Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-02
17:08:40 openstackgerrit sean mooney proposed openstack/nova-specs master: add libvirt pqos spec https://review.opendev.org/662264
17:08:49 sean-k-mooney lyarwood: ^ is the updated versions
17:13:52 sean-k-mooney hum looks like i need to fix the diagram
17:14:10 jroll efried: yep, hi!
17:14:21 efried jroll: Wanna talk TPM?
17:14:37 jroll efried: gimme 15, in a meeting atm
17:14:40 efried sho
17:14:43 openstackgerrit Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.opendev.org/637955
17:14:51 efried I await thy ping
17:20:19 gibi efried, mriedem: I think I'm done with the heal port allocation rework based on your comments. (except two change in a followup)
17:20:26 efried ack
17:24:13 openstackgerrit sean mooney proposed openstack/nova-specs master: add libvirt pqos spec https://review.opendev.org/662264
17:24:46 sean-k-mooney ok fixed the ascii diagram
17:28:19 openstackgerrit Merged openstack/nova master: Un-safe_connect and publicize get_providers_in_tree https://review.opendev.org/668062
17:30:56 jroll efried: am free now
17:31:02 efried o/
17:31:24 efried So what do you know about this "reboot required" business? I was able to confirm that from several sources.
17:31:44 sean-k-mooney im going to go have food so ill be away for the next hour or so. ill be back later
17:31:51 sean-k-mooney efried: reboot requried?
17:31:54 efried And are you caught up with what penick was saying about "oh, just leave it to us to manage the state of the TPM"
17:32:11 efried sean-k-mooney: talking to jroll about TPM stuff. Go do your food thing :)
17:33:09 jroll efried: I wasn't aware a hypervisor reboot was required until you were. and I think I'm caught up with penick?
17:33:21 sean-k-mooney oh im guessing after a guest has finished using a tpm and we delete teh guest the TPM is unaviaoble until after a reboot? and yep its time for breakfest/lunch/dinner brb
17:33:54 efried correct sean-k-mooney. Either unavailable, or still has the old VM's secrets in it.
17:34:46 efried jroll: So what penick is saying, IIUC, is that we should blindly pass the TPM through, and worry about the orchestration layer to know what's on it at any given time. I.e. nova doesn't do any prep or checking or clearing or ownership assigning.
17:35:15 efried That sounds like a pretty big security risk to me. Kind of doubt it's going to fly, design-wise, with the Nova maintainers.
17:35:16 dansmith how is that not a terrible idea?
17:35:21 efried yeah
17:35:34 dansmith I mean, I get that it's the minimum required effort to get what you want, but...
17:35:39 dansmith doesn't seem like a smart decision at all
17:36:27 jroll right, it seems like our use case would be long-running VMs
17:36:40 sean-k-mooney efried: that is not too unsuerpising. older gpus had the same issue. unless the uefi firmware is specificlay coded to handel it pci passthou deveice can become unusable until they are reset ususally that reuires a host reboot.
17:36:40 jroll and/or these hosts would only be accessible by this tenant
17:36:51 sean-k-mooney and now that i have my phone back to cooking
17:37:30 jroll I'm not sure I agree that we should just let nova blindly land stuff on a TPM without checking it, fwiw
17:38:35 jroll I haven't thought through what it would take to have nova track if a TPM is 'usable' or not
17:38:36 efried Right. That's Nova abdicating a pretty serious burden of responsibility to the unknown upper layer. I mean, we have trust models in place that are a certain shape and this really seems to be breaking outside of that shape.
17:38:59 efried so given that that approach is likely to be -many, unless there's some other place we can go with this, we're probably going to have to declare it dead in the water. (aka "downstream it if you really need it")
17:39:36 dansmith I'd like to see more uses for it
17:39:54 jroll I assume assigning some sort of TPM_DIRTY trait isn't going to fly, right?
17:40:06 dansmith while I feel for the situation of trying to push people to vms by providing things that look like hardware, the "single long-lived vm per host" use case doesn't hold much weight for me
17:40:46 efried jroll: If we were going to remove it from service via placement-ism, we would probably use the reserved=total trick.
17:40:54 efried rather than a trait
17:41:20 jroll dansmith: that's fair. the reason we would do this on a VM instead of bare metal is for neutron security groups, boot from volume, etc
17:41:39 efried (and btw, implied in your question and my response is: one RP per TPM)
17:41:53 dansmith but we also need to know how to clean it and I think that depending on placement as a persistence mechanism for something like this is an abuse.. it'd be too easy for an operator to just delete that allocation not knowing why it's there, only to have us hand the tpm to something else
17:42:04 jroll or rather, that's why the "single long-lived vm per host" is a somewhat valid use case for us
17:45:10 jroll efried: I guess I'm not deep enough in nova to offer suggestions on how to manage this, I'll have to dig around some and maybe come back and talk about it
17:45:37 jroll unless "tracking the state of the hyp" is 100% not going to happen for something like this
17:46:12 efried jroll: We would have to do it with an external file of some kind.
17:46:28 efried unless there's a way to know by querying the device
17:46:40 efried or sysfs or whatever
17:46:54 jroll hmm ok
17:47:31 efried but sysfs is unlikely to track instance UUID for us
17:47:34 dansmith efried: I think you mean the database
17:47:50 dansmith efried: we don't need to introduce a new persistence mechanism on the host for this as a one-off thing
17:47:52 efried dansmith: Yeah, that would work :)
17:48:18 dansmith sysfs is ephemeral, so it's definitely not going to help us here :)
17:48:36 efried there would have to be some kind of db manage command to manually clear the state
17:48:53 efried because, like, we can't assume it's clear on a reboot or a compute service startup or whatever.
17:49:02 dansmith it's specifically not supposed to be clear on reboot
17:49:25 efried it's supposed to be: purge, reboot, now it's clear so manually say it's clear.
17:49:33 dansmith and if you're suggesting that we hand out tpms to an instance, and then when that instance is deleted, we're stuck until the operator manually clears the tpm and then frees it up with a manage command,
17:49:41 dansmith that's crazypants
17:49:43 efried yup, it would have to be that.
17:49:45 efried And I agree.
17:49:52 dansmith that's implementing half a feature because some guy asked for it and is fine with the manual cleanup
17:49:57 dansmith I'm -5 on that
17:50:12 efried (my earlier estimate of -many wasn't too far off then)
17:50:25 efried yeah, the right way to do this is vTPM
17:50:45 efried but as currently implemented that's not secure because the Master Key is stored on the hypervisor's disk.
17:51:08 dansmith yeah, solving it properly is making that more reasonable I think
17:51:16 dansmith which seems quite doable
17:51:18 efried They're figuring out some way around that in qemu, but it hasn't happened yet, so this was an attempt to work around it until that's available.
17:51:30 dansmith mmhmm
17:53:43 efried So jroll, it's really looking like this isn't going to happen, upstream, in this way. If there's enough $motivation$ to make it happen downstream anyway, let me know and I can advise a bit on the nova-isms and placement-isms that would need to be hacked together.
17:54:36 jroll efried: thanks
17:56:24 efried adrianc: whoops, https://review.opendev.org/#/c/659101/ is in merge conflict now. Since you're going to need a new PS anyway, want to take care of those couple of nits?
18:09:01 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Add 'flavor-extra-spec-image-property-validation-extended' spec https://review.opendev.org/638734
18:13:53 stephenfin efried: Tackled those comments on the extra spec validation spec. Lemme know if what I want to do wrt key validation is not clearer now
18:14:16 efried ack
18:22:55 markguz_ hi all. Anyone out there got any experience with using NPIV and pci passthrough for share Fiber Channel HBAs amongst vms?
18:23:28 markguz_ i want to share the VFs but am not really clear on how it might be done.
18:23:56 markguz_ most if not all of the docs seem to focus on networking virtual functions
18:28:35 markguz_ there is a type=VF but i'm not clear how to share the vport
18:34:12 openstackgerrit Eric Fried proposed openstack/nova-specs master: Add PENDING vm state https://review.opendev.org/648687
18:38:54 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Add a rbd_connect_timeout configurable https://review.opendev.org/667421
18:52:06 openstackgerrit Eric Fried proposed openstack/nova master: [FUP] Follow-up patch for SR-IOV live migration https://review.opendev.org/659101
18:54:17 efried adrianc: ftfy ^
18:54:41 efried stephenfin: if you're still around, trivial re+A ^
19:09:15 openstackgerrit Merged openstack/nova-specs master: Add PENDING vm state https://review.opendev.org/648687
19:14:15 openstackgerrit Matt Riedemann proposed openstack/nova master: Update COMPUTE_STATUS_DISABLED from set_host_enabled compute call https://review.opendev.org/668743
19:20:28 mriedem dansmith: could use another opinion here https://review.opendev.org/#/c/668743/1/nova/compute/manager.py@5047
19:23:40 dansmith mriedem: do I need to read it or can I just give you an opinion?
19:23:59 mriedem like, cats > dogs?
19:23:59 mriedem sure
19:24:11 dansmith pizza > cookies
19:24:28 mriedem i'd agree with that
19:24:49 mriedem https://sallysbakingaddiction.com/chocolate-chip-cookie-pizza/
19:24:56 mriedem a love child

Earlier   Later