Thursday, 2022-01-27

*** Uggla|afk is now known as Uggla08:45
*** ministry is now known as __ministry09:48
opendevreviewFrode Nordahl proposed openstack/nova master: Ensure binding profile keys added by Nova are cleared  https://review.opendev.org/c/openstack/nova/+/82660110:10
gibibauzas: can we land this? https://review.opendev.org/q/topic:bug%252F1952941 I'm getting pressure from downstream...10:41
*** bhagyashris_ is now known as bhagyashris|ruck11:05
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: [yoga] Include pf mac and vf num in port updates  https://review.opendev.org/c/openstack/nova/+/82483311:14
guesswhatis xen ( xcp-ng ) supported in openstack as nova driver? seems its deprecated, right ?11:31
dmitriissean-k-mooney: o/ question about https://review.opendev.org/c/openstack/nova/+/824834/1/nova/pci/stats.py#530. Looking at pci_passthrough_whitelist alone without runtime checks we can't tell if a device is a PF or not. There may be a case where a device is present in the config but not yet hot-plugged into the host or deployment tooling may apply11:44
dmitriisthe same config for various PCI devices which may or may not be present in all servers. So I am trying to decide whether implementing runtime checks during pci_passthrough_whitelist parsing is a good idea or not.11:44
sean-k-mooneydmitriis: its not that tere wont be any runtime checks its that when we first inistalise the pci tracker and iterate over the pci devcied on the host we can check once and either raise an error that prevent the agent form starting or strip out the pf depending on the configurtion12:51
sean-k-mooneydmitriis: you do not use the same config on all servers12:53
sean-k-mooneythe pci whitelist is differnt per host12:53
sean-k-mooneyi dont enforce this today but its logcially an error to list a device in the pci whitelist if its not present on the host.12:54
sean-k-mooneythe only reason we dont enforce it is it could alredy be pass through to a vm 12:55
dmitriissean-k-mooney: What about the hot-plug case? I know it's a niche one and I haven't actually seen this to be used12:55
sean-k-mooneydmitriis: we do not support hotplug of pci device on the host12:55
sean-k-mooneylibvirt caches the pci device list and you woudl have ot restart it for libvirt to work and then restart the nova agent12:56
dmitriissean-k-mooney: ah, ok, so then it's not a problem and I can make a runtime check when whitelist is parsed12:56
sean-k-mooneyso for the lifetime of the nova agent hot-plug on the host is not supported12:56
sean-k-mooneyyes12:56
sean-k-mooneywe can ensure the PFs never actully make it to the db in the first plance12:56
sean-k-mooneyand therefore can never be a candiate for selection12:57
dmitriissean-k-mooney: right, presumably the compute node will filter out PCI devices obtained from libvirt based on the whitelist12:57
dmitriissean-k-mooney: what about the "if PF is specified in a request with a remote_managed tag"? Do I need to support this?12:58
sean-k-mooneywell there wont be any pf with remote managed in the db because we filtered them at start up so it will be handeled automaticaly12:59
sean-k-mooneyvnic-type direct-phsyical will only match PFs without remote-managed=true12:59
sean-k-mooneybecause that is all tha will exist13:00
sean-k-mooneyand vnic-type smartnic will only match VFs13:00
sean-k-mooneyso i think that is covered13:00
sean-k-mooneyyou do not need to specificlyu request remote_mannaged=false in the driect-physical case13:00
dmitriissean-k-mooney: ok, so I can just drop the check here https://review.opendev.org/c/openstack/nova/+/824834/1/nova/pci/stats.py#50513:00
dmitriisbasically we assume that those devices won't get into the DB so no additional filtering will be needed13:01
sean-k-mooneyyes that is more or less why im suggesting.  you jst need to move the logic to the inital startup13:01
sean-k-mooneyso its done once per host rather then once per request13:02
sean-k-mooney* once per host start up13:02
dmitriissean-k-mooney: ok, makes sense, I'll have a look at how/where to put those and resubmit13:02
dmitriissean-k-mooney: regarding os-traits, looks like the 2.7.0 package got built and pushed out but 2.6.0 is still referenced in upper-constraits https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L38213:04
dmitriisI've seen a change to the release repo and the requirements repo13:05
dmitriisah, looks like this hasn't been merged yet https://review.opendev.org/c/openstack/requirements/+/826447 while it's approved13:06
sean-k-mooneyright i had to make a change to placment and rebase that to depend on it13:06
sean-k-mooneyhttps://review.opendev.org/c/openstack/placement/+/82648613:06
sean-k-mooneystill need to be approved.13:06
sean-k-mooneybauzas: can you quickly hit ^13:07
dmitriissean-k-mooney: ack, I see13:07
sean-k-mooneydmitriis: we have some packaging issue with os-traits and placment that dont really work with how our ci is13:08
sean-k-mooneywe may need to merge os-traits into placment to fix it13:08
sean-k-mooneyso i had to hack around it for now13:08
sean-k-mooneyuntil recently we did not have ci in the requirements repo that tested placement13:08
sean-k-mooneyso this is the first tiem we are seeign the cirular depency problem13:09
sean-k-mooneydmitriis: by the way you and chateaulav  both need the os-trait bump13:10
sean-k-mooneythe best way to handel that is to have a singel patch to nova that increases our lower-constirati and requiremets.txt to 2.7.0 and then have both of ye rebase your series ontop of that patch13:11
sean-k-mooneyi can prably go file that but if you or chateaulav want to file that patch to nova feel free too13:11
dmitriissean-k-mooney: ack, I'll propose a patch and make my change depend on it13:12
sean-k-mooneycool can you ping chateaulav when you do or add them as a reviewer so they see it13:12
dmitriissean-k-mooney: will do.13:13
dmitriisJust trying to figure out why my local unit test runs are failing with13:13
dmitriis      File "/home/<user>/src/opendev/nova/.tox/py39/lib/python3.9/site-packages/oslo_concurrency/lockutils.py", line 183, in _get_lock_path13:13
dmitriis    raise cfg.RequiredOptError('lock_path')13:13
dmitriis    oslo_config.cfg.RequiredOptError: value required for option lock_path in group [DEFAULT]13:13
sean-k-mooneyyour not adding any locks are you13:15
sean-k-mooneythat seam unrelated 13:15
sean-k-mooneytry reruning with tox -r 13:16
sean-k-mooneyto regenerate teh tox venv13:16
sean-k-mooneyincase you have some out of date pacakges13:16
sean-k-mooneyor just rm the tox enve manually without -r and let it regenerate it 13:16
dmitriissean-k-mooney: no, and the test cases aren't related to what I've changed. Tried nuking .tox before. Let's see if -r helps.13:18
sean-k-mooneyif you nuked . tox it wont13:18
sean-k-mooneyi can try running it locally what patch have you checked out13:19
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: [yoga] Include pf mac and vf num in port updates  https://review.opendev.org/c/openstack/nova/+/82483313:20
dmitriissean-k-mooney: ^ https://review.opendev.org/c/openstack/nova/+/824833 the latest here13:20
sean-k-mooneyfuncitonal or unit13:21
dmitriissean-k-mooney: unit: `tox -e py39`13:21
sean-k-mooneyack just running them now under py3813:22
sean-k-mooneyif they pass ill install py39 and test again13:22
dmitriissean-k-mooney: ack, I'll spin up a container and do a clean check as well.13:23
sean-k-mooneywe do ocationally get unit test breakages when a new lib is released13:23
sean-k-mooneyalthough the last release was  Oct 21, 202113:24
sean-k-mooneyso that is likely not the issue here13:24
dmitriisack13:26
sean-k-mooneythere was an oslo.limits release and olslo utils release in the last few days but also does not look like the woudl be at fault13:28
sean-k-mooneyso far i think things are pass ing but im gong to grab a drink13:28
sean-k-mooneybrb13:28
dmitriissean-k-mooney: thanks for checking, will try to figure out what's on my env that's causing it13:28
*** dasm|off is now known as dasm13:34
sean-k-mooneygot the same error here13:38
bauzassean-k-mooney: gibi: sorry folks, was on discussion with someone you know13:38
sean-k-mooneyhttps://paste.opendev.org/show/812399/13:38
bauzaslooking at both your changes13:38
sean-k-mooneydmitriis: so its in the block device tests so not related to your patch13:39
gibibauzas: no worries13:39
sean-k-mooneythis is failing here https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/lockutils.py#L172-L18513:40
dmitriissean-k-mooney: yeah, just confusing. Got 1 failure only with py39 in a clean 21.10 container https://paste.opendev.org/show/812400/13:42
dmitriishopefully it will just work in CI :^)13:42
sean-k-mooneyah there was a fasterners release 2 days ago13:43
sean-k-mooneyhttps://pypi.org/project/fasteners/13:43
sean-k-mooneywhich we picked up13:44
sean-k-mooneyhttps://github.com/openstack/requirements/commit/c086fff066e40f3a87ff81fe72c8c16cdefe7c6413:44
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: [yoga] Introduce remote_managed tag for PCI devices  https://review.opendev.org/c/openstack/nova/+/82483413:54
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: [yoga] Add support for VNIC_TYPE_SMARTNIC  https://review.opendev.org/c/openstack/nova/+/82483513:54
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: Filter computes without remote-managed ports early  https://review.opendev.org/c/openstack/nova/+/81211113:54
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: Bump os-traits to 2.7.0  https://review.opendev.org/c/openstack/nova/+/82667513:54
dmitriissean-k-mooney: looking13:56
dmitriissean-k-mooney, chateaulav: os-traits version bump change: https://review.opendev.org/c/openstack/nova/+/82667513:57
chateaulavthanks13:57
sean-k-mooneygibi: bauzas  we might have an impending gate failure https://paste.opendev.org/show/812401/14:07
sean-k-mooneyso looks like even with latest master we now have lock issues14:07
sean-k-mooneylooks like os-brick was depending on poslition for calling kw args with is always dangrous14:11
sean-k-mooneyhttps://github.com/openstack/os-brick/blob/master/os_brick/initiator/utils.py#L45-L4614:11
gibisean-k-mooney: I cannot reproduce the lockpath failure locally with fresh env on nova master14:12
sean-k-mooneyodd i could after checking out dmitriis  code and then still could after  checking out master14:13
sean-k-mooneyill try cleaning my env and pyc files again14:13
sean-k-mooneyi can repoduce ti consitently on my laptop im trying it on my server now too14:16
dmitriissean-k-mooney: oddly, the latest run on CI https://zuul.opendev.org/t/openstack/build/daf00a97b54f4e349ef609240a956347/log/job-output.txt doesn't have it14:17
sean-k-mooneygibi: odd it passed there14:20
bauzasgibi: sean-k-mooney: do we have logstash yet ?14:20
bauzasto see whether it's a large race condition14:20
gibibauzas: I used logstash today14:20
sean-k-mooneyim going to see if it only happens in a repo after usign dmitriis patch14:21
sean-k-mooneyi wonder if we are leaking locks or somehting14:21
sean-k-mooneydmitriis: you patch is still pending in the gate right14:22
dmitriissean-k-mooney: yes but I can see here https://zuul.opendev.org/t/openstack/status#nova that it already finished running unit tests14:23
sean-k-mooney odd that it passed 14:24
sean-k-mooneyand we can both repoduce the issue locally14:24
sean-k-mooneydmitriis: what operating system are you using by the way14:25
dmitriissean-k-mooney: yes, I'm trying to compare how many test cases fail each time and whether it depends on timing14:25
opendevreviewMerged openstack/placement master: disable traits count check to allow os-traits 2.7.0  https://review.opendev.org/c/openstack/placement/+/82648614:25
dmitriissean-k-mooney: Ubuntu 21.1014:25
sean-k-mooneyfor me it was consitent14:26
sean-k-mooneywell mostly14:26
sean-k-mooneyi coudl re run with --failing14:26
dmitriissean-k-mooney: in a 21.10 container I consistently get 1 failure14:26
sean-k-mooneythat went form 9 to 8 then staied with 814:26
sean-k-mooneyhum clean repo one failure but its differetn 14:28
sean-k-mooney RuntimeError: Reader <_MainThread(MainThread, started 140118297270080)> to writer privilege escalation not allowed14:28
dmitriissean-k-mooney: yes, that's the one I am getting in a clean container with the patch applied14:28
dmitriis    RuntimeError: Reader <_MainThread(MainThread, started 139926055308288)> to writer privilege escalation not allowed14:29
sean-k-mooneyya i have your patch aplied too14:29
sean-k-mooneygibi: bauzas  i guess we are not seeing this in the gate14:30
sean-k-mooneybut its just odd behavior14:30
sean-k-mooneythe issue seam to be related to the fasteners release i think14:31
sean-k-mooneyim going to downgrade it to confirm14:31
dmitriissean-k-mooney: ack14:31
dmitriissean-k-mooney: tried with the previous (VPD) patch only https://paste.opendev.org/show/812404/14:32
sean-k-mooneywell a uuid is not an rfc1738 url14:33
sean-k-mooneyhum same issue with older fasteners14:34
dmitriissean-k-mooney: the other failures are odd to see because that same patch passed on CI https://review.opendev.org/c/openstack/nova/+/808199. Checking with older fasteners as well.14:36
sean-k-mooneydmitriis: master seam to work ok for me14:37
sean-k-mooneydmitriis: have you treid rebaseing all your patches14:37
sean-k-mooneywe might have fix this already on master and you patches might be missing it14:37
dmitriissean-k-mooney: ack, let me try that14:37
*** artom__ is now known as artom14:50
bauzassean-k-mooney: cool, interesting14:53
bauzasthanks for the follow-up14:53
sean-k-mooneybauzas: gibi  by the way we likely need to have a dicussion about what to do about placment,os-traits and os-resouce-providres at some point14:54
gibisean-k-mooney: ack. I read the scrollback from the release channel14:54
sean-k-mooneyperhaps a ptg topic. we coudl start it on the ML or in an etherpad14:55
gibiI do believe that os-traits being a separate lib helps for the other consumers like nova and neutron. So I would not want to merge that back to placement14:55
gibiSo I'm on the side to relax the testing and add a release step where we check that the placement is released with the latest os-traits14:56
sean-k-mooneyya long term that is proably the most operator freindly too14:57
sean-k-mooneyit would be a lot of work to reabsorb os-trait into placment14:57
sean-k-mooneysince we woudl have to modify nova,neutron,cyborg and possibel others + the deployment tooling14:58
sean-k-mooneygibi: i can look at relaxing the test and push a patch for people to consider15:01
gibisean-k-mooney: OK, thanks15:01
sean-k-mooneyi dont know if cdent or others are aroudn that shoudl review15:05
sean-k-mooneyare any of the placment core team actully still active15:05
dmitriissean-k-mooney: hmm, tried master locally, getting the same failures with locking. Tried master on a server machine (21.04) - no failures.15:05
gibisean-k-mooney: I think we only have those that are active in nova too15:06
dmitriiswill try a few more combinations 15:06
sean-k-mooneyperhaps tetsuro? although i have not seen them in a while15:06
sean-k-mooneyill add the patch to open discuss for next weeks meeting once i figure out what to do15:07
gibiack15:07
ade_lee__sean-k-mooney, hey -- could you take a look at https://zuul.opendev.org/t/openstack/build/554ffdeb6c3a4cdc8c53c55dddd6c36e  please and let me know whats missing?15:24
ade_lee__sean-k-mooney, this is for https://review.opendev.org/c/openstack/tempest/+/826580 as discussd the other day15:24
sean-k-mooneysure ill take a look quickly and see if anything jumps out15:26
sean-k-mooneyyou might need to set swap on the subnode too but ill check that15:26
sean-k-mooneyade_lee__: actuly devstack may not have finished on the compute15:29
sean-k-mooneyya ok15:29
sean-k-mooneyso on the compute devstack failed to install pip15:29
sean-k-mooneyhttps://zuul.opendev.org/t/openstack/build/554ffdeb6c3a4cdc8c53c55dddd6c36e/log/compute1/logs/devstacklog.txt15:29
dmitriissean-k-mooney: on 21.04 server tests are passing even with patches applied like it happens on the CI. Also not getting any failures in a 21.04 container locally with patches applied (with a rebase to master). Without a rebase I seem to be getting only "writer privilege escalation not allowed". So probably something in 21.10 libs is different and15:30
dmitriisresults in the breakage with locks. This hasn't happened recently so I'll try to explore further which update might have caused it.15:30
dmitriisbut at least one issue should be covered with rebasing15:31
sean-k-mooneyack15:31
sean-k-mooneyif we dont see it in ci for now i would proceed with the rest of your work and we can keep an eye out for it15:31
sean-k-mooneyade_lee__: this might just be an intermient failure on centos 8 15:34
sean-k-mooneyso we shoudl recheck but ade_lee__ any plans to move that to centos-9-stream15:35
sean-k-mooneyif we dont do that this cycle we shoudl do it next cycle15:35
ade_lee__sean-k-mooney, maybe -- the relevant code seems to be here -- https://opendev.org/openstack/devstack/src/branch/master/tools/install_pip.sh#L121-L13415:35
sean-k-mooneyit looks like hte rax mirror just did not have a cenots8 compatiable packages15:36
ade_lee__sean-k-mooney, but yes, the plan is absolutely to move to centos-9-stream15:36
sean-k-mooneythe issue with 8 is its using python 3.615:37
sean-k-mooneywhich is now end of life upstream15:37
sean-k-mooneyso we are going to start to see pip not working on it sonner rather then later15:37
ade_lee__sean-k-mooney, the only problem right now is that fips+python+centos-9 is broken15:37
ade_lee__sean-k-mooney, but its getting fixed ..15:37
sean-k-mooneyso we might need to expand that to use pip form packages for cenos 8 stream too15:38
ade_lee__yup15:39
sean-k-mooneyhttps://github.com/pypa/pip/commit/0252c04a16cd93fe422cebf0b48453b559a2e40415:40
sean-k-mooneypip droped support for 3.615:40
sean-k-mooneyhttps://github.com/pypa/pip/blob/main/setup.py#L8315:40
ade_lee__sean-k-mooney, as soon as https://bugzilla.redhat.com/show_bug.cgi?id=1942527 is fixed, I plan to move all these to centos-9-stream15:40
sean-k-mooneyso ya that is the issue15:40
sean-k-mooneythis will break all centos 8 jobs so we should likely fix devstack to work around it for now15:41
ade_lee__which is supposed to happen maybe by next week ..15:41
ade_lee__yeah - I'll expand the conditional and see if that works15:41
* sean-k-mooney clicks15:41
sean-k-mooneyjust have it check is_fedroa15:42
sean-k-mooneydrop the rest15:42
sean-k-mooneyand it shoudl be correct15:42
sean-k-mooneywe just need to ensure python3-pip is in the rpm files in devstack15:43
ade_lee__sean-k-mooney, ok - trying ..15:43
sean-k-mooneywhich it is https://github.com/openstack/devstack/blob/master/files/rpms/general#L2915:44
sean-k-mooneyade_lee__: by the way that is in post but has to go through qe ectra and then be published and buil in centos15:45
sean-k-mooneyso it will proably take more then a week15:45
ade_lee__sigh .. yeah15:45
sean-k-mooneyi mean it wont take that much longer there is a merge request up15:46
sean-k-mooneywe can still do it this cycle15:46
ade_lee__sean-k-mooney, oh we definitely want to do it this cycle15:46
sean-k-mooneyam so pip installed fine on one of the host15:46
sean-k-mooneyyou can proably just recheck and see if you get looking and avoid rackspace15:47
sean-k-mooneybut i think infra/qa are aware of the centos 8 failure15:47
ade_lee__I'll throw up the dependent patch to avoid the issue for now15:48
sean-k-mooneyelodilles: ^ pip being broken on centos 8 on some clouds, is that new to you15:48
ade_lee__with my luck, I'll get rax three times in a row15:48
sean-k-mooneyade_lee__: well staticially they used to be one of the larges ci providers so proably15:51
ade_lee__sean-k-mooney, seems like others have run into this -- https://review.opendev.org/c/openstack/devstack/+/77980615:53
sean-k-mooneyya15:54
sean-k-mooneyi was conisdering addign a env var to disable it a few weeks ago15:54
sean-k-mooneyactully did i push my one15:55
sean-k-mooneyi have been using a modifed install_pip on one of my hosts15:55
sean-k-mooneyade_lee__: https://termbin.com/k0x915:57
sean-k-mooneyade_lee__: i was modifying it to only install pip if it was not already there15:59
ade_lee__sean-k-mooney, makes sense -- anyways, for now added this as depends -- https://review.opendev.org/c/openstack/devstack/+/826714  - lets see how it goes16:00
pmonteirHi everybody! I was checking the "live_migration_downtime" parameter and I there's a function that supposedly configures the max_downtime, but this function (migrate_configure_max_downtime in https://opendev.org/openstack/nova/src/commit/ca03fe87371d8c13fc2895f8ff3e7e1ca88cfe79/nova/virt/libvirt/guest.py) calls another one which is just a "pass", has anyone ever used this parameter? I think it's not working properly, 16:03
pmonteirshould this be implemented?16:03
pmonteirps: this function that's just a pass that I mentioned above, belongs to a "tests" folder (which makes me think that it shouldn't be used outside of a testcase).16:12
opendevreviewBalazs Gibizer proposed openstack/placement master: Add any-traits support for listing resource providers  https://review.opendev.org/c/openstack/placement/+/82649116:15
opendevreviewBalazs Gibizer proposed openstack/placement master: Add any-traits support for allocation candidates  https://review.opendev.org/c/openstack/placement/+/82649216:15
opendevreviewBalazs Gibizer proposed openstack/placement master: Remove unused compatibility code  https://review.opendev.org/c/openstack/placement/+/82649316:15
opendevreviewBalazs Gibizer proposed openstack/placement master: Add microversion 1.39 to support any-trait queries  https://review.opendev.org/c/openstack/placement/+/82671916:15
gibipmonteir: what you see is the libvirt test fixture we use for functional testing16:17
gibipmonteir: in production we use the real python binding for libvirt 16:18
gibihttps://libvirt.org/python.html16:18
prometheanfireuefi guests are failing to boot after upgrade to xena :|   nova.exception.UEFINotSupported: UEFI is not supported16:18
prometheanfiretrying to find what in particular is triggering it16:18
gibipmonteir: so the the migrateSetMaxDowntime call is sent to libvirt 16:20
prometheanfireintroduced in faad45b6323d7c52d35b7ccc45eacb5580b3b4d316:21
pmonteirgibi: ohhh, I think I got it know...16:21
pmonteirbut shouln't it be virDomainMigrateGetMaxDowntime then? Don't know if I'm looking at the right place here > https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainMigrateSetMaxDowntime16:22
pmonteirI meant virDomainMigrateSetMaxDowntime*16:23
gibipmonteir: look at the naming rules at https://libvirt.org/python.html I think the python bindig call is generated to be MigrateSetMaxDowntime on teh domain object16:24
gibisorry migrateSetMaxDowntime16:25
prometheanfirespatel: think this is a nova issue? (if so we should probably talk here) :D16:26
spatelprometheanfire did you check your vm xml file and see what are the path you are seeing? 16:27
opendevreviewBalazs Gibizer proposed openstack/nova master: DNM: run nova tests with any--traits placement feature  https://review.opendev.org/c/openstack/nova/+/82591416:28
prometheanfirearch not specified, so hits the continue16:33
prometheanfirespatel: the vm was shut down, so it's failing to boot on being defined16:33
prometheanfireinstance id is not listed in /etc/libvirt/qemu/16:34
pmonteirgibi: I think I got it now, thanks!16:35
prometheanfireif I had the xml it'd be easier to debug16:35
gibipmonteir: cool 16:35
gmanndansmith: gibi can you check this backport centos8 nodeset usage update for stable/xena https://review.opendev.org/c/openstack/nova/+/82593016:44
gmannafter that I will recheck on devstack patch and see if need to backport it for other stable too https://review.opendev.org/c/openstack/devstack/+/82429016:45
dansmithgmann: by "check" you mean "rubber stamp" right?16:45
gmanndansmith: yes :)16:45
gibigmann: looks good to me, but I only have the small stamp on stable16:45
gmannoh did not know16:46
dansmithgibi: any concern with me ninjaing?16:46
gibidansmith: go for it16:46
prometheanfireI think nova uefi booting only works with redhat now16:51
sean-k-mooneyprometheanfire: it shoudl work on ubuntu 20.17:11
sean-k-mooney20.0417:11
sean-k-mooneysince that is what the dev and testign was down with17:11
prometheanfiredebian buster doesn't seem to be working at least, still trying to figure out what in particular is throwing the flag17:12
prometheanfiresean-k-mooney: if you have suggestions on how to debug https://github.com/openstack/nova/commit/faad45b6323d7c52d35b7ccc45eacb5580b3b4d3#diff-67d0163175a798156def4ec53c18fa2ce6eba79b6400fa833a9219d3669e9a11R1465 I'd appreciate it :D17:13
prometheanfireatm I'm about to put in a bunch of debug statements17:14
sean-k-mooney what is the errror you are seeing 17:16
prometheanfiretraceback nova.exception.UEFINotSupported: UEFI is not supported17:16
prometheanfirewhich tracks down to just that get_loader function17:17
gmanndansmith: one more easy one https://review.opendev.org/c/openstack/osc-placement/+/81920317:17
sean-k-mooneyprometheanfire: but that is coming form use parsing libvirt17:17
sean-k-mooneyprometheanfire: so that impleis qemu is sayign secure boot is not supproted on debian17:17
sean-k-mooneyprometheanfire: can you paste the output of vrish capablities adn vrish domcaps17:18
prometheanfirethe ovmf files are there, it used to work, I'll look some more, I didn't see any errors on the libvirt-daemon side17:18
prometheanfirek17:18
dansmithgmann: done17:18
gmanndansmith: thanks 17:18
prometheanfiresean-k-mooney: capabilities https://gist.github.com/prometheanfire/adb89403ef70a11301b9cc45b040cd4e17:22
sean-k-mooneyack looks liek the loader info is not in the main caps proably dom caps17:23
prometheanfiresean-k-mooney: domcaps https://gist.github.com/prometheanfire/49bf656542cacbf8e37c275cb08ca27b17:23
sean-k-mooneyok yes17:23
sean-k-mooneyhttps://gist.github.com/prometheanfire/49bf656542cacbf8e37c275cb08ca27b#file-gistfile1-txt-L10-L2517:24
sean-k-mooneyso ya libvirt said secure no17:24
sean-k-mooneyhttps://gist.github.com/prometheanfire/49bf656542cacbf8e37c275cb08ca27b#file-gistfile1-txt-L2317:24
prometheanfirebut I don't want secure boot17:24
sean-k-mooneybecause the files it looked at are not the secure boot ones17:24
sean-k-mooneyoh right17:24
sean-k-mooneyam let me reead the patch17:24
prometheanfireis nova only supporting secure boot for uefi now?17:24
prometheanfireack17:24
sean-k-mooneywell yes secure boot is only supprote with uefi but no you shoudl be able to use uefi without secure boot17:25
prometheanfirecool17:25
prometheanfireso, domcaps says I should support uefi guests, but only without secure boot, nova is saying that's not good enough, I think17:26
prometheanfire(to summarize)17:26
sean-k-mooneyya still readign the code it was out of my cache17:28
sean-k-mooneybut that i belvie is incorect17:28
sean-k-mooneywe should not require secure boot unless you ask for it17:28
opendevreviewMerged openstack/osc-placement master: Updating python testing as per Yoga testing runtime  https://review.opendev.org/c/openstack/osc-placement/+/81920317:29
prometheanfireelsewhere in debug logs it says UEFI support detected17:29
sean-k-mooneyprometheanfire: ok so i don tthink the get_loader part is the issue17:32
sean-k-mooneyit _get_loaders i think17:32
sean-k-mooneyhttps://github.com/openstack/nova/commit/faad45b6323d7c52d35b7ccc45eacb5580b3b4d3#diff-67d0163175a798156def4ec53c18fa2ce6eba79b6400fa833a9219d3669e9a11R9717:32
sean-k-mooneyyou have <value>/usr/share/OVMF/OVMF_CODE.fd</value>17:32
sean-k-mooneywe are checking 17:33
sean-k-mooney  '/usr/share/qemu/firmware',17:33
sean-k-mooney    '/etc/qemu/firmware',17:33
sean-k-mooneywell maybe that is not the issue actuly17:33
prometheanfireyou are only checking json there though?17:33
prometheanfirelogs don't show the error message either17:34
sean-k-mooneyprometheanfire: bacicly im curently looking back in that patch to see where we determin if its supported or not17:36
sean-k-mooneyuefi that is17:36
prometheanfireack17:36
sean-k-mooneyprometheanfire: we really should have test that assert this behavior using xml by the way 17:37
sean-k-mooneyif we dont we can use your gist as the sameple data and and see if we can repoduce17:37
prometheanfireack17:37
prometheanfireI think this is a problem in OSA for xena on buster (and maybe bullseye), ovmf in debian buster-backports includes json and secboot files17:43
prometheanfireinstance booted with that17:43
prometheanfiresean-k-mooney: https://gist.github.com/prometheanfire/1e2414828d7904daa2c568653c70cd1517:44
prometheanfirespatel: ^ I think ovmf needs to be installed from backports on buster at least17:44
spatelhmm17:45
spatelsean-k-mooney i had this issue in nova error logs when i was trying to do secure boot - nova error Secure boot requires SMM feature enabled        17:47
sean-k-mooneywell SMM is enabled by default be libvirt17:48
sean-k-mooneyand we do not specify it at all17:48
sean-k-mooneyso that seams like a libvirt bug17:48
sean-k-mooneywhat prometheanfire  is reporting is more extream 17:48
sean-k-mooneye.g. uefi just does not work on non redhat distos17:49
EugenMayeri have an instance which has a 'stuck image backup task' - is there any way to clean this up?17:49
prometheanfiresean-k-mooney: I THINK that the missing json file may be a cause17:49
prometheanfire /usr/share/qemu/firmware/60-edk2-x86_64.json in the backports version vs not in the main version17:50
sean-k-mooneyprometheanfire: ya i think kashyap had a converation with the ubuntu deves at somepoint17:50
sean-k-mooneylooking at the code it does seam to be tryign to pasrse that instead fo gettign suff from libvirt17:51
sean-k-mooneybut im not really sure17:51
opendevreviewLee Yarwood proposed openstack/nova master: func: Allow compute_driver to be set and used by _IntegratedTestBase  https://review.opendev.org/c/openstack/nova/+/76448418:03
opendevreviewLee Yarwood proposed openstack/nova master: block_device_info: Add swap to inline  https://review.opendev.org/c/openstack/nova/+/82652318:03
opendevreviewLee Yarwood proposed openstack/nova master: libvirt: Improve creating images INFO log  https://review.opendev.org/c/openstack/nova/+/82652418:03
opendevreviewLee Yarwood proposed openstack/nova master: libvirt: Remove defunct comment  https://review.opendev.org/c/openstack/nova/+/82652518:03
opendevreviewLee Yarwood proposed openstack/nova master: imagebackend: default by_name image_type to config correctly  https://review.opendev.org/c/openstack/nova/+/82652618:03
opendevreviewLee Yarwood proposed openstack/nova master: image_meta: Add ephemeral encryption properties  https://review.opendev.org/c/openstack/nova/+/76045418:03
opendevreviewLee Yarwood proposed openstack/nova master: BlockDeviceMapping: Add encryption fields  https://review.opendev.org/c/openstack/nova/+/76045318:03
opendevreviewLee Yarwood proposed openstack/nova master: BlockDeviceMapping: Add is_local property  https://review.opendev.org/c/openstack/nova/+/76448518:03
opendevreviewLee Yarwood proposed openstack/nova master: compute: Update bdms with ephemeral encryption details when requested  https://review.opendev.org/c/openstack/nova/+/76448618:03
opendevreviewLee Yarwood proposed openstack/nova master: virt: Add ephemeral encryption flag  https://review.opendev.org/c/openstack/nova/+/76045518:03
opendevreviewLee Yarwood proposed openstack/nova master: scheduler: Add an ephemeral encryption pre filter  https://review.opendev.org/c/openstack/nova/+/76045618:03
opendevreviewLee Yarwood proposed openstack/nova master: block_device: Add DriverImageBlockDevice to block_device_info  https://review.opendev.org/c/openstack/nova/+/82652718:03
opendevreviewLee Yarwood proposed openstack/nova master: block_device: Add encryption attributes to image and ephemeral disks  https://review.opendev.org/c/openstack/nova/+/82652818:03
opendevreviewLee Yarwood proposed openstack/nova master: virt: Add block_device_info helper to find encrypted disks  https://review.opendev.org/c/openstack/nova/+/82652918:03
opendevreviewLee Yarwood proposed openstack/nova master: blockinfo: Add encryption details to the disk_info mappings when provided  https://review.opendev.org/c/openstack/nova/+/77227218:03
opendevreviewLee Yarwood proposed openstack/nova master: imagebackend: Add disk_info_mapping as an optional attribute of Image  https://review.opendev.org/c/openstack/nova/+/82653018:03
opendevreviewLee Yarwood proposed openstack/nova master: libvirt: Introduce support for qcow2 with LUKS  https://review.opendev.org/c/openstack/nova/+/77227318:03
opendevreviewLee Yarwood proposed openstack/nova master: privsep: Move qemu-img create calls under nova.privsep.qemu  https://review.opendev.org/c/openstack/nova/+/82675018:03
opendevreviewLee Yarwood proposed openstack/nova master: privsep: Return QemuImgInfo objects from qemu-img info calls  https://review.opendev.org/c/openstack/nova/+/82675118:03
opendevreviewLee Yarwood proposed openstack/nova master: privsep: Add encryption support to qemu-img create command  https://review.opendev.org/c/openstack/nova/+/82675218:03
opendevreviewLee Yarwood proposed openstack/nova master: libvirt: Report ephemeral encryption traits based on imagebackend  https://review.opendev.org/c/openstack/nova/+/82675318:03
opendevreviewLee Yarwood proposed openstack/nova master: libvirt: Configure and teardown ephemeral encryption secrets  https://review.opendev.org/c/openstack/nova/+/82675418:03
opendevreviewLee Yarwood proposed openstack/nova master: imagebackend: Add support to libvirt_info for LUKS based encryption  https://review.opendev.org/c/openstack/nova/+/82675518:03
opendevreviewLee Yarwood proposed openstack/nova master: imagebackend: Cache the key manager when disk is encrypted  https://review.opendev.org/c/openstack/nova/+/82675618:03
sean-k-mooneyprometheanfire: so can you see if adding the file will actully resolve this 18:05
prometheanfiresean-k-mooney: fix already deployed :|18:05
sean-k-mooneyok so you are fixing via packaging18:06
prometheanfireyep, ovmf from buster-backports18:06
sean-k-mooneyi think we might stil need to update the doc18:06
prometheanfireprobably18:06
EugenMayerto 'unstuck from a stuck iamge backup task' i used 'nova reset-state` .. eventhough the task did not show up, i can neither restart the instance soft or hard. So somehow it is still in an undefined state. Any hint how to get out of this (alive :) )18:10
gansoHi folks. I see that since Wallaby the option --live has been removed from the migrate command, therefore not providing a way to bypass the scheduler. I have a customer that is trying to evacuate a host for maintenance and is not able to evacuate because of the anti-affinity policy, therefore the scheduler needs to be bypassed. I've looked at the evacuate commands but I strongly suspect that they will not bypass the scheduler18:13
gansoIs there any other way to bypass the scheduler?18:13
EugenMayerganso there was a hack i got told, but i forgot about it (had the same question). I ended up backing up the instance and restoring it with the other affinity policy, the moving it to the new host during the restore18:16
gansoEugenMayer: thanks! unfortunately the instance cannot be shutdown :\18:17
EugenMayerAll in one, comparing to what i know from k8s, affinity policies in openstack are really clunky since changing the basically means 'rebuilding the instance'18:17
EugenMayerganso well, no clue then, sorry18:17
gansoEugenMayer: yea the instance cannot be removed from the group, it is only added to the group when it is created and removed only when deleted... I'm trying to avoid DB surgery18:18
EugenMayerah i remember what it was, i think you just downgrade the API level in the cli and force the parameter anyway - i think that was it18:19
EugenMayeryou should test that though - do not trust me :)18:19
rosmaitabauzas: i posted these to deal with the openstacksdk-functional-devstack failures in the stable branches: https://review.opendev.org/q/topic:fix-sdk-func-job ... want me to do a set for nova?18:23
gansoEugenMayer: that is still not working, but it is not working for other reason (I am to blame), just a min18:25
gansoEugenMayer: this: https://review.opendev.org/c/openstack/nova/+/80011418:25
gansoEugenMayer: apparently this might work  CONF.workarounds.disable_group_policy_check_upcall18:27
EugenMayerinteresting18:28
sean-k-mooneyganso: you can use the old microversion but we really dont like supproting forced live migrations18:29
sean-k-mooneyganso: if yo just want to specify the host you can now do that18:29
sean-k-mooneybut it wont bypass the schduler18:29
sean-k-mooneyevacuate does not use live migration by the way18:30
gansosean-k-mooney: yea but apparently it is not a matter of bypassing the scheduler anymore, I think, but I'm confused to how this worked in this past... my patch broke the functionality, but I can't see exactly how the forced host could also bypass the anti-affinity check before18:31
gansosean-k-mooney: oh it doesn't? I won't run pre_live_migration checks if it is a live-evacuation?18:31
EugenMayersean-k-mooney i recall you helped me unstack an instance which had an endless/stack task (image backup) running. I tried to reset state but i still cannot restart the instance or check the logs/console. Are there any leftovers?18:31
sean-k-mooneyganso: it wont bypass the late affintiy check on the compute18:31
sean-k-mooneyyou can only bypass that by disabling it on the host temporaly18:32
sean-k-mooneyganso: live evacuation are not a thing at the api level its a nova client thing18:33
sean-k-mooneyso nova host-evacuate-live18:33
sean-k-mooneyis just a clisnt side for loop that does live migrations18:33
gansosean-k-mooney: oh, therefore it will use live-migration code at the backend18:34
sean-k-mooneyganso: the workaroudn you can do for new is select a singel host, temperally disable the upcall then migrate teh host to the host useing a force live migratio nwith the old microversion18:34
sean-k-mooneythen renable the upcall18:34
sean-k-mooneyganso: yes18:34
gansosean-k-mooney: thanks!18:35
sean-k-mooneylol im glad you coudl read that. i am slightly distracted and that had more typos then i usually have18:36
gansosean-k-mooney: lol np it isn't hard to spellcheck while reading xD18:38
elodillessean-k-mooney: sorry for the late answer. so, no, i didn't know about any pip issue in centos job. though my local devstack started to fail with the very same point (pip bootstrap; ubuntu focal host), so it's weird :S19:05
sean-k-mooneyelodilles: pip upsteream now require py3.7+19:06
sean-k-mooneysince 3.6 is eol19:06
sean-k-mooneymy local hack which i have not push is to skip installing pip form pypi if pip is already installed19:06
elodillesit's interesting, because py3.8 is on the host19:07
sean-k-mooneyis that you default python19:07
elodillessean-k-mooney: i did exactly the same as a temporary fix19:07
elodillesyepp, 3.8 is the default19:07
sean-k-mooneyya so we used to install pip form pypi in the past becasue the default was old19:07
sean-k-mooneybut im thinking maybe we shoudl rever to the package manager version19:08
sean-k-mooneyor at least have an option too19:08
elodillesgood question19:08
elodillesi need to leave now... but my feeling is that we will see the issue in other jobs as well in the coming days, so some kind of general fix might be needed19:21
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: [yoga] Add PCI VPD Capability Handling  https://review.opendev.org/c/openstack/nova/+/80819921:25
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: [yoga] Include pf mac and vf num in port updates  https://review.opendev.org/c/openstack/nova/+/82483321:25
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: [yoga] Introduce remote_managed tag for PCI devices  https://review.opendev.org/c/openstack/nova/+/82483421:25
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: [yoga] Add support for VNIC_TYPE_SMARTNIC  https://review.opendev.org/c/openstack/nova/+/82483521:25
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: Bump os-traits to 2.7.0  https://review.opendev.org/c/openstack/nova/+/82667521:25
opendevreviewDmitrii Shcherbakov proposed openstack/nova master: Filter computes without remote-managed ports early  https://review.opendev.org/c/openstack/nova/+/81211121:25
*** dasm is now known as dasm|off22:58

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