| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-02 | |||
| 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 | |
| 12:31:09 | lyarwood | for the in-direct deps? | |
| 12:31:13 | lyarwood | I thought that wasn't required? | |
| 12:31:17 | sean-k-mooney | it is | |
| 12:31:30 | lyarwood | huh pip was fine without them | |
| 12:31:30 | sean-k-mooney | we also use those directly | |
| 12:31:44 | sean-k-mooney | pip is but this is the requiremetns check job | |
| 12:32:10 | sean-k-mooney | we dont allow the min in requirements.txt to differ form lc by policy in openstack | |
| 12:32:47 | sean-k-mooney | and that job enforces that while also check the markers match what is in GR/UC | |
| 12:33:28 | lyarwood | *sigh* | |
| 12:33:29 | 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:42 | lyarwood | yeah just building the venv now | |
| 12:34:10 | sean-k-mooney | it wont see this error since this is not part of nova | |
| 12:34:54 | lyarwood | the requirements venv | |
| 12:34:59 | lyarwood | not nova | |
| 12:35:02 | sean-k-mooney | ah | |