| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-10 | |||
| 14:09:07 | sean-k-mooney | jaypipes: we proably can make the all 1 but i would be fine to bump them all to 2.0 or something wehn we use them over http | |
| 14:09:37 | jaypipes | sean-k-mooney: ++ | |
| 14:09:48 | jaypipes | sean-k-mooney: and after the version manifest stuff is added in... | |
| 14:11:30 | sean-k-mooney | jaypipes: yes assuming that is needed | |
| 14:11:56 | sean-k-mooney | we will need to document all this in a spec in any case | |
| 14:14:33 | mriedem | gibi: jaypipes: bauzas: efried: i'm all caught up on that ML thread, | |
| 14:14:35 | mriedem | replies inline, | |
| 14:14:50 | mriedem | tl;dr i agree with jay on failing hard if the source has nested allocatoins and we're being forced | |
| 14:15:03 | efried | ++ | |
| 14:15:05 | bauzas | yup, +1 | |
| 14:15:16 | mriedem | force predates these exotic topologies | |
| 14:15:19 | bauzas | if they really want to migrate, just don't force | |
| 14:15:21 | mriedem | and we shouldn't attempt to support it | |
| 14:15:46 | bauzas | so, first they force, and if they get a non-accepted migration, they could just not force | |
| 14:15:55 | bauzas | which looks good to me | |
| 14:16:02 | mriedem | right | |
| 14:16:19 | sean-k-mooney | mriedem: taking that one step futher thw will mean eventually force will never work as at some point all compute nodes will be nested | |
| 14:16:24 | gibi | mriedem: so do we all agree that moving from nested to flat is OK to fail even if it would succeed in placement? | |
| 14:16:27 | mriedem | the one case i can see for using force is what bauzas mentioned in the thread, which is you disable a compute so new instances can't go there, meanwhile rebalancing by forcing things there via live migrate | |
| 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 | 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 | |