Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-08-04
19:16:59 mriedem fried_rice: i don't think there is justification for getting that in after FF and before RC1
19:17:21 fried_rice mriedem Certainly. That's basically what's happening. The outstanding change set just does glance & ironic. The other services can be added one at a time, or whatever.
19:18:00 fried_rice mriedem Anyway, I'll just keep plugging away at the changes, and let y'all decide whether/when to push 'em.
19:18:32 mriedem superdan: another thing i thought of which complicates the shared storage trampling in the heal task, but if we're doing a move and there are allocations for the instance against 3 providers, like CN1 provides ram/cpu and gets DISK_GB from a shared storage provider (which is provider #2), and then the dest compute provider provides ram/cpu/disk (local disk)
19:18:36 mriedem things get wonky
19:18:53 mriedem because during a move, there is nothing preventing the scheduler from picking a compute node that is sharing storage with the source node
19:18:59 mriedem so it could pike a node with locak disk
19:19:02 mriedem *pick
19:19:10 superdan well,
19:19:24 superdan if there is not request in the reqspec that prevents that, then I would say that's fine
19:19:44 superdan but you'd have to have block migration for that, which I think is automatic now,right?
19:19:47 mriedem right i think it's fine from a scheduler pov
19:20:13 superdan could be a thing with a hypervisor needing shared storage all te time for a migration though, if that's what you mean
19:20:30 mriedem we don't consult block vs shared migration in the scheduler to determine which compute nodes to use based on if they have a shared storage provider aggregate
19:20:46 mriedem i was just thinking resize/cold migrate
19:20:59 mriedem could move the instance from a source node using shared storage to a dest node using locak disk
19:21:01 mriedem *local
19:21:06 mriedem which i think is ok
19:21:13 superdan yeah'
19:21:27 mriedem it's just that things in the report client trying to sort this mess out is going to be...messy
19:21:54 fried_rice edmondsw_ Looking at https://review.openstack.org/#/c/485121 - I think the answer is yes. Stay tuned.
19:22:32 edmondsw_ fried_rice tx
19:22:33 superdan well, as leakypipes has said, we probably need to be providing more info the scheduler in those situations to account for some of this
19:22:36 superdan but yteah
19:33:18 fried_rice edmondsw_ Checkacheckacheck it out.
19:34:50 cfriesen superdan: mriedem: I think that if the end-user hasn't explicitly requested shared storage than doing a block migration to/from a compute with local storage is fine
19:35:12 cfriesen so I'm not sure the scheduler needs to care about the storage the instance is currently on
19:35:36 cfriesen unless the hypervisor physically can't handle that case
19:38:19 edmondsw_ fried_rice ty sir
19:46:04 cfriesen do we even have a way to say "I want to be on a hypervisor with shared storage for instance "localdisk"?
19:46:42 cfriesen almost seems like that would be a host-aggregate thing
19:57:07 sean-k-mooney cfriesen: are you assuming that if the tenant wants there instance to be backed by shared storage then they would request the instance to be backed by a cinder volume
19:59:00 superdan leakypipes: you're going to look at my split of your patch right?
20:11:31 cfriesen sean-k-mooney: either that or they would specify a flavor that the admin has set up to map to a host aggregate that has shared storage.
20:12:32 cfriesen I can't think of any other way to request shared-storage in a mixed shared/local cloud
20:13:01 sean-k-mooney cfriesen: the issue with that is its not programatically discoverable unless we used traits to model that
20:14:14 cfriesen sean-k-mooney: right. so we don't currently support the scenario where we happen to schedule on a hypervisor with shared storage that doesn't support block-migrating to non-shared storage. (are there such hypervisors?)
20:15:20 sean-k-mooney cfriesen: does that work for ceph to non ceph today?
20:15:53 cfriesen sean-k-mooney: I think it'd be a question of whether qemu supports it
20:16:02 sean-k-mooney cfriesen: you can configure nova to always use ceph on one node without the tenant requesting it but not sure if you can do a block migration to another host
20:16:34 openstackgerrit Dan Smith proposed openstack/nova master: Resource tracker compatibility with Ocata and Pike https://review.openstack.org/491012
20:17:04 cfriesen sean-k-mooney: yeah, I don't know if it works or not
20:17:09 sean-k-mooney cfriesen: well even if qemu could i dont think anything would endup deleteing the ceph voluome in that case unless maybe libvirt would?
20:17:19 openstackgerrit Merged openstack/nova master: Fix getting instance bdms in multiple cells https://review.openstack.org/490340
20:18:10 cfriesen sean-k-mooney: no clue. I'd hope it'd be covered by the normal post-live-migration cleanup on the source side.
20:18:21 sean-k-mooney it proably is not a good idea to mix nova with default ceph stoage and nova with default local in the same availablity zone in anycase
20:19:40 cfriesen certainly that'd be the simplest option....."don't do that"
20:21:41 sean-k-mooney well if you want to keep your openstack sysadmins sane mixing default storage configs in the same availablity zone is certenly not the way to go
20:43:36 openstackgerrit Eric Fried proposed openstack/nova master: nova.utils.get_ksa_adapter() https://review.openstack.org/488137
20:47:31 leakypipes superdan: just back from doctor... have you pushed the split yet?
20:47:57 superdan leakypipes: yeah dude.. but I just realized there's still a functional failure in the middle, so fixing that up,
20:48:15 leakypipes superdan: gotcha. just ping me when ready.
20:48:27 superdan leakypipes: you could still look, it's just a minor thing
20:48:32 leakypipes ah, k
20:48:39 leakypipes looking now
20:48:41 superdan leakypipes: just to see if you're okay with it or I missed something major
20:48:47 leakypipes k
20:53:42 superdan ah just a thing we can't assert reliably in your patch, so I'm commenting that and then the following one will assert it always
20:53:51 superdan fix coming in a sec
20:55:15 openstackgerrit Dan Smith proposed openstack/nova master: remove provider allocs in confirm/revert resize https://review.openstack.org/488510
20:55:16 openstackgerrit Dan Smith proposed openstack/nova master: Resource tracker compatibility with Ocata and Pike https://review.openstack.org/491012
20:56:34 leakypipes superdan: see my comment on previous patch about the min service version mock that will want to move to the ocata computes patch...
20:56:49 superdan okay
20:56:57 superdan I did this super mechanically so not surprised to miss something like that
20:57:19 leakypipes superdan: ya, no worries. I annotated what needs to move to the next patch.
20:57:28 leakypipes superdan: other than that, looks like a good split.
20:58:38 leakypipes superdan: maybe add me as co-author on that ocata patch, too? :)
20:58:45 superdan oh sure
20:58:54 superdan sorry
20:58:59 leakypipes no worries :)
20:59:12 leakypipes these patches have been through the proverbial ringer.
21:02:31 openstackgerrit Dan Smith proposed openstack/nova master: remove provider allocs in confirm/revert resize https://review.openstack.org/488510
21:02:32 openstackgerrit Dan Smith proposed openstack/nova master: Resource tracker compatibility with Ocata and Pike https://review.openstack.org/491012
21:10:49 mriedem i'm about to dump a pile on you two also
21:11:13 mriedem no pair programming over here for this shared storage mess
21:11:35 mriedem i'm about to give up and go see how pied piper is doing
21:17:25 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add functional resize tests using shared storage https://review.openstack.org/490733
21:17:25 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Account for shared storage in the report client https://review.openstack.org/491098
21:17:28 mriedem superdan: leakypipes: ^ gets all sorts of gross and several unhandled cases
21:17:31 mriedem during a move
21:25:41 leakypipes superdan: ++ from me on those split patches.
21:26:18 leakypipes mriedem: ok, will look at those later this evening. thanks for the heads up.
21:36:16 mriedem oh i see where i was confused by something in the tests - when we 'double stuff' in the scheduler during the move claim, we keep the source and dest compute node allocations along with the shared storage provider allocation, but we don't sum the shared storage allocation, like we would if we resized to the same host
21:36:36 mriedem noticed that from this test
21:36:37 mriedem https://review.openstack.org/#/c/490085/7/nova/tests/unit/scheduler/client/test_report.py@361
21:37:20 mriedem superdan: when we were talking about handling resize to same host the other day for https://review.openstack.org/#/c/490085/ didn't we say we thought that we should sum the disk even if it's shared?
21:38:09 mriedem you can see that sum for disk happen on the same host in test_claim_resources_success_resize_to_same_host_with_shared
21:38:26 mriedem but we don't sum disk if it's on different hosts, from test_claim_resources_success_move_operation_with_shared
21:56:51 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Get auth from context for glance endpoint https://review.openstack.org/490057
22:11:31 openstackgerrit Eric Fried proposed openstack/nova master: Get auth from context for glance endpoint https://review.openstack.org/490057
22:14:52 fried_rice mordred ^^ I *think* will pass tox now, and I *think* will pass sdague's https://review.openstack.org/490031
22:31:22 superdan mriedem: not sure what you mean.. we don't sum anything for different hosts
22:31:31 superdan mriedem: you saying we don't claim against the shared storage again?
#openstack-nova - 2017-08-05
00:17:01 mriedem dansmith: yes if we're moving from source host A to dest host B and they are sharing storage on provider C, we don't sum the disk_gb allocation between the flavors for the move
00:17:22 mriedem apparently intentionally but i'm not sure why now
05:07:53 openstackgerrit Jackie Truong proposed openstack/nova master: Add trusted_certs to instance_extra https://review.openstack.org/457711
06:40:35 openstackgerrit Michael Still proposed openstack/nova master: Avoid chowning console logs in libvirt https://review.openstack.org/472229
06:40:36 openstackgerrit Michael Still proposed openstack/nova master: First attempt at adding a privsep user to nova itself. https://review.openstack.org/459166
06:40:36 openstackgerrit Michael Still proposed openstack/nova master: Move execs of touch to privsep. https://review.openstack.org/489190
06:40:37 openstackgerrit Michael Still proposed openstack/nova master: Move libvirts dmcrypt support to privsep. https://review.openstack.org/490737

Earlier   Later