Earlier  
Posted Nick Remark
#openstack-nova - 2017-07-31
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:11 mriedem or was the security issue just that it was completely unbounded to begin with?
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 cdent https://bugs.launchpad.net/nova/+bug/1707669
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: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 cdent edleafe: I think the main thing to do is try to break stuff
16:10:11 mriedem i hate the allocate_for_instance code ^
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: remove source provider allocs in confirm_resize() https://review.openstack.org/488510
16:32:15 openstackgerrit Jay Pipes proposed openstack/nova master: placement: remove existing allocs when set allocs https://review.openstack.org/489273
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: fix security_groups response parameter in os-security-groups https://review.openstack.org/489274
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: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 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: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: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.
17:36:00 cdent no if the rps are the same, it might be shared

Earlier   Later