| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-02 | |||
| 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 | |
| 12:25:47 | lyarwood | aaaaaand something has already failed | |
| 12:25:53 | 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:26:23 | sean-k-mooney | the new resolver has changed the meanin of LC and expanded its scope | |
| 12:26:47 | sean-k-mooney | if we want to continue to use that i think we need to discuss what LC now means | |
| 12:27:32 | lyarwood | sean-k-mooney: yeah I've added a line in the ptg pad but feel free to rephrase the question | |
| 12:29:06 | sean-k-mooney | lyarwood: run tox with -r to recreate the env | |
| 12:29:16 | sean-k-mooney | or before that check the pip version | |
| 12:29:37 | sean-k-mooney | it wont automatically upgrade the pip version | |
| 12:29:52 | sean-k-mooney | so if the enve was created with the old resolver then it will still be using it | |
| 12:30:39 | sean-k-mooney | oh | |
| 12:30:43 | lyarwood | that's a different job | |
| 12:30:50 | sean-k-mooney | lyarwood: you forgot to update requirements.txt | |
| 12:30:52 | lyarwood | I'm just about to run it locally now | |
| 12:31:00 | sean-k-mooney | you only bumped the min in lc | |