Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-28
16:00:57 s-dean probably a config error again
16:00:59 mriedem may i suggest using a deployment tool
16:01:17 s-dean yeah but which oone
16:01:17 mriedem like openstack-ansible or kolla
16:01:24 mriedem ^ are the ones i'd look at
16:01:25 s-dean i was looking into kolla
16:01:39 s-dean deploys it onto docker right
16:02:21 mriedem yeah
16:02:29 mriedem openstack-ansible deploys into lxc containers
16:02:39 leakypipes builds openstack as docker images is what you mean, but yeah.
16:03:01 s-dean ive just spent so much time learning how to deploy to bare metal
16:03:10 s-dean 3 node setup
16:03:26 s-dean i dont even now how all that stuff ties into my backend network
16:04:10 s-dean i wanted to deploy a self service network with overlay network provider and management hence why ive been doing it by hand
16:05:06 s-dean been one heck of a learning experience i'm glad its the weekend though hahaha
16:10:00 openstackgerrit Jay Pipes proposed openstack/nova master: remove source provider allocs in confirm_resize() https://review.openstack.org/488510
16:11:51 leakypipes mriedem, superdan, bauwser, cdent, figleaf: ^^
16:12:25 leakypipes that didn't mock everything out..
16:12:26 mriedem leakypipes: we do-ish
16:12:39 leakypipes mriedem: see my qualifying statement above :)
16:12:53 mriedem like what?
16:13:08 mriedem we mock out cinder/glance/neutron yeah
16:13:14 mriedem but we don't really need those for testing this
16:13:34 mriedem e.g https://review.openstack.org/#/c/487958/
16:15:09 openstackgerrit Merged openstack/nova master: libvirt: Post-migration, set cache value for Cinder volume(s) https://review.openstack.org/485752
16:15:24 leakypipes mriedem: yeah, that's a good start. thanks for the link.
16:16:09 leakypipes mriedem: still no way to test the kinds of timing issues that superdan was bringing up on the call yesterday though... emulating a long MQ interaction on the destination for instance and ensuring that the source host does the right thing...
16:16:19 leakypipes anyway, I'm just bitching. it's Friday, deal with it :P
16:16:32 mriedem leakypipes: you're about as sassy as that gd sax
16:17:31 melwitt *sniff* my precious blueprint
16:17:50 mriedem sorry
16:18:32 melwitt s'okay :)
16:18:50 mriedem tell your bp to have a kick grass summer and you'll see it in the fall
16:18:59 mriedem in it's yearbook of course
16:19:10 melwitt haha
16:19:14 mriedem ps bobby flynn is soooo cute!
16:19:35 melwitt "Stay cool!"
16:27:31 leakypipes mriedem: grr, shitbuckets.
16:27:39 leakypipes mriedem: we forgot about resize to same host. :(
16:27:41 mriedem literally?
16:28:06 leakypipes mriedem: so when doing a resize same host, we'll end up deleting the entire allocation except for the shared providers in the patch I just put up.
16:28:29 cdent yeehaw
16:28:41 mriedem just check instance.host == CONF.host?
16:29:12 leakypipes mriedem: yeah. though... in the thing we added for scheduler claiming a double-up allocation, did we account for resize to same host? :(
16:29:49 mriedem yes
16:29:53 mriedem it comares the rp uuid right?
16:29:56 mriedem does a set difference
16:30:15 mriedem pretty sure i thought about that when reviewing and came to the conclusion it's handled by the set difference on rp uuid
16:30:28 cdent yeah, but isn’t the point that you still need a doubling and since the rp uuid is the same, you need to double within the allocation, not adjacent to
16:30:38 mriedem no
16:30:39 leakypipes mriedem: yeah, but the issue is that we need to create an allocation for the *same provider* but the resource amounts are added together (old and new amount)
16:30:44 mriedem the double is for the source and target
16:30:49 superdan yes
16:30:51 mriedem so you don't lose the source when putting allocations for the target
16:30:53 superdan but if resize to same host, you still have two copies
16:30:59 superdan so you need twice the allocation
16:31:06 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/488034
16:31:26 mriedem i guess you do need to account for the resize up flavor resource class stuff
16:31:26 leakypipes superdan: well, not twice the allocation, but the new amount of resources added to the old amount of resources, but on the same resource provider. :(
16:31:46 leakypipes I hate my life.
16:31:47 superdan leakypipes: yes, I mean the sum of the allocations of course :)
16:31:48 mriedem so is it just that we aren't doing the correct 'new' flavor allocation when resize to same host?
16:31:56 superdan leakypipes: I've been using "doubled up" to mean "the sum"
16:31:56 mriedem is it sum?
16:32:04 mriedem for resize to same host i mean
16:32:10 leakypipes superdan: understood.
16:32:23 superdan it's definitely sum for disk, but I don't think we should distinguish, we should just sum everything
16:32:28 mriedem ok
16:32:30 leakypipes mriedem: yeah, it's sum
16:32:33 mriedem so let's open a bug?
16:32:42 mriedem tag it with pike-rc-potential
16:32:48 superdan if you're resizing to a new flavor with more disk, but fewer cpu/mem, you have to protect the older larger amount of resource
16:32:57 mriedem superdan: good point
16:33:44 cdent leakypipes: on the resourcce tracker side, when the resize confirm wants to delete everything on itself, would it be safe/okay to let that happen, and then immediately call into the _update routines so it would then write a new allocation for the correct size?
16:33:50 leakypipes ffs, we're just going to end up porting all the craziness and conditionals from the resource_tracker.py module into the scheduler report client for this stuff :(
16:34:49 leakypipes cdent: might be, yes... need to think through it.
16:35:06 mriedem cdent: _update only updates inventory
16:35:22 mriedem if you're talking about ResourceTracker._update
16:35:25 mriedem maybe we should rename that :)
16:35:27 cdent I don’t mean _update specifically say _update_* perhaps
16:35:31 mriedem heh
16:35:36 cdent wherever the regular allocations happens
16:35:50 mriedem _update_something_for_instance_maybe
16:36:06 cdent anyway, there’s another wrinkle near this that I wanted to ask about: are those regular allocation update shared providers aware yet?
16:36:25 mriedem don't think so
16:36:44 figleaf cdent: no, but they won't delete the shared provider allocation, right?
16:36:54 mriedem https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L919
16:37:12 mriedem https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L1024
16:38:05 cdent figleaf: if we write any allocation at all, it will replace. so it depends on what we’re creating, to write
16:38:12 figleaf leakypipes: sorry, but the nuns beat that stuff into me
16:38:21 leakypipes mriedem: right, and the idea was to not have to call put_allocations() once the placement-claims stuff was done.
16:38:33 cdent I’m thinking in terms of these vaunted “heals” we love. Is a heal going to be correct in the face of a shared provider
16:38:43 figleaf cdent: OIC what you're getting at
16:39:24 figleaf cdent: yeah, that would only work if allocations were consumer/rp specific
16:39:42 mriedem leakypipes: yeah, and my original understanding from 4+ months ago was we'd put code into the computes that wouldn't do anything with allocations if they were already created by the scheduler, and we'd not do claims in the scheduler until all computes had that code
16:39:48 mriedem but then that went away
16:41:06 superdan mriedem: that code _is_ in the computes though
16:41:28 superdan well, part of it
16:41:32 mriedem superdan: the diff thing in the report client you mean right?
16:41:40 mriedem my_allocations vs current_allocations

Earlier   Later