| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-05-03 | |||
| 14:21:55 | dansmith | yep | |
| 14:22:12 | bauzas | which is quite a chicken-and-egg problem | |
| 14:22:14 | sean-k-mooney | the thing is we would like this to be more atomatic while also not havign upcalls or having the comptue specificly knwo what az its in | |
| 14:22:31 | sean-k-mooney | because that shoudl still be changable vai the api | |
| 14:22:43 | dansmith | well, I don't see "desired_az" as breaking the "knowing what az I'm in" rule | |
| 14:22:49 | dansmith | yeah of course | |
| 14:23:05 | sean-k-mooney | desired_az to me woudl be like the initial cpu allocation ratio | |
| 14:23:10 | dansmith | just like our default allocation ratios - they're used if we have to set a default, otherwise it's what is in placement that matters | |
| 14:23:13 | dansmith | yep | |
| 14:23:14 | sean-k-mooney | rigth somethign that is used once and only once | |
| 14:23:17 | dansmith | exactly | |
| 14:23:24 | bauzas | fwiw, AZs are already a complicated matter to understand | |
| 14:23:36 | sahid | dansmith: yes our biggest concern was the az showed | |
| 14:23:38 | bauzas | do we really want to introduce another concept ? | |
| 14:23:51 | dansmith | bauzas: what other concept? | |
| 14:24:14 | bauzas | 'I, as compute, will be part of an AZ eventually' | |
| 14:24:33 | dansmith | well, that's true regardless of what we do here :) | |
| 14:24:33 | sean-k-mooney | that a concept for the installer/deploer | |
| 14:24:36 | bauzas | reconciliation, if you prefer | |
| 14:24:42 | sean-k-mooney | not really for the end users and only partly for the admin | |
| 14:25:09 | bauzas | dansmith: see, sahid's problem is the user-facing AZ list problem | |
| 14:25:30 | bauzas | not the day-2 operational problem of adding a host to an AZ | |
| 14:25:35 | dansmith | bauzas: I've said several times, I get that.. I think there are two benefits to a solution here, his being one | |
| 14:25:46 | sean-k-mooney | im still not sure if that can be adress by settign default_avaialblity_zone=internal | |
| 14:26:04 | bauzas | sean-k-mooney: internal has a very different meaning today | |
| 14:26:09 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.internal_service_availability_zone | |
| 14:26:19 | sean-k-mooney | bauzas: it does but its not show to non admins | |
| 14:26:27 | sean-k-mooney | and sahid does not want this to be show | |
| 14:26:32 | bauzas | internal skips all computes | |
| 14:26:45 | sean-k-mooney | i know | |
| 14:27:01 | bauzas | again, this show problem is resolvable by default_availability_zone | |
| 14:27:01 | sean-k-mooney | but do we have somethign to prevent you setting https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_availability_zone to internal | |
| 14:27:11 | bauzas | ah, no | |
| 14:27:20 | bauzas | but I can quickly check | |
| 14:28:13 | sean-k-mooney | i would be ok with extending the concep of the intenal az to have compute in it if you set default_availability_zone=internal and documenting this means they cannot be used for workloads | |
| 14:28:40 | sean-k-mooney | i.e. make it a parkign ground for newly added compute serivce that the operator is yet to assign to a real az | |
| 14:28:53 | sean-k-mooney | i dont think that woudl break any exising usecases | |
| 14:29:21 | bauzas | this could break the filter | |
| 14:29:23 | bauzas | https://github.com/openstack/nova/blob/033af941792a9ae510c8d6b2cc318f062f0e1c66/nova/scheduler/filters/availability_zone_filter.py#L68 | |
| 14:29:50 | sahid | bauzas: if user can see that, they can try to deploy instance with this az which is not what we want as-well | |
| 14:30:06 | sean-k-mooney | not if we reject all api request with az=Config.internal_service_availability_zone | |
| 14:30:31 | sean-k-mooney | sahid: i belive they cannot see it unless they are an admin | |
| 14:30:36 | sahid | (i mean in an ideal case) | |
| 14:31:10 | bauzas | sahid: again, speaking of examples | |
| 14:31:25 | bauzas | sahid: if you already have AZ1, AZ2 and AZ2 that are meaningful | |
| 14:31:37 | bauzas | all those three are shown by nova az-list | |
| 14:31:49 | bauzas | and now you do care of not showing 'nova' in that list | |
| 14:32:12 | bauzas | what I'm saying is that then change 'default_az' to any of the three, and job is done | |
| 14:35:50 | sahid | ok, let's use this way | |
| 15:06:11 | opendevreview | Sylvain Bauza proposed openstack/nova master: Fix get_segments_id with subnets without segment_id https://review.opendev.org/c/openstack/nova/+/882160 | |
| 15:12:57 | dansmith | eharney: if you're good with this, it could use a +W as everything it depends on is in the gate now: https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/881764 | |
| 15:18:58 | opendevreview | Dan Smith proposed openstack/nova master: DNM: Test new ceph job configuration with nova https://review.opendev.org/c/openstack/nova/+/881585 | |
| 15:21:41 | dansmith | man, the nova jobs sure have gotten big again | |
| 15:21:50 | dansmith | we're running a lot of jobs | |
| 15:28:04 | auniyal | dansmith, yes its takes around 2 hour for a patch to get verified from tox | |
| 15:28:24 | auniyal | zuul | |
| 15:32:20 | dansmith | auniyal: that's generally a function of the slowest job, not the number of jobs | |
| 16:50:18 | dansmith | gouthamr: the tempest stuff is all landed.. if you can +W the cinder-tempest-change now, it can go in and then the devstack plugin change is all that's left | |
| 16:56:22 | dansmith | eharney: good catch I guess... I don't know if it's okay to just bump the requirement or not | |
| 16:56:25 | dansmith | gmann: https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/881764?tab=comments | |
| 16:57:13 | dansmith | 27 was wallaby and 30 was yoga | |
| 16:57:36 | dansmith | so upstream I would think we're good bumping the version but I dunno if anything installs this from master in older versions... | |
| 17:25:15 | gmann | dansmith: give me 2 min, will check | |
| 17:25:36 | dansmith | gmann: ack thanks | |
| 17:34:49 | gouthamr | stable jobs install "master" version of the plugin (and tempest) unless explicitly pinned | |
| 17:35:57 | dansmith | gouthamr: but how far back? | |
| 17:36:19 | dansmith | we pin tempest at some point I think when the stable jobs get too old to support master tempest | |
| 17:37:08 | dansmith | all the release jobs back to xena are passing | |
| 17:37:39 | gouthamr | ah good; the first pin i see is in stable/wallaby: https://github.com/openstack/cinder/blob/stable/wallaby/.zuul.yaml#L291-L292 | |
| 17:37:47 | dansmith | and I know they're using master tempest because they were honoring the depends-on when I was working on those patches (and breaking things) | |
| 17:38:07 | dansmith | gouthamr: ack, and since the xena job on c-t-p works, we should be good then right? | |
| 17:38:45 | gouthamr | i think so dansmith; tosky and gmann would be experts in this area | |
| 17:38:59 | dansmith | ack, well, we'll see what gmann has to say | |
| 17:39:43 | gouthamr | for correctness, we need the latest version of tempest - and afawct, that's working as expected.. | |
| 17:40:06 | dansmith | yeah, so I'm not sure what the tempest requirement would be, if we're actually using master tempest | |
| 17:40:11 | gouthamr | we just hope no-one outside of our gates is pinning tempest for whatever reason but using a newer version of ctp.. (a weirdness i've seen albeit temporarily in some rdo jobs) | |
| 17:40:50 | gmann | dansmith: gouthamr tempest is pinned till wallaby as stable/xena still not in EM https://review.opendev.org/c/openstack/releases/+/881254 | |
| 17:41:26 | dansmith | gmann: right, but xena is good according to this: https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/881764?tab=change-view-tab-header-zuul-results-summary | |
| 17:42:16 | gmann | dansmith: ok, which one is failing | |
| 17:42:33 | dansmith | gmann: nothing is failing | |
| 17:42:47 | dansmith | gmann: eharney was concerned about the tempest version in ctp requirements | |
| 17:43:11 | gmann | dansmith: ohk, checking that only. will reply | |
| 17:43:29 | dansmith | btw "nothing is failing" feels *amazing* to say :) | |
| 17:45:34 | gmann | :) | |
| 18:13:03 | gouthamr | ++ | |
| 18:16:09 | gmann | dansmith: replied, agree with Eric to bump tempest version there https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/881764/comments/0be5d072_64ceae34 | |
| 18:17:04 | dansmith | gmann: okay I'll update it, but I don't understand why it would time out | |
| 18:17:32 | dansmith | oh is it because with ACTIVE we wait for the instance state to become the wait_until value? | |
| 18:17:46 | gmann | yeah https://github.com/openstack/tempest/blob/27.0.0/tempest/common/compute.py#L236 | |
| 18:18:02 | gmann | it will pass SSHABLE as server status to wait for | |
| 18:18:17 | dansmith | ack, okay I was focused on the SSHABLE special cases up earlier, I see | |
| 18:18:28 | dansmith | just updated, gouthamr ^ | |
| 18:20:49 | gmann | ack | |
| 18:38:43 | opendevreview | Merged openstack/nova stable/yoga: Remove mentions of removed scheduler filters https://review.opendev.org/c/openstack/nova/+/858025 | |
| 18:41:11 | dansmith | gouthamr: I think I better go ahead and do the cephadm->py3 job name change in the devstack plugin, otherwise we'll break nova as soon as that lands before we either rename it there or change nova (et al) to point to the new job | |
| 18:45:14 | gouthamr | dansmith: +1; to clear this in my head and plan further cleanup - in your revert patch, you set cephadm options in "devstack-plugin-ceph-tempest-py3-base", correct? | |
| 18:46:09 | dansmith | gouthamr: no I set the cephadm thing only in the cephadm job (which would be renamed to -py3).. probably no reason not to set it on the base one yet | |
| 18:46:32 | dansmith | i figured I would rename the jobs and then you can remove the old one when you remove the non cephadm support from it | |
| 18:46:57 | dansmith | just leave the distro-based one named -ubuntu, nonvoting | |
| 18:47:17 | dansmith | I can do the removal and refactoring there, I just don't want to change so much, especially in a patch that was supposed to be a revert :) | |