Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-08-01
19:32:19 melwitt cfriesen: right. this can happen in the scenario where the guest is busy (e.g. file open) and the guest ignores the ACPI request to detach from live. so what happens there is the detach from the persistent config succeeds but the live fails and so the overall detach fails
19:32:54 mriedem can qemu / libvirt just add a "seriously_please_detach_this_thing_at_some_point" API?
19:33:02 jmlowe cdent: it appears that most of my advise is scatological in nature
19:33:06 cdent jmlowe: ceph your glance and your disk
19:33:11 cfriesen melwitt: I take it libvirt chokes if you specify both VIR_DOMAIN_AFFECT_CONFIG and VIR_DOMAIN_AFFECT_LIVE and it's not in the persistant?
19:33:12 melwitt cfriesen: later on, if the guest is all done and the file is closed, the user wants to detach the volume again, they will issue the detach command and we'll need to detach it from only the live config bc it's already gone from the persistent config
19:33:16 cdent which may be scat
19:33:20 melwitt cfriesen: tes
19:33:22 melwitt *yes
19:33:56 melwitt libvirt will raise a "no device found" type error due to the AFFECT_CONFIG flag
19:34:21 cfriesen melwitt: almost seems safer to just handle persistent and live separately rather than trying to do them both and have to clean up if it fails
19:34:35 cfriesen but I suppose it's probably more efficient to do them both at the same time
19:34:43 jmlowe cdent: I do what I can, I was practically frothing at the mouth to go from Liberty to Mitaka just for the ceph glance nova stuff
19:35:16 melwitt cfriesen: yeah, I have wondered similar. in a normal scenario you'd only need one call to do the whole thing
19:37:01 cfriesen melwitt: looks okay to me with the caveat of adding that check for "live"
19:37:36 melwitt cfriesen: cool, thanks. I'm working on adding that and beefing up the test to match
19:37:44 melwitt and adding more code comments
19:38:32 cfriesen seems like we could have run into problems with the second call currently if live was false
19:39:27 melwitt yeah, possibly. I'm not sure what it does if you pass no flags, maybe a no-op one would hope
19:42:14 melwitt okay, 0 is VIR_DOMAIN_AFFECT_CURRENT=0
19:42:15 melwitt Affect current domain state. so it would do something, hopefully raising one of the "not found" we handle and then it would bubble up to compute which would ignore it
19:43:37 mriedem jaypipes: want to -2 this so someone doesn't get confused it's not for pike? https://review.openstack.org/#/c/488595/
19:44:17 openstackgerrit Matthew Edmonds proposed openstack/nova master: update policy UT fixtures https://review.openstack.org/398610
19:47:32 cfriesen melwitt: looks like libvirt virDomainDetachDeviceFlags() will error if "flags" is not set.
19:47:49 cfriesen based on a quick check of the code
19:47:59 mriedem dims: i'm beating my head against some weird traceback logging we're seeing but don't know where the traceback is actually coming from https://review.openstack.org/#/c/489683/2
19:48:05 mriedem dims: i assume it's something in oslo
19:48:39 melwitt cfriesen: okay. well, we'd pass 0 for flags if neither persistent nor live, and I thought 0 was a valid flag
19:49:58 cfriesen melwitt: wait, I think I misread.
19:50:01 cfriesen oops
19:50:11 cfriesen was looking at the function pointer, not the variable
19:54:11 cfriesen melwitt: the common code does not check for empty flags, but passes it on down to the specific sub-driver (ie the qemu one).
20:01:58 cfriesen melwitt: based on virDomainObjUpdateModificationImpact() it looks like if flags is empty it will set either VIR_DOMAIN_AFFECT_LIVE or VIR_DOMAIN_AFFECT_CONFIG based on whether or not the domain is currently active
20:02:37 melwitt cfriesen: ah, cool. so that's what they mean by VIR_DOMAIN_AFFECT_CURRENT (which is 0)
20:02:49 cfriesen yes
20:18:11 openstackgerrit melanie witt proposed openstack/nova master: Detach device from live domain even if not found on persistent https://review.openstack.org/488545
20:20:56 cdent mriedem: if you’re in a docs way here’s a bit of placement docs: https://review.openstack.org/#/c/469048/
20:23:59 mriedem ack
20:24:46 mriedem dansmith: whilst reviewing your cells v2 topology docaroo, i realized we could/should disable CONF.filter_scheduler.track_instance_changes in the superconductor mode for devstack,
20:24:55 mriedem since the computes are basically rpc casting into the ether
20:24:59 dansmith ah yeah
20:25:29 sdague speaking of docs, if anyone wants to fix a whole lot of our 404s... https://review.openstack.org/#/c/489650/ one more +2
20:25:36 mriedem so i'm +2 on the doc https://review.openstack.org/#/c/487183/ but what did you have in mind for documenting the upcall limitations?
20:26:40 dansmith mriedem: I can throw those into the bottom set of things if you want
20:27:02 mriedem ok, i mentioned them in ps5 to go in there, but you didn't add them so i didn't know what you had planned
20:29:02 dansmith unintentional
20:30:45 jackie-truong dansmith: Do you have a few minutes? I have another question related to https://review.openstack.org/#/c/457711
20:31:17 dansmith jackie-truong: okay, since that's not release-related it's not very high priority, but.. go ahead and ask
20:32:17 jackie-truong dansmith: Got it. We want the trusted_certs column to store lists of UUIDs
20:32:49 jackie-truong dansmith: On L31 of 363_add_trusted_certs.py, we're trying to store an sqlalchemy ARRAY of Strings
20:33:18 jackie-truong dansmith: I don't think that that's the best way to go about that, but unsure if you all of seen a similar need?
20:33:34 dansmith jackie-truong: yeah I have no idea what that would look like in the sql
20:34:42 dansmith huh arrays in sql
20:35:11 dansmith that's new to me, but I'm fairly certain that that's not the way to do this
20:35:40 dansmith jackie-truong: everywhere else that we store multiples of things, they're either as rows, related to the instance table, if we need to be able to query them (and if there will be lots)
20:36:08 dansmith the instance_extra table is specifically 1:1 to instances, and is just TEXT columns, where we store json blobs
20:36:25 dansmith can't query on the contents (easily), but if you just need to store a list of a few strings, then that's the place,
20:36:51 dansmith but ideally you'd store an object in there so it's versioned instead of just some complex unversioned wild-west structure of stuff
20:39:49 jackie-truong dansmith: Hmm we just need to be able to store and access the list of strings. If the trusted_certs column is a TEXT column, then the Instance object should be able to retrieve the list with something like L412 in https://review.openstack.org/#/c/489408/1/nova/objects/instance.py ?
20:41:06 dansmith jackie-truong: no, because the field is a list and the column (if TEXT) is a string
20:41:18 dansmith you have to serialize and deserialize the contents there somehow
20:41:31 jackie-truong Okay, that's where I was having the disconnect
20:41:53 mriedem more like https://review.openstack.org/#/c/489408/1/nova/objects/instance.py@982
20:42:19 mriedem dansmith: ok here is the track_instance_changes thing for devstack https://review.openstack.org/489742
20:42:36 mriedem i need to dig a bit into how the scheduler keeps up to date with what's in the compute node for the affinity filters if that's disabled
20:43:23 jackie-truong Thanks, @mriedem
20:44:06 jackie-truong It would probably make most sense to go ahead and create a TrustedCerts object and corresponding TrustedCertsList
20:44:51 jackie-truong s/TrustedCerts object and corresponding TrustedCertsList/TrustedCert object and corresponding TrustedCertList
20:44:53 dansmith no need for the list object
20:45:15 dansmith the list objects we have are mostly syntactic sugar for remotable query methods
20:45:21 jackie-truong So a single TrustedCerts object that stores the list of strings
20:45:23 jackie-truong got it
20:45:52 jackie-truong Cool, that gives me some better direction. Thanks!
20:52:08 openstackgerrit Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766
20:52:21 mriedem hilarious
20:52:22 mriedem policies body array A list of exactly one policy name to associate with the server group. The current valid policy names are:
20:52:27 mriedem a list of exactly one
20:53:00 openstackgerrit Jackie Truong proposed openstack/nova master: Add trusted_certs to instance_extra https://review.openstack.org/457711
20:53:09 dfisher ok, so, to continue the adventure of the flammable Oracle engineer … http://paste.openstack.org/show/617175/ … Something is clearly not implemented but I don't know what it is :(
20:54:09 mriedem get_inventory() method in your compute driver?
20:54:25 dfisher E486: Pattern not found: get_inventory
20:54:27 dfisher well!
20:54:39 dfisher thank you
20:55:22 mriedem where that shows up is very wonky
20:55:26 mriedem in the logs in that paste i mean
20:55:31 mriedem get_inventory is optional
20:56:21 dfisher ok.
20:56:31 dfisher hmm.
20:57:08 dfisher let me see if I can implement it real quick and see what happens.
21:22:56 mriedem dansmith: jaypipes: looks like tempest wasn't testing anti-affinity before https://review.openstack.org/489754
21:23:04 mriedem it was testing the different_hosts stuff
21:24:02 dansmith so that'll fail in our current multinode setup right?
21:24:23 mriedem that's what i'm trying to test
21:24:43 dansmith well, it'll be flaky I think
21:25:13 mriedem b/c we don't have the upcall?
21:25:29 dansmith yeah
21:25:30 dansmith well,
21:25:35 dansmith hmm
21:25:38 mriedem does that scenario rely on rebuilds?
21:25:42 dansmith no

Earlier   Later