| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-10 | |||
| 14:20:31 | jangutter | sean-k-mooney: you can still keep port_profiles versioned, but you don't require the combination mapping. | |
| 14:20:35 | sean-k-mooney | jangutter: so in teh host info obejct jsut filter by name not by version, but keep version in the object to say i know about at most version x of this object | |
| 14:20:57 | sean-k-mooney | jangutter: yep | |
| 14:21:24 | sean-k-mooney | bauzas: but why do we want to supprot that | |
| 14:22:22 | sean-k-mooney | they may but it instead of using disabled to reserve a host for mainainace would it not be better to have a maintanace availablity zone they could move the host into | |
| 14:22:34 | bauzas | sean-k-mooney: I guess operators want to migrate some instances from some host because for example the RAID situation is bad | |
| 14:22:54 | sean-k-mooney | bauzas: well migrating from a disable host is fine | |
| 14:23:03 | bauzas | sean-k-mooney: but then they want to migrate to a single host which is exactly like the source one for all the instances | |
| 14:23:04 | sean-k-mooney | bauzas: migrating too a disable host i think is strange | |
| 14:23:14 | bauzas | sean-k-mooney: because of capacity I guess | |
| 14:24:03 | bauzas | gibi: either way, 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 | |
| 14:24:13 | mriedem | bauzas: force_hosts on boot still goes through the filters | |
| 14:24:21 | bauzas | mriedem: not thru the filters | |
| 14:24:30 | bauzas | mriedem: thru the filter scheduler yep | |
| 14:24:36 | bauzas | but then it says "all good" | |
| 14:24:41 | bauzas | and then returens | |
| 14:24:43 | bauzas | returns | |
| 14:24:49 | mriedem | show me the code | |
| 14:25:19 | sean-k-mooney | bauzas: your refing to when you use --availability-zone ZONE:HOST right | |
| 14:25:25 | gibi | bauzas: I can make it clear in the spec that force migration or force evacuating to the disable destination will not work as scheduler's ComputeFilter will reject that host | |
| 14:25:51 | sean-k-mooney | which adds the force flag an just check the availablity zone and host exits then skips all the filters | |
| 14:25:55 | bauzas | mriedem: https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L589 | |
| 14:26:11 | mriedem | yup just found that | |
| 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 ? | |