Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...

[Livnat Peer]

On 04/02/2014 09:06 AM, Moti Asayag wrote:
> 
> 
> - Original Message -
>> From: "Eli Mesika" 
>> To: engine-devel@ovirt.org
>> Sent: Thursday, March 27, 2014 1:43:22 PM
>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to 
>> decrease DC compatibility...
>>
>>
>>
>> - Original Message -
>>> From: "Moti Asayag" 
>>> To: "Itamar Heim" 
>>> Cc: "Eli Mesika" , engine-devel@ovirt.org
>>> Sent: Sunday, March 23, 2014 2:47:53 PM
>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to
>>> decrease DC compatibility...
>>>
>>>
>>>
>>> - Original Message -
>>>> From: "Itamar Heim" 
>>>> To: "Eli Mesika" , engine-devel@ovirt.org
>>>> Sent: Sunday, March 23, 2014 12:14:37 PM
>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>>> to
>>>> decrease DC compatibility...
>>>>
>>>> On 03/23/2014 12:13 PM, Eli Mesika wrote:
>>>>>
>>>>> So, as far a I understand for resolving this bug the following is OK :
>>>>>
>>>>> Block downgrading if there are Hosts or Networks (other than the
>>>>> default
>>>>> management network) or SD in the DC when downgrading.
>>>>
>>>> yes
>>>>
>>>
>>> I don't think it is enough. There is a need to verify the management
>>> network
>>> wasn't modified to use unsupported features in the new data-center.
>>>
>>> On the same matter, we can allow downgrading if all of the networks in the
>>> data center are using only features that are supported on the target DC
>>> version
>>> and not to restrict it only to the management network.
>>
>> Since Moti is in PTO, talked with Mike K to get advanced with that , we came
>> to the following conclusion:
>>
>> when DC is downgraded :
>>  Block downgrading if there are Hosts or Networks (other than the default
>>  management network) or SD in the DC.
>>  In case that only default management network exists we should check that all
>>  network features are still supported (This can be done by adding a method
>>  to the NetworkValidator that will check for support of all relevant
>>  features)
>>
>> when Cluster is downgraded :
>>  Same as above , but we don't need to check for features validation since we
>>  can not downgrade below the DC version and therefor the cluster network is
>>  supposed to be valid already
>>
>> Mike, please let me know If I miss something from our discussion (and thanks
>> for your kind help :-) )
> 
> +1 from me and Mike for the above.
> 

Eli -
please note there is no need to block the DC downgrade if there are
hosts in the DC.

Thanks, Livnat


>>
>>>
>>>>>
>>>>>
>>>>> - Original Message -
>>>>>> From: "Livnat Peer" 
>>>>>> To: "Moti Asayag" 
>>>>>> Cc: engine-devel@ovirt.org
>>>>>> Sent: Friday, March 21, 2014 8:33:59 AM
>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>>> enable
>>>>>> to decrease DC compatibility...
>>>>>>
>>>>>> On 03/20/2014 09:20 PM, Moti Asayag wrote:
>>>>>>> - Original Message -
>>>>>>>> From: "Moti Asayag" 
>>>>>>>> To: "Livnat Peer" 
>>>>>>>> Cc: "Itamar Heim" , engine-devel@ovirt.org
>>>>>>>> Sent: Wednesday, March 12, 2014 10:44:07 PM
>>>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>>>>> enable
>>>>>>>> to decrease DC compatibility...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> - Original Message -
>>>>>>>>> From: "Livnat Peer" 
>>>>>>>>> To: "Moti Asayag" 
>>>>>>>>> Cc: "Itamar Heim" , engine-devel@ovirt.org
>>>>>>>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
>>>>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>>>>>> enable
&

Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...

[Livnat Peer]

On 03/23/2014 01:39 PM, Itamar Heim wrote:
> On 03/23/2014 01:13 PM, Livnat Peer wrote:
>> On 03/23/2014 01:10 PM, Itamar Heim wrote:
>>> On 03/23/2014 12:25 PM, Livnat Peer wrote:
>>>> On 03/23/2014 12:13 PM, Eli Mesika wrote:
>>>>>
>>>>> So, as far a I understand for resolving this bug the following is OK :
>>>>>
>>>>> Block downgrading if there are Hosts or Networks (other than the
>>>>> default management network) or SD in the DC when downgrading.
>>>>>
>>>>
>>>>
>>>> Why does having hosts should prevent us from downgrading the DC level?
>>>
>>> tomorrow you may have hosts which won't support an older cluster.
>>
>> Host are associated with a cluster, how can downgrading of DC level
>> impact the existing hosts? DC downgrade does not downgrade the clusters
>> level.
>>
> 
> well, you are kind of explaining why this can't happen...
> a DC can only be upgraded if all Clusters have already been upgraded.
> hence a DC can only be downgraded if it has no clusters, hence no hosts.
> (because to downgrade the DC, the clusters would have to be downgraded
> first, and you can't have a cluster lower than the DC...)

The only rule we enforce today is -

DC level <= Cluster level : for all clusters in the DC

Thus you can downgrade the DC with clusters in it with no effect on the
clusters or the hosts.
The clusters do not need to be downgraded.


> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...

[Livnat Peer]

On 03/23/2014 01:10 PM, Itamar Heim wrote:
> On 03/23/2014 12:25 PM, Livnat Peer wrote:
>> On 03/23/2014 12:13 PM, Eli Mesika wrote:
>>>
>>> So, as far a I understand for resolving this bug the following is OK :
>>>
>>> Block downgrading if there are Hosts or Networks (other than the
>>> default management network) or SD in the DC when downgrading.
>>>
>>
>>
>> Why does having hosts should prevent us from downgrading the DC level?
> 
> tomorrow you may have hosts which won't support an older cluster.

Host are associated with a cluster, how can downgrading of DC level
impact the existing hosts? DC downgrade does not downgrade the clusters
level.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...

[Livnat Peer]

On 03/23/2014 12:13 PM, Eli Mesika wrote:
> 
> So, as far a I understand for resolving this bug the following is OK :
> 
> Block downgrading if there are Hosts or Networks (other than the default 
> management network) or SD in the DC when downgrading.
>  


Why does having hosts should prevent us from downgrading the DC level?

> 
> - Original Message -----
>> From: "Livnat Peer" 
>> To: "Moti Asayag" 
>> Cc: engine-devel@ovirt.org
>> Sent: Friday, March 21, 2014 8:33:59 AM
>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to 
>> decrease DC compatibility...
>>
>> On 03/20/2014 09:20 PM, Moti Asayag wrote:
>>> - Original Message -
>>>> From: "Moti Asayag" 
>>>> To: "Livnat Peer" 
>>>> Cc: "Itamar Heim" , engine-devel@ovirt.org
>>>> Sent: Wednesday, March 12, 2014 10:44:07 PM
>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>>> to decrease DC compatibility...
>>>>
>>>>
>>>>
>>>> - Original Message -
>>>>> From: "Livnat Peer" 
>>>>> To: "Moti Asayag" 
>>>>> Cc: "Itamar Heim" , engine-devel@ovirt.org
>>>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>>>> to
>>>>> decrease DC compatibility...
>>>>>
>>>>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
>>>>>>
>>>>>>
>>>>>> - Original Message -
>>>>>>> From: "Livnat Peer" 
>>>>>>> To: "Itamar Heim" , engine-devel@ovirt.org
>>>>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
>>>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core:
>>>>>>> enable
>>>>>>> to  decrease DC compatibility...
>>>>>>>
>>>>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
>>>>>>>> On 03/12/2014 12:26 AM, emes...@redhat.com wrote:
>>>>>>>>> Eli Mesika has submitted this change and it was merged.
>>>>>>>>>
>>>>>>>>> Change subject: core: enable to decrease DC compatibility...
>>>>>>>>> ..
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> core: enable to decrease DC compatibility...
>>>>>>>>>
>>>>>>>>> enable to decrease DC compatibility version if DC has no clusters
>>>>>>>>>
>>>>>>>>> This patch enables to decrease the DC compatibility version if DC has
>>>>>>>>> no
>>>>>>>>> clusters.
>>>>>>>>
>>>>>>>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a
>>>>>>>> DC
>>>>>>>> version if it has storage domains as well. not sure if this is checked
>>>>>>>> already or not.
>>>>>>>>
>>>>>>>> may also be an issue with some logical network features.
>>>>>>>>
>>>>>>>
>>>>>>> Most of the network features are driven from cluster level, we enable
>>>>>>> using the features on all DC level (actually >=3.1) but actually enable
>>>>>>> /disable the feature when attaching the network to a cluster.
>>>>>>>
>>>>>>> So from network perspective I think it should be fine to downgrade the
>>>>>>> DC level even if there are networks in the DC (at least now this could
>>>>>>> change in future versions).
>>>>>>>
>>>>>>
>>>>>> Actually we block adding or updating networks if the feature is not
>>>>>> supported
>>>>>> on the network's DC level, for example: STP, Jumbo frames and non-vm
>>>>>> network.
>>>>>>
>>>>>
>>>>> From which DC level we support STP?  Jumbo frames? non-vm network? isn't
>>>>> all of them supported in >=3.1 ?
>>>>>
>>>>
>>>> Yes, mainly the problem with dow

Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...

[Livnat Peer]

On 03/20/2014 09:20 PM, Moti Asayag wrote:
> - Original Message -
>> From: "Moti Asayag" 
>> To: "Livnat Peer" 
>> Cc: "Itamar Heim" , engine-devel@ovirt.org
>> Sent: Wednesday, March 12, 2014 10:44:07 PM
>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to 
>> decrease DC compatibility...
>>
>>
>>
>> - Original Message -
>>> From: "Livnat Peer" 
>>> To: "Moti Asayag" 
>>> Cc: "Itamar Heim" , engine-devel@ovirt.org
>>> Sent: Wednesday, March 12, 2014 10:33:45 PM
>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to
>>> decrease DC compatibility...
>>>
>>> On 03/12/2014 10:20 PM, Moti Asayag wrote:
>>>>
>>>>
>>>> - Original Message -
>>>>> From: "Livnat Peer" 
>>>>> To: "Itamar Heim" , engine-devel@ovirt.org
>>>>> Sent: Wednesday, March 12, 2014 12:42:44 PM
>>>>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable
>>>>> todecrease DC compatibility...
>>>>>
>>>>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
>>>>>> On 03/12/2014 12:26 AM, emes...@redhat.com wrote:
>>>>>>> Eli Mesika has submitted this change and it was merged.
>>>>>>>
>>>>>>> Change subject: core: enable to decrease DC compatibility...
>>>>>>> ..
>>>>>>>
>>>>>>>
>>>>>>> core: enable to decrease DC compatibility...
>>>>>>>
>>>>>>> enable to decrease DC compatibility version if DC has no clusters
>>>>>>>
>>>>>>> This patch enables to decrease the DC compatibility version if DC has
>>>>>>> no
>>>>>>> clusters.
>>>>>>
>>>>>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a
>>>>>> DC
>>>>>> version if it has storage domains as well. not sure if this is checked
>>>>>> already or not.
>>>>>>
>>>>>> may also be an issue with some logical network features.
>>>>>>
>>>>>
>>>>> Most of the network features are driven from cluster level, we enable
>>>>> using the features on all DC level (actually >=3.1) but actually enable
>>>>> /disable the feature when attaching the network to a cluster.
>>>>>
>>>>> So from network perspective I think it should be fine to downgrade the
>>>>> DC level even if there are networks in the DC (at least now this could
>>>>> change in future versions).
>>>>>
>>>>
>>>> Actually we block adding or updating networks if the feature is not
>>>> supported
>>>> on the network's DC level, for example: STP, Jumbo frames and non-vm
>>>> network.
>>>>
>>>
>>> From which DC level we support STP?  Jumbo frames? non-vm network? isn't
>>> all of them supported in >=3.1 ?
>>>
>>
>> Yes, mainly the problem with downgrading a DC to 3.0.
>>
> 
> I had a discussion with Mike (cc'ed) about several possible solutions
> for the networks compatibility within the data-center.
> 
> The first proposed solution would utilize the NetworkUpdateValidator,
> a validation utility that verifies the compatibility of a network
> to the data-center. This solution preserves the same behaviour as today,
> that the features of network-level are dictated by the DC version. No
> need to reimplement any logic in the decrease DC version flow, just use
> an existing one to be applied for any network within the DC.
> 
> The second solution suggests we allow any settings of a network, and 
> compatibility enforcement is done on attaching the network to the clusters.
> This modifies the existing behaviour and expands the capabilities of the
> engine to support advanced network feature in advanced cluster within an
> old data center (i.e. cluster 3.4 in 3.0 data-center could and probably
> should use non-vm network, jumbo-frames and more).
> This option requires more work in add/update network and attach network to 
> cluster
> flows, both on the backend and UI. Specifically since by default a new network
> created in a DC is being attached to all of the cluste

Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...

[Livnat Peer]

On 03/12/2014 10:20 PM, Moti Asayag wrote:
> 
> 
> - Original Message -
>> From: "Livnat Peer" 
>> To: "Itamar Heim" , engine-devel@ovirt.org
>> Sent: Wednesday, March 12, 2014 12:42:44 PM
>> Subject: Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to  
>> decrease DC compatibility...
>>
>> On 03/12/2014 11:59 AM, Itamar Heim wrote:
>>> On 03/12/2014 12:26 AM, emes...@redhat.com wrote:
>>>> Eli Mesika has submitted this change and it was merged.
>>>>
>>>> Change subject: core: enable to decrease DC compatibility...
>>>> ..
>>>>
>>>>
>>>> core: enable to decrease DC compatibility...
>>>>
>>>> enable to decrease DC compatibility version if DC has no clusters
>>>>
>>>> This patch enables to decrease the DC compatibility version if DC has no
>>>> clusters.
>>>
>>> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC
>>> version if it has storage domains as well. not sure if this is checked
>>> already or not.
>>>
>>> may also be an issue with some logical network features.
>>>
>>
>> Most of the network features are driven from cluster level, we enable
>> using the features on all DC level (actually >=3.1) but actually enable
>> /disable the feature when attaching the network to a cluster.
>>
>> So from network perspective I think it should be fine to downgrade the
>> DC level even if there are networks in the DC (at least now this could
>> change in future versions).
>>
> 
> Actually we block adding or updating networks if the feature is not supported
> on the network's DC level, for example: STP, Jumbo frames and non-vm network.
> 

>From which DC level we support STP?  Jumbo frames? non-vm network? isn't
all of them supported in >=3.1 ?

> Therefore if the management network was configured with any of those feature,
> there is a need to either block the action or to 'initialize' the network to
> the default settings (as new network being added).
> 
>> In general I believe the use case for this patch is mostly for empty DCs
>> so for simplicity we should block it if there are networks or SD in the
>> DC when downgrading.
>>
>> Livnat
>>
>>
>>>>
>>>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
>>>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
>>>> Signed-off-by: Eli Mesika 
>>>> ---
>>>> M
>>>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
>>>>
>>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>>
>>>> Approvals:
>>>>Eli Mesika: Verified
>>>>Ravi Nori: Looks good to me, but someone else must approve
>>>>Yair Zaslavsky: Looks good to me, approved
>>>>
>>>>
>>>>
>>>
>>
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...

[Livnat Peer]

On 03/12/2014 12:47 PM, Itamar Heim wrote:
> On 03/12/2014 12:42 PM, Livnat Peer wrote:
>> In general I believe the use case for this patch is mostly for empty DCs
>> so for simplicity we should block it if there are networks or SD in the
>> DC when downgrading.
> 
> other than ovirt/rhevm one of course.

of course, the management network which is automatically created when
creating the DC can be there.

> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Change in ovirt-engine[master]: core: enable to decrease DC compatibility...

[Livnat Peer]

On 03/12/2014 11:59 AM, Itamar Heim wrote:
> On 03/12/2014 12:26 AM, emes...@redhat.com wrote:
>> Eli Mesika has submitted this change and it was merged.
>>
>> Change subject: core: enable to decrease DC compatibility...
>> ..
>>
>>
>> core: enable to decrease DC compatibility...
>>
>> enable to decrease DC compatibility version if DC has no clusters
>>
>> This patch enables to decrease the DC compatibility version if DC has no
>> clusters.
> 
> Eli - just saw this. I'm pretty sure it would be *bad* to downgrade a DC
> version if it has storage domains as well. not sure if this is checked
> already or not.
> 
> may also be an issue with some logical network features.
> 

Most of the network features are driven from cluster level, we enable
using the features on all DC level (actually >=3.1) but actually enable
/disable the feature when attaching the network to a cluster.

So from network perspective I think it should be fine to downgrade the
DC level even if there are networks in the DC (at least now this could
change in future versions).

In general I believe the use case for this patch is mostly for empty DCs
so for simplicity we should block it if there are networks or SD in the
DC when downgrading.

Livnat


>>
>> Change-Id: I73284f641b7f80b380b39efbbd7b4566f55119b6
>> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1057029
>> Signed-off-by: Eli Mesika 
>> ---
>> M
>> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/storage/UpdateStoragePoolCommand.java
>>
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> Approvals:
>>Eli Mesika: Verified
>>Ravi Nori: Looks good to me, but someone else must approve
>>Yair Zaslavsky: Looks good to me, approved
>>
>>
>>
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Network labeling requirements follow up questions

[Livnat Peer]

On 01/08/2014 06:18 PM, Malini Rao wrote:
> [top posting] 
> 
> Based on your responses then, we need to tweak Eldan's sketch  - see 
> attached. 
> 
> Here, you will see I have two tabs on the right - Unassigned networks and 
> Labels. Unassigned networks will list individual networks that have not been 
> assigned either manually or as part of a label. If a network has been 
> assigned to a NIC as apart of a label, it will still show up on the 
> unassigned networks list but if the user tries to assign that network to that 
> same NIC, then the UI will not allow that and a message will pop-up stating 
> ' is already assigned to this NIC". Does this make sense? Or do 
> we allow network sharing only via Bonding? I.e, if NIC 1 is assigned Label1 ( 
> Blue, yellow, Green) and I want to assign NIC2 to Blue only, would I drag 
> Blue from unassigned networks ( even t hoguh blue is assigned via label 1 to 
> another NIC) or do I drag NIC 2 to NIC 1 and create a bond which presents me 
> an option to use all 3 or select from the list of networks attached to NIC1?
> 
> Going back to my mockup, you will also see an attachment for the unassigned 
> Labels tab where you see the labels, the networks associated with them so 
> that you don't have to drag it to the left in order to see what networks live 
> in that label. I have retained Eldan's Manage labels action link too.
> 
> Let me know if this makes sense.
> 

Hi Malini,
We are currently using the idea of labels as an aggregation object and
tried to capture that in the UI approach we are taking.

Lior would add screen shots of the approach later today or early next
week and we can start a discussion based on his current work.

Livnat

> Thanks
> Malini
> 
> 
> 
> - Original Message -
> From: "Livnat Peer" 
> To: "Malini Rao" 
> Cc: "Eldan Hildesheim" , "Dan Kenigsberg" 
> , "Moti Asayag" , "Lior Vernia" 
> , "engine-devel" 
> Sent: Wednesday, January 8, 2014 3:41:29 AM
> Subject: Re: Network labeling requirements follow up questions
> 
> On 01/07/2014 11:46 PM, Malini Rao wrote:
>> Livnat, 
>>
>> I had asked a couple of questions about network labeling reqs offline but 
>> wanted to continue the discussion on the list. Thank you for the answers and 
>> I have copied my questions and your answers for context -
>>
>> 1. Can a network be part of several labels?
>> Currently not, we are not sure if there is a use case for that ATM, but
>> I hope users would surprise us with an interesting use case.
>>
>> 2. Can a network exist as a available network in the Setup Host networks 
>> dialog on its own even if it is part of a label? i.e, can a network be 
>> assigned to a NIC on its own and to another NIC as part of a label?
>>
>> Network can not be provisioned twice on the same host (regardless of labels).
>>
>> With regard to your answer to my question 2, I understand that the network 
>> cannot be provisioned twice on the same host but it can be provisioned to 
>> multiple hosts... right? 
>>
>> So, Let's say the Green network is part of a label called label 1 which also 
>> includes yellow and red networks, and let's say Host 1 is provisioned using 
>> label 1 and so it can use green, yellow and red networks.
> 
>> For Host 2, can I provision with just Green rather than with Label 1? 
> 
> yes
> 
>> Or can a network be used only once in a label and across hosts?
> 
> label is just a tool to ease network provisioning on the host, you can
> always use 'manual' actions to provision the networks.
> 
> Hope that clarifies, I'll be happy to answer more questions if you have any.
> 
> Livnat
> 
> 
>>
>>
>> Thanks
>> Malini
>>
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Network labeling requirements follow up questions

[Livnat Peer]

On 01/07/2014 11:46 PM, Malini Rao wrote:
> Livnat, 
> 
> I had asked a couple of questions about network labeling reqs offline but 
> wanted to continue the discussion on the list. Thank you for the answers and 
> I have copied my questions and your answers for context -
> 
> 1. Can a network be part of several labels?
> Currently not, we are not sure if there is a use case for that ATM, but
> I hope users would surprise us with an interesting use case.
> 
> 2. Can a network exist as a available network in the Setup Host networks 
> dialog on its own even if it is part of a label? i.e, can a network be 
> assigned to a NIC on its own and to another NIC as part of a label?
> 
> Network can not be provisioned twice on the same host (regardless of labels).
> 
> With regard to your answer to my question 2, I understand that the network 
> cannot be provisioned twice on the same host but it can be provisioned to 
> multiple hosts... right? 
>
> So, Let's say the Green network is part of a label called label 1 which also 
> includes yellow and red networks, and let's say Host 1 is provisioned using 
> label 1 and so it can use green, yellow and red networks.

> For Host 2, can I provision with just Green rather than with Label 1? 

yes

> Or can a network be used only once in a label and across hosts?

label is just a tool to ease network provisioning on the host, you can
always use 'manual' actions to provision the networks.

Hope that clarifies, I'll be happy to answer more questions if you have any.

Livnat


> 
> 
> Thanks
> Malini
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Lior Vernia as ovirt-UI maintainer

[Livnat Peer]

I'd like to propose Lior Vernia as a ovirt-UI maintainer.

Lior Vernia has been working on the UI for over a year, with a lot of
dedication enthusiasm and motivation.
He has more than 140 UI patches merged and hopefully many more in the
pipeline :)


Thanks, Livnat
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] VNIC profiles

[Livnat Peer]

On 07/08/2013 12:36 AM, Moti Asayag wrote:
> I've updated the wiki accordingly and added few comments inline.
> 
> - Original Message -----
>> From: "Livnat Peer" 
>> To: "Moti Asayag" 
>> Cc: "engine-devel" , "Ofri Masad" 
>> , "Mike Kolesnik" ,
>> "Oved Ourfalli" 
>> Sent: Sunday, July 7, 2013 2:59:34 PM
>> Subject: Re: VNIC profiles
>>
>> On 07/07/2013 01:59 PM, Moti Asayag wrote:
>>> Hi,
>>>
>>> I've updated the wiki with the feedbacks from this thread, added a backend
>>> section naming the affected commands and also add added few questions of
>>> my own embedded in the pastedtext below.
>>>
>>
>> Hi Moti,
>> A good and comprehensive description of the feature behavior.
>> See my comments bellow -
>>
>>> In addition, another question here:
>>>
>>> The units within the UI mockups are Mb and Mbps. The libvirt APIs expects
>>> the units to be in kb and kbps. Which component is responsible to convert
>>> them to the expect units ? engine or VDSM ?
>>
>> Giuseppe mentioned that in a previous thread on this subject.
>> Ofri and Giuseppe agreed that the translation would be done on the
>> engine level.
>>
>>
>>>
>>> Copied text from the wiki:
>>>
>>> Adding a Profile
>>>
>>> The network administrator could create several VNIC Profiles for each
>>> network. He could then grant a users with the permission to use (consume)
>>> each profile. The user will only be able to use profiles which he was
>>> granted access to.
>>>
>>> For example: the network admin will create two VNIC profiles for
>>> network "blue":
>>>
>>> Profile "Gold" - with better QoS and with port mirroring
>>> Profile "Silver" with lower QoS and without port mirroring.
>>>
>>
>> I would use other names for the profiles to avoid confusion.
>> Gold and Silver are likely to be QoS object names,  a more typical name
>> for a network profile is - teachers-blue and students-blue
>>
>> The different profiles can have different QoS (teachers-blue would get
>> Gold QoS while Students-blue will have Silver).
>>
>>
>>> He will then define the user-group "students" as user of profile
>>> "Silver" and user-group "teachers" as user of profile "Gold". In this
>>> case the teachers will enjoy better quality of service then the
>>> students. When a teacher will add/edit a virtual NIC he could select
>>> profile "Gold" for that NIC - the VNIC will be connected to network
>>> "blue" with high QoS and with port mirroring.
>>>
>>> Question: In the same matter we allowed via the UI to grant 'NetworkUser'
>>> to 'everyone' user, wouldn't it ease the use of Profiles if we support it
>>> in this context as well?
>>
>> The ease of use could be that when creating a network we'll display in
>> the UI all VNIC-QoS-objects and the users could tick next to the QoS
>> they are interested in, for each QoS that was chosen a profile would be
>> created.
>>
>> I would enhance that with youe suggestion above and display next to the
>> QoS that was checked the option to mark 'Allow All users' like we have
>> today for making a network public, this option would give permission to
>> everyone on that profile.
>>
>>
>>>
>>> Editing a Profile
>>>
>>> A user should be able to edit the profile properties (including profile
>>> name) while VMs are attached and are using this Profile (reference
>>> should be done by id).
>>> Changing the network of a vNic profile will be allowed only if no VMs
>>> are using the profile.
>>
>> It would be better if we can limit this to no running VM is using the
>> profile (or more simple to implement if all VMs that are using this
>> profile are in status down).
> 
> Allowing to delete a vnic profile when used by vms is asymmetric to the 
> network removal
> when it is used by vms or templates. Today the update network operation is 
> blocked for that.
> In addition, with the suggest simplification to remove a profile when no 
> running vms, the user
> will have to find for himself if the profile is being used prior to its 
> removal since the 
> operation will not be blocked.
> 
>

Re: [Engine-devel] VNIC profiles

[Livnat Peer]

VNIC Profiles could not be deleted from the engine as long as one or more 
> VM/Templates are using those profiles.

> Reporting vNic actual configuration
> 
> The engine will retrieve the actual configuration of the profile 
> properties on the VNIC from VDSM (using the network statistics mechanism) and 
> the networked administrator will be presented with the state of each VNIC 
> (synched/unsynched). 
> 

Will the admin be able to see the actual values? I think the synced
property is not enough (I'm not sure how interesting this property is to
start with).

> Editing a VNIC / Changing a VNIC profile
> 
> Changing the profile a VM is using while the VM is running should behave 
> like dynamic wiring (changing the VM network while it is running).
> Hot-plug of a vnic will will use will use the updated profile connected 
> to the VNIC. 
> 

Not sure I fully understand the sentence above.
Hot plug will be fully supported, you can choose any profile (you have
permissions on) while plugging a new device.

> Adding a Network
> 
> When adding a network, a user can provide an option to create a vNic 
> Profile for it. 
> 
> Question: Is it s default profile ? what are its properties ?
> Question: What about 'Public Use' option ? Are they still relevant in the 
> context of adding new networks or we should eliminate them and move it only 
> to 'Add vNic Profile' dialog?
> 

see previous comments
In addition when creating a profile we should have 'Allow all' for
implicitly creating permissions, like we have today for network.

> Updating a Network
> 
> When a network role is modified to be a 'non-VM network', all vNic profiles 
> associated with it should be deleted.

And permissions associated with these profiles

> Removing a Network
> 
> Should remove all profiles on that network 
> 

And associated permissions

> Adding an Empty Data-Center
> 
> Currently, When creating a new Data-Center, the management network is 
> automatically created.
> From 3.3, a default vNic profile will be created for the management 
> network. 
> 
> VM snapshot/import/export
> 
> We should handle VMs that are pointing to a network directly for backward 
> compatibility.
> We need to select first profile that is on that network that the user has 
> permissions on. 
> 
> Question: Do we wish to support it export from 3.3 and import to 3.2 or below?

That means that when you write a VM in the OVF you need to write network
in addition to profile.


> Question: A user can import/export a VM/Template even if he doesn't have 
> permissions on the networks. Is the next flow valid ?
> 
> The profile name should be saved in the OVF (in addition to the network 
> name which is saved today).
> During import, if both (network name, profile name) exist on the target 
> DC, the vnic will get the profile id.
> If the network exists in the Data-Center, but has no profile as specified 
> in the OVF, the user will be notified (event log) and the VNIC will be 
> connected to a default minimal profile defined in the system, regardless the 
> permissions the user has on the network. 
> 

What is a 'default minimal profile' ? I would rather have a VNIC with no
profile associated with it.

> If failed to find any matching vNic profile, the vnic's profile will be set 
> with 'none'.
> 
> When a Template is created from a VM the VNIC Profile will be kept along 
> with the VNIC. When a VM is created from template the VNIC Profiles will be 
> taken from the template's VNICs. 
> 
> - Original Message -
>> From: "Livnat Peer" 
>> To: "engine-devel" , "Ofri Masad" 
>> Cc: "Mike Kolesnik" , "Moti Asayag" 
>> , "Oved Ourfalli" 
>> Sent: Sunday, June 30, 2013 3:59:37 PM
>> Subject: VNIC profiles
>>
>> Hi,
>>
>> We are working on adding VNIC profiles as part of the work to add VNIC QoS.
>>
>> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
>>
>> We need to define some of the system behavior followed by this change,
>> here is my take -
>>
>> Editing a profile -
>> 
>> A user should be able to edit the profile properties (including profile
>> name) while VMs are attached and are using this Profile (reference
>> should be done by id).
>>
>> Changing the network though is a bit more tricky as long as we don't
>> have a way to distinguish between running and current configurations I
>> think it could be very confusing to the user. Especially since we
>> support dynamic wiring so the behavi

Re: [Engine-devel] Kudos to Allon Mureinik for his 1, 000 patch merged

[Livnat Peer]

Nice number, +1000
Next milestone 5k :)

Livnat

On 07/04/2013 09:59 PM, Itamar Heim wrote:
> While 1,000 is an arbitrary number, kudos to Allon for his 1,000 patch
> to ovirt-engine repo being merged[1]!
> 
> (yes, a lot of these are cleanup patches, but these matter too).
> 
> Thanks,
>Itamar
> 
> [1] you can use 'git shortlog -sn' to get the full list.
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] VNIC profiles

[Livnat Peer]

On 07/03/2013 07:42 PM, Malini Rao wrote:
> - Original Message -
>> From: "Livnat Peer" 
>> To: "Malini Rao" 
>> Cc: "engine-devel" , "Ofri Masad" 
>> , "Eldan Hildesheim"
>> 
>> Sent: Tuesday, July 2, 2013 2:00:03 AM
>> Subject: Re: [Engine-devel] VNIC profiles
>>
>> On 07/01/2013 09:22 PM, Malini Rao wrote:
>>> Hi Livnat,
>>>
>>> My name is Malini Rao and I am the lead interaction designer dedicated to
>>> RHEV/Ovirt UX from Red Hat and we have another interaction designer Eldan
>>> Hildeshiem who is also focused on RHEV UX.
>>
>> Hi Malini - nice to e-meet you :)
>>
>>> I went over your feature page and in general, the GUI proposals look great.
>>> I do have some quick feedback comments -
>>
>> Just a small credit correction - the feature page is Ofri's feature
>> page, I added some feedback of my own :)
> 
> Sorry about that! Ofri, I look forward to collaborating with you and I hope 
> we can contribute to this feature from the UX/ usability perspective.
> 
>>
>>>
>>> Will there be any predefined profiles available to the users out of the box
>>> in RHEV? Or will they have to define their own?
>>
>> If you start with a clean install setup there are no predefined vNICs
>> profiles.
>>
>> Profiles can be generated in two flows, a user can explicitly generate a
>> profile or when admin network creates a new network he can mark create a
>> profile for this network** in a single action.
>> A VNIC profile is the link between the abstract network entity and the
>> VM which consumes this network.
>>
>> If you upgrade existing setup, in the upgrade process profiles will be
>> created per network and will be attached to the VNICs that are currently
>> using the network.
> 
> So you are saying any VNIC profiles created and the associations with VMS 
> that already exist will be preserved during Upgrades... correct? But none of 
> these need to be pre-defined ( as in something that was available to the user 
> automatically and not via user action)... correct?
> 

