Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-05
15:57:21 efried cdent: Even more so if we have shared RPs involved, and these threads could be hitting from multiple separate compute nodes.
15:57:33 edleafe efried: this all seems like a good argument for placement not being part of nova
15:57:45 cdent a) that's not a thing I think placement should concern itself with, b) that's not a concern I think a cloud should concern itself with (in that fashion, it shoul be orchestrated at a different layer)
15:58:14 efried cdent: That's precisely my point. It should *not* be placement's responsibility. But therefore it *needs* to be the caller's.
15:58:32 efried cdent: But with the API as it stands, we provide the caller no mechanism to enable it to execute that responsibility.
15:58:40 dansmith mriedem: we kinda disabled the on_shared_storage flag, IIRC.. are we good to remove that in the rpc bump or do we need to keep it so the api can ask us to check it for compat?
15:58:46 efried cdent: Generation would be one such mechanism.
15:59:11 edleafe efried: so would something like Watcher, which can re-balance things at the cloud level
15:59:26 cdent efried: the caller can do what it likes, managing data how it likes, but it shouldn't rely on placement to do it for it, at the level of allocations. It could make requests for allocation candidates how it likes, look at them, analyze then, do whatever.
15:59:28 mriedem dansmith: are you asking b/c of gibi's functional test?
15:59:31 mriedem or b/c you're bumping major versions?
15:59:35 efried edleafe: After the allocation has been made and the instance has been scheduled? Sure. Messy, though.
15:59:37 edleafe efried: IOW, detect a crowded host and performt the migration to uncrowd it
15:59:53 edleafe efried: it
15:59:57 edleafe it's a cloud
16:01:08 efried edleafe: Right, I get it. I'm saying migration-after-the-fact is a viable solution, but it's more expensive/disruptive to the workload than getting the scheduling "right" in the first place.
16:01:38 edleafe efried: it *will* get it right the overwhelming majority of the time
16:01:51 edleafe The case we're describing is an edge of an edge case
16:02:07 efried edleafe: Actually, I think it'll get it "wrong" (for common definitions of "wrong") quite often.
16:02:27 efried edleafe: Only when lots of concurrent deploys are happening, of course.
16:02:30 dansmith mriedem: bumping major versions
16:02:49 efried edleafe: Or concurrent migrations (such as an "evacuate host" scenario).
16:03:24 gibi mriedem: I'm in the process to updat that patch not to depened on that flag
16:03:30 cdent efried: if you're a person deploying 3 instances and the mechanism you want to use to ensure they go different places is "not loaded please", that sounds wrong. Presumably what you really want is anti-affinity and not loaded.
16:03:50 cdent If you're just going with "not loaded" and you get something weird, isn't that you're own fault?
16:03:50 edleafe efried: https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L411-L422
16:04:13 cdent sigh: your
16:04:18 efried cdent: I mean, we can document it that way, but it's not very satisfying to the consumer.
16:04:30 efried cdent: And I don't agree that you necessarily want anti-affinity.
16:05:02 efried If host A is 10% full and host B is 90% full, I totally want my instances (each of which consumes 10%) to both go to host A.
16:05:02 edleafe efried: and also https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L426-L436
16:05:24 edleafe There is plenty of race avoidance in the code.
16:05:49 cdent I dunno, I think your host should just go where it will get what it needs, unless you tell it something special.
16:06:03 cdent And providing too many knobs is bad for everyone
16:07:08 efried edleafe: Okay, glad those mechanisms are there, but they're somewhat inelegant. (Not that thrashing GET /allocation_candidates is any more elegant - overall I think it's clunkier and less efficient - but as an example, 'twill serve.)
16:07:23 mriedem dansmith: i'd have to take a look at that flag to see what the api does with it
16:07:40 efried cdent: Too many knobs, sure, but I thought a "least consumed" weigher was one of the basics.
16:07:43 dansmith mriedem: okay I thought you did it which is why I was asking.. I'll add a note and come back to it
16:07:56 openstackgerrit Merged openstack/nova stable/pike: doc: Add user index page https://review.openstack.org/540494
16:08:02 openstackgerrit Merged openstack/nova stable/pike: Migrate "launch instance" user guide docs https://review.openstack.org/540495
16:09:06 cdent efried: is it? to me it sounds like a "exposing too much info to the user about this cloud" and "our resource accounting and allocation ratio subscription model is actually a cheat, here we've provided you with this way to get around it rather than being good cloud providers with good ratios"
16:09:13 mriedem dansmith: no i don't think so, sounds like a tdurakov thing
16:09:36 dansmith mriedem: ack
16:10:40 efried cdent: I don't see what this has to do with allocation ratios.
16:11:16 cdent if allocation ratios are set fairly and correctly, then where your instance goes shouldn't matter: it should always have good access to resources whatever host it lands one
16:11:43 cdent if hosts are oversiubscribed then of course you're going to try to do tricks to get on an underutilized host
16:12:39 efried cdent: That makes a lot of assumptions about the possible reasons for a "least consumed" deployment strategy.
16:13:05 cdent what other reason can you want other than needing to ensure you "get enough"?
16:13:53 efried cdent, edleafe: Anyway, y'all have convinced me we don't need/want this for Nova. So until/unless we get a request from some other placement consumer (which isn't quite so likely to happen as long as placement is part of nova) I can drop it.
16:18:04 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add regression test for bug 1735407 https://review.openstack.org/526095
16:18:06 openstack bug 1735407 in OpenStack Compute (nova) "[Nova] Evacuation doesn't respect anti-affinity rules" [Medium,In progress] https://launchpad.net/bugs/1735407 - Assigned to Balazs Gibizer (balazs-gibizer)
16:18:56 gibi mriedem: ^^ fixed the functional test, now start fixing the bugfix patch
16:26:15 mriedem dansmith: looks like gibi made onSharedStorage optional in evacuate
16:26:36 dansmith mriedem: right, but it was required in earlier api versions
16:26:37 openstackgerrit Jay Pipes proposed openstack/nova master: only increment disk address unit for scsi devices https://review.openstack.org/538310
16:26:51 mriedem dansmith: yeah, so it looks like we could kill it from compute...
16:26:52 dansmith so I'm wondering if we have to keep the yes/no/unspecified support in the lower layers
16:27:19 jaypipes melwitt, mdbooth: really need some assistance from either/both of you on https://review.openstack.org/538310. Please see my desperate cry for help in the second unit test there...
16:27:20 mriedem unless there is some scenario where operators actually need to rely on it b/c the auto-check using the driver is wrong,
16:27:23 mriedem but that would seem like a bug
16:27:49 dansmith mriedem: well, the point being the api used to advertise that it will check your work
16:27:59 dansmith so if people used that, and we silently ignore it in compute now...
16:28:22 mriedem it used it for some other stuff too, related to the adminPass
16:29:23 mriedem reading the spec https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/optional-shared-storage-flag-in-evacuate-api.html
16:30:02 openstackgerrit Eric Fried proposed openstack/nova master: placement doc: Conflict caveat for DELETE APIs https://review.openstack.org/540919
16:30:16 efried cdent, edleafe: ^ For the remainder of bug 1746373
16:30:17 openstack bug 1746373 in OpenStack Compute (nova) "Placement APIs with missing conflict detection" [Undecided,In progress] https://launchpad.net/bugs/1746373 - Assigned to Eric Fried (efried)
16:30:30 efried jaypipes also ^
16:32:03 mriedem dansmith: fine to just leave it in for compat
16:39:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Rename the 'recreate' param to rebuild_instance to 'evacuate' https://review.openstack.org/508190
16:39:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Rename the 'recreate' param in rebuild_instance to 'evacuate' https://review.openstack.org/508190
16:47:42 hrw stephenfin: what is docstring?
16:47:52 openstackgerrit Merged openstack/python-novaclient master: nova limits ERROR (Exception): Field names must be unique https://review.openstack.org/527922
16:47:53 openstackgerrit Merged openstack/python-novaclient master: Implement hypervisor hostname exact pattern match https://review.openstack.org/520187
16:49:38 hrw ah. """ D:
16:50:36 dansmith mriedem: ack
16:52:40 mriedem artom: https://review.openstack.org/#/c/508190/2/nova/compute/manager.py@2663
16:53:13 artom mriedem, ah, doh
16:53:28 artom mriedem, well, my second one still kinda stands :P
16:53:33 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Make sure that we have usable input for graphical console https://review.openstack.org/538003
16:53:37 hrw stephenfin: as you wish ;D
16:53:56 openstackgerrit Merged openstack/python-novaclient master: Add CLI to show instance usage audit logs https://review.openstack.org/409413
16:54:02 artom I'll remove the -1 though
16:57:01 stephenfin hrw: ++
16:59:29 hrw mriedem, jaypipes, sahid: can you take another look at https://review.openstack.org/538003 patch? it is simplest of all versions and comes with extra test
17:01:06 stephenfin bauzas: Gentle reminder for https://review.openstack.org/#/c/530743/
17:03:26 mriedem stephenfin: see the latest comment there, it introduces a bug
17:04:04 mriedem so a big -1 from me on the backport
17:04:30 jaypipes hrw: I never saw a response from you to sahid's review comments?
17:05:04 hrw jaypipes: rewrote whole as an answer
17:05:33 stephenfin mriedem: Yup, I was focussing on the latter part of the comment though: a partial fix was better than no fix
17:05:37 jaypipes hrw: heh, ok :)
17:05:56 jaypipes hrw: I don't see a followup from sahid which is why I asked..
17:06:03 stephenfin Probably best to wait for the fixes' fix to be merged though
17:06:06 hrw jaypipes: sure
17:07:17 hrw jaypipes: when 'a reply' would be just message then I write it. If it is simple fix then I mark Done'
17:07:43 hrw jaypipes: if it is complicated then do code mostly
17:08:09 hrw jaypipes: and here comment was more or less 'rewrite the shit' so I did
17:11:57 jaypipes hrw: understood. I'd still like to have sahid's opinion on it, though, since he had the biggest objection to it..
17:12:04 hrw sure

Earlier   Later