----- Original Message ----- > From: "Moti Asayag" <[email protected]> > To: "Livnat Peer" <[email protected]> > Cc: "arch" <[email protected]> > Sent: Sunday, December 8, 2013 6:32:14 PM > Subject: Re: Networks label feature > > > > ----- Original Message ----- > > From: "Livnat Peer" <[email protected]> > > To: "Moti Asayag" <[email protected]>, "arch" <[email protected]> > > 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 > > > [email protected] > > > http://lists.ovirt.org/mailman/listinfo/arch > > > > > > > > _______________________________________________ > Arch mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/arch > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
