Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks

On 07/03/2012 10:30 AM, Livnat Peer wrote: > 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. how is that different from top collections including VMs and templates? (or logical networks becoming main tab in the UI going forward)

> > 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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >