12:06 p.m.
On 05/07/12 11:56, Michael Pasternak wrote:
On 07/05/2012 11:40 AM, Livnat Peer wrote:
> 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.
http://lists.ovirt.org/pipermail/engine-devel/2012-July/002009.html
>
> 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.
exactly on opposite, if network would have /clusters links sub-collection,
<status>attached|unattached<status> will not be needed as it obvious by
absence or existence of clusters links in sub-collection,
the use-case is: when you have N networks in DC and want to find unused one
to attach it to cluster.
I don't see the logic in this use case, you don't attach a network to a
cluster because it is unused, you attach it because you want to use it,
having it attached to another cluster does not make much of a difference.
I don't see the need for the attached/detached property.
I do think that adding a sub-collection of attached cluster can give
some value to the user but again not an immediate action.
(without this <status> you'll have to traverse over all
networks against all
clusters to find one unused)
>
> we can always add it later and it does not change the fact that the API
the solution is very simple and does not require any resources:
1. to enum NetworkStatus add new (default) member UNATTACHED
2. clients will show UNATTACHED if NetworkStatus == UNATTACHED
or ATTACHED otherwise
> changes.
>
>
>>
>>> Can you please open a bug / update the existing bug to reflect that.
>>>
>>> Thanks, Livnat
>>>
>>>
>>>
>>
>>
>
>