Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-02
15:55:54 jaypipes johnthetubaguy: actually, just reviewing you patch to fix the MB -> GB thing. running some tests on it locally, but overall the code looks fine (but also bauzas' identified issue with the allocation side also is a good find)
15:56:37 openstackgerrit Lance Bragstad proposed openstack/nova-specs master: Cleanup pike policy spec https://review.openstack.org/428222
15:57:08 bauzas jaypipes: mriedem: FWIW I'm about to add a PTG bullet about discussing on modifying the disk resources so it's bytes
15:57:16 lbragstad johnthetubaguy ^ feel free to squash that into your original version (it's just cleanup to get your draft passing)
15:57:56 johnthetubaguy lbragstad: oh, cool, thanks
15:58:05 jaypipes bauzas: I support the general idea. but would be a pain in the ass to migrate all the MEMORY_MB and DISK_GB inventory and allocation records to bytes...
15:58:07 johnthetubaguy lbragstad: feel free to just push to my change if you want, thats cool
15:58:12 johnthetubaguy jaypipes: great, thank you
15:58:20 lbragstad johnthetubaguy yep! also - you have a todo in there for the keystone model
15:58:22 jaypipes bauzas: in addition to the fact that MEMORY_MB and DISK_GB are standard resource classes.
15:58:51 lbragstad johnthetubaguy I can take that action item - but where do you want that documented? I felt weird putting keystone things in a nova specific spec
15:59:16 bauzas jaypipes: exactly
15:59:29 bauzas jaypipes: that's why I think we should be discussing about it during the PTG
15:59:38 bauzas jaypipes: or during a hangout
15:59:51 bauzas because yes, changing that could be a PITA
15:59:56 jaypipes cool with me.
16:00:03 jaypipes (the discussions) :)
16:02:06 edleafe jaypipes: cdent just found a flaw in this approach
16:02:27 edleafe jaypipes: we can't delete allocations by RP or ID
16:02:39 edleafe jaypipes: only by consumer_id
16:02:55 edleafe jaypipes: and a consumer might have allocations across multiple RPs
16:03:36 jaypipes edleafe: yes, and?
16:04:01 dansmith so after an evacuate,
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

Earlier   Later