| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-01-24 | |||
| 10:44:08 | kashyap | sean-k-mooney: The API replacement patch lost your +2, can you also re-look at it when you can? - https://review.opendev.org/c/openstack/nova/+/869950/9 | |
| 10:44:19 | kashyap | (And also it lost +W due to rebase) | |
| 10:44:32 | sean-k-mooney[m] | sure i tought it still had it when i looked but ill look again | |
| 10:44:52 | kashyap | Thx! | |
| 10:45:34 | sean-k-mooney[m] | +2 was still there it lost +w | |
| 10:45:52 | sean-k-mooney[m] | i have added that but its obviously pendeing the first change having both | |
| 10:50:09 | sean-k-mooney[m] | ok i think its time for coffee brb | |
| 10:55:55 | kashyap | Yeah, it won't merge anyway until the predicated patch is merged | |
| 11:00:33 | ratailor | sean-k-mooney[m], gibi Could you please review https://review.opendev.org/c/openstack/nova/+/852737 and https://review.opendev.org/c/openstack/nova/+/861738 | |
| 11:09:55 | sean-k-mooney | ratailor: i started looking at that yesterday actully i just got pulled into other discussions | |
| 11:10:28 | ratailor | sean-k-mooney, ack. np. Thanks! | |
| 11:18:58 | opendevreview | Merged openstack/nova stable/zed: Correct config help message related options https://review.opendev.org/c/openstack/nova/+/871247 | |
| 11:45:42 | opendevreview | Merged openstack/nova stable/train: func: Introduce a server_expected_state kwarg to InstanceHelperMixin._live_migrate https://review.opendev.org/c/openstack/nova/+/865382 | |
| 12:14:24 | opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova master: api: extend evacuate instance to support target state https://review.opendev.org/c/openstack/nova/+/858384 | |
| 13:04:44 | sean-k-mooney | bauzas: ^ can you look at shaid's seriese i think its ready to go | |
| 13:05:05 | sean-k-mooney | zuul is still running on the last revision but the func test fix was trivial so i expect it to pass | |
| 13:08:38 | sean-k-mooney | dansmith: can you send this on its way https://review.opendev.org/c/openstack/nova/+/865071 that the last patch for the new defaults | |
| 13:29:24 | bauzas | sean-k-mooney: was on my todolist | |
| 13:30:08 | bauzas | btw. thanks for the first thoughts on my series | |
| 13:30:51 | sean-k-mooney | more or less it made sense to me | |
| 13:31:03 | sean-k-mooney | i just needed to figure out how you had it split up | |
| 13:32:24 | bauzas | sean-k-mooney : the 3rd patch was too large for the CI | |
| 13:32:31 | bauzas | hence the split | |
| 13:33:12 | sean-k-mooney | so i can generate a smaller set of files for you if you like | |
| 13:33:16 | sean-k-mooney | many of the files in that are not used | |
| 13:33:47 | sean-k-mooney | if you look you are only using a small subset of sysfs currenly | |
| 13:34:02 | sean-k-mooney | and most of the fiels are symlinks | |
| 13:35:48 | bauzas | yep I know | |
| 13:36:15 | bauzas | like in general sysfs btw ;-) | |
| 13:36:47 | sean-k-mooney | yep | |
| 13:37:00 | sean-k-mooney | it took a while to figureout how to make a copy that worked the same | |
| 13:37:41 | sean-k-mooney | if i rememebr correctly my first attempt flatened the symlinks and resulted in things getting out of sync | |
| 14:04:41 | opendevreview | Jorge San Emeterio proposed openstack/nova master: [DNM] Testing effects on privsep on a build. https://review.opendev.org/c/openstack/nova/+/871607 | |
| 14:05:01 | opendevreview | Jorge San Emeterio proposed openstack/nova master: [DNM] Testing effects on privsep on a build. https://review.opendev.org/c/openstack/nova/+/871607 | |
| 14:56:18 | dansmith | sean-k-mooney: yep | |
| 15:01:10 | opendevreview | Dan Smith proposed openstack/nova master: Check VMDK create-type against an allowed list https://review.opendev.org/c/openstack/nova/+/871612 | |
| 15:01:45 | opendevreview | Dan Smith proposed openstack/nova master: Check VMDK create-type against an allowed list https://review.opendev.org/c/openstack/nova/+/871612 | |
| 15:02:19 | opendevreview | Dan Smith proposed openstack/nova stable/zed: Check VMDK create-type against an allowed list https://review.opendev.org/c/openstack/nova/+/871616 | |
| 15:03:09 | opendevreview | Dan Smith proposed openstack/nova stable/xena: Check VMDK create-type against an allowed list https://review.opendev.org/c/openstack/nova/+/871622 | |
| 15:03:39 | opendevreview | Dan Smith proposed openstack/nova stable/yoga: Check VMDK create-type against an allowed list https://review.opendev.org/c/openstack/nova/+/871624 | |
| 15:03:43 | dansmith | bauzas: your help on these quickly is appreciated ^ | |
| 15:05:16 | bauzas | dansmith: kk, I've seen it before | |
| 15:06:08 | bauzas | sean-k-mooney: dansmith: I have a bit thoughts on upgrades for sahid's new API microversion https://review.opendev.org/c/openstack/nova/+/858384 | |
| 15:06:26 | bauzas | dansmith: +2d the master one | |
| 15:12:33 | sean-k-mooney | evacuate will work but not with the latest microverion until you are fully upgraded | |
| 15:13:05 | sean-k-mooney | so the only way around that is a new paramater in the api | |
| 15:13:18 | bauzas | sean-k-mooney: I know, see my comments | |
| 15:13:34 | dansmith | wow, that patch | |
| 15:13:35 | bauzas | sean-k-mooney: my only comment is to say we should at least explain it more | |
| 15:13:39 | sean-k-mooney | but that kind of defeats the idea of always pwowering off unless the new parmater default to powering off if not set | |
| 15:14:49 | sean-k-mooney | bauzas: is the concern mainly for nova-client | |
| 15:14:52 | bauzas | sean-k-mooney: sure, and again, I'm not *against* the new behaviour | |
| 15:15:16 | sean-k-mooney | openstack client need explcit opt in | |
| 15:15:24 | sean-k-mooney | baiscally im wondiering are you ok with just docs | |
| 15:15:26 | bauzas | sean-k-mooney: my only concern is that IMHO we don't really explain it correctly, at least we need an upgrade section | |
| 15:15:28 | sean-k-mooney | or do you want a design change | |
| 15:15:51 | sean-k-mooney | ok so you would like better docs and beeter release note to call that out | |
| 15:16:04 | bauzas | sean-k-mooney: at least I can accept the new behaviour, but I want to make sure that people know it | |
| 15:16:37 | bauzas | as you said, by default OSC will return an exception if you evacuate an instance on Antelope without upgrading all computes | |
| 15:16:46 | sean-k-mooney | no | |
| 15:16:50 | sean-k-mooney | by default it will evacuate | |
| 15:16:57 | sean-k-mooney | because it does not use the latest microverions | |
| 15:17:12 | sean-k-mooney | its only an issue for nova client which woudl use the latest microversion automatically | |
| 15:17:15 | bauzas | I thought that now OSC defaults to the latest | |
| 15:17:18 | sean-k-mooney | nope | |
| 15:17:20 | sean-k-mooney | 2.1 | |
| 15:17:50 | bauzas | sean-k-mooney: this is an issue for any client asking the latest | |
| 15:17:53 | sean-k-mooney | if you want anything else you have to choose it by env var, cli flag or in your clouds.yaml | |
| 15:17:54 | bauzas | point. | |
| 15:18:13 | bauzas | hence me saying I'm OK (again, see my comments) | |
| 15:18:14 | sean-k-mooney | bauzas: right which we tell them not to do to avoid this exact type of issue | |
| 15:18:20 | bauzas | but we correctly need to document it | |
| 15:18:23 | sean-k-mooney | sure | |
| 15:18:30 | sean-k-mooney | tottaly fine wiht adding more docs | |
| 15:18:44 | bauzas | and having a better returned exception | |
| 15:19:20 | bauzas | like "heh, we don't accept your parameters for the new feature" doesn't really explain *why* the exception was returned | |
| 15:19:20 | sean-k-mooney | we can explictly say use a microversion before X (2.95?) to evacuate until upgades are complete | |
| 15:19:34 | bauzas | sean-k-mooney: true, that's what I'm asking | |
| 15:19:53 | sean-k-mooney | this is also an adming only api so the impact is much less | |
| 15:20:12 | bauzas | again, I've said it : it's admin-only hence why I'm OK | |
| 15:20:16 | sean-k-mooney | but we still need to tell them about it so ya | |
| 15:20:34 | bauzas | if this was an enduser API, then definitely -1 and asking for another design | |
| 15:20:48 | bauzas | because endusers don't know the environment was upgraded | |
| 15:21:00 | sean-k-mooney | im not sure i would agree | |
| 15:21:02 | bauzas | and actually, even API admins couldn't be knowing itr | |
| 15:21:21 | sean-k-mooney | but i would say if that how you felt giving that feedback now instead of in the spec review is unfortunet | |
| 15:21:22 | bauzas | sometimes, environment operators and API admins are different people | |
| 15:21:47 | bauzas | sean-k-mooney: again, I'm not against the desing | |
| 15:21:51 | bauzas | we discussed it at the PTG | |
| 15:22:00 | bauzas | and the spec was there, agreed | |
| 15:22:07 | sean-k-mooney | we did and the spec had 4 +2s too | |
| 15:22:19 | bauzas | I'm just explaining that this could have been different if the API was enduser, that's it | |
| 15:22:43 | bauzas | and see "could" | |
| 15:22:49 | bauzas | not saying I would disagree | |
| 15:22:55 | sean-k-mooney | we have microversion to allow this so we could but i dont think we should even for an end user api | |
| 15:23:18 | sean-k-mooney | anyway lets work on the release note and excetion message so | |
| 15:23:19 | bauzas | anyway, I think we both agree : it needs a better explanation | |
| 15:23:22 | sean-k-mooney | thanks for taking a look | |
| 15:23:27 | sean-k-mooney | yep | |
| 15:25:18 | dansmith | no, it's already +2 | |