Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-02
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
12:18:25 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:19:12 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:24 sean-k-mooney for optional deps that was the correct behaivor
12:21:58 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:22:13 sean-k-mooney we could not do the bump
12:22:18 lyarwood land code that we know would fail with our current reqs?
12:22:26 sean-k-mooney there is no code path in any of our test coverage that will require this
12:22:43 lyarwood there is in third party for hyperv
12:22:48 sean-k-mooney lyarwood: it wont break our unit or funct test
12:22:56 lyarwood and?
12:23:00 sean-k-mooney lyarwood: right and they can install the dep
12:23:03 lyarwood we're still landing broken code
12:23:09 lyarwood it just feels wrong to me
12:23:25 lyarwood and in any case bumping os-brick like this pulls in a load of other fixes and improvements
12:23:28 sean-k-mooney so does importing deps form an optional lib
12:23:36 lyarwood I'd argue that we needed to do that this cycle anyway tbh
12:24:04 lyarwood there are no new deps there btw, just version bumps
12:24:06 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:13 sean-k-mooney oh i know
12:24:15 lyarwood the same would also apply
12:24:23 sean-k-mooney but we dont want every lib to be viral
12:24:41 sean-k-mooney you also have a smaller set of changes then the hyperv patch orginally had
12:25:07 lyarwood yeah I'm not sure where some of the changes in the original hyperv change came from but pip was happy with these

Earlier   Later