11:56 a.m.
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.
(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
>>
>>
>>
>
>
--
Michael Pasternak
RedHat, ENG-Virtualization R&D