| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-02 | |||
| 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 | |
| 20:57:03 | sean-k-mooney | i think descret tp0ms and maybe the integrated tpm in the intel chips set can be passthed through | |
| 20:57:15 | sean-k-mooney | the firware and software one obviosly cant be | |
| 20:57:45 | efried | mriedem, melwitt: in case y'all weren't silently following along, here's the earlier conversation with jroll and dansmith: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-07-02.log.html#t2019-07-02T17:30:56 | |
| 20:57:54 | mriedem | efried: i saw it | |
| 20:58:04 | mriedem | and agreed with the -5 comment | |
| 20:58:09 | efried | k | |
| 20:58:10 | melwitt | efried: yeah, I mentioned what I did bc I read it | |
| 20:58:16 | efried | k | |
| 20:58:36 | efried | thanks for the followup | |
| 20:58:37 | melwitt | at the very least for any potential downstream-only endeavor | |
| 20:59:46 | sean-k-mooney | i takeign booting windows to run the clear-tpm powershell commadn is not a thing we cand do :) https://docs.microsoft.com/en-us/powershell/module/trustedplatformmodule/clear-tpm?view=win10-ps | |
| 21:00:03 | sean-k-mooney | its rare that all the hits i get in google are for windows | |
| 21:00:26 | melwitt | if there were a way we could query the tpm device to know whether it's clear/ready, then IMO it seems similar enough to pci passthrough and not so bad | |
| 21:00:58 | melwitt | but since there's not, then I agree it doesn't fit | |
| 21:01:41 | sean-k-mooney | apparent there is a tpm_clear command | |
| 21:01:58 | mriedem | we have also done a poor job at times of tracking allocated pci devices | |
| 21:02:07 | sean-k-mooney | just reading https://resources.infosecinstitute.com/linux-tpm-encryption-initializing-and-using-the-tpm/#gref | |
| 21:02:10 | openstackgerrit | Merged openstack/nova stable/rocky: libvirt: Rework 'EBUSY' (SIGKILL) error handling code path https://review.opendev.org/667436 | |
| 21:02:35 | mriedem | e.g. https://review.opendev.org/#/q/I6e871311a0fa10beaf601ca6912b4a33ba4094e0 | |
| 21:02:52 | melwitt | aye | |
| 21:03:33 | sean-k-mooney | it looks like clearing the tpm makes it unowned and disablses it which requries a reboot to fix | |
| 21:03:57 | melwitt | yeah, that's what efried was saying earlier. it's a two-step deal | |
| 21:06:04 | sean-k-mooney | ya diging a bit deeper it looks like linux cant actully clear teh tpm its self for security reason and its actully the uefi on reboot that is clearing it | |