Networks label feature

[Livnat Peer]

On 12/08/2013 06:32 PM, Moti Asayag wrote:
> 
> 
> ----- Original Message -----
>> From: "Livnat Peer" <lpeer at redhat.com>
>> To: "Moti Asayag" <masayag at redhat.com>, "arch" <arch at ovirt.org>
>> Sent: Sunday, December 8, 2013 4:06:17 PM
>> Subject: Re: Networks label feature
>>
>> On 12/08/2013 03:22 PM, Moti Asayag wrote:
>>> Hi All,
>>>
>>> Another network feature planned for ovirt-engine-3.4 is
>>> the network labels [1].
>>>
>>> Please review and share your feedbacks.
>>>
>>> [1] http://www.ovirt.org/Features/NetworkLabels
>>>
>>> Thanks,
>>> Moti
>>
>> Hi Moti,
>>
>> Thanks for writing a detailed feature page, good work.
>>
>> I have a few questions -
>>
>> 1. What does it mean to rename a network label. How does it work with
>> the fact that label is not a managed entity.
>> "Renaming a network label" - It seems from the document that you meant
>> edit network label (instead of rename), and why do we want to add that
>> unpredictable action in the first phase? I would start without this option.
>>
> 
> 
> The network labels related actions will be executed either from the add/edit
> network dialog by editing the 'label' property, or by editing the label of
> 'interface/bond' on the 'setup networks' dialog. Since the label designed to
> be a plan text property on the network, renaming it means changing its value
> to other. Removing a label stands for clearing this field.
> 

So I guess it all about terminology, I think that since we are not
managing labels as entities we can't rename them, what we do is edit the
label on the network, changing one label to another.

> The notation of label actions meant to clarify what are the result of each
> action.
> 
> Without this option we won't allow the admin to change a label once it is created.

I think the user should be able to change the network label of course,
but that would translate to remove and add label from the implementation
perspective.

Which means you'll have to remove the network from all NICs with the
original label and add the network to all the NICs with the new label,
hopefully it would be done using a single setupNetwork operation per host.

> That seems like a harsh limitation. What if the user wishes to manage a specific 
> network by other label that the network was originally added with ? 
> 
> And it goes for the host direction as well: changing the label of the host nic 
> indicates the user wishes to manage the networks attached to that nic by other
> label. That seems like a reasonable use case to me.
> 
>> 2. on the 'More examples' section you give an example with two labels on
>> a single network while at the beginning of the page you specified that
>> only one label is supported on a network.
>>
> 
> This is a leftover from a wider solution. we'll start with a design for
> a single label per network and we'll see how it will evolves from there.
> 
>> 3. Do you plan to have the 'Apply to all hosts' check box? in the add
>> label section is says -"no further indication is required " and then on
>> the delete label it says - "The property 'Apply to all hosts' will be
>> reused"
>>
> 
> In 'Add network' dialog there will be no 'Apply to all hosts' checkbox.
> This operation by itself cannot cause the network to be added to hosts 
> without assigning the network to the clusters (even if the hosts' nics are labelled).
> 

The point is about add label, not about add network :)

> The 'delete labels' is basically using the 'Edit network' command for
> clearing this field. Therefore i suggest to make the already existing
> 'Apply to all hosts' property to indicates the network should be removed from 
> all the labelled hosts, the alternative is not to remove a network
> from hosts if the label was cleared from the network.
> 

I think this checkbox is redundant in delete, same as you suggested,
rightfully, in add.

>> 4. Why does the delete label action is not symmetric with add label?
>> specifically why "Deleting the label from the host interface will not
>> cause the removal of the networks.."?
>>
> 
> As stated in previous section - this is an alternative. Fine by me:
> Removing a label from network/host nic won't trigger its removal from
> the hosts. 
> 

I think that removing a label from the host and from the network should
effect the setup configuration - for consistency and for predictability.

removing a label from a NIC would remove the networks associated with
that label from the NIC
removing a label from the network would remove the network from all NICS
that have this label.


>> 5."Pre-'Setup Networks' execution"
>> It looks to me that we are playing catch 22 with the user there :)
>> If the user manually removed the network, although he labeled the NIC
>> then he does not expect the engine to add it again automatically on next
>> setup network.
>> I understand the need for exceptions but in this case I would start with
>> implementing this feature as simple as possible (it is already
>> complicated enough). So my suggestion is do not let the user remove the
>> network manually, if he want s to manage this NIC as an exception then
>> he needs to remove the label.
>>
>> In this specific case I think it would make the behavior more
>> predictable to the user which is crucial (at least for the first phase)
>> for such a complicated feature IMO.
>>
> 
> As I see it, if the user provided label for the host nic (especially via the api), 
> all the eligible networks labelled should be added to that nic.
> Therefore if the label wasn't removed, we should preserve the label definition on
> that host. Therefore limiting the removal seems a reasonable restriction.
> 

Great

>>
>> 6. How does the system reflect failures? If we added a label to a new
>> network and we failed to provisioned it on the host, how will the user
>> know about this? Can you please this to the feature page.
>>
> 
> I'll add the 'events' section to the feature page. Basically, we should separate
> between the Add/Update network command to their extension behind the scenes by
> the labels or the 'apply to all hosts' option. So the correct place in the 
> system to file those events will be in the event log, same as does for the
> 'Edit provisioned networks' feature.
> 

The audit log are good for the action itself but I guess my question is
would the setup network dialog reflect that the labels and the networks
are not in sync?

>>
>> 7. After reading this page I wonder why not use the existing object Tag
>> that we have for labeling the networks and NICs?
>>
> 
> The 'Tag' entity in the system is a hierarchical managed object, designed to
> tag mainly main entities in the system AFAICT. While the tags might work
> for network (after adding respectively the support of it, as there are no 'generic'
> tags), using the tags will raise further complexities for the host nics: 
> In this case will require fetching a list of tags from the tag table for each nic.
> I would rather avoid using the tags, while all needed is a simple property.
> 

ack
I agree that the fact the host NICs are not managed entities could make
using TAGs not a good idea.



>> Livnat
>>
>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>
>>