Friday, 2023-03-10

opendevreviewmelanie witt proposed openstack/nova master: testing: Fix and robustify archive_deleted_rows test  https://review.opendev.org/c/openstack/nova/+/87705502:14
opendevreviewmelanie witt proposed openstack/nova master: database: Archive parent and child rows "trees" one at a time  https://review.opendev.org/c/openstack/nova/+/87705602:14
*** thelounge556 is now known as thelounge5507:45
zigoMy first Antelope VM pings ! :)09:15
gibizigo: awesome \o/09:20
bauzaspong09:23
bauzasgibi: sean-k-mooney: I would appreciate your comments on a PTL doc amendment https://review.opendev.org/c/openstack/nova/+/87573010:05
bauzasalso, 10:06
bauzasgibi: sean-k-mooney: some operators would like to know which specs were implemented :) https://review.opendev.org/c/openstack/nova-specs/+/87688710:06
bauzasand eventually, a easy peasy for count_blueprints.py https://review.opendev.org/c/openstack/nova-specs/+/87688810:07
* bauzas is deep down looking into internals of Storyboard to see how to tell 'sorry, please use Launchpad for Placement'10:14
bauzashttps://docs.openstack.org/infra/storyboard/gui/theory.html#the-rest-api looks like there is a REST API and a CLI, lovely10:14
bauzasway better to play with than the web ui from what I've seen in the last 30 mins10:14
gibibauzas: I have only one small commment on the PTL guid patch10:35
bauzascool 10:35
bauzasbtw. this isn't a simple task to leave Storyboard AFAIK10:36
bauzasI'll need to discuss this with the infra folks and the storyboard team (if it still exists :) )10:36
bauzasgibi: that's fun but fwiw, I just noticed last week of takashi's diligence of creating those schedule wikipages every cyvcle10:47
gibi:)10:48
bauzasIMHO if we really want to add more nova-specific deadlines, we would need to stuff it into https://releases.openstack.org/bobcat/schedule.html10:48
bauzasnot sure a lot of us still checkouts the wiki besides the meeting agenda :)10:48
bauzas(but don't get me wrong, I like the wiki for its convenience)10:49
bauzasgibi: as you see, we can add project-specific deadlines https://releases.openstack.org/bobcat/schedule.html#project-specific-events10:49
gibicool that is then probably a better place than the wikipage10:50
bauzasI'll then explain this in the PTL doc10:58
gibiOK10:58
bauzasand next week's meeting, I'll propose the usual times for spec freeze and feature freeze10:58
bauzasso I could add them in the schedule page10:59
opendevreviewSylvain Bauza proposed openstack/nova master: Update to the PTL guide  https://review.opendev.org/c/openstack/nova/+/87573012:02
opendevreviewDanylo Vodopianov proposed openstack/os-vif master: Openvswitch driver was extended  https://review.opendev.org/c/openstack/os-vif/+/85957412:37
zigoIs it normal that the openstackclient now shows so many fields when doing "server show", with some fields looking like not useful at all?!? :)13:11
zigo(many fields having no values at all...)13:11
zigo(some being redondant too...)13:16
sean-k-mooneythats more of a client question we dont really have any inflance over that13:25
sean-k-mooneybut on the otherhand some people might depend on some of the out put so it might not be wise to remove things13:26
sean-k-mooneypeopel will have differnt definitoin of userful13:26
sean-k-mooneyzigo: do you have an example out put13:26
zigosean-k-mooney: https://paste.opendev.org/show/b7FfjsIpFW6o5NS9slD9/13:27
sean-k-mooneythis is what i get as an admin https://paste.opendev.org/show/bHaPZKj88T8mQ5uulgH7/13:28
zigoWhat's the point of accessIPv4, accessIPv6, access_ipv4, access_ipv6, private_v4, private_v6 for example?13:28
sean-k-mooneythat is not what i get with my version of osc13:28
zigoI have a way more on my setup ...13:28
sean-k-mooneyaccessIPv4, accessIPv6, are optional feilds that peopel can use to track the ip to use to access a vm13:29
sean-k-mooneyit just metadta on the instance that enduser can use it not used by nova13:29
zigoYeah, except that they are empty, and show twice ...13:29
sean-k-mooneythey are empty unless you set them in the server create/update13:29
sean-k-mooneythese used ot be used for nova-netowrks13:29
sean-k-mooneywhat version of osc are you using 13:30
sean-k-mooneyi was using 6.0.013:30
zigo6.1.013:30
zigoThe "location" field also looks weird ...13:31
sean-k-mooneyok so ya i get the same now13:31
zigoWhat's that Munch() thingy?13:31
sean-k-mooneyits a clase we use as part of the prtty prining of data13:32
sean-k-mooneyits part of how dicts are rendered using click/cliff13:32
zigoAll of this, I don't really mind much, but IMO, it's going to confuse users a lot !13:32
sean-k-mooneyzigo: it kind of looks like someone wen through all the files that could be returned and rendered them by default13:33
sean-k-mooneyzigo: right but hte nova team is not really invovled in osc13:33
zigoAlso, why do we now have attached_volumes AND volumes_attached ? Do we need this *TWICE* ? :)13:33
sean-k-mooneylike we were not asked about any of these changes13:33
zigoOk.13:34
sean-k-mooneyhttps://github.com/openstack/python-openstackclient/commit/794334ec2405bcfe086b3a56c796a9b6c2f7c685 might be related13:35
sean-k-mooneyit may have incorectly resulting in --long effectilgy being always used13:35
sean-k-mooneyno its this https://github.com/openstack/python-openstackclient/commit/70dbb01ea3ed900a41092d46ed5ae1370d5771af13:36
sean-k-mooneythey swap to the sdk but they added a bunch of fields at the same time13:36
sean-k-mooneyi would proably have gated the sdk names behind a flag or somethign and doen it in two patchs13:39
sean-k-mooneyfirst just to swap to sdk with current behavior13:40
sean-k-mooneyalso the client shoudl really use the names of the field n the api resopnce if possible13:40
sean-k-mooneyso im not sure we should use the sdk names at all13:41
sean-k-mooneythe ones that novaclient used are the ones form the api responce so i proably would have -1 that patch if we had been asked to review13:41
sean-k-mooneystephenfin: ^ for awareness13:41
sean-k-mooneygive there have now been two release with that i assume its two late to revert it and disucss this with the wider nova team?13:42
sean-k-mooneywe should at least add it to the ptg adgenda i think to disucss this or have a mailing list thread on the topic13:44
sean-k-mooneyi dont nessicarly disagree that the new names are more consitent but it breaks the idea that if you want to include a coluem you use -c with the api field 13:45
zigoI agree with all you wrote above. :)13:55
sean-k-mooneyhttps://review.opendev.org/c/openstack/python-openstackclient/+/87701713:55
sean-k-mooneyi propsoed a revert so we can discuss the way forward13:55
sean-k-mooneyill add it to the ptg adgenda13:56
zigoYou may want to review your patch header (typoes...) :)13:56
gibibauzas: how do you feel about requiring that share_mapping.id is an sa.BigInteger from the start?14:21
bauzasgibi: good question, I have a PTG topic about it14:23
bauzasmaybe not all the tables, but I dunno for this one14:23
* bauzas will try to review Uggla's series hopefully soon14:24
gibibauzas: I will leave a comment to Uggla's but if there is no consensus yet on this then I will keep this optional14:24
Uggla\o/14:24
bauzasgibi: afaik, all our FK ids are not BigInteger yet14:24
gibiyeah, I just thought that if we already know that we want to increase the key space from sa.Integer to a bigger one to avoid the overflow we saw, then maybe want to have share_mapping with a big key from the start so that table does not need to be changed later14:25
bauzasyup meh to me14:26
sean-k-mooneyif we are adding new id fiels i would prefer to use unsigned big ints14:32
sean-k-mooneybasically uint64_t in c++ terms14:32
bauzassean-k-mooney: SQLA doesn't support unsigned ints by default AFAIK https://docs.sqlalchemy.org/en/20/core/types.html14:42
bauzasso you would need to setup an unsigned int object with a mysql variant14:42
bauzasanyway, let's not open this can of worms on a Friday afternoon14:43
sean-k-mooneyyou have ot use the dialect form yes i know14:44
sean-k-mooneybut but what if i want to ruine you weekend :P14:44
sean-k-mooneywe can talk about it next week or on the review but i would at least use a BigInteger field14:45
sean-k-mooney63 bits is still better then 3114:45
bauzaswell, my weenkend is somehow already ruined, the snow isn't there here and the wind is acting like a hairdryer on the very few left snow14:46
sean-k-mooneyif we dont want to rely on https://docs.sqlalchemy.org/en/20/dialects/mysql.html#sqlalchemy.dialects.mysql.BIGINT.params.unsigned then im fine with just the generic bigint14:47
sean-k-mooneythis is going to be a ptg topic anyway14:47
sean-k-mooneybauzas: we had snow here last night14:47
sean-k-mooneyyour welcome to come take it back :P14:47
bauzassean-k-mooney: that depends, how many tracks do you have here ?14:56
bauzas:p14:56
bauzashttps://webcams.lecollet.com/imageSC.jpg when I see this, I cry14:57
bauzasdansmith: if you have a bit of time, could we discuss about https://review.opendev.org/c/openstack/nova/+/875621/2 ?15:00
bauzasdansmith: I'm not really a grenade expert, so I need to make sure I understood it correctly15:00
dansmithbauzas: sure, gmann wants to wait to merge that until devstack and grenade get branched15:01
dansmithwhich usually happens a bit after the last regular project15:01
bauzasack ok15:01
dansmith(the dependent patch I mean)15:01
bauzasI'll look at the open grenade changes then15:01
bauzasdansmith: actually, I haven't done https://review.opendev.org/c/openstack/nova/+/875621/2 depending on your skip-level-always zuul patch15:02
dansmithoh, it's merged now, I missed that15:02
bauzasbut, it still fails for the same reason : grenade has an original branch which is zed and tries to update to master, which is now Bobcat, hence the grenade job failing15:02
bauzasso we need to update grenade to have an original branch to be antelope15:03
dansmithyou mean for regular grenade jobs?15:03
bauzasyep, see my patch  : https://review.opendev.org/c/openstack/nova/+/875621/215:03
dansmiththe skip-always job should be zed->bobcat15:03
bauzasit fails on grenade-multinode https://zuul.opendev.org/t/openstack/build/cd27f6d6a4094fd48b1725e1f63098f115:04
bauzas(which is an expected behaviour, if we upgrade from zed to master)15:04
dansmiththe grenade job as defined in grenade's zuul config should be moving to antelope15:05
bauzasok, that's what I understood and wrote in my last comment then 15:05
bauzashttps://review.opendev.org/c/openstack/nova/+/875621/2#message-cef3c3bb3d8a590cd4d9bf51267a7fe092bd32b215:05
dansmiththat happens after all the projects are branched15:05
bauzasokay15:06
bauzasthat's what I guessed15:06
bauzasthe service projects I guess, not the trailing ones15:06
dansmithyou're moving your OLDEST_SUPPORTED, but will use the workaround to prevent that from breaking on the skip-always job?15:06
dansmithbauzas: anything that runs a grenade job I think15:06
bauzasin my patch ?15:06
dansmithyes15:06
bauzaswell, in my patch, I'm just saying we continue to only support N-1 nodes for a non-SLURP release15:07
bauzaseven if skip-always job workarounds it15:07
bauzashence the service version be Antelope15:07
bauzasonce grenade is modified to have a source env to be Antelope, this will work15:08
dansmiththat's what I just said yeah15:08
bauzasand this is now unrelated to the skip-always job you're doing15:08
bauzassince the skip-always is using the workaround flag15:08
dansmithright15:08
bauzascoo col15:08
bauzasdansmith: my ping was just for making sure I was understand the job failure correctly15:09
bauzasunderstanding*15:09
bauzasthanks so15:09
bauzasI'll wait 15:09
dansmithyeah, I dunno what gmann's schedule is for that.. we could put up the grenade change for you to depends-on I think15:10
dansmithbut i mean, you're bumping the min version, and it's failing on the min version check, because it's still upgrading from zed, so ... pretty straightforward15:11
bauzasyup, I'll track the open grenade changes15:11
bauzashaving a depends-on is nice, because next cycle, people who would write this service version bump would remember we need to hold until grenade is updated15:11
bauzascall it a documentation :)15:11
bauzasactually15:12
bauzaswe won't bump next cycle, as this will be SLURP15:12
dansmithI mean, it's pretty clear why it's failing no? :)15:12
bauzasso the next patch to update the min will be beginning of D, in one year15:12
dansmithbut sure15:12
bauzasdansmith: well, I had to dig into the grenade job to understand what release was used and how15:13
bauzasnothing really difficult, but a Depends-On will make the dependency clearer :)15:13
dansmithbauzas: devstack isn't even branched yet, so a patch can't even really work15:14
dansmithhttps://github.com/openstack/devstack/branches15:14
bauzasyeah, I guess my patch will gonna need to wait until GA probably :)15:15
bauzasbut meh15:15
dansmithconsider it a little extra skip-level coverage ;)15:15
dansmith1.1 releases15:15
bauzas:)15:15
bauzasfor people deploying on master, woooo15:15
* bauzas won't call the audience to raise their hands and say dips on who's running master15:16
bauzasdibs*15:16
dansmithvery incorrect use of dibs15:16
sean-k-mooneythere is nothign wrong with runnng master also that15:17
dansmithdibs implies claim of ownership on, usually on snack foods15:17
bauzasdansmith: pardon my French :p15:17
dansmithhaha15:17
bauzassean-k-mooney: oh I am not saying this is wrong to run against master15:17
bauzasand I'd be proud if operators would do it like they did in the past15:18
sean-k-mooneysame15:18
bauzaswe respect an healthy gate and we very carefully take care of the master stability15:18
bauzasbut, alas, I think those days are gone15:18
sean-k-mooneywe are still going to try an keep it working15:19
bauzasdespite I'm considering to release a bobcat-1 for deployers needs (like zigo) 15:19
sean-k-mooneyyou mean the irst milestone15:19
bauzasyes15:19
bauzaswe did it in the pasyt15:19
bauzasbut we stopped15:19
sean-k-mooneywe are technially release with intermidarys so we are allowed to realse as often as we like15:19
bauzasI want to provide tarballs back15:19
sean-k-mooneywell we are free too its just not done automatically15:20
bauzasI know, and that's something I want to15:20
bauzasand bobcat-3 too15:20
sean-k-mooneyi dont really object as long as we state that they are not full releases15:21
bauzaslast RC1 was juggling so I want some tarball that people can consume 15:21
bauzasbefore the rc1 one15:21
sean-k-mooneyi.e. we wont have bances for them so if they need bugfixes they will have to wiat fo rthe next one15:21
bauzassean-k-mooney: as a reminder, m-1 or m-3 are considered alphas on a semver15:21
zigoIMO, just having a *subset* of OpenStack doing milestones isn't helpful. At the time, I was packaging all intermediary milestones, and nobody was consuming them ...15:21
zigo(not even myself)15:21
bauzasanyway, I need to leave for taxi reasons15:21
sean-k-mooneyo/15:22
sean-k-mooneyhonestly i think distros that want to test early are just better having a conitues build of master somewhere15:23
sean-k-mooneylike having a nightly build so they see when we raise a min version or something15:23
sean-k-mooneybut not really shiping that outside of an experimtal channel15:23
bauzassean-k-mooney: yeah, that's the reason why I want more tarballs but the rc1 one15:49
bauzasdeployers can start to test them 15:49
bauzaseven if they're not consumed by any user15:49
bauzasalso, say we have a rc1 issue like one we had last week, I'm afraid we could only have one tarball 3 weeks before GA if we don't have another one15:50
bauzashence why I'd like to have at least a m-3 tarball and maybe one for m-1 depending on what we already merged15:50
sean-k-mooneybauzas: honestly im not sure tars help much but either way its just a commit to the release repo.15:57
bauzassean-k-mooney: well, maybe but it looks like some operators use a pip version for nova16:04
bauzasso that may also help them to test this pip package version16:05
bauzasanyway, this is simple to do, so let's do it16:05
dansmithmy experience is that most deployers want to build from a release tarball16:19
elodillesi know it's mostly end-of-day already (end-of-week, even), but any idea about this weird issue: when bumping oslo.log u-c from 5.0.0 to 5.1.0 cross-nova-py310 seems to be failing: https://review.opendev.org/c/openstack/requirements/+/873390/16:29
elodillesit seems that oslo.log 5.0.1 and 5.0.2 weren't even bumped, but that could be due to different issues. though what I see is there are eventlet related patches in oslo.log ( https://github.com/openstack/oslo.log/compare/5.0.0...5.1.0 ). could that somehow interfere with those 2 failing unit tests?16:31
gibiUggla: I left some feedback in the Manial series. I planned to do more review on it today and even built a devstack with manila support to try things out. But run out of time before I can dig deep. I see some issues around ShareMapping.detach() and the instance delete with active shares code paths. So I left comments there16:58
Ugglagibi, ok cool, I'll have a look16:58
Ugglagibi, thx !16:58
gibiI have the intention to look more and try this series out, but you can already check these two issues to see if it make sense what I found16:58
Ugglagibi, I'm currently try to setup devstack with ceph.... it is a nighmare...16:59
gibiI only run the default setup with manial so no ceph there17:00
Ugglayep the one with NFS provided on Manila site is ok.17:02
gouthamrUggla: o/ is something failing with devstack and manila/ceph? 17:04
Ugglagouthamr, yep it is not working with jammy, package issue and same with centos stream 917:05
Ugglagouthamr, example on centos9 : ++functions-common:sudo_with_proxies:2391   sudo http_proxy= https_proxy= no_proxy= dnf install -y ceph nfs-ganesha nfs-ganesha-ceph nfs-ganesha-rados-urls nfs-ganesha-vfs17:06
UgglaCeph packages for x86_64                         68 kB/s |  76 kB     00:01    17:06
UgglaCeph noarch packages                             17 kB/s |  15 kB     00:00    17:06
UgglaNFS Ganesha packages for x86_64                  14 kB/s |  13 kB     00:00    17:06
UgglaNFS Ganesha noarch packages                     1.1 kB/s | 1.0 kB     00:00    17:06
UgglaError: 17:06
Uggla Problem: package ceph-2:16.2.11-0.el8.x86_64 requires ceph-mgr = 2:16.2.11-0.el8, but none of the providers can be installed17:06
Uggla  - cannot install the best candidate for the job17:06
Uggla  - nothing provides libpython3.6m.so.1.0()(64bit) needed by ceph-mgr-2:16.2.11-0.el8.x86_6417:06
Uggla(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)17:06
gouthamrah; ty - that's frustrating - let me look at this, most likely devstack-plugin-ceph needs some updates; we're still testing with focal on the CI because packages for Jammy haven't showed up on download.ceph.com17:11
gouthamri haven't tried CS9-stream, i will and raise an issue with the ceph community17:12
Ugglagouthamr, it seams i'm progressing pre installing ceph from https://buildlogs.centos.org/centos/9-stream/storage/x86_64/ceph-pacific/17:18
Ugglagouthamr, not sure if I'll end up with something that works but it has passed the devstack-plugin-ceph stage.17:21
* gouthamr hopes so..17:30
jrosserif anyone has any influence over availabilty of jammy packages at download.ceph.com it would be really really useful to get those published17:31
sean-k-mooneyjrosser: they are onder the debian folders17:43
sean-k-mooneyor at least they used to be17:43
sean-k-mooneyhttp://download.ceph.com/debian-pacific/dists/17:44
jrosseri don't beleive there are any for quincy17:44
sean-k-mooneyyas so pacifici has focal and bionic17:44
sean-k-mooneyi dont see quincy at all17:44
sean-k-mooneyoh its there17:45
sean-k-mooneybut only focal17:45
sean-k-mooneywell and bullsye but that actully debian17:45
sean-k-mooneyit looks like they only build for the lts release17:45
sean-k-mooneyand havent added support for 22.0417:45
sean-k-mooneyi have 0 influance over that but im surpsied they have not clsoed that gap17:46
jrosseri would like to belive it is not intentional17:47
sean-k-mooneyhttps://launchpad.net/ubuntu/+source/ceph17:47
sean-k-mooneyyou can use the ubuntu ppa to get the downstream one17:47
sean-k-mooneyim not sure which release 17.1.0 is https://launchpad.net/ubuntu/+source/ceph/17.1.0-0ubuntu317:48
sean-k-mooneyits quincy https://docs.ceph.com/en/latest/releases/index.html17:49
sean-k-mooneyjrosser: so if the disto package is an option for you thats a workaroudn for now i guess17:50
jrosserit is very nice the way they provide versioned repos at download.ceph.com17:51
sean-k-mooneyyep i prefered using those one personally too17:51
jrosser"as an operator" I want to test some version and stick rigidly to it unless i decide to change it17:51
dansmithI surely hope that's not going away17:51
sean-k-mooneyit looks like its still built for 20.0417:52
jrosserso taking the packages from ubuntu or UCA is really unappealing to me as the pinning is much harder17:52
sean-k-mooneyya the 20.04 package might just work but i would be good to reach out to the ceph comuncity and see if it can get fixed17:53
jrossersean-k-mooney: btw i had an unrelated question - what would you expect to happen if you upload an aarch64 image to an x86 cloud and boot it?17:55
jrosserbecasue i was very surprised when it booted on an x86 node under emulation rather than fail17:55
dansmithno valid host17:55
dansmithdid you set the arch on the image?17:56
jrosserincorrectly - to 'arm'17:56
sean-k-mooneyjrosser: https://github.com/ceph/ceph/pull/49087 looks like they curerntly have som build issue due t python 3.1017:56
dansmithI thought we filter hosts by arch, but maybe not17:56
sean-k-mooneyjrosser: emulation was added recently17:57
dansmithohhh, right17:57
jrosserfrom the docs i though i had to set a property to make that happen17:57
dansmithI thought you had to opt into that17:57
clarkbhttps://packages.ubuntu.com/jammy-updates/ceph is not UCA and shouldn't change17:57
sean-k-mooneyhttps://specs.openstack.org/openstack/nova-specs/specs/yoga/implemented/pick-guest-arch-based-on-host-arch-in-libvirt-driver.html17:58
jrosserwhilst i was looking at this i thought there might be a docs bug here https://docs.openstack.org/nova/latest/admin/scheduling.html#imagepropertiesfilter18:00
dansmithseems like that shoudn't be easy to enable "accidentally"18:00
jrosser'Describes the machine architecture required by the image. Examples are i686, x86_64, arm, and ppc64.'18:00
jrosserarm vs AARCH64 ^ there18:00
sean-k-mooneyjrosser: https://github.com/openstack/nova/blob/master/nova/objects/fields.py#L120-L17118:01
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/virt/arch.py#L16-L6518:02
sean-k-mooneyso you shoudl use aarch6418:02
sean-k-mooneyfor 64bit arm18:02
sean-k-mooneyin the image properies that is 18:03
sean-k-mooneyfor the machine type i think its the same value18:03
jrosserit is also unclear if those are / are not the same strings defined in os-traits18:03
jrosseri need to investigate this more next week but what would it be that steers an hw_architecture=aarch6418:05
sean-k-mooney hw_architecture=aarch64 should select a host that is  aarch6418:06
jrossereven when setting that correct it's consistently choosing an x86 compute node but i'm not sure what to check regarding the arm node to check it is a valid candiate to schedule to18:06
sean-k-mooneyand you defintly dont have hw_emulation_architecture set18:08
jrosserno - i didnt know about that until trying to find out how the vm ended up on the wrong node18:09
sean-k-mooneylooking at the code without that set it shoudl not be using emulation18:10
sean-k-mooneyunless you have virt_type=qemu?18:10
jrosserthats set to kvm18:11
sean-k-mooneyso this lookd right https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5242-L527718:12
sean-k-mooneyhttps://github.com/openstack/nova/blob/373be3db5b7b058767ddac50ff1367725c932a84/nova/virt/libvirt/utils.py#L509-L52618:12
sean-k-mooneyso do you have hw_architecture set18:12
sean-k-mooneyi can maybe see why it activating on the comptue side18:14
sean-k-mooneybut im not sure why its scudlign to the compute18:14
jrosseri think currently hw_architecture is set to 'AARCH64"18:15
jrosserso that could still be wrong18:15
sean-k-mooneyno i think we dont care about the casing but not sure18:16
sean-k-mooneyif you have that version of qemu i think it will be able to boot18:16
sean-k-mooneymy guess is you dont have the request filter enabled?18:17
sean-k-mooneydo you have teh  transform_image_metadata prefilter enabled18:17
sean-k-mooney[scheduler]image_metadata_prefilter18:18
sean-k-mooneyhttps://docs.openstack.org/nova/latest/configuration/config.html#scheduler.image_metadata_prefilter18:18
sean-k-mooneythat is what enforce the host selection18:18
sean-k-mooneyas far as i am aware emulation is enabeld by default if you have the binary avaiable18:20
sean-k-mooneyat least without enable the prefilter18:21
sean-k-mooneywe should turn that prefilter on by default18:21
jrosserok i will look at the prefilter18:21
sean-k-mooneybut we dont currently18:21
jrosseri want it to not schdule at all to x86 when i have real arm nodes18:22
* jrosser has to head out - thanks for the pointers18:22
opendevreviewTyler Stachecki proposed openstack/nova master: nova-scheduler: Encourage weighers to spread  https://review.opendev.org/c/openstack/nova/+/87628922:03

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