| opendevreview | melanie witt proposed openstack/nova master: testing: Fix and robustify archive_deleted_rows test https://review.opendev.org/c/openstack/nova/+/877055 | 02:14 |
|---|---|---|
| opendevreview | melanie witt proposed openstack/nova master: database: Archive parent and child rows "trees" one at a time https://review.opendev.org/c/openstack/nova/+/877056 | 02:14 |
| *** thelounge556 is now known as thelounge55 | 07:45 | |
| zigo | My first Antelope VM pings ! :) | 09:15 |
| gibi | zigo: awesome \o/ | 09:20 |
| bauzas | pong | 09:23 |
| bauzas | gibi: sean-k-mooney: I would appreciate your comments on a PTL doc amendment https://review.opendev.org/c/openstack/nova/+/875730 | 10:05 |
| bauzas | also, | 10:06 |
| bauzas | gibi: sean-k-mooney: some operators would like to know which specs were implemented :) https://review.opendev.org/c/openstack/nova-specs/+/876887 | 10:06 |
| bauzas | and eventually, a easy peasy for count_blueprints.py https://review.opendev.org/c/openstack/nova-specs/+/876888 | 10:07 |
| * bauzas is deep down looking into internals of Storyboard to see how to tell 'sorry, please use Launchpad for Placement' | 10:14 | |
| bauzas | https://docs.openstack.org/infra/storyboard/gui/theory.html#the-rest-api looks like there is a REST API and a CLI, lovely | 10:14 |
| bauzas | way better to play with than the web ui from what I've seen in the last 30 mins | 10:14 |
| gibi | bauzas: I have only one small commment on the PTL guid patch | 10:35 |
| bauzas | cool | 10:35 |
| bauzas | btw. this isn't a simple task to leave Storyboard AFAIK | 10:36 |
| bauzas | I'll need to discuss this with the infra folks and the storyboard team (if it still exists :) ) | 10:36 |
| bauzas | gibi: that's fun but fwiw, I just noticed last week of takashi's diligence of creating those schedule wikipages every cyvcle | 10:47 |
| gibi | :) | 10:48 |
| bauzas | IMHO if we really want to add more nova-specific deadlines, we would need to stuff it into https://releases.openstack.org/bobcat/schedule.html | 10:48 |
| bauzas | not 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 |
| bauzas | gibi: as you see, we can add project-specific deadlines https://releases.openstack.org/bobcat/schedule.html#project-specific-events | 10:49 |
| gibi | cool that is then probably a better place than the wikipage | 10:50 |
| bauzas | I'll then explain this in the PTL doc | 10:58 |
| gibi | OK | 10:58 |
| bauzas | and next week's meeting, I'll propose the usual times for spec freeze and feature freeze | 10:58 |
| bauzas | so I could add them in the schedule page | 10:59 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Update to the PTL guide https://review.opendev.org/c/openstack/nova/+/875730 | 12:02 |
| opendevreview | Danylo Vodopianov proposed openstack/os-vif master: Openvswitch driver was extended https://review.opendev.org/c/openstack/os-vif/+/859574 | 12:37 |
| zigo | Is 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-mooney | thats more of a client question we dont really have any inflance over that | 13:25 |
| sean-k-mooney | but on the otherhand some people might depend on some of the out put so it might not be wise to remove things | 13:26 |
| sean-k-mooney | peopel will have differnt definitoin of userful | 13:26 |
| sean-k-mooney | zigo: do you have an example out put | 13:26 |
| zigo | sean-k-mooney: https://paste.opendev.org/show/b7FfjsIpFW6o5NS9slD9/ | 13:27 |
| sean-k-mooney | this is what i get as an admin https://paste.opendev.org/show/bHaPZKj88T8mQ5uulgH7/ | 13:28 |
| zigo | What's the point of accessIPv4, accessIPv6, access_ipv4, access_ipv6, private_v4, private_v6 for example? | 13:28 |
| sean-k-mooney | that is not what i get with my version of osc | 13:28 |
| zigo | I have a way more on my setup ... | 13:28 |
| sean-k-mooney | accessIPv4, accessIPv6, are optional feilds that peopel can use to track the ip to use to access a vm | 13:29 |
| sean-k-mooney | it just metadta on the instance that enduser can use it not used by nova | 13:29 |
| zigo | Yeah, except that they are empty, and show twice ... | 13:29 |
| sean-k-mooney | they are empty unless you set them in the server create/update | 13:29 |
| sean-k-mooney | these used ot be used for nova-netowrks | 13:29 |
| sean-k-mooney | what version of osc are you using | 13:30 |
| sean-k-mooney | i was using 6.0.0 | 13:30 |
| zigo | 6.1.0 | 13:30 |
| zigo | The "location" field also looks weird ... | 13:31 |
| sean-k-mooney | ok so ya i get the same now | 13:31 |
| zigo | What's that Munch() thingy? | 13:31 |
| sean-k-mooney | its a clase we use as part of the prtty prining of data | 13:32 |
| sean-k-mooney | its part of how dicts are rendered using click/cliff | 13:32 |
| zigo | All of this, I don't really mind much, but IMO, it's going to confuse users a lot ! | 13:32 |
| sean-k-mooney | zigo: it kind of looks like someone wen through all the files that could be returned and rendered them by default | 13:33 |
| sean-k-mooney | zigo: right but hte nova team is not really invovled in osc | 13:33 |
| zigo | Also, why do we now have attached_volumes AND volumes_attached ? Do we need this *TWICE* ? :) | 13:33 |
| sean-k-mooney | like we were not asked about any of these changes | 13:33 |
| zigo | Ok. | 13:34 |
| sean-k-mooney | https://github.com/openstack/python-openstackclient/commit/794334ec2405bcfe086b3a56c796a9b6c2f7c685 might be related | 13:35 |
| sean-k-mooney | it may have incorectly resulting in --long effectilgy being always used | 13:35 |
| sean-k-mooney | no its this https://github.com/openstack/python-openstackclient/commit/70dbb01ea3ed900a41092d46ed5ae1370d5771af | 13:36 |
| sean-k-mooney | they swap to the sdk but they added a bunch of fields at the same time | 13:36 |
| sean-k-mooney | i would proably have gated the sdk names behind a flag or somethign and doen it in two patchs | 13:39 |
| sean-k-mooney | first just to swap to sdk with current behavior | 13:40 |
| sean-k-mooney | also the client shoudl really use the names of the field n the api resopnce if possible | 13:40 |
| sean-k-mooney | so im not sure we should use the sdk names at all | 13:41 |
| sean-k-mooney | the 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 review | 13:41 |
| sean-k-mooney | stephenfin: ^ for awareness | 13:41 |
| sean-k-mooney | give 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-mooney | we should at least add it to the ptg adgenda i think to disucss this or have a mailing list thread on the topic | 13:44 |
| sean-k-mooney | i 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 |
| zigo | I agree with all you wrote above. :) | 13:55 |
| sean-k-mooney | https://review.opendev.org/c/openstack/python-openstackclient/+/877017 | 13:55 |
| sean-k-mooney | i propsoed a revert so we can discuss the way forward | 13:55 |
| sean-k-mooney | ill add it to the ptg adgenda | 13:56 |
| zigo | You may want to review your patch header (typoes...) :) | 13:56 |
| gibi | bauzas: how do you feel about requiring that share_mapping.id is an sa.BigInteger from the start? | 14:21 |
| bauzas | gibi: good question, I have a PTG topic about it | 14:23 |
| bauzas | maybe not all the tables, but I dunno for this one | 14:23 |
| * bauzas will try to review Uggla's series hopefully soon | 14:24 | |
| gibi | bauzas: I will leave a comment to Uggla's but if there is no consensus yet on this then I will keep this optional | 14:24 |
| Uggla | \o/ | 14:24 |
| bauzas | gibi: afaik, all our FK ids are not BigInteger yet | 14:24 |
| gibi | yeah, 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 later | 14:25 |
| bauzas | yup meh to me | 14:26 |
| sean-k-mooney | if we are adding new id fiels i would prefer to use unsigned big ints | 14:32 |
| sean-k-mooney | basically uint64_t in c++ terms | 14:32 |
| bauzas | sean-k-mooney: SQLA doesn't support unsigned ints by default AFAIK https://docs.sqlalchemy.org/en/20/core/types.html | 14:42 |
| bauzas | so you would need to setup an unsigned int object with a mysql variant | 14:42 |
| bauzas | anyway, let's not open this can of worms on a Friday afternoon | 14:43 |
| sean-k-mooney | you have ot use the dialect form yes i know | 14:44 |
| sean-k-mooney | but but what if i want to ruine you weekend :P | 14:44 |
| sean-k-mooney | we can talk about it next week or on the review but i would at least use a BigInteger field | 14:45 |
| sean-k-mooney | 63 bits is still better then 31 | 14:45 |
| bauzas | well, 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 snow | 14:46 |
| sean-k-mooney | if 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 bigint | 14:47 |
| sean-k-mooney | this is going to be a ptg topic anyway | 14:47 |
| sean-k-mooney | bauzas: we had snow here last night | 14:47 |
| sean-k-mooney | your welcome to come take it back :P | 14:47 |
| bauzas | sean-k-mooney: that depends, how many tracks do you have here ? | 14:56 |
| bauzas | :p | 14:56 |
| bauzas | https://webcams.lecollet.com/imageSC.jpg when I see this, I cry | 14:57 |
| bauzas | dansmith: if you have a bit of time, could we discuss about https://review.opendev.org/c/openstack/nova/+/875621/2 ? | 15:00 |
| bauzas | dansmith: I'm not really a grenade expert, so I need to make sure I understood it correctly | 15:00 |
| dansmith | bauzas: sure, gmann wants to wait to merge that until devstack and grenade get branched | 15:01 |
| dansmith | which usually happens a bit after the last regular project | 15:01 |
| bauzas | ack ok | 15:01 |
| dansmith | (the dependent patch I mean) | 15:01 |
| bauzas | I'll look at the open grenade changes then | 15:01 |
| bauzas | dansmith: actually, I haven't done https://review.opendev.org/c/openstack/nova/+/875621/2 depending on your skip-level-always zuul patch | 15:02 |
| dansmith | oh, it's merged now, I missed that | 15:02 |
| bauzas | but, 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 failing | 15:02 |
| bauzas | so we need to update grenade to have an original branch to be antelope | 15:03 |
| dansmith | you mean for regular grenade jobs? | 15:03 |
| bauzas | yep, see my patch : https://review.opendev.org/c/openstack/nova/+/875621/2 | 15:03 |
| dansmith | the skip-always job should be zed->bobcat | 15:03 |
| bauzas | it fails on grenade-multinode https://zuul.opendev.org/t/openstack/build/cd27f6d6a4094fd48b1725e1f63098f1 | 15:04 |
| bauzas | (which is an expected behaviour, if we upgrade from zed to master) | 15:04 |
| dansmith | the grenade job as defined in grenade's zuul config should be moving to antelope | 15:05 |
| bauzas | ok, that's what I understood and wrote in my last comment then | 15:05 |
| bauzas | https://review.opendev.org/c/openstack/nova/+/875621/2#message-cef3c3bb3d8a590cd4d9bf51267a7fe092bd32b2 | 15:05 |
| dansmith | that happens after all the projects are branched | 15:05 |
| bauzas | okay | 15:06 |
| bauzas | that's what I guessed | 15:06 |
| bauzas | the service projects I guess, not the trailing ones | 15:06 |
| dansmith | you're moving your OLDEST_SUPPORTED, but will use the workaround to prevent that from breaking on the skip-always job? | 15:06 |
| dansmith | bauzas: anything that runs a grenade job I think | 15:06 |
| bauzas | in my patch ? | 15:06 |
| dansmith | yes | 15:06 |
| bauzas | well, in my patch, I'm just saying we continue to only support N-1 nodes for a non-SLURP release | 15:07 |
| bauzas | even if skip-always job workarounds it | 15:07 |
| bauzas | hence the service version be Antelope | 15:07 |
| bauzas | once grenade is modified to have a source env to be Antelope, this will work | 15:08 |
| dansmith | that's what I just said yeah | 15:08 |
| bauzas | and this is now unrelated to the skip-always job you're doing | 15:08 |
| bauzas | since the skip-always is using the workaround flag | 15:08 |
| dansmith | right | 15:08 |
| bauzas | coo col | 15:08 |
| bauzas | dansmith: my ping was just for making sure I was understand the job failure correctly | 15:09 |
| bauzas | understanding* | 15:09 |
| bauzas | thanks so | 15:09 |
| bauzas | I'll wait | 15:09 |
| dansmith | yeah, I dunno what gmann's schedule is for that.. we could put up the grenade change for you to depends-on I think | 15:10 |
| dansmith | but 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 straightforward | 15:11 |
| bauzas | yup, I'll track the open grenade changes | 15:11 |
| bauzas | having 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 updated | 15:11 |
| bauzas | call it a documentation :) | 15:11 |
| bauzas | actually | 15:12 |
| bauzas | we won't bump next cycle, as this will be SLURP | 15:12 |
| dansmith | I mean, it's pretty clear why it's failing no? :) | 15:12 |
| bauzas | so the next patch to update the min will be beginning of D, in one year | 15:12 |
| dansmith | but sure | 15:12 |
| bauzas | dansmith: well, I had to dig into the grenade job to understand what release was used and how | 15:13 |
| bauzas | nothing really difficult, but a Depends-On will make the dependency clearer :) | 15:13 |
| dansmith | bauzas: devstack isn't even branched yet, so a patch can't even really work | 15:14 |
| dansmith | https://github.com/openstack/devstack/branches | 15:14 |
| bauzas | yeah, I guess my patch will gonna need to wait until GA probably :) | 15:15 |
| bauzas | but meh | 15:15 |
| dansmith | consider it a little extra skip-level coverage ;) | 15:15 |
| dansmith | 1.1 releases | 15:15 |
| bauzas | :) | 15:15 |
| bauzas | for people deploying on master, woooo | 15:15 |
| * bauzas won't call the audience to raise their hands and say dips on who's running master | 15:16 | |
| bauzas | dibs* | 15:16 |
| dansmith | very incorrect use of dibs | 15:16 |
| sean-k-mooney | there is nothign wrong with runnng master also that | 15:17 |
| dansmith | dibs implies claim of ownership on, usually on snack foods | 15:17 |
| bauzas | dansmith: pardon my French :p | 15:17 |
| dansmith | haha | 15:17 |
| bauzas | sean-k-mooney: oh I am not saying this is wrong to run against master | 15:17 |
| bauzas | and I'd be proud if operators would do it like they did in the past | 15:18 |
| sean-k-mooney | same | 15:18 |
| bauzas | we respect an healthy gate and we very carefully take care of the master stability | 15:18 |
| bauzas | but, alas, I think those days are gone | 15:18 |
| sean-k-mooney | we are still going to try an keep it working | 15:19 |
| bauzas | despite I'm considering to release a bobcat-1 for deployers needs (like zigo) | 15:19 |
| sean-k-mooney | you mean the irst milestone | 15:19 |
| bauzas | yes | 15:19 |
| bauzas | we did it in the pasyt | 15:19 |
| bauzas | but we stopped | 15:19 |
| sean-k-mooney | we are technially release with intermidarys so we are allowed to realse as often as we like | 15:19 |
| bauzas | I want to provide tarballs back | 15:19 |
| sean-k-mooney | well we are free too its just not done automatically | 15:20 |
| bauzas | I know, and that's something I want to | 15:20 |
| bauzas | and bobcat-3 too | 15:20 |
| sean-k-mooney | i dont really object as long as we state that they are not full releases | 15:21 |
| bauzas | last RC1 was juggling so I want some tarball that people can consume | 15:21 |
| bauzas | before the rc1 one | 15:21 |
| sean-k-mooney | i.e. we wont have bances for them so if they need bugfixes they will have to wiat fo rthe next one | 15:21 |
| bauzas | sean-k-mooney: as a reminder, m-1 or m-3 are considered alphas on a semver | 15:21 |
| zigo | IMO, 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 |
| bauzas | anyway, I need to leave for taxi reasons | 15:21 |
| sean-k-mooney | o/ | 15:22 |
| sean-k-mooney | honestly i think distros that want to test early are just better having a conitues build of master somewhere | 15:23 |
| sean-k-mooney | like having a nightly build so they see when we raise a min version or something | 15:23 |
| sean-k-mooney | but not really shiping that outside of an experimtal channel | 15:23 |
| bauzas | sean-k-mooney: yeah, that's the reason why I want more tarballs but the rc1 one | 15:49 |
| bauzas | deployers can start to test them | 15:49 |
| bauzas | even if they're not consumed by any user | 15:49 |
| bauzas | also, 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 one | 15:50 |
| bauzas | hence why I'd like to have at least a m-3 tarball and maybe one for m-1 depending on what we already merged | 15:50 |
| sean-k-mooney | bauzas: honestly im not sure tars help much but either way its just a commit to the release repo. | 15:57 |
| bauzas | sean-k-mooney: well, maybe but it looks like some operators use a pip version for nova | 16:04 |
| bauzas | so that may also help them to test this pip package version | 16:05 |
| bauzas | anyway, this is simple to do, so let's do it | 16:05 |
| dansmith | my experience is that most deployers want to build from a release tarball | 16:19 |
| elodilles | i 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 |
| elodilles | it 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 |
| gibi | Uggla: 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 there | 16:58 |
| Uggla | gibi, ok cool, I'll have a look | 16:58 |
| Uggla | gibi, thx ! | 16:58 |
| gibi | I 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 found | 16:58 |
| Uggla | gibi, I'm currently try to setup devstack with ceph.... it is a nighmare... | 16:59 |
| gibi | I only run the default setup with manial so no ceph there | 17:00 |
| Uggla | yep the one with NFS provided on Manila site is ok. | 17:02 |
| gouthamr | Uggla: o/ is something failing with devstack and manila/ceph? | 17:04 |
| Uggla | gouthamr, yep it is not working with jammy, package issue and same with centos stream 9 | 17:05 |
| Uggla | gouthamr, 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-vfs | 17:06 |
| Uggla | Ceph packages for x86_64 68 kB/s | 76 kB 00:01 | 17:06 |
| Uggla | Ceph noarch packages 17 kB/s | 15 kB 00:00 | 17:06 |
| Uggla | NFS Ganesha packages for x86_64 14 kB/s | 13 kB 00:00 | 17:06 |
| Uggla | NFS Ganesha noarch packages 1.1 kB/s | 1.0 kB 00:00 | 17:06 |
| Uggla | Error: | 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 installed | 17:06 |
| Uggla | - cannot install the best candidate for the job | 17:06 |
| Uggla | - nothing provides libpython3.6m.so.1.0()(64bit) needed by ceph-mgr-2:16.2.11-0.el8.x86_64 | 17:06 |
| Uggla | (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) | 17:06 |
| gouthamr | ah; 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.com | 17:11 |
| gouthamr | i haven't tried CS9-stream, i will and raise an issue with the ceph community | 17:12 |
| Uggla | gouthamr, it seams i'm progressing pre installing ceph from https://buildlogs.centos.org/centos/9-stream/storage/x86_64/ceph-pacific/ | 17:18 |
| Uggla | gouthamr, 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 | |
| jrosser | if anyone has any influence over availabilty of jammy packages at download.ceph.com it would be really really useful to get those published | 17:31 |
| sean-k-mooney | jrosser: they are onder the debian folders | 17:43 |
| sean-k-mooney | or at least they used to be | 17:43 |
| sean-k-mooney | http://download.ceph.com/debian-pacific/dists/ | 17:44 |
| jrosser | i don't beleive there are any for quincy | 17:44 |
| sean-k-mooney | yas so pacifici has focal and bionic | 17:44 |
| sean-k-mooney | i dont see quincy at all | 17:44 |
| sean-k-mooney | oh its there | 17:45 |
| sean-k-mooney | but only focal | 17:45 |
| sean-k-mooney | well and bullsye but that actully debian | 17:45 |
| sean-k-mooney | it looks like they only build for the lts release | 17:45 |
| sean-k-mooney | and havent added support for 22.04 | 17:45 |
| sean-k-mooney | i have 0 influance over that but im surpsied they have not clsoed that gap | 17:46 |
| jrosser | i would like to belive it is not intentional | 17:47 |
| sean-k-mooney | https://launchpad.net/ubuntu/+source/ceph | 17:47 |
| sean-k-mooney | you can use the ubuntu ppa to get the downstream one | 17:47 |
| sean-k-mooney | im not sure which release 17.1.0 is https://launchpad.net/ubuntu/+source/ceph/17.1.0-0ubuntu3 | 17:48 |
| sean-k-mooney | its quincy https://docs.ceph.com/en/latest/releases/index.html | 17:49 |
| sean-k-mooney | jrosser: so if the disto package is an option for you thats a workaroudn for now i guess | 17:50 |
| jrosser | it is very nice the way they provide versioned repos at download.ceph.com | 17:51 |
| sean-k-mooney | yep i prefered using those one personally too | 17:51 |
| jrosser | "as an operator" I want to test some version and stick rigidly to it unless i decide to change it | 17:51 |
| dansmith | I surely hope that's not going away | 17:51 |
| sean-k-mooney | it looks like its still built for 20.04 | 17:52 |
| jrosser | so taking the packages from ubuntu or UCA is really unappealing to me as the pinning is much harder | 17:52 |
| sean-k-mooney | ya 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 fixed | 17:53 |
| jrosser | sean-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 |
| jrosser | becasue i was very surprised when it booted on an x86 node under emulation rather than fail | 17:55 |
| dansmith | no valid host | 17:55 |
| dansmith | did you set the arch on the image? | 17:56 |
| jrosser | incorrectly - to 'arm' | 17:56 |
| sean-k-mooney | jrosser: https://github.com/ceph/ceph/pull/49087 looks like they curerntly have som build issue due t python 3.10 | 17:56 |
| dansmith | I thought we filter hosts by arch, but maybe not | 17:56 |
| sean-k-mooney | jrosser: emulation was added recently | 17:57 |
| dansmith | ohhh, right | 17:57 |
| jrosser | from the docs i though i had to set a property to make that happen | 17:57 |
| dansmith | I thought you had to opt into that | 17:57 |
| clarkb | https://packages.ubuntu.com/jammy-updates/ceph is not UCA and shouldn't change | 17:57 |
| sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/yoga/implemented/pick-guest-arch-based-on-host-arch-in-libvirt-driver.html | 17:58 |
| jrosser | whilst i was looking at this i thought there might be a docs bug here https://docs.openstack.org/nova/latest/admin/scheduling.html#imagepropertiesfilter | 18:00 |
| dansmith | seems 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 |
| jrosser | arm vs AARCH64 ^ there | 18:00 |
| sean-k-mooney | jrosser: https://github.com/openstack/nova/blob/master/nova/objects/fields.py#L120-L171 | 18:01 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/arch.py#L16-L65 | 18:02 |
| sean-k-mooney | so you shoudl use aarch64 | 18:02 |
| sean-k-mooney | for 64bit arm | 18:02 |
| sean-k-mooney | in the image properies that is | 18:03 |
| sean-k-mooney | for the machine type i think its the same value | 18:03 |
| jrosser | it is also unclear if those are / are not the same strings defined in os-traits | 18:03 |
| jrosser | i need to investigate this more next week but what would it be that steers an hw_architecture=aarch64 | 18:05 |
| sean-k-mooney | hw_architecture=aarch64 should select a host that is aarch64 | 18:06 |
| jrosser | even 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 to | 18:06 |
| sean-k-mooney | and you defintly dont have hw_emulation_architecture set | 18:08 |
| jrosser | no - i didnt know about that until trying to find out how the vm ended up on the wrong node | 18:09 |
| sean-k-mooney | looking at the code without that set it shoudl not be using emulation | 18:10 |
| sean-k-mooney | unless you have virt_type=qemu? | 18:10 |
| jrosser | thats set to kvm | 18:11 |
| sean-k-mooney | so this lookd right https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5242-L5277 | 18:12 |
| sean-k-mooney | https://github.com/openstack/nova/blob/373be3db5b7b058767ddac50ff1367725c932a84/nova/virt/libvirt/utils.py#L509-L526 | 18:12 |
| sean-k-mooney | so do you have hw_architecture set | 18:12 |
| sean-k-mooney | i can maybe see why it activating on the comptue side | 18:14 |
| sean-k-mooney | but im not sure why its scudlign to the compute | 18:14 |
| jrosser | i think currently hw_architecture is set to 'AARCH64" | 18:15 |
| jrosser | so that could still be wrong | 18:15 |
| sean-k-mooney | no i think we dont care about the casing but not sure | 18:16 |
| sean-k-mooney | if you have that version of qemu i think it will be able to boot | 18:16 |
| sean-k-mooney | my guess is you dont have the request filter enabled? | 18:17 |
| sean-k-mooney | do you have teh transform_image_metadata prefilter enabled | 18:17 |
| sean-k-mooney | [scheduler]image_metadata_prefilter | 18:18 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#scheduler.image_metadata_prefilter | 18:18 |
| sean-k-mooney | that is what enforce the host selection | 18:18 |
| sean-k-mooney | as far as i am aware emulation is enabeld by default if you have the binary avaiable | 18:20 |
| sean-k-mooney | at least without enable the prefilter | 18:21 |
| sean-k-mooney | we should turn that prefilter on by default | 18:21 |
| jrosser | ok i will look at the prefilter | 18:21 |
| sean-k-mooney | but we dont currently | 18:21 |
| jrosser | i want it to not schdule at all to x86 when i have real arm nodes | 18:22 |
| * jrosser has to head out - thanks for the pointers | 18:22 | |
| opendevreview | Tyler Stachecki proposed openstack/nova master: nova-scheduler: Encourage weighers to spread https://review.opendev.org/c/openstack/nova/+/876289 | 22:03 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
