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

[Livnat Peer]

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.

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.

we can always add it later and it does not change the fact that the API
changes.


> 
>> Can you please open a bug / update the existing bug to reflect that.
>>
>> Thanks, Livnat
>>
>>
>>
> 
>