Networks label feature

Mon Dec 9 14:50:44 UTC 2013

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: "arch" <arch at ovirt.org>
> Sent: Sunday, December 8, 2013 6:32:14 PM
> Subject: Re: Networks label feature
> 
> 
> 
> ----- 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.

I think that even this is what you are going to support on 1st phase, it is good to
build things correctly right from the beginning, so , I would not add the label as a property
to an entity, rather , it should be a Many<-Many relation between entities and labels which 
implies an entity_label table.

>From past experience, this will not cots more than the simple 1 label solution, but changing it 
to a many-to-many relation in future will cost more ....

> 
> > 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
> > > 
> > 
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 