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

[Simon Grinberg]

----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Simon Grinberg" <simon at redhat.com>
> 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
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>