| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-30 | |||
| 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 | bauzas | jaypipes: we agreed on making the claims | |
| 14:16:02 | jaypipes | mriedem: yes | |
| 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 ^ | |
| 14:45:46 | openstackgerrit | Jay Pipes proposed openstack/nova master: pci: add uuid field to PciDevice object https://review.openstack.org/469147 | |
| 14:57:47 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Scheduler returning alternatives per destination https://review.openstack.org/465175 | |
| 14:57:47 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Have scheduler claim resources https://review.openstack.org/463993 | |
| 14:57:48 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Pass a list of instance UUIDs to scheduler https://review.openstack.org/465171 | |
| 15:01:03 | bauzas | jaypipes: mriedem: edleafe: there it is, restored the original direction for https://review.openstack.org/465171 with a bit of fixes from me | |
| 15:01:15 | openstackgerrit | Merged openstack/nova master: cinder: add attachment_create method https://review.openstack.org/459111 | |
| 15:03:36 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Completely remove mox from unit/network/test_linux_net.py https://review.openstack.org/445504 | |
| 15:04:33 | openstackgerrit | Merged openstack/nova master: cinder: add attachment_update method https://review.openstack.org/459113 | |
| 15:10:14 | sfinucan | jaypipes, mriedem: Could I ask you folks to take a look at https://review.openstack.org/#/q/status:open+project:openstack/nova+topic:bp/reserve-numa-with-pci today? | |
| 15:11:06 | jaypipes | sfinucan: sure thing. wrapping up a review on melwitt's quotas patch then will do. | |
| 15:11:21 | sfinucan | jaypipes: Sweet. Thank you :) | |
| 15:11:36 | jaypipes | sfinucan: in the meantime, I offer you https://review.openstack.org/469147\ | |
| 15:12:09 | sfinucan | didn't I review that already 🤔 | |
| 15:13:01 | sfinucan | jaypipes: Ah, I did - https://review.openstack.org/#/c/414768/. Yup, I'll take a look now | |
| 15:14:52 | jaypipes | sfinucan: ya, I broke that patch out of the n-r-p series because it's self-contained. | |
| 15:15:49 | openstack | Launchpad bug 1689692 in OpenStack Compute (nova) "MarkerNotFound when limit>num(instances) and marker starts in cell0" [High,In progress] - Assigned to Matt Riedemann (mriedem) | |
| 15:15:49 | bauzas | mriedem: I do wonder about a specific case for https://bugs.launchpad.net/nova/+bug/1689692 | |
| 15:16:10 | bauzas | mriedem: given 3 instances with #1 ACTIVE, #2 ERROR and #3 ACTIVE | |
| 15:16:43 | bauzas | mriedem: if we set the marker to #1, we're still able to get #2 and #3 AFAICU | |
| 15:16:45 | bauzas | mriedem: correct? | |
| 15:17:03 | bauzas | because #2 will verify cell0 with marker #1 and we'll pass on it | |
| 15:17:41 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Plumbing for tagged nic attachment https://review.openstack.org/415622 | |
| 15:17:43 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Delete nic metadata when detaching interface https://review.openstack.org/435387 | |
| 15:17:49 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Delete disk metadata when detaching volume https://review.openstack.org/435082 | |