Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-03-02
15:13:38 gmann dansmith: yeah'
15:13:58 dansmith ack, I will, I waffled over that when I first wrote it
15:14:22 bauzas gmann: OK thanks
15:14:34 bauzas gmann: so, A will be the first 'tick' release, right?
15:14:38 dansmith bauzas: working on that job, I hit the now-known bug where we broke FFUs, which is why I added that workaround
15:14:59 dansmith this will help catch things that break FFU as well, so pretty helpful for us downstream, IMHO
15:14:59 bauzas :p
15:15:26 bauzas I see
15:15:30 dansmith bauzas: A will be the first tick, yoga->A is our opportunity to get it right
15:15:54 bauzas and then zed ?
15:16:03 dansmith zed is tock
15:16:05 bauzas OK
15:16:43 bauzas ok, so yoga is 'tick', zed is 'tock' so we need to verify yoga > A
15:16:45 bauzas OK, understood
15:16:50 dansmith yeah
15:16:51 gmann yeah
15:17:13 bauzas and if we want to deprecate something, we need to wait for zed
15:17:19 dansmith yoga->Z is normal grenade job, and then when we start A, skip-level starts validating that we *keep* not breaking things from Y->A
15:17:45 bauzas got it
15:18:04 dansmith bauzas: you can deprecate something any time you want, you just can't remove support for something in A that was supported in Y (unless they had homework to do in Y or something)
15:18:23 bauzas I see
15:18:41 bauzas so, we need to remove some stuff at the next 'tock' release
15:19:19 bauzas say we deprecate something in Z, we need to remove it in B
15:19:38 bauzas if we deprecate something in A, we can remove it in B
15:19:48 bauzas but if we deprecate in B, we need to wait until D
15:19:49 dansmith it depends on what it is and what happens to the users
15:19:50 bauzas right?
15:20:03 dansmith give me an example and we should talk through it
15:20:14 bauzas good question
15:20:21 bauzas about policies, for example
15:20:45 bauzas the default is continuing to use the legacy
15:21:39 dansmith well, not sure that's a good one because I'm not sure we've ever actually had a switch like this
15:21:40 bauzas we were saying to start using the new policy scope/roles by default on Zed, right?
15:21:41 dansmith but,
15:21:55 gmann I think we said deprecate and remove the things in tick release only not in tock
15:22:28 dansmith if it's supported in A, then it needs to be support-able in C, but if it was deprecated in A, C can remove support for it if there's a reno that says "don't upgrade to C until you've done your work in A to remove dependence on deprecated policies"
15:22:59 bauzas I see
15:23:00 dansmith the reason not to deprecate and remove things in a tock is because the reno will live in that tock, which people shouldn't have to look at in this scheme
15:23:20 dansmith but you definitely can't have, say, a required data migration in B that does work that wasn't done in A before they land at A
15:23:23 dansmith er, land at C
15:23:53 dansmith it's really just the same rules we've always had, but only applied to tick releases
15:24:06 dansmith if you consider tock equivalent to say m2 then it's the same procedure
15:24:11 gmann bauzas: and for policy, plan is z - make enforce_scop=True by defaul but keep legacy policy (operator can disable the scope to keep it working) AA - remove the legacy policy
15:27:29 bauzas dansmith: yeah, that's what I understood
15:27:41 bauzas we can only remove by a tick release
15:28:06 bauzas and only if it was not supported by the previous tick release
15:28:17 bauzas got it?
15:28:44 bauzas but yeah gotcha, we take a tock release as an intermediate milestone
15:28:52 dansmith I think it's more fine-grained and nuanced than that, but yes, that's a fine simple approximation
15:31:33 bauzas OK
15:31:38 bauzas thanks for explaining
15:35:12 Uggla bauzas, did I understand well that the µapi version will not change in Yoga ? (remains 2.90)
15:36:44 bauzas Uggla: correct
15:36:58 bauzas we haven't merged any API change adding a new microversion
15:37:13 bauzas we had two of them be open in Yoga, none were merged
15:37:31 bauzas so, for the moment, 2.92 is the next microversion
15:37:34 bauzas whops
15:37:38 bauzas 2.91
15:37:43 bauzas fucking fingers
15:40:17 dansmith wow, no microversions in yoga?
15:40:24 dansmith that's both maybe a little scary and kinda amazing
15:40:50 Uggla bauzas, cool so maybe I will not have to change it in my patch. \o/
15:41:15 bauzas dansmith: we only had two open changes for it
15:41:30 bauzas dansmith: one for tenant > project usage
15:42:30 bauzas the other one for a /servers new UUID parameter
15:43:12 bauzas (for booting to a specific hypervisor instead of using a very bad AZ param)
15:43:28 dansmith bauzas: and the volume rebuild
15:43:33 bauzas ah right
16:12:09 opendevreview ribaudr proposed openstack/nova master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova/+/831507
16:22:59 melwitt gmann: I understand there are no additional tempest test running on skip level job but nova-grenade-multinode will only be testing that policy change doesn't break N -> N+1 but only the skip level job will test N -> N+2. maybe I am missing something?
16:25:47 melwitt nvm just saw your later comment on the review
16:26:00 dansmith oh sorry,
16:26:07 dansmith I just realized my git-review failed to merge with master
16:27:50 opendevreview Dan Smith proposed openstack/nova master: Add grenade-skip-level irrelevant-files config https://review.opendev.org/c/openstack/nova/+/831229
16:27:54 dansmith thar we go ^
16:28:59 gmann melwitt: yeah
16:29:02 gmann dansmith: thanks
17:22:54 opendevreview Balazs Gibizer proposed openstack/nova master: Record SRIOV PF MAC in the binding profile https://review.opendev.org/c/openstack/nova/+/829248
17:42:57 opendevreview ribaudr proposed openstack/nova master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova/+/831507
19:44:33 ade_lee_ sean-k-mooney, dansmith - hey - could you guys take a look at some jobs -- https://review.opendev.org/c/openstack/nova/+/827895
19:45:26 ade_lee_ sean-k-mooney, dansmith trying to figure out why the centos/fips jobs are failing -- this seems to be the same problem in other jobs too.
19:46:33 ade_lee_ sean-k-mooney, dansmith eharney looked and in tempest.api.compute.servers.test_server_rescue.ServerStableDeviceRescueTest.test_stable_device_rescue_disk_virtio_with_volume_attached claims that the volume doesn't detach but if you look at the cinder and nova logs, it seems to be doing all the right things..
19:46:42 ade_lee_ (for instance)
19:54:43 sean-k-mooney that could be due to libvirt
19:54:49 sean-k-mooney is this happening on centos 9 stream
19:55:05 sean-k-mooney if its only centos 8 stream we shoudl proably ignore it
19:55:28 sean-k-mooney ya the fips job is still centos 8
19:55:46 sean-k-mooney so there are issues with q35 and device detach
19:55:57 sean-k-mooney does the fips job use the q35 manchien type?
19:56:28 ade_lee_ sean-k-mooney, q35?
19:57:09 ade_lee_ sean-k-mooney, let me retry it with centos-9 stream -- we want to move in that direction in any case
19:58:49 clarkb sean-k-mooney: ade_lee_ I think the default was updated to q35 beacuse the previous default in devstack wouldn't boot centos-9
19:59:02 opendevreview Merged openstack/nova stable/victoria: [rt] Apply migration context for incoming migrations https://review.opendev.org/c/openstack/nova/+/820559
20:03:12 sean-k-mooney clarkb: that should not be done globally
20:03:24 sean-k-mooney that will break our testing expectations
20:03:37 sean-k-mooney we expect q35 to only be enabled in nova next currently
20:04:29 clarkb ah maybe we didn't jump that far ahead. We definitely had to move the machine type ahead to boot centos 9
20:04:47 sean-k-mooney clarkb: you should not have too
20:04:54 sean-k-mooney centos 9 shoudl boot fine with pc
20:05:40 sean-k-mooney clarkb: do you have any link to that change

Earlier   Later