Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-02
16:04:20 dansmith we wouldn't want to delete allocations for not-our-instance-anymore
16:04:58 johnthetubaguy lbragstad: ah, sorry, I missundertood, got you now
16:05:14 jaypipes edleafe: should still be able to delete the resource provider if the deletion of the consumers on that resource provider (identified with an InstanceList.get_all_by_host()) is called to DELETE /allocations/<instance_uuid>
16:05:48 lbragstad johnthetubaguy yep - line 102 here https://review.openstack.org/#/c/427872/3/specs/pike/approved/policy-cleanup-pike.rst
16:06:01 jaypipes dansmith: yeah, we would. the evacuate would result in a *new* allocation on a new resource provider. we would definitely want to delete the allocation on the old one.
16:06:08 edleafe jaypipes: yeah, that could work.
16:06:28 dansmith jaypipes: edleafe just said you can only delete by consumer id, which is instance uuid right?
16:07:17 openstackgerrit Balazs Gibizer proposed openstack/nova master: Improve assertJsonEqual error reporting https://review.openstack.org/428199
16:08:07 edleafe dansmith: yeah, so to delete by compute node, you'd have to get all the instances for that node, and delete their allocations first
16:08:20 jaypipes dansmith: yes, what edleafe said.
16:08:50 dansmith edleafe: right, but after an evacuation we have allocations on two compute nodes for that instance, right?
16:09:14 edleafe dansmith: wouldn't the evacuation delete allocations?
16:09:17 jaypipes dansmith: I think what we're saying is that the evacuation process would delete the allocs on the source node before adding them in the dest node.
16:09:46 dansmith edleafe: how? allocations are only managed from the compute node's RT AFAIK
16:10:00 dansmith if we add that, then maybe that's okay
16:10:12 dansmith but I don't think it happens today
16:10:24 sfinucan diana_clarke: https://review.openstack.org/#/c/411441/2/nova/tests/unit/api/openstack/compute/test_cells.py
16:10:58 jaypipes dansmith: no, does not happen today.
16:11:19 dansmith jaypipes: so today we probably already corrupt the allocations after an evacuate anyway I guess
16:11:25 edleafe so let me summarize to make sure I'm clear on the evacuation scenario
16:11:30 jaypipes dansmith: sounds like it.
16:11:38 dansmith jaypipes: we just allocate again on the new node, and then maybe when the old node comes up, we delete the new and old ones
16:12:02 edleafe when we evacuate an instance to a new host, the instance ID stays the same, so the allocations for that instance remain
16:12:02 jaypipes dansmith: sounds right.
16:12:13 jaypipes dansmith: I mean, not right, but sounds like what currently would happen.
16:12:13 dansmith jaypipes: sounds wrong.. but accurate, unfortunately.
16:12:16 dansmith heh
16:12:19 jaypipes jinx :)
16:12:33 edleafe the new host for that instance would periodically update, see the new instance, and then re-allocate against the new RP
16:12:36 jaypipes dansmith: want to add a bug? or should I?
16:12:52 dansmith jaypipes: I have done nothing useful so far today, so let me
16:13:00 jaypipes edleafe: yes, eventually it would resolve itself... but still not ideal
16:13:10 edleafe If we then delete all allocations for that instance / consumer, there will be a window where there are no allocations for that instance
16:13:33 dansmith jaypipes: oh yeah I guess it will heal, although not after cdent's proposed lessening of the healing action I think
16:13:37 dansmith or at least, heal slower
16:13:57 dansmith jaypipes: but opens us up for a poor decision because we think that host is less loaded than it is
16:14:00 cdent dansmith: i've punted on that until we figure out how that stuff even works
16:14:11 dansmith cdent: yeah, I know, I'm just saying
16:14:26 dansmith cdent: either (a) this is a good reason to take the hit on the healing or (b) need to consider this kind of thing if/when we proceed with that
16:14:35 cdent I'd vote for b
16:14:55 cdent so we can get rid of some of the implictness and confusion when we talk about this stuff :)
16:15:20 dansmith well, things like this being papered over because we heal aggressively is problematic I think,
16:15:32 dansmith because before we heal, we're making bad decisions
16:15:48 dansmith which I think is an argument for (b), but..
16:16:35 cdent ( )|( )
16:17:31 dansmith um
16:17:43 dansmith a butt?
16:17:58 cdent a big ol butt
16:18:30 dansmith classy, cdent, classy
16:19:42 openstackgerrit Maciej Szankin proposed openstack/nova master: conf: mark glance.api_servers opt as required https://review.openstack.org/428241
16:21:10 openstack Launchpad bug 1661312 in OpenStack Compute (nova) "Evacuation will corrupt instance allocations" [Undecided,New]
16:21:10 dansmith edleafe: https://bugs.launchpad.net/nova/+bug/1661312
16:22:57 edleafe dansmith: Thanks.
16:24:08 lbragstad johnthetubaguy i'm going to propose a keystone spec for policy in code and I'll get a follow on to that to address your keystone TODOs in https://review.openstack.org/#/c/427872 (then we can reassess)
16:30:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix access_ip_v4/6 filters params for servers filter https://review.openstack.org/428071
16:35:49 mriedem gmann: any idea if Kevin had an update for this https://review.openstack.org/#/c/421760/?
16:35:56 mriedem or if the release note was going to be split out?
16:36:17 mriedem b/c we probably don't have time to wait for china to wake up
16:52:08 openstackgerrit Balazs Gibizer proposed openstack/nova master: Short circuit notifiations when not enabled https://review.openstack.org/428260
16:54:10 openstackgerrit Balazs Gibizer proposed openstack/nova master: handle uninited fields in notification payload https://review.openstack.org/415857
16:55:57 jaypipes sdague, dims: new box, trying to run some py 3.5-specific things. getting this: http://paste.openstack.org/show/597397/. Any ideas?
16:58:40 openstackgerrit Artom Lifshitz proposed openstack/nova master: Pass APIVersionRequest to extensions https://review.openstack.org/425876
16:59:03 mriedem jaypipes: read the note in tox.ini
16:59:09 mriedem you need to delete .testrepository
16:59:23 jaypipes ah. thx mriedem.
17:01:16 alex_xu mriedem: let me try to take care of https://review.openstack.org/#/c/421760
17:02:02 openstackgerrit John Garbutt proposed openstack/nova master: [WIP] Placement api: Add json_error_formatter to defaults https://review.openstack.org/395194
17:02:31 ildikov johnthetubaguy: mriedem: can you come to the Cinder-NOva meeting?
17:04:12 johnthetubaguy ildikov: ah, thats moved to today then I guess
17:04:50 johnthetubaguy ildikov: I have updated my calendar, but honestly I have to chase a few of these RC related patches
17:05:04 mriedem ildikov: busy with rc1 things
17:05:37 ildikov johnthetubaguy: mriedem: yep, it got moved, but will ping you directly if something pops up then
17:06:55 mriedem alex_xu: thanks, i think at this point i'd rather just make the reno a separate patch
17:07:08 mriedem the api-ref change is too large and needs a much more detailed review
17:07:32 alex_xu mriedem: yea, agree with that, just working on separating the patch
17:29:15 openstackgerrit Diana Clarke proposed openstack/nova master: Add offset & limit docs & tests https://review.openstack.org/411441
17:33:02 openstackgerrit John Garbutt proposed openstack/nova master: Report reserved_host_disk_mb in GB not KB https://review.openstack.org/428120
17:39:53 jaypipes johnthetubaguy: lol between 2.7 and 3.5 float handling, eh?
17:43:06 melwitt jaypipes: mriedem1 and I were discussing yesterday, is everything already merged that handles the local disk for volume backed instances to treat it as 0? does it also request 0 disk during a rebuild, etc?
17:46:00 mriedem mdbooth: i'm going through your nfs mount patch now
17:46:05 mriedem mdbooth: so don't drop off yet
17:46:09 openstackgerrit Alex Xu proposed openstack/nova master: Add release note for filter/sort whitelist https://review.openstack.org/428285
17:46:14 alex_xu mriedem: ^ done
17:46:18 mriedem thanks
17:46:21 openstackgerrit Maciej Szankin proposed openstack/nova master: conf: mark glance.api_servers opt as required https://review.openstack.org/428241
17:46:24 alex_xu np
17:46:38 dansmith melwitt: yeah, I think we should be good there
17:47:24 melwitt sweet
17:53:46 johnthetubaguy jaypipes: the joys!
17:54:06 johnthetubaguy jaypipes: I have a concern on this ironic patch still: https://review.openstack.org/#/c/404472
17:54:25 johnthetubaguy jaypipes: but something tells me I am miss understanding the resource tracker sequence
17:55:17 diana_clarke sfinucan: thanks a bunch for reviewing that!
18:02:24 sfinucan diana_clarke: np :)
18:02:25 mriedem mdbooth: lyarwood: before i go further, some comments/questions inline https://review.openstack.org/#/c/383859/13/nova/virt/libvirt/volume/mount.py
18:09:43 BobBall johnthetubaguy / mriedem FYI I believe https://review.openstack.org/#/c/428180/ will fix the Citrix XenServer CI
18:10:26 mriedem cool
18:10:28 BobBall johnthetubaguy / mriedem: A dodgy Cinder commit meant that "older" versions of pvs would all fail (as they don't have the newly required option) - the check for the version was broken.
18:11:11 BobBall We will monitor the CI after this cinder commit is merged and let you know the results and when we'd like to re-start voting.
18:11:16 mriedem sure
18:11:31 openstackgerrit Maciej Szankin proposed openstack/nova master: conf: resolved TODOs in compute configuration https://review.openstack.org/426793

Earlier   Later