correct x2

>>
>> **This is not accurate, the user would be able to check all relevant
>> VNIC-QoS-entities and for each one we need to create a profile.
> 
> So there are two concepts here - VNIC-QoS-entities and VNIC Profiles? 
> 

correct again :)

> 
>>
>>
>>> I am wondering if there are any common standard QoS levels that can be
>>> predefined and the users can get a heeadstart and use or tweak instead of
>>> defining from scratch.
>>
>> That's a very good point.
>> The wiki page is not fully up to date, I think.
>> Ofri wanted to add an entity of VNIC QoS which would be linked from
>> within the VNIC profile.
>>
>> The VNIC QoS entity is located in the entities hierarchy under Data Center.
>>
>> The point you made, I think, is will we have predefined VNIC QoS entities.
>>
>> The Qos entity is tight to the hardware you have in your DC. If you have
>> 10G or 1G Ethernet links the QoS entities would look very different, so
>> I'm not sure what predefined values would look like.
> 
> So are you saying that we can have pre-defined VNIC Qos Entities like Gold, 
> silver etc.

I am saying it is something that Ofri should consider, although I
personally don't think there is an added value in having a pre-defined
VNIC Qos.


> but not VNIC profiles because what is gold for a 10G Ehternet is different 
> from gold for a 1G Ethernet? 

VNIC profile is associated with a specific Network, so technically we
can't have pre-defined profiles as we don't have predefined Networks.
Well, we do have the management network (which is predefined) and for
that we do need to create a predefined profile - Thanks.

This point out another behavior we should document, when removing the
VM-network role from a network we need to remove the profiles associated
with that network. (Moti, can you capture this in the VNIC profile wiki
as well)


> But even if they are different, can the VNIC profiles not also be auto 
> generated based on the Hardware and the VNIC Qos Entities?
> 

I lost you here, can you please elaborate.

>>
>>>
>>> VNIC level QoS dialog
>>>
>>> 1. Will the Outbound and inbound values come with some defaults? Or will
>>> they be empty? Is there a need for any spinners or drop downs for
>>> frequently used values or is it ok to just have fields to type in the
>>> numeric values? Also I am assuming there is some kind of validation to
>>> 

Re: [Engine-devel] SSH Soft Fencing

[Livnat Peer]

Hi Martin,
I have some more questions,
- Do we persist the host root password for this feature?
- If we do, is this feature limited for new hosts, can I provide it for
already existing hosts?
- Do we encrypt this value when storing in the DB?

Thanks, Livnat


On 07/03/2013 02:55 PM, Martin Perina wrote:
> Let's summarize again, SSH Soft Fencing patches has been merged yesterday
> with following functionality:
> 
> 1) For hosts with power management configured, SSH Soft Fencing is the 1st
>fencing stage. If it doesn't help, real fencing will be executed.
> 
> 2) For hosts without power management configured, SSH Soft Fencing is the only
>fencing stage. If it doesn't help, host will become non responsive.
> 
> 3) SSH Soft Fencing is enabled by default, there's no configuration option
>to disable it
> 
> 4) SshSoftFencingCommand option is used to define what command is executed
>during SSH Soft Fencing. It can only be changed manually in database.
> 
> The whole fencing process in oVirt 3.3 is decribed at
> 
> http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3
> 
> 
> 
> Martin Perina
> 
> 
> - Original Message -
>> From: "Michal Skrivanek" 
>> To: engine-devel@ovirt.org
>> Sent: Wednesday, July 3, 2013 12:03:13 PM
>> Subject: Re: [Engine-devel] SSH Soft Fencing
>>
>>
>> On Jul 2, 2013, at 10:44 , Eli Mesika  wrote:
>>
>>>
>>>
>>> - Original Message -
>>>> From: "Livnat Peer" 
>>>> To: "Yair Zaslavsky" 
>>>> Cc: engine-devel@ovirt.org
>>>> Sent: Monday, July 1, 2013 12:57:34 PM
>>>> Subject: Re: [Engine-devel] SSH Soft Fencing
>>>>
>>>> On 07/01/2013 11:27 AM, Yair Zaslavsky wrote:
>>>>>
>>>>>
>>>>> - Original Message -
>>>>>> From: "Martin Perina" 
>>>>>> To: engine-devel@ovirt.org
>>>>>> Sent: Monday, July 1, 2013 11:23:12 AM
>>>>>> Subject: Re: [Engine-devel] SSH Soft Fencing
>>>>>>
>>>>>> So let me summarize it:
>>>>>>
>>>>>> We have come to agreement in those questions:
>>>>>>
>>>>>> 1) SSH Soft Fencing logic should be extracted from
>>>>>> VdsNotRespondingTreatment
>>>>>>   command to its own SshSoftFencingCommand
>>>>>>
>>>>>> 2) VdsNotRespondingCommand should be refactored so it's not inherited
>>>>>> from
>>>>>>   VdsRestartCommand, but it should run SshSoftFencingCommand
>>>>>>   or VdsRestartCommand based on defined fencing flow
>>>>>>
>>>>>>
>>>>>> These questions has not been resolved yet:
>>>>>>
>>>>>> 3) Should SSH Soft Fencing be executed also for hosts without PM
>>>>>> configured?
>>>>>>
>>>>>> 4) Should SSH Soft Fencing execution for hosts without PM configured be
>>>>>> enabled
>>>>>>   by default and admin can turn off these feature using configuration
>>>>>>   options
>>>>>>   SshSoftFencingWithoutPmEnabled (or something like that)?
>>>>>>
>>>>>> 5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster
>>>>>> wide
>>>>>>   option (can be turned off for specific cluster version) or a VDS
>>>>>>   option
>>>>>>   (it can be turned off for each host)?
>>>>>>
>>>>>>
>>>>>> Personally I would suggest:
>>>>>>
>>>>>> ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM
>>>>>> configured
>>>>>>
>>>>
>>>>
>>>> +1
>>>>
>>>>>> ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be
>>>>>> enabled by default
>>>>>>
>>>>
>>>> +1
>>>>
>>>>>> ad 5) I don't see any significant reason why someone would like to turn
>>>>>> off
>>>>>> SSH Soft Fencing
>>>>>>   for hosts without PM configured. But if someone would like to do
>>>>>>   that,
>>>>>>   I think
>>>>>>   he would like to turn it off only for specific hosts, so VDS level
>>>>>>   option makes sense
>>>>>>   for me
>>>>>
>>>>> After re-thinking 5 - I agree.
>>>>> +1 on the other suggestions, but of course we need to get more consensus
>>>>> here.
>>>>>
>>>>
>>>> I think it does not need to be configurable.
>>
>> I think a configuration option, as cumbersome and confusing as it can be, is
>> still better than no choice. Especially if it means to restore the previous
>> behavior.
>> If it only can happen in a theoretical problem at customer where vdsm restart
>> cause issues for whatever theoretical reason….it would be of great help
>> then.
>> And if you don't understand the parameter - just don't touch it, I hope
>> that's a general rule:-)
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] VNIC profiles

[Livnat Peer]

On 07/01/2013 09:22 PM, Malini Rao wrote:
> Hi Livnat,
> 
> My name is Malini Rao and I am the lead interaction designer dedicated to 
> RHEV/Ovirt UX from Red Hat and we have another interaction designer Eldan 
> Hildeshiem who is also focused on RHEV UX. 

Hi Malini - nice to e-meet you :)

> I went over your feature page and in general, the GUI proposals look great. I 
> do have some quick feedback comments -

Just a small credit correction - the feature page is Ofri's feature
page, I added some feedback of my own :)

> 
> Will there be any predefined profiles available to the users out of the box 
> in RHEV? Or will they have to define their own? 

If you start with a clean install setup there are no predefined vNICs
profiles.

Profiles can be generated in two flows, a user can explicitly generate a
profile or when admin network creates a new network he can mark create a
profile for this network** in a single action.
A VNIC profile is the link between the abstract network entity and the
VM which consumes this network.

If you upgrade existing setup, in the upgrade process profiles will be
created per network and will be attached to the VNICs that are currently
using the network.

**This is not accurate, the user would be able to check all relevant
VNIC-QoS-entities and for each one we need to create a profile.


> I am wondering if there are any common standard QoS levels that can be 
> predefined and the users can get a heeadstart and use or tweak instead of 
> defining from scratch.

That's a very good point.
The wiki page is not fully up to date, I think.
Ofri wanted to add an entity of VNIC QoS which would be linked from
within the VNIC profile.

The VNIC QoS entity is located in the entities hierarchy under Data Center.

The point you made, I think, is will we have predefined VNIC QoS entities.

The Qos entity is tight to the hardware you have in your DC. If you have
10G or 1G Ethernet links the QoS entities would look very different, so
I'm not sure what predefined values would look like.

> 
> VNIC level QoS dialog
> 
> 1. Will the Outbound and inbound values come with some defaults? Or will they 
> be empty? Is there a need for any spinners or drop downs for frequently used 
> values or is it ok to just have fields to type in the numeric values? Also I 
> am assuming there is some kind of validation to ensure only numbers an be 
> entered in these fields.
> 
> 2. For custom properties, why do we have a drop down? Can custom properties 
> defined elsewhere be accessed here and applied? If not, then I am assuming 
> this will have to be a text field. Correct? Also, I am guessing if there is 
> only one custom property field, the [-] icon will be disabled.
> 
> Edit Network Interface Dialog
> 1. It will be awesome if under the Profile Field value, you can present a 
> short summary of the profile in gray text. alternately, there can be a little 
> info icon which will present this info on hover. This will help people who 
> pick Gold know what that means vs silver or any other profile.
> 
> Besides these specific feedback, I am wondering if any of the VM dialogs are 
> affected by this? Will a VNIC profile field now show up on those dialogs as 
> well? 
> 
> I see you have identified a bunch of open issues to work out and we will be 
> more than happy to help you with the GUI for these flows as needed. Please 
> feel free to reach out to Eldan and me and we can post back to the group with 
> our work.
> 


Thank you Malini for the above feedback, I think these are good questions.

Ofri - can you comment on the above ?

Livnat

> Thanks
> Malini
> 
> 
> 
> 
> - Original Message -
> From: "Livnat Peer" 
> To: "engine-devel" , "Ofri Masad" 
> Sent: Sunday, June 30, 2013 8:59:37 AM
> Subject: [Engine-devel] VNIC profiles
> 
> Hi,
> 
> We are working on adding VNIC profiles as part of the work to add VNIC QoS.
> 
> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
> 
> We need to define some of the system behavior followed by this change,
> here is my take -
> 
> Editing a profile -
> 
> A user should be able to edit the profile properties (including profile
> name) while VMs are attached and are using this Profile (reference
> should be done by id).
> 
> Changing the network though is a bit more tricky as long as we don't
> have a way to distinguish between running and current configurations I
> think it could be very confusing to the user. Especially since we
> support dynamic wiring so the behavior IMO is unpredictable.
> I think it should be blocked at this point.
> 
> 
> Edit a VNIC / change a VNIC profile -
> 
> Changing the profile a VM is

Re: [Engine-devel] SSH Soft Fencing

[Livnat Peer]

On 07/01/2013 11:27 AM, Yair Zaslavsky wrote:
> 
> 
> - Original Message -
>> From: "Martin Perina" 
>> To: engine-devel@ovirt.org
>> Sent: Monday, July 1, 2013 11:23:12 AM
>> Subject: Re: [Engine-devel] SSH Soft Fencing
>>
>> So let me summarize it:
>>
>> We have come to agreement in those questions:
>>
>> 1) SSH Soft Fencing logic should be extracted from VdsNotRespondingTreatment
>>command to its own SshSoftFencingCommand
>>
>> 2) VdsNotRespondingCommand should be refactored so it's not inherited from
>>VdsRestartCommand, but it should run SshSoftFencingCommand
>>or VdsRestartCommand based on defined fencing flow
>>
>>
>> These questions has not been resolved yet:
>>
>> 3) Should SSH Soft Fencing be executed also for hosts without PM configured?
>>
>> 4) Should SSH Soft Fencing execution for hosts without PM configured be
>> enabled
>>by default and admin can turn off these feature using configuration
>>options
>>SshSoftFencingWithoutPmEnabled (or something like that)?
>>
>> 5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster wide
>>option (can be turned off for specific cluster version) or a VDS option
>>(it can be turned off for each host)?
>>
>>
>> Personally I would suggest:
>>
>>  ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM
>>  configured
>>


+1

>>  ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be
>>  enabled by default
>>

+1

>>  ad 5) I don't see any significant reason why someone would like to turn off
>>  SSH Soft Fencing
>>for hosts without PM configured. But if someone would like to do that,
>>I think
>>he would like to turn it off only for specific hosts, so VDS level
>>option makes sense
>>for me
> 
> After re-thinking 5 - I agree.
> +1 on the other suggestions, but of course we need to get more consensus here.
> 

I think it does not need to be configurable.

>>
>>
>> Martin
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] SSH Soft Fencing

[Livnat Peer]

On 06/30/2013 07:35 PM, Barak Azulay wrote:
> 
> 
> - Original Message -
>> From: "Barak Azulay" 
>> To: "Martin Perina" 
>> Cc: "Yair Zaslavsky" , engine-devel@ovirt.org, "Eli 
>> Mesika" 
>> Sent: Thursday, June 27, 2013 8:31:35 PM
>> Subject: Re: SSH Soft Fencing
>>
>>
>>
>> - Original Message -
>>> From: "Eli Mesika" 
>>> To: "Yair Zaslavsky" 
>>> Cc: "Martin Perina" , engine-devel@ovirt.org, "Barak
>>> Azulay" 
>>> Sent: Thursday, June 27, 2013 5:55:29 PM
>>> Subject: Re: SSH Soft Fencing
>>>
>>>
>>>
>>> - Original Message -
 From: "Yair Zaslavsky" 
 To: "Eli Mesika" 
 Cc: "Martin Perina" , engine-devel@ovirt.org, "Barak
 Azulay" 
 Sent: Thursday, June 27, 2013 5:43:17 PM
 Subject: Re: SSH Soft Fencing



 - Original Message -
> From: "Eli Mesika" 
> To: "Martin Perina" 
> Cc: engine-devel@ovirt.org, "Yair Zaslavsky" ,
> "Barak
> Azulay" 
> Sent: Thursday, June 27, 2013 3:48:39 PM
> Subject: Re: SSH Soft Fencing
>
>
>
> - Original Message -
>> From: "Martin Perina" 
>> To: engine-devel@ovirt.org
>> Cc: "Yair Zaslavsky" , "Barak Azulay"
>> , "Eli Mesika" 
>> Sent: Thursday, June 27, 2013 1:51:06 PM
>> Subject: SSH Soft Fencing
>>
>> Hi,
>>
>> SSH Soft Fencing is a new feature for 3.3 and it tries to restart
>> VDSM
>> using SSH connection on non responsive hosts prior to real fencing.
>> More info can be found at
>>
>> http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3
>>
>> In current SSH Soft Fencing implementation the restart VDSM using SSH
>> command is part of standard fencing implementation in
>> VdsNotRespondingTreatmentCommand. But this command is executed only
>> if a host has a valid PM configuration. If host doesn't have a valid
>> PM configuration, the execution of the command is disabled and host
>> state is change to Non Responsive.
>>
>> So my question are:
>>
>> 1) Should SSH Soft Fencing be executed on hosts without valid PM
>>configuration?
>
> I think that the answer should be yes. The vdsm restart will solve most
> of
> problems , so why not using it whether a PM agent is defined or not.
 I agree.
 I would like to say that I also don't like the fact that
 VdsNotRespondingTreatment extends RestartVdsCommand.
 One should ask if "non responding treatment is a restart vds operation"
 or
 maybe RestartVdsCommand is just a step in the non responding treatment
 (inheritance vs containment/delegation).
 I think that VdsNotRespodingTreatment should delegate the call to
 RestartVdsCommand as the 2nd step after issuing the Soft Fencing command.
 Thoughts anyone?
>>>
>>> That would be a nice and needed re-factoring
>>
>> I would say yes - but would add it only with appropriate configuration
>> (enableAutoSoftVdsmRestartWhenNoPMAvailable  I hate the name)
>>
>>  
>>
>>>

>
>>
>> 2) Should VDSM restart using SSH command be reimplemented
>>as standalone command to be usable also in other parts of engine?
>>If 1) is true, I think it will have to be done anyway.

 I agree here.
>
> +1
>>
>> On one hand it makes sense,  but I have several questions on the above:
>> - Who do we think may want to use such a command ?


I believe you'll agree that right encapsulation and decoupling is part
of writing a maintainable code, it is not necessarily about reusing it.

>> - Should (or even can) we limit the use of such command to
>> noneResponsiveTreatment ?
>>

At this point this command would be executed only within the
noneResponsiveTreatment flow.
We don't need to model this in the REST API nor in the UI, decoupling
the vdsm fencing code is just an internal implementation detail.


>> Having general commands available to all code when there is only one specific
>> case we are using it might be a bit riskey,
>> Especially when we talk about restarting something.
> 

I am not sure what is the risk?

> Martin ? Eli? Yair?
> 
> Can you please refer to the issue above ?
> 
> 
>>
>> Thoughts ?
>>
>>
>>
>
>>
>>
>> Martin Perina
>>
>

>>>
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] VNIC profiles

[Livnat Peer]

On 07/01/2013 12:19 AM, Eli Mesika wrote:
> 
> 
> - Original Message -
>> From: "Livnat Peer" 
>> To: "engine-devel" , "Ofri Masad" 
>> Sent: Sunday, June 30, 2013 3:59:37 PM
>> Subject: [Engine-devel] VNIC profiles
>>
>> Hi,
>>
>> We are working on adding VNIC profiles as part of the work to add VNIC QoS.
>>
>> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
>>
>> We need to define some of the system behavior followed by this change,
>> here is my take -
>>
>> Editing a profile -
>> 
>> A user should be able to edit the profile properties (including profile
>> name) while VMs are attached and are using this Profile (reference
>> should be done by id).
>>
>> Changing the network though is a bit more tricky as long as we don't
>> have a way to distinguish between running and current configurations I
>> think it could be very confusing to the user. Especially since we
>> support dynamic wiring so the behavior IMO is unpredictable.
>> I think it should be blocked at this point.
>>
>>
>> Edit a VNIC / change a VNIC profile -
>> 
>> Changing the profile a VM is using while the VM is running should behave
>> like dynamic wiring (changing the VM network while it is running).
>>
>>
>> Remove a Profile -
>> ---
>> Is only valid if all VMs that are using this profile are in status down.
> 
> What about HA VMs , are they forced to be down as well for this operation?
> 

If you want to remove the profile you can remove it from the HA VM (hot
unplug NIC for example) and then delete the profile. You can do that
when the VM is up and running.



>> It should update all VMs to point to no profile which should behave like
>> none network today.
>>
>> I see no reason to support a profile on a none network at this point.
>>
>> The above is also relevant for upgrade flow (upgrading none network to
>> point to no profile)
>>
>>
>> Removing a Network -
>> --
>> should remove all profiles on that network
>>
>>
>> VM snapshot/import/export -
>> --
>> We should handle VMs that are pointing to a network directly for b/w
>> compatibility.
>> we need to select first profile that is on that network that the user
>> has permissions on.
>>
>>
>> I assume there are more, comments are welcome
>>
>> Thanks, Livnat
>>
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] SSH Soft Fencing

[Livnat Peer]

On 06/30/2013 07:26 PM, Barak Azulay wrote:
> 
> 
> - Original Message -
>> From: "Dan Kenigsberg" 
>> To: "Eli Mesika" 
>> Cc: engine-devel@ovirt.org
>> Sent: Sunday, June 30, 2013 5:40:49 PM
>> Subject: Re: [Engine-devel] SSH Soft Fencing
>>
>> On Thu, Jun 27, 2013 at 08:48:39AM -0400, Eli Mesika wrote:
>>>
>>>
>>> - Original Message -
 From: "Martin Perina" 
 To: engine-devel@ovirt.org
 Cc: "Yair Zaslavsky" , "Barak Azulay"
 , "Eli Mesika" 
 Sent: Thursday, June 27, 2013 1:51:06 PM
 Subject: SSH Soft Fencing

 Hi,

 SSH Soft Fencing is a new feature for 3.3 and it tries to restart VDSM
 using SSH connection on non responsive hosts prior to real fencing.
 More info can be found at

 http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3

 In current SSH Soft Fencing implementation the restart VDSM using SSH
 command is part of standard fencing implementation in
 VdsNotRespondingTreatmentCommand. But this command is executed only
 if a host has a valid PM configuration. If host doesn't have a valid
 PM configuration, the execution of the command is disabled and host
 state is change to Non Responsive.

 So my question are:

 1) Should SSH Soft Fencing be executed on hosts without valid PM
configuration?
>>>
>>> I think that the answer should be yes. The vdsm restart will solve most of
>>> problems
>>
>> Would you enumerate the problems that would be solved by a vdsm restart
>> (on list, but on the feature page, too)?
>> I am aware of two issues, both are vdsm bugs:
>> - If libvirtd crashes, vdsm not is not restarted unless there are
>>   running VMs
>> - Vdsm had several bugs in its soft prepareForShutdown process, getting
>>   itself stuck there in case of various background storage processes.
>>
>> I think that solving these two issues would be safer and cleaner than
>> introducing `ssh host service vdsmd restart` flow.
>>
>> The first issue is only a matter of untangling some vdsm internal
>> ugliness: whenever a libvirtconnection is produced, it should be wrapped
>> so that it cathces libvirt crashes. Unlike now, where only VM-related
>> libvirtconnection undergo this treatment.
>>
>> The second issue can be avoiding by vdsm resorting to kill-9-ing itself.
>> After all, this is what `service vdsmd restart` ends up doing after a
>> VERY short timeout (2-3 seconds, iicr).
>>
>> I suppose that there are other reasoning for a remote restart, but in
>> general, I think that it's better to have Vdsm "do the right thing" than
>> expecting Engine to control that remotely.
> 
> 
> theoretically you are absolutely right, but this is much more challenging 
> when the platform you are using keeps changing and might introduce unfamiliar 
> behaviors or bugs.
> You have enumerated several issues that we have encountered in the past and 
> were fixed by us or by different components.
> - libvirt related
> - prepareForShutdown
> - ... I even remember some from SuperVDSM
> 
> All the above eventually were handled brutally by the engine and caused the 
> host to be entirely fenced and all running VMs were killed (and the service 
> they gave went down).
> 
> This is about trying to handle an unexpected situation in a more somewhat 
> delicate manner that in most cases will save killing the VMs, in a scenario 
> where the host is going to be fenced anyway 
> 

+1
We can not anticipates our own bugs ;)


> Now the question Martin had raised is whether this functionality should be 
> applied also when a host has no physical Power-Management device, 
> 
> Hopes this provides the info you refereed to.
> 
> 
> Thanks
> Barak Azulay 
> 
> 
>>
>> Regards,
>> Dan.
>>> , so why not using it whether a PM agent is defined or not.
>>>

 2) Should VDSM restart using SSH command be reimplemented
as standalone command to be usable also in other parts of engine?
If 1) is true, I think it will have to be done anyway.
>>>
>>> +1
>>>


 Martin Perina

>>> ___
>>> Engine-devel mailing list
>>> Engine-devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>>
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] SSH Soft Fencing

[Livnat Peer]

On 06/30/2013 07:33 PM, Barak Azulay wrote:
> 
> 
> - Original Message -
>> From: "Livnat Peer" 
>> To: "Yair Zaslavsky" 
>> Cc: engine-devel@ovirt.org
>> Sent: Sunday, June 30, 2013 8:06:28 AM
>> Subject: Re: [Engine-devel] SSH Soft Fencing
>>
>> On 06/30/2013 05:46 AM, Yair Zaslavsky wrote:
>>>
>>>
>>> - Original Message -
>>>> From: "Barak Azulay" 
>>>> To: "Martin Perina" 
>>>> Cc: "Yair Zaslavsky" , engine-devel@ovirt.org, "Eli
>>>> Mesika" 
>>>> Sent: Thursday, June 27, 2013 8:31:35 PM
>>>> Subject: Re: SSH Soft Fencing
>>>>
>>>>
>>>>
>>>> - Original Message -
>>>>> From: "Eli Mesika" 
>>>>> To: "Yair Zaslavsky" 
>>>>> Cc: "Martin Perina" , engine-devel@ovirt.org, "Barak
>>>>> Azulay" 
>>>>> Sent: Thursday, June 27, 2013 5:55:29 PM
>>>>> Subject: Re: SSH Soft Fencing
>>>>>
>>>>>
>>>>>
>>>>> - Original Message -
>>>>>> From: "Yair Zaslavsky" 
>>>>>> To: "Eli Mesika" 
>>>>>> Cc: "Martin Perina" , engine-devel@ovirt.org, "Barak
>>>>>> Azulay" 
>>>>>> Sent: Thursday, June 27, 2013 5:43:17 PM
>>>>>> Subject: Re: SSH Soft Fencing
>>>>>>
>>>>>>
>>>>>>
>>>>>> - Original Message -
>>>>>>> From: "Eli Mesika" 
>>>>>>> To: "Martin Perina" 
>>>>>>> Cc: engine-devel@ovirt.org, "Yair Zaslavsky" ,
>>>>>>> "Barak
>>>>>>> Azulay" 
>>>>>>> Sent: Thursday, June 27, 2013 3:48:39 PM
>>>>>>> Subject: Re: SSH Soft Fencing
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - Original Message -
>>>>>>>> From: "Martin Perina" 
>>>>>>>> To: engine-devel@ovirt.org
>>>>>>>> Cc: "Yair Zaslavsky" , "Barak Azulay"
>>>>>>>> , "Eli Mesika" 
>>>>>>>> Sent: Thursday, June 27, 2013 1:51:06 PM
>>>>>>>> Subject: SSH Soft Fencing
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> SSH Soft Fencing is a new feature for 3.3 and it tries to restart
>>>>>>>> VDSM
>>>>>>>> using SSH connection on non responsive hosts prior to real fencing.
>>>>>>>> More info can be found at
>>>>>>>>
>>>>>>>> http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3
>>>>>>>>
>>>>>>>> In current SSH Soft Fencing implementation the restart VDSM using SSH
>>>>>>>> command is part of standard fencing implementation in
>>>>>>>> VdsNotRespondingTreatmentCommand. But this command is executed only
>>>>>>>> if a host has a valid PM configuration. If host doesn't have a valid
>>>>>>>> PM configuration, the execution of the command is disabled and host
>>>>>>>> state is change to Non Responsive.
>>>>>>>>
>>>>>>>> So my question are:
>>>>>>>>
>>>>>>>> 1) Should SSH Soft Fencing be executed on hosts without valid PM
>>>>>>>>configuration?
>>>>>>>
>>>>>>> I think that the answer should be yes. The vdsm restart will solve most
>>>>>>> of
>>>>>>> problems , so why not using it whether a PM agent is defined or not.
>>>>>> I agree.
>>>>>> I would like to say that I also don't like the fact that
>>>>>> VdsNotRespondingTreatment extends RestartVdsCommand.
>>>>>> One should ask if "non responding treatment is a restart vds operation"
>>>>>> or
>>>>>> maybe RestartVdsCommand is just a step in the non responding treatment
>>>>>> (inheritance vs containment/delegation).
>>>>>> 

[Engine-devel] VNIC profiles

[Livnat Peer]

Hi,

We are working on adding VNIC profiles as part of the work to add VNIC QoS.

http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles

We need to define some of the system behavior followed by this change,
here is my take -

Editing a profile -

A user should be able to edit the profile properties (including profile
name) while VMs are attached and are using this Profile (reference
should be done by id).

Changing the network though is a bit more tricky as long as we don't
have a way to distinguish between running and current configurations I
think it could be very confusing to the user. Especially since we
support dynamic wiring so the behavior IMO is unpredictable.
I think it should be blocked at this point.


Edit a VNIC / change a VNIC profile -

Changing the profile a VM is using while the VM is running should behave
like dynamic wiring (changing the VM network while it is running).


Remove a Profile -
---
Is only valid if all VMs that are using this profile are in status down.
It should update all VMs to point to no profile which should behave like
none network today.

I see no reason to support a profile on a none network at this point.

The above is also relevant for upgrade flow (upgrading none network to
point to no profile)


Removing a Network -
--
should remove all profiles on that network


VM snapshot/import/export -
--
We should handle VMs that are pointing to a network directly for b/w
compatibility.
we need to select first profile that is on that network that the user
has permissions on.


I assume there are more, comments are welcome

Thanks, Livnat

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Introduce mail

[Livnat Peer]

Hi Fellipe,

We'll be happy to use your help, there is always a lot of work to do :)
Is there any specific area in virtualization you would like to focus on?
Network | storage | VMs life-cycle | host life-cycle other?

To start setting your development environment, take a look at -
www.ovirt.org/Vdsm_Developers


Also adding Dan to point any low hanging fruits, or pointers for a
potentially first task :)

Livnat

On 06/28/2013 12:48 AM, Fellipe Henrique wrote:
> hello folks! 
> 
> I'm here today, to introduce myself. I want to start to contribute to
> oVirt project, I'm developing most of time in python, and I'll love to
> contribute in python, but can be in C.
> 
> I love developing and virtualization, and I think this project have all
> I like.
> 
> well, like I said, this is a introduce email, and I'll like suggestion
> how can I help, and show my code to you guys.
> 
> best regards,
> 
> T.·.F.·.A.·. S+F
> *Fellipe Henrique P. Soares*
> 
> /"Quemadmodum gladius neminem occidit, occidentis telum est."/
> (Epistulae morales ad Lucilium
> , Lucius
> Annaeus Seneca)
> 
> /"Any intelligent fool can make things bigger, more complex, and more
> violent. It takes a touch of genius -- and a lot of courage -- to move
> in the opposite direction."/ 
> Albert Einstein (March 14th 1879 – April 18th 1955)
> 
> 
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] SSH Soft Fencing

[Livnat Peer]

On 06/30/2013 05:46 AM, Yair Zaslavsky wrote:
> 
> 
> - Original Message -
>> From: "Barak Azulay" 
>> To: "Martin Perina" 
>> Cc: "Yair Zaslavsky" , engine-devel@ovirt.org, "Eli 
>> Mesika" 
>> Sent: Thursday, June 27, 2013 8:31:35 PM
>> Subject: Re: SSH Soft Fencing
>>
>>
>>
>> - Original Message -
>>> From: "Eli Mesika" 
>>> To: "Yair Zaslavsky" 
>>> Cc: "Martin Perina" , engine-devel@ovirt.org, "Barak
>>> Azulay" 
>>> Sent: Thursday, June 27, 2013 5:55:29 PM
>>> Subject: Re: SSH Soft Fencing
>>>
>>>
>>>
>>> - Original Message -
 From: "Yair Zaslavsky" 
 To: "Eli Mesika" 
 Cc: "Martin Perina" , engine-devel@ovirt.org, "Barak
 Azulay" 
 Sent: Thursday, June 27, 2013 5:43:17 PM
 Subject: Re: SSH Soft Fencing



 - Original Message -
