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