Networks label feature

Sun Dec 8 16:32:14 UTC 2013

----- 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.

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.
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 '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.

> 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. 

> 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.

> 
> 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.

> 
> 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.

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