> From: "Eli Mesika" 
> To: "Martin Perina" 
> Cc: engine-devel@ovirt.org, "Yair Zaslavsky" ,
> "Barak
> Azulay" 
> Sent: Thursday, June 27, 2013 3:48:39 PM
> Subject: Re: SSH Soft Fencing
>
>
>
> - Original Message -
>> From: "Martin Perina" 
>> To: engine-devel@ovirt.org
>> Cc: "Yair Zaslavsky" , "Barak Azulay"
>> , "Eli Mesika" 
>> Sent: Thursday, June 27, 2013 1:51:06 PM
>> Subject: SSH Soft Fencing
>>
>> Hi,
>>
>> SSH Soft Fencing is a new feature for 3.3 and it tries to restart
>> VDSM
>> using SSH connection on non responsive hosts prior to real fencing.
>> More info can be found at
>>
>> http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3
>>
>> In current SSH Soft Fencing implementation the restart VDSM using SSH
>> command is part of standard fencing implementation in
>> VdsNotRespondingTreatmentCommand. But this command is executed only
>> if a host has a valid PM configuration. If host doesn't have a valid
>> PM configuration, the execution of the command is disabled and host
>> state is change to Non Responsive.
>>
>> So my question are:
>>
>> 1) Should SSH Soft Fencing be executed on hosts without valid PM
>>configuration?
>
> I think that the answer should be yes. The vdsm restart will solve most
> of
> problems , so why not using it whether a PM agent is defined or not.
 I agree.
 I would like to say that I also don't like the fact that
 VdsNotRespondingTreatment extends RestartVdsCommand.
 One should ask if "non responding treatment is a restart vds operation"
 or
 maybe RestartVdsCommand is just a step in the non responding treatment
 (inheritance vs containment/delegation).
 I think that VdsNotRespodingTreatment should delegate the call to
 RestartVdsCommand as the 2nd step after issuing the Soft Fencing command.
 Thoughts anyone?
>>>
>>> That would be a nice and needed re-factoring
>>
>> I would say yes - but would add it only with appropriate configuration
>> (enableAutoSoftVdsmRestartWhenNoPMAvailable  I hate the name)
> 
> +1 on configuration.
> Configuration must reside at host-related entities (i.e - VdsStatic).
> 
> Yair
> 

Why would a user like to avoid fencing VDSM when host becomes
non-responsive?

I think that adding another configuration option is cumbersome with no
real value.

Livnat

>>
>>  
>>
>>>

>
>>
>> 2) Should VDSM restart using SSH command be reimplemented
>>as standalone command to be usable also in other parts of engine?
>>If 1) is true, I think it will have to be done anyway.

 I agree here.
>
> +1
>>
>> On one hand it makes sense,  but I have several questions on the above:
>> - Who do we think may want to use such a command ?
>> - Should (or even can) we limit the use of such command to
>> noneResponsiveTreatment ?
>>
>> Having general commands available to all code when there is only one specific
>> case we are using it might be a bit riskey,
>> Especially when we talk about restarting something.
>>
>> Thoughts ?
>>
>>
>>
>
>>
>>
>> Martin Perina
>>
>

>>>
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] SSH Soft Fencing

[Livnat Peer]

On 06/27/2013 05:43 PM, Yair Zaslavsky wrote:
> 
> 
> - Original Message -
>> From: "Eli Mesika" 
>> To: "Martin Perina" 
>> Cc: engine-devel@ovirt.org, "Yair Zaslavsky" , "Barak 
>> Azulay" 
>> Sent: Thursday, June 27, 2013 3:48:39 PM
>> Subject: Re: SSH Soft Fencing
>>
>>
>>
>> - Original Message -
>>> From: "Martin Perina" 
>>> To: engine-devel@ovirt.org
>>> Cc: "Yair Zaslavsky" , "Barak Azulay"
>>> , "Eli Mesika" 
>>> Sent: Thursday, June 27, 2013 1:51:06 PM
>>> Subject: SSH Soft Fencing
>>>
>>> Hi,
>>>
>>> SSH Soft Fencing is a new feature for 3.3 and it tries to restart VDSM
>>> using SSH connection on non responsive hosts prior to real fencing.
>>> More info can be found at
>>>
>>> http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3
>>>
>>> In current SSH Soft Fencing implementation the restart VDSM using SSH
>>> command is part of standard fencing implementation in
>>> VdsNotRespondingTreatmentCommand. But this command is executed only
>>> if a host has a valid PM configuration. If host doesn't have a valid
>>> PM configuration, the execution of the command is disabled and host
>>> state is change to Non Responsive.
>>>
>>> So my question are:
>>>
>>> 1) Should SSH Soft Fencing be executed on hosts without valid PM
>>>configuration?
>>
>> I think that the answer should be yes. The vdsm restart will solve most of
>> problems , so why not using it whether a PM agent is defined or not.
> I agree.
> I would like to say that I also don't like the fact that 
> VdsNotRespondingTreatment extends RestartVdsCommand.
> One should ask if "non responding treatment is a restart vds operation" or 
> maybe RestartVdsCommand is just a step in the non responding treatment 
> (inheritance vs containment/delegation).
> I think that VdsNotRespodingTreatment should delegate the call to 
> RestartVdsCommand as the 2nd step after issuing the Soft Fencing command.
> Thoughts anyone?
> 

I agree.
The purpose of this feature is to add escalation step when handling non
responsive host.
Power fencing is only a step in the escalation flow. so should be called
from within the main flow controller (the VdsNotRespodingTreatment).

Maybe we'd like this to be fine tuned by a custom policy in future versions.

>>
>>>
>>> 2) Should VDSM restart using SSH command be reimplemented
>>>as standalone command to be usable also in other parts of engine?
>>>If 1) is true, I think it will have to be done anyway.
> 
> I agree here. 
>>
>> +1

+1
The VDSM restart is a step in the escalation flow, and it should not be
tightly coupled with the non-responsive treatment implementation.

>>
>>>
>>>
>>> Martin Perina
>>>
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] VNic QoS measure units and attributes.

[Livnat Peer]

On 06/24/2013 03:07 PM, Giuseppe Vallarelli wrote:
> Hi Ofri, I've been reading your design page for this feature [1] and and I've 
> found out
> that there's a possible unit of measure mismatch regarding: Average, Burst 
> and Peak, clearly
> makes sense to use Mbps on the gui but I wonder if you're aware that the vdsm 
> api expects
> respectivly: kB/sec, kB and kB/sec (for average, burst and peak), so a 
> conversion is needed.
> As a side note the only compulsory attribute needed to define QoS for 
> incoming and outgoing
> traffic is average, burst and peak are optional (see [2]), this is not clear 
> by looking
> at the mockups and description.
> 
> Cheers, Giuseppe
> 

Hi Giuseppe,
Do you know why VDSM API exposes KB/Sec? don't you think that Mbps is
more intuitive?


Livnat

> [1] http://www.ovirt.org/Features/Network_QoS
> [2] http://libvirt.org/formatdomain.html#elementQoS
> 
> 
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Cancelled: ovirt network

[Livnat Peer]

BEGIN:VCALENDAR
PRODID:Zimbra-Calendar-Provider
VERSION:2.0
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETTO:+0200
TZOFFSETFROM:+0300
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=1SU
TZNAME:IST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETTO:+0300
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR
TZNAME:IDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:cfd70d5d-b663-41f3-b72a-15b532782b23
SUMMARY:Cancelled: ovirt network 
COMMENT:The following meeting has been cancelled:
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine-
 de...@ovirt.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:vdsm-de
 v...@lists.fedorahosted.org
ATTENDEE;CN=Tony Gargya/Germany/IBM;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTI
 ON;RSVP=TRUE:mailto:gar...@de.ibm.com
ATTENDEE;CN=Dan Yasny;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;RSVP=TRUE:mail
 to:dya...@redhat.com
ATTENDEE;CN=Simon Grinberg;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE:
 mailto:si...@redhat.com
ATTENDEE;CN=Mike Kolesnik;PARTSTAT=ACCEPTED:mailto:mkole...@redhat.com
ATTENDEE;CN=Avi Tal;PARTSTAT=ACCEPTED:mailto:a...@redhat.com
ATTENDEE;CN=Igor Lvovsky;PARTSTAT=ACCEPTED:mailto:ilvov...@redhat.com
ATTENDEE;CN=Doron Fediuck;PARTSTAT=ACCEPTED:mailto:dfedi...@redhat.com
ATTENDEE;CN=Pradipta Kumar Banerjee;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED:m
 ailto:pradipta.baner...@gmail.com
ATTENDEE;CN=Gary Kotton;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED:mailto:gkotto
 n...@redhat.com
ATTENDEE;CN=Keith Robertson;PARTSTAT=ACCEPTED:mailto:krobe...@redhat.com
ATTENDEE;CN=Antoni Segura Puimedon;PARTSTAT=ACCEPTED:mailto:asegurap@redhat.
 com
ATTENDEE;CN=Thang Pham/Poughkeepsie/IBM;SENT-BY="mailto:thang.p...@us.ibm.co
 m";PARTSTAT=ACCEPTED:mailto:thang.p...@us.ibm.com
ATTENDEE;CN=Yaniv Kaul;PARTSTAT=TENTATIVE:mailto:yk...@redhat.com
ATTENDEE;CN=Ayal Baron;PARTSTAT=TENTATIVE:mailto:aba...@redhat.com
ORGANIZER;CN=Livnat Peer:mailto:lp...@redhat.com
DTSTART;TZID="Asia/Jerusalem":20120815T16
DTEND;TZID="Asia/Jerusalem":20120815T17
STATUS:CANCELLED
CLASS:PUBLIC
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
LAST-MODIFIED:20130612T174006Z
DTSTAMP:20130612T174006Z
SEQUENCE:2
DESCRIPTION:The following meeting has been cancelled:\n\nSubject: ovirt netw
 ork  \nOrganizer: "Livnat Peer"  \n\nTime: 4:00:00 PM - 5:
 00:00 PM GMT +02:00 Jerusalem\n Recurrence : Every 5 week(s) on Wednesday No
  end date Effective Aug 15\, 2012\n\nInvitees: engine-devel@ovirt.org\; vdsm
 -de...@lists.fedorahosted.org\; gar...@de.ibm.com\; dya...@redhat.com\; simo
 n...@redhat.com\; mkole...@redhat.com\; a...@redhat.com\; ilvov...@redhat.com\;
  dfedi...@redhat.com\; pradipta.baner...@gmail.com\; gkot...@redhat.com ... 
 \n\n\n*~*~*~*~*~*~*~*~*~*\n\nHi All\, \nAs discussed previously on the list\
 , I am adding a monthly discussion on Networking in oVirt. \nIn this meeting
  we'll discuss general status of networking and features that we're missing.
  \n\nThanks\, Livnat \n\n\nBridge ID: 972506565679 \nDial-in information: \n
 Reservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679 
 \nReservationless-Plus International Dial-In Number: (212) 729-5016 \nConfer
 ence code: 8425973915 \n\nGlobal Access Numbers Local: \nAustralia\, Sydney 
 Dial-In #: 0289852326 \nAustria\, Vienna Dial-In #: 012534978196 \nBelgium\,
  Brussels Dial-In #: 027920405 \nChina Dial-In #: 4006205013 \nDenmark\, Cop
 enhagen Dial-In #: 32729215 \nFinland\, Helsinki Dial-In #: 0923194436 \nFra
 nce\, Paris Dial-In #: 0170377140 \nGermany\, Berlin Dial-In #: 030300190579
  \nIreland\, Dublin Dial-In #: 014367793 \nItaly\, Milan Dial-In #: 02362695
 29 \nNetherlands\, Amsterdam Dial-In #: 0207975872 \nNorway\, Oslo Dial-In #
 : 21033188 \nSingapore Dial-In #: 64840858 \nSpain\, Barcelona Dial-In #: 93
 5452328 \nSweden\, Stockholm Dial-In #: 0850513770 \nSwitzerland\, Geneva Di
 al-In #: 0225927881 \nUnited Kingdom Dial-In #: 02078970515 \nUnited Kingdom
  Dial-In #: 08445790676 \nUnited Kingdom\, LocalCall Dial-In #: 08445790678 
 \nUnited States Dial-In #: 2127295016 \n\n\nGlobal Access Numbers Tollfree: 
 \nArgentina Dial-In #: 8004441016 \nAustralia Dial-In #: 1800337169 \nAustri
 a Dial-In #: 085898 \nBahamas Dial-In #: 18002054776 \nBahrain Dial-In #
 : 80004377 \nBelgium Dial-In #: 080048325 \nBrazil Dial-In #: 08008921002 \n
 Bulgaria Dial-In #: 008001100236 \nChile Dial-In #: 800370228 \nColombia Dia
 l-In #: 018009134033 \nCosta Rica Dial-In #: 08000131048 \nCyprus Dial-In #:
  80095297 \nCzech Republic Dial-In #: 800700318 \nDenmark Dial-In #: 8088711
 4 \nDominican Republic Dial-In #: 18887512313 \nEstonia Dial-In #: 800010023
 2 \nFinland Dial-In #: 0800117116 \nFrance Dial-In #: 0805632867 \nGermany D
 ial-In #: 8006647541 \nGreece Dial-In #: 00800127562 \nHong Kong Dial-In #: 
 800930349 \nHungary Dial-In #: 

Re: [Engine-devel] Add traffic shaping parameters for a network interface.

[Livnat Peer]

On 06/10/2013 07:46 PM, Doron Fediuck wrote:
> 
> 
> - Original Message -
>> From: "Giuseppe Vallarelli" 
>> To: "Dan Kenigsberg" 
>> Cc: engine-devel@ovirt.org
>> Sent: Monday, June 10, 2013 6:04:27 PM
>> Subject: Re: [Engine-devel] Add traffic shaping parameters for a network 
>> interface.
>>
>> - Original Message -
>> | From: "Dan Kenigsberg" 
>> | To: "Giuseppe Vallarelli" 
>> | Cc: engine-devel@ovirt.org
>> | Sent: Monday, June 10, 2013 4:22:54 PM
>> | Subject: Re: [Engine-devel] Add traffic shaping parameters for a network
>> | interface.
>> | 
>> | On Mon, Jun 10, 2013 at 08:56:21AM -0400, Giuseppe Vallarelli wrote:
>> | > Hi Guys, I've recently submitted a patch to support traffic shaping for a
>> | > network interface (http://gerrit.ovirt.org/#/c/15445/).
>> | > This work is needed in order to support
>> | > http://www.ovirt.org/Features/Network_QoS .
>> | > Given:
>> | > 
>> | > 'specParams': {'inbound': {'average': '1000', 'peak': '5000', 'burst':
>> | > '1024'},
>> | >'outbound': {'average': '128', 'burst': '256'}}}
>> | > 
>> | > Generated xml is the following one:
>> | > 
>> | > 
>> | > 
>> | > 
>> | > 
>> | > 
>> | > As you can see I tried to keep the data structure as flat as possible
>> | > having the bandwidth element not carrying any useful information.
>> | > Feedback is highly appreciated.
>> | > 
>> | 
>> | The issue has not been mentioned on the wiki page, but may need a means
>> | to report the currently-configured QoS of each vNIC from Vdsm to Engine.
>> | For example, when a VM is de-hibernated, we may want to tell whether its
>> | QoS needs to be set according to a recently-tweaked policy.
>> | 
>> | I suggest that we use the "getVmList" verb of Vdsm, which is intended to
>> | report "static" properties of one Vm (or all of them).
>> | 
>> | On the other hand, Engine would want to blindly set new values whenever
>> | in doubt. In such a case, I think that reporting of QoS can be avoided.
>> | 
>> | Dan.
>> | 
>>
>> I'm not sure I've understood completely the issue in discussion, doesn't the
>> engine knows already
>> which are the QoS profile applied to each vNIC ? The last 'tweaked' profile
>> is the one that should
>> be applied after de-hibernation. This means that on the engine side we should
>> keep track of profile
>> change, if a change happens de-hibernating a vm triggers a QoS profile update
>> on the host of the
>> latest profile. I'm not aware of the implementation details so I might be
>> wrong.
>>
>> Giuseppe.
> 
> The idea is to handle scenarios where something went wrong;
> For example, VDSM crash while starting a new VM, engine crash, etc.
> So the engine should be able to ask for current QoS for reporting,
> and (re-)apply it if out of sync.


In addition, if we change the VNIC profile we do not require the VMs
that are using this profile to be down.
Now we can reach a state were the profile is configured for one thing
and the VMs using this profile are running with another value.

At least we would like the user to be aware of that.
I'm not sure if we'd like to sync it automatically. I would start only
with exposing this information to our administrator.

Livnat




> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Performance and scalability

[Livnat Peer]

On 06/04/2013 02:43 PM, Liran Zelkha wrote:
> Hi all,
> 
> I've added a new feature page for Performance and Scalability. Please review 
> and add your ideas... 
> http://www.ovirt.org/Features/Performance_And_Scalability
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 

Hi Liran,

Handling performance and scale in oVirt seems very interesting.
I would love to get a better understanding of what the problem is before
viewing the different solutions to solve it.

Can you please describe which scenarios you think we should tune the
performance for and which scale are we looking at?

I think that adding the above to the wiki page would give us a better
ground for discussing the issue.
In addition I suggest polling the users list for issues around
performance and/or scale. Maybe the input would help us focus on tuning
the right flows going forward.

Thanks, Livnat
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Network Quality of Service 3.3 - Feature design

[Livnat Peer]

On 06/02/2013 09:58 AM, Ofri Masad wrote:
> Hi all,
> 
> A new Feature page for "Network Quality of Service" feature was published.
> 
> http://www.ovirt.org/Features/Design/Network_QoS
> 
> You are more than welcome to share you thoughts and insights.
> 


Hi Ofri,

Here is another suggestion for you to consider, this suggestion is
realted only to QoS on the VNIC level -

Introducing a new entity - VNIC Profile.
The VNIC profile would include all the properties of a VNIC:
 - network,
 - Qos,
 - Port mirroring,
 - custom properties

>From now on a user would choose a VNIC profile when he defines a VNIC
(instead of choosing a network and defining properties directly on the VNIC)

A network could have multiple profiles defined on it.

A User would need permissions to use a profile instead of the current
state that we require permission to use a network.

The benefits of this approach :

1. Limiting the user to a specific QoS on a network is easy you give the
user permission to use a specific profile.

2. A user can add a new VNIC but he would be limited to QoS defined on
the profile he is able to use (which eliminates the problem that a user
can add a VNIC to it's VM but won't get any bandwidth limitations).

3. An administrator does not add VNIC QoS properties on the network
entity (to serve as defaults) which are not relevant for non-VM network.

4. The network admin who creates the VNIC profile is also the one who
can configure the QoS to that Network.

5. The separation between user portal and admin portal is very clear, in
user portal we expose only the profile name and in the admin portal a
user can view the profile details.

6. We would leave custom properties also on the VNIC level not only the
profile level so a user can send VM specific data.

7.I can also describe upgrade path but maybe we should discuss the
general concept before diving into the details.


Livnat



> Thanks,
> Ofri.
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Live storage migration status in oVirt 3.2

[Livnat Peer]

On 01/13/2013 04:23 PM, Shu Ming wrote:
> 于 2013-1-11 19:07, Daniel Erez 写道:
>>
>> - Original Message -
>>> From: "Shu Ming" 
>>> To: engine-devel@ovirt.org, "VDSM Project Development"
>>> 
>>> Cc: "Federico Simoncelli" , de...@redhat.com
>>> Sent: Friday, January 11, 2013 2:45:47 AM
>>> Subject: Live storage migration status in oVirt 3.2
>>>
>>> Hi,
>>>
>>> I am reviewing the live storage migration with my oVirt environment
>>> updated from the public nightly repository two weeks ago.  I found
>>> that
>>> the "move" button was still gray as before when the VM was up.  Only
>>> after I deactivated the disk, did the button become into non-gray
>>> state.
>>>   I am wondering if the live storage migration will be supported in
>>>   oVirt
>>> 3.2 release or not.
>>>
>>> BTW: These patches below should enable the live storage migration
>>> already, but I can not see  it enabled in my engine.
>>>
>>> http://gerrit.ovirt.org/5252  Change I91e641cb: pool: live storage
>>> migration implementation
>>>
>>> http://gerrit.ovirt.org/8105  Change subject: core: Live Storage
>>> Migration commands
>>> http://gerrit.ovirt.org/8103  Change subject: core: VDS Commands for
>>> Live Storage Migration
>>> http://gerrit.ovirt.org/8102  Change subject: core: Adding VDSM API
>>> for
>>> Live Storage Migration
>>> http://gerrit.ovirt.org/8470  Change subject: webadmin: Adding Live
>>> Storage Migration support
>>> http://gerrit.ovirt.org/8857 core: disable LiveStorageMigration on
>>> 3.1
>>>
>>> -- 
>>> ---
>>> 舒明 Shu Ming
>>> Open Virtualization Engineerning; CSTL, IBM Corp.
>>> Tel: 86-10-82451626  Tieline: 9051626 E-mail: shum...@cn.ibm.com or
>>> shum...@linux.vnet.ibm.com
>>> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
>>> District, Beijing 100193, PRC
>>>
>> Hi Shu,
>>
>> When a VM is up, the "move" button is enabled only for Data Center
>> version 3.2.
>> Can you please verify that the selected disk resides on a 3.2 Data
>> Center?
> 
> I checked my data center compatibility version is 3.1.  However, it is
> interesting that the compatibility version of the cluster in the data
> center is 3.2  Does the data center allow a higher version cluster?  

Clusters can have higher versions than the DC itself.
Actually in order to upgrade the DC level you first need to upgrade all
the clusters in the DC.

For storage live migration we require DC level 3.2 which implies that
all cluster in that DC are also 3.2.


> I
> will try to upgrade the data center version and try the migration again.
> 
>>
>> Best Regards,
>> Daniel
>>
>>>
> 
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Java code formatting

[Livnat Peer]

On 01/01/2013 05:39 PM, Doron Fediuck wrote:
> 
> 
> - Original Message -
>> From: "Alon Bar-Lev" 
>> To: "Doron Fediuck" 
>> Cc: "engine-devel" 
>> Sent: Tuesday, January 1, 2013 5:05:09 PM
>> Subject: Re: [Engine-devel] Java code formatting
>>
>>
>>
>> - Original Message -
>>> From: "Doron Fediuck" 
>>> To: "Alon Bar-Lev" 
>>> Cc: "engine-devel" 
>>> Sent: Tuesday, January 1, 2013 5:00:20 PM
>>> Subject: Re: [Engine-devel] Java code formatting
>>>
>>>
>>>
>>> - Original Message -
 From: "Alon Bar-Lev" 
 To: "Doron Fediuck" 
 Cc: "engine-devel" 
 Sent: Tuesday, January 1, 2013 4:53:49 PM
 Subject: Re: [Engine-devel] Java code formatting



 - Original Message -
> From: "Doron Fediuck" 
> To: "Alon Bar-Lev" 
> Cc: "engine-devel" 
> Sent: Tuesday, January 1, 2013 4:48:22 PM
> Subject: Re: [Engine-devel] Java code formatting
>
>
>
> - Original Message -
>> From: "Alon Bar-Lev" 
>> To: "Doron Fediuck" 
>> Cc: "engine-devel" 
>> Sent: Tuesday, January 1, 2013 4:33:20 PM
>> Subject: Re: [Engine-devel] Java code formatting
>>
>>
>>
>> - Original Message -
>>> From: "Doron Fediuck" 
>>> To: "Alon Bar-Lev" 
>>> Cc: "engine-devel" 
>>> Sent: Tuesday, January 1, 2013 4:28:15 PM
>>> Subject: Re: [Engine-devel] Java code formatting
>>>
>>>
>>>
>>> - Original Message -
 From: "Alon Bar-Lev" 
 To: "Doron Fediuck" 
 Cc: "engine-devel" 
 Sent: Tuesday, January 1, 2013 4:17:18 PM
 Subject: Re: [Engine-devel] Java code formatting



 - Original Message -
> From: "Doron Fediuck" 
> To: "engine-devel" 
> Sent: Tuesday, January 1, 2013 4:07:53 PM
> Subject: [Engine-devel] Java code formatting
>
> Hi,
> Recently I saw many patches with multiple code
> re-formatting.
> When looking into it, we saw that many people didn't
> use
> the
> project
> policy, and now we have many files with bad formatting.
>
> So I just posted a big ugly fix for this[1], and
> hopefully
> if
> accepted
> people should start using the right conventions and
> reduce
> the
> amount
> of non-relevant changes we see in the patches.
>
> I'm aware of the fact that this may create some issues
> when
> porting
> patches, but better sooner than later.
> Doron.
>
> [1] http://gerrit.ovirt.org/#/c/10541/1

 Hi,

 These automatic conversions are not better than current
 state,
 also
 I
 don't think that this is that important. If you want
 machine
 written
 code, then also provide commit hook to reformat anything,
 and
 probably machines to read it.

 I, personally, think that this change over the sources I
 manage
 did
 not do any good.

 Regards,
 Alon
>>>
>>> Alon,
>>> there's a formatting convention for the project set long
>>> ago.
>>> If you feel it needs to be fixed, go ahead and suggest a
>>> fix
>>> for
>>> the xml.
>>> Otherwise we end up in the current chaos, where every 2nd
>>> or
>>> 3rd
>>> patch carries unneeded changes.
>>>
>>
>> What do you mean unneeded changes? how do you prevent this in
>> future?
>>
>> Alon
>
> Unneeded changes is when you get one line of code fixed due to
> a
> bug,
> and many others re-indented.
> Best prevention is if people would make sure to use the same
> conventions.
> We also have a checkstyle which monitors important issues such
> as
> trailing
> white spaces, localization, etc.
>

 But how do you prevent this in future, not all working in same
 editor
 nor same styles.
 You can say that once in a while you perform cross over auto
 re-format...
 I am not native Java programmer but this sounds very strange
 thing
 to
 do, I don't think I know of any project that does that.

 The main problem is that people commit stuff they don't touch due
 to
 their editor behavior, which tread the whole source as if it was
 at
 its disposal, while cation should be taken not to modify extra
 stuff.

 So maybe just to reject patches that touches lines which are not
 belong to the patch it-self.

 Alon
>>>
>>> I'm fine with rejecting patches with irrelevant changes.
>>> Still sometimes you get new files and this repeats itself.
>>> The whole point of a convention is that people keep it.
>>> Most major IDEs today can use the same formatting XML we now 

Re: [Engine-devel] Engine local configuration

[Livnat Peer]

On 01/01/2013 09:30 AM, Alon Bar-Lev wrote:
> 
> 
> - Original Message -
>> From: "Livnat Peer" 
>> To: "Doron Fediuck" 
>> Cc: "Juan Hernandez" , engine-devel@ovirt.org
>> Sent: Tuesday, January 1, 2013 9:05:03 AM
>> Subject: Re: [Engine-devel] Engine local configuration
>>
>> On 12/31/2012 05:05 PM, Doron Fediuck wrote:
>>>
>>> - Original Message -
>>>> From: "Juan Hernandez" 
>>>> To: "Roy Golan" 
>>>> Cc: engine-devel@ovirt.org
>>>> Sent: Friday, December 14, 2012 1:25:57 PM
>>>> Subject: Re: [Engine-devel] Error on starting webadmin
>>>>
>>>> On 12/13/2012 03:55 PM, Roy Golan wrote:
>>>>> On 12/13/2012 04:49 PM, Vojtech Szocs wrote:
>>>>>>> this is making the contribution process more complex. lets
>>>>>>> think
>>>>>>> of a
>>>>>>> lighter way to get a developing setup.
>>>>>> I agree, I just wanted to have the local Engine configuration
>>>>>> steps documented for reference.. If there's a better way to do
>>>>>> it, I'm for it.
>>>>>>
>>>>>> Vojtech
>>>>>
>>>>> having LocalConfig look for "engine.conf.defaults" system
>>>>> property
>>>>> before fallback to System.getenv("ENGINE_DEFAULTS");
>>>>>   +  concatenating
>>>>>   -Dengine.conf.defaults=$HOME/.engine.conf.defaults
>>>>> to  JAVA_OPTS  on standalone.conf
>>>>
>>>> How is the system property simpler than the environment variable?
>>>>
>>>> I agree that this makes the development process a bit more complex
>>>> at
>>>> the moment, but I think that the way to make it simpler is not to
>>>> continue adding things to standalone.conf. I think that we should
>>>> move
>>>> towards a development environment that is closer to the production
>>>> environment, not the other way around. Ideally the developer
>>>> should
>>>> be
>>>> able to do something like "make install" to have the engine
>>>> deployed
>>>> to
>>>> a directory structure similar to what he have in the production
>>>> environment. Then you should be able to go to the bin directory
>>>> inside
>>>> that structure and start the engine (and the other tools) using
>>>> the
>>>> same
>>>> script that we use in production environments. If we achieve this
>>>> goal
>>>> then we have a simple development environment setup and also we
>>>> have
>>>> all
>>>> developers testing almost the same thing that will go into the
>>>> production environments. At the moment we don't have that, most
>>>> times
>>>> you are testing something quite different (in terms of directory
>>>> structure, configuration, etc) to what will be installed in
>>>> production
>>>> environments. I am working in that direction.
>>>>
>>>
>>> Hi Guys,
>>> Sorry to resume this discussion, but I find the current situation
>>> unfriendly to most developers. I understand there's a need for
>>> specific configurations, but it seems to me that this has taken
>>> one step too far for most developers.
>>>
>>> Further more, I expect to see such fundamental concepts being
>>> initially discussed here, and not settle with a technical ack,
>>> only to be a part of a thread called: "Error on starting webadmin".
>>> In this context I expect the verified flag to mean "This was
>>> discussed and verified with contributers in the relevant list".
>>>
>>
>> Hi Doron,
>> Thanks for bringing this on the list, I agree with everything you
>> wrote
>> and could not put it any better myself.
>>
>> I configured an environment from scratch yesterday and the additional
>> step to have this config file in /etc does not feel right, not to
>> mentioned that this is not documented in the wiki installation page.
>>
>> I think one of the guidelines we kept so far for setting a
>> development
>> environment and making it as easy as possible for new developers is
>> that
>> no manual step is needed on top of using the setup profile and this
>> definitely breaks this assumption 

Re: [Engine-devel] Engine local configuration

[Livnat Peer]

On 12/31/2012 05:05 PM, Doron Fediuck wrote:
> 
> - Original Message -
>> From: "Juan Hernandez" 
>> To: "Roy Golan" 
>> Cc: engine-devel@ovirt.org
>> Sent: Friday, December 14, 2012 1:25:57 PM
>> Subject: Re: [Engine-devel] Error on starting webadmin
>>
>> On 12/13/2012 03:55 PM, Roy Golan wrote:
>>> On 12/13/2012 04:49 PM, Vojtech Szocs wrote:
> this is making the contribution process more complex. lets think
> of a
> lighter way to get a developing setup.
 I agree, I just wanted to have the local Engine configuration
 steps documented for reference.. If there's a better way to do
 it, I'm for it.

 Vojtech
>>>
>>> having LocalConfig look for "engine.conf.defaults" system property
>>> before fallback to System.getenv("ENGINE_DEFAULTS");
>>>   +  concatenating
>>>   -Dengine.conf.defaults=$HOME/.engine.conf.defaults
>>> to  JAVA_OPTS  on standalone.conf
>>
>> How is the system property simpler than the environment variable?
>>
>> I agree that this makes the development process a bit more complex at
>> the moment, but I think that the way to make it simpler is not to
>> continue adding things to standalone.conf. I think that we should
>> move
>> towards a development environment that is closer to the production
>> environment, not the other way around. Ideally the developer should
>> be
>> able to do something like "make install" to have the engine deployed
>> to
>> a directory structure similar to what he have in the production
>> environment. Then you should be able to go to the bin directory
>> inside
>> that structure and start the engine (and the other tools) using the
>> same
>> script that we use in production environments. If we achieve this
>> goal
>> then we have a simple development environment setup and also we have
>> all
>> developers testing almost the same thing that will go into the
>> production environments. At the moment we don't have that, most times
>> you are testing something quite different (in terms of directory
>> structure, configuration, etc) to what will be installed in
>> production
>> environments. I am working in that direction.
>>
> 
> Hi Guys,
> Sorry to resume this discussion, but I find the current situation 
> unfriendly to most developers. I understand there's a need for
> specific configurations, but it seems to me that this has taken
> one step too far for most developers.
> 
> Further more, I expect to see such fundamental concepts being
> initially discussed here, and not settle with a technical ack,
> only to be a part of a thread called: "Error on starting webadmin".
> In this context I expect the verified flag to mean "This was
> discussed and verified with contributers in the relevant list".
> 

Hi Doron,
Thanks for bringing this on the list, I agree with everything you wrote
and could not put it any better myself.

I configured an environment from scratch yesterday and the additional
step to have this config file in /etc does not feel right, not to
mentioned that this is not documented in the wiki installation page.

I think one of the guidelines we kept so far for setting a development
environment and making it as easy as possible for new developers is that
no manual step is needed on top of using the setup profile and this
definitely breaks this assumption (at least with the way it is handled
today).

> My use case is exactly what Juan describes, but I think the resolution
> should be different. ie- contributers should be able to git clone
> and once they setup jboss & postgres they should be able to have
> something running.
> 
> We cannot assume /etc is a location contributers can access. Think
> of university students who would like to see how ovirt works using
> university's machines. In the past they may have had issues with
> JBoss, but that's already handled by profiles. So there's really
> no need for oVirt to ask them more than that. I know UI plugins
> are using this infra, but remember that the plugins are completely
> optional and should not block basic operation.
> 
> Some more concerns this issue raises are related to release versions;
> What happens when we need to support more than one jboss and/or
> release version?
> 
> So here are 2 options we should consider in order to allow local
> config without additional requirements:
> 
> 1. Use defaults.
> System should boot and start in whichever way we decide without
> anything else needed. Local configuration can override these
> defaults if it exists, but it should simply work.

The engine.conf.defaults holds default values for the keys, so I guess
that by defaults you mean a way to have this file as part of our
deploying | setup process and only for overriding values we should use
/etc/sysconfig/ovirt-engine, which seems to be the original intention of
the writer (according to the file documentation), I wonder where it went
wrong...

> 
> 2. Use local JBoss profile.
> Have everything we need in my-standalone.conf and start running jboss
> with a local p

Re: [Engine-devel] Creating New Data-Center and Permission on Network

[Livnat Peer]

On 10/12/12 16:06, Moti Asayag wrote:
> Hi,
> 
> When creating a new data-center, a management network is created for it.
> By default the created management network is defined as VM network.
> 
> I'd like to consult from permissions perspective, what is the preferred
> permission settings for that network.
> 
> The network is defined as management network, therefore it is designed
> be used by VMs.

I think you meant that the management network is marked by default as a
VM network and therefor is available for usage within the VMs.

> However, the admin should grant permissions on that
> networks to the target users (which one might find tedious).
> 

I'm in favor of keeping this behavior, I think that by default the
management network should not be available to users unless explicitly a
permission was added by the admin.

> We can grant permission on that network to 'everyone' with role
> 'NetworkUser', but in case the admin doesn't meant this network to be
> used, the permission should be removed.
> 
> In 'Add Logical Network' dialog I've added a new checkbox to allow
> granting 'everyone' a role for using that network ('NetworkUser').
> We can embrace same method in 'Add Data-Center' dialog.
> 

That's an interesting option I'd wait with adding this until we get some
feedback from the users on the usage of network permissions.


> Thoughts ?
> 
> Thanks,
> Moti
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] ThreadPoolUtil with 500 threads and no queue?

[Livnat Peer]

On 12/12/12 18:06, Juan Hernandez wrote:
> Hello all,
> 
> What is the reasoning behind the decision to have a pool with a maximum
> of 500 threads and no job queue (see ThreadPoolUtil.java)? Wouldn't it
> make more sense to have a much smaller thread pool and a potentially
> large queue of jobs?
> 

Hi Juan,
I think there is no right/wrong number, as Kublin added on this thread
there are several approaches to address this issue.

My 2 cents on this is that a change should be based on a given workload
profile. Any given solution would suits specific workload and hurt
another, as long as we are not sure what is the common workload our
users use I would make any change configurable and write a
recommendation on how to configure it.
For writing such document one should characterized few typical usages of
the system and test what is the preferred configuration for them.

Livnat

> Regards,
> Juan Hernandez
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] compatibility version

[Livnat Peer]

On 11/12/12 15:26, Laszlo Hornyak wrote:
> Hi,
> 
> When I install an ovirt engine from scratch, the Default DC is set to 
> Compatibility version 3.1, but when I create a new DC, it's Compatibility 
> version is set to 3.2 by default. Is this intentional? Why?
> 

Looks like a bug.
I think that when we added 3.2 support we did not change the pre-defined
DC to match it (BTW - I guess it should be fixed for default cluster as
well).


> Laszlo
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Proposal to add Shireesh Anjal as maintainer to engine-gluster

[Livnat Peer]

On 30/11/12 13:28, Itamar Heim wrote:
> Shireesh has been working on the engine gluster support for the past
> year, covering patches and leading reviews of the various engine gluster
> patches.
> 
> I'd like to propose a new sub-component of the engine for the gluster
> module, adding shireesh as its maintainer.
> 

+1,
I had the pleasure of working with shireesh in the past year, In
addition to the obvious contribution he did (patches and reviews), I
liked his fresh POV in the various discussions.

Thanks, Livnat


> Thanks,
>Itamar
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] ovirt network

[Livnat Peer]

BEGIN:VCALENDAR
PRODID:Zimbra-Calendar-Provider
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
BEGIN:STANDARD
DTSTART:19710101T02
TZOFFSETTO:+0200
TZOFFSETFROM:+0300
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=9;BYDAY=4SU
TZNAME:IST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19710101T02
TZOFFSETTO:+0300
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR
TZNAME:IDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:cfd70d5d-b663-41f3-b72a-15b532782b23
SUMMARY:ovirt network 
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine-
 de...@ovirt.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:vdsm-de
 v...@lists.fedorahosted.org
ATTENDEE;CN=Tony Gargya/Germany/IBM;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTI
 ON;RSVP=TRUE:mailto:gar...@de.ibm.com
ATTENDEE;CN=Dan Yasny;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:m
 ailto:dya...@redhat.com
ATTENDEE;CN=Simon Grinberg;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=T
 RUE:mailto:si...@redhat.com
ATTENDEE;CN=Mike Kolesnik;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
 UE:mailto:mkole...@redhat.com
ATTENDEE;CN=Avi Tal;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mai
 lto:a...@redhat.com
ATTENDEE;CN=Igor Lvovsky;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU
 E:mailto:ilvov...@redhat.com
ATTENDEE;CN=Doron Fediuck;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
 UE:mailto:dfedi...@redhat.com
ATTENDEE;CN=Pradipta Kumar Banerjee;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTI
 ON;RSVP=TRUE:mailto:pradipta.baner...@gmail.com
ATTENDEE;CN=Gary Kotton;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE
 :mailto:gkot...@redhat.com
ATTENDEE;CN=Keith Robertson;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE:mailto:krobe...@redhat.com
ATTENDEE;CN=Antoni Segura Puimedon;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTIO
 N;RSVP=TRUE:mailto:asegu...@redhat.com
ATTENDEE;CN=Thang Pham/Poughkeepsie/IBM;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-
 ACTION;RSVP=TRUE:mailto:thang.p...@us.ibm.com
ATTENDEE;CN=Yaniv Kaul;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:
 mailto:yk...@redhat.com
ORGANIZER;CN=Livnat Peer:mailto:lp...@redhat.com
DTSTART;TZID="Asia/Jerusalem":20121205T16
DTEND;TZID="Asia/Jerusalem":20121205T17
STATUS:CONFIRMED
CLASS:PUBLIC
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
RECURRENCE-ID;TZID="Asia/Jerusalem":20121128T16
LAST-MODIFIED:20121128T071446Z
DTSTAMP:20121128T071446Z
SEQUENCE:2
DESCRIPTION:A single instance of the following meeting has been modified:\n\
 nSubject: ovirt network  \nOrganiser: "Livnat Peer"  \n\nT
 ime: Wednesday\, 5 December\, 2012\, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jeru
 salem [MODIFIED]\n \nInvitees: engine-devel@ovirt.org\; vdsm-de...@lists.fed
 orahosted.org\; gar...@de.ibm.com\; dya...@redhat.com\; si...@redhat.com\; m
 kole...@redhat.com\; a...@redhat.com\; ilvov...@redhat.com\; dfediuck@redhat
 .com\; pradipta.baner...@gmail.com\; gkot...@redhat.com ... \n\n\n*~*~*~*~*~
 *~*~*~*~*\n\nHi All\, \nAs discussed previously on the list\, I am adding a 
 monthly discussion on Networking in oVirt. \nIn this meeting we'll discuss g
 eneral status of networking and features that we're missing. \n\nThanks\, Li
 vnat \n\n\nBridge ID: 972506565679 \nDial-in information: \nReservationless-
 Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679 \nReservationles
 s-Plus International Dial-In Number: (212) 729-5016 \nConference code: 84259
 73915 \n\nGlobal Access Numbers Local: \nAustralia\, Sydney Dial-In #: 02898
 52326 \nAustria\, Vienna Dial-In #: 012534978196 \nBelgium\, Brussels Dial-I
 n #: 027920405 \nChina Dial-In #: 4006205013 \nDenmark\, Copenhagen Dial-In 
 #: 32729215 \nFinland\, Helsinki Dial-In #: 0923194436 \nFrance\, Paris Dial
 -In #: 0170377140 \nGermany\, Berlin Dial-In #: 030300190579 \nIreland\, Dub
 lin Dial-In #: 014367793 \nItaly\, Milan Dial-In #: 0236269529 \nNetherlands
 \, Amsterdam Dial-In #: 0207975872 \nNorway\, Oslo Dial-In #: 21033188 \nSin
 gapore Dial-In #: 64840858 \nSpain\, Barcelona Dial-In #: 935452328 \nSweden
 \, Stockholm Dial-In #: 0850513770 \nSwitzerland\, Geneva Dial-In #: 0225927
 881 \nUnited Kingdom Dial-In #: 02078970515 \nUnited Kingdom Dial-In #: 0844
 5790676 \nUnited Kingdom\, LocalCall Dial-In #: 08445790678 \nUnited States 
 Dial-In #: 2127295016 \n\n\nGlobal Access Numbers Tollfree: \nArgentina Dial
 -In #: 8004441016 \nAustralia Dial-In #: 1800337169 \nAustria Dial-In #: 080
 0005898 \nBahamas Dial-In #: 18002054776 \nBahrain Dial-In #: 80004377 \nBel
 gium Dial-In #: 080048325 \nBrazil Dial-In #: 08008921002 \nBulgaria Dial-In
  #: 008001100236 \nChile Dial-In #: 800370228 \nColombia Dial-In #: 01800913
 4033 \nCosta Rica Dial-In #: 08000131048 \nCyprus Dial-In #: 80095297 \nCzec
 h Republic Dial-In #: 800700318 \nDenmark Dial-In #: 80887114 \nDominican Re
 public Dial-In #: 18887512313 \nEstonia Dial-In #: 8000100

[Engine-devel] ovirt network monthly sync meeting - Agenda

[Livnat Peer]

Hi All,
We have a scheduled sync meeting on oVirt network today.
We did not set an agenda for this meeting yet so I'll postpone it for
next week.

Please respond to this note with agenda items.  If there are
no agenda items by December 5th, I'll cancel the call.


Thanks, Livnat
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Report vNic Implementation Details

[Livnat Peer]

On 25/11/12 15:58, Dan Kenigsberg wrote:
> On Sun, Nov 25, 2012 at 03:21:28PM +0200, Livnat Peer wrote:
>> On 25/11/12 15:00, Itamar Heim wrote:
>>> On 11/25/2012 02:56 PM, Livnat Peer wrote:
>>>> On 22/11/12 23:18, Itamar Heim wrote:
>>>>> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>>>>>> Back to the original question:
>>>>>>
>>>>>> What is most inconvenient for many users is:
>>>>>> 1. The name we provide while creating the VNIC differs from the one in
>>>>>> the guest
>>>>>> 2. No correlation between IP and NIC
>>>>>>
>>>>>> The current page covers for this but indeed as raised here does not
>>>>>> cover what happens if this information is not easy to retrieve due to
>>>>>> non strait forward configurations.
>>>>>>
>>>>>> What I suggest is,
>>>>>>
>>>>>> For the short term:
>>>>>> - Agent to report the MACs, IPs and interface names if can be found,
>>>>>> engine to match these to the existing and show
>>>>>> Name In Engine| Name in guest | MAC | IP  etc like the current feature
>>>>>> page, but...
>>>>>>
>>>>>> - If a match could not be found then just report Name in Engine N/A
>>>>>> and then the rest and keep it in dynamic only table.
>>>>>> This is useful for NICs created by hooks, advanced topology that we
>>>>>> can't support ATM etc.
>>>>>>
>>>>>> *The above does require the agent to at least match MAC to IP.
>>>>>>
>>>>>>
>>>>>> Long term: The agent to report a topology the same as vdsm does (use
>>>>>> same code at least for Linux guests?) and present it similar to what
>>>>>> we present in the host tab. In most cases this will collapse to the
>>>>>> short term.
>>>>>>
>>>>>> MTU, is good to have in any of the two if we can get it.
>>>>>>
>>>>>> More?
>>>>>
>>>>> I don't think the guest agent ip information should be correlated to the
>>>>> vnic engine information at rest api level.
>>>>> the vm (and vnic) api provides the authoritative configuration
>>>>> information of the guest as defined in the engine.
>>>>> I don't think we should 'taint' it with untrusted data from the guest.
>>>>> it would make sense to place there IPs configured/allocated by engine
>>>>> when we deal with ip allocation though.
>>>>>
>>>>
>>>>
>>>> I was too quick to say we have an agreement...
>>>>
>>>> The comment above seems to give more emphasis on the segregation between
>>>> data collected via the GA and data configured via the engine.
>>>>
>>>> In the API we have today the following modeling: per VM entity we hold
>>>> GuestInfo entity and there we hold a list of IP addresses.
>>>>
>>>> Are you suggesting to keep this approach and not report anything on the
>>>> vNIC level at this point (until we'll be able to configure IP addresses
>>>> via the engine)?
>>>
>>> yes.
>>>
>>>> Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
>>>> should be additional to the one on the VM level (as we discussed before
>>>> the correlation between VNIC and GA reported data is not always possible)
>>>
>>> i didn't think about reporting guest info at vnic level, only at vm
>>> level. it could be a valid option, but since some network information
>>> doesn't correlate to vnic's, i think a more natural modeling at vm level
>>> may be easier.
>>>
>>>>
>>>> Also what you have in mind for the UI?
>>>
>>> at ui level i do think/agree it would make sense to show the ip per vnic
>>> if the correlation between the two is clean and direct (based on mac
>>> address i assume).
>>> you do need to make sure "bad data" won't break the ui though.
>>
>> I'm not sure I agree with the differentiation you are doing between UI
>> and API in this case.
>>
>> If we think the IP address field per vNIC should display info configured
>> via the engine and not untrusted data (reported

Re: [Engine-devel] Report vNic Implementation Details

[Livnat Peer]

On 25/11/12 15:00, Itamar Heim wrote:
> On 11/25/2012 02:56 PM, Livnat Peer wrote:
>> On 22/11/12 23:18, Itamar Heim wrote:
>>> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>>>> Back to the original question:
>>>>
>>>> What is most inconvenient for many users is:
>>>> 1. The name we provide while creating the VNIC differs from the one in
>>>> the guest
>>>> 2. No correlation between IP and NIC
>>>>
>>>> The current page covers for this but indeed as raised here does not
>>>> cover what happens if this information is not easy to retrieve due to
>>>> non strait forward configurations.
>>>>
>>>> What I suggest is,
>>>>
>>>> For the short term:
>>>> - Agent to report the MACs, IPs and interface names if can be found,
>>>> engine to match these to the existing and show
>>>> Name In Engine| Name in guest | MAC | IP  etc like the current feature
>>>> page, but...
>>>>
>>>> - If a match could not be found then just report Name in Engine N/A
>>>> and then the rest and keep it in dynamic only table.
>>>> This is useful for NICs created by hooks, advanced topology that we
>>>> can't support ATM etc.
>>>>
>>>> *The above does require the agent to at least match MAC to IP.
>>>>
>>>>
>>>> Long term: The agent to report a topology the same as vdsm does (use
>>>> same code at least for Linux guests?) and present it similar to what
>>>> we present in the host tab. In most cases this will collapse to the
>>>> short term.
>>>>
>>>> MTU, is good to have in any of the two if we can get it.
>>>>
>>>> More?
>>>
>>> I don't think the guest agent ip information should be correlated to the
>>> vnic engine information at rest api level.
>>> the vm (and vnic) api provides the authoritative configuration
>>> information of the guest as defined in the engine.
>>> I don't think we should 'taint' it with untrusted data from the guest.
>>> it would make sense to place there IPs configured/allocated by engine
>>> when we deal with ip allocation though.
>>>
>>
>>
>> I was too quick to say we have an agreement...
>>
>> The comment above seems to give more emphasis on the segregation between
>> data collected via the GA and data configured via the engine.
>>
>> In the API we have today the following modeling: per VM entity we hold
>> GuestInfo entity and there we hold a list of IP addresses.
>>
>> Are you suggesting to keep this approach and not report anything on the
>> vNIC level at this point (until we'll be able to configure IP addresses
>> via the engine)?
> 
> yes.
> 
>> Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
>> should be additional to the one on the VM level (as we discussed before
>> the correlation between VNIC and GA reported data is not always possible)
> 
> i didn't think about reporting guest info at vnic level, only at vm
> level. it could be a valid option, but since some network information
> doesn't correlate to vnic's, i think a more natural modeling at vm level
> may be easier.
> 
>>
>> Also what you have in mind for the UI?
> 
> at ui level i do think/agree it would make sense to show the ip per vnic
> if the correlation between the two is clean and direct (based on mac
> address i assume).
> you do need to make sure "bad data" won't break the ui though.

I'm not sure I agree with the differentiation you are doing between UI
and API in this case.

If we think the IP address field per vNIC should display info configured
via the engine and not untrusted data (reported via the guest agent)
then we should keep this approach in the UI as well.

I agree that in some cases the API can model data differently, or enable
more complicated actions, but this is not the case, here we have the
same data modeled differently which can cause confusion with users.

I think that we should keep the separation in the UI as well and add GA
sub-tab in VM and there have a field network devices with the data given
by the GA. no correlation (between engine configured vNICs and GA
report) at this point, when we'll have the ip address configuration via
the engine we'll present per vNIC the address.



> 
>>
>>
>>
>>
>>> i.e., the guest info element in the rest api provides good separation
>>> between engine level data, and guest agent data.
>>> ___
>>> Engine-devel mailing list
>>> Engine-devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Report vNic Implementation Details

[Livnat Peer]

On 22/11/12 23:18, Itamar Heim wrote:
> On 11/22/2012 08:40 PM, Simon Grinberg wrote:
>> Back to the original question:
>>
>> What is most inconvenient for many users is:
>> 1. The name we provide while creating the VNIC differs from the one in
>> the guest
>> 2. No correlation between IP and NIC
>>
>> The current page covers for this but indeed as raised here does not
>> cover what happens if this information is not easy to retrieve due to
>> non strait forward configurations.
>>
>> What I suggest is,
>>
>> For the short term:
>> - Agent to report the MACs, IPs and interface names if can be found,
>> engine to match these to the existing and show
>> Name In Engine| Name in guest | MAC | IP  etc like the current feature
>> page, but...
>>
>> - If a match could not be found then just report Name in Engine N/A
>> and then the rest and keep it in dynamic only table.
>> This is useful for NICs created by hooks, advanced topology that we
>> can't support ATM etc.
>>
>> *The above does require the agent to at least match MAC to IP.
>>
>>
>> Long term: The agent to report a topology the same as vdsm does (use
>> same code at least for Linux guests?) and present it similar to what
>> we present in the host tab. In most cases this will collapse to the
>> short term.
>>
>> MTU, is good to have in any of the two if we can get it.
>>
>> More?
> 
> I don't think the guest agent ip information should be correlated to the
> vnic engine information at rest api level.
> the vm (and vnic) api provides the authoritative configuration
> information of the guest as defined in the engine.
> I don't think we should 'taint' it with untrusted data from the guest.
> it would make sense to place there IPs configured/allocated by engine
> when we deal with ip allocation though.
> 


I was too quick to say we have an agreement...

The comment above seems to give more emphasis on the segregation between
data collected via the GA and data configured via the engine.

In the API we have today the following modeling: per VM entity we hold
GuestInfo entity and there we hold a list of IP addresses.

Are you suggesting to keep this approach and not report anything on the
vNIC level at this point (until we'll be able to configure IP addresses
via the engine)?
Or add GuestInfo element under /api/vms/{vm:id}/nics/{nic:id}/ which
should be additional to the one on the VM level (as we discussed before
the correlation between VNIC and GA reported data is not always possible)

Also what you have in mind for the UI?




> i.e., the guest info element in the rest api provides good separation
> between engine level data, and guest agent data.
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Report vNic Implementation Details

[Livnat Peer]

On 22/11/12 20:40, Simon Grinberg wrote:
> Back to the original question:
> 
> What is most inconvenient for many users is:
> 1. The name we provide while creating the VNIC differs from the one in the 
> guest
> 2. No correlation between IP and NIC
> 
> The current page covers for this but indeed as raised here does not cover 
> what happens if this information is not easy to retrieve due to non strait 
> forward configurations.
> 
> What I suggest is,
> 
> For the short term: 
> - Agent to report the MACs, IPs and interface names if can be found, engine 
> to match these to the existing and show
> Name In Engine| Name in guest | MAC | IP  etc like the current feature page, 
> but...
> 

I think we are all in agreement on the current proposal.
It also seems like you have ideas for enhancing the current proposal so
if you can write a detailed feature page with what you have in mind all
the way from the guest agent report to the REST API modeling we'll be
happy to discuss this as well.


> - If a match could not be found then just report Name in Engine N/A and then 
> the rest and keep it in dynamic only table. 
> This is useful for NICs created by hooks, advanced topology that we can't 
> support ATM etc. 
> 
> *The above does require the agent to at least match MAC to IP. 
> 
> 
> Long term: The agent to report a topology the same as vdsm does (use same 
> code at least for Linux guests?) and present it similar to what we present in 
> the host tab. In most cases this will collapse to the short term.
> 
> MTU, is good to have in any of the two if we can get it. 
> 
> More?
> 
> 
>  
> 
> - Original Message -
>> From: "Moti Asayag" 
>> To: "Yaniv Kaul" 
>> Cc: "Simon Grinberg" , engine-devel@ovirt.org
>> Sent: Thursday, November 22, 2012 5:39:53 PM
>> Subject: Re: [Engine-devel] Report  vNic Implementation Details
>>
>> On 11/22/2012 05:36 PM, Yaniv Kaul wrote:
>>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:

 - Original Message -
> From: "Moti Asayag" 
> To: engine-devel@ovirt.org
> Sent: Wednesday, November 21, 2012 12:36:58 PM
> Subject: [Engine-devel] Report  vNic Implementation Details
>
> Hi all,
>
> This is a proposal for reporting the vNic implementation details
> as
> reported by the guest agent per each vNic.
>
> Please review the wiki and add your comments.

 While we're making the change is there anything else we'd want to
 report - MTU, MAC (since a user might try to override), etc ?
>>>
>>> Do we support change of MAC from within the VM? Is it even working?
>>> Y.
>>>
>>
>> Shouldn't work if the nwfilter rules are enabled (which are by
>> default)
>>
>>>



> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>
> Thanks,
> Moti
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Report vNic Implementation Details

[Livnat Peer]

On 25/11/12 08:11, Dan Kenigsberg wrote:
> On Fri, Nov 23, 2012 at 09:02:09AM +0200, Livnat Peer wrote:
>> On 22/11/12 13:59, Dan Kenigsberg wrote:
>>> On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
>>>> On 22/11/12 00:02, Itamar Heim wrote:
>>>>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>>>>>
>>>>>>
>>>>>> - Original Message -
>>>>>>> From: "Moti Asayag" 
>>>>>>> To: engine-devel@ovirt.org
>>>>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>>>>>> Subject: [Engine-devel] Report  vNic Implementation Details
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> This is a proposal for reporting the vNic implementation details as
>>>>>>> reported by the guest agent per each vNic.
>>>>>>>
>>>>>>> Please review the wiki and add your comments.
>>>>>>
>>>>>>
>>>>>> While we're making the change is there anything else we'd want to
>>>>>> report - MTU, MAC (since a user might try to override), etc ?
>>>>>>>
>>>>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>>>
>>>>> iirc, the fact ip addresses appear under guest info in the api and not
>>>>> under the vnic was a modeling decision.
>>>>> for example, what if guest is using a bridge, or a bond (yes, sounds
>>>>> unlikely, but the point is it may be incorrect to assume ip-vnic relation.
>>>>> michael - do you remember the details of that discussion?
>>>>
>>>> I'd love to know what drove this modeling decision.
>>>> The use case above is not a typical use case.
>>>> We know we won't be able to present the guest internal network
>>>> configuration accurately in some scenarios but if we cover 90% of the
>>>> use cases correctly I think we should not let perfect be the enemy of
>>>> (very) good ;)
>>>
>>> We do not support this yet, but once we have nested virtualization, it
>>> won't be that odd to have a bridge or bond in the guest. I know that we
>>> already have users with in-guest vlan devices.
>>>
>>
>> The fact that it's not odd does not mean it is common.., which was the
>> point I was trying to make.
>> I agree that we should be able to accommodate such info, not sure that
>> it is required at this point.
>>
>>
>>> I think that the api should accomodate these configurations - even if we
>>> do not report them right away. The guest agent already reports (some) of
>>> the information:
>>>
>>
>> Which API are you referring to? if you are talking about VDSM-Engine API
>> we do not change it, only use what is already reported by the GA. I
>> don't think we should change the API for future support...
> 
> I was refering to the Engine API. Now that we are designing how guest IP
> addresses are to be reported, we should think how to accomodate IP
> addresses on non-nic devices.
> 

Currently the engine do not expose guest-network-devices other than
vNICs which were defined in the engine from the first place.

I suggested adding a blob (at VM level) to present the
network-devices-data reported by the guest agent.
So far I did not see on the users list any request for such info, so
maybe we can hold this addition back a little to see what requests our
users have for this.


> I believe that the Engine API should replicate the guest agent API: give
> a list of guest network devices, each one with its ethernet/ipv4/6
> addresses.
> 
> I am less sure how we should correlate this information with the VNICs
> defined on the VM. If we do not want to "taint" the VNIC with this dubious 
> information, we can leave this correlation (based on MAC address) to UI or 
> user script.
> 
> Dan.
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Report vNic Implementation Details

[Livnat Peer]

On 22/11/12 13:59, Dan Kenigsberg wrote:
> On Thu, Nov 22, 2012 at 09:55:43AM +0200, Livnat Peer wrote:
>> On 22/11/12 00:02, Itamar Heim wrote:
>>> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>>>
>>>>
>>>> - Original Message -
>>>>> From: "Moti Asayag" 
>>>>> To: engine-devel@ovirt.org
>>>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>>>> Subject: [Engine-devel] Report  vNic Implementation Details
>>>>>
>>>>> Hi all,
>>>>>
>>>>> This is a proposal for reporting the vNic implementation details as
>>>>> reported by the guest agent per each vNic.
>>>>>
>>>>> Please review the wiki and add your comments.
>>>>
>>>>
>>>> While we're making the change is there anything else we'd want to
>>>> report - MTU, MAC (since a user might try to override), etc ?
>>>>>
>>>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>>
>>> iirc, the fact ip addresses appear under guest info in the api and not
>>> under the vnic was a modeling decision.
>>> for example, what if guest is using a bridge, or a bond (yes, sounds
>>> unlikely, but the point is it may be incorrect to assume ip-vnic relation.
>>> michael - do you remember the details of that discussion?
>>
>> I'd love to know what drove this modeling decision.
>> The use case above is not a typical use case.
>> We know we won't be able to present the guest internal network
>> configuration accurately in some scenarios but if we cover 90% of the
>> use cases correctly I think we should not let perfect be the enemy of
>> (very) good ;)
> 
> We do not support this yet, but once we have nested virtualization, it
> won't be that odd to have a bridge or bond in the guest. I know that we
> already have users with in-guest vlan devices.
> 

The fact that it's not odd does not mean it is common.., which was the
point I was trying to make.
I agree that we should be able to accommodate such info, not sure that
it is required at this point.


> I think that the api should accomodate these configurations - even if we
> do not report them right away. The guest agent already reports (some) of
> the information:
> 

Which API are you referring to? if you are talking about VDSM-Engine API
we do not change it, only use what is already reported by the GA. I
don't think we should change the API for future support...

>> The Guest Agent reports the vNic details:
>>
>> IP addresses (both IPv4 and IPv6).
>> vNic internal name 
> 
> Actually, the guest agent reports all in-guest network device. vNics (and 
> bonds
> and vlans) included.

true, but AFAIU we won't be able to build the networking topology of the
guest from this report. For example if the guest agent reports a bridge
it does not say to which interface it is connected to etc.


>>
>> The retrieved information by the Guest Agent should be reported to the 
>> ovirt-engine and to be viewed by its client
>> Today only the IPv4 addresses are reported to the User, kept on VM level. 
>> This feature will maintain the information on vNic level.
> 
> I think we should report the information on the vNic level only when we
> can. If we have a vlan device, which we do not know how tie to a
> specific vNic, we'd better report its IP address on the VM level.

If I understand you correctly you are suggesting to keep the IP address
property also on the VM level and for devices with reported IP-address
which the engine can not correlate to a VNIC hold it on this VM-level
property.

My concern is that in the UI we are currently displaying in the main
greed the VM IP and on the network sub-tab the IP per vNIC.
If we choose to hold the IP addresses the engine does not correlate on
the VM level they become the more visible addresses for the users which
I am not sure is what we want.

What I suggest is to add a property to VM that says network devices and
hold the GA report as a 'blob'. we can display this info in the API on
the VM level and in the UI maybe display it on the general sub-tab or
add a dialog on the network subtab.


> 
> It might be worthwhile to note that we should (try to) correlate Engine
> idea of a vNic with the guest agent report, according to the mac address.
> The guest can try to fool us by changing the mac address, but that's
> true for every bit of info coming from the agent.
> 
> Dan.
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Report vNic Implementation Details

[Livnat Peer]

On 22/11/12 00:02, Itamar Heim wrote:
> On 11/21/2012 10:53 PM, Andrew Cathrow wrote:
>>
>>
>> - Original Message -
>>> From: "Moti Asayag" 
>>> To: engine-devel@ovirt.org
>>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>>> Subject: [Engine-devel] Report  vNic Implementation Details
>>>
>>> Hi all,
>>>
>>> This is a proposal for reporting the vNic implementation details as
>>> reported by the guest agent per each vNic.
>>>
>>> Please review the wiki and add your comments.
>>
>>
>> While we're making the change is there anything else we'd want to
>> report - MTU, MAC (since a user might try to override), etc ?
>>>
>>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
> 
> iirc, the fact ip addresses appear under guest info in the api and not
> under the vnic was a modeling decision.
> for example, what if guest is using a bridge, or a bond (yes, sounds
> unlikely, but the point is it may be incorrect to assume ip-vnic relation.
> michael - do you remember the details of that discussion?

I'd love to know what drove this modeling decision.
The use case above is not a typical use case.
We know we won't be able to present the guest internal network
configuration accurately in some scenarios but if we cover 90% of the
use cases correctly I think we should not let perfect be the enemy of
(very) good ;)

