Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-12
15:54:10 bauzas edleafe: in that case, it would mean some new query param for Placement
15:54:21 bauzas thoughts ?
15:55:05 gameon cfriesen: Nehalem works :)
15:56:27 efried edleafe: The way the doc is written, it *is* guaranteeing that the format won't change (without a new microversion).
15:56:53 efried which is as it should be.
15:57:10 edleafe efried: about to run off to a meeting
15:57:17 efried I've never understood the reasoning behind that payload needing to be opaque, btw.
15:57:50 edleafe efried: all it was supposed to be was something you could send back to allocate/claim
15:57:53 cfriesen bauzas: it seems to me that we have two options. give the filters access to the allocation candidates so they can rule out ones they don't like, or have enough flexibility in placement that we can ensure we never get back invalid candidates.
15:58:03 edleafe it could have been a hash, or a uuid, or...
15:58:22 efried edleafe: And you're supposed to pick one based on... what?
15:58:32 cfriesen edleafe: for that to work we need enough flexibility in what we can request from placement to ensure that all the candidates are valid
15:58:33 edleafe now we have nested, which brings in multiple a-cs per rp
15:58:35 melwitt efried: when you get a chance, wanna write some notes on how the update-provider-tree runway review went at L118? https://etherpad.openstack.org/p/nova-runways-rocky
15:58:47 efried melwitt: ack
15:58:51 edleafe efried: you picked a host, and found the matching a-c
15:59:08 efried edleafe: There were several a-cs for that host.
15:59:13 efried edleafe: How did I pick one?
15:59:19 edleafe now there isn't a 1:1 host:a-c relationship with nesting
15:59:22 cfriesen efried: if they were all actually valid it wouldn't matter
15:59:37 efried cfriesen: Yup, that's the big IF.
16:00:05 efried cfriesen: For this use case, we either implement new logic in placement, or they're *not* all valid and we can't just pick one at random.
16:00:14 cfriesen efried: yes, agreed
16:00:43 efried edleafe: There was never a 1:1 host:a-c relationship.
16:05:01 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Don't persist RequestSpec.retry https://review.openstack.org/560955
16:06:24 bauzas efried: just for the context, they're not all valid because of some specific implementation details of the filter that I don't particularly like
16:06:53 efried melwitt: done
16:06:58 bauzas adding more debt to either placement or the filters looks terrible to me
16:07:06 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Don't persist RequestSpec.retry https://review.openstack.org/560167
16:07:18 melwitt efried: thanks
16:07:45 bauzas efried: from a placement perspective, we can ask for a query that would *shard* resources between children, but that's the only trade-off I'd make
16:08:18 bauzas efried: if we implement such thing, then we wouldn't need to pass the candidates down to the filters
16:08:22 efried bauzas: It's starting to sound like that might be the "easier" option
16:08:37 bauzas not the easier
16:08:43 efried bauzas: And as I've said, we know we're going to want that logic in placement eventually regardless.
16:08:46 bauzas the less debtful
16:08:49 efried bauzas: So this might as well be the motivation.
16:08:51 efried Yeah
16:09:19 bauzas ok, I'll amend my spec accordingly
16:09:27 edleafe efried: sorry, in the API-SIG meeting
16:09:30 edleafe efried: https://github.com/openstack/nova/blob/master/nova/scheduler/manager.py#L154-L160
16:09:49 edleafe That creates one a-c per rp
16:10:00 melwitt cdent: the placement-forbidden-traits blueprint has been added to a review runway. please ack if the next two weeks work for you for quick iteration on review
16:10:25 edleafe we always just grab the first one of that list
16:11:13 cdent melwitt: thanks, it does
16:11:24 melwitt k, great
16:11:28 efried edleafe: It creates a *list* of allocation requests per rp_uuid
16:11:44 efried edleafe: ...by introspecting the payload, by the way :P
16:13:41 openstack Launchpad bug 1739593 in OpenStack Security Advisory "Swapping encrypted volumes can lead to data loss and a possible compute host DOS attack (CVE-2017-18191)" [Undecided,Incomplete]
16:13:41 mriedem lyarwood: for https://review.openstack.org/#/c/543569/ - do we want a security reno for https://bugs.launchpad.net/nova/+bug/1739593 and CVE-2017-18191?
16:13:45 mriedem i see the ossa isn't published
16:14:07 melwitt jichen: the z/VM driver series has been added to a review runway. I know you have been active on the patches already but please let us know if there are any problems with the next two weeks for quick iteration on review
16:14:16 edleafe efried: this is the part that I was referring to: https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L212-L217
16:14:25 edleafe "information in the provider summaries"
16:17:36 efried edleafe: Yeah, I get that we can do *some* weighing/filtering based on the provider summaries; but that still only gets us down to the list of allocation requests for a given host. It doesn't help us pick among those.
16:20:45 mriedem lyarwood: sounds like the ossa is blocked until the stable/ocata patch is up
16:20:54 mriedem i'm +1 on the stable/pike change now if you want to start on the stable/ocata backport
16:27:02 openstackgerrit Brianna Poulos proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949
16:28:25 cfriesen mriedem: lyarwood: I've got https://review.openstack.org/#/c/560690/ up for the stable/pike backport, but there's a complication in that Pike treats the encryption stuff a bit differently. Wondering how you want to handle it. I wrote it up in the review.
16:29:04 mriedem cfriesen: heh, see https://review.openstack.org/#/c/543569/
16:32:13 mriedem cfriesen: comments inline
16:32:46 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
16:34:42 mriedem cfriesen: oh yeah reading https://review.openstack.org/#/c/460243/ i see the problem kind of,
16:34:51 mriedem that was really a frankenstein of a patch, and should have been split up
16:36:02 mriedem https://review.openstack.org/#/c/460243/16/nova/virt/libvirt/driver.py@1453 specifically
16:36:15 mriedem if that's its own bug, we'd have to backport separately before your change, but would need to talk to lyarwood
16:36:47 mriedem i don't know if that applies before the changes to _disconnect_volume though
16:36:53 mriedem if not, don't worry about it
16:38:43 cfriesen mriedem: If we wanted to backport "proper" handling of encrypted volumes in the error case it could be done in a separate patch, I don't think the ordering really matters. For now I'll rework the backport to go off the stable/queens one.
16:39:21 mriedem i think the encrypted volume stuff only needed to change because of the behavior change in _disconnect_volume for luks native encryption
16:39:24 mriedem which we're not going to backport
16:41:45 cfriesen mriedem: well...with my fix if we hit exception.DeviceNotFound we'll continue on without every calling encryptor.detach_volume()
16:44:01 cfriesen mriedem: so I was wondering if we should move the call to ncryptor.detach_volume() down right above the call to self._disconnect_volume(), but I didn't know enough about that code to know if that was okay.
16:44:27 cfriesen it *seems* analogous to what happens in the newer code, but I could be missing something
16:45:10 mriedem i defer to lyarwood
16:50:01 openstackgerrit Chris Friesen proposed openstack/nova stable/pike: libvirt: disconnect volume from host during detach https://review.openstack.org/560690
16:50:18 melwitt cfriesen: see the earlier version of the patch from before the encryption-related refactor https://review.openstack.org/#/c/515008/9/nova/virt/libvirt/driver.py
16:53:31 efried melwitt: Care to have a look at https://review.openstack.org/#/c/553475/ ? Then we can put update_provider_tree to bed.
16:53:46 efried melwitt: Should be an easy on.
16:53:48 efried one
16:54:36 melwitt sure
16:55:23 cfriesen melwitt: perfect, that's exactly what I was thinking about doing
17:08:38 efried mikal: What's your feel on deferring the requirements issue out of the zvm driver series?
17:09:09 openstackgerrit Jay Pipes proposed openstack/nova-specs master: Numbered request groups use different providers https://review.openstack.org/560974
17:10:14 mriedem efried: like we did in the powervm series? :)
17:10:45 efried mriedem: Sure. I.e. nobody cared enough to pursue it, so it dropped. That's as it should be, if nobody cares enough to pursue it.
17:11:01 mriedem i was also going to mention in that ML thread, btw, that if we did get pedantic about requirements, os-brick would also fall into that camp since only the libvirt and hyperv driver use it
17:11:38 efried mriedem: The ML thread is making it clearer with every note that this is a bigger issue than we can/should expect to solve in the zvm driver series.
17:13:10 openstackgerrit Chris Friesen proposed openstack/nova stable/pike: libvirt: disconnect volume from host during detach https://review.openstack.org/560690
17:13:22 openstackgerrit Jay Pipes proposed openstack/nova-specs master: Standardize CPU resource tracking https://review.openstack.org/555081
17:13:53 mriedem i haven't read the latest
17:14:16 mriedem i know what we'll do,
17:14:18 mriedem i'll run for TC,
17:14:28 mriedem and then push through that all projects must define optional requirements in [extras]
17:14:31 mriedem as a community wide goal
17:14:38 dansmith mriedem: os-brick isn't really environment specific as much though
17:14:55 dansmith well, maybe that's not true, I guess it runs linux commands
17:15:07 mriedem dansmith: this zvm lib dep isn't conditional on arch right?
17:15:08 dansmith but, it seems less confusingly installed than my linux machine with powervm and zvm stuff both installed
17:15:35 dansmith mriedem: arch or platform?

Earlier   Later