| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-14 | |||
| 13:16:04 | sean-k-mooney | and +2 to comunciate to the core team that i think its imporant for them to look at too | |
| 13:16:18 | opendevreview | Sylvain Bauza proposed openstack/nova master: Prelude section for Zed release https://review.opendev.org/c/openstack/nova/+/857467 | |
| 13:16:26 | sean-k-mooney | im not commiting them to but usign it to signal asyc that i think its more important for wider review | |
| 13:16:27 | bauzas | sean-k-mooney ack, then let's discuss this at the PTG | |
| 13:16:38 | bauzas | sean-k-mooney: gibi: updated prelude ^ | |
| 13:16:38 | sean-k-mooney | cool | |
| 13:16:51 | sean-k-mooney | im trying to decople priorty from quality | |
| 13:17:15 | sean-k-mooney | i.e. rp +2 my be with a buch of -1 but may have topic that need wider input | |
| 13:19:54 | sean-k-mooney | bauzas: when will that move to zed https://6bc7844fa7b995ed5b77-cdf523d3b16150ab0b9ddc512a79d512.ssl.cf2.rackcdn.com/857467/1/check/build-openstack-releasenotes/b8db3f7/docs/unreleased.html should that also be in the patch or is it when we cut the stable branch | |
| 13:20:21 | bauzas | sean-k-mooney: ah | |
| 13:20:24 | sean-k-mooney | stephenfin: ^ pbr has some magic based on commit messages right it it tied into that or do we need to do somethign esle | |
| 13:20:30 | bauzas | you mean when it will be told "zed" | |
| 13:20:37 | sean-k-mooney | yep | |
| 13:20:46 | bauzas | sean-k-mooney: that's because reno works with git branches | |
| 13:20:49 | sean-k-mooney | this shoudl be rended under zed in rc1 right | |
| 13:20:55 | bauzas | for the moment, we haven't released zed | |
| 13:21:03 | bauzas | even with rc1 | |
| 13:21:12 | sean-k-mooney | so on stable zed this will render under zed automatically | |
| 13:21:20 | sean-k-mooney | have you checked that locally? | |
| 13:21:21 | bauzas | yup, because it branches | |
| 13:21:40 | bauzas | no, this is just the releases team which creates the correct new pages | |
| 13:21:57 | bauzas | https://6bc7844fa7b995ed5b77-cdf523d3b16150ab0b9ddc512a79d512.ssl.cf2.rackcdn.com/857467/1/check/build-openstack-releasenotes/b8db3f7/docs/unreleased.html#relnotes-25-0-0-195 will be seen |
|
| 13:23:31 | sean-k-mooney | ok +2 then i captured that in the review message | |
| 13:23:42 | bauzas | sean-k-mooney: example of a release patch creating the yoga page https://github.com/openstack/nova/commit/d2cba990a6205e5b0361e750c173850cf209a9e6 | |
| 13:24:22 | sean-k-mooney | right i tought we needed one like that i woudl prefer to do that before rc1 | |
| 13:24:36 | sean-k-mooney | we can do it after but i find that messier | |
| 13:24:39 | bauzas | https://review.opendev.org/c/openstack/nova/+/833243 was the patch | |
| 13:25:30 | sean-k-mooney | yep so why are we not doing that in the prelude patch or at least proposing it now | |
| 13:25:32 | bauzas | as you see in the "included in", this was merged *after* yoga GA | |
| 13:25:35 | sean-k-mooney | so we can merge both together | |
| 13:25:41 | bauzas | you can't | |
| 13:25:45 | sean-k-mooney | right i think that is wrong | |
| 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? | |