Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-12
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?
17:15:53 dansmith mriedem: I assume you run nova in linux land on z, so not platform
17:16:12 dansmith and maybe not even on an s390x if it's like an HMC
17:16:13 mriedem i assume this zvm driver runs on a linux host, and then calls REST APIs to some zvm hypervisor
17:16:17 dansmith yeah
17:16:24 mriedem like powervm
17:16:30 dansmith linux for sure, but might even be on x86
17:16:35 mriedem yeah totes
17:16:43 mriedem doesn't need to be linux on s390x
17:16:48 mriedem that would be dumb
17:16:59 dansmith yeah, the arch thing isn't the concern as much as it's a lib for a hypervisor I don't need
17:17:12 mriedem sure, but the point is, we are all over the board
17:17:16 dansmith brick is kinda the same-ish, although it's not as weird I think
17:17:19 dansmith yes, definitely
17:17:31 mriedem os-xenapi is also in requirements.txt
17:17:43 mriedem taskflow is also only used by powervm but in requiments.txt
17:17:52 dansmith I think that for people who get government audits for every line of installed code, it'd be a harder sell than os-brick being there but not used
17:17:55 dansmith but just a guess
17:18:10 mriedem you know what i miss? COOs
17:18:18 dansmith I'd be happy using this as an opportunity to get right with the loahd on here
17:18:25 dansmith mriedem: really? that's funny, I don't miss them at all

Earlier   Later