Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-26
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 mriedem but we expose it in the API
19:36:58 dansmith it was dubious, but yeah,
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: New objects for NUMA live migration https://review.openstack.org/634827
20:20:34 openstackgerrit Artom Lifshitz proposed openstack/nova master: Introduce live_migration_claim() https://review.openstack.org/635669
20:20:35 openstackgerrit Artom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source https://review.openstack.org/635229
20:20:35 openstackgerrit Artom Lifshitz proposed openstack/nova master: LM: add support for sending NUMAMigrateData to the source https://review.openstack.org/634828
20:20:36 openstackgerrit Artom Lifshitz proposed openstack/nova master: [WIP needs more tests] Full NUMA live migration support https://review.openstack.org/634606
20:20:36 openstackgerrit Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.openstack.org/634605
20:20:37 openstackgerrit Artom Lifshitz proposed openstack/nova master: Make the use of the CastAsCall fixture configurable https://review.openstack.org/639428
20:20:46 mriedem not sure if edleafe or cdent (api sig) would have an opinion
20:26:12 jaypipes mriedem: well, having more than one policy for the same server group is bonkers. however, having an instance in more than one server group is, IMHO, *not* bonkers and is actually something we'd like to see at Oath. e.g. a user wants to add instances to two server groups, where server group one is a rack anti-affinity and server group two is a power-domain affinity, etc.
20:28:41 mriedem lots of people over time have tried to add support for adding/removing servers to/from groups, and it's just been rejected every time, so i don't see it happening anytime soon
20:28:44 mriedem i get the request
20:29:03 jaypipes mriedem: ack
20:29:40 jaypipes mriedem: well, like you said, we can always mod the API in the future if ever we support >1 server group on boot.
20:29:49 jaypipes mriedem: I'll relinquish
20:30:53 mriedem up to you, i just know our existing server groups stuff is very flaky so adding support for >1 group would be a big deal
20:30:59 mriedem which i just don't see happening anytime soon
20:32:07 jaypipes ack
21:13:00 openstackgerrit Chris Friesen proposed openstack/nova master: Add emulated TPM support to Nova https://review.openstack.org/631363
21:13:33 cfriesen sean-k-mooney: with this version ^ I can boot instances after setting the version/model in either flavor or image.
21:53:23 openstackgerrit Artom Lifshitz proposed openstack/nova master: Introduce live_migration_claim() https://review.openstack.org/635669
21:53:24 openstackgerrit Artom Lifshitz proposed openstack/nova master: LM: add support for sending NUMAMigrateData to the source https://review.openstack.org/634828
21:53:24 openstackgerrit Artom Lifshitz proposed openstack/nova master: New objects for NUMA live migration https://review.openstack.org/634827

Earlier   Later