Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-08-16
16:47:23 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Add functional resize tests using shared storage https://review.openstack.org/490733
17:18:55 openstackgerrit David Rabel proposed openstack/nova master: Adds support for gracefull shutdown for VMware instances https://review.openstack.org/494169
17:22:43 openstackgerrit Ken'ichi Ohmichi proposed openstack/nova master: Fix contributor documentation https://review.openstack.org/494277
17:42:35 openstackgerrit Pavlo Shchelokovskyy proposed openstack/nova master: Shuffle best hosts from weighed hosts https://review.openstack.org/494136
18:28:29 dansmith melwitt: you wanna send this? https://review.openstack.org/#/c/493963/4
18:28:44 dansmith it's just a "don't end up with things that sum to zero 'cause placement will reject it" sort of deal
18:34:17 melwitt dansmith: on it
18:42:08 melwitt dansmith: +W
18:42:15 dansmith thanks
18:42:21 dansmith cdent: you gonna propose the backport?
18:42:28 cdent can do, sure
18:42:32 dansmith it'd be nice if someone else would since I have to +2+W these
18:42:33 dansmith thanks
18:47:14 cdent dansmith: oh, am I supposed to wait until it merges? it seems that not doing so has meant it doesn’t get the nice references to the commit. oops.
18:47:40 dansmith cdent: you should be fine to use the current hash with cherry-pick -x
18:48:30 dansmith which shouldn't change unless we have to modify the current one
18:48:34 dansmith which is unlikely
18:48:56 melwitt dansmith: have you seen this or heard of some discussion about it? it makes the scheduler always spread instead of pack https://review.openstack.org/#/c/494136
18:49:32 dansmith melwitt: I think someone poked jay about that this morning but I havent' looked at all
18:49:44 melwitt okay. I'm just surprised by it
18:50:04 dansmith cdent: if you can update that backport with the header that'd be cool, otherwise I'll just wait and do it when it merges.. at least you'll be the owner that way
18:50:12 cdent yeah, wil do
18:50:18 dansmith I'll check on it when I get back from lunch
18:50:22 dansmith thanks
18:53:10 cdent never try to interact with gerrit while also trying to interact with panicking daugher and mother
19:11:33 cdent melwitt, dansmith: why is it that some people love pack so much?
19:11:49 cdent that fix looks right on for the ironic case
19:12:23 cdent (because it is only randomize those hosts in the weighted list that match the first weight)
19:14:01 melwitt cdent: I'm not certain how much they love it but it's currently possible to pack and after this change I think it's not, correct? the use case for fill-first is the ability to schedule large instances. in spread-first, you could easily lose the ability to schedule large instances
19:14:32 melwitt yeah, I understand for ironic it would be fine. but this is changing it across the board, right?
19:15:01 cdent if you want a resource provider to be for large instances, just set min_unit > 1 on it’s resource?
19:15:33 cdent I’m slightly kidding on that. I know that we have to maintain existing behaviors and expectations, but still… also s/'//
19:15:35 melwitt at the very least, there should be a release note that explains that fill-first is no longer possible to signal the change in behavior
19:16:38 melwitt this is the sort of thing we'd usually email the operators ML about to get a quick check if anyone cares about fill-first anymore
19:18:27 melwitt and if there's a way to address the use case with resource provider settings, then that's probably fine. something to include in the release note
19:19:04 dansmith cdent: spreading uses more power, means lower utilization on your hosts, and in the case of windows, makes you bleed on the license fee like crazy
19:20:25 cdent there’s an easy fix to that windows problem :) no, I get it, I just, meh, reality...
19:21:35 cdent hmm, so right now in libvirt at least, we provide now way to control min_unit. I guess we’ll want to change that eventually
19:22:23 melwitt yeah, and I want to know why setting host_subset_size isn't sufficient. that's the knob for adjusting the spread or pack
19:22:41 melwitt it's mentioned in the commit message but I didn't get what it means
19:26:21 cdent melwitt: do jay and pavlo cover that in their discussion on ps2?
19:27:35 cdent heh, and simultaneously jay said the same thing on the review
19:33:15 melwitt yeah, my bad
19:40:35 dansmith melwitt: from briefly looking, I'd expect that we're basically using the natural ordering of the resource providers as returned from placement,
19:40:47 dansmith which means the order isn't predictable, but it is consistent
19:41:07 dansmith which would mean that if you don't have any weights configured and you just want to pack, this would completely break your desired behavior
19:42:25 melwitt dansmith: okay, so the question there would be, could we get around by not random shuffling if weights are all 0 or can 0 not be treated as a special thing? is there a way to detect no weights have been configured
19:42:33 cdent where does the order that makes things pack come from is there are no weighers?
19:42:49 cdent if there
19:43:16 dansmith melwitt: maybe? I'm not sure I really see the problem here anyway
19:43:39 dansmith melwitt: if you want to spread, then spread. If you want to pack, you're _choosing_ less desirable placement in terms of performance
19:44:34 melwitt dansmith: I mean, we could keep this change if in the case of no weights configured, we don't do the random shuffle
19:45:25 melwitt what do you mean by you don't see the problem? you don't see the use case for the change?
19:45:26 dansmith I get that, I'm just not sure I see the point
19:45:29 dansmith ues
19:45:32 melwitt k
19:45:53 cdent the bug report goes into some detail on why it is bad for ironic, yeah?
19:46:00 melwitt I think the only point is the shuffling of same weights only vs shuffling of all (using host_subset_size)
19:46:08 dansmith it's basically "if the weighers don't know the difference between two things, then spread regardless of what you want"
19:46:24 melwitt yeah
19:46:31 dansmith like, two things that score the same are not equal if you want packing
19:46:39 melwitt right
19:46:47 dansmith and AFAICT, this is just choosing one default over the other (reversing the current default) right?
19:46:59 melwitt but the change wants the ability to shuffle things that score the same
19:47:23 melwitt that is, they can't get what they want with host_subset_size
19:47:49 dansmith yeah, but they're breaking pack people because they want to shuffle a smaller set of the top results
19:48:08 melwitt yeah I know. I was trying to think if there's some way to get them what they want and also not break pack people
19:48:36 dansmith sorry, I realize you think I mean I don't understand what they want
19:48:37 dansmith I do,
19:48:53 melwitt no, I know that you understand
19:48:54 dansmith I just think it's not the automatic applies-to-everybody performance optimization that they think it is
19:49:03 dansmith ack
19:49:18 melwitt I was just trying to explain what I was saying, that I was brainstorming if there's way to fulfill both use cases
19:49:42 dansmith yep yep
19:50:48 dansmith making 0.0 a magic weight seems less desirable to me
19:51:08 dansmith it's more confusing than a boolean called shuffle_same_weight_hosts=True, IMHO
19:51:18 melwitt yeah. the more I think about it the more I think that would be a bad idea. because weights can be negative too, so 0.0 is a real weight
19:51:23 dansmith because you think you disabled all weights and you get completely random behavior
19:51:36 dansmith yep
19:54:36 openstackgerrit Merged openstack/nova master: Add documentation for documentation contributions https://review.openstack.org/492124
19:55:13 openstackgerrit Merged openstack/nova master: Clean up *most* ec2 / euca2ools references https://review.openstack.org/492166
20:03:11 cdent dansmith: I’m done for the night. I it looks like https://review.openstack.org/#/c/493963/ is going to need a recheck. I put the hash on the backport manually.
20:40:38 oomichi sdake:
20:40:56 oomichi oh, sorry. ^^^ is my mistake
21:17:20 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Tweak connection_info translation for the new Cinder attach/detach API https://review.openstack.org/493324
21:17:20 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
21:20:43 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Add attachment_complete call to volume/cinder.py https://review.openstack.org/493323
21:20:44 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Tweak connection_info translation for the new Cinder attach/detach API https://review.openstack.org/493324
21:20:44 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
21:35:09 openstackgerrit Merged openstack/nova master: remove extension param and usage https://review.openstack.org/481491
21:38:51 openstackgerrit Eric Fried proposed openstack/nova master: [Trivial] docstrings, typos, minor refactoring https://review.openstack.org/493701
22:42:19 oomichi melwitt: hi, can you take a look at https://review.openstack.org/#/c/494277 ? That is just a follow-up patch for https://review.openstack.org/#/c/492124
22:42:48 oomichi I hesitated to clear many +1 with updating, then created another one
22:42:56 melwitt oomichi: sure, looking
22:43:02 oomichi thanks :)
22:43:49 melwitt +2
22:44:09 oomichi melwitt: thanks again
22:44:14 melwitt np
22:44:46 melwitt thanks for fixing those up
#openstack-nova - 2017-08-17
01:52:58 openstackgerrit zhangbailin proposed openstack/nova-specs master: Modify spelling error in nova-specs document https://review.openstack.org/494094

Earlier   Later