| *** akekane_ is now known as abhishekk | 06:56 | |
| *** hemna8 is now known as hemna | 07:37 | |
| opendevreview | Lior Friedman proposed openstack/nova master: support use_multipath for nvme driver https://review.opendev.org/c/openstack/nova/+/823941 | 08:24 |
|---|---|---|
| opendevreview | Tobias Urdin proposed openstack/nova master: libvirt: Add announce-self post live-migration workaround https://review.opendev.org/c/openstack/nova/+/741529 | 08:40 |
| opendevreview | Tobias Urdin proposed openstack/nova master: libvirt: Add announce-self post live-migration workaround https://review.opendev.org/c/openstack/nova/+/741529 | 08:41 |
| bauzas | good morning Nova | 08:57 |
| *** gibi_pto_back_on_10th is now known as gibi | 08:59 | |
| gibi | good morning | 08:59 |
| gibi | I'm back | 08:59 |
| gibi | please be gentle with me as I still needs to catch up | 09:00 |
| bauzas | gibi: well, I'd say I'm all way meetings this week again :) | 10:22 |
| * bauzas winks at Uggla ;) | 10:23 | |
| bauzas | gibi: so I won't harass you *by now* | 10:23 |
| gibi | bauzas: all way meetings sounds bad | 10:26 |
| gibi | bauzas: do I need to ask for a spec freeze exception for https://review.opendev.org/q/topic:%22any-traits-support%22 ? | 10:27 |
| gibi | OK, I saw the mail that the freez is moved to this week | 11:18 |
| gibi | lyarwood: hi! do you have time to heck https://review.opendev.org/q/topic:any-traits-support spec before the spec freeze? (I'm hunting for a second core for it) | 11:20 |
| gibi | *check | 11:20 |
| lyarwood | gibi: ack queued | 11:20 |
| gibi | thanks | 11:21 |
| opendevreview | Merged openstack/placement master: Add yoga spec directory https://review.opendev.org/c/openstack/placement/+/819660 | 12:02 |
| gibi | stephenfin: I've replied in https://review.opendev.org/c/openstack/oslo.messaging/+/819142/comment/b5b812b5_8091e77f/ but I'm not about your second comment | 13:57 |
| gibi | * not sure | 14:00 |
| opendevreview | Alexey Stupnikov proposed openstack/nova master: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/776250 | 14:36 |
| sean-k-mooney | dansmith: so ya looking at the code its defintly an unintended consequence | 18:01 |
| dansmith | yup | 18:01 |
| sean-k-mooney | dansmith: i tought we were only checking for up sevice but its any service record | 18:02 |
| sean-k-mooney | which results in the catch 22 of you cant start the conductor to be able to udpate the computes in the db | 18:02 |
| sean-k-mooney | well unless service.get_minimum_version_all_cells is ignoreing down computes but i dont think it is | 18:04 |
| sean-k-mooney | actully | 18:06 |
| sean-k-mooney | https://github.com/openstack/nova/blob/4a359d576ddbc4b104116515c7e8b4176ac511f7/nova/db/main/api.py#L403-L412 | 18:06 |
| sean-k-mooney | its not chekc up or down but is checking forced down | 18:06 |
| sean-k-mooney | so the workaorund would have been to force them down before the upgrade | 18:07 |
| sean-k-mooney | and the fix would be to allow filtering based on current state | 18:08 |
| sean-k-mooney | or somethign like that | 18:08 |
| dansmith | yeah, makes sense | 18:11 |
| dansmith | also, | 18:11 |
| dansmith | if you have one compute that was never upgraded and you forgot about (has been off for a year) you wouldn't want to hold up the upgrade until you find it | 18:12 |
| 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:19 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: libvirt: remove default cputune shares value https://review.opendev.org/c/openstack/nova/+/824048 | 18: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 | 19:10 |
| *** artom__ is now known as artom | 19:25 | |
| artom | So if Jonathan Race writes an `if` block, is that a race condition? :D | 19:26 |
| chateaulav | -lol, its a fast one for sure | 19:27 |
| kashyap | chateaulav: Hey, I saw your email, but glad you're already here chatting. (I'm just back and catching up with things) | 19:30 |
| opendevreview | Kashyap Chamarthy proposed openstack/nova-specs master: Repropose "CPU selection with guest hypervisor consideration" https://review.opendev.org/c/openstack/nova-specs/+/824053 | 19:35 |
| kashyap | artom: In case you have a bit of time, mind you mind looking at chateaulav (Jonathan Race's) spec/blueprint? He has already been on it before I went on PTO | 19:36 |
| artom | kashyap, wait, can you clarify? That spec is jut for the automatic re-approval paperwork, right? | 19:38 |
| kashyap | artom: Mine, yes | 19:38 |
| kashyap | artom: I was referring to chateaulav's spec - https://review.opendev.org/c/openstack/nova-specs/+/824044 | 19:38 |
| kashyap | "Adds Pick guest CPU architecture based on host arch in libvirt driver support" | 19:38 |
| artom | Ah, sorry, got confused by the "CPU" in both | 19:38 |
| artom | Ack, I can take a look | 19:39 |
| kashyap | chateaulav notes he's got a preview version of the code. | 19:39 |
| kashyap | chateaulav: Also, I must add, upstream has been severely starved of reviewer attention, so don't be dissuaded if you don't see "quick responses". A ping here can help. | 19:40 |
| kashyap | artom: Yeah, not your fault; a quick look at the title can be deceiving :) | 19:40 |
| chateaulav | no worries, i understand. :) | 19:40 |
| * kashyap --> heads out | 19:41 | |
| sean-k-mooney | kashyap: did you reporpose that based on the xena version | 19:46 |
| sean-k-mooney | dansmith: i havent read your review comments on the health check speck but ill try and rework it tommorw with the other feedback | 19:52 |
| dansmith | sean-k-mooney: cool, looks very comprehensive :) | 19:52 |
| sean-k-mooney | am i was considering punting warn out of the inital scope | 19:54 |
| sean-k-mooney | do you think we shoudl try and keep it intiall or just start with pass/fail | 19:54 |
| dansmith | I think pass/fail for first go seems fine.. we can keep it in the spec as a valid result, but just implement everything as pass/fail initially I think | 19:55 |
| sean-k-mooney | ack. i was conidering moving it to the alternitives section but that works too | 19:55 |
| dansmith | if we're going to have it, it's not really an alternative, so I'd just leave the door open but say initially we'll just target pass/fail for the actual implementaiton | 19:56 |
| sean-k-mooney | ack | 19:56 |
| sean-k-mooney | and yes i speelchecked v2 with gramerly but then i made a lot of changes i will corret that in v4 | 19:57 |
| dansmith | I figured.. seemed like a whole section was affected :D | 19:57 |
| sean-k-mooney | oh i like the idea of makeing devstack use this to see if the service is started | 19:59 |
| dansmith | yeah, dogfood is yummy :) | 19:59 |
| sean-k-mooney | your right we currently hit the service endpoitn and check if its up | 19:59 |
| dansmith | yeah | 19:59 |
| sean-k-mooney | ok its just 8 hear so ill call it a day. hope you enjoyed your PTO talk to you tommorow | 20:00 |
| sean-k-mooney | o/ | 20:00 |
| dansmith | o/ | 20:01 |
| opendevreview | Ade Lee proposed openstack/nova master: Add ecdsa key generation https://review.opendev.org/c/openstack/nova/+/824062 | 21:19 |
| ade_lee | sean-k-mooney, fungi , gmann https://review.opendev.org/c/openstack/nova/+/824062 | 21:20 |
| ade_lee | sean-k-mooney, fungi gmann please take a look and comment. I'm not sure yet if all the tests will pass - but I want to make sure you all agree with the approach before I add more to it. | 21:21 |
| ade_lee | and let me know what else needs to be added | 21:21 |
| fungi | sure | 21:22 |
| ade_lee | thanks! | 21:22 |
| clarkb | my only though is the existing type seems to distinguish the encoding ssh vs x509 not the actual key algorithm. Might want to do ssh_ecdsa instead to keep that axis? | 21:29 |
| ade_lee | clarkb, sure I can do that - thats easy enough | 21:30 |
| ade_lee | clarkb, please add that comment to the review so others can comment on it | 21:30 |
| clarkb | can do | 21:31 |
| ade_lee | thanks | 21:31 |
| clarkb | and ya I'd wait for someone that knows nova better to weigh in on what I say before implementing it | 21:31 |
| fungi | oh, i assumed that was for ssh's x509 auth | 21:32 |
| clarkb | it may be, though I'm not sure how nova would configure the VM to enable that? it would have to add the CA to stuff right? | 21:34 |
| clarkb | in any case ssh vs x509 vs ecdsa is a bit confusing to me | 21:34 |
| clarkb | as they don't seem to align | 21:34 |
| fungi | yeah, agreed | 21:35 |
| opendevreview | Merged openstack/nova stable/xena: [rt] Apply migration context for incoming migrations https://review.opendev.org/c/openstack/nova/+/820553 | 22:13 |
| ade_lee | fungi, you haven't heard anything from canonical re: fips yet , have you? | 22:24 |
| ade_lee | clarkb, ^^ | 22:25 |
| ade_lee | if not, I'll re-ping | 22:25 |
| clarkb | I haven't seen anything | 22:26 |
| clarkb | there was an initial response and then fungi jumped in with more info iirc | 22:26 |
| ade_lee | clarkb, ack thats the last I saw too -- I'll re-ping them | 22:27 |
| fungi | ade_lee: clarkb: while i'm trying not to be pessimistic, we're really no good at running things which are locked up by commercial registration (cf a decade of failing to find a legal solution to testing on rhel) | 22:58 |
| fungi | the easiest solution to it, from our perspective, is if ubuntu made their fips compliance solutions free for everyone | 22:59 |
| clarkb | ya I suspect the easiset thing is for specific jobs to have access to a secret thta they use the enroll | 22:59 |
| fungi | but that's a business decision involving the parts of canonical we rarely have the pleasure of interacting with | 22:59 |
| clarkb | and then run that post merge or something | 22:59 |
| clarkb | assuming their license system is ok with changing IPs and maybe even duplicate IPs over time | 23:00 |
| gmann | ade_lee: ack, will check | 23:21 |
| sean-k-mooney[m] | ade_lee you willl need a spec to change the api to allow ssh key gen with the ec algorithim | 23:37 |
| sean-k-mooney[m] | nova currently allows you to import ecdsa keys | 23:37 |
| sean-k-mooney[m] | but it cant generate them | 23:38 |
| sean-k-mooney[m] | ade_lee if you want to start using them in tempest you should not relay on nova generating them | 23:39 |
| sean-k-mooney[m] | at least not if you want to do it this cycle given spec freeze is thursday | 23:39 |
| sean-k-mooney[m] | clarkb fungi gmann is there a reason for trying to do this in nova andn not in tempest | 23:44 |
| sean-k-mooney[m] | i dont think the current approch is the correct one | 23:44 |
| clarkb | sean-k-mooney[m]: well Ithink if nova generates keys it is reasonable to generate different key types. As a nova user I have never once relied on a key generated by nova for me though so I can see both sides | 23:45 |
| sean-k-mooney[m] | ecdsa is not a differnt key type | 23:45 |
| sean-k-mooney[m] | its a diffent algortiom for ssh key generation | 23:45 |
| sean-k-mooney[m] | so the existing key-type fileid is not valid to extend | 23:45 |
| sean-k-mooney[m] | and if we wer to expose this implentation detail we also should be exposing the key lenght | 23:46 |
| gmann | sean-k-mooney[m]: there are two things here 1. add support and tests in tempest for ecdsa which is this (I have given comment to add tests for that) https://review.opendev.org/c/openstack/tempest/+/807465 2. add support in nova to autogenerate the ecdsa key this is what can be proposed in spec | 23:46 |
| sean-k-mooney[m] | which spec? | 23:47 |
| gmann | and in nova spec we can discuss about autogenerating the ecdsa key in nova. this nova change is not only because of tempest test but a new feature | 23:47 |
| gmann | sean-k-mooney[m]: it is not yet proposed. but as you mentioned this is API change and need spec | 23:47 |
| sean-k-mooney[m] | right so if we want to extend this feature we really shoudl add 2 knew parmaters 1 key size and 2 key algorthim or key cypher | 23:48 |
| fungi | alternatively, consider that nova api deprecated and, as you say, have tempest generate and upload ecdsa keypairs instead | 23:49 |
| sean-k-mooney[m] | ya | 23:49 |
| fungi | i agree i've never used this nova "feature" either, so it does seem like maybe it's a vestige of a bygone era | 23:49 |
| sean-k-mooney[m] | personally i would prefer to consider the generation part deprecated | 23:49 |
| sean-k-mooney[m] | same i have always uses ssh-keygen or simialr espically when scpriting in ansible or similr | 23:50 |
| fungi | the classical way to handle asymmetric keys is to generate the pairs client-side and only communicate the public part | 23:51 |
| fungi | so having nova supply both halves is not great from a security perspective | 23:51 |
| sean-k-mooney[m] | yep espically since using this api means if the rest api is not protected with ssl the private key is sent to you in the clear | 23:51 |
| sean-k-mooney[m] | meaning it can be intercepted and while we dont log or store this key anywere as a user you dont know that | 23:52 |
| sean-k-mooney[m] | the other benifit of the client generating it is they can generate it with any secuirty requirements they like | 23:53 |
| gmann | yeah that seems more reasonable and secure. | 23:53 |
| sean-k-mooney[m] | fungi this is being motivated by limiations in the cirros image ssh server right | 23:53 |
| fungi | yes | 23:54 |
| gmann | sean-k-mooney[m]: that is from proposed goal https://review.opendev.org/c/openstack/governance/+/816587 | 23:54 |
| gmann | part of that | 23:54 |
| sean-k-mooney[m] | do we need to revisit using alpine or an alternitive guest image at somepoint or do we think cirros will continue to be upddated | 23:54 |
| sean-k-mooney[m] | gmann ack ya the fips goal | 23:55 |
| fungi | in short, the sshd in the cirros images lacks support for rsa with any signarture hash other than sha-1, and fips mode won't let tempest's ssh client use that, so ecdsa (which works on both ends) is an afreeable alternative | 23:56 |
| fungi | agreeable | 23:56 |
| sean-k-mooney[m] | yep its using a old version of dropbare from the commit message which makes sense | 23:57 |
| fungi | and yes, swapping out or improving cirros there is another option of course | 23:57 |
| sean-k-mooney[m] | ya i think long term we should look into nixos, alpine or maintianing cirros oursleve so we can update it | 23:57 |
| sean-k-mooney[m] | but ecdsa is a vaild short term step | 23:58 |
| fungi | if only someone had the time to resurrect emdebian | 23:58 |
| sean-k-mooney[m] | did the dib form docker feature ever land? | 23:58 |
| fungi | yeah, it's currently used to bootstrap fedora images, i believe | 23:59 |
| sean-k-mooney[m] | i more or less had alpine working i just could not get the init ram to find the root disk | 23:59 |
| gmann | from tempest test perspective we cab do either way 1. ecdsa in proposed patch which seems ok and does not depends on nova featrure | 23:59 |
| gmann | 2. new image has been considered in wallaby PTG and we said ok to try but again need someone to try adding/running tests with new image | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!