| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-10 | |||
| 14:26:15 | mriedem | huh i didn't realize | |
| 14:26:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Deprecate the 'discover_hosts_in_cells_interval' option https://review.openstack.org/609346 | |
| 14:27:12 | mriedem | bauzas: "I think we need to be super clear in the spec that this usecase won't be possible once we remove the force field in a microversion" isn't accurate | |
| 14:27:19 | mriedem | you can still hit the force code with the older microversions | |
| 14:27:24 | mriedem | and osc's default behavior | |
| 14:27:38 | bauzas | mriedem: okay, I wasn't clear | |
| 14:27:56 | gibi | mriedem, bauzas: but that old code won't work for nested allocatons | |
| 14:27:56 | bauzas | I meant "microversions >2.XX won't support this usecase now" | |
| 14:27:59 | mriedem | gibi: yeah i left a comment on that in the spec just now, and added mnaser and tobias from city network (public cloud SIG chair) | |
| 14:28:05 | mriedem | gibi: agree | |
| 14:28:17 | bauzas | mriedem: both are in OSDN AFAIK | |
| 14:28:17 | mriedem | i know mnaser does the rebalance dance, | |
| 14:28:22 | mriedem | i just don't know if he disables computes before doing so | |
| 14:28:30 | bauzas | at least that's what twitter claims :) | |
| 14:28:35 | gibi | sooo, the operators will use the force case totally as soon as the allocations are nested | |
| 14:28:39 | gibi | regardless of microversion | |
| 14:28:40 | sean-k-mooney | mriedem: have we increased the minium microverion by the way since we started using them. | |
| 14:28:49 | mriedem | no we don't do that | |
| 14:28:55 | gibi | s/use/lose/ | |
| 14:29:33 | sean-k-mooney | mriedem: so we will always effectly have to support force then as you can always use an old microverion ? | |
| 14:29:50 | gibi | sean-k-mooney: we could not suppor force for nested allocations | |
| 14:29:50 | mriedem | until everything is nested | |
| 14:30:13 | mriedem | which is whenever jaypipes' cpu resource tracking stuff happens | |
| 14:30:30 | sean-k-mooney | mriedem: or numa in placement | |
| 14:30:31 | mriedem | unless we start supporting VMs without compute resources... | |
| 14:30:43 | mriedem | you can't live migrate with numa today anyway so meh | |
| 14:30:49 | sean-k-mooney | mriedem: oh you mean "serverless" workloads | |
| 14:30:56 | mriedem | sean-k-mooney: it was a joke | |
| 14:31:23 | sean-k-mooney | mriedem: yes but i just wanted to bitch about "serverless" marketing | |
| 14:31:40 | bauzas | MEEEEH | |
| 14:31:49 | mriedem | qinling already handles that | |
| 14:32:05 | mriedem | see https://qinling.readthedocs.io/ | |
| 14:32:28 | mriedem | heh | |
| 14:32:29 | mriedem | https://docs.openstack.org/qinling/latest/ | |
| 14:32:30 | sean-k-mooney | mriedem: either jays cpu think of bauzas's numa stuff "should" land in stein | |
| 14:32:40 | bauzas | there are a couple of proposals about serverless w/ OpenStack that don't necessarly imply a high-level OpenStack service for this, but meh :) | |
| 14:32:41 | sean-k-mooney | mriedem: so does storelets | |
| 14:33:10 | sean-k-mooney | https://github.com/openstack/storlets | |
| 14:33:10 | bauzas | anyway, we're running VMs | |
| 14:33:26 | bauzas | looks like we're diverting | |
| 14:33:30 | pooja_jadhav | mriedem: able to write FT :).. thanks alot | |
| 14:34:24 | sean-k-mooney | bauzas: sorry your right. so are you ok with documenting that force is availabel for old microverions and will not be supported for nested hosts? | |
| 14:34:44 | mriedem | pooja_jadhav: np. | |
| 14:35:00 | mriedem | pooja_jadhav: i'd recommend starting with a patch that adds the functional test to show the bug, as my patch does | |
| 14:35:09 | mriedem | then you can work the fix on top of that separately | |
| 14:35:56 | pooja_jadhav | mriedem: sure | |
| 14:56:39 | openstack | Launchpad bug 1797146 in OpenStack Compute (nova) "failed to boot guest with vnic_type direct when rx_queue_size, tx_queue_size and hw_vif_type are set" [Undecided,New] | |
| 14:56:39 | stephenfin | moshele, sean-k-mooney: Yeah, it's a bug https://bugs.launchpad.net/nova/+bug/1797146 | |
| 14:58:15 | sean-k-mooney | stephenfin: yes but only for vnic_types direct or direct_physical corect | |
| 14:58:21 | stephenfin | yup | |
| 14:58:33 | sean-k-mooney | stephenfin: if the guest also has ovs ports they should still use the specifid model | |
| 14:58:49 | openstack | Launchpad bug 1797146 in OpenStack Compute (nova) "failed to boot guest with vnic_type direct when rx_queue_size, tx_queue_size and hw_vif_type are set" [Undecided,New] | |
| 14:58:49 | stephenfin | Yup https://bugs.launchpad.net/nova/+bug/1797146/comments/1 | |
| 14:58:50 | sean-k-mooney | we should test macvtap ports too | |
| 14:59:35 | stephenfin | sean-k-mooney: Is there any configuration where we'd have a direct or direct_physical vnic_type and still use virtio? | |
| 15:00:25 | stephenfin | I'm assuming not because those are two opposing things | |
| 15:00:47 | sean-k-mooney | stephenfin: yes but we should ignore the model in that case | |
| 15:01:19 | sean-k-mooney | stephenfin: e.g. if the VF itself is a virtio-net-pci device that is fine | |
| 15:01:39 | sean-k-mooney | but we should not set the model to virtio expcitly in that case as qemu is not emulating virtio | |
| 15:01:47 | sean-k-mooney | virtio is being implemneted in hardware | |
| 15:02:05 | stephenfin | Sweet | |
| 15:02:10 | stephenfin | That makes this nice and easy so | |
| 15:02:15 | sean-k-mooney | stephenfin: just add vnic_type not in VNIC_TYPES_DIRECT_PASSTHROUGH | |
| 15:02:31 | stephenfin | sean-k-mooney: Yup, exactly what I'm doing | |
| 15:02:37 | sean-k-mooney | VNIC_TYPES_DIRECT_PASSTHROUGH is form https://github.com/openstack/nova/blob/6bf11e1dc14afad78b11d980c2544a3dc41579ff/nova/network/model.py#L116 | |
| 15:02:41 | sean-k-mooney | :) | |
| 15:03:20 | melwitt | . | |
| 15:03:57 | sean-k-mooney | melwitt: i read "." as basically you saying "um" and pausing | |
| 15:04:28 | melwitt | I don't know what that means, but ok :) | |
| 15:05:05 | sean-k-mooney | melwitt: you typed "." on irc so i just assumed you were about to say something and paused to think for a sec | |
| 15:11:44 | openstack | Launchpad bug 1797146 in OpenStack Compute (nova) "failed to boot guest with vnic_type direct when rx_queue_size, tx_queue_size and hw_vif_type are set" [Medium,Confirmed] | |
| 15:11:44 | sean-k-mooney | stephenfin: your activly fixing https://bugs.launchpad.net/nova/+bug/1797146 right so im jsut going to assign it to you on launchpad | |
| 15:11:53 | stephenfin | Go for it | |
| 15:14:10 | jaypipes | mriedem: have you ever used the "query" scheduler hint? https://github.com/openstack/nova/blob/0163b9bfb54aaa89b0574c86e7fd36321eebccfe/nova/api/openstack/compute/schemas/servers.py#L122 | |
| 15:14:57 | sean-k-mooney | jaypipes: as in the json filter "query" schduer hint | |
| 15:16:59 | mriedem | jaypipes: hell no | |
| 15:18:00 | cfriesen | efried: jaypipes: new version of the emulated TPM spec is up. you folks okay with HW_SYSTEM_TPM for the trait, or do you want something like COMPUTE_SECURITY_TPM ? | |
| 15:19:30 | sean-k-mooney | cfriesen: when i was proposing tpm traits before i was going with something slightly different https://review.openstack.org/#/c/514712/3/os_traits/hw/platform/security.py | |
| 15:20:42 | sean-k-mooney | cfriesen: so it would be HW_PLATFORM_SECURITY_TPM | |
| 15:21:12 | sean-k-mooney | or HW_PLATFORM_SECURITY_TPM_2_0 | |
| 15:21:57 | sean-k-mooney | COMPUTE_SECURITY_TPM would indicate taht the hypervior can emulate a TPM and HW_PLATFORM_SECURITY_TPM would be the host has a tpm | |
| 15:22:05 | cfriesen | yeah, in the review I did call out whether we want to embed the TPM version in the trait | |
| 15:23:08 | cfriesen | sean-k-mooney: I thought from the hangout that physical TPM would be handled via a resource with inventory? | |
| 15:23:45 | sean-k-mooney | in the tpm i guess it could be as it is passthough to the vm and not subdevied | |
| 15:24:09 | sean-k-mooney | in which case COMPUTE_SECURITY_TPM should be the only trait that is needed | |
| 15:24:18 | jaypipes | sean-k-mooney: is TPM2.0 an Intel-specific thing? | |
| 15:24:21 | sean-k-mooney | moduleo adding a version | |
| 15:24:30 | sean-k-mooney | jaypipes: no its an open standard | |
| 15:24:34 | jaypipes | k. | |
| 15:24:55 | jaypipes | sean-k-mooney: I was going to suggest prefixing with X86 if it was Intel-specific. | |
| 15:25:03 | sean-k-mooney | jaypipes: https://www.iso.org/standard/66510.html | |
| 15:25:42 | cfriesen | okay, I can switch to COMPUTE_SECURITY_TPM_1_2 and COMPUTE_SECURITY_TPM_2_0 if jaypipes is cool with that | |
| 15:26:10 | jaypipes | sean-k-mooney: we have used COMPUTE_ to refer to virt-driver specific capabilities. I don't believe this is that? | |
| 15:26:18 | jaypipes | sean-k-mooney: isn't TPM a hardware thing? | |
| 15:26:30 | cfriesen | jaypipes: with the trait we're talking about an emulated TPM | |
| 15:26:42 | cfriesen | the hardware TPM would be a resource since there would be a finite number of them | |
| 15:26:49 | jaypipes | ah, right.. | |
| 15:26:55 | jaypipes | OK, good with me then. | |
| 15:27:07 | sean-k-mooney | yep what cfriesen said :) | |
| 15:27:11 | jaypipes | this is what I was confusing HPET with :) | |