> 
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Report vNic Implementation Details

[Livnat Peer]

On 21/11/12 22:53, Andrew Cathrow wrote:
> 
> 
> - Original Message -
>> From: "Moti Asayag" 
>> To: engine-devel@ovirt.org
>> Sent: Wednesday, November 21, 2012 12:36:58 PM
>> Subject: [Engine-devel] Report  vNic Implementation Details
>>
>> Hi all,
>>
>> This is a proposal for reporting the vNic implementation details as
>> reported by the guest agent per each vNic.
>>
>> Please review the wiki and add your comments.
> 
> 
> While we're making the change is there anything else we'd want to report - 
> MTU, MAC (since a user might try to override), etc ?
> 

About the MAC address - the engine uses the MAC address to correlate
between the guest-agent report and the VNICs defined in the engine. If
the GA reports a MAC that the engine does not recognize the engine can
not associate it with a VNIC.
What the engine can do is to issue a warning to the audit log in case
such a mismatch is recognized, Is that good enough?


About MTU - It is not being reported by the guest agent ATM (while IPv4
IPv6 and MAC are), If we'd like to have it I can open RFE for the GA to
report additional fields.

Livnat


> 
> 
>>
>> http://wiki.ovirt.org/wiki/Feature/ReportingVnicImplementation
>>
>> Thanks,
>> Moti
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] network wiring DD questions/comments

[Livnat Peer]

On 20/11/12 17:06, Alona Kaplan wrote:
> 
>> Hi,
>>
>> I"ve added my answers as inline comments.
>>
>> Thanks,
>> Alona.
>>
>>> Hi Alona,
>>> I reviewed the DD of wired/unwired and I have a few
>>> questions/comments -
>>>
>>> 1. update vnic while the VM is running should be limited to cluster
>>> 3.2
>>> (except for plug/unplug)
>> I"ve updated the detailed wiki-
>> 1. On Add- there will be a canDoAction error if the user will try to
>> change the network to "none" on 3.1 or less.
>> I don't think the "none" should be removed from the combo. The user
>> won't understand why sometimes he has "none" and sometimes not.
>> 2. On Update- there are two problematic cases with 3.1 or less-
>>  2.1 The user changes the network to "none" - should behave as add.
>>  2.2 The vnic is plugged (before and after the update) and the only
>>  change is the network.
>>  In this case an "UpdateDevice" verb should be sent to vdsm, so
>>  if it is 3.1 or less the backend should throw a canDoAction. (I
>>  updated the wiki we this scenario)
>>  But, if mac address, type or plug were updated- we are sending
>>  plug/unplug to the vdsm. So the update can be done although for
>>  3.1.
>>  We talked about disabling all the fields (except "plug/unplug")
>>  in the dialog if the nic is plugged and rollback the ui if the
>>  user change from plugged to unplugged and then to plugged
>>  again.
>>  I don't think it is right. Because if the user wants just to
>>  update the mac for example, we should allow it even if the nic
>>  is plugged.
>>  I think the canDoAction is enough.

true, we can enable changing the MAC and the type in 3.1.
I think the UI should reflect better what the user can or can't do.
leaving it only to the canDoAction is not good enough.

How about in 3.1 -

If the device is originally unplugged
 - everything is enabled.

If the device is originally plugged
 - everything is disabled except for
* changing to unplugged
* changing the type
* changing the MAC address.
If the user changes to unplugged he can edit all fields,
If the user changes to plugged (back) then we reset everything except
for MAC and type.

It's not too complicated if you keep the original plugged value and
evaluate what should be done on any change from plugged to unplugged and
vice versa.


>>  2.3 I think for 3.0 or less, the update button should be disabled if
>>  the vm is not down. (Updated the wiki).

There is a request t see the details of the NIC

>>>
>>> 2. RunVM - why do we need to pass the  'linkState' property to
>>> VDSM?
>>> I
>>> think that if the link is down we should pass none as the network
>>> and
>>> if
>>> the link is up we should pass the network name, like we did so far.
>>> the
>>> link-state is internal implementation detail in the engine.
>>>
>> I will talk to Simon. If he is ok with it, I will remove the link
>> state from the feature.
>>
>>> 3. looking on the VDSM API -
>>> * why do we need 'type' ?
>> Danken wanted UpdateDevice to be a common api for updating all the
>> devices. By the type the vdsm decides which device is updated.
>>> * why do we need 'device'?
>> You are right, it should be removed. (I updated the wiki)
>>> * why do we need 'alias'?
>> We don't send the mac. This is the "unique id" of the nic.
>> The libvirt sets a unique alias for each device(disk, interface...),
>> so it can be used as the identifier of the device.
>>> * As I wrote I think we don't need 'linkState'
>>>
>>> 4. I am missing the error handling description when the user
>>> performs
>>> -
>>> Update Vnic while changing the type for example. What is the
>>> behavior
>>> if
>>> we succeed to unplug but not plug after that, etc.
>>>
>> When changing the type we are internally using the plug/unplug
>> actions.
>> If the unplug succeeds and the plug fails- the backend/ui will get an
>> error from the plug action.
>> At the end of such situation the vnic will be unplugged.
>> I"m not sure what we should do with the type- store the new type or
>> rollback to the old value in the db?

I agree it should stay unplugged, I would not perform roll back of the
type, MAC or any other field if the user will give it another try and
succeed the configuration would be as he wanted it to be.
IMO there is no right answer to that, I can think of use cases where
roll back is the right behavior from the user POV and I can also think
of scenarios where not rolling back is good for the user...


>>
>>> 5. Updated APIs section -This section is based on the fact that we
>>> pass
>>> linkstate to vdsm which is not needed IMO, so if we change that
>>> this
>>> section should be updated accordingly.
>>>
>>> 6. The EVENT section is empty, what events should be issued to
>>> audit
>>> log?
>>> I think we should have an even for update vnic and if plug/unplug
>>> is
>>> required a second event should be issued.
>> We already have events for update_vnic failure-
>> NETWORK_UPDATE_VM_INTERFACE_

[Engine-devel] network wiring DD questions/comments

[Livnat Peer]

Hi Alona,
I reviewed the DD of wired/unwired and I have a few questions/comments -

1. update vnic while the VM is running should be limited to cluster 3.2
(except for plug/unplug)

2. RunVM - why do we need to pass the  'linkState' property to VDSM? I
think that if the link is down we should pass none as the network and if
the link is up we should pass the network name, like we did so far. the
link-state is internal implementation detail in the engine.

3. looking on the VDSM API -
* why do we need 'type' ?
* why do we need 'device'?
* why do we need 'alias'?
* As I wrote I think we don't need 'linkState'

4. I am missing the error handling description when the user performs -
Update Vnic while changing the type for example. What is the behavior if
we succeed to unplug but not plug after that, etc.

5. Updated APIs section -This section is based on the fact that we pass
linkstate to vdsm which is not needed IMO, so if we change that this
section should be updated accordingly.

6. The EVENT section is empty, what events should be issued to audit log?
I think we should have an even for update vnic and if plug/unplug is
required a second event should be issued.

7. why does link state is varchar in DB? you expect to support other
option in addition to up/Down (which can be represented by 1 bit), maybe
n/a status?

8. About the open issues-

* About deprecation of ActivateDeactivateVmNic command  - I think that
we should remove this command from the backend to avoid duplicate flows
and bugs etc. for Backwards compatibility we should update the clients
to use the new UpdateVmNetworkInterface. the down side for that is we
have to make the can do action validation more complicated (according to
cluster level etc.)

* If we remove ActivateDeactivateVmNic there is no need to rename it ;)


Thanks, Livnat
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Network Wiring

[Livnat Peer]

On 18/11/12 17:06, Alona Kaplan wrote:
> 
>>> 
>>>
>> purge a network while it is connected to VMs: Link-Down on
>> all
>> nics
>> and connect to the empty/no network. (Yes I know, it's not
>> par
>> of
>> the
>> feature, but you know someone will ask for it soon :))
>
> It should not be hard to implement; In
> http://wiki.ovirt.org/wiki/Feature/DetailedNetworkWiring#New_API
> I
> suggest passing
> no 'network' element to mean "connected to nothing".
>
 I don't really understand why changing the link state to down is
 not enough?
 What is the added value of connecting "unwired" nic to a none
 network?
>>>
>>> It is not a big deal of a difference, but the semantics of having
>>> no
>>> network is clear: you can run the VM if networks are missing, you
>>> can
>>> remove a network when the VM is running. When a VM is associated to
>>> a
>>> network, but its link state is down, the "right" semantics is more
>>> vague.
>>
>> Indeed :)
>>
>> Plus consider the use case of hooks providing the networking - they
>> still need the engine to assign the MAC and type (like the CISCO
>> hook).
>> If you force a logical network on each nic, it means you have to
>> invent a dummy LN and define it as non-required and set the global
>> config to allow VMs to run on hosts that do not have this networks -
>> Too messy. Though sometimes desirable since the network name may be
>> a hint to the hook, there are cases it's not.
>>
>> -> No LN means this VM can run on any host! with implicit assumption
>> that someone else takes care of connecting it to the proper network.
>>
>> Note that in this case you may still want the network with link state
>> up and be allowed to bring the link up/down so it's for sure not the
>> case as 'unwired/link down but connected to arbitrary network'
>>
> 
> I"ve added "none" network option to the wiki.
> Any more comments? Do we have green light to start working on the feature?

+1 for the high level design naming and behavior.

> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Managing permissions on network

[Livnat Peer]

On 19/11/12 23:24, Itamar Heim wrote:
> On 11/19/2012 11:22 PM, Livnat Peer wrote:
>> On 16/11/12 12:06, Itamar Heim wrote:
>>> On 11/16/2012 10:22 AM, Moti Asayag wrote:
>>>> On 11/16/2012 09:34 AM, Itamar Heim wrote:
>>>>> On 11/15/2012 07:01 PM, Moti Asayag wrote:
>>>>>> To recap so far:
>>>>>>
>>>>>> 1. User may see only the networks he has a permission on.
>>>>>> 2. User API: Only permitted networks are shown to the user. A user
>>>>>> will
>>>>>> be capable to view the network element attached to its vnic, only
>>>>>> if he
>>>>>> has permission on that network, else it will see its id (same as
>>>>>> storage
>>>>>> domain id appears under disk element which attached to a vm).
>>>>>
>>>>> I think a user should be able to see network for networks
>>>>> associated to
>>>>> their VMs, regardless of permissions to the attach the network to
>>>>> other
>>>>> vms.
>>>>> it doesn't mean they need to see all details (like statistics,
>>>>> which are
>>>>> not part of the user level api)
>>>>> I'm pretty sure storage, cluster and dc follow the same concept in
>>>>> user
>>>>> level api.
>>>>>
>>>>
>>>> Could you elaborate the importance from user perspective for the
>>>> network
>>>> implementation details? why the user should be concerned with MTU, Vlan
>>>> and other network properties? Wouldn't the cloud-provider prefer to
>>>> encapsulate this information from the end-user ?
>>>
>>> i do agree not all fields are relevant to user, and iirc, we have a
>>> mechanism to filter out such fields.
>>> is the MTU of the logical network a secret? user will get it from the
>>> vnic anyway, right?
>>> logical network name is also something user may need to know (what is
>>> user going to see in the power user portal when standing on a VM which
>>> has a vnic with a network they don't have a permission for? the uuid
>>> instead of the network name?
>>> tomorrow will let user create virtual networks. you need to decide which
>>> fields they can and cannot set (vlan they cannot set. not sure if we
>>> should or shouldn't hide it. i'm guessing both use cases will have merit
>>> actually).
>>>
>>>
>>
>> With the above approach, what will the user see if he go to the network
>> main collection (/api/networks) in the user API?
>>
>> Today you don't get any network info in the user API (I think - need to
>> make sure), with the approach Moti suggested you see all the networks
>> you have permissions on, but with the approach you suggested it seems
>> like the user will be able to see all networks, for those he has
>> permissions on he'll get all the details and for those he has no
>> permissions he'll get limited amount of info like (name, description,
>> MTU, usage). Do we want the user to be aware of all the networks defined
>> in our DC?
> 
> user always gets same level of details on entities they see today.
> according to the approach i'm suggesting, user will see all networks
> they can see either via direct permissions, or because they are used by
> entities they have permissions to.
> 

I guess the question is how do we define indirect permissions for networks.
* Obviously if a user has a permission on a VM or a template then he has
indirect permission on the networks attached to these entities.

what about cluster and DC -
* If a user has a userVMManager role on the cluster/DC - he should be
able to see all networks attached to a VM/tempalte in the cluster/DC? or
all networks attached to the cluster/ in the DC?




>>
>> Livnat
>>
>>>>
>>>>>> 3. On upgrade: 'everyone' will get 'VmNetworkUser' role on all of the
>>>>>> networks on the system.
>>>>>> 4. On the dialog of creating new network there will be an option to
>>>>>> grant 'everyone' permissions of the created network with
>>>>>> 'VmNetworkUser'
>>>>>> role (same as on 'make template' dialog).
>>>>>> 5. Since there is no granularity of permission of network for the
>>>>>> scope
>>>>>> of a specific VM, If a user is 'VmNetworkUser' on a network

Re: [Engine-devel] Managing permissions on network

[Livnat Peer]

On 16/11/12 12:06, Itamar Heim wrote:
> On 11/16/2012 10:22 AM, Moti Asayag wrote:
>> On 11/16/2012 09:34 AM, Itamar Heim wrote:
>>> On 11/15/2012 07:01 PM, Moti Asayag wrote:
>>>> To recap so far:
>>>>
>>>> 1. User may see only the networks he has a permission on.
>>>> 2. User API: Only permitted networks are shown to the user. A user will
>>>> be capable to view the network element attached to its vnic, only if he
>>>> has permission on that network, else it will see its id (same as
>>>> storage
>>>> domain id appears under disk element which attached to a vm).
>>>
>>> I think a user should be able to see network for networks associated to
>>> their VMs, regardless of permissions to the attach the network to other
>>> vms.
>>> it doesn't mean they need to see all details (like statistics, which are
>>> not part of the user level api)
>>> I'm pretty sure storage, cluster and dc follow the same concept in user
>>> level api.
>>>
>>
>> Could you elaborate the importance from user perspective for the network
>> implementation details? why the user should be concerned with MTU, Vlan
>> and other network properties? Wouldn't the cloud-provider prefer to
>> encapsulate this information from the end-user ?
> 
> i do agree not all fields are relevant to user, and iirc, we have a
> mechanism to filter out such fields.
> is the MTU of the logical network a secret? user will get it from the
> vnic anyway, right?
> logical network name is also something user may need to know (what is
> user going to see in the power user portal when standing on a VM which
> has a vnic with a network they don't have a permission for? the uuid
> instead of the network name?
> tomorrow will let user create virtual networks. you need to decide which
> fields they can and cannot set (vlan they cannot set. not sure if we
> should or shouldn't hide it. i'm guessing both use cases will have merit
> actually).
> 
> 

With the above approach, what will the user see if he go to the network
main collection (/api/networks) in the user API?

Today you don't get any network info in the user API (I think - need to
make sure), with the approach Moti suggested you see all the networks
you have permissions on, but with the approach you suggested it seems
like the user will be able to see all networks, for those he has
permissions on he'll get all the details and for those he has no
permissions he'll get limited amount of info like (name, description,
MTU, usage). Do we want the user to be aware of all the networks defined
in our DC?

Livnat

>>
>>>> 3. On upgrade: 'everyone' will get 'VmNetworkUser' role on all of the
>>>> networks on the system.
>>>> 4. On the dialog of creating new network there will be an option to
>>>> grant 'everyone' permissions of the created network with
>>>> 'VmNetworkUser'
>>>> role (same as on 'make template' dialog).
>>>> 5. Since there is no granularity of permission of network for the scope
>>>> of a specific VM, If a user is 'VmNetworkUser' on a network, he may
>>>> attach it to any VM he has a permission on (permission to edit the VM).
>>>> 6. 'Create a VM from Template' and 'Create a VM from Snapshot/Clone VM'
>>>> requires permissions on the vnics' networks. This will save the need to
>>>> grant an automatic permissions for the vnics' networks. An alternative
>>>> would be the opposite: Leave the current required permissions as is and
>>>> grant permissions to the users for the networks of the created VM.
>>>>
>>>> Once we'll reach into a conclusion, I'll update the wiki accordingly.
>>>>
>>>> Thanks,
>>>> Moti
>>>>
>>>> On 11/06/2012 03:56 PM, Livnat Peer wrote:
>>>>> Hi All,
>>>>>
>>>>> This is a proposal for handling network permissions in oVirt.
>>>>>
>>>>> In this proposal we took the more permissive approach as we find it
>>>>> simple and a good starting point, we also think a more restrict
>>>>> approach
>>>>> makes the configuration of a network cumbersome for ovirt
>>>>> administrators.
>>>>>
>>>>> Inputs are welcomed as always...
>>>>>
>>>>> Here is an overview of the approach, for more detailed description
>>>>> please read the wiki page:

Re: [Engine-devel] Network Wiring

[Livnat Peer]

On 15/11/12 05:57, Itamar Heim wrote:
> On 11/13/2012 04:46 PM, Alona Kaplan wrote:
>> Hi all,
>>
>> Please review the wiki and add your comments.
>>
>> http://wiki.ovirt.org/wiki/Feature/NetworkWiring
> 
>> Dialog
>>
>> If the VM status is 'UP'
>>
>> If the Vnic is plugged there should be a message on top of
> the dialog "Please notice, changing Type or MAC will cause unplugging
> and plugging the Vnic".
>> Port Mirroring - If the Vnic is plugged and the Vnic is
> set for port mirroring - "network", "type", "mac" and "port mirroring"
> fields in the dialog will be disabled.
> 
> can user change the type if port mirroring isn't enabled? doesn't this
> require unplug/plug back?

It does (see the first message written in the paragraph you copied, "if
changing type or MAC unplug and plug of the device is performed.") and
that's the action the engine will trigger.

> I assume all validations are at engine side to cover rest api as well?
> 

of course

>> REST API
>>
>> NIC properties:
>>
>> Changes:
>>
>> Adding new properties under VM NIC:
>>
>> plugged
>> wired
>>
>> Deprecating the active property under VM NIC
>> Deprecating activate/deactivate actions
>> Plug/unplug and wire/unwire on a vnic, will be done via PUT action
> on the VM NIC
>> /api/vms/xxx/nics/yyy/
>>
> 
> that's a lot of deprecation - you can mark them as deprecated, but they
> still need to work over a period of time for backward compatibility, so
> please explain what they will show/how they behave until they are
> deprecated.

Same as today, they will perform plug and unplug , in the API you'll be
able to plug/unplug in two ways the deprecated one (use action) or via
edit vNic. the active property will be there as well, it will show the
same value a the plugged property.

> 
>> There is no reason to have dedicated actions for plug/unplug or
> wire/unwire. The original reason for having them was that edit VM nic
> while the VM was up used to be blocked and now we'll enable doing these
> actions.
> 
> actually, some users may not want to make these config changes while the
> VM is live, just to make them for the next boot. how will that work?

Well as long as we don't have separation for configuration and running
configuration it won't work. (same as changing the CPU or memory for
next VM run)

> 
> i agree with other comments that 'wired' is a bit confusing.
> s/wired-unwired/connected-disconnected/?
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Managing permissions on network

[Livnat Peer]

On 14/11/12 10:11, Antoni Segura Puimedon wrote:
> 
> 
> - Original Message -
>> From: "Itamar Heim" 
>> To: "Charlie" 
>> Cc: "engine-devel" 
>> Sent: Wednesday, November 14, 2012 5:28:21 AM
>> Subject: Re: [Engine-devel] Managing permissions on network
>>
>> On 11/13/2012 09:57 PM, Charlie wrote:
>>> Will any of these groups and/or permissions be drawn from LDAP?
>>>
>>> Frankly, system admins are not looking for yet another console to
>>> manage permissions.
>>
>> all users/groups come from LDAP.
>> you just need to give permissions to these groups/users in ovirt.
>> is that what you meant?
> 
> Would it be possible to somehow allow the admins to set permissions
> on the LDAP console?
> 

The integration with LDAP is on the level of managing users and groups
not the oVirt permissions themselves.
The reason for that is that permission = User + Role + Object
A user is given some Role on an Object, for example, admin1 is given the
role of clusterAdmin on clusterA, we can't set such permission in LDAP
as the objects themselves (Clusters, VMs, etc.) do not exist in LDAP.

Thanks, Livnat



___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Proposal to add Allon Mureinik as maintainer to engine core

[Livnat Peer]

+1
I especially appreciate his involvement and contribution to the testing
framework.

Livnat

On 14/11/12 06:16, Yair Zaslavsky wrote:
> +1
> 
> - Original Message -
>> From: "Itamar Heim" 
>> To: engine-devel@ovirt.org
>> Sent: Wednesday, November 14, 2012 6:12:09 AM
>> Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to  
>> engine core
>>
>> Allon has worked on oVirt for the past 10 months.
>> With 534 patches ranging from cleanups, to complex features like user
>> level api and storage live migration. In addition, Allon has been
>> instrumental in the number of patch reviews he has done.
>>
>> I'd like to propose Allon as a maintainer of engine core.
>>
>> Thanks,
>> Itamar
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Managing permissions on network

[Livnat Peer]

On 13/11/12 15:39, Itamar Heim wrote:
> On 11/13/2012 03:37 PM, Livnat Peer wrote:
>> On 13/11/12 15:19, Itamar Heim wrote:
>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>>> Interesting point, I think that if a user has permission to create a VM
>>>> from a specific template we should give him permission to use the
>>>> template networks on this VM implicitly upon the VM creation.
>>>
>>> having a permission to a template does not mean a permission to the
>>> default network of that VM, especially as we'll use templates more as
>>> instance types.
>>
>> Another alternative is to require permission on the network as well as
>> the template.
>> I must say I don't really like it, although I agree with your comment,
>> we require too many operations for enabling a user to create a VM from
>> template (permission on the template, quota on the storage, permissions
>> on the network, next we'll require a PHD ;)).
>>
>> Anyone has a better idea?
> 
> I assume most networks would be given either to 'everyone' or groups of
> users, not per user (and if the network is per user/tenant, then it must
> be done per user.

Which reminds that I wanted to propose adding a property on a network
which is called public.
It's just a UI feature to give a NetworkUser on this network to
'everyone'. It makes making a network public easier for the user.

In addition during upgrade we should make all existing networks public
networks and not allocate specific permissions for users on networks.

In addition it also means a user is given permission on a network and
then he can use it for any VM he owns. Isn't that problematic? We can't
limit a user to use a network on a specific VM.

> i may not remember correctly, but i thought when giving quota to user we
> also give some permissions with it (on cluster and storage)?

I am not sure what is the current implementation as it changed a lot,
but last I tracked we checked for either quota or permissions we did not
give implicit permissions when creating a quota.

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Managing permissions on network

[Livnat Peer]

On 13/11/12 15:19, Itamar Heim wrote:
> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>> Interesting point, I think that if a user has permission to create a VM
>> from a specific template we should give him permission to use the
>> template networks on this VM implicitly upon the VM creation.
> 
> having a permission to a template does not mean a permission to the
> default network of that VM, especially as we'll use templates more as
> instance types.

Another alternative is to require permission on the network as well as
the template.
I must say I don't really like it, although I agree with your comment,
we require too many operations for enabling a user to create a VM from
template (permission on the template, quota on the storage, permissions
on the network, next we'll require a PHD ;)).

Anyone has a better idea?

Livnat
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Managing permissions on network

[Livnat Peer]

On 13/11/12 10:57, Itamar Heim wrote:
> On 11/06/2012 02:56 PM, Livnat Peer wrote:
>> Hi All,
>>
>> This is a proposal for handling network permissions in oVirt.
>>
>> In this proposal we took the more permissive approach as we find it
>> simple and a good starting point, we also think a more restrict approach
>> makes the configuration of a network cumbersome for ovirt administrators.
>>
>> Inputs are welcomed as always...
>>
>> Here is an overview of the approach, for more detailed description
>> please read the wiki page:
>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions
>>
> 
> 
>> High Level Feature Description
>> Admin
>>
>> For creating a network in a DC you need to be SuperUser or
>> DataCenterAdmin or NetworkAdmin on the DC.
> 
> since there are multiple permissions among the differnet roles, maybe
> worth specifying the actual permissions (actiongroups), rather than just
> the roles?
> 

you can find this info in the wiki page itself,this is only high level
summary.

>> After creating the network you can manipulate the network if you
>> are a DataCenterAdmin or NetworkAdmin on the relevant network (or the
>> whole DC).
>> For attaching the network to cluster user needs to be NetworkAdmin
>> on the network (no requirement to have permission on the cluster)
>> ClusterAdmin cannot attach/detach a network from the cluster, the
>> motivation for this is that as long as the network is not attached to
>> the cluster it is not part of the cluster resources thus can not be
>> managed by the cluster administrator.
> 
> I'm not sure above two lines are intuitive to manage (a network admin
> can manipulate a cluster, but the cluster admin can't change networks in
> the cluster? this means you must give network permissions, at DC level,
> so you can't limit an admin to network attach/detach to a specific cluster.
> 

That is true but looking on the alternative I think it make sense.
The alternative is to require two permissions for attaching a network to
a cluster one is networkAdmin (for editing network properties) on a
network and the other is networkAttach (a separate Role?) on a cluster
or the DC (if you want the user to be able to add the network for all
the clusters in the DC).
While I think the common use case is that a network administrator will
be able to attach the network to all the clusters I find the above
cumbersome and rather stick to the approach that you need only a single
permission and you can't limit the network manager to specific cluster.

I think that if a requirement for limiting the network to specific
clusters comes from our users only then we should make the model more
strict and require two permissions.


>> The ClusterAdmin can change a network from required to
>> non-required for controlling the impact of the network within the
>> cluster.
>> For setting or manipulating a network on the host you need to be
>> host administrator on the host and you don't need to be network
>> administrator.
>>
>> User
>>
>> For attaching a network to a Vnic in the VM you need to have the
>> role of VmNetworkUser on the network and VmAdmin on the VM.
> 
> again, roles are just default roles, please specify the actual
> permission (actiongroup)

take a look in the wiki for exact details (which role is composed out of
which action groups)
> 
>> In user portal - the list of shown network for a user will include
>> only the list of networks the user is allowed to attach to its vnics
>> (instead of all cluster's networks).
> 
> or attached to user VMs.
> and need to handle case of network attached to template but user has no
> permission to that network?
> 

Interesting point, I think that if a user has permission to create a VM
from a specific template we should give him permission to use the
template networks on this VM implicitly upon the VM creation.

I noticed the wiki page is missing which permission should be given to
users on which networks/VMs during upgrade - Moti?


> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Managing permissions on network

[Livnat Peer]

Hi All,

This is a proposal for handling network permissions in oVirt.

In this proposal we took the more permissive approach as we find it
simple and a good starting point, we also think a more restrict approach
makes the configuration of a network cumbersome for ovirt administrators.

Inputs are welcomed as always...

Here is an overview of the approach, for more detailed description
please read the wiki page:
http://wiki.ovirt.org/wiki/Feature/NetworkPermissions

---
Admin
==

-> For creating a network in a data center you need to be a Superuser or
a DCAdmin or a networkAdmin on the DC.

-> After creating the network you can manipulate the network if you are
a DCAdmin or a networkAdmin on the relevant network (or the whole DC).

-> For attaching the network to cluster you need to be a networkAdmin on
the network (no requirement to have permission on the cluster)

-> Cluster administrator can not attach/detach a network from the
cluster, the motivation for this is that as long as the network is not
attached to the cluster it is not part of the cluster resources thus can
not be managed by the cluster administrator.
In addition once a network is attached to a cluster the cluster
administrator can change the network from required to non-required for
controlling the impact of the network within the cluster.

-> For setting a network on the host you need to be host administrator
on the host and you don't need to be network administrator.
This implies that if you are a host administrator you can add/remove all
the cluster networks from your host without the need for network related
permissions (this is the permissive approach).

User


-> For attaching a network to a Vnic in the VM you need to have the role
of VmNetworkUser on the network and vmAdmin on the VM.

-> In user portal - the list of shown network for a user will include
only the list of networks the user is allowed to attach to its vnics
(instead of all cluster's networks).

Port-mirroring
===

->  For configuring in the VM port mirroring you need to have the role
of VmAdvancedNetworkUser on the network and vmAdmin on the VM.
VmAdvancedNetworkUser includes the VmNetworkUser actions in addition to
port mirroring.




For all DB upgrade information and new roles/action groups please review
the wiki.

Thanks,
Livnat & Moti
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Cancelled: ovirt network

[Livnat Peer]

BEGIN:VCALENDAR
PRODID:Zimbra-Calendar-Provider
VERSION:2.0
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
BEGIN:STANDARD
DTSTART:19710101T02
TZOFFSETTO:+0200
TZOFFSETFROM:+0300
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=9;BYDAY=4SU
TZNAME:IST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19710101T02
TZOFFSETTO:+0300
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR
TZNAME:IDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:cfd70d5d-b663-41f3-b72a-15b532782b23
SUMMARY:Cancelled: ovirt network 
COMMENT:A single instance of a recurring meeting has been cancelled.
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine-
 de...@ovirt.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:vdsm-de
 v...@lists.fedorahosted.org
ATTENDEE;CN=Tony Gargya/Germany/IBM;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTI
 ON;RSVP=TRUE:mailto:gar...@de.ibm.com
ATTENDEE;CN=Dan Yasny;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;RSVP=TRUE:mail
 to:dya...@redhat.com
ATTENDEE;CN=Simon Grinberg;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE:
 mailto:si...@redhat.com
ATTENDEE;CN=Mike Kolesnik;PARTSTAT=ACCEPTED:mailto:mkole...@redhat.com
ATTENDEE;CN=Avi Tal;PARTSTAT=ACCEPTED:mailto:a...@redhat.com
ATTENDEE;CN=Igor Lvovsky;PARTSTAT=ACCEPTED:mailto:ilvov...@redhat.com
ATTENDEE;CN=Doron Fediuck;PARTSTAT=ACCEPTED:mailto:dfedi...@redhat.com
ATTENDEE;CN=Pradipta Kumar Banerjee;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED:m
 ailto:pradipta.baner...@gmail.com
ATTENDEE;CN=Gary Kotton;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED:mailto:gkotto
 n...@redhat.com
ATTENDEE;CN=Keith Robertson;PARTSTAT=ACCEPTED:mailto:krobe...@redhat.com
ATTENDEE;CN=Antoni Segura Puimedon;PARTSTAT=ACCEPTED:mailto:asegurap@redhat.
 com
ATTENDEE;CN=Thang Pham/Poughkeepsie/IBM;SENT-BY="mailto:thang.p...@us.ibm.co
 m";PARTSTAT=ACCEPTED:mailto:thang.p...@us.ibm.com
ORGANIZER;CN=Livnat Peer:mailto:lp...@redhat.com
DTSTART;TZID="Asia/Jerusalem":20121024T16
DTEND;TZID="Asia/Jerusalem":20121024T17
STATUS:CANCELLED
CLASS:PUBLIC
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
RECURRENCE-ID;TZID="Asia/Jerusalem":20121024T16
LAST-MODIFIED:20121024T132456Z
DTSTAMP:20121024T132456Z
SEQUENCE:2
DESCRIPTION:A single instance of the following meeting has been cancelled:\n
 \nSubject: ovirt network  \nOrganiser: "Livnat Peer"  \n\n
 Time: Wednesday\, 24 October\, 2012\, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jer
 usalem\n \nInvitees: engine-devel@ovirt.org\; vdsm-devel@lists.fedorahosted.
 org\; gar...@de.ibm.com\; dya...@redhat.com\; si...@redhat.com\; mkolesni@re
 dhat.com\; a...@redhat.com\; ilvov...@redhat.com\; dfedi...@redhat.com\; pra
 dipta.baner...@gmail.com\; gkot...@redhat.com ... \n\n\n*~*~*~*~*~*~*~*~*~*\
 n\nHi All\,\nDue to day-light saving change in Israel this meeting collides 
 with ovirt sync meeting this week.\n\nI am cancelling this instance of the m
 eeting\, If there is a specific items you'd like to discuss related to netwo
 rking please reply and we'll schedule a dedicated meeting.\n\nThanks\, Livan
 t
X-ALT-DESC;FMTTYPE=text/html:A single instance of the follow
 ing meeting has been cancelled:\n\n\n\nSubject:ovirt network  \nOrgan
 iser:"Livnat Peer" <\;lp...@redhat.com>\; \n\
 n\n\nTime:Wednesday\, 24 Oc
 tober\, 2012\, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem\n \n\n\nInvitees:engine-d
 e...@ovirt.org\; vdsm-de...@lists.fedorahosted.org\; gar...@de.ibm.com\; dya
 s...@redhat.com\; si...@redhat.com\; mkole...@redhat.com\; a...@redhat.com\; 
 ilvov...@redhat.com\; dfedi...@redhat.com\; pradipta.baner...@gmail.com\; gk
 ot...@redhat.com ... \n\n*~*~*~*~*~*~*~*~*~*Hi All\,Due to day-light saving change in Israel this meeting collides 
 with ovirt sync meeting this week.I am cancelling this instance of t
 he meeting\, If there is a specific items you'd like to discuss related to n
 etworking please reply and we'll schedule a dedicated meeting.Thanks
 \, Livant
END:VEVENT
END:VCALENDAR___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom' feature

[Livnat Peer]

On 21/10/12 23:49, Dan Kenigsberg wrote:
> On Sun, Oct 21, 2012 at 11:57:10AM -0400, Eli Mesika wrote:
>>
>>
>> - Original Message -
>>> From: "Yair Zaslavsky" 
>>> To: "Livnat Peer" 
>>> Cc: "Genadi Chereshnya" , engine-devel@ovirt.org, 
>>> vdsm-de...@fedorahosted.org
>>> Sent: Sunday, October 21, 2012 5:38:54 PM
>>> Subject: Re: [Engine-devel] unmanaged devices thrown into 'custom' feature
>>>
>>>
>>>
>>> - Original Message -
>>>> From: "Livnat Peer" 
>>>> To: "Dan Kenigsberg" 
>>>> Cc: "Genadi Chereshnya" ,
>>>> engine-devel@ovirt.org, vdsm-de...@fedorahosted.org
>>>> Sent: Sunday, October 21, 2012 5:18:31 PM
>>>> Subject: Re: [Engine-devel] unmanaged devices thrown into 'custom'
>>>> feature
>>>>
>>>> On 21/10/12 16:42, Dan Kenigsberg wrote:
>>>>> I have just noticed that when a VM is started for the second
>>>>> time,
>>>>> Engine
>>>>> issues the "create" vdsm verb with some information regarding
>>>>> "unmanaged" devices (an example is shown below[1]) in the
>>>>> 'custom'
>>>>> propery bag.
>>>>>
>>>>> I'm surprised about this, as I was not aware of this usage of the
>>>>> 'custom' dictionary, and Vdsm is not doing anything with the
>>>>> data.
>>>>>
>>>>
>>>> If I recall correctly the idea of passing the unmanaged devices
>>>> data
>>>> in
>>>> the custom property was to enable managing stable device addresses
>>>> in
>>>> the hooks (to devices that were added to the VM via hooks from the
>>>> first
>>>> place), so this info is there not for VDSM use.
>>>> For example if you add a device in a hook it will be kept in the
>>>> engine
>>>> as a non managed device. later when starting the VM again you would
>>>> like
>>>> to assign the same device address to your device, and you can do so
>>>> because you have access to the original address in the custom
>>>> properties
>>>> of the VM.
>>>
>>> This is exactly what Eli has explained Gendai and Dan today.
> 
> (I was asking here because I did not understand the verbal explanation.)
> 
>>
>> This is taken from the Stable Device Address design in
>> http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses
>>
>> Unmanaged Device
>> -
>> Unmanaged Device will be supported in the new format and will include all 
>> unhandled devices as sound/controller/etc and future devices. Those devices 
>> will be persistent and will have Type , SubType (device specific) and an 
>> Address. For 3.1 an unmanaged Device is not exposed to any GUI/REST API. 
>> Unmanaged devices are passed to vdsm inside a Custom property. VDSM in it 
>> turn is passing this as is for possible hook processing. 
> 
> Thanks for the elaboration. Too bad that I've missed this issue before.
> 
> Are you aware of any hook making use of this?  I hope that hook writers
> are not using APIs that are not documented in vdsmd(8).
> 
> It seems as a classic case where a generic bag interface is coerced into
> an awkward partially-documented interface.
> 
> I think that a better approach would have been to pass all devices
> (managed and unmanaged alike) in the 'devices' property, and let vdsm
> expose whatever is needed to the before_vm_start hook.
> 
> Maybe we can still do this.

That was the original idea but Ayal objected and I think Igor did not
like it as well...


> 
> Dan.
> ___
> vdsm-devel mailing list
> vdsm-de...@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] unmanaged devices thrown into 'custom' feature

[Livnat Peer]

On 21/10/12 16:42, Dan Kenigsberg wrote:
> I have just noticed that when a VM is started for the second time, Engine
> issues the "create" vdsm verb with some information regarding
> "unmanaged" devices (an example is shown below[1]) in the 'custom'
> propery bag.
> 
> I'm surprised about this, as I was not aware of this usage of the
> 'custom' dictionary, and Vdsm is not doing anything with the data.
> 

If I recall correctly the idea of passing the unmanaged devices data in
the custom property was to enable managing stable device addresses in
the hooks (to devices that were added to the VM via hooks from the first
place), so this info is there not for VDSM use.
For example if you add a device in a hook it will be kept in the engine
as a non managed device. later when starting the VM again you would like
to assign the same device address to your device, and you can do so
because you have access to the original address in the custom properties
of the VM.



> Would anyone elaborate about it? On the face of it, it does not seem
> like a pleasant API. If Engine wants to tell Vdsm about the location of
> various devices, we should probably be using the 'devices' property, not
> the bag of 'custom' property made for user-defined hooks.
> 
> I hope this API pecularity can be avoided, and very much hope that no
> one is depending on it.
> 
> Dan.
> 
> 
> [1]
> 'custom': {
> 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315': 'VmDevice 
> {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
> deviceId=e97a9759-1c1b-45ed-9ed9-7136ef538315, device=ide, type=controller, 
> bootOrder=0, specParams={}, address={bus=0x00, domain=0x, type=pci, 
> slot=0x01, function=0x1}, managed=false, plugged=true, readOnly=false, 
> alias=ide0}',
> 
> 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709':
>  'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
> deviceId=7bfffa34-2e27-4b01-b499-6ac79c997709, device=unix, type=channel, 
> bootOrder=0, specParams={}, address={port=1, bus=0, controller=0, 
> type=virtio-serial}, managed=false, plugged=true, readOnly=false, 
> alias=channel0}',
> 
> 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6':
>  'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
> deviceId=133d9bfa-c531-414e-ad20-208d67d5a5e6, device=virtio-serial, 
> type=controller, bootOrder=0, specParams={}, address={bus=0x00, 
> domain=0x, type=pci, slot=0x04, function=0x0}, managed=false, 
> plugged=true, readOnly=false, alias=virtio-serial0}',
> 
> 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424device_48007de9-467d-46a1-aa84-cc1a6419b5fb':
>  'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
> deviceId=48007de9-467d-46a1-aa84-cc1a6419b5fb, device=spicevmc, type=channel, 
> bootOrder=0, specParams={}, address={port=3, bus=0, controller=0, 
> type=virtio-serial}, managed=false, plugged=true, readOnly=false, 
> alias=channel2}',
> 
> 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424':
>  'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c, 
> deviceId=7c107c63-605f-4b21-9893-c052ec211424, device=unix, type=channel, 
> bootOrder=0, specParams={}, address={port=2, bus=0, controller=0, 
> type=virtio-serial}, managed=false, plugged=true, readOnly=false, 
> alias=channel1}'
> }
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Network related hooks in vdsm

