Repository navigation
Network_Firewall_AccessControlList service not respecting new object mask #48
Description
We are finally getting around to merging our own api wrapper with the 2.x+ gem here so we can start work on the new semantic models, but we're hitting a few bumps.
We've found at least one service that seems to ignore the new object mask string. Here's some test code that isolates this behavior along with the outputs.
## vvvvv Comment in/out gem version along with appropriate object mask
#gem 'softlayer_api', '=1.0.7'
#OBJECT_MASK = { 'id' => '', 'rules' => { 'id' => ''} }
#gem 'softlayer_api', '=2.1.1'
#OBJECT_MASK = "mask[ id, rules [ id ] ]"
## ^^^^^ Comment in/out gem version along with appropriate object mask
require 'softlayer_api'
require 'pp'
user = "abc"
api_key = "xyzxyz"
firewall_id = 2132 # provide a valid firewall ID
service = SoftLayer::Service.new("SoftLayer_Network_Firewall_AccessControlList", :username => user, :api_key => api_key)
result = service.object_mask(OBJECT_MASK).object_with_id(firewall_id).getObject
pp result
with v1.0.7:
{"id"=>2132,
"rules"=>
[{"id"=>1273226},
{"id"=>1273228},
{"id"=>1273230},
{"id"=>1273232},
......
with v2.1.1:
{"direction"=>"in", "firewallContextInterfaceId"=>4235, "id"=>2132}
We haven't found any way to get this mask to work.
Activity
SLsthompson commentedon Aug 4, 2014
After some discussion with the development team, this appears to be a bug in the way extended object masks are applied to "getObject" calls. The work around would be to use object masks in the "old" format (which the current Ruby client will not allow you to do). Or to make a separate call to request the rules of the ACL directly
Given that information... it may be most prudent to add some mechanism to the gem that allows you to provide object masks in the 'old' format if you wish.
cbreden commentedon Aug 4, 2014
Do you have any idea if the bug will be addressed by the dev team soon? This is the main issue holding us back at the moment. While I'm not opposed to an interim fix that accepts the old mask, it would get messy to bounce between the two masks constantly.
SLsthompson commentedon Aug 4, 2014
I do not have any information about how (or when) the bug might be addressed by the development team.
SLsthompson commentedon Aug 7, 2014
The bug concerning the application of object_masks in the getObject call has been addressed and passed QE. It still must work it's way through the production process, but should be in place next week.
cbreden commentedon Aug 7, 2014
That's great news, thank you.
SLsthompson commentedon Aug 12, 2014
The bug fix for using extended object masks with the firewall rules is released and in production. Please re-visit the issue and let me know if it still does not work for you.
I noticed and reported a similar problem where using a mask while calling "getRules" for a server firewall does not apply the mask to the rules (you always get back the full set of information).