On 22.03.21 07:48, Leon Romanovsky wrote:
> On Mon, Mar 22, 2021 at 06:58:34AM +0100, Jürgen Groß wrote:
>> On 22.03.21 06:39, Leon Romanovsky wrote:
>>> On Sun, Mar 21, 2021 at 06:54:52PM +0100, Hsu, Chiahao wrote:
>>>>
>>>
>>> <...>
>>>
>>>>>> Typically there should be one VM running netback on each host,
>>>>>> and having control over what interfaces or features it exposes is also
>>>>>> important for stability.
>>>>>> How about we create a 'feature flags' modparam, each bits is specified for
>>>>>> different new features?
>>>>> At the end, it will be more granular module parameter that user still
>>>>> will need to guess.
>>>> I believe users always need to know any parameter or any tool's flag before
>>>> they use it.
>>>> For example, before user try to set/clear this ctrl_ring_enabled, they
>>>> should already have basic knowledge about this feature,
>>>> or else they shouldn't use it (the default value is same as before), and
>>>> that's also why we use the 'ctrl_ring_enabled' as parameter name.
>>>
>>> It solves only forward migration flow. Move from machine A with no
>>> option X to machine B with option X. It doesn't work for backward
>>> flow. Move from machine B to A back will probably break.
>>>
>>> In your flow, you want that users will set all module parameters for
>>> every upgrade and keep those parameters differently per-version.
>>
>> I think the flag should be a per guest config item. Adding this item to
>> the backend Xenstore nodes for netback to consume it should be rather
>> easy.
>>
>> Yes, this would need a change in Xen tools, too, but it is the most
>> flexible way to handle it. And in case of migration the information
>> would be just migrated to the new host with the guest's config data.
> 
> Yes, it will overcome global nature of module parameters, but how does
> it solve backward compatibility concern?

When creating a guest on A the (unknown) feature will not be set to
any value in the guest's config data. A migration stream not having any
value for that feature on B should set it to "false".

When creating a guest on B it will either have the feature value set
explicitly in the guest config (either true or false), or it will get
the server's default (this value should be configurable in a global
config file, default for that global value would be "true").

So with the guest created on B with feature specified as "false" (either
for this guest only, or per global config), it will be migratable to
machine A without problem. Migrating it back to B would work the same
way as above. Trying to migrate a guest with feature set to "true" to
B would not work, but this would be the host admin's fault due to not
configuring the guest correctly.


Juergen