)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"abf94a00db688905c9454687a558fdbce3552b55","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"5cdb4440_0cf27069","updated":"2021-11-30 13:56:41.000000000","message":"Excuse my wall of text, but I would like for this discussion to end fruitfully - be it a reviewed and accepted spec or a rejected feature.\n\n\n\nI read the discussion from your last meeting  (https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2021-11-23.log.html)\nand am wondering if there is a way going forward with this proposal, meaning making changes to the spec and then consequently to the already\nexisting implementation and code jhartkopf wrote (https://review.opendev.org/c/openstack/nova/+/816157) to allow for mutable userdata.\nIf I may sum up what I believe is the current state of things:\n\n\n1) Use-cases for cloud administrators to modify instance userdata\n\n First of all, I would fully agree to ditch all potential cloud administrator use-cases for mutating the userdata from this spec.\n This data should solely remain in the domain of the user.\n\n\n\n2) Use-cases which benefit from mutable user-data\n\nOne major part of the discussion was the lack of use-cases. We established that the  use-cases for mutable user-data certainly are more with\nclients other than cloud-init. As even though it does allow to be run on every boot, this scenario less common.\nBut other tools, clients and approaches on consuming user-data can benefit from it being mutable by the user during the life of an instance (not requiring a rebuild):\n\n\n a) First there is cloudbase-init (https://github.com/cloudbase/cloudbase-init/), which is quite common for Windows machines running on OpenStack.\n    This is the use-case we hit after a customer raised a support case about being unable to update the userdata of an instance.\n    Cloudbase-Init documents their plugins being run on every boot, picking up changes in userdata.\n    While it\u0027s certainly possible to e.g. modify the timeservers manually or via config management after the instance has been brought up,\n    allowing for mutable user-data keeps all those settings and changes in a single place.\n    Provided there is no proper config management being used anyways and only settings taken from the initial user-data are changed.\n    See point #3 for more on the documentation of mutable user-data.\n\n\n b) Cloud-Native / Ephemeral Operating systems\n\n    There are OS which are not managed in a traditional sense, with packages being installed via package management\n    and a config management tool being used to configure them. But rather an ephemeral image to which a single config \"file\" is applied.\n\n    Some examples are:\n\n      * TalosOS https://www.talos.dev/docs/v0.13/cloud-platforms/openstack/#compute-creation\n      * Rancher\n      ** K3OS: https://github.com/rancher/k3os#phases // https://github.com/rancher/k3os#etc\n      ** Rancher RKE: https://rancher.com/docs/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/#cluster-config-file\n\n    even though the instances of such OS could also be rebuild, a reboot with a changed configuration is usually much quicker.\n    And not all clouds have OpenStack Heat available to manage the migration of an instance pool from one config to the other.\n\n\n c) Scripts to setup instance after boot\n\n    I understand that looking towards other (public) clouds does not make for a use case for mutable userdata in itself.\n    But taken from the prominently documented ability to update userdata and to place scripts there to run certain basic steps\n    on every boot - this is an actively applied design practice in cloud environments:\n      * https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-user-data.html#user-data-execution\n      * https://docs.microsoft.com/en-us/azure/virtual-machines/user-data#what-is-user-data\n      * ...\n\n    being able to edit this script is all that mutable user-data would provide.\n\n    This approach is not about managing packages or modifying config files, which is the job of a config management -\n    no objections to what your said Sean.\n    But rather to allow for less modifications of the instance and rather use a script to apply startup parameters or e.g.\n    join commands for some clustered software. And those instructions might change.\n\n    This is somewhat similar to (b), having an image containing all the packages and userdata just being the \"configuration\" source.\n    Similar to a container receiving environment variables or a config file, but being immutable otherwise.\n\n\n d) NFV or other virtual appliances which consume their \"config\" via userdata.\n\n    Apparently Vadim Ponomarev had some particular examples.\n\n\n\n2) Compatibility with config drive\n\n  Sean you said \"jhartkopf: we could proably make it mutable if there is a use facing usecase but we would need to support config dirve and note that the change may not fully be ableable untill after a hard reboot\".\n\n  As for the config drive there are multiple ways dealing with mutable userdata\n  if a config drive is used:\n\n  a) Allow it and document clearly that the content of the drive will only be visible to the instance after a reboot.\n  b) Reject it always and respond to the API call with a clear message indicating that userdata cannot be updated if a config drive is used.\n  c) Reject it for running instances with an equally clear message instructing the user to shut the instance down prior to the change of userdata.\n\n  Reading your statement again, Sean, I believe you like (a) the most?\n\n\n\n3) Documentation\n\n  As for every feature the documentation should also guide the user in making the best use of it. In this case the documentation shall point out clearly that:\n\n  \"User data is a blob of data that the user can specify when they launch an instance and modify it afterwards.\n  The instance can access this data through the metadata service or config drive.\n  Nova does not provide any form of syntax validation, state or config management. This data and even more any mutation to it during the instance lifetime,\n  needs to make sense to a particular client-side software on the instance.\"\n\n  (As addition to https://docs.openstack.org/nova/latest/user/metadata.html#user-data)\n","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d7a169d2e7c4ef4097ed362bf8e2138f150c3410","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"1088ef21_b1bfccd0","updated":"2021-11-08 12:03:16.000000000","message":"I miss two things to be defined in the spec:\n\n* When and how nova will regenerate the config drive, and how the new config drive will be plugged to the instance, if we allow update while the instance is running.\n\n* How can guest consume the updated data if cloud-init only reads that at firstboot. I see that discussion about it is ongoing. That is good, let\u0027s document the result of that.\n\n\n","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"cf40fd2dfc45ba52b291fe7cd6a98780ba4f0246","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"cfc38ee6_e93cfcb9","updated":"2021-11-16 14:28:21.000000000","message":"Sorry but I feel strongly against this proposal : the use cases don\u0027t sound to me legit. For sure, you *COULD* modify the user data if you like, but you *CAN* also use config management tools for achieving such things.\nThe mission of Nova has never been to provide external tools for managing the application level but rather providing APIs that can help such tools for managing the created instances.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"b49be2b3258e0ae7b3a91c86399587e7c7fe320a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"7b6d134a_bae505c5","updated":"2021-11-05 11:00:55.000000000","message":"Thank you Sean for picking up on this new spec so quickly and for your kind review and rich comments.\nI added some responses and comments to your remarks.\n\nHow can we proceed with the discussion to get a nice and focused spec ready?\nThis idea has been discussed multiples times and quite thoroughly in the blueprint https://blueprints.launchpad.net/nova/+spec/userdata-modification and there even was (at least) one implementation done (https://review.opendev.org/c/openstack/nova-specs/+/547964/), unfortunately then abandoned.\n\nThere even was an approved spec https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/user-data-modification.html\n\nJan did pick up on this and implemented the required changes to the nova API and the novaclient:\n\n* https://review.opendev.org/c/openstack/nova/+/816157\n* https://review.opendev.org/c/openstack/python-novaclient/+/816158\n\n\nAnd in the review Takashi Natsume pointed out, that writing a spec for this feature as first step would make sense.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"c24b47f34ced0526a86d3e4ee0dca46f1bc2f68d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"bde77ede_13c39995","updated":"2021-11-16 21:18:42.000000000","message":"Vadmin, Pavel, Mikhail, Tetiana - I took the liberty to add you as reviewers to this proposed spec since you did support a similar spec for the OpenStack Rocky release (https://review.opendev.org/c/openstack/nova-specs/+/547964/) and were talking about use cases in which user_data holds config data for e.g. a Juniper vSRX (NFV) or similar virtual appliances and having the capability to update the user_data was beneficial to having to go through a rebuild.\nMaybe your use-cases are still valid and you could kindly contribute to this review as well?\n\n\nSteve you did write the blueprint (https://blueprints.launchpad.net/nova/+spec/update-userdata) also proposing the capability to update the user_data of an instance.\n","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b6ef496b3cfb752fca6f68e564ee0a870a71ef9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0d915a7f_c48b4a3e","updated":"2021-11-03 19:08:50.000000000","message":"im not fully conviced that this is the right way to approch this.\n\ni think this is yet another usecasue that would be better served by an extention to the resize api to allow resizing to the same flavor and in this case also allow updated to the user data as part of that operation.\n\nor better a dedeicated recreate instnace action but if we were to proceed with this as planned we would either need to require the vm is stop when the update is done or document that the change will not fully take effect until the instnace has been hard rebooted or moved via a cold migration or shleve/unshelve.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"b49be2b3258e0ae7b3a91c86399587e7c7fe320a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"26cc511f_c0a1515b","in_reply_to":"0d915a7f_c48b4a3e","updated":"2021-11-05 11:00:55.000000000","message":"Certainly the implications of a required reboot depending on consuming piece of software would need to be well documented. But they are the same as on other platforms which support updates to the user_data. \n\nRequiring the instance to be stopped (as AWS does) has the downside, that declarative tools like Terraform have a hard time to make use of the new flexibility.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"aae8ec100af3d956612a3cba6a614d91c01a55d4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"90767fae_fc5246e9","in_reply_to":"1088ef21_b1bfccd0","updated":"2021-11-15 14:08:02.000000000","message":"The intention for this spec/change was mainly to support updating user_data in the metadata service.\nWhile there are definitely people using a config drive, I would suggest to not support this use case and stick with the metadata service.\nConfig drives are static by design and do not fit the possibility to dynamically update user_data.\n\nWhen someone updates user_data via the new microversion\u0027s extended PUT API, we could check whether the instance uses a config drive and reject the update request in that case.\n\nWould this approach be sufficient to handle the usage of config drives?\n\n\nTo address your second point, as Christian already mentioned, there are many different ways for a guest to consume the updated user_data. For example, they could reset the current cloud-init state and re-init, or use custom software which parses the current user_data in the metadata service.\n(Of course, this could be a manual process to start in addition to calling the Nova API.)","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":27256,"name":"Vadim Ponomarev","email":"velizarx@gmail.com","username":"velizarx"},"change_message_id":"252def45d7989093bc907f1fb83ba89dd5b1ed32","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"babf17c5_ab746290","in_reply_to":"19909d74_888eb164","updated":"2021-11-17 08:16:39.000000000","message":"Hey Christian! We resolved our issues by creating the patch for our fork of OpenStack Nova. 3 years ago we pushed these changes to Rocky to implement such functionality in upstream but for now we do not want to spend a time for this.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"27758fbd11e20f3324ac781b5b6828854efc9121","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b27a309b_669cb3aa","in_reply_to":"1a8f35a6_8a420f36","updated":"2021-11-16 09:32:54.000000000","message":"Updating user_data via a rebuild is already possible (https://docs.openstack.org/api-ref/compute/?expanded\u003drebuild-server-rebuild-action-detail#rebuild-server-rebuild-action).\nI don\u0027t think this would be a fitting solution as it adds basically the same feature just to another API (and even requires calling the existing Rebuild API afterwards).\n\nThe whole point of this spec is to be able to update user_data without rebooting or rebuilding the instance. If someone wants to change user_data and is fine with rebuilding, they can simply use the rebuild action.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":27256,"name":"Vadim Ponomarev","email":"velizarx@gmail.com","username":"velizarx"},"change_message_id":"7a5084304d492fc2525dbcbef02bbfd38959ac97","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"da15edfc_f4f062ca","in_reply_to":"54150591_4aff210a","updated":"2021-11-20 12:46:12.000000000","message":"We tried to implement this feature 5 months in the linked patchset, despite the fact that adding improvements to the upstream didn\u0027t help us in any way. The patchset just waited for review for 2 months from core reviewers. In the end, it became clear to us that no one except us needed it. So I don’t understand why we should waste our extra time on this.\nNowadays we are still using this patch in production and changing it for newer releases every year. With this patch, we are setting SSH keys inside VM because the usual way doesn\u0027t work with multiple keys, and doesn\u0027t work with domain-level users.\nThe use case for NFV is still valid but we are not using NFVs in our infrastructure now.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e7b1933a0f28e58d2c34300db95cf4b192eedeb2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a32ad396_70dfc1ce","in_reply_to":"5cdb4440_0cf27069","updated":"2021-11-30 16:57:18.000000000","message":"\u003e Excuse my wall of text, but I would like for this discussion to end fruitfully - be it a reviewed and accepted spec or a rejected feature.\n\nno need to appologies.\n\nthis is often eiser to respond to in line rather then as a top level comment but this works too.\n\u003e \n\u003e \n\u003e \n\u003e I read the discussion from your last meeting  (https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2021-11-23.log.html)\n\u003e and am wondering if there is a way going forward with this proposal, meaning making changes to the spec and then consequently to the already\n\u003e existing implementation and code jhartkopf wrote (https://review.opendev.org/c/openstack/nova/+/816157) to allow for mutable userdata.\n\u003e If I may sum up what I believe is the current state of things:\n\u003e \n\u003e \n\u003e 1) Use-cases for cloud administrators to modify instance userdata\n\u003e \n\u003e  First of all, I would fully agree to ditch all potential cloud administrator use-cases for mutating the userdata from this spec.\n\u003e  This data should solely remain in the domain of the user.\n\u003e \n\nack, +1\n\n\u003e \n\u003e \n\u003e 2) Use-cases which benefit from mutable user-data\n\u003e \n\u003e One major part of the discussion was the lack of use-cases. We established that the  use-cases for mutable user-data certainly are more with\n\u003e clients other than cloud-init. As even though it does allow to be run on every boot, this scenario less common.\n\u003e But other tools, clients and approaches on consuming user-data can benefit from it being mutable by the user during the life of an instance (not requiring a rebuild):\n\u003e \n\u003e \n\u003e  a) First there is cloudbase-init (https://github.com/cloudbase/cloudbase-init/), which is quite common for Windows machines running on OpenStack.\n\u003e     This is the use-case we hit after a customer raised a support case about being unable to update the userdata of an instance.\n\u003e     Cloudbase-Init documents their plugins being run on every boot, picking up changes in userdata.\n\u003e     While it\u0027s certainly possible to e.g. modify the timeservers manually or via config management after the instance has been brought up,\n\u003e     allowing for mutable user-data keeps all those settings and changes in a single place.\n\u003e     Provided there is no proper config management being used anyways and only settings taken from the initial user-data are changed.\n\u003e     See point #3 for more on the documentation of mutable user-data.\n\u003e \n\nSo to parapharse. \n\nusecase 1 is:\n\nAs a user i want to dynmicaly reconfigure the time/name servres used by my instance via user data to update theses settign using the same interface (user-data) i intially used to bootstrap the vm.\n\n\nthis is still somewhat nebulus but i could support that as a resonable request.\n\n\u003e \n\u003e  b) Cloud-Native / Ephemeral Operating systems\n\u003e \n\u003e     There are OS which are not managed in a traditional sense, with packages being installed via package management\n\u003e     and a config management tool being used to configure them. But rather an ephemeral image to which a single config \"file\" is applied.\n\u003e \n\u003e     Some examples are:\n\u003e \n\u003e       * TalosOS https://www.talos.dev/docs/v0.13/cloud-platforms/openstack/#compute-creation\n\u003e       * Rancher\n\u003e       ** K3OS: https://github.com/rancher/k3os#phases // https://github.com/rancher/k3os#etc\n\u003e       ** Rancher RKE: https://rancher.com/docs/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/#cluster-config-file\n\u003e \n\u003e     even though the instances of such OS could also be rebuild, a reboot with a changed configuration is usually much quicker.\n\u003e     And not all clouds have OpenStack Heat available to manage the migration of an instance pool from one config to the other.\n\nthis usecase has less weight to it in my view since cloud native/ephemeral operating systems are intened to be redeploy when the configuration changes.\n\nThat was one of the reasons we extended the rebuild api to suport an updated userdata in the first place.\n\nas such i dont think there is a valid usecase for Cloud-Native / Ephemeral Operating systems. the correct way to manage such application is to delelte and recreate them. if you modify them after they are deploy the are nolonger Cloud-Native / Ephemeral Operating systems they are stateful workloads. as such i woudl drop this.\n\n\u003e \n\u003e \n\u003e  c) Scripts to setup instance after boot\n\u003e \n\u003e     I understand that looking towards other (public) clouds does not make for a use case for mutable userdata in itself.\n\u003e     But taken from the prominently documented ability to update userdata and to place scripts there to run certain basic steps\n\u003e     on every boot - this is an actively applied design practice in cloud environments:\n\u003e       * https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-user-data.html#user-data-execution\n\u003e       * https://docs.microsoft.com/en-us/azure/virtual-machines/user-data#what-is-user-data\n\u003e       * ...\n\u003e \n\u003e     being able to edit this script is all that mutable user-data would provide.\n\u003e \n\u003e     This approach is not about managing packages or modifying config files, which is the job of a config management -\n\u003e     no objections to what your said Sean.\n\u003e     But rather to allow for less modifications of the instance and rather use a script to apply startup parameters or e.g.\n\u003e     join commands for some clustered software. And those instructions might change.\n\u003e \n\u003e     This is somewhat similar to (b), having an image containing all the packages and userdata just being the \"configuration\" source.\n\u003e     Similar to a container receiving environment variables or a config file, but being immutable otherwise.\n\nthe issue with this is using user-data not metadata and by updating the user data you nolonger have repoduciblity. a vm redeployed with the current user data from the same image may not be fucional if a step done in a previous user-data is not contaied in the latests. if  this was docker user-data would be the dockerfile\nand you would be embeding confirution in the build script which is seen as a bad partice in the contaienr world and it should be the same in openstack.\n\n\nconfigureing of application inside the application is already a support usecase of generic metadata not user data.\n\nfor example the standardised metadata for dbs,webservers and software runtime\n\nhttps://github.com/openstack/glance/blob/master/etc/metadefs/software-databases.json\nhttps://github.com/openstack/glance/blob/master/etc/metadefs/software-runtimes.json\nhttps://github.com/openstack/glance/blob/master/etc/metadefs/software-webservers.json\n\ni guess usage is the arbiter of usefullness and the fact that peopel are not using the server metadata api to pass those parmaters shoudl be factored into this review.\n\nthe intended behavior was that an instance would  have a on boot script (e.g. systemd service) that woudl run and read the mutable content form the metadata api/config driver and use that to run the intended applciation.\n\nthe metadata api prvides exactily the same fucntionality that envionment vailable proivide to contaienrs.\n\nhere i guess the request is to use cloud-init instead of a user provided scritp to be that on boot process and to that end you want to also modify the user-data as an input instead of relying on the server metadata.\n\nif i was to reformulate this as an actual usecase it would be somethign like this.\n\nAs a user with expericne with provioning epmeral workload with tools like cloud-init i would like to also mange my stateful workload via userdata and metadata on each boot. metadata to store my external confgurion and userdata to perfrom operation such as rejoining a cluster when the update has been applied.\n\n\n\u003e \n\u003e \n\u003e  d) NFV or other virtual appliances which consume their \"config\" via userdata.\n\u003e \n\u003e     Apparently Vadim Ponomarev had some particular examples.\n\nyes the way this is ment to work is the user data script is ment to read data form the metadata api to then retrive the config form else where.\nthe userdata script is ment to work similar to the kbugblet when dealing withconfig maps works with k8s. it should look up the configuration data form the metadata service which may be a reference to an external store like swift or may have the data inline.\n\nthese VNFs are just stateful workloads so i think they are coverd by my restated version of usecaes c. so i would remove this.\n\n\u003e \n\u003e \n\u003e \n\u003e 2) Compatibility with config drive\n\u003e \n\u003e   Sean you said \"jhartkopf: we could proably make it mutable if there is a use facing usecase but we would need to support config dirve and note that the change may not fully be ableable untill after a hard reboot\".\n\u003e \n\u003e   As for the config drive there are multiple ways dealing with mutable userdata\n\u003e   if a config drive is used:\n\u003e \n\u003e   a) Allow it and document clearly that the content of the drive will only be visible to the instance after a reboot.\n\nthis could work but i do not think we currently regenerate the config_drive\non every hard reboot so we would need to figure out how to mark the\nvm so that is done only when needed.\n\nit would be better to allow user-data to be updated via the hard reboot\ninstance action instead of on running vms in this case.\n\nfor example we could reject the user data update if the vm has a config\ndrive via a normal server update but allow it on hard reboot instance action.\n\n\u003e   b) Reject it always and respond to the API call with a clear message indicating that userdata cannot be updated if a config drive is used.\nim -1 on this approch.\n\n\u003e   c) Reject it for running instances with an equally clear message instructing the user to shut the instance down prior to the change of userdata.\n\nthis still has the complexity of trying to track when we need to regenerate the config drive with less usableity then a unless we make it condigional on the use of config drive.\n\n\u003e \n\u003e   Reading your statement again, Sean, I believe you like (a) the most?\n\ni would propose reject it for server update if using config drive and allow\nuser data to be passed on hard-reboot which would regenerate the config drive\nfor config drive users.\n\n\n\u003e \n\u003e \n\u003e \n\u003e 3) Documentation\n\u003e \n\u003e   As for every feature the documentation should also guide the user in making the best use of it. In this case the documentation shall point out clearly that:\n\u003e \n\u003e   \"User data is a blob of data that the user can specify when they launch an instance and modify it afterwards.\n\u003e   The instance can access this data through the metadata service or config drive.\n\u003e   Nova does not provide any form of syntax validation, state or config management. This data and even more any mutation to it during the instance lifetime,\n\u003e   needs to make sense to a particular client-side software on the instance.\"\n\u003e \n\u003e   (As addition to https://docs.openstack.org/nova/latest/user/metadata.html#user-data)\n\nyes verbage such as this could and likely should be added there +1\n\u003e \n\nover all im somewhat open to this but i disagree with the postioning of some of the usecases.\n\ni belive i have rephased 2 that i can live with as real end user usecase that could be enabled by this spec that are not operator driven or cause by vnf vendors misusing our apis today.\n\nif you update the spec with thoses uscases ill re review and we can see if we can move this forward.\n\nwith that said i still want to hear form sylvain and other if they supprot this change in the next revision fo the review before im comfrotable with changing my -1 to a +2","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"953c9a8153fbd15ac7b4148815a5d091752617ac","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"1a8f35a6_8a420f36","in_reply_to":"90767fae_fc5246e9","updated":"2021-11-16 08:52:06.000000000","message":"Hm. Rejecting metadata update if the instance uses config drive could be an option yes. An alternative option would be to document that if the instance uses a config drive then the metadata change will only be visible to the instance after the instance is rebuilt.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"87c450ab16a553158e22b8797bbc53725fc3fb44","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"54150591_4aff210a","in_reply_to":"babf17c5_ab746290","updated":"2021-11-19 09:41:44.000000000","message":"Thank your Vadim for your response. Too bad you don\u0027t have time to join the effort  on getting this functionality into upstream or at least discuss this further.\n\nBut do you mind sharing your use case(s), as this seems to be more questioned aspect of the proposed change, and you supposedly are still running your own patch in production?","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"17831e9ee679a5061c973e69fbca55b1416b1b1f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"19909d74_888eb164","in_reply_to":"bde77ede_13c39995","updated":"2021-11-16 22:21:10.000000000","message":"\u003e Vadmin, Pavel, Mikhail, Tetiana - I took the liberty to add you as reviewers to this proposed spec since you did support a similar spec for the OpenStack Rocky release (https://review.opendev.org/c/openstack/nova-specs/+/547964/) and were talking about use cases in which user_data holds config data for e.g. a Juniper vSRX (NFV) or similar virtual appliances and having the capability to update the user_data was beneficial to having to go through a rebuild.\n\nThere seem to be multiple \"virtual appliances\" which can consume their config via user_data:\n\n * FortiGate https://docs.fortinet.com/document/fortigate-private-cloud/6.0.0/fortigate-vm-on-openstack/669322/creating-a-user-data-file-to-pre-configure-a-fortigate-vm-instance\n * Junipers vSRX","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"753d0a859c33a225f8f1459fc5a75582f6da0ab6","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"08a2b39a_3825f05f","in_reply_to":"da15edfc_f4f062ca","updated":"2021-11-22 12:33:31.000000000","message":"have you ever considerd filing a feature request for multiple ssh keys per instance. i think that would be a valid feature request.\n\nnova does not actully support domain level user today at all.\nwe only support project scoped tokens so all resouces that are created in nova are owned by a user or project and never a domian.\nbut we may add domain support as part of the ongoing rbac work.\n\nin the domain case i a am assuming the  domain user has an interitied member role on a porject? then then create vms in that project with an ssh key but that breaks? in what way? that might be an easy fix.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"04b86b0aa6f88fc38b23e9f5bac2774ae0d2fda2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6486990b_937daa41","updated":"2021-12-06 14:35:10.000000000","message":"I\u0027ve updated the spec to reflect the latest results of our discussion.","commit_id":"f24957435db2c0ad03f1455d32ea1d1f3cf84332"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d59f0eae91e4b0cfb457bd70b9421a7214e46459","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"8cfbd1f5_23fb9da8","updated":"2021-12-06 15:38:25.000000000","message":"some more nits inline but i think this is at least workable.","commit_id":"5b23f92c0e95eb37fed156614f9a3188784e81e4"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fbd72178fe49c6b4587f173960b9a85d9f2654e","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"d5e0e2fd_31dc4483","updated":"2021-12-14 10:40:20.000000000","message":"As I already said, I have concerns with the fact that userdata is mutable. If so, this would mean that when changing a value, we wouldn\u0027t longer know whether the related instance continues to use the orginal value or the new one. \n\nAlso, I\u0027m not convinced we *really* need to change this given there are already configuration tools that support the needed use cases. This doesn\u0027t really look as a nova scope : https://docs.openstack.org/nova/latest/contributor/project-scope.html#no-more-orchestration\n\n","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"08bce3fd30b17e369ba90e874601a3f7bfb7e598","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"6a895e56_cb488420","updated":"2022-01-11 21:31:58.000000000","message":"I actually don\u0027t hate this idea. When I read the title, I immediately thought of (IMHO) the similarity between server metadata and server userdata. Given that we allow multiple ways to mutate metadata, I\u0027m not sure that allowing replacement of userdata is such a stretch.\n\nI don\u0027t think you should change the spec based on my inline comments at this stage, given the reservations from other reviewers. I just wanted to add my high level thoughts about it.","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"e3ddd9357136593169a457b997deeaecaba37e87","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"1f3e60f4_a81cdc29","updated":"2022-01-11 16:41:01.000000000","message":"Is there any way to go forward with this?","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c2e36b1051ab61410ef5e8fa1d88719cc3db0dcd","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"d46dea9e_9f506098","updated":"2022-01-14 09:11:43.000000000","message":"Procedural -2: We hit spec freeze [1]. If you are still working on this the please re-propose it to Z release once we have the directory created (we miss the Z release naming).\nDetails of the process of accepting feature requests can be found on [2].\nIf any questions left about the process, feel free to ping bauzas on #openstack-nova or please attend any Nova meeting [3].\n\nThanks.\n\n[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026530.html\n[2] https://docs.openstack.org/nova/latest/contributor/process.html#spec-and-blueprint-approval-freeze\n[3] https://wiki.openstack.org/wiki/Meetings/Nova\n\n","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"079fc9959254e596788a49a41f3e24a3db40375a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"b67708f2_35528fc3","updated":"2021-12-15 08:13:28.000000000","message":"Sylvain,\n\nI tried as best as I can to reply to your comments inline.\nBut I believe some of the discussion was lost here between review and resulting revisions.\n\nMaybe, if you even tentatively could agree with the ideas behind this proposal, I gladly discuss more.\nWhile I understand you concerns about adding functionality that may confuse users or facilitates use cases which have may side effects.\n\nBut quite honestly it just extends on the existing ability to modify metadata items (usually consumed the same way user-data is). And metadata items very much are mutable (https://docs.openstack.org/api-ref/compute/?expanded\u003dcreate-or-update-metadata-items-detail#create-or-update-metadata-items). They are just a little less flexible / commonly used.\n\nThus the ideas to add a bit of (totally optional) flexibility to use the user-data.","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"079fc9959254e596788a49a41f3e24a3db40375a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"0544c834_11ed62de","in_reply_to":"d5e0e2fd_31dc4483","updated":"2021-12-15 08:13:28.000000000","message":"While I absolutely agree with the rule of not doing any orchestration, having user-data mutable during the lifecycle of an instance is merely \"orchestration\".\nIt\u0027s just dead data living in an API reach to be fetched an consumed. And the consumption of it is the actual orchestration. And certainly that\u0027s the job of cloud-init or all the other tools like cloudbase-init, ignition or a simple script interpreter running on the machine - so making use of that data.\n\nHaving it mutable just allows from some use-cases to benefit from user-data without actively adding any control loops or \"orchestration\".","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"70a1ec9774554d7eb64edbbcb4a5d7b673d16323","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"024e9959_e5091f30","updated":"2022-03-29 16:01:10.000000000","message":"With the switch to the next release, Zed, may I bump this one?\n\nMind you there is not only this spec, but then also a mostly done implementation via https://review.opendev.org/c/openstack/nova/+/816157.","commit_id":"384f187a8f971f85b0d6625eaf0db343473f3517"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"46e32d1660bbca03c19a58acc8e9a7c045b2a561","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"c33d6870_015c7d11","in_reply_to":"024e9959_e5091f30","updated":"2022-03-30 17:31:18.000000000","message":"You are welcome to repropose your spec or the Zed release, to do it you copy the .rst file to specs/zed/approved and then update the History section to add:\n\n   * - Zed\n       Reproposed\n\nThen review of the spec will continue there. If you will be at the PTG [1][2] next week, you might consider adding your spec as a discussion topic on the etherpad [3] for high bandwidth discussion. I suggest this because the review comments so far indicate a lack of consensus on this proposal.\n\n[1] https://ptg.opendev.org\n[2] https://ptg.opendev.org/ptg.html\n[3] https://etherpad.opendev.org/p/nova-zed-ptg","commit_id":"384f187a8f971f85b0d6625eaf0db343473f3517"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"621aa149aebf67bc80c402283c9724758df63777","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"93d57d6c_fc1a6f70","in_reply_to":"c33d6870_015c7d11","updated":"2022-03-30 17:36:58.000000000","message":"\u003e You are welcome to repropose your spec or the Zed release, to do it you copy the .rst file to specs/zed/approved and then update the History section to add:\n\u003e \n\u003e    * - Zed\n\u003e        Reproposed\n\nSorry, this contains a sphinx error, it should be:\n\n     * - Zed\n       - Reproposed","commit_id":"384f187a8f971f85b0d6625eaf0db343473f3517"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"dd09a1b923c446e7599f31297f83a6642ad422d8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"8d1b89b1_d570aad6","updated":"2022-04-06 06:41:26.000000000","message":"@Melwitt: The required changes are in (thx Jan). \nWhat would be the way forward for this spec to be accepted then?\n\nI placed it onto the PTG agenda - https://etherpad.opendev.org/p/nova-zed-ptg#L283 but am unsure on how and when to attend (if even required).\n\nHonestly I believe most of the refinements have already happened here in the review and also during one or two weekly meetings.","commit_id":"8c5cc528c81206b00e7ffca470fc259fe6e1f0c6"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f0021188690f5bb2d4317fdfbb883f6416a738c0","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"1aedeb3b_f4e88ac0","updated":"2022-05-10 12:52:33.000000000","message":"I think this is now in line with the agreement we had during the Zed PTG[1]\n\n[1] https://etherpad.opendev.org/p/nova-zed-ptg","commit_id":"8c5cc528c81206b00e7ffca470fc259fe6e1f0c6"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"29c0c8d98870c4470c1bbb4a51adee872aaa69ab","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"cf30a1d3_74cd73f9","updated":"2022-05-10 14:36:10.000000000","message":"based on our agreement at the ptg to proceed with this and also add the ablity to regenerate the config driver on hard reboot i think this is now good to go.","commit_id":"8c5cc528c81206b00e7ffca470fc259fe6e1f0c6"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"403431720a697402a847bf7f24fe220b08d061c0","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"756830e1_a85e2aeb","updated":"2022-05-10 12:49:35.000000000","message":"recheck to generate doc preview as the latest one expired","commit_id":"8c5cc528c81206b00e7ffca470fc259fe6e1f0c6"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"5533bf73e92eaa281330a6342d55396db1b9d7b3","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":7,"id":"aa738376_58b1dfc7","in_reply_to":"10da9500_f064473a","updated":"2022-04-29 06:20:09.000000000","message":"Since we discussed this at PTG, may I kindly ask again if this spec could receive a final review and be an accepted?\n\nWe could then discuss further on the actual implementation details in https://review.opendev.org/c/openstack/nova/+/816157.","commit_id":"8c5cc528c81206b00e7ffca470fc259fe6e1f0c6"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"8b2907ba4b26c32e06207563e078cbb0d272d042","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"10da9500_f064473a","in_reply_to":"8d1b89b1_d570aad6","updated":"2022-04-06 17:27:14.000000000","message":"I know we already discussed at the PTG today but just for completeness, I suggested a high bandwidth PTG discussion because as far as I could tell, the comments on this review were not trending toward spec approval. And I thought we might be able to resolve that aspect at the PTG. Cheers","commit_id":"8c5cc528c81206b00e7ffca470fc259fe6e1f0c6"}],"specs/yoga/approved/update-userdata.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b6ef496b3cfb752fca6f68e564ee0a870a71ef9","unresolved":true,"context_lines":[{"line_number":19,"context_line":"Currently, it is not possible to update an instance\u0027s user_data without"},{"line_number":20,"context_line":"rebuilding it."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Rebuilding takes much more time than just propagating updated user_data,"},{"line_number":23,"context_line":"e. g. via cloud-init, and may be unfavorable in production."},{"line_number":24,"context_line":"Editing a few lines in a cloud config file should not lead to a whole"},{"line_number":25,"context_line":"rebuild of an instance."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Additionally, other public cloud providers like Azure [1] have the"},{"line_number":28,"context_line":"functionality to update user_data for an existing instance, so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"be16090d_b2642ef1","line":25,"range":{"start_line":22,"start_character":0,"end_line":25,"end_character":23},"updated":"2021-11-03 19:08:50.000000000","message":"the default behavior fo cloud-init glean and ignition which are the most common guest agent that consume this is to run once on instance creattion and never run again.\n\nyes they can in some case by configured to run on each boot but that is not the default or expected behavior for these systems so im not sure how useful this change woudl be.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"17831e9ee679a5061c973e69fbca55b1416b1b1f","unresolved":true,"context_lines":[{"line_number":19,"context_line":"Currently, it is not possible to update an instance\u0027s user_data without"},{"line_number":20,"context_line":"rebuilding it."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Rebuilding takes much more time than just propagating updated user_data,"},{"line_number":23,"context_line":"e. g. via cloud-init, and may be unfavorable in production."},{"line_number":24,"context_line":"Editing a few lines in a cloud config file should not lead to a whole"},{"line_number":25,"context_line":"rebuild of an instance."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Additionally, other public cloud providers like Azure [1] have the"},{"line_number":28,"context_line":"functionality to update user_data for an existing instance, so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3e0715c5_05df9c08","line":25,"range":{"start_line":22,"start_character":0,"end_line":25,"end_character":23},"in_reply_to":"0385e8e2_b0dd6964","updated":"2021-11-16 22:21:10.000000000","message":"If cloud-init was the only consumer of such data I\u0027d fully agree.\n\nBut actually the user_data available via the metadata service is one thing and cloud-init making use of that data is another. As stated, other platforms / cloud providers do allow updates, and also even promote the capability to run a (changeable) script on every boot: https://aws.amazon.com/premiumsupport/knowledge-center/execute-user-data-ec2/","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"cf40fd2dfc45ba52b291fe7cd6a98780ba4f0246","unresolved":true,"context_lines":[{"line_number":19,"context_line":"Currently, it is not possible to update an instance\u0027s user_data without"},{"line_number":20,"context_line":"rebuilding it."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Rebuilding takes much more time than just propagating updated user_data,"},{"line_number":23,"context_line":"e. g. via cloud-init, and may be unfavorable in production."},{"line_number":24,"context_line":"Editing a few lines in a cloud config file should not lead to a whole"},{"line_number":25,"context_line":"rebuild of an instance."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Additionally, other public cloud providers like Azure [1] have the"},{"line_number":28,"context_line":"functionality to update user_data for an existing instance, so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0385e8e2_b0dd6964","line":25,"range":{"start_line":22,"start_character":0,"end_line":25,"end_character":23},"in_reply_to":"9111edde_71212301","updated":"2021-11-16 14:28:21.000000000","message":"We always designed user_data to be immutable as it caches a lot of image information besides the networking details. As you also mentioned, cloud-init exposes a cache to know whether it\u0027s a first boot or not, so we want it to be idempotent ideally.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"b49be2b3258e0ae7b3a91c86399587e7c7fe320a","unresolved":true,"context_lines":[{"line_number":19,"context_line":"Currently, it is not possible to update an instance\u0027s user_data without"},{"line_number":20,"context_line":"rebuilding it."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Rebuilding takes much more time than just propagating updated user_data,"},{"line_number":23,"context_line":"e. g. via cloud-init, and may be unfavorable in production."},{"line_number":24,"context_line":"Editing a few lines in a cloud config file should not lead to a whole"},{"line_number":25,"context_line":"rebuild of an instance."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Additionally, other public cloud providers like Azure [1] have the"},{"line_number":28,"context_line":"functionality to update user_data for an existing instance, so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9111edde_71212301","line":25,"range":{"start_line":22,"start_character":0,"end_line":25,"end_character":23},"in_reply_to":"be16090d_b2642ef1","updated":"2021-11-05 11:00:55.000000000","message":"As for Ignition the project itself fully agrees with you: https://coreos.github.io/ignition/rationale/#ignition-runs-only-on-the-first-boot\nBut there projects making use of Ignition which also clearly document the way to rerun it, e.g. Flatcar Linux: https://www.flatcar-linux.org/docs/latest/provisioning/ignition/boot-process/#reprovisioning\n\nCloud-Init clearly makes are distinction between first-boot and consequent boots https://cloudinit.readthedocs.io/en/latest/topics/boot.html#first-boot-determination documenting what can be done when.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b6ef496b3cfb752fca6f68e564ee0a870a71ef9","unresolved":true,"context_lines":[{"line_number":28,"context_line":"functionality to update user_data for an existing instance, so"},{"line_number":29,"context_line":"administrators and end users may expect this to work in Nova as well."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"AWS requires the instance to be powered off [2] before updating user_data"},{"line_number":32,"context_line":"and Google also allows updates at any time [3][4]."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"| [1] https://docs.microsoft.com/en-us/azure/virtual-machines/user-data#what-is-user-data"},{"line_number":35,"context_line":"| [2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html#user-data-view-change"}],"source_content_type":"text/x-rst","patch_set":1,"id":"93a29e5d_423e36dc","line":32,"range":{"start_line":31,"start_character":0,"end_line":32,"end_character":50},"updated":"2021-11-03 19:08:50.000000000","message":"if we are using config driver this would require us to also udpate the config drive or recreate it.\n\nwhile file injection has been deprecated and even removed in later microverions its still possible to use if you pin to an older micorverion.\n\nas a result if we were to niavly recreate the config drive it woudl cause the instance to loose data as all injected files would be lost.\n\nso we would have to reopen the orginial config drive and then update its content.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"aae8ec100af3d956612a3cba6a614d91c01a55d4","unresolved":false,"context_lines":[{"line_number":28,"context_line":"functionality to update user_data for an existing instance, so"},{"line_number":29,"context_line":"administrators and end users may expect this to work in Nova as well."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"AWS requires the instance to be powered off [2] before updating user_data"},{"line_number":32,"context_line":"and Google also allows updates at any time [3][4]."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"| [1] https://docs.microsoft.com/en-us/azure/virtual-machines/user-data#what-is-user-data"},{"line_number":35,"context_line":"| [2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html#user-data-view-change"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5e2a86d5_a2e7941c","line":32,"range":{"start_line":31,"start_character":0,"end_line":32,"end_character":50},"in_reply_to":"10cc650f_ed56b38d","updated":"2021-11-15 14:08:02.000000000","message":"File injection should not be of interest in this case when we only support updating data in the metadata service.\n\nEither way, file injection is deprecated and should not be required to be supported by this change.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"d7a169d2e7c4ef4097ed362bf8e2138f150c3410","unresolved":true,"context_lines":[{"line_number":28,"context_line":"functionality to update user_data for an existing instance, so"},{"line_number":29,"context_line":"administrators and end users may expect this to work in Nova as well."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"AWS requires the instance to be powered off [2] before updating user_data"},{"line_number":32,"context_line":"and Google also allows updates at any time [3][4]."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"| [1] https://docs.microsoft.com/en-us/azure/virtual-machines/user-data#what-is-user-data"},{"line_number":35,"context_line":"| [2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html#user-data-view-change"}],"source_content_type":"text/x-rst","patch_set":1,"id":"10cc650f_ed56b38d","line":32,"range":{"start_line":31,"start_character":0,"end_line":32,"end_character":50},"in_reply_to":"234ef6d9_9273758d","updated":"2021-11-08 12:03:16.000000000","message":"@Sean: when we use file injection don\u0027t we inject the file into the root disk instead of the config drive?","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"08e5d6d9da5c8163c4bd330ff6c8c1c60e14d93c","unresolved":false,"context_lines":[{"line_number":28,"context_line":"functionality to update user_data for an existing instance, so"},{"line_number":29,"context_line":"administrators and end users may expect this to work in Nova as well."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"AWS requires the instance to be powered off [2] before updating user_data"},{"line_number":32,"context_line":"and Google also allows updates at any time [3][4]."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"| [1] https://docs.microsoft.com/en-us/azure/virtual-machines/user-data#what-is-user-data"},{"line_number":35,"context_line":"| [2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html#user-data-view-change"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5e1f56c9_50a67139","line":32,"range":{"start_line":31,"start_character":0,"end_line":32,"end_character":50},"in_reply_to":"5e2a86d5_a2e7941c","updated":"2021-11-16 11:12:29.000000000","message":"gibi  i think it depends personaltiy file are injected into the root filesystem.\nuser_data is stored in the config drive.\ni tought we had another way to inject files that was also in the config drive \n\nbut it looks like https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.inject_password\nand https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.inject_key actully inject into the root disk so its only the user_data that is stored in the config_drive.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"b49be2b3258e0ae7b3a91c86399587e7c7fe320a","unresolved":true,"context_lines":[{"line_number":28,"context_line":"functionality to update user_data for an existing instance, so"},{"line_number":29,"context_line":"administrators and end users may expect this to work in Nova as well."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"AWS requires the instance to be powered off [2] before updating user_data"},{"line_number":32,"context_line":"and Google also allows updates at any time [3][4]."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"| [1] https://docs.microsoft.com/en-us/azure/virtual-machines/user-data#what-is-user-data"},{"line_number":35,"context_line":"| [2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html#user-data-view-change"}],"source_content_type":"text/x-rst","patch_set":1,"id":"234ef6d9_9273758d","line":32,"range":{"start_line":31,"start_character":0,"end_line":32,"end_character":50},"in_reply_to":"93a29e5d_423e36dc","updated":"2021-11-05 11:00:55.000000000","message":"\u003e if we are using config driver this would require us to also udpate the config drive or recreate it.\n\u003e \n\u003e while file injection has been deprecated and even removed in later microverions its still possible to use if you pin to an older micorverion.\n\u003e \n\u003e as a result if we were to niavly recreate the config drive it woudl cause the instance to loose data as all injected files would be lost.\n\u003e \n\u003e so we would have to reopen the orginial config drive and then update its content.\n\n\nCertainly a case to consider, but as I read it, this condition only arises if some one creates an instance with injected files via an old API microversion and then uses the to be implemented new microversion to dynamically update the user_data?\n\nI\u0027d rather check and reject the request to update user_data in this case (injected files being used) to ensure this case is handled, but would not implement the full workflow. It\u0027s a deprecated features as you said, why adding more baggage and  complexity to the current feature-set.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b6ef496b3cfb752fca6f68e564ee0a870a71ef9","unresolved":true,"context_lines":[{"line_number":39,"context_line":"Use Cases"},{"line_number":40,"context_line":"---------"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"As an administrator, I would like to be able to update an instance\u0027s"},{"line_number":43,"context_line":"user_data, so that I can add new users in the guest OS via user_data."},{"line_number":44,"context_line":"I also would like to update users\u0027 SSH keys and add new packages"},{"line_number":45,"context_line":"to be installed in the guest OS."},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"11a7f76c_25082bcc","line":43,"range":{"start_line":42,"start_character":0,"end_line":43,"end_character":69},"updated":"2021-11-03 19:08:50.000000000","message":"user data is generaly not intended to be use or maniuplated by admin at all.\n\nwe support external vendor data service to  allow oerators to modify the metadata avaiabel to things like cloud-init \n\nhttps://docs.openstack.org/nova/latest/admin/vendordata.html\n\nthe user data is owned by and reserved for the end user to use.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"b49be2b3258e0ae7b3a91c86399587e7c7fe320a","unresolved":false,"context_lines":[{"line_number":39,"context_line":"Use Cases"},{"line_number":40,"context_line":"---------"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"As an administrator, I would like to be able to update an instance\u0027s"},{"line_number":43,"context_line":"user_data, so that I can add new users in the guest OS via user_data."},{"line_number":44,"context_line":"I also would like to update users\u0027 SSH keys and add new packages"},{"line_number":45,"context_line":"to be installed in the guest OS."},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"e812d32c_8be740bd","line":43,"range":{"start_line":42,"start_character":0,"end_line":43,"end_character":69},"in_reply_to":"11a7f76c_25082bcc","updated":"2021-11-05 11:00:55.000000000","message":"Ack","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"cf40fd2dfc45ba52b291fe7cd6a98780ba4f0246","unresolved":false,"context_lines":[{"line_number":39,"context_line":"Use Cases"},{"line_number":40,"context_line":"---------"},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"As an administrator, I would like to be able to update an instance\u0027s"},{"line_number":43,"context_line":"user_data, so that I can add new users in the guest OS via user_data."},{"line_number":44,"context_line":"I also would like to update users\u0027 SSH keys and add new packages"},{"line_number":45,"context_line":"to be installed in the guest OS."},{"line_number":46,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacc64f0_fa605c96","line":43,"range":{"start_line":42,"start_character":0,"end_line":43,"end_character":69},"in_reply_to":"e812d32c_8be740bd","updated":"2021-11-16 14:28:21.000000000","message":"Sean is absolutely correct, this isn\u0027t a good use case for user data.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"cf40fd2dfc45ba52b291fe7cd6a98780ba4f0246","unresolved":true,"context_lines":[{"line_number":42,"context_line":"As an administrator, I would like to be able to update an instance\u0027s"},{"line_number":43,"context_line":"user_data, so that I can add new users in the guest OS via user_data."},{"line_number":44,"context_line":"I also would like to update users\u0027 SSH keys and add new packages"},{"line_number":45,"context_line":"to be installed in the guest OS."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"As an end user, I would like to be able to update my instance\u0027s"},{"line_number":48,"context_line":"user_data, so that I can add new users in the guest OS via user_data."}],"source_content_type":"text/x-rst","patch_set":1,"id":"6a91a23f_cd6c17c4","line":45,"updated":"2021-11-16 14:28:21.000000000","message":"There are other mechanisms that allow you to push SSH keys into your servers thanks to a cloud-init bootstrap that doesn\u0027t require you to update your user_data.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b6ef496b3cfb752fca6f68e564ee0a870a71ef9","unresolved":true,"context_lines":[{"line_number":44,"context_line":"I also would like to update users\u0027 SSH keys and add new packages"},{"line_number":45,"context_line":"to be installed in the guest OS."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"As an end user, I would like to be able to update my instance\u0027s"},{"line_number":48,"context_line":"user_data, so that I can add new users in the guest OS via user_data."},{"line_number":49,"context_line":"I also would like to update users\u0027 SSH keys and add new packages"},{"line_number":50,"context_line":"to be installed in the guest OS."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"Proposed change"},{"line_number":53,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ab2a5879_8ac94327","line":50,"range":{"start_line":47,"start_character":0,"end_line":50,"end_character":32},"updated":"2021-11-03 19:08:50.000000000","message":"this is a more resonable requst however it goes against the paridime that cloud-init exctra are intneded to supprot which is inital bootstraping of an instance. they are not ment to replace ansible or other orchestration systems that mange the software of an instnace.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"cf40fd2dfc45ba52b291fe7cd6a98780ba4f0246","unresolved":true,"context_lines":[{"line_number":44,"context_line":"I also would like to update users\u0027 SSH keys and add new packages"},{"line_number":45,"context_line":"to be installed in the guest OS."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"As an end user, I would like to be able to update my instance\u0027s"},{"line_number":48,"context_line":"user_data, so that I can add new users in the guest OS via user_data."},{"line_number":49,"context_line":"I also would like to update users\u0027 SSH keys and add new packages"},{"line_number":50,"context_line":"to be installed in the guest OS."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"Proposed change"},{"line_number":53,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9342caf4_38d9ba7b","line":50,"range":{"start_line":47,"start_character":0,"end_line":50,"end_character":32},"in_reply_to":"179c180a_e4074804","updated":"2021-11-16 14:28:21.000000000","message":"Again, I feel there are better alternatives that modifying user data with config management tools that don\u0027t require your user data to be modified.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"08e5d6d9da5c8163c4bd330ff6c8c1c60e14d93c","unresolved":true,"context_lines":[{"line_number":44,"context_line":"I also would like to update users\u0027 SSH keys and add new packages"},{"line_number":45,"context_line":"to be installed in the guest OS."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"As an end user, I would like to be able to update my instance\u0027s"},{"line_number":48,"context_line":"user_data, so that I can add new users in the guest OS via user_data."},{"line_number":49,"context_line":"I also would like to update users\u0027 SSH keys and add new packages"},{"line_number":50,"context_line":"to be installed in the guest OS."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"Proposed change"},{"line_number":53,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"179c180a_e4074804","line":50,"range":{"start_line":47,"start_character":0,"end_line":50,"end_character":32},"in_reply_to":"a974d495_a68fee48","updated":"2021-11-16 11:12:29.000000000","message":"well no the user_data is ment to be the first boot configuration.\nthe server metadata and tag is ment to be the long lived updatable data sorce for and isntace.\n\nhttps://docs.openstack.org/api-ref/compute/?expanded\u003d#list-all-metadata\n\nNTP should be advertised idealy via dhcp not the server user data\nbut something short like that is perfect for server metadata\n\nyou can simple store it as ntp_server_1 -\u003e time.google.com\nthis will be avaiable via curl to the instance at teh default metadta endpoint beside the user-data script. i.e. http://169.254.169.254\n\nyou can retive it form  curl http://169.254.169.254/openstack/latest/meta_data.json\nhttps://docs.openstack.org/nova/latest/user/metadata.html#openstack-format-metadata\n\nThe maximum size for each metadata key and value pair is 255 bytes which is sufficnt for ip and most urls\nso you can very eaislly store links to other location to retive more data if needed.\naddtionaly if this is info the cloud operator is provideign to instance it can be shared via dynamic vendor data https://docs.openstack.org/nova/latest/admin/vendordata.html#dynamicjson\n\nwhich will be available to cloud-init and other applications to use at curl http://169.254.169.254/openstack/2018-08-27/vendor_data2.json\n\nhttps://docs.openstack.org/nova/latest/user/metadata.html#vendordata\n\nif you update either the server metadata or the vendor data that chagne will be aviableable automatically immiedtly via the metadata api today.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"b49be2b3258e0ae7b3a91c86399587e7c7fe320a","unresolved":true,"context_lines":[{"line_number":44,"context_line":"I also would like to update users\u0027 SSH keys and add new packages"},{"line_number":45,"context_line":"to be installed in the guest OS."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"As an end user, I would like to be able to update my instance\u0027s"},{"line_number":48,"context_line":"user_data, so that I can add new users in the guest OS via user_data."},{"line_number":49,"context_line":"I also would like to update users\u0027 SSH keys and add new packages"},{"line_number":50,"context_line":"to be installed in the guest OS."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"Proposed change"},{"line_number":53,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a974d495_a68fee48","line":50,"range":{"start_line":47,"start_character":0,"end_line":50,"end_character":32},"in_reply_to":"ab2a5879_8ac94327","updated":"2021-11-05 11:00:55.000000000","message":"I fully agree that cloud-init or ignition do not replace a configuration management and were never intended to do so.\n\nThen there also are other consuming entities for user_data, such as Cloudbase-init for Windows machines (https://github.com/cloudbase/cloudbase-init). And those plugins very much run on each boot and can update things (https://cloudbase-init.readthedocs.io/en/latest/plugins.html). Thing of just injecting new NTP servers to your machines or similar. \n\nAnd last but not least one could simply store other data that is not consumed by any of the well known tools. Think of a virtual appliance and some config data maybe.\n\nQuintessentially the user_data should just be the store of data provided by the user and to be then retrievable by an instance via an HTTP call (or drive). If and how updates to this data through the life of an instance can be taken into account fully depends on the consumer of the data (Cloud-Init, Ignition, Cloudbase-init, custom code doing HTTP GET, ...)","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b6ef496b3cfb752fca6f68e564ee0a870a71ef9","unresolved":true,"context_lines":[{"line_number":59,"context_line":"user_data to the value set in the request parameter (if the input is valid,"},{"line_number":60,"context_line":"i. e. not longer than 65535 bytes)."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"The guest OS can then poll the updated data from the metadata service and"},{"line_number":63,"context_line":"propagate it via an utility like cloud-init."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Alternatives"},{"line_number":66,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1245f95a_54920bc3","line":63,"range":{"start_line":62,"start_character":0,"end_line":63,"end_character":44},"updated":"2021-11-03 19:08:50.000000000","message":"realistically this wont happen unless you initally altered how cloud-init works.\n\nunless the medtatdata include a when clause that uses boot as a tirgger to run on each boot its not goign to propagate to the guest\n\nhttps://cloudinit.readthedocs.io/en/latest/topics/boot.html#first-boot-determination\n\ncloud-init does not currenly suppor tMETADATA_CHANGE events to triger this based on dynmicaly chaing metadata so it will not poll as you suggest today.\n\nyou whoudl have to do a hard-reboot to have the update take effect and we woudl have to update the config driver as part of that hard reboot.\n\nthe openstack provider suppots\n\nsupported_update_events \u003d {EventScope.NETWORK: {\n        EventType.BOOT_NEW_INSTANCE,\n        EventType.BOOT,\n        EventType.BOOT_LEGACY,\n        EventType.HOTPLUG\n    }}\nhttps://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceOpenStack.py#L50-L53\nas does config drive\nhttps://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceConfigDrive.py#L39-L44\n\nwhich are the two we support in openstack but neither supprot onlie update out side of a pci hotpug event\n\nso we cant really have the change take effect without also doing a reboot or move operation after the instance user-data is updated.\n\ni dont think a hard-reboot would be an appriated side effect fo doing the user-data update implcitly either so these woudl have to be seperate actions.\n\n\nsoft-reboots likely wont work in the case of config drive eitehr since we will need to update the config drive file so this would  have to be a hard reboot at a minium.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"b49be2b3258e0ae7b3a91c86399587e7c7fe320a","unresolved":true,"context_lines":[{"line_number":59,"context_line":"user_data to the value set in the request parameter (if the input is valid,"},{"line_number":60,"context_line":"i. e. not longer than 65535 bytes)."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"The guest OS can then poll the updated data from the metadata service and"},{"line_number":63,"context_line":"propagate it via an utility like cloud-init."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Alternatives"},{"line_number":66,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2e871a89_f18bd085","line":63,"range":{"start_line":62,"start_character":0,"end_line":63,"end_character":44},"in_reply_to":"1245f95a_54920bc3","updated":"2021-11-05 11:00:55.000000000","message":"As stated above, propagating the change of user_data without a reboot is out of scope of simply allowing it to be updated. This would open a whole new set of challenges.\n\nWould it be sufficient to you to document the implications being either soft-reboot for user_data via metadata service and hard-reboot for the config drive?\nCertainly there are people using a config drive, but I suspect this is a lot less common than fetching user_data via the metadata service.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"08e5d6d9da5c8163c4bd330ff6c8c1c60e14d93c","unresolved":true,"context_lines":[{"line_number":59,"context_line":"user_data to the value set in the request parameter (if the input is valid,"},{"line_number":60,"context_line":"i. e. not longer than 65535 bytes)."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"The guest OS can then poll the updated data from the metadata service and"},{"line_number":63,"context_line":"propagate it via an utility like cloud-init."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Alternatives"},{"line_number":66,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9ad77c69_b5dff796","line":63,"range":{"start_line":62,"start_character":0,"end_line":63,"end_character":44},"in_reply_to":"2e871a89_f18bd085","updated":"2021-11-16 11:12:29.000000000","message":"actully we config_drive is much more commen then a lot of peopel might think. its often deployed in addtion to the metadta api so that if there is any contention or issue connecting to metadata it can fall \nback to the configdrive. we use it hevilly in our upstream ci for this reason since the ci runs workload in small vms so the performce is not great and the metadta service can sometimes be slow.","commit_id":"6a469c734e955ec01fe74822b4e26e57344bdf07"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d59f0eae91e4b0cfb457bd70b9421a7214e46459","unresolved":true,"context_lines":[{"line_number":60,"context_line":"i. e. not longer than 65535 bytes)."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"In case the instance uses a config drive, the above method should not be"},{"line_number":63,"context_line":"allowed and rejected with a clear response message. Instead, the user data"},{"line_number":64,"context_line":"can be updated via a hard reboot, i. e. via the"},{"line_number":65,"context_line":"``POST /servers/{server_id}/action`` API, with an additional parameter similar"},{"line_number":66,"context_line":"to the above method. The config drive will be rebuilt automatically on a hard"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5b1f4bec_d18e124f","line":63,"range":{"start_line":63,"start_character":21,"end_line":63,"end_character":51},"updated":"2021-12-06 15:38:25.000000000","message":"with a clear response message and 409 conflict error code.","commit_id":"5b23f92c0e95eb37fed156614f9a3188784e81e4"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"ae56a23b5b7c8db3020362733bd96edcd17c930b","unresolved":false,"context_lines":[{"line_number":60,"context_line":"i. e. not longer than 65535 bytes)."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"In case the instance uses a config drive, the above method should not be"},{"line_number":63,"context_line":"allowed and rejected with a clear response message. Instead, the user data"},{"line_number":64,"context_line":"can be updated via a hard reboot, i. e. via the"},{"line_number":65,"context_line":"``POST /servers/{server_id}/action`` API, with an additional parameter similar"},{"line_number":66,"context_line":"to the above method. The config drive will be rebuilt automatically on a hard"}],"source_content_type":"text/x-rst","patch_set":4,"id":"796d2f63_c347be2d","line":63,"range":{"start_line":63,"start_character":21,"end_line":63,"end_character":51},"in_reply_to":"5b1f4bec_d18e124f","updated":"2021-12-06 16:46:34.000000000","message":"Ack","commit_id":"5b23f92c0e95eb37fed156614f9a3188784e81e4"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d59f0eae91e4b0cfb457bd70b9421a7214e46459","unresolved":true,"context_lines":[{"line_number":120,"context_line":"Other end user impact"},{"line_number":121,"context_line":"---------------------"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"The option to update user data with python-novaclient is required:"},{"line_number":124,"context_line":"``nova update --userdata data {server_id}``"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"An option to update user data on a hard reboot should be added as well."}],"source_content_type":"text/x-rst","patch_set":4,"id":"69c58365_b4d67eee","line":123,"range":{"start_line":123,"start_character":36,"end_line":123,"end_character":53},"updated":"2021-12-06 15:38:25.000000000","message":"openstack client","commit_id":"5b23f92c0e95eb37fed156614f9a3188784e81e4"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"ae56a23b5b7c8db3020362733bd96edcd17c930b","unresolved":false,"context_lines":[{"line_number":120,"context_line":"Other end user impact"},{"line_number":121,"context_line":"---------------------"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"The option to update user data with python-novaclient is required:"},{"line_number":124,"context_line":"``nova update --userdata data {server_id}``"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"An option to update user data on a hard reboot should be added as well."}],"source_content_type":"text/x-rst","patch_set":4,"id":"a3c27273_d0d77e32","line":123,"range":{"start_line":123,"start_character":36,"end_line":123,"end_character":53},"in_reply_to":"69c58365_b4d67eee","updated":"2021-12-06 16:46:34.000000000","message":"Ack","commit_id":"5b23f92c0e95eb37fed156614f9a3188784e81e4"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d59f0eae91e4b0cfb457bd70b9421a7214e46459","unresolved":true,"context_lines":[{"line_number":121,"context_line":"---------------------"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"The option to update user data with python-novaclient is required:"},{"line_number":124,"context_line":"``nova update --userdata data {server_id}``"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"An option to update user data on a hard reboot should be added as well."},{"line_number":127,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"b25f9741_1e22063a","line":124,"range":{"start_line":124,"start_character":2,"end_line":124,"end_character":41},"updated":"2021-12-06 15:38:25.000000000","message":"openstack server set --user-data {data} {server_id}\n\n\nwe are no longer adding new cli options to nova client so all api change should now be enabled in the unifed openstack client instead.\nhttps://etherpad.opendev.org/p/r.e70aa851abf8644c29c8abe4bce32b81#L513","commit_id":"5b23f92c0e95eb37fed156614f9a3188784e81e4"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"ae56a23b5b7c8db3020362733bd96edcd17c930b","unresolved":false,"context_lines":[{"line_number":121,"context_line":"---------------------"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"The option to update user data with python-novaclient is required:"},{"line_number":124,"context_line":"``nova update --userdata data {server_id}``"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"An option to update user data on a hard reboot should be added as well."},{"line_number":127,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"2432fbec_b2c4f0ef","line":124,"range":{"start_line":124,"start_character":2,"end_line":124,"end_character":41},"in_reply_to":"b25f9741_1e22063a","updated":"2021-12-06 16:46:34.000000000","message":"Ack","commit_id":"5b23f92c0e95eb37fed156614f9a3188784e81e4"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d59f0eae91e4b0cfb457bd70b9421a7214e46459","unresolved":true,"context_lines":[{"line_number":138,"context_line":"Developer impact"},{"line_number":139,"context_line":"----------------"},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"The option to update user data should be added to other clients as well"},{"line_number":142,"context_line":"in order to implement full API functionality."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"Upgrade impact"},{"line_number":145,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"2c5987b6_6df238bd","line":142,"range":{"start_line":141,"start_character":0,"end_line":142,"end_character":45},"updated":"2021-12-06 15:38:25.000000000","message":"None\n\nwe dont need to update any other clients then osc or at least we dont need to mention them in the spec.\nwe are not accpeting new cli option in nova client as of the yoga release.\nand we do not manage or update any other clients via the sepc process so this can just be None.","commit_id":"5b23f92c0e95eb37fed156614f9a3188784e81e4"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"ae56a23b5b7c8db3020362733bd96edcd17c930b","unresolved":false,"context_lines":[{"line_number":138,"context_line":"Developer impact"},{"line_number":139,"context_line":"----------------"},{"line_number":140,"context_line":""},{"line_number":141,"context_line":"The option to update user data should be added to other clients as well"},{"line_number":142,"context_line":"in order to implement full API functionality."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"Upgrade impact"},{"line_number":145,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"6328ece2_8f163d29","line":142,"range":{"start_line":141,"start_character":0,"end_line":142,"end_character":45},"in_reply_to":"2c5987b6_6df238bd","updated":"2021-12-06 16:46:34.000000000","message":"Ack","commit_id":"5b23f92c0e95eb37fed156614f9a3188784e81e4"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d59f0eae91e4b0cfb457bd70b9421a7214e46459","unresolved":true,"context_lines":[{"line_number":186,"context_line":""},{"line_number":187,"context_line":"In addition, make clear that user data is mutable but also that it does not"},{"line_number":188,"context_line":"replace proper config management."},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"References"},{"line_number":191,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":192,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"88cb0bcf_0f3bb259","line":189,"updated":"2021-12-06 15:38:25.000000000","message":"+1","commit_id":"5b23f92c0e95eb37fed156614f9a3188784e81e4"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"ae56a23b5b7c8db3020362733bd96edcd17c930b","unresolved":false,"context_lines":[{"line_number":186,"context_line":""},{"line_number":187,"context_line":"In addition, make clear that user data is mutable but also that it does not"},{"line_number":188,"context_line":"replace proper config management."},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"References"},{"line_number":191,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":192,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"abf1d9f4_8b723905","line":189,"in_reply_to":"88cb0bcf_0f3bb259","updated":"2021-12-06 16:46:34.000000000","message":"Ack","commit_id":"5b23f92c0e95eb37fed156614f9a3188784e81e4"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fbd72178fe49c6b4587f173960b9a85d9f2654e","unresolved":true,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"As a user, I want to dynamically reconfigure the time and name servers used"},{"line_number":43,"context_line":"by my instance via user data in order to update theses settings using the"},{"line_number":44,"context_line":"same interface (user data) I initially used to bootstrap the instance."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"As a user with experience at provisioning ephemeral workloads with tools like"},{"line_number":47,"context_line":"cloud-init, I would like to manage my stateful workload via user data and"}],"source_content_type":"text/x-rst","patch_set":5,"id":"a8e9e8d1_13f22e54","line":44,"updated":"2021-12-14 10:40:20.000000000","message":"you can do this with some other configuration management tools than cloud-init, right?","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"079fc9959254e596788a49a41f3e24a3db40375a","unresolved":true,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"As a user, I want to dynamically reconfigure the time and name servers used"},{"line_number":43,"context_line":"by my instance via user data in order to update theses settings using the"},{"line_number":44,"context_line":"same interface (user data) I initially used to bootstrap the instance."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"As a user with experience at provisioning ephemeral workloads with tools like"},{"line_number":47,"context_line":"cloud-init, I would like to manage my stateful workload via user data and"}],"source_content_type":"text/x-rst","patch_set":5,"id":"0747c718_39f0bcaa","line":44,"in_reply_to":"a8e9e8d1_13f22e54","updated":"2021-12-15 08:13:28.000000000","message":"Yes. If I may point you to section 2) of my lengthy \"wall of text\" in my previous reply to this patchset. There I listed some use-cases, if I may quote:\n\n\u003e2) Use-cases which benefit from mutable user-data\n\u003e\n\u003eOne major part of the discussion was the lack of use-cases. We established that the  use-cases for mutable user-data certainly are more with\n\u003eclients other than cloud-init. As even though it does allow to be run on every boot, this scenario less common.\n\u003eBut other tools, clients and approaches on consuming user-data can benefit from it being mutable by the user during the life of an instance (not requiring a rebuild):\n\u003e\n\u003e    a) First there is cloudbase-init (https://github.com/cloudbase/cloudbase-init/), which is quite common for Windows machines running on OpenStack.\n\u003e        This is the use-case we hit after a customer raised a support case about being unable to update the userdata of an instance.\n\u003e        Cloudbase-Init documents their plugins being run on every boot, picking up changes in userdata.\n\u003e        While it\u0027s certainly possible to e.g. modify the timeservers manually or via config management after the instance has been brought up,\n\u003e        allowing for mutable user-data keeps all those settings and changes in a single place.\n\u003e        Provided there is no proper config management being used anyways and only settings taken from the initial user-data are changed.\n\u003e        See point #3 for more on the documentation of mutable user-data.\n\u003e\n\u003e    b) Cloud-Native / Ephemeral Operating systems\n\u003e        There are OS which are not managed in a traditional sense, with packages being installed via package management\n\u003e        and a config management tool being used to configure them. But rather an ephemeral image to which a single config \"file\" is applied.\n\u003e        Some examples are:\n\u003e\n\u003e        * TalosOS https://www.talos.dev/docs/v0.13/cloud-platforms/openstack/#compute-creation\n\u003e        * Rancher\n\u003e        ** K3OS: https://github.com/rancher/k3os#phases // https://github.com/rancher/k3os#etc\n\u003e        ** Rancher RKE: https://rancher.com/docs/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/#cluster-config-file\n\u003e\n\u003e        even though the instances of such OS could also be rebuild, a reboot with a changed configuration is usually much quicker.\n\u003e        And not all clouds have OpenStack Heat available to manage the migration of an instance pool from one config to the other.\n\u003e\n\u003e    c) Scripts to setup instance after boot\n\u003e        I understand that looking towards other (public) clouds does not make for a use case for mutable userdata in itself.\n\u003e        But taken from the prominently documented ability to update userdata and to place scripts there to run certain basic steps\n\u003e        on every boot - this is an actively applied design practice in cloud environments:\n\u003e        * https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-user-data.html#user-data-execution\n\u003e        * https://docs.microsoft.com/en-us/azure/virtual-machines/user-data#what-is-user-data\n\u003e        * ...\n\u003e\n\u003e        being able to edit this script is all that mutable user-data would provide.\n\u003e        This approach is not about managing packages or modifying config files, which is the job of a config management -\n\u003e        no objections to what your said Sean.\n\u003e        But rather to allow for less modifications of the instance and rather use a script to apply startup parameters or e.g.\n\u003e        join commands for some clustered software. And those instructions might change.\n\u003e\n\u003e            This is somewhat similar to (b), having an image containing all the packages and userdata just being the \"configuration\" source.\n\u003e        Similar to a container receiving environment variables or a config file, but being immutable otherwise.\n\u003e\n\u003e    d) NFV or other virtual appliances which consume their \"config\" via userdata.\n\u003e        Apparently Vadim Ponomarev had some particular examples.\n\u003e\n\nSean did respond with some suggestions to phrase a particular use-case (like the time servers example) which was then simply used for the following revision of the spec. Certainly more verbosity on use-cases could be applied to the spec - as you can read I have a hard time keeping myself from creating long paragraphs :-)","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fbd72178fe49c6b4587f173960b9a85d9f2654e","unresolved":true,"context_lines":[{"line_number":47,"context_line":"cloud-init, I would like to manage my stateful workload via user data and"},{"line_number":48,"context_line":"metadata on each boot. Metadata is used to store my external configuration"},{"line_number":49,"context_line":"while user data is used to perform operations like rejoining a cluster when the"},{"line_number":50,"context_line":"update has been applied."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"Proposed change"},{"line_number":53,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"820438ea_a22b91dd","line":50,"updated":"2021-12-14 10:40:20.000000000","message":"That would mean that we need to reboot the instance to get the updates, right ?\n\nIf so, how an user could know whether the userdata values are related to the existing instance or not ?","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"079fc9959254e596788a49a41f3e24a3db40375a","unresolved":true,"context_lines":[{"line_number":47,"context_line":"cloud-init, I would like to manage my stateful workload via user data and"},{"line_number":48,"context_line":"metadata on each boot. Metadata is used to store my external configuration"},{"line_number":49,"context_line":"while user data is used to perform operations like rejoining a cluster when the"},{"line_number":50,"context_line":"update has been applied."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"Proposed change"},{"line_number":53,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ec5bdfc3_58d5399d","line":50,"in_reply_to":"820438ea_a22b91dd","updated":"2021-12-15 08:13:28.000000000","message":"Yes and no. The data is simply provided by the API / metadata service and any change would be  available immediately after mutation. But, as you said, there rightfully is no orchestration in Nova. That\u0027s the job of whatever the user uses for his workflow to change the user data in the first place. IaC tools like terraform or pulumi or even a script using the openstack-client could trigger the reboot after a change.","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"08bce3fd30b17e369ba90e874601a3f7bfb7e598","unresolved":true,"context_lines":[{"line_number":53,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"The existing ``PUT /servers/{server_id}`` API should accept an additional"},{"line_number":56,"context_line":"parameter named ``user_data`` to allow updates to the instance\u0027s user data."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"If the parameter is set in the request body, Nova should update the instance\u0027s"},{"line_number":59,"context_line":"user data to the value set in the request parameter (if the input is valid,"}],"source_content_type":"text/x-rst","patch_set":5,"id":"98d42541_818cdf03","line":56,"updated":"2022-01-11 21:31:58.000000000","message":"Looking at the existing api-ref, I tend to think this should rather follow the format of the server metadata replacement [1] API, for example:\n\n PUT /servers/{server_id}/userdata\n\n[1] https://docs.openstack.org/api-ref/compute/?expanded\u003d#replace-metadata-items","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fbd72178fe49c6b4587f173960b9a85d9f2654e","unresolved":true,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"If the parameter is set in the request body, Nova should update the instance\u0027s"},{"line_number":59,"context_line":"user data to the value set in the request parameter (if the input is valid,"},{"line_number":60,"context_line":"i. e. not longer than 65535 bytes)."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"In case the instance uses a config drive, the above method should not be"},{"line_number":63,"context_line":"allowed and rejected with a clear response message and 409 (conflict) status"}],"source_content_type":"text/x-rst","patch_set":5,"id":"e195c5df_2b73a8de","line":60,"updated":"2021-12-14 10:40:20.000000000","message":"OK, but this would mean that the already created instance wouldn\u0027t use the values that are updated, until someone asks to reboot the instance, right?","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"079fc9959254e596788a49a41f3e24a3db40375a","unresolved":true,"context_lines":[{"line_number":57,"context_line":""},{"line_number":58,"context_line":"If the parameter is set in the request body, Nova should update the instance\u0027s"},{"line_number":59,"context_line":"user data to the value set in the request parameter (if the input is valid,"},{"line_number":60,"context_line":"i. e. not longer than 65535 bytes)."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"In case the instance uses a config drive, the above method should not be"},{"line_number":63,"context_line":"allowed and rejected with a clear response message and 409 (conflict) status"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bd889607_3c27deaf","line":60,"in_reply_to":"e195c5df_2b73a8de","updated":"2021-12-15 08:13:28.000000000","message":"Yes - depending on the consuming client software only running on reboot. As I said the mutated data would be available immediately.\n\nIf you accept my brave comparison - it\u0027s a little like the Kubernetes ConfigMaps. They are just resources holding arbitrary data. Updating a config map will, in case it\u0027s mounted as a volume and not exposed as environment variables, update immediately to the Pod (https://kubernetes.io/docs/concepts/configuration/configmap/#mounted-configmaps-are-updated-automatically). \n\nBut actually reacting to the change is the job of the workload there as the ConfigMaps (or Secrets for that matter) are literally just some (mutable) piece of data being provided.","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fbd72178fe49c6b4587f173960b9a85d9f2654e","unresolved":true,"context_lines":[{"line_number":64,"context_line":"code. Instead, the user data can be updated via a hard reboot, i. e. via the"},{"line_number":65,"context_line":"``POST /servers/{server_id}/action`` API, with an additional parameter similar"},{"line_number":66,"context_line":"to the above method. The config drive will be rebuilt automatically on a hard"},{"line_number":67,"context_line":"reboot, containing the updated user data."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Alternatives"},{"line_number":70,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"2432800b_35b5245c","line":67,"updated":"2021-12-14 10:40:20.000000000","message":"see, here you need to reboot.","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"08bce3fd30b17e369ba90e874601a3f7bfb7e598","unresolved":true,"context_lines":[{"line_number":64,"context_line":"code. Instead, the user data can be updated via a hard reboot, i. e. via the"},{"line_number":65,"context_line":"``POST /servers/{server_id}/action`` API, with an additional parameter similar"},{"line_number":66,"context_line":"to the above method. The config drive will be rebuilt automatically on a hard"},{"line_number":67,"context_line":"reboot, containing the updated user data."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Alternatives"},{"line_number":70,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"70182db4_24d94e6c","line":67,"in_reply_to":"22fbe182_61fed55d","updated":"2022-01-11 21:31:58.000000000","message":"Maybe it\u0027s just me but I would have thought option a) would be the most consistent and intuitive way to handle config drive. That is, the user can update nova\u0027s storage of the server\u0027s userdata via \u0027PUT /servers/{server_id}/userdata\u0027 whether it\u0027s using config drive or not, and if it uses config drive, the user has to hard reboot it to effect the update in the guest.\n\nI say the above having had past experience using nova guests as my dev boxes in and injecting ssh keys and so on through userdata + cloud-init + config drive. And if I had had the ability to change the userdata with a PUT API, I would have expected the guest would need a reboot of some kind to consume the new userdata. It feels intuitive, at least to me.","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"079fc9959254e596788a49a41f3e24a3db40375a","unresolved":true,"context_lines":[{"line_number":64,"context_line":"code. Instead, the user data can be updated via a hard reboot, i. e. via the"},{"line_number":65,"context_line":"``POST /servers/{server_id}/action`` API, with an additional parameter similar"},{"line_number":66,"context_line":"to the above method. The config drive will be rebuilt automatically on a hard"},{"line_number":67,"context_line":"reboot, containing the updated user data."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Alternatives"},{"line_number":70,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"22fbe182_61fed55d","line":67,"in_reply_to":"2432800b_35b5245c","updated":"2021-12-15 08:13:28.000000000","message":"If I may refer my lengthy post again - this was just one option to deal with a config drive.\n\n\u003e2) Compatibility with config drive\n\u003e\n\u003e    Sean you said \"jhartkopf: we could proably make it mutable if there is a use facing usecase but we would need to support config dirve and note that the change may not fully be ableable untill after a hard reboot\".\n\u003e    As for the config drive there are multiple ways dealing with mutable userdata\n\u003e    if a config drive is used:\n\u003e        a) Allow it and document clearly that the content of the drive will only be visible to the instance after a reboot.\n\u003e        b) Reject it always and respond to the API call with a clear message indicating that userdata cannot be updated if a config drive is used.\n\u003e        c) Reject it for running instances with an equally clear message instructing the user to shut the instance down prior to the change of userdata.\n\u003e\n\u003e        Reading your statement again, Sean, I believe you like (a) the most?\n\n\nSean like rejecting the change and guiding the user trough a hard reboot the most here to that was written as \"the solution\" to the spec.\n\n\nI could totally agree to any of the solutions. The Config drive is, excuse my comparison to Kubernetes gain, like having a ConfigMap as environment variables which require a Pod deletion to be applied.","commit_id":"3adab045989e2e5714ca5951cff15948c64c43c3"}]}