Tuesday, 2021-03-02

*** tbachman has joined #openstack-nova00:03
*** macz_ has quit IRC00:06
*** luksky has quit IRC00:14
*** osmanlicilegi has joined #openstack-nova00:16
*** gibi has joined #openstack-nova00:17
*** tosky has quit IRC00:17
*** k_mouza has joined #openstack-nova00:21
*** k_mouza has quit IRC00:25
*** jamesdenton has quit IRC00:26
*** jamesden_ has joined #openstack-nova00:27
*** martinkennelly has quit IRC00:32
*** martinkennelly has joined #openstack-nova00:36
*** hamalq has quit IRC00:41
*** martinkennelly has quit IRC00:46
*** martinkennelly has joined #openstack-nova00:47
openstackgerritMerged openstack/nova master: libvirt: Define and emit DeviceRemovedEvent and DeviceRemovalFailedEvent  https://review.opendev.org/c/openstack/nova/+/74992900:53
*** martinkennelly has quit IRC00:55
*** martinkennelly has joined #openstack-nova00:56
*** iurygregory has quit IRC01:07
*** mlavalle has quit IRC01:14
*** hemanth_n has joined #openstack-nova01:25
*** iurygregory has joined #openstack-nova01:30
*** zzzeek has quit IRC01:49
*** zzzeek has joined #openstack-nova01:51
*** martinkennelly has quit IRC01:57
openstackgerritWenping Song proposed openstack/nova master: Nova supports password encrypted VNC  https://review.opendev.org/c/openstack/nova/+/62233602:03
openstackgerritMerged openstack/nova master: libvirt: Remove dead code  https://review.opendev.org/c/openstack/nova/+/77292802:06
openstackgerritMerged openstack/nova master: rpc: Rework 'get_notifier', 'wrap_exception'  https://review.opendev.org/c/openstack/nova/+/74166302:17
*** rcernin has quit IRC02:34
*** zenkuro has quit IRC02:36
*** rcernin has joined #openstack-nova02:47
*** jkulik has quit IRC03:03
*** spatel has joined #openstack-nova03:03
*** jkulik has joined #openstack-nova03:14
*** mkrai has joined #openstack-nova03:16
*** spatel has quit IRC03:22
*** jamesden_ is now known as jamesdenton03:29
*** vishalmanchanda has joined #openstack-nova03:45
*** psachin has joined #openstack-nova03:47
*** LinPeiWen has joined #openstack-nova04:16
*** zzzeek has quit IRC04:32
*** zzzeek has joined #openstack-nova04:33
*** zul has quit IRC04:53
*** whoami-rajat_ has joined #openstack-nova05:25
*** brinzhang_ has quit IRC06:01
*** brinzhang_ has joined #openstack-nova06:01
*** khomesh24 has joined #openstack-nova06:03
*** lbragstad_ has joined #openstack-nova06:03
*** lbragstad has quit IRC06:06
*** zzzeek has quit IRC06:10
*** zzzeek has joined #openstack-nova06:11
*** k_mouza has joined #openstack-nova06:21
*** k_mouza has quit IRC06:25
*** tbachman has quit IRC06:28
*** tbachman has joined #openstack-nova06:28
*** gyee has quit IRC06:47
*** whoami-rajat_ is now known as whoami-rajat06:54
*** ralonsoh has joined #openstack-nova06:55
*** rcernin has quit IRC06:57
*** slaweq has joined #openstack-nova07:08
*** jawad_axd has joined #openstack-nova07:25
openstackgerritYongli He proposed openstack/nova master: Smartnic support - cyborg drive  https://review.opendev.org/c/openstack/nova/+/77136207:25
openstackgerritYongli He proposed openstack/nova master: smartnic support - new vnic type  https://review.opendev.org/c/openstack/nova/+/77136307:25
openstackgerritYongli He proposed openstack/nova master: smartnic support  https://review.opendev.org/c/openstack/nova/+/75894407:25
*** lpetrut has joined #openstack-nova07:27
openstackgerritYongli He proposed openstack/nova master: smartnic support  https://review.opendev.org/c/openstack/nova/+/75894407:40
*** dklyle has quit IRC07:47
*** links has joined #openstack-nova07:51
*** belmoreira has joined #openstack-nova07:55
*** andrewbonney has joined #openstack-nova07:58
openstackgerritYongli He proposed openstack/nova master: Smartnic support - cyborg drive  https://review.opendev.org/c/openstack/nova/+/77136208:03
openstackgerritYongli He proposed openstack/nova master: smartnic support - new vnic type  https://review.opendev.org/c/openstack/nova/+/77136308:03
openstackgerritYongli He proposed openstack/nova master: smartnic support  https://review.opendev.org/c/openstack/nova/+/75894408:03
*** khomesh24 has quit IRC08:05
*** khomesh24 has joined #openstack-nova08:06
*** alex_xu has joined #openstack-nova08:07
yonglihegibi:  alex_xu:  i still own alex_xu 2 more check in code, everything else done.08:08
*** luksky has joined #openstack-nova08:14
*** mkrai has quit IRC08:18
*** mkrai has joined #openstack-nova08:18
*** rpittau|afk is now known as rpittau08:22
*** xek has joined #openstack-nova08:24
gibisean-k-mooney: sure I will do a doodle poll similar to previous PTGs08:25
gibiyonglihe: ack08:25
*** tosky has joined #openstack-nova08:35
*** ociuhandu has joined #openstack-nova08:44
*** martinkennelly has joined #openstack-nova08:50
*** jamesdenton has quit IRC08:56
*** jamesdenton has joined #openstack-nova08:57
*** lucasagomes has joined #openstack-nova09:01
*** songwenping_ has quit IRC09:07
* bauzas fights with live migration <309:09
bauzascan someone know how I could reproduce locally the tox lower-constraints job ?09:10
bauzascontext : https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_f69/761452/8/check/openstack-tox-lower-constraints/f699784/testr_results.html09:11
*** songwenping_ has joined #openstack-nova09:12
bauzasmmmm, there is a l-c tox target with not using use_develop09:15
* bauzas wonders why09:15
*** brinzhang0 has joined #openstack-nova09:15
bauzasand also, I don't have py36 running09:16
bauzas(as default)09:16
kashyaplyarwood: Morning, when you get a min: Nova uses in-QEMU RBD driver with raw or QCOW2 format or both?09:17
*** brinzhang_ has quit IRC09:18
*** songwenping_ has quit IRC09:18
stephenfinbauzas: care to bump this +1 to +2? https://review.opendev.org/c/openstack/nova/+/775415/09:30
*** zenkuro has joined #openstack-nova09:31
hemanth_nsean-k-mooney: can you review the PCI stat bug on stable/rocky when you get some time https://review.opendev.org/c/openstack/nova/+/76182409:31
bauzasstephenfin: I'm focusing on fixing the RPC API bump issues in the gate, but I can try to take a look on it later today09:40
lyarwoodkashyap: RAW only, we block qcow2 iirc09:48
kashyaplyarwood: A QEMU dev was asking about it; do you know the reason why we block QCOW2?09:50
*** ociuhandu has quit IRC09:50
lyarwoodkashyap: we block it when cloning rbd volumes as rbd already does the COW for us09:51
lyarwoodkashyap: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/imagebackend.py#L1038-L104109:51
lyarwoodkashyap: ^ that's for ephemeral storage nova controls, I'm not sure about cinder tbh09:51
* lyarwood looks09:51
lpetruthi: 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
lyarwoodkashyap: https://github.com/openstack/cinder/blob/85975fb2b63866ba6e216e621b84d571b9dbe90e/cinder/volume/drivers/rbd.py#L1525-L1530 - looks like the same logic in cinder09:53
lyarwoodlpetrut: 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
kashyaplyarwood: /me clicks09:53
lyarwoodgibi / 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
kashyaplyarwood: 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=174452509:54
openstackbugzilla.redhat.com bug 1744525 in qemu-kvm "Writing data to the qcow2 image over RBD is too slow" [Medium,Assigned] - Assigned to sgarzare09:54
kashyaplyarwood: But I don't think that's the case; as the logic in Cinder and Nova predates that bug09:55
stephenfinlyarwood: lpetrut: it sounds like we're avoiding bumping lower-constraints because it causes a mess?09:56
lpetrutstephenfin yep :)09:56
stephenfinOkay, 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 easily09:57
stephenfinEveryone else has dropped them. No point in us suffering for little to no benefit09:57
lpetrutstephenfin: 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.txt09:57
lyarwoodstephenfin: have people dropped them on master?09:58
stephenfinsean-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 huuuuuuge09:58
lyarwoodstephenfin: I noticed the stable stuff09:58
stephenfinlyarwood: they're totally gone from oslo and neutron. Likely many other projects also09:58
* stephenfin looks at glance and cinder09:58
lyarwoodwell well well10:01
lpetrutCinder still uses lower constraints. most of them have been bumped here: https://github.com/openstack/cinder/commit/d3ffa90baa959530eaa1cd1d4e3800fbe9148806#diff-f868e67d7bc10a25bc6baaea42ed5c763b42174505e4441349a52cf60dc007b010:01
lyarwoodit doesn't really resolve our issue however10:01
lyarwoodhttps://review.opendev.org/c/openstack/nova/+/763550/12..14/requirements.txt <- as os-brick causes this as well10:01
lyarwoodthat IMHO we can't avoid10:01
lyarwoodwhy don't I spend some time later today breaking that out into another change you can rebase on lpetrut10:02
lyarwoodthere's a load of bugfixes in there that we need anyway outside of the new Windows RBD stuff10:02
stephenfinthat's...downgrading most things?10:02
lyarwoodyeah what the10:02
lpetrutnot quite, it's flipped :)10:03
stephenfinThat seems off. We won't be allowed to specify a lower limit that os-brick, but we should be able to specify a higher one10:03
lyarwoodoh right because you reverted it so the diff is the wrong way around10:03
stephenfinahh10:03
stephenfinokay :)10:03
stephenfinphew10:03
lpetruthttps://review.opendev.org/c/openstack/nova/+/763550/12/lower-constraints.txt10:03
stephenfinyeah, I have no issues with bumping l-c10:04
stephenfinthe only issue would be if we were to backport this, but it's a feature so that's not an issue10:04
*** nightmare_unreal has joined #openstack-nova10:04
lpetrutawesome. lyarwood: are you ok with going back to patchset 12?10:04
*** derekh has joined #openstack-nova10:05
*** khomesh24 has quit IRC10:05
lyarwoodlpetrut: I'd like it to be a seperate change if I'm honest but I also don't want to hold you up anymore10:06
*** zoharm has joined #openstack-nova10:06
*** ociuhandu has joined #openstack-nova10:06
lyarwoodlpetrut: 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
lpetrutlyarwood: sure, thanks!10:07
lyarwoodlpetrut: ack np and sorry for dragging this out10:07
lpetrutnp, glad that we managed to reach a consensus :D10:08
kashyapstephenfin: 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
openstackgerritSylvain Bauza proposed openstack/nova master: Bump the Compute RPC API to version 6.0  https://review.opendev.org/c/openstack/nova/+/76145210:20
openstackgerritBrin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Update Servers APIs  https://review.opendev.org/c/openstack/nova/+/76429210:35
openstackgerritBrin Zhang proposed openstack/nova master: Replace all_tenants with all_projects in List Server APIs  https://review.opendev.org/c/openstack/nova/+/76531110:36
openstackgerritBrin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Rebuild Server API  https://review.opendev.org/c/openstack/nova/+/76638010:37
openstackgerritBrin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List SG API  https://review.opendev.org/c/openstack/nova/+/76672610:38
*** jangutter has joined #openstack-nova10:41
*** jangutter has quit IRC10:42
*** jangutter has joined #openstack-nova10:43
*** jangutte_ has quit IRC10:44
*** mkrai has quit IRC10:46
*** mkrai_ has joined #openstack-nova10:46
*** k_mouza has joined #openstack-nova10:56
openstackgerritJames Page proposed openstack/nova stable/train: add functional regression test for bug #1888395  https://review.opendev.org/c/openstack/nova/+/75953311:04
openstackbug 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
lyarwoodgibi / 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
stephenfinwe document direct requirements in the various requirments.txt files. We document everything in lower-constraints.txt11:16
stephenfinI suggested switching to just direct dependencies for lower-constraints.txt also but...11:16
lyarwoodwell it's working with just os-brick bumped11:16
lyarwoodLC that is11: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 huuuuuuge11:16
lyarwoodyeah I see11:17
stephenfinyou sure you're testing with pip >= 20.3 ?11:18
lyarwood20.2.211:18
stephenfinyeah, you need to install 20.3+ first11:19
stephenfinthat has the new dependency resolver11:19
lyarwoodwait that was in the venv11:19
lyarwood20.3.1 outside but that doesn't matter11:19
* lyarwood wonders why 20.2.2 is being used within the venvs11:19
stephenfinI think pip might be bundled with virtualenv11:20
lyarwoodyeah but I thought I had a new enough version on f3311:20
lyarwoodbumps and tries again11:21
*** psachin has quit IRC11:22
lyarwoodcool that's failing correctly now, let me work through these11:25
*** ahsen has joined #openstack-nova11:28
*** jangutter_ has joined #openstack-nova11:30
*** jangutter has quit IRC11:33
brinzhang0stephenfin: how about the novnc feature? https://review.opendev.org/c/openstack/nova/+/62233611:39
stephenfinbrinzhang0: I'm thoroughly confused on that now and need to sit down and figure it out11:39
brinzhang0I saw gibi said we will FF at 11th, can we complete this in this cycle?11:39
stephenfinI'm setting up a dev environment atm to play around with it11:40
stephenfinIt 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 out11:40
brinzhang0Now we are sopport input password when we open the console, if we do this config11:40
* gibi was away and now reading back11:41
brinzhang0I am very sorry, the tenant series patches may need much time to back 2.89, Ithink I want to do whatever11:42
brinzhang0s/want/wont11:42
gibilyarwood, 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 introduces11:43
lyarwoodgibi: thankfully it's not, I'm also breaking the os-win bump out into another change11:44
gibilyarwood: thanks for working on that11:44
gibistephenfin: 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
stephenfinI'm not sure. I haven't looked into that11:46
gibistephenfin: ack, I can try to look into that at some point11:46
gibiI assume there are a short list of offender indirect deps11:46
gibiif it is not the case then meh11:47
lyarwoodactually I don't need to break os-win out sorry, I thought it also had changes11:48
*** ociuhandu has quit IRC11:48
gibibrinzhang0, 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 me11:48
gibilyarwood: ack, no worries11:49
*** hoonetorg has quit IRC11:49
*** ociuhandu has joined #openstack-nova11:50
*** ociuhandu has quit IRC11:50
brinzhang0gibi: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
brinzhang0gibi: But we dont consider the authorican with proxy-->server yet, this is stephenfin concerned.11:52
*** ociuhandu has joined #openstack-nova11:52
stephenfinbrinzhang0: 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 server11:53
brinzhang0gibi: yes, hope stephenfin can give the clear direction, or let we improve it in future.11:53
stephenfinHence why I'm testing things now11:54
gibithanks, now I see the confusion11:54
openstackgerritLee Yarwood proposed openstack/nova master: hyper-v rbd volume support  https://review.opendev.org/c/openstack/nova/+/76355011:54
openstackgerritLee Yarwood proposed openstack/nova master: requirements.txt: Bump os-brick to 4.2.0  https://review.opendev.org/c/openstack/nova/+/77817711:54
lyarwoodstephenfin / gibi ; ^ okay that should finally do it for the hyperv rbd stuff11:54
* lyarwood -> coffee11:54
lyarwoodlpetrut: ^ also sorry11:54
stephenfingibi: 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
gibilyarwood: thanks. I will jump on it before I dissapeare again to a meeting11:54
gibistephenfin: I'm glad you picket it up, the vnc proxy stuff is a black hole to me at the moment11:55
*** ociuhandu has quit IRC11:57
brinzhang0stephenfin: 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 scenario11:57
*** Luzi has joined #openstack-nova11:58
lpetrutlyarwood: thanks!11:58
brinzhang0this is also we were used daily^11:58
lpetrutlyarwood: I'm wondering if there's any way in which we could automate this process, it's quite tedious11:58
gibilyarwood: I'm +2 on the bump11:59
* gibi disappeares again :/11:59
brinzhang0stephenfin: we used the VNC tool is vnc viewer, maybe you can try11:59
lyarwoodlpetrut: I think the new pip resolver might provide a way of doing this if we wanted to keep lower-constraints.txt around in nova12:00
lyarwoodlpetrut: something to bring up at the PTG I think, either we automate this or drop lower-constraints.txt12:00
stephenfinpip doesn't have machinery for this. That's the main issue :-(12:01
gibihere is the ptg etherpad if neede :) https://etherpad.opendev.org/p/nova-xena-ptg12:01
stephenfinThere's an open RFE against it (filed by dhellmann iirc) but it needs bodies of course12:01
lyarwoodoh it doesn't?12:03
*** hoonetorg has joined #openstack-nova12:03
lyarwoodhuh I had assumed there was a lib or something we could call into to automate it, that's a shame12:03
sean-k-mooneylyarwood: a min version resolver no uncortunetly not12:09
sean-k-mooneylyarwood: we likely should restrict lower constratits to just our direct deps12:09
sean-k-mooneypossibly excluding any deps in test-requirements12:10
sean-k-mooneyfor now i think we should contiue to have lower constraitns.12:11
sean-k-mooneylyarwood: you should not be importing os-brick constratis versin into nova however12:11
sean-k-mooneylyarwood: is the hyperv feature the only reason you are doing https://review.opendev.org/c/openstack/nova/+/77817712:12
*** ociuhandu has joined #openstack-nova12:12
sean-k-mooneybecause we said we were not going to bump the min version for that12:12
lyarwoodthat's a direct dependency12:12
lyarwoodthe code doesn't work without that version12:13
sean-k-mooneyits an optional depency12:13
lyarwoodit's direct if you're using that codepath12:13
sean-k-mooneyyes12:13
sean-k-mooneybut its not when not using the hyperv driver12:13
sean-k-mooneyand we said we were not going to do an os-brick bump for that12:13
lyarwoodwe'd never bump os-brick with that logic12:13
lyarwoodthere have been plenty of examples in the past where we have done this to accomidate the libvirt driver12:14
lyarwoodI don't get how that's optional12:14
sean-k-mooneytrue however it makes all lib deps viral12:14
openstackgerritStephen Finucane proposed openstack/python-novaclient master: Add support for microversion v2.88  https://review.opendev.org/c/openstack/python-novaclient/+/77057312:14
sean-k-mooneyif 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 deps12:15
lyarwoodright and that's in LC at present12:15
sean-k-mooneythis did not use to happen with the old resolver12:16
lyarwoodbecause it was broken12:16
sean-k-mooneyno i know how it worked12:16
sean-k-mooneyit was not broken12:16
sean-k-mooneyit just worked differently then we expected12:16
sean-k-mooneyand that had some useful cases12:16
sean-k-mooneyit had some negitives too12:16
sean-k-mooneybut we have regressed our ablity to state teh min verion of nova requirements with the new resolver12:17
*** ociuhandu has quit IRC12:17
sean-k-mooneynow we can only state if you deploy every possible backend connently on the same host this is the set of all min deps12:17
sean-k-mooneythat is a very different statement12:17
sean-k-mooneypreviously we only needed to do a bump it we use a python api that did not exist or had a different signiture12:18
*** ociuhandu has joined #openstack-nova12:18
sean-k-mooneyif nova did not use a feature in a trasitive dep directly we did not need to bump it in lc12:19
sean-k-mooneyfor optional deps that was the correct behaivor12:19
*** zzzeek has quit IRC12:20
lyarwoodI'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-mooneywe could not do the bump12:22
lyarwoodland code that we know would fail with our current reqs?12:22
sean-k-mooneythere is no code path in any of our test coverage that will require this12:22
lyarwoodthere is in third party for hyperv12:22
sean-k-mooneylyarwood: it wont break our unit or funct test12:22
lyarwoodand?12:22
*** ociuhandu has quit IRC12:22
sean-k-mooneylyarwood: right and they can install the dep12:23
lyarwoodwe're still landing broken code12:23
lyarwoodit just feels wrong to me12:23
lyarwoodand in any case bumping os-brick like this pulls in a load of other fixes and improvements12:23
sean-k-mooneyso does importing deps form an optional lib12:23
lyarwoodI'd argue that we needed to do that this cycle anyway tbh12:23
*** zzzeek has joined #openstack-nova12:23
lyarwoodthere are no new deps there btw, just version bumps12:24
sean-k-mooneywe can do that for other reasons but i think this is a bad pattern to apply in the general case12:24
sean-k-mooneyoh i know12:24
lyarwoodthe same would also apply12:24
sean-k-mooneybut we dont want every lib to be viral12:24
sean-k-mooneyyou also have a smaller set of changes then the hyperv patch orginally had12:24
lyarwoodyeah I'm not sure where some of the changes in the original hyperv change came from but pip was happy with these12:25
lyarwoodaaaaaand something has already failed12:25
* lyarwood looks12:25
sean-k-mooneyif 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 future12:25
sean-k-mooneythe new resolver has changed the meanin of LC and expanded its scope12:26
sean-k-mooneyif we want to continue to use that i think we need to discuss what LC now means12:26
*** bbowen_ has joined #openstack-nova12:26
lyarwoodsean-k-mooney: yeah I've added a line in the ptg pad but feel free to rephrase the question12:27
* lyarwood tries to understand why https://5e7e7be1ea42142e6d74-f918abb3dcdfb01ed824790c230ea283.ssl.cf2.rackcdn.com/763550/15/check/requirements-check/86d1c2f/job-output.txt is failing12:28
sean-k-mooneylyarwood: run tox with -r to recreate the env12:29
sean-k-mooneyor before that check the pip version12:29
*** bbowen has quit IRC12:29
sean-k-mooneyit wont automatically upgrade the pip version12:29
sean-k-mooneyso if the enve was created with the old resolver then it will still be using it12:29
sean-k-mooneyoh12:30
lyarwoodthat's a different job12:30
sean-k-mooneylyarwood: you forgot to update requirements.txt12:30
lyarwoodI'm just about to run it locally now12:30
sean-k-mooneyyou only bumped the min in lc12:31
lyarwoodfor the in-direct deps?12:31
lyarwoodI thought that wasn't required?12:31
sean-k-mooneyit is12:31
sean-k-mooneywe also use those directly12:31
lyarwoodhuh pip was fine without them12:31
sean-k-mooneypip is but this is the requiremetns check job12:31
sean-k-mooneywe dont allow the min in requirements.txt to differ form lc by policy in openstack12:32
sean-k-mooneyand that job enforces that while also check the markers match what is in GR/UC12:32
lyarwood*sigh*12:33
sean-k-mooneylyarwood: 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 nova12:33
lyarwoodyeah just building the venv now12:33
sean-k-mooneyit wont see this error since this is not part of nova12:34
lyarwoodthe requirements venv12:34
lyarwoodnot nova12:34
sean-k-mooneyah12:35
sean-k-mooneyanyway its a simple fix12:35
*** ociuhandu has joined #openstack-nova12:35
sean-k-mooneyjust update nova's requiremetns.txt12:35
sean-k-mooneywith the same min version you set in lc12:35
sean-k-mooneyyou do not need to change anything in the requiremetns repo in case that is not obvious form the error12:36
lyarwoodit's obvious, I just wanted to run the same test locally12:37
lyarwoodfrom the requirements repo12:37
*** mkrai_ has quit IRC12:38
ahsenHi, 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 I12:43
ahsenincrease waiting time or attemps? We are using Ussuri. Thank you.12:43
*** ociuhandu has quit IRC12:44
lyarwoodahsen: the retries and interval are controlled by CONF.block_device_allocate_retries and CONF.block_device_allocate_retries_interval on the Nova side12:46
lyarwoodahsen: but you should trace the request through to the Cinder side to understand why it's taking so long12:46
sean-k-mooneyahsen: is it a large image or are you using HDDs on the cinder side or low bandwith nics12:52
sean-k-mooneyahsen: i had to set block_device_allocate_retries_interval=10 on my home cluster12:53
sean-k-mooneythe time it took for qemu image to copy the image data for larger images was taking just over 60 seconds and it was timing out12:53
ahsenlyarwood Thank you, I will try to increase those values. And actually Cinder creates volumes but I don't know how long does it take12:54
*** links has quit IRC12:55
sean-k-mooneyahsen: if you look at teh cidner driver log you should see the qemu-img command doing the data transfer12:55
sean-k-mooneyahsen: for me it only became a proable for images over about 5-8Gs12:55
ahsensean-k-mooney Image is not large and we are using SSD also bandwith is not low12:56
lyarwoodahsen: kk, you should see a request-id logged by Nova from Cinder that you can use to grep through your logs12:57
sean-k-mooneyok 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 case12:57
sean-k-mooneyahsen: what cinder backend are you using by the way12:58
ahsensean-k-mooney I will look at them12:58
openstackgerritLee Yarwood proposed openstack/nova master: requirements.txt: Bump os-brick to 4.2.0  https://review.opendev.org/c/openstack/nova/+/77817712:58
openstackgerritLee Yarwood proposed openstack/nova master: hyper-v rbd volume support  https://review.opendev.org/c/openstack/nova/+/76355012:58
lyarwoodokay lets try this again12:58
ahsenlyarwood and sean-k-mooney I will try what you said. Thank you both13:00
*** links has joined #openstack-nova13:04
openstackgerritMerged openstack/nova master: libvirt: add AsyncDeviceEventsHandler  https://review.opendev.org/c/openstack/nova/+/77238113:11
lyarwoodstephenfin: 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-nova13:27
*** jangutter has joined #openstack-nova13:33
*** jangutter_ has quit IRC13:37
*** tbachman has quit IRC13:38
*** tbachman has joined #openstack-nova13:40
*** lbragstad_ is now known as lbragstad13:41
openstackgerritElod Illes proposed openstack/nova stable/ussuri: Fallback to same-cell resize with qos ports  https://review.opendev.org/c/openstack/nova/+/77393213:43
gmannbrinzhang0: sorry i was away yesterday. replied on https://review.opendev.org/c/openstack/nova/+/766726/13:48
bauzasgibi: dansmith: huzzah \o/ the Compute RPC API bump patch eventually got a +1 from Zuul https://review.opendev.org/c/openstack/nova/+/76145213:57
*** mlavalle has joined #openstack-nova13:59
bauzasfwiw, the grenade multinode job helped to find an issue14:03
bauzas+ some functest related to numa live migration14:03
*** hemanth_n has quit IRC14:04
gibibauzas: added the RPC bump to my review queue14:07
bauzasgibi: 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 reviewed14:11
gibithanks I will dig into it14:12
bauzasgibi: I can help you to understand how this works14:15
sean-k-mooneyFYI we may need to rework how we do memory tracking to fix a previously unknow aspect of pci passhtough14:15
*** jangutter has quit IRC14:16
bauzasgibi: once you begin to look at the RPC API, ping me and I'll explain14:16
sean-k-mooneyill try and file a bug for it when i have time but basically memory oversubsciption cant be done if you have pci passthough/sriov14:16
bauzasgibi: tl;dr: I'm providing a 5.x proxy for supporting old clients14:16
sean-k-mooneyit might also affect vgpu14:16
*** jangutter has joined #openstack-nova14:16
bauzassean-k-mooney: ack14:16
bauzassean-k-mooney: vgpu or gpu ?14:17
sean-k-mooneyboth14:17
bauzaswhy ?14:17
sean-k-mooneywe will have to verify it14:17
bauzasb/c vgpu is different from pci passthrough and sriov14:17
sean-k-mooneybauzas: libivrt is locking the guest memory pages whenever we use pci passthoug14:17
sean-k-mooneyit may or may not be doing the same for vgpu14:17
bauzasah14:17
bauzastest it then, yes14:18
bauzasand like I discussed with you, I'd also like to work on pci attach/detach14:18
sean-k-mooneygeneric attach ya14:18
sean-k-mooneythis 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 explictly14:19
sean-k-mooneyfor vdpa libvirt does not do it implcitly which is why i got dma error14:19
sean-k-mooneyso i have not actully avalidated it myself yet14:20
sean-k-mooneyonce i do ill try and write up my findings14:20
sean-k-mooneyim 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-nova14:24
bauzassean-k-mooney: sure, I can try to get some vgpu environment (hopefully)14:28
*** jawad_axd has quit IRC14:31
*** jawad_axd has joined #openstack-nova14:32
*** Luzi has quit IRC14:36
*** jangutter_ has joined #openstack-nova14:38
*** jangutter has quit IRC14:41
sean-k-mooneyvgpus dont work with ubuntu hosts correct at leat not the nvida version?15:00
*** spatel has quit IRC15:00
sean-k-mooneyactully im using teh mainline 5.11 kernel so never mind it wont install on my host anyway15:00
sean-k-mooneythe vdpa host im using also has a t4 but i dont really have a way to test it there15:01
*** spatel has joined #openstack-nova15:02
bauzassean-k-mooney: no, ubuntu is not supported by nvidia drivers but you can use intel gvt-g if you really want to test vgpus15:02
*** links has quit IRC15:02
bauzasand a i915 host if you have one by hand15:02
sean-k-mooneyi was just wondering if the host i have would work or not. am maybe my laptop i could test with libvirt directly i guess15:03
bauzasthat's what I did for i91515:03
bauzasI just used an old laptop for testing15:03
sean-k-mooneyit wont happen in the next 2 weeks so we can figure it out later.15:03
bauzasthat's actually the problem with gvt-g, you can't find good intel cards that are for production15:04
bauzasall the i915 cards are for desktop lines15:04
bauzasbut hopefully, ROCI will help us15:05
sean-k-mooneyyes they removed integrated grapshic for the server line when they added it15:05
sean-k-mooneyim hoping that the new descreet intel gpus will support it15:05
bauzasfwiw, devstack on rhel works okay to me15:05
bauzasbut you'd need to run another env15:05
sean-k-mooneyi need a newer kernel for the vdpa work so rhel was not an option15:06
*** links has joined #openstack-nova15:06
sean-k-mooneyit does not have the vendor driver15:06
sean-k-mooney8.4 might but not 8.3 or even centos stream15:06
sean-k-mooneythats why im using the mainline 5.11 kernel for development15:07
bauzasha15:08
bauzasand what about fedora ?15:08
bauzasin theory, nvidia RPMs should work but I never tested them15:08
sean-k-mooneyit has python 3.9 which breaks eventlests and openstack in general15:08
bauzasthe dependency saga.15:09
sean-k-mooneyi 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.815:09
sean-k-mooneyalthough i ended up compiling qemu form souce anyway due to a driver bug15:10
*** mkrai has joined #openstack-nova15:11
sean-k-mooneybut 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 manully15:13
sean-k-mooney* happy15:13
*** jawad_axd has quit IRC15:15
*** jawad_axd has joined #openstack-nova15:16
*** macz_ has joined #openstack-nova15:19
*** jawad_axd has quit IRC15:24
*** zenkuro has quit IRC15:27
*** lpetrut has quit IRC15:34
*** openstackgerrit has quit IRC15:35
sean-k-mooneybauzas: 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 it15:41
kashyapgibi: artom: When you get a min, I think I've addressed all the pressing concerns: https://review.opendev.org/c/openstack/nova/+/77424015:42
gibikashyap: ack, I will check back15:43
kashyapThanks; 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 IRC15:45
*** mkrai has quit IRC15:57
*** dklyle has joined #openstack-nova16:02
*** links has quit IRC16:12
*** dviroel has quit IRC16:34
gibibauzas: I left some questions in the RPC bump series https://review.opendev.org/c/openstack/nova/+/761452 but overall the patch looks good to me16:34
bauzasthanks for the review, /me looks16:35
bauzasgibi: tbc, we need to hold this change until FF16:35
gibibauzas: is there any RPC impacting change open I should be aware of?16:35
bauzasbut the more we review, the quickier we could merge it just after m-316:35
bauzasgibi: some compute service bumps AFAIK16:35
gibitrue, service version will be in conflict if we merge those16:36
bauzashttps://review.opendev.org/c/openstack/nova/+/761452 has a lot of merge conflicts16:36
bauzasso I'm prepared to rebase this change16:36
gibibauzas: ack. I will prioritize to land this after FF16:37
gibibut we might get FFE requests16:37
gibiwith service bumps16:37
gibiso it will be a tricky balance16:37
gibianyhow we have to be strict with FFEs due to sortness of time til RC116:38
gibibrinzhang0: 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
bauzasgibi: what we could discuss is whether this parameter should be mandatory16:40
sean-k-mooneygibi: ya with one week i would say we likely dont have time in most case16:40
bauzassame for all the other methods like rebuild16:40
gibibauzas: 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 supprot16:41
gibisuport16:42
gibisupport even16:42
gibisean-k-mooney: yeah16:42
gibisean-k-mooney: we have two week between FF (Mar12) and the lat possible date of RC1 Mar2616:42
gibiI mean FF mar1116:43
gibifor nova16:43
sean-k-mooneygibi: the only reservatio ni would have for makign it mandatory is that not all driver need it or will support cyborg16:43
sean-k-mooneybut other then that ya it could be16:43
bauzasgibi: yeah for sure16:43
bauzasgibi: we actually pass the parameter everytime now16:43
gibiit is the compute manager interface not the virt driver interface16:43
bauzasif so, it's mandatory16:43
bauzasbut if we don't, then it should continue to be optional16:44
sean-k-mooneygibi: oh i though rc1 was the 18 cool still tight16:44
bauzassean-k-mooney: am i right?16:44
sean-k-mooneybauzas: when working with cyborg instace we need to pass it16:44
sean-k-mooneybut for none cycboge isntace its not needed16:44
bauzassean-k-mooney: the question is, do we pass them everytime even without cyborg ?16:44
gibibauzas: I also think that we pass accel_uuids now via the RPC. if this is not a cyborg intance then we pass [] I hope16:45
bauzassean-k-mooney: meaning we could pass an empty list16:45
sean-k-mooneywe can pass an empty list yes16:45
bauzasbut we could have made it optional16:45
bauzasinstead of an empty list16:45
sean-k-mooneywe cant make kwards defualt to empty list16:45
bauzaslike, you don't use cyborg, accel_uuids be None16:46
sean-k-mooneybut we could default to None16:46
sean-k-mooneyand then pass [] if its none16:46
bauzasand if so, the RPC 6.0 version should continue to support None16:46
bauzasbut afaicu, we pass []16:46
bauzasso now, it's mandatory16:46
bauzasI mean, the parameter is passed16:46
bauzasevery time16:46
bauzaseven if 99% of the time the value is an empty list16:47
bauzasthat's sad16:47
sean-k-mooneyi honestly dont recall what i did orginally but i proably passed an empty list16:47
bauzasdansmith: thoughts on it ?16:47
bauzasdansmith: I recall you reviewed the cyborg patches16:47
gibiit is empty list in the cases I now checked16:47
bauzasok, then we need to make the parameter mandatory16:48
gibiand you did that16:48
bauzasyup16:48
bauzasbut that's sad16:48
bauzasin particular for the boot case16:48
bauzasI would have preferred to have this parameter be optional16:48
sean-k-mooneyactully i think we pass None though most of the calls16:49
sean-k-mooneynot []16:49
*** nightmare_unreal has quit IRC16:49
bauzasbut the ship is sailed16:49
bauzashas* sailed16:49
gibisean-k-mooney: hm, _create_and_bind_arqs and get_arq_uuids_for_instance returns []16:49
dansmithbauzas: just skimming the scrollback... the question is what the *client* should do, right?16:49
bauzassean-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
bauzasdansmith: the question is, should we make accel_uuids mandatory (I did this, but this is terrible)16:50
dansmithideally, all RPC parameters for matching client/server would be passed, either None or [] depending, but never missing for a given version that supports it16:50
dansmithbauzas: right but mandatory where, client or server?16:50
bauzasserver16:50
dansmithit should be mandatory that it is passed over the wire, yes16:50
bauzasthat's my point16:50
bauzaswe could have make it optional16:51
dansmiththe 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 convenience16:51
bauzasbut looks like we didn't16:51
sean-k-mooneythe server side in teh compute manager seam to use None so i guess the rpcapi is what we need to check or the compute api16:51
dansmithreally?16:51
sean-k-mooneythats using []16:51
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L419216:51
dansmitheither way, 6.0 not landed yet, so we can make it mandatory in 6.0 and correct that problem16:51
bauzaswe default to a empty list16:52
bauzasand we pass the parameter anyway16:52
bauzaswhich makes this argument mandatory from a manager perspective IIUC16:52
dansmithsince 5.x people can't talk to 6.0 anyway, and then the 5.x proxy can tolerate it being missing16:52
sean-k-mooneyya so form the compute manager/driver point of view it hink it will happly use [] or None and treat it the same16:52
sean-k-mooneyif you really think [] is too much overhead vs None you could proably change it in 6.0 but im not sure it gets us much16:53
bauzasmmm16:54
bauzasI'm confused16:54
dansmithwhether it's [] or None doesn't really matter much, but I expect [] makes more sense16:54
gibi^^ agree16:54
bauzasbefore this change, we were having accel_uuids be None16:55
bauzashence be optional16:55
sean-k-mooneyya we just cant uses [] for the default in a kwarg16:55
bauzasbut this was just for compat reasonqs16:55
gibibauzas: only for the case when the client did not sent the param accel_uuids16:55
sean-k-mooneybecause only one list would be created and shared between all calls16:55
bauzasgibi: correct16:55
bauzasgibi: so, a recent client was *always* passing an empty list16:55
sean-k-mooneythat why we use None in the compute manager but always pass [] or a populated list16:55
gibisean-k-mooney: we are not defaulting anyting to [], the client sends a list either empty or non empty16:56
bauzaswell, a recent client is *always* passing accel_uuids as a param, tbc16:56
sean-k-mooneygibi: correct16:56
gibiOK, we are in violent agreement then :)16:56
bauzasok, so let's leave it mandatory16:56
gibiyepp16:56
bauzassad but ok16:56
dansmiththe 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 behavior16:56
dansmithbut going forward, I think it should be mandatory for sure, and ideally [] if no accel_uuids16:57
bauzasI agree, it was the usual signal for knowing whether the client was new enoguh16:57
dansmithyeah16:57
bauzasbut we also have optional args16:57
dansmithideally we shouldn't16:57
bauzasbecause the RPC signature can change ?16:58
bauzasI think I get you16:58
sean-k-mooneydansmith: 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 None16:58
bauzaseither way, let's stick with it then16:58
bauzasgibi: I'll reply to your comments16:58
gibicool16:58
gibiI will check back tomorro16:58
gibiw16:58
dansmithsean-k-mooney: yeah, it's explicit vs. implicit16:59
*** zoharm has quit IRC17:04
*** lucasagomes has quit IRC17:06
gibiartom, 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-nova17:09
*** ociuhandu has quit IRC17:12
stephenfinI 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 territory17:13
*** ociuhandu_ has quit IRC17:13
gibiI can work with both but I do understand the uniqueness of the prefix based approach17:13
bauzasstephenfin: dansmith: worth removing this argument now I'm bumping the RPC API ? https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L531117:14
gibiI cannot recall if we discussed this during the meeting when we approved the bp17:14
bauzasI mean, in https://review.opendev.org/c/openstack/nova/+/76145217:14
artomstephenfin, 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 side17:14
* bauzas does a quick look at all the comments for 6.017:15
artomAnd it's not like +/- is super complex to understand.17:15
bauzasstephenfin: dansmith: but I'm fine with punting this for a later minor bump, like 6.117:15
dansmithbauzas: you can't drop a param in 6.1 :)17:15
artomI'd be more inclined to go stephenfin's route if the alternative was edging into DSL territory, which it definitely isn't17:15
bauzasoh shit17:15
bauzasyou're right17:16
bauzasdansmith: worth the effort then ?17:16
stephenfinNo, 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 opts17:16
dansmithbauzas: yep, else you wait until 7.0 and those cleanups are the whole point of this17:16
bauzasdansmith: my only concern is that we're passing this argument everytime now17:16
stephenfingibi: 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 nothing17:17
bauzasit's just the manager which doesn't use it17:17
gibikashyap, 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-14817:17
gibiand there was no objection then17:17
dansmithbauzas: no we're not, because 6.0 hasn't landed yet and YOU are defining its behavior :)17:17
bauzasbut I'm lazy17:17
bauzas:p17:17
dansmithbauzas: well, that may be :)17:17
stephenfingibi: 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
artomgibi, ah, last week when I was on PTO? :)17:18
bauzasdansmith: I mean, I would have appreciated if someone (like stephenfin :p ) would have stopped to provide this arg by the client17:18
bauzasclient isez17:18
bauzasside17:18
bauzasnow, we're passing it over the wire17:18
bauzasso we could pretend we never did17:18
dansmithbauzas: in 5.x17:18
bauzasyup17:19
dansmithbut not in 6.x17:19
gibiartom: you were present on that meeting :)17:19
bauzasdansmith: right, making it optional17:19
bauzason the client17:19
artomgibi, oh, hah :P17:19
gibibut good try :P17:19
artomClearly shows how much I care17:19
bauzasdansmith: but of course, still mandatory on the server until 6.017:19
artomGenuinely, we could go either way and I'll sleep perfectly well that night17:19
gibiOK, let's go with the proposed implementation. as I don't see it as a dealbreaker17:20
gibiI'm upgrading my vote on the patch17:20
dansmithgibi: it shouldn't even be optional on the client for 6.0 right?17:21
stephenfincool, I'll take a look tomorrow17:21
gibistephenfin: thanks17:21
stephenfinstill working through the VNC fun17:21
stephenfinit's a pain in the a*** :)17:21
gibidansmith: 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 well17:22
dansmithoops s/gibi/bauzas/ above17:22
dansmithgibi: that comment was about request_spec, not accel_uuids17:23
gibiaah17:23
gibithen ignore me17:23
dansmithgibi: I confused you by replying to you instead of bauzas17:23
gibisorry17:23
bauzasdansmith: right17:23
* dansmith is in two active convos atm :)17:23
bauzasOK, looks like I have work to do17:23
*** lpetrut has joined #openstack-nova17:28
bauzashonestly, 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.1317:28
bauzasso I won't do it, unless someone steps up and write a 5.x version for making it deprecated17:28
bauzasstephenfin: ^17:28
bauzaswe lost some opportunity here17:29
stephenfinI haven't been following, I'm afraid :( We're passing an unnecessary argument through to some RPC API?17:30
sean-k-mooneybauzas: how would we get the request_spec if we dont pass it? via the instance?17:34
sean-k-mooneyi dont think we want to lazy load that if its currently used17:35
bauzassean-k-mooney: stephenfin's point is that we don't use this parameter even if we pass it thru the wire17:35
sean-k-mooneyfor which api call17:35
bauzasand we have a few other methods that have some parameters passed thru the wire that we don't use17:35
sean-k-mooneyright so those whould have to be removed in 6.017:36
bauzasyou know what ? I'm changing the docstring to be 7.017:36
bauzasand we know we have to write some 6.x API version that would deprecate those parameters17:36
sean-k-mooneydo we have to do deprecations like that for internal rpc apis?17:37
bauzashonestly, now I wrote a 6.0 bump, I feel brave enough for writing a 7.0 one17:37
bauzasbut this will have to be at least for X, ideally Y17:37
sean-k-mooneybauzas: well we likely wont do a 7.0 bump for another couple of releases17:37
bauzasyes17:37
bauzasI know17:37
sean-k-mooneyproably not before Z17:38
sean-k-mooneyi mean there is not strict rule but we have mostly wated 4-6 release between major bumps17:38
bauzassure, but at least we should stop passing those over the wire if we don't need them17:38
bauzasno17:38
bauzassean-k-mooney: we released major RPC versions more often in the past17:38
bauzasKilo, Mitaka, Queens17:39
bauzasand now Wallaby17:39
sean-k-mooneyright which is why i said there was no rule that we cant do it more often17:39
sean-k-mooneybut we avoid it unless it buys use a lot17:40
bauzassure, but my concern is to make sure that if we don't need them, we should stop passing them by the client17:40
bauzashence a 6.x release for stopping this17:40
bauzasand later, a 7.0 for removing17:40
sean-k-mooneywith that said not that we enforce the min compute version on startup there is less utility in keeping a major version for a long time17:40
*** rpittau is now known as rpittau|afk17:42
bauzassean-k-mooney: again, stop thinking about the next major RPC release17:42
bauzassean-k-mooney: just a single minor version for stopping to emit this param and I'll be happy17:43
sean-k-mooneysure but to do that you need to make them optional parmaters right17:43
sean-k-mooneyand then just stop setting them17:43
sean-k-mooneyso you need to prepare for it in the 6.0 version17:44
sean-k-mooneyunless you were planning to keep them mandatoy and have the clinet hardcode None or something?17:45
sean-k-mooneyi 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 is17:47
*** bnemec has quit IRC17:49
sean-k-mooneyhttps://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 proxy17:54
sean-k-mooneyhttps://github.com/openstack/nova/commit/eae37a27caa5ca8b0ca50187928bde81f28a24e1#diff-91f79786d7e3744c39926c88bbafe3b727630fa4eb48e845686d7f12f876d067L53117:54
*** derekh has quit IRC18:01
*** tobias-urdin has quit IRC18:02
*** openstackgerrit has joined #openstack-nova18:05
openstackgerritMerged openstack/nova master: Docs: Correct ``Password injection using the dashboard`` Explanation  https://review.opendev.org/c/openstack/nova/+/77508418:05
*** lpetrut has quit IRC18:07
dansmithsean-k-mooney: we only ever drop params in a major bump, and all such bumps have dropped parameters, AFAIR18:09
dansmithsean-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 forward18:10
sean-k-mooneydansmith: yes that is what i understood too18:11
dansmithack18:11
dansmithbauzas: 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
dansmithThe 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.018:16
dansmithso 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 changes18:16
*** bnemec has joined #openstack-nova18:16
bauzasdansmith: ok, I'll see what I can do18:19
bauzasthe 6.0 bump already has a long list of changed things18:19
bauzasand I'm just about cleaning it more18:19
bauzasI'm the janitor and it's a mess18:19
dansmiththat's the whole point of a major bump though18:19
bauzasI don't disagree18:20
dansmithit's both why we should maybe do it more frequently, and also why we don't :)18:20
bauzasI'm just afraid by the timings here18:20
bauzasand the review steam18:20
dansmithyup, it's hard, and why we've been talking about it for a cycle :)18:21
bauzasZuul eventually gave me its blessing after a long period of doubt18:21
bauzasand I'm just removing extra other bits18:22
bauzasbut OK, I can try18:24
*** ralonsoh has quit IRC18:29
*** k_mouza has quit IRC18:36
*** k_mouza_ has joined #openstack-nova18:36
*** andrewbonney has quit IRC18:38
*** hamalq has joined #openstack-nova18:38
*** xek has quit IRC18:39
openstackgerritStephen Finucane proposed openstack/python-novaclient master: WIP: Add support for setting VNC password  https://review.opendev.org/c/openstack/python-novaclient/+/77822918:43
stephenfinmelwitt: More comments on https://review.opendev.org/c/openstack/nova/+/62233618:45
stephenfinI'm so confused about what's doing what18:45
*** xek has joined #openstack-nova18:47
*** xek has quit IRC18:47
stephenfinmelwitt: 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
bauzasdansmith: around ? I'm facing some concern about https://review.opendev.org/c/openstack/nova/+/761452/9/nova/tests/functional/libvirt/test_numa_live_migration.py18:55
bauzassince we upgraded to 6.0, now the version_cap is defaulted to 6.018:56
bauzasand then can_send_version() can only support 6.018:56
bauzaswhile previously with 5.13, can_support_version was accepting 5.318:57
bauzaseven if the version cap was 5.1318:57
bauzaswhat 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
bauzasthis whole testclass is so tangled with RPC versioning that we should consider axing a lot of them later on18:58
bauzasbut I just want to pass the bar here18:58
bauzasand not do unnecessary scrubbing18:59
bauzasactually, I need to eat by now19:02
*** k_mouza_ has quit IRC19:04
*** k_mouza has joined #openstack-nova19:05
openstackgerritSylvain Bauza proposed openstack/nova master: Bump the Compute RPC API to version 6.0  https://review.opendev.org/c/openstack/nova/+/76145219:16
*** k_mouza has quit IRC19:29
openstackgerritMerged openstack/nova master: libvirt: allow querying devices from the persistent domain  https://review.opendev.org/c/openstack/nova/+/77238319:41
*** tbachman has quit IRC19:44
*** tbachman has joined #openstack-nova19:53
dansmithbauzas: 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 concerns20:18
dansmithbauzas: 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.x20:19
bauzasso, which option would you prefer ?20:19
bauzasscenario 2 in my comment, ie. capping to 5.13 ?20:20
bauzasdansmith: ^20:20
bauzasor scenario 1, leave as it is20:20
bauzasfrom what I understand you, looks like you prefer scenario #220:20
*** spatel has quit IRC20:25
*** Underknowledge has quit IRC20:26
*** Underknowledge has joined #openstack-nova20:26
dansmithbauzas: commented20:35
bauzasta, will look20:36
bauzasdansmith: ok thanks, will then pin to 5.1320:39
dansmithcool20:39
* bauzas just works at the unnecessary parameters removal20:40
*** dviroel has joined #openstack-nova20:55
*** abhishekk has quit IRC21:06
*** bhagyashri|rover has quit IRC21:06
*** abhishekk has joined #openstack-nova21:06
*** bhagyashris has joined #openstack-nova21:07
*** hoonetorg has quit IRC21:21
*** belmoreira has quit IRC21:24
* bauzas stops for the night, will continue on the RPC bump tomorrow morning21:27
bauzasg'night21:27
*** k_mouza has joined #openstack-nova21:29
*** k_mouza has quit IRC21:34
*** belmoreira has joined #openstack-nova21:37
*** hoonetorg has joined #openstack-nova21:42
openstackgerritMerged openstack/nova master: apidb: Compact Newton database migrations  https://review.opendev.org/c/openstack/nova/+/75940121:43
*** gyee has joined #openstack-nova21:43
*** brinzhang0 has quit IRC21:47
*** belmoreira has quit IRC22:23
*** rcernin has joined #openstack-nova22:33
*** vishalmanchanda has quit IRC22:54
*** pmannidi has joined #openstack-nova23:07
*** pmannidi_ has quit IRC23:08
*** zzzeek has quit IRC23:13
*** zzzeek has joined #openstack-nova23:17
*** k_mouza has joined #openstack-nova23:30
*** k_mouza has quit IRC23:34
*** luksky has quit IRC23:35

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!