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

[Igor Lvovsky]

> -----Original Message-----
> From: engine-devel-bounces at ovirt.org
[mailto:engine-devel-bounces at ovirt.org]
> On Behalf Of Livnat Peer
> Sent: Thursday, July 05, 2012 1:39 PM
> To: Mike Kolesnik
> Cc: engine-devel; Simon Grinberg
> Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying
of
> logical networks
> 
> On 05/07/12 13:23, Mike Kolesnik wrote:
> >> On 07/05/2012 12:19 PM, Livnat Peer wrote:
> >>>> I'll give you one scenario and I'm sure there are lot more:
> >>>>> delete all unused networks ....
> >>>>>
> >>> not strong enough use case in my opinion
> >>
> >> i do see sense in this, and based on my experience of closing ~5 bugs
> >> on this for SD and explaining like
> >> ~10 times on ML to users why /api/storagedomains/xxx doesn't have
> >> <status>, I'm sure it should be done this way as it creates clear
> >> differentiation between root-resource and cluster-resource (shared)
> >> status.
> >>
> >>> to add this yet another confusing property.
> >>
> >> you not adding another property, you fix existent (which was
> >> incorrectly used/implemented).
> >>
> >>>
> >>> BTW - If a requirement will get from the field to add properties we
> >>> can do them later why add something we think is not needed.
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Michael Pasternak
> >> RedHat, ENG-Virtualization R&D
> >>
> >
> > I think we got a little bit off the topic here, so if you don't mind I
would
> like to see if everyone agrees on this:
> >
> > We have at the api/networks collection these properties and their
possible
> values:
> >   status - OPERATIONAL, NON_OPERATIONAL
> >   display - true, false
> >
> > We (as far as I understood) agreed that these fields causea problem in
this
> context since they can be different for a given network, and current
> representation will return the network element multiple times with only
> difference in either one of these fields.
> > Also I understood we agreed that this is bad behaviour (even a bug)
and we
> don't want to support this anymore.
> >
> > This gives 2 choices IMHO:
> >   1. Fix the behaviour but keep the fields with some default values.
> >   2. Fix the behaviour and remove these field as well, which isn't
really
> breaking an API since the behaviour was broken to begin with.
> >
> 
> So a summary of the thread so far:
> 
> Simon, Miki Ori and me voted +1 for option #2
> 
> Michael wants to change the value of the status field to attach/detach
> 
> Anyone else wants to vote in on this?
> 

It seems like #2 is more reasonable. +1 for #2

> 
> > Please comment what option seems valid (I though we were going to the
> direction of fix #2).
> >
> > Thanks,
> > Mike
> >
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel