| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-26 | |||
| 17:16:26 | openstackgerrit | Merged openstack/nova master: Dump config options on wsgi startup earlier https://review.openstack.org/638691 | |
| 17:21:33 | openstackgerrit | Chris Dent proposed openstack/nova master: Correct lower-constraints.txt and the related tox job https://review.openstack.org/622972 | |
| 17:26:03 | jaypipes | sean-k-mooney: +1 to skip func tests if change in docs dir | |
| 17:33:47 | mriedem | gibi: hmm ok so i guess we have to handle the network-vif-deleted event right? | |
| 17:36:06 | openstackgerrit | Merged openstack/nova master: [Doc] Best practices for effectively tolerating down cells https://review.openstack.org/638173 | |
| 17:37:51 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [Broken WIP] Split external events handling into 2 steps https://review.openstack.org/639396 | |
| 17:48:04 | artom | dansmith, so, you've just made me have an epiphany | |
| 17:48:26 | artom | I thought the claims would provide extra checking that the instance will fit | |
| 17:48:32 | artom | But no, the scheduler already does that | |
| 17:48:45 | artom | If the scheduler accepted a host, the claim will work. | |
| 17:49:00 | artom | The problem is that we never updated the XML, not that we allowed unacceptable hosts | |
| 17:49:10 | dansmith | artom: no, that's not true | |
| 17:49:21 | artom | Unless the host was forced | |
| 17:49:25 | artom | dansmith, no? | |
| 17:49:25 | sean-k-mooney | well it does but only to the extent that it check that something else has not raced with you for resouce on that host | |
| 17:49:34 | dansmith | artom: the scheduler may send you four instances that it thinks will fit into the last slot | |
| 17:49:44 | sean-k-mooney | ya ^ | |
| 17:49:52 | artom | Ah, that problem. | |
| 17:50:03 | artom | OK, so my original reply that I'm writing stands. | |
| 17:50:05 | dansmith | artom: since the scheduler does not reserve/lock/claim numa resources when it makes a decision, there's no context between decisions to make sure they don't overlap | |
| 17:50:07 | artom | Lemme finish it up. | |
| 17:50:29 | artom | Essentially, we need the claim to happen before driver.cclmad() | |
| 17:51:08 | artom | dansmith, ok, replies in https://review.openstack.org/#/c/634828/28 | |
| 17:51:16 | sean-k-mooney | cclmad -> check_can_live_migrate_at_destination? | |
| 17:52:25 | artom | Yeah, at some point I need to shorten stuff | |
| 17:53:12 | sean-k-mooney | artom: just dont do tha in the code... | |
| 17:53:56 | artom | Hrmm, unless we do manager.cclmad() -> driver.cclmad() -> source.cclmas() -> put instance_numa_topology into migrate_data -> driver.cclmad() returns -> manager checks for presence of instance_numa_topology -> claims -> driver.new_method_that_returns_NUMAMIgrateData | |
| 17:54:35 | dansmith | artom: isn't that what I suggested? | |
| 17:54:51 | artom | dansmith, I hadn't groked that last new_method part | |
| 17:55:51 | artom | Then we'd have some instance live migrating with a claim and migration_context, and some without | |
| 17:55:55 | artom | Is that acceptable? | |
| 17:56:31 | artom | Or do we still do the claim regardless, and just call that new_NUMAMigrateData method conditionally? | |
| 17:57:25 | dansmith | well, I was going to ask somewhere else about this.. it's unfortunate to have a bunch of new hosts that don't do claims until all the hosts are upgraded and then you've migrated everything around one step to the left | |
| 17:57:43 | dansmith | but, obviously if you need the source to do the pin config in the xml, it's tough | |
| 17:58:24 | dansmith | but yeah, I think you always call the new method, and that method does the claim iff the source indicated during its pre-check that it's going to do the xml manip for you | |
| 17:58:43 | dansmith | instead of you doing it before you called to the host based on educated guessing | |
| 17:59:38 | artom | dansmith, ok, and that's a nicely elegant solution to the upgrades problem | |
| 17:59:49 | dansmith | s'mah point | |
| 18:00:08 | artom | You know, a gracious "thank you" would have been even better ;) | |
| 18:00:19 | dansmith | GAWD | |
| 18:00:40 | artom | Who do you think you are, Han Solo? With your "I know"s | |
| 18:00:41 | artom | :D | |
| 18:00:42 | openstackgerrit | Chris Friesen proposed openstack/nova master: Add emulated TPM support to Nova https://review.openstack.org/631363 | |
| 18:01:15 | dansmith | I'm going to assume that is a very impressive deep reference that, if I got it, would be hilarious | |
| 18:01:40 | artom | I'm secure in my references and don't need no validation | |
| 18:01:47 | artom | (Unlike in my code) | |
| 18:02:08 | dansmith | heh | |
| 18:05:07 | mriedem | it's when leia tells han she loves him | |
| 18:05:08 | mriedem | duh | |
| 18:05:21 | mriedem | or wait, the other way around? | |
| 18:06:01 | dansmith | mriedem: so artom is leia and I'm solo? I'm okay with that I guess. | |
| 18:06:18 | artom | That backfired slightly | |
| 18:06:32 | mriedem | according to this tshirt, yes https://www.amazon.com/Star-Wars-Shirt-Medium-Heather/dp/B078Z1Z1BG/ref=asc_df_B078Z1Z1BG/?tag=hyprod-20&linkCode=df0&hvadid=319000730304&hvpos=1o1&hvnetw=g&hvrand=18017460218835467438&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1020048&hvtargid=pla-659942629837&psc=1 | |
| 18:06:33 | artom | (Nothing against Leia, she's badass - but the implication is that I, err, yeah) | |
| 18:07:03 | mriedem | dansmith is a scruffy looking nerf herder | |
| 18:07:22 | artom | Nerd herder, even - reviewing all our codes | |
| 18:07:35 | dansmith | we should maybe move on | |
| 18:22:32 | openstackgerrit | sean mooney proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226 | |
| 19:00:18 | aspiers | efried: I've pinned down the test failure to an interaction with test_pci_sriov_servers.SRIOVServersTest.test_create_server_with_pci_dev_and_numa_fails | |
| 19:00:24 | aspiers | efried: investigating further now | |
| 19:11:03 | efried | aspiers: cool. And weird. wtf? | |
| 19:11:11 | efried | probably some closure somewhere. | |
| 19:11:12 | aspiers | yeah, right :) | |
| 19:11:14 | aspiers | haha | |
| 19:11:17 | aspiers | probably my fault | |
| 19:11:37 | efried | you try to do something nice... | |
| 19:11:48 | aspiers | I guess the other test is bringing in different traits, and they are hanging around | |
| 19:12:06 | aspiers | although I thought each test would do sufficient teardown to avoid that | |
| 19:12:56 | cfriesen | sean-k-mooney: do you know if linux supports TPM 2.0 with CRB? | |
| 19:26:57 | cfriesen | Should nova verify whether helper utilities are present if they're needed by libvirt to provide a service? The alternative would be to fail at instance creation time. | |
| 19:27:38 | cfriesen | (this is in the context of vTPM, I'm wondering if I should check whether "swtpm" is available before advertising TPM support in placement) | |
| 19:36:44 | mriedem | dansmith: do you happen to remember the thought process when adding the Migration.hidden attribute here? https://review.openstack.org/#/c/181110/ | |
| 19:36:55 | mriedem | nothing ever actually sets that to True anywhere | |
| 19:36:58 | dansmith | it was dubious, but yeah, | |
| 19:36:58 | mriedem | but we expose it in the API | |
| 19:37:11 | dansmith | when we started to expose live migrations as migrations, | |
| 19:37:28 | dansmith | there was concern that operators may want to be able to hide the shuffling they do behind the scenes, | |
| 19:37:37 | dansmith | so we added that for the future backlash | |
| 19:37:59 | dansmith | not sure why we expose it in the api though, it's supposed to be a "do we display this in the api or not" flag | |
| 19:38:09 | mriedem | hmm, but GET /os-migrations is admin-only anyway | |
| 19:38:45 | dansmith | by default | |
| 19:38:48 | mriedem | sure | |
| 19:38:53 | dansmith | just sayin' | |
| 19:38:56 | dansmith | that was the reasoning | |
| 19:39:03 | mriedem | anyway, it's come up in https://review.openstack.org/#/c/636224/ as an alternative to filtering duplicate migrations by updated_at | |
| 19:39:29 | mriedem | because with cross-cell resize i'm hiding the instance using this instance.hidden field, and it would be pretty simple to do the same for migration.hidden, | |
| 19:39:35 | mriedem | but i'd have to thnk about implications to that API | |
| 19:40:35 | mriedem | especially because we have changes-since and changes-before filters on GET /os-migrations now too, so filtering duplicates based on updated_at is error prone | |
| 19:42:15 | dansmith | yeah I mean, hiding them using that flag until you're ready for them to be seen is probably reasonable I would think | |
| 19:47:57 | mriedem | jaypipes: we should probably sort this out before yonglihe is back online http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003166.html | |
| 19:48:38 | sean-k-mooney | cfriesen: i am not sure. i woudl assume it is the operators responcibilty to install any helper functions needed | |
| 19:51:29 | cfriesen | sean-k-mooney: I just put the check in...you can see what you think when I push the next iteration. It's unfortunate but I couldn't find a way to query libvirt itself about support. | |
| 20:14:26 | jaypipes | mriedem: by "sort this out" I presume you mean that you convince me I'm wrong? :) | |
| 20:16:26 | mriedem | not necessarily | |
| 20:16:36 | mriedem | i understand your point | |
| 20:16:51 | mriedem | i also remember server group 'policies' being only exactly ever one | |
| 20:16:56 | mriedem | which seems pretty gross to me | |
| 20:18:00 | mriedem | and writing code to use the server group api i always have to remember that little wart | |
| 20:20:34 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Introduce live_migration_claim() https://review.openstack.org/635669 | |
| 20:20:34 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: New objects for NUMA live migration https://review.openstack.org/634827 | |