)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"422fbea95765e4c5c7248252b33eafbba49dd6af","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8babe02c_91b343ce","updated":"2023-03-09 13:54:30.000000000","message":"Also, you should not skip xena and yoga.","commit_id":"9ac01acdbac1df8342c90ecc8ce6645e0d2ba93a"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"e9c606f259d0fb987368a92e22a56e5874e74506","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"be28f621_3622e9cd","updated":"2023-03-09 13:53:59.000000000","message":"If we avoid deprecating the parameter in wallaby then please do that in zed. I don\u0027t understand why we need that change wallaby only.","commit_id":"9ac01acdbac1df8342c90ecc8ce6645e0d2ba93a"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"c0e011044b41cd9ea96a9f8bcd1a825e750a3c2f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"cddc6c24_992de5b0","updated":"2023-03-10 12:36:42.000000000","message":"Yoga 1st","commit_id":"9ac01acdbac1df8342c90ecc8ce6645e0d2ba93a"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"72d542d414298d14422820dfc292bcdc5c970762","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"dab7ca03_0b0910cf","updated":"2023-03-09 13:47:46.000000000","message":"Zed 1st","commit_id":"9ac01acdbac1df8342c90ecc8ce6645e0d2ba93a"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"c0e011044b41cd9ea96a9f8bcd1a825e750a3c2f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"79874c09_95b14235","in_reply_to":"3040c1bf_6e2ba35c","updated":"2023-03-10 12:36:42.000000000","message":"as you\u0027ve aligned it with Zed backport, please reconsider your review","commit_id":"9ac01acdbac1df8342c90ecc8ce6645e0d2ba93a"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"ce15052e222162629c67981ba16c7640da3a0226","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f2f8ada2_c27458f8","in_reply_to":"79874c09_95b14235","updated":"2023-03-10 12:47:59.000000000","message":"the latest zed backport has some differences from this one(eg .release note) so we should again cherry-pick this .Also again this should be backported from xena, instead of zed so my -1 still stays.","commit_id":"9ac01acdbac1df8342c90ecc8ce6645e0d2ba93a"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"55cb9e9c4cd4b0f1844a344028ef36ce039852d6","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"3040c1bf_6e2ba35c","in_reply_to":"8babe02c_91b343ce","updated":"2023-03-09 15:52:18.000000000","message":"good points!","commit_id":"9ac01acdbac1df8342c90ecc8ce6645e0d2ba93a"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"ca5c889620ee95fc52c9b78b30e683be6064d75c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"daa3371a_1f6e423e","updated":"2023-03-16 10:53:18.000000000","message":"I\u0027m fine with abandoning these backports. The feature has been incomplete for long until I fixed it quite recently. Less backports always makes our life easier.\n\nHowever I want to make the reason we block this backport clear and accurate, mainly because we have already merged stable/zed backport.","commit_id":"3c2a982c3966a566fe9e86784d6cff01dce2a0e4"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b16d0d8bf881136995c19c703e1702f15fcf6a5e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ece0709d_10641f19","updated":"2023-03-15 17:13:15.000000000","message":"Sorry, I have to -1 this change for upgrade reasons. Let me explain it further in details :\n\nExisting users may have changed this config option on the nova-api service only (as the existing puppet-nova module was doing). Unfortunately, given this instance name isn\u0027t persisted in our DB as of now, every single service (including nova-compute) just tries to lookup instance.name by applying the config option template that\u0027s defined locally. As a result, some existing clouds could run instances with different internal names used by libvirt without the user would notice it (since it would show the expected instance.name on the API).\n\nChanging this value would then be errorprone : a hardreboot would regenerate a new guest name which would differ from the previous, leading to broken migrations in a subsequent future. We even document how fragile it is to change the instance name template when you have running instances : https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.instance_name_template\n\n If you already have instances in your deployment when you change this, your deployment will break.\n\nAccordingly, I would suggest to *not* backport such change, please.\n","commit_id":"3c2a982c3966a566fe9e86784d6cff01dce2a0e4"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"574ed008aa50c0e345a761f5ba755e44d93a518f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"de704c4a_35d8d84c","updated":"2023-03-14 12:53:50.000000000","message":"Xena 1st","commit_id":"3c2a982c3966a566fe9e86784d6cff01dce2a0e4"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"7a66b80c9fd4ae147ea818348f2b69c4185a74e1","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6d3e2ecd_1125f8bd","in_reply_to":"406240b3_053f2f8a","updated":"2023-03-16 10:08:39.000000000","message":"The problem is if the operator changed the value from the API service before. If so, that would mean that the libvirt guest would have a name still using the default value (ie. instance_{id}).\n\nSo, if we backport this change, that would then mean that if the operator upgrades its services and then modifies the value, then it would change the libvirt guest name while the operator shouldn\u0027t be not knowing it.","commit_id":"3c2a982c3966a566fe9e86784d6cff01dce2a0e4"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"ca5c889620ee95fc52c9b78b30e683be6064d75c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"bf8d5e16_eac61222","in_reply_to":"6d3e2ecd_1125f8bd","updated":"2023-03-16 10:53:18.000000000","message":"I think there are two separate things.\n\n1. The existing implementation with nova::api::instance_name_template is incomplete and did not work. Without this change user\u0027s can\u0027t configure the parameter properly\n\n2. However the new \"correct\" parameter should be used only in a fresh deployment and in case the deployment was using the old parameter then the parameter should be just removed instead of being migrated to the new \"correct\" one.\n\n1 is technically worth fixing, but we should be careful to make users aware of 2. Probably we should put some notes about 2 (Do not use the new parameter in existing deployment) and not encourage people to use the new value.","commit_id":"3c2a982c3966a566fe9e86784d6cff01dce2a0e4"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"b1ede7b5c3957dfc3471145bdd84f83334073fa9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"b39cf8b3_f87d038e","in_reply_to":"bf8d5e16_eac61222","updated":"2023-03-17 13:49:20.000000000","message":"So, if user adds instance_name_template into nova.conf on compute nodes which didn\u0027t have it earlier, there could become problems with libvirt guests changing names? Which may result in \" a hardreboot would regenerate a new guest name which would differ from the previous, leading to broken migrations in a subsequent future\"?\n\nIf so, we should not warn users about using this paramter in existing deployments via Puppet, but in Nova instead - exectly there the breakage has been introduced","commit_id":"3c2a982c3966a566fe9e86784d6cff01dce2a0e4"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"ba5d7361747044c5de1133693f088ad055e6f2b0","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"406240b3_053f2f8a","in_reply_to":"ece0709d_10641f19","updated":"2023-03-16 02:35:53.000000000","message":"This change introduces a separate parameter(nova::instance_name_template) which works better than the existing one(nova::api::instance_name_template) (actually, it works \"correctly\"). \n\nI does not change the behavior unless the user explicitly users that parameter so should have no impact during upgrade/update.","commit_id":"3c2a982c3966a566fe9e86784d6cff01dce2a0e4"}]}