[Livnat Peer]

On 16/10/12 08:52, Mike Kolesnik wrote:
> - Original Message -
>> On 10/10/12 16:47, Igor Lvovsky wrote:
>>>   Hi everyone,
>>> As you know vdsm has hooks mechanism and we already support dozen
>>> of hooks for different needs.
>>> Now it's a network's time.
>>> We would like to get your comments regarding our proposition for
>>> network related hooks.
>>>
>>> In general we are planning to prepare framework for future support
>>> of bunch network related hooks.
>>> Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
>>>
>>> Below you can find the additional hooks list that we propose:
>>>
>>
>> Many of the API calls bellow are deprecated. Why do we want to add
>> hooks
>> before/after to deprecated APIs?
> 
> They are actually still very much in use with the REST API.
> 

Deprecate does not mean "not in use" but "not using it going forward".

Today if a user is using 3.1 cluster/DC in the UI or the setupNetwork
API (which is the recommended way to configure your network in 3.1 and
in future versions) the hooks for add/edit-Network won't get activated
and that is confusing to the users (and the developers).

> Perhaps we should address just the logical entry points instead of specific 
> commands.
> A command such as setup networks can trigger multiple logical events in which 
> hooks can be planted (same goes for edit network in a smaller scale).
> 

What you are suggesting above is to deviate from the current hook
mechanism we have in VDSM and add some logic to where/when we activate
hooks.

That's an interesting suggestion, I suggest to write a wiki page and
start thinking of the implementation implications of it.
Since I like the idea I'll work with you on the wiki and we'll see if we
can get something more useful to the users and send a formal proposal.

Livnat

>>
>>> Note: In the first stage we can implement these hooks without any
>>> parameters, just to provide an entry point
>>>  for simple hooks.
>>>
>>> Networks manipulation:
>>> - before_add_network(conf={}, customProperty={})
>>> - after_add_network(conf={}, customProperty={})
>>> - before_del_network(conf={}, customProperty={})
>>> - after_del_network(conf={}, customProperty={})
>>> - before_edit_network(conf={}, customProperty={})
>>> - after_edit_network(conf={}, customProperty={})
>>> - TBD
>>>
>>> Bondings manipulations:
>>> - before_add_bond(conf={}, customProperty={})
>>> - after_add_bond(conf={}, customProperty={})
>>> - before_del_bond(conf={}, customProperty={})
>>> - after_del_bond(conf={}, customProperty={})
>>> - before_edit_bond(conf={}, customProperty={})
>>> - after_edit_bond(conf={}, customProperty={})
>>> - TBD
>>>
>>> General purpose:
>>> - before_persist_network
>>> - after_persist_network
>>>
>>>
>>> Now we just need to figure out the use cases.
>>>
>>> Your input more than welcome...
>>>
>>> [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for
>>> NIC hotplug
>>> [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX
>>> support
>>>
>>>
>>> Regards,
>>> Igor Lvovsky
>>> ___
>>> Engine-devel mailing list
>>> Engine-devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Network related hooks in vdsm

[Livnat Peer]

On 10/10/12 16:47, Igor Lvovsky wrote:
>   Hi everyone,
> As you know vdsm has hooks mechanism and we already support dozen of hooks 
> for different needs.
> Now it's a network's time.
> We would like to get your comments regarding our proposition for network 
> related hooks.
> 
> In general we are planning to prepare framework for future support of bunch 
> network related hooks.
> Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
> 
> Below you can find the additional hooks list that we propose:
> 

Many of the API calls bellow are deprecated. Why do we want to add hooks
before/after to deprecated APIs?

> Note: In the first stage we can implement these hooks without any parameters, 
> just to provide an entry point
>  for simple hooks.
> 
> Networks manipulation:
> - before_add_network(conf={}, customProperty={})
> - after_add_network(conf={}, customProperty={})
> - before_del_network(conf={}, customProperty={})
> - after_del_network(conf={}, customProperty={})
> - before_edit_network(conf={}, customProperty={})
> - after_edit_network(conf={}, customProperty={})
> - TBD
> 
> Bondings manipulations:
> - before_add_bond(conf={}, customProperty={})
> - after_add_bond(conf={}, customProperty={})
> - before_del_bond(conf={}, customProperty={})
> - after_del_bond(conf={}, customProperty={})
> - before_edit_bond(conf={}, customProperty={})
> - after_edit_bond(conf={}, customProperty={})
> - TBD
> 
> General purpose:
> - before_persist_network
> - after_persist_network
> 
> 
> Now we just need to figure out the use cases.
> 
> Your input more than welcome...
> 
> [1] http://gerrit.ovirt.org/#/c/7224/   - Adding hooks support for NIC hotplug
> [2] http://gerrit.ovirt.org/#/c/7547/   - Hook: Cisco VM-FEX support
> 
> 
> Regards,
> Igor Lvovsky
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] RFE: Netwrok Main Tab

[Livnat Peer]

On 15/10/12 16:33, Moti Asayag wrote:
> On 10/02/2012 07:36 PM, Simon Grinberg wrote:
>> Trying to sum up some of the suggestions ('coincidently' dropping those 
>> which I think a bit too much for first implementation :)) and add some 
>> suggestions of my own 
>>
>> 1. On the hosts subtab:
>>1.1 Have a radio button that will show either 
>>1.1.1 All the hosts that this network is attached to
>>1.1.2 All the hosts where this network attached to the cluster but 
>> not to the host (Very important for non-required where the host status does 
>> not indicate something is missing)
>>1.2 Have a remove button for 1.1.1, ManageNetworks button for 1.1.2. 
>> Simple add will not do since you don't know where to add. 
>>
>> 2. On the vms subtab 
>>2.1 Have a radio button that will show either 
>>2.1.1 All the vms that this network is attached to
>>2.1.2 All the vms where this network is not attached to
>>2.2 Have a 'remove' button for 2.1.1, Have 'add' button for 2.1.2
>>2.3 Allow multiple selection for both actions of 2.2
>>2.4 Add remove from all button. 
>>2.5 I would not bother to show all the nics attached to the VM from the 
>> same network, it's too rare. Just make sure there is no exception if this 
>> does exist. So the columns should have 'nic' as the first and there should 
>> be only one VM per line. If there are more then one nic per VM then just 
>> indicate 'multiple' 
>>
>> 3. Templates subtab - same as VM, drop the expansion of the NICs list.
>>
>> 4. Clusters subtab
>>Allow assign to multiple clusters - same as the edit in the data center 
>> tab (Just use the same dialogue)
>>
>> 5. Main: You have enough space then why not add the MTU column?
> 
> How about adding the DC version to the main tab next to the DC name? The
> DC version determines which features (i.e. network features) are
> supported by the DC, therefore supported for the specific network.

Since this is a valuable information but focused on the DC and not the
network I would add that on the general subtab instead of the main tab.

> 
>>
>> 6. Queries for the sub tabs: For each needs the reverse query as well 
>> (Probably more important when adding new network)  
>>
>>
>> Oops, I think I mostly added and dropped (almost) nothing :)   
>>
>> Regards,
>> Simon
>>  
>>
>> - Original Message -
>>> From: "Avi Tal" 
>>> To: "Yaniv Kaul" 
>>> Cc: engine-devel@ovirt.org
>>> Sent: Monday, September 24, 2012 10:13:52 AM
>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>
>>>
>>>
>>> - Original Message -
 From: "Yaniv Kaul" 
 To: "Moti Asayag" 
 Cc: engine-devel@ovirt.org
 Sent: Sunday, September 23, 2012 6:16:47 PM
 Subject: Re: [Engine-devel] RFE: Netwrok Main Tab

 On 09/23/2012 06:12 PM, Moti Asayag wrote:
> On 09/23/2012 05:01 PM, Yaniv Kaul wrote:
>> On 09/23/2012 04:55 PM, Alona Kaplan wrote:
>>> - Original Message -
 From: "Avi Tal" 
 To: "Alona Kaplan" 
 Cc: engine-devel@ovirt.org
 Sent: Sunday, September 23, 2012 4:17:26 PM
 Subject: Re: [Engine-devel] RFE: Netwrok Main Tab



 - Original Message -
> From: "Alona Kaplan" 
> To: "Avi Tal" 
> Cc: engine-devel@ovirt.org
> Sent: Sunday, September 23, 2012 1:31:32 PM
> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>
> 1. What actions do you suggest to add?
 Add, Edit and remove actions of each component.

>>> Host:
>>> Add- What will add action on Networks->Hosts sub tab do? Choose
>>> an
>>> existing host and attach the network to one of its nics?
>>> How will it work? after choosing the host you will open
>>> setupNetworks
>>> window and just enable dragging of the selected network (in the
>>> main
>>> tab) to a nic? I think it is too much.
>>>
>>> Edit- same as add.
>>>
>>> Remove- What is the meaning of Remove host in network's
>>> context?
>>> The
>>> network will be detached from the host? I think it is
>>> confusing.
>>>
>>> Vm/Template:
>>> Add: What will it do? You will choose a vm and then add a vnic
>>> to
>>> the
>>> vm? Where will you see the vnic details?
>>> Edit: Same as add.
>>> Remove: You will remove all the vnics that use the selected
>>> network
>>> from the vm? Or do you mean to add a remove per vnic?
>> For all the above: yes.
>> We can certainly work on the small details, but having a main
>> tab
>> with
>> little to no action whatsoever is kinda disappointing.
> IMO adding 'assign' action in the main tab might be handy in
> order
> to
> assign a single network in a single dialog to several clusters.
>
> However It is not clear to me how Add/Edit for a VM in a sub-tab
> should
> look like. The VM should have a list of inter

Re: [Engine-devel] RFE: Netwrok Main Tab

[Livnat Peer]

On 02/10/12 19:36, Simon Grinberg wrote:
> Trying to sum up some of the suggestions ('coincidently' dropping those which 
> I think a bit too much for first implementation :)) and add some suggestions 
> of my own 
> 
> 1. On the hosts subtab:
>1.1 Have a radio button that will show either 
>1.1.1 All the hosts that this network is attached to
>1.1.2 All the hosts where this network attached to the cluster but not 
> to the host (Very important for non-required where the host status does not 
> indicate something is missing)
>1.2 Have a remove button for 1.1.1, ManageNetworks button for 1.1.2. 
> Simple add will not do since you don't know where to add. 
> 
> 2. On the vms subtab 
>2.1 Have a radio button that will show either 
>2.1.1 All the vms that this network is attached to
>2.1.2 All the vms where this network is not attached to
>2.2 Have a 'remove' button for 2.1.1, Have 'add' button for 2.1.2
>2.3 Allow multiple selection for both actions of 2.2
>2.4 Add remove from all button. 
>2.5 I would not bother to show all the nics attached to the VM from the 
> same network, it's too rare. Just make sure there is no exception if this 
> does exist. So the columns should have 'nic' as the first and there should be 
> only one VM per line. If there are more then one nic per VM then just 
> indicate 'multiple' 
> 

Can you please explain the need of 2.1.2 - "All the vms where this
network is not attached to (but attached to the cluster) "?

> 3. Templates subtab - same as VM, drop the expansion of the NICs list.
> 
> 4. Clusters subtab
>Allow assign to multiple clusters - same as the edit in the data center 
> tab (Just use the same dialogue)
> 
> 5. Main: You have enough space then why not add the MTU column?
> 
> 6. Queries for the sub tabs: For each needs the reverse query as well 
> (Probably more important when adding new network)  
> 
> 
> Oops, I think I mostly added and dropped (almost) nothing :)   
> 
> Regards,
> Simon
>  
> 
> - Original Message -
>> From: "Avi Tal" 
>> To: "Yaniv Kaul" 
>> Cc: engine-devel@ovirt.org
>> Sent: Monday, September 24, 2012 10:13:52 AM
>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>
>>
>>
>> - Original Message -
>>> From: "Yaniv Kaul" 
>>> To: "Moti Asayag" 
>>> Cc: engine-devel@ovirt.org
>>> Sent: Sunday, September 23, 2012 6:16:47 PM
>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>
>>> On 09/23/2012 06:12 PM, Moti Asayag wrote:
 On 09/23/2012 05:01 PM, Yaniv Kaul wrote:
> On 09/23/2012 04:55 PM, Alona Kaplan wrote:
>> - Original Message -
>>> From: "Avi Tal" 
>>> To: "Alona Kaplan" 
>>> Cc: engine-devel@ovirt.org
>>> Sent: Sunday, September 23, 2012 4:17:26 PM
>>> Subject: Re: [Engine-devel] RFE: Netwrok Main Tab
>>>
>>>
>>>
>>> - Original Message -
 From: "Alona Kaplan" 
 To: "Avi Tal" 
 Cc: engine-devel@ovirt.org
 Sent: Sunday, September 23, 2012 1:31:32 PM
 Subject: Re: [Engine-devel] RFE: Netwrok Main Tab

 1. What actions do you suggest to add?
>>> Add, Edit and remove actions of each component.
>>>
>> Host:
>> Add- What will add action on Networks->Hosts sub tab do? Choose
>> an
>> existing host and attach the network to one of its nics?
>> How will it work? after choosing the host you will open
>> setupNetworks
>> window and just enable dragging of the selected network (in the
>> main
>> tab) to a nic? I think it is too much.
>>
>> Edit- same as add.
>>
>> Remove- What is the meaning of Remove host in network's
>> context?
>> The
>> network will be detached from the host? I think it is
>> confusing.
>>
>> Vm/Template:
>> Add: What will it do? You will choose a vm and then add a vnic
>> to
>> the
>> vm? Where will you see the vnic details?
>> Edit: Same as add.
>> Remove: You will remove all the vnics that use the selected
>> network
>> from the vm? Or do you mean to add a remove per vnic?
> For all the above: yes.
> We can certainly work on the small details, but having a main
> tab
> with
> little to no action whatsoever is kinda disappointing.
 IMO adding 'assign' action in the main tab might be handy in
 order
 to
 assign a single network in a single dialog to several clusters.

 However It is not clear to me how Add/Edit for a VM in a sub-tab
 should
 look like. The VM should have a list of interfaces (represented
 as
 sub
 collection/tree).
>>>
>>> I was thinking more of right-click on the network, selecting 'Add
>>> to
>>> VM'
>>> and then selecting single/mutliple VMs from a dialog with all the
>>> VMs
>>> (yes, filtered via search).
>>> Y.
>>>
>>
>> +1
>>
 What will be the meaning of 'Add' in that context? Since the VM
 already
 have a vNIC attached t

Re: [Engine-devel] network subnet

[Livnat Peer]

On 12/09/12 12:51, Alon Bar-Lev wrote:
> 
> 
> - Original Message -
>> From: "David Jaša" 
>> To: engine-devel@ovirt.org
>> Sent: Tuesday, September 11, 2012 2:47:56 PM
>> Subject: Re: [Engine-devel] network subnet
>>
>> Livnat Peer píše v Út 11. 09. 2012 v 09:21 +0300:
>>> On 30/08/12 23:11, Alon Bar-Lev wrote:
>>>>
>>>>
>>>> - Original Message -
>>>>> From: "Livnat Peer" 
>>>>> To: "Alon Bar-Lev" 
>>>>> Cc: engine-devel@ovirt.org
>>>>> Sent: Thursday, August 30, 2012 10:16:05 PM
>>>>> Subject: Re: [Engine-devel] network subnet
>>>>>
>>>>> On 30/08/12 21:39, Alon Bar-Lev wrote:
>>>>>>
>>>>>>
>>>>>> - Original Message -
>>>>>>> From: "Livnat Peer" 
>>>>>>> To: engine-devel@ovirt.org
>>>>>>> Sent: Thursday, August 30, 2012 3:22:29 PM
>>>>>>> Subject: [Engine-devel] network subnet
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Today when a user wants to define a network subnet mask, he
>>>>>>> does
>>>>>>> it
>>>>>>> when
>>>>>>> he attaches the network to a host NIC.
>>>>>>>
>>>>>>> I was wondering if there is a reason not to define the network
>>>>>>> subnet
>>>>>>> on
>>>>>>> the logical network entity (Data center level).
>>>>>>>
>>>>>>> Thanks, Livnat
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I am sorry, maybe I do not understand... the IP scheme enforces
>>>>>> the
>>>>>> use of address mask in order to properly route packets.
>>>>>
>>>>> of course. My proposal is related to our user usage of the
>>>>> system.
>>>>> Today
>>>>> ovirt user, who wants to define a network subnet, has to type
>>>>> the
>>>>> subnet
>>>>> per host (per network), I think the user should only define it
>>>>> once
>>>>> on
>>>>> the logical network entity in the Data Center.
>>>>> Propagating the value to all hosts is needed but it should be
>>>>> our
>>>>> internal implementation detail.
>>>>>
>>>>>>
>>>>>> Network mask is used in any case, I guess it can be dropped
>>>>>> from
>>>>>> configuration in favour of using the address class as mask, is
>>>>>> that what you suggest?
>>>>>>
>>>>>
>>>>> No, hope the above paragraph made it more clear.
>>>>>
>>>>
>>>> Hello,
>>>>
>>>> Then you assume that a logical network, which is actually layer 2
>>>> network in our implementation, has layer 3 characteristics,
>>>> right?
>>>>
>>>> In our current implementation "data center logical network" is
>>>> pure layer 2 segment aka layer 2 broadcast domain.
>>>>
>>>> One can use the same logical network for multiple layer 3
>>>> segments, which is totally valid and consistent with standard
>>>> physical layer 2 setup.
>>>>
>>>> Unless I am missing something crucial, I would suggest to keep
>>>> the consistent physical->virtual mapping, unless we emulate
>>>> layer 3 switching. Layer 2 does not have layer 3
>>>> characteristics.
>>>>
>>>> Regards,
>>>> Alon.
>>>>
>>>
>>> Generally I agree with what you wrote.
>>>
>>> I would like to open for discussion the definition mentioned above
>>> that
>>> a logical network is a layer 2 broadcast domain.
>>>
>>> We have 2 types of logical networks, VM networks and 'other' (host
>>> functionality?) networks.
>>>
>>> When talking about VM networks, I think the definition above is
>>> accurate, the guests using the network should get a layer 2
>>> broadcast
>>> domain.
>>> It can be implemented over a single (physical) layer 2 domain or it
>>> can
>>> be implemented over multiple (physical) layer 2 domains using

Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options

[Livnat Peer]

On 10/09/12 11:30, Alon Bar-Lev wrote:
> 
> 
> - Original Message -
>> From: "Livnat Peer" 
>> To: "Alon Bar-Lev" 
>> Cc: engine-devel@ovirt.org
>> Sent: Monday, September 10, 2012 8:55:32 AM
>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
>>
>> On 10/09/12 00:58, Alon Bar-Lev wrote:
>>> Hello All,
>>>
>>> I would like to discuss the method we use to manage default
>>> options. I believe it can be significantly simplified.
>>>
>>> Please read though and comment.
>>>
>>> Thank you,
>>> Alon Bar-Lev
>>>
>>> ---
>>>
>>> CURRENT STATE
>>>
>>> Most options are located in three different locations.
>>>
>>> Let's explain by example... The
>>> FenceQuietTimeBetweenOperationsInSec option.
>>>
>>> ---
>>> ConfigValues.java
>>> ---
>>> public enum ConfigValues {
>>> 
>>> @Reloadable
>>> @TypeConverterAttribute(Integer.class)
>>> @DefaultValueAttribute("180")
>>> FenceQuietTimeBetweenOperationsInSec(30),
>>> 
>>> }
>>> ---
>>>
>>> ---
>>> _config.sql
>>> ---
>>> 
>>> select
>>> fn_db_add_config_value('FenceQuietTimeBetweenOperationsInSec','180','general');
>>> 
>>> ---
>>>
>>> ---
>>> engine-config.properties
>>> ---
>>> 
>>> FenceQuietTimeBetweenOperationsInSec.type=Integer
>>> FenceQuietTimeBetweenOperationsInSec.validValues=60..600
>>> FenceQuietTimeBetweenOperationsInSec.description="Fence quiet time
>>> between operations (in seconds)"
>>> FenceQuietTimeBetweenOperationsInSec.alternateKey=Fence_Quiet_Time
>>> 
>>> ---
>>>
>>> ConfigValues.java is the base, it defines all options and
>>> appropriate metadata as annotations. It defines the option name,
>>> type, default value, and if reloadable.
>>>
>>> _config.sql adds all parameters into the database using their
>>> default value, we actually duplicate the parameter name and
>>> default value into the sql script. Please note that even if we do
>>> not add the parameter to the database the engine infrastructure
>>> will use the default value specify at ConfigValues.
>>>
>>> engine-config.properties is used as an interface to engine-config
>>> utility, a command-line utility that can manipulate engine
>>> options. engine-config manages only options that are specified in
>>> this property files. Property files specifies user friendly
>>> description, valid values, alias, but duplicate the option name
>>> and type that already specified in ConfigValues. engine-config
>>> will only manage options that exists in database.
>>>
>>> QUESTIONS
>>>
>>> 1. Why do we store default values in database?
>>>
>>
>> Our intention so far was to remove default values from the code.
>>
>> The values in the data base are not default values but the values of
>> the
>> properties and we keep them per version were we need different values
>> per version.
>>
>> The obvious advantage of keeping them in the DB vs. in code is they
>> can
>> be changed with no compilation required and today you don't need to
>> restart the application for changing some of them (WIP).
> 
> The above statement is true if you use database or any other format, such as 
> XML file for the metadata.
> 
> As long as there is no duplication between code and metadata storage, and as 
> long as the default values are not stored within the options tables, so that 
> after upgrade the new defaults are in effect unless explicitly overridden by 
> user.
> 
> Let's assume we would like to avoid compilation. What is the benefit in 
> storing the metadata within the database and not in plain text file / XML 
> file / properties file?

I think that the main advantage of using data base over XML is that we
already maintain data base and work with it. I have nothing against XML
but I think the question we should ask ourselves is why add another
mechanism like XML file for managing static configuration when we can
use data base?

Also I think there was/is a thought to expose the configuration via the
UI (both for view and edit) I think that if this is still the intention
then working with DB would be easier than XML.

> 
>>> From what I managed to g

Re: [Engine-devel] network subnet

[Livnat Peer]

