| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-10 | |||
| 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 | bauzas | anyway, we're running VMs | |
| 14:33:10 | sean-k-mooney | https://github.com/openstack/storlets | |
| 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 | stephenfin | moshele, sean-k-mooney: Yeah, it's a bug https://bugs.launchpad.net/nova/+bug/1797146 | |
| 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: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 | stephenfin | Yup https://bugs.launchpad.net/nova/+bug/1797146/comments/1 | |
| 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: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 | 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: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: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 :) | |
| 15:27:19 | sean-k-mooney | yep | |
| 15:27:25 | cfriesen | okay, I'll respin the TPM spec with that minor change | |
| 15:27:30 | jaypipes | cfriesen: you proposing the os-trait patch? | |
| 15:27:53 | cfriesen | sure | |
| 15:28:59 | sean-k-mooney | *subdivided | |
| 15:29:19 | jaypipes | cfriesen: ok, when you do, please be sure to be crystal clear that the trait refers to the virt-driver emulated capability, not a physical resource. | |
| 15:29:28 | jaypipes | sean-k-mooney: I'm kidding with you :) | |
| 15:29:43 | cfriesen | jaypipes: right, makes sense | |
| 15:29:49 | jaypipes | ty sir | |
| 15:30:24 | sean-k-mooney | what i have realised while typeing used to massively reduce the amount of missspelling i made due to reversing or omitting letter now that i touch type entirly without thinking they are reappearing | |
| 15:31:39 | sean-k-mooney | it used to be a huge problem in school when i would hand write things and just stop writing a word half way through and start in the middle fo the next one bacially because my hand could not keep up with my brian when writing | |
| 15:32:49 | jangutter | In the past few years I've noticed that I've started to mistype things really really badly, reading back the sentence once is no longer enough for me to figure out what I messed up. | |
| 15:33:38 | jangutter | Worse, it's happening to my speech too. Pretty hilarious when you realise that your words leaving your mouth and in your brain don't match up. | |
| 15:34:50 | jangutter | but really, I try to spread that rumour so I can claim I actually meant "offloads" when I said "screwdriver". | |
| 15:48:49 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Ignore hw_vif_type for direct, direct-physical vNIC types https://review.openstack.org/609460 | |
| 15:49:04 | stephenfin | sean-k-mooney: ^ | |
| 15:57:05 | openstackgerrit | Chris Friesen proposed openstack/nova-specs master: Add support for emulated virtual TPM https://review.openstack.org/571111 | |
| 16:00:59 | openstackgerrit | Andreas Jaeger proposed openstack/nova master: Replace openSUSE experimental check with newer version https://review.openstack.org/609467 | |
| 16:03:02 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Consider nested allocations during allocation cleanup https://review.openstack.org/606050 | |
| 16:03:03 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject forced move with nested source allocation https://review.openstack.org/605785 | |
| 16:04:55 | gibi | jaypipes, mriedem, bauzas, efried: here is the rework of the force migration with nested allocation https://review.openstack.org/#/c/605785 | |
| 16:05:08 | gibi | and I'm leaving for today | |
| 16:05:13 | bauzas | I'm done for the day, but I'll look tomorrow | |
| 16:05:20 | bauzas | hah | |
| 16:09:07 | sean-k-mooney | stephenfin: can you take a look at https://review.openstack.org/#/c/609414/ before you leave | |