| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-02 | |||
| 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 | sure | |
| 19:23:59 | mriedem | like, cats > dogs? | |
| 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 | |
| 19:28:39 | dansmith | mriedem: okay I'm not sure I get it | |
| 19:28:45 | dansmith | we have this set_host_enabled call already yeah? | |
| 19:29:05 | dansmith | and the base virt driver does what when you call it? raise not implemented? | |
| 19:29:11 | mriedem | yes, only used by the os-hosts api which was deprecated in 2.43 and only implemented by the xenapi driver | |
| 19:29:14 | mriedem | yes | |
| 19:29:39 | dansmith | oh, I see, different from service disable yeah? | |
| 19:29:43 | mriedem | yes, | |
| 19:29:48 | dansmith | right right, okay | |
| 19:29:49 | mriedem | but i'm going to use it for service disable/enable in the api change | |
| 19:29:56 | dansmith | yeah | |
| 19:29:57 | dansmith | so, | |
| 19:30:17 | dansmith | the thing you're concerned about is replicating the 501 "this thing doesn't support that" case for libvirt and v2.1? | |
| 19:30:38 | mriedem | it's a minor concern, but yeah | |
| 19:30:39 | dansmith | I guess I'm not sure why that matters.. the fact that libvirt does or doesn't support the thing has nothing to do with microversion 2.1 (or any version) | |
| 19:31:00 | mriedem | the version really only matters b/c the api no longer works with 2.43+ | |
| 19:31:06 | mriedem | for any driver | |
| 19:31:24 | dansmith | okay but.. why does it matter if someone calls it with v2.1 on libvirt and it works? | |
| 19:31:45 | mriedem | because it's a behavior change... | |
| 19:31:50 | dansmith | it's not | |
| 19:31:58 | dansmith | it's an implementation detail | |
| 19:32:14 | dansmith | if the thing (which the user can't see) supports it, it works, and if not it's 501 | |
| 19:32:40 | mriedem | or 400 if i just return None | |
| 19:32:41 | dansmith | they can't see that libvirt didn't support it before, got a 501, and that either now it does support it, or some other driver is being used | |
| 19:33:03 | mriedem | in this case the user == admin anyway, | |
| 19:33:08 | mriedem | so another reason why it's a minor concern for me | |
| 19:33:37 | dansmith | right, but this is not necessarily an admin user that has visibility into the hypervisor details | |
| 19:34:03 | dansmith | this could be a level-1 lab monkey that needs to disable a host to go blow dust out of the fans or something | |
| 19:34:51 | dansmith | anyway, just saying I don't think we should tie behavior of a microversion to a version of the implementation underneath when the behavior and semantics haven't changed | |
| 19:35:11 | mriedem | sure. if you don't think anything needs to change that's fine with me. would appreciate a comment in the review for if/when someone comes along saying it's a change. | |
| 19:35:19 | dansmith | will | |
| 19:35:19 | mriedem | also note the api ref is pretty clear to not use that api https://developer.openstack.org/api-ref/compute/?expanded=update-host-status-detail#update-host-status | |
| 19:46:37 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Remove unreachable native QEMU iSCSI initiator config code https://review.opendev.org/668750 | |
| 20:07:06 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add placement request pre-filter compute_status_filter https://review.opendev.org/668752 | |
| 20:42:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Refactor HostAPI.service_update https://review.opendev.org/668756 | |
| 20:50:31 | melwitt | 'tpm_project_id' compute stat to the project_id when a tpm request lands on the host. and the 'tpm_project_id' stat gets cleared during init_host | |
| 20:50:31 | melwitt | efried, jroll, dansmith: fwiw, an idea we had when I chatted with penick about the TPM thing was tracking the "TPM availability" outside of placement using a scheduler filter and a new compute stat. the compute stat would be something like 'tpm_project_id' and defaults to None. and the scheduler filter passes a host only if 'tpm_project_id' is None or matches project_id [if a tpm is requested]. and then in nova-compute, set | |
| 20:51:53 | efried | melwitt: Except for that last bit. Having restarted the compute service does *not* mean the TPM is clear and ready for use by someone else. The only way we can know that bit is if the admin tells us so. | |
| 20:52:04 | melwitt | the only caveat I was thinking here is that init_host doesn't guarantee a reboot happened | |
| 20:52:13 | efried | just so | |
| 20:52:24 | efried | and a reboot doesn't guarantee the TPM was cleared. | |
| 20:52:24 | melwitt | yeah | |
| 20:52:43 | melwitt | oh, ok, I didn't know that or misunderstood | |
| 20:52:58 | sean-k-mooney | is there any reason we cant wipe the tpm directly when we delete a vm that is using it | |
| 20:53:05 | efried | a reboot is required, but not sufficient. You had to have done some kind of purgey command prior | |
| 20:53:13 | melwitt | sean-k-mooney: from what penick said, that is not possible | |
| 20:53:22 | melwitt | efried: I see | |
| 20:53:41 | sean-k-mooney | efried: is a reboot requried or can we do a device reset | |
| 20:53:57 | sean-k-mooney | i have not looked into it but i know fo bios based gpus a reboot was required | |
| 20:54:06 | efried | I don't know whether "purgey command" is "device reset" or what, but you have to reboot the host for it to be reusable. | |
| 20:54:07 | sean-k-mooney | for uefi based gpus a deivce reset was enough | |
| 20:54:28 | sean-k-mooney | it could depend on the type of tpm you have | |
| 20:54:40 | sean-k-mooney | there are several diffeerent tpm types | |
| 20:54:50 | sean-k-mooney | that are connect over different buses | |
| 20:54:50 | efried | how would we know? | |
| 20:56:05 | mriedem | sure sounds like hardware management that nova shouldn't be doing... | |
| 20:56:06 | sean-k-mooney | im not sure https://en.wikipedia.org/wiki/Trusted_Platform_Module#TPM_implementations | |