| sean-k-mooney[m] | fungi ack, im not sure ill have much time in the short term but i would like to expore a new image again i might look into the docker file support | 00:00 |
|---|---|---|
| sean-k-mooney[m] | fungi presumable we could host such an image in the ci infra somewhere or on tarballs.o.o | 00:01 |
| sean-k-mooney[m] | if we were to make that move | 00:01 |
| fungi | sure, ironic does (or did) that with their ipa images too | 00:01 |
| sean-k-mooney[m] | we have had times where it would have been useful to upgade specific packages like the guest kernel in the past to workaround itermitent gate issues | 00:02 |
| fungi | but if it's small enough we could just bake a copy into our test node images like we do with cirros | 00:02 |
| sean-k-mooney[m] | ya any replacment would have to be both small on disk and on ram requiremnt | 00:02 |
| sean-k-mooney[m] | but hosting it woudl be usefull for devstack | 00:03 |
| sean-k-mooney[m] | i have been leaning about and using nixos on my work laptop over the break and they have a way to make very small image for contaienr but also have generator for many other formats https://github.com/nix-community/nixos-generators | 00:06 |
| sean-k-mooney[m] | one of them is openstack | 00:06 |
| sean-k-mooney[m] | nixos is also declaritvie by design so we could specify exactly what we wanted to include | 00:07 |
| clarkb | sean-k-mooney[m]: sorry I've been distracted and the point about types is exactly what I was trying to say before | 00:19 |
| clarkb | but it seems nova assumes rsa == ssh in this case | 00:19 |
| clarkb | I don't think its crazy to have ssh_rsa and ssh_ecdsa and so on | 00:19 |
| clarkb | note a new version of dropbear isn't good enough either I don't think | 00:20 |
| clarkb | I don't think they have fixed this issue in dropbear | 00:20 |
| sean-k-mooney[m] | well the value we have rith now are ssh or x509 | 00:20 |
| sean-k-mooney[m] | technially there is no guarentee that ssh is rsa i think | 00:21 |
| sean-k-mooney[m] | ill have to check the api ref | 00:21 |
| clarkb | I think nova is hardcoded to do that though | 00:21 |
| clarkb | but ya I doubt it is written in api docs | 00:21 |
| sean-k-mooney[m] | right but its and implemention detail | 00:21 |
| sean-k-mooney[m] | not part fo the api contract | 00:21 |
| sean-k-mooney[m] | we just promice we will give you a valid ssh key we dont tell you how its generated | 00:22 |
| clarkb | I've not been very fond of nixos image generation fwiw. our matrix gerritbot image is generated with nixos and it does a bunch of silly stuff like set a unicode shell prompt. But then doesn't install a shell | 00:22 |
| clarkb | Its a super power tool and if you aren't using it for everything seems extremely clunky | 00:22 |
| sean-k-mooney[m] | ya i just lost my will to live with fedora any longer and tried it to get back some contol of my laptop | 00:23 |
| sean-k-mooney[m] | its seams to be working fine for me right now but just geting used to it | 00:24 |
| clarkb | the problem with the give me an ssh key api is that as a user I don't want an ssh key per instance. I want each instance to use my ssh key | 00:25 |
| sean-k-mooney[m] | clarkb honetst alpine or simlar would still be my perfered alternitive | 00:25 |
| clarkb | ya alpine would be a good choice too since they target embedded environments | 00:25 |
| sean-k-mooney[m] | alpine was what i prviosuly tried to get working | 00:25 |
| clarkb | but running a full openssh server on alpine etc isn't likely to be much faster than say on ubuntu | 00:25 |
| sean-k-mooney[m] | i should proably abandon does patches | 00:25 |
| clarkb | which is why I mention that dropbear isn't patched yet as far as I know | 00:25 |
| clarkb | to me using ecdsa and dropbear regardless of the image is still going to be necessary | 00:26 |
| sean-k-mooney[m] | well its not about speed right | 00:26 |
| clarkb | it definitely is | 00:26 |
| sean-k-mooney[m] | we could use ubunut if we could get it to fit the ram requiremnts | 00:26 |
| clarkb | tempest is running however many hundreds of instance boots per run | 00:26 |
| clarkb | if you make each one 5 minutes longer that isn't sustainable | 00:26 |
| sean-k-mooney[m] | ok ya speed is also imporant | 00:26 |
| sean-k-mooney[m] | but the first limit we have is must work with 64-96 mb of ram | 00:27 |
| clarkb | ok I'm wrong dropbear does do rsa-sh2 | 00:27 |
| sean-k-mooney[m] | then must have small disk footprint then must not really be any slower then cirros | 00:27 |
| clarkb | as of version 2020.79 | 00:27 |
| sean-k-mooney[m] | yep | 00:27 |
| sean-k-mooney[m] | the version in the cirros image is just too old | 00:27 |
| clarkb | I think frickler mentioned that a new cirros is in the works though | 00:27 |
| sean-k-mooney[m] | so alpine with dropbear would be nice | 00:28 |
| sean-k-mooney[m] | i mean thats also an option buy if frikler does i hope they also update the kernel to something form this decade | 00:28 |
| sean-k-mooney[m] | i think cirros is still using a ubuntu 18.04 kernel | 00:29 |
| sean-k-mooney[m] | it might be from 20.04 but its several years out of date in anycase | 00:30 |
| clarkb | I'm not super familiar with cirros build tooling but I think last I looked you get an entirely new user space when you update busybox to get a new dropbear | 00:30 |
| clarkb | and when you do that chances of needing an ew kernel are much higher too | 00:30 |
| clarkb | I would be surprised if it wasn't a comprehensive update. But also if not updating the kernel as a subsequent step is probably not terrible | 00:30 |
| clarkb | one step at a time and all that | 00:30 |
| sean-k-mooney[m] | the current one has a bug that we ocationally hit | 00:31 |
| sean-k-mooney[m] | its patched in later version of that kernel in ubuntu but not in the specific point release they have imported | 00:31 |
| sean-k-mooney[m] | ya they skip updating the kernel the last time they rebuilt for somethign we needed so hopefully they will do it this time | 00:32 |
| sean-k-mooney[m] | clarkb i just generally like the idea of using something more mainstream but on the other hand its worked well for us for a long time so i dont dislike cirros just its update cadence | 00:33 |
| clarkb | ya, but also frickler seems to be working on solving those problems so I'm happy to defer to epople doing the work :) | 00:33 |
| clarkb | the good thing about cirros is its a proven system that works while still being tiny | 00:33 |
| clarkb | whittling something else down could be significant work and as far as I know no one is doing that work (unlike with frickler and cirros) | 00:34 |
| sean-k-mooney[m] | so one option i think woudl be more viable would be to update nova ssh keygen to use ecrsa unconditioanlly | 00:34 |
| clarkb | There is a problem with that: ecdsa isn't considered secure by many beacuse it relies on magic from NIST | 00:35 |
| sean-k-mooney[m] | clarkb well alpine because of its embeded and contaienr focus is the only thing that comes close form off the shelf solutions | 00:35 |
| sean-k-mooney[m] | clarkb well that depend on the curve | 00:35 |
| clarkb | FIPS is on board with it, but you might notice there is a conflict of interest between the people making FIPS and NIST :) | 00:35 |
| sean-k-mooney[m] | no one should use the nist curve | 00:35 |
| clarkb | I don't think there is another kind that ssh-keygen emits? | 00:36 |
| clarkb | ecsda as supported by fips is the curve that nist magic'd | 00:36 |
| clarkb | (there are other eliptic curve algorithms but fips doesn't support them) | 00:37 |
| sean-k-mooney[m] | Ed25519 is not allowed? | 00:37 |
| clarkb | it is not | 00:37 |
| sean-k-mooney[m] | oh well personally im not really comfrotable with default to the nist curve so ignorem my previous suggestion | 00:38 |
| sean-k-mooney[m] | i was assuming we would only enable Ed25519 | 00:38 |
| ade_lee | ed25519 is in proposed fips standard but hasn't been accepted yet, so it wont work for fips now | 00:39 |
| fungi | not allowed by current fips standards, but slated for inclusion in the "near" future (for usa gubment definitions thereof) | 00:39 |
| fungi | yeah, what ade_lee said | 00:39 |
| sean-k-mooney[m] | ack | 00:40 |
| fungi | it may be prudent, tinfoil hat on, to assume that means the nsa has only recently figure out how to break ed25519 ;) | 00:40 |
| * fungi waves at the handlers reading all his communications | 00:41 | |
| sean-k-mooney[m] | rsa 4096 with sha2 i think is till the best generally compatible ssh key you can generate today | 00:42 |
| sean-k-mooney[m] | which i still need to do later this week actully | 00:42 |
| fungi | agreed, except for all those half-baked sshds that serve up rsa host keys with sha-1 signatures (to the case in point) | 00:42 |
| clarkb | the sha1/sha2 stuff is handled during protocol negotiation and not key generation time fwiw | 00:42 |
| clarkb | I really really wish that the clients whould just force sha2 for those sshds that can sha2 but don't advertise it | 00:43 |
| clarkb | like gerrit | 00:43 |
| sean-k-mooney[m] | yep | 00:43 |
| sean-k-mooney[m] | i tried doing that in my ssh config but could not get it to work | 00:44 |
| sean-k-mooney[m] | well forcing sha2 and enabling sha 1 but just failed | 00:44 |
| sean-k-mooney[m] | i could proably get it to work but was not worht the time | 00:44 |
| clarkb | ya I converted to ed25519 and called it a day | 00:46 |
| sean-k-mooney[m] | i was actully reading https://blog.peterruppel.de/ed25519-for-ssh/ earlier today | 00:46 |
| ade_lee | so -- for fips testing, then, it sounds like - unless we can update or change cirros - the best short term solution is allowing ecdsa - and we'd prefer to generate the key in tempest? | 00:48 |
| sean-k-mooney[m] | yes that would be my preference | 00:49 |
| ade_lee | gmann, ^^ | 00:49 |
| sean-k-mooney[m] | generating in tempest would also be useful for downstream osp 17 testing based on wallaby | 00:49 |
| sean-k-mooney[m] | ade_lee we would not backport the nova ssh key generation downstream | 00:49 |
| sean-k-mooney[m] | we never backport api changes downstream | 00:50 |
| ade_lee | ack, then the tempest change would be preferable for sure | 00:50 |
| fungi | ideally, we'd generate the ssh-rsa keys in tempest too, and nova would slap a big red "deprecated" on its server-side key generation api | 00:54 |
| sean-k-mooney[m] | gmann deprecation is not an api change right from a micorversion point of view | 00:56 |
| sean-k-mooney[m] | so we could just propos a patch to update the docs to do that ? | 00:56 |
| sean-k-mooney[m] | the removal would be an api change | 00:57 |
| sean-k-mooney[m] | so that would need a spec | 00:57 |
| sean-k-mooney[m] | honestly i would be ok with doing the deprecation and removing in a later microversion but keeping the code to support the older micro verions | 00:58 |
| sean-k-mooney[m] | you should not really use it but it cost use very little to leave the code there for backwards compatiblity | 00:59 |
| fungi | with my vmt/security wonk hat firmly affixed, i'd be fine deprecating it and never getting around to removing it. just so long as its use is discouraged | 01:37 |
| gmann | ade_lee: yeah generating in tempest and testing is always ok/more coverage irrespective of nova auto generate or not | 01:40 |
| gmann | sean-k-mooney[m]: no, we have to do with microversion. | 01:43 |
| gmann | it will be like <=2.xx microversion it will work as it is and >2.xx this will return 404, 400 or something | 01:44 |
| gmann | removing is not possible until we bump the minimum microversion | 01:44 |
| gmann | that is how we deprecate the API in nova | 01:45 |
| sean-k-mooney[m] | we have to have the microversion for the removal os generating the key yes but to deprecate it with out any other change we dont | 01:45 |
| gmann | and yes we need spec for that | 01:45 |
| sean-k-mooney[m] | e.g. just a docs update | 01:45 |
| gmann | ohk you mean just auto generation part | 01:46 |
| gmann | in that case, removal is possible yes and with microversion | 01:46 |
| sean-k-mooney[m] | and ya since we still woud have the code for < 2.x a 400 would be correct | 01:46 |
| gmann | but deprecation is again I will say need microversion for notification at least | 01:46 |
| sean-k-mooney[m] | the same endpoint is used for create and import too | 01:46 |
| sean-k-mooney[m] | so we would still support import in the new verion just not create | 01:47 |
| sean-k-mooney[m] | its a http post in both cases i belive | 01:47 |
| sean-k-mooney[m] | with differnt body for create vs import | 01:47 |
| gmann | we cannot return 400 directly without version bump as it will break users who are curently getting 200 success case and then will get 400 | 01:47 |
| gmann | it is behavior change not just about return code | 01:48 |
| sean-k-mooney[m] | yep im not suggesting returnnign a 400 without a new microversion | 01:48 |
| gmann | so we can directly remove the auto generation of key in microversion and keep supporting for old microversion | 01:48 |
| sean-k-mooney[m] | yep | 01:48 |
| gmann | no need for deprecation | 01:48 |
| sean-k-mooney[m] | i spoke of deprecation becasue i dont know if we will get arount to it this cycle | 01:49 |
| sean-k-mooney[m] | so more a reminder to us and warning to users that we might remove it next cycle | 01:49 |
| sean-k-mooney[m] | but we could also just add it to your api cleanup etherpad | 01:50 |
| gmann | sure, putting something in api-ref like 'this is not recommended to use' and later with microversion can amend that with 'not supported >2.xx' | 01:50 |
| gmann | +1 | 01:50 |
| sean-k-mooney[m] | ok i really should try and go to sleep so ill chat to ye tomorrow o/ | 01:51 |
| gmann | sean-k-mooney[m]: done. | 01:52 |
| gmann | sean-k-mooney[m]: yeah, me too. GN | 01:52 |
| opendevreview | Merged openstack/nova stable/victoria: Ensure MAC addresses characters are in the same case https://review.opendev.org/c/openstack/nova/+/816927 | 01:53 |
| EugenMayer | Hello, experimenting with the "lock" feature. It seems that lock does not protect against deletion, against what does it protect then? Is there anything like a protected flag in openstack which protects particular instances form deletion? | 07:00 |
| EugenMayer | Ah i see https://platform9.com/kb/openstack/can-i-lock-preserve-instance-from-deletion - admins can always delete. So i need somewhat of a different user, interesting | 07:01 |
| *** hemna9 is now known as hemna | 07:38 | |
| lyarwood | EugenMayer: yeah see https://docs.openstack.org/api-ref/compute/?expanded=lock-server-lock-action-detail#lock-server-lock-action for more details | 09:11 |
| lyarwood | and https://docs.openstack.org/api-guide/compute/server_concepts.html#server-actions | 09:11 |
| sean-k-mooney | EugenMayer: the primay uage of lock is to prevent normal users starting or stoping a vm | 09:21 |
| sean-k-mooney | admins can always bypass it as you have found | 09:21 |
| opendevreview | Ilya Popov proposed openstack/nova master: Fix to implement 'pack' or 'spread' VM's NUMA cells https://review.opendev.org/c/openstack/nova/+/805649 | 11:12 |
| opendevreview | Merged openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/813180 | 12:25 |
| *** hemna1 is now known as hemna | 12:30 | |
| opendevreview | Merged openstack/os-traits master: Updating python testing classifier as per Yoga testing runtime https://review.opendev.org/c/openstack/os-traits/+/819205 | 13:28 |
| *** whoami-rajat__ is now known as whoami-rajat | 13:36 | |
| opendevreview | Jonathan Race proposed openstack/os-traits master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/os-traits/+/824050 | 14:13 |
| opendevreview | Jonathan Race proposed openstack/nova master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/nova/+/822053 | 14:20 |
| opendevreview | yuval proposed openstack/nova-specs master: lightos volume driver spec https://review.opendev.org/c/openstack/nova-specs/+/824191 | 14:36 |
| opendevreview | Jonathan Race proposed openstack/os-traits master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/os-traits/+/824050 | 14:40 |
| opendevreview | Jonathan Race proposed openstack/nova master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/nova/+/822053 | 14:40 |
| *** xek_ is now known as xek | 15:04 | |
| bauzas | reminder: nova meeting starts in 45 mins here at #openstack-nova | 15:14 |
| gibi | melwitt: Hi! Happy New Year! if you have time, could you look at this placement spec please https://review.opendev.org/q/topic:any-traits-support ? | 15:18 |
| sean-k-mooney | gibi i tought that was approved? | 15:20 |
| sean-k-mooney | oh its not ok | 15:20 |
| sean-k-mooney | then yes it woudl be useful for the emulation feature too | 15:21 |
| sean-k-mooney | so we can say give me a host with HW_ARCH_X86_64 or COMPUTE_ARCH_X86_64 | 15:22 |
| * bauzas disappears now but is back around 16:50 hopefully | 15:22 | |
| bauzas | gibi: I need to get my car back, in case I'm not there on time, could you start the meeting ? | 15:23 |
| bauzas | gibi: I wrote the agenda | 15:23 |
| gibi | bauzas: sure | 15:28 |
| gibi | no worries | 15:28 |
| gibi | sean-k-mooney: yeah I saw the discussion around the emulation and I agree that needs OR relationship for traits | 15:29 |
| yuval | Hey, the nova meeting, on which channel is it? | 15:39 |
| gibi | yuval: it will be here in this channel from the top of the hour | 15:41 |
| yuval | ok thanks | 15:41 |
| gibi | gmann: if you have time could you look at the qos tempest tests https://review.opendev.org/c/openstack/tempest/+/806257 ? | 15:51 |
| gmann | gibi: sure, I started it yesterday but could not finish. let me review today | 15:55 |
| gibi | gmann: thanks a lot! | 15:55 |
| bauzas | I'm here | 15:58 |
| bauzas | nova meeting starting in 1 min | 15:59 |
| Uggla | \o/ | 15:59 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Jan 11 16:00:00 2022 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| gibi | \o | 16:00 |
| bauzas | hey ho everybody | 16:00 |
| elodilles | o/ | 16:00 |
| bauzas | gibi: elodilles: welcome back \o/ | 16:00 |
| elodilles | \o/ | 16:00 |
| bauzas | hope you both have good vacations | 16:00 |
| bauzas | had* | 16:00 |
| chateaulav | \o | 16:00 |
| gmann | o/ | 16:01 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:01 |
| bauzas | I guess we can start, people will join meanwhile | 16:02 |
| bauzas | #topic Bugs (stuck/critical) | 16:02 |
| bauzas | #info No Critical bug | 16:02 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 36 new untriaged bugs (+3 since the last meeting) | 16:02 |
| bauzas | #help Nova bug triage help is appreciated https://wiki.openstack.org/wiki/Nova/BugTriage | 16:02 |
| bauzas | #link https://storyboard.openstack.org/#!/project/openstack/placement 25 open stories (+0 since the last meeting) in Storyboard for Placement | 16:02 |
| bauzas | I need to do homework | 16:02 |
| bauzas | any bug to discuss in particular? | 16:03 |
| bauzas | looks not | 16:03 |
| bauzas | #topic Gate status | 16:04 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:04 |
| bauzas | no new gate failure | 16:04 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status | 16:04 |
| bauzas | no placement periodic job issue | 16:04 |
| bauzas | #info Please look at the gate failures, file a bug, and add an elastic-recheck signature in the opendev/elastic-recheck repo (example: https://review.opendev.org/#/c/759967) | 16:04 |
| bauzas | nothing to say about the gate jobs ? | 16:04 |
| gibi | I have no experience yet on how good our CI this year :) | 16:05 |
| bauzas | gibi: I haven't seen it too | 16:06 |
| bauzas | anyway | 16:06 |
| bauzas | #topic Release Planning | 16:06 |
| bauzas | #info Yoga-2 was Jan 6th | 16:06 |
| bauzas | #link https://releases.openstack.org/yoga/schedule.html#y-2 | 16:06 |
| bauzas | #info FeatureApprovalFreeze is punted to Jan 13st, 2 days left. | 16:06 |
| bauzas | that means we need to review some spec changes :) | 16:07 |
| yuval | I have added a spec today for review | 16:07 |
| bauzas | I have seen it | 16:08 |
| chateaulav | and there is the one i added yesterday. fixing items from sean's review | 16:08 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/824191 and https://review.opendev.org/c/openstack/nova-specs/+/824044 | 16:08 |
| sean-k-mooney | yuval: your spec is very very light on details. | 16:09 |
| bauzas | https://review.opendev.org/q/project:openstack/nova-specs+is:open+directory:specs/yoga | 16:09 |
| yuval | sean: yes, I just saw your comment | 16:09 |
| bauzas | I'll review them tomorrow | 16:10 |
| yuval | there is not much in the nova driver most of the logic is in the cinder side and os-brick | 16:10 |
| bauzas | also, if people want to have specless bps approved, today is the last meeting for verifying them | 16:11 |
| bauzas | if so, please add your blueprint in the open discussion topic | 16:11 |
| bauzas | #info fwiw, we have 16 accepted blueprints at the moment https://blueprints.launchpad.net/nova/yoga | 16:11 |
| bauzas | so, I guess we should be around 18-20 for yoga, which is like xena | 16:12 |
| bauzas | I have a question | 16:13 |
| bauzas | #info any releases wanted for clients or libs ? | 16:13 |
| bauzas | we're around the midcycle for yoga | 16:13 |
| bauzas | tbh, I haven't looked at what we merged for all repos, but I can do | 16:14 |
| ade_lee | gmann, so based on discussion last night, you good with the generation of the ecdsa key in tempest? | 16:15 |
| bauzas | ade_lee: we're in a meeting | 16:16 |
| bauzas | please wait for the end of it | 16:16 |
| gmann | ade_lee: let's discuss after meeting or in qa channel | 16:16 |
| ade_lee | bauzas, sorry | 16:16 |
| bauzas | anyway, moving to the next topic, looks like nobody wants a release for now | 16:16 |
| bauzas | and I'll look at the os-vif and os-brick repos to see whether we need some releases | 16:17 |
| bauzas | #topic Review priorities | 16:17 |
| gibi | the release team will propose the release pathes if they need a release from us :) | 16:17 |
| sean-k-mooney | we have a few patches under review for os-trait | 16:17 |
| bauzas | #undo | 16:17 |
| opendevmeet | Removing item from minutes: #topic Review priorities | 16:17 |
| bauzas | sean-k-mooney: that's what I want to verify | 16:17 |
| sean-k-mooney | we might want to do an os-trait release in week or two once those land | 16:18 |
| bauzas | we're around yoga-2 which means it's time for us to provide new lib releases if needed | 16:18 |
| bauzas | so new features could use them | 16:18 |
| sean-k-mooney | we use release with intermidary we dont have to wait for or only release at milestones | 16:18 |
| bauzas | if this is around yoga-3 and featurefreeze, I don't see how it could help | 16:18 |
| bauzas | sean-k-mooney: yeah, my point is not about milestones | 16:18 |
| sean-k-mooney | so we can do it when it make the most sense for us to consume them | 16:19 |
| sean-k-mooney | ack | 16:19 |
| elodilles | the release patches were generated for yoga-2 already, so i guess there were no content from nova | 16:19 |
| bauzas | it's more about saying "meh, we're like 6 weeks from feature freeze, maybe it's time to release some libs" | 16:19 |
| bauzas | elodilles: I haven't got a release change for yoga-2 | 16:20 |
| bauzas | (for nova I mean) | 16:20 |
| bauzas | but this is fine, we no longer do them | 16:20 |
| elodilles | sorry, s/nova/libs | 16:20 |
| bauzas | elodilles: oh ok | 16:21 |
| bauzas | anyway, moving on | 16:21 |
| bauzas | #topic Review priorities | 16:21 |
| bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+label:Review-Priority%252B1 | 16:21 |
| bauzas | nothing to tell here | 16:21 |
| bauzas | we said last week that the three late changes should be reviewed | 16:22 |
| bauzas | any review priority to discuss in particular ? | 16:23 |
| bauzas | do people want to have a priority ? | 16:23 |
| bauzas | looks not | 16:24 |
| yuval | Hey, we really try to reach the deadline | 16:24 |
| bauzas | yuval: there are two deadlines tbc | 16:24 |
| yuval | if we can have priority in review that will be great | 16:25 |
| bauzas | first is in 2 days, which is spec approval | 16:25 |
| yuval | yes | 16:25 |
| bauzas | the second is in 6.2 weeks which is feature freeze | 16:25 |
| yuval | then the code need to be merged | 16:25 |
| bauzas | there is no rush about merging features but for your spec, agreed, we'll try to review it before the spec freeze | 16:25 |
| yuval | Thank you | 16:26 |
| bauzas | yuval: correct, code for feature delivery has to be merged before yoga-3 | 16:26 |
| sean-k-mooney | yuval: do you have an approved cinder spec yet | 16:26 |
| sean-k-mooney | the nova work depens on the cinder driver being merged before we can proceed | 16:27 |
| sean-k-mooney | you might have missed there deadline for cinder devers this cycle | 16:27 |
| sean-k-mooney | https://releases.openstack.org/yoga/schedule.html#y-cinder-driver-deadline | 16:28 |
| sean-k-mooney | jan 17th | 16:28 |
| sean-k-mooney | and os brick freature freeze is feb 10th | 16:29 |
| yuval | yesterday brain approved the blueprints | 16:29 |
| yuval | there was not request for spec so I havent created one | 16:30 |
| yuval | but I can talk to him to verfiy if it needed | 16:30 |
| sean-k-mooney | ok if they are ok with a specless blueprint for a driver that is fine | 16:30 |
| bauzas | hum | 16:30 |
| bauzas | I'd then appreciate if some cinder cores could review this nova spec too | 16:30 |
| sean-k-mooney | but the timing is quite tight | 16:30 |
| bauzas | yuval: do you think you could ask them to look at your nova spec ? | 16:31 |
| bauzas | I'm a bit concerned by being realistic | 16:31 |
| yuval | I can try, I will answer sean comments, update and talk to them | 16:31 |
| sean-k-mooney | ack | 16:31 |
| bauzas | if some cores can sponsor this, this would raise my confidence into the blueprint being able to be merged in time | 16:32 |
| sean-k-mooney | one of ther requirements is a third party ci in place before merging th edriver code | 16:32 |
| bauzas | and this is a huge commitment | 16:32 |
| yuval | we have thrid party ci running on cinder | 16:32 |
| sean-k-mooney | cool | 16:32 |
| yuval | and I will have it running on nova today also | 16:32 |
| bauzas | oh this would be nice | 16:32 |
| yuval | can you specify the regex for the tempest run? | 16:33 |
| bauzas | that kind of things raise my level of confidence easily :) | 16:33 |
| bauzas | yuval: yeah you can | 16:33 |
| bauzas | https://docs.openstack.org/tempest/latest/run.html | 16:33 |
| bauzas | but I guess we can discuss this off-meeting | 16:34 |
| bauzas | moving on | 16:34 |
| bauzas | #link https://review.opendev.org/c/openstack/nova/+/816861 bauzas proposing a documentation change for helping contributors to ask for reviews, needs more cores to vote | 16:34 |
| bauzas | just sayin' | 16:35 |
| bauzas | anyway, next topic | 16:36 |
| bauzas | #topic Stable Branches | 16:36 |
| bauzas | elodilles: anything in particular to mention ? | 16:36 |
| elodilles | well, i haven't updated the stable status | 16:36 |
| elodilles | but actually it is still valid if i'm not mistaken | 16:36 |
| elodilles | stable gates are not blocked | 16:36 |
| elodilles | but recheckes are needed mostly before patches merge | 16:37 |
| elodilles | so nothing special i would say | 16:37 |
| elodilles | that's it | 16:37 |
| bauzas | elodilles: yeah I left this status :D | 16:37 |
| bauzas | intentionally I mean | 16:38 |
| elodilles | bauzas: thanks :) | 16:38 |
| elodilles | it came handy o:) | 16:38 |
| bauzas | ok, looks it's a nobrainer | 16:38 |
| bauzas | #topic Sub/related team Highlights | 16:38 |
| bauzas | #info No subteam left | 16:38 |
| bauzas | we demoted the libvirt one | 16:38 |
| gibi | :) | 16:38 |
| bauzas | just in case some people are wondering about the process, this is simple | 16:39 |
| bauzas | https://wiki.openstack.org/wiki/Nova#Nova_subteams | 16:39 |
| bauzas | the tl;dr is "Sub-teams don't need permission. They can be around for short or long periods of time. " | 16:39 |
| bauzas | so, I'll leave this topic as a placeholder | 16:40 |
| bauzas | but if I don't see needs, I'll skip it | 16:40 |
| bauzas | just keep in mind subteams exist and are a good way forward to communicate and raise trustfulness and confidence | 16:40 |
| bauzas | last item before we close | 16:41 |
| bauzas | #topic Open discussion | 16:41 |
| bauzas | I have no item in the agenda | 16:41 |
| yuval | can I introduce myself? | 16:42 |
| bauzas | last reminder, today is the last meeting for approving specless blueprints | 16:42 |
| bauzas | yuval: sure, any introduction is appreciated | 16:42 |
| yuval | my name is yuval brave, from lightbits labs | 16:42 |
| yuval | lightbits is working on a storage cluster solution | 16:43 |
| yuval | working with nvme over tcp | 16:43 |
| yuval | we have been working with openstack for few years now | 16:43 |
| yuval | and support rockey, queens, stein, train and xena | 16:43 |
| yuval | and questions? | 16:44 |
| bauzas | yuval: I guess you'll get plenty of them once we review your spec :D | 16:44 |
| sean-k-mooney | :) | 16:44 |
| yuval | :) | 16:44 |
| gibi | :) | 16:44 |
| bauzas | anyway, welcome | 16:45 |
| bauzas | we don't bite | 16:45 |
| yuval | thats it, good "meet" you all | 16:45 |
| chateaulav | im Jonathan Race, from the Georgia Cyber Center. We support security and medical device research. currently working with providing emulation support. | 16:45 |
| bauzas | welcome chateaulav too | 16:46 |
| chateaulav | we use our our framework for deployment and orchestration of openstack, so I be around here and there | 16:46 |
| * bauzas wonders the nick but that's absolutely not the right timing and place to do such thing | 16:46 | |
| bauzas | cool | 16:46 |
| * artom just wants to make more "Race condition" puns | 16:46 | |
| bauzas | artom: man, have you just pop up at the end of the meeting literally just for a oneliner which is a pun ? | 16:47 |
| gibi | :) | 16:47 |
| yuval | lol | 16:47 |
| artom | Hey, I was here all along | 16:48 |
| gibi | bauzas: would have been better if artom starts the meeting with that? | 16:48 |
| bauzas | artom: speak more then :D | 16:48 |
| artom | Only if I have something to say :P | 16:48 |
| sean-k-mooney | i think we can proably wrap up the meeting at this point | 16:48 |
| bauzas | absolutely | 16:48 |
| bauzas | that being said, | 16:48 |
| bauzas | #endmeeting | 16:48 |
| opendevmeet | Meeting ended Tue Jan 11 16:48:56 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:48 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-01-11-16.00.html | 16:48 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-01-11-16.00.txt | 16:48 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-01-11-16.00.log.html | 16:48 |
| bauzas | probably the weirdest ending I made | 16:49 |
| bauzas | but it's all artom's fault | 16:49 |
| artom | I am *not* touching that | 16:49 |
| yuval | :)) its funny here | 16:50 |
| gibi | so if there is good vibes the all can start thinking and proposing names for the Z release https://wiki.openstack.org/wiki/Release_Naming/Z_Proposals | 16:50 |
| gmann | +1, please do | 16:50 |
| artom | Would "zizi" fly? bauzas and my 5 year old son would find it *hillarious* | 16:51 |
| bauzas | gibi: I assume Zombie was proposed 1000 times ? | 16:51 |
| gibi | bauzas: actulay not on the list | 16:51 |
| gibi | bauzas: so go ahead | 16:51 |
| yuval | zoro is classic | 16:51 |
| bauzas | artom: man, you're gross | 16:51 |
| artom | bauzas, correction, I am 5 years old in my head | 16:52 |
| bauzas | artom: you're on the verge of a big thing | 16:52 |
| artom | Ouch | 16:52 |
| gmann | bauzas: that is good candidate, feel free to add in wiki | 16:53 |
| gibi | wondering what zizi means for you | 16:53 |
| bauzas | gmann: I'll propose and hide | 16:53 |
| bauzas | probably the last thing I'm able to support | 16:53 |
| gmann | :) | 16:53 |
| gmann | ade_lee: on ecdsa, from tempest side yes we can generate the key in test case. what I commented in https://review.opendev.org/c/openstack/tempest/+/807465 | 16:55 |
| sean-k-mooney | the cynical side of me likes Zenith since it would be all down hill form there | 16:56 |
| * artom is surprised no one proposed Zulu | 16:56 | |
| artom | Well, until I did just now | 16:56 |
| sean-k-mooney | and zion obviously because the matix | 16:56 |
| bauzas | gibi: it's a childish word about male attributes | 16:57 |
| sean-k-mooney | bauzas: its also a first name | 16:57 |
| gibi | bauzas: aah, here it is a type of sweet rice | 16:57 |
| bauzas | gibi: you can't imagine how many times children laughed at the rock band ZZ Top here | 16:58 |
| gibi | :D | 16:58 |
| * bauzas is glad we stopped the meeting but remembers that the chan is logged | 16:59 | |
| sean-k-mooney | https://www.youtube.com/watch?v=Ae829mFAGGE i think thats the only zz top song i know | 17:00 |
| artom | bauzas, hah, almost makes we want to propose ZZ, and facetiously say it's in honour of the band | 17:00 |
| sean-k-mooney | oh and sharp dressed man too https://www.youtube.com/watch?v=7wRHBLwpASw | 17:01 |
| artom | So then all the francophones would snigger when we say "on a sorti ZZ" | 17:01 |
| artom | "ZZ a un bug" | 17:01 |
| artom | And so on | 17:01 |
| artom | "J'arrive pas a deployer ZZ" | 17:01 |
| * artom stops | 17:01 | |
| bauzas | artom: yeah, like my Yoga has a problem | 17:01 |
| * bauzas is glad we chose Ussuri over Uranus | 17:02 | |
| gibi | nah Uranus would be understood universally at least | 17:02 |
| chateaulav | that really would have put things in the dump | 17:02 |
| artom | chateaulav, top kek, you're fitting right in :D | 17:02 |
| bauzas | gibi: I don't know how Uranus is known, but I prefer to keep it secret | 17:03 |
| sean-k-mooney | ok im going to take a break for a while o/ | 17:03 |
| * gibi ends his day too | 17:05 | |
| gibi | o/ | 17:05 |
| bauzas | artom: you swamped both my proposal and another https://wiki.openstack.org/w/index.php?title=Release_Naming/Z_Proposals&diff=next&oldid=180329 | 17:06 |
| bauzas | booo | 17:06 |
| artom | bauzas, ah crap, sorry | 17:07 |
| artom | I thought I refreshed to avoid the conflict | 17:07 |
| bauzas | artom: I'm writing them back | 17:07 |
| artom | Apologies | 17:08 |
| bauzas | done | 17:08 |
| bauzas | artom: heh, no worries | 17:08 |
| opendevreview | Merged openstack/nova master: Make the CellDatabases fixture work with fasteners >= 0.15 https://review.opendev.org/c/openstack/nova/+/813114 | 17:19 |
| spatel | sean-k-mooney Hi and happy new year | 17:30 |
| spatel | I am getting stranger error in nova-scheduler logs - numatopologyfilter returned 0 hosts | 17:30 |
| spatel | Question can i check resource provider inventory of host to see why my numa not getting filter? | 17:31 |
| spatel | all i can see this but how do i check my NUMA related resources in placement? - https://paste.opendev.org/show/812039/ | 17:33 |
| opendevreview | Merged openstack/nova master: Fill the exception msg https://review.opendev.org/c/openstack/nova/+/821385 | 17:34 |
| bauzas | spatel: there are no NUMA resources in placement | 17:37 |
| spatel | hmm | 17:37 |
| bauzas | if the filter returns 0 hosts, then look at it | 17:37 |
| bauzas | add a DEBUG if you can | 17:37 |
| bauzas | for the nova-scheduler service log level | 17:38 |
| spatel | ok so there is no way to see my host NUMA inventory in DB. anyway if that is the case then only option i have which is debug | 17:38 |
| spatel | I was reading this - https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/numa-topology-with-rps.html | 17:39 |
| spatel | https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/numa-topology-with-rps.html#optionally-configured-numa-resources | 17:40 |
| bauzas | spatel: yeah but as you can see, the spec was only approved, not implemented | 17:40 |
| spatel | +1 copy that | 17:41 |
| spatel | Thank you so much! let me play with debug and see | 17:41 |
| bauzas | spatel: ack, I'll leave by now | 17:45 |
| ade_lee | gmann, sorry - just to confirm -- as we're not going to add ecdsa key generation to nova api, we can leave the key generation code in create_keypair() in https://review.opendev.org/c/openstack/tempest/+/807465/23/tempest/lib/services/compute/keypairs_client.py#84 for ecdsa , right? | 18:04 |
| ade_lee | gmann, so that basically the only changes needed in that patch is adding more detail to the release note | 18:07 |
| gmann | ade_lee: for nova api, yes we do not need to add and we will remove the existing ssh key generation part too with microversion. | 18:13 |
| gmann | ade_lee: for tempest, let me re-review it now. I think it make sense to me now to add in create_keypair() so that complete set of test can be tested with configured key. I will leave comment in review today | 18:15 |
| ade_lee | gmann, great thanks | 18:15 |
| gmann | ade_lee: I will be able to review in my evening, need to prepare lunch now :) | 18:16 |
| ade_lee | gmann, ok - enjoy -- I have to do the same .. | 18:17 |
| yuval | Hey regarding running third party ci on the nova repo | 18:27 |
| yuval | which tempest test should I run? | 18:27 |
| gmann | yuval: you can run compute integrated test which is what we run in upstream ci (or less depends on what you want to test). this file is used to prepare the integrated compute tests https://github.com/openstack/tempest/blob/master/tools/tempest-integrated-gate-compute-exclude-list.txt | 18:30 |
| gmann | this file exclude all other tests and in tempest run you can pass this file with --exclude-list , example: https://github.com/openstack/tempest/blob/master/tox.ini#L161 | 18:31 |
| yuval | I see thank you | 18:34 |
| opendevreview | Jonathan Race proposed openstack/nova-specs master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/nova-specs/+/824044 | 18:47 |
| chateaulav | sean-k-mooney: I think that covers what was identified. | 19:04 |
| opendevreview | Jonathan Race proposed openstack/os-traits master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/os-traits/+/824050 | 19:11 |
| opendevreview | Jonathan Race proposed openstack/nova master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/nova/+/822053 | 19:15 |
| opendevreview | Jonathan Race proposed openstack/os-traits master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/os-traits/+/824050 | 19:16 |
| opendevreview | Merged openstack/placement master: Spec: support any trait in allocation candidates https://review.opendev.org/c/openstack/placement/+/649992 | 21:02 |
| opendevreview | Merged openstack/placement master: Spec: support mixing required traits with any traits https://review.opendev.org/c/openstack/placement/+/649368 | 21:05 |
| opendevreview | yuval proposed openstack/nova master: NO MERGE - activate lightbits third party ci on nova repo https://review.opendev.org/c/openstack/nova/+/824255 | 22:47 |
| *** dasm is now known as dasm|off | 22:52 | |
| yuval | if someone is still awake - I have enabled the third party ci | 23:02 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!