*** tbachman has joined #openstack-nova | 00:03 | |
*** macz_ has quit IRC | 00:06 | |
*** luksky has quit IRC | 00:14 | |
*** osmanlicilegi has joined #openstack-nova | 00:16 | |
*** gibi has joined #openstack-nova | 00:17 | |
*** tosky has quit IRC | 00:17 | |
*** k_mouza has joined #openstack-nova | 00:21 | |
*** k_mouza has quit IRC | 00:25 | |
*** jamesdenton has quit IRC | 00:26 | |
*** jamesden_ has joined #openstack-nova | 00:27 | |
*** martinkennelly has quit IRC | 00:32 | |
*** martinkennelly has joined #openstack-nova | 00:36 | |
*** hamalq has quit IRC | 00:41 | |
*** martinkennelly has quit IRC | 00:46 | |
*** martinkennelly has joined #openstack-nova | 00:47 | |
openstackgerrit | Merged openstack/nova master: libvirt: Define and emit DeviceRemovedEvent and DeviceRemovalFailedEvent https://review.opendev.org/c/openstack/nova/+/749929 | 00:53 |
---|---|---|
*** martinkennelly has quit IRC | 00:55 | |
*** martinkennelly has joined #openstack-nova | 00:56 | |
*** iurygregory has quit IRC | 01:07 | |
*** mlavalle has quit IRC | 01:14 | |
*** hemanth_n has joined #openstack-nova | 01:25 | |
*** iurygregory has joined #openstack-nova | 01:30 | |
*** zzzeek has quit IRC | 01:49 | |
*** zzzeek has joined #openstack-nova | 01:51 | |
*** martinkennelly has quit IRC | 01:57 | |
openstackgerrit | Wenping Song proposed openstack/nova master: Nova supports password encrypted VNC https://review.opendev.org/c/openstack/nova/+/622336 | 02:03 |
openstackgerrit | Merged openstack/nova master: libvirt: Remove dead code https://review.opendev.org/c/openstack/nova/+/772928 | 02:06 |
openstackgerrit | Merged openstack/nova master: rpc: Rework 'get_notifier', 'wrap_exception' https://review.opendev.org/c/openstack/nova/+/741663 | 02:17 |
*** rcernin has quit IRC | 02:34 | |
*** zenkuro has quit IRC | 02:36 | |
*** rcernin has joined #openstack-nova | 02:47 | |
*** jkulik has quit IRC | 03:03 | |
*** spatel has joined #openstack-nova | 03:03 | |
*** jkulik has joined #openstack-nova | 03:14 | |
*** mkrai has joined #openstack-nova | 03:16 | |
*** spatel has quit IRC | 03:22 | |
*** jamesden_ is now known as jamesdenton | 03:29 | |
*** vishalmanchanda has joined #openstack-nova | 03:45 | |
*** psachin has joined #openstack-nova | 03:47 | |
*** LinPeiWen has joined #openstack-nova | 04:16 | |
*** zzzeek has quit IRC | 04:32 | |
*** zzzeek has joined #openstack-nova | 04:33 | |
*** zul has quit IRC | 04:53 | |
*** whoami-rajat_ has joined #openstack-nova | 05:25 | |
*** brinzhang_ has quit IRC | 06:01 | |
*** brinzhang_ has joined #openstack-nova | 06:01 | |
*** khomesh24 has joined #openstack-nova | 06:03 | |
*** lbragstad_ has joined #openstack-nova | 06:03 | |
*** lbragstad has quit IRC | 06:06 | |
*** zzzeek has quit IRC | 06:10 | |
*** zzzeek has joined #openstack-nova | 06:11 | |
*** k_mouza has joined #openstack-nova | 06:21 | |
*** k_mouza has quit IRC | 06:25 | |
*** tbachman has quit IRC | 06:28 | |
*** tbachman has joined #openstack-nova | 06:28 | |
*** gyee has quit IRC | 06:47 | |
*** whoami-rajat_ is now known as whoami-rajat | 06:54 | |
*** ralonsoh has joined #openstack-nova | 06:55 | |
*** rcernin has quit IRC | 06:57 | |
*** slaweq has joined #openstack-nova | 07:08 | |
*** jawad_axd has joined #openstack-nova | 07:25 | |
openstackgerrit | Yongli He proposed openstack/nova master: Smartnic support - cyborg drive https://review.opendev.org/c/openstack/nova/+/771362 | 07:25 |
openstackgerrit | Yongli He proposed openstack/nova master: smartnic support - new vnic type https://review.opendev.org/c/openstack/nova/+/771363 | 07:25 |
openstackgerrit | Yongli He proposed openstack/nova master: smartnic support https://review.opendev.org/c/openstack/nova/+/758944 | 07:25 |
*** lpetrut has joined #openstack-nova | 07:27 | |
openstackgerrit | Yongli He proposed openstack/nova master: smartnic support https://review.opendev.org/c/openstack/nova/+/758944 | 07:40 |
*** dklyle has quit IRC | 07:47 | |
*** links has joined #openstack-nova | 07:51 | |
*** belmoreira has joined #openstack-nova | 07:55 | |
*** andrewbonney has joined #openstack-nova | 07:58 | |
openstackgerrit | Yongli He proposed openstack/nova master: Smartnic support - cyborg drive https://review.opendev.org/c/openstack/nova/+/771362 | 08:03 |
openstackgerrit | Yongli He proposed openstack/nova master: smartnic support - new vnic type https://review.opendev.org/c/openstack/nova/+/771363 | 08:03 |
openstackgerrit | Yongli He proposed openstack/nova master: smartnic support https://review.opendev.org/c/openstack/nova/+/758944 | 08:03 |
*** khomesh24 has quit IRC | 08:05 | |
*** khomesh24 has joined #openstack-nova | 08:06 | |
*** alex_xu has joined #openstack-nova | 08:07 | |
yonglihe | gibi: alex_xu: i still own alex_xu 2 more check in code, everything else done. | 08:08 |
*** luksky has joined #openstack-nova | 08:14 | |
*** mkrai has quit IRC | 08:18 | |
*** mkrai has joined #openstack-nova | 08:18 | |
*** rpittau|afk is now known as rpittau | 08:22 | |
*** xek has joined #openstack-nova | 08:24 | |
gibi | sean-k-mooney: sure I will do a doodle poll similar to previous PTGs | 08:25 |
gibi | yonglihe: ack | 08:25 |
*** tosky has joined #openstack-nova | 08:35 | |
*** ociuhandu has joined #openstack-nova | 08:44 | |
*** martinkennelly has joined #openstack-nova | 08:50 | |
*** jamesdenton has quit IRC | 08:56 | |
*** jamesdenton has joined #openstack-nova | 08:57 | |
*** lucasagomes has joined #openstack-nova | 09:01 | |
*** songwenping_ has quit IRC | 09:07 | |
* bauzas fights with live migration <3 | 09:09 | |
bauzas | can someone know how I could reproduce locally the tox lower-constraints job ? | 09:10 |
bauzas | context : https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_f69/761452/8/check/openstack-tox-lower-constraints/f699784/testr_results.html | 09:11 |
*** songwenping_ has joined #openstack-nova | 09:12 | |
bauzas | mmmm, there is a l-c tox target with not using use_develop | 09:15 |
* bauzas wonders why | 09:15 | |
*** brinzhang0 has joined #openstack-nova | 09:15 | |
bauzas | and also, I don't have py36 running | 09:16 |
bauzas | (as default) | 09:16 |
kashyap | lyarwood: Morning, when you get a min: Nova uses in-QEMU RBD driver with raw or QCOW2 format or both? | 09:17 |
*** brinzhang_ has quit IRC | 09:18 | |
*** songwenping_ has quit IRC | 09:18 | |
stephenfin | bauzas: care to bump this +1 to +2? https://review.opendev.org/c/openstack/nova/+/775415/ | 09:30 |
*** zenkuro has joined #openstack-nova | 09:31 | |
hemanth_n | sean-k-mooney: can you review the PCI stat bug on stable/rocky when you get some time https://review.opendev.org/c/openstack/nova/+/761824 | 09:31 |
bauzas | stephenfin: I'm focusing on fixing the RPC API bump issues in the gate, but I can try to take a look on it later today | 09:40 |
lyarwood | kashyap: RAW only, we block qcow2 iirc | 09:48 |
kashyap | lyarwood: A QEMU dev was asking about it; do you know the reason why we block QCOW2? | 09:50 |
*** ociuhandu has quit IRC | 09:50 | |
lyarwood | kashyap: we block it when cloning rbd volumes as rbd already does the COW for us | 09:51 |
lyarwood | kashyap: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/imagebackend.py#L1038-L1041 | 09:51 |
lyarwood | kashyap: ^ that's for ephemeral storage nova controls, I'm not sure about cinder tbh | 09:51 |
* lyarwood looks | 09:51 | |
lpetrut | hi: what should we do about the windows rbd patch? https://review.opendev.org/c/openstack/nova/+/763550 lyarwood would like to bump the lower constraints, sean-k-mooney was asking us not to do that :) | 09:52 |
lyarwood | kashyap: https://github.com/openstack/cinder/blob/85975fb2b63866ba6e216e621b84d571b9dbe90e/cinder/volume/drivers/rbd.py#L1525-L1530 - looks like the same logic in cinder | 09:53 |
lyarwood | lpetrut: yeah sorry about this, I don;t think sean-k-mooney got that the current os-brick version would fail with your change, at least I'm hoping that's the case. | 09:53 |
kashyap | lyarwood: /me clicks | 09:53 |
lyarwood | gibi / stephenfin / gibi ; ^ any thoughts on lpetrut's issue? The change will not work with the current os-brick version listed in our lc/requirements.txt so we have to bump right? | 09:54 |
kashyap | lyarwood: Thanks! So the QEMU storage dev was wondering if Nova doesn't use qcow2-over-RBD due to this 2019 bug: https://bugzilla.redhat.com/show_bug.cgi?id=1744525 | 09:54 |
openstack | bugzilla.redhat.com bug 1744525 in qemu-kvm "Writing data to the qcow2 image over RBD is too slow" [Medium,Assigned] - Assigned to sgarzare | 09:54 |
kashyap | lyarwood: But I don't think that's the case; as the logic in Cinder and Nova predates that bug | 09:55 |
stephenfin | lyarwood: lpetrut: it sounds like we're avoiding bumping lower-constraints because it causes a mess? | 09:56 |
lpetrut | stephenfin yep :) | 09:56 |
stephenfin | Okay, in that case I suggest we spend a small amount of time trying to resolve the damage, and drop l-c if we can't do it easily | 09:57 |
stephenfin | Everyone else has dropped them. No point in us suffering for little to no benefit | 09:57 |
lpetrut | stephenfin: I had a patch set that sync-ed nova's lower constraints with the os-brick ones but some people were concerned by the amount of changes: https://review.opendev.org/c/openstack/nova/+/763550/12..14/lower-constraints.txt | 09:57 |
lyarwood | stephenfin: have people dropped them on master? | 09:58 |
stephenfin | sean-k-mooney: fwiw, dropping indirect dependencies from l-c can cause dependency resolution to devolve into a multi-hour slog, since the combinatorial matrix of possible versions for those indirect dependencies is huuuuuuge | 09:58 |
lyarwood | stephenfin: I noticed the stable stuff | 09:58 |
stephenfin | lyarwood: they're totally gone from oslo and neutron. Likely many other projects also | 09:58 |
* stephenfin looks at glance and cinder | 09:58 | |
lyarwood | well well well | 10:01 |
lpetrut | Cinder still uses lower constraints. most of them have been bumped here: https://github.com/openstack/cinder/commit/d3ffa90baa959530eaa1cd1d4e3800fbe9148806#diff-f868e67d7bc10a25bc6baaea42ed5c763b42174505e4441349a52cf60dc007b0 | 10:01 |
lyarwood | it doesn't really resolve our issue however | 10:01 |
lyarwood | https://review.opendev.org/c/openstack/nova/+/763550/12..14/requirements.txt <- as os-brick causes this as well | 10:01 |
lyarwood | that IMHO we can't avoid | 10:01 |
lyarwood | why don't I spend some time later today breaking that out into another change you can rebase on lpetrut | 10:02 |
lyarwood | there's a load of bugfixes in there that we need anyway outside of the new Windows RBD stuff | 10:02 |
stephenfin | that's...downgrading most things? | 10:02 |
lyarwood | yeah what the | 10:02 |
lpetrut | not quite, it's flipped :) | 10:03 |
stephenfin | That seems off. We won't be allowed to specify a lower limit that os-brick, but we should be able to specify a higher one | 10:03 |
lyarwood | oh right because you reverted it so the diff is the wrong way around | 10:03 |
stephenfin | ahh | 10:03 |
stephenfin | okay :) | 10:03 |
stephenfin | phew | 10:03 |
lpetrut | https://review.opendev.org/c/openstack/nova/+/763550/12/lower-constraints.txt | 10:03 |
stephenfin | yeah, I have no issues with bumping l-c | 10:04 |
stephenfin | the only issue would be if we were to backport this, but it's a feature so that's not an issue | 10:04 |
*** nightmare_unreal has joined #openstack-nova | 10:04 | |
lpetrut | awesome. lyarwood: are you ok with going back to patchset 12? | 10:04 |
*** derekh has joined #openstack-nova | 10:05 | |
*** khomesh24 has quit IRC | 10:05 | |
lyarwood | lpetrut: I'd like it to be a seperate change if I'm honest but I also don't want to hold you up anymore | 10:06 |
*** zoharm has joined #openstack-nova | 10:06 | |
*** ociuhandu has joined #openstack-nova | 10:06 | |
lyarwood | lpetrut: would you mind if I just broke it out into another change myself and documented the reasons for the increases in a fresh commit? | 10:07 |
lpetrut | lyarwood: sure, thanks! | 10:07 |
lyarwood | lpetrut: ack np and sorry for dragging this out | 10:07 |
lpetrut | np, glad that we managed to reach a consensus :D | 10:08 |
kashyap | stephenfin: Thank you for picking up the secure boot work! Please add yourself as the co-author / author as you see fit. I don't see your name on one of the patches that you revised. (I haven't looked at all yet; still ploughing through my post-PTO backlog of suff.) | 10:14 |
openstackgerrit | Sylvain Bauza proposed openstack/nova master: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452 | 10:20 |
openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Update Servers APIs https://review.opendev.org/c/openstack/nova/+/764292 | 10:35 |
openstackgerrit | Brin Zhang proposed openstack/nova master: Replace all_tenants with all_projects in List Server APIs https://review.opendev.org/c/openstack/nova/+/765311 | 10:36 |
openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Rebuild Server API https://review.opendev.org/c/openstack/nova/+/766380 | 10:37 |
openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List SG API https://review.opendev.org/c/openstack/nova/+/766726 | 10:38 |
*** jangutter has joined #openstack-nova | 10:41 | |
*** jangutter has quit IRC | 10:42 | |
*** jangutter has joined #openstack-nova | 10:43 | |
*** jangutte_ has quit IRC | 10:44 | |
*** mkrai has quit IRC | 10:46 | |
*** mkrai_ has joined #openstack-nova | 10:46 | |
*** k_mouza has joined #openstack-nova | 10:56 | |
openstackgerrit | James Page proposed openstack/nova stable/train: add functional regression test for bug #1888395 https://review.opendev.org/c/openstack/nova/+/759533 | 11:04 |
openstack | bug 1888395 in OpenStack Compute (nova) train "live migration of a vm using the single port binding work flow is broken in train as a result of the introduction of sriov live migration" [High,In progress] https://launchpad.net/bugs/1888395 - Assigned to Billy Olsen (billy-olsen) | 11:04 |
lyarwood | gibi / stephenfin: stupid question time, we only document direct requirements in requirements.txt, lower-constraints.txt etc right? so in bumping os-brick we don't need to bump everything the new version depends on in our tree? | 11:15 |
stephenfin | we document direct requirements in the various requirments.txt files. We document everything in lower-constraints.txt | 11:16 |
stephenfin | I suggested switching to just direct dependencies for lower-constraints.txt also but... | 11:16 |
lyarwood | well it's working with just os-brick bumped | 11:16 |
lyarwood | LC that is | 11:16 |
stephenfin | <stephenfin> sean-k-mooney: fwiw, dropping indirect dependencies from l-c can cause dependency resolution to devolve into a multi-hour slog, since the combinatorial matrix of possible versions for those indirect dependencies is huuuuuuge | 11:16 |
lyarwood | yeah I see | 11:17 |
stephenfin | you sure you're testing with pip >= 20.3 ? | 11:18 |
lyarwood | 20.2.2 | 11:18 |
stephenfin | yeah, you need to install 20.3+ first | 11:19 |
stephenfin | that has the new dependency resolver | 11:19 |
lyarwood | wait that was in the venv | 11:19 |
lyarwood | 20.3.1 outside but that doesn't matter | 11:19 |
* lyarwood wonders why 20.2.2 is being used within the venvs | 11:19 | |
stephenfin | I think pip might be bundled with virtualenv | 11:20 |
lyarwood | yeah but I thought I had a new enough version on f33 | 11:20 |
lyarwood | bumps and tries again | 11:21 |
*** psachin has quit IRC | 11:22 | |
lyarwood | cool that's failing correctly now, let me work through these | 11:25 |
*** ahsen has joined #openstack-nova | 11:28 | |
*** jangutter_ has joined #openstack-nova | 11:30 | |
*** jangutter has quit IRC | 11:33 | |
brinzhang0 | stephenfin: how about the novnc feature? https://review.opendev.org/c/openstack/nova/+/622336 | 11:39 |
stephenfin | brinzhang0: I'm thoroughly confused on that now and need to sit down and figure it out | 11:39 |
brinzhang0 | I saw gibi said we will FF at 11th, can we complete this in this cycle? | 11:39 |
stephenfin | I'm setting up a dev environment atm to play around with it | 11:40 |
stephenfin | It might make sense to reshuffle the series so that the tenant ID -> project ID gets 2.89 and I don't know how long it will take to figure this out | 11:40 |
brinzhang0 | Now we are sopport input password when we open the console, if we do this config | 11:40 |
* gibi was away and now reading back | 11:41 | |
brinzhang0 | I am very sorry, the tenant series patches may need much time to back 2.89, Ithink I want to do whatever | 11:42 |
brinzhang0 | s/want/wont | 11:42 |
gibi | lyarwood, lpetrut, stephenfin: on the os-brick bump. I'm happy to review an lc bump and I hope it is not as big as the original proposal was. If it needs to be that big then I'm a bit affraid what such amount of change introduces | 11:43 |
lyarwood | gibi: thankfully it's not, I'm also breaking the os-win bump out into another change | 11:44 |
gibi | lyarwood: thanks for working on that | 11:44 |
gibi | stephenfin: on the removal of the indirect deps from lc. Is there a way to print the huge matrix to see where are those deps that needs contraints to significantly reduce the size of the matrix? | 11:45 |
stephenfin | I'm not sure. I haven't looked into that | 11:46 |
gibi | stephenfin: ack, I can try to look into that at some point | 11:46 |
gibi | I assume there are a short list of offender indirect deps | 11:46 |
gibi | if it is not the case then meh | 11:47 |
lyarwood | actually I don't need to break os-win out sorry, I thought it also had changes | 11:48 |
*** ociuhandu has quit IRC | 11:48 | |
gibi | brinzhang0, stephenfin: I read stephenfin's comment on the vnc series but honeslty I haven't fully grocked the situation. So I trust stephenfin to do the invenstigation as he already started it and has a better view on it than me | 11:48 |
gibi | lyarwood: ack, no worries | 11:49 |
*** hoonetorg has quit IRC | 11:49 | |
*** ociuhandu has joined #openstack-nova | 11:50 | |
*** ociuhandu has quit IRC | 11:50 | |
brinzhang0 | gibi:There are two sides we need to consider. Now, we can authorican the console for client-->proxy, we need to input the password when we open its console., this is also clarified in the specs. | 11:52 |
brinzhang0 | gibi: But we dont consider the authorican with proxy-->server yet, this is stephenfin concerned. | 11:52 |
*** ociuhandu has joined #openstack-nova | 11:52 | |
stephenfin | brinzhang0: That is what has me confused. If we're doing encryption of client -> proxy then why are we setting attributes on the instance via libvirt XML. The instance lives on the server | 11:53 |
brinzhang0 | gibi: yes, hope stephenfin can give the clear direction, or let we improve it in future. | 11:53 |
stephenfin | Hence why I'm testing things now | 11:54 |
gibi | thanks, now I see the confusion | 11:54 |
openstackgerrit | Lee Yarwood proposed openstack/nova master: hyper-v rbd volume support https://review.opendev.org/c/openstack/nova/+/763550 | 11:54 |
openstackgerrit | Lee Yarwood proposed openstack/nova master: requirements.txt: Bump os-brick to 4.2.0 https://review.opendev.org/c/openstack/nova/+/778177 | 11:54 |
lyarwood | stephenfin / gibi ; ^ okay that should finally do it for the hyperv rbd stuff | 11:54 |
* lyarwood -> coffee | 11:54 | |
lyarwood | lpetrut: ^ also sorry | 11:54 |
stephenfin | gibi: Yeah, it's the little dance we do in the proxy that's confusing. I'm worked on this before but I've lost much of the context :-( | 11:54 |
gibi | lyarwood: thanks. I will jump on it before I dissapeare again to a meeting | 11:54 |
gibi | stephenfin: I'm glad you picket it up, the vnc proxy stuff is a black hole to me at the moment | 11:55 |
*** ociuhandu has quit IRC | 11:57 | |
brinzhang0 | stephenfin: one case, if you use the third VNC tools to open the instance's console, taht need to be authorican with the passwsord, it's used for proxy-->server scenario | 11:57 |
*** Luzi has joined #openstack-nova | 11:58 | |
lpetrut | lyarwood: thanks! | 11:58 |
brinzhang0 | this is also we were used daily^ | 11:58 |
lpetrut | lyarwood: I'm wondering if there's any way in which we could automate this process, it's quite tedious | 11:58 |
gibi | lyarwood: I'm +2 on the bump | 11:59 |
* gibi disappeares again :/ | 11:59 | |
brinzhang0 | stephenfin: we used the VNC tool is vnc viewer, maybe you can try | 11:59 |
lyarwood | lpetrut: I think the new pip resolver might provide a way of doing this if we wanted to keep lower-constraints.txt around in nova | 12:00 |
lyarwood | lpetrut: something to bring up at the PTG I think, either we automate this or drop lower-constraints.txt | 12:00 |
stephenfin | pip doesn't have machinery for this. That's the main issue :-( | 12:01 |
gibi | here is the ptg etherpad if neede :) https://etherpad.opendev.org/p/nova-xena-ptg | 12:01 |
stephenfin | There's an open RFE against it (filed by dhellmann iirc) but it needs bodies of course | 12:01 |
lyarwood | oh it doesn't? | 12:03 |
*** hoonetorg has joined #openstack-nova | 12:03 | |
lyarwood | huh I had assumed there was a lib or something we could call into to automate it, that's a shame | 12:03 |
sean-k-mooney | lyarwood: a min version resolver no uncortunetly not | 12:09 |
sean-k-mooney | lyarwood: we likely should restrict lower constratits to just our direct deps | 12:09 |
sean-k-mooney | possibly excluding any deps in test-requirements | 12:10 |
sean-k-mooney | for now i think we should contiue to have lower constraitns. | 12:11 |
sean-k-mooney | lyarwood: you should not be importing os-brick constratis versin into nova however | 12:11 |
sean-k-mooney | lyarwood: is the hyperv feature the only reason you are doing https://review.opendev.org/c/openstack/nova/+/778177 | 12:12 |
*** ociuhandu has joined #openstack-nova | 12:12 | |
sean-k-mooney | because we said we were not going to bump the min version for that | 12:12 |
lyarwood | that's a direct dependency | 12:12 |
lyarwood | the code doesn't work without that version | 12:13 |
sean-k-mooney | its an optional depency | 12:13 |
lyarwood | it's direct if you're using that codepath | 12:13 |
sean-k-mooney | yes | 12:13 |
sean-k-mooney | but its not when not using the hyperv driver | 12:13 |
sean-k-mooney | and we said we were not going to do an os-brick bump for that | 12:13 |
lyarwood | we'd never bump os-brick with that logic | 12:13 |
lyarwood | there have been plenty of examples in the past where we have done this to accomidate the libvirt driver | 12:14 |
lyarwood | I don't get how that's optional | 12:14 |
sean-k-mooney | true however it makes all lib deps viral | 12:14 |
openstackgerrit | Stephen Finucane proposed openstack/python-novaclient master: Add support for microversion v2.88 https://review.opendev.org/c/openstack/python-novaclient/+/770573 | 12:14 |
sean-k-mooney | if a lib bumps there min then any project that bumps there min to pick up that new lib version is forced to transitivly pick up any min verion change in that lib or its deps | 12:15 |
lyarwood | right and that's in LC at present | 12:15 |
sean-k-mooney | this did not use to happen with the old resolver | 12:16 |
lyarwood | because it was broken | 12:16 |
sean-k-mooney | no i know how it worked | 12:16 |
sean-k-mooney | it was not broken | 12:16 |
sean-k-mooney | it just worked differently then we expected | 12:16 |
sean-k-mooney | and that had some useful cases | 12:16 |
sean-k-mooney | it had some negitives too | 12:16 |
sean-k-mooney | but we have regressed our ablity to state teh min verion of nova requirements with the new resolver | 12:17 |
*** ociuhandu has quit IRC | 12:17 | |
sean-k-mooney | now we can only state if you deploy every possible backend connently on the same host this is the set of all min deps | 12:17 |
sean-k-mooney | that is a very different statement | 12:17 |
sean-k-mooney | previously we only needed to do a bump it we use a python api that did not exist or had a different signiture | 12:18 |
*** ociuhandu has joined #openstack-nova | 12:18 | |
sean-k-mooney | if nova did not use a feature in a trasitive dep directly we did not need to bump it in lc | 12:19 |
sean-k-mooney | for optional deps that was the correct behaivor | 12:19 |
*** zzzeek has quit IRC | 12:20 | |
lyarwood | I'm not disagreeing, but given the current behaviour of pip and the fact that we can't limit deps to each backend I don't see what choice we had here? | 12:21 |
sean-k-mooney | we could not do the bump | 12:22 |
lyarwood | land code that we know would fail with our current reqs? | 12:22 |
sean-k-mooney | there is no code path in any of our test coverage that will require this | 12:22 |
lyarwood | there is in third party for hyperv | 12:22 |
sean-k-mooney | lyarwood: it wont break our unit or funct test | 12:22 |
lyarwood | and? | 12:22 |
*** ociuhandu has quit IRC | 12:22 | |
sean-k-mooney | lyarwood: right and they can install the dep | 12:23 |
lyarwood | we're still landing broken code | 12:23 |
lyarwood | it just feels wrong to me | 12:23 |
lyarwood | and in any case bumping os-brick like this pulls in a load of other fixes and improvements | 12:23 |
sean-k-mooney | so does importing deps form an optional lib | 12:23 |
lyarwood | I'd argue that we needed to do that this cycle anyway tbh | 12:23 |
*** zzzeek has joined #openstack-nova | 12:23 | |
lyarwood | there are no new deps there btw, just version bumps | 12:24 |
sean-k-mooney | we can do that for other reasons but i think this is a bad pattern to apply in the general case | 12:24 |
sean-k-mooney | oh i know | 12:24 |
lyarwood | the same would also apply | 12:24 |
sean-k-mooney | but we dont want every lib to be viral | 12:24 |
sean-k-mooney | you also have a smaller set of changes then the hyperv patch orginally had | 12:24 |
lyarwood | yeah I'm not sure where some of the changes in the original hyperv change came from but pip was happy with these | 12:25 |
lyarwood | aaaaaand something has already failed | 12:25 |
* lyarwood looks | 12:25 | |
sean-k-mooney | if we want to proceed with this for this cycle i wont try to block it but i do think we need to have a ptg discusssion about this and i dont think we should do this in the future | 12:25 |
sean-k-mooney | the new resolver has changed the meanin of LC and expanded its scope | 12:26 |
sean-k-mooney | if we want to continue to use that i think we need to discuss what LC now means | 12:26 |
*** bbowen_ has joined #openstack-nova | 12:26 | |
lyarwood | sean-k-mooney: yeah I've added a line in the ptg pad but feel free to rephrase the question | 12:27 |
* lyarwood tries to understand why https://5e7e7be1ea42142e6d74-f918abb3dcdfb01ed824790c230ea283.ssl.cf2.rackcdn.com/763550/15/check/requirements-check/86d1c2f/job-output.txt is failing | 12:28 | |
sean-k-mooney | lyarwood: run tox with -r to recreate the env | 12:29 |
sean-k-mooney | or before that check the pip version | 12:29 |
*** bbowen has quit IRC | 12:29 | |
sean-k-mooney | it wont automatically upgrade the pip version | 12:29 |
sean-k-mooney | so if the enve was created with the old resolver then it will still be using it | 12:29 |
sean-k-mooney | oh | 12:30 |
lyarwood | that's a different job | 12:30 |
sean-k-mooney | lyarwood: you forgot to update requirements.txt | 12:30 |
lyarwood | I'm just about to run it locally now | 12:30 |
sean-k-mooney | you only bumped the min in lc | 12:31 |
lyarwood | for the in-direct deps? | 12:31 |
lyarwood | I thought that wasn't required? | 12:31 |
sean-k-mooney | it is | 12:31 |
sean-k-mooney | we also use those directly | 12:31 |
lyarwood | huh pip was fine without them | 12:31 |
sean-k-mooney | pip is but this is the requiremetns check job | 12:31 |
sean-k-mooney | we dont allow the min in requirements.txt to differ form lc by policy in openstack | 12:32 |
sean-k-mooney | and that job enforces that while also check the markers match what is in GR/UC | 12:32 |
lyarwood | *sigh* | 12:33 |
sean-k-mooney | lyarwood: the script that does this is in the requiremetns repo if i rememebr correctly its not in nova so you cant test this with tox in nova | 12:33 |
lyarwood | yeah just building the venv now | 12:33 |
sean-k-mooney | it wont see this error since this is not part of nova | 12:34 |
lyarwood | the requirements venv | 12:34 |
lyarwood | not nova | 12:34 |
sean-k-mooney | ah | 12:35 |
sean-k-mooney | anyway its a simple fix | 12:35 |
*** ociuhandu has joined #openstack-nova | 12:35 | |
sean-k-mooney | just update nova's requiremetns.txt | 12:35 |
sean-k-mooney | with the same min version you set in lc | 12:35 |
sean-k-mooney | you do not need to change anything in the requiremetns repo in case that is not obvious form the error | 12:36 |
lyarwood | it's obvious, I just wanted to run the same test locally | 12:37 |
lyarwood | from the requirements repo | 12:37 |
*** mkrai_ has quit IRC | 12:38 | |
ahsen | Hi, I'm getting an error while creating an instance. It says "Build of instance xxx aborted: Volume xxx did not finish being created even after we waited 188 seconds or 61 attempts. And its status is downloading." I did not get this error before and there is'nt any error on Cinder's logs. Do you have any idea why am I getting this error? How can I | 12:43 |
ahsen | increase waiting time or attemps? We are using Ussuri. Thank you. | 12:43 |
*** ociuhandu has quit IRC | 12:44 | |
lyarwood | ahsen: the retries and interval are controlled by CONF.block_device_allocate_retries and CONF.block_device_allocate_retries_interval on the Nova side | 12:46 |
lyarwood | ahsen: but you should trace the request through to the Cinder side to understand why it's taking so long | 12:46 |
sean-k-mooney | ahsen: is it a large image or are you using HDDs on the cinder side or low bandwith nics | 12:52 |
sean-k-mooney | ahsen: i had to set block_device_allocate_retries_interval=10 on my home cluster | 12:53 |
sean-k-mooney | the time it took for qemu image to copy the image data for larger images was taking just over 60 seconds and it was timing out | 12:53 |
ahsen | lyarwood Thank you, I will try to increase those values. And actually Cinder creates volumes but I don't know how long does it take | 12:54 |
*** links has quit IRC | 12:55 | |
sean-k-mooney | ahsen: if you look at teh cidner driver log you should see the qemu-img command doing the data transfer | 12:55 |
sean-k-mooney | ahsen: for me it only became a proable for images over about 5-8Gs | 12:55 |
ahsen | sean-k-mooney Image is not large and we are using SSD also bandwith is not low | 12:56 |
lyarwood | ahsen: kk, you should see a request-id logged by Nova from Cinder that you can use to grep through your logs | 12:57 |
sean-k-mooney | ok increasing the interval to 10 might help but you should look at the cidner logs and try and determin why its taking so long in that case | 12:57 |
sean-k-mooney | ahsen: what cinder backend are you using by the way | 12:58 |
ahsen | sean-k-mooney I will look at them | 12:58 |
openstackgerrit | Lee Yarwood proposed openstack/nova master: requirements.txt: Bump os-brick to 4.2.0 https://review.opendev.org/c/openstack/nova/+/778177 | 12:58 |
openstackgerrit | Lee Yarwood proposed openstack/nova master: hyper-v rbd volume support https://review.opendev.org/c/openstack/nova/+/763550 | 12:58 |
lyarwood | okay lets try this again | 12:58 |
ahsen | lyarwood and sean-k-mooney I will try what you said. Thank you both | 13:00 |
*** links has joined #openstack-nova | 13:04 | |
openstackgerrit | Merged openstack/nova master: libvirt: add AsyncDeviceEventsHandler https://review.opendev.org/c/openstack/nova/+/772381 | 13:11 |
lyarwood | stephenfin: https://review.opendev.org/c/openstack/nova/+/673790/14/nova/virt/libvirt/host.py@1244 - going to grab some lunch but let me know if that concern isn't clear still. | 13:26 |
*** ociuhandu has joined #openstack-nova | 13:27 | |
*** jangutter has joined #openstack-nova | 13:33 | |
*** jangutter_ has quit IRC | 13:37 | |
*** tbachman has quit IRC | 13:38 | |
*** tbachman has joined #openstack-nova | 13:40 | |
*** lbragstad_ is now known as lbragstad | 13:41 | |
openstackgerrit | Elod Illes proposed openstack/nova stable/ussuri: Fallback to same-cell resize with qos ports https://review.opendev.org/c/openstack/nova/+/773932 | 13:43 |
gmann | brinzhang0: sorry i was away yesterday. replied on https://review.opendev.org/c/openstack/nova/+/766726/ | 13:48 |
bauzas | gibi: dansmith: huzzah \o/ the Compute RPC API bump patch eventually got a +1 from Zuul https://review.opendev.org/c/openstack/nova/+/761452 | 13:57 |
*** mlavalle has joined #openstack-nova | 13:59 | |
bauzas | fwiw, the grenade multinode job helped to find an issue | 14:03 |
bauzas | + some functest related to numa live migration | 14:03 |
*** hemanth_n has quit IRC | 14:04 | |
gibi | bauzas: added the RPC bump to my review queue | 14:07 |
bauzas | gibi: I could split it by having two changes, one for the compute service manager and one for the compute client, but the existing change is quite simple to be reviewed | 14:11 |
gibi | thanks I will dig into it | 14:12 |
bauzas | gibi: I can help you to understand how this works | 14:15 |
sean-k-mooney | FYI we may need to rework how we do memory tracking to fix a previously unknow aspect of pci passhtough | 14:15 |
*** jangutter has quit IRC | 14:16 | |
bauzas | gibi: once you begin to look at the RPC API, ping me and I'll explain | 14:16 |
sean-k-mooney | ill try and file a bug for it when i have time but basically memory oversubsciption cant be done if you have pci passthough/sriov | 14:16 |
bauzas | gibi: tl;dr: I'm providing a 5.x proxy for supporting old clients | 14:16 |
sean-k-mooney | it might also affect vgpu | 14:16 |
*** jangutter has joined #openstack-nova | 14:16 | |
bauzas | sean-k-mooney: ack | 14:16 |
bauzas | sean-k-mooney: vgpu or gpu ? | 14:17 |
sean-k-mooney | both | 14:17 |
bauzas | why ? | 14:17 |
sean-k-mooney | we will have to verify it | 14:17 |
bauzas | b/c vgpu is different from pci passthrough and sriov | 14:17 |
sean-k-mooney | bauzas: libivrt is locking the guest memory pages whenever we use pci passthoug | 14:17 |
sean-k-mooney | it may or may not be doing the same for vgpu | 14:17 |
bauzas | ah | 14:17 |
bauzas | test it then, yes | 14:18 |
bauzas | and like I discussed with you, I'd also like to work on pci attach/detach | 14:18 |
sean-k-mooney | generic attach ya | 14:18 |
sean-k-mooney | this came up in a call i had this morining for vdpa when i was trying to dig into why it needed the memory to be locked explictly | 14:19 |
sean-k-mooney | for vdpa libvirt does not do it implcitly which is why i got dma error | 14:19 |
sean-k-mooney | so i have not actully avalidated it myself yet | 14:20 |
sean-k-mooney | once i do ill try and write up my findings | 14:20 |
sean-k-mooney | im not sure ill have time to try and validate vgpu but when i fiture out how to check if teh vm memory is locked maybe you can try? | 14:21 |
*** spatel has joined #openstack-nova | 14:24 | |
bauzas | sean-k-mooney: sure, I can try to get some vgpu environment (hopefully) | 14:28 |
*** jawad_axd has quit IRC | 14:31 | |
*** jawad_axd has joined #openstack-nova | 14:32 | |
*** Luzi has quit IRC | 14:36 | |
*** jangutter_ has joined #openstack-nova | 14:38 | |
*** jangutter has quit IRC | 14:41 | |
sean-k-mooney | vgpus dont work with ubuntu hosts correct at leat not the nvida version? | 15:00 |
*** spatel has quit IRC | 15:00 | |
sean-k-mooney | actully im using teh mainline 5.11 kernel so never mind it wont install on my host anyway | 15:00 |
sean-k-mooney | the vdpa host im using also has a t4 but i dont really have a way to test it there | 15:01 |
*** spatel has joined #openstack-nova | 15:02 | |
bauzas | sean-k-mooney: no, ubuntu is not supported by nvidia drivers but you can use intel gvt-g if you really want to test vgpus | 15:02 |
*** links has quit IRC | 15:02 | |
bauzas | and a i915 host if you have one by hand | 15:02 |
sean-k-mooney | i was just wondering if the host i have would work or not. am maybe my laptop i could test with libvirt directly i guess | 15:03 |
bauzas | that's what I did for i915 | 15:03 |
bauzas | I just used an old laptop for testing | 15:03 |
sean-k-mooney | it wont happen in the next 2 weeks so we can figure it out later. | 15:03 |
bauzas | that's actually the problem with gvt-g, you can't find good intel cards that are for production | 15:04 |
bauzas | all the i915 cards are for desktop lines | 15:04 |
bauzas | but hopefully, ROCI will help us | 15:05 |
sean-k-mooney | yes they removed integrated grapshic for the server line when they added it | 15:05 |
sean-k-mooney | im hoping that the new descreet intel gpus will support it | 15:05 |
bauzas | fwiw, devstack on rhel works okay to me | 15:05 |
bauzas | but you'd need to run another env | 15:05 |
sean-k-mooney | i need a newer kernel for the vdpa work so rhel was not an option | 15:06 |
*** links has joined #openstack-nova | 15:06 | |
sean-k-mooney | it does not have the vendor driver | 15:06 |
sean-k-mooney | 8.4 might but not 8.3 or even centos stream | 15:06 |
sean-k-mooney | thats why im using the mainline 5.11 kernel for development | 15:07 |
bauzas | ha | 15:08 |
bauzas | and what about fedora ? | 15:08 |
bauzas | in theory, nvidia RPMs should work but I never tested them | 15:08 |
sean-k-mooney | it has python 3.9 which breaks eventlests and openstack in general | 15:08 |
bauzas | the dependency saga. | 15:09 |
sean-k-mooney | i had to use ubuntu 20.10 as it was the only os i could fined with precomipled libvit/qemu new enough and had access to the mainlin kernel and python 3.8 | 15:09 |
sean-k-mooney | although i ended up compiling qemu form souce anyway due to a driver bug | 15:10 |
*** mkrai has joined #openstack-nova | 15:11 | |
sean-k-mooney | but ya dependicies for really new hardware features is a pain. | 15:11 |
* sean-k-mooney is happing i spend the time to write https://opendev.org/x/devstack-plugin-libvirt-qemu years ago. i need to fix it or ubuntu 20.04 and i can proably drop the centos 6 support but its still helped alot even if i had to use it manully | 15:13 | |
sean-k-mooney | * happy | 15:13 |
*** jawad_axd has quit IRC | 15:15 | |
*** jawad_axd has joined #openstack-nova | 15:16 | |
*** macz_ has joined #openstack-nova | 15:19 | |
*** jawad_axd has quit IRC | 15:24 | |
*** zenkuro has quit IRC | 15:27 | |
*** lpetrut has quit IRC | 15:34 | |
*** openstackgerrit has quit IRC | 15:35 | |
sean-k-mooney | bauzas: it look like they might have been wrong. libvirt is provide qemu the capablity to lock memory but it does not look like its using it | 15:41 |
kashyap | gibi: artom: When you get a min, I think I've addressed all the pressing concerns: https://review.opendev.org/c/openstack/nova/+/774240 | 15:42 |
gibi | kashyap: ack, I will check back | 15:43 |
kashyap | Thanks; see the small change log for PS10 ["Mar 01 12:54 PM"] -- the only diff in PS11 is to put back the line that I accidentally removed during rebase. | 15:44 |
*** ahsen has quit IRC | 15:45 | |
*** mkrai has quit IRC | 15:57 | |
*** dklyle has joined #openstack-nova | 16:02 | |
*** links has quit IRC | 16:12 | |
*** dviroel has quit IRC | 16:34 | |
gibi | bauzas: I left some questions in the RPC bump series https://review.opendev.org/c/openstack/nova/+/761452 but overall the patch looks good to me | 16:34 |
bauzas | thanks for the review, /me looks | 16:35 |
bauzas | gibi: tbc, we need to hold this change until FF | 16:35 |
gibi | bauzas: is there any RPC impacting change open I should be aware of? | 16:35 |
bauzas | but the more we review, the quickier we could merge it just after m-3 | 16:35 |
bauzas | gibi: some compute service bumps AFAIK | 16:35 |
gibi | true, service version will be in conflict if we merge those | 16:36 |
bauzas | https://review.opendev.org/c/openstack/nova/+/761452 has a lot of merge conflicts | 16:36 |
bauzas | so I'm prepared to rebase this change | 16:36 |
gibi | bauzas: ack. I will prioritize to land this after FF | 16:37 |
gibi | but we might get FFE requests | 16:37 |
gibi | with service bumps | 16:37 |
gibi | so it will be a tricky balance | 16:37 |
gibi | anyhow we have to be strict with FFEs due to sortness of time til RC1 | 16:38 |
gibi | brinzhang0: could you please check what would be the good accel_uuid paramter here https://review.opendev.org/c/openstack/nova/+/761452/9/nova/compute/manager.py#9481 ? | 16:38 |
bauzas | gibi: what we could discuss is whether this parameter should be mandatory | 16:40 |
sean-k-mooney | gibi: ya with one week i would say we likely dont have time in most case | 16:40 |
bauzas | same for all the other methods like rebuild | 16:40 |
gibi | bauzas: I think it should be mandatory as the impl uses accel_uuids to support cyborg devices, so if accel_uuids param is not passed then we loose cyborg supprot | 16:41 |
gibi | suport | 16:42 |
gibi | support even | 16:42 |
gibi | sean-k-mooney: yeah | 16:42 |
gibi | sean-k-mooney: we have two week between FF (Mar12) and the lat possible date of RC1 Mar26 | 16:42 |
gibi | I mean FF mar11 | 16:43 |
gibi | for nova | 16:43 |
sean-k-mooney | gibi: the only reservatio ni would have for makign it mandatory is that not all driver need it or will support cyborg | 16:43 |
sean-k-mooney | but other then that ya it could be | 16:43 |
bauzas | gibi: yeah for sure | 16:43 |
bauzas | gibi: we actually pass the parameter everytime now | 16:43 |
gibi | it is the compute manager interface not the virt driver interface | 16:43 |
bauzas | if so, it's mandatory | 16:43 |
bauzas | but if we don't, then it should continue to be optional | 16:44 |
sean-k-mooney | gibi: oh i though rc1 was the 18 cool still tight | 16:44 |
bauzas | sean-k-mooney: am i right? | 16:44 |
sean-k-mooney | bauzas: when working with cyborg instace we need to pass it | 16:44 |
sean-k-mooney | but for none cycboge isntace its not needed | 16:44 |
bauzas | sean-k-mooney: the question is, do we pass them everytime even without cyborg ? | 16:44 |
gibi | bauzas: I also think that we pass accel_uuids now via the RPC. if this is not a cyborg intance then we pass [] I hope | 16:45 |
bauzas | sean-k-mooney: meaning we could pass an empty list | 16:45 |
sean-k-mooney | we can pass an empty list yes | 16:45 |
bauzas | but we could have made it optional | 16:45 |
bauzas | instead of an empty list | 16:45 |
sean-k-mooney | we cant make kwards defualt to empty list | 16:45 |
bauzas | like, you don't use cyborg, accel_uuids be None | 16:46 |
sean-k-mooney | but we could default to None | 16:46 |
sean-k-mooney | and then pass [] if its none | 16:46 |
bauzas | and if so, the RPC 6.0 version should continue to support None | 16:46 |
bauzas | but afaicu, we pass [] | 16:46 |
bauzas | so now, it's mandatory | 16:46 |
bauzas | I mean, the parameter is passed | 16:46 |
bauzas | every time | 16:46 |
bauzas | even if 99% of the time the value is an empty list | 16:47 |
bauzas | that's sad | 16:47 |
sean-k-mooney | i honestly dont recall what i did orginally but i proably passed an empty list | 16:47 |
bauzas | dansmith: thoughts on it ? | 16:47 |
bauzas | dansmith: I recall you reviewed the cyborg patches | 16:47 |
gibi | it is empty list in the cases I now checked | 16:47 |
bauzas | ok, then we need to make the parameter mandatory | 16:48 |
gibi | and you did that | 16:48 |
bauzas | yup | 16:48 |
bauzas | but that's sad | 16:48 |
bauzas | in particular for the boot case | 16:48 |
bauzas | I would have preferred to have this parameter be optional | 16:48 |
sean-k-mooney | actully i think we pass None though most of the calls | 16:49 |
sean-k-mooney | not [] | 16:49 |
*** nightmare_unreal has quit IRC | 16:49 | |
bauzas | but the ship is sailed | 16:49 |
bauzas | has* sailed | 16:49 |
gibi | sean-k-mooney: hm, _create_and_bind_arqs and get_arq_uuids_for_instance returns [] | 16:49 |
dansmith | bauzas: just skimming the scrollback... the question is what the *client* should do, right? | 16:49 |
bauzas | sean-k-mooney: to be clear, do we pass the argument with a None value in it, or do we just call the API without this arg ? | 16:49 |
bauzas | dansmith: the question is, should we make accel_uuids mandatory (I did this, but this is terrible) | 16:50 |
dansmith | ideally, all RPC parameters for matching client/server would be passed, either None or [] depending, but never missing for a given version that supports it | 16:50 |
dansmith | bauzas: right but mandatory where, client or server? | 16:50 |
bauzas | server | 16:50 |
dansmith | it should be mandatory that it is passed over the wire, yes | 16:50 |
bauzas | that's my point | 16:50 |
bauzas | we could have make it optional | 16:51 |
dansmith | the client should always pass it, but the client's own python API can make it optional for the rest of the code if we want, just for convenience | 16:51 |
bauzas | but looks like we didn't | 16:51 |
sean-k-mooney | the server side in teh compute manager seam to use None so i guess the rpcapi is what we need to check or the compute api | 16:51 |
dansmith | really? | 16:51 |
sean-k-mooney | thats using [] | 16:51 |
sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4192 | 16:51 |
dansmith | either way, 6.0 not landed yet, so we can make it mandatory in 6.0 and correct that problem | 16:51 |
bauzas | we default to a empty list | 16:52 |
bauzas | and we pass the parameter anyway | 16:52 |
bauzas | which makes this argument mandatory from a manager perspective IIUC | 16:52 |
dansmith | since 5.x people can't talk to 6.0 anyway, and then the 5.x proxy can tolerate it being missing | 16:52 |
sean-k-mooney | ya so form the compute manager/driver point of view it hink it will happly use [] or None and treat it the same | 16:52 |
sean-k-mooney | if you really think [] is too much overhead vs None you could proably change it in 6.0 but im not sure it gets us much | 16:53 |
bauzas | mmm | 16:54 |
bauzas | I'm confused | 16:54 |
dansmith | whether it's [] or None doesn't really matter much, but I expect [] makes more sense | 16:54 |
gibi | ^^ agree | 16:54 |
bauzas | before this change, we were having accel_uuids be None | 16:55 |
bauzas | hence be optional | 16:55 |
sean-k-mooney | ya we just cant uses [] for the default in a kwarg | 16:55 |
bauzas | but this was just for compat reasonqs | 16:55 |
gibi | bauzas: only for the case when the client did not sent the param accel_uuids | 16:55 |
sean-k-mooney | because only one list would be created and shared between all calls | 16:55 |
bauzas | gibi: correct | 16:55 |
bauzas | gibi: so, a recent client was *always* passing an empty list | 16:55 |
sean-k-mooney | that why we use None in the compute manager but always pass [] or a populated list | 16:55 |
gibi | sean-k-mooney: we are not defaulting anyting to [], the client sends a list either empty or non empty | 16:56 |
bauzas | well, a recent client is *always* passing accel_uuids as a param, tbc | 16:56 |
sean-k-mooney | gibi: correct | 16:56 |
gibi | OK, we are in violent agreement then :) | 16:56 |
bauzas | ok, so let's leave it mandatory | 16:56 |
gibi | yepp | 16:56 |
bauzas | sad but ok | 16:56 |
dansmith | the reason I think [] makes more sense than explicitly passing None is that the latter is the only indication we have that it wasn't passed, which in the past was important for knowing "does the client even know about accel_uuids" in terms of compat behavior | 16:56 |
dansmith | but going forward, I think it should be mandatory for sure, and ideally [] if no accel_uuids | 16:57 |
bauzas | I agree, it was the usual signal for knowing whether the client was new enoguh | 16:57 |
dansmith | yeah | 16:57 |
bauzas | but we also have optional args | 16:57 |
dansmith | ideally we shouldn't | 16:57 |
bauzas | because the RPC signature can change ? | 16:58 |
bauzas | I think I get you | 16:58 |
sean-k-mooney | dansmith: true although i dont think we relay on that distiction anywhere today but its a valid reason. i take a different appoch and say well the data stucture should be a list so pass an empty one in preference to None | 16:58 |
bauzas | either way, let's stick with it then | 16:58 |
bauzas | gibi: I'll reply to your comments | 16:58 |
gibi | cool | 16:58 |
gibi | I will check back tomorro | 16:58 |
gibi | w | 16:58 |
dansmith | sean-k-mooney: yeah, it's explicit vs. implicit | 16:59 |
*** zoharm has quit IRC | 17:04 | |
*** lucasagomes has quit IRC | 17:06 | |
gibi | artom, stephenfin, kashyap: Do we have an agreement on the extra config option vs. +/- prefix in https://review.opendev.org/c/openstack/nova/+/774240/ ? | 17:08 |
*** ociuhandu_ has joined #openstack-nova | 17:09 | |
*** ociuhandu has quit IRC | 17:12 | |
stephenfin | I would still rather separate config opts since that seems clearer and less "unique" to me. I would appreciate other perspectives, though it's definitely into bikeshedding territory | 17:13 |
*** ociuhandu_ has quit IRC | 17:13 | |
gibi | I can work with both but I do understand the uniqueness of the prefix based approach | 17:13 |
bauzas | stephenfin: dansmith: worth removing this argument now I'm bumping the RPC API ? https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5311 | 17:14 |
gibi | I cannot recall if we discussed this during the meeting when we approved the bp | 17:14 |
bauzas | I mean, in https://review.opendev.org/c/openstack/nova/+/761452 | 17:14 |
artom | stephenfin, gibi, I don't really care, tbh - stephenfin's idea feels more rigorously correct, but the current +/- approach does have the "way less work" argument on its side | 17:14 |
* bauzas does a quick look at all the comments for 6.0 | 17:15 | |
artom | And it's not like +/- is super complex to understand. | 17:15 |
bauzas | stephenfin: dansmith: but I'm fine with punting this for a later minor bump, like 6.1 | 17:15 |
dansmith | bauzas: you can't drop a param in 6.1 :) | 17:15 |
artom | I'd be more inclined to go stephenfin's route if the alternative was edging into DSL territory, which it definitely isn't | 17:15 |
bauzas | oh shit | 17:15 |
bauzas | you're right | 17:16 |
bauzas | dansmith: worth the effort then ? | 17:16 |
stephenfin | No, it's not. It just feels a bit weird. I think I'd even be happier if we had a path to not supporting unprefixed opts | 17:16 |
dansmith | bauzas: yep, else you wait until 7.0 and those cleanups are the whole point of this | 17:16 |
bauzas | dansmith: my only concern is that we're passing this argument everytime now | 17:16 |
stephenfin | gibi: If you don't particularly care, I can drop my complaint. I don't want to have to rework the patch so something is better than nothing | 17:17 |
bauzas | it's just the manager which doesn't use it | 17:17 |
gibi | kashyap, stephenfin, artom: so the prefix based solution was raised during the meeting http://eavesdrop.openstack.org/meetings/nova/2021/nova.2021-02-11-16.00.log.html#l-148 | 17:17 |
gibi | and there was no objection then | 17:17 |
dansmith | bauzas: no we're not, because 6.0 hasn't landed yet and YOU are defining its behavior :) | 17:17 |
bauzas | but I'm lazy | 17:17 |
bauzas | :p | 17:17 |
dansmith | bauzas: well, that may be :) | 17:17 |
stephenfin | gibi: yeah, my lack of objections was to the general idea of disabling features rather than how we'd do it (I'd already zoned out by then, as kashyap thought we might have :)) | 17:18 |
artom | gibi, ah, last week when I was on PTO? :) | 17:18 |
bauzas | dansmith: I mean, I would have appreciated if someone (like stephenfin :p ) would have stopped to provide this arg by the client | 17:18 |
bauzas | client isez | 17:18 |
bauzas | side | 17:18 |
bauzas | now, we're passing it over the wire | 17:18 |
bauzas | so we could pretend we never did | 17:18 |
dansmith | bauzas: in 5.x | 17:18 |
bauzas | yup | 17:19 |
dansmith | but not in 6.x | 17:19 |
gibi | artom: you were present on that meeting :) | 17:19 |
bauzas | dansmith: right, making it optional | 17:19 |
bauzas | on the client | 17:19 |
artom | gibi, oh, hah :P | 17:19 |
gibi | but good try :P | 17:19 |
artom | Clearly shows how much I care | 17:19 |
bauzas | dansmith: but of course, still mandatory on the server until 6.0 | 17:19 |
artom | Genuinely, we could go either way and I'll sleep perfectly well that night | 17:19 |
gibi | OK, let's go with the proposed implementation. as I don't see it as a dealbreaker | 17:20 |
gibi | I'm upgrading my vote on the patch | 17:20 |
dansmith | gibi: it shouldn't even be optional on the client for 6.0 right? | 17:21 |
stephenfin | cool, I'll take a look tomorrow | 17:21 |
gibi | stephenfin: thanks | 17:21 |
stephenfin | still working through the VNC fun | 17:21 |
stephenfin | it's a pain in the a*** :) | 17:21 |
gibi | dansmith: logically accel_uuids are a part of the client code, we do gather them from the flavor and from cyborg. So I think it should be mandatory on the client side as well | 17:22 |
dansmith | oops s/gibi/bauzas/ above | 17:22 |
dansmith | gibi: that comment was about request_spec, not accel_uuids | 17:23 |
gibi | aah | 17:23 |
gibi | then ignore me | 17:23 |
dansmith | gibi: I confused you by replying to you instead of bauzas | 17:23 |
gibi | sorry | 17:23 |
bauzas | dansmith: right | 17:23 |
* dansmith is in two active convos atm :) | 17:23 | |
bauzas | OK, looks like I have work to do | 17:23 |
*** lpetrut has joined #openstack-nova | 17:28 | |
bauzas | honestly, since this request_spec argument isn't deprecated yet in some 5.x API, removing it now would make 6.0 semantically different from 5.13 | 17:28 |
bauzas | so I won't do it, unless someone steps up and write a 5.x version for making it deprecated | 17:28 |
bauzas | stephenfin: ^ | 17:28 |
bauzas | we lost some opportunity here | 17:29 |
stephenfin | I haven't been following, I'm afraid :( We're passing an unnecessary argument through to some RPC API? | 17:30 |
sean-k-mooney | bauzas: how would we get the request_spec if we dont pass it? via the instance? | 17:34 |
sean-k-mooney | i dont think we want to lazy load that if its currently used | 17:35 |
bauzas | sean-k-mooney: stephenfin's point is that we don't use this parameter even if we pass it thru the wire | 17:35 |
sean-k-mooney | for which api call | 17:35 |
bauzas | and we have a few other methods that have some parameters passed thru the wire that we don't use | 17:35 |
sean-k-mooney | right so those whould have to be removed in 6.0 | 17:36 |
bauzas | you know what ? I'm changing the docstring to be 7.0 | 17:36 |
bauzas | and we know we have to write some 6.x API version that would deprecate those parameters | 17:36 |
sean-k-mooney | do we have to do deprecations like that for internal rpc apis? | 17:37 |
bauzas | honestly, now I wrote a 6.0 bump, I feel brave enough for writing a 7.0 one | 17:37 |
bauzas | but this will have to be at least for X, ideally Y | 17:37 |
sean-k-mooney | bauzas: well we likely wont do a 7.0 bump for another couple of releases | 17:37 |
bauzas | yes | 17:37 |
bauzas | I know | 17:37 |
sean-k-mooney | proably not before Z | 17:38 |
sean-k-mooney | i mean there is not strict rule but we have mostly wated 4-6 release between major bumps | 17:38 |
bauzas | sure, but at least we should stop passing those over the wire if we don't need them | 17:38 |
bauzas | no | 17:38 |
bauzas | sean-k-mooney: we released major RPC versions more often in the past | 17:38 |
bauzas | Kilo, Mitaka, Queens | 17:39 |
bauzas | and now Wallaby | 17:39 |
sean-k-mooney | right which is why i said there was no rule that we cant do it more often | 17:39 |
sean-k-mooney | but we avoid it unless it buys use a lot | 17:40 |
bauzas | sure, but my concern is to make sure that if we don't need them, we should stop passing them by the client | 17:40 |
bauzas | hence a 6.x release for stopping this | 17:40 |
bauzas | and later, a 7.0 for removing | 17:40 |
sean-k-mooney | with that said not that we enforce the min compute version on startup there is less utility in keeping a major version for a long time | 17:40 |
*** rpittau is now known as rpittau|afk | 17:42 | |
bauzas | sean-k-mooney: again, stop thinking about the next major RPC release | 17:42 |
bauzas | sean-k-mooney: just a single minor version for stopping to emit this param and I'll be happy | 17:43 |
sean-k-mooney | sure but to do that you need to make them optional parmaters right | 17:43 |
sean-k-mooney | and then just stop setting them | 17:43 |
sean-k-mooney | so you need to prepare for it in the 6.0 version | 17:44 |
sean-k-mooney | unless you were planning to keep them mandatoy and have the clinet hardcode None or something? | 17:45 |
sean-k-mooney | i dont think i have review a patch were we actully droped parmaters. i know matt did it before but im not sure what the process is | 17:47 |
*** bnemec has quit IRC | 17:49 | |
sean-k-mooney | https://github.com/openstack/nova/commit/a761e57368280b6d3e931831ecd393fd5787b3ef dropped the compat code for 4.x but the parmaters i think were doped in teh 5.0 bump that added the 4.x proxy | 17:54 |
sean-k-mooney | https://github.com/openstack/nova/commit/eae37a27caa5ca8b0ca50187928bde81f28a24e1#diff-91f79786d7e3744c39926c88bbafe3b727630fa4eb48e845686d7f12f876d067L531 | 17:54 |
*** derekh has quit IRC | 18:01 | |
*** tobias-urdin has quit IRC | 18:02 | |
*** openstackgerrit has joined #openstack-nova | 18:05 | |
openstackgerrit | Merged openstack/nova master: Docs: Correct ``Password injection using the dashboard`` Explanation https://review.opendev.org/c/openstack/nova/+/775084 | 18:05 |
*** lpetrut has quit IRC | 18:07 | |
dansmith | sean-k-mooney: we only ever drop params in a major bump, and all such bumps have dropped parameters, AFAIR | 18:09 |
dansmith | sean-k-mooney: you need to continue to honor them for N-1.x compatibility in that shim, but the N.0 client and server can assume everything is always passed and expected at the new signatures you want going forward | 18:10 |
sean-k-mooney | dansmith: yes that is what i understood too | 18:11 |
dansmith | ack | 18:11 |
dansmith | bauzas: to be clear, we do not need to do any sort of "deprecate in 6.x and remove in 7.0" dance for _anything_. We're the only consumer of this API, so we only need to make sure we honor our own rules.. | 18:15 |
dansmith | The entire 5.x lineage is adding things to the API as optional, to be made mandatory in 6.0, and ignoring things we plan to drop in 6.0 | 18:16 |
dansmith | so all you need to do is support 5.max and 6.0 in both the client and server, and the only thing that you can't do is break 5.max.. 6.0 could be anything else you want if you're willing to make the changes | 18:16 |
*** bnemec has joined #openstack-nova | 18:16 | |
bauzas | dansmith: ok, I'll see what I can do | 18:19 |
bauzas | the 6.0 bump already has a long list of changed things | 18:19 |
bauzas | and I'm just about cleaning it more | 18:19 |
bauzas | I'm the janitor and it's a mess | 18:19 |
dansmith | that's the whole point of a major bump though | 18:19 |
bauzas | I don't disagree | 18:20 |
dansmith | it's both why we should maybe do it more frequently, and also why we don't :) | 18:20 |
bauzas | I'm just afraid by the timings here | 18:20 |
bauzas | and the review steam | 18:20 |
dansmith | yup, it's hard, and why we've been talking about it for a cycle :) | 18:21 |
bauzas | Zuul eventually gave me its blessing after a long period of doubt | 18:21 |
bauzas | and I'm just removing extra other bits | 18:22 |
bauzas | but OK, I can try | 18:24 |
*** ralonsoh has quit IRC | 18:29 | |
*** k_mouza has quit IRC | 18:36 | |
*** k_mouza_ has joined #openstack-nova | 18:36 | |
*** andrewbonney has quit IRC | 18:38 | |
*** hamalq has joined #openstack-nova | 18:38 | |
*** xek has quit IRC | 18:39 | |
openstackgerrit | Stephen Finucane proposed openstack/python-novaclient master: WIP: Add support for setting VNC password https://review.opendev.org/c/openstack/python-novaclient/+/778229 | 18:43 |
stephenfin | melwitt: More comments on https://review.opendev.org/c/openstack/nova/+/622336 | 18:45 |
stephenfin | I'm so confused about what's doing what | 18:45 |
*** xek has joined #openstack-nova | 18:47 | |
*** xek has quit IRC | 18:47 | |
stephenfin | melwitt: At present, it seems totally broken but there's a good chance I'm misunderstanding something. If so, or if I'm saying daft things, please let me know :) | 18:48 |
bauzas | dansmith: around ? I'm facing some concern about https://review.opendev.org/c/openstack/nova/+/761452/9/nova/tests/functional/libvirt/test_numa_live_migration.py | 18:55 |
bauzas | since we upgraded to 6.0, now the version_cap is defaulted to 6.0 | 18:56 |
bauzas | and then can_send_version() can only support 6.0 | 18:56 |
bauzas | while previously with 5.13, can_support_version was accepting 5.3 | 18:57 |
bauzas | even if the version cap was 5.13 | 18:57 |
bauzas | what should I do ? stick with what I wrote, or stub the RPC API for a 5.13 version cap ? | 18:57 |
bauzas | (even if we don't pin) | 18:58 |
bauzas | this whole testclass is so tangled with RPC versioning that we should consider axing a lot of them later on | 18:58 |
bauzas | but I just want to pass the bar here | 18:58 |
bauzas | and not do unnecessary scrubbing | 18:59 |
bauzas | actually, I need to eat by now | 19:02 |
*** k_mouza_ has quit IRC | 19:04 | |
*** k_mouza has joined #openstack-nova | 19:05 | |
openstackgerrit | Sylvain Bauza proposed openstack/nova master: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452 | 19:16 |
*** k_mouza has quit IRC | 19:29 | |
openstackgerrit | Merged openstack/nova master: libvirt: allow querying devices from the persistent domain https://review.opendev.org/c/openstack/nova/+/772383 | 19:41 |
*** tbachman has quit IRC | 19:44 | |
*** tbachman has joined #openstack-nova | 19:53 | |
dansmith | bauzas: I think those tests were doing exactly what they needed, and I remember all the work artom did to make them validate all the upgrade concerns | 20:18 |
dansmith | bauzas: I think a lot of the concern there goes away with 6.0, but it might be best to pin them to their original versions (i.e. pretend they're running in an upgrade scenario) until we can drop 5.x | 20:19 |
bauzas | so, which option would you prefer ? | 20:19 |
bauzas | scenario 2 in my comment, ie. capping to 5.13 ? | 20:20 |
bauzas | dansmith: ^ | 20:20 |
bauzas | or scenario 1, leave as it is | 20:20 |
bauzas | from what I understand you, looks like you prefer scenario #2 | 20:20 |
*** spatel has quit IRC | 20:25 | |
*** Underknowledge has quit IRC | 20:26 | |
*** Underknowledge has joined #openstack-nova | 20:26 | |
dansmith | bauzas: commented | 20:35 |
bauzas | ta, will look | 20:36 |
bauzas | dansmith: ok thanks, will then pin to 5.13 | 20:39 |
dansmith | cool | 20:39 |
* bauzas just works at the unnecessary parameters removal | 20:40 | |
*** dviroel has joined #openstack-nova | 20:55 | |
*** abhishekk has quit IRC | 21:06 | |
*** bhagyashri|rover has quit IRC | 21:06 | |
*** abhishekk has joined #openstack-nova | 21:06 | |
*** bhagyashris has joined #openstack-nova | 21:07 | |
*** hoonetorg has quit IRC | 21:21 | |
*** belmoreira has quit IRC | 21:24 | |
* bauzas stops for the night, will continue on the RPC bump tomorrow morning | 21:27 | |
bauzas | g'night | 21:27 |
*** k_mouza has joined #openstack-nova | 21:29 | |
*** k_mouza has quit IRC | 21:34 | |
*** belmoreira has joined #openstack-nova | 21:37 | |
*** hoonetorg has joined #openstack-nova | 21:42 | |
openstackgerrit | Merged openstack/nova master: apidb: Compact Newton database migrations https://review.opendev.org/c/openstack/nova/+/759401 | 21:43 |
*** gyee has joined #openstack-nova | 21:43 | |
*** brinzhang0 has quit IRC | 21:47 | |
*** belmoreira has quit IRC | 22:23 | |
*** rcernin has joined #openstack-nova | 22:33 | |
*** vishalmanchanda has quit IRC | 22:54 | |
*** pmannidi has joined #openstack-nova | 23:07 | |
*** pmannidi_ has quit IRC | 23:08 | |
*** zzzeek has quit IRC | 23:13 | |
*** zzzeek has joined #openstack-nova | 23:17 | |
*** k_mouza has joined #openstack-nova | 23:30 | |
*** k_mouza has quit IRC | 23:34 | |
*** luksky has quit IRC | 23:35 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!