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

[Michael Pasternak]

On 07/05/2012 12:00 PM, Simon Grinberg wrote:
> 
> 
> ----- 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:31:41 AM
>> Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks
>>
>> 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)
> 
> With storage domains attached/unattached is generally a 1:1 so it may make sense in a way.
> * not sure it's going to be in the future with shared read only export domain
> * It's probably wrong even today with ISO domain in case that the setup contains more then one DC.

attached|unattached does not imply on amount of resources it being used in,
only used/not-used

> 
> With Networks it fore may be attached to partial collection on clusters, de facto that will only say it is in uses by at least one cluster.

that's the purpose, see my other email (to Livnat) on this.

> 
> So in both cases this is wrong, 

why? i'd say it's exactly serve the goal.

> 
> If you insist on maintaining this property the only valid values that I can see ATM is INUSE vs UNUSED. - This should be true both for storage domains and logical networks. 

i don't mind, only problem is that SD uses UNATTACHED and you told by yourself
that it's 1:1, so i guess we won't break SD api for consistency ...

> 
> 
>>
>>> 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
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D