| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-01 | |||
| 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 | |
| 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 | |