Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-08-02
16:13:45 cdent dansmith: are you doing just the undoubling, or also the doubling?
16:13:58 dansmith cdent: we're already doubling right?
16:14:15 mriedem we only double if >1 provider
16:14:18 cdent we don’t have info to double
16:14:20 cdent yeah, what mriedem says
16:14:24 dansmith ah okay
16:14:30 mriedem we can figure out the resize to same host case
16:14:33 dansmith then yeah I'll look at that too
16:14:37 mriedem in the scheduler, that's what i was going to poke at
16:17:22 dansmith cdent: can you look at my comment on the top one just now?
16:18:16 cdent oh yeah that. every single time I read that chunk of code I get confused
16:18:20 cdent they are different structures
16:18:46 cdent i’m not sure how we ended up there
16:19:07 dansmith cdent: they're supposed to be different you mean?
16:19:11 dansmith GET vs PUT?
16:19:15 cdent yeah
16:19:27 dansmith how is that restful?
16:19:42 cdent it isn’t very
16:19:50 dansmith okay, glad we agree on that :)
16:19:55 cdent but there was a disagreement between you/me and jay at some point
16:20:10 cdent you and i wanted the GET to return a dict because it made processing the response easy
16:20:19 cdent (this was at the end of last summer or so)
16:20:24 dansmith not about that, that I know of, but maybe it ended up with a disparity as a side effect?
16:20:46 cdent side effect of?
16:21:08 dansmith meaning, I would never argue for GET/PUT to be different structures, so I'm wondering if we just never made PUT match the changed GET or something and nobody realized?
16:21:55 cdent oh, possibly?
16:22:05 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
16:22:20 dansmith mriedem: you're working on the scheduler doubling or what? I kinda need to do it to test any changes I make for the un-doubling, so I might as well do it unless you've already started
16:22:30 cdent but I also think there was some dislike (I don’t recall why) of the rp uuid being a key in the POST
16:22:36 dansmith cdent: that's pretty disappointing
16:22:41 dansmith regardless of how we ended up here
16:22:45 cdent indeed
16:22:58 cdent there are quite a lot of disappointments
16:23:12 mriedem dansmith: was just starting with a unit test for the scheduler
16:23:26 dansmith mriedem: okay I guess I'll hold off them
16:23:27 dansmith *then
16:23:59 mriedem i'll throw up the wip shortly
16:24:00 dansmith I'm really kinda confused about this doubling anyway
16:25:17 dansmith I guess it's the attempt to account for shared storage that makes this complicated,
16:25:22 dansmith and which avoids doubling for same-host
16:25:30 cdent dansmith: yes
16:26:03 mriedem yup
16:26:38 mriedem "Remove any allocations against resource providers that are
16:26:38 mriedem # already allocated against on the source host (like shared storage
16:26:39 mriedem # providers)"
16:26:49 mriedem so i guess the intention was to specifically not double up shared storage
16:26:51 mriedem on a mov
16:26:52 mriedem *move
16:26:55 dansmith which is wrong anyway
16:27:00 dansmith for certain types of shared storage
16:27:11 mriedem seemed like the right idea at the time?!
16:27:13 dansmith it's not wrong for a volume, but is wrong for a compute node using ceph
16:27:21 mriedem which was 72 hours ago?
16:27:52 dansmith I know, looking at this, I swear I've never seen it before, but I'm pretty sure I +2d it not long ago
16:28:31 mriedem ha yeah same here
16:28:54 mriedem https://review.openstack.org/#/c/487589/
16:29:01 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
16:30:58 mriedem dansmith: melwitt: skip the cells v2 meeting yeah?
16:31:55 dansmith oh heh, I meant to say I have a conflict today anyway
16:31:56 dansmith so yeah
16:39:32 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
16:42:31 openstack Launchpad bug 1708205 in OpenStack Compute (nova) "placement allocation representation asymetric on PUT and GET" [Low,Confirmed]
16:42:31 cdent dansmith: in honor of your pain, I created a bug, which we can decided to care about or not: https://bugs.launchpad.net/nova/+bug/1708205
16:42:40 dansmith oh I care
16:42:42 dansmith I care bigly
16:42:50 cdent tremendous
16:47:03 mriedem ok got the patch
16:47:08 mriedem pushing soon
16:47:10 mriedem prepare
16:50:49 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Sum allocations in the scheduler when resizing to the same host https://review.openstack.org/490085
16:50:52 mriedem dansmith: cdent: ^ it's not the prettiest, and it doesn't account for a case that we'd have shared storage
16:51:09 jangutter I've got a newbie question here regarding attaching/detaching SR-IOV ports in Nova. I presume it's not going to be "just something simple" and would need work in Queens at the very least? (ref: https://review.openstack.org/#/c/139910/ )
16:51:26 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Avoid error log on 405 response https://review.openstack.org/490021
16:52:17 dansmith ack I will build on it when I'm done with my thing
16:54:07 cdent mriedem: If were on a non-shared some host resize, there will only be one allocation, so perhaps we can avoid some of the looping, which makes my brain explore?
16:54:14 cdent s/some/same/
16:54:28 mriedem dansmith: ok, i have a todo question in the test - which is i'm not sure if we even need the compute to adjust things, e.g. if the new alloc for vcpu is smaller than the current alloc, wouldn't we just not sum those? in other words, shouldn't the new allocations when we're done be the max of the current + new?
16:54:41 jangutter Has someone taken a look at attaching/detaching SR-IOV ports recently? If not, I can try to take a stab at it.
16:54:49 mriedem jangutter: no
16:54:53 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Start using oslo_config.sphinxext https://review.openstack.org/482961
16:54:53 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Rework README to reflect new doc URLs https://review.openstack.org/480074
16:54:54 cdent mriedem: for the duration of the resize we need room for both vms, don’t we?
16:54:54 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Start using oslo_policy.sphinxext https://review.openstack.org/479358
16:54:54 openstackgerrit Stephen Finucane proposed openstack/nova master: policies: Fix Sphinx issues https://review.openstack.org/480516
16:54:55 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Rework index page per new sections https://review.openstack.org/478485
16:54:56 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Rewrite index page https://review.openstack.org/490088
16:54:56 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Remove dead files https://review.openstack.org/478470
16:55:05 dansmith mriedem: I don't think we should be that discriminating
16:55:06 mriedem cdent: even if it's on the same host?
16:55:18 dansmith cdent: his point is that vcpus are somewhat ephemeral, not a strict quantity of things that go away
16:55:23 dansmith except for pinning, but...
16:55:24 mriedem cdent: yes i tried a few ways to do this w/o the looping and stuff and it hurt my brain
16:55:37 dansmith I think the scheduler should stay out of deciding what it does and doesn't know about the hypervisor
16:55:44 mriedem if i'm resizing from 1 cpu to 2 cpu on the same host, my total allocation on that host should be 2, not 3
16:56:20 mriedem yeah it's fair to say we don't want to bake all that logic into the scheduler
16:56:33 mriedem just seems a bit wasteful
16:56:39 mriedem until you confirm and we fix thigns
16:56:41 cdent and for vmware and powervm and maybe others, the resize may not be on the same host, just the same n-cpu?
16:56:54 mriedem powervm should be fine
16:56:56 dansmith cdent: we're accounting based on node though

Earlier   Later