Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AutoscalingGroups with a TargetGroup set are not parsed correctly #308

Closed
msiuts opened this issue Oct 13, 2016 · 1 comment
Closed

AutoscalingGroups with a TargetGroup set are not parsed correctly #308

msiuts opened this issue Oct 13, 2016 · 1 comment

Comments

@msiuts
Copy link
Contributor

msiuts commented Oct 13, 2016

There is an issue with parsing the response of DescribeAutoscalingGroups.

We have 52 ASGs. Two of them have one TargetGroup associated.
image

When we get all the ASGs via fog with something like Fog::AWS[:auto_scaling].groups the two ASGs with the assigned TargetGroups are not parsed correctly and appear two times in the list with different attributes not set (nil) for example the ARN or the Id.

Here are some steps that show the issue:

irb(main):005:0* require 'fog/aws'
=> true
irb(main):006:0> asg_ids = Fog::AWS[:auto_scaling].groups.all.size
=> 54
irb(main):007:0> asg_ids = Fog::AWS[:auto_scaling].groups.all.select{ |g| g.arn}.size
=> 52
irb(main):008:0> asg_ids = Fog::AWS[:auto_scaling].groups.all.select{ |g| g.id}.size
=> 52

The issue seems to be in the parser which does not recognize the TargetGroups element and closes the parsed ASG too early and starting the next one.

I think it would be easy to provide support for TargetGroups and we are going to provide a PR for this.

It should be discussed how the parser (DescribeAutoScalingGroups) can be more robust for new elements, especially since the AWS-API version does not seem to be pinned.

@geemus
Copy link
Member

geemus commented Oct 18, 2016

I think we do pin the version actually: https://github.com/fog/fog-aws/blob/master/lib/fog/aws/compute.rb#L462

Unfortunately, the changelog from AWS sometimes leaves something to be desired (so we occasionally miss things like this). I think the parsers usually do a pretty good job of being resilient (at least in terms of continuing to work as expected, but just lacking new info), but we definitely have some outliers like this. Hopefully it is the exception rather than the rule, but certainly worth keeping an eye on.

Going to go ahead and close this in favor of the PR, which looks like it has the particular issue in hand.

@geemus geemus closed this as completed Oct 18, 2016
lanej added a commit that referenced this issue Oct 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants