| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-30 | |||
| 14:02:21 | mriedem | we use it for the default quota class tests | |
| 14:02:44 | mriedem | https://github.com/openstack/tempest/blob/master/tempest/api/compute/admin/test_quotas.py#L32 | |
| 14:03:23 | artom | Ah, but you have to specify a lock name | |
| 14:03:26 | artom | (Right?) | |
| 14:03:40 | artom | So if we want to use it for evacuation tests, we'd have to modify every other test to lock them out | |
| 14:03:41 | mriedem | yes, and define that lock in other tests too, that you need to lock with | |
| 14:03:51 | mriedem | correct, or do something sneaky in the base compute class | |
| 14:04:02 | openstackgerrit | Mikhail Feoktistov proposed openstack/nova master: Add is_vz_container function https://review.openstack.org/445947 | |
| 14:04:15 | artom | At least it shows they're amenable to that sort of stuff | |
| 14:04:36 | artom | Maybe a "synchronized" thing would fly | |
| 14:04:46 | jaypipes | edleafe, bauzas, cdent, mriedem: fancy doing a quick pow-wow about scheduler topics given we missed yesterday's meeting? | |
| 14:04:56 | bauzas | why not | |
| 14:05:02 | bauzas | I just provide some new revs | |
| 14:05:20 | mriedem | andymccr: is there a log with the tempest console logs in it from the failed tempest run? http://logs.openstack.org/21/468321/2/check/gate-openstack-ansible-os_nova-ansible-func-ubuntu-xenial/2b36790/console.html#_2017-05-30_12_03_59_084558 | |
| 14:05:26 | bauzas | about a thought I had about not providing instance UUIDs but rather a list of Spec objects | |
| 14:05:48 | mriedem | bauzas: so just totally explode rpc then? | |
| 14:05:52 | cdent | jaypipes: ten minutes ago edleafe said he was in meetings for next few hours, and I'm out in the big city on yet another dead car curn | |
| 14:05:57 | cdent | mriedem: that's what I thought too | |
| 14:06:00 | bauzas | mriedem: we already do that for the conductor | |
| 14:06:20 | bauzas | mriedem: as dan wrote it :) | |
| 14:06:23 | mriedem | we should do it less if we can help it | |
| 14:06:42 | bauzas | as I said in the commit msg, it's not really a performance issue | |
| 14:06:55 | bauzas | only if you're asking for more than one instance | |
| 14:06:55 | mriedem | how do you know? | |
| 14:07:00 | mriedem | right, which people do | |
| 14:07:02 | mriedem | people/systems | |
| 14:07:27 | bauzas | mriedem: see code, you'll see api calling conductor with passing a list of buildrequests and request_specs | |
| 14:07:34 | andymccr | double checking that. it looks like we might not be copying it for the gate purposes. will run a test and check! | |
| 14:08:03 | bauzas | not sure why it would be a problem now with the scheduler API, while it wasn't a problem with the conductor one | |
| 14:08:34 | cdent | bauzas: do you want to do it for sake of consistency, or is there some other reason? | |
| 14:08:59 | mriedem | bauzas: it might have been a problem that no one directly complained about, but people have complained about the memory usage bloat in nova over the last few releases | |
| 14:09:07 | bauzas | cdent: because of the comments I made in PS7 | |
| 14:09:16 | mriedem | and i have to assume some of that is tied to us passing big lists of big objects around and assuming it's fine | |
| 14:09:38 | bauzas | mriedem: you mean RPC payload size, or memory consumption for services ? | |
| 14:09:41 | mriedem | reqspecs were new in mitaka right? and people are just still getting to mitaka and beyond | |
| 14:09:48 | mriedem | both | |
| 14:10:42 | bauzas | mriedem: again, I'm still not convinced it's a performance issue | |
| 14:10:58 | bauzas | we're passing way more huge objects thru RPC | |
| 14:11:16 | bauzas | while the Spec object is fairly small, except the flavor bit | |
| 14:11:21 | mriedem | which patch are you even referring to? | |
| 14:11:40 | mriedem | https://review.openstack.org/#/c/465171/ ? | |
| 14:11:46 | bauzas | mriedem: I made a comment on PS7 https://review.openstack.org/#/c/465171/7 | |
| 14:11:54 | bauzas | mriedem: and I just provided a PS8 | |
| 14:12:34 | mriedem | so, | |
| 14:12:51 | mriedem | how did we go from agreeing to pass just a list of instance uuids over rpc last week, to now passing a list of request spec objects? | |
| 14:13:59 | mriedem | i think that was a hangout between myself, superdan, jaypipes and maybe edleafe, b/c cdent had to drop and we didn't recap our discussion anywhere | |
| 14:14:03 | mriedem | and bauzas was on PTO | |
| 14:14:38 | bauzas | that's a typical distributed problem :) | |
| 14:14:54 | bauzas | anyway, if folks thought about that... | |
| 14:14:58 | jaypipes | mriedem: we didn't agree to pass a list of reqspec objects. | |
| 14:15:09 | mriedem | jaypipes: i know, we never even talked about that | |
| 14:15:12 | bauzas | tbc, I wasn't aware of that agreement | |
| 14:15:35 | mriedem | jaypipes: we agreed to pass a list of instance uuids over the rpc method, not embedded in the request spec that's already getting passed, yes? | |
| 14:15:38 | bauzas | I just provided a patch for that purpose because I thought it was nicier from an interface PoV | |
| 14:15:45 | jaypipes | bauzas: Sylvain, you were on the hangout where we discussed doing the instance_uuids parameter. | |
| 14:15:53 | jaypipes | bauzas: it was right before you went on PTO | |
| 14:16:02 | jaypipes | mriedem: yes | |
| 14:16:02 | bauzas | jaypipes: we agreed on making the claims | |
| 14:16:18 | bauzas | I don't remember if we agreed on the interface | |
| 14:16:51 | bauzas | anyway, looks like the general direction was on another trend | |
| 14:16:57 | bauzas | edleafe: I'll provide a PS9 | |
| 14:17:08 | bauzas | because I still have concerns with PS7 | |
| 14:17:17 | jaypipes | bauzas: yes, I'm pretty sure we agreed to pass the instance_uuids as a new param on RPC. I remember that because I had said changing the RequestSpec object definition was cleaner but was persuaded that wasn't a good idea to add non-DB fields to an object definition. | |
| 14:17:41 | mriedem | maybe we should make a rule that anything discussed while one of the 5 people coding this is out, that we actually communicate decisions back into the mailing list, or something :) | |
| 14:17:58 | jaypipes | mriedem: hindsight 20/20 | |
| 14:18:17 | bauzas | so | |
| 14:19:10 | bauzas | I'm not particularly tied to my PS8 | |
| 14:19:29 | bauzas | I just think https://review.openstack.org/#/c/469037/2 is worth it anyway | |
| 14:19:40 | mriedem | ok, good, so 1 reqspec and list of instance uuids over the rpc method, not within the reqspec | |
| 14:20:26 | mriedem | bauzas: isn't that https://blueprints.launchpad.net/nova/+spec/request-spec-use-by-compute which hasn't been started yet? | |
| 14:20:38 | bauzas | I'm just surprised we had a consensus on an interface that made it very tied with how we use placement | |
| 14:20:45 | bauzas | but okay | |
| 14:21:18 | bauzas | mriedem: yup, it can be supported by that bp | |
| 14:22:09 | mriedem | andymccr: circling back, ok so i see at least one tempest test failed - but it's unclear why really, so if there are tempest console logs in a separate file it'd be cool to see those to debug | |
| 14:22:15 | mriedem | andymccr: if you're working on that, ack | |
| 14:23:09 | andymccr | mriedem: got it. thanks! I'm running a test manually and i'll get some logs and circle back if i cant figure it out, but tl;dr the hostmappingnotfound error is not the cause of the issue | |
| 14:23:28 | jaypipes | bauzas: how does this interface tie us to placement? | |
| 14:23:31 | mriedem | right i didn't think it would be, just ugliness in the logs | |
| 14:24:02 | bauzas | jaypipes: because we expose as a parameter some attribute only needed because we want to use placement | |
| 14:24:27 | bauzas | jaypipes: the original interface is ask_me_for(this_request) | |
| 14:24:54 | bauzas | jaypipes: now it becomes ask_me_for_(this_request, those UUIDs) | |
| 14:25:09 | bauzas | but anyway, I don't want to open wounds | |
| 14:25:25 | mriedem | since we're not pulling nova-scheduler out, at this point i don't really care | |
| 14:25:32 | mriedem | nova-scheduler is internal to nova | |
| 14:25:48 | bauzas | mriedem: which is what wasn't said in PS7's commit msg... | |
| 14:26:24 | bauzas | if we're saying we don't care of the beauty of the scheduler API, I'm totally fine | |
| 14:26:42 | bauzas | then, we shouldn't be afraid of having alternatives returned by the scheduler... | |
| 14:27:07 | cdent | bauzas: we decided that we have to return alternatives. the only open question is on the data structure | |
| 14:27:46 | mriedem | btw sheeple, the bottom big ass counting quotas change has a +2 on it https://review.openstack.org/#/c/446239/ | |
| 14:27:50 | bauzas | cdent: the reason why I asked edleafe to abandon https://review.openstack.org/#/c/465767/5 in favor of https://review.openstack.org/#/c/465175/7 | |
| 14:28:22 | jaypipes | mriedem: I have the quotas one up in gertty. | |
| 14:28:32 | jaypipes | mriedem: since I previously reviewed it, I'll take that on. | |
| 14:44:09 | EmilienM | mriedem: hey, do you know how nova-coresec launchpad works? I created one for tripleo and don't know the next step | |
| 14:44:19 | EmilienM | should I add the group to another group? | |
| 14:44:53 | mriedem | EmilienM: i never set that up, but https://security.openstack.org/vmt-process.html might have details | |
| 14:44:58 | mriedem | otherwise i'd ask fungi | |
| 14:45:05 | EmilienM | ok, thx | |
| 14:45:11 | EmilienM | you have a checkbox "This bug is a security vulnerability" | |
| 14:45:12 | openstackgerrit | Chris Friesen proposed openstack/nova master: show flavor info in server details https://review.openstack.org/434514 | |
| 14:45:43 | cfriesen | api-ref tweaks ^ | |