Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-05-03
21:32:49 lbragstad johnthetubaguy https://opendev.org/openstack/oslo.policy/src/branch/master/oslo_policy/policy.py#L633
22:05:33 openstackgerrit Matt Riedemann proposed openstack/nova master: Add InstanceList.get_uuids_by_host_and_node https://review.opendev.org/657070
22:06:28 openstackgerrit Matt Riedemann proposed openstack/nova master: Optimize SchedulerReportClient.delete_resource_provider https://review.opendev.org/657070
22:11:49 openstackgerrit Merged openstack/nova master: Include all network devices in nova diagnostics https://review.opendev.org/648123
22:11:56 openstackgerrit Merged openstack/nova master: Add ids to sections of flavors guide to allow deep-linking https://review.opendev.org/653458
22:15:31 efried mriedem: where you at? Compute capabilities as traits in 207
22:18:23 mriedem right next to you
22:26:57 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Make nova-tox-functional-py36 reusable https://review.opendev.org/657074
22:31:20 openstackgerrit Dan Smith proposed openstack/nova master: Add a workaround config toggle to refuse ceph image upload https://review.opendev.org/657078
22:35:50 openstackgerrit Balazs Gibizer proposed openstack/nova master: Log when port resource is leaked during port delete https://review.opendev.org/657079
22:54:50 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/scheduler/filters/affinity_filter.py#L108-L111
22:55:39 gmann johnthetubaguy: melwitt this is how currently or in past, we handle the deprecated policy check -L47 https://etherpad.openstack.org/p/ptg-train-xproj-nova-keystone
22:56:28 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Rework the PCI passthrough guides https://review.opendev.org/635243
22:57:50 melwitt gmann: thanks
23:20:03 openstackgerrit Chris Dent proposed openstack/nova master: Make nova-tox-functional-py36 reusable https://review.opendev.org/657074
#openstack-nova - 2019-05-04
02:22:16 openstackgerrit Merged openstack/nova master: libvirt: Always disconnect volumes after libvirtError exceptions https://review.opendev.org/655712
03:05:43 openstackgerrit Merged openstack/nova master: Add nova-status upgrade check for minimum required cinder API version https://review.opendev.org/649759
09:16:43 openstackgerrit Merged openstack/nova master: Delete the placement code https://review.opendev.org/618215
12:14:59 lyarwood \o/
12:23:25 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: libvirt: Always disconnect volumes after libvirtError exceptions https://review.opendev.org/657109
12:23:55 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: libvirt: Always disconnect volumes after libvirtError exceptions https://review.opendev.org/657110
12:24:32 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: libvirt: Always disconnect volumes after libvirtError exceptions https://review.opendev.org/657111
12:58:33 openstackgerrit sean mooney proposed openstack/nova master: Libvirt: add nfv job https://review.opendev.org/652197
13:21:18 openstackgerrit sean mooney proposed openstack/nova master: Libvirt: add nfv job https://review.opendev.org/652197
13:39:25 openstackgerrit Matt Riedemann proposed openstack/nova master: Enable cross-cell resize in the nova-multi-cell job https://review.opendev.org/656656
14:58:25 mriedem rm_work: do you happen to know if oath needed to disable versioned notifications because of load on the MQ?
15:02:57 rm_work mriedem: Not positive but I can track down an answer for you easily enough ;)
15:07:18 efried cfriesen: I put a comment on the TPM patch, if you could take a look please. Unless I'm way off, may require a slight design change...
15:07:21 mriedem thanks, wasn't sure who to ask
15:08:28 cfriesen efried: will take a look, thanks
15:16:30 lyarwood stephenfin: https://review.rdoproject.org/r/#/c/16234/ - now that placement has gone.
15:18:03 lyarwood stephenfin: cheers
15:18:06 stephenfin lyarwood: Done
15:18:50 efried http://paste.openstack.org/raw/750586/ \o/
15:20:55 openstackgerrit Merged openstack/nova stable/stein: libvirt: Stop ignoring unknown libvirtError exceptions during volume attach https://review.opendev.org/657049
15:24:09 stephenfin efried: Only three patches standing between us and https://review.opendev.org/#/c/651306/8 too :)
15:24:22 stephenfin Also, CI /o\
15:24:49 cdent efried and or mriedem : if you could register an opinion on whether I should do the same changes to all the functional jobs as https://review.opendev.org/#/c/657074/ that would be keen. No rush, simply that it is in flight.
15:25:14 efried stephenfin: yeah, I need to get back to that series (and a zillion others)
15:25:34 cdent moar delegation
15:25:44 stephenfin ack. It'll be back in a runway in a few weeks too
15:25:47 efried stephenfin: We've also got mox, privsep, and fake-libvirt cleanups which ought to be pretty much ready to go.
15:26:35 stephenfin efried: Aye, though privsep is blocked by some comments from you that mikal hasn't address yet. I've been tackling the libvirt version enum cleanup ones from mriedem/kashyap already
15:27:02 efried oh, is that where I left privsep? cool
15:27:03 efried :)
15:27:34 efried looks like there are two I could push
15:30:02 cfriesen efried: is the TPM version actually an issue? given that it's emulated, all hosts can provide both TPM versions. if the guest doesn't care, they can just ask for version 1.2
15:35:29 openstackgerrit Merged openstack/nova stable/stein: libvirt: Avoid using os-brick encryptors when device_path isn't provided https://review.opendev.org/656462
15:40:40 rm_work mriedem: seems that we just never enabled notifications to begin with? ¯\_(ツ)_/¯
15:40:52 rm_work where can I go look in our deployment tooling/config to see? :D
15:41:02 rm_work what config option is it?
15:41:35 mriedem rm_work: https://docs.openstack.org/nova/latest/configuration/config.html#notifications
15:41:46 mriedem https://docs.openstack.org/nova/latest/configuration/config.html#notifications.notification_format specifically is what i'm looking for
15:42:10 efried cfriesen: Well, that's what I was asking you, I guess.
15:42:18 mriedem also this https://docs.openstack.org/nova/latest/configuration/config.html#oslo-messaging-notifications
15:42:40 efried cfriesen: Is it not the case that 2.0 is only available (emulatable) at certain versions of... things (qemu, libvirt, ...)?
15:43:25 mriedem rm_work: notifications are enabled by default so maybe you're just generating them but not consuming them. to disable them, [oslo_messaging_notifications]/driver=noop
15:43:50 efried cfriesen: Basically: is the model the thing the user primarily cares about, or is the version?
15:44:11 rm_work ok, yeah i think that's likely
15:44:56 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: Include all network devices in nova diagnostics https://review.opendev.org/657125
15:46:02 cfriesen efried: the version of libvirt that introduced TPM support adds support for both, and the TPM emulator supports both, so they should always be available. I want to double-check with sean-k-mooney and kashyap but I think the initial concern would be the version as the two versions are quite different.
15:48:45 efried cfriesen: Oh, so the implementation (which I haven't gotten to yet, sorry) is using the version trait to effect the proper emulated version?
15:48:58 efried I guess if both versions are available, it would have to.
15:50:22 cfriesen efried: yeah, the virt driver uses the version trait when generating the libvirt XML
15:51:58 efried cfriesen: Okay. This was probably already discussed during design and I'm just late to the party. If hosts are advertising both versions, and users care about the version (are in fact locked to just one) then the current design is fine.
15:52:17 mriedem smcginnis: can you stop in the nova room to talk about openlab for 5 minutes?
15:52:34 smcginnis mriedem: Sure. Right now?
15:52:39 mriedem if possible yeah
15:52:40 mriedem 207
15:52:42 smcginnis OMW
15:53:36 rm_work mriedem: seems we leave the default
15:53:45 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove macs kwarg from allocate_for_instance https://review.opendev.org/652749
15:53:45 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove ComputeDriver.macs_for_instance method https://review.opendev.org/652737
15:54:17 mriedem rm_work: ok thanks
15:55:17 mriedem sean-k-mooney: fyi several things are marked as experimental here https://docs.openstack.org/nova/latest/user/feature-classification.html#nfv-cloud-features
15:55:25 mriedem https://docs.openstack.org/nova/latest/user/feature-classification.html#matrix-hpc
15:55:59 mriedem https://docs.openstack.org/nova/latest/admin/huge-pages.html doesn't mention anything about being experimental or not tested
15:59:18 cfriesen efried: A guest could have support for both versions, but unless they're specifically wanting 2.0 functionality then 1.2 should be fine. You raised another issue though, moving operators away from speaking placement-ese in flavors/images. Was that still an issue? This was loosely modelled after the CPU features traits which are explicitly placement-ese.
16:02:06 efried cfriesen: It's not crucial to me that there be zero placement-ese in flavors. For simple things like this (requiring a single trait) it's fine, and is why we enabled support for it. It's complex placement-ese I want to avoid, instead having nova translate more operator-ese thingies to placement-ese.
16:03:57 cfriesen efried: makes sense. I'll reply to your review comment with a summary for others who look at it.
16:04:30 efried cfriesen: Thank you sir.
16:05:41 efried cfriesen: Wait, "A guest could have support for both versions, but unless they're specifically wanting 2.0 functionality then 1.2 should be fine." <== so it's possible I only care about "give me TIS"?
16:06:25 efried If that's the case, I'd still be in favor of making the trait optional (and set up by the request filter)
16:06:32 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP/DNM objects: Remove get_by_volume_id from BlockDeviceMapping https://review.opendev.org/657127
16:07:14 cfriesen efried: I think the guest support is different for TIS-on-1.2 vs TIS-on-2.0, but let me confirm with sean/kashyap
16:08:01 efried cfriesen: Okay. None of this should be a huge delta in the impl/spec IIUC. If it turns out to be, I can live with it as is.
16:08:04 kashyap cfriesen: Hi, what exactly you want to double-check? You said "support for both" up-thread -- what are you referring to?
16:08:31 efried kashyap: We're talking about the use cases for TPM. What is it that the operator cares about?
16:08:47 efried kashyap: Is "Give me TIS, I don't care if it's 1.2 or 2.0" a possibility?
16:09:25 cfriesen or do they care primarily about 1.2 vs 2.0, and then crb/tis if they're on 2.0
16:09:51 kashyap efried: I don't know the answer to your second question -- need to go do some QEMU sluething for it
16:09:51 cfriesen (the spec was written assuming the second)
16:11:11 kashyap efried: The use cases for TPM, my limited understanding is that: they are a "big deal" recently:
16:11:18 kashyap efried: The idea is that you have a tiny co-processor that can do crypto, but with company-specified policies.
16:12:03 cfriesen kashyap: we can talk to sean-k-mooney, he doesn't seem to be paying attention to IRC. :)
16:13:41 efried he's paying attention to the room, like I should be :P
16:13:47 kashyap efried: The use cases are disk encryption — e.g. MS's BitLocker, and "Clevis" (https://github.com/latchset/clevis), TLS key storage (openssl-engine-tpm), etc.
16:14:25 kashyap efried: But I agree: there should be some clear write-up about "use cases from an OpenStack operator PoV"
16:15:09 efried kashyap: That would be nice, but I don't want to go crazy here, or block the work pending said writeup.
16:15:33 efried kashyap: Really the only thing I care about is whether there exists a use case where the VM doesn't care which version it gets.

Earlier   Later