Earlier  
Posted Nick Remark
#openstack-nova - 2022-01-10
09:00:23 gibi please be gentle with me as I still needs to catch up
10:22:22 bauzas gibi: well, I'd say I'm all way meetings this week again :)
10:23:27 bauzas gibi: so I won't harass you *by now*
10:26:42 gibi bauzas: all way meetings sounds bad
10:27:41 gibi bauzas: do I need to ask for a spec freeze exception for https://review.opendev.org/q/topic:%22any-traits-support%22 ?
11:18:18 gibi OK, I saw the mail that the freez is moved to this week
11:20:22 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:29 gibi *check
11:20:41 lyarwood gibi: ack queued
11:21:05 gibi thanks
12:02:11 opendevreview Merged openstack/placement master: Add yoga spec directory https://review.opendev.org/c/openstack/placement/+/819660
13:57:51 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
14:00:59 gibi * not sure
14:36:36 opendevreview Alexey Stupnikov proposed openstack/nova master: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/776250
18:01:47 sean-k-mooney dansmith: so ya looking at the code its defintly an unintended consequence
18:01:58 dansmith yup
18:02:06 sean-k-mooney dansmith: i tought we were only checking for up sevice but its any service record
18:02:58 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:04:04 sean-k-mooney well unless service.get_minimum_version_all_cells is ignoreing down computes but i dont think it is
18:06:31 sean-k-mooney actully
18:06:32 sean-k-mooney https://github.com/openstack/nova/blob/4a359d576ddbc4b104116515c7e8b4176ac511f7/nova/db/main/api.py#L403-L412
18:06:56 sean-k-mooney its not chekc up or down but is checking forced down
18:07:17 sean-k-mooney so the workaorund would have been to force them down before the upgrade
18:08:04 sean-k-mooney and the fix would be to allow filtering based on current state
18:08:21 sean-k-mooney or somethign like that
18:11:40 dansmith yeah, makes sense
18:11:44 dansmith also,
18:12:00 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:19:32 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:36:56 opendevreview Artom Lifshitz proposed openstack/nova master: WIP: libvirt: remove default cputune shares value https://review.opendev.org/c/openstack/nova/+/824048
19:10:44 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:26:21 artom So if Jonathan Race writes an `if` block, is that a race condition? :D
19:27:20 chateaulav -lol, its a fast one for sure
19:30:36 kashyap chateaulav: Hey, I saw your email, but glad you're already here chatting. (I'm just back and catching up with things)
19:35:34 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:36:43 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:38:08 artom kashyap, wait, can you clarify? That spec is jut for the automatic re-approval paperwork, right?
19:38:15 kashyap artom: Mine, yes
19:38:26 kashyap artom: I was referring to chateaulav's spec - https://review.opendev.org/c/openstack/nova-specs/+/824044
19:38:37 kashyap "Adds Pick guest CPU architecture based on host arch in libvirt driver support"
19:38:42 artom Ah, sorry, got confused by the "CPU" in both
19:39:26 artom Ack, I can take a look
19:39:41 kashyap chateaulav notes he's got a preview version of the code.
19:40:16 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:37 kashyap artom: Yeah, not your fault; a quick look at the title can be deceiving :)
19:40:59 chateaulav no worries, i understand. :)
19:46:34 sean-k-mooney kashyap: did you reporpose that based on the xena version
19:52:04 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:31 dansmith sean-k-mooney: cool, looks very comprehensive :)
19:54:00 sean-k-mooney am i was considering punting warn out of the inital scope
19:54:18 sean-k-mooney do you think we shoudl try and keep it intiall or just start with pass/fail
19:55:00 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:33 sean-k-mooney ack. i was conidering moving it to the alternitives section but that works too
19:56:05 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:19 sean-k-mooney ack
19:57:13 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:59 dansmith I figured.. seemed like a whole section was affected :D
19:59:05 sean-k-mooney oh i like the idea of makeing devstack use this to see if the service is started
19:59:16 dansmith yeah, dogfood is yummy :)
19:59:34 sean-k-mooney your right we currently hit the service endpoitn and check if its up
19:59:44 dansmith yeah
20:00:42 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:48 sean-k-mooney o/
20:01:02 dansmith o/
21:19:31 opendevreview Ade Lee proposed openstack/nova master: Add ecdsa key generation https://review.opendev.org/c/openstack/nova/+/824062
21:20:21 ade_lee sean-k-mooney, fungi , gmann https://review.opendev.org/c/openstack/nova/+/824062
21:21:21 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:39 ade_lee and let me know what else needs to be added
21:22:08 fungi sure
21:22:20 ade_lee thanks!
21:29:32 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:30:30 ade_lee clarkb, sure I can do that - thats easy enough
21:30:56 ade_lee clarkb, please add that comment to the review so others can comment on it
21:31:13 clarkb can do
21:31:17 ade_lee thanks
21:31:23 clarkb and ya I'd wait for someone that knows nova better to weigh in on what I say before implementing it
21:32:23 fungi oh, i assumed that was for ssh's x509 auth
21:34:06 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:14 clarkb in any case ssh vs x509 vs ecdsa is a bit confusing to me
21:34:20 clarkb as they don't seem to align
21:35:01 fungi yeah, agreed
22:13:59 opendevreview Merged openstack/nova stable/xena: [rt] Apply migration context for incoming migrations https://review.opendev.org/c/openstack/nova/+/820553
22:24:55 ade_lee fungi, you haven't heard anything from canonical re: fips yet , have you?
22:25:22 ade_lee clarkb, ^^
22:25:31 ade_lee if not, I'll re-ping
22:26:05 clarkb I haven't seen anything
22:26:15 clarkb there was an initial response and then fungi jumped in with more info iirc
22:27:24 ade_lee clarkb, ack thats the last I saw too -- I'll re-ping them
22:58:20 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:59:10 fungi the easiest solution to it, from our perspective, is if ubuntu made their fips compliance solutions free for everyone
22:59:42 clarkb ya I suspect the easiset thing is for specific jobs to have access to a secret thta they use the enroll
22:59:49 fungi but that's a business decision involving the parts of canonical we rarely have the pleasure of interacting with
22:59:51 clarkb and then run that post merge or something
23:00:08 clarkb assuming their license system is ok with changing IPs and maybe even duplicate IPs over time
23:21:51 gmann ade_lee: ack, will check
23:37:14 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:55 sean-k-mooney[m] nova currently allows you to import ecdsa keys
23:38:23 sean-k-mooney[m] but it cant generate them
23:39:02 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:25 sean-k-mooney[m] at least not if you want to do it this cycle given spec freeze is thursday

Earlier   Later