Earlier  
Posted Nick Remark
#openstack-nova - 2021-06-29
10:08:38 stephenfin git config format.pretty fuller # <-- if you don't have it, very helpful
10:08:53 lyarwood wonder if that works with tig
10:09:57 lyarwood nope, nvm I'll just engage my brain next time
10:10:20 stephenfin stephenfin yes, it seems we are missing binding-extended in the https://github.com/openstack/neutron/blob/master/neutron/common/ovn/extensions.py#L85
10:10:23 stephenfin lyarwood: fyi ^
10:10:34 stephenfin (from #openstack-neutron)
10:10:40 lyarwood Coolio
10:15:28 opendevreview Stephen Finucane proposed openstack/nova master: DNM: Testing ML2 extension aliases fix https://review.opendev.org/c/openstack/nova/+/798635
10:18:21 opendevreview Stephen Finucane proposed openstack/nova master: DNM: Testing ML2 extension aliases fix https://review.opendev.org/c/openstack/nova/+/798635
10:31:50 kashyap lyarwood: Hi, is this soft-lockup w/ CirrOS consistently reproducible? - https://bugs.launchpad.net/nova/+bug/1931702
10:33:00 lyarwood kashyap: hard to say, I had to hack dumping the console log into a few runs of the job before we disabled certain tests that always failed, I've not had time to rerun things with that change reverted yet
10:34:16 kashyap Hm; I saw your comment on the console log.
10:34:45 lyarwood kashyap: https://review.opendev.org/c/openstack/tempest/+/794757 and https://review.opendev.org/c/openstack/nova/+/795997 FWIW
10:38:07 kashyap lyarwood: Thanks for the rework; and the skip makes sense for now. To guess a non-OpenStack reproducer from the test:
10:39:13 kashyap lyarwood: Live-migrating a guest, its disk, with an additional file-based disk should do it?
10:39:34 lyarwood kashyap: yeah pretty much
10:40:02 kashyap lyarwood: Okay; thanks. I can also ask the virt QE to add a test to this effect to this suite. As this is a common path for OpenStack
11:13:44 gibi kashyap: do you want to talk about https://blueprints.launchpad.net/nova/+spec/virtio-as-default-display-device on the todays Nova meeting?
11:23:34 kashyap gibi: Oh, hi. Yes, that'd be good
11:23:50 gibi then I will add it to the agenda
11:23:51 kashyap gibi: Thanks for priming my memory
11:26:19 gibi no problem
11:43:20 gibi stephenfin: I'm here until the top of the hour to talk about the availability zone check. Alternatively I'm here from 15:30 CEST till the nova meeting
11:47:28 gibi stephenfin: bauzas replyed in the review and I think that was how I understood the the original agreement. so --az az:host should be translated to an internal behavior to match the --host host behavior and log a warning if that host is not in the az
11:49:27 kashyap gibi: Afraid, I might not be there for the entire meeting, as I have to run for an errand; I see it's 18:00 CET (1600 UTC)
11:50:11 gibi kashyap: I can move the topic a earlier in the agend, what is your cut of time_
11:50:14 gibi ?
11:50:46 kashyap I can be around the first 20 mins
11:50:53 kashyap Thank you, as usual for adjusting. I feel guilty :D
11:51:30 gibi kashyap: OK, I will move it. Don't worry
11:52:58 kashyap Thx!
12:53:03 bauzas gibi: again, even if we do the same, the main difference between the az hack and the --host value is that for the former, we don't verify the AZ
12:53:44 gibi bauzas: but for the --host we also not verify any az as az was not even provided
12:53:45 bauzas that's why I would like to continue to not verify it, but saying that the instance couldn't be stuck to a specific AZ
12:54:01 bauzas gibi: ah, correct indeed
12:54:03 gibi that work sof me
12:54:08 gibi works for me
12:54:13 bauzas kk
12:54:56 gibi so in --az my-az:host we dont enforce my-az, we simply replace that to whathever internal data that represents --host host only
12:55:21 gibi I don't want to say "ignore az" as I'd like to have a warning that the az is ignored
12:55:55 gibi question: do we only ignore the az if the host is not in the az, or we ignore it even if the host is in the az?
13:06:12 sean-k-mooney gibi: https://review.opendev.org/c/openstack/nova/+/797428/2 has finally passed check so im +1 on it and the preceeding patch if we want to move those forward now
13:06:36 sean-k-mooney oh your +2 on that bauzas ^
13:06:53 gibi yepp I'm OK
13:07:04 sean-k-mooney bauzas: its stephens fixs for my port delegation patch
13:07:25 bauzas sean-k-mooney: ok, I can take a look
13:07:31 bauzas gibi: I haven't seen your question, looking
13:07:45 sean-k-mooney gibi: thanks for reviewing those
13:08:11 bauzas gibi: by saying --az foo:host, we make the instance movable between AZs
13:08:25 bauzas gibi: so, the instance will land on host1 which can be on az1
13:08:47 bauzas gibi: but eventually, the instance could be moved to another host in az2 as the requested AZ eventually is "None"
13:08:57 gibi bauzas: so if --az foo:host and host in foo then we still not pin the instance to foo az toda?
13:09:00 gibi y
13:09:22 bauzas gibi: today, we stick to foo
13:09:33 bauzas gibi: even if host isn't in foo
13:09:56 bauzas tomorrow, we'll stick to nothing and leave the instance be in any AZ
13:10:25 bauzas if host is in 'bar' AZ, fine
13:10:34 gibi bauzas: ack, this works for me
13:10:41 sean-k-mooney the alternitive being stick to the az that host is in, reject the request or keep the current behavior
13:10:57 sean-k-mooney i think im ok with what bauzas is suggesting too
13:11:14 bauzas and like I said, if the operator wants to land on host and stick to foo, they can say --host host and --az foo
13:11:27 bauzas then, they'll get NoValidHosts
13:11:47 bauzas sean-k-mooney: I don't like the alternative as I don't wanna verify the AZ by the API
13:11:58 bauzas since the AZFilter can be disabled
13:12:12 sean-k-mooney its not related to the az filter
13:12:14 bauzas and I know some ops that use forced_hosts hack but don't run AZFilter
13:12:31 sean-k-mooney instance hav az without that
13:12:46 bauzas we only enforce AZs by the filter
13:12:56 bauzas or by placement
13:13:01 sean-k-mooney no we also suport^
13:13:03 bauzas (if the prefilter is enabled)
13:13:12 sean-k-mooney yep and you can disable both
13:13:16 bauzas correct
13:13:29 bauzas so, you can technically use the forced_hosts hack without using AZs
13:13:30 sean-k-mooney although the filter should get deprecated this cycle and removed next cycle
13:13:38 bauzas whatever
13:13:42 sean-k-mooney but the prefilter will still be configurable
13:13:47 bauzas we'll continue to verify AZs by the scheduler
13:13:50 sean-k-mooney although on by default
13:13:57 bauzas like the AZFilter ;)
13:14:06 sean-k-mooney right although we could do in the api instead
13:14:09 bauzas no
13:14:15 bauzas it's a breaking change
13:14:18 sean-k-mooney its a viald althernitive
13:14:31 sean-k-mooney bauzas: not if its configurable although yes config driven api behavior is bad
13:14:45 sean-k-mooney although that is effectivly what we do with the filter
13:14:50 bauzas we said a couple of times to *not* verify the filters by the api service
13:15:02 bauzas the api service needs to be scheduler agnostic
13:15:19 sean-k-mooney this is not really verifying the filter
13:15:26 sean-k-mooney its verifying if the request is valid
13:15:32 sean-k-mooney anyway
13:15:36 bauzas it's enforcing AZs on the API side while you could have disabled it
13:15:45 bauzas and I have serious concerns about it
13:16:00 bauzas but yeah, I think we have a plan
13:16:02 sean-k-mooney well long term i would like to remove the ablity to diable az filtering
13:16:12 opendevreview Merged openstack/nova master: Fix error '404 Not Found' https://review.opendev.org/c/openstack/nova/+/797233
13:16:13 sean-k-mooney and by long term i mean in Z
13:16:18 bauzas sean-k-mooney: you'll release the operator's fury
13:16:33 sean-k-mooney why by default everything will be in one az
13:16:39 bauzas AZs *have to* be optional

Earlier   Later