Networks label feature

[Moti Asayag]

I've incorporated the comments from the mail into the feature page.
Please read the inline comments below:

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Monday, December 9, 2013 9:57:27 AM
> Subject: Re: Networks label feature
> 
> 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 new actions naming:

1.5.1 Labeling a network or an interface
1.5.2 Unlabeling a network or an interface
1.5.3 Changing a label of a network or an interface

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

I think it should be achievable in a single 'setup networks' call. It will
require a more extensive parameters construction than the other use cases.

> > 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 property 'Apply to all hosts' will appear in the 'Edit Network' dialog
as part of the Multi-Host Network Configuration [1]. It should instruct the
appliance of the network changes on all of the hosts. This feature should 
co-exit with the network labels. I've added a section for it to the 'Unlabel
a network' section:

"In conjunction with the 'apply to all hosts', the network will be removed 
from all of the labelled interfaces, and the network will be updated on all 
of the other eligible hosts."

IMO, the 'apply all' property of the 'Update Network' command will apply the
network change to all of the hosts. If no change was made to the label, it
will sync the network on all of the hosts. If 'apply all' wasn't set, the
network change should be applied to the labelled interfaces only.

[1] http://www.ovirt.org/Features/MultiHostNetworkConfiguration

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

We should be able to provide such a feedback to the user. It may vary between
clusters according to the network assignment to the cluster. The indication for
it should be near the label configuration on the host and we should reflect it
as well in the networks main tab ---> host sub-tab.

Which leads to another question regarding 'Network Label constraints' [1]:
Wouldn't we like to prevent label definition which its appliance will fail 
for sure if all of the label associated networks are assigned to a cluster ? 
In this case we should extend the can-do-actions of add-update network commands
to validate the network label correctness. However, since the label is on dc level,
the user may configure invalid label that will function well according to
the assignment of the networks to cluster. I'm in favor of blocking the action
if the label isn't supported. I'd like to hear other opinion on this matter.

[1] http://www.ovirt.org/Features/NetworkLabels#Network_Label_constraints

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