Wednesday, 2020-12-09

« Tuesday, 2020-12-08 Index Thursday, 2020-12-10 »
*** tosky has quit IRC00:00
*** slaweq has quit IRC00:05
*** slaweq has joined #openstack-nova00:08
*** tkajinam has quit IRC00:16
*** tkajinam has joined #openstack-nova00:16
*** imtiazc has joined #openstack-nova00:28
*** luksky has quit IRC00:29
*** macz_ has quit IRC00:39
*** ftarasenko has quit IRC00:53
*** benj_ has quit IRC00:54
*** zigo has quit IRC00:54
*** benj_ has joined #openstack-nova00:54
*** mlavalle has quit IRC01:04
-openstackstatus- NOTICE: The Gerrit service on review.opendev.org is being restarted quickly to make heap memory and jgit config adjustments, downtime should be less than 5 minutes01:09
prometheanfireany work on the updated mock support?  https://review.opendev.org/76568001:38
*** songwenping_ has quit IRC01:48
*** songwenping_ has joined #openstack-nova01:48
*** zzzeek has quit IRC01:52
*** zzzeek has joined #openstack-nova01:53
*** amotoki has quit IRC02:01
*** amotoki has joined #openstack-nova02:02
*** zzzeek has quit IRC02:05
*** zzzeek has joined #openstack-nova02:06
*** hamalq has quit IRC02:12
*** lifeless has quit IRC02:25
*** lifeless has joined #openstack-nova02:27
melwittprometheanfire: I resolved the remaining issues in the proposed patch but need someone to rebase it and handle the merge conflicts. I hoped stephenfin could help with that02:30
melwittI don't have as much of the context on the rest of the patch02:30
*** macz_ has joined #openstack-nova02:31
prometheanfiremelwitt: thanks for the update :D02:35
*** macz_ has quit IRC02:36
melwittnp02:37
*** READ10 has joined #openstack-nova02:59
*** hemanth_n has joined #openstack-nova03:01
*** songwenping__ has joined #openstack-nova03:13
*** songwenping_ has quit IRC03:16
*** mkrai has joined #openstack-nova03:16
*** jamesdenton has quit IRC03:17
*** jamesdenton has joined #openstack-nova03:18
*** psachin has joined #openstack-nova03:20
*** k_mouza has joined #openstack-nova03:37
*** k_mouza has quit IRC03:42
openstackgerritBrin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Update Servers APIs  https://review.opendev.org/c/openstack/nova/+/76429203:42
openstackgerritBrin Zhang proposed openstack/nova master: Replace all_tenants with all_projects in List Server APIs  https://review.opendev.org/c/openstack/nova/+/76531103:42
openstackgerritBrin Zhang proposed openstack/nova master: Replace tenants* with projects* of policies  https://review.opendev.org/c/openstack/nova/+/76531503:42
*** songwenping_ has joined #openstack-nova04:13
*** k_mouza has joined #openstack-nova04:13
*** songwenping__ has quit IRC04:16
*** k_mouza has quit IRC04:17
*** zzzeek has quit IRC04:19
*** zzzeek has joined #openstack-nova04:21
*** zzzeek has quit IRC04:26
*** zzzeek has joined #openstack-nova04:27
*** vishalmanchanda has joined #openstack-nova04:55
*** zzzeek has quit IRC05:26
*** arne_wiebalck has quit IRC05:27
*** yonglihe has quit IRC05:27
*** yonglihe has joined #openstack-nova05:28
*** arne_wiebalck has joined #openstack-nova05:29
*** zzzeek has joined #openstack-nova05:29
*** evrardjp has quit IRC05:33
*** evrardjp has joined #openstack-nova05:33
*** mkrai has quit IRC05:35
*** mkrai has joined #openstack-nova05:35
*** ratailor has joined #openstack-nova05:39
*** READ10 has quit IRC05:43
*** LinPeiWen has quit IRC05:45
*** mkrai has quit IRC05:54
*** zzzeek has quit IRC06:15
*** zzzeek has joined #openstack-nova06:17
*** gyee has quit IRC06:28
*** LinPeiWen has joined #openstack-nova06:31
*** zzzeek has quit IRC06:49
*** zzzeek has joined #openstack-nova06:51
*** damien_r has joined #openstack-nova07:04
*** damien_r has quit IRC07:05
*** lpetrut has joined #openstack-nova07:12
*** psachin has quit IRC07:17
*** ralonsoh has joined #openstack-nova07:19
*** zzzeek has quit IRC07:21
*** zzzeek has joined #openstack-nova07:23
LarsErikPmelwitt: I noticed whis was merged a few hours ago \o/ can it be backported to ussuri?07:25
*** dklyle has quit IRC07:34
*** lifeless has quit IRC07:54
*** lifeless has joined #openstack-nova07:56
*** tosky has joined #openstack-nova08:02
*** elod_pto is now known as elod08:05
openstackgerritMamduh proposed openstack/os-vif stable/ussuri: Refactor code of linux_net to more cleaner and increase performace  https://review.opendev.org/c/openstack/os-vif/+/76541908:06
*** tesseract has joined #openstack-nova08:12
gibiLarsErikP: sure, it can be backported. But please propose a backport to stable/victoria first then stable/ussuri08:12
*** andrewbonney has joined #openstack-nova08:13
*** rpittau|afk is now known as rpittau08:14
LarsErikPmelwitt: Uh.. Don't know what happended there. Forgot the link: https://review.opendev.org/c/openstack/nova/+/759348/08:15
LarsErikPgibi: Uhm.. not sure howto do that. Maybe melwitt could do it, as she fixed this originally? =)08:16
openstackgerritMamduh proposed openstack/os-vif stable/ussuri: Fix - os-vif fails to get the correct UpLink Representor  https://review.opendev.org/c/openstack/os-vif/+/76596708:18
openstackgerritLars Erik Pedersen proposed openstack/nova stable/victoria: Omit resource inventories from placement update if zero  https://review.opendev.org/c/openstack/nova/+/76617708:20
LarsErikPgibi: I found the button ^ :P08:20
LarsErikPshould I add reviewers? and.. there is merge conflicts in ussuri. not feeling comfortable to deal with that :S08:23
openstackgerritMamduh proposed openstack/os-vif stable/train: Refactor code of linux_net to more cleaner and increase performace  https://review.opendev.org/c/openstack/os-vif/+/76591208:25
gibiLarsErikP:added some stable cores to the review. Thanks for proposing the backport08:30
gibiLarsErikP: as for the ussuri backport, lets merge the victoria one first then I think melwitt can resolv the merge conflict in ussuri or I can take it if needed08:31
LarsErikPgibi: good plan :-) thanks so much!08:32
gibiLarsErikP: :)08:32
*** aj_mailing has joined #openstack-nova08:41
*** teoobo_ has joined #openstack-nova08:41
*** ociuhandu has joined #openstack-nova08:42
bauzasgood morning Nova08:44
*** zzzeek has quit IRC08:50
*** zzzeek has joined #openstack-nova08:50
*** ociuhandu has quit IRC08:52
gibibauzas: O/08:55
*** rcernin has quit IRC08:56
*** rcernin has joined #openstack-nova08:56
*** teoobo_ has quit IRC08:57
*** ociuhandu has joined #openstack-nova08:59
*** teoobo_ has joined #openstack-nova09:02
*** derekh has joined #openstack-nova09:02
*** CeeMac has quit IRC09:07
*** luksky has joined #openstack-nova09:10
*** xek__ has joined #openstack-nova09:16
*** zzzeek has quit IRC09:16
*** zzzeek has joined #openstack-nova09:17
*** fudunwei has joined #openstack-nova09:20
*** rcernin has quit IRC09:23
*** martinkennelly has joined #openstack-nova09:25
openstackgerritAdrian Chiris proposed openstack/os-vif stable/ussuri: Fix - os-vif fails to get the correct UpLink Representor  https://review.opendev.org/c/openstack/os-vif/+/76596709:30
*** rcernin has joined #openstack-nova09:32
*** zzzeek has quit IRC09:40
*** k_mouza has joined #openstack-nova09:40
*** zzzeek has joined #openstack-nova09:41
lyarwoodelod: morning, have you had anytime to look at the pip failures in stable before I start digging in?09:46
*** zzzeek has quit IRC09:46
lyarwoodelod: https://review.opendev.org/q/Ia2007bc63ef09931ea0197cef29d6a5614ed821a - I was checking in on this series and noticed that everything prior to victoria is failing with pip 20.2.409:47
elodlyarwood: good morning :) I'm looking at several issues now, which pip failures do you mean? :)09:48
lyarwoodelod: https://zuul.opendev.org/t/openstack/build/cb6247d4b3644045ab6d83a064e812c6 for example09:48
*** rcernin has quit IRC09:48
lyarwoodactually ussuri looks okay sorry09:48
lyarwoodERROR: Package 'bandit' requires a different Python: 2.7.17 not in '>=3.5'09:49
elodyes, this bandit is what I just started to look at09:49
*** zzzeek has joined #openstack-nova09:49
*** rcernin has joined #openstack-nova09:49
elodI guess we've got a new bandit version with incorrect setup.cfg :S09:49
elodbut haven't checked yet09:49
elodat least there was a release, for sure: https://pypi.org/project/bandit/#history09:51
lyarwoodoh it's just a new version that drops py2 support09:51
lyarwoodokay we can cap this easily on stable where we are still using py209:51
elodI'll look for the bandit changes and let's see if I can put this new version to disallow-list in global requirements09:53
lyarwoodhttps://github.com/PyCQA/bandit/releases/tag/1.6.3 it dropped py2 support09:54
lyarwoodelod: https://review.opendev.org/c/openstack/requirements/+/76617009:55
lyarwoodelod: I *think* that's enough right?09:55
elodthanks! setup.cfg looks ok ( https://github.com/PyCQA/bandit/blob/1.6.3/setup.cfg ) so I think this patch with the cap should be OK09:56
openstackgerritLee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host  https://review.opendev.org/c/openstack/nova/+/76577109:57
lyarwoodkk testing above09:57
elodmaybe we need to add that to global-requirements.txt09:59
lyarwoodhmm it's only a test-requirment in nova10:00
* lyarwood forgets if that's a valid thing to add to global-requirements10:01
*** zzzeek has quit IRC10:01
*** macz_ has joined #openstack-nova10:02
*** zzzeek has joined #openstack-nova10:03
elodlyarwood: it seems the patch won't work: https://opendev.org/openstack/requirements/src/branch/stable/train/blacklist.txt#L510:04
elodso if I understand correctly we need to add it to every branch in every test-requirements.txt :/10:05
elod* the bandit cap10:05
lyarwoodelod: in nova right?10:06
lyarwoodfun10:06
elodyes10:06
lyarwoodokay I'll do that now10:06
*** macz_ has quit IRC10:07
elod(and "fortunately" I see lots of bandit failures all along other openstack repos :/ so it will be a nice amount of bandit patch if I'm not mistaken...)10:07
stephenfinlyarwood: elod: We should probably move bandit and other linters out of test-requirements.txt and into tox.ini since they're not subject to upper-constraints10:08
stephenfinhttps://github.com/openstack/python-openstackclient/blob/master/tox.ini#L31-L3410:08
stephenfinfrom https://github.com/openstack/python-openstackclient/commit/20769cd7b27d51da84a324a17922427eba5c6eac10:09
lyarwoodstephenfin: we can start doing that on master10:09
lyarwoodstephenfin: I'm not sure we want to change that on stable however right?10:09
stephenfinI wouldn't see a reason not to, assuming your issue is derived from the new pip 20.3 resolver, rather than simply uncapped requirements10:10
stephenfinIf it's the latter, obviously just cap them and be done with it, sure10:10
lyarwoodit's the latter sorry, I assumed it was pip to begin with10:11
openstackgerritLee Yarwood proposed openstack/nova stable/train: Cap bandit at 1.6.2 when using py2  https://review.opendev.org/c/openstack/nova/+/76617110:11
stephenfinah, then yes, cap all the way10:11
lyarwoodbut it just wasn't capped10:11
lyarwoodokay lets try this again10:13
elodhmmm, stephenfin I don't see the benefit of movint from test-req to tox.ini. we use capping in test-req, too10:13
stephenfinelod: not for linters, you don't10:13
stephenfinhttps://github.com/openstack/requirements/blob/master/blacklist.txt10:13
lyarwoodas we just found out :)10:13
openstackgerritLee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host  https://review.opendev.org/c/openstack/nova/+/76577110:13
elodbut that just mean there shouldn't be a global cap10:13
elodin test-req it's OK10:14
elodat least this is how I understand :)10:14
stephenfinHmm, I recall seeing something from mordred about this a while ago on openstack-discuss. Wonder if I can find it...10:14
lyarwoodactually let me write up a bug for this10:16
stephenfinelod, lyarwood: Okay, this is what I was thinking of http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013642.html10:16
elodjust found it, too, but have to re-read :)10:17
stephenfinNot exactly it, but it does describe the issue I was seeing with OSC. Specifically "That means we uninstall and reinstall flake8 at different versions over and over again - and the final state is not one that is completely consistent."10:17
stephenfinpip went nuts when those were included10:17
stephenfinWith that said, we have out own hacking plugins and tests for same, which means we do actually depend on those things to run unit tests. I don't know what the answer for that is :-\10:18
stephenfinMaybe it's just "Not A Problem" (TM)? :)10:18
openstackgerritLee Yarwood proposed openstack/nova stable/train: Cap bandit at 1.6.2 when using py2  https://review.opendev.org/c/openstack/nova/+/76617110:20
openstackgerritLee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host  https://review.opendev.org/c/openstack/nova/+/76577110:20
lyarwoodoh wait, so adding the cap in test-reqs isn't going to work?10:20
elodthe uninstall and reinstall is mainly a problem in devstack. but test-req installation is removed in devstack, so that's not a problem anymore.10:20
elodlyarwood: i think it will work10:21
lyarwoodokay something is still installing bandit in the grenade jobs as well on stable/train FWIW10:22
lyarwoodbrb10:22
elodthe question is whether there are some benefit if we move linters to tox.ini instead. which I don't see yet, as that would add another place where we should look for dependencies... but maybe I'm wrong :X10:22
stephenfinelod: Is it actually a dependency? You don't need it to run the main code nor the tests (for anything that doesn't have tests for custom linters, that is). It's a dependency but only in the same way tox is a dependency10:24
lyarwoodstephenfin: there's a bandit env in tox10:25
lyarwoodstephenfin: I assume that's why it's there?10:25
stephenfinI don't get you. wdym?10:25
lyarwood[testenv:bandit]10:26
lyarwood# NOTE(browne): This is required for the integration test job of the bandit10:26
lyarwood# project. Please do not remove.10:26
lyarwoodenvdir = {toxworkdir}/shared10:26
lyarwoodcommands = bandit -r nova -x tests -n 5 -ll10:26
lyarwood^ in tox.ini on stable/train10:26
*** littlebogfury11 has joined #openstack-nova10:26
stephenfinoh, okay, I'm not saying we don't need to specify bandit somewhere. I'm saying we don't need to do it in test-requirements.txt because it doesn't need to be subject to e.g. lower-constraints checks10:27
stephenfinwe can do it in tox.ini instead10:27
lyarwoodah right sorry10:27
lyarwoodyeah well I get elod's point that it's just another place to look for deps but if it isn't needed outside of that tox env then I'd be okay with just listing it there in tox.ini10:27
stephenfinIn case it helps, the way I was diagnosing those lower-constraints jobs yesterday was to create a new virtualenv, update pip and run the same command as the lower-constraints tox target10:28
lyarwooddo you want to push a change on master?10:28
stephenfinI had to do that because on Fedora 33, I get Python 3.9 in my virtualenv which isn't compatible with a few of the dependencies10:28
*** littlebogfury11 has quit IRC10:28
lyarwoodyeah I just hacked the base python version when working on this the other day10:28
lyarwoodupgraded pip and reproduced the issue10:29
lyarwoodbut that's different to this issue again10:29
stephenfinFair10:29
lyarwoodthis was just an uncapped dep dropping py2 support10:29
* stephenfin idly wonders if we should start setting basepython for lower-constraints job10:29
lyarwoodtbh I think we might need to do that until py39 is actually supported10:29
lyarwoodotherwise some of us on modern distros get stung all the damn time10:30
stephenfinyuuup10:30
stephenfinfwiw, you can also do this10:30
lyarwoodoh cool there's a LC failure now on stable/train as well10:31
stephenfinTOX_CONSTRAINTS_FILE=lower-constraints.txt tox -e py3610:31
stephenfinsub UPPER_ for TOX_ on pre-victoria iirc10:31
stephenfin \o/10:31
elodwasn't there another discussion in mailing list that the usage of basepython is discouraged? o:)10:31
*** rcernin has quit IRC10:31
stephenfinunless this was recently, I fixed that10:32
lyarwoodERROR: No matching distribution found for hacking<1.2.0,>=1.1.010:32
lyarwood^ stephenfin was that the LC issue you were working on?10:32
elodthis 'no matching distro' issue seems more like some mirror thing to me. (and again, I might be wrong :X)10:33
stephenfinNot that exact, but it looks familiar. That happens because it can't match the dependencies of that hacking version with those required by other dependencies10:33
stephenfinIt's very misleading10:33
lyarwoodyeah I thought that the other day but talking to fungi we found https://review.opendev.org/c/openstack/nova/+/76582410:34
lyarwoodstephenfin: yeah indeed it's an awful error message10:34
*** brinzhang_ has quit IRC10:34
elod:S10:35
lpetruthi, I have a quick question about the lower-constraints file: it's supposed to contain only direct dependencies, right? for example, if we need package x, which in turn requires package y, would package y need to be in lower-constraints.txt?10:38
*** littleboyfury has joined #openstack-nova10:39
stephenfinlpetrut: it would, yes10:39
stephenfinHowever, we haven't been very good around managing that since the tooling situation is quite poor10:39
stephenfinSo I don't think anyone is going to hold it against you in a review10:40
lpetrutstephenfin: thanks for clearing it out. yep, it's really difficult to maintain, I was hoping to be able to limit lower-constraints to direct dependencies10:41
lpetrutbut I guess that would affect its usefulness10:41
*** brinzhang has joined #openstack-nova10:42
lyarwoodstephenfin: which version of py36 are you using btw?10:43
*** jangutter has quit IRC10:43
*** jangutter has joined #openstack-nova10:44
lyarwoodstephenfin: everything is borked for me with 3.6.12 with setuptools 49.1.3 /o\10:44
lyarwoodand https://github.com/pypa/setuptools/issues/201710:45
* lyarwood screams into the void10:45
stephenfinI was using 3.6.12, but that was with OSC, not nova10:45
lpetrutlywarwood: looks like I'm not the only one having a hard time chasing Python dependencies :)10:46
lyarwoodyeah it's failing to install MarkupSafe==1.010:46
lyarwoodlpetrut: yup don't you just love python some days? :)10:46
*** ociuhandu has quit IRC10:47
sean-k-mooneylowerconstriat has more then direct depencies. it was auto generated using pip freeze10:51
*** LinPeiWen has quit IRC10:51
sean-k-mooneywe have removed some of the indirect deps but not all of them10:51
*** ociuhandu has joined #openstack-nova10:51
*** dtantsur|afk is now known as dtantsur10:52
sean-k-mooneylyarwood: just be glad your not dealing with nodejs10:52
*** littleboyfury has quit IRC10:52
*** rcernin has joined #openstack-nova10:53
*** littleboyfury has joined #openstack-nova10:54
*** mkrai has joined #openstack-nova10:56
*** littleboyfury has quit IRC11:02
*** littleboyfury has joined #openstack-nova11:05
stephenfinlyarwood: you've probably figured this out already but https://github.com/openstack/nova/blob/stable/train/lower-constraints.txt#L3711:05
stephenfinhttps://github.com/openstack/nova/blob/stable/train/test-requirements.txt#L511:06
lyarwoodyeah I've been trying to prove that was the issue but I can't build a venv11:06
lyarwoodlet me squash this into my other change11:06
stephenfinI'm doing11:07
stephenfindeactivate; rm -rf .venv; virtualenv .venv --python=python3.6; source .venv/bin/activate; pip install --upgrade pip; pip install -vvv -c lower-constraints.txt 'hacking>=1.1.0,<1.2.0'11:07
stephenfinon repeat11:07
stephenfinwhile playing with lower-constraints.txt11:07
openstackgerritLee Yarwood proposed openstack/nova stable/train: Cap bandit and raise hacking lower-constraint  https://review.opendev.org/c/openstack/nova/+/76617111:09
openstackgerritLee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host  https://review.opendev.org/c/openstack/nova/+/76577111:09
lyarwoodoh right because that moves flake etc11:10
lyarwoodgah11:10
lyarwoodso broken11:10
stephenfinI wonder if we can start using train-era virtualenv and pip?11:11
openstackgerritLee Yarwood proposed openstack/nova stable/train: Cap bandit while also raising hacking and flake lower-constraints  https://review.opendev.org/c/openstack/nova/+/76617111:13
openstackgerritLee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host  https://review.opendev.org/c/openstack/nova/+/76577111:13
lyarwoodmy issue was more with the version of setuptools being pulled in by default by virtualenv, I don't think that's tied to the version of virtualenv itself right?11:14
stephenfinI think it is11:14
lyarwoodah11:14
lyarwoodI thouight that was a python version thing11:14
stephenfinI saw something from fungi...somewhere this morning11:14
sean-k-mooneystephenfin: im not sure about that you can tell virtualenv to download and decompress setuptools11:14
sean-k-mooneyi think by default it uses your host copy11:15
sean-k-mooneythere is a --setuptools<version> flag11:15
stephenfinif that was the case, why is the gate failing? They (Canonical) are hardly releasing new versions of pip on 18.04 still11:16
sean-k-mooney--download might also be needed11:16
sean-k-mooneybut i think that is for latest11:16
openstackgerritLee Yarwood proposed openstack/nova stable/train: [stable-only] Cap bandit while also raising hacking and flake lower-constraints  https://review.opendev.org/c/openstack/nova/+/76617111:17
openstackgerritLee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host  https://review.opendev.org/c/openstack/nova/+/76577111:17
sean-k-mooneystephenfin: is it devstack or tox11:17
stephenfinlyarwood: this works for me http://paste.openstack.org/show/800886/11:17
sean-k-mooneythe job that is failing11:17
sean-k-mooneydevstack install pip its self11:17
*** zzzeek has quit IRC11:17
stephenfinI didn't have to bump bandit, weirdly :-\11:17
lyarwoodhuh weird I didn't need the stestr changes11:18
lyarwood\o/11:18
lyarwoodeither way lets see what the gate says11:18
stephenfinlyarwood: for me, it complains that oslo.test 2.6.0 needs stestr 2.0.011:18
lyarwoodthat makes sense11:18
*** zzzeek has joined #openstack-nova11:18
lyarwoodstephenfin: oh sorry I was using your previous command11:20
lyarwoodstephenfin: right so yeah it does, let me update that now11:20
stephenfinah, whoops, yeah, you need to append '-r requirements.txt .'11:20
stephenfinhahahaha http://paste.openstack.org/show/800887/11:21
stephenfinthat's some dependency tree11:21
stephenfin(from pipdeptree)11:21
stephenfinsean-k-mooney: you were complaining about nodejs? ^11:22
openstackgerritLee Yarwood proposed openstack/nova stable/train: [stable-only] Cap bandit while also raising hacking, flake and stestr LCs  https://review.opendev.org/c/openstack/nova/+/76617111:23
openstackgerritLee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host  https://review.opendev.org/c/openstack/nova/+/76577111:23
*** aj_mailing has quit IRC11:24
*** tesseract has quit IRC11:25
stephenfinI think it's fair to say the idea of maintaining a comprehensive list of lower-constraints will die pretty soon now11:25
*** tesseract has joined #openstack-nova11:25
sean-k-mooneystephenfin: that has many many duplicates11:26
stephenfinunless that list is updated somewhat regularly, we're going to be playing whack-a-mole as it ages (and it's already pretty well aged)11:26
sean-k-mooneywell we are not ment to update it ever for stable brances11:26
sean-k-mooneyits only ment to be updated on master11:27
stephenfinyou've no choice here. It was wrong11:27
sean-k-mooneyit was working previously11:27
lyarwood`working`11:27
lyarwoodit wasn't11:27
stephenfinno, it wasn't11:27
lyarwoodit's been borked for a while looking at this11:27
sean-k-mooneyit was passing ci11:27
lyarwoodpip wasn't resolving the deps correctly11:27
stephenfindef test_advanced_feature(self):11:27
stephenfin    pass11:27
lyarwoodit does now and so it's failing in CI11:27
sean-k-mooneybecause of the constrits file?11:28
stephenfinadvanced feature is working :)11:28
lyarwoodthe new resolver appears to be doing things correctly11:28
lyarwoodthe old one didn't11:28
stephenfinpreviously, the resolver didn't go more than one dependency deep11:28
sean-k-mooneythis is a behviaor change11:28
lyarwoodhaha really11:28
sean-k-mooneywe should not be usein gthe new resolve on stable11:28
stephenfinso if you required foo=1.0.0 and bar=2.0.0, but bar required foo=1.2.0, it would work11:28
stephenfinand it no longer will11:29
lyarwoodwe capped at 20. something but it looks like this has been backported in pip?11:29
stephenfinthis is 20.311:29
lyarwoodso unless we lower the cap again11:29
sean-k-mooneystephenfin: the behvioar of the old resovler was if somethign is listed twice we use the first value11:29
stephenfinso we need to cap at less than that11:29
lyarwoodyeah I thought 21. broke us11:29
lyarwoodwith the new resolver11:29
sean-k-mooneythat was why the order of deps mattered11:29
stephenfinnah, they clearly don't use semver this isn't a major release11:30
stephenfin*to say this11:30
sean-k-mooneyso we need to cap pip right11:30
stephenfinah, it's calver11:30
sean-k-mooneyand not modify the lower constraits11:30
stephenfinwe're not changing anything11:31
lyarwoodoh it was 20.311:31
sean-k-mooneystephenfin: you not going to modify lower-constraits on stable. ok11:31
lyarwoodhttps://review.opendev.org/c/openstack/devstack/+/764803 was what I was thinking about in devstack11:31
stephenfinno, we are, but it won't change anything11:31
stephenfinbecause pip wasn't using that11:32
stephenfinyou can prove it locally too11:32
sean-k-mooneypip was in the lower constraits job11:32
stephenfinvirtualenv .venv --python=python3.6; source .venv/bin/activate; pip install 'pip<20.3'; pip install -c lower-constraints.txt -r requirements.txt -r test-requirements.txt .11:32
sean-k-mooneythe semantics of the old resovler was if it saw x==1 and later x==2 it ignored the x==211:32
stephenfinthen do pip freeze11:33
stephenfinyou'll get stestr 2.0.0 and hacking 1.1.011:33
lyarwoodso there was a comment in #openstack-infra that a virtualenv bump introduced pip 20.3 btw11:33
stephenfin(do that on stable/train, obviously)11:33
lyarwoodI'm in favor of fixing LC tbh11:33
stephenfinAs am I11:33
lyarwoodyes it's a change but it's a fix11:33
stephenfinyup11:34
lyarwoodand ultimatley you should end up with the same env11:34
*** ociuhandu has quit IRC11:35
lyarwoodbrb11:35
*** ociuhandu has joined #openstack-nova11:49
elodbtw, in old stable branches pip should not be version 20.3. so I wonder where this new behavior comes from... :/11:49
elod(as for example, clearly 'hacking===0.12' (in LC) should have contradicted with hacking>=1.0.0 (in test-req) for ages)11:52
elodand pip 20.3 resolver issue only appeared in grenade jobs, where pip is bootstrapped directly from pypi... hmmm...11:54
lyarwoodelod: I think the tox jobs are using it now after a virtualenv change that pulls in pip 20.3 by default11:55
elodlyarwood: oh. interesting. so that's why :/11:57
*** tbachman has quit IRC11:57
*** ociuhandu_ has joined #openstack-nova11:58
lyarwoodelod: that said devstack is now failing to deploy swift so maybe we do need https://review.opendev.org/c/openstack/devstack/+/764876 on stable/train11:58
*** ratailor has quit IRC11:59
*** ociuhandu has quit IRC12:02
*** rcernin has quit IRC12:04
elodlyarwood: it was/is there in since newton :) https://review.opendev.org/c/openstack/devstack/+/26995412:05
elodso the issue must be something new with swift :/12:06
*** imtiazc has quit IRC12:09
*** waverider has joined #openstack-nova12:13
lyarwoodhmmm I'm not sure that's used with devstack-gate and grenade12:14
openstackgerritLee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host  https://review.opendev.org/c/openstack/nova/+/76577112:14
openstackgerritLee Yarwood proposed openstack/nova stable/train: libvirt: Remove native LUKS compat code  https://review.opendev.org/c/openstack/nova/+/76621012:14
lyarwoodeither way <= stable/train is borked now12:14
*** JamesBenson has joined #openstack-nova12:16
lyarwoodah wait the bandit issue isn't related to pip it's just a broken release for py212:19
lyarwoodgah this is fun12:19
lyarwoodcinder is attempting to install it as well12:20
elodlyarwood: I thought that too first, but as I saw in bandit's setup.cfg it should be OK... or there is something that I'm missing... :X12:23
elodok, meanwhile I read back the opendev infra and there are some things explained, too (new pip causes the errors; new pip is pulled in by latest virtualenv; latest virtualenv is installed via ensure-tox task -- http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2020-12-08.log.html#t2020-12-08T15:05:27 )12:29
elodso now I get why there are latest pip on old stable jobs :/12:32
lyarwoodis there a cli for codesearch.opendev.org?12:36
elodlyarwood: yes, beagle12:38
lyarwoodelod: ack thanks12:40
openstackgerritLee Yarwood proposed openstack/nova stable/train: [stable-only] Cap bandit while also raising hacking, flake and stestr LCs  https://review.opendev.org/c/openstack/nova/+/76617112:41
openstackgerritLee Yarwood proposed openstack/nova stable/train: libvirt: Remove native LUKS compat code  https://review.opendev.org/c/openstack/nova/+/76621012:41
openstackgerritLee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host  https://review.opendev.org/c/openstack/nova/+/76577112:41
lyarwoodhmm that doesn't let you search by branch12:49
*** ociuhandu_ has quit IRC12:51
*** ociuhandu has joined #openstack-nova12:51
sean-k-mooneylyarwood: ya its master only12:51
elodjust as hound12:58
lyarwoodelod: coming back to the pip issue, do we want to pin the version of virtualenv?13:00
lyarwoodelod: on stable that is13:00
elodlyarwood: I don't see yet how we can do it, as it is installed via ensure-tox zuul task13:01
sean-k-mooneyelod: virtualenv has a --pip <version> flag13:02
sean-k-mooneyso we can add a var to ensure tox for the version13:02
*** littleboyfury has quit IRC13:02
sean-k-mooneyleave it undefiend to the current behavior13:02
elodhmmm, that could work13:03
sean-k-mooneyand override it in the openstack-tox definion per branch13:03
elodsorry, need to go AFK, bbl13:04
*** mkrai has quit IRC13:05
*** mkrai has joined #openstack-nova13:05
*** ociuhandu has quit IRC13:06
*** ociuhandu has joined #openstack-nova13:08
*** hemanth_n has quit IRC13:12
*** ociuhandu has quit IRC13:16
*** waverider has quit IRC13:18
*** martinkennelly has quit IRC13:22
*** ociuhandu has joined #openstack-nova13:24
*** ociuhandu has quit IRC13:24
*** martinkennelly has joined #openstack-nova13:24
elodok, I'm back13:26
elodsean-k-mooney: thanks for the idea, I'm looking at if I can make it work13:26
lyarwoodI can back the lower-constraints changes out of https://review.opendev.org/c/openstack/nova/+/766171 and just handle the bandit cap there13:27
*** martinkennelly has quit IRC13:27
lyarwoodif we can work out a way of capping virtualenv for the tox jobs13:27
*** martinkennelly has joined #openstack-nova13:28
*** k_mouza has quit IRC13:28
*** k_mouza has joined #openstack-nova13:28
openstackgerritLee Yarwood proposed openstack/nova stable/train: [stable-only] Cap bandit to 1.6.2  https://review.opendev.org/c/openstack/nova/+/76617113:30
openstackgerritMamduh proposed openstack/os-vif stable/stein: Refactor code of linux_net to more cleaner and increase performace  https://review.opendev.org/c/openstack/os-vif/+/76591413:37
elodok, one more addition, the failure came already before the virtualenv 20.2.2 was released... e.g.: https://d13e36a31c498ea1cea8-86befd0513c66a7b4cc05c94ded6a0d4.ssl.cf1.rackcdn.com/periodic-stable/opendev.org/openstack/nova/stable/train/openstack-tox-py27/3fb6863/job-output.txt13:37
elodso there should be something else that pulls in latest pip :'(13:38
lyarwoodelod: two different problems13:39
lyarwoodelod: the bandit failure is just with the 1.6.3 release13:39
elodlyarwood: yes, sorry, you are right13:39
elodmy bad :X13:39
lyarwoodelod: and for that I honestly think we need to remove it from the blacklist in requirements13:39
lyarwoodelod: otherwise we need to update all projects etc13:40
lyarwoodelod: for both stable/train and stable/stein13:40
lyarwoodelod: thanks to grenade13:40
elodlyarwood: the problem is that it could cause another repositories to break (according to the comment in blacklist.txt) :/13:41
elodhowever it would be the most convenient way13:41
*** martinkennelly has quit IRC13:42
elodotherwise lots of branches in lots of repos needs to be patched separately :/13:42
lyarwoodelod: I'll propose it and post to the ML13:42
lyarwoodelod: yeah indeed13:42
elodlyarwood: thanks! let's see what we can do13:43
*** tbachman has joined #openstack-nova13:44
elodlyarwood: or maybe if bandit 1.6.3 gets yanked... there's already the issue reported: https://github.com/PyCQA/bandit/issues/66313:48
lyarwoodelod: ah cool13:53
*** ociuhandu has joined #openstack-nova14:00
*** waverider has joined #openstack-nova14:04
*** ociuhandu has quit IRC14:07
*** ociuhandu has joined #openstack-nova14:11
bauzasgibi: around ?14:19
bauzasgibi: I was looking at your comment for https://review.opendev.org/c/openstack/nova/+/749068/2/nova/scheduler/request_filter.py@32714:19
bauzasactually, I think we need to discuss about why we shouldn't be get required_aggregates14:20
bauzasthis would be because Neutron doesn't create those aggregates14:20
sean-k-mooneywhich aggreates14:22
bauzas(well, Nova would create those aggregates as per https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html step 10 )14:22
bauzassean-k-mooney: see ^14:22
sean-k-mooneyneutron creates the nova host aggates and addes server too it for the routed networks14:22
sean-k-mooneyi.e. neutron calls nova api and relyes on the replciation fo those host aggrates to placment aggreates14:23
bauzassean-k-mooney: is that nova or neutron ?14:23
*** johanssone has quit IRC14:23
bauzasah-ha ok14:23
bauzasok, so neutron directly asks the nova api to create the nova aggregates which then automatically creates the placement one14:24
bauzaskk14:24
bauzasso14:24
*** bbowen has quit IRC14:24
*** teoobo_ has quit IRC14:24
*** bbowen has joined #openstack-nova14:24
sean-k-mooneyhttps://github.com/openstack/neutron/blob/master/neutron/services/segments/plugin.py#L272-L28914:24
sean-k-mooneyyes when its creatign the RPs and inventories14:25
bauzasif an operator uses this prefilter for routed networks, then in case we can't find a routed network related aggregate, should we accept to find any host ?14:25
sean-k-mooneyno i dont think so14:25
bauzas(I mean , when a user asks for a network when creating the instance)14:25
*** johanssone has joined #openstack-nova14:26
sean-k-mooneycan you rephase do you mean "openstack server create --network "14:26
sean-k-mooneyor somethign else14:26
bauzasyup, this14:27
sean-k-mooneyif a server has a port that is connected to a routed network we shoudl always reuiqre the aggreate if the prefilter is enabled14:28
bauzassean-k-mooney: look at https://review.opendev.org/c/openstack/nova/+/749068/2/nova/scheduler/request_filter.py14:28
sean-k-mooneyneutron does not allow mixing routed subnets and unrouted subnets in the same network14:28
bauzassean-k-mooney: and gibi's concern on L32714:28
bauzasactually, the prefilter won't ask for any aggregate if we can't find them14:29
bauzasit's just the method which would be returning either False or True14:29
sean-k-mooneyso we shoudl be rejecting the request14:29
bauzasbut,14:29
bauzasreturning False won't do anything AFAICT14:29
sean-k-mooneyi mean raise an excption14:30
*** noonedeadpunk has quit IRC14:30
bauzassean-k-mooney: k, i see14:31
bauzassean-k-mooney: that said, just a question14:31
bauzasgiven two networks14:31
bauzasone having routed segments, and one without any routed segments14:31
bauzasneutron would then create aggregates for the routed segments mapping to net114:32
bauzasbut wouldn't do anything for net2, right?14:32
sean-k-mooneyin that case you want the intersection fo the aggreates14:32
sean-k-mooneyyes14:32
sean-k-mooneywell not the intersection14:32
bauzassean-k-mooney: k, so if a user is passing net2 when creating the instance, then we should be accepting it14:32
bauzasand not rejecting the instance creation14:33
sean-k-mooneyyes althoughg its unlikely that there will be a mix14:33
*** noonedeadpunk_ has joined #openstack-nova14:33
sean-k-mooneyits vlaid but you tend to have one or the other14:33
bauzassure, but then the fact that we can't find aggregates for this network doesn't mean it's a blocker14:33
sean-k-mooneycorrect14:33
bauzashence us not rejecting it14:33
sean-k-mooneyits only an issue if its a routed network14:34
bauzasso we should keep it valid14:34
sean-k-mooneysince that should always have an aggreate per segment14:34
bauzasand me just accepting gibi's change to turn it into True14:34
sean-k-mooneyyou still need to rais in the routed case i think14:34
bauzassean-k-mooney: sure but the prefilter doesn't know why the aggregate wasn't there14:34
bauzasnova only knows about aggregates14:34
sean-k-mooneybut it know if its a routed network request right?14:35
bauzashow?14:35
sean-k-mooneyfrom the presence of a segment on the neutron subnet14:35
bauzasrequested_networks is there for *any* network query14:35
sean-k-mooneyor ip_allocation=defer14:35
bauzassean-k-mooney: sorry but again, we don't know it14:36
*** ociuhandu has quit IRC14:36
sean-k-mooneyutils.get_aggregates_for_routed_network is calling neutron14:36
sean-k-mooneyso it can check14:36
*** dcapone2004 has joined #openstack-nova14:37
sean-k-mooneyhttps://review.opendev.org/c/openstack/nova/+/749068/2/nova/network/neutron.py#353914:38
sean-k-mooneyif that retuns segments then its a routed netork14:38
bauzaswell, shit, you're right14:38
bauzaswe can raise an exception accordingly14:38
bauzasand we do actually14:40
bauzassean-k-mooney: https://review.opendev.org/c/openstack/nova/+/749068/2/nova/scheduler/utils.py@138314:40
bauzasaaaand we actually do this for *any* segment, which is bad and probably why I'm getting large number of issues14:42
bauzasI think I found a bug :)à14:42
gibibauzas: sorry, I have to get back to you with this I had a complicated day so fat14:43
*** ociuhandu has joined #openstack-nova14:43
gibifar14:43
bauzasheh no worries14:44
sean-k-mooneybauzas: raising PlacementAPIConnectFailure is not really the best14:44
bauzassean-k-mooney: mriedem did that I think in case of any placement call issues14:44
sean-k-mooneyya but its not nessialy a connection issue14:44
bauzasagreed14:45
sean-k-mooneyin this case however i dont know if we need to call placemnet at all14:45
sean-k-mooneydont we mirror the aggreate to placement using the hostaggret uuid for the placement aggreate uuid14:45
sean-k-mooneyi think we can just do an api db lookup instead14:45
bauzascorrexct14:45
sean-k-mooneythis is how neutron creates the hostaggret14:46
bauzasI see your point14:46
bauzasif neutron creates a nova aggregate, then I'm ok with your proposal14:46
bauzasI wouldn't be OK if neutron was creating a placement aggregate directly14:47
sean-k-mooneyyep it does then it lookup the uuid of the created nova aggrate and uses that to add its RP too the placment aggreate14:47
bauzasyour point is fair, I'll change it14:47
sean-k-mooneythe nova aggreate is named 'Neutron segment id %s' % segment_id14:47
bauzasthat being said, just a left concern,14:48
bauzasif a user passes net2 when creating14:48
fungisorry, was in meetings... i'd never seen pipdeptree before, that's a rather awesome tool14:48
bauzassean-k-mooney: (with net2 having no routed segments)14:48
sean-k-mooneyit wont enter the for14:49
bauzassean-k-mooney: in this case, we would ask neutron to give us net2's segments, right?14:49
sean-k-mooneyyep network_api.get_segment_ids_for_network woudl retrun None or [] i think14:49
bauzasoh14:49
fungiand yeah, i've long asserted that to generate a consistent set of lower constraints you'd need to make it with something like a hacked pip which tries to solve for lowest rather than highest satisfying version of every dependency in the transitive set14:49
sean-k-mooneyit returns []14:50
sean-k-mooneypy14:50
bauzassean-k-mooney: https://review.opendev.org/c/openstack/nova/+/749068/2/nova/network/neutron.py#354814:50
bauzassean-k-mooney: say a net2 is not configured for routed networks14:50
bauzassean-k-mooney: what would this API return ?14:50
sean-k-mooneyi would expect an empty list but lets see what the api ref says14:51
bauzasI was thinking that a segment API resource was not only for routed networks14:52
sean-k-mooneynot is routed netowrks only14:52
sean-k-mooneyhttps://docs.openstack.org/api-ref/network/v2/index.html?expanded=list-segments-detail#list-segments14:52
sean-k-mooneywe are using the list endpoint14:52
fungiwhen the idea of lower constraints jobs was first proposed some years back, i suggested that if people really wanted to do that they should work with the pip maintainers to implement some option to invert version selection, because otherwise the constraints lists wouldn't really be complete or internally consistent... folks said "meh it's good enough" and just punted by guessing some constraints14:52
sean-k-mooneyso that shoudl return an empy list14:52
sean-k-mooneyill check on my home cloud14:52
bauzassean-k-mooney: ack, thanks14:52
sean-k-mooneyi think the query sting is wrong by the way14:57
sean-k-mooney?network_id=%sfields=id i think should be ?network_id=%s&fields=id14:57
sean-k-mooneyhttps://review.opendev.org/c/openstack/nova/+/749068/2/nova/network/neutron.py@354814:57
*** waverider has quit IRC15:01
sean-k-mooneybauzas: ok so i dont have the resouce in my api15:02
sean-k-mooneyi guess i dont have the api extion enabled15:02
sean-k-mooneywhich ill check now15:02
bauzasK15:02
bauzasthanks for helping, btw.15:02
*** waverider has joined #openstack-nova15:03
* bauzas just awaits for sean-k-mooney's results but also some French's Council of State court procedure about skiing ban in France :)15:04
sean-k-mooneyso ya i dont have the segments extnsion enabled http://paste.openstack.org/show/800901/15:05
sean-k-mooneywhich mean that we also need to check for that in the nova code15:06
sean-k-mooneyits just called segment https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/segment.py#L2915:06
bauzassean-k-mooney: well, we raise_exc=False15:08
gibibauzas: now I read back, It is OK to me what you and sean-k-mooney come up with15:10
*** ociuhandu has quit IRC15:11
sean-k-mooneybauzas: so we check if the multi provide net extension exist here https://review.opendev.org/c/openstack/nova/+/749068/2/nova/network/neutron.py#352415:12
sean-k-mooneybut we shoudl be checking if the segment extions exists15:12
*** sapd1 has joined #openstack-nova15:13
bauzasthis sounds a reasonable ask15:14
*** hoonetorg has quit IRC15:14
sean-k-mooneywe can cache it the same way we do with the other check so we only do it once.15:14
bauzassean-k-mooney: but my question remains open, do we get an empty list for a network that doesn't do routed segments or whatever else ?15:15
*** ociuhandu has joined #openstack-nova15:15
sean-k-mooneythe api ref does not say but i would expect the list endpoint which we are calling to return an empty list15:16
sean-k-mooneyi can check there unit tests15:16
bauzassean-k-mooney: thanks15:17
stephenfinbauzas, lyarwood, gibi, (anyone else): This is not high priority work, but I have an ass-load of OSC patches that would benefit from some nova devs' eyes15:18
stephenfin https://review.opendev.org/q/project:openstack/python-openstackclient+status:open+file:compute+owner:stephenfin%2540redhat.com15:18
gibistephenfin: now queued them for review15:18
stephenfinI've been skimming through novaclient commands, mapping them to OSC equivalents, and figuring out what's missing. I'm getting very close to feature parity with those and know where the remaining gaps are15:19
stephenfingibi: \o/ thanks!15:19
bauzasstephenfin: opened the link but later, I'm sorry15:19
stephenfinLater is good. This is low priority. I just want it to move _eventually_ :)15:19
bauzasstephenfin: ping me tomorrow morning then15:19
* stephenfin would like to be done with OSC gaps in Wallaby15:19
*** ociuhandu has quit IRC15:20
lyarwoodstephenfin: ack open, I'll start looking through them now15:20
gibistephenfin: there is a probable mitigation for the long standing bug 1823251 https://review.opendev.org/c/openstack/nova/+/76530015:23
openstackbug 1823251 in OpenStack Compute (nova) "Spike in TestNovaMigrationsMySQL.test_walk_versions/test_innodb_tables failures since April 1 2019 on limestone-regionone" [High,Confirmed] https://launchpad.net/bugs/182325115:23
stephenfingibi: looking15:23
gibiso far I was not able to reproduce the bug with this patch in 10 CI runs15:23
*** ociuhandu has joined #openstack-nova15:25
bauzassean-k-mooney: I mean, my concern is to know whether we can know that if we get an empty list of aggregates, it's either fine or not15:25
*** ralonsoh has quit IRC15:27
sean-k-mooney https://github.com/openstack/neutron/blob/a9fc746249cd34cb7cc594c0b4d74d8ddf65bd46/neutron/tests/unit/extensions/test_segment.py#L341-L35115:27
*** ralonsoh has joined #openstack-nova15:27
sean-k-mooneyso it will be a list of segments i think but it will be empty still checking15:27
*** xek_ has joined #openstack-nova15:29
*** ociuhandu has quit IRC15:30
sean-k-mooney gibi  i hit that bug too15:31
gibisean-k-mooney: all of us hit that during the past one and a half year, we  turned that test off during FF many times in the past to make patches land15:32
*** xek__ has quit IRC15:32
gibiit seems like an unsolvable thing15:32
sean-k-mooneyoh i mean i have seen it in the last week15:32
gibiat least to me15:32
bauzassean-k-mooney: well, ok, so no way to distinct in between networks not using routed segments vs. networks using routed segments but with no aggregate for this segment15:33
gibiyeah, recently I seen it almost every day, hence my new atempt to sovle it15:33
sean-k-mooneybauzas:right but the later case should never happen15:33
sean-k-mooneybauzas: neutron always creates the aggreates if the segments service plugin is loaded15:33
*** ralonsoh has quit IRC15:34
sean-k-mooneywhich is what provides routed network support in neutron15:34
bauzassean-k-mooney: ok, so, just checking the extension is enough15:35
*** ociuhandu has joined #openstack-nova15:35
bauzasand getting no aggregates is totally fine15:35
sean-k-mooneygetting no segments is fine15:35
sean-k-mooneyif we get segment but done get aggreates for those segment that a neutorn issue15:35
gibi^^ +115:36
bauzasok, then I'll distinct this15:36
sean-k-mooneyit means neutron could not create them for some reason15:36
bauzasin scheduler.utils15:36
bauzasokay, I should be able to upload a new rev in 10 mins15:36
bauzasstill a WIP tho15:36
sean-k-mooneycool15:36
sean-k-mooneyby did i see correctly that you are adding the network request to the request spec15:37
sean-k-mooneyi might have a use for that in for one of my specs15:37
*** dklyle has joined #openstack-nova15:37
*** ralonsoh has joined #openstack-nova15:38
sean-k-mooneyhttps://review.opendev.org/c/openstack/nova-specs/+/765901/1/specs/wallaby/approved/port-scoped-sriov-numa-affinity.rst#7515:38
sean-k-mooneyi was planning to add a prefilter but realised i did not have the requested networks in the prefilter15:38
sean-k-mooneyso i was going to move it eairler but i think i can just build on your change instead15:39
sean-k-mooneybauzas: can you review and provide input on that in particalar15:39
*** ociuhandu has quit IRC15:39
bauzassean-k-mooney: okay, will look15:40
* bauzas does yet another click15:40
sean-k-mooneythere is an clean way to do it with out a prefiler but i dont want to break the patern if i dont have to15:42
*** ociuhandu has joined #openstack-nova15:43
*** ralonsoh_ has joined #openstack-nova15:45
*** ralonsoh has quit IRC15:46
*** ociuhandu has quit IRC15:47
*** macz_ has joined #openstack-nova15:52
openstackgerritSylvain Bauza proposed openstack/nova master: Add requested_networks field to RequestSpec object  https://review.opendev.org/c/openstack/nova/+/74997715:53
openstackgerritSylvain Bauza proposed openstack/nova master: WIP: Add a routed networks scheduler pre-filter  https://review.opendev.org/c/openstack/nova/+/74906815:53
*** sapd1 has quit IRC15:56
*** mkrai has quit IRC15:57
*** amodi has joined #openstack-nova16:01
*** sapd1 has joined #openstack-nova16:09
*** waverider has quit IRC16:09
*** xek has joined #openstack-nova16:09
*** xek_ has quit IRC16:11
*** xek_ has joined #openstack-nova16:11
*** mlavalle has joined #openstack-nova16:13
*** xek has quit IRC16:15
*** brinzhang has quit IRC16:27
*** ociuhandu has joined #openstack-nova16:29
melwittLarsErikP: I can take care of the merge conflict for the ussuri backport, no worry16:30
melwittfor the victoria one, we are currently stuck behind a known gate failure, I posted a note on the review16:30
*** lpetrut has quit IRC16:46
*** hamalq has joined #openstack-nova16:53
*** hamalq_ has joined #openstack-nova16:55
*** hamalq has quit IRC16:59
stephenfinlyarwood: should I even bother exposing this if it's really internal only? https://review.opendev.org/c/openstack/python-openstackclient/+/76536617:06
*** tesseract has quit IRC17:06
lyarwoodstephenfin: yeah we could just block it in the cli17:07
lyarwoodstephenfin: but I'm assuming that will create future up and/or downstream bugs17:07
lyarwoodstephenfin: but they always have the API17:07
stephenfinthat's what I'm thinking. I'm not converting e.g. the 'nova reset-network' command17:08
lyarwoodstephenfin: that said the recently landed update stuff is actually useful outside of swap volume17:08
lyarwoodstephenfin: so you would just be blocking the swap volume stuff and allowing the volume update flow17:08
lyarwoodstephenfin: and FWIW this is why I wanted the swap volume flow fork lifted out from this API *before* we landed the volume update stuff17:09
stephenfinso I'd drop the dst_volume argument and simply use src_volume for both17:09
lyarwoodyeah17:09
stephenfinI can do that17:09
*** rpittau is now known as rpittau|afk17:12
*** ociuhandu_ has joined #openstack-nova17:24
melwittstephenfin: while you're here, do you think you might be able to give this patch to use unittest.mock instead of third party mock a refresh from merge conflicts? https://review.opendev.org/c/openstack/nova/+/714676 prometheanfire was asking yesterday if we'd made progress on support for mock 4.0.2 https://review.opendev.org/76568017:26
melwitt*while you're here, I wanted to ask17:26
*** ociuhandu has quit IRC17:27
*** ociuhandu_ has quit IRC17:28
*** ociuhandu has joined #openstack-nova17:34
*** luksky has quit IRC17:35
*** ociuhandu has quit IRC17:39
*** hoonetorg has joined #openstack-nova17:41
*** jangutter_ has joined #openstack-nova17:43
*** jangutter has quit IRC17:46
*** k_mouza has quit IRC17:46
*** gyee has joined #openstack-nova17:57
*** noonedeadpunk_ is now known as noonedeadpunk18:01
*** k_mouza has joined #openstack-nova18:11
*** derekh has quit IRC18:15
*** k_mouza has quit IRC18:15
-openstackstatus- NOTICE: The Gerrit service on review.opendev.org is currently responding slowly or timing out due to resource starvation, investigation is underway18:16
*** k_mouza has joined #openstack-nova18:17
*** jangutter has joined #openstack-nova18:23
*** k_mouza has quit IRC18:25
*** jangutter_ has quit IRC18:25
*** jangutte_ has joined #openstack-nova18:25
*** dtantsur is now known as dtantsur|afk18:28
*** jangutter has quit IRC18:28
*** jangutte_ has quit IRC18:40
*** jangutter has joined #openstack-nova18:40
*** jangutter has quit IRC18:41
*** jangutter has joined #openstack-nova18:42
*** aj_mailing has joined #openstack-nova18:44
*** nweinber has joined #openstack-nova18:52
stephenfinmelwitt: Sorry, missed that. I'd deprioritized that because I couldn't figure out what the gain was. mock (the pypi package) is a rolling backport of upstream changes and as such, any bugs it introduces are things we're going to have to fix when we reach that future Python version anyway18:57
sean-k-mooneystephenfin: not always18:58
stephenfinso sticking with mock and simply getting it working with 4.0 seemed a wiser course of action, tbh18:58
melwittoh, hm18:58
sean-k-mooneywe have nit bugs in there backported implemation18:58
sean-k-mooneythat are not there in the native one18:58
stephenfinI don't think so, at least not from reading upstream bug reports18:59
stephenfinany bugs are also present in unittest.mock on the either the latest Python or Python master, I don't recall which18:59
melwittstephenfin: I see, ok, I can try that approach then. I didn't realize why the conversion patch wasn't being worked18:59
sean-k-mooneyour inablity to use one of the mock decortors is due to mock the lib vs unittest.mock18:59
stephenfinsean-k-mooney: my understanding of that was that it was also an issue in the Python 3.9 unittest.mock implementation19:00
sean-k-mooneyi think its teh use of assert raises as a context manager actully19:00
stephenfinI can root out the bug report in the morning (dinner time here)19:00
stephenfinmelwitt: I think that might be a wiser approach, but I'm not the only one with a say here. It just seems foolish to have to work around bugs with e.g. unittest.mock on Python 3.6 when mock 3.x+ doesn't have them19:01
*** andrewbonney has quit IRC19:03
melwittstephenfin: no I think what you're saying makes sense, I think that would be a simpler way to address this19:03
sean-k-mooneystephenfin: https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertRaises19:03
melwittI can put that together19:03
sean-k-mooneywith self.assertRaises(SomeException) as cm:19:03
sean-k-mooney    do_something()19:03
sean-k-mooneystephenfin: that does not work with mock the lib19:04
sean-k-mooneyor at least it did not work in the past19:04
sean-k-mooneyperhaps its actully caused by soemthing else but that is what we belived it was blocking that form working in nova the last time we investigated19:05
*** martinkennelly has joined #openstack-nova19:16
*** martinkennelly has quit IRC19:37
*** waverider has joined #openstack-nova19:47
*** waverider has quit IRC19:47
*** waverider has joined #openstack-nova19:47
*** waverider has quit IRC19:48
*** waverider has joined #openstack-nova19:48
*** waverider is now known as adrian-a19:49
*** adrian-a has quit IRC19:51
*** adrian-a_ has joined #openstack-nova19:54
*** adrian-a_ has quit IRC19:54
*** adrian-a has joined #openstack-nova19:55
*** k_mouza has joined #openstack-nova19:58
*** k_mouza has quit IRC20:03
*** jangutter_ has joined #openstack-nova20:06
*** hoonetorg has quit IRC20:08
*** jangutter has quit IRC20:09
*** jangutter has joined #openstack-nova20:11
*** jangutter_ has quit IRC20:14
*** adrian-a has quit IRC20:24
*** adrian-a has joined #openstack-nova20:25
*** ralonsoh_ has quit IRC20:28
*** dave-mccowan has joined #openstack-nova20:31
*** ociuhandu has joined #openstack-nova20:42
*** ociuhandu has quit IRC20:46
*** ociuhandu has joined #openstack-nova20:48
*** ociuhandu has quit IRC20:52
*** vishalmanchanda has quit IRC20:54
*** ociuhandu has joined #openstack-nova20:59
*** ociuhandu has quit IRC21:04
*** sapd1 has quit IRC21:04
*** ociuhandu has joined #openstack-nova21:10
*** slaweq has quit IRC21:12
*** slaweq has joined #openstack-nova21:13
*** hack-char has quit IRC21:17
*** hack-char has joined #openstack-nova21:17
JamesBensonHi all, I've modified my nova.conf with `cpu_mode = host-model` in a mixed CPU environment, but not all of my CPU flags passed through. What else am I missing?21:57
*** rcernin has joined #openstack-nova22:02
*** rcernin has quit IRC22:04
*** rcernin has joined #openstack-nova22:05
*** ociuhandu has quit IRC22:09
*** raildo has quit IRC22:13
*** ociuhandu has joined #openstack-nova22:15
*** ociuhandu has quit IRC22:19
*** ociuhandu has joined #openstack-nova22:20
*** xek_ has quit IRC22:28
*** ociuhandu has quit IRC22:34
*** ociuhandu has joined #openstack-nova22:41
*** ociuhandu has quit IRC22:41
*** nweinber has quit IRC22:43
*** slaweq has quit IRC23:23
*** lemko3 has joined #openstack-nova23:28
*** lemko has quit IRC23:31
*** lemko3 is now known as lemko23:31
openstackgerritmelanie witt proposed openstack/nova stable/victoria: WIP [stable-only] Target cell for min bw migration service lookup  https://review.opendev.org/c/openstack/nova/+/76636423:40
*** fudunwei has quit IRC23:40
*** k_mouza has joined #openstack-nova23:41
sean-k-mooneyJamesBenson: host model will not pass all the flags23:42
sean-k-mooneyJamesBenson: some cpu flags are not virtualisable but the real reason is host model chose the clost model to you actual cpu listed in qemus/libvirts cpu model xml file23:43
sean-k-mooneythose models are ment to represent the common set of flag commen to a specific generation of a cpu not the specific sku23:44
sean-k-mooneyso if you cpu has feature that are not avaiable on other cpus in the same generation those feature flags likely wont be present23:44
*** k_mouza has quit IRC23:45
« Tuesday, 2020-12-08 Index Thursday, 2020-12-10 »

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