| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-14 | |||
| 13:25:52 | bauzas | prelude has to be merged before RC1 | |
| 13:26:07 | sean-k-mooney | yes and after RC1 master is A | |
| 13:26:10 | opendevreview | Merged openstack/nova master: Test setting the nova job to centos-9-stream https://review.opendev.org/c/openstack/nova/+/831844 | |
| 13:26:12 | bauzas | correct | |
| 13:26:18 | sean-k-mooney | so we would have to backport it to stable | |
| 13:26:25 | sean-k-mooney | i would like to avoid that backport | |
| 13:26:30 | bauzas | correct, we did it once and we had hard times with ops | |
| 13:26:35 | sean-k-mooney | by merging it at RC1 | |
| 13:26:40 | bauzas | we merged prelude after RC1 | |
| 13:26:43 | sean-k-mooney | and using it as the base of the rc tag | |
| 13:26:48 | bauzas | in Newton IIRC | |
| 13:26:58 | bauzas | that's the usual thing we do | |
| 13:27:10 | bauzas | but prelude can be merged a bit earler | |
| 13:27:34 | sean-k-mooney | yep that fin i would just like to also incldue the other patch in rc1 | |
| 13:27:46 | sean-k-mooney | the zed version of https://review.opendev.org/c/openstack/nova/+/833243 | |
| 13:27:59 | sean-k-mooney | so we can proceed with the prelude patch as is | |
| 13:28:18 | bauzas | yup, was in Newton https://docs.openstack.org/releasenotes/nova/newton.html#release-notes-14-0-1-stable-newton | |
| 13:28:19 | sean-k-mooney | but i was trying to avoid another review cycle for the trivail rel note change | |
| 13:28:47 | bauzas | as a consequence, we were only able to provide the prelude section once we released a stable release | |
| 13:29:00 | bauzas | operators were angry about it | |
| 13:29:15 | sean-k-mooney | sure but your not listenting to what im saying | |
| 13:29:32 | sean-k-mooney | im not talking about not providing the prelude in rc1 | |
| 13:29:35 | sean-k-mooney | we should | |
| 13:29:50 | bauzas | ah, the zed file creation | |
| 13:29:54 | sean-k-mooney | im saying please add zed to the index in rc1 | |
| 13:29:58 | sean-k-mooney | yes | |
| 13:29:59 | bauzas | no, again, we can't | |
| 13:30:04 | bauzas | this isn't logical | |
| 13:30:09 | sean-k-mooney | why yes it is | |
| 13:30:13 | bauzas | we haven't released officially Zed yet | |
| 13:30:24 | sean-k-mooney | right but its the release candiate | |
| 13:30:27 | bauzas | hence the "unreleased" | |
| 13:30:30 | bauzas | correct | |
| 13:30:33 | bauzas | but a candidate | |
| 13:30:36 | bauzas | not a release | |
| 13:30:37 | sean-k-mooney | and ideally there shoudl be no change in that and the final release | |
| 13:30:43 | bauzas | there could be | |
| 13:30:53 | bauzas | some regression bugfix adding notes | |
| 13:30:59 | sean-k-mooney | right but in the case that there is no change required we should use the same sha | |
| 13:31:15 | sean-k-mooney | meaning the candiate should have the same content as the final releas package | |
| 13:31:26 | bauzas | as you see, this is an automated bot https://review.opendev.org/c/openstack/nova/+/833243 | |
| 13:31:40 | bauzas | and the release team is doing this for all the managed projects | |
| 13:31:50 | sean-k-mooney | ok fine lest keep the extra paperwork for now | |
| 13:32:15 | sean-k-mooney | but this is pointless extra work that we shoudl try and avoid going forward | |
| 13:32:33 | sean-k-mooney | we can maybe chat to the release team about this going forward | |
| 13:32:59 | sean-k-mooney | its forceing that RC1 can never be the release package | |
| 13:33:28 | sean-k-mooney | by doing it this way we always have to do a release of a diffenrt sha for the offical release | |
| 13:36:23 | sean-k-mooney | bauzas: can you hit https://review.opendev.org/c/openstack/os-vif/+/856782 | |
| 13:36:56 | sean-k-mooney | bauzas: and the folloing patch if you can too | |
| 13:37:48 | bauzas | done | |
| 13:38:08 | bauzas | was in the list of https://etherpad.opendev.org/p/nova-zed-rc-potential | |
| 13:40:50 | sean-k-mooney | ack just saw the request form elodilles in my inbox hence the poke to actully land does | |
| 13:40:56 | sean-k-mooney | *those | |
| 13:46:48 | opendevreview | Merged openstack/os-vif master: Update master for stable/zed https://review.opendev.org/c/openstack/os-vif/+/856782 | |
| 13:50:07 | Uggla | question about my_block_storage_ip. This flag can be available on each compute nodes or the default is the compute ip. Am I right ? | |
| 13:50:37 | sean-k-mooney | yes | |
| 13:51:49 | Uggla | is there a way to get this parameter from the api or it can be only provided by the compute node itself ? | |
| 13:52:00 | sean-k-mooney | only on the compute | |
| 13:52:15 | sean-k-mooney | that is why you need to do the grant on the compute not the api | |
| 13:52:21 | sean-k-mooney | or conductor | |
| 13:52:49 | sean-k-mooney | it has to be done in the compute agent | |
| 13:53:28 | Uggla | so it needs a new "entry" in the compute API for this. Correct ? | |
| 13:54:19 | sean-k-mooney | for share attament yes you need that anyway | |
| 13:55:02 | sean-k-mooney | this is an internal detail or the attach_share rpc call | |
| 13:56:05 | Uggla | so far there is no rpc call for attach. As everything could be done in the API. | |
| 13:56:34 | sean-k-mooney | that would never work | |
| 13:56:49 | sean-k-mooney | we need a call to the compute to actully do the mounting of the share ectra | |
| 13:57:14 | sean-k-mooney | were you jsut goign to put that into spawn or something? | |
| 13:57:32 | Uggla | attach is just an entry within the db. And mount + real work is done at power_on | |
| 13:57:35 | sean-k-mooney | i have not look at this in a while so i dont remember the details | |
| 13:58:03 | sean-k-mooney | i guess that work today only because we require the vm to be off/shelved | |
| 13:58:23 | sean-k-mooney | but the rpc would be required if we supprot live attach in the future | |
| 13:58:24 | Uggla | yes off | |
| 13:58:45 | sean-k-mooney | ya so unless yo defer the grant to the power on stage | |
| 13:58:56 | sean-k-mooney | your going to need an attach_share rpc call | |
| 13:59:09 | sean-k-mooney | however hard reboot should not really call any external services | |
| 13:59:26 | sean-k-mooney | like it should not udpate cinder attachment or neutron prot bindings | |
| 13:59:38 | sean-k-mooney | so i woudl find it odd for it to update manila grants | |
| 14:00:07 | Uggla | ok I can implement that in rpc. Can I just make a sync call to rpc get the result and do the rest in the API ? | |
| 14:00:19 | Uggla | result = get the ip | |
| 14:00:45 | Uggla | or is it better to call the rpc and do the required work in the rpc ? | |
| 14:04:30 | gibi | bauzas: I left feedback on the prelude | |
| 14:04:43 | bauzas | ack, looing | |
| 14:06:26 | stephenfin | sean-k-mooney: the release note will be moved to zed when the tag is created | |
| 14:06:43 | stephenfin | (sorry, my VPN disconnected and I never noticed) | |
| 14:07:03 | stephenfin | (my ZNC deployment is now behind VPN) | |
| 14:09:24 | sean-k-mooney | no worries | |
| 14:10:45 | opendevreview | Sylvain Bauza proposed openstack/nova master: Prelude section for Zed release https://review.opendev.org/c/openstack/nova/+/857467 | |
| 14:10:50 | bauzas | gibi: sean-k-mooney: updated ^ | |
| 14:11:04 | bauzas | stephenfin: well, not automatically | |
| 14:11:23 | stephenfin | wdym? | |
| 14:11:24 | bauzas | stephenfin: we need to tell reno to look at the new stable/zed branch | |
| 14:11:25 | gibi | bauzas: that was fast :) | |
| 14:12:06 | bauzas | stephenfin: I mean, by for example https://review.opendev.org/c/openstack/nova/+/833243 | |
| 14:12:30 | stephenfin | bauzas: oh yeah, but the bot will do that | |
| 14:12:31 | bauzas | stephenfin: if we don't merge this file, then none of the files look at the new stable branch | |
| 14:12:41 | sean-k-mooney | bauzas: that also has the pbr tag in the commit | |
| 14:12:41 | stephenfin | you're right though | |
| 14:12:50 | bauzas | so we need to merge it quickly after the new branch | |
| 14:13:18 | stephenfin | it'll appear under the 26.0.0 tag but the zed page won't exist until created | |