Enable editing of Instance Template
Cannot make changes after saving the Instance Template
Rahul Pathak
shared this idea
This is something we are planning to improve, hopefully later in the year.
14 comments
-
Emilio
commented
I have a new image I would like to swap out on my templates... Leaving everything in place just change the image... But it wont let me edit ;-(
-
Emilio
commented
Please get this pushed out! Its been a 1 1/2 years
-
Craigiebabe
commented
So I noticed in AWS CloudFormation, you describe a launch configuration (roughly equivalent to instance templates), without actually specifying a name or id for it.
This means the launch configuration is more or less anonymous in the CloudFormation YAML You can still reference the launch configuration from within other parts of the YAML by its logical name.
This means that when you change the image id in the launch config, CloudFormation will "under the hood" delete the Launch Configuration object, then create a new Launch Configuration referencing the new sourceImage.
You should be able to do something similar when declaring instance templates in deployment manager configuration files.
-
Craigiebabe
commented
Even if you only allow the sourceImage in unbound instance templates (i.e. not associated with any instance groups) to be updated, that would allow us to define a pair of instance templates in our Deployment Manager scripts, and toggle between them to perform updates via Deployment Manager.
-
Craigiebabe
commented
If I update the sourceImage in my instance-template, I get NO_METHOD_TO_UPDATE_FIELD. This means I cannot use deployment manager to trigger an update to my instance group.
Either (a) allow instance templates to be updated, or (b) make the deletion and recreation of instance templates happen in a way transparent to the user (under the hood, as it were).
The benefit of this include:
* Avoid configuration drift
* Avoid DM inconsistency whereby sourceImage can be updated on an instance, but not on an instance group
* Allows DM to be used to roll out application (sourceImage) changes - a very common DevOps use-case -
Ivo
commented
I just ran into this using the deployment manager. It is pretty inconvenient having to duplicate and rename all the resources when you want to change anything, network tags, machine type etc.. (Or alternatively having to take the whole stack down and recreate everything). AWS handles that seamlessly with CloudFormation: They call it Launch Configuration and only newly launched instances use the template. On update, autoscaling groups replace the instances gradually according to the settings (respecting cooldown periods etc.).
It would be great if that would be possible on GCP too. -
One other note - Copy Template as available in the UI is not a core API feature, but something the UI is doing on top, which may explain why the behavior you're describing isn't quite what you want. However, we should be able to patch that, at least. Please comment back if you like about which settings it is/isn't copying and I'll see if we can adjust that without breaking users' expectations generally.
-
Thanks, Carl, those are great insights, and we agree. I've updated the status to indicate that we are actively planning improvements here (the possibility of different behavior when in use vs. not that you note is one example of something that takes some extra design time).
-
Carl Smith
commented
Understanding that editing an Instance Template (IT) that is in use could lead to problems with mixed instances in the same group, however, editing an IT that is not in use on an Instance Group would make things a lot easier to make a tiny change.
Especially when the "Copy Template" does not always copy ALL of the settings across to the new template. I have had things like "Delete Disk" and metadata not copy across to the new template (even just now).
-
Dane MacMillan
commented
This would be great to have.
-
Thanks for the feedback in these comments. I think at this point we understand what users are looking to do, and we're investigating changes that would allow this. The evolution of this limitation is due to what Scott described earlier - templates started as a requirement for MIGs, but they have since evolved into a more general "make a VM like this" function of the platform. I hope we can make improvements here in the near future.
-
Jay
commented
Well if everything could be editable and version controlled that would be great.
-
Zach Bjornson
commented
A similar case of handling mutability in GCP is how you can change the template for an instance group. If you change the template, then any newly created machines will be updated, but existing machines will be unchanged. It seems like that same type of thing could be applied to instance templates.
Note that because instance templates can refer to an image family, you can essentially mutate an instance template by publishing a newer image to the family. Thus there is currently no guarantee that template instances are identical.
-
Hi Rahul,
An Instance Template is for stamping out VMs for Managed Instance Groups, ensuring that the VMs within a MIG are all the same. Semantics for allowing edits to ITs, then, could get pretty ugly resulting in weird restrictions (e.g., only allowed to edit if it is not part of an active MIG) or bad MIG behavior (e.g., a MIG has a mix of VMs because the IT was edited).
Our current thinking is that it is safer and conceptually consistent to simply have the user create a new IT, but I'm interested to hear what the community thinks so I'll leave this one open for more comments for now.