| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-17 | |||
| 04:27:12 | openstackgerrit | melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324 | |
| 07:22:45 | kashyap | aspiers: Morning, just took a quick look. I see the topic is: machine types as 'traits'. Will respond today once I finish something | |
| 08:00:34 | openstackgerrit | Hamdy Khader proposed openstack/nova master: Do not perform port update in case of baremetal instance. https://review.openstack.org/649345 | |
| 08:33:20 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: Re-propose stable device rescue for Train https://review.openstack.org/651151 | |
| 09:09:09 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Add in_tree field to RequestGroup object https://review.openstack.org/649534 | |
| 09:09:10 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Add get_compute_nodes_by_host_or_node() https://review.openstack.org/650877 | |
| 09:09:10 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Pass target host to RequestGroup.in_tree https://review.openstack.org/650878 | |
| 09:09:11 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Query `in_tree` to placement https://review.openstack.org/649535 | |
| 09:09:11 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: WIP: FUP on use-placement-in-tree series https://review.openstack.org/653362 | |
| 09:49:53 | stephenfin | rechecking all the things | |
| 10:26:24 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova-specs master: Add "Secure Boot support for KVM & QEMU guests" spec https://review.openstack.org/506720 | |
| 10:27:50 | kashyap | sean-k-mooney: Hi, when you get a minute ^ I've wrote a summary response. And addressed a few things. | |
| 10:28:48 | kashyap | I spent a lot of time writing the summary response, please read it in full before responding. | |
| 10:45:38 | kashyap | lyarwood: gibi: If you have 15 more minutes today, appreciate another look at this: https://review.openstack.org/506720 | |
| 11:01:48 | aspiers | kashyap: cool thanks | |
| 11:02:05 | kashyap | aspiers: About to hit 'submit' with my comment | |
| 11:02:10 | aspiers | awesome | |
| 11:02:32 | kashyap | aspiers: Also if you have spare neurons, here's the UEFI SB spec: https://review.openstack.org/#/c/506720/ | |
| 11:02:48 | kashyap | I addressed as much as I can. And my eyes are weary from reading my own text. (Despite extensive editing) | |
| 11:02:53 | aspiers | if anything I have a neuron deficit, but that's my problem ;-) | |
| 11:02:58 | aspiers | Haha I know that feeling | |
| 11:04:59 | kashyap | aspiers: No problem at all. Then just say "no". :-) | |
| 11:06:09 | aspiers | I hate asking people for help and not offering some in return though :-/ | |
| 11:12:25 | sean-k-mooney | kashyap: ya most of your responce makes sense. ill re review with itopen in a secon tab | |
| 11:13:52 | kashyap | Nod. I would like to avoid "scope creep". "Takcle few things, and takle them well" | |
| 11:16:00 | sean-k-mooney | well i dont think you can tackel it well without the trait for secure boot support and if we add one then we have to add it for all hyperviors that support it or require operator to manully add it to the flavor instead of making it automatic | |
| 11:16:27 | sean-k-mooney | so the way to avoid scope creap is to documnet the reqrirement to add it to the flavor. | |
| 11:16:33 | kashyap | Let's talk systematically on the change. I need to go be AFK for lunch | |
| 11:16:51 | sean-k-mooney | sure :) | |
| 11:19:21 | NewBruce | sean-k-mooney: (mnaser) - have restared nova-conductor, issue still persists; cold migration RDO - OSA works fine, and OSA - OSA is ok | |
| 11:19:29 | NewBruce | - have updated the launchpad | |
| 11:21:36 | sean-k-mooney | NewBruce: you are sure your python interperter was not built on friday the 13th and shipt on april 1st with some magical gremlens thrown in for good mesure | |
| 11:21:45 | NewBruce | he he he, seems that way, huh? | |
| 11:22:25 | NewBruce | ive got on my to try 1) disable binding-extended (if possible) 2) upgrade_levels = queens 3) priest + full a moon | |
| 11:22:35 | sean-k-mooney | im wondering if we litrally need to do a singel node osa deployment + add a singel node rdo compute to actlly be able to reporduce this | |
| 11:23:20 | NewBruce | yeah, im thinking what we can do to reproduce | |
| 11:24:22 | sean-k-mooney | NewBruce: is you rdo deployment made with triplo or packstack? | |
| 11:24:45 | NewBruce | Not that im aware of, it pre-dates my time here - but i think it was pretty ad-hoc | |
| 11:25:30 | sean-k-mooney | so its a manual install of RDO without a tool? | |
| 11:25:39 | NewBruce | but going back to basics and what we know; we can localise it to post_migrate and an attempt to update the port profiles, which it shouldnt be doing. right? | |
| 11:25:51 | sean-k-mooney | im wondering if we can use a gate job to repoduce | |
| 11:26:23 | openstackgerrit | Jiri Suchomel proposed openstack/nova master: WIP: Initial prototype for simple RPC health checks https://review.openstack.org/653406 | |
| 11:27:07 | sean-k-mooney | mnaser: it should be fairly simple to create an all in one OSA right, im wondering how hard it would be to also add a singel node rdo computej too maybe via packstack to repoducs NewBruce's issue | |
| 11:27:10 | NewBruce | so, peppering the api.py with enough debug statements we’ve been able to localise where thats done - and we should be able to walk backwards right? | |
| 11:28:11 | NewBruce | sean-k-mooney: did you see the full log traces i sent? | |
| 11:28:44 | sean-k-mooney | yes it is ending in post migrate so we should be able to walk backward. | |
| 11:29:12 | NewBruce | grabbed your email from you launchpad page - will drop you a mail shortly | |
| 11:29:13 | sean-k-mooney | NewBruce: no not yet. bit of a late start today so still catching up on things | |
| 11:33:06 | NewBruce | quick question to the assembled masses - does anyone know if Enable cold migration with target host - Queen (https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/cold-migration-with-target-queens.html was ever implemented? ive not had any luck getting it to work | |
| 11:34:06 | sean-k-mooney | well its in the implemented section so it should have been yes | |
| 11:35:08 | sean-k-mooney | you cant do it via osc | |
| 11:35:53 | NewBruce | only apl? | |
| 11:36:00 | sean-k-mooney | nova migrate [--host <host>] [--poll] <server> | |
| 11:36:10 | NewBruce | Aha - gotcha; cheers | |
| 11:36:26 | sean-k-mooney | you have to add --host and the order is cahnged | |
| 11:36:34 | sean-k-mooney | we should proablly add that to osc too | |
| 13:24:54 | mriedem | thoughts on a potentially less invasive fix (see inline comments) on this stein regression https://review.openstack.org/#/c/653273/ are appreciated | |
| 13:25:10 | mriedem | i wrote the fix late last night but aren't super happy with how grossly tightly coupled all of that code is | |
| 13:32:17 | sean-k-mooney | mriedem: i was talking to NewBruce about the bug they are hitting and i tink i might know how to fix it but still not clear on why its happening. im starting on a patch now. should i add you to review list when i submit | |
| 13:42:39 | sean-k-mooney | lyarwood: mriedem when ye have time can one of ye +2 +W this https://review.openstack.org/#/c/644035/ so that we use the correct upper_constratins | |
| 13:49:09 | mriedem | sean-k-mooney: done and yes | |
| 13:51:55 | sean-k-mooney | thanks and cool will do | |
| 13:54:26 | mriedem | bauzas: want to hit this backport https://review.openstack.org/#/c/647911/ ? | |
| 13:54:39 | bauzas | sure | |
| 13:54:48 | mriedem | all of them actually since it's a gate race issue https://review.openstack.org/#/q/If966eb1161c842ff49aa530e4482dbca87b61a3e+status:open | |
| 13:54:50 | bauzas | looking | |
| 13:54:53 | mriedem | http://status.openstack.org/elastic-recheck/index.html#1820337 | |
| 14:08:24 | kashyap | aspiers: Hiya...seems like I need the getDomainCapabilities() API call for Secure Boot | |
| 14:08:31 | kashyap | aspiers: Wondering if you're planning to split it out: https://review.openstack.org/#/c/633855/11/nova/virt/libvirt/host.py@680 | |
| 14:09:01 | aspiers | I wasn't, as per previous conversation | |
| 14:09:13 | aspiers | but maybe that can be revisited | |
| 14:09:58 | kashyap | aspiers: Yeah, let's revisit that conversation, plese | |
| 14:10:14 | aspiers | Can you do me a favour and find the link to it? ;-) | |
| 14:10:17 | kashyap | aspiers: Because, IMHO, it is not needed to tie that to SEV at all | |
| 14:10:18 | aspiers | Maybe in that review | |
| 14:10:40 | aspiers | I remember explicitly explaining the dependency somewhere | |
| 14:11:02 | aspiers | Oh, that *is* the link | |
| 14:11:08 | kashyap | Yeah :-) | |
| 14:11:17 | aspiers | Yeah, my comment on March 19th | |
| 14:11:39 | kashyap | aspiers: Oh, I'm blind. Will read it | |
| 14:11:45 | aspiers | :) | |
| 14:11:59 | kashyap | aspiers: The reason I ask is ... just now a libvirt dev was suggesting: | |
| 14:12:19 | kashyap | "I suggest Nova queries domcapabilities first, to see if 'efi' with Secure Boot is available" | |
| 14:12:33 | kashyap | (When implementing SB support, i.e.) | |
| 14:21:55 | mriedem | so we have a RESIZE_CONFIRMING task_state enum but never use it while confirming a resize https://github.com/openstack/nova/blob/e25d59078e61fe9f925dbef53dfe88e575d34dab/nova/compute/api.py#L3535 | |
| 14:21:59 | mriedem | that seems...not good? | |
| 14:22:28 | mriedem | unlike when reverting a resize we set the task_state in the API before casting to compute https://github.com/openstack/nova/blob/e25d59078e61fe9f925dbef53dfe88e575d34dab/nova/compute/api.py#L3515 | |
| 14:26:43 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: libvirt: Do not reraise DiskNotFound exceptions during resize https://review.openstack.org/571410 | |
| 14:28:09 | mriedem | vdrok: mdbooth: lyarwood: more comments in https://review.openstack.org/#/c/571410/9 | |
| 14:29:10 | mriedem | i'm inclined to take a more conservative incremental approach to fixing the VERIFY_RESIZE steady state issue | |
| 14:29:20 | mriedem | which we could also backport more safely i think | |
| 14:31:31 | vdrok | meaning somewhat like it was done in ps7 https://review.openstack.org/#/c/571410/7/nova/virt/libvirt/driver.py | |
| 14:31:53 | mriedem | exactly | |
| 14:33:05 | mriedem | i'm not entirely sold on the completely ignore case like in bug 1824974 where the disk on the host is garbage and we just put our heads in the sand | |
| 14:33:06 | openstack | bug 1824974 in OpenStack Compute (nova) "Nova Compute Manager (Resource update) fails if a disk is missing" [Low,In progress] https://launchpad.net/bugs/1824974 - Assigned to Vladyslav Drok (vdrok) | |
| 14:39:35 | mnaser | as far as I know RDO ships upstream code | |
| 14:40:13 | mnaser | NewBruce: I wonder if it would be a good exercise to change one of the compute nodes to log it's current highest negotiated rpc version | |
| 14:40:26 | mnaser | and then see if for some reason it's negotiating a bad number | |
| 14:41:28 | artom | mnaser, I believe you're right, RDO is straight up upstream | |
| 14:41:35 | artom | Any backports we do is OSP, not RSO | |