Earlier  
Posted Nick Remark
#openstack-nova - 2022-09-14
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 -rc1
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?
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)

Earlier   Later