| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-10 | |||
| 13:56:47 | jangutter | dansmith: I've seen that mapping, the question is, do we need/want it in os-vif? | |
| 13:57:11 | dansmith | sean-k-mooney: it means within a scope you don't randomly upgrade one object and not another yeah | |
| 13:57:34 | dansmith | sean-k-mooney: which is what this was designed to do, not for "I loaded a new plugin which loaded one new object into a sea of older ones" | |
| 13:58:15 | sean-k-mooney | dansmith: right... so we might have to deal with the lather in os-vif but perhaps we dont | |
| 13:58:39 | dansmith | yeah I dunno | |
| 13:58:44 | mriedem | bauzas: we had 2 different versions previously because of all the related plumbing those required | |
| 13:59:04 | mriedem | this is a simple schema change | |
| 13:59:09 | sean-k-mooney | dansmith: did any of this impact out of tree virt drivers on the nova side? or are all the OVOs managed above the virt dirver level | |
| 13:59:16 | bauzas | mriedem: okay, fair then | |
| 13:59:27 | dansmith | sean-k-mooney: we don't support out of tree virt drivers | |
| 14:00:18 | sean-k-mooney | dansmith: :) well thats one answer. but i think we are still fine. plugins are not allowed to provide vif types or profiles they can only consume them so i think we wont have the mixed case | |
| 14:00:38 | dansmith | oh okay I thought that was the point of os-vif | |
| 14:00:39 | dansmith | but cool if not | |
| 14:01:05 | sean-k-mooney | plugins can consume the datamodels but not extend them | |
| 14:02:40 | sean-k-mooney | dansmith: that said kuryr-kubernetes are violating that contract https://github.com/openstack/kuryr-kubernetes/blob/master/kuryr_kubernetes/objects/vif.py | |
| 14:03:08 | mriedem | bauzas: i think you wanted to copy the ops list but didn't | |
| 14:03:09 | mriedem | "adding openstack-operators@ accordingly." | |
| 14:03:12 | mriedem | the ops list isn't on copy | |
| 14:03:35 | sean-k-mooney | dansmith: i told them that this was not be supported a few cycles ago and we will be moving those vif types before nova and neutron start useing os-vif objects to negociate bindings | |
| 14:03:37 | mriedem | oh i see, "Shit, I forgot to add openstack-operators@..." | |
| 14:03:40 | bauzas | mriedem: I had a problem with my other gmail address | |
| 14:03:53 | bauzas | hence the three emails | |
| 14:04:24 | bauzas | hopefully the single ML address will simplify it | |
| 14:04:28 | dansmith | sean-k-mooney: ack | |
| 14:06:57 | jangutter | dansmith, sean-k-mooney, jaypipes: thanks very much for this discussion, I think it might be a good time to explicitly fix os-vif into the simpler model rather than allowing a possible version explosion. | |
| 14:07:59 | sean-k-mooney | jangutter: im not sure how you would do that | |
| 14:08:07 | jaypipes | jangutter: well, since nothing yet uses the object-over-http I wouldn't mind keeping all the versions at 1.0 at this point. | |
| 14:08:14 | sean-k-mooney | i dont think its partacally complex | |
| 14:08:25 | jaypipes | but I need to run away now for a half hour. back soon. | |
| 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 | |