On 30/08/12 23:11, Alon Bar-Lev wrote:
> 
> 
> - Original Message -
>> From: "Livnat Peer" 
>> To: "Alon Bar-Lev" 
>> Cc: engine-devel@ovirt.org
>> Sent: Thursday, August 30, 2012 10:16:05 PM
>> Subject: Re: [Engine-devel] network subnet
>>
>> On 30/08/12 21:39, Alon Bar-Lev wrote:
>>>
>>>
>>> - Original Message -
>>>> From: "Livnat Peer" 
>>>> To: engine-devel@ovirt.org
>>>> Sent: Thursday, August 30, 2012 3:22:29 PM
>>>> Subject: [Engine-devel] network subnet
>>>>
>>>> Hi All,
>>>>
>>>> Today when a user wants to define a network subnet mask, he does
>>>> it
>>>> when
>>>> he attaches the network to a host NIC.
>>>>
>>>> I was wondering if there is a reason not to define the network
>>>> subnet
>>>> on
>>>> the logical network entity (Data center level).
>>>>
>>>> Thanks, Livnat
>>>
>>> Hello,
>>>
>>> I am sorry, maybe I do not understand... the IP scheme enforces the
>>> use of address mask in order to properly route packets.
>>
>> of course. My proposal is related to our user usage of the system.
>> Today
>> ovirt user, who wants to define a network subnet, has to type the
>> subnet
>> per host (per network), I think the user should only define it once
>> on
>> the logical network entity in the Data Center.
>> Propagating the value to all hosts is needed but it should be our
>> internal implementation detail.
>>
>>>
>>> Network mask is used in any case, I guess it can be dropped from
>>> configuration in favour of using the address class as mask, is
>>> that what you suggest?
>>>
>>
>> No, hope the above paragraph made it more clear.
>>
> 
> Hello,
> 
> Then you assume that a logical network, which is actually layer 2 network in 
> our implementation, has layer 3 characteristics, right?
> 
> In our current implementation "data center logical network" is pure layer 2 
> segment aka layer 2 broadcast domain.
> 
> One can use the same logical network for multiple layer 3 segments, which is 
> totally valid and consistent with standard physical layer 2 setup.
> 
> Unless I am missing something crucial, I would suggest to keep the consistent 
> physical->virtual mapping, unless we emulate layer 3 switching. Layer 2 does 
> not have layer 3 characteristics.
> 
> Regards,
> Alon.
> 

Generally I agree with what you wrote.

I would like to open for discussion the definition mentioned above that
a logical network is a layer 2 broadcast domain.

We have 2 types of logical networks, VM networks and 'other' (host
functionality?) networks.

When talking about VM networks, I think the definition above is
accurate, the guests using the network should get a layer 2 broadcast
domain.
It can be implemented over a single (physical) layer 2 domain or it can
be implemented over multiple (physical) layer 2 domains using
technologies like tunneling or vxlan.

When talking about other networks like storage, display, migration,
etc. we are actually discussing a network which represent a common
functionality the hosts are using but I am not sure guaranteeing a layer
2 broadcast domain is interesting for such network.

Going forward I expect we'll associate layer 3 services with logical
networks. For example DHCP, DNS, LB etc.

Any thoughts/comments on the above are welcomed.


Thanks, Livnat
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options

[Livnat Peer]

On 10/09/12 09:30, Alon Bar-Lev wrote:
> 
> 
> - Original Message -
>> From: "Livnat Peer" 
>> To: "Itamar Heim" 
>> Cc: "Alon Bar-Lev" , engine-devel@ovirt.org
>> Sent: Monday, September 10, 2012 9:19:00 AM
>> Subject: Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options
>>
>> On 10/09/12 09:04, Itamar Heim wrote:
>>> On 09/10/2012 08:55 AM, Livnat Peer wrote:
>>>> The obvious advantage of keeping them in the DB vs. in code is
>>>> they can
>>>> be changed with no compilation required and today you don't need
>>>> to
>>>> restart the application for changing some of them (WIP).
>>>
>>> you can still change them in the db without code by overriding them
>>> in
>>> the db - code is just the default if there is no value in the db,
>>> right?
>>>
>>
>> copy paste from my previous mail -
>>
>> "
>> 3. I personally find holding values in code cumbersome, usually you
>> end
>> up with adding option to override the values by entries in the data
>> base.
>> "
>>
>> if you are going to maintain a table in the data base why start with
>> code from the first place
>>
>>
> 
> Because upgrading an application becomes more complex, as you need not only 
> install application binaries (rpm), but also touch the database.
> 

I don't think you can avoid upgrading the data base, regardless of the
the configuration table.


> Touching the database is a failure potential.
> 
> I will get back to your previous response later, just wanted to quick comment 
> this one.
> 
> However, if you believe that any option needs to be in database, then the 
> metadata (description, restriction, internal flag, type, default) should also 
> be moved to the database, into its own table, so that vdc_options will not 
> contain any default, so that application can enjoy modifying defaults upon 
> upgrade, and there will be no duplicate between code and database.
> 

I would like to have everything stored in the data base.
We just need to do it (which we did not have time to do so far) and we
need to think of solution for the description field,(multilingual
support is typically done via properties file).

> Microsoft "Registry" is a good example of application options handling. The 
> "Registry" holds only non-default values, allowing the application to evolve 
> (both in term of more variables and in term of different defaults), without 
> actually touching the "Registry".
> 
> Alon.
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options

[Livnat Peer]

On 10/09/12 09:04, Itamar Heim wrote:
> On 09/10/2012 08:55 AM, Livnat Peer wrote:
>> The obvious advantage of keeping them in the DB vs. in code is they can
>> be changed with no compilation required and today you don't need to
>> restart the application for changing some of them (WIP).
> 
> you can still change them in the db without code by overriding them in
> the db - code is just the default if there is no value in the db, right?
> 

copy paste from my previous mail -

"
3. I personally find holding values in code cumbersome, usually you end
up with adding option to override the values by entries in the data
base.
"

if you are going to maintain a table in the data base why start with
code from the first place

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [RFC] ovirt-engine - vdc_config default options

[Livnat Peer]

On 10/09/12 00:58, Alon Bar-Lev wrote:
> Hello All,
> 
> I would like to discuss the method we use to manage default options. I 
> believe it can be significantly simplified.
> 
> Please read though and comment.
> 
> Thank you,
> Alon Bar-Lev
> 
> ---
> 
> CURRENT STATE
> 
> Most options are located in three different locations.
> 
> Let's explain by example... The FenceQuietTimeBetweenOperationsInSec option.
> 
> ---
> ConfigValues.java
> ---
> public enum ConfigValues {
> 
> @Reloadable
> @TypeConverterAttribute(Integer.class)
> @DefaultValueAttribute("180")
> FenceQuietTimeBetweenOperationsInSec(30),
> 
> }
> ---
> 
> ---
> _config.sql
> ---
> 
> select 
> fn_db_add_config_value('FenceQuietTimeBetweenOperationsInSec','180','general');
> 
> ---
> 
> ---
> engine-config.properties
> ---
> 
> FenceQuietTimeBetweenOperationsInSec.type=Integer
> FenceQuietTimeBetweenOperationsInSec.validValues=60..600
> FenceQuietTimeBetweenOperationsInSec.description="Fence quiet time between 
> operations (in seconds)"
> FenceQuietTimeBetweenOperationsInSec.alternateKey=Fence_Quiet_Time
> 
> ---
> 
> ConfigValues.java is the base, it defines all options and appropriate 
> metadata as annotations. It defines the option name, type, default value, and 
> if reloadable.
> 
> _config.sql adds all parameters into the database using their default 
> value, we actually duplicate the parameter name and default value into the 
> sql script. Please note that even if we do not add the parameter to the 
> database the engine infrastructure will use the default value specify at 
> ConfigValues.
> 
> engine-config.properties is used as an interface to engine-config utility, a 
> command-line utility that can manipulate engine options. engine-config 
> manages only options that are specified in this property files. Property 
> files specifies user friendly description, valid values, alias, but duplicate 
> the option name and type that already specified in ConfigValues. 
> engine-config will only manage options that exists in database.
> 
> QUESTIONS
> 
> 1. Why do we store default values in database?
> 

Our intention so far was to remove default values from the code.

The values in the data base are not default values but the values of the
properties and we keep them per version were we need different values
per version.

The obvious advantage of keeping them in the DB vs. in code is they can
be changed with no compilation required and today you don't need to
restart the application for changing some of them (WIP).

> From what I managed to gather, we store default values in database under the 
> assumption that we need to keep defaults when we upgrade from one version to 
> another.
> 
> However, in most cases when upgrading an application the new defaults should 
> apply as long as they were not overridden by user. Keeping old default as a 
> new value is an exception that can be taken care of during the upgrade 
> process for selected options.
> 
> 2. Why do we keep properties file?


The properties file primary use was to add translation/description for
each property. The reason we store it in the file was that at some point
we'll support multilingual description for each property.

> 
> In practice we could specify the metadata within the property files as 
> annotations in ConfigValues.java. So why do we actually need the properties 
> file?
> 
> From what I managed to gather, we use the property file as an interface to 
> support personal, to allow adding/removing options exposed to the 
> engine-config utility. An addition of option to the property file exposes it.
> 
> SUGGESTED STATE
> 
> Establish a single place to manage options.
> Do not store default values in database.
> 
> Provide alternate method of exposing internal options to engine-config 
> utility.
> 

Maintaining that in a single place would be great.

1. Were do you store the description of each property (and optionally
support multilingual)?

2. Where do you store value per version?

3. I personally find holding values in code cumbersome, usually you end
up with adding option to override the values by entries in the data
base.


> ---
> ConfigValues.java
> ---
> public enum ConfigValues {
> 
> @Reloadable
> @Public
> @TypeConverterAttribute(Integer.class)
> @Restriction.IntegerRange(60, 600)
> @DefaultValueAttribute("180")
> @Description("Fence quiet time between operations (in seconds)")
> FenceQuietTimeBetweenOperationsInSec(30),
> 
> }
> ---
> 
> BENEFITS
> 
> No duplication of option name, type, default value, etc... between multiple 
> files. One place to role them all.
> 
> Simpler upgrade sequence, in most cases as we do want the new defaults to 
> apply.
> 
> METHOD
> 
> 1. Add @Public annotation for ConfigValues, to expose options to 
> engine-config instead of the properties file.
> 
> 2. Add @Restrict annotation for ConfigValues, instead of validValues of 
> properties file.
> 
> 3. Add @Descript

[Engine-devel] Cancelled: ovirt network

[Livnat Peer]

BEGIN:VCALENDAR
PRODID:Zimbra-Calendar-Provider
VERSION:2.0
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
BEGIN:STANDARD
DTSTART:19710101T02
TZOFFSETTO:+0200
TZOFFSETFROM:+0300
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=9;BYDAY=4SU
TZNAME:IST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19710101T02
TZOFFSETTO:+0300
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR
TZNAME:IDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:cfd70d5d-b663-41f3-b72a-15b532782b23
SUMMARY:Cancelled: ovirt network 
COMMENT:A single instance of a recurring meeting has been cancelled.
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine-
 de...@ovirt.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:vdsm-de
 v...@lists.fedorahosted.org
ATTENDEE;CN=Tony Gargya/Germany/IBM;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTI
 ON;RSVP=TRUE:mailto:gar...@de.ibm.com
ATTENDEE;CN=Dan Yasny;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;RSVP=TRUE:mail
 to:dya...@redhat.com
ATTENDEE;CN=Simon Grinberg;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE:
 mailto:si...@redhat.com
ATTENDEE;CN=Mike Kolesnik;PARTSTAT=ACCEPTED:mailto:mkole...@redhat.com
ATTENDEE;CN=Avi Tal;PARTSTAT=ACCEPTED:mailto:a...@redhat.com
ATTENDEE;CN=Igor Lvovsky;PARTSTAT=ACCEPTED:mailto:ilvov...@redhat.com
ATTENDEE;CN=Doron Fediuck;PARTSTAT=ACCEPTED:mailto:dfedi...@redhat.com
ATTENDEE;CN=Pradipta Kumar Banerjee;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED:m
 ailto:pradipta.baner...@gmail.com
ATTENDEE;CN=Gary Kotton;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED:mailto:gkotto
 n...@redhat.com
ATTENDEE;CN=Keith Robertson;PARTSTAT=ACCEPTED:mailto:krobe...@redhat.com
ATTENDEE;CN=Antoni Segura Puimedon;PARTSTAT=ACCEPTED:mailto:asegurap@redhat.
 com
ATTENDEE;CN=Thang Pham/Poughkeepsie/IBM;SENT-BY="mailto:thang.p...@us.ibm.co
 m";PARTSTAT=ACCEPTED:mailto:thang.p...@us.ibm.com
ORGANIZER;CN=Livnat Peer:mailto:lp...@redhat.com
DTSTART;TZID="Asia/Jerusalem":20120919T16
DTEND;TZID="Asia/Jerusalem":20120919T17
STATUS:CANCELLED
CLASS:PUBLIC
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
RECURRENCE-ID;TZID="Asia/Jerusalem":20120919T16
LAST-MODIFIED:20120905T090211Z
DTSTAMP:20120905T090211Z
SEQUENCE:2
DESCRIPTION:A single instance of the following meeting has been cancelled:\n
 \nSubject: ovirt network  \nOrganiser: "Livnat Peer"  \n\n
 Time: Wednesday\, 19 September\, 2012\, 4:00:00 PM - 5:00:00 PM GMT +02:00 J
 erusalem\n \nInvitees: engine-devel@ovirt.org\; vdsm-devel@lists.fedorahoste
 d.org\; gar...@de.ibm.com\; dya...@redhat.com\; si...@redhat.com\; mkolesni@
 redhat.com\; a...@redhat.com\; ilvov...@redhat.com\; dfedi...@redhat.com\; p
 radipta.baner...@gmail.com\; gkot...@redhat.com ... \n\n\n*~*~*~*~*~*~*~*~*~
 *\n\nI'm on vacation Sep 19th\, cancelling this meeting instance.\nIf you wa
 nt to have the meeting please send a new invite to the dev lists.\n\nThanks\
 , Livnat
X-ALT-DESC;FMTTYPE=text/html:A single instance of the follow
 ing meeting has been cancelled:\n\n\n\nSubject:ovirt network  \nOrgan
 iser:"Livnat Peer" <\;lp...@redhat.com>\; \n\
 n\n\nTime:Wednesday\, 19 Se
 ptember\, 2012\, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem\n \n\n\nInvitees:engine
 -de...@ovirt.org\; vdsm-de...@lists.fedorahosted.org\; gar...@de.ibm.com\; d
 ya...@redhat.com\; si...@redhat.com\; mkole...@redhat.com\; a...@redhat.com\
 ; ilvov...@redhat.com\; dfedi...@redhat.com\; pradipta.baner...@gmail.com\; 
 gkot...@redhat.com ... \n\n*~*~*~*~*~*~*~*~*~*<
 br>I'm on vacation Sep 19th\, cancelling this meeting instance.If you wa
 nt to have the meeting please send a new invite to the dev lists.Tha
 nks\, Livnat
END:VEVENT
END:VCALENDAR___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] network subnet

[Livnat Peer]

On 30/08/12 21:39, Alon Bar-Lev wrote:
> 
> 
> - Original Message -
>> From: "Livnat Peer" 
>> To: engine-devel@ovirt.org
>> Sent: Thursday, August 30, 2012 3:22:29 PM
>> Subject: [Engine-devel] network subnet
>>
>> Hi All,
>>
>> Today when a user wants to define a network subnet mask, he does it
>> when
>> he attaches the network to a host NIC.
>>
>> I was wondering if there is a reason not to define the network subnet
>> on
>> the logical network entity (Data center level).
>>
>> Thanks, Livnat
> 
> Hello,
> 
> I am sorry, maybe I do not understand... the IP scheme enforces the use of 
> address mask in order to properly route packets.

of course. My proposal is related to our user usage of the system. Today
ovirt user, who wants to define a network subnet, has to type the subnet
per host (per network), I think the user should only define it once on
the logical network entity in the Data Center.
Propagating the value to all hosts is needed but it should be our
internal implementation detail.

> 
> Network mask is used in any case, I guess it can be dropped from 
> configuration in favour of using the address class as mask, is that what you 
> suggest?
> 

No, hope the above paragraph made it more clear.

> Regards,
> Alon
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] network subnet

[Livnat Peer]

Hi All,

Today when a user wants to define a network subnet mask, he does it when
he attaches the network to a host NIC.

I was wondering if there is a reason not to define the network subnet on
the logical network entity (Data center level).

Thanks, Livnat
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Engine supporting Cluster and Data Center level 3.2

[Livnat Peer]

Hi All,

Following previous discussion on the list a patch was sent (and
accepted) to add cluster and Data center 3.2 in the engine.

http://gerrit.ovirt.org/#/c/7169/

Please note that vdsm is reporting version 3.2 for a while now (started
reporting 3.2 soon after oVirt 3.1 release was built).

To make it easier for us to keep track of what features are supported in
3.2 cluster and data center I created the following wiki page -

http://wiki.ovirt.org/wiki/Features/compatibilityVersion


Thanks, Livnat
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Serial Execution of Async Tasks

[Livnat Peer]

On 10/08/12 03:40, Eli Mesika wrote:
> 
> 
> - Original Message -
>> From: "Allon Mureinik" 
>> To: "engine-devel" 
>> Cc: "Eduardo Warszawski" , "Yeela Kaplan" 
>> , "Federico Simoncelli"
>> , "Liron Aravot" 
>> Sent: Thursday, August 9, 2012 6:41:09 PM
>> Subject: [Engine-devel] Serial Execution of Async Tasks
>>
>> Hi guys,
>>
>> As you may know the engine currently has the ability to fire an SPM
>> task, and be asynchronously be "woken-up" when it ends.
>> This is great, but we found the for the Live Storage Migration
>> feature we need something a bit complex - the ability to have a
>> series of async tasks in a single control flow.
>>
>> Here's my initial design for this, your comments and criticism would
>> be welcome:
>> http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design
> 
> Apart from the short explanation & flow , since this is a detailed design , I 
> would add
> 1) Class diagram
> 2) Flow diagram 
> 

+1, it would help understanding the flow.

- It looks like you chose not re-use/extend the ExecutionHandler (the
entity used for building the tasks view exposed to the users).
It might be a good idea to keep the separation between the engine Jobs
and the underlying vdsm tasks, but I want to make sure you are familiar
with this mechanism and ruled it out with a reason. If this is the case
please share why you decided not to use it.


- how does this design survives a jboss restart? Can you please a
section in the wiki to explain that.

-successful execution -
* "CommandBase iterates over its SPMAsyncTaskHandlers" - when?
* If the second task is an HSM command (vs. SPM command), I think you
should explain in the design how to handle such flows as well.
* Why do we need before task? can you give a concrete example of what
would you do in such a method.

- I see you added SPMAsyncTaskHandler, any reason not to use
SPMAsyncTasK to manage it own life-cycle?

- In the life-cycle managed by the SPMAsyncTaskHandler there is a step
'createTask - how to create the async task' can you please elaborate
what are the options.





Livnat

>>
>>
>> -Allon
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Proposal to add Alona Kaplan as maintainers to webadmin

[Livnat Peer]

On 12/08/12 01:20, Itamar Heim wrote:
> Alona has worked on oVirt for the past 9 months, developing several
> features in the webadmin (including localization and integrated
> dashboards) and also a slew of bugs...
> 
> I'd like to propose Alona as a maintainer of the webadmin

In the past 3 months Alona was focused on the new setup network dialog
and she did a great Job, we started with a dialog that de-facto was not
working and ended up with one of the more attractive dialogs in the
webadmin.

+1

> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Proposal to add Juan Hernandez as maintainer to packaging

[Livnat Peer]

On 12/08/12 01:19, Itamar Heim wrote:
> Juan has worked on oVirt for the past 12 months, with considerable
> contribution to the packaging and deployment parts.
> he also almost single handedly packaged ovirt engine for fedora and the
> new ovirt-engine service for fedora.
> 
> I'd like to propose Juan as a maintainer of the packaging subproject of
> ovirt-engine.
> 

+1, Juan put a lot of work in packaging ovirt-engine for Fedora, thanks
to his work we were able to push it to Fedora 17.


___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Unifying (parts of) commit templates.

[Livnat Peer]

On 09/08/12 11:52, Itamar Heim wrote:
> On 08/09/2012 09:11 AM, Livnat Peer wrote:
>> On 09/08/12 00:41, Doron Fediuck wrote:
>>> Hi All,
>>> It seems that for commit subjects, vdsm is using a general concept of-
>>>
>>> BZ#??? some message
>>>
>>> I'd like to suggest adopting it to the engine template we use today-
>>>
>>> BZ#??? >> webadmin>: short summary under 50 chars
>>>
>>> This may help us write some scripts which will work both for vdsm and
>>> engine BZs.
>>>
>>
>> +1
>> with a small change - adding a \n after the bz number -
> 
> wouldn't this kill git shortlog?
> patch short summary must be in first line iirc
> 

yes it will.
+1 for Doron's initial proposal

>> BZ#???
>> :
>> short summary under 50 chars
>>
>> Long description of what this commit is about
>>
>> Livnat
>>
>>> Doron.
>>> ___
>>> Engine-devel mailing list
>>> Engine-devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Data center level 3.2 and cluster level 3.2

[Livnat Peer]

Hi All,

We pushed a fix for bridge-less networks that requires vdsm version 3.2.
Does anyone have any concerns with adding engine cluster and DC 3.2 so
we can enable bridge-less networks?

We had in mind that DC 3.2 will support clusters 3.0, 3.1 and 3.2.
Cluster and DC 3.2 will have parity features to 3.1 ATM, except for
bridgless networks that will require 3.2 DC.


Thanks, Livnat
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Unifying (parts of) commit templates.

[Livnat Peer]

On 09/08/12 00:41, Doron Fediuck wrote:
> Hi All,
> It seems that for commit subjects, vdsm is using a general concept of-
> 
> BZ#??? some message
> 
> I'd like to suggest adopting it to the engine template we use today-
> 
> BZ#???  webadmin>: short summary under 50 chars
> 
> This may help us write some scripts which will work both for vdsm and engine 
> BZs.
> 

+1
with a small change - adding a \n after the bz number -
BZ#???
:
short summary under 50 chars

Long description of what this commit is about

Livnat

> Doron.
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] ovirt network

[Livnat Peer]

BEGIN:VCALENDAR
PRODID:Zimbra-Calendar-Provider
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
BEGIN:STANDARD
DTSTART:19710101T02
TZOFFSETTO:+0200
TZOFFSETFROM:+0300
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=9;BYDAY=4SU
TZNAME:IST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19710101T02
TZOFFSETTO:+0300
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR
TZNAME:IDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:cfd70d5d-b663-41f3-b72a-15b532782b23
RRULE:FREQ=WEEKLY;INTERVAL=5;BYDAY=WE
SUMMARY:ovirt network 
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine-
 de...@ovirt.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:vdsm-de
 v...@lists.fedorahosted.org
ATTENDEE;CN=Tony Gargya/Germany/IBM;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTI
 ON;RSVP=TRUE:mailto:gar...@de.ibm.com
ATTENDEE;CN=Dan Yasny;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:m
 ailto:dya...@redhat.com
ATTENDEE;CN=Simon Grinberg;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=T
 RUE:mailto:si...@redhat.com
ORGANIZER;CN=Livnat Peer:mailto:lp...@redhat.com
DTSTART;TZID="Asia/Jerusalem":20120815T16
DTEND;TZID="Asia/Jerusalem":20120815T17
STATUS:CONFIRMED
CLASS:PUBLIC
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
LAST-MODIFIED:20120806T075507Z
DTSTAMP:20120806T075507Z
SEQUENCE:1
DESCRIPTION:The following meeting has been modified:\n\nSubject: ovirt netwo
 rk  \nOrganiser: "Livnat Peer"  \n\nTime: 4:00:00 PM - 5:0
 0:00 PM GMT +02:00 Jerusalem\n Recurrence : Every 5 weeks on Wednesday No en
 d date Effective 15 Aug\, 2012\n\nInvitees: engine-devel@ovirt.org\; vdsm-de
 v...@lists.fedorahosted.org\; gar...@de.ibm.com\; dya...@redhat.com\; simon@r
 edhat.com \n\n\n*~*~*~*~*~*~*~*~*~*\n\nHi All\, \nAs discussed previously on
  the list\, I am adding a monthly discussion on Networking in oVirt. \nIn th
 is meeting we'll discuss general status of networking and features that we'r
 e missing. \n\nThanks\, Livnat \n\n\nBridge ID: 972506565679 \nDial-in infor
 mation: \nReservationless-Plus Toll Free Dial-In Number (US & Canada): (800)
  451-8679 \nReservationless-Plus International Dial-In Number: (212) 729-501
 6 \nConference code: 8425973915 \n\nGlobal Access Numbers Local: \nAustralia
 \, Sydney Dial-In #: 0289852326 \nAustria\, Vienna Dial-In #: 012534978196 \
 nBelgium\, Brussels Dial-In #: 027920405 \nChina Dial-In #: 4006205013 \nDen
 mark\, Copenhagen Dial-In #: 32729215 \nFinland\, Helsinki Dial-In #: 092319
 4436 \nFrance\, Paris Dial-In #: 0170377140 \nGermany\, Berlin Dial-In #: 03
 0300190579 \nIreland\, Dublin Dial-In #: 014367793 \nItaly\, Milan Dial-In #
 : 0236269529 \nNetherlands\, Amsterdam Dial-In #: 0207975872 \nNorway\, Oslo
  Dial-In #: 21033188 \nSingapore Dial-In #: 64840858 \nSpain\, Barcelona Dia
 l-In #: 935452328 \nSweden\, Stockholm Dial-In #: 0850513770 \nSwitzerland\,
  Geneva Dial-In #: 0225927881 \nUnited Kingdom Dial-In #: 02078970515 \nUnit
 ed Kingdom Dial-In #: 08445790676 \nUnited Kingdom\, LocalCall Dial-In #: 08
 445790678 \nUnited States Dial-In #: 2127295016 \n\n\nGlobal Access Numbers 
 Tollfree: \nArgentina Dial-In #: 8004441016 \nAustralia Dial-In #: 180033716
 9 \nAustria Dial-In #: 085898 \nBahamas Dial-In #: 18002054776 \nBahrain
  Dial-In #: 80004377 \nBelgium Dial-In #: 080048325 \nBrazil Dial-In #: 0800
 8921002 \nBulgaria Dial-In #: 008001100236 \nChile Dial-In #: 800370228 \nCo
 lombia Dial-In #: 018009134033 \nCosta Rica Dial-In #: 08000131048 \nCyprus 
 Dial-In #: 80095297 \nCzech Republic Dial-In #: 800700318 \nDenmark Dial-In 
 #: 80887114 \nDominican Republic Dial-In #: 18887512313 \nEstonia Dial-In #:
  8000100232 \nFinland Dial-In #: 0800117116 \nFrance Dial-In #: 0805632867 \
 nGermany Dial-In #: 8006647541 \nGreece Dial-In #: 00800127562 \nHong Kong D
 ial-In #: 800930349 \nHungary Dial-In #: 0680016796 \nIceland Dial-In #: 800
 8967 \nIndia Dial-In #: 0008006501533 \nIndonesia Dial-In #: 0018030179162 \
 nIreland Dial-In #: 1800932401 \nIsrael Dial-In #: 1809462557 \nItaly Dial-I
 n #: 800985897 \nJamaica Dial-In #: 18002050328 \nJapan Dial-In #: 012093445
 3 \nKorea (South) Dial-In #: 007986517393 \nLatvia Dial-In #: 80003339 \nLit
 huania Dial-In #: 880030479 \nLuxembourg Dial-In #: 80026595 \nMalaysia Dial
 -In #: 1800814451 \nMexico Dial-In #: 0018664590915 \nNew Zealand Dial-In #:
  0800888167 \nNorway Dial-In #: 80012994 \nPanama Dial-In #: 008002269184 \n
 Philippines Dial-In #: 180011100991 \nPoland Dial-In #: 008001210187 \nPortu
 gal Dial-In #: 800814625 \nRussian Federation Dial-In #: 81080028341012 \nSa
 int Kitts and Nevis Dial-In #: 18002059252 \nSingapore Dial-In #: 8006162235
  \nSlovak Republic Dial-In #: 081441 \nSouth Africa Dial-In #: 080098114
 8 \nSpain Dial-In #: 800300524 \nSweden Dial-In #: 200896860 \nSwitzerland D
 ial-In #: 800650077 \nTaiwan Dial-In #: 00801127141 \nThailand Dial-In #: 00
 1800656966 \nTrinida

[Engine-devel] ovirt network

[Livnat Peer]

BEGIN:VCALENDAR
PRODID:Zimbra-Calendar-Provider
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
BEGIN:STANDARD
DTSTART:19710101T02
TZOFFSETTO:+0200
TZOFFSETFROM:+0300
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=9;BYDAY=4SU
TZNAME:IST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19710101T02
TZOFFSETTO:+0300
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR
TZNAME:IDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:cfd70d5d-b663-41f3-b72a-15b532782b23
SUMMARY:ovirt network 
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine-
 de...@ovirt.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:vdsm-de
 v...@lists.fedorahosted.org
ORGANIZER;CN=Livnat Peer:mailto:lp...@redhat.com
DTSTART;TZID="Asia/Jerusalem":20120815T16
DTEND;TZID="Asia/Jerusalem":20120815T17
STATUS:CONFIRMED
CLASS:PUBLIC
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
LAST-MODIFIED:20120806T073421Z
DTSTAMP:20120806T073421Z
SEQUENCE:0
DESCRIPTION:The following is a new meeting request:\n\nSubject: ovirt networ
 k  \nOrganiser: "Livnat Peer"  \n\nTime: Wednesday\, 15 Au
 gust\, 2012\, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem\n \nInvitees: eng
 ine-de...@ovirt.org\; vdsm-de...@lists.fedorahosted.org \n\n\n*~*~*~*~*~*~*~
 *~*~*\n\nHi All\,\nAs discussed previously on the list\, I am adding a month
 ly discussion on Networking in oVirt.\nIn this meeting we'll discuss general
  status of networking and features that we're missing.\n\nThanks\, Livnat\n\
 n\nBridge ID: 972506565679\nDial-in information:\nReservationless-Plus Toll 
 Free Dial-In Number (US & Canada): (800) 451-8679\nReservationless-Plus Inte
 rnational Dial-In Number: (212) 729-5016\nConference code: 8425973915\n\nGlo
 bal Access Numbers Local:\nAustralia\, Sydney Dial-In #: 0289852326\nAustria
 \, Vienna Dial-In #: 012534978196\nBelgium\, Brussels Dial-In #: 027920405\n
 China Dial-In #: 4006205013\nDenmark\, Copenhagen Dial-In #: 32729215\nFinla
 nd\, Helsinki Dial-In #: 0923194436\nFrance\, Paris Dial-In #: 0170377140\nG
 ermany\, Berlin Dial-In #: 030300190579\nIreland\, Dublin Dial-In #: 0143677
 93\nItaly\, Milan Dial-In #: 0236269529\nNetherlands\, Amsterdam Dial-In #: 
 0207975872\nNorway\, Oslo Dial-In #: 21033188\nSingapore Dial-In #: 64840858
 \nSpain\, Barcelona Dial-In #: 935452328\nSweden\, Stockholm Dial-In #: 0850
 513770\nSwitzerland\, Geneva Dial-In #: 0225927881\nUnited Kingdom Dial-In #
 : 02078970515\nUnited Kingdom Dial-In #: 08445790676\nUnited Kingdom\, Local
 Call Dial-In #: 08445790678\nUnited States Dial-In #: 2127295016\n\n\nGlobal
  Access Numbers Tollfree:\nArgentina Dial-In #: 8004441016\nAustralia Dial-I
 n #: 1800337169\nAustria Dial-In #: 085898\nBahamas Dial-In #: 180020547
 76\nBahrain Dial-In #: 80004377\nBelgium Dial-In #: 080048325\nBrazil Dial-I
 n #: 08008921002\nBulgaria Dial-In #: 008001100236\nChile Dial-In #: 8003702
 28\nColombia Dial-In #: 018009134033\nCosta Rica Dial-In #: 08000131048\nCyp
 rus Dial-In #: 80095297\nCzech Republic Dial-In #: 800700318\nDenmark Dial-I
 n #: 80887114\nDominican Republic Dial-In #: 18887512313\nEstonia Dial-In #:
  8000100232\nFinland Dial-In #: 0800117116\nFrance Dial-In #: 0805632867\nGe
 rmany Dial-In #: 8006647541\nGreece Dial-In #: 00800127562\nHong Kong Dial-I
 n #: 800930349\nHungary Dial-In #: 0680016796\nIceland Dial-In #: 8008967\nI
 ndia Dial-In #: 0008006501533\nIndonesia Dial-In #: 0018030179162\nIreland D
 ial-In #: 1800932401\nIsrael Dial-In #: 1809462557\nItaly Dial-In #: 8009858
 97\nJamaica Dial-In #: 18002050328\nJapan Dial-In #: 0120934453\nKorea (Sout
 h) Dial-In #: 007986517393\nLatvia Dial-In #: 80003339\nLithuania Dial-In #:
  880030479\nLuxembourg Dial-In #: 80026595\nMalaysia Dial-In #: 1800814451\n
 Mexico Dial-In #: 0018664590915\nNew Zealand Dial-In #: 0800888167\nNorway D
 ial-In #: 80012994\nPanama Dial-In #: 008002269184\nPhilippines Dial-In #: 1
 80011100991\nPoland Dial-In #: 008001210187\nPortugal Dial-In #: 800814625\n
 Russian Federation Dial-In #: 81080028341012\nSaint Kitts and Nevis Dial-In 
 #: 18002059252\nSingapore Dial-In #: 8006162235\nSlovak Republic Dial-In #: 
 081441\nSouth Africa Dial-In #: 0800981148\nSpain Dial-In #: 800300524\n
 Sweden Dial-In #: 200896860\nSwitzerland Dial-In #: 800650077\nTaiwan Dial-I
 n #: 00801127141\nThailand Dial-In #: 001800656966\nTrinidad and Tobago Dial
 -In #: 18002024615\nUnited Arab Emirates Dial-In #: 8000650591\nUnited Kingd
 om Dial-In #: 08006948057\nUnited States Dial-In #: 8004518679\nUruguay Dial
 -In #: 00040190315\nVenezuela Dial-In #: 08001627182
X-ALT-DESC;FMTTYPE=text/html:The following is a new meeting 
 request:\n\n\n\nSubject:ovirt network  \nOrganiser:"Livnat P
 eer" <\;lp...@redhat.com>\; \n\n\n\nTime:Wednesday\, 15 August\, 2012\, 4:00:00 P
 M - 5:00:00 PM GMT +02:00 Jerusalem\n \n\n\nInvitees:engine-devel@ovirt.org\; vdsm-de
 v...@lists.

[Engine-devel] oVirt engine core

[Livnat Peer]

BEGIN:VCALENDAR
PRODID:Zimbra-Calendar-Provider
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
BEGIN:STANDARD
DTSTART:19710101T02
TZOFFSETTO:+0200
TZOFFSETFROM:+0300
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=9;BYDAY=4SU
TZNAME:IST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19710101T02
TZOFFSETTO:+0300
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR
TZNAME:IDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:f9f190e9-f568-4103-b8bc-f549b2d47ece
RRULE:FREQ=WEEKLY;UNTIL=20120814T205959Z;INTERVAL=2;BYDAY=WE
SUMMARY:oVirt engine core
DESCRIPTION:Hi All\,\n\nI am cancelling this series as we set a specific mee
 ting for any subject that needs to be discussed.\nSome of the discussions ar
 e taking place on the ovirt general sync meetings.\n\nThanks\, Livnat
X-ALT-DESC;FMTTYPE=text/html:The following meeting has been 
 modified:\n\n\n\nSubject:<
 td>oVirt engine core \nOrganiser:"Livn
 at Peer" <\;lp...@redhat.com>\; \n\n\n\nTime:4:00:00 PM - 5:00:00 PM GMT +02:00 J
 erusalem [MODIFIED]\n Recurrence: Ever
 y 2 weeks on Wednesday End by 14 Aug\, 2012 Effective 23 Nov\, 2011\n\n\n\nInvitees:e
 ngine-de...@ovirt.org\; wangbo_b...@hotmail.com\; mkole...@redhat.com\; ykau
 l...@redhat.com\; ofren...@redhat.com\; lhorn...@redhat.com\; smizrahi@redhat.c
 om\; oschr...@redhat.com\; sgor...@redhat.com\; dedu...@cisco.com\; emesika@
 redhat.com ... \n\n*~*~*~*~*~*~*~*~*~*Hi Al
 l\,I am cancelling this series as we set a specific meeting for any 
 subject that needs to be discussed.Some of the discussions are taking pl
 ace on the ovirt general sync meetings.Thanks\, Livnat
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=FALSE:mailto:engine
 -de...@ovirt.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=FALSE:mailto:wangbo_bup
 t...@hotmail.com
ATTENDEE;CN=Mike Kolesnik;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=FALSE:
 mailto:mkole...@redhat.com
ATTENDEE;CN=Yaniv Kaul;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;RSVP=FALSE:ma
 ilto:yk...@redhat.com
ATTENDEE;CN=Omer Frenkel;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=FALSE:m
 ailto:ofren...@redhat.com
ATTENDEE;CN=Laszlo Hornyak;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=FALSE
 :mailto:lhorn...@redhat.com
ATTENDEE;CN=Saggi Mizrahi;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=FALSE:
 mailto:smizr...@redhat.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=FALSE:mailto:oschreib@r
 edhat.com
ATTENDEE;CN=Steve Gordon;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=FALSE:m
 ailto:sgor...@redhat.com
ATTENDEE;CN=Debo Dutta;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=FALSE:mai
 lto:dedu...@cisco.com
ATTENDEE;CN=Eli Mesika;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=FALSE:mai
 lto:emes...@redhat.com
ATTENDEE;CN=Barak Azulay;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;RSVP=FALSE:
 mailto:bazu...@redhat.com
ATTENDEE;CN=Jon Choate;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=FALSE:mai
 lto:jcho...@redhat.com
ATTENDEE;CN=Keith Robertson;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=FALS
 E:mailto:krobe...@redhat.com
ATTENDEE;CN=Ayal Baron;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=FALSE:mai
 lto:aba...@redhat.com
ORGANIZER;CN=Livnat Peer:mailto:lp...@redhat.com
DTSTART;TZID="Asia/Jerusalem":2023T16
DTEND;TZID="Asia/Jerusalem":2023T17
STATUS:CONFIRMED
CLASS:PUBLIC
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
LAST-MODIFIED:20120806T072751Z
DTSTAMP:20120806T072751Z
SEQUENCE:2
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;RELATED=START:-PT5M
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Migration status of a VM

[Livnat Peer]

On 24/07/12 10:39, Itzik Brown wrote:
> Hi,
> 
>  
> 
> Is it possible to know the status of a VM through the API – whether it's
> in a migration process and if it is , what are the source and destination?
> 
>  
> 
> Thanks,
> 
> Itzik
> 

Hi Itzik,

The status is part of the VM in the API, when the VM is migrating the VM
status changes to migrating

The source host is available in the VM in property named host (it is
mapped to run_on_vds in the backend)

The destination - well it seems to not be mapped in the api, in the
backend we hold it in VmDynamic migrating_to_vds

Ori - do you know why we don't have it in the VM in the API?

Anyway it looks like an easy fix and maybe you can open a BZ for it.


Livnat




> 
> 
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] java 1.6 compatibility no more?

[Livnat Peer]

On 21/07/12 15:15, Itamar Heim wrote:
> On 07/19/2012 03:34 PM, Ayal Baron wrote:
>>
>>
>> - Original Message -
>>>
>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
>>>
>>>> On 19/07/12 14:41, Juan Hernandez wrote:
>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
>>>>>>>> Don't we need that (the source part) to avoid Java 7 syntax in
>>>>>>>> GWT code?
>>>>>>>
>>>>>>> That's a very good point.
>>>>>>>
>>>>>>> In general, GWT compiler supports Java 5 syntax (note that there
>>>>>>> are no language changes between Java 5 and 6). For this reason,
>>>>>>> our frontend code should be compliant with Java 5. If someone
>>>>>>> uses new Java 7 language features in frontend code, GWT
>>>>>>> compiler will throw an error and the build will fail.
>>>>>>>
>>>>>>> So the 'Java 5 only' limitation applies to frontend code and any
>>>>>>> other code (e.g. shared modules) that is directly referenced by
>>>>>>> frontend code. This shouldn't affect the backend, however.
>>>>>>>
>>>>>>> We could do something like this:
>>>>>>>
>>>>>>> - let oVirt root POM declare source and target compliance to
>>>>>>> Java 7
>>>>>>> - let frontend modules POM (frontend/webadmin/modules/pom.xml)
>>>>>>> declare source compliance to Java 5 (or 6)
>>>>>>>
>>>>>>> (note that target compliance can be left to Java 7 since
>>>>>>> frontend compilation results in JavaScript code)
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Vojtech
>>>>>>
>>>>>> +1 - I really like this idea!
>>>>>
>>>>> +1 from me as well.
>>>>
>>>>
>>>> There are two calls to make when it comes to JDK7 (regardless of
>>>> GWT -
>>>> excuse me for taking this discussion some steps backwards)
>>>>
>>>> 1. Are we running with JRE 7?
>>>> The answer is yes we agreed on that a few months ago.
>>>>
>>>> 2. Are we using code syntax which is incompatible with JDK6?
>>>>
>>>> I think the answer to the above should be no (at least for now -
>>>> maybe
>>>> until the next ovirt release?).
>>> +1
>>> exactly. Why starting with jdk6 incompatible constructs unless there
>>> is a good (or at least any) reason for them…
>>
>> +1
> 
> +1 - there is merit keeping backward compatibility to allow comparing
> behavior while java 7 is still young.

Since no one objected, we'll go with JDK6 syntax compatibility for Now.

Kublin - can you please send a patch to remove the usage of Long.Compare
in StorageDomainCommandBase

Thanks, Livnat


> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] java 1.6 compatibility no more?

[Livnat Peer]

On 19/07/12 14:41, Juan Hernandez wrote:
> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
 Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
>>>
>>> That's a very good point.
>>>
>>> In general, GWT compiler supports Java 5 syntax (note that there are no 
>>> language changes between Java 5 and 6). For this reason, our frontend code 
>>> should be compliant with Java 5. If someone uses new Java 7 language 
>>> features in frontend code, GWT compiler will throw an error and the build 
>>> will fail.
>>>
>>> So the 'Java 5 only' limitation applies to frontend code and any other code 
>>> (e.g. shared modules) that is directly referenced by frontend code. This 
>>> shouldn't affect the backend, however.
>>>
>>> We could do something like this:
>>>
>>> - let oVirt root POM declare source and target compliance to Java 7
>>> - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare 
>>> source compliance to Java 5 (or 6)
>>>
>>> (note that target compliance can be left to Java 7 since frontend 
>>> compilation results in JavaScript code)
>>>
>>> What do you think?
>>>
>>> Vojtech
>>
>> +1 - I really like this idea!
> 
> +1 from me as well.


There are two calls to make when it comes to JDK7 (regardless of GWT -
excuse me for taking this discussion some steps backwards)

1. Are we running with JRE 7?
The answer is yes we agreed on that a few months ago.

2. Are we using code syntax which is incompatible with JDK6?

I think the answer to the above should be no (at least for now - maybe
until the next ovirt release?).

There are two reason off the top of my head for that -
If we find an issue it is easier to compare the issue on JDK6 vs. JDK7
if the code compiles on both.

Open JDK7 is out for a year or so, It was packaged for fedora only in
March  2012, I am not sure how ofter it is used in 'production'
environment, I think we should at least keep ourself the option to
roll-back in case we need it.


Livnat



> 
>>> - Original Message -
>>> From: "Juan Hernandez" 
>>> To: "Vojtech Szocs" 
>>> Cc: "Yair Zaslavsky" , engine-devel@ovirt.org
>>> Sent: Thursday, July 19, 2012 11:01:00 AM
>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more?
>>>
>>> On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
> As I previously emailed - JDK7 already fixed a known issue with ldap and
> DNS ,and made one of my patches at gerrit redundant.
> Why not enjoy the bug fixes?

 I agree, but in that case, why not switch to '1.7' Java source/target 
 compliance for oVirt Maven build as well?

 If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, 
 because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven 
 POM files. Currently, when I import oVirt projects into Eclipse (using 
 Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This 
 is because our Maven POM files declare '1.6' Java source/target compliance.

 Juan - you are right, but for me, it sounds quite strange to have '1.6' 
 Java source/target compliance for Maven build, and use JDK7 to do the 
 build.
>>>
>>> Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
>>>
 - Original Message -
 From: "Yair Zaslavsky" 
 To: engine-devel@ovirt.org
 Sent: Thursday, July 19, 2012 7:59:45 AM
 Subject: Re: [Engine-devel] java 1.6 compatibility no more?

 On 07/18/2012 08:21 PM, Juan Hernandez wrote:
> On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
>> In fact, for both backend and frontend, Maven effective POM contains:
>>
>> maven-compiler-plugin
>> 
>>   1.6
>>   1.6
>> 
>>
>> Therefore, according to Maven POM files, oVirt should be build-able 
>> using Java 6, but it's not. (?)
>
> These maven settings just tell the java compiler to accept Java 6 syntax
> only and to generate a Java 6 compatible .class file format, but they
> don't restrict the set of APIs that can be used.
>
>> The problem is in backend/manager/modules/bll: StorageDomainCommandBase 
>> class uses new Java 7 Long.compare() static method.
>>
>> I think we should decide if we want to be compliant with Java 7, or 
>> submit a patch that uses Java 6 API (Long.compareTo instance method).
>>
>> Vojtech

 As I previously emailed - JDK7 already fixed a known issue with ldap and
 DNS ,and made one of my patches at gerrit redundant.
 Why not enjoy the bug fixes?

>>
>>
>> - Original Message -
>> From: "Laszlo Hornyak" 
>> To: "engine-devel" 
>> Cc: "Vojtech Szocs" 
>> Sent: Wednesday, July 18, 2012 5:43:34 PM
>> Subject: java 1.6 compatibility no more?
>>
>> Hi,
>>
>> It may be a historic moment, but for a few hours oVirt engine is no 
>> longer building on java 1.6.
>> Is this intentional?
>>

Re: [Engine-devel] [vdsm] Getting rid of a...@ovirt.org?

[Livnat Peer]

On 16/07/12 10:01, Itamar Heim wrote:
> On 07/16/2012 09:56 AM, Livnat Peer wrote:
>> On 16/07/12 09:41, Itamar Heim wrote:
>>> On 07/16/2012 01:46 AM, Robert Middleswarth wrote:
>>>> On 07/15/2012 03:59 PM, Ayal Baron wrote:
>>>>>
>>>>> - Original Message -
>>>>>> -BEGIN PGP SIGNED MESSAGE-
>>>>>> Hash: SHA1
>>>>>>
>>>>>> On 07/15/2012 01:53 AM, Ayal Baron wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Sorry for cross-posting, but in this case I think it's relevant.
>>>>>>>
>>>>>>> The original idea was that every time we wish to discuss a new
>>>>>>> cross-component feature we should do it over arch list. However, it
>>>>>>> would appear that de-facto usually engine-devel and vdsm-devel are
>>>>>>> being used (cross posted). Currently engine-devel has 211
>>>>>>> subscribers, arch has 160 and vdsm-devel has 128 so from this
>>>>>>> perspective again, arch seems less relevant. I propose we ditch
>>>>>>> arch and keep the other 2 mailing lists. I'm not sure whether new
>>>>>>> cross-component features should be discussed solely on engine-devel
>>>>>>> or cross-posted (there are probably people who wouldn't care about
>>>>>>> engine side but would still like to know about such changes).
>>>>>>>
>>>>>>> Thoughts?
>>>>>> - -1
>>>>>>
>>>>>> I don't normally read engine-devel and vdsm-devel, so I hadn't
>>>>>> noticed
>>>>>> that discussions I would expect to be on arch@ are not happening
>>>>>> here.
>>>>>> I'm probably not the only person in that situation.
>>>>>>
>>>>>> If this project were 100% about Engine and VDSM, then I could
>>>>>> understand your reasoning. But we've already added a few new
>>>>>> incubating projects, we have subsystem teams such as documentation
>>>>>> and
>>>>>> infrastructure, and we all need a single location where we know we
>>>>>> can
>>>>>> reach *all* contributors to this project.
>>>>>>
>>>>>> If we try to force all that discussion on to engine-devel, not
>>>>>> everyone would be interested. There is enough on engine-devel that is
>>>>>> not general interest that it would become noise (as it has for me, so
>>>>>> I filter it) or people would drop it all together.
>>>>>>
>>>>>> Perhaps what we need to do is have the discipline to cross-post *all*
>>>>>> general interest discussions from the project mailing list back to
>>>>>> arch@? Enforce the rule that decisions that affect the whole project
>>>>>> have to be ratified on arch@ instead of whatever project list the
>>>>>> discussions started on? Strongly suggest that all contributors be on
>>>>>> arch@ and announce@ as a minimum?
>>>>> I find that anything that should go on arch would interest anyone on
>>>>> the devel lists (as it is about new features, design, etc) so I
>>>>> believe that arch should have at least everyone on engine-devel and
>>>>> vdsm-devel.
>>>>> However, right now this is not the case as is evident by number of
>>>>> subs to each list (e.g. I haven't compared to see if everyone on arch
>>>>> is on engine).
>>>>> So imo something needs to be done.
>>>>> I'm fine with keeping arch, but as you said, that means we need to
>>>>> enforce it to be *the* list for feature discussions and I'm not
>>>>> exactly sure how you'd go about doing that.
>>>> Maybe arch needs renamed to make it clear what if is for?
>>>>
>>>> Maybe something simple like ovirt-devel to make it clear it is for
>>>> generally ovirt development?
>>>
>>> we can simply make it arch include the other mailing lists, so sending
>>> to arch would be sending to all other mailing lists.
>>
>> What would happen if someone reply on the engine-list to a mail
>> originally sent to arch?
>>
>> wouldn't we end-up starting a thread on arch and then loosing it to one
>> of the other lists?
> 
> reply-to is not set to reply-to-list, rather to original sender/cc list,
> so shouldn't be an issue
> 

ok so if reply to such mail de-facto I'll send a mail to the arch list -
shouldn't I be register to the arch list (or I need someone to approve
the mail)?


>>
>>
>>> wouldn't resolve the dupes, but will resolve need of everyone to
>>> subscribe to it as well.
>>> (for dupes i also use a mail filter to delete emails arriving from
>>> engine-devel and cc other mailing list, etc.
>>> ___
>>> Arch mailing list
>>> a...@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>>
> 
> 


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] [vdsm] Getting rid of a...@ovirt.org?

[Livnat Peer]

On 16/07/12 09:41, Itamar Heim wrote:
> On 07/16/2012 01:46 AM, Robert Middleswarth wrote:
>> On 07/15/2012 03:59 PM, Ayal Baron wrote:
>>>
>>> - Original Message -
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 07/15/2012 01:53 AM, Ayal Baron wrote:
> Hi all,
>
> Sorry for cross-posting, but in this case I think it's relevant.
>
> The original idea was that every time we wish to discuss a new
> cross-component feature we should do it over arch list. However, it
> would appear that de-facto usually engine-devel and vdsm-devel are
> being used (cross posted). Currently engine-devel has 211
> subscribers, arch has 160 and vdsm-devel has 128 so from this
> perspective again, arch seems less relevant. I propose we ditch
> arch and keep the other 2 mailing lists. I'm not sure whether new
> cross-component features should be discussed solely on engine-devel
> or cross-posted (there are probably people who wouldn't care about
> engine side but would still like to know about such changes).
>
> Thoughts?
 - -1

 I don't normally read engine-devel and vdsm-devel, so I hadn't
 noticed
 that discussions I would expect to be on arch@ are not happening
 here.
 I'm probably not the only person in that situation.

 If this project were 100% about Engine and VDSM, then I could
 understand your reasoning. But we've already added a few new
 incubating projects, we have subsystem teams such as documentation
 and
 infrastructure, and we all need a single location where we know we
 can
 reach *all* contributors to this project.

 If we try to force all that discussion on to engine-devel, not
 everyone would be interested. There is enough on engine-devel that is
 not general interest that it would become noise (as it has for me, so
 I filter it) or people would drop it all together.

 Perhaps what we need to do is have the discipline to cross-post *all*
 general interest discussions from the project mailing list back to
 arch@? Enforce the rule that decisions that affect the whole project
 have to be ratified on arch@ instead of whatever project list the
 discussions started on? Strongly suggest that all contributors be on
 arch@ and announce@ as a minimum?
>>> I find that anything that should go on arch would interest anyone on
>>> the devel lists (as it is about new features, design, etc) so I
>>> believe that arch should have at least everyone on engine-devel and
>>> vdsm-devel.
>>> However, right now this is not the case as is evident by number of
>>> subs to each list (e.g. I haven't compared to see if everyone on arch
>>> is on engine).
>>> So imo something needs to be done.
>>> I'm fine with keeping arch, but as you said, that means we need to
>>> enforce it to be *the* list for feature discussions and I'm not
>>> exactly sure how you'd go about doing that.
>> Maybe arch needs renamed to make it clear what if is for?
>>
>> Maybe something simple like ovirt-devel to make it clear it is for
>> generally ovirt development?
> 
> we can simply make it arch include the other mailing lists, so sending
> to arch would be sending to all other mailing lists.

What would happen if someone reply on the engine-list to a mail
originally sent to arch?

wouldn't we end-up starting a thread on arch and then loosing it to one
of the other lists?


> wouldn't resolve the dupes, but will resolve need of everyone to
> subscribe to it as well.
> (for dupes i also use a mail filter to delete emails arriving from
> engine-devel and cc other mailing list, etc.
> ___
> Arch mailing list
> a...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Please review: Sync Networks enhancement

[Livnat Peer]

On 15/07/12 12:03, Miki Kenneth wrote:
> 
> 
> - Original Message -
>> On 15/07/12 11:14, Miki Kenneth wrote:
>>> I would like to see an alert notification when the host is
>>> Installed/added, and not only on the network dialog.
>>> There should be a message on the audit log for sure, alert ?
>>>
>>>
>>
>> Miki,
>>
>> Are you talking about issuing an audit log message when installing a
>> host ( / changing the host DC ) if there is a mismatch between the
>> logical network definition and the actual host network configuration?
> yes, that is what i was referring to.


Mike - can you please add that to the wiki.




>>
>> Thanks, Livnat
>>
>>
>>>
>>>
>>> - Original Message -
 - Original Message -
>
> - Original Message -
>
>> From: "Mike Kolesnik" 
>> To: "engine-devel" 
>> Sent: Wednesday, July 11, 2012 4:57:42 AM
>> Subject: [Engine-devel] Please review: Sync Networks enhancement
>
>> http://www.ovirt.org/wiki/SetupNetworks_SyncNetworks
>
>> Please review this enhancement to the way network attachment on
>> host
>> network device is kept in sync or not.
>
> Perhaps we need a way on the host for the administrator to label
> a
> network so it is flagged by vdsm?
> For example on a RHEL/Fedora system you can use NM_CONTROLLED=no
> in
> the ifcfg-* files to tell network manager to ignore it.
>
>

 Can you please elaborate on this?

>
>
>> Regards,
>> Mike
>
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

>>> ___
>>> Engine-devel mailing list
>>> Engine-devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>>
>>


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Please review: Sync Networks enhancement

[Livnat Peer]

On 15/07/12 11:14, Miki Kenneth wrote:
> I would like to see an alert notification when the host is Installed/added, 
> and not only on the network dialog.
> There should be a message on the audit log for sure, alert ? 
> 
> 

Miki,

Are you talking about issuing an audit log message when installing a
host ( / changing the host DC ) if there is a mismatch between the
logical network definition and the actual host network configuration?

Thanks, Livnat


> 
> 
> - Original Message -
>> - Original Message -
>>>
>>> - Original Message -
>>>
 From: "Mike Kolesnik" 
 To: "engine-devel" 
 Sent: Wednesday, July 11, 2012 4:57:42 AM
 Subject: [Engine-devel] Please review: Sync Networks enhancement
>>>
 http://www.ovirt.org/wiki/SetupNetworks_SyncNetworks
>>>
 Please review this enhancement to the way network attachment on
 host
 network device is kept in sync or not.
>>>
>>> Perhaps we need a way on the host for the administrator to label a
>>> network so it is flagged by vdsm?
>>> For example on a RHEL/Fedora system you can use NM_CONTROLLED=no in
>>> the ifcfg-* files to tell network manager to ignore it.
>>>
>>>
>>
>> Can you please elaborate on this?
>>
>>>
>>>
 Regards,
 Mike
>>>
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Requirements for hosts in a non-virt cluster.

[Livnat Peer]

On 12/07/12 22:49, Itamar Heim wrote:
> On 07/12/2012 04:19 PM, Steve Gordon wrote:
>> Hi guys,
>>
>> When creating a cluster with 'Enable virt service' selected when a
>> host is later added to it we use vdsGetCaps to check that the host has
>> the required virtualization extensions etc. What checks are performed
>> if 'Enable virt service' is *not* checked but 'Enable gluster service'
>> is?
> 
> iirc, same checks except the kvm / VT is enabled in host and bios.
> gluster still need to add bootstrap code to install and configure the
> gluster rpms, ip tables, etc.
> 

Adding to the above - from a quick look we have 3 phases -

1. Networking validation - shared for virt and gluster (network topology
that is required by the cluster is enforced)

2. processSoftwareCapabilities - empty implementation for gluster
(GlusterMonitoringStrategy)

3. processHardwareCapabilities - empty implementation for gluster
(GlusterMonitoringStrategy)


Livnat

>>
>> Steve
>> ___
>> Engine-devel mailing list
>> Engine-devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> 
> ___
> Engine-devel mailing list
> Engine-devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

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

[Livnat Peer]

On 05/07/12 13:23, Mike Kolesnik wrote:
>> On 07/05/2012 12:19 PM, Livnat Peer wrote:
>>>> I'll give you one scenario and I'm sure there are lot more:
>>>>> delete all unused networks 
>>>>>
>>> not strong enough use case in my opinion
>>
>> i do see sense in this, and based on my experience of
>> closing ~5 bugs on this for SD and explaining like
>> ~10 times on ML to users why /api/storagedomains/xxx
>> doesn't have , I'm sure it should be done this way
>> as it creates clear differentiation between root-resource
>> and cluster-resource (shared) status.
>>
>>> to add this yet another confusing property.
>>
>> you not adding another property, you fix existent
>> (which was incorrectly used/implemented).
>>
>>>
>>> BTW - If a requirement will get from the field to add properties we
>>> can
>>> do them later why add something we think is not needed.
>>>
>>>
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>>
> 
> I think we got a little bit off the topic here, so if you don't mind I would 
> like to see if everyone agrees on this:
> 
> We have at the api/networks collection these properties and their possible 
> values:
>   status - OPERATIONAL, NON_OPERATIONAL
>   display - true, false
> 
> We (as far as I understood) agreed that these fields causea problem in this 
> context since they can be different for a given network, and current 
> representation will return the network element multiple times with only 
> difference in either one of these fields.
> Also I understood we agreed that this is bad behaviour (even a bug) and we 
> don't want to support this anymore.
> 
> This gives 2 choices IMHO:
>   1. Fix the behaviour but keep the fields with some default values.
>   2. Fix the behaviour and remove these field as well, which isn't really 
> breaking an API since the behaviour was broken to begin with.
> 

So a summary of the thread so far:

Simon, Miki Ori and me voted +1 for option #2

Michael wants to change the value of the status field to attach/detach

Anyone else wants to vote in on this?


> Please comment what option seems valid (I though we were going to the 
> direction of fix #2).
> 
> Thanks,
> Mike
> 


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

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

[Livnat Peer]

On 05/07/12 12:13, Michael Pasternak wrote:
> On 07/05/2012 12:06 PM, Livnat Peer wrote:
>> 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  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,
>>> attached|unattached 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.
> 
> I'll give you one scenario and I'm sure there are lot more:
> delete all unused networks 
> 

not strong enough use case in my opinion to add this yet another
confusing property.

BTW - If a requirement will get from the field to add properties we can
do them later why add something we think is not needed.


>>
>>
>>> (without this  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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

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

[Livnat Peer]

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  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,
> attached|unattached 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  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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [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  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
>>
>>
>>
> 
> 


___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

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

[Livnat Peer]

On 05/07/12 10:24, Miki Kenneth wrote:
> 
> 
> - Original Message -
>>
>>
>> - Original Message -
>>> From: "Itamar Heim" 
>>> To: "Simon Grinberg" 
>>> Cc: "engine-devel" 
>>> Sent: Wednesday, July 4, 2012 7:38:46 PM
>>> Subject: Re: [Engine-devel] Fwd: Problem in REST API
>>> handling/displaying of logical networks
>>>
>>> On 07/04/2012 07:27 PM, Simon Grinberg wrote:
>>>>
>>>>
>>>> - Original Message -
>>>>> From: "Livnat Peer" 
>>>>> To: "Itamar Heim" 
>>>>> Cc: "engine-devel" 
>>>>> Sent: Tuesday, July 3, 2012 10:06:37 PM
>>>>> Subject: Re: [Engine-devel] Fwd: Problem in REST API
>>>>> handling/displaying of logical networks
>>>>>
>>>>> On 03/07/12 21:28, Itamar Heim wrote:
>>>>>> On 07/03/2012 10:30 AM, Livnat Peer wrote:
>>>>>>> On 02/07/12 17:35, Mike Kolesnik wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> I would like to hear opinions about a behaviour that I think
>>>>>>>> is
>>>>>>>> problematic in
>>>>>>>> REST API handling of logical networks.
>>>>>>>>
>>>>>>>> -- Intro --
>>>>>>>> Today in the REST API we are exposing two collections for
>>>>>>>> "logical
>>>>>>>> network" related entities.
>>>>>>>>
>>>>>>>> First is a top level collection which is out of any context
>>>>>>>> at
>>>>>>>> the
>>>>>>>> address
>>>>>>>> http://engine/api/networks.
>>>>>>>> Second is a sub-collection in the context of a cluster:
>>>>>>>> http://engine/api/cluster/xxx/networks
>>>>>>>>
>>>>>>>> The network itself is defined per DC level, so for each DC
>>>>>>>> you
>>>>>>>> would
>>>>>>>> have
>>>>>>>> at least one logical network for management, which has some
>>>>>>>> properties such
>>>>>>>> as STP, MTU, etc..
>>>>>>>> The top level collection is used to create/delete such
>>>>>>>> network
>>>>>>>> entities.
>>>>>>>>
>>>>>>>> The sub-collection in the context of a Cluster is used to
>>>>>>>> attach/detach a
>>>>>>>> network from the DC of that cluster.
>>>>>>>> The network in the context of a cluster has some additional
>>>>>>>> information,
>>>>>>>> let's
>>>>>>>> say for example 'status' of the network:
>>>>>>>>   If a network is defined on all hosts in the cluster
>>>>>>>>   then
>>>>>>>>   it's
>>>>>>>> status is
>>>>>>>>   'Operational'.
>>>>>>>>   If a network is not defined on some of the hosts in the
>>>>>>>>   cluster
>>>>>>>> then
>>>>>>>> it's
>>>>>>>>   status is 'Not Operational'[1].
>>>>>>>>
>>>>>>>>
>>>>>>>> -- Problem --
>>>>>>>> The problem is that details which are only relevant in
>>>>>>>> context
>>>>>>>> of
>>>>>>>> a
>>>>>>>> cluster, are still displayed in the root context as well
>>>>>>>> (e.g:
>>>>>>>> 'status').
>>>>>>>> This can, in certain cases, cause unexpected behaviour.
>>>>>>>>
>>>>>>>> For example, let's consider this topology:
>>>>>>>> Data Center A
>>>>>>>>   |
>>>>>>>>   |\ Network 'red'
>>>>>>>>   |\ Cluster A1
>>>>>>>>   |  \__ Network 'red' at