----- Original Message ----- > From: "Michael Pasternak" <[email protected]> > To: "Livnat Peer" <[email protected]> > Cc: "engine-devel" <[email protected]>, "Simon Grinberg" > <[email protected]> > Sent: Thursday, July 5, 2012 11:56:03 AM > Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of > logical networks > > On 07/05/2012 11:40 AM, Livnat Peer wrote: > > On 05/07/12 11:31, Michael Pasternak wrote: > >> On 07/05/2012 10:51 AM, Livnat Peer wrote: > >>>>>>> Actually the API has the same concept as you suggest for > >>>>>>> storage > >>>>>>>>>>> domains. > >>>>>>>>>>> At the top level you don't have a status field, but under > >>>>>>>>>>> data > >>>>>>>>>>> center level, where it's valid then you get the status > >>>>>>>>>>> property. > >>>>>>>>>>> > >>>>>>>>>>> Same should go for networks. > >>>>>>>>>>> The status property should be added only where it's > >>>>>>>>>>> valid, in > >>>>>>>>>>> this > >>>>>>>>>>> case the cluster level sub-collection > >>>>>>>>> > >>>>>>>>> so sounds like we want to declare these properties > >>>>>>>>> deprecated to be > >>>>>>>>> able > >>>>>>>>> to remove them in a future version? > >>>>>>> > >>>>>>> I guess so, > >>>>>>> The question is, are there other location where the status > >>>>>>> property > >>>>>>> (or any other property) exists at an irrelevant level. Unless > >>>>>>> we > >>>>>>> want to go into the effort of mapping them all now we > >>>>>>> probably need > >>>>>>> to define a concept and anything not complying to that is a > >>>>>>> bug that > >>>>>>> is allowed to be fixed without considering it as breaking the > >>>>>>> API. > >>>>>>> > >>>>>>> Thoughts? > >>>>>>> > >>>>> +1 > >>>>> I agree that this is a bug and I DO suggest we go into the > >>>>> effort of reviewing the other objects as well. > >>>>> This is too major to just fix this one, and wait until we bump > >>>>> into another one... > >>> Mike i see there a general consensus that this is a bug and the > >>> top > >>> level entity should be a DC network. > >> > >> i disagree that <status> should be completely removed, instead as > >> bug fix it > >> should contain different members: ATTACHED|UNATTACHED (same > >> concept we using in > >> /api/storagedomains/xxx) > > > > first you agree we should remove the status as it is today as it > > does > > not indicate anything to the user. > > http://lists.ovirt.org/pipermail/engine-devel/2012-July/002009.html > > > > > second you suggest that we'll add attached unattached status, I > > don't > > see value in it unless you specify the clusters it is attached to > > as a > > sub - collection, I don't see us getting to this anytime soon. > > exactly on opposite, if network would have /clusters links > sub-collection, > <status>attached|unattached<status> will not be needed as it obvious > by > absence or existence of clusters links in sub-collection, > > the use-case is: when you have N networks in DC and want to find > unused one > to attach it to cluster. > > (without this <status> you'll have to traverse over all networks > against all > clusters to find one unused)
Previous email sent in delay due to network disconnection, So we are saying the same, that the status if left de facto indicates used/unused so why not to use the proper terminology? attached is already an over loaded term > > > > > we can always add it later and it does not change the fact that the > > API > > the solution is very simple and does not require any resources: > > 1. to enum NetworkStatus add new (default) member UNATTACHED > 2. clients will show UNATTACHED if NetworkStatus == UNATTACHED > or ATTACHED otherwise > > > changes. > > > > > >> > >>> Can you please open a bug / update the existing bug to reflect > >>> that. > >>> > >>> Thanks, Livnat > >>> > >>> > >>> > >> > >> > > > > > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > _______________________________________________ > Engine-devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
