Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-02
10:20:54 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:35:42 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:36: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:37:21 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:38:07 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
11:04:15 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:33 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:15:17 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:16:16 stephenfin we document direct requirements in the various requirments.txt files. We document everything in lower-constraints.txt
11:16:38 stephenfin I suggested switching to just direct dependencies for lower-constraints.txt also but...
11:16:49 lyarwood well it's working with just os-brick bumped
11:16:53 lyarwood LC that is
11:16:54 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:17:07 lyarwood yeah I see
11:18:13 stephenfin you sure you're testing with pip >= 20.3 ?
11:18:55 lyarwood 20.2.2
11:19:06 stephenfin yeah, you need to install 20.3+ first
11:19:21 stephenfin that has the new dependency resolver
11:19:22 lyarwood wait that was in the venv
11:19:34 lyarwood 20.3.1 outside but that doesn't matter
11:20:00 stephenfin I think pip might be bundled with virtualenv
11:20:25 lyarwood yeah but I thought I had a new enough version on f33
11:21:24 lyarwood bumps and tries again
11:25:14 lyarwood cool that's failing correctly now, let me work through these
11:39:04 brinzhang0 stephenfin: how about the novnc feature? https://review.opendev.org/c/openstack/nova/+/622336
11:39:39 stephenfin brinzhang0: I'm thoroughly confused on that now and need to sit down and figure it out
11:39:43 brinzhang0 I saw gibi said we will FF at 11th, can we complete this in this cycle?
11:40:29 stephenfin I'm setting up a dev environment atm to play around with it
11:40:36 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:39 brinzhang0 Now we are sopport input password when we open the console, if we do this config
11:42:14 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:28 brinzhang0 s/want/wont
11:43:36 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:44:12 lyarwood gibi: thankfully it's not, I'm also breaking the os-win bump out into another change
11:44:32 gibi lyarwood: thanks for working on that
11:45:22 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:46:27 stephenfin I'm not sure. I haven't looked into that
11:46:37 gibi stephenfin: ack, I can try to look into that at some point
11:46:58 gibi I assume there are a short list of offender indirect deps
11:47:03 gibi if it is not the case then meh
11:48:30 lyarwood actually I don't need to break os-win out sorry, I thought it also had changes
11:48:54 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:49:00 gibi lyarwood: ack, no worries
11:52:23 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:30 brinzhang0 gibi: But we dont consider the authorican with proxy-->server yet, this is stephenfin concerned.
11:53:39 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:54 brinzhang0 gibi: yes, hope stephenfin can give the clear direction, or let we improve it in future.
11:54:06 stephenfin Hence why I'm testing things now
11:54:20 gibi thanks, now I see the confusion
11:54:30 openstackgerrit Lee Yarwood proposed openstack/nova master: hyper-v rbd volume support https://review.opendev.org/c/openstack/nova/+/763550
11:54:31 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:32 lyarwood stephenfin / gibi ; ^ okay that should finally do it for the hyperv rbd stuff
11:54:55 lyarwood lpetrut: ^ also sorry
11:54:57 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:58 gibi lyarwood: thanks. I will jump on it before I dissapeare again to a meeting
11:55:32 gibi stephenfin: I'm glad you picket it up, the vnc proxy stuff is a black hole to me at the moment
11:57:46 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:58:05 lpetrut lyarwood: thanks!
11:58:36 brinzhang0 this is also we were used daily^
11:58:49 lpetrut lyarwood: I'm wondering if there's any way in which we could automate this process, it's quite tedious
11:59:31 gibi lyarwood: I'm +2 on the bump
11:59:54 brinzhang0 stephenfin: we used the VNC tool is vnc viewer, maybe you can try
12:00:12 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:31 lyarwood lpetrut: something to bring up at the PTG I think, either we automate this or drop lower-constraints.txt
12:01:28 stephenfin pip doesn't have machinery for this. That's the main issue :-(
12:01:42 gibi here is the ptg etherpad if neede :) https://etherpad.opendev.org/p/nova-xena-ptg
12:01:54 stephenfin There's an open RFE against it (filed by dhellmann iirc) but it needs bodies of course
12:03:33 lyarwood oh it doesn't?
12:03:54 lyarwood huh I had assumed there was a lib or something we could call into to automate it, that's a shame
12:09:25 sean-k-mooney lyarwood: a min version resolver no uncortunetly not
12:09:52 sean-k-mooney lyarwood: we likely should restrict lower constratits to just our direct deps
12:10:14 sean-k-mooney possibly excluding any deps in test-requirements
12:11:09 sean-k-mooney for now i think we should contiue to have lower constraitns.
12:11:42 sean-k-mooney lyarwood: you should not be importing os-brick constratis versin into nova however
12:12:36 sean-k-mooney lyarwood: is the hyperv feature the only reason you are doing https://review.opendev.org/c/openstack/nova/+/778177
12:12:49 sean-k-mooney because we said we were not going to bump the min version for that
12:12:57 lyarwood that's a direct dependency
12:13:02 lyarwood the code doesn't work without that version
12:13:06 sean-k-mooney its an optional depency
12:13:16 lyarwood it's direct if you're using that codepath
12:13:20 sean-k-mooney yes
12:13:32 sean-k-mooney but its not when not using the hyperv driver
12:13:42 sean-k-mooney and we said we were not going to do an os-brick bump for that
12:13:43 lyarwood we'd never bump os-brick with that logic
12:14:06 lyarwood there have been plenty of examples in the past where we have done this to accomidate the libvirt driver
12:14:18 lyarwood I don't get how that's optional
12:14:26 sean-k-mooney true however it makes all lib deps viral
12:14:31 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: Add support for microversion v2.88 https://review.opendev.org/c/openstack/python-novaclient/+/770573
12:15:17 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:49 lyarwood right and that's in LC at present
12:16:04 sean-k-mooney this did not use to happen with the old resolver
12:16:12 lyarwood because it was broken
12:16:19 sean-k-mooney no i know how it worked
12:16:23 sean-k-mooney it was not broken
12:16:31 sean-k-mooney it just worked differently then we expected
12:16:42 sean-k-mooney and that had some useful cases
12:16:48 sean-k-mooney it had some negitives too
12:17:08 sean-k-mooney but we have regressed our ablity to state teh min verion of nova requirements with the new resolver
12:17:41 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:49 sean-k-mooney that is a very different statement

Earlier   Later