On 02/07/12 17:35, Mike Kolesnik wrote: > Hi All, > > I would like to hear opinions about a behaviour that I think is > problematic in > REST API handling of logical networks. > > -- Intro -- > Today in the REST API we are exposing two collections for "logical > network" related entities. > > First is a top level collection which is out of any context at the address > http://engine/api/networks. > Second is a sub-collection in the context of a cluster: > http://engine/api/cluster/xxx/networks > > The network itself is defined per DC level, so for each DC you would have > at least one logical network for management, which has some properties such > as STP, MTU, etc.. > The top level collection is used to create/delete such network entities. > > The sub-collection in the context of a Cluster is used to attach/detach a > network from the DC of that cluster. > The network in the context of a cluster has some additional information, > let's > say for example 'status' of the network: > If a network is defined on all hosts in the cluster then it's status is > 'Operational'. > If a network is not defined on some of the hosts in the cluster then > it's > status is 'Not Operational'[1]. > > > -- Problem -- > The problem is that details which are only relevant in context of a > cluster, are still displayed in the root context as well (e.g: 'status'). > This can, in certain cases, cause unexpected behaviour. > > For example, let's consider this topology: > Data Center A > | > |\____ Network 'red' > |\____ Cluster A1 > | \______ Network 'red' attached > \____ Cluster A2 > \______ Network 'red' attached > > If the 'status' is the same on all the clusters that the network is > attached to > (A1, A2) then there will be one element in the top level collection, > with the > network details and the 'status' field representing the state (which is same > for all networks in the cluster contexts of the cluster). > If, however, the status is not the same (ie. on A1 the network is > 'Operational' and on A2 it is 'Non Operational') then the top-level > collection will show two elements for the network, where all network > details are the same and only the 'status' field is different. >
That sounds like a bug to me. I think that top collection should include only DC level properties and not cluster level properties, status should not be there (same as display required etc.) > This is problematic IMHO for several reasons: > 1. Showing one network in certain states, and multiple copies of this > network in other states is not optimal, to say the least. > 2. In the top-level collection there is no indicator of the cluster > for which > the network is displayed, so there is no way to differentiate > between the > two 'red' network elements (they will have same id, name, etc.). > 3. There is a certain asymmetry between the remove action[2] and the > result in that you would expect: you either remove a network but > in the > result you would see several elements removed. > > > -- Proposed Solutions -- > Personally I can think of several solutions to this problem: > 1. Declare the top-level collection as a collection of all networks > that are > either attached to cluster or not, and if they are indeed attached > then > show the details for each cluster, including a link to the cluster. > 2. Declare the top-level collection as a collection of all networks > that are > defined in data-centers, but they will not contain any cluster > specific > data, and thus each entry is unique. > > Solution #2 is breaking the API backwards-compatibility, since it includes > removing certain fields that have appeared today (namely 'status' and > 'display') but IMO would give a better experience since the top-level > collection is actually used for managing networks, and not their attachment > to clusters which should be done in the context of each cluster. > I really don't think top collections should include cluster networks it is not user-friendly to say the least. I vote for the second option, I don't think that having a bug in previous versions should drive this decision. > I would like to hear what suggestions you have to solve this problem or if > you prefer either of the above solutions. > > > -- Footnotes -- > [1] In 3.1 this is slightly different, but for the sake of simplicity I > didn't > specify the new behaviour. > [2] Currently you can't update the network if it's attached to any cluster, > but perhaps in the future this would be possible. > > Regards, > Mike > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
