| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-10 | |||
| 14:17:08 | mriedem | gibi: that would only succeed in the case that the dest host is not upgraded and reshaped yet | |
| 14:17:09 | mriedem | right? | |
| 14:17:15 | gibi | mriedem: right | |
| 14:17:16 | mriedem | so it's a narrow window where we might get lucky and it works | |
| 14:17:18 | jangutter | sean-k-mooney: one way of doing this is to explicitly ignore relationships established by composition - in other words, you assume that a particular plugin will not require distinct port_profile versions for different vifs that it supports. | |
| 14:17:22 | mriedem | so i don't care about supporting that | |
| 14:17:25 | gibi | mriedem: yes | |
| 14:17:31 | gibi | mriedem: OK | |
| 14:17:40 | mriedem | sean-k-mooney: yes i'm ok with that | |
| 14:17:55 | bauzas | mriedem: for the disabled host, they can still call the scheduler | |
| 14:18:08 | bauzas | mriedem: but yeah the computefilter will then return no | |
| 14:18:11 | mriedem | bauzas: the ComputeFilter will reject it | |
| 14:18:12 | mriedem | right | |
| 14:18:15 | sean-k-mooney | mriedem: i know :) so am i force is a pain in the ass. but where i was going with this is shoudl we consider deprecating force | |
| 14:18:28 | mriedem | sean-k-mooney: that's gibi's spec | |
| 14:18:33 | mriedem | https://review.openstack.org/#/c/609330/1 | |
| 14:18:36 | bauzas | mriedem: actually I guess that's probably why force_hosts on boot doesn't run on filters | |
| 14:18:51 | bauzas | mriedem: but we shouldn't really skip all filters, just the compute one | |
| 14:19:00 | sean-k-mooney | mriedem: oh :) | |
| 14:19:43 | sean-k-mooney | jangutter: ya i can see jsut removing the version info in general that said it may be useful to keep jsut so we can say this is the newest version i supprot to nova/neutron | |
| 14:19:45 | bauzas | mriedem: jaypipes: gibi: actually, hold on | |
| 14:20:04 | bauzas | I think the usecase I said for force is still needed for operators :( | |
| 14:20:22 | bauzas | because they probably want to migrate instances to some disabled compute | |
| 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 | bauzas | I meant "microversions >2.XX won't support this usecase now" | |
| 14:27:56 | gibi | mriedem, bauzas: but that old code won't work for nested allocatons | |
| 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 | mriedem | i know mnaser does the rebalance dance, | |
| 14:28:17 | bauzas | mriedem: both are in OSDN AFAIK | |
| 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 | mriedem | until everything is nested | |
| 14:29:50 | gibi | sean-k-mooney: we could not suppor force for nested allocations | |
| 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 | 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 | |