| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-31 | |||
| 15:58:00 | mriedem | sdague: wasn't the limits stuff added here https://review.openstack.org/#/c/486642/ for a security bug? | |
| 15:58:11 | mriedem | or was the security issue just that it was completely unbounded to begin with? | |
| 15:58:11 | edleafe | cdent: ok, catching up. Looking through the long paste, I don't see where we clean up the allocations for the source host | |
| 15:58:22 | sdague | mriedem: yes, the security issue was completely unbounded | |
| 15:58:28 | sdague | it was originally set to 2 seconds | |
| 15:58:41 | edleafe | We PUT the allocations for the target, but don't seem to remove the source allocs | |
| 15:58:43 | sdague | then after that actually failed in the gate some times, it was bounced to 8 | |
| 15:58:45 | cdent | edleafe: it was the third of three PUTs | |
| 15:58:54 | sdague | but there are real world reports that times out in legit cases | |
| 15:59:28 | sdague | it still gives us a backstop though so you can't make a malicious image that eats all the cpu forever | |
| 15:59:46 | jaypipes | sdague: done | |
| 16:00:20 | sdague | jaypipes: thank you | |
| 16:01:07 | edleafe | cdent: ok, I see that now. So is that PUT not doing a true PUT? | |
| 16:01:25 | edleafe | cdent: or just for the consumer/RP combo? | |
| 16:01:50 | cdent | it's not doing a true put | |
| 16:01:59 | openstack | Launchpad bug 1707669 in OpenStack Compute (nova) "[placement] put allocations does not do a full overwrite of existing allocations" [High,Triaged] | |
| 16:01:59 | cdent | https://bugs.launchpad.net/nova/+bug/1707669 | |
| 16:02:09 | cdent | server-side is borked | |
| 16:02:43 | edleafe | cdent: what I'm asking is if it's just doing a true PUT for RP/consumer | |
| 16:02:54 | edleafe | cdent: and not for consumer | |
| 16:02:58 | edleafe | *just | |
| 16:03:29 | cdent | edleafe: sorry, I'm not parsing you | |
| 16:03:37 | mriedem | sdague: comments on more testing in https://review.openstack.org/#/c/487860/3/nova/tests/unit/test_nova_manage.py | |
| 16:03:46 | mriedem | the db url parsing has broken a few times | |
| 16:03:52 | cdent | the bodies of the PUTs, all three, are correct, according to our expectations of how the api behaves. the api doesn't not behave as we expect | |
| 16:03:58 | mriedem | and we have an outstanding bug for db urls with TLS info in them | |
| 16:05:44 | sdague | mriedem: so, using urlparse we're never going to hit that, but I'm fine putting some more in there | |
| 16:06:21 | mriedem | we were originally using urlparse | |
| 16:06:24 | mriedem | which was causing problems | |
| 16:07:00 | edleafe | cdent: yes I see that. Is the disconnect due to the fact that we expect when we PUT allocations for a consumer, it first removes any existing allocs for that consumer? | |
| 16:07:33 | ralonsoh_ | stephenfin: hi, can you take a look at my question in https://review.openstack.org/#/c/427145/? PS7 | |
| 16:07:53 | cdent | edleafe: that's the bug. we expect that, but it does not do that. what it was doing is removes only those allocations where rp uuid and consumer uuid match | |
| 16:07:57 | cdent | which is not enough | |
| 16:09:25 | edleafe | cdent: ok, that's what I was asking above about "or just for the consumer/RP combo?" | |
| 16:09:33 | edleafe | I'm following now | |
| 16:09:39 | edleafe | Is this being worked on? | |
| 16:09:45 | edleafe | IOW, can I help? | |
| 16:09:47 | cdent | yes, jay's integrating it in his stack | |
| 16:09:59 | jaypipes | just running new tests now.. | |
| 16:10:00 | edleafe | ok cool | |
| 16:10:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Clean variable names and docs around neutron allocate_for_instance https://review.openstack.org/489267 | |
| 16:10:11 | mriedem | i hate the allocate_for_instance code ^ | |
| 16:10:11 | cdent | edleafe: I think the main thing to do is try to break stuff | |
| 16:11:27 | edleafe | cdent: roger that. | |
| 16:15:54 | mdbooth | gibi_: Just looking at https://review.openstack.org/#/c/487958/4/nova/tests/functional/test_servers.py | |
| 16:16:02 | mdbooth | gibi_: Any idea how close that might be to landing? | |
| 16:16:52 | mdbooth | gibi_: I need to add a test for https://review.openstack.org/#/c/462521/ and ServerMovingTests looks like an obvious place for it | |
| 16:17:38 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Clean variable names and docs around neutron allocate_for_instance https://review.openstack.org/489267 | |
| 16:20:42 | cdent | mdbooth: I think gibi_'s gone. We could potentially land that code soon if dansmith and jaypipes think it belongs alongside jay's stack, but it is primarily for testing how allocations are handled, not verifying reverts etc. Not sure if that makes it better or worse. | |
| 16:21:42 | jaypipes | cdent: five minutes. | |
| 16:22:03 | mdbooth | cdent: Well the setUp there creates an environment with 2 computes sufficient for running resize(), which is exactly what I need | |
| 16:22:50 | cdent | mdbooth: yeah, it apparently also fixes some issues with doing that | |
| 16:23:11 | mdbooth | cdent: I'm not surprised in the slightest there are dragons. | |
| 16:23:24 | mdbooth | Didn't want duplicate the effort slaying them. | |
| 16:24:31 | cdent | indeed | |
| 16:32:14 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: don't allocate on compute nodes https://review.openstack.org/488595 | |
| 16:32:15 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: remove existing allocs when set allocs https://review.openstack.org/489273 | |
| 16:32:15 | openstackgerrit | Jay Pipes proposed openstack/nova master: remove source provider allocs in confirm_resize() https://review.openstack.org/488510 | |
| 16:32:27 | jaypipes | dansmith, edleafe, cdent, gibi_: ok dokey ^ | |
| 16:33:16 | cdent | word | |
| 16:33:40 | jaypipes | the bird. | |
| 16:34:11 | dansmith | I just got off the phone for the first time all morning, | |
| 16:34:19 | dansmith | so I need some food and then I'll dig in | |
| 16:34:56 | jaypipes | dansmith: ditto. | |
| 16:34:59 | jaypipes | about the food... | |
| 16:35:06 | openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted certificates to InstanceExtras https://review.openstack.org/457711 | |
| 16:38:25 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: requested security groups are not applied to pre-existing ports https://review.openstack.org/489275 | |
| 16:38:25 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: fix security_groups response parameter in os-security-groups https://review.openstack.org/489274 | |
| 16:38:56 | openstackgerrit | Chris Dent proposed openstack/nova master: Test resize with placement api https://review.openstack.org/487958 | |
| 16:55:25 | cdent | mriedem, jaypipes : on the topic of "live" placement tests: http://lists.openstack.org/pipermail/openstack-dev/2017-July/120369.html | |
| 17:14:55 | openstack | Launchpad bug 1707252 in OpenStack Compute (nova) "Claims in the scheduler does not account for doubling allocations on resize to same host" [Medium,Confirmed] | |
| 17:14:55 | cdent | jaypipes: did you already have a plan in mind for https://bugs.launchpad.net/nova/+bug/1707252 or is that one still open? | |
| 17:26:47 | jaypipes | cdent: I'd like to see if gibi's test runs successfully with the fix for 1707669 up | |
| 17:27:11 | cdent | i rebased that one on to your latest stuff | |
| 17:27:39 | cdent | he said it had worked with local mods | |
| 17:28:28 | cdent | jaypipes: if you're responding to my question about 1707252, it won't make any different will it. If you're making conversation then: ✔ | |
| 17:29:10 | jaypipes | cdent: sorry, yeah, doesn't handle the resize same host problem. you want to handle that? | |
| 17:29:47 | jaypipes | cdent: though I'm not sure how the scheduler can tell if it's a resize-to-same-host situation... | |
| 17:30:08 | cdent | jaypipes: yes, that's part of why I haven't done it yet | |
| 17:30:20 | jaypipes | cdent: :) | |
| 17:30:25 | cdent | I've poked around at deeper inspection of the allocations | |
| 17:30:35 | cdent | but anything I can think of feels very hacky | |
| 17:31:04 | cdent | but basically: | |
| 17:31:37 | jaypipes | yeah, same | |
| 17:31:38 | cdent | if there are same rps in the source and dest allocs, where one of the resource classes is VCPU that signals a local resize | |
| 17:32:02 | jaypipes | cdent: yeah, same thought I had. | |
| 17:32:09 | jaypipes | cdent: ugly, but I suppose it would work... | |
| 17:32:18 | jaypipes | what does dansmith think of that? | |
| 17:32:50 | dansmith | jaypipes: I think I said that last week as the way we could tell | |
| 17:33:09 | cdent | that's 3/3, shall I go ahead then? | |
| 17:33:17 | dansmith | jaypipes: that goes away once we get to queens and don't have computes managing the allocations anyway right? | |
| 17:33:19 | jaypipes | dansmith: k. still agree it's ugly though, eh? | |
| 17:33:34 | dansmith | aside from the fact that the destination will eventually put the single one | |
| 17:33:35 | jaypipes | dansmith: no, this needs to go in the scheduler... | |
| 17:33:37 | dansmith | jaypipes: of course it's ugly | |
| 17:33:50 | jaypipes | dansmith: because the scheduler is the thing that creates that "doubled-up" allocation. | |
| 17:34:11 | dansmith | jaypipes: oh I thought you were talking about how to clean up the doubled-for-same-host allocation on the compute | |
| 17:34:50 | dansmith | jaypipes: why does the scheduler need to probe which is the compute by looking at vpcu? it just needs to add the new allocation to the existing one, and if the RPs are the same then sum the values | |
| 17:35:08 | jaypipes | dansmith: that's part of it I yeah, and that would be unnecessary once we remove the allocations on compute stuff, but there's the first step needed to actually create the doubled-up alloc in the scheduler. | |
| 17:35:41 | jaypipes | dansmith: ack, yeah that's true. | |