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