Support for Auto Scaling Group Tags #380
Conversation
|
asgard-pull-requests #147 SUCCESS |
|
asgard-pull-requests #148 SUCCESS |
|
It's a big change and there are some issues. We'll have to review it and give feedback for revisions and discussion, but we can't promise immediate focus on this yet due to other priorities. |
|
@joesondow no problem, that's understandable. We did submit this as part of Cloud Prize, so if you guys do have any feedback that would relate to the quality of the submission that would be appreciated. |
|
This is a feature that we need in order to transition from using Cloudformation to Asgard. +1 |
|
👍 This is a feature I'd love to see added. It'd help out with transitioning a second product onto Asgard without interfering with our existing workflow. |
|
@joesondow Any thing we can do to get this reviewed, commented on, an discussed? Should we just wait until AWS web ui allows us to add tags? |
|
@joesondow @claymccoy Hey guys. I updated my code to reflect the current state (1.4.1). It's possible my job function will be changing, so I would love to get this merged in before that happens. Please let me know if any priority can be placed on this. |
|
asgard-pull-requests #253 FAILURE |
…w template new template for tag details, showing propagate on edit new tag table
Added jQuery code to dynamically add and remove rows to Tag table. Added ability to add new tags from ASG edit.
Added the ability to edit tags on sequential ASGs and view existing tags on rolling push. Working Unit Tests Minor Cleanup
Cleaned up a few errors reported by codenarc Fixed bug in creating new Cluster ASG. Submitting a new ASG without tags was creating an exception. Leveraging noOptionalDefaults corrects the issue and allows the unit tests to pass.
Updated to 1.4.2 code Fixed a few bugs Bug fixes have re-enabled the ability to make an ASG as inactive Codenarc cleanup
|
asgard-pull-requests #308 FAILURE |
|
Cleaned up a few bugs and got this updated to 1.4.2. I have left the team that uses this, so it may be my last major update. |
|
We haven't forgotten about this, and it's a useful feature for a lot of people so I'm planning to address it in the next couple of weeks. There's a lot to talk about when it comes to ASG tagging, so this topic has been on our back burner for a while, but let's see if we can sort out the risks and solve them. In the next few weeks I expect to have time to return to this pull request and to #514 to see what I can do to add the functionality while avoiding the problems listed below. The issues I know of are these: Warn users about risk of tag relianceASG tags are super convenient, but anyone who relies on them today needs to be cognizant of the fact that Amazon's API sometimes omits all tags for a brief time with no indication that the response has a partial failure. In other words, there is no way to know whether someone in your company deleted all your tags or whether Amazon's tag system simply didn't respond fast enough to Amazon's auto scaling system, so the auto scaling system simply omitted the tags in the response to your API call. Silent failure. Not good. When and if Amazon improves their auto scaling API to allow callers to state in each request that partial results should result in a totally failed response (so we can ignore that response and retry until we get a full success) then the risk will go away. Until then, offering obviously useful ASG tags could encourage development teams who deploy with Asgard to rely on those tags for production runtime behavior, which could easily cause accidental outages because tags only show up most of the time. To mitigate this problem, I think Asgard needs some fairly strong looking warnings on the tag input forms so users can understand that they should only rely on tags if their use case can easily tolerate the fact that the tags will seem to disappear and reappear at times, although the majority of the time the tags will work fine. Some tags should be copied to the next ASG, but not allThere are two reasons people want to tag ASGs. Either they want to indicate something distinctive about a single disposable ASG, or they want to indicate something distinctive about the entire cluster of all the current and future ASGs in the cluster. The uniquely tagged ASG case is simpler to implement, and there are legitimate use cases for it. However, other users will assume that all characteristics of the previous ASG will be copied to the next ASG, including tags. This is why there is another later pull request #514 to try to have Asgard copy all tags from the previous ASG to the next ASG in a cluster. I know of teams who want to tag ASGs specifically to mark each ASG in a cluster differently from each other. Those teams want tags that will definitely not be copied to the next ASG in the cluster. I also know of other teams who only care about tagging their cluster. They want all their ASGs to have the same tags and they want no risk of losing those tags during a cluster-based deployment of a new ASG. In order to avoid an unpleasant surprise for either of those types of teams, we need to adopt an Asgard-specific naming convention for the keys of the tags that should be copied to the next ASG. Since Amazon uses key for their tags like "aws:autoscaling:groupName" I think Asgard should prefix keys of tags intended for an entire cluster with "cluster:" and then only copy the tags starting with that prefix on to the next ASG. Dangerous, unreliable tag copying to the next ASGThe danger is that sometimes there is a tag service outage just at the wrong moment when you've loaded or submitted the Create Next ASG form, and Amazon's Auto Scaling API erroneously states that there are zero tags in the previous ASG, and Asgard has no secondary way to verify whether or not that empty set of tags is currently correct. So what does Asgard do in that situation? It makes the next ASG with zero tags and no errors because zero tags is also a normal case. Users are then unpleasantly surprised when they discover that all the ASGs in their cluster from v384 onward have no tags, even though the tags were always present on v000 through v383. What would have caused this? Asgard would be the culprit, by incorrectly assuming that tags are as reliable as all the other ASG fields. What those users really want is to tag a cluster, but Asgard has no mechanism for that yet other than to tag one or all of the ASGs within the cluster, since the cluster's existence is merely inferred from the existence of the matching ASGs. So, if we're going to copy any tags to the next ASG, we need to add clear messaging on the ASG forms that tag ASGs, and the forms that create the next ASG, to tell users about the inherent risk that there is a possibility that any tags put on an ASG may or may not get copied to the next ASG, depending on the behavior of the Amazon API. Retrying the API call repeatedly for a long time is not helpful if Asgard has no way of knowing which ASGs are supposed to have some tags and which ones are supposed to have zero tags. One way to handle this is to have a background process that continuously looks to copy each "cluster:" prefixed tags to all other ASGs in that cluster where the tag is missing. This is a somewhat more advanced change to undertake, but it would be a fairly good mitigator, since a previous ASG almost always hangs around for at least a few minutes before someone deletes it, which is probably enough time for Amazon to be consistent about having a window of time where the tag service is available to the auto scaling service. There is precedence for a safety net workaround like this in Asgard, since Asgard is already capable of being configured to copy AMI tags continuously from a source account to a target account (in Netflix's case, from the test account to the prod account). Untested JavaScriptThe implementation issue is that each time we add more JavaScript to make our forms more complex, but we have no automated testing for that JavaScript, we take on more technical debt and more risk that we'll break something later. We won't have time to test every use case of the form's behavior manually every time we change code that we didn't even realize would break something. For example, if we change the Groovy and GSP code and all our Groovy tests pass and a simple use of the form works in a browser, it's unlikely we'd notice that we broke the assumptions of the JavaScript for some other case. This is why we have avoided adding too much JavaScript so far. The good news is that Clay McCoy has just added AngularJS and Yeoman in #542, including a bunch of automated unit tests that will run on our CloudBees Jenkins server as part of the Asgard build. That framework addition should make it feasible for us to write fully unit testable JavaScript that we don't have to worry about so much. |
|
Any updates on this? Mostly concerned with getting the "Name" field populated correctly to make quickly scanning the list of instances in the console easier. To be fair, searching still returns accurate results as ASGs automatically tag instances with the name of the ASG that launched it. |
|
It's been half a year, is there any further update on this? I'm trying to use Netflix's own Ice tool, but can't seem to get it working because Asgard isn't tagging things... |
|
Hey All! |
|
Curious on the status of this. I am also using ICE at work and would love for the Billing tag to propagate to new ASGs rather than having to manually go add the tag later. |
This enhancement provides the ability to create and edit tags for Auto Scaling Groups. Specific functionality is to add tags on ASG creation, add/edit/delete tags on existing ASG's, add/edit/delete tags on sequential ASG's, and view tags on rolling ASG's.
Client side validation is done to ensure tags and values are unique, and there are no more than 10 tags per ASG.
This feature satisfies feature request #219