Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-08-01
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
21:26:01 dansmith it requires scheduler races
21:26:18 mriedem i think it should just say server 1 is going on host A and when the filter scheduler processes server 2, it should put it on host B because we're tracking server1 on A in the HostState
21:26:46 mriedem i'm really just trying to make sure the HostState stuff doesn't explode w/o the upcalls
21:27:36 dansmith right, but your test may validate that without enough parallelism the right thing happens early on
21:27:41 dansmith which I guess is what you're going for,
21:28:01 dansmith but it doesn't prove that the upcall is working (especially since it won't even be done currently)
21:28:14 mriedem yeah not trying to prove the upcall
21:28:29 mriedem just trying to make sure the basic scenario through the filter works properly
21:29:02 mriedem i think people have tried to add a test for this in tempest in the past and it's been shot down because it could be done in nova functional tests, but i worry about how much we actually stub out in the functional stuff
21:29:15 dansmith I guess I'm not sure how the filter really works so I can't say if it'll be likely to fail
21:29:25 dansmith yeah
21:29:29 mikal Morning
21:29:45 cfriesen was there an official notification email that the Sydney presentation voting was open? I don't remember seeing one.
21:30:13 mriedem i don't remember seeing one, but i don't vote either
21:30:23 mriedem i'm only one person,
21:30:25 mriedem my vote doesn't count
21:32:54 cdent cfriesen: I’ve seen a few different announcements, but I’m not sure on which lists
21:33:11 cdent and there were some “we’ve extended voiting” announcements too
21:33:17 openstackgerrit Ed Leafe proposed openstack/nova master: Handle addition of new nodes/instances in ironic flavor migration https://review.openstack.org/487954
21:36:12 melwitt I can't find a link to the voting other than the one that cisco person sent out
21:36:25 melwitt (can't find in email I mean)
21:38:56 mriedem edleafe: i think i'm going to make us run E128 just for you https://review.openstack.org/#/c/487925/2/nova/virt/ironic/driver.py
21:43:43 cdent melwitt, cfriesen: I’m on a _lot_ of lists, so may not have been os-dev
21:44:07 melwitt I found one email to os-dev but it had no link to voting :P
21:44:25 melwitt vote ... somewhere ... that you should find by googling
21:45:23 edleafe mriedem: I'm consistent :)
21:54:29 cfriesen mriedem: for https://review.openstack.org/#/c/339715 would you be okay with me updating the "stale" migration to a "failed" or "error" state when we detect it? Or just check for them at nova-compute startup and assume they can't happen during "normal" running?

Earlier   Later