From amureini at redhat.com  Thu Mar  1 08:31:53 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Thu, 01 Mar 2012 03:31:53 -0500 (EST)
Subject: [Engine-devel] synthetic-access
In-Reply-To: <961907e9-d4e3-4c27-b56d-f8bdd5046d6c@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <20014738-a8b1-4ef6-ba02-e579d110d843@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, February 29, 2012 7:39:37 PM
> Subject: Re: [Engine-devel] synthetic-access
> 
> > On 02/29/2012 04:23 PM, Laszlo Hornyak wrote:
> > > Hi,
> > > 
> > > I am reviewing Allon's patches (e.g.
> > > http://gerrit.ovirt.org/#patch,sidebyside,2188,11,backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dao/VdsGroupDAODbFacadeImpl.java
> > > ) and this is the first time I have met
> > > @SuppressWarnings("synthetic-access") annotations in the ovirt
> > > code. It is right, eclipse warns about the performance problem
> > > synthetic access (if turned on, by default it is turned off).
> > > This
> > > mostly happens in DAO's because rowmappers are private inner
> > > classes. What if, instead of adding an annotation to ignore this
> > >  - we could make the rowmapper classes package protected?
> > >  - or since most of these classes are stateless and thread safe,
> > >  we
> > >  can add a public final static rowmapper instance and instead of
> > >  instantiating the rowmapper over and over again, use that single
> > >  instance.
> > +1 on this, and I'm already giving comments to people on this issue
> > (to
> > make a single static instance of a mapper)
> 
> +1 this sounds like the right thing to do anyway.
+1
I've also begun doing this in my newer patches.

> 
> > 
> > > 
> > > Please share your thoughts.
> > > 
> > > Thank you,
> > > Laszlo
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From sanjal at redhat.com  Thu Mar  1 10:54:04 2012
From: sanjal at redhat.com (Shireesh Anjal)
Date: Thu, 01 Mar 2012 16:24:04 +0530
Subject: [Engine-devel] Introducing virt / gluster flags at cluster level
Message-ID: <4F4F554C.1000002@redhat.com>

Hi,

In order to identify whether a cluster exposes Gluster / Virtualization 
capabilities, we plan to introduce two boolean columns - virt_service 
and gluster_service in the vds_groups table. As per immediate plans, it 
is intended to support only one service per cluster, meaning only one of 
these two values can be true.

We plan to make following changes as part of the patch:

1) Introduce an upgrade script for adding following columns to the table 
"vds_groups"
     - virt_service - boolean - NOT_NULL - default value true
     - gluster_service - boolean - NOT_NULL - default value false

=> What is the naming convention for naming the upgrade script? Is it 
<major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql 
? By that logic, the name of our script will be something like 
03_01_0560_add_service_columns_to_vds_groups.sql

2) Modify vds_groups_sp.sql to introduce these arguments / variables in 
save and update methods

3) Modify the DAO interface and implementation to introduce these 
arguments / variables in the save/update methods and VdsGroupRawMapper.

4) Modify the DAO JUnit test class to take care of these new fields, if 
required.

5) Modify class VDSGroup to introduce the two new boolean variables 
virtService and glusterService and modify the methods equals and 
hashCode to use these.

=> One question here. Most of the attributes of class VDSGroup have 
annotations like @XmlElement and @Column. I think these are related to 
jaxb and JPA. Are these annotations really required? If yes, how are 
they useful?

6) REST API : Default populate these variables (virtService = true, 
glusterService = false) before invoking the BLL command 
(AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the 
existing API won't break. No change in api.xsd for now.

7) webadmin create cluster code: Default populate the new variables, 
same as above. No change in UI screen for now.

=> Alternatively, the variable declaration on VDSGroup itself can 
initialize these variables with default values, so that changes to UI / 
REST API code (points 6 and 7) may not be required immediately. What do 
you suggest?

Inputs / comments / suggestions welcome.

-- 
Thanks,
Shireesh



From yzaslavs at redhat.com  Thu Mar  1 15:18:03 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Thu, 01 Mar 2012 17:18:03 +0200
Subject: [Engine-devel] Use java.util.Collection where possible?
Message-ID: <4F4F932B.9090402@redhat.com>

Hi,
I see that in some places in engine-core we use Java.Util.List, or even
Java.Util.ArrayList as types of method arguments, while in the method
code we do nothing besides iterating over the collection.
I then found all kinds of usages like this:

x.foo(new ArrayList<MyType>(myMap.values()));

As you can see need to instantiate a new ArrayList in order to use the
values of the map in method foo.
Do you see any reason why not change the argument type (at method
signature) to Collection in such places, where possible?

Yair



From iheim at redhat.com  Thu Mar  1 15:45:33 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 01 Mar 2012 17:45:33 +0200
Subject: [Engine-devel] Introducing virt / gluster flags at cluster level
In-Reply-To: <4F4F554C.1000002@redhat.com>
References: <4F4F554C.1000002@redhat.com>
Message-ID: <4F4F999D.4090107@redhat.com>

On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
> Hi,
>
> In order to identify whether a cluster exposes Gluster / Virtualization
> capabilities, we plan to introduce two boolean columns - virt_service
> and gluster_service in the vds_groups table. As per immediate plans, it
> is intended to support only one service per cluster, meaning only one of
> these two values can be true.

Can we allow both to be true for folks to play with this mode and see if 
there are issues worth making it exclusive only if there are too many 
issues yet to be resolved making this a pit hole?




From eedri at redhat.com  Sun Mar  4 06:41:35 2012
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 04 Mar 2012 01:41:35 -0500 (EST)
Subject: [Engine-devel] [ovirt Jenkins] new HIGH priority bugs introduced
In-Reply-To: <c9f9ae5d-b978-42e2-bec1-d4f43a3f099b@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <04d7733a-e2d8-4579-a24b-ef919231b1a1@zmail17.collab.prod.int.phx2.redhat.com>

FYI,

one of these commits inserted 3 new HIGH Priority bugs:

core : Fixing import of vm with snapshots (detail / gitweb)
restapi: rename case-sensitive matrix param (detail / gitweb)
restapi: Add JSON support (detail / gitweb)

pleae check here for more details: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/278/

Eyal Edri
oVirt Infrastructure


From ykaul at redhat.com  Sun Mar  4 06:47:29 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Sun, 04 Mar 2012 01:47:29 -0500 (EST)
Subject: [Engine-devel] [ovirt Jenkins] new HIGH priority bugs introduced
Message-ID: <1pf1l7ggeec4gmyq7usmq6x4.1330843643580@email.android.com>

If Jenkins is bored,  it could be cool if it could perform 'git bisect' on such failures.
Y. 

Eyal Edri <eedri at redhat.com> wrote:

FYI,

one of these commits inserted 3 new HIGH Priority bugs:

core : Fixing import of vm with snapshots (detail / gitweb)
restapi: rename case-sensitive matrix param (detail / gitweb)
restapi: Add JSON support (detail / gitweb)

pleae check here for more details: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/278/

Eyal Edri
oVirt Infrastructure
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From eedri at redhat.com  Sun Mar  4 08:09:26 2012
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 04 Mar 2012 03:09:26 -0500 (EST)
Subject: [Engine-devel] [ovirt Jenkins] new HIGH priority bugs introduced
In-Reply-To: <1pf1l7ggeec4gmyq7usmq6x4.1330843643580@email.android.com>
Message-ID: <fbfc63fb-c3a9-49c1-8c5a-95ef1e321a80@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Eyal Edri" <eedri at redhat.com>, engine-devel at ovirt.org
> Sent: Sunday, March 4, 2012 8:47:29 AM
> Subject: Re: [Engine-devel] [ovirt Jenkins] new HIGH priority bugs introduced
> 
> If Jenkins is bored,  it could be cool if it could perform 'git
> bisect' on such failures.
> Y.

Jenkins is far from bored nowadays :)
but it sounds like a good RFE for the 'jenkins findbugs plugin'. (https://issues.jenkins-ci.org/secure/Dashboard.jspa)

Eyal.


> 
> Eyal Edri <eedri at redhat.com> wrote:
> 
> FYI,
> 
> one of these commits inserted 3 new HIGH Priority bugs:
> 
> core : Fixing import of vm with snapshots (detail / gitweb)
> restapi: rename case-sensitive matrix param (detail / gitweb)
> restapi: Add JSON support (detail / gitweb)
> 
> pleae check here for more details:
> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/278/
> 
> Eyal Edri
> oVirt Infrastructure
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From masayag at redhat.com  Sun Mar  4 10:20:43 2012
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 04 Mar 2012 12:20:43 +0200
Subject: [Engine-devel] Introducing virt / gluster flags at cluster level
In-Reply-To: <4F4F554C.1000002@redhat.com>
References: <4F4F554C.1000002@redhat.com>
Message-ID: <4F5341FB.4050001@redhat.com>

On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
> Hi,
> 
> In order to identify whether a cluster exposes Gluster / Virtualization
> capabilities, we plan to introduce two boolean columns - virt_service
> and gluster_service in the vds_groups table. As per immediate plans, it
> is intended to support only one service per cluster, meaning only one of
> these two values can be true.

Couldn't there be additional future services in the future ? In that
case perhaps worth considering enum for services, to be stored in a
single service column, its values are: virt, gluster,...) instead of
extending the vds_group table consistently when introducing new services
(under the assumption no mix of services is allowed).

> 
> We plan to make following changes as part of the patch:
> 
> 1) Introduce an upgrade script for adding following columns to the table
> "vds_groups"
>     - virt_service - boolean - NOT_NULL - default value true
>     - gluster_service - boolean - NOT_NULL - default value false
> 
> => What is the naming convention for naming the upgrade script? Is it
> <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql
> ? By that logic, the name of our script will be something like
> 03_01_0560_add_service_columns_to_vds_groups.sql

Correct. Make sure to verify script sequence uniqueness (under
ovirt-engine/backend/manager/dbscripts/upgrade) before pushing, since
there is no enforcement for that.

> 
> 2) Modify vds_groups_sp.sql to introduce these arguments / variables in
> save and update methods
> 
> 3) Modify the DAO interface and implementation to introduce these
> arguments / variables in the save/update methods and VdsGroupRawMapper.
> 
> 4) Modify the DAO JUnit test class to take care of these new fields, if
> required.

As part of DAO unit-test you should add the new columns and possible
data to
ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml

> 
> 5) Modify class VDSGroup to introduce the two new boolean variables
> virtService and glusterService and modify the methods equals and
> hashCode to use these.
> 
> => One question here. Most of the attributes of class VDSGroup have
> annotations like @XmlElement and @Column. I think these are related to
> jaxb and JPA. Are these annotations really required? If yes, how are
> they useful?
> 

@XmlElement annotations could be deleted from that file as a prior patch
to the patch-set.

JPA annotations could be ignored as not fully supported nor maintained.

> 6) REST API : Default populate these variables (virtService = true,
> glusterService = false) before invoking the BLL command
> (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the
> existing API won't break. No change in api.xsd for now.
> 
> 7) webadmin create cluster code: Default populate the new variables,
> same as above. No change in UI screen for now.
> 
> => Alternatively, the variable declaration on VDSGroup itself can
> initialize these variables with default values, so that changes to UI /
> REST API code (points 6 and 7) may not be required immediately. What do
> you suggest?
> 
> Inputs / comments / suggestions welcome.
> 



From emesika at redhat.com  Sun Mar  4 11:53:34 2012
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 04 Mar 2012 06:53:34 -0500 (EST)
Subject: [Engine-devel] Introducing virt / gluster flags at cluster level
In-Reply-To: <4F5341FB.4050001@redhat.com>
Message-ID: <0c0fdcba-b7b7-48d0-853a-0c0a926888ae@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Sunday, March 4, 2012 12:20:43 PM
> Subject: Re: [Engine-devel] Introducing virt / gluster flags at cluster level
> 
> On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
> > Hi,
> > 
> > In order to identify whether a cluster exposes Gluster /
> > Virtualization
> > capabilities, we plan to introduce two boolean columns -
> > virt_service
> > and gluster_service in the vds_groups table. As per immediate
> > plans, it
> > is intended to support only one service per cluster, meaning only
> > one of
> > these two values can be true.
> 
> Couldn't there be additional future services in the future ? In that
> case perhaps worth considering enum for services, to be stored in a
> single service column, its values are: virt, gluster,...) instead of
> extending the vds_group table consistently when introducing new
> services
> (under the assumption no mix of services is allowed).
> 
> > 
> > We plan to make following changes as part of the patch:
> > 
> > 1) Introduce an upgrade script for adding following columns to the
> > table
> > "vds_groups"
> >     - virt_service - boolean - NOT_NULL - default value true
> >     - gluster_service - boolean - NOT_NULL - default value false
> > 
> > => What is the naming convention for naming the upgrade script? Is
> > it
> > <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql
> > ? By that logic, the name of our script will be something like
> > 03_01_0560_add_service_columns_to_vds_groups.sql
> 
> Correct. Make sure to verify script sequence uniqueness (under
> ovirt-engine/backend/manager/dbscripts/upgrade) before pushing, since
> there is no enforcement for that.
> 
> > 
> > 2) Modify vds_groups_sp.sql to introduce these arguments /

Keep in mind that all sp parameters should start with "v_"

> > variables in
> > save and update methods

Aren't those columns need to be added to relevant views in create_views.sql ???

> > 
> > 3) Modify the DAO interface and implementation to introduce these
> > arguments / variables in the save/update methods and
> > VdsGroupRawMapper.
> > 
> > 4) Modify the DAO JUnit test class to take care of these new
> > fields, if
> > required.
> 
> As part of DAO unit-test you should add the new columns and possible
> data to
> ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
> 
> > 
> > 5) Modify class VDSGroup to introduce the two new boolean variables
> > virtService and glusterService and modify the methods equals and
> > hashCode to use these.
> > 
> > => One question here. Most of the attributes of class VDSGroup have
> > annotations like @XmlElement and @Column. I think these are related
> > to
> > jaxb and JPA. Are these annotations really required? If yes, how
> > are
> > they useful?
> > 
> 
> @XmlElement annotations could be deleted from that file as a prior
> patch
> to the patch-set.
> 
> JPA annotations could be ignored as not fully supported nor
> maintained.
> 
> > 6) REST API : Default populate these variables (virtService = true,
> > glusterService = false) before invoking the BLL command
> > (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that
> > the
> > existing API won't break. No change in api.xsd for now.
> > 
> > 7) webadmin create cluster code: Default populate the new
> > variables,
> > same as above. No change in UI screen for now.
> > 
> > => Alternatively, the variable declaration on VDSGroup itself can
> > initialize these variables with default values, so that changes to
> > UI /
> > REST API code (points 6 and 7) may not be required immediately.
> > What do
> > you suggest?
> > 
> > Inputs / comments / suggestions welcome.
> > 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Sun Mar  4 12:22:43 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 04 Mar 2012 14:22:43 +0200
Subject: [Engine-devel] Introducing virt / gluster flags at cluster level
In-Reply-To: <4F5341FB.4050001@redhat.com>
References: <4F4F554C.1000002@redhat.com> <4F5341FB.4050001@redhat.com>
Message-ID: <4F535E93.8080600@redhat.com>

On 03/04/2012 12:20 PM, Moti Asayag wrote:
> On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
>> Hi,
>>
>> In order to identify whether a cluster exposes Gluster / Virtualization
>> capabilities, we plan to introduce two boolean columns - virt_service
>> and gluster_service in the vds_groups table. As per immediate plans, it
>> is intended to support only one service per cluster, meaning only one of
>> these two values can be true.
> 
> Couldn't there be additional future services in the future ? In that
> case perhaps worth considering enum for services, to be stored in a
> single service column, its values are: virt, gluster,...) instead of
> extending the vds_group table consistently when introducing new services
> (under the assumption no mix of services is allowed).
+1 on enum idea.
Even if mixture of services is allowed, we can still use this enum.

> 
>>
>> We plan to make following changes as part of the patch:
>>
>> 1) Introduce an upgrade script for adding following columns to the table
>> "vds_groups"
>>     - virt_service - boolean - NOT_NULL - default value true
>>     - gluster_service - boolean - NOT_NULL - default value false
>>
>> => What is the naming convention for naming the upgrade script? Is it
>> <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql
>> ? By that logic, the name of our script will be something like
>> 03_01_0560_add_service_columns_to_vds_groups.sql
> 
> Correct. Make sure to verify script sequence uniqueness (under
> ovirt-engine/backend/manager/dbscripts/upgrade) before pushing, since
> there is no enforcement for that.
> 
>>
>> 2) Modify vds_groups_sp.sql to introduce these arguments / variables in
>> save and update methods
>>
>> 3) Modify the DAO interface and implementation to introduce these
>> arguments / variables in the save/update methods and VdsGroupRawMapper.
>>
>> 4) Modify the DAO JUnit test class to take care of these new fields, if
>> required.
> 
> As part of DAO unit-test you should add the new columns and possible
> data to
> ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
> 
>>
>> 5) Modify class VDSGroup to introduce the two new boolean variables
>> virtService and glusterService and modify the methods equals and
>> hashCode to use these.
>>
>> => One question here. Most of the attributes of class VDSGroup have
>> annotations like @XmlElement and @Column. I think these are related to
>> jaxb and JPA. Are these annotations really required? If yes, how are
>> they useful?
>>
> 
> @XmlElement annotations could be deleted from that file as a prior patch
> to the patch-set.
> 
> JPA annotations could be ignored as not fully supported nor maintained.
> 
>> 6) REST API : Default populate these variables (virtService = true,
>> glusterService = false) before invoking the BLL command
>> (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the
>> existing API won't break. No change in api.xsd for now.
>>
>> 7) webadmin create cluster code: Default populate the new variables,
>> same as above. No change in UI screen for now.
>>
>> => Alternatively, the variable declaration on VDSGroup itself can
>> initialize these variables with default values, so that changes to UI /
>> REST API code (points 6 and 7) may not be required immediately. What do
>> you suggest?
>>
>> Inputs / comments / suggestions welcome.
>>
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From rgolan at redhat.com  Sun Mar  4 12:25:14 2012
From: rgolan at redhat.com (Roy Golan)
Date: Sun, 04 Mar 2012 07:25:14 -0500 (EST)
Subject: [Engine-devel] Introducing virt / gluster flags at cluster level
In-Reply-To: <4F5341FB.4050001@redhat.com>
Message-ID: <03a28e79-67db-40a5-b05b-1bf30bdb5bf7@zmail01.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Sunday, March 4, 2012 12:20:43 PM
> Subject: Re: [Engine-devel] Introducing virt / gluster flags at cluster level
> 
> On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
> > Hi,
> > 
> > In order to identify whether a cluster exposes Gluster /
> > Virtualization
> > capabilities, we plan to introduce two boolean columns -
> > virt_service
> > and gluster_service in the vds_groups table. As per immediate
> > plans, it
> > is intended to support only one service per cluster, meaning only
> > one of
> > these two values can be true.
> 
> Couldn't there be additional future services in the future ? In that
> case perhaps worth considering enum for services, to be stored in a
> single service column, its values are: virt, gluster,...) instead of
> extending the vds_group table consistently when introducing new
> services
> (under the assumption no mix of services is allowed).

+1 for an Enum insteand of boolean columns. we have too much of that already and eventually we see long records and
 routine refactoring to our DAL. 
Also to make mixed configuration we can embrace bit fields which interacts very nice with Enums e.g a 5 value of  is a cluster with
VIRT(1) and FUTURE(4) capabilities

> 
> > 
> > We plan to make following changes as part of the patch:
> > 
> > 1) Introduce an upgrade script for adding following columns to the
> > table
> > "vds_groups"
> >     - virt_service - boolean - NOT_NULL - default value true
> >     - gluster_service - boolean - NOT_NULL - default value false
> > 
> > => What is the naming convention for naming the upgrade script? Is
> > it
> > <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql
> > ? By that logic, the name of our script will be something like
> > 03_01_0560_add_service_columns_to_vds_groups.sql
> 
> Correct. Make sure to verify script sequence uniqueness (under
> ovirt-engine/backend/manager/dbscripts/upgrade) before pushing, since
> there is no enforcement for that.
> 
> > 
> > 2) Modify vds_groups_sp.sql to introduce these arguments /
> > variables in
> > save and update methods
> > 
> > 3) Modify the DAO interface and implementation to introduce these
> > arguments / variables in the save/update methods and
> > VdsGroupRawMapper.
> > 
> > 4) Modify the DAO JUnit test class to take care of these new
> > fields, if
> > required.
> 
> As part of DAO unit-test you should add the new columns and possible
> data to
> ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
> 
> > 
> > 5) Modify class VDSGroup to introduce the two new boolean variables
> > virtService and glusterService and modify the methods equals and
> > hashCode to use these.
> > 
> > => One question here. Most of the attributes of class VDSGroup have
> > annotations like @XmlElement and @Column. I think these are related
> > to
> > jaxb and JPA. Are these annotations really required? If yes, how
> > are
> > they useful?
> > 
> 
> @XmlElement annotations could be deleted from that file as a prior
> patch
> to the patch-set.
> 
> JPA annotations could be ignored as not fully supported nor
> maintained.
> 
> > 6) REST API : Default populate these variables (virtService = true,
> > glusterService = false) before invoking the BLL command
> > (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that
> > the
> > existing API won't break. No change in api.xsd for now.
> > 
> > 7) webadmin create cluster code: Default populate the new
> > variables,
> > same as above. No change in UI screen for now.
> > 
> > => Alternatively, the variable declaration on VDSGroup itself can
> > initialize these variables with default values, so that changes to
> > UI /
> > REST API code (points 6 and 7) may not be required immediately.
> > What do
> > you suggest?
> > 
> > Inputs / comments / suggestions welcome.
> > 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From abaron at redhat.com  Sun Mar  4 13:22:16 2012
From: abaron at redhat.com (Ayal Baron)
Date: Sun, 04 Mar 2012 08:22:16 -0500 (EST)
Subject: [Engine-devel] Introducing virt / gluster flags at cluster level
In-Reply-To: <03a28e79-67db-40a5-b05b-1bf30bdb5bf7@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <15be9286-df8e-4687-a4d4-9bab9eab056e@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Moti Asayag" <masayag at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Sunday, March 4, 2012 12:20:43 PM
> > Subject: Re: [Engine-devel] Introducing virt / gluster flags at
> > cluster level
> > 
> > On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
> > > Hi,
> > > 
> > > In order to identify whether a cluster exposes Gluster /
> > > Virtualization
> > > capabilities, we plan to introduce two boolean columns -
> > > virt_service
> > > and gluster_service in the vds_groups table. As per immediate
> > > plans, it
> > > is intended to support only one service per cluster, meaning only
> > > one of
> > > these two values can be true.
> > 
> > Couldn't there be additional future services in the future ? In
> > that
> > case perhaps worth considering enum for services, to be stored in a
> > single service column, its values are: virt, gluster,...) instead
> > of
> > extending the vds_group table consistently when introducing new
> > services
> > (under the assumption no mix of services is allowed).
> 
> +1 for an Enum insteand of boolean columns. we have too much of that
> already and eventually we see long records and
>  routine refactoring to our DAL.
> Also to make mixed configuration we can embrace bit fields which
> interacts very nice with Enums e.g a 5 value of  is a cluster with
> VIRT(1) and FUTURE(4) capabilities

I agree about the columns being inflexible but personally I don't like enums.  What if we need to support finer grained services? e.g. different topologies (active/passive, active/active etc) or other types of intricate relationships?
Not to mention that looking at the raw data you don't undetstand what it means without holding a dictionary.  And it's annoying to support BC of the numbers once things change.


> 
> > 
> > > 
> > > We plan to make following changes as part of the patch:
> > > 
> > > 1) Introduce an upgrade script for adding following columns to
> > > the
> > > table
> > > "vds_groups"
> > >     - virt_service - boolean - NOT_NULL - default value true
> > >     - gluster_service - boolean - NOT_NULL - default value false
> > > 
> > > => What is the naming convention for naming the upgrade script?
> > > Is
> > > it
> > > <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql
> > > ? By that logic, the name of our script will be something like
> > > 03_01_0560_add_service_columns_to_vds_groups.sql
> > 
> > Correct. Make sure to verify script sequence uniqueness (under
> > ovirt-engine/backend/manager/dbscripts/upgrade) before pushing,
> > since
> > there is no enforcement for that.
> > 
> > > 
> > > 2) Modify vds_groups_sp.sql to introduce these arguments /
> > > variables in
> > > save and update methods
> > > 
> > > 3) Modify the DAO interface and implementation to introduce these
> > > arguments / variables in the save/update methods and
> > > VdsGroupRawMapper.
> > > 
> > > 4) Modify the DAO JUnit test class to take care of these new
> > > fields, if
> > > required.
> > 
> > As part of DAO unit-test you should add the new columns and
> > possible
> > data to
> > ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
> > 
> > > 
> > > 5) Modify class VDSGroup to introduce the two new boolean
> > > variables
> > > virtService and glusterService and modify the methods equals and
> > > hashCode to use these.
> > > 
> > > => One question here. Most of the attributes of class VDSGroup
> > > have
> > > annotations like @XmlElement and @Column. I think these are
> > > related
> > > to
> > > jaxb and JPA. Are these annotations really required? If yes, how
> > > are
> > > they useful?
> > > 
> > 
> > @XmlElement annotations could be deleted from that file as a prior
> > patch
> > to the patch-set.
> > 
> > JPA annotations could be ignored as not fully supported nor
> > maintained.
> > 
> > > 6) REST API : Default populate these variables (virtService =
> > > true,
> > > glusterService = false) before invoking the BLL command
> > > (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure
> > > that
> > > the
> > > existing API won't break. No change in api.xsd for now.
> > > 
> > > 7) webadmin create cluster code: Default populate the new
> > > variables,
> > > same as above. No change in UI screen for now.
> > > 
> > > => Alternatively, the variable declaration on VDSGroup itself can
> > > initialize these variables with default values, so that changes
> > > to
> > > UI /
> > > REST API code (points 6 and 7) may not be required immediately.
> > > What do
> > > you suggest?
> > > 
> > > Inputs / comments / suggestions welcome.
> > > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From amureini at redhat.com  Sun Mar  4 16:57:24 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Sun, 04 Mar 2012 11:57:24 -0500 (EST)
Subject: [Engine-devel] Use java.util.Collection where possible?
In-Reply-To: <4F4F932B.9090402@redhat.com>
Message-ID: <26b6e4a2-6f66-4c3c-b95a-76c50ec9687a@zmail17.collab.prod.int.phx2.redhat.com>

My two cents:

There are two meanings of subtyping Collection (or any other interface, for that matter) - additional logic and specific implementation.
I think wherever possible, we should use the interface that infers as much logic as possible (e.g., java.util.List for ordering, java.util.Set for uniquness, java.util.SortedSet for natural ordering, etc.), without inferring any specific implementation (e.g., ArrayList, HashSet, etc.).

The flipside of this notion is that it's a mistake to use an overly specific class/interface - when your parameter type is ArrayList, you implicitly tell the user the *order* of his objects matter, and that it matters to your internal algorithm to be able to do get(i) as an O(1) operation.

Bottom line,  now that I'm done with CS 101:
+1, but be careful not use interfaces that are too low.
Most methods that now receive an ArrayList will still compile if you change the parameter type to Collection, but make sure that you don't implicitly assume some ordering, e.g.

-Allon

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, March 1, 2012 5:18:03 PM
> Subject: [Engine-devel] Use java.util.Collection where possible?
> 
> Hi,
> I see that in some places in engine-core we use Java.Util.List, or
> even
> Java.Util.ArrayList as types of method arguments, while in the method
> code we do nothing besides iterating over the collection.
> I then found all kinds of usages like this:
> 
> x.foo(new ArrayList<MyType>(myMap.values()));
> 
> As you can see need to instantiate a new ArrayList in order to use
> the
> values of the map in method foo.
> Do you see any reason why not change the argument type (at method
> signature) to Collection in such places, where possible?
> 
> Yair
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Sun Mar  4 18:08:52 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 04 Mar 2012 20:08:52 +0200
Subject: [Engine-devel] Introducing virt / gluster flags at cluster level
In-Reply-To: <15be9286-df8e-4687-a4d4-9bab9eab056e@zmail13.collab.prod.int.phx2.redhat.com>
References: <15be9286-df8e-4687-a4d4-9bab9eab056e@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4F53AFB4.30505@redhat.com>

On 03/04/2012 03:22 PM, Ayal Baron wrote:
>
>
> ----- Original Message -----
>>
>>
>> ----- Original Message -----
>>> From: "Moti Asayag"<masayag at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Sent: Sunday, March 4, 2012 12:20:43 PM
>>> Subject: Re: [Engine-devel] Introducing virt / gluster flags at
>>> cluster level
>>>
>>> On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
>>>> Hi,
>>>>
>>>> In order to identify whether a cluster exposes Gluster /
>>>> Virtualization
>>>> capabilities, we plan to introduce two boolean columns -
>>>> virt_service
>>>> and gluster_service in the vds_groups table. As per immediate
>>>> plans, it
>>>> is intended to support only one service per cluster, meaning only
>>>> one of
>>>> these two values can be true.
>>>
>>> Couldn't there be additional future services in the future ? In
>>> that
>>> case perhaps worth considering enum for services, to be stored in a
>>> single service column, its values are: virt, gluster,...) instead
>>> of
>>> extending the vds_group table consistently when introducing new
>>> services
>>> (under the assumption no mix of services is allowed).
>>
>> +1 for an Enum insteand of boolean columns. we have too much of that
>> already and eventually we see long records and
>>   routine refactoring to our DAL.
>> Also to make mixed configuration we can embrace bit fields which
>> interacts very nice with Enums e.g a 5 value of  is a cluster with
>> VIRT(1) and FUTURE(4) capabilities
>
> I agree about the columns being inflexible but personally I don't like enums.  What if we need to support finer grained services? e.g. different topologies (active/passive, active/active etc) or other types of intricate relationships?
> Not to mention that looking at the raw data you don't undetstand what it means without holding a dictionary.  And it's annoying to support BC of the numbers once things change.

enums are an issue, since we want to share them.
i agree services table seems the right approach, but actually, booleans 
are used here exactly because it seems services is the right long term 
approach, but we there is a lot of ground to cover before we know how 
they would look like.
so boolean flags for the first few services, learning from these, 
designing the bigger service models, and upgrading to it from the 
cluster-with-flags seems (to me) the right path to take.

>
>
>>
>>>
>>>>
>>>> We plan to make following changes as part of the patch:
>>>>
>>>> 1) Introduce an upgrade script for adding following columns to
>>>> the
>>>> table
>>>> "vds_groups"
>>>>      - virt_service - boolean - NOT_NULL - default value true
>>>>      - gluster_service - boolean - NOT_NULL - default value false
>>>>
>>>> =>  What is the naming convention for naming the upgrade script?
>>>> Is
>>>> it
>>>> <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql
>>>> ? By that logic, the name of our script will be something like
>>>> 03_01_0560_add_service_columns_to_vds_groups.sql
>>>
>>> Correct. Make sure to verify script sequence uniqueness (under
>>> ovirt-engine/backend/manager/dbscripts/upgrade) before pushing,
>>> since
>>> there is no enforcement for that.
>>>
>>>>
>>>> 2) Modify vds_groups_sp.sql to introduce these arguments /
>>>> variables in
>>>> save and update methods
>>>>
>>>> 3) Modify the DAO interface and implementation to introduce these
>>>> arguments / variables in the save/update methods and
>>>> VdsGroupRawMapper.
>>>>
>>>> 4) Modify the DAO JUnit test class to take care of these new
>>>> fields, if
>>>> required.
>>>
>>> As part of DAO unit-test you should add the new columns and
>>> possible
>>> data to
>>> ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
>>>
>>>>
>>>> 5) Modify class VDSGroup to introduce the two new boolean
>>>> variables
>>>> virtService and glusterService and modify the methods equals and
>>>> hashCode to use these.
>>>>
>>>> =>  One question here. Most of the attributes of class VDSGroup
>>>> have
>>>> annotations like @XmlElement and @Column. I think these are
>>>> related
>>>> to
>>>> jaxb and JPA. Are these annotations really required? If yes, how
>>>> are
>>>> they useful?
>>>>
>>>
>>> @XmlElement annotations could be deleted from that file as a prior
>>> patch
>>> to the patch-set.
>>>
>>> JPA annotations could be ignored as not fully supported nor
>>> maintained.
>>>
>>>> 6) REST API : Default populate these variables (virtService =
>>>> true,
>>>> glusterService = false) before invoking the BLL command
>>>> (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure
>>>> that
>>>> the
>>>> existing API won't break. No change in api.xsd for now.
>>>>
>>>> 7) webadmin create cluster code: Default populate the new
>>>> variables,
>>>> same as above. No change in UI screen for now.
>>>>
>>>> =>  Alternatively, the variable declaration on VDSGroup itself can
>>>> initialize these variables with default values, so that changes
>>>> to
>>>> UI /
>>>> REST API code (points 6 and 7) may not be required immediately.
>>>> What do
>>>> you suggest?
>>>>
>>>> Inputs / comments / suggestions welcome.
>>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From ofrenkel at redhat.com  Sun Mar  4 19:37:42 2012
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Sun, 04 Mar 2012 14:37:42 -0500 (EST)
Subject: [Engine-devel] Introducing virt / gluster flags at cluster level
In-Reply-To: <4F53AFB4.30505@redhat.com>
Message-ID: <9247170a-dd57-4cfd-92b8-81712aa8ede5@ofrenkel.csb>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Ayal Baron" <abaron at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Sunday, March 4, 2012 8:08:52 PM
> Subject: Re: [Engine-devel] Introducing virt / gluster flags at cluster level
> 
> On 03/04/2012 03:22 PM, Ayal Baron wrote:
> >
> >
> > ----- Original Message -----
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Moti Asayag"<masayag at redhat.com>
> >>> To: engine-devel at ovirt.org
> >>> Sent: Sunday, March 4, 2012 12:20:43 PM
> >>> Subject: Re: [Engine-devel] Introducing virt / gluster flags at
> >>> cluster level
> >>>
> >>> On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
> >>>> Hi,
> >>>>
> >>>> In order to identify whether a cluster exposes Gluster /
> >>>> Virtualization
> >>>> capabilities, we plan to introduce two boolean columns -
> >>>> virt_service
> >>>> and gluster_service in the vds_groups table. As per immediate
> >>>> plans, it
> >>>> is intended to support only one service per cluster, meaning
> >>>> only
> >>>> one of
> >>>> these two values can be true.
> >>>
> >>> Couldn't there be additional future services in the future ? In
> >>> that
> >>> case perhaps worth considering enum for services, to be stored in
> >>> a
> >>> single service column, its values are: virt, gluster,...) instead
> >>> of
> >>> extending the vds_group table consistently when introducing new
> >>> services
> >>> (under the assumption no mix of services is allowed).
> >>
> >> +1 for an Enum insteand of boolean columns. we have too much of
> >> that
> >> already and eventually we see long records and
> >>   routine refactoring to our DAL.
> >> Also to make mixed configuration we can embrace bit fields which
> >> interacts very nice with Enums e.g a 5 value of  is a cluster with
> >> VIRT(1) and FUTURE(4) capabilities
> >
> > I agree about the columns being inflexible but personally I don't
> > like enums.  What if we need to support finer grained services?
> > e.g. different topologies (active/passive, active/active etc) or
> > other types of intricate relationships?
> > Not to mention that looking at the raw data you don't undetstand
> > what it means without holding a dictionary.  And it's annoying to
> > support BC of the numbers once things change.
> 
> enums are an issue, since we want to share them.
> i agree services table seems the right approach, but actually,
> booleans
> are used here exactly because it seems services is the right long
> term
> approach, but we there is a lot of ground to cover before we know how
> they would look like.
> so boolean flags for the first few services, learning from these,
> designing the bigger service models, and upgrading to it from the
> cluster-with-flags seems (to me) the right path to take.
>

+1
 
> >
> >
> >>
> >>>
> >>>>
> >>>> We plan to make following changes as part of the patch:
> >>>>
> >>>> 1) Introduce an upgrade script for adding following columns to
> >>>> the
> >>>> table
> >>>> "vds_groups"
> >>>>      - virt_service - boolean - NOT_NULL - default value true
> >>>>      - gluster_service - boolean - NOT_NULL - default value
> >>>>      false
> >>>>
> >>>> =>  What is the naming convention for naming the upgrade script?
> >>>> Is
> >>>> it
> >>>> <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql
> >>>> ? By that logic, the name of our script will be something like
> >>>> 03_01_0560_add_service_columns_to_vds_groups.sql
> >>>
> >>> Correct. Make sure to verify script sequence uniqueness (under
> >>> ovirt-engine/backend/manager/dbscripts/upgrade) before pushing,
> >>> since
> >>> there is no enforcement for that.
> >>>
> >>>>
> >>>> 2) Modify vds_groups_sp.sql to introduce these arguments /
> >>>> variables in
> >>>> save and update methods
> >>>>
> >>>> 3) Modify the DAO interface and implementation to introduce
> >>>> these
> >>>> arguments / variables in the save/update methods and
> >>>> VdsGroupRawMapper.
> >>>>
> >>>> 4) Modify the DAO JUnit test class to take care of these new
> >>>> fields, if
> >>>> required.
> >>>
> >>> As part of DAO unit-test you should add the new columns and
> >>> possible
> >>> data to
> >>> ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
> >>>
> >>>>
> >>>> 5) Modify class VDSGroup to introduce the two new boolean
> >>>> variables
> >>>> virtService and glusterService and modify the methods equals and
> >>>> hashCode to use these.
> >>>>
> >>>> =>  One question here. Most of the attributes of class VDSGroup
> >>>> have
> >>>> annotations like @XmlElement and @Column. I think these are
> >>>> related
> >>>> to
> >>>> jaxb and JPA. Are these annotations really required? If yes, how
> >>>> are
> >>>> they useful?
> >>>>
> >>>
> >>> @XmlElement annotations could be deleted from that file as a
> >>> prior
> >>> patch
> >>> to the patch-set.
> >>>
> >>> JPA annotations could be ignored as not fully supported nor
> >>> maintained.
> >>>
> >>>> 6) REST API : Default populate these variables (virtService =
> >>>> true,
> >>>> glusterService = false) before invoking the BLL command
> >>>> (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure
> >>>> that
> >>>> the
> >>>> existing API won't break. No change in api.xsd for now.
> >>>>
> >>>> 7) webadmin create cluster code: Default populate the new
> >>>> variables,
> >>>> same as above. No change in UI screen for now.
> >>>>
> >>>> =>  Alternatively, the variable declaration on VDSGroup itself
> >>>> can
> >>>> initialize these variables with default values, so that changes
> >>>> to
> >>>> UI /
> >>>> REST API code (points 6 and 7) may not be required immediately.
> >>>> What do
> >>>> you suggest?
> >>>>
> >>>> Inputs / comments / suggestions welcome.
> >>>>
> >>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From abaron at redhat.com  Sun Mar  4 21:42:52 2012
From: abaron at redhat.com (Ayal Baron)
Date: Sun, 04 Mar 2012 16:42:52 -0500 (EST)
Subject: [Engine-devel] Introducing virt / gluster flags at cluster level
In-Reply-To: <4F53AFB4.30505@redhat.com>
Message-ID: <1cb74725-3f7b-493c-adcb-50c6fbc1b59a@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On 03/04/2012 03:22 PM, Ayal Baron wrote:
> >
> >
> > ----- Original Message -----
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Moti Asayag"<masayag at redhat.com>
> >>> To: engine-devel at ovirt.org
> >>> Sent: Sunday, March 4, 2012 12:20:43 PM
> >>> Subject: Re: [Engine-devel] Introducing virt / gluster flags at
> >>> cluster level
> >>>
> >>> On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
> >>>> Hi,
> >>>>
> >>>> In order to identify whether a cluster exposes Gluster /
> >>>> Virtualization
> >>>> capabilities, we plan to introduce two boolean columns -
> >>>> virt_service
> >>>> and gluster_service in the vds_groups table. As per immediate
> >>>> plans, it
> >>>> is intended to support only one service per cluster, meaning
> >>>> only
> >>>> one of
> >>>> these two values can be true.
> >>>
> >>> Couldn't there be additional future services in the future ? In
> >>> that
> >>> case perhaps worth considering enum for services, to be stored in
> >>> a
> >>> single service column, its values are: virt, gluster,...) instead
> >>> of
> >>> extending the vds_group table consistently when introducing new
> >>> services
> >>> (under the assumption no mix of services is allowed).
> >>
> >> +1 for an Enum insteand of boolean columns. we have too much of
> >> that
> >> already and eventually we see long records and
> >>   routine refactoring to our DAL.
> >> Also to make mixed configuration we can embrace bit fields which
> >> interacts very nice with Enums e.g a 5 value of  is a cluster with
> >> VIRT(1) and FUTURE(4) capabilities
> >
> > I agree about the columns being inflexible but personally I don't
> > like enums.  What if we need to support finer grained services?
> > e.g. different topologies (active/passive, active/active etc) or
> > other types of intricate relationships?
> > Not to mention that looking at the raw data you don't undetstand
> > what it means without holding a dictionary.  And it's annoying to
> > support BC of the numbers once things change.
> 
> enums are an issue, since we want to share them.
> i agree services table seems the right approach, but actually,
> booleans
> are used here exactly because it seems services is the right long
> term
> approach, but we there is a lot of ground to cover before we know how
> they would look like.
> so boolean flags for the first few services, learning from these,
> designing the bigger service models, and upgrading to it from the
> cluster-with-flags seems (to me) the right path to take.

db scheme should be something that doesn't change every major, minor and z-stream version.  It means we're doing something wrong.
Having a 'gluster service' boolean column means that by definition we will be changing the db scheme for the next service we want to add or even for the same service but when we'll need some more info.
To start with, we can just rely on the hosts themselves reporting capabilities and we can cache this info if we want it to display quickly next time we load.  This would be similar to supported cpu types.
If we have limitations on combining services then the first service utilized wins.



> 
> >
> >
> >>
> >>>
> >>>>
> >>>> We plan to make following changes as part of the patch:
> >>>>
> >>>> 1) Introduce an upgrade script for adding following columns to
> >>>> the
> >>>> table
> >>>> "vds_groups"
> >>>>      - virt_service - boolean - NOT_NULL - default value true
> >>>>      - gluster_service - boolean - NOT_NULL - default value
> >>>>      false
> >>>>
> >>>> =>  What is the naming convention for naming the upgrade script?
> >>>> Is
> >>>> it
> >>>> <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql
> >>>> ? By that logic, the name of our script will be something like
> >>>> 03_01_0560_add_service_columns_to_vds_groups.sql
> >>>
> >>> Correct. Make sure to verify script sequence uniqueness (under
> >>> ovirt-engine/backend/manager/dbscripts/upgrade) before pushing,
> >>> since
> >>> there is no enforcement for that.
> >>>
> >>>>
> >>>> 2) Modify vds_groups_sp.sql to introduce these arguments /
> >>>> variables in
> >>>> save and update methods
> >>>>
> >>>> 3) Modify the DAO interface and implementation to introduce
> >>>> these
> >>>> arguments / variables in the save/update methods and
> >>>> VdsGroupRawMapper.
> >>>>
> >>>> 4) Modify the DAO JUnit test class to take care of these new
> >>>> fields, if
> >>>> required.
> >>>
> >>> As part of DAO unit-test you should add the new columns and
> >>> possible
> >>> data to
> >>> ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
> >>>
> >>>>
> >>>> 5) Modify class VDSGroup to introduce the two new boolean
> >>>> variables
> >>>> virtService and glusterService and modify the methods equals and
> >>>> hashCode to use these.
> >>>>
> >>>> =>  One question here. Most of the attributes of class VDSGroup
> >>>> have
> >>>> annotations like @XmlElement and @Column. I think these are
> >>>> related
> >>>> to
> >>>> jaxb and JPA. Are these annotations really required? If yes, how
> >>>> are
> >>>> they useful?
> >>>>
> >>>
> >>> @XmlElement annotations could be deleted from that file as a
> >>> prior
> >>> patch
> >>> to the patch-set.
> >>>
> >>> JPA annotations could be ignored as not fully supported nor
> >>> maintained.
> >>>
> >>>> 6) REST API : Default populate these variables (virtService =
> >>>> true,
> >>>> glusterService = false) before invoking the BLL command
> >>>> (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure
> >>>> that
> >>>> the
> >>>> existing API won't break. No change in api.xsd for now.
> >>>>
> >>>> 7) webadmin create cluster code: Default populate the new
> >>>> variables,
> >>>> same as above. No change in UI screen for now.
> >>>>
> >>>> =>  Alternatively, the variable declaration on VDSGroup itself
> >>>> can
> >>>> initialize these variables with default values, so that changes
> >>>> to
> >>>> UI /
> >>>> REST API code (points 6 and 7) may not be required immediately.
> >>>> What do
> >>>> you suggest?
> >>>>
> >>>> Inputs / comments / suggestions welcome.
> >>>>
> >>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 


From iheim at redhat.com  Sun Mar  4 21:49:33 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 04 Mar 2012 23:49:33 +0200
Subject: [Engine-devel] Introducing virt / gluster flags at cluster level
In-Reply-To: <1cb74725-3f7b-493c-adcb-50c6fbc1b59a@zmail13.collab.prod.int.phx2.redhat.com>
References: <1cb74725-3f7b-493c-adcb-50c6fbc1b59a@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4F53E36D.5050506@redhat.com>

On 03/04/2012 11:42 PM, Ayal Baron wrote:
>
>
> ----- Original Message -----
>> On 03/04/2012 03:22 PM, Ayal Baron wrote:
>>>
>>>
>>> ----- Original Message -----
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Moti Asayag"<masayag at redhat.com>
>>>>> To: engine-devel at ovirt.org
>>>>> Sent: Sunday, March 4, 2012 12:20:43 PM
>>>>> Subject: Re: [Engine-devel] Introducing virt / gluster flags at
>>>>> cluster level
>>>>>
>>>>> On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
>>>>>> Hi,
>>>>>>
>>>>>> In order to identify whether a cluster exposes Gluster /
>>>>>> Virtualization
>>>>>> capabilities, we plan to introduce two boolean columns -
>>>>>> virt_service
>>>>>> and gluster_service in the vds_groups table. As per immediate
>>>>>> plans, it
>>>>>> is intended to support only one service per cluster, meaning
>>>>>> only
>>>>>> one of
>>>>>> these two values can be true.
>>>>>
>>>>> Couldn't there be additional future services in the future ? In
>>>>> that
>>>>> case perhaps worth considering enum for services, to be stored in
>>>>> a
>>>>> single service column, its values are: virt, gluster,...) instead
>>>>> of
>>>>> extending the vds_group table consistently when introducing new
>>>>> services
>>>>> (under the assumption no mix of services is allowed).
>>>>
>>>> +1 for an Enum insteand of boolean columns. we have too much of
>>>> that
>>>> already and eventually we see long records and
>>>>    routine refactoring to our DAL.
>>>> Also to make mixed configuration we can embrace bit fields which
>>>> interacts very nice with Enums e.g a 5 value of  is a cluster with
>>>> VIRT(1) and FUTURE(4) capabilities
>>>
>>> I agree about the columns being inflexible but personally I don't
>>> like enums.  What if we need to support finer grained services?
>>> e.g. different topologies (active/passive, active/active etc) or
>>> other types of intricate relationships?
>>> Not to mention that looking at the raw data you don't undetstand
>>> what it means without holding a dictionary.  And it's annoying to
>>> support BC of the numbers once things change.
>>
>> enums are an issue, since we want to share them.
>> i agree services table seems the right approach, but actually,
>> booleans
>> are used here exactly because it seems services is the right long
>> term
>> approach, but we there is a lot of ground to cover before we know how
>> they would look like.
>> so boolean flags for the first few services, learning from these,
>> designing the bigger service models, and upgrading to it from the
>> cluster-with-flags seems (to me) the right path to take.
>
> db scheme should be something that doesn't change every major, minor and z-stream version.  It means we're doing something wrong.
> Having a 'gluster service' boolean column means that by definition we will be changing the db scheme for the next service we want to add or even for the same service but when we'll need some more info.
> To start with, we can just rely on the hosts themselves reporting capabilities and we can cache this info if we want it to display quickly next time we load.  This would be similar to supported cpu types.
> If we have limitations on combining services then the first service utilized wins.

we can't rely on hosts providing this info, as we want to provision 
them, and need to know what to provision them with / monitor for.
i don't see the db scheme not changing between versions (not even sure 
we defined a concept of major or minor versions, we just said we'll have 
a version every 6 months).
as for backports of bug fixes to released versions, that's the only 
thing we managed to avoid in the past (i.e., so far, we didn't change db 
scheme when backporting patches, since dealing with upgrade is a 
nightmare in that case - but that doesn't mean distributions of ovirt 
will not stabilize on a version which is a mix of an upstream version 
and a few more patches/features, which may include a db change, and will 
have to maintain the upgrade from that.


From abaron at redhat.com  Sun Mar  4 22:21:11 2012
From: abaron at redhat.com (Ayal Baron)
Date: Sun, 04 Mar 2012 17:21:11 -0500 (EST)
Subject: [Engine-devel] Introducing virt / gluster flags at cluster level
In-Reply-To: <4F53E36D.5050506@redhat.com>
Message-ID: <3400f4d1-bb3a-424f-a9f3-159dbd50f0af@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On 03/04/2012 11:42 PM, Ayal Baron wrote:
> >
> >
> > ----- Original Message -----
> >> On 03/04/2012 03:22 PM, Ayal Baron wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Moti Asayag"<masayag at redhat.com>
> >>>>> To: engine-devel at ovirt.org
> >>>>> Sent: Sunday, March 4, 2012 12:20:43 PM
> >>>>> Subject: Re: [Engine-devel] Introducing virt / gluster flags at
> >>>>> cluster level
> >>>>>
> >>>>> On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> In order to identify whether a cluster exposes Gluster /
> >>>>>> Virtualization
> >>>>>> capabilities, we plan to introduce two boolean columns -
> >>>>>> virt_service
> >>>>>> and gluster_service in the vds_groups table. As per immediate
> >>>>>> plans, it
> >>>>>> is intended to support only one service per cluster, meaning
> >>>>>> only
> >>>>>> one of
> >>>>>> these two values can be true.
> >>>>>
> >>>>> Couldn't there be additional future services in the future ? In
> >>>>> that
> >>>>> case perhaps worth considering enum for services, to be stored
> >>>>> in
> >>>>> a
> >>>>> single service column, its values are: virt, gluster,...)
> >>>>> instead
> >>>>> of
> >>>>> extending the vds_group table consistently when introducing new
> >>>>> services
> >>>>> (under the assumption no mix of services is allowed).
> >>>>
> >>>> +1 for an Enum insteand of boolean columns. we have too much of
> >>>> that
> >>>> already and eventually we see long records and
> >>>>    routine refactoring to our DAL.
> >>>> Also to make mixed configuration we can embrace bit fields which
> >>>> interacts very nice with Enums e.g a 5 value of  is a cluster
> >>>> with
> >>>> VIRT(1) and FUTURE(4) capabilities
> >>>
> >>> I agree about the columns being inflexible but personally I don't
> >>> like enums.  What if we need to support finer grained services?
> >>> e.g. different topologies (active/passive, active/active etc) or
> >>> other types of intricate relationships?
> >>> Not to mention that looking at the raw data you don't undetstand
> >>> what it means without holding a dictionary.  And it's annoying to
> >>> support BC of the numbers once things change.
> >>
> >> enums are an issue, since we want to share them.
> >> i agree services table seems the right approach, but actually,
> >> booleans
> >> are used here exactly because it seems services is the right long
> >> term
> >> approach, but we there is a lot of ground to cover before we know
> >> how
> >> they would look like.
> >> so boolean flags for the first few services, learning from these,
> >> designing the bigger service models, and upgrading to it from the
> >> cluster-with-flags seems (to me) the right path to take.
> >
> > db scheme should be something that doesn't change every major,
> > minor and z-stream version.  It means we're doing something wrong.
> > Having a 'gluster service' boolean column means that by definition
> > we will be changing the db scheme for the next service we want to
> > add or even for the same service but when we'll need some more
> > info.
> > To start with, we can just rely on the hosts themselves reporting
> > capabilities and we can cache this info if we want it to display
> > quickly next time we load.  This would be similar to supported cpu
> > types.
> > If we have limitations on combining services then the first service
> > utilized wins.
> 
> we can't rely on hosts providing this info, as we want to provision
> them, and need to know what to provision them with / monitor for.
> i don't see the db scheme not changing between versions (not even

I think therein lies the problem.
But at least changes should be incremental and not deprecate things every version...
So as I mentioned on the patch, you could have a table which has 'clusterId, serviceType' and according to the serviceType(s) that this cluster is associated with dynamically provision whatever is required.
By the way, what services would be enabled on the default cluster?
What would ovirt-node register as?


> sure
> we defined a concept of major or minor versions, we just said we'll
> have
> a version every 6 months).
> as for backports of bug fixes to released versions, that's the only
> thing we managed to avoid in the past (i.e., so far, we didn't change
> db
> scheme when backporting patches, since dealing with upgrade is a
> nightmare in that case - but that doesn't mean distributions of ovirt
> will not stabilize on a version which is a mix of an upstream version
> and a few more patches/features, which may include a db change, and
> will
> have to maintain the upgrade from that.
> 


From ashakarc at redhat.com  Mon Mar  5 02:23:45 2012
From: ashakarc at redhat.com (Asaf Shakarchi)
Date: Sun, 04 Mar 2012 21:23:45 -0500 (EST)
Subject: [Engine-devel] UI Related: Removal of SharedGwt module [imprtant
	notes]
In-Reply-To: <d7dd8fec-f2f5-48b6-b36c-22acc4386369@asafnb.int.vertix-tech.com>
Message-ID: <95618e85-9d61-46c2-9361-0e7e55f2c5e5@asafnb.int.vertix-tech.com>

All,
Gerrit ticket: http://gerrit.ovirt.org/#change,2164 was just merged,
This commit removes the SharedGwt module from oVirt maven structure,

This module aggregated backend source code of three modules: Common, Compat and SearchBackend for UI (gwt) modules during compile phase,
This is replaced now by a direct access to the backend modules using sources artifacts,


GWT module descriptor of SharedGwt maven module (named: SharedGwt.gwt.xml) contained a list of java classes that should be visible for the GWT compiler,
Since this module does not exist anymore, this file was split into three files per backend module:

Common.gwt.xml - Contains backend Common code that is visible to GWT compiler.
SearchBackend.gwt.xml - Contains SearchBackend code that is visible to GWT compiler.
Compat.gwt.xml - Contains backend Compat code that is visible to GWT compiler.


To avoid pushing UI related files directly into the backend modules, these files are located in gwt-common module, which contains shared code for UI modules.

In short: any backend source code that should be available during UI compilation which exist in Common|Compat|SearchBackend must be included in the appropriate GWT module descriptor according to its parent module.

Please contact me if this is causing any issue,



Regards,
+972-543094949
Asaf.


From lhornyak at redhat.com  Mon Mar  5 08:42:06 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 05 Mar 2012 03:42:06 -0500 (EST)
Subject: [Engine-devel] [ovirt Jenkins] new HIGH priority bugs introduced
In-Reply-To: <04d7733a-e2d8-4579-a24b-ef919231b1a1@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <c41b4d90-7a8c-4d56-90b2-c16a00609ea4@zmail01.collab.prod.int.phx2.redhat.com>

Hi Eyal,

What are the 3 new bugs?

Thank you,
Laszlo

----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Sunday, March 4, 2012 7:41:35 AM
> Subject: [Engine-devel] [ovirt Jenkins] new HIGH priority bugs introduced
> 
> FYI,
> 
> one of these commits inserted 3 new HIGH Priority bugs:
> 
> core : Fixing import of vm with snapshots (detail / gitweb)
> restapi: rename case-sensitive matrix param (detail / gitweb)
> restapi: Add JSON support (detail / gitweb)
> 
> pleae check here for more details:
> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/278/
> 
> Eyal Edri
> oVirt Infrastructure
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From eedri at redhat.com  Mon Mar  5 08:58:10 2012
From: eedri at redhat.com (Eyal Edri)
Date: Mon, 05 Mar 2012 03:58:10 -0500 (EST)
Subject: [Engine-devel] [ovirt Jenkins] new HIGH priority bugs introduced
In-Reply-To: <c41b4d90-7a8c-4d56-90b2-c16a00609ea4@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <99e86b7d-ab7a-4e39-84c0-0679340a847c@zmail17.collab.prod.int.phx2.redhat.com>

http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/291/findbugsResult/HIGH/?

clicking on each of the links will get to the problematic code.

E.

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Eyal Edri" <eedri at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, March 5, 2012 10:42:06 AM
> Subject: Re: [Engine-devel] [ovirt Jenkins] new HIGH priority bugs introduced
> 
> Hi Eyal,
> 
> What are the 3 new bugs?
> 
> Thank you,
> Laszlo
> 
> ----- Original Message -----
> > From: "Eyal Edri" <eedri at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Sunday, March 4, 2012 7:41:35 AM
> > Subject: [Engine-devel] [ovirt Jenkins] new HIGH priority bugs
> > introduced
> > 
> > FYI,
> > 
> > one of these commits inserted 3 new HIGH Priority bugs:
> > 
> > core : Fixing import of vm with snapshots (detail / gitweb)
> > restapi: rename case-sensitive matrix param (detail / gitweb)
> > restapi: Add JSON support (detail / gitweb)
> > 
> > pleae check here for more details:
> > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/278/
> > 
> > Eyal Edri
> > oVirt Infrastructure
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From masayag at redhat.com  Mon Mar  5 09:01:20 2012
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 05 Mar 2012 11:01:20 +0200
Subject: [Engine-devel] [ovirt Jenkins] new HIGH priority bugs introduced
In-Reply-To: <c41b4d90-7a8c-4d56-90b2-c16a00609ea4@zmail01.collab.prod.int.phx2.redhat.com>
References: <c41b4d90-7a8c-4d56-90b2-c16a00609ea4@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <4F5480E0.1050802@redhat.com>

On 03/05/2012 10:42 AM, Laszlo Hornyak wrote:
> Hi Eyal,
> 
> What are the 3 new bugs?

A patch is awaiting +2 from REST:

http://gerrit.ovirt.org/#change,2547

> 
> Thank you,
> Laszlo
> 
> ----- Original Message -----
>> From: "Eyal Edri" <eedri at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Sunday, March 4, 2012 7:41:35 AM
>> Subject: [Engine-devel] [ovirt Jenkins] new HIGH priority bugs introduced
>>
>> FYI,
>>
>> one of these commits inserted 3 new HIGH Priority bugs:
>>
>> core : Fixing import of vm with snapshots (detail / gitweb)
>> restapi: rename case-sensitive matrix param (detail / gitweb)
>> restapi: Add JSON support (detail / gitweb)
>>
>> pleae check here for more details:
>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/278/
>>
>> Eyal Edri
>> oVirt Infrastructure
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From rgolan at redhat.com  Mon Mar  5 13:13:09 2012
From: rgolan at redhat.com (Roy Golan)
Date: Mon, 05 Mar 2012 08:13:09 -0500 (EST)
Subject: [Engine-devel] network - UI Sync meeting
Message-ID: <3e75833d-f6db-4ab6-be28-e1a577b603a1@zmail01.collab.prod.int.phx2.redhat.com>

The following meeting has been modified:

Subject: network - UI Sync meeting 
Organizer: "Roy Golan" <rgolan at redhat.com> 

Location:  [MODIFIED]
Time: Monday, March 5, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem [MODIFIED]
 
Invitees: mkenneth at redhat.com; sgrinber at redhat.com; lpeer at redhat.com; dfediuck at redhat.com; drankevi at redhat.com; ecohen at redhat.com; iheim at redhat.com; ovedo at redhat.com; acathrow at redhat.com; engine-devel at ovirt.org; kroberts at redhat.com ... 


*~*~*~*~*~*~*~*~*~*


Follow-up meeting on setup networks UI. 

Last meeting AIs:
? "Edit..." button should be placed on the network to cover cases of single interface to multiple network.
? "i" icon on each logical network to have details: vlan, mtu, VmNetworks, mandatoy...
? right-hand breakdown  VM-networks|VLAN/Non-VLAN|optional

issues to follow: 
1. can VDSM attach many non-vlan and many vlan networks to a single nic? (Dan - please reply if its doable) 


Bridge ID: 1814335863 

https://www.intercallonline.com/portlets/scheduling/viewNumbers/listNumbersByCode.do?confCode=1814335863 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120305/54329ef5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 5165 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120305/54329ef5/attachment.ics>

From rgolan at redhat.com  Mon Mar  5 16:47:52 2012
From: rgolan at redhat.com (Roy Golan)
Date: Mon, 05 Mar 2012 11:47:52 -0500 (EST)
Subject: [Engine-devel] setup newtorks UI sync meeting MOM
In-Reply-To: <b3660d8c-1111-4648-a54f-bc7340a79df3@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <25938913-f765-4877-9e53-bbda92c3126e@zmail01.collab.prod.int.phx2.redhat.com>


MTU 
?  provision MTU when network is down
? valid values?  -1, minimum = 68, maximum = configurable
? MTU -1 -> dont send the value to VDSM let the default take place
? mtu checkbox, label : "override MTU" , unchecked, value box always blank when uncheck.
? mtu box checked, show a box for a value 
? support matrix of co-exisiting networks MTU values on single interface - open issue


STP
? remove stp from the dialog

VM network
? checked by default for management network as well

 Setup network 
? On what host status we allow to run setup networks on ? - open issue
? boxes are a bit naked. Add icons for allowed actions on each interface box. 



From lhornyak at redhat.com  Tue Mar  6 09:54:55 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 06 Mar 2012 04:54:55 -0500 (EST)
Subject: [Engine-devel] [backend] some graphs from sonar
In-Reply-To: <c5d7d473-3bf9-4143-8725-6fa1b6f69e1f@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <4f59b416-35bd-44ce-95db-a65b2f3b4570@zmail01.collab.prod.int.phx2.redhat.com>

Hi,

I am running sonar (http://www.sonarsource.org/) on oVirt source code since last October and I would like to share some results with you.

http://twitpic.com/8son6o/full - showing the backend complexity, rules compliance and coverage. While complexity increased about 10%, the code coverage doubled.
http://twitpic.com/8soojz/full - size vs coverage in backend (100% would be green)

Unfortunately this server is on the internal network but it would be great to have a public sonar instance.

Laszlo


From lpeer at redhat.com  Tue Mar  6 16:11:08 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 06 Mar 2012 18:11:08 +0200
Subject: [Engine-devel] setup newtorks UI sync meeting MOM
In-Reply-To: <25938913-f765-4877-9e53-bbda92c3126e@zmail01.collab.prod.int.phx2.redhat.com>
References: <25938913-f765-4877-9e53-bbda92c3126e@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <4F56371C.9050209@redhat.com>

On 05/03/12 18:47, Roy Golan wrote:
> 
> MTU 
> ?  provision MTU when network is down
> ? valid values?  -1, minimum = 68, maximum = configurable

maximum default should be 9000

> ? MTU -1 -> dont send the value to VDSM let the default take place

This should be communicated to VDSM team

> ? mtu checkbox, label : "override MTU" , unchecked, value box always blank when uncheck.
> ? mtu box checked, show a box for a value 
> ? support matrix of co-exisiting networks MTU values on single interface - open issue

> 
> STP
> ? remove stp from the dialog

Just an emphasis - UI action only, we keep the support in the API level.

> 
> VM network
> ? checked by default for management network as well
> 
>  Setup network 
> ? On what host status we allow to run setup networks on ? - open issue

On what host status do we enable add/edit network?

> ? boxes are a bit naked. Add icons for allowed actions on each interface box. 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From lhornyak at redhat.com  Wed Mar  7 10:15:27 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 07 Mar 2012 05:15:27 -0500 (EST)
Subject: [Engine-devel] [backend] logger declarations
In-Reply-To: <a23caaa0-53b6-402f-ad57-1d4eb1af9323@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <9ce26572-ae09-43c0-b822-16fa90922dd0@zmail01.collab.prod.int.phx2.redhat.com>

Hi,

In general loggers are recommended to be private static final, also have the correct class. (e.g. commons logging standards from PMD http://pmd.sourceforge.net/rules/logging-jakarta-commons.html)

In oVirt backend, very often the logger is just package protected, which allows classes in the same package to use it. Actually the classes that really use it are usualy subclasses, but what I believe is misleading in this case is that when reading a log, you will see that e.g. org.foo.Bar logged 'X', and you look into the sourcecode of org.foo.Bar and you do not see any code that would ever log that message, you will have to look for that message in all of it's subclasses and this will make debugging harder especially if the number of subclasses is high.

I am trying to maintain a coding standard here, please feel free to edit:
http://www.ovirt.org/wiki/Backend_Coding_Standards

Thank you,
Laszlo


From sanjal at redhat.com  Fri Mar  9 14:36:39 2012
From: sanjal at redhat.com (Shireesh Anjal)
Date: Fri, 09 Mar 2012 20:06:39 +0530
Subject: [Engine-devel] Wiki page for audit logs and event notifications
Message-ID: <4F5A1577.7030006@redhat.com>

Hi all,

Based on my recent experience with audit logs and event notifications, I 
have created a Wiki page explaining how to introduce the same for a new 
entity in oVirt. It is available at following URL:

http://www.ovirt.org/wiki/Development/Audit_Logs_and_Event_Notifications

Please feel free to contribute to the same in order to correct any 
discrepancies or enhance the information provided.

-- 
Thanks,
Shireesh



From mkolesni at redhat.com  Sun Mar 11 13:51:09 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 11 Mar 2012 09:51:09 -0400 (EDT)
Subject: [Engine-devel] [backend] logger declarations
In-Reply-To: <9ce26572-ae09-43c0-b822-16fa90922dd0@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <858f3b95-130f-4aaf-a5a6-d2fc8fa4adb6@zmail14.collab.prod.int.phx2.redhat.com>

> Hi,
> 
> In general loggers are recommended to be private static final, also
> have the correct class. (e.g. commons logging standards from PMD
> http://pmd.sourceforge.net/rules/logging-jakarta-commons.html)
> 
> In oVirt backend, very often the logger is just package protected,
> which allows classes in the same package to use it. Actually the
> classes that really use it are usualy subclasses, but what I believe
> is misleading in this case is that when reading a log, you will see
> that e.g. org.foo.Bar logged 'X', and you look into the sourcecode
> of org.foo.Bar and you do not see any code that would ever log that
> message, you will have to look for that message in all of it's
> subclasses and this will make debugging harder especially if the
> number of subclasses is high.

You are talking about category, but since our command inherit from each other then I think it's more useful to have the category determined by the actual runtime class - this way you can control the log verbosity of a specific command/flow.

However, I think this is not our biggest problem, but that the logging itself is not very good overall and it is sometimes hard to track down what causes the issues because of that.

> 
> I am trying to maintain a coding standard here, please feel free to
> edit:
> http://www.ovirt.org/wiki/Backend_Coding_Standards
> 
> Thank you,
> Laszlo


From mlipchuk at redhat.com  Mon Mar 12 09:01:30 2012
From: mlipchuk at redhat.com (Maor Lipchuk)
Date: Mon, 12 Mar 2012 11:01:30 +0200
Subject: [Engine-devel] Shared Raw Disk - Design change
Message-ID: <4F5DBB6A.3010201@redhat.com>

Hello all,

The shared raw disk feature description has been changed.
The changes can be found in the following wiki:
links:
	http://www.ovirt.org/wiki/Features/DetailedSharedRawDisk
	http://www.ovirt.org/wiki/Features/SharedRawDisk

Please feel free, to share your comments.

Regards,
Maor


From iheim at redhat.com  Tue Mar 13 14:47:31 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 13 Mar 2012 16:47:31 +0200
Subject: [Engine-devel] Shared Raw Disk - Design change
In-Reply-To: <4F5DBB6A.3010201@redhat.com>
References: <4F5DBB6A.3010201@redhat.com>
Message-ID: <4F5F5E03.3060006@redhat.com>

On 03/12/2012 11:01 AM, Maor Lipchuk wrote:
> Hello all,
>
> The shared raw disk feature description has been changed.
> The changes can be found in the following wiki:
> links:
> 	http://www.ovirt.org/wiki/Features/SharedRawDisk
 > 	http://www.ovirt.org/wiki/Features/DetailedSharedRawDisk

1. affected components - isn't vdsm aware of this as well wrt disk lock 
protection (appears in both urls)

2. Remove Shared Disk
maybe make it clear this is about delete, not detach from this vm?
my view - UI should have a clear warning (with checkbox approval) making 
it clear delete will remove the shared disk from all VMs sharing it.

3. Copy Shared Disk
this is "clone disk"? do we have it for non shared disks?

4. Export/Import
the text is copy/paste from template part - should be fixed to say 
export in several places.

5. move disk
s/inactivatee/inactive/

Thanks,
   Itamar


From mlipchuk at redhat.com  Tue Mar 13 18:36:12 2012
From: mlipchuk at redhat.com (Maor Lipchuk)
Date: Tue, 13 Mar 2012 20:36:12 +0200
Subject: [Engine-devel] Shared Raw Disk - Design change
In-Reply-To: <4F5F5E03.3060006@redhat.com>
References: <4F5DBB6A.3010201@redhat.com> <4F5F5E03.3060006@redhat.com>
Message-ID: <4F5F939C.4060300@redhat.com>

Thanks for the comments,
Please see responds in the message body.

On 03/13/2012 04:47 PM, Itamar Heim wrote:
> On 03/12/2012 11:01 AM, Maor Lipchuk wrote:
>> Hello all,
>>
>> The shared raw disk feature description has been changed.
>> The changes can be found in the following wiki:
>> links:
>>     http://www.ovirt.org/wiki/Features/SharedRawDisk
>>     http://www.ovirt.org/wiki/Features/DetailedSharedRawDisk
> 
> 1. affected components - isn't vdsm aware of this as well wrt disk lock
> protection (appears in both urls)
You right, Backend sends VDSM an indication when ever we create a VM
whether the disk is shared or not.
I Added the OVirt Node, as a related component in the dependencies tab
at the wiki.
> 
> 2. Remove Shared Disk
> maybe make it clear this is about delete, not detach from this vm?
> my view - UI should have a clear warning (with checkbox approval) making
> it clear delete will remove the shared disk from all VMs sharing it.
I tried to stay consistent with the semantic here, by not mentioning
delete and remove in the same sentence.
I changed it to be as follow:

User can remove the shared raw disk entirely from the setup, whether the
disk is inactive in all the VMs which are attached to it, or all the VMs
which the disk is attached to, are in status down (or any combination of
the two).
When disk will be removed a warning message should display the user the
following message :

"Removing the shared disk will remove it from all the VMs which are
associated with it."

> 
> 3. Copy Shared Disk
> this is "clone disk"? do we have it for non shared disks?
I'm not sure I understood completely.
Move disk for shared disk, will need to have the same functionality as
regular disk, the only difference is that fir shared disk I check all
the VMs which the disk is attached to, whether the disk is inactive in
the running VMs or attached to non active VMs.>
> 4. Export/Import
> the text is copy/paste from template part - should be fixed to say
> export in several places.
Fixed, although I found only one mention of template there, hope I
didn't missed something.
> 
> 5. move disk
> s/inactivatee/inactive/
Fixed, thank you.
> 
> Thanks,
>   Itamar



From iheim at redhat.com  Tue Mar 13 20:16:32 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 13 Mar 2012 22:16:32 +0200
Subject: [Engine-devel] Shared Raw Disk - Design change
In-Reply-To: <4F5F939C.4060300@redhat.com>
References: <4F5DBB6A.3010201@redhat.com> <4F5F5E03.3060006@redhat.com>
	<4F5F939C.4060300@redhat.com>
Message-ID: <4F5FAB20.3060206@redhat.com>

On 03/13/2012 08:36 PM, Maor Lipchuk wrote:
...

>> 1. affected components - isn't vdsm aware of this as well wrt disk lock
>> protection (appears in both urls)
> You right, Backend sends VDSM an indication when ever we create a VM
> whether the disk is shared or not.
> I Added the OVirt Node, as a related component in the dependencies tab
> at the wiki.

ovirt node isn't the affected component. vdsm is.
ovirt node has vdsm in it, but so does any host running vdsm (i.e., full 
blown fedora host).

>>
>> 2. Remove Shared Disk
>> maybe make it clear this is about delete, not detach from this vm?
>> my view - UI should have a clear warning (with checkbox approval) making
>> it clear delete will remove the shared disk from all VMs sharing it.
> I tried to stay consistent with the semantic here, by not mentioning
> delete and remove in the same sentence.
> I changed it to be as follow:
>
> User can remove the shared raw disk entirely from the setup, whether the
> disk is inactive in all the VMs which are attached to it, or all the VMs
> which the disk is attached to, are in status down (or any combination of
> the two).
> When disk will be removed a warning message should display the user the
> following message :
>
> "Removing the shared disk will remove it from all the VMs which are
> associated with it."

consult einav on phrasing, or assume it will be looked at later on again 
i guess.

>
>>
>> 3. Copy Shared Disk
>> this is "clone disk"? do we have it for non shared disks?
> I'm not sure I understood completely.
> Move disk for shared disk, will need to have the same functionality as
> regular disk, the only difference is that fir shared disk I check all
> the VMs which the disk is attached to, whether the disk is inactive in
> the running VMs or attached to non active VMs.>

your reply started with "move disk for...". I'm asking on "Copy Shared 
Disk".
do we have a copy disk action?

Thanks,
    Itamar


From masayag at redhat.com  Wed Mar 14 00:20:18 2012
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 14 Mar 2012 02:20:18 +0200
Subject: [Engine-devel] Disk Permissions Feature
Message-ID: <4F5FE442.7070602@redhat.com>

Hi all,

Disk Permissions feature description Wiki page:
http://www.ovirt.org/wiki/Features/DiskPermissions

Please share your comments.

Thanks,
Moti



From lpeer at redhat.com  Wed Mar 14 07:22:35 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 14 Mar 2012 09:22:35 +0200
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <4F5FE442.7070602@redhat.com>
References: <4F5FE442.7070602@redhat.com>
Message-ID: <4F60473B.1010408@redhat.com>

On 14/03/12 02:20, Moti Asayag wrote:
> Hi all,
> 
> Disk Permissions feature description Wiki page:
> http://www.ovirt.org/wiki/Features/DiskPermissions
> 
> Please share your comments.
> 

I changed the wiki to use the terminology we used previously when
discussing permissions.

I also fixed some things, for example AddDiskToVM I changed the need for
permissions on the disk to need permissions on the storage domain.

I am missing details of what actions does the DISK_OPERATOR role
includes, also when a user creates a disk what permissions do we give
him implicitly (DISK_OPERATOR ?)

The upgrade flow is written in the open issues, we need to move it from
the open issues to it's own section and add there that all disk related
operations should be added to the system administrator.

The direct LUN open issues are mostly because the implementation is not
there yet, it is not about the behavior of the permissions AFAIU.

Thanks, Livnat


> Thanks,
> Moti
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From danny.ran at redhat.com  Wed Mar 14 10:58:35 2012
From: danny.ran at redhat.com (Danny Rankevich)
Date: Wed, 14 Mar 2012 06:58:35 -0400 (EDT)
Subject: [Engine-devel] Use java.util.Collection where possible?
In-Reply-To: <26b6e4a2-6f66-4c3c-b95a-76c50ec9687a@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <76fa018e-bc1f-482a-989d-a290c54f8781@zmail16.collab.prod.int.phx2.redhat.com>

BWT I did some checks on the GWT RPC that we use (deRPC) and there shouldn't be any problems using Collection interface (or any interface) in the generic api service.

----- Original Message -----
> From: "Allon Mureinik" <amureini at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, March 4, 2012 6:57:24 PM
> Subject: Re: [Engine-devel] Use java.util.Collection where possible?
> 
> My two cents:
> 
> There are two meanings of subtyping Collection (or any other
> interface, for that matter) - additional logic and specific
> implementation.
> I think wherever possible, we should use the interface that infers as
> much logic as possible (e.g., java.util.List for ordering,
> java.util.Set for uniquness, java.util.SortedSet for natural
> ordering, etc.), without inferring any specific implementation
> (e.g., ArrayList, HashSet, etc.).
> 
> The flipside of this notion is that it's a mistake to use an overly
> specific class/interface - when your parameter type is ArrayList,
> you implicitly tell the user the *order* of his objects matter, and
> that it matters to your internal algorithm to be able to do get(i)
> as an O(1) operation.
> 
> Bottom line,  now that I'm done with CS 101:
> +1, but be careful not use interfaces that are too low.
> Most methods that now receive an ArrayList will still compile if you
> change the parameter type to Collection, but make sure that you
> don't implicitly assume some ordering, e.g.
> 
> -Allon
> 
> ----- Original Message -----
> > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, March 1, 2012 5:18:03 PM
> > Subject: [Engine-devel] Use java.util.Collection where possible?
> > 
> > Hi,
> > I see that in some places in engine-core we use Java.Util.List, or
> > even
> > Java.Util.ArrayList as types of method arguments, while in the
> > method
> > code we do nothing besides iterating over the collection.
> > I then found all kinds of usages like this:
> > 
> > x.foo(new ArrayList<MyType>(myMap.values()));
> > 
> > As you can see need to instantiate a new ArrayList in order to use
> > the
> > values of the map in method foo.
> > Do you see any reason why not change the argument type (at method
> > signature) to Collection in such places, where possible?
> > 
> > Yair
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ashakarc at redhat.com  Wed Mar 14 11:19:18 2012
From: ashakarc at redhat.com (Asaf Shakarchi)
Date: Wed, 14 Mar 2012 07:19:18 -0400 (EDT)
Subject: [Engine-devel] Use java.util.Collection where possible?
In-Reply-To: <76fa018e-bc1f-482a-989d-a290c54f8781@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <2c5e3d14-7679-4ea2-88cc-189a08c53568@asafnb.int.vertix-tech.com>

Danny are you sure?
IIRC GWT RPC Oracle wont be able to pick the right implementatione and will generate code for any possible concrete impl,


Asaf.
----- Original Message -----
> From: "Danny Rankevich" <danny.ran at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, March 14, 2012 12:58:35 PM
> Subject: Re: [Engine-devel] Use java.util.Collection where possible?
> 
> BWT I did some checks on the GWT RPC that we use (deRPC) and there
> shouldn't be any problems using Collection interface (or any
> interface) in the generic api service.
> 
> ----- Original Message -----
> > From: "Allon Mureinik" <amureini at redhat.com>
> > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, March 4, 2012 6:57:24 PM
> > Subject: Re: [Engine-devel] Use java.util.Collection where
> > possible?
> > 
> > My two cents:
> > 
> > There are two meanings of subtyping Collection (or any other
> > interface, for that matter) - additional logic and specific
> > implementation.
> > I think wherever possible, we should use the interface that infers
> > as
> > much logic as possible (e.g., java.util.List for ordering,
> > java.util.Set for uniquness, java.util.SortedSet for natural
> > ordering, etc.), without inferring any specific implementation
> > (e.g., ArrayList, HashSet, etc.).
> > 
> > The flipside of this notion is that it's a mistake to use an overly
> > specific class/interface - when your parameter type is ArrayList,
> > you implicitly tell the user the *order* of his objects matter, and
> > that it matters to your internal algorithm to be able to do get(i)
> > as an O(1) operation.
> > 
> > Bottom line,  now that I'm done with CS 101:
> > +1, but be careful not use interfaces that are too low.
> > Most methods that now receive an ArrayList will still compile if
> > you
> > change the parameter type to Collection, but make sure that you
> > don't implicitly assume some ordering, e.g.
> > 
> > -Allon
> > 
> > ----- Original Message -----
> > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Thursday, March 1, 2012 5:18:03 PM
> > > Subject: [Engine-devel] Use java.util.Collection where possible?
> > > 
> > > Hi,
> > > I see that in some places in engine-core we use Java.Util.List,
> > > or
> > > even
> > > Java.Util.ArrayList as types of method arguments, while in the
> > > method
> > > code we do nothing besides iterating over the collection.
> > > I then found all kinds of usages like this:
> > > 
> > > x.foo(new ArrayList<MyType>(myMap.values()));
> > > 
> > > As you can see need to instantiate a new ArrayList in order to
> > > use
> > > the
> > > values of the map in method foo.
> > > Do you see any reason why not change the argument type (at method
> > > signature) to Collection in such places, where possible?
> > > 
> > > Yair
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lpeer at redhat.com  Wed Mar 14 12:51:17 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 14 Mar 2012 14:51:17 +0200
Subject: [Engine-devel] agenda for todays meeting
Message-ID: <4F609445.6060609@redhat.com>

Hi All,
We don't have an agenda for today - open for suggestions.

If no other requests will be suggested for today's agenda we'll discuss
storage live migration and who ever is interested can join us.

Federico/ayal  can you make the slot today at 1600?

Thanks, Livnat


From mlipchuk at redhat.com  Wed Mar 14 13:16:02 2012
From: mlipchuk at redhat.com (Maor Lipchuk)
Date: Wed, 14 Mar 2012 15:16:02 +0200
Subject: [Engine-devel] Shared Raw Disk - Design change
In-Reply-To: <4F5FAB20.3060206@redhat.com>
References: <4F5DBB6A.3010201@redhat.com> <4F5F5E03.3060006@redhat.com>
	<4F5F939C.4060300@redhat.com> <4F5FAB20.3060206@redhat.com>
Message-ID: <4F609A12.4010406@redhat.com>

On 03/13/2012 10:16 PM, Itamar Heim wrote:
> On 03/13/2012 08:36 PM, Maor Lipchuk wrote:
> ...
> 
>>> 1. affected components - isn't vdsm aware of this as well wrt disk lock
>>> protection (appears in both urls)
>> You right, Backend sends VDSM an indication when ever we create a VM
>> whether the disk is shared or not.
>> I Added the OVirt Node, as a related component in the dependencies tab
>> at the wiki.
> 
> ovirt node isn't the affected component. vdsm is.
> ovirt node has vdsm in it, but so does any host running vdsm (i.e., full
> blown fedora host).
> 
Changed to VDSM
>>>
>>> 2. Remove Shared Disk
>>> maybe make it clear this is about delete, not detach from this vm?
>>> my view - UI should have a clear warning (with checkbox approval) making
>>> it clear delete will remove the shared disk from all VMs sharing it.
>> I tried to stay consistent with the semantic here, by not mentioning
>> delete and remove in the same sentence.
>> I changed it to be as follow:
>>
>> User can remove the shared raw disk entirely from the setup, whether the
>> disk is inactive in all the VMs which are attached to it, or all the VMs
>> which the disk is attached to, are in status down (or any combination of
>> the two).
>> When disk will be removed a warning message should display the user the
>> following message :
>>
>> "Removing the shared disk will remove it from all the VMs which are
>> associated with it."
> 
> consult einav on phrasing, or assume it will be looked at later on again
> i guess.
Sure, I think its better the messages phrase will be looked deeply at
the patches review process, also to preserve time now to review the
design for more crucial issues, and also since its not hard to change it
then.
Also suggestions for new phrasing are welcome.
> 
>>
>>>
>>> 3. Copy Shared Disk
>>> this is "clone disk"? do we have it for non shared disks?
>> I'm not sure I understood completely.
>> Move disk for shared disk, will need to have the same functionality as
>> regular disk, the only difference is that fir shared disk I check all
>> the VMs which the disk is attached to, whether the disk is inactive in
>> the running VMs or attached to non active VMs.>
> 
> your reply started with "move disk for...". I'm asking on "Copy Shared
> Disk".
> do we have a copy disk action?
Oh sorry, got confused with move disk since its using the same command.
This is a remaining from the old wiki where shared disk was considered
to be handled also with Template.

Copy disk should not be considered for shared disk, I removed it from
the wiki.
> 
> Thanks,
>    Itamar



From agwells0714 at gmail.com  Wed Mar 14 14:51:56 2012
From: agwells0714 at gmail.com (Andrew Wells)
Date: Wed, 14 Mar 2012 10:51:56 -0400
Subject: [Engine-devel] Hints for building up a spicec connection in Ovirt
Message-ID: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>

I am trying to build a connection manually with spicec (or what ever I need
to build the connection with) in Ovirt/RHEV and I am wondering what do I
need to form this connection?

And if this is the wrong place to ask, can you point me in the correct
direction?

Andrew Wells
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120314/60c60a23/attachment.html>

From iheim at redhat.com  Wed Mar 14 15:36:38 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 14 Mar 2012 17:36:38 +0200
Subject: [Engine-devel] Hints for building up a spicec connection in
	Ovirt
In-Reply-To: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
Message-ID: <4F60BB06.7010806@redhat.com>

On 03/14/2012 04:51 PM, Andrew Wells wrote:
> I am trying to build a connection manually with spicec (or what ever I
> need to build the connection with) in Ovirt/RHEV and I am wondering what
> do I need to form this connection?
>
> And if this is the wrong place to ask, can you point me in the correct
> direction?

rhev-m mostly uses the activex/xpi wrappers.
cc-ing spice-devel on command line invocation (or client integrating 
with the REST API).

one thing you will need is to call the engine via the API to set the 
"ticket" (password) of the VM, to pass to the client.



From masayag at redhat.com  Wed Mar 14 16:37:07 2012
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 14 Mar 2012 18:37:07 +0200
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <4F60473B.1010408@redhat.com>
References: <4F5FE442.7070602@redhat.com> <4F60473B.1010408@redhat.com>
Message-ID: <4F60C933.3050003@redhat.com>

On 03/14/2012 09:22 AM, Livnat Peer wrote:
> On 14/03/12 02:20, Moti Asayag wrote:
>> Hi all,
>>
>> Disk Permissions feature description Wiki page:
>> http://www.ovirt.org/wiki/Features/DiskPermissions
>>
>> Please share your comments.
>>
> 
> I changed the wiki to use the terminology we used previously when
> discussing permissions.
> 
> I also fixed some things, for example AddDiskToVM I changed the need for
> permissions on the disk to need permissions on the storage domain.
> 
> I am missing details of what actions does the DISK_OPERATOR role
> includes, also when a user creates a disk what permissions do we give
> him implicitly (DISK_OPERATOR ?)

Added to wiki:
http://www.ovirt.org/wiki/Features/DiskPermissions#Roles

> 
> The upgrade flow is written in the open issues, we need to move it from
> the open issues to it's own section and add there that all disk related
> operations should be added to the system administrator.

Added to wiki:
http://www.ovirt.org/wiki/Features/DiskPermissions#Upgrade_DB

> 
> The direct LUN open issues are mostly because the implementation is not
> there yet, it is not about the behavior of the permissions AFAIU.

Indeed.

> 
> Thanks, Livnat
> 
> 
>> Thanks,
>> Moti
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From juan.hernandez at redhat.com  Wed Mar 14 16:44:54 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Wed, 14 Mar 2012 17:44:54 +0100
Subject: [Engine-devel] Can we add a engine_3.0 tag to the git repository?
Message-ID: <4F60CB06.30309@redhat.com>

Currently we have only a engine_3.0 branch, that can be modified. Is it
possible to add a tag?


From ewoud+ovirt at kohlvanwijngaarden.nl  Wed Mar 14 16:49:43 2012
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Wed, 14 Mar 2012 17:49:43 +0100
Subject: [Engine-devel] Hints for building up a spicec connection in
 Ovirt
In-Reply-To: <4F60BB06.7010806@redhat.com>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
	<4F60BB06.7010806@redhat.com>
Message-ID: <20120314164943.GJ4385@bogey.xentower.nl>

On Wed, Mar 14, 2012 at 05:36:38PM +0200, Itamar Heim wrote:
> On 03/14/2012 04:51 PM, Andrew Wells wrote:
> >I am trying to build a connection manually with spicec (or what ever I
> >need to build the connection with) in Ovirt/RHEV and I am wondering what
> >do I need to form this connection?
> >
> >And if this is the wrong place to ask, can you point me in the correct
> >direction?
>
> rhev-m mostly uses the activex/xpi wrappers.
> cc-ing spice-devel on command line invocation (or client integrating
> with the REST API).
>
> one thing you will need is to call the engine via the API to set the
> "ticket" (password) of the VM, to pass to the client.
http://code.google.com/p/rhev-api-labs/source/browse/python/spice/
is a fairly old example written for RHEV 2.2 based on the powershell
RHEV-M API, but I don't think this really changed.


From iheim at redhat.com  Wed Mar 14 16:53:21 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 14 Mar 2012 18:53:21 +0200
Subject: [Engine-devel] Hints for building up a spicec connection in
	Ovirt
In-Reply-To: <20120314164943.GJ4385@bogey.xentower.nl>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
	<4F60BB06.7010806@redhat.com>
	<20120314164943.GJ4385@bogey.xentower.nl>
Message-ID: <4F60CD01.8080303@redhat.com>

On 03/14/2012 06:49 PM, Ewoud Kohl van Wijngaarden wrote:
> On Wed, Mar 14, 2012 at 05:36:38PM +0200, Itamar Heim wrote:
>> On 03/14/2012 04:51 PM, Andrew Wells wrote:
>>> I am trying to build a connection manually with spicec (or what ever I
>>> need to build the connection with) in Ovirt/RHEV and I am wondering what
>>> do I need to form this connection?
>>>
>>> And if this is the wrong place to ask, can you point me in the correct
>>> direction?
>>
>> rhev-m mostly uses the activex/xpi wrappers.
>> cc-ing spice-devel on command line invocation (or client integrating
>> with the REST API).
>>
>> one thing you will need is to call the engine via the API to set the
>> "ticket" (password) of the VM, to pass to the client.
> http://code.google.com/p/rhev-api-labs/source/browse/python/spice/
> is a fairly old example written for RHEV 2.2 based on the powershell
> RHEV-M API, but I don't think this really changed.

actually, i just saw the ovirt cli has a console launch option.
michael - does it launch spice as well, or only vnc?


From agwells0714 at gmail.com  Wed Mar 14 17:17:39 2012
From: agwells0714 at gmail.com (Andrew Wells)
Date: Wed, 14 Mar 2012 13:17:39 -0400
Subject: [Engine-devel] Hints for building up a spicec connection in
	Ovirt
In-Reply-To: <4F60CD01.8080303@redhat.com>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
	<4F60BB06.7010806@redhat.com> <20120314164943.GJ4385@bogey.xentower.nl>
	<4F60CD01.8080303@redhat.com>
Message-ID: <CAP3iW_QKZ7ANiCPjUomjebQKv4JT2UD6VuhE0brU3rf=vo8W3A@mail.gmail.com>

On Wed, Mar 14, 2012 at 12:53 PM, Itamar Heim <iheim at redhat.com> wrote:

> On 03/14/2012 06:49 PM, Ewoud Kohl van Wijngaarden wrote:
>
>> On Wed, Mar 14, 2012 at 05:36:38PM +0200, Itamar Heim wrote:
>>
>>> On 03/14/2012 04:51 PM, Andrew Wells wrote:
>>>
>>>> I am trying to build a connection manually with spicec (or what ever I
>>>> need to build the connection with) in Ovirt/RHEV and I am wondering what
>>>> do I need to form this connection?
>>>>
>>>> And if this is the wrong place to ask, can you point me in the correct
>>>> direction?
>>>>
>>>
>>> rhev-m mostly uses the activex/xpi wrappers.
>>> cc-ing spice-devel on command line invocation (or client integrating
>>> with the REST API).
>>>
>>> one thing you will need is to call the engine via the API to set the
>>> "ticket" (password) of the VM, to pass to the client.
>>>
>> http://code.google.com/p/rhev-**api-labs/source/browse/python/**spice/<http://code.google.com/p/rhev-api-labs/source/browse/python/spice/>
>> is a fairly old example written for RHEV 2.2 based on the powershell
>> RHEV-M API, but I don't think this really changed.
>>
>
> actually, i just saw the ovirt cli has a console launch option.
> michael - does it launch spice as well, or only vnc?
>
> ______________________________**_________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/**mailman/listinfo/engine-devel<http://lists.ovirt.org/mailman/listinfo/engine-devel>
>

So I am assuming that building this connection up in a linux terminal on
Ovirt is more or less equal to setting it up using RHEV, but is that not
the case? Also what michael posted looks good, but I will need to wait
before I can actually dig into that code. In the end I am hoping to just
launch X and then launch the spicec session.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120314/a91208f3/attachment.html>

From eedri at redhat.com  Wed Mar 14 20:45:24 2012
From: eedri at redhat.com (Eyal Edri)
Date: Wed, 14 Mar 2012 16:45:24 -0400 (EDT)
Subject: [Engine-devel] [Jenkins] Auto Generated ovirt-engine rpms for
	fedora 16
In-Reply-To: <2f2e5eb4-e54e-469a-b5db-c5b72d6c5515@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <07147d35-fa5d-4374-ad00-1be50d05651a@zmail17.collab.prod.int.phx2.redhat.com>

fyi,

a new Jenkins job has been added to jenkins.ovirt.org.

you can now d/l fresh ovirt-engine rpms after each commit. 

the rpms are created and latest are stored here:

http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/

the job will also notify the author in case his/her commit will break the rpm build.

latest rpms for now:

ovirt-engine-3.1.0_0001-1.8.fc16.src.rpm
ovirt-engine-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-debuginfo-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64.rpm
ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64.rpm

Enjoy,
Eyal Edri
oVirt Infra Team



From dfediuck at redhat.com  Wed Mar 14 21:30:40 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 14 Mar 2012 23:30:40 +0200
Subject: [Engine-devel] [Jenkins] Auto Generated ovirt-engine rpms for
	fedora 16
In-Reply-To: <07147d35-fa5d-4374-ad00-1be50d05651a@zmail17.collab.prod.int.phx2.redhat.com>
References: <07147d35-fa5d-4374-ad00-1be50d05651a@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F610E00.30304@redhat.com>

Cool!

Any chance to have the same with vdsm rpm's?

On 14/03/12 22:45, Eyal Edri wrote:
> fyi,
> 
> a new Jenkins job has been added to jenkins.ovirt.org.
> 
> you can now d/l fresh ovirt-engine rpms after each commit. 
> 
> the rpms are created and latest are stored here:
> 
> http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/
> 
> the job will also notify the author in case his/her commit will break the rpm build.
> 
> latest rpms for now:
> 
> ovirt-engine-3.1.0_0001-1.8.fc16.src.rpm
> ovirt-engine-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-debuginfo-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64.rpm
> 
> Enjoy,
> Eyal Edri
> oVirt Infra Team
> 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra



From shuming at linux.vnet.ibm.com  Thu Mar 15 01:06:38 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Thu, 15 Mar 2012 09:06:38 +0800
Subject: [Engine-devel] [Jenkins] Auto Generated ovirt-engine rpms for
 fedora 16
In-Reply-To: <07147d35-fa5d-4374-ad00-1be50d05651a@zmail17.collab.prod.int.phx2.redhat.com>
References: <07147d35-fa5d-4374-ad00-1be50d05651a@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F61409E.7090204@linux.vnet.ibm.com>

On 2012-3-15 4:45, Eyal Edri wrote:
> fyi,
>
> a new Jenkins job has been added to jenkins.ovirt.org.
>
> you can now d/l fresh ovirt-engine rpms after each commit.
>
> the rpms are created and latest are stored here:
>
> http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/
>
> the job will also notify the author in case his/her commit will break the rpm build.

How does it notify the submitter?  By echoing messages or email 
notification?

>
> latest rpms for now:
>
> ovirt-engine-3.1.0_0001-1.8.fc16.src.rpm
> ovirt-engine-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-debuginfo-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64.rpm
>
> Enjoy,
> Eyal Edri
> oVirt Infra Team
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


-- 
Shu Ming<shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From iheim at redhat.com  Thu Mar 15 05:25:02 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Mar 2012 07:25:02 +0200
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <4F5FE442.7070602@redhat.com>
References: <4F5FE442.7070602@redhat.com>
Message-ID: <4F617D2E.7090404@redhat.com>

On 03/14/2012 02:20 AM, Moti Asayag wrote:
> Hi all,
>
> Disk Permissions feature description Wiki page:
> http://www.ovirt.org/wiki/Features/DiskPermissions
>
> Please share your comments.

I think you are lacking a paragraph explaining some of the issues around 
this:
- are disks part of storage domains or VMs wrt permissions inheritance?
- what about direct luns (are not part of storage domains)?
- what about shared disks (multiple inheritance if from VM)?
- what if tomorrow we allow disks to span multiple storage domains?
- quota's are already a concept of permissions to create disks at 
storage domain level, does user need both (cumbersome)
- when do we must have this (to filter shared, floating or direct lun 
disks we would show to power users when not attached to VMs) - or these 
won't be available for now via the power user portal, only via admin.

1. "Create disk - requires permissions on the Storage Domain, (can't 
assume Quota is sufficient to permit user creating the disk on the 
Storage Domain, as Quota might be disabled)"

I'd also specify create disk for regular disks is at storage domain 
level?, while direct lun disks require system level permission of add disk.

so, if quota is disabled, how important is it to prevent creation of 
disks (other than direct lun ones, which would require a permission 
similar to storage domain creation)?

if this is added, it has to be implicitly added / not needed if user has 
quota (i.e., having a quota should be similar to having a permission as 
far as the check goes).

2. "Attach disk to VM - requires permissions on the Disk and on the VM 
(applies for shared disk as well). "

which permission at disk is required? (disk access?)

3. "Detach disk from VM - requires permissions on the VM only. (Unlike

attach disk that requires permissions on the VM and on the Disk). "

will detaching a disk copy the permission it so far inherited from the VM?

4. UI changes
an edit permissions button from VM disks subtab seems appropriate (will 
open a dialog i guess)


From yzaslavs at redhat.com  Thu Mar 15 06:44:56 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Thu, 15 Mar 2012 08:44:56 +0200
Subject: [Engine-devel] [Jenkins] Auto Generated ovirt-engine rpms for
	fedora 16
In-Reply-To: <07147d35-fa5d-4374-ad00-1be50d05651a@zmail17.collab.prod.int.phx2.redhat.com>
References: <07147d35-fa5d-4374-ad00-1be50d05651a@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F618FE8.7090705@redhat.com>

On 03/14/2012 10:45 PM, Eyal Edri wrote:
> fyi,
> 
> a new Jenkins job has been added to jenkins.ovirt.org.
> 
> you can now d/l fresh ovirt-engine rpms after each commit. 
> 
> the rpms are created and latest are stored here:
> 
> http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/
> 
> the job will also notify the author in case his/her commit will break the rpm build.
> 
> latest rpms for now:

That's awesome!! +100 on that!

> 
> ovirt-engine-3.1.0_0001-1.8.fc16.src.rpm
> ovirt-engine-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-debuginfo-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64.rpm
> ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64.rpm
> 
> Enjoy,
> Eyal Edri
> oVirt Infra Team
> 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra



From mpastern at redhat.com  Thu Mar 15 06:58:37 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Thu, 15 Mar 2012 08:58:37 +0200
Subject: [Engine-devel] Hints for building up a spicec connection in
	Ovirt
In-Reply-To: <4F60CD01.8080303@redhat.com>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
	<4F60BB06.7010806@redhat.com>
	<20120314164943.GJ4385@bogey.xentower.nl>
	<4F60CD01.8080303@redhat.com>
Message-ID: <4F61931D.9090207@redhat.com>

On 03/14/2012 06:53 PM, Itamar Heim wrote:
> On 03/14/2012 06:49 PM, Ewoud Kohl van Wijngaarden wrote:
>> On Wed, Mar 14, 2012 at 05:36:38PM +0200, Itamar Heim wrote:
>>> On 03/14/2012 04:51 PM, Andrew Wells wrote:
>>>> I am trying to build a connection manually with spicec (or what ever I
>>>> need to build the connection with) in Ovirt/RHEV and I am wondering what
>>>> do I need to form this connection?
>>>>
>>>> And if this is the wrong place to ask, can you point me in the correct
>>>> direction?
>>>
>>> rhev-m mostly uses the activex/xpi wrappers.
>>> cc-ing spice-devel on command line invocation (or client integrating
>>> with the REST API).
>>>
>>> one thing you will need is to call the engine via the API to set the
>>> "ticket" (password) of the VM, to pass to the client.
>> http://code.google.com/p/rhev-api-labs/source/browse/python/spice/
>> is a fairly old example written for RHEV 2.2 based on the powershell
>> RHEV-M API, but I don't think this really changed.
> 
> actually, i just saw the ovirt cli has a console launch option.
> michael - does it launch spice as well, or only vnc?

right now only vnc, in next release spice will be supported as well.



-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From eedri at redhat.com  Thu Mar 15 07:24:39 2012
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 15 Mar 2012 03:24:39 -0400 (EDT)
Subject: [Engine-devel] [Jenkins] Auto Generated ovirt-engine rpms for
	fedora 16
In-Reply-To: <4F610E00.30304@redhat.com>
Message-ID: <9d4bd2c8-7ae1-4ca0-a384-a1276e97a8d5@zmail17.collab.prod.int.phx2.redhat.com>

already exists :)

http://jenkins.ovirt.org/view/vdsm/job/vdsm_create_rpms/

----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Eyal Edri" <eedri at redhat.com>
> Cc: engine-users at ovirt.org, engine-devel at ovirt.org, infra at ovirt.org
> Sent: Wednesday, March 14, 2012 11:30:40 PM
> Subject: Re: [Jenkins] Auto Generated ovirt-engine rpms for fedora 16
> 
> Cool!
> 
> Any chance to have the same with vdsm rpm's?
> 
> On 14/03/12 22:45, Eyal Edri wrote:
> > fyi,
> > 
> > a new Jenkins job has been added to jenkins.ovirt.org.
> > 
> > you can now d/l fresh ovirt-engine rpms after each commit.
> > 
> > the rpms are created and latest are stored here:
> > 
> > http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/
> > 
> > the job will also notify the author in case his/her commit will
> > break the rpm build.
> > 
> > latest rpms for now:
> > 
> > ovirt-engine-3.1.0_0001-1.8.fc16.src.rpm
> > ovirt-engine-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-debuginfo-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64.rpm
> > 
> > Enjoy,
> > Eyal Edri
> > oVirt Infra Team
> > 
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> 
> 


From eedri at redhat.com  Thu Mar 15 07:25:10 2012
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 15 Mar 2012 03:25:10 -0400 (EDT)
Subject: [Engine-devel] [Jenkins] Auto Generated ovirt-engine rpms for
	fedora 16
In-Reply-To: <4F61409E.7090204@linux.vnet.ibm.com>
Message-ID: <9ededfd7-0588-4f10-a83b-fdffc21afd8d@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Shu Ming" <shuming at linux.vnet.ibm.com>
> To: "Eyal Edri" <eedri at redhat.com>
> Cc: engine-users at ovirt.org, engine-devel at ovirt.org, infra at ovirt.org
> Sent: Thursday, March 15, 2012 3:06:38 AM
> Subject: Re: [Engine-devel] [Jenkins] Auto Generated ovirt-engine rpms for fedora 16
> 
> On 2012-3-15 4:45, Eyal Edri wrote:
> > fyi,
> >
> > a new Jenkins job has been added to jenkins.ovirt.org.
> >
> > you can now d/l fresh ovirt-engine rpms after each commit.
> >
> > the rpms are created and latest are stored here:
> >
> > http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/
> >
> > the job will also notify the author in case his/her commit will
> > break the rpm build.
> 
> How does it notify the submitter?  By echoing messages or email
> notification?

emailing the email set in git/gerrit.

> 
> >
> > latest rpms for now:
> >
> > ovirt-engine-3.1.0_0001-1.8.fc16.src.rpm
> > ovirt-engine-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-debuginfo-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64.rpm
> > ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64.rpm
> >
> > Enjoy,
> > Eyal Edri
> > oVirt Infra Team
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> --
> Shu Ming<shuming at linux.vnet.ibm.com>
> IBM China Systems and Technology Laboratory
> 
> 
> 


From lpeer at redhat.com  Thu Mar 15 07:52:59 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Thu, 15 Mar 2012 09:52:59 +0200
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <4F617D2E.7090404@redhat.com>
References: <4F5FE442.7070602@redhat.com> <4F617D2E.7090404@redhat.com>
Message-ID: <4F619FDB.9030309@redhat.com>

On 15/03/12 07:25, Itamar Heim wrote:
> On 03/14/2012 02:20 AM, Moti Asayag wrote:
>> Hi all,
>>
>> Disk Permissions feature description Wiki page:
>> http://www.ovirt.org/wiki/Features/DiskPermissions
>>
>> Please share your comments.
> 
> I think you are lacking a paragraph explaining some of the issues around
> this:
> - are disks part of storage domains or VMs wrt permissions inheritance?
> - what about direct luns (are not part of storage domains)?
> - what about shared disks (multiple inheritance if from VM)?
> - what if tomorrow we allow disks to span multiple storage domains?
> - quota's are already a concept of permissions to create disks at
> storage domain level, does user need both (cumbersome)
> - when do we must have this (to filter shared, floating or direct lun
> disks we would show to power users when not attached to VMs) - or these
> won't be available for now via the power user portal, only via admin.
> 
> 1. "Create disk - requires permissions on the Storage Domain, (can't
> assume Quota is sufficient to permit user creating the disk on the
> Storage Domain, as Quota might be disabled)"
> 
> I'd also specify create disk for regular disks is at storage domain
> level?, while direct lun disks require system level permission of add disk.
> 
> so, if quota is disabled, how important is it to prevent creation of
> disks (other than direct lun ones, which would require a permission
> similar to storage domain creation)?
> 
> if this is added, it has to be implicitly added / not needed if user has
> quota (i.e., having a quota should be similar to having a permission as
> far as the check goes).
> 

We should look into it, how complicate is it to validate if user has
either quota or permission, and allow creating a disk on a SD if either
exists.

> 2. "Attach disk to VM - requires permissions on the Disk and on the VM
> (applies for shared disk as well). "
> 
> which permission at disk is required? (disk access?)
> 


The user should have attach_disk permission on the disk and on the VM
(same action on two objects).

> 3. "Detach disk from VM - requires permissions on the VM only. (Unlike
> 
> attach disk that requires permissions on the VM and on the Disk). "
> 
> will detaching a disk copy the permission it so far inherited from the VM?
> 

No, inheritance is never translated into explicit permission on the
objects in the hierarchy .

> 4. UI changes
> an edit permissions button from VM disks subtab seems appropriate (will
> open a dialog i guess)

I think we need permissions subtab in the floating disk main tab.
I'll ask Einav to add the UI part as well to the wiki.



> ________________________
_______________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From mpastern at redhat.com  Thu Mar 15 10:53:11 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Thu, 15 Mar 2012 12:53:11 +0200
Subject: [Engine-devel] Bridgeless Networks api design
Message-ID: <4F61CA17.6080203@redhat.com>


Hi,

First of all i would like to understand the exact meaning of the vm_network,
from the wiki [1] - "a "Vm network" is implemented over a bridge, otherwise bridgeless",

if so, why not calling network property <bridged>true|false</bridged>?

from the other hand i understand that this is only current implementation and it
may change in a future,

anyway adding <vm_network>true|false</vm_network> property to <network> entity in api
(as was suggested) doesn't sound good cause vm_network sounds as a network type, but then
the question is Management/Migration/Storage/Display should be also network's types? and if single
network can be used for the Management|Migration|Storage|Display simultaneously? if the answer is
yes, network modelling probably should look like:

<network>
  <bridged>true|false</bridged>
  <type>Management/Migration/Storage/Display</type>
</network>

or

<network>
  <bridged>true|false</bridged>
  <designation>Management|Migration|Storage|Display</designation>
</network>

your thoughts?

[1] http://www.ovirt.org/wiki/Features/Design/Network/Bridgeless_Networks

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From lhornyak at redhat.com  Thu Mar 15 10:50:31 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Thu, 15 Mar 2012 06:50:31 -0400 (EDT)
Subject: [Engine-devel] revievers needed
In-Reply-To: <444ba547-1669-4f6d-aa81-74e51a48f935@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <8e8009a8-887e-4ce1-840a-87feaa71c134@zmail01.collab.prod.int.phx2.redhat.com>

Hi,

I have a big pile of patches waiting for reviewers, some of them are very old. If you have some spare-time, please take any:
http://gerrit.ovirt.org/#dashboard,1000027

Thank you,
Laszlo


From amureini at redhat.com  Thu Mar 15 11:49:44 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Thu, 15 Mar 2012 07:49:44 -0400 (EDT)
Subject: [Engine-devel] revievers needed
In-Reply-To: <8e8009a8-887e-4ce1-840a-87feaa71c134@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <0ab27e12-60e8-406d-a5dd-f5d0974d25d2@zmail17.collab.prod.int.phx2.redhat.com>

I'd be happy to review them, but someone else will have to +2 them.

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, March 15, 2012 12:50:31 PM
> Subject: [Engine-devel] revievers needed
> 
> Hi,
> 
> I have a big pile of patches waiting for reviewers, some of them are
> very old. If you have some spare-time, please take any:
> http://gerrit.ovirt.org/#dashboard,1000027
> 
> Thank you,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Thu Mar 15 12:49:14 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Mar 2012 14:49:14 +0200
Subject: [Engine-devel] revievers needed
In-Reply-To: <0ab27e12-60e8-406d-a5dd-f5d0974d25d2@zmail17.collab.prod.int.phx2.redhat.com>
References: <0ab27e12-60e8-406d-a5dd-f5d0974d25d2@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F61E54A.9050609@redhat.com>

On 03/15/2012 01:49 PM, Allon Mureinik wrote:
> I'd be happy to review them, but someone else will have to +2 them.

giving +1 to patches helps maintainers in their review as well.


From iheim at redhat.com  Thu Mar 15 13:58:59 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Mar 2012 15:58:59 +0200
Subject: [Engine-devel] Bridgeless Networks api design
In-Reply-To: <4F61CA17.6080203@redhat.com>
References: <4F61CA17.6080203@redhat.com>
Message-ID: <4F61F5A3.90706@redhat.com>

On 03/15/2012 12:53 PM, Michael Pasternak wrote:
>
> Hi,
>
> First of all i would like to understand the exact meaning of the vm_network,
> from the wiki [1] - "a "Vm network" is implemented over a bridge, otherwise bridgeless",
>
> if so, why not calling network property<bridged>true|false</bridged>?

bridge vs. bridgeless is an implementation detail. some network models 
could run without a bridge as well for VMs (though not currently supported).
so the optimization is to not use a bridge for networks that can't run 
VMs, but the reverse logic does not apply.

>
> from the other hand i understand that this is only current implementation and it
> may change in a future,
>
> anyway adding<vm_network>true|false</vm_network>  property to<network>  entity in api
> (as was suggested) doesn't sound good cause vm_network sounds as a network type, but then
> the question is Management/Migration/Storage/Display should be also network's types? and if single
> network can be used for the Management|Migration|Storage|Display simultaneously? if the answer is
> yes, network modelling probably should look like:
>
> <network>
>    <bridged>true|false</bridged>
>    <type>Management/Migration/Storage/Display</type>
> </network>
>
> or
>
> <network>
>    <bridged>true|false</bridged>
>    <designation>Management|Migration|Storage|Display</designation>
> </network>

that bridged should be replaced with something saying VM_Network (better 
name needed).
btw, I wonder if a private network (only for one vm) is also a type, or 
just a private case of a vm network.

and that type/designation can have more than one of course.
(and that migration/storage networks are still not supported).

>
> your thoughts?
>
> [1] http://www.ovirt.org/wiki/Features/Design/Network/Bridgeless_Networks
>



From agwells0714 at gmail.com  Thu Mar 15 15:03:00 2012
From: agwells0714 at gmail.com (Andrew Wells)
Date: Thu, 15 Mar 2012 11:03:00 -0400
Subject: [Engine-devel] Hints for building up a spicec connection in
	Ovirt
In-Reply-To: <4F61931D.9090207@redhat.com>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
	<4F60BB06.7010806@redhat.com> <20120314164943.GJ4385@bogey.xentower.nl>
	<4F60CD01.8080303@redhat.com> <4F61931D.9090207@redhat.com>
Message-ID: <CAP3iW_Si21TAL1PzsFYCb0E8T=s6jAj-hf-FqE0nx4j3pxjUXg@mail.gmail.com>

On Thu, Mar 15, 2012 at 2:58 AM, Michael Pasternak <mpastern at redhat.com>wrote:

> On 03/14/2012 06:53 PM, Itamar Heim wrote:
> > On 03/14/2012 06:49 PM, Ewoud Kohl van Wijngaarden wrote:
> >> On Wed, Mar 14, 2012 at 05:36:38PM +0200, Itamar Heim wrote:
> >>> On 03/14/2012 04:51 PM, Andrew Wells wrote:
> >>>> I am trying to build a connection manually with spicec (or what ever I
> >>>> need to build the connection with) in Ovirt/RHEV and I am wondering
> what
> >>>> do I need to form this connection?
> >>>>
> >>>> And if this is the wrong place to ask, can you point me in the correct
> >>>> direction?
> >>>
> >>> rhev-m mostly uses the activex/xpi wrappers.
> >>> cc-ing spice-devel on command line invocation (or client integrating
> >>> with the REST API).
> >>>
> >>> one thing you will need is to call the engine via the API to set the
> >>> "ticket" (password) of the VM, to pass to the client.
> >> http://code.google.com/p/rhev-api-labs/source/browse/python/spice/
> >> is a fairly old example written for RHEV 2.2 based on the powershell
> >> RHEV-M API, but I don't think this really changed.
> >
> > actually, i just saw the ovirt cli has a console launch option.
> > michael - does it launch spice as well, or only vnc?
>
> right now only vnc, in next release spice will be supported as well.
>
>
>
> --
>
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

Is the api-power-shell
https://rhevm.example.com:8443/rhevm-api-powershellstill in 3.0? do I
need to install it? Or is this the /api now?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120315/8028b110/attachment.html>

From iheim at redhat.com  Thu Mar 15 15:07:04 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Mar 2012 17:07:04 +0200
Subject: [Engine-devel] Hints for building up a spicec connection in
	Ovirt
In-Reply-To: <CAP3iW_Si21TAL1PzsFYCb0E8T=s6jAj-hf-FqE0nx4j3pxjUXg@mail.gmail.com>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
	<4F60BB06.7010806@redhat.com>
	<20120314164943.GJ4385@bogey.xentower.nl>
	<4F60CD01.8080303@redhat.com> <4F61931D.9090207@redhat.com>
	<CAP3iW_Si21TAL1PzsFYCb0E8T=s6jAj-hf-FqE0nx4j3pxjUXg@mail.gmail.com>
Message-ID: <4F620598.8030107@redhat.com>

On 03/15/2012 05:03 PM, Andrew Wells wrote:
> On Thu, Mar 15, 2012 at 2:58 AM, Michael Pasternak <mpastern at redhat.com
> <mailto:mpastern at redhat.com>> wrote:
...
>
> Is the api-power-shell
> https://rhevm.example.com:8443/rhevm-api-powershell still in 3.0? do I
> need to install it? Or is this the /api now?

no. this is the old 2.2 wrapper api. 3.0 has a "native" /api now.


From agwells0714 at gmail.com  Thu Mar 15 15:32:01 2012
From: agwells0714 at gmail.com (Andrew Wells)
Date: Thu, 15 Mar 2012 11:32:01 -0400
Subject: [Engine-devel] Hints for building up a spicec connection in
	Ovirt
In-Reply-To: <4F620598.8030107@redhat.com>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
	<4F60BB06.7010806@redhat.com> <20120314164943.GJ4385@bogey.xentower.nl>
	<4F60CD01.8080303@redhat.com> <4F61931D.9090207@redhat.com>
	<CAP3iW_Si21TAL1PzsFYCb0E8T=s6jAj-hf-FqE0nx4j3pxjUXg@mail.gmail.com>
	<4F620598.8030107@redhat.com>
Message-ID: <CAP3iW_TsyAGkCyDPJyC2B1vGgFXDf0h15ufFnkV8N07WUUcqkQ@mail.gmail.com>

On Thu, Mar 15, 2012 at 11:07 AM, Itamar Heim <iheim at redhat.com> wrote:

> On 03/15/2012 05:03 PM, Andrew Wells wrote:
>
>> On Thu, Mar 15, 2012 at 2:58 AM, Michael Pasternak <mpastern at redhat.com
>> <mailto:mpastern at redhat.com>> wrote:
>>
> ...
>
>
>> Is the api-power-shell
>> https://rhevm.example.com:**8443/rhevm-api-powershell<https://rhevm.example.com:8443/rhevm-api-powershell>still in 3.0? do I
>> need to install it? Or is this the /api now?
>>
>
> no. this is the old 2.2 wrapper api. 3.0 has a "native" /api now.
>

Is there a package that provides the python rhev libraries used in the
script? Or where is the source so that I can include/import them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120315/a497c42c/attachment.html>

From agwells0714 at gmail.com  Thu Mar 15 15:33:15 2012
From: agwells0714 at gmail.com (Andrew Wells)
Date: Thu, 15 Mar 2012 11:33:15 -0400
Subject: [Engine-devel] Hints for building up a spicec connection in
	Ovirt
In-Reply-To: <CAP3iW_TsyAGkCyDPJyC2B1vGgFXDf0h15ufFnkV8N07WUUcqkQ@mail.gmail.com>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
	<4F60BB06.7010806@redhat.com> <20120314164943.GJ4385@bogey.xentower.nl>
	<4F60CD01.8080303@redhat.com> <4F61931D.9090207@redhat.com>
	<CAP3iW_Si21TAL1PzsFYCb0E8T=s6jAj-hf-FqE0nx4j3pxjUXg@mail.gmail.com>
	<4F620598.8030107@redhat.com>
	<CAP3iW_TsyAGkCyDPJyC2B1vGgFXDf0h15ufFnkV8N07WUUcqkQ@mail.gmail.com>
Message-ID: <CAP3iW_QYUmP2-s4U+yTQ7ER=w4iw-G25ahMi7-8spzhK2+KQ9A@mail.gmail.com>

And is their any documentation on using the python rhev libraries as that
would be helpful as well. you guys are getting me excited thinking this
might work.

On Thu, Mar 15, 2012 at 11:32 AM, Andrew Wells <agwells0714 at gmail.com>wrote:

>
>
> On Thu, Mar 15, 2012 at 11:07 AM, Itamar Heim <iheim at redhat.com> wrote:
>
>> On 03/15/2012 05:03 PM, Andrew Wells wrote:
>>
>>> On Thu, Mar 15, 2012 at 2:58 AM, Michael Pasternak <mpastern at redhat.com
>>> <mailto:mpastern at redhat.com>> wrote:
>>>
>> ...
>>
>>
>>> Is the api-power-shell
>>> https://rhevm.example.com:**8443/rhevm-api-powershell<https://rhevm.example.com:8443/rhevm-api-powershell>still in 3.0? do I
>>> need to install it? Or is this the /api now?
>>>
>>
>> no. this is the old 2.2 wrapper api. 3.0 has a "native" /api now.
>>
>
> Is there a package that provides the python rhev libraries used in the
> script? Or where is the source so that I can include/import them.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120315/e8ecc777/attachment.html>

From ofrenkel at redhat.com  Thu Mar 15 15:34:58 2012
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Thu, 15 Mar 2012 11:34:58 -0400 (EDT)
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <4F619FDB.9030309@redhat.com>
Message-ID: <e43ebb15-267a-4046-930f-07f60bbf60ba@ofrenkel.csb>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, March 15, 2012 9:52:59 AM
> Subject: Re: [Engine-devel] Disk Permissions Feature
> 
> On 15/03/12 07:25, Itamar Heim wrote:
> > On 03/14/2012 02:20 AM, Moti Asayag wrote:
> >> Hi all,
> >>
> >> Disk Permissions feature description Wiki page:
> >> http://www.ovirt.org/wiki/Features/DiskPermissions
> >>
> >> Please share your comments.
> > 
> > I think you are lacking a paragraph explaining some of the issues
> > around
> > this:
> > - are disks part of storage domains or VMs wrt permissions
> > inheritance?

yes - "Disk inherits permissions from the VM it is attached to and from the storage domain it resides on (if there is one)"

> > - what about direct luns (are not part of storage domains)?
> > - what about shared disks (multiple inheritance if from VM)?

i guess so, i think current vm roles shouldn't contain the disks actions,
therefore vm admin cannot change any disk attached to his vm,
only if got an explicit permission on it.
(one can have "disk-operator" on vm, and then can manipulate any disk related to that vm)

> > - what if tomorrow we allow disks to span multiple storage domains?

i don't see a problem with this, as user will need to have permission on all the domains,
makes sense to me.

> > - quota's are already a concept of permissions to create disks at
> > storage domain level, does user need both (cumbersome)
> > - when do we must have this (to filter shared, floating or direct
> > lun
> > disks we would show to power users when not attached to VMs) - or
> > these
> > won't be available for now via the power user portal, only via
> > admin.
> > 
> > 1. "Create disk - requires permissions on the Storage Domain,
> > (can't
> > assume Quota is sufficient to permit user creating the disk on the
> > Storage Domain, as Quota might be disabled)"
> > 
> > I'd also specify create disk for regular disks is at storage domain
> > level?, while direct lun disks require system level permission of
> > add disk.
> > 
> > so, if quota is disabled, how important is it to prevent creation
> > of
> > disks (other than direct lun ones, which would require a permission
> > similar to storage domain creation)?
> > 
> > if this is added, it has to be implicitly added / not needed if
> > user has
> > quota (i.e., having a quota should be similar to having a
> > permission as
> > far as the check goes).
> > 
> 
> We should look into it, how complicate is it to validate if user has
> either quota or permission, and allow creating a disk on a SD if
> either
> exists.

this might be confusing to the user as he can disable the quota,
then stuff would stop working.

> 
> > 2. "Attach disk to VM - requires permissions on the Disk and on the
> > VM
> > (applies for shared disk as well). "
> > 
> > which permission at disk is required? (disk access?)
> > 
> 
> 
> The user should have attach_disk permission on the disk and on the VM
> (same action on two objects).
> 
> > 3. "Detach disk from VM - requires permissions on the VM only.
> > (Unlike
> > 
> > attach disk that requires permissions on the VM and on the Disk). "
> > 
> > will detaching a disk copy the permission it so far inherited from
> > the VM?
> > 
> 
> No, inheritance is never translated into explicit permission on the
> objects in the hierarchy .
> 
> > 4. UI changes
> > an edit permissions button from VM disks subtab seems appropriate
> > (will
> > open a dialog i guess)
> 
> I think we need permissions subtab in the floating disk main tab.
> I'll ask Einav to add the UI part as well to the wiki.
> 
> 
> 
> > ________________________
> _______________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Thu Mar 15 15:46:07 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Mar 2012 17:46:07 +0200
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <e43ebb15-267a-4046-930f-07f60bbf60ba@ofrenkel.csb>
References: <e43ebb15-267a-4046-930f-07f60bbf60ba@ofrenkel.csb>
Message-ID: <4F620EBF.2040704@redhat.com>

On 03/15/2012 05:34 PM, Omer Frenkel wrote:
>>> >  >  1. "Create disk - requires permissions on the Storage Domain,
>>> >  >  (can't
>>> >  >  assume Quota is sufficient to permit user creating the disk on the
>>> >  >  Storage Domain, as Quota might be disabled)"
>>> >  >
>>> >  >  I'd also specify create disk for regular disks is at storage domain
>>> >  >  level?, while direct lun disks require system level permission of
>>> >  >  add disk.
>>> >  >
>>> >  >  so, if quota is disabled, how important is it to prevent creation
>>> >  >  of
>>> >  >  disks (other than direct lun ones, which would require a permission
>>> >  >  similar to storage domain creation)?
>>> >  >
>>> >  >  if this is added, it has to be implicitly added / not needed if
>>> >  >  user has
>>> >  >  quota (i.e., having a quota should be similar to having a
>>> >  >  permission as
>>> >  >  far as the check goes).
>>> >  >
>> >
>> >  We should look into it, how complicate is it to validate if user has
>> >  either quota or permission, and allow creating a disk on a SD if
>> >  either
>> >  exists.
> this might be confusing to the user as he can disable the quota,
> then stuff would stop working.
>

we can't require both quota and permissions from user on storage domains 
- that's cumbersome.
question is if we can limit the need for permissions to disks only to 
places where they are needed (shared, direct, floating)?


From iheim at redhat.com  Thu Mar 15 15:47:59 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 15 Mar 2012 17:47:59 +0200
Subject: [Engine-devel] Hints for building up a spicec connection in
	Ovirt
In-Reply-To: <CAP3iW_QYUmP2-s4U+yTQ7ER=w4iw-G25ahMi7-8spzhK2+KQ9A@mail.gmail.com>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
	<4F60BB06.7010806@redhat.com>
	<20120314164943.GJ4385@bogey.xentower.nl>
	<4F60CD01.8080303@redhat.com> <4F61931D.9090207@redhat.com>
	<CAP3iW_Si21TAL1PzsFYCb0E8T=s6jAj-hf-FqE0nx4j3pxjUXg@mail.gmail.com>
	<4F620598.8030107@redhat.com>
	<CAP3iW_TsyAGkCyDPJyC2B1vGgFXDf0h15ufFnkV8N07WUUcqkQ@mail.gmail.com>
	<CAP3iW_QYUmP2-s4U+yTQ7ER=w4iw-G25ahMi7-8spzhK2+KQ9A@mail.gmail.com>
Message-ID: <4F620F2F.1080502@redhat.com>

On 03/15/2012 05:33 PM, Andrew Wells wrote:
> And is their any documentation on using the python rhev libraries as
> that would be helpful as well. you guys are getting me excited thinking
> this might work.

to both your questions:
http://www.ovirt.org/wiki/CLI
http://www.ovirt.org/wiki/SDK
http://lists.ovirt.org/pipermail/users/2012-March/001159.html
http://lists.ovirt.org/pipermail/users/2012-March/001158.html

> On Thu, Mar 15, 2012 at 11:32 AM, Andrew Wells <agwells0714 at gmail.com
> <mailto:agwells0714 at gmail.com>> wrote:
>
>
>
>     On Thu, Mar 15, 2012 at 11:07 AM, Itamar Heim <iheim at redhat.com
>     <mailto:iheim at redhat.com>> wrote:
>
>         On 03/15/2012 05:03 PM, Andrew Wells wrote:
>
>             On Thu, Mar 15, 2012 at 2:58 AM, Michael Pasternak
>             <mpastern at redhat.com <mailto:mpastern at redhat.com>
>             <mailto:mpastern at redhat.com <mailto:mpastern at redhat.com>>>
>             wrote:
>
>         ...
>
>
>             Is the api-power-shell
>             https://rhevm.example.com:__8443/rhevm-api-powershell
>             <https://rhevm.example.com:8443/rhevm-api-powershell> still
>             in 3.0? do I
>             need to install it? Or is this the /api now?
>
>
>         no. this is the old 2.2 wrapper api. 3.0 has a "native" /api now.
>
>
>     Is there a package that provides the python rhev libraries used in
>     the script? Or where is the source so that I can include/import them.
>
>



From agwells0714 at gmail.com  Thu Mar 15 16:11:38 2012
From: agwells0714 at gmail.com (Andrew Wells)
Date: Thu, 15 Mar 2012 12:11:38 -0400
Subject: [Engine-devel] Hints for building up a spicec connection in
	Ovirt
In-Reply-To: <4F620F2F.1080502@redhat.com>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
	<4F60BB06.7010806@redhat.com> <20120314164943.GJ4385@bogey.xentower.nl>
	<4F60CD01.8080303@redhat.com> <4F61931D.9090207@redhat.com>
	<CAP3iW_Si21TAL1PzsFYCb0E8T=s6jAj-hf-FqE0nx4j3pxjUXg@mail.gmail.com>
	<4F620598.8030107@redhat.com>
	<CAP3iW_TsyAGkCyDPJyC2B1vGgFXDf0h15ufFnkV8N07WUUcqkQ@mail.gmail.com>
	<CAP3iW_QYUmP2-s4U+yTQ7ER=w4iw-G25ahMi7-8spzhK2+KQ9A@mail.gmail.com>
	<4F620F2F.1080502@redhat.com>
Message-ID: <CAP3iW_RUoLwk+AmhqhrDx17xSa5GdkdSV0_NeKeCjRCsV3LUZg@mail.gmail.com>

On Thu, Mar 15, 2012 at 11:47 AM, Itamar Heim <iheim at redhat.com> wrote:

> On 03/15/2012 05:33 PM, Andrew Wells wrote:
>
>> And is their any documentation on using the python rhev libraries as
>> that would be helpful as well. you guys are getting me excited thinking
>> this might work.
>>
>
> to both your questions:
> http://www.ovirt.org/wiki/CLI
> http://www.ovirt.org/wiki/SDK
> http://lists.ovirt.org/**pipermail/users/2012-March/**001159.html<http://lists.ovirt.org/pipermail/users/2012-March/001159.html>
> http://lists.ovirt.org/**pipermail/users/2012-March/**001158.html<http://lists.ovirt.org/pipermail/users/2012-March/001158.html>
>
>  On Thu, Mar 15, 2012 at 11:32 AM, Andrew Wells <agwells0714 at gmail.com
>> <mailto:agwells0714 at gmail.com>**> wrote:
>>
>>
>>
>>    On Thu, Mar 15, 2012 at 11:07 AM, Itamar Heim <iheim at redhat.com
>>    <mailto:iheim at redhat.com>> wrote:
>>
>>        On 03/15/2012 05:03 PM, Andrew Wells wrote:
>>
>>            On Thu, Mar 15, 2012 at 2:58 AM, Michael Pasternak
>>            <mpastern at redhat.com <mailto:mpastern at redhat.com>
>>            <mailto:mpastern at redhat.com <mailto:mpastern at redhat.com>>>
>>
>>            wrote:
>>
>>        ...
>>
>>
>>            Is the api-power-shell
>>            https://rhevm.example.com:__**8443/rhevm-api-powershell
>>
>>            <https://rhevm.example.com:**8443/rhevm-api-powershell<https://rhevm.example.com:8443/rhevm-api-powershell>>
>> still
>>            in 3.0? do I
>>            need to install it? Or is this the /api now?
>>
>>
>>        no. this is the old 2.2 wrapper api. 3.0 has a "native" /api now.
>>
>>
>>    Is there a package that provides the python rhev libraries used in
>>    the script? Or where is the source so that I can include/import them.
>>
>>
>>
>
You are Awesome!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120315/affabf70/attachment.html>

From agwells0714 at gmail.com  Thu Mar 15 16:38:05 2012
From: agwells0714 at gmail.com (Andrew Wells)
Date: Thu, 15 Mar 2012 12:38:05 -0400
Subject: [Engine-devel] [Spice-devel] Hints for building up a spicec
 connection in Ovirt
In-Reply-To: <20120315163233.GU2726@teriyaki.redhat.com>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
	<4F60BB06.7010806@redhat.com> <20120314164943.GJ4385@bogey.xentower.nl>
	<4F60CD01.8080303@redhat.com> <4F61931D.9090207@redhat.com>
	<CAP3iW_Si21TAL1PzsFYCb0E8T=s6jAj-hf-FqE0nx4j3pxjUXg@mail.gmail.com>
	<4F620598.8030107@redhat.com>
	<CAP3iW_TsyAGkCyDPJyC2B1vGgFXDf0h15ufFnkV8N07WUUcqkQ@mail.gmail.com>
	<CAP3iW_QYUmP2-s4U+yTQ7ER=w4iw-G25ahMi7-8spzhK2+KQ9A@mail.gmail.com>
	<20120315163233.GU2726@teriyaki.redhat.com>
Message-ID: <CAP3iW_SqqJWWLUBWZ2539SWrHcGn2BvVO+NKys=D=p_xudwt9w@mail.gmail.com>

On Thu, Mar 15, 2012 at 12:32 PM, Christophe Fergeau <cfergeau at redhat.com>wrote:

> Hey,
>
> On Thu, Mar 15, 2012 at 11:33:15AM -0400, Andrew Wells wrote:
> > And is their any documentation on using the python rhev libraries as that
> > would be helpful as well. you guys are getting me excited thinking this
> > might work.
>
> If that can be helpful to you, I've worked on some C code to talk to the
> oVirt REST API to be able to list VMs and get the needed info to connect to
> such a VM with SPICE. The code is unfinished, but listing VMs, starting VMs
> and connecting to VM without TLS works, I can send you this code if that
> can be of any use to you.
>
> Christophe
>

More examples the better, thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120315/b3a8b5b5/attachment.html>

From oschreib at redhat.com  Thu Mar 15 17:39:20 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Thu, 15 Mar 2012 13:39:20 -0400 (EDT)
Subject: [Engine-devel] Can we add a engine_3.0 tag to the git
	repository?
In-Reply-To: <4F60CB06.30309@redhat.com>
Message-ID: <02a9ad2d-cf38-49af-b87c-5251262216e8@zmail14.collab.prod.int.phx2.redhat.com>

Forgot to do that during last build release.

Done.

Thanks for noticing.

----- Original Message -----
> Currently we have only a engine_3.0 branch, that can be modified. Is
> it
> possible to add a tag?
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From danny.ran at redhat.com  Thu Mar 15 17:52:47 2012
From: danny.ran at redhat.com (Danny Rankevich)
Date: Thu, 15 Mar 2012 13:52:47 -0400 (EDT)
Subject: [Engine-devel] Use java.util.Collection where possible?
In-Reply-To: <2c5e3d14-7679-4ea2-88cc-189a08c53568@asafnb.int.vertix-tech.com>
Message-ID: <7992dfd9-fe8d-4615-bccf-fa44bc1bba92@zmail16.collab.prod.int.phx2.redhat.com>

I ran deRPC with Collection in the parameters AND return type, and everything works ok.
why should there be a problem? the concrete type is serialized in the payload...

----- Original Message -----
> From: "Asaf Shakarchi" <ashakarc at redhat.com>
> To: "Danny Rankevich" <danny.ran at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Yair Zaslavsky" <yzaslavs at redhat.com>
> Sent: Wednesday, March 14, 2012 1:19:18 PM
> Subject: Re: [Engine-devel] Use java.util.Collection where possible?
> 
> Danny are you sure?
> IIRC GWT RPC Oracle wont be able to pick the right implementation
> and will generate code for any possible concrete impl,
> 
> 
> Asaf.
> ----- Original Message -----
> > From: "Danny Rankevich" <danny.ran at redhat.com>
> > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, March 14, 2012 12:58:35 PM
> > Subject: Re: [Engine-devel] Use java.util.Collection where
> > possible?
> > 
> > BWT I did some checks on the GWT RPC that we use (deRPC) and there
> > shouldn't be any problems using Collection interface (or any
> > interface) in the generic api service.
> > 
> > ----- Original Message -----
> > > From: "Allon Mureinik" <amureini at redhat.com>
> > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Sunday, March 4, 2012 6:57:24 PM
> > > Subject: Re: [Engine-devel] Use java.util.Collection where
> > > possible?
> > > 
> > > My two cents:
> > > 
> > > There are two meanings of subtyping Collection (or any other
> > > interface, for that matter) - additional logic and specific
> > > implementation.
> > > I think wherever possible, we should use the interface that
> > > infers
> > > as
> > > much logic as possible (e.g., java.util.List for ordering,
> > > java.util.Set for uniquness, java.util.SortedSet for natural
> > > ordering, etc.), without inferring any specific implementation
> > > (e.g., ArrayList, HashSet, etc.).
> > > 
> > > The flipside of this notion is that it's a mistake to use an
> > > overly
> > > specific class/interface - when your parameter type is ArrayList,
> > > you implicitly tell the user the *order* of his objects matter,
> > > and
> > > that it matters to your internal algorithm to be able to do
> > > get(i)
> > > as an O(1) operation.
> > > 
> > > Bottom line,  now that I'm done with CS 101:
> > > +1, but be careful not use interfaces that are too low.
> > > Most methods that now receive an ArrayList will still compile if
> > > you
> > > change the parameter type to Collection, but make sure that you
> > > don't implicitly assume some ordering, e.g.
> > > 
> > > -Allon
> > > 
> > > ----- Original Message -----
> > > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Thursday, March 1, 2012 5:18:03 PM
> > > > Subject: [Engine-devel] Use java.util.Collection where
> > > > possible?
> > > > 
> > > > Hi,
> > > > I see that in some places in engine-core we use Java.Util.List,
> > > > or
> > > > even
> > > > Java.Util.ArrayList as types of method arguments, while in the
> > > > method
> > > > code we do nothing besides iterating over the collection.
> > > > I then found all kinds of usages like this:
> > > > 
> > > > x.foo(new ArrayList<MyType>(myMap.values()));
> > > > 
> > > > As you can see need to instantiate a new ArrayList in order to
> > > > use
> > > > the
> > > > values of the map in method foo.
> > > > Do you see any reason why not change the argument type (at
> > > > method
> > > > signature) to Collection in such places, where possible?
> > > > 
> > > > Yair
> > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From juan.hernandez at redhat.com  Thu Mar 15 17:55:08 2012
From: juan.hernandez at redhat.com (Juan Hernandez)
Date: Thu, 15 Mar 2012 18:55:08 +0100
Subject: [Engine-devel] Can we add a engine_3.0 tag to the git
	repository?
In-Reply-To: <02a9ad2d-cf38-49af-b87c-5251262216e8@zmail14.collab.prod.int.phx2.redhat.com>
References: <02a9ad2d-cf38-49af-b87c-5251262216e8@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F622CFC.2060203@redhat.com>

Than you Ofer, that simplifies the instructions to generate the tarball
that should go in the .spec file for Fedora.

On 03/15/2012 06:39 PM, Ofer Schreiber wrote:
> Forgot to do that during last build release.
> 
> Done.
> 
> Thanks for noticing.
> 
> ----- Original Message -----
>> Currently we have only a engine_3.0 branch, that can be modified. Is
>> it
>> possible to add a tag?
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From eedri at redhat.com  Thu Mar 15 19:48:56 2012
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 15 Mar 2012 15:48:56 -0400 (EDT)
Subject: [Engine-devel] [Jenkins] ovirt-engine-cli and ovirt-engine-sdk rpms
	availiable
In-Reply-To: <f431773e-a534-45d3-a366-81266f60adba@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <c270310b-bf9f-453f-9960-a09a41007561@zmail17.collab.prod.int.phx2.redhat.com>

fyi,

you can now d/l ovirt engine cli & rpms built per commit directly from jenkins:

http://jenkins.ovirt.org/view/ovirt_engine_sdk/job/ovirt_engine_sdk_create_rpms/
http://jenkins.ovirt.org/view/ovirt_engine_cli/job/ovirt_engine_cli_create_rpms/

Enjoy,

Eyal Edri
oVirt Infra Team


From cfergeau at redhat.com  Thu Mar 15 16:32:33 2012
From: cfergeau at redhat.com (Christophe Fergeau)
Date: Thu, 15 Mar 2012 17:32:33 +0100
Subject: [Engine-devel] [Spice-devel] Hints for building up a spicec
 connection in Ovirt
In-Reply-To: <CAP3iW_QYUmP2-s4U+yTQ7ER=w4iw-G25ahMi7-8spzhK2+KQ9A@mail.gmail.com>
References: <CAP3iW_RqD9XSCE=9hKY56UzxUdbahWPVsh8u9bESMWFek01y-Q@mail.gmail.com>
	<4F60BB06.7010806@redhat.com>
	<20120314164943.GJ4385@bogey.xentower.nl>
	<4F60CD01.8080303@redhat.com> <4F61931D.9090207@redhat.com>
	<CAP3iW_Si21TAL1PzsFYCb0E8T=s6jAj-hf-FqE0nx4j3pxjUXg@mail.gmail.com>
	<4F620598.8030107@redhat.com>
	<CAP3iW_TsyAGkCyDPJyC2B1vGgFXDf0h15ufFnkV8N07WUUcqkQ@mail.gmail.com>
	<CAP3iW_QYUmP2-s4U+yTQ7ER=w4iw-G25ahMi7-8spzhK2+KQ9A@mail.gmail.com>
Message-ID: <20120315163233.GU2726@teriyaki.redhat.com>

Hey,

On Thu, Mar 15, 2012 at 11:33:15AM -0400, Andrew Wells wrote:
> And is their any documentation on using the python rhev libraries as that
> would be helpful as well. you guys are getting me excited thinking this
> might work.

If that can be helpful to you, I've worked on some C code to talk to the
oVirt REST API to be able to list VMs and get the needed info to connect to
such a VM with SPICE. The code is unfinished, but listing VMs, starting VMs
and connecting to VM without TLS works, I can send you this code if that
can be of any use to you.

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120315/6afeea2a/attachment.sig>

From cfergeau at redhat.com  Thu Mar 15 17:11:55 2012
From: cfergeau at redhat.com (Christophe Fergeau)
Date: Thu, 15 Mar 2012 18:11:55 +0100
Subject: [Engine-devel] [Spice-devel] Hints for building up a spicec
 connection in Ovirt
In-Reply-To: <CAP3iW_SqqJWWLUBWZ2539SWrHcGn2BvVO+NKys=D=p_xudwt9w@mail.gmail.com>
References: <4F60BB06.7010806@redhat.com>
	<20120314164943.GJ4385@bogey.xentower.nl>
	<4F60CD01.8080303@redhat.com> <4F61931D.9090207@redhat.com>
	<CAP3iW_Si21TAL1PzsFYCb0E8T=s6jAj-hf-FqE0nx4j3pxjUXg@mail.gmail.com>
	<4F620598.8030107@redhat.com>
	<CAP3iW_TsyAGkCyDPJyC2B1vGgFXDf0h15ufFnkV8N07WUUcqkQ@mail.gmail.com>
	<CAP3iW_QYUmP2-s4U+yTQ7ER=w4iw-G25ahMi7-8spzhK2+KQ9A@mail.gmail.com>
	<20120315163233.GU2726@teriyaki.redhat.com>
	<CAP3iW_SqqJWWLUBWZ2539SWrHcGn2BvVO+NKys=D=p_xudwt9w@mail.gmail.com>
Message-ID: <20120315171155.GV2726@teriyaki.redhat.com>

On Thu, Mar 15, 2012 at 12:38:05PM -0400, Andrew Wells wrote:
> On Thu, Mar 15, 2012 at 12:32 PM, Christophe Fergeau <cfergeau at redhat.com>wrote:
> 
> > Hey,
> >
> > On Thu, Mar 15, 2012 at 11:33:15AM -0400, Andrew Wells wrote:
> > > And is their any documentation on using the python rhev libraries as that
> > > would be helpful as well. you guys are getting me excited thinking this
> > > might work.
> >
> > If that can be helpful to you, I've worked on some C code to talk to the
> > oVirt REST API to be able to list VMs and get the needed info to connect to
> > such a VM with SPICE. The code is unfinished, but listing VMs, starting VMs
> > and connecting to VM without TLS works, I can send you this code if that
> > can be of any use to you.

I quickly made a tarball
http://teuf.fedorapeople.org/libgovirt-0.0.1.tar.xz but it's probably far
too low level for your needs :) It needs librest from git.gnome.org too,
and you need to set your details in one of the C files. If all you want is
to get a ticket from ovirt and then start spicec using it, it's better to
use the previously mentioned python tool.

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120315/1f30e13e/attachment.sig>

From sanjal at redhat.com  Fri Mar 16 09:32:36 2012
From: sanjal at redhat.com (Shireesh Anjal)
Date: Fri, 16 Mar 2012 15:02:36 +0530
Subject: [Engine-devel] Gluster Support Feature
Message-ID: <4F6308B4.4090902@redhat.com>

Hi all,

Here is the feature page for Gluster Support in oVirt:
http://www.ovirt.org/wiki/Features/Gluster_Support

Comments / Suggestions welcome.

-- 
Thanks,
Shireesh



From tekka at normantec.it  Fri Mar 16 10:23:56 2012
From: tekka at normantec.it (Gianluca Cecchi)
Date: Fri, 16 Mar 2012 11:23:56 +0100
Subject: [Engine-devel] ovirt-shell problem on F16 and nightly builds
Message-ID: <CACK36mysKVf69g6a-xEiV+TSrNzChUxR2T4bA6H+P--fm+Qpgg@mail.gmail.com>

Hello,
sorry if this is a -devel mailing list. Let me know please if I have to
send to another list.

Would like to test ovirt-shell against an RH EV 3.0 installation.
My system is based on F16 x86_64.
Installed from nightly builds directory:

Mar 16 11:02:30 Installed: python-lxml-2.3-1.fc16.x86_64
Mar 16 11:02:30 Installed: ovirt-engine-sdk-1.6.1-1.fc16.noarch
Mar 16 11:02:30 Installed: pexpect-2.3-6.fc15.noarch
Mar 16 11:02:30 Installed: python-ply-3.3-5.fc15.noarch
Mar 16 11:02:30 Installed: ovirt-engine-cli-2.1.2-1.fc16.noarch

But

$ ovirt-shell --help
Traceback (most recent call last):
  File "/usr/bin/ovirt-shell", line 9, in <module>
    load_entry_point('ovirt-shell==2.1.2-SNAPSHOT', 'console_scripts',
'ovirt-shell')()
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 337, in
load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2279, in
load_entry_point
    return ep.load()
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 1989, in
load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "/usr/lib/python2.7/site-packages/ovirtcli/main.py", line 20, in
<module>
    from ovirtcli.context import OvirtCliExecutionContext
  File "/usr/lib/python2.7/site-packages/ovirtcli/context.py", line 18, in
<module>
    from cli.command import *
  File "/usr/lib/python2.7/site-packages/cli/command/__init__.py", line 2,
in <module>
    from cli.command.command import Command
  File "/usr/lib/python2.7/site-packages/cli/command/command.py", line 21,
in <module>
    from ovirtcli.utils.methodhelper import MethodHelper
  File "/usr/lib/python2.7/site-packages/ovirtcli/utils/methodhelper.py",
line 20, in <module>
    from codegen.doc.documentation import Documentation
ImportError: No module named codegen.doc.documentation

Probably it is something stupid I miss?
I installed them with
sudo yum localinstall ovirt-engine-cli-2.1.2-1.fc16.noarch.rpm
ovirt-engine-sdk-1.6.1-1.fc16.noarch.rpm

and got:
Loaded plugins: auto-update-debuginfo, downloadonly, langpacks, presto,
refresh-packagekit
Setting up Local Package Process
Examining ovirt-engine-cli-2.1.2-1.fc16.noarch.rpm:
ovirt-engine-cli-2.1.2-1.fc16.noarch
Marking ovirt-engine-cli-2.1.2-1.fc16.noarch.rpm to be installed
Examining ovirt-engine-sdk-1.6.1-1.fc16.noarch.rpm:
ovirt-engine-sdk-1.6.1-1.fc16.noarch
Marking ovirt-engine-sdk-1.6.1-1.fc16.noarch.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package ovirt-engine-cli.noarch 0:2.1.2-1.fc16 will be installed
--> Processing Dependency: pexpect for package:
ovirt-engine-cli-2.1.2-1.fc16.noarch
--> Processing Dependency: python-ply for package:
ovirt-engine-cli-2.1.2-1.fc16.noarch
---> Package ovirt-engine-sdk.noarch 0:1.6.1-1.fc16 will be installed
--> Processing Dependency: python-lxml for package:
ovirt-engine-sdk-1.6.1-1.fc16.noarch
--> Running transaction check
---> Package pexpect.noarch 0:2.3-6.fc15 will be installed
---> Package python-lxml.x86_64 0:2.3-1.fc16 will be installed
---> Package python-ply.noarch 0:3.3-5.fc15 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

possibly any dependency problem in rpm composition?
Thanks in advance,
Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120316/2ad5f758/attachment.html>

From iheim at redhat.com  Fri Mar 16 11:11:58 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 16 Mar 2012 13:11:58 +0200
Subject: [Engine-devel] ovirt-shell problem on F16 and nightly builds
In-Reply-To: <CACK36mysKVf69g6a-xEiV+TSrNzChUxR2T4bA6H+P--fm+Qpgg@mail.gmail.com>
References: <CACK36mysKVf69g6a-xEiV+TSrNzChUxR2T4bA6H+P--fm+Qpgg@mail.gmail.com>
Message-ID: <4F631FFE.1090508@redhat.com>

On 03/16/2012 12:23 PM, Gianluca Cecchi wrote:
> Hello,
> sorry if this is a -devel mailing list. Let me know please if I have to
> send to another list.

users mailing list probably more relevant.
any reason you are taking nightly, rather than published/tested versions 
(nightly builds is not necessarily tested/stable)
http://lists.ovirt.org/pipermail/users/2012-March/001158.html
http://lists.ovirt.org/pipermail/users/2012-March/001159.html

>
> Would like to test ovirt-shell against an RH EV 3.0 installation.
> My system is based on F16 x86_64.
> Installed from nightly builds directory:
>
> Mar 16 11:02:30 Installed: python-lxml-2.3-1.fc16.x86_64
> Mar 16 11:02:30 Installed: ovirt-engine-sdk-1.6.1-1.fc16.noarch
> Mar 16 11:02:30 Installed: pexpect-2.3-6.fc15.noarch
> Mar 16 11:02:30 Installed: python-ply-3.3-5.fc15.noarch
> Mar 16 11:02:30 Installed: ovirt-engine-cli-2.1.2-1.fc16.noarch
>
> But
>
> $ ovirt-shell --help
> Traceback (most recent call last):
>    File "/usr/bin/ovirt-shell", line 9, in <module>
>      load_entry_point('ovirt-shell==2.1.2-SNAPSHOT', 'console_scripts',
> 'ovirt-shell')()
>    File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 337,
> in load_entry_point
>      return get_distribution(dist).load_entry_point(group, name)
>    File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2279,
> in load_entry_point
>      return ep.load()
>    File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 1989,
> in load
>      entry = __import__(self.module_name, globals(),globals(), ['__name__'])
>    File "/usr/lib/python2.7/site-packages/ovirtcli/main.py", line 20, in
> <module>
>      from ovirtcli.context import OvirtCliExecutionContext
>    File "/usr/lib/python2.7/site-packages/ovirtcli/context.py", line 18,
> in <module>
>      from cli.command import *
>    File "/usr/lib/python2.7/site-packages/cli/command/__init__.py", line
> 2, in <module>
>      from cli.command.command import Command
>    File "/usr/lib/python2.7/site-packages/cli/command/command.py", line
> 21, in <module>
>      from ovirtcli.utils.methodhelper import MethodHelper
>    File
> "/usr/lib/python2.7/site-packages/ovirtcli/utils/methodhelper.py", line
> 20, in <module>
>      from codegen.doc.documentation import Documentation
> ImportError: No module named codegen.doc.documentation
>
> Probably it is something stupid I miss?
> I installed them with
> sudo yum localinstall ovirt-engine-cli-2.1.2-1.fc16.noarch.rpm
> ovirt-engine-sdk-1.6.1-1.fc16.noarch.rpm
>
> and got:
> Loaded plugins: auto-update-debuginfo, downloadonly, langpacks, presto,
> refresh-packagekit
> Setting up Local Package Process
> Examining ovirt-engine-cli-2.1.2-1.fc16.noarch.rpm:
> ovirt-engine-cli-2.1.2-1.fc16.noarch
> Marking ovirt-engine-cli-2.1.2-1.fc16.noarch.rpm to be installed
> Examining ovirt-engine-sdk-1.6.1-1.fc16.noarch.rpm:
> ovirt-engine-sdk-1.6.1-1.fc16.noarch
> Marking ovirt-engine-sdk-1.6.1-1.fc16.noarch.rpm to be installed
> Resolving Dependencies
> --> Running transaction check
> ---> Package ovirt-engine-cli.noarch 0:2.1.2-1.fc16 will be installed
> --> Processing Dependency: pexpect for package:
> ovirt-engine-cli-2.1.2-1.fc16.noarch
> --> Processing Dependency: python-ply for package:
> ovirt-engine-cli-2.1.2-1.fc16.noarch
> ---> Package ovirt-engine-sdk.noarch 0:1.6.1-1.fc16 will be installed
> --> Processing Dependency: python-lxml for package:
> ovirt-engine-sdk-1.6.1-1.fc16.noarch
> --> Running transaction check
> ---> Package pexpect.noarch 0:2.3-6.fc15 will be installed
> ---> Package python-lxml.x86_64 0:2.3-1.fc16 will be installed
> ---> Package python-ply.noarch 0:3.3-5.fc15 will be installed
> --> Finished Dependency Resolution
>
> Dependencies Resolved
>
> possibly any dependency problem in rpm composition?
> Thanks in advance,
> Gianluca
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From tekka at normantec.it  Fri Mar 16 11:39:40 2012
From: tekka at normantec.it (Gianluca Cecchi)
Date: Fri, 16 Mar 2012 12:39:40 +0100
Subject: [Engine-devel] ovirt-shell problem on F16 and nightly builds
In-Reply-To: <4F631FFE.1090508@redhat.com>
References: <CACK36mysKVf69g6a-xEiV+TSrNzChUxR2T4bA6H+P--fm+Qpgg@mail.gmail.com>
	<4F631FFE.1090508@redhat.com>
Message-ID: <CACK36mz6axSJSMbyw7W=1M-K2YXGxRvaBH4x9-hgeYhRAK+wrQ@mail.gmail.com>

2012/3/16 Itamar Heim

> On 03/16/2012 12:23 PM, Gianluca Cecchi wrote:
>
>> Hello,
>> sorry if this is a -devel mailing list. Let me know please if I have to
>> send to another list.
>>
>
> users mailing list probably more relevant.
> any reason you are taking nightly, rather than published/tested versions
> (nightly builds is not necessarily tested/stable)
> http://lists.ovirt.org/pipermail/users/2012-Ma<http://lists.ovirt.org/pipermail/users/2012-March/001158.html>
> rch/001158.html<http://lists.ovirt.org/pipermail/users/2012-March/001158.html>
> http://lists.ovirt.org/pipermail/users/2012-March/001159.html


I didn't find link to user mailing list at ovirt.org web site... now with
your pointer I will do...
Take into account that the links inside the users ml threads for both src
and rpm packages point to nightly build... ;-)
Probably not so stable yet and suggested way is to use nughtly build?
At first stage I searched inside the stable tree but I didn't find them...

Thanks anyway,
Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120316/2ae8c469/attachment.html>

From acathrow at redhat.com  Fri Mar 16 11:48:35 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Fri, 16 Mar 2012 07:48:35 -0400 (EDT)
Subject: [Engine-devel] ovirt-shell problem on F16 and nightly builds
In-Reply-To: <4F631FFE.1090508@redhat.com>
Message-ID: <119faa5c-30aa-49bb-908c-d9b447ae750f@zmail07.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Gianluca Cecchi" <tekka at normantec.it>
> Cc: engine-devel at ovirt.org
> Sent: Friday, March 16, 2012 7:11:58 AM
> Subject: Re: [Engine-devel] ovirt-shell problem on F16 and nightly builds
> 
> On 03/16/2012 12:23 PM, Gianluca Cecchi wrote:
> > Hello,
> > sorry if this is a -devel mailing list. Let me know please if I
> > have to
> > send to another list.
> 
> users mailing list probably more relevant.
> any reason you are taking nightly, rather than published/tested
> versions
> (nightly builds is not necessarily tested/stable)
> http://lists.ovirt.org/pipermail/users/2012-March/001158.html
> http://lists.ovirt.org/pipermail/users/2012-March/001159.html

ovirt-cli/shell isn't in the stable build repo yet, it's only in the nightlies (which are linked in those emails)

> 
> >
> > Would like to test ovirt-shell against an RH EV 3.0 installation.
> > My system is based on F16 x86_64.
> > Installed from nightly builds directory:
> >
> > Mar 16 11:02:30 Installed: python-lxml-2.3-1.fc16.x86_64
> > Mar 16 11:02:30 Installed: ovirt-engine-sdk-1.6.1-1.fc16.noarch
> > Mar 16 11:02:30 Installed: pexpect-2.3-6.fc15.noarch
> > Mar 16 11:02:30 Installed: python-ply-3.3-5.fc15.noarch
> > Mar 16 11:02:30 Installed: ovirt-engine-cli-2.1.2-1.fc16.noarch
> >
> > But
> >
> > $ ovirt-shell --help
> > Traceback (most recent call last):
> >    File "/usr/bin/ovirt-shell", line 9, in <module>
> >      load_entry_point('ovirt-shell==2.1.2-SNAPSHOT',
> >      'console_scripts',
> > 'ovirt-shell')()
> >    File "/usr/lib/python2.7/site-packages/pkg_resources.py", line
> >    337,
> > in load_entry_point
> >      return get_distribution(dist).load_entry_point(group, name)
> >    File "/usr/lib/python2.7/site-packages/pkg_resources.py", line
> >    2279,
> > in load_entry_point
> >      return ep.load()
> >    File "/usr/lib/python2.7/site-packages/pkg_resources.py", line
> >    1989,
> > in load
> >      entry = __import__(self.module_name, globals(),globals(),
> >      ['__name__'])
> >    File "/usr/lib/python2.7/site-packages/ovirtcli/main.py", line
> >    20, in
> > <module>
> >      from ovirtcli.context import OvirtCliExecutionContext
> >    File "/usr/lib/python2.7/site-packages/ovirtcli/context.py",
> >    line 18,
> > in <module>
> >      from cli.command import *
> >    File "/usr/lib/python2.7/site-packages/cli/command/__init__.py",
> >    line
> > 2, in <module>
> >      from cli.command.command import Command
> >    File "/usr/lib/python2.7/site-packages/cli/command/command.py",
> >    line
> > 21, in <module>
> >      from ovirtcli.utils.methodhelper import MethodHelper
> >    File
> > "/usr/lib/python2.7/site-packages/ovirtcli/utils/methodhelper.py",
> > line
> > 20, in <module>
> >      from codegen.doc.documentation import Documentation
> > ImportError: No module named codegen.doc.documentation
> >
> > Probably it is something stupid I miss?
> > I installed them with
> > sudo yum localinstall ovirt-engine-cli-2.1.2-1.fc16.noarch.rpm
> > ovirt-engine-sdk-1.6.1-1.fc16.noarch.rpm
> >
> > and got:
> > Loaded plugins: auto-update-debuginfo, downloadonly, langpacks,
> > presto,
> > refresh-packagekit
> > Setting up Local Package Process
> > Examining ovirt-engine-cli-2.1.2-1.fc16.noarch.rpm:
> > ovirt-engine-cli-2.1.2-1.fc16.noarch
> > Marking ovirt-engine-cli-2.1.2-1.fc16.noarch.rpm to be installed
> > Examining ovirt-engine-sdk-1.6.1-1.fc16.noarch.rpm:
> > ovirt-engine-sdk-1.6.1-1.fc16.noarch
> > Marking ovirt-engine-sdk-1.6.1-1.fc16.noarch.rpm to be installed
> > Resolving Dependencies
> > --> Running transaction check
> > ---> Package ovirt-engine-cli.noarch 0:2.1.2-1.fc16 will be
> > installed
> > --> Processing Dependency: pexpect for package:
> > ovirt-engine-cli-2.1.2-1.fc16.noarch
> > --> Processing Dependency: python-ply for package:
> > ovirt-engine-cli-2.1.2-1.fc16.noarch
> > ---> Package ovirt-engine-sdk.noarch 0:1.6.1-1.fc16 will be
> > installed
> > --> Processing Dependency: python-lxml for package:
> > ovirt-engine-sdk-1.6.1-1.fc16.noarch
> > --> Running transaction check
> > ---> Package pexpect.noarch 0:2.3-6.fc15 will be installed
> > ---> Package python-lxml.x86_64 0:2.3-1.fc16 will be installed
> > ---> Package python-ply.noarch 0:3.3-5.fc15 will be installed
> > --> Finished Dependency Resolution
> >
> > Dependencies Resolved
> >
> > possibly any dependency problem in rpm composition?
> > Thanks in advance,
> > Gianluca
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From tekka at normantec.it  Fri Mar 16 12:00:12 2012
From: tekka at normantec.it (Gianluca Cecchi)
Date: Fri, 16 Mar 2012 13:00:12 +0100
Subject: [Engine-devel] ovirt-shell problem on F16 and nightly builds
In-Reply-To: <119faa5c-30aa-49bb-908c-d9b447ae750f@zmail07.collab.prod.int.phx2.redhat.com>
References: <4F631FFE.1090508@redhat.com>
	<119faa5c-30aa-49bb-908c-d9b447ae750f@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <CACK36my1F4buZ3zhMUU1mQ2_04pHSwvqYNhqjvd6cbe1JrKVRw@mail.gmail.com>

2012/3/16 Andrew Cathrow :
> ovirt-cli/shell isn't in the stable build repo yet, it's only in the nightlies (which are linked in those emails)

It seems solved with the rpms packaged as in

http://lists.ovirt.org/pipermail/users/2012-March/001176.html

ovirt-engine-cli-2.1.3-1.fc16.noarch.rpm
ovirt-engine-sdk-1.6.2-1.fc16.noarch.rpm

at least with the basic run of
$ ovirt-shell --help
and
$ ovirt-shell



 ++++++++++++++++++++++++++++++++++++++++++

           Welcome to oVirt shell

 ++++++++++++++++++++++++++++++++++++++++++


[oVirt shell (disconnected)]# exit

I'm going to test further wit connection to RHEV infra.

Gianluca


From mburns at redhat.com  Fri Mar 16 14:45:20 2012
From: mburns at redhat.com (Mike Burns)
Date: Fri, 16 Mar 2012 10:45:20 -0400
Subject: [Engine-devel] [Jenkins] Auto Generated ovirt-engine rpms for
	fedora 16
In-Reply-To: <9d4bd2c8-7ae1-4ca0-a384-a1276e97a8d5@zmail17.collab.prod.int.phx2.redhat.com>
References: <9d4bd2c8-7ae1-4ca0-a384-a1276e97a8d5@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <1331909120.14799.141.camel@beelzebub.mburnsfire.net>

On Thu, 2012-03-15 at 03:24 -0400, Eyal Edri wrote:
> already exists :)
> 
> http://jenkins.ovirt.org/view/vdsm/job/vdsm_create_rpms/

I was looking at this and noticed that it picked up ovirt-node-iso rpms
in the build artifacts as well.  When I looked into why, I found that
it's building the rpms in ~jenkins/rpmbuild.  This can be easily changed
by exporting the HOME variable.  I'll make the changes if people ACK,
but otherwise I won't since I'm not the vdsm maintainer.

Mike

Diff:  

-#git clone git://gerrit.ovirt.org/vdsm vdsm-git
-
 #create VDSM rpms
-cd vdsm-git
+export HOME=${WORKSPACE}
 make clean
 ./autogen.sh --system
 ./configure
 make rpm 

-cd $WORKSPACE
-rm -rf rpmbuild
-mv ~/rpmbuild .

> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Eyal Edri" <eedri at redhat.com>
> > Cc: engine-users at ovirt.org, engine-devel at ovirt.org, infra at ovirt.org
> > Sent: Wednesday, March 14, 2012 11:30:40 PM
> > Subject: Re: [Jenkins] Auto Generated ovirt-engine rpms for fedora 16
> > 
> > Cool!
> > 
> > Any chance to have the same with vdsm rpm's?
> > 
> > On 14/03/12 22:45, Eyal Edri wrote:
> > > fyi,
> > > 
> > > a new Jenkins job has been added to jenkins.ovirt.org.
> > > 
> > > you can now d/l fresh ovirt-engine rpms after each commit.
> > > 
> > > the rpms are created and latest are stored here:
> > > 
> > > http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/
> > > 
> > > the job will also notify the author in case his/her commit will
> > > break the rpm build.
> > > 
> > > latest rpms for now:
> > > 
> > > ovirt-engine-3.1.0_0001-1.8.fc16.src.rpm
> > > ovirt-engine-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-debuginfo-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > 
> > > Enjoy,
> > > Eyal Edri
> > > oVirt Infra Team
> > > 
> > > _______________________________________________
> > > Infra mailing list
> > > Infra at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> > 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra




From eedri at redhat.com  Fri Mar 16 16:58:51 2012
From: eedri at redhat.com (Eyal Edri)
Date: Fri, 16 Mar 2012 12:58:51 -0400 (EDT)
Subject: [Engine-devel] [Jenkins] Auto Generated ovirt-engine rpms for
	fedora 16
In-Reply-To: <1331909120.14799.141.camel@beelzebub.mburnsfire.net>
Message-ID: <4892500a-97fb-4a15-9f99-645bcc971f7a@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Mike Burns" <mburns at redhat.com>
> To: "Eyal Edri" <eedri at redhat.com>
> Cc: "Doron Fediuck" <dfediuck at redhat.com>, engine-devel at ovirt.org, engine-users at ovirt.org, infra at ovirt.org
> Sent: Friday, March 16, 2012 4:45:20 PM
> Subject: Re: [Jenkins] Auto Generated ovirt-engine rpms for fedora 16
> 
> On Thu, 2012-03-15 at 03:24 -0400, Eyal Edri wrote:
> > already exists :)
> > 
> > http://jenkins.ovirt.org/view/vdsm/job/vdsm_create_rpms/
> 
> I was looking at this and noticed that it picked up ovirt-node-iso
> rpms
> in the build artifacts as well.  When I looked into why, I found that
> it's building the rpms in ~jenkins/rpmbuild.  This can be easily
> changed
> by exporting the HOME variable.  I'll make the changes if people ACK,
> but otherwise I won't since I'm not the vdsm maintainer.
> 

Mike,
i created that job, so if it's changes in the job configuration you can go  a head and make the change.

Eyal.

> Mike
> 
> Diff:
> 
> -#git clone git://gerrit.ovirt.org/vdsm vdsm-git
> -
>  #create VDSM rpms
> -cd vdsm-git
> +export HOME=${WORKSPACE}
>  make clean
>  ./autogen.sh --system
>  ./configure
>  make rpm
> 
> -cd $WORKSPACE
> -rm -rf rpmbuild
> -mv ~/rpmbuild .
> 
> > 
> > ----- Original Message -----
> > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > To: "Eyal Edri" <eedri at redhat.com>
> > > Cc: engine-users at ovirt.org, engine-devel at ovirt.org,
> > > infra at ovirt.org
> > > Sent: Wednesday, March 14, 2012 11:30:40 PM
> > > Subject: Re: [Jenkins] Auto Generated ovirt-engine rpms for
> > > fedora 16
> > > 
> > > Cool!
> > > 
> > > Any chance to have the same with vdsm rpm's?
> > > 
> > > On 14/03/12 22:45, Eyal Edri wrote:
> > > > fyi,
> > > > 
> > > > a new Jenkins job has been added to jenkins.ovirt.org.
> > > > 
> > > > you can now d/l fresh ovirt-engine rpms after each commit.
> > > > 
> > > > the rpms are created and latest are stored here:
> > > > 
> > > > http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/
> > > > 
> > > > the job will also notify the author in case his/her commit will
> > > > break the rpm build.
> > > > 
> > > > latest rpms for now:
> > > > 
> > > > ovirt-engine-3.1.0_0001-1.8.fc16.src.rpm
> > > > ovirt-engine-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-debuginfo-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > 
> > > > Enjoy,
> > > > Eyal Edri
> > > > oVirt Infra Team
> > > > 
> > > > _______________________________________________
> > > > Infra mailing list
> > > > Infra at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/infra
> > > 
> > > 
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> 
> 
> 


From mburns at redhat.com  Fri Mar 16 20:12:48 2012
From: mburns at redhat.com (Mike Burns)
Date: Fri, 16 Mar 2012 16:12:48 -0400
Subject: [Engine-devel] [Jenkins] Auto Generated ovirt-engine rpms for
	fedora 16
In-Reply-To: <4892500a-97fb-4a15-9f99-645bcc971f7a@zmail17.collab.prod.int.phx2.redhat.com>
References: <4892500a-97fb-4a15-9f99-645bcc971f7a@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <1331928768.2559.12.camel@beelzebub.mburnsfire.net>

On Fri, 2012-03-16 at 12:58 -0400, Eyal Edri wrote:
> 
> ----- Original Message -----
> > From: "Mike Burns" <mburns at redhat.com>
> > To: "Eyal Edri" <eedri at redhat.com>
> > Cc: "Doron Fediuck" <dfediuck at redhat.com>, engine-devel at ovirt.org, engine-users at ovirt.org, infra at ovirt.org
> > Sent: Friday, March 16, 2012 4:45:20 PM
> > Subject: Re: [Jenkins] Auto Generated ovirt-engine rpms for fedora 16
> > 
> > On Thu, 2012-03-15 at 03:24 -0400, Eyal Edri wrote:
> > > already exists :)
> > > 
> > > http://jenkins.ovirt.org/view/vdsm/job/vdsm_create_rpms/
> > 
> > I was looking at this and noticed that it picked up ovirt-node-iso
> > rpms
> > in the build artifacts as well.  When I looked into why, I found that
> > it's building the rpms in ~jenkins/rpmbuild.  This can be easily
> > changed
> > by exporting the HOME variable.  I'll make the changes if people ACK,
> > but otherwise I won't since I'm not the vdsm maintainer.
> > 
> 
> Mike,
> i created that job, so if it's changes in the job configuration you can go  a head and make the change.
> 
> Eyal.

Done, though it took a bit more than it should have.  jenkins really
messes things up when you try to run git describe...

It should work now though.

Mike

> 
> > Mike
> > 
> > Diff:
> > 
> > -#git clone git://gerrit.ovirt.org/vdsm vdsm-git
> > -
> >  #create VDSM rpms
> > -cd vdsm-git
> > +export HOME=${WORKSPACE}
> >  make clean
> >  ./autogen.sh --system
> >  ./configure
> >  make rpm
> > 
> > -cd $WORKSPACE
> > -rm -rf rpmbuild
> > -mv ~/rpmbuild .
> > 
> > > 
> > > ----- Original Message -----
> > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > To: "Eyal Edri" <eedri at redhat.com>
> > > > Cc: engine-users at ovirt.org, engine-devel at ovirt.org,
> > > > infra at ovirt.org
> > > > Sent: Wednesday, March 14, 2012 11:30:40 PM
> > > > Subject: Re: [Jenkins] Auto Generated ovirt-engine rpms for
> > > > fedora 16
> > > > 
> > > > Cool!
> > > > 
> > > > Any chance to have the same with vdsm rpm's?
> > > > 
> > > > On 14/03/12 22:45, Eyal Edri wrote:
> > > > > fyi,
> > > > > 
> > > > > a new Jenkins job has been added to jenkins.ovirt.org.
> > > > > 
> > > > > you can now d/l fresh ovirt-engine rpms after each commit.
> > > > > 
> > > > > the rpms are created and latest are stored here:
> > > > > 
> > > > > http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/
> > > > > 
> > > > > the job will also notify the author in case his/her commit will
> > > > > break the rpm build.
> > > > > 
> > > > > latest rpms for now:
> > > > > 
> > > > > ovirt-engine-3.1.0_0001-1.8.fc16.src.rpm
> > > > > ovirt-engine-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-debuginfo-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64.rpm
> > > > > 
> > > > > Enjoy,
> > > > > Eyal Edri
> > > > > oVirt Infra Team
> > > > > 
> > > > > _______________________________________________
> > > > > Infra mailing list
> > > > > Infra at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/infra
> > > > 
> > > > 
> > > _______________________________________________
> > > Infra mailing list
> > > Infra at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> > 
> > 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra




From mpastern at redhat.com  Sun Mar 18 07:33:23 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 18 Mar 2012 09:33:23 +0200
Subject: [Engine-devel] Bridgeless Networks api design
In-Reply-To: <4F61F5A3.90706@redhat.com>
References: <4F61CA17.6080203@redhat.com> <4F61F5A3.90706@redhat.com>
Message-ID: <4F658FC3.6030403@redhat.com>

On 03/15/2012 03:58 PM, Itamar Heim wrote:
> On 03/15/2012 12:53 PM, Michael Pasternak wrote:
>>
>> Hi,
>>
>> First of all i would like to understand the exact meaning of the vm_network,
>> from the wiki [1] - "a "Vm network" is implemented over a bridge, otherwise bridgeless",
>>
>> if so, why not calling network property<bridged>true|false</bridged>?
> 
> bridge vs. bridgeless is an implementation detail. some network models could run without a bridge as well for VMs (though not currently supported).
> so the optimization is to not use a bridge for networks that can't run VMs, but the reverse logic does not apply.
> 
>>
>> from the other hand i understand that this is only current implementation and it
>> may change in a future,
>>
>> anyway adding<vm_network>true|false</vm_network>  property to<network>  entity in api
>> (as was suggested) doesn't sound good cause vm_network sounds as a network type, but then
>> the question is Management/Migration/Storage/Display should be also network's types? and if single
>> network can be used for the Management|Migration|Storage|Display simultaneously? if the answer is
>> yes, network modelling probably should look like:
>>
>> <network>
>>    <bridged>true|false</bridged>
>>    <type>Management/Migration/Storage/Display</type>
>> </network>
>>
>> or
>>
>> <network>
>>    <bridged>true|false</bridged>
>>    <designation>Management|Migration|Storage|Display</designation>
>> </network>
> 
> that bridged should be replaced with something saying VM_Network (better name needed).

the question is Management/Migration/Storage/Display can be non-bridged?, if so,
<bridged>true|false</bridged> makes sense.

> btw, I wonder if a private network (only for one vm) is also a type, or just a private case of a vm network.

<private>true</private> by itself doesn't provide much info and to complete the picture will require

<network>
  <private>true</private>
  <designation>VM</designation>
  <vm id=xxx>
</network>

having only <designation>VM</designation> also not enough cause it may sound
that this network will be used only for vms and not a single vm.

> 
> and that type/designation can have more than one of course.
> (and that migration/storage networks are still not supported).

i know, looking forward to take in account all future features.

> 
>>
>> your thoughts?
>>
>> [1] http://www.ovirt.org/wiki/Features/Design/Network/Bridgeless_Networks
>>
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From iheim at redhat.com  Sun Mar 18 08:21:23 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 18 Mar 2012 10:21:23 +0200
Subject: [Engine-devel] Bridgeless Networks api design
In-Reply-To: <4F658FC3.6030403@redhat.com>
References: <4F61CA17.6080203@redhat.com> <4F61F5A3.90706@redhat.com>
	<4F658FC3.6030403@redhat.com>
Message-ID: <4F659B03.2030502@redhat.com>

On 03/18/2012 09:33 AM, Michael Pasternak wrote:
> the question is Management/Migration/Storage/Display can be non-bridged?, if so,
> <bridged>true|false</bridged>  makes sense.

bridge is an implementation detail at host level, hence the discussion 
is about abstracting it from users.
a VM network doesn't have to have bridge at host level, for networks 
using VMFex or SR-IOV


From mpastern at redhat.com  Sun Mar 18 08:43:29 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 18 Mar 2012 10:43:29 +0200
Subject: [Engine-devel] Bridgeless Networks api design
In-Reply-To: <4F659B03.2030502@redhat.com>
References: <4F61CA17.6080203@redhat.com> <4F61F5A3.90706@redhat.com>
	<4F658FC3.6030403@redhat.com> <4F659B03.2030502@redhat.com>
Message-ID: <4F65A031.8080002@redhat.com>

On 03/18/2012 10:21 AM, Itamar Heim wrote:
> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
>> the question is Management/Migration/Storage/Display can be non-bridged?, if so,
>> <bridged>true|false</bridged>  makes sense.
> 
> bridge is an implementation detail at host level, hence the discussion is about abstracting it from users.
> a VM network doesn't have to have bridge at host level, for networks using VMFex or SR-IOV

<network>
  <designation>Management|Migration|Storage|Display|VM</designation>
</network>

what do you say about having it as another /designation/ type?

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Sun Mar 18 08:52:51 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 18 Mar 2012 10:52:51 +0200
Subject: [Engine-devel] Bridgeless Networks api design
In-Reply-To: <4F659F54.5000300@redhat.com>
References: <4F61CA17.6080203@redhat.com> <4F61F5A3.90706@redhat.com>
	<4F658FC3.6030403@redhat.com> <4F659B03.2030502@redhat.com>
	<4F65A031.8080002@redhat.com> <4F659F54.5000300@redhat.com>
Message-ID: <4F65A263.7070504@redhat.com>

On 03/18/2012 10:39 AM, Itamar Heim wrote:
> On 03/18/2012 10:43 AM, Michael Pasternak wrote:
>> On 03/18/2012 10:21 AM, Itamar Heim wrote:
>>> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
>>>> the question is Management/Migration/Storage/Display can be non-bridged?, if so,
>>>> <bridged>true|false</bridged>   makes sense.
>>>
>>> bridge is an implementation detail at host level, hence the discussion is about abstracting it from users.
>>> a VM network doesn't have to have bridge at host level, for networks using VMFex or SR-IOV
>>
>> <network>
>>    <designation>Management|Migration|Storage|Display|VM</designation>
>> </network>
>>
>> what do you say about having it as another /designation/ type?
>>
> 
> it==VM?
> the above looks ok to me.
> (I really hope for a better element name than designation though)

I'd avoid using /type/ as type usually applies on single variant,
/assignment/ maybe? nothing batter comes to my mind

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Sun Mar 18 09:14:48 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 18 Mar 2012 11:14:48 +0200
Subject: [Engine-devel] ovirt-shell problem on F16 and nightly builds
In-Reply-To: <CACK36mysKVf69g6a-xEiV+TSrNzChUxR2T4bA6H+P--fm+Qpgg@mail.gmail.com>
References: <CACK36mysKVf69g6a-xEiV+TSrNzChUxR2T4bA6H+P--fm+Qpgg@mail.gmail.com>
Message-ID: <4F65A788.5080909@redhat.com>


this is known issue, new rpms/tarballs will be available in release repo today,
also you can get them from http://lists.ovirt.org/pipermail/users/2012-March/001176.html

thanks.

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From ovedo at redhat.com  Sun Mar 18 09:09:54 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 18 Mar 2012 05:09:54 -0400 (EDT)
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <4F620EBF.2040704@redhat.com>
Message-ID: <4f21ed43-b988-4a55-bf44-0a3a91196c7d@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, March 15, 2012 5:46:07 PM
> Subject: Re: [Engine-devel] Disk Permissions Feature
> 
> On 03/15/2012 05:34 PM, Omer Frenkel wrote:
> >>> >  >  1. "Create disk - requires permissions on the Storage
> >>> >  >  Domain,
> >>> >  >  (can't
> >>> >  >  assume Quota is sufficient to permit user creating the disk
> >>> >  >  on the
> >>> >  >  Storage Domain, as Quota might be disabled)"
> >>> >  >
> >>> >  >  I'd also specify create disk for regular disks is at
> >>> >  >  storage domain
> >>> >  >  level?, while direct lun disks require system level
> >>> >  >  permission of
> >>> >  >  add disk.
> >>> >  >
> >>> >  >  so, if quota is disabled, how important is it to prevent
> >>> >  >  creation
> >>> >  >  of
> >>> >  >  disks (other than direct lun ones, which would require a
> >>> >  >  permission
> >>> >  >  similar to storage domain creation)?
> >>> >  >
> >>> >  >  if this is added, it has to be implicitly added / not
> >>> >  >  needed if
> >>> >  >  user has
> >>> >  >  quota (i.e., having a quota should be similar to having a
> >>> >  >  permission as
> >>> >  >  far as the check goes).
> >>> >  >
> >> >
> >> >  We should look into it, how complicate is it to validate if
> >> >  user has
> >> >  either quota or permission, and allow creating a disk on a SD
> >> >  if
> >> >  either
> >> >  exists.
> > this might be confusing to the user as he can disable the quota,
> > then stuff would stop working.
> >
> 
> we can't require both quota and permissions from user on storage
> domains
> - that's cumbersome.
> question is if we can limit the need for permissions to disks only to
> places where they are needed (shared, direct, floating)?
+1 on that.
I also think it is only relevant on attaching a disk to a VM, as the other use-cases are simpler:
1. Attach disk to VM - would require having permissions on the disk (whether it is shared, direct lun or floating)
2. Add disk to VM - would only require quota (if enforced).
3. Create disk (i.e., floating/shared disk) - would only require quota (if enforced).

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


From iheim at redhat.com  Sun Mar 18 08:39:48 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 18 Mar 2012 10:39:48 +0200
Subject: [Engine-devel] Bridgeless Networks api design
In-Reply-To: <4F65A031.8080002@redhat.com>
References: <4F61CA17.6080203@redhat.com> <4F61F5A3.90706@redhat.com>
	<4F658FC3.6030403@redhat.com> <4F659B03.2030502@redhat.com>
	<4F65A031.8080002@redhat.com>
Message-ID: <4F659F54.5000300@redhat.com>

On 03/18/2012 10:43 AM, Michael Pasternak wrote:
> On 03/18/2012 10:21 AM, Itamar Heim wrote:
>> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
>>> the question is Management/Migration/Storage/Display can be non-bridged?, if so,
>>> <bridged>true|false</bridged>   makes sense.
>>
>> bridge is an implementation detail at host level, hence the discussion is about abstracting it from users.
>> a VM network doesn't have to have bridge at host level, for networks using VMFex or SR-IOV
>
> <network>
>    <designation>Management|Migration|Storage|Display|VM</designation>
> </network>
>
> what do you say about having it as another /designation/ type?
>

it==VM?
the above looks ok to me.
(I really hope for a better element name than designation though)


From ofrenkel at redhat.com  Sun Mar 18 09:27:33 2012
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Sun, 18 Mar 2012 05:27:33 -0400 (EDT)
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <4f21ed43-b988-4a55-bf44-0a3a91196c7d@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <fc9108f8-1f4d-47ce-937f-2b61af9c4b3f@ofrenkel.csb>



----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: engine-devel at ovirt.org, "Omer Frenkel" <ofrenkel at redhat.com>
> Sent: Sunday, March 18, 2012 11:09:54 AM
> Subject: Re: [Engine-devel] Disk Permissions Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Omer Frenkel" <ofrenkel at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Thursday, March 15, 2012 5:46:07 PM
> > Subject: Re: [Engine-devel] Disk Permissions Feature
> > 
> > On 03/15/2012 05:34 PM, Omer Frenkel wrote:
> > >>> >  >  1. "Create disk - requires permissions on the Storage
> > >>> >  >  Domain,
> > >>> >  >  (can't
> > >>> >  >  assume Quota is sufficient to permit user creating the
> > >>> >  >  disk
> > >>> >  >  on the
> > >>> >  >  Storage Domain, as Quota might be disabled)"
> > >>> >  >
> > >>> >  >  I'd also specify create disk for regular disks is at
> > >>> >  >  storage domain
> > >>> >  >  level?, while direct lun disks require system level
> > >>> >  >  permission of
> > >>> >  >  add disk.
> > >>> >  >
> > >>> >  >  so, if quota is disabled, how important is it to prevent
> > >>> >  >  creation
> > >>> >  >  of
> > >>> >  >  disks (other than direct lun ones, which would require a
> > >>> >  >  permission
> > >>> >  >  similar to storage domain creation)?
> > >>> >  >
> > >>> >  >  if this is added, it has to be implicitly added / not
> > >>> >  >  needed if
> > >>> >  >  user has
> > >>> >  >  quota (i.e., having a quota should be similar to having a
> > >>> >  >  permission as
> > >>> >  >  far as the check goes).
> > >>> >  >
> > >> >
> > >> >  We should look into it, how complicate is it to validate if
> > >> >  user has
> > >> >  either quota or permission, and allow creating a disk on a SD
> > >> >  if
> > >> >  either
> > >> >  exists.
> > > this might be confusing to the user as he can disable the quota,
> > > then stuff would stop working.
> > >
> > 
> > we can't require both quota and permissions from user on storage
> > domains
> > - that's cumbersome.
> > question is if we can limit the need for permissions to disks only
> > to
> > places where they are needed (shared, direct, floating)?
> +1 on that.
> I also think it is only relevant on attaching a disk to a VM, as the
> other use-cases are simpler:
> 1. Attach disk to VM - would require having permissions on the disk
> (whether it is shared, direct lun or floating)
> 2. Add disk to VM - would only require quota (if enforced).
> 3. Create disk (i.e., floating/shared disk) - would only require
> quota (if enforced).

and if not enforced? anyone can create as much disks as he like?
we thought of requiring permissions if quota is disabled,
but i think its confusing to the user as he plays with 
> 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From ykaul at redhat.com  Sun Mar 18 09:27:38 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Sun, 18 Mar 2012 11:27:38 +0200
Subject: [Engine-devel] Bridgeless Networks api design
In-Reply-To: <4F65A031.8080002@redhat.com>
References: <4F61CA17.6080203@redhat.com> <4F61F5A3.90706@redhat.com>
	<4F658FC3.6030403@redhat.com> <4F659B03.2030502@redhat.com>
	<4F65A031.8080002@redhat.com>
Message-ID: <4F65AA8A.6020009@redhat.com>

On 03/18/2012 10:43 AM, Michael Pasternak wrote:
> On 03/18/2012 10:21 AM, Itamar Heim wrote:
>> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
>>> the question is Management/Migration/Storage/Display can be non-bridged?, if so,
>>> <bridged>true|false</bridged>   makes sense.
>> bridge is an implementation detail at host level, hence the discussion is about abstracting it from users.
>> a VM network doesn't have to have bridge at host level, for networks using VMFex or SR-IOV
> <network>
>    <designation>Management|Migration|Storage|Display|VM</designation>
> </network>
>
> what do you say about having it as another /designation/ type?
>

Not sure I understand: Management can be bridge-less, Migration can be 
bridge-less, Storage can be bridge-less, Display can be bridge-less, VM 
is the only that perhaps today cannot be bridge-less, so I do think that 
'<bridged>true|false</bridged>' makes some sense. However, I'd 
generalize it to 'attachment' as I believe we'll have other types in the 
future (Macvtap, SRIOV and friends), so something like 
<attachment>bridge|sriov|macvtap|...</attachment>
Y.



From ovedo at redhat.com  Sun Mar 18 09:52:33 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 18 Mar 2012 05:52:33 -0400 (EDT)
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <fc9108f8-1f4d-47ce-937f-2b61af9c4b3f@ofrenkel.csb>
Message-ID: <24d4e819-da82-405e-a0f7-df11e202faa3@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Sunday, March 18, 2012 11:27:33 AM
> Subject: Re: [Engine-devel] Disk Permissions Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Oved Ourfalli" <ovedo at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: engine-devel at ovirt.org, "Omer Frenkel" <ofrenkel at redhat.com>
> > Sent: Sunday, March 18, 2012 11:09:54 AM
> > Subject: Re: [Engine-devel] Disk Permissions Feature
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Itamar Heim" <iheim at redhat.com>
> > > To: "Omer Frenkel" <ofrenkel at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Thursday, March 15, 2012 5:46:07 PM
> > > Subject: Re: [Engine-devel] Disk Permissions Feature
> > > 
> > > On 03/15/2012 05:34 PM, Omer Frenkel wrote:
> > > >>> >  >  1. "Create disk - requires permissions on the Storage
> > > >>> >  >  Domain,
> > > >>> >  >  (can't
> > > >>> >  >  assume Quota is sufficient to permit user creating the
> > > >>> >  >  disk
> > > >>> >  >  on the
> > > >>> >  >  Storage Domain, as Quota might be disabled)"
> > > >>> >  >
> > > >>> >  >  I'd also specify create disk for regular disks is at
> > > >>> >  >  storage domain
> > > >>> >  >  level?, while direct lun disks require system level
> > > >>> >  >  permission of
> > > >>> >  >  add disk.
> > > >>> >  >
> > > >>> >  >  so, if quota is disabled, how important is it to
> > > >>> >  >  prevent
> > > >>> >  >  creation
> > > >>> >  >  of
> > > >>> >  >  disks (other than direct lun ones, which would require
> > > >>> >  >  a
> > > >>> >  >  permission
> > > >>> >  >  similar to storage domain creation)?
> > > >>> >  >
> > > >>> >  >  if this is added, it has to be implicitly added / not
> > > >>> >  >  needed if
> > > >>> >  >  user has
> > > >>> >  >  quota (i.e., having a quota should be similar to having
> > > >>> >  >  a
> > > >>> >  >  permission as
> > > >>> >  >  far as the check goes).
> > > >>> >  >
> > > >> >
> > > >> >  We should look into it, how complicate is it to validate if
> > > >> >  user has
> > > >> >  either quota or permission, and allow creating a disk on a
> > > >> >  SD
> > > >> >  if
> > > >> >  either
> > > >> >  exists.
> > > > this might be confusing to the user as he can disable the
> > > > quota,
> > > > then stuff would stop working.
> > > >
> > > 
> > > we can't require both quota and permissions from user on storage
> > > domains
> > > - that's cumbersome.
> > > question is if we can limit the need for permissions to disks
> > > only
> > > to
> > > places where they are needed (shared, direct, floating)?
> > +1 on that.
> > I also think it is only relevant on attaching a disk to a VM, as
> > the
> > other use-cases are simpler:
> > 1. Attach disk to VM - would require having permissions on the disk
> > (whether it is shared, direct lun or floating)
> > 2. Add disk to VM - would only require quota (if enforced).
> > 3. Create disk (i.e., floating/shared disk) - would only require
> > quota (if enforced).
> 
> and if not enforced? anyone can create as much disks as he like?
> we thought of requiring permissions if quota is disabled,
> but i think its confusing to the user as he plays with
You are right. Need to think this through...
Also, we need to get a better understanding on the use-cases for floating/shared disk... who is supposed to create them, and who to attach...


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


From ovedo at redhat.com  Sun Mar 18 11:48:46 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 18 Mar 2012 07:48:46 -0400 (EDT)
Subject: [Engine-devel] Bridgeless Networks api design
In-Reply-To: <4F659F54.5000300@redhat.com>
Message-ID: <519ec45b-adbb-4148-9ee8-88338592a33d@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Michael Pasternak" <mpastern at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Sunday, March 18, 2012 10:39:48 AM
> Subject: Re: [Engine-devel] Bridgeless Networks api design
> 
> On 03/18/2012 10:43 AM, Michael Pasternak wrote:
> > On 03/18/2012 10:21 AM, Itamar Heim wrote:
> >> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
> >>> the question is Management/Migration/Storage/Display can be
> >>> non-bridged?, if so,
> >>> <bridged>true|false</bridged>   makes sense.
> >>
> >> bridge is an implementation detail at host level, hence the
> >> discussion is about abstracting it from users.
> >> a VM network doesn't have to have bridge at host level, for
> >> networks using VMFex or SR-IOV
> >
> > <network>
> >    <designation>Management|Migration|Storage|Display|VM</designation>
> > </network>
> >
> > what do you say about having it as another /designation/ type?
> >
> 
> it==VM?
> the above looks ok to me.
> (I really hope for a better element name than designation though)

Consider using "purpose" instead of "designation".

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


From ashakarc at redhat.com  Sun Mar 18 12:11:33 2012
From: ashakarc at redhat.com (Asaf Shakarchi)
Date: Sun, 18 Mar 2012 08:11:33 -0400 (EDT)
Subject: [Engine-devel] Use java.util.Collection where possible?
In-Reply-To: <7992dfd9-fe8d-4615-bccf-fa44bc1bba92@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <6ddbad1c-3389-4b57-a0dd-7bef53d7a8b2@asafnb.int.vertix-tech.com>

----- Original Message -----
> From: "Danny Rankevich" <danny.ran at redhat.com>
> To: "Asaf Shakarchi" <ashakarc at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, March 15, 2012 7:52:47 PM
> Subject: Re: [Engine-devel] Use java.util.Collection where possible?
> 
> I ran deRPC with Collection in the parameters AND return type, and
> everything works ok.
> why should there be a problem? the concrete type is serialized in the
> payload...
Yes it works, but again, IIRC gwt compiler, while generating js has to take into account all possible variants of the Collection in the compilation unit, including all the classes impl Collection and Serializable interface in the class path. 
So that will cause the permutations to be much larger, it also affects compile time and the app size.
> 
> ----- Original Message -----
> > From: "Asaf Shakarchi" <ashakarc at redhat.com>
> > To: "Danny Rankevich" <danny.ran at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "Yair Zaslavsky"
> > <yzaslavs at redhat.com>
> > Sent: Wednesday, March 14, 2012 1:19:18 PM
> > Subject: Re: [Engine-devel] Use java.util.Collection where
> > possible?
> > 
> > Danny are you sure?
> > IIRC GWT RPC Oracle wont be able to pick the right implementation
> > and will generate code for any possible concrete impl,
> > 
> > 
> > Asaf.
> > ----- Original Message -----
> > > From: "Danny Rankevich" <danny.ran at redhat.com>
> > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, March 14, 2012 12:58:35 PM
> > > Subject: Re: [Engine-devel] Use java.util.Collection where
> > > possible?
> > > 
> > > BWT I did some checks on the GWT RPC that we use (deRPC) and
> > > there
> > > shouldn't be any problems using Collection interface (or any
> > > interface) in the generic api service.
> > > 
> > > ----- Original Message -----
> > > > From: "Allon Mureinik" <amureini at redhat.com>
> > > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Sunday, March 4, 2012 6:57:24 PM
> > > > Subject: Re: [Engine-devel] Use java.util.Collection where
> > > > possible?
> > > > 
> > > > My two cents:
> > > > 
> > > > There are two meanings of subtyping Collection (or any other
> > > > interface, for that matter) - additional logic and specific
> > > > implementation.
> > > > I think wherever possible, we should use the interface that
> > > > infers
> > > > as
> > > > much logic as possible (e.g., java.util.List for ordering,
> > > > java.util.Set for uniquness, java.util.SortedSet for natural
> > > > ordering, etc.), without inferring any specific implementation
> > > > (e.g., ArrayList, HashSet, etc.).
> > > > 
> > > > The flipside of this notion is that it's a mistake to use an
> > > > overly
> > > > specific class/interface - when your parameter type is
> > > > ArrayList,
> > > > you implicitly tell the user the *order* of his objects matter,
> > > > and
> > > > that it matters to your internal algorithm to be able to do
> > > > get(i)
> > > > as an O(1) operation.
> > > > 
> > > > Bottom line,  now that I'm done with CS 101:
> > > > +1, but be careful not use interfaces that are too low.
> > > > Most methods that now receive an ArrayList will still compile
> > > > if
> > > > you
> > > > change the parameter type to Collection, but make sure that you
> > > > don't implicitly assume some ordering, e.g.
> > > > 
> > > > -Allon
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Thursday, March 1, 2012 5:18:03 PM
> > > > > Subject: [Engine-devel] Use java.util.Collection where
> > > > > possible?
> > > > > 
> > > > > Hi,
> > > > > I see that in some places in engine-core we use
> > > > > Java.Util.List,
> > > > > or
> > > > > even
> > > > > Java.Util.ArrayList as types of method arguments, while in
> > > > > the
> > > > > method
> > > > > code we do nothing besides iterating over the collection.
> > > > > I then found all kinds of usages like this:
> > > > > 
> > > > > x.foo(new ArrayList<MyType>(myMap.values()));
> > > > > 
> > > > > As you can see need to instantiate a new ArrayList in order
> > > > > to
> > > > > use
> > > > > the
> > > > > values of the map in method foo.
> > > > > Do you see any reason why not change the argument type (at
> > > > > method
> > > > > signature) to Collection in such places, where possible?
> > > > > 
> > > > > Yair
> > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Sun Mar 18 12:31:45 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 18 Mar 2012 14:31:45 +0200
Subject: [Engine-devel] Bridgeless Networks api design
In-Reply-To: <4F65AA8A.6020009@redhat.com>
References: <4F61CA17.6080203@redhat.com> <4F61F5A3.90706@redhat.com>
	<4F658FC3.6030403@redhat.com> <4F659B03.2030502@redhat.com>
	<4F65A031.8080002@redhat.com> <4F65AA8A.6020009@redhat.com>
Message-ID: <4F65D5B1.4040501@redhat.com>

On 03/18/2012 11:27 AM, Yaniv Kaul wrote:
> On 03/18/2012 10:43 AM, Michael Pasternak wrote:
>> On 03/18/2012 10:21 AM, Itamar Heim wrote:
>>> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
>>>> the question is Management/Migration/Storage/Display can be
>>>> non-bridged?, if so,
>>>> <bridged>true|false</bridged> makes sense.
>>> bridge is an implementation detail at host level, hence the
>>> discussion is about abstracting it from users.
>>> a VM network doesn't have to have bridge at host level, for networks
>>> using VMFex or SR-IOV
>> <network>
>> <designation>Management|Migration|Storage|Display|VM</designation>
>> </network>
>>
>> what do you say about having it as another /designation/ type?
>>
>
> Not sure I understand: Management can be bridge-less, Migration can be
> bridge-less, Storage can be bridge-less, Display can be bridge-less, VM
> is the only that perhaps today cannot be bridge-less, so I do think that
> '<bridged>true|false</bridged>' makes some sense. However, I'd
> generalize it to 'attachment' as I believe we'll have other types in the
> future (Macvtap, SRIOV and friends), so something like
> <attachment>bridge|sriov|macvtap|...</attachment>
> Y.
>

attachment would be at physical host level and could vary from host to host.
this is about intended allowed usages of the logical network across the 
system


From rgolan at redhat.com  Sun Mar 18 13:31:46 2012
From: rgolan at redhat.com (Roy Golan)
Date: Sun, 18 Mar 2012 09:31:46 -0400 (EDT)
Subject: [Engine-devel] Bridgeless Networks api design
In-Reply-To: <4F65D5B1.4040501@redhat.com>
Message-ID: <815f1bb1-ab1b-4225-93fd-9e2bfe986a27@zmail01.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Yaniv Kaul" <ykaul at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Sunday, March 18, 2012 2:31:45 PM
> Subject: Re: [Engine-devel] Bridgeless Networks api design
> 
> On 03/18/2012 11:27 AM, Yaniv Kaul wrote:
> > On 03/18/2012 10:43 AM, Michael Pasternak wrote:
> >> On 03/18/2012 10:21 AM, Itamar Heim wrote:
> >>> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
> >>>> the question is Management/Migration/Storage/Display can be
> >>>> non-bridged?, if so,
> >>>> <bridged>true|false</bridged> makes sense.
> >>> bridge is an implementation detail at host level, hence the
> >>> discussion is about abstracting it from users.
> >>> a VM network doesn't have to have bridge at host level, for
> >>> networks
> >>> using VMFex or SR-IOV
> >> <network>
> >> <designation>Management|Migration|Storage|Display|VM</designation>
> >> </network>
> >>
> >> what do you say about having it as another /designation/ type?
> >>
> >
> > Not sure I understand: Management can be bridge-less, Migration can
> > be
> > bridge-less, Storage can be bridge-less, Display can be
> > bridge-less, VM
> > is the only that perhaps today cannot be bridge-less, so I do think
> > that
> > '<bridged>true|false</bridged>' makes some sense. However, I'd
> > generalize it to 'attachment' as I believe we'll have other types
> > in the
> > future (Macvtap, SRIOV and friends), so something like
> > <attachment>bridge|sriov|macvtap|...</attachment>
> > Y.
> >
> 
> attachment would be at physical host level and could vary from host
> to host.
> this is about intended allowed usages of the logical network across
> the
> system

we should probably have a set of, so called, "usages" and not a single one. It should give enough 
flexibility for future usages with an easy upgrade.

something like:

<network>
 <usages>management,display,VM</usages>
<network>

or:

 <network>
  <usages>
   <usage>management</usage>
   <usage>display</usage>
   <usage>VM</usage>
  </usages>
 </network>

 

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


From ecohen at redhat.com  Mon Mar 19 08:25:24 2012
From: ecohen at redhat.com (Einav Cohen)
Date: Mon, 19 Mar 2012 04:25:24 -0400 (EDT)
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <24d4e819-da82-405e-a0f7-df11e202faa3@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <3cd8ba05-5c77-4fe5-a5ac-a838a23eec8b@zmail04.collab.prod.int.phx2.redhat.com>

> ----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> Sent: Sunday, March 18, 2012 11:52:33 AM
> > > > 
> > > > On 03/15/2012 05:34 PM, Omer Frenkel wrote:
> > > > >>> >  >  1. "Create disk - requires permissions on the Storage
> > > > >>> >  >  Domain,
> > > > >>> >  >  (can't
> > > > >>> >  >  assume Quota is sufficient to permit user creating
> > > > >>> >  >  the
> > > > >>> >  >  disk
> > > > >>> >  >  on the
> > > > >>> >  >  Storage Domain, as Quota might be disabled)"
> > > > >>> >  >
> > > > >>> >  >  I'd also specify create disk for regular disks is at
> > > > >>> >  >  storage domain
> > > > >>> >  >  level?, while direct lun disks require system level
> > > > >>> >  >  permission of
> > > > >>> >  >  add disk.
> > > > >>> >  >
> > > > >>> >  >  so, if quota is disabled, how important is it to
> > > > >>> >  >  prevent
> > > > >>> >  >  creation
> > > > >>> >  >  of
> > > > >>> >  >  disks (other than direct lun ones, which would
> > > > >>> >  >  require
> > > > >>> >  >  a
> > > > >>> >  >  permission
> > > > >>> >  >  similar to storage domain creation)?
> > > > >>> >  >
> > > > >>> >  >  if this is added, it has to be implicitly added / not
> > > > >>> >  >  needed if
> > > > >>> >  >  user has
> > > > >>> >  >  quota (i.e., having a quota should be similar to
> > > > >>> >  >  having
> > > > >>> >  >  a
> > > > >>> >  >  permission as
> > > > >>> >  >  far as the check goes).
> > > > >>> >  >
> > > > >> >
> > > > >> >  We should look into it, how complicate is it to validate
> > > > >> >  if
> > > > >> >  user has
> > > > >> >  either quota or permission, and allow creating a disk on
> > > > >> >  a
> > > > >> >  SD
> > > > >> >  if
> > > > >> >  either
> > > > >> >  exists.
> > > > > this might be confusing to the user as he can disable the
> > > > > quota,
> > > > > then stuff would stop working.
> > > > >
> > > > 
> > > > we can't require both quota and permissions from user on
> > > > storage
> > > > domains
> > > > - that's cumbersome.
> > > > question is if we can limit the need for permissions to disks
> > > > only
> > > > to
> > > > places where they are needed (shared, direct, floating)?
> > > +1 on that.
> > > I also think it is only relevant on attaching a disk to a VM, as
> > > the
> > > other use-cases are simpler:
> > > 1. Attach disk to VM - would require having permissions on the
> > > disk
> > > (whether it is shared, direct lun or floating)
> > > 2. Add disk to VM - would only require quota (if enforced).
> > > 3. Create disk (i.e., floating/shared disk) - would only require
> > > quota (if enforced).
> > 
> > and if not enforced? anyone can create as much disks as he like?
> > we thought of requiring permissions if quota is disabled,
> > but i think its confusing to the user as he plays with
> You are right. Need to think this through...
> Also, we need to get a better understanding on the use-cases for
> floating/shared disk... who is supposed to create them, and who to
> attach...

The convention today is that in order to create something, you need permissions on the ancestor entity.
Therefore, I think it should be as follows:

1. In order to create a Disk in a VM context, you need permission on the VM (just like in 3.0, IIRC).
2. In order to create a Floating Disk within a storage domain, you need permission on the storage domain
3. In order to create an External LUN Disk, you need permission on System/DC/Whatever we decide the ancestor entity of External LUN is.
4? Not sure regarding creation of External LUN Disk in a VM context (if that scenario exists) - will probably need a permission on both VM and External-LUN-ancestor, since this is a special case.

All of the above is regardless quota, meaning, if quota is enforced, quota restrictions will apply as relevant *in addition* to the permission limitations.

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


From ecohen at redhat.com  Mon Mar 19 10:47:42 2012
From: ecohen at redhat.com (Einav Cohen)
Date: Mon, 19 Mar 2012 06:47:42 -0400 (EDT)
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <4F5FE442.7070602@redhat.com>
Message-ID: <4bb168a8-2421-4fdc-9fb1-6a021b188665@zmail04.collab.prod.int.phx2.redhat.com>

1.
According to the wiki, these are the new Action Groups that will be added:
 CREATE_DISK - AddDisk, AddDiskToVm
 EDIT_DISK_PROPERTIES - UpdateDisk, UpdateVM, Activate/Deactivate
 ATTACH_DISK - AttachDiskToVm
 CONFIGURE_DISK_STORAGE - MoveOrCopyDisk
 DELETE_DISK - RemoveDisk, RemoveVm

Currently we have:
CONFIGURE_VM_STORAGE - AddDiskToVm, RemoveDisksFromVm, UpdateVmDisk

So, since "AddDiskToVm" has moved to "CREATE_DISK", it will now be:
CONFIGURE_VM_STORAGE - RemoveDisksFromVm, UpdateVmDisk

- Is there a difference between RemoveDisk and RemoveDisksFromVm? If so, what is the difference?
- Is there a difference between UpdateDisk and UpdateVmDisk? If so, what is the difference?
[If answer to both questions is "no", CONFIGURE_VM_STORAGE action-group should be removed; this should be considered in the upgrade process]

2. [Michael/Daniel] (more related to the floating disks feature): In which Action Group will "DetachDiskFromVm" reside?

3. "Updated Roles: VM Operator should be extended with permissions on Disk" - note that all other pre-defined roles that have "UpdateVM" within them (and most of them do, AFAIK) should also be extended with the extra Disk-related ActionGroups (otherwise we can reach strange situations in which a Cluster Admin can do everything in his cluster except manipulate Disks in his VMs, for example).

4. "Upgrade DB: Add Disk Operator role to users that have VM Operators to allow permissions on Disks": 
- I assume that you mean that Disk Operator *permissions* should be added on the relevant *Disks* to the "VM Operator" users.
- I suggest to add these during upgrade not only for "VM Operators" but for all users that have a direct permission on a VM which is associated with any Role that contains the action "UpdateVM".

5. GUI will need a new query: GetAllAttachableDisks. 
 - This query should be an Admin + User query and will have two "flavors": Admin and User (using the "isFiltered" property).
 - With "isFiltered = false" (will be used for the admin portal), it should return a list of all floating and/or sharable disks.
 - With "isFiltered = true" (will be used in the power user portal), it should return a list of all floating and/or sharable disks on which the user has permissions.


----
Thanks,
Einav

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, March 14, 2012 2:20:18 AM
> Subject: [Engine-devel] Disk Permissions Feature
> 
> Hi all,
> 
> Disk Permissions feature description Wiki page:
> http://www.ovirt.org/wiki/Features/DiskPermissions
> 
> Please share your comments.
> 
> Thanks,
> Moti
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ovedo at redhat.com  Mon Mar 19 11:22:22 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Mon, 19 Mar 2012 07:22:22 -0400 (EDT)
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <3cd8ba05-5c77-4fe5-a5ac-a838a23eec8b@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <a91499c4-f312-4540-8a95-0ff0810b96bb@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, March 19, 2012 10:25:24 AM
> Subject: Re: [Engine-devel] Disk Permissions Feature
> 
> > ----- Original Message -----
> > From: "Oved Ourfalli" <ovedo at redhat.com>
> > Sent: Sunday, March 18, 2012 11:52:33 AM
> > > > > 
> > > > > On 03/15/2012 05:34 PM, Omer Frenkel wrote:
> > > > > >>> >  >  1. "Create disk - requires permissions on the
> > > > > >>> >  >  Storage
> > > > > >>> >  >  Domain,
> > > > > >>> >  >  (can't
> > > > > >>> >  >  assume Quota is sufficient to permit user creating
> > > > > >>> >  >  the
> > > > > >>> >  >  disk
> > > > > >>> >  >  on the
> > > > > >>> >  >  Storage Domain, as Quota might be disabled)"
> > > > > >>> >  >
> > > > > >>> >  >  I'd also specify create disk for regular disks is
> > > > > >>> >  >  at
> > > > > >>> >  >  storage domain
> > > > > >>> >  >  level?, while direct lun disks require system level
> > > > > >>> >  >  permission of
> > > > > >>> >  >  add disk.
> > > > > >>> >  >
> > > > > >>> >  >  so, if quota is disabled, how important is it to
> > > > > >>> >  >  prevent
> > > > > >>> >  >  creation
> > > > > >>> >  >  of
> > > > > >>> >  >  disks (other than direct lun ones, which would
> > > > > >>> >  >  require
> > > > > >>> >  >  a
> > > > > >>> >  >  permission
> > > > > >>> >  >  similar to storage domain creation)?
> > > > > >>> >  >
> > > > > >>> >  >  if this is added, it has to be implicitly added /
> > > > > >>> >  >  not
> > > > > >>> >  >  needed if
> > > > > >>> >  >  user has
> > > > > >>> >  >  quota (i.e., having a quota should be similar to
> > > > > >>> >  >  having
> > > > > >>> >  >  a
> > > > > >>> >  >  permission as
> > > > > >>> >  >  far as the check goes).
> > > > > >>> >  >
> > > > > >> >
> > > > > >> >  We should look into it, how complicate is it to
> > > > > >> >  validate
> > > > > >> >  if
> > > > > >> >  user has
> > > > > >> >  either quota or permission, and allow creating a disk
> > > > > >> >  on
> > > > > >> >  a
> > > > > >> >  SD
> > > > > >> >  if
> > > > > >> >  either
> > > > > >> >  exists.
> > > > > > this might be confusing to the user as he can disable the
> > > > > > quota,
> > > > > > then stuff would stop working.
> > > > > >
> > > > > 
> > > > > we can't require both quota and permissions from user on
> > > > > storage
> > > > > domains
> > > > > - that's cumbersome.
> > > > > question is if we can limit the need for permissions to disks
> > > > > only
> > > > > to
> > > > > places where they are needed (shared, direct, floating)?
> > > > +1 on that.
> > > > I also think it is only relevant on attaching a disk to a VM,
> > > > as
> > > > the
> > > > other use-cases are simpler:
> > > > 1. Attach disk to VM - would require having permissions on the
> > > > disk
> > > > (whether it is shared, direct lun or floating)
> > > > 2. Add disk to VM - would only require quota (if enforced).
> > > > 3. Create disk (i.e., floating/shared disk) - would only
> > > > require
> > > > quota (if enforced).
> > > 
> > > and if not enforced? anyone can create as much disks as he like?
> > > we thought of requiring permissions if quota is disabled,
> > > but i think its confusing to the user as he plays with
> > You are right. Need to think this through...
> > Also, we need to get a better understanding on the use-cases for
> > floating/shared disk... who is supposed to create them, and who to
> > attach...
> 
> The convention today is that in order to create something, you need
> permissions on the ancestor entity.
> Therefore, I think it should be as follows:
> 
> 1. In order to create a Disk in a VM context, you need permission on
> the VM (just like in 3.0, IIRC).
> 2. In order to create a Floating Disk within a storage domain, you
> need permission on the storage domain

"1" is okay as long as we limit the user from detaching this disk later on, as detaching it will make it floating.
Or, we can allow detaching only in case the user has permissions on the storage domain, but that will be hard to understand in a user's perspective.

> 3. In order to create an External LUN Disk, you need permission on
> System/DC/Whatever we decide the ancestor entity of External LUN is.
> 4? Not sure regarding creation of External LUN Disk in a VM context
> (if that scenario exists) - will probably need a permission on both
> VM and External-LUN-ancestor, since this is a special case.
> 
> All of the above is regardless quota, meaning, if quota is enforced,
> quota restrictions will apply as relevant *in addition* to the
> permission limitations.
> 
> > 
> > 
> > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From masayag at redhat.com  Mon Mar 19 16:55:57 2012
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 19 Mar 2012 18:55:57 +0200
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <4bb168a8-2421-4fdc-9fb1-6a021b188665@zmail04.collab.prod.int.phx2.redhat.com>
References: <4bb168a8-2421-4fdc-9fb1-6a021b188665@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4F67651D.90801@redhat.com>

On 03/19/2012 12:47 PM, Einav Cohen wrote:
> 1.
> According to the wiki, these are the new Action Groups that will be added:
>  CREATE_DISK - AddDisk, AddDiskToVm
>  EDIT_DISK_PROPERTIES - UpdateDisk, UpdateVM, Activate/Deactivate
>  ATTACH_DISK - AttachDiskToVm
>  CONFIGURE_DISK_STORAGE - MoveOrCopyDisk
>  DELETE_DISK - RemoveDisk, RemoveVm
> 
> Currently we have:
> CONFIGURE_VM_STORAGE - AddDiskToVm, RemoveDisksFromVm, UpdateVmDisk
> 
> So, since "AddDiskToVm" has moved to "CREATE_DISK", it will now be:
> CONFIGURE_VM_STORAGE - RemoveDisksFromVm, UpdateVmDisk
> 
> - Is there a difference between RemoveDisk and RemoveDisksFromVm? If so, what is the difference?
> - Is there a difference between UpdateDisk and UpdateVmDisk? If so, what is the difference?
> [If answer to both questions is "no", CONFIGURE_VM_STORAGE action-group should be removed; this should be considered in the upgrade process]

This point should be taken into consideration when design/implementation
of new verbs (RemoveDisk / UpdateDisk ) is done.

> 
> 2. [Michael/Daniel] (more related to the floating disks feature): In which Action Group will "DetachDiskFromVm" reside?
> 
> 3. "Updated Roles: VM Operator should be extended with permissions on Disk" - note that all other pre-defined roles that have "UpdateVM" within them (and most of them do, AFAIK) should also be extended with the extra Disk-related ActionGroups (otherwise we can reach strange situations in which a Cluster Admin can do everything in his cluster except manipulate Disks in his VMs, for example).

Updated wiki:
http://www.ovirt.org/wiki/Features/DiskPermissions#Updated_Roles

> 
> 4. "Upgrade DB: Add Disk Operator role to users that have VM Operators to allow permissions on Disks": 
> - I assume that you mean that Disk Operator *permissions* should be added on the relevant *Disks* to the "VM Operator" users.
> - I suggest to add these during upgrade not only for "VM Operators" but for all users that have a direct permission on a VM which is associated with any Role that contains the action "UpdateVM".
> 

Updated wiki:
http://www.ovirt.org/wiki/Features/DiskPermissions#Upgrade_DB

> 5. GUI will need a new query: GetAllAttachableDisks. 
>  - This query should be an Admin + User query and will have two "flavors": Admin and User (using the "isFiltered" property).
>  - With "isFiltered = false" (will be used for the admin portal), it should return a list of all floating and/or sharable disks.
>  - With "isFiltered = true" (will be used in the power user portal), it should return a list of all floating and/or sharable disks on which the user has permissions.
> 
> 
> ----
> Thanks,
> Einav
> 
> ----- Original Message -----
>> From: "Moti Asayag" <masayag at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Wednesday, March 14, 2012 2:20:18 AM
>> Subject: [Engine-devel] Disk Permissions Feature
>>
>> Hi all,
>>
>> Disk Permissions feature description Wiki page:
>> http://www.ovirt.org/wiki/Features/DiskPermissions
>>
>> Please share your comments.
>>
>> Thanks,
>> Moti
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From masayag at redhat.com  Mon Mar 19 17:03:36 2012
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 19 Mar 2012 19:03:36 +0200
Subject: [Engine-devel] Disk Permissions Feature
In-Reply-To: <4F620EBF.2040704@redhat.com>
References: <e43ebb15-267a-4046-930f-07f60bbf60ba@ofrenkel.csb>
	<4F620EBF.2040704@redhat.com>
Message-ID: <4F6766E8.2080409@redhat.com>

On 03/15/2012 05:46 PM, Itamar Heim wrote:
> On 03/15/2012 05:34 PM, Omer Frenkel wrote:
>>>> >  >  1. "Create disk - requires permissions on the Storage Domain,
>>>> >  >  (can't
>>>> >  >  assume Quota is sufficient to permit user creating the disk on
>>>> the
>>>> >  >  Storage Domain, as Quota might be disabled)"
>>>> >  >
>>>> >  >  I'd also specify create disk for regular disks is at storage
>>>> domain
>>>> >  >  level?, while direct lun disks require system level permission of
>>>> >  >  add disk.
>>>> >  >
>>>> >  >  so, if quota is disabled, how important is it to prevent creation
>>>> >  >  of
>>>> >  >  disks (other than direct lun ones, which would require a
>>>> permission
>>>> >  >  similar to storage domain creation)?
>>>> >  >
>>>> >  >  if this is added, it has to be implicitly added / not needed if
>>>> >  >  user has
>>>> >  >  quota (i.e., having a quota should be similar to having a
>>>> >  >  permission as
>>>> >  >  far as the check goes).
>>>> >  >
>>> >
>>> >  We should look into it, how complicate is it to validate if user has
>>> >  either quota or permission, and allow creating a disk on a SD if
>>> >  either
>>> >  exists.
>> this might be confusing to the user as he can disable the quota,
>> then stuff would stop working.
>>
> 
> we can't require both quota and permissions from user on storage domains
> - that's cumbersome.
> question is if we can limit the need for permissions to disks only to
> places where they are needed (shared, direct, floating)?

Wiki is updated with a proposal for this issue. In a nutshell, adding
'automatic' permissions on the Storage Domain (or to Storage Pool for
Global quota) to relevant users when performing Quota specific actions
so they be used regardless quota concern (e.g. when Quota is disabled
for DC):

http://www.ovirt.org/wiki/Features/DiskPermissions#Design

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



From lhornyak at redhat.com  Tue Mar 20 11:08:52 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 20 Mar 2012 07:08:52 -0400 (EDT)
Subject: [Engine-devel] ovirt.org unavailable
In-Reply-To: <36abe8b5-663c-49d6-93fb-6a118b35aafa@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <ebf46190-4358-428f-b5a7-3ed268fe19ce@zmail01.collab.prod.int.phx2.redhat.com>

Hi,

The ovirt.org site is inavailable for a few hours. Does the infrastructure team know about the problem?

Thank you,
Laszlo


From oschreib at redhat.com  Tue Mar 20 12:32:27 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Tue, 20 Mar 2012 08:32:27 -0400 (EDT)
Subject: [Engine-devel] [Users] ovirt.org unavailable
In-Reply-To: <ebf46190-4358-428f-b5a7-3ed268fe19ce@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <a64aed95-52d8-420d-9942-bdd4306c3d78@zmail14.collab.prod.int.phx2.redhat.com>

mburns and quiad are working on the issue as we speak.
more updates soon.

----- Original Message -----
> Hi,
> 
> The ovirt.org site is inavailable for a few hours. Does the
> infrastructure team know about the problem?
> 
> Thank you,
> Laszlo
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From lhornyak at redhat.com  Tue Mar 20 12:37:34 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 20 Mar 2012 08:37:34 -0400 (EDT)
Subject: [Engine-devel] [Users] ovirt.org unavailable
In-Reply-To: <a64aed95-52d8-420d-9942-bdd4306c3d78@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <32038cb2-6fe9-4c7b-9b33-6c0c58915e6f@zmail01.collab.prod.int.phx2.redhat.com>

Yeah, I realized that the mailing lists are served by the same server. So I guess by now they have fixed it.

Thank you!

----- Original Message -----
> From: "Ofer Schreiber" <oschreib at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: users at ovirt.org, "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, March 20, 2012 1:32:27 PM
> Subject: Re: [Users] ovirt.org unavailable
> 
> mburns and quiad are working on the issue as we speak.
> more updates soon.
> 
> ----- Original Message -----
> > Hi,
> > 
> > The ovirt.org site is inavailable for a few hours. Does the
> > infrastructure team know about the problem?
> > 
> > Thank you,
> > Laszlo
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> > 
> 


From ItzikB at mellanox.com  Thu Mar 22 08:43:32 2012
From: ItzikB at mellanox.com (Itzik Brown)
Date: Thu, 22 Mar 2012 08:43:32 +0000
Subject: [Engine-devel] Problem with detachment of host interface using
	ovirt-sdk
Message-ID: <4488206DC085244C886DBC9E7038B68918D382CE@MTRDAG01.mtl.com>

Hi,

I'm using ovirt-sdk to attach and detach a network to a host's Interface.
Once the network is attached to the interface I try to detach the network from the interface using the following steps:

1.Detach the network from the cluster through the GUI.
2.Remove the network from the datacenter through the GUI.
3.Detach the network from the host's interface using the SDK:

nic = api.hosts.get(name=host).nics.get(name=if_name)
net = params.Network(name=net_name)
act = params.Action(network=net)
nic.detach(act)
api.hosts.get(name=host).commitnetconfig()

Then I get the error:
http://pastebin.com/3Md07huE

The same flow using the GUI works fine.

Network removal from the Datacenter is a trigger for me to run the detachment operation therefore I use this flow.

I use the following components:

rhevm-3.0.2_0001-2
ovirt-sdk (Using the latest from git repository)

Please advise how to proceed.

Thanks,
Itzik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120322/594afc44/attachment.html>

From mkolesni at redhat.com  Thu Mar 22 09:04:04 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Thu, 22 Mar 2012 05:04:04 -0400 (EDT)
Subject: [Engine-devel] Forward comp[atibility of OVF
In-Reply-To: <ed8c42d9-86e7-4766-986b-2c6c619d8a5b@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <d7c57832-0cb5-48eb-b673-f6dd64a800a5@zmail14.collab.prod.int.phx2.redhat.com>

Hi, 

I wanted to know if we want to support forward compatibility of OVF format, which is used for export/import of VMs/VM Templates. 

For example, 
I create a VM in a 3.1 system, export it to an export Domain. 
Should I be able to import this VM on a 3.0 system? 

Obviously, backwards compatibility (from older version to newer) is desired and is kept , but do we really need forward compatibility also? 

The reason I'm asking is some changes that need to be done in current OVF format to support new features. These new changes will be backwards-compatible with old OVF formats, but is it desirable for them to be forward compatible? 


Regards, 
Mike 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120322/7fc2de41/attachment.html>

From lpeer at redhat.com  Thu Mar 22 09:37:05 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Thu, 22 Mar 2012 11:37:05 +0200
Subject: [Engine-devel] Forward comp[atibility of OVF
In-Reply-To: <d7c57832-0cb5-48eb-b673-f6dd64a800a5@zmail14.collab.prod.int.phx2.redhat.com>
References: <d7c57832-0cb5-48eb-b673-f6dd64a800a5@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F6AF2C1.9080903@redhat.com>

On 22/03/12 11:04, Mike Kolesnik wrote:
> Hi,
> 
> I wanted to know if we want to support forward compatibility of OVF
> format, which is used for export/import of VMs/VM Templates.
> 
> For example,
> I create a VM in a 3.1 system, export it to an export Domain.
> Should I be able to import this VM on a 3.0 system?
> 

I think we should support only backwards compatibility no need for
forward compatibility.
The question is should we block importing such a VM (that it's version
is not something the engine identifies) I think we should block it
otherwise the engine will import the VM which can fail sometimes with
errors like NullPointerException which will end-up being filed as a BZ.


> Obviously, backwards compatibility (from older version to newer) is
> desired and is kept, but do we really need forward compatibility also?
> 
> The reason I'm asking is some changes that need to be done in current
> OVF format to support new features. These new changes will be
> backwards-compatible with old OVF formats, but is it desirable for them
> to be forward compatible?
> 
> Regards,
> Mike
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From mkolesni at redhat.com  Thu Mar 22 09:38:55 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Thu, 22 Mar 2012 05:38:55 -0400 (EDT)
Subject: [Engine-devel] Forward comp[atibility of OVF
In-Reply-To: <4F6AF2C1.9080903@redhat.com>
Message-ID: <749e2dbf-732a-46e4-aff5-93ad234917b5@zmail14.collab.prod.int.phx2.redhat.com>

> On 22/03/12 11:04, Mike Kolesnik wrote:
> > Hi,
> > 
> > I wanted to know if we want to support forward compatibility of OVF
> > format, which is used for export/import of VMs/VM Templates.
> > 
> > For example,
> > I create a VM in a 3.1 system, export it to an export Domain.
> > Should I be able to import this VM on a 3.0 system?
> > 
> 
> I think we should support only backwards compatibility no need for
> forward compatibility.
> The question is should we block importing such a VM (that it's
> version
> is not something the engine identifies) I think we should block it
> otherwise the engine will import the VM which can fail sometimes with
> errors like NullPointerException which will end-up being filed as a
> BZ.

I agree that this should be blocked, however to do so for older versions will require extra work that i don't know if we need or not..

> 
> 
> > Obviously, backwards compatibility (from older version to newer) is
> > desired and is kept, but do we really need forward compatibility
> > also?
> > 
> > The reason I'm asking is some changes that need to be done in
> > current
> > OVF format to support new features. These new changes will be
> > backwards-compatible with old OVF formats, but is it desirable for
> > them
> > to be forward compatible?
> > 
> > Regards,
> > Mike
> > 
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 


From ykaul at redhat.com  Thu Mar 22 12:50:45 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Thu, 22 Mar 2012 14:50:45 +0200
Subject: [Engine-devel] Releases/31/FeatureList - oVirtWiki
Message-ID: <4F6B2025.7060101@redhat.com>

Is anyone maintaining this page? Is it up-to-date, wrt feature list, 
completion percentage, etc.?

http://www.ovirt.org/wiki/Releases/31/FeatureList


From ovedo at redhat.com  Thu Mar 22 13:13:37 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Thu, 22 Mar 2012 09:13:37 -0400 (EDT)
Subject: [Engine-devel] Releases/31/FeatureList - oVirtWiki
In-Reply-To: <4F6B2025.7060101@redhat.com>
Message-ID: <50cc634d-efa6-4472-bbaa-49ec23ec4ed9@zmail02.collab.prod.int.phx2.redhat.com>

We need to remove that one.
We thought at first to put a feature list there, but maintaining it is not so trivial.

----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, March 22, 2012 2:50:45 PM
> Subject: [Engine-devel] Releases/31/FeatureList - oVirtWiki
> 
> Is anyone maintaining this page? Is it up-to-date, wrt feature list,
> completion percentage, etc.?
> 
> http://www.ovirt.org/wiki/Releases/31/FeatureList
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From rgolan at redhat.com  Sun Mar 25 06:51:06 2012
From: rgolan at redhat.com (Roy Golan)
Date: Sun, 25 Mar 2012 08:51:06 +0200
Subject: [Engine-devel] Problem with detachment of host interface using
 ovirt-sdk
In-Reply-To: <4488206DC085244C886DBC9E7038B68918D382CE@MTRDAG01.mtl.com>
References: <4488206DC085244C886DBC9E7038B68918D382CE@MTRDAG01.mtl.com>
Message-ID: <4F6EC05A.9010209@redhat.com>

On 03/22/2012 10:43 AM, Itzik Brown wrote:
>
> Hi,
>
> I'm using ovirt-sdk to attach and detach a network to a host's Interface.
>
> Once the network is attached to the interface I try to detach the 
> network from the interface using the following steps:
>
> 1.Detach the network from the cluster through the GUI.
>
> 2.Remove the network from the datacenter through the GUI.
>
> 3.Detach the network from the host's interface using the SDK:
>
> nic = api.hosts.get(name=host).nics.get(name=if_name)
>
> net = params.Network(name=net_name)
>
> act = params.Action(network=net)
>
> nic.detach(act)
>
> api.hosts.get(name=host).commitnetconfig()
>
> Then I get the error:
>
> http://pastebin.com/3Md07huE
>
> The same flow using the GUI works fine.
>
> Network removal from the Datacenter is a trigger for me to run the 
> detachment operation therefore I use this flow.
>
> I use the following components:
>
> rhevm-3.0.2_0001-2
>
> ovirt-sdk (Using the latest from git repository)
>
> Please advise how to proceed.
>
> Thanks,
>
> Itzik
>
>
>
> This body part will be downloaded on demand.
Ovirt-sdk and rhevm don't comply (ovirt-sdk is based on the upstream 
version of rhevm)

Use the REST api instead:

curl -X POST user at domain:password -H "Content-Type: application/xml" 
-d@/path/to/file.xml 
https://rhevm:8843/api/hosts/{host-id}/nics/{nic-id}/detach

file.xml:

<action>
<host_nic>
<name>eth0</name>
</host_nic>
</action>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120325/15386e41/attachment.html>

From lhornyak at redhat.com  Mon Mar 26 13:01:40 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 26 Mar 2012 09:01:40 -0400 (EDT)
Subject: [Engine-devel] Feature: backend support for Advanced NFS Options
In-Reply-To: <7e3e9c99-98c7-42b4-9b4e-7b3bf232ec79@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <e3317eff-c7bb-486a-8305-fd0b62bdea70@zmail01.collab.prod.int.phx2.redhat.com>

Hi,

http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#Changes_in_ovirt_engine

Your feedback is welcome.

Laszlo


From mkolesni at redhat.com  Mon Mar 26 14:08:13 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 26 Mar 2012 10:08:13 -0400 (EDT)
Subject: [Engine-devel] How to utilize Jenkins to do your dirty (build) work
	for you...
In-Reply-To: <8c9bcb52-7ffb-425a-8824-6f03803de6f8@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <0210de81-3776-4c65-bbc6-1dffd4e59df8@zmail14.collab.prod.int.phx2.redhat.com>

Hi, 


-- Intro -- 
  When working on your local GIT repo you probably do a lot of: 
    mvn clean install 

  Additionally, if you're working on oVirt-engine you might be doing some of: 
    mvn test -Penable-dao-tests 
    mvn install -Pgwt-admin 
    etc.. 

  This, of course, might take your development computer a while, and hog your resources. 

  Usually though, if you work on oVirt, you have a host that you use for testing your changes.. 
  This host probably has a 2/4 cores CPU and at least 4Gb of RAM.. 

  This host is sitting quietly most of the time, consuming mostly electricity but not doing much. 
  You're probably not even utilizing it that much even when you are testing something on it. 
  It is like a powerful guard dog that you keep tied in the back-yard most of the time, instead of letting it run free. 

  Well, I have a suggestion how to put that puppy into good use and also free up your resources.. 

-- End Intro -- 

You can install Jenkins on the host, and have it monitor your local GIT repo for changes, building your commits as necessary.
This works with every local branch you have - Jenkins will pick up the change (be it a local commit you just did, or a rebase over the origin) and generate a build for it.

This will allow you to monitor your build results just as you would monitor locally, while in the same time utilize a (probably) more powerful machine to do this for you. It will also probably speed up your build cycle, as builds will be executed in parallel. 

I have written an installation guide which explains how to do it in the oVirt wiki: 
  http://www.ovirt.org/wiki/Local_Jenkins_For_The_People 

I have also written a script that will run the installation part on the host for you, 
so you just need to download the attachment and run it as root on the host, but you will still need to do some manual work so make sure to check the wiki.

-- Example Jobs --
  I am also attaching sample jobs to import to Jenkins.
  Make sure to replace the GIT repo URL, you can do this before importing with sed:
   # sed -i 's#[git-repo-url]#ssh://[user]@[git-host]/[git-repo-location]#' oVirt-engine.*

  For example:
   # sed -i 's#[git-repo-url]#ssh://mkolesni at myhost/~/git/ovirt-engine#' oVirt-engine.*

  You can import them with the command:
   # cat [job].xml | java -jar /tmp/jenkins-cli.jar -s http://localhost:8080 create-job [job-name]

  For example:
   # cat oVirt-engine.xml | java -jar /tmp/jenkins-cli.jar -s http://localhost:8080 create-job oVirt-engine
-- End Example Jobs --

Of course, this might not be ideal in cases when you need 100% percent of your host.. 
But in such a case you can simply turn off Jenkins, and turn it back on later. ;) 


Regards, 
Mike 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jenkins.sh
Type: application/x-shellscript
Size: 5125 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120326/7ac51fbf/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oVirt-engine.jobs.tar.gz
Type: application/x-compressed-tar
Size: 2388 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120326/7ac51fbf/attachment-0001.bin>

From ecohen at redhat.com  Mon Mar 26 14:54:38 2012
From: ecohen at redhat.com (Einav Cohen)
Date: Mon, 26 Mar 2012 10:54:38 -0400 (EDT)
Subject: [Engine-devel] Bridgeless Networks api design
In-Reply-To: <815f1bb1-ab1b-4225-93fd-9e2bfe986a27@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <42081a90-df1e-4949-b6ff-7944146347e1@zmail04.collab.prod.int.phx2.redhat.com>

> ----- Original Message -----
> From: "Roy Golan" <rgolan at redhat.com>
> Sent: Sunday, March 18, 2012 3:31:46 PM
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Yaniv Kaul" <ykaul at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Sunday, March 18, 2012 2:31:45 PM
> > Subject: Re: [Engine-devel] Bridgeless Networks api design
> > 
> > On 03/18/2012 11:27 AM, Yaniv Kaul wrote:
> > > On 03/18/2012 10:43 AM, Michael Pasternak wrote:
> > >> On 03/18/2012 10:21 AM, Itamar Heim wrote:
> > >>> On 03/18/2012 09:33 AM, Michael Pasternak wrote:
> > >>>> the question is Management/Migration/Storage/Display can be
> > >>>> non-bridged?, if so,
> > >>>> <bridged>true|false</bridged> makes sense.
> > >>> bridge is an implementation detail at host level, hence the
> > >>> discussion is about abstracting it from users.
> > >>> a VM network doesn't have to have bridge at host level, for
> > >>> networks
> > >>> using VMFex or SR-IOV
> > >> <network>
> > >> <designation>Management|Migration|Storage|Display|VM</designation>
> > >> </network>
> > >>
> > >> what do you say about having it as another /designation/ type?
> > >>
> > >
> > > Not sure I understand: Management can be bridge-less, Migration
> > > can
> > > be
> > > bridge-less, Storage can be bridge-less, Display can be
> > > bridge-less, VM
> > > is the only that perhaps today cannot be bridge-less, so I do
> > > think
> > > that
> > > '<bridged>true|false</bridged>' makes some sense. However, I'd
> > > generalize it to 'attachment' as I believe we'll have other types
> > > in the
> > > future (Macvtap, SRIOV and friends), so something like
> > > <attachment>bridge|sriov|macvtap|...</attachment>
> > > Y.
> > >
> > 
> > attachment would be at physical host level and could vary from host
> > to host.
> > this is about intended allowed usages of the logical network across
> > the
> > system
> 
> we should probably have a set of, so called, "usages" and not a
> single one. It should give enough
> flexibility for future usages with an easy upgrade.
> 
> something like:
> 
> <network>
>  <usages>management,display,VM</usages>
> <network>
> 
> or:
> 
>  <network>
>   <usages>
>    <usage>management</usage>
>    <usage>display</usage>
>    <usage>VM</usage>
>   </usages>
>  </network>
> 

+1 on the last suggestion for representing network usages.

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


From eedri at redhat.com  Mon Mar 26 16:42:36 2012
From: eedri at redhat.com (Eyal Edri)
Date: Mon, 26 Mar 2012 12:42:36 -0400 (EDT)
Subject: [Engine-devel] [Jenkins] ovirt engine unit tests failed
In-Reply-To: <e357196a-b6d1-44d0-9916-073a4e785de6@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <42944d4c-38dd-4636-a195-179bd28e7e87@zmail17.collab.prod.int.phx2.redhat.com>

ovirt-engine unit tests failed after this commit:

core : It is possible to clone preallocated COW VM from template on NFS storage domain (#805811) (detail / gitweb)


Failed test:
org.ovirt.engine.core.bll.AddVmCommandTest.create10GBVmWith11GbAvailableAndA5GbBuffer


please check: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/455/

eyal.


From msalem at redhat.com  Mon Mar 26 17:10:10 2012
From: msalem at redhat.com (Muli Salem)
Date: Mon, 26 Mar 2012 13:10:10 -0400 (EDT)
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <63e7e900-b5c6-4d89-8641-03ac149f7372@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <cbc331f8-d103-4cc9-a9ea-9373653d5f2d@zmail16.collab.prod.int.phx2.redhat.com>

Hi All,

Below please find a wiki page regarding the design of the Reloadable Configuration feature.
You are more than welcome to review and comment.

http://www.ovirt.org/wiki/Features/ReloadableConfiguration

Thanks,
Muli


From smizrahi at redhat.com  Mon Mar 26 19:53:53 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Mon, 26 Mar 2012 15:53:53 -0400 (EDT)
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <cbc331f8-d103-4cc9-a9ea-9373653d5f2d@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <1e7b67fe-f609-4cd4-b94b-c8b4e23a4caf@zmail16.collab.prod.int.phx2.redhat.com>

1. The column listing value is reloadable is redundant. Whether or not a value is "reloadable" or not is defined in the actual Engine code. Values that are currently not "reloadable" might become reloadable in the future. Putting this is the db just means you have to sync between the engine logic and the DB. I think this value should be obtained from the Engine dynamically and not persisted to disk.
2. Why don't configuration changes happen only through the Engine REST API? That way you always know when values change and you don't have to periodically reload. For cases where someone want's to change the values bypassing the API just make them use `service ovirt-engine reload` like every other daemon.
3. Values that cannot be refreshed without a restart will print a warning wither in the API response or to stderr for the service call.
something in the form of:
WARNING option XXXXX changed a reboot is required for it to take affect.
4. I also don't see why you write the data type to the DB (config type, column type). It's not like you are saving the values in binary format. It's just another case when this information is already written in code anyway and when you change it in code you will just have to do the book keeping and needlessly change it again in the DB. As a rule try and not use db values to document the code. This is what documentation is for.


These are things I'm not against I just want more explanation about:
1. Why even put the configuration in the DB? Data bases are notoriously strict and once you have schema you are committed to it. Having a regular config file might be simpler for users to edit and for you to maintain. The only reasons to use a DB as opposed to a flat file are ACID and scaleability. None of these are actually important for configuration.
2. The definition to what might not be "reloadable" seem arbitrary to me (eg. "Quartz services that are setup on startup and cannot be changed afterwords."). I admit I don't really know what Quartz services are, but I don't imagine it's impossible to write one that has at least one "reloadable" configuration value.

----- Original Message -----
> From: "Muli Salem" <msalem at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, March 26, 2012 1:10:10 PM
> Subject: [Engine-devel] Reloadable Configuration - Wiki Page
> 
> Hi All,
> 
> Below please find a wiki page regarding the design of the Reloadable
> Configuration feature.
> You are more than welcome to review and comment.
> 
> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
> 
> Thanks,
> Muli
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Tue Mar 27 06:18:17 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 27 Mar 2012 08:18:17 +0200
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <1e7b67fe-f609-4cd4-b94b-c8b4e23a4caf@zmail16.collab.prod.int.phx2.redhat.com>
References: <1e7b67fe-f609-4cd4-b94b-c8b4e23a4caf@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <4F715BA9.4020207@redhat.com>

On 03/26/2012 09:53 PM, Saggi Mizrahi wrote:
> 1. The column listing value is reloadable is redundant. Whether or not a value is "reloadable" or not is defined in the actual Engine code. Values that are currently not "reloadable" might become reloadable in the future. Putting this is the db just means you have to sync between the engine logic and the DB. I think this value should be obtained from the Engine dynamically and not persisted to disk.
> 2. Why don't configuration changes happen only through the Engine REST API? That way you always know when values change and you don't have to periodically reload. For cases where someone want's to change the values bypassing the API just make them use `service ovirt-engine reload` like every other daemon.
> 3. Values that cannot be refreshed without a restart will print a warning wither in the API response or to stderr for the service call.
> something in the form of:
> WARNING option XXXXX changed a reboot is required for it to take affect.
> 4. I also don't see why you write the data type to the DB (config type, column type). It's not like you are saving the values in binary format. It's just another case when this information is already written in code anyway and when you change it in code you will just have to do the book keeping and needlessly change it again in the DB. As a rule try and not use db values to document the code. This is what documentation is for.

a different take on this - why not just annotate the enums with this 
information?
also, not sure configuration should be reloaded per change 
automatically. maybe user wants it to happen on next restart, maybe some 
changes must happen together.
i.e., I'd expect a specific 'reconfigure' call to make it happen rather 
than poll for it.

> These are things I'm not against I just want more explanation about:
> 1. Why even put the configuration in the DB? Data bases are notoriously strict and once you have schema you are committed to it. Having a regular config file might be simpler for users to edit and for you to maintain. The only reasons to use a DB as opposed to a flat file are ACID and scaleability. None of these are actually important for configuration.
> 2. The definition to what might not be "reloadable" seem arbitrary to me (eg. "Quartz services that are setup on startup and cannot be changed afterwords."). I admit I don't really know what Quartz services are, but I don't imagine it's impossible to write one that has at least one "reloadable" configuration value.
>
> ----- Original Message -----
>> From: "Muli Salem"<msalem at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Monday, March 26, 2012 1:10:10 PM
>> Subject: [Engine-devel] Reloadable Configuration - Wiki Page
>>
>> Hi All,
>>
>> Below please find a wiki page regarding the design of the Reloadable
>> Configuration feature.
>> You are more than welcome to review and comment.
>>
>> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
>>
>> Thanks,
>> Muli
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From lpeer at redhat.com  Tue Mar 27 10:33:45 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 27 Mar 2012 12:33:45 +0200
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <1e7b67fe-f609-4cd4-b94b-c8b4e23a4caf@zmail16.collab.prod.int.phx2.redhat.com>
References: <1e7b67fe-f609-4cd4-b94b-c8b4e23a4caf@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <4F719789.3010504@redhat.com>

On 26/03/12 21:53, Saggi Mizrahi wrote:
> 1. The column listing value is reloadable is redundant. Whether or not a value is "reloadable" or not is defined in the actual Engine code. Values that are currently not "reloadable" might become reloadable in the future. Putting this is the db just means you have to sync between the engine logic and the DB. I think this value should be obtained from the Engine dynamically and not persisted to disk.

I agree, I think this should not be persist in the data base, a simple
annotation can do the work of marking a property as re-loadable or not.

> 2. Why don't configuration changes happen only through the Engine REST API? That way you always know when values change and you don't have to periodically reload. For cases where someone want's to change the values bypassing the API just make them use `service ovirt-engine reload` like every other daemon.

+1,
I think reloading configuration values should be only on demand.

> 3. Values that cannot be refreshed without a restart will print a warning wither in the API response or to stderr for the service call.
> something in the form of:
> WARNING option XXXXX changed a reboot is required for it to take affect.

A nice to have IMO, we don't have it today and all values change require
reboot.

> 4. I also don't see why you write the data type to the DB (config type, column type). It's not like you are saving the values in binary format. It's just another case when this information is already written in code anyway and when you change it in code you will just have to do the book keeping and needlessly change it again in the DB. As a rule try and not use db values to document the code. This is what documentation is for.

I think it is used for validations but I don't really remember I can
take a look.

> 
> 
> These are things I'm not against I just want more explanation about:
> 1. Why even put the configuration in the DB? Data bases are notoriously strict and once you have schema you are committed to it.

What do you mean by committed to it?
the DB schema is not part of the API, we change it as we go.

>same as having a property file and changing the key in it (only the
upgrade process is much easier when you are using data base).
> Having a regular config file might be simpler for users to edit and for you to maintain.

not sure what you mean by 'regular', in the enterprise management world
storing configuration in data base is a regular thing to do.

> The only reasons to use a DB as opposed to a flat file are ACID and scaleability. None of these are actually important for configuration.

And the tools you have for data bases which make the maintaining process
much easier.

> 2. The definition to what might not be "reloadable" seem arbitrary to me (eg. "Quartz services that are setup on startup and cannot be changed afterwords."). 
> I admit I don't really know what Quartz services are, but I don't
imagine it's impossible to write one that has at least one "reloadable"
configuration value.

The definition of what is reloadable is based on how much work it takes
to change it from a static config to a reloadable config.

Of course you can reload the time configuration used by a quartz service
it requires to cancel the job and reschedule it with the new
configuration value. it is just not as easy as the other changes that's
why this is the 4th phase of this feature.


> 
> ----- Original Message -----
>> From: "Muli Salem" <msalem at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Monday, March 26, 2012 1:10:10 PM
>> Subject: [Engine-devel] Reloadable Configuration - Wiki Page
>>
>> Hi All,
>>
>> Below please find a wiki page regarding the design of the Reloadable
>> Configuration feature.
>> You are more than welcome to review and comment.
>>
>> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
>>
>> Thanks,
>> Muli
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From yzaslavs at redhat.com  Tue Mar 27 11:20:01 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 27 Mar 2012 13:20:01 +0200
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <4F715BA9.4020207@redhat.com>
References: <1e7b67fe-f609-4cd4-b94b-c8b4e23a4caf@zmail16.collab.prod.int.phx2.redhat.com>
	<4F715BA9.4020207@redhat.com>
Message-ID: <4F71A261.1090205@redhat.com>

On 03/27/2012 08:18 AM, Itamar Heim wrote:
> On 03/26/2012 09:53 PM, Saggi Mizrahi wrote:
>> 1. The column listing value is reloadable is redundant. Whether or not
>> a value is "reloadable" or not is defined in the actual Engine code.
>> Values that are currently not "reloadable" might become reloadable in
>> the future. Putting this is the db just means you have to sync between
>> the engine logic and the DB. I think this value should be obtained
>> from the Engine dynamically and not persisted to disk.
>> 2. Why don't configuration changes happen only through the Engine REST
>> API? That way you always know when values change and you don't have to
>> periodically reload. For cases where someone want's to change the
>> values bypassing the API just make them use `service ovirt-engine
>> reload` like every other daemon.
>> 3. Values that cannot be refreshed without a restart will print a
>> warning wither in the API response or to stderr for the service call.
>> something in the form of:
>> WARNING option XXXXX changed a reboot is required for it to take affect.
>> 4. I also don't see why you write the data type to the DB (config
>> type, column type). It's not like you are saving the values in binary
>> format. It's just another case when this information is already

Agreed. Current code in engine-core uses a generic method to get the
value, and uses @TypeConverterAttribute annotation to give indication to
which type the data should be "cast" to.
See DbConfigUtils.parseValue(String value, String name,
java.lang.Class<?> fieldType)

>> written in code anyway and when you change it in code you will just
>> have to do the book keeping and needlessly change it again in the DB.
>> As a rule try and not use db values to document the code. This is what
>> documentation is for.
> 
> a different take on this - why not just annotate the enums with this
> information?

+1 On annotation idea - although this introduces "information on
behavior" to code, and any change will require re-compiling, I don't see
why anyone would like to change the behavior.

> also, not sure configuration should be reloaded per change
> automatically. maybe user wants it to happen on next restart, maybe some
> changes must happen together.
> i.e., I'd expect a specific 'reconfigure' call to make it happen rather
> than poll for it.
> 
>> These are things I'm not against I just want more explanation about:
>> 1. Why even put the configuration in the DB? Data bases are
>> notoriously strict and once you have schema you are committed to it.
>> Having a regular config file might be simpler for users to edit and
>> for you to maintain. The only reasons to use a DB as opposed to a flat
>> file are ACID and scaleability. None of these are actually important
>> for configuration.
>> 2. The definition to what might not be "reloadable" seem arbitrary to
>> me (eg. "Quartz services that are setup on startup and cannot be
>> changed afterwords."). I admit I don't really know what Quartz
>> services are, but I don't imagine it's impossible to write one that
>> has at least one "reloadable" configuration value.
Muli - are you sure about Quartz? Have you checked it out?

>>
>> ----- Original Message -----
>>> From: "Muli Salem"<msalem at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Sent: Monday, March 26, 2012 1:10:10 PM
>>> Subject: [Engine-devel] Reloadable Configuration - Wiki Page
>>>
>>> Hi All,
>>>
>>> Below please find a wiki page regarding the design of the Reloadable
>>> Configuration feature.
>>> You are more than welcome to review and comment.
>>>
>>> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
>>>
>>> Thanks,
>>> Muli
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From atal at redhat.com  Tue Mar 27 11:41:18 2012
From: atal at redhat.com (avi tal)
Date: Tue, 27 Mar 2012 13:41:18 +0200
Subject: [Engine-devel] checking
Message-ID: <4F71A75E.1000102@redhat.com>




From atal at redhat.com  Tue Mar 27 11:46:56 2012
From: atal at redhat.com (avi tal)
Date: Tue, 27 Mar 2012 13:46:56 +0200
Subject: [Engine-devel] check
Message-ID: <4F71A8B0.5030809@redhat.com>




From atal at redhat.com  Tue Mar 27 12:11:27 2012
From: atal at redhat.com (avi tal)
Date: Tue, 27 Mar 2012 14:11:27 +0200
Subject: [Engine-devel] Extend host_nics action with UpdateNetworks
Message-ID: <4F71AE6F.6030703@redhat.com>

Hi,
I am checking the SetupNetwork feature in 3.1 (si01) and I think we are 
missing a very important implementation.
SetupNetworks in vdsm layer is able to receive a nics collection which 
describe which nics will be updated and handle only those nics.
This implementation is missing from engine-backend because backend 
automatically treat missing nics as nics we would like to remove.
A very buggy scenario would be, missing mgmt network.

The idea is to send (via REST API) a collection which contain only the 
interfaces (nics) we would like to update.

This is actually an UPDATE collection procedure. it could be added as a 
different action:
http://engine ip:port/hosts/id/nics/*updatenetworks*

I believe it is a part of the SetupNetwork feature that needs to be in 3.1.

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120327/c39eb5fb/attachment.html>

From yzaslavs at redhat.com  Tue Mar 27 13:41:04 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 27 Mar 2012 15:41:04 +0200
Subject: [Engine-devel] Feature: backend support for Advanced NFS Options
In-Reply-To: <e3317eff-c7bb-486a-8305-fd0b62bdea70@zmail01.collab.prod.int.phx2.redhat.com>
References: <e3317eff-c7bb-486a-8305-fd0b62bdea70@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <4F71C370.1040108@redhat.com>

On 03/26/2012 03:01 PM, Laszlo Hornyak wrote:
> Hi,
> 
> http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#Changes_in_ovirt_engine
> 
> Your feedback is welcome.

Few comments -
a. Do we want to edit the options while storage domain is in maintenance
mode?
b. Maybe calling this field "mount_options" (and not "nfs_options)
(thinking about making it reusable for PosixFS feature).



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


From lhornyak at redhat.com  Tue Mar 27 13:50:16 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 27 Mar 2012 09:50:16 -0400 (EDT)
Subject: [Engine-devel] Feature: backend support for Advanced NFS Options
In-Reply-To: <4F71C370.1040108@redhat.com>
Message-ID: <bfd37a33-a1f9-436b-b890-2cfe0f3c13f1@zmail01.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, March 27, 2012 3:41:04 PM
> Subject: Re: [Engine-devel] Feature: backend support for Advanced NFS Options
> 
> On 03/26/2012 03:01 PM, Laszlo Hornyak wrote:
> > Hi,
> > 
> > http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#Changes_in_ovirt_engine
> > 
> > Your feedback is welcome.
> 
> Few comments -
> a. Do we want to edit the options while storage domain is in
> maintenance
> mode?

I guess when it is in maintenance mode, the behavior should be that it should not be reconnected, but only the mount options stored. If the mount options are wrong... I think the domain will fallback when trying to activate.

> b. Maybe calling this field "mount_options" (and not "nfs_options)
> (thinking about making it reusable for PosixFS feature).

Ah yes, last time I was editing this page the wiki crashed fopr a few hours and I forgot about it, but it was meant to be mount_options instead of nfs_options.

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


From yzaslavs at redhat.com  Tue Mar 27 13:58:52 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 27 Mar 2012 15:58:52 +0200
Subject: [Engine-devel] Feature: backend support for Advanced NFS Options
In-Reply-To: <bfd37a33-a1f9-436b-b890-2cfe0f3c13f1@zmail01.collab.prod.int.phx2.redhat.com>
References: <bfd37a33-a1f9-436b-b890-2cfe0f3c13f1@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <4F71C79C.8030106@redhat.com>

On 03/27/2012 03:50 PM, Laszlo Hornyak wrote:
> 
> 
> ----- Original Message -----
>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>> To: "Laszlo Hornyak" <lhornyak at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Tuesday, March 27, 2012 3:41:04 PM
>> Subject: Re: [Engine-devel] Feature: backend support for Advanced NFS Options
>>
>> On 03/26/2012 03:01 PM, Laszlo Hornyak wrote:
>>> Hi,
>>>
>>> http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#Changes_in_ovirt_engine
>>>
>>> Your feedback is welcome.
>>
>> Few comments -
>> a. Do we want to edit the options while storage domain is in
>> maintenance
>> mode?
> 
> I guess when it is in maintenance mode, the behavior should be that it should not be reconnected, but only the mount options stored. If the mount options are wrong... I think the domain will fallback when trying to activate.
Not sure I understood you here - what I meant is, that after
maintainable you can activate the domain - so , why not let edit the
options so you perform the connection with different parameters values
(i.e - increase retrans value).
> 
>> b. Maybe calling this field "mount_options" (and not "nfs_options)
>> (thinking about making it reusable for PosixFS feature).
> 
> Ah yes, last time I was editing this page the wiki crashed fopr a few hours and I forgot about it, but it was meant to be mount_options instead of nfs_options.
> 
>>
>>
>>
>>>
>>> Laszlo
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From simon at redhat.com  Tue Mar 27 13:58:01 2012
From: simon at redhat.com (Simon Grinberg)
Date: Tue, 27 Mar 2012 09:58:01 -0400 (EDT)
Subject: [Engine-devel] Extend host_nics action with UpdateNetworks
In-Reply-To: <4F71AE6F.6030703@redhat.com>
Message-ID: <be62cfb3-7e6a-4346-85f0-478e8243c12f@zmail17.collab.prod.int.phx2.redhat.com>


----- Original Message ----- 

> From: "avi tal" <atal at redhat.com>
> To: engine-devel at ovirt.org
> Cc: "Oded Ramraz" <oramraz at redhat.com>, "Roy Golan"
> <rgolan at redhat.com>, "michael pasternak" <mpastern at redhat.com>,
> "Simon Grinberg" <simon at redhat.com>
> Sent: Tuesday, March 27, 2012 2:11:27 PM
> Subject: Extend host_nics action with UpdateNetworks

> Hi,
> I am checking the SetupNetwork feature in 3.1 (si01) and I think we
> are missing a very important implementation.
> SetupNetworks in vdsm layer is able to receive a nics collection
> which describe which nics will be updated and handle only those
> nics.
> This implementation is missing from engine-backend because backend
> automatically treat missing nics as nics we would like to remove.
> A very buggy scenario would be, missing mgmt network.

> The idea is to send (via REST API) a collection which contain only
> the interfaces (nics) we would like to update.

> This is actually an UPDATE collection procedure. it could be added as
> a different action:
> http://engine ip:port/hosts/id/nics/ updatenetworks

> I believe it is a part of the SetupNetwork feature that needs to be
> in 3.1.

+1

While for web UI it makes sense to do it in Read/Modify/Write fashion, meaning that the setup network dialogue shows the complete picture, allows the user to modify and then write it back. It does not make sense to force the same on an API user.

Consider a user that just wants to remove/add two logical networks on bond X. Does he really have to read it all, then add the networks, then send back? It makes sense to explicitly say update: add only those two on bond X - do not touch the rest.

This means though that the updateNetworks command has to explicitly say remove/add/update per network.  

> Thanks


From yzaslavs at redhat.com  Tue Mar 27 14:27:44 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 27 Mar 2012 16:27:44 +0200
Subject: [Engine-devel] How to utilize Jenkins to do your dirty (build)
	work for you...
In-Reply-To: <0210de81-3776-4c65-bbc6-1dffd4e59df8@zmail14.collab.prod.int.phx2.redhat.com>
References: <0210de81-3776-4c65-bbc6-1dffd4e59df8@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F71CE60.8040609@redhat.com>

On 03/26/2012 04:08 PM, Mike Kolesnik wrote:
> Hi, 
> 
> 
> -- Intro -- 
>   When working on your local GIT repo you probably do a lot of: 
>     mvn clean install 
> 
>   Additionally, if you're working on oVirt-engine you might be doing some of: 
>     mvn test -Penable-dao-tests 
>     mvn install -Pgwt-admin 
>     etc.. 
> 
>   This, of course, might take your development computer a while, and hog your resources. 
> 
>   Usually though, if you work on oVirt, you have a host that you use for testing your changes.. 
>   This host probably has a 2/4 cores CPU and at least 4Gb of RAM.. 
> 
>   This host is sitting quietly most of the time, consuming mostly electricity but not doing much. 
>   You're probably not even utilizing it that much even when you are testing something on it. 
>   It is like a powerful guard dog that you keep tied in the back-yard most of the time, instead of letting it run free. 
> 
>   Well, I have a suggestion how to put that puppy into good use and also free up your resources.. 
> 
> -- End Intro -- 
> 
> You can install Jenkins on the host, and have it monitor your local GIT repo for changes, building your commits as necessary.
> This works with every local branch you have - Jenkins will pick up the change (be it a local commit you just did, or a rebase over the origin) and generate a build for it.
> 
> This will allow you to monitor your build results just as you would monitor locally, while in the same time utilize a (probably) more powerful machine to do this for you. It will also probably speed up your build cycle, as builds will be executed in parallel. 
> 
> I have written an installation guide which explains how to do it in the oVirt wiki: 
>   http://www.ovirt.org/wiki/Local_Jenkins_For_The_People 
> 
> I have also written a script that will run the installation part on the host for you, 
> so you just need to download the attachment and run it as root on the host, but you will still need to do some manual work so make sure to check the wiki.
> 
> -- Example Jobs --
>   I am also attaching sample jobs to import to Jenkins.
>   Make sure to replace the GIT repo URL, you can do this before importing with sed:
>    # sed -i 's#[git-repo-url]#ssh://[user]@[git-host]/[git-repo-location]#' oVirt-engine.*
> 
>   For example:
>    # sed -i 's#[git-repo-url]#ssh://mkolesni at myhost/~/git/ovirt-engine#' oVirt-engine.*
> 
>   You can import them with the command:
>    # cat [job].xml | java -jar /tmp/jenkins-cli.jar -s http://localhost:8080 create-job [job-name]
> 
>   For example:
>    # cat oVirt-engine.xml | java -jar /tmp/jenkins-cli.jar -s http://localhost:8080 create-job oVirt-engine
> -- End Example Jobs --
> 
> Of course, this might not be ideal in cases when you need 100% percent of your host.. 
> But in such a case you can simply turn off Jenkins, and turn it back on later. ;) 

Great idea.
One comment -
I noticed that if u specify */* in "branches to build" then it of course
fetches for you all the branches. If you want to build the current
branch you're working on - use HEAD instead.

> 
> 
> Regards, 
> Mike 



From mkolesni at redhat.com  Tue Mar 27 15:02:52 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Tue, 27 Mar 2012 11:02:52 -0400 (EDT)
Subject: [Engine-devel] How to utilize Jenkins to do your dirty (build)
	work for you...
In-Reply-To: <4F71CE60.8040609@redhat.com>
Message-ID: <65224afb-1466-45f3-bd6d-d9b61f562234@zmail14.collab.prod.int.phx2.redhat.com>

> On 03/26/2012 04:08 PM, Mike Kolesnik wrote:
> > Hi,
> > 
> > 
> > -- Intro --
> >   When working on your local GIT repo you probably do a lot of:
> >     mvn clean install
> > 
> >   Additionally, if you're working on oVirt-engine you might be
> >   doing some of:
> >     mvn test -Penable-dao-tests
> >     mvn install -Pgwt-admin
> >     etc..
> > 
> >   This, of course, might take your development computer a while,
> >   and hog your resources.
> > 
> >   Usually though, if you work on oVirt, you have a host that you
> >   use for testing your changes..
> >   This host probably has a 2/4 cores CPU and at least 4Gb of RAM..
> > 
> >   This host is sitting quietly most of the time, consuming mostly
> >   electricity but not doing much.
> >   You're probably not even utilizing it that much even when you are
> >   testing something on it.
> >   It is like a powerful guard dog that you keep tied in the
> >   back-yard most of the time, instead of letting it run free.
> > 
> >   Well, I have a suggestion how to put that puppy into good use and
> >   also free up your resources..
> > 
> > -- End Intro --
> > 
> > You can install Jenkins on the host, and have it monitor your local
> > GIT repo for changes, building your commits as necessary.
> > This works with every local branch you have - Jenkins will pick up
> > the change (be it a local commit you just did, or a rebase over
> > the origin) and generate a build for it.
> > 
> > This will allow you to monitor your build results just as you would
> > monitor locally, while in the same time utilize a (probably) more
> > powerful machine to do this for you. It will also probably speed
> > up your build cycle, as builds will be executed in parallel.
> > 
> > I have written an installation guide which explains how to do it in
> > the oVirt wiki:
> >   http://www.ovirt.org/wiki/Local_Jenkins_For_The_People
> > 
> > I have also written a script that will run the installation part on
> > the host for you,
> > so you just need to download the attachment and run it as root on
> > the host, but you will still need to do some manual work so make
> > sure to check the wiki.
> > 
> > -- Example Jobs --
> >   I am also attaching sample jobs to import to Jenkins.
> >   Make sure to replace the GIT repo URL, you can do this before
> >   importing with sed:
> >    # sed -i
> >    's#[git-repo-url]#ssh://[user]@[git-host]/[git-repo-location]#'
> >    oVirt-engine.*
> > 
> >   For example:
> >    # sed -i
> >    's#[git-repo-url]#ssh://mkolesni at myhost/~/git/ovirt-engine#'
> >    oVirt-engine.*
> > 
> >   You can import them with the command:
> >    # cat [job].xml | java -jar /tmp/jenkins-cli.jar -s
> >    http://localhost:8080 create-job [job-name]
> > 
> >   For example:
> >    # cat oVirt-engine.xml | java -jar /tmp/jenkins-cli.jar -s
> >    http://localhost:8080 create-job oVirt-engine
> > -- End Example Jobs --
> > 
> > Of course, this might not be ideal in cases when you need 100%
> > percent of your host..
> > But in such a case you can simply turn off Jenkins, and turn it
> > back on later. ;)
> 
> Great idea.
> One comment -
> I noticed that if u specify */* in "branches to build" then it of
> course
> fetches for you all the branches. If you want to build the current
> branch you're working on - use HEAD instead.

Yes that should work relatively well, but it limits you in the sense that it ONLY monitors the HEAD, while if you use default (** or */*) then it will monitor changes on all branches regardless if you on them or not - it could be a double edged sword if you have a lot of garbage in the repo, but on the other hand it might drive you to clean it :)

> 
> > 
> > 
> > Regards,
> > Mike
> 
> 


From yzaslavs at redhat.com  Tue Mar 27 17:33:18 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 27 Mar 2012 19:33:18 +0200
Subject: [Engine-devel] Getting rid of PowerMock?
Message-ID: <4F71F9DE.5030403@redhat.com>

Hi all,
As (almost) all of us can see,
Running BLL tests both takes considerable time, and also we have to take
class loading dependencies between classes with static methods when we
use mockStatic - IMHO, this is kinda frustrating.
Maybe we should start get rid of  PowerMock.
Here is what I'm thinking of -
Currently, as we use no IoC for DAOs , for tested class we do not use
DbFacade.getInstance().getXXXDao()

instead we define:

protected XXXDao getXXXDao() {
  return DBFacade.getInstance().getXXXDao();
}

And then in our tests we use Mockito to define how getXXDao acts in the
test.

The following can be achieved also for config values , the following way -

protected <T> T getConfig(ConfigValues key) {
        return Config.<T> GetValue(key);
    }

And then in code (for example, in a query test) -

 doReturn(5).when(query).<Integer>
getConfig(any(ConfigValues.SomeIntegerConstant));


This effort can be done in small steps -
a. Define getConfig method in base classes (i.e AuditLoggalbeBase).
b. Rewrite parts (i.e Commands, and their tests) step by step (small
commits)

Thoughts and ideas are more than welcome,

Yair


From iheim at redhat.com  Wed Mar 28 07:06:45 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 28 Mar 2012 09:06:45 +0200
Subject: [Engine-devel] Feature: backend support for Advanced NFS Options
In-Reply-To: <bfd37a33-a1f9-436b-b890-2cfe0f3c13f1@zmail01.collab.prod.int.phx2.redhat.com>
References: <bfd37a33-a1f9-436b-b890-2cfe0f3c13f1@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <4F72B885.4090504@redhat.com>

On 03/27/2012 03:50 PM, Laszlo Hornyak wrote:
>
>
> ----- Original Message -----
>> From: "Yair Zaslavsky"<yzaslavs at redhat.com>
>> To: "Laszlo Hornyak"<lhornyak at redhat.com>
>> Cc: "engine-devel"<engine-devel at ovirt.org>
>> Sent: Tuesday, March 27, 2012 3:41:04 PM
>> Subject: Re: [Engine-devel] Feature: backend support for Advanced NFS Options
>>
>> On 03/26/2012 03:01 PM, Laszlo Hornyak wrote:
>>> Hi,
>>>
>>> http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#Changes_in_ovirt_engine
>>>
>>> Your feedback is welcome.
>>
>> Few comments -
>> a. Do we want to edit the options while storage domain is in
>> maintenance
>> mode?
>
> I guess when it is in maintenance mode, the behavior should be that it should not be reconnected, but only the mount options stored. If the mount options are wrong... I think the domain will fallback when trying to activate.
>
>> b. Maybe calling this field "mount_options" (and not "nfs_options)
>> (thinking about making it reusable for PosixFS feature).
>
> Ah yes, last time I was editing this page the wiki crashed fopr a few hours and I forgot about it, but it was meant to be mount_options instead of nfs_options.

actually, why not make this generic as storage_domain_options, which 
could be used like custom properties for hooks later on?


From yzaslavs at redhat.com  Wed Mar 28 07:18:20 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 28 Mar 2012 09:18:20 +0200
Subject: [Engine-devel] Feature: backend support for Advanced NFS Options
In-Reply-To: <4F72B885.4090504@redhat.com>
References: <bfd37a33-a1f9-436b-b890-2cfe0f3c13f1@zmail01.collab.prod.int.phx2.redhat.com>
	<4F72B885.4090504@redhat.com>
Message-ID: <4F72BB3C.9060908@redhat.com>

On 03/28/2012 09:06 AM, Itamar Heim wrote:
> On 03/27/2012 03:50 PM, Laszlo Hornyak wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Yair Zaslavsky"<yzaslavs at redhat.com>
>>> To: "Laszlo Hornyak"<lhornyak at redhat.com>
>>> Cc: "engine-devel"<engine-devel at ovirt.org>
>>> Sent: Tuesday, March 27, 2012 3:41:04 PM
>>> Subject: Re: [Engine-devel] Feature: backend support for Advanced NFS
>>> Options
>>>
>>> On 03/26/2012 03:01 PM, Laszlo Hornyak wrote:
>>>> Hi,
>>>>
>>>> http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#Changes_in_ovirt_engine
>>>>
>>>>
>>>> Your feedback is welcome.
>>>
>>> Few comments -
>>> a. Do we want to edit the options while storage domain is in
>>> maintenance
>>> mode?
>>
>> I guess when it is in maintenance mode, the behavior should be that it
>> should not be reconnected, but only the mount options stored. If the
>> mount options are wrong... I think the domain will fallback when
>> trying to activate.
>>
>>> b. Maybe calling this field "mount_options" (and not "nfs_options)
>>> (thinking about making it reusable for PosixFS feature).
>>
>> Ah yes, last time I was editing this page the wiki crashed fopr a few
>> hours and I forgot about it, but it was meant to be mount_options
>> instead of nfs_options.
> 
> actually, why not make this generic as storage_domain_options, which
> could be used like custom properties for hooks later on?
I thought we're talking about options passed to "-O" (mount -O ).
If we want to have more generalization, we should probably have a "key
value" pair, similar to custom properties, as you suggested.


From lhornyak at redhat.com  Wed Mar 28 07:23:56 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 28 Mar 2012 03:23:56 -0400 (EDT)
Subject: [Engine-devel] Getting rid of PowerMock?
In-Reply-To: <4F71F9DE.5030403@redhat.com>
Message-ID: <4c641a6a-2552-4e41-ae6d-bbeb159dabcd@zmail01.collab.prod.int.phx2.redhat.com>

Hi,

How much faster could the unit tests run after removing powermock and using the instance methods instead?

I like this idea anyway because it could be a step towards dependency injection.
Could be a more motivating long term objective than just to get rid of powermock :)

Laszlo

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, March 27, 2012 7:33:18 PM
> Subject: [Engine-devel] Getting rid of PowerMock?
> 
> Hi all,
> As (almost) all of us can see,
> Running BLL tests both takes considerable time, and also we have to
> take
> class loading dependencies between classes with static methods when
> we
> use mockStatic - IMHO, this is kinda frustrating.
> Maybe we should start get rid of  PowerMock.
> Here is what I'm thinking of -
> Currently, as we use no IoC for DAOs , for tested class we do not use
> DbFacade.getInstance().getXXXDao()
> 
> instead we define:
> 
> protected XXXDao getXXXDao() {
>   return DBFacade.getInstance().getXXXDao();
> }
> 
> And then in our tests we use Mockito to define how getXXDao acts in
> the
> test.
> 
> The following can be achieved also for config values , the following
> way -
> 
> protected <T> T getConfig(ConfigValues key) {
>         return Config.<T> GetValue(key);
>     }
> 
> And then in code (for example, in a query test) -
> 
>  doReturn(5).when(query).<Integer>
> getConfig(any(ConfigValues.SomeIntegerConstant));
> 
> 
> This effort can be done in small steps -
> a. Define getConfig method in base classes (i.e AuditLoggalbeBase).
> b. Rewrite parts (i.e Commands, and their tests) step by step (small
> commits)
> 
> Thoughts and ideas are more than welcome,
> 
> Yair
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mkolesni at redhat.com  Wed Mar 28 07:26:34 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Wed, 28 Mar 2012 03:26:34 -0400 (EDT)
Subject: [Engine-devel] Getting rid of PowerMock?
In-Reply-To: <4F71F9DE.5030403@redhat.com>
Message-ID: <c6bacc90-2293-409f-a041-77c0ecc7bc14@zmail14.collab.prod.int.phx2.redhat.com>

> Hi all,
> As (almost) all of us can see,

Almost ;)

> Running BLL tests both takes considerable time, and also we have to
> take
> class loading dependencies between classes with static methods when
> we
> use mockStatic - IMHO, this is kinda frustrating.
> Maybe we should start get rid of  PowerMock.

+ 1
PowerMock is the root of all evil...
Seriously, it costs more than it's worth..

> Here is what I'm thinking of -
> Currently, as we use no IoC for DAOs , for tested class we do not use
> DbFacade.getInstance().getXXXDao()
> 
> instead we define:
> 
> protected XXXDao getXXXDao() {
>   return DBFacade.getInstance().getXXXDao();
> }
> 
> And then in our tests we use Mockito to define how getXXDao acts in
> the
> test.
> 
> The following can be achieved also for config values , the following
> way -
> 
> protected <T> T getConfig(ConfigValues key) {
>         return Config.<T> GetValue(key);
>     }
> 
> And then in code (for example, in a query test) -
> 
>  doReturn(5).when(query).<Integer>
> getConfig(any(ConfigValues.SomeIntegerConstant));

This is true for all static calls that do something other than 'util' stuff.
That is, if the static call is accessing DB or VDSM then it can be defined in a protected method that will be mocked out when spying.
However I (obviously) don't see any use mocking out calls such as Arrays.asList(...).

> 
> 
> This effort can be done in small steps -
> a. Define getConfig method in base classes (i.e AuditLoggalbeBase).

I would put it in command bases, since this doesn't have anything to do with logging.

> b. Rewrite parts (i.e Commands, and their tests) step by step (small
> commits)
> 
> Thoughts and ideas are more than welcome,
> 
> Yair
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Wed Mar 28 07:31:34 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 28 Mar 2012 09:31:34 +0200
Subject: [Engine-devel] Getting rid of PowerMock?
In-Reply-To: <4c641a6a-2552-4e41-ae6d-bbeb159dabcd@zmail01.collab.prod.int.phx2.redhat.com>
References: <4c641a6a-2552-4e41-ae6d-bbeb159dabcd@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <4F72BE56.7070805@redhat.com>

On 03/28/2012 09:23 AM, Laszlo Hornyak wrote:
> Hi,
> 
> How much faster could the unit tests run after removing powermock and using the instance methods instead?
Faster. I remind you we reached OutOfMemory when using PowerMock (it
consumes lots of memory) and we had to split the tests and run them on
separate java processes.

> 
> I like this idea anyway because it could be a step towards dependency injection.
> Could be a more motivating long term objective than just to get rid of powermock :)

I totally agree here.

> 
> Laszlo
> 
> ----- Original Message -----
>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Tuesday, March 27, 2012 7:33:18 PM
>> Subject: [Engine-devel] Getting rid of PowerMock?
>>
>> Hi all,
>> As (almost) all of us can see,
>> Running BLL tests both takes considerable time, and also we have to
>> take
>> class loading dependencies between classes with static methods when
>> we
>> use mockStatic - IMHO, this is kinda frustrating.
>> Maybe we should start get rid of  PowerMock.
>> Here is what I'm thinking of -
>> Currently, as we use no IoC for DAOs , for tested class we do not use
>> DbFacade.getInstance().getXXXDao()
>>
>> instead we define:
>>
>> protected XXXDao getXXXDao() {
>>   return DBFacade.getInstance().getXXXDao();
>> }
>>
>> And then in our tests we use Mockito to define how getXXDao acts in
>> the
>> test.
>>
>> The following can be achieved also for config values , the following
>> way -
>>
>> protected <T> T getConfig(ConfigValues key) {
>>         return Config.<T> GetValue(key);
>>     }
>>
>> And then in code (for example, in a query test) -
>>
>>  doReturn(5).when(query).<Integer>
>> getConfig(any(ConfigValues.SomeIntegerConstant));
>>
>>
>> This effort can be done in small steps -
>> a. Define getConfig method in base classes (i.e AuditLoggalbeBase).
>> b. Rewrite parts (i.e Commands, and their tests) step by step (small
>> commits)
>>
>> Thoughts and ideas are more than welcome,
>>
>> Yair
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From lhornyak at redhat.com  Wed Mar 28 08:36:57 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 28 Mar 2012 04:36:57 -0400 (EDT)
Subject: [Engine-devel] Getting rid of PowerMock?
In-Reply-To: <4F72BE56.7070805@redhat.com>
Message-ID: <e04e6eac-0902-4092-8439-a93a241c86f6@zmail01.collab.prod.int.phx2.redhat.com>


----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, March 28, 2012 9:31:34 AM
> Subject: Re: [Engine-devel] Getting rid of PowerMock?
> 
> On 03/28/2012 09:23 AM, Laszlo Hornyak wrote:
> > Hi,
> > 
> > How much faster could the unit tests run after removing powermock
> > and using the instance methods instead?
> Faster. I remind you we reached OutOfMemory when using PowerMock (it
> consumes lots of memory) and we had to split the tests and run them
> on
> separate java processes.

Ah yes, I had to set the maxpermsize to 1.5 GB to run sonar on the backend, even when running with forkmode=always
I do not care about unit-test speed that much but that memory size is crazy.

I have seen this approach in QuotaHelper and I did not completely understand why instantiate a Util object just in order to have instance methods to call static methods, so I submitted this patch http://gerrit.ovirt.org/#change,3008 as a response to Allon's patch http://gerrit.ovirt.org/#change,2975

Now I understand the idea, but for Helper / Util classes, we do not have to instantiate. We can keep all the methods still static and pass over all the data it is running with, rather than using a global variable or hiding the global variable with an overrideable instance method. E.g. in this case, we could pass the DAO classes as argument to static methods.


> 
> > 
> > I like this idea anyway because it could be a step towards
> > dependency injection.
> > Could be a more motivating long term objective than just to get rid
> > of powermock :)
> 
> I totally agree here.
> 
> > 
> > Laszlo
> > 
> > ----- Original Message -----
> >> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> >> To: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Tuesday, March 27, 2012 7:33:18 PM
> >> Subject: [Engine-devel] Getting rid of PowerMock?
> >>
> >> Hi all,
> >> As (almost) all of us can see,
> >> Running BLL tests both takes considerable time, and also we have
> >> to
> >> take
> >> class loading dependencies between classes with static methods
> >> when
> >> we
> >> use mockStatic - IMHO, this is kinda frustrating.
> >> Maybe we should start get rid of  PowerMock.
> >> Here is what I'm thinking of -
> >> Currently, as we use no IoC for DAOs , for tested class we do not
> >> use
> >> DbFacade.getInstance().getXXXDao()
> >>
> >> instead we define:
> >>
> >> protected XXXDao getXXXDao() {
> >>   return DBFacade.getInstance().getXXXDao();
> >> }
> >>
> >> And then in our tests we use Mockito to define how getXXDao acts
> >> in
> >> the
> >> test.
> >>
> >> The following can be achieved also for config values , the
> >> following
> >> way -
> >>
> >> protected <T> T getConfig(ConfigValues key) {
> >>         return Config.<T> GetValue(key);
> >>     }
> >>
> >> And then in code (for example, in a query test) -
> >>
> >>  doReturn(5).when(query).<Integer>
> >> getConfig(any(ConfigValues.SomeIntegerConstant));
> >>
> >>
> >> This effort can be done in small steps -
> >> a. Define getConfig method in base classes (i.e
> >> AuditLoggalbeBase).
> >> b. Rewrite parts (i.e Commands, and their tests) step by step
> >> (small
> >> commits)
> >>
> >> Thoughts and ideas are more than welcome,
> >>
> >> Yair
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 


From masayag at redhat.com  Wed Mar 28 08:55:35 2012
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 28 Mar 2012 10:55:35 +0200
Subject: [Engine-devel] Getting rid of PowerMock?
In-Reply-To: <4F71F9DE.5030403@redhat.com>
References: <4F71F9DE.5030403@redhat.com>
Message-ID: <4F72D207.6040407@redhat.com>

On 03/27/2012 07:33 PM, Yair Zaslavsky wrote:
> Hi all,
> As (almost) all of us can see,
> Running BLL tests both takes considerable time, and also we have to take
> class loading dependencies between classes with static methods when we
> use mockStatic - IMHO, this is kinda frustrating.
> Maybe we should start get rid of  PowerMock.
> Here is what I'm thinking of -
> Currently, as we use no IoC for DAOs , for tested class we do not use
> DbFacade.getInstance().getXXXDao()
> 
> instead we define:
> 
> protected XXXDao getXXXDao() {
>   return DBFacade.getInstance().getXXXDao();
> }
> 

+1 for this. IMO all DAOs should be reachable from the CommandBase as
this is a repeated code scattered in the various commands.

I'd suggest to create an interface that declares all of available DAOs.
The new interface should be implemented by both DbFacade (which already
contains that implementation) and CommandBase to assure new DAOs added
to DbFacade will be added to the CommandBase as well.

> And then in our tests we use Mockito to define how getXXDao acts in the
> test.
> 
> The following can be achieved also for config values , the following way -
> 
> protected <T> T getConfig(ConfigValues key) {
>         return Config.<T> GetValue(key);
>     }
> 
> And then in code (for example, in a query test) -
> 
>  doReturn(5).when(query).<Integer>
> getConfig(any(ConfigValues.SomeIntegerConstant));
> 
> 
> This effort can be done in small steps -
> a. Define getConfig method in base classes (i.e AuditLoggalbeBase).
> b. Rewrite parts (i.e Commands, and their tests) step by step (small
> commits)
> 
> Thoughts and ideas are more than welcome,

Searching for the static mocked classes brought the following list:

      1 AuditLogDirector.class
      1 CommandsFactory.class
      1 FileUtil.class
      1 LoggerFactory.class
      1 QuotaHelper.class
      1 QuotaManager.class
      1 SchedulerUtilQuartzImpl.class
      1 StopVdsCommand.class
      1 TransactionSupport.class
      1 VmTemplateCommand.class
      2 CpuFlagsManagerHandler.class
      2 StorageDomainSpaceChecker.class
      2 VdsGroupDAO.class
      3 EjbUtils.class
      3 LogFactory.class
      3 MultiLevelAdministrationHandler.class
      3 StorageHelperDirector.class
      3 VmTemplateHandler.class
      6 ImagesHandler.class
      6 VmHandler.class
     10 Backend.class
     28 Config.class
     33 DbFacade.class

So handling the Config and DbFacade will be a major step toward
powermock elimination.
(list retrieved by running the next command from ovirt-engine head: find
. -name "*Test.java" -exec grep -r "@PrepareForTest" {} \; | tr "{)}" "
" | cut -d \(  -f2 | tr "," "\n" | tr -d " " | sort | uniq -c | sort -n)


> 
> Yair
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From yzaslavs at redhat.com  Wed Mar 28 09:09:38 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 28 Mar 2012 11:09:38 +0200
Subject: [Engine-devel] Getting rid of PowerMock?
In-Reply-To: <4F72D207.6040407@redhat.com>
References: <4F71F9DE.5030403@redhat.com> <4F72D207.6040407@redhat.com>
Message-ID: <4F72D552.8030500@redhat.com>

On 03/28/2012 10:55 AM, Moti Asayag wrote:
> On 03/27/2012 07:33 PM, Yair Zaslavsky wrote:
>> Hi all,
>> As (almost) all of us can see,
>> Running BLL tests both takes considerable time, and also we have to take
>> class loading dependencies between classes with static methods when we
>> use mockStatic - IMHO, this is kinda frustrating.
>> Maybe we should start get rid of  PowerMock.
>> Here is what I'm thinking of -
>> Currently, as we use no IoC for DAOs , for tested class we do not use
>> DbFacade.getInstance().getXXXDao()
>>
>> instead we define:
>>
>> protected XXXDao getXXXDao() {
>>   return DBFacade.getInstance().getXXXDao();
>> }
>>
> 
> +1 for this. IMO all DAOs should be reachable from the CommandBase as
> this is a repeated code scattered in the various commands.
> 
> I'd suggest to create an interface that declares all of available DAOs.
> The new interface should be implemented by both DbFacade (which already
> contains that implementation) and CommandBase to assure new DAOs added
> to DbFacade will be added to the CommandBase as well.
+1 On your idea.
Too bad QueriesCommandBase and CommandBase do no share the same parent.
Your idea is needed in queries as well.


> 
>> And then in our tests we use Mockito to define how getXXDao acts in the
>> test.
>>
>> The following can be achieved also for config values , the following way -
>>
>> protected <T> T getConfig(ConfigValues key) {
>>         return Config.<T> GetValue(key);
>>     }
>>
>> And then in code (for example, in a query test) -
>>
>>  doReturn(5).when(query).<Integer>
>> getConfig(any(ConfigValues.SomeIntegerConstant));
>>
>>
>> This effort can be done in small steps -
>> a. Define getConfig method in base classes (i.e AuditLoggalbeBase).
>> b. Rewrite parts (i.e Commands, and their tests) step by step (small
>> commits)
>>
>> Thoughts and ideas are more than welcome,
> 
> Searching for the static mocked classes brought the following list:
> 
>       1 AuditLogDirector.class
>       1 CommandsFactory.class
>       1 FileUtil.class
>       1 LoggerFactory.class
>       1 QuotaHelper.class
>       1 QuotaManager.class
>       1 SchedulerUtilQuartzImpl.class
>       1 StopVdsCommand.class
>       1 TransactionSupport.class
>       1 VmTemplateCommand.class
>       2 CpuFlagsManagerHandler.class
>       2 StorageDomainSpaceChecker.class
>       2 VdsGroupDAO.class
>       3 EjbUtils.class
>       3 LogFactory.class
>       3 MultiLevelAdministrationHandler.class
>       3 StorageHelperDirector.class
>       3 VmTemplateHandler.class
>       6 ImagesHandler.class
>       6 VmHandler.class
>      10 Backend.class
>      28 Config.class
>      33 DbFacade.class
> 
> So handling the Config and DbFacade will be a major step toward
> powermock elimination.
> (list retrieved by running the next command from ovirt-engine head: find
> . -name "*Test.java" -exec grep -r "@PrepareForTest" {} \; | tr "{)}" "
> " | cut -d \(  -f2 | tr "," "\n" | tr -d " " | sort | uniq -c | sort -n)
> 
> 
>>
>> Yair
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From masayag at redhat.com  Wed Mar 28 09:11:04 2012
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 28 Mar 2012 11:11:04 +0200
Subject: [Engine-devel] Getting rid of PowerMock?
In-Reply-To: <4c641a6a-2552-4e41-ae6d-bbeb159dabcd@zmail01.collab.prod.int.phx2.redhat.com>
References: <4c641a6a-2552-4e41-ae6d-bbeb159dabcd@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <4F72D5A8.2020903@redhat.com>

On 03/28/2012 09:23 AM, Laszlo Hornyak wrote:
> Hi,
> 
> How much faster could the unit tests run after removing powermock and using the instance methods instead?
> 

Major problem is the demand for forkMode=always to bypass the OOME.
Simple check of running SearchBackend unit-test without/with
forkMode=always shows 3s vs 7s, and for utils project 17s vs 65s.
I can only assume that for the backend project test time could be cut by
half.

> I like this idea anyway because it could be a step towards dependency injection.
> Could be a more motivating long term objective than just to get rid of powermock :)
> 
> Laszlo
> 
> ----- Original Message -----
>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Tuesday, March 27, 2012 7:33:18 PM
>> Subject: [Engine-devel] Getting rid of PowerMock?
>>
>> Hi all,
>> As (almost) all of us can see,
>> Running BLL tests both takes considerable time, and also we have to
>> take
>> class loading dependencies between classes with static methods when
>> we
>> use mockStatic - IMHO, this is kinda frustrating.
>> Maybe we should start get rid of  PowerMock.
>> Here is what I'm thinking of -
>> Currently, as we use no IoC for DAOs , for tested class we do not use
>> DbFacade.getInstance().getXXXDao()
>>
>> instead we define:
>>
>> protected XXXDao getXXXDao() {
>>   return DBFacade.getInstance().getXXXDao();
>> }
>>
>> And then in our tests we use Mockito to define how getXXDao acts in
>> the
>> test.
>>
>> The following can be achieved also for config values , the following
>> way -
>>
>> protected <T> T getConfig(ConfigValues key) {
>>         return Config.<T> GetValue(key);
>>     }
>>
>> And then in code (for example, in a query test) -
>>
>>  doReturn(5).when(query).<Integer>
>> getConfig(any(ConfigValues.SomeIntegerConstant));
>>
>>
>> This effort can be done in small steps -
>> a. Define getConfig method in base classes (i.e AuditLoggalbeBase).
>> b. Rewrite parts (i.e Commands, and their tests) step by step (small
>> commits)
>>
>> Thoughts and ideas are more than welcome,
>>
>> Yair
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From lpeer at redhat.com  Wed Mar 28 10:31:19 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 28 Mar 2012 12:31:19 +0200
Subject: [Engine-devel] agenda for todays meeting
Message-ID: <4F72E877.7030103@redhat.com>

Hi,

Today's meeting include status of the different features.
If you want to add something for the agenda please send to the list.

Thanks, Livnat


From kwade at redhat.com  Wed Mar 28 14:17:08 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 28 Mar 2012 07:17:08 -0700
Subject: [Engine-devel] Engine meeting
Message-ID: <4F731D64.2030608@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi:

I just learned that this team's open project meeting is held as a
teleconference.

Would you consider switching it to a regular IRC meeting, perhaps with
an occasional phone call?

IRC meetings have many advantages in an open project: low barrier of
access, easier to understand for non-native speakers, meeting log is
archivable and searchable, and more inviting for the project.

For phone meetings, do you publish the audio recording? That is not
optimal, but at least it allows for someone to transcribe the discussion.

Cheers - Karsten
- -- 
name:  Karsten 'quaid' Wade, Sr. Community Architect
team:    Red Hat Community Architecture & Leadership
uri:              http://communityleadershipteam.org
                         http://TheOpenSourceWay.org
gpg:                                        AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPcx1j2ZIOBq0ODEERAj1+AKDla8pokm8KifAoFOj/FE4fsXAP3wCeOJRL
oQfAO+hE2tXx5fbifJUeasY=
=Ftj6
-----END PGP SIGNATURE-----


From lpeer at redhat.com  Wed Mar 28 14:48:14 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 28 Mar 2012 16:48:14 +0200
Subject: [Engine-devel] Engine meeting
In-Reply-To: <4F731D64.2030608@redhat.com>
References: <4F731D64.2030608@redhat.com>
Message-ID: <4F7324AE.1000504@redhat.com>

On 28/03/12 16:17, Karsten 'quaid' Wade wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi:
> 
> I just learned that this team's open project meeting is held as a
> teleconference.
> 
> Would you consider switching it to a regular IRC meeting, perhaps with
> an occasional phone call?

We actually discussed this option a few months ago and decided to keep
it via phone, it seemed right at the time when we mostly discussed
features design and tried to get to conclusions for on-going (endless
;)) threads.

> 
> IRC meetings have many advantages in an open project: low barrier of
> access, easier to understand for non-native speakers, meeting log is
> archivable and searchable, and more inviting for the project.
> 
> For phone meetings, do you publish the audio recording? That is not
> optimal, but at least it allows for someone to transcribe the discussion.
> 

All the results of the calls are documented in the wiki pages of the
different features and being reflected in the different mailing threads
that we have.


Having said that I think it is time to reconsider the decision because
we are soon moving to a stabilization cycle before May's release.

I suggest we'll have our next meeting on IRC and see how it goes.


Thanks, Livnat

> Cheers - Karsten
> - -- 
> name:  Karsten 'quaid' Wade, Sr. Community Architect
> team:    Red Hat Community Architecture & Leadership
> uri:              http://communityleadershipteam.org
>                          http://TheOpenSourceWay.org
> gpg:                                        AD0E0C41
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iD8DBQFPcx1j2ZIOBq0ODEERAj1+AKDla8pokm8KifAoFOj/FE4fsXAP3wCeOJRL
> oQfAO+hE2tXx5fbifJUeasY=
> =Ftj6
> -----END PGP SIGNATURE-----
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From dfediuck at redhat.com  Wed Mar 28 14:55:16 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 28 Mar 2012 16:55:16 +0200
Subject: [Engine-devel] Engine meeting
In-Reply-To: <4F7324AE.1000504@redhat.com>
References: <4F731D64.2030608@redhat.com> <4F7324AE.1000504@redhat.com>
Message-ID: <4F732654.6030705@redhat.com>

+1 on moving status meetings to irc, starting next one.

On 28/03/12 16:48, Livnat Peer wrote:
> On 28/03/12 16:17, Karsten 'quaid' Wade wrote:
> Hi:
> 
> I just learned that this team's open project meeting is held as a
> teleconference.
> 
> Would you consider switching it to a regular IRC meeting, perhaps with
> an occasional phone call?
> 
>> We actually discussed this option a few months ago and decided to keep
>> it via phone, it seemed right at the time when we mostly discussed
>> features design and tried to get to conclusions for on-going (endless
>> ;)) threads.
> 
> 
> IRC meetings have many advantages in an open project: low barrier of
> access, easier to understand for non-native speakers, meeting log is
> archivable and searchable, and more inviting for the project.
> 
> For phone meetings, do you publish the audio recording? That is not
> optimal, but at least it allows for someone to transcribe the discussion.
> 
> 
>> All the results of the calls are documented in the wiki pages of the
>> different features and being reflected in the different mailing threads
>> that we have.
> 
> 
>> Having said that I think it is time to reconsider the decision because
>> we are soon moving to a stabilization cycle before May's release.
> 
>> I suggest we'll have our next meeting on IRC and see how it goes.
> 
> 
>> Thanks, Livnat
> 
> Cheers - Karsten
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From kwade at redhat.com  Wed Mar 28 15:00:37 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 28 Mar 2012 08:00:37 -0700
Subject: [Engine-devel] Engine meeting
In-Reply-To: <4F7324AE.1000504@redhat.com>
References: <4F731D64.2030608@redhat.com> <4F7324AE.1000504@redhat.com>
Message-ID: <4F732795.3020005@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/28/2012 07:48 AM, Livnat Peer wrote:

>> All the results of the calls are documented in the wiki pages of
>> the different features and being reflected in the different
>> mailing threads that we have.

That's great, and I agree that it is all being done very transparently.

One thing that an IRC meeting provides is a record of the process -
the discussions that leads to decisions. (That's harder to capture
with audio, so we usually stick with documenting decisions and what we
remember of why.) Also, the IRC channel has many people on it lurking,
who learn from the meeting, and may occasionally have useful input.

- - Karsten
- -- 
name:  Karsten 'quaid' Wade, Sr. Community Architect
team:    Red Hat Community Architecture & Leadership
uri:              http://communityleadershipteam.org
                         http://TheOpenSourceWay.org
gpg:                                        AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPcyeV2ZIOBq0ODEERAoLGAJ0bXbSJh7e3Cg5G73/Up63H56h7yACg3lx4
zgc6/w/s+wFFY/g/aGTOlwA=
=Jp1g
-----END PGP SIGNATURE-----


From kwade at redhat.com  Wed Mar 28 15:34:23 2012
From: kwade at redhat.com (Karsten 'quaid' Wade)
Date: Wed, 28 Mar 2012 08:34:23 -0700
Subject: [Engine-devel] Engine meeting
In-Reply-To: <4F732DD6.3030100@redhat.com>
References: <4F731D64.2030608@redhat.com> <4F7324AE.1000504@redhat.com>
	<4F732795.3020005@redhat.com> <4F732DD6.3030100@redhat.com>
Message-ID: <4F732F7F.9070206@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/28/2012 08:27 AM, Doron Fediuck wrote:
> Karsten, I'm guessing we'll need someone to learn how to master the
> wiki bot, in order to set the agenda, AI's, etc. Can you point /me
> to a wiki?

Doron:

These are the basic commands:

http://wiki.debian.org/MeetBot

> Can I create a test channel to try it out?

We could, but I think #ovirt is quiet enough that folks won't mind if
we do a b it of testing there. I can meet with you for testing, and
I'll be sure to attend the Engine meeting on IRC and help with the
meetbot until you don't need me anymore. :)

- - Karsten

> On 28/03/12 17:00, Karsten 'quaid' Wade wrote:
>> On 03/28/2012 07:48 AM, Livnat Peer wrote:
>> 
>>>> All the results of the calls are documented in the wiki pages
>>>> of the different features and being reflected in the
>>>> different mailing threads that we have.
>> 
>> That's great, and I agree that it is all being done very
>> transparently.
>> 
>> One thing that an IRC meeting provides is a record of the process
>> - the discussions that leads to decisions. (That's harder to
>> capture with audio, so we usually stick with documenting
>> decisions and what we remember of why.) Also, the IRC channel has
>> many people on it lurking, who learn from the meeting, and may
>> occasionally have useful input.
>> 
>> - Karsten _______________________________________________ 
>> Engine-devel mailing list Engine-devel at ovirt.org 
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


- -- 
name:  Karsten 'quaid' Wade, Sr. Community Architect
team:    Red Hat Community Architecture & Leadership
uri:              http://communityleadershipteam.org
                         http://TheOpenSourceWay.org
gpg:                                        AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPcy9/2ZIOBq0ODEERAnRMAKDP56ry2nVsZkaGQ0Qnh+mkMzpINwCfSL2h
Nm94nra7PI0byh/yqowELDI=
=/BaD
-----END PGP SIGNATURE-----


From dfediuck at redhat.com  Wed Mar 28 15:46:58 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 28 Mar 2012 17:46:58 +0200
Subject: [Engine-devel] Engine meeting
In-Reply-To: <4F732F7F.9070206@redhat.com>
References: <4F731D64.2030608@redhat.com> <4F7324AE.1000504@redhat.com>
	<4F732795.3020005@redhat.com> <4F732DD6.3030100@redhat.com>
	<4F732F7F.9070206@redhat.com>
Message-ID: <4F733272.50606@redhat.com>

On 28/03/12 17:34, Karsten 'quaid' Wade wrote:
> On 03/28/2012 08:27 AM, Doron Fediuck wrote:
>> Karsten, I'm guessing we'll need someone to learn how to master the
>> wiki bot, in order to set the agenda, AI's, etc. Can you point /me
>> to a wiki?
> 
> Doron:
> 
> These are the basic commands:
> 
> http://wiki.debian.org/MeetBot
> 
>> Can I create a test channel to try it out?
> 
> We could, but I think #ovirt is quiet enough that folks won't mind if
> we do a b it of testing there. I can meet with you for testing, and
> I'll be sure to attend the Engine meeting on IRC and help with the
> meetbot until you don't need me anymore. :)
> 
> - Karsten
> 
Excellent!
cya in the next engine meeting!


>> On 28/03/12 17:00, Karsten 'quaid' Wade wrote:
>>> On 03/28/2012 07:48 AM, Livnat Peer wrote:
>>>
>>>>> All the results of the calls are documented in the wiki pages
>>>>> of the different features and being reflected in the
>>>>> different mailing threads that we have.
>>>
>>> That's great, and I agree that it is all being done very
>>> transparently.
>>>
>>> One thing that an IRC meeting provides is a record of the process
>>> - the discussions that leads to decisions. (That's harder to
>>> capture with audio, so we usually stick with documenting
>>> decisions and what we remember of why.) Also, the IRC channel has
>>> many people on it lurking, who learn from the meeting, and may
>>> occasionally have useful input.
>>>
>>> - Karsten _______________________________________________ 
>>> Engine-devel mailing list Engine-devel at ovirt.org 
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From atal at redhat.com  Wed Mar 28 16:17:10 2012
From: atal at redhat.com (avi tal)
Date: Wed, 28 Mar 2012 18:17:10 +0200
Subject: [Engine-devel] Monitor host's Default Gateway
Message-ID: <4F733986.8030909@redhat.com>

Hi,
Detach host's interface that holds the Default Gateway would be very 
dangerous. there for Engine must start monitor who holds the default 
gateway.
It is true, a static IP interface can never add gateway (other than 
mgmt) due to CanDoAction but what about DHCP?

If a non-mgmt interface with DHCP got the gateway, Engine must know 
about it in order to protect connectivity to the host.

BTW, VDSM send these details in getCapabilities.

Bottom line, we should not limit other interfaces from holding gateway, 
not by statically or dhcp configuration. there is a reason why someone 
would like to have his gateway on a different interface than the mgmt. 
But non-mgmt interface that holds the gateway should be treated as mgmt 
interface when trying to remove or edit it.

Thanks




From dfediuck at redhat.com  Wed Mar 28 15:27:18 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 28 Mar 2012 17:27:18 +0200
Subject: [Engine-devel] Engine meeting
In-Reply-To: <4F732795.3020005@redhat.com>
References: <4F731D64.2030608@redhat.com> <4F7324AE.1000504@redhat.com>
	<4F732795.3020005@redhat.com>
Message-ID: <4F732DD6.3030100@redhat.com>

Karsten, 
I'm guessing we'll need someone to learn how to master the wiki bot,
in order to set the agenda, AI's, etc. Can you point /me to a wiki?
Can I create a test channel to try it out?

On 28/03/12 17:00, Karsten 'quaid' Wade wrote:
> On 03/28/2012 07:48 AM, Livnat Peer wrote:
> 
>>> All the results of the calls are documented in the wiki pages of
>>> the different features and being reflected in the different
>>> mailing threads that we have.
> 
> That's great, and I agree that it is all being done very transparently.
> 
> One thing that an IRC meeting provides is a record of the process -
> the discussions that leads to decisions. (That's harder to capture
> with audio, so we usually stick with documenting decisions and what we
> remember of why.) Also, the IRC channel has many people on it lurking,
> who learn from the meeting, and may occasionally have useful input.
> 
> - Karsten
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From lhornyak at redhat.com  Wed Mar 28 17:27:47 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 28 Mar 2012 13:27:47 -0400 (EDT)
Subject: [Engine-devel] advanced nfs options in vdsm
In-Reply-To: <a0c6df66-d003-43a4-9b1a-cf4cc8a6fb8b@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <06a7e4e4-397b-4a1e-a5d8-bb05c0584fcf@zmail01.collab.prod.int.phx2.redhat.com>

Hi Saggi,

The wiki page of the Advanced NFS options says that the changes needed in vdsm are already done http://www.ovirt.org/wiki/Features/AdvancedNfsOptions
Which VDSM release has this feature built in? Also, could you send me what changes have been done on vdsm?

Thank you,
Laszlo


From iheim at redhat.com  Wed Mar 28 19:58:57 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 28 Mar 2012 21:58:57 +0200
Subject: [Engine-devel] 'Import VM/Template More Than Once' feature
In-Reply-To: <daf0f887-dcc8-41fa-83cb-093fea620993@zmail14.collab.prod.int.phx2.redhat.com>
References: <daf0f887-dcc8-41fa-83cb-093fea620993@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F736D81.8010007@redhat.com>

On 02/21/2012 05:11 PM, Gilad Chaplik wrote:
> Hello all,
>
> The 'Import VM/Template More Than Once' feature description can be found under the following link:
>
> http://www.ovirt.org/wiki/Features/ImportMoreThanOnce
>
> Please review, and feel free to share your comments and thoughts.

1. "    Add 'Already Exists in Setup' column to import entity dialog: 
       Run multiple queries for get_entity_by_id to check whether the 
imported entities exist in the setup. "

what if there are 1000 VMs to import?

2. "Add 'clone only existing entities' check box to Import Entity Dialog: "

I'd keep simple for first round to get feedback from users and assume 
users want to either clone or not during import, rather than mixed 
(i.e., i'd drop this option to clone some of the imported images - i 
think it is confusing)

which means maybe user should choose between importing already existing 
images or new ones.

for existing ones, user should choose if to clone or overwrite.


From mkolesni at redhat.com  Thu Mar 29 06:35:07 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Thu, 29 Mar 2012 02:35:07 -0400 (EDT)
Subject: [Engine-devel] Getting rid of PowerMock?
In-Reply-To: <4F72D207.6040407@redhat.com>
Message-ID: <24fd4b7c-af50-4e4c-8d8c-1c0ffe9140e4@zmail14.collab.prod.int.phx2.redhat.com>

> On 03/27/2012 07:33 PM, Yair Zaslavsky wrote:
> > Hi all,
> > As (almost) all of us can see,
> > Running BLL tests both takes considerable time, and also we have to
> > take
> > class loading dependencies between classes with static methods when
> > we
> > use mockStatic - IMHO, this is kinda frustrating.
> > Maybe we should start get rid of  PowerMock.
> > Here is what I'm thinking of -
> > Currently, as we use no IoC for DAOs , for tested class we do not
> > use
> > DbFacade.getInstance().getXXXDao()
> > 
> > instead we define:
> > 
> > protected XXXDao getXXXDao() {
> >   return DBFacade.getInstance().getXXXDao();
> > }
> > 
> 
> +1 for this. IMO all DAOs should be reachable from the CommandBase as
> this is a repeated code scattered in the various commands.
> 
> I'd suggest to create an interface that declares all of available
> DAOs.
> The new interface should be implemented by both DbFacade (which
> already
> contains that implementation) and CommandBase to assure new DAOs
> added
> to DbFacade will be added to the CommandBase as well.

I'm not sure an interface is needed, since you won't be replacing it with different implementations.

However, maybe a good approach is to put this method in bases class:
protected DbFacade getDbFacade() {
    return DbFacade.getInstance();
}

This of course can be spied on to return a mock of the facade, and this mock can in turn return whatever mock DAOs you need.

> 
> > And then in our tests we use Mockito to define how getXXDao acts in
> > the
> > test.
> > 
> > The following can be achieved also for config values , the
> > following way -
> > 
> > protected <T> T getConfig(ConfigValues key) {
> >         return Config.<T> GetValue(key);
> >     }
> > 
> > And then in code (for example, in a query test) -
> > 
> >  doReturn(5).when(query).<Integer>
> > getConfig(any(ConfigValues.SomeIntegerConstant));
> > 
> > 
> > This effort can be done in small steps -
> > a. Define getConfig method in base classes (i.e AuditLoggalbeBase).
> > b. Rewrite parts (i.e Commands, and their tests) step by step
> > (small
> > commits)
> > 
> > Thoughts and ideas are more than welcome,
> 
> Searching for the static mocked classes brought the following list:
> 
>       1 AuditLogDirector.class
>       1 CommandsFactory.class
>       1 FileUtil.class
>       1 LoggerFactory.class
>       1 QuotaHelper.class
>       1 QuotaManager.class
>       1 SchedulerUtilQuartzImpl.class
>       1 StopVdsCommand.class
>       1 TransactionSupport.class
>       1 VmTemplateCommand.class
>       2 CpuFlagsManagerHandler.class
>       2 StorageDomainSpaceChecker.class
>       2 VdsGroupDAO.class
>       3 EjbUtils.class
>       3 LogFactory.class
>       3 MultiLevelAdministrationHandler.class
>       3 StorageHelperDirector.class
>       3 VmTemplateHandler.class
>       6 ImagesHandler.class
>       6 VmHandler.class
>      10 Backend.class
>      28 Config.class
>      33 DbFacade.class
> 
> So handling the Config and DbFacade will be a major step toward
> powermock elimination.
> (list retrieved by running the next command from ovirt-engine head:
> find
> . -name "*Test.java" -exec grep -r "@PrepareForTest" {} \; | tr "{)}"
> "
> " | cut -d \(  -f2 | tr "," "\n" | tr -d " " | sort | uniq -c | sort
> -n)
> 
> 
> > 
> > Yair
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From rgolan at redhat.com  Thu Mar 29 07:52:20 2012
From: rgolan at redhat.com (Roy Golan)
Date: Thu, 29 Mar 2012 09:52:20 +0200
Subject: [Engine-devel] Getting rid of PowerMock?
In-Reply-To: <24fd4b7c-af50-4e4c-8d8c-1c0ffe9140e4@zmail14.collab.prod.int.phx2.redhat.com>
References: <24fd4b7c-af50-4e4c-8d8c-1c0ffe9140e4@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F7414B4.3090803@redhat.com>

On 03/29/2012 08:35 AM, Mike Kolesnik wrote:
>> On 03/27/2012 07:33 PM, Yair Zaslavsky wrote:
>>> Hi all,
>>> As (almost) all of us can see,
>>> Running BLL tests both takes considerable time, and also we have to
>>> take
>>> class loading dependencies between classes with static methods when
>>> we
>>> use mockStatic - IMHO, this is kinda frustrating.
>>> Maybe we should start get rid of  PowerMock.
>>> Here is what I'm thinking of -
>>> Currently, as we use no IoC for DAOs , for tested class we do not
>>> use
>>> DbFacade.getInstance().getXXXDao()
>>>
>>> instead we define:
>>>
>>> protected XXXDao getXXXDao() {
>>>    return DBFacade.getInstance().getXXXDao();
>>> }
>>>
>> +1 for this. IMO all DAOs should be reachable from the CommandBase as
>> this is a repeated code scattered in the various commands.
>>
>> I'd suggest to create an interface that declares all of available
>> DAOs.
>> The new interface should be implemented by both DbFacade (which
>> already
>> contains that implementation) and CommandBase to assure new DAOs
>> added
>> to DbFacade will be added to the CommandBase as well.
> I'm not sure an interface is needed, since you won't be replacing it with different implementations.
>
> However, maybe a good approach is to put this method in bases class:
> protected DbFacade getDbFacade() {
>      return DbFacade.getInstance();
> }
I think we should use insert an injection stage in the commandFactory to 
fulfill the command resources .

@EngineInject
DbFacade dbFacade;

We can do something similar with the Config.
> This of course can be spied on to return a mock of the facade, and this mock can in turn return whatever mock DAOs you need.
>
>>> And then in our tests we use Mockito to define how getXXDao acts in
>>> the
>>> test.
>>>
>>> The following can be achieved also for config values , the
>>> following way -
>>>
>>> protected<T>  T getConfig(ConfigValues key) {
>>>          return Config.<T>  GetValue(key);
>>>      }
>>>
>>> And then in code (for example, in a query test) -
>>>
>>>   doReturn(5).when(query).<Integer>
>>> getConfig(any(ConfigValues.SomeIntegerConstant));
>>>
>>>
>>> This effort can be done in small steps -
>>> a. Define getConfig method in base classes (i.e AuditLoggalbeBase).
>>> b. Rewrite parts (i.e Commands, and their tests) step by step
>>> (small
>>> commits)
>>>
>>> Thoughts and ideas are more than welcome,
>> Searching for the static mocked classes brought the following list:
>>
>>        1 AuditLogDirector.class
>>        1 CommandsFactory.class
>>        1 FileUtil.class
>>        1 LoggerFactory.class
>>        1 QuotaHelper.class
>>        1 QuotaManager.class
>>        1 SchedulerUtilQuartzImpl.class
>>        1 StopVdsCommand.class
>>        1 TransactionSupport.class
>>        1 VmTemplateCommand.class
>>        2 CpuFlagsManagerHandler.class
>>        2 StorageDomainSpaceChecker.class
>>        2 VdsGroupDAO.class
>>        3 EjbUtils.class
>>        3 LogFactory.class
>>        3 MultiLevelAdministrationHandler.class
>>        3 StorageHelperDirector.class
>>        3 VmTemplateHandler.class
>>        6 ImagesHandler.class
>>        6 VmHandler.class
>>       10 Backend.class
>>       28 Config.class
>>       33 DbFacade.class
>>
>> So handling the Config and DbFacade will be a major step toward
>> powermock elimination.
>> (list retrieved by running the next command from ovirt-engine head:
>> find
>> . -name "*Test.java" -exec grep -r "@PrepareForTest" {} \; | tr "{)}"
>> "
>> " | cut -d \(  -f2 | tr "," "\n" | tr -d " " | sort | uniq -c | sort
>> -n)
>>
>>
>>> Yair
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From msalem at redhat.com  Thu Mar 29 08:05:38 2012
From: msalem at redhat.com (Muli Salem)
Date: Thu, 29 Mar 2012 04:05:38 -0400 (EDT)
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <4F71A261.1090205@redhat.com>
Message-ID: <07f78b09-4af7-4638-9189-33013e7c2f9b@zmail16.collab.prod.int.phx2.redhat.com>

Thanks for the comments, I updated the wiki page accordingly:
http://www.ovirt.org/wiki/Features/ReloadableConfiguration

1. Instead of the new DB column is_reloadable --> Annotation to ConfigValues.
2. Found a way to update the Quartz jobs, at least basic issues such as interval size.
3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, March 27, 2012 1:20:01 PM
> Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
> 
> On 03/27/2012 08:18 AM, Itamar Heim wrote:
> > On 03/26/2012 09:53 PM, Saggi Mizrahi wrote:
> >> 1. The column listing value is reloadable is redundant. Whether or
> >> not
> >> a value is "reloadable" or not is defined in the actual Engine
> >> code.
> >> Values that are currently not "reloadable" might become reloadable
> >> in
> >> the future. Putting this is the db just means you have to sync
> >> between
> >> the engine logic and the DB. I think this value should be obtained
> >> from the Engine dynamically and not persisted to disk.
> >> 2. Why don't configuration changes happen only through the Engine
> >> REST
> >> API? That way you always know when values change and you don't
> >> have to
> >> periodically reload. For cases where someone want's to change the
> >> values bypassing the API just make them use `service ovirt-engine
> >> reload` like every other daemon.
> >> 3. Values that cannot be refreshed without a restart will print a
> >> warning wither in the API response or to stderr for the service
> >> call.
> >> something in the form of:
> >> WARNING option XXXXX changed a reboot is required for it to take
> >> affect.
> >> 4. I also don't see why you write the data type to the DB (config
> >> type, column type). It's not like you are saving the values in
> >> binary
> >> format. It's just another case when this information is already
> 
> Agreed. Current code in engine-core uses a generic method to get the
> value, and uses @TypeConverterAttribute annotation to give indication
> to
> which type the data should be "cast" to.
> See DbConfigUtils.parseValue(String value, String name,
> java.lang.Class<?> fieldType)
> 
> >> written in code anyway and when you change it in code you will
> >> just
> >> have to do the book keeping and needlessly change it again in the
> >> DB.
> >> As a rule try and not use db values to document the code. This is
> >> what
> >> documentation is for.
> > 
> > a different take on this - why not just annotate the enums with
> > this
> > information?
> 
> +1 On annotation idea - although this introduces "information on
> behavior" to code, and any change will require re-compiling, I don't
> see
> why anyone would like to change the behavior.
> 
> > also, not sure configuration should be reloaded per change
> > automatically. maybe user wants it to happen on next restart, maybe
> > some
> > changes must happen together.
> > i.e., I'd expect a specific 'reconfigure' call to make it happen
> > rather
> > than poll for it.
> > 
> >> These are things I'm not against I just want more explanation
> >> about:
> >> 1. Why even put the configuration in the DB? Data bases are
> >> notoriously strict and once you have schema you are committed to
> >> it.
> >> Having a regular config file might be simpler for users to edit
> >> and
> >> for you to maintain. The only reasons to use a DB as opposed to a
> >> flat
> >> file are ACID and scaleability. None of these are actually
> >> important
> >> for configuration.
> >> 2. The definition to what might not be "reloadable" seem arbitrary
> >> to
> >> me (eg. "Quartz services that are setup on startup and cannot be
> >> changed afterwords."). I admit I don't really know what Quartz
> >> services are, but I don't imagine it's impossible to write one
> >> that
> >> has at least one "reloadable" configuration value.
> Muli - are you sure about Quartz? Have you checked it out?
> 
> >>
> >> ----- Original Message -----
> >>> From: "Muli Salem"<msalem at redhat.com>
> >>> To: engine-devel at ovirt.org
> >>> Sent: Monday, March 26, 2012 1:10:10 PM
> >>> Subject: [Engine-devel] Reloadable Configuration - Wiki Page
> >>>
> >>> Hi All,
> >>>
> >>> Below please find a wiki page regarding the design of the
> >>> Reloadable
> >>> Configuration feature.
> >>> You are more than welcome to review and comment.
> >>>
> >>> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
> >>>
> >>> Thanks,
> >>> Muli
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Thu Mar 29 08:54:53 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 29 Mar 2012 10:54:53 +0200
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <07f78b09-4af7-4638-9189-33013e7c2f9b@zmail16.collab.prod.int.phx2.redhat.com>
References: <07f78b09-4af7-4638-9189-33013e7c2f9b@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <4F74235D.3050202@redhat.com>

On 03/29/2012 10:05 AM, Muli Salem wrote:
> Thanks for the comments, I updated the wiki page accordingly:
> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
>
> 1. Instead of the new DB column is_reloadable -->  Annotation to ConfigValues.
> 2. Found a way to update the Quartz jobs, at least basic issues such as interval size.
> 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.

just wondering - how will the CLI do this at the technical level (via 
REST API? signal to service, etc.)?


From lpeer at redhat.com  Thu Mar 29 08:56:17 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Thu, 29 Mar 2012 10:56:17 +0200
Subject: [Engine-devel] 'Import VM/Template More Than Once' feature
In-Reply-To: <daf0f887-dcc8-41fa-83cb-093fea620993@zmail14.collab.prod.int.phx2.redhat.com>
References: <daf0f887-dcc8-41fa-83cb-093fea620993@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F7423B1.5050607@redhat.com>

On 21/02/12 17:11, Gilad Chaplik wrote:
> Hello all,
> 
> The 'Import VM/Template More Than Once' feature description can be found under the following link:
> 
> http://www.ovirt.org/wiki/Features/ImportMoreThanOnce
> 
> Please review, and feel free to share your comments and thoughts.
> 
> Thanks, 
> Gilad.

I am missing the most obvious limitation of this feature in the summary
of the feature.

This feature is limited to mode of collapsing the imported VM images
AFAIR, if you import a VM based on a template, for each import, a
collapsed image is created in the setup (It is like importing the
template with each VM you have based on this template).

I think this limitation makes the feature unworthy, we should be able to
support changing the ID's and importing only the needed storage layer.


Livnat

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



From dfediuck at redhat.com  Thu Mar 29 09:59:33 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 29 Mar 2012 11:59:33 +0200
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <4F74235D.3050202@redhat.com>
References: <07f78b09-4af7-4638-9189-33013e7c2f9b@zmail16.collab.prod.int.phx2.redhat.com>
	<4F74235D.3050202@redhat.com>
Message-ID: <4F743285.5060300@redhat.com>

On 29/03/12 10:54, Itamar Heim wrote:
> On 03/29/2012 10:05 AM, Muli Salem wrote:
>> Thanks for the comments, I updated the wiki page accordingly:
>> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
>>
>> 1. Instead of the new DB column is_reloadable -->  Annotation to ConfigValues.
>> 2. Found a way to update the Quartz jobs, at least basic issues such as interval size.
>> 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.
> 
> just wondering - how will the CLI do this at the technical level (via REST API? signal to service, etc.)?

Basically we need a script using the REST sdk to trigger re-configuration
This script will need the engine's IP so it'll know where to find it.
The thing is, REST also needs the admin's user and password to run...

We can get it in 2 options:

1. Store Admin's user+pass in the engine's conf file.
2. Use engine-config to fetch the credentials.

Once we have credentials, we can use it with a new script to trigger configuration reload.
We can also incorporate this script into engine-config so admin won't need to know another
script, and simply use a 'reload' verb.

I'm not keen on storing the credentials in a conf' file, but (unfortunately) it wouldn't
be a first time. Any better alternative is welcome (just as patches ;-).

A simple alternative to the whole credentials and IP need,
is a simple periodic reload, as suggested initially.

/d


From iheim at redhat.com  Thu Mar 29 10:13:01 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 29 Mar 2012 12:13:01 +0200
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <4F743285.5060300@redhat.com>
References: <07f78b09-4af7-4638-9189-33013e7c2f9b@zmail16.collab.prod.int.phx2.redhat.com>
	<4F74235D.3050202@redhat.com> <4F743285.5060300@redhat.com>
Message-ID: <4F7435AD.1080400@redhat.com>

On 03/29/2012 11:59 AM, Doron Fediuck wrote:
> On 29/03/12 10:54, Itamar Heim wrote:
>> On 03/29/2012 10:05 AM, Muli Salem wrote:
>>> Thanks for the comments, I updated the wiki page accordingly:
>>> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
>>>
>>> 1. Instead of the new DB column is_reloadable -->   Annotation to ConfigValues.
>>> 2. Found a way to update the Quartz jobs, at least basic issues such as interval size.
>>> 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.
>>
>> just wondering - how will the CLI do this at the technical level (via REST API? signal to service, etc.)?
>
> Basically we need a script using the REST sdk to trigger re-configuration
> This script will need the engine's IP so it'll know where to find it.
> The thing is, REST also needs the admin's user and password to run...
>
> We can get it in 2 options:
>
> 1. Store Admin's user+pass in the engine's conf file.
> 2. Use engine-config to fetch the credentials.
>
> Once we have credentials, we can use it with a new script to trigger configuration reload.
> We can also incorporate this script into engine-config so admin won't need to know another
> script, and simply use a 'reload' verb.
>
> I'm not keen on storing the credentials in a conf' file, but (unfortunately) it wouldn't
> be a first time. Any better alternative is welcome (just as patches ;-).

true.

>
> A simple alternative to the whole credentials and IP need,
> is a simple periodic reload, as suggested initially.



>
> /d

isn't there some way to send a process signal or something like that 
(not allowing remote access, but i think it uses the db crednetials from 
a local file anyway, and i don't think running config remotely is a must)

other options:
1. require user to provide user/password (kind of funny for running 
manage-domains utility, but possible
2. use a way on the host to send a signal (change a file, process 
signal, etc.)




From dfediuck at redhat.com  Thu Mar 29 12:42:05 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 29 Mar 2012 14:42:05 +0200
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <4F7435AD.1080400@redhat.com>
References: <07f78b09-4af7-4638-9189-33013e7c2f9b@zmail16.collab.prod.int.phx2.redhat.com>
	<4F74235D.3050202@redhat.com> <4F743285.5060300@redhat.com>
	<4F7435AD.1080400@redhat.com>
Message-ID: <4F74589D.3030001@redhat.com>

On 29/03/12 12:13, Itamar Heim wrote:
> On 03/29/2012 11:59 AM, Doron Fediuck wrote:
>> On 29/03/12 10:54, Itamar Heim wrote:
>>> On 03/29/2012 10:05 AM, Muli Salem wrote:
>>>> Thanks for the comments, I updated the wiki page accordingly:
>>>> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
>>>>
>>>> 1. Instead of the new DB column is_reloadable -->   Annotation to ConfigValues.
>>>> 2. Found a way to update the Quartz jobs, at least basic issues such as interval size.
>>>> 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.
>>>
>>> just wondering - how will the CLI do this at the technical level (via REST API? signal to service, etc.)?
>>
>> Basically we need a script using the REST sdk to trigger re-configuration
>> This script will need the engine's IP so it'll know where to find it.
>> The thing is, REST also needs the admin's user and password to run...
>>
>> We can get it in 2 options:
>>
>> 1. Store Admin's user+pass in the engine's conf file.
>> 2. Use engine-config to fetch the credentials.
>>
>> Once we have credentials, we can use it with a new script to trigger configuration reload.
>> We can also incorporate this script into engine-config so admin won't need to know another
>> script, and simply use a 'reload' verb.
>>
>> I'm not keen on storing the credentials in a conf' file, but (unfortunately) it wouldn't
>> be a first time. Any better alternative is welcome (just as patches ;-).
> 
> true.
> 
>>
>> A simple alternative to the whole credentials and IP need,
>> is a simple periodic reload, as suggested initially.
> 
> 
Any thoughts on this?

> 
>>
>> /d
> 
> isn't there some way to send a process signal or something like that (not allowing remote access, but i think it uses the db crednetials from a local file anyway, and i don't think running config remotely is a must)
> 
Simply signaling a process such as "kill TRAP PID" is problematic since:
- The engine core is a web-app on top of JBoss, how do we know which pid to trigger?
- What happens if JBoss isn't running / using nohup / ... ?

> other options:
> 1. require user to provide user/password (kind of funny for running manage-domains utility, but possible
This will make service xxx reload pointless, unless we decide to drop it and reduce to a simple
script (embedded or not in the config utility).

> 2. use a way on the host to send a signal (change a file, process signal, etc.)
Great. This means we need to poll a folder or similar (DB)... sounds familiar?
See above the periodic reload. We can do it better if we look for a key in the DB
(enableReconfigure=true), to avoid reloading in the middle of an update process
of several keys. We still need to be careful from concurrency, but I have solutions
for this as well (do not allow updates to vdc_options until the key becomes false again,
also set it to false on initial boot).

> 
3. Write a simple public reload servlet (maybe limit to local host only?), which
we can call using simple curl http://xxx/reload?
 
As I see it now,
I'd go for one of the following (in this order)-
2: periodically poll DB, reload only when allowed.
3: local servlet.

Thoughts?
Better solutions?


From eedri at redhat.com  Thu Mar 29 15:57:13 2012
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 29 Mar 2012 11:57:13 -0400 (EDT)
Subject: [Engine-devel] [Jenkins] new high priority bug still open in
	ovirt-engine
In-Reply-To: <b08db676-8b1b-4695-a9ed-cdbb465829ca@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4ba979d9-1b0e-43f6-9f11-817459fc182f@zmail17.collab.prod.int.phx2.redhat.com>

fyi,

these commits caused a new high priority bug:

common: Changes to image_storage_domain_map (detail / gitweb)
core: Extracting ImageStorageDomainMap Dao (detail / gitweb)

details here:

http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_find_bugs/470/

please check,

Eyal Edri
oVirt Infra Team


From masayag at redhat.com  Thu Mar 29 16:36:51 2012
From: masayag at redhat.com (Moti Asayag)
Date: Thu, 29 Mar 2012 18:36:51 +0200
Subject: [Engine-devel] Manual DB change required - remove grant_mode column
	from DB
Message-ID: <4F748FA3.4090208@redhat.com>

Hi,

The commit which added the grant_mode column to the permissions table
was reverted (604ae480ab677b06e53abd0edfaf0ec04f017fb8).

If you upgraded the DB since the 25/3, please run manually the next
command in order to drop that column and run refresh procedure
afterwards/run upgrade script:

echo 'alter table permissions drop column grant_mode' | psql engine postgres

(supply database name if differ from engine).

Thanks,
Moti


From masayag at redhat.com  Thu Mar 29 16:50:38 2012
From: masayag at redhat.com (Moti Asayag)
Date: Thu, 29 Mar 2012 18:50:38 +0200
Subject: [Engine-devel] [Jenkins] new high priority bug still open in
 ovirt-engine
In-Reply-To: <4ba979d9-1b0e-43f6-9f11-817459fc182f@zmail17.collab.prod.int.phx2.redhat.com>
References: <4ba979d9-1b0e-43f6-9f11-817459fc182f@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F7492DE.4000707@redhat.com>

On 03/29/2012 05:57 PM, Eyal Edri wrote:
> fyi,
> 
> these commits caused a new high priority bug:
> 
> common: Changes to image_storage_domain_map (detail / gitweb)
> core: Extracting ImageStorageDomainMap Dao (detail / gitweb)
> 
> details here:
> 
> http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_find_bugs/470/
> 
> please check,

patch was merged (commit cc4ef58a384c77e9fd193ba52bc2d4b0c0831d83).

> 
> Eyal Edri
> oVirt Infra Team
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From gchaplik at redhat.com  Thu Mar 29 19:14:38 2012
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 29 Mar 2012 15:14:38 -0400 (EDT)
Subject: [Engine-devel] 'Import VM/Template More Than Once' feature
In-Reply-To: <4F736D81.8010007@redhat.com>
Message-ID: <61ca8f92-6e3c-4088-86b8-013df5e92cc4@zmail14.collab.prod.int.phx2.redhat.com>

see inline

Thanks, 
Gilad.

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, March 28, 2012 9:58:57 PM
> Subject: Re: [Engine-devel] 'Import VM/Template More Than Once' feature
> 
> On 02/21/2012 05:11 PM, Gilad Chaplik wrote:
> > Hello all,
> >
> > The 'Import VM/Template More Than Once' feature description can be
> > found under the following link:
> >
> > http://www.ovirt.org/wiki/Features/ImportMoreThanOnce
> >
> > Please review, and feel free to share your comments and thoughts.
> 
> 1. "    Add 'Already Exists in Setup' column to import entity dialog:
>        Run multiple queries for get_entity_by_id to check whether the
> imported entities exist in the setup. "
> 
> what if there are 1000 VMs to import?

My mistake, meant it to be run search query on VMs with concating 'OR' between all vms ids (if search by vm ids is not supported I will add it).
but if you prefer it I can remove the column.

> 
> 2. "Add 'clone only existing entities' check box to Import Entity
> Dialog: "
> 
> I'd keep simple for first round to get feedback from users and assume
> users want to either clone or not during import, rather than mixed
> (i.e., i'd drop this option to clone some of the imported images - i
> think it is confusing)
> 
> which means maybe user should choose between importing already
> existing
> images or new ones.
> 
> for existing ones, user should choose if to clone or overwrite.
> 

Not sure what is override? delete the VM that is currently in setup and then import?
Anyhow, I think it's quite important, especially if we remove the 'exist in setup' column, we want the user to avoid getting can-do-action.
I agree that it is slightly confusing, I can rerun it through Eldan again, even though it's his design.



From gchaplik at redhat.com  Thu Mar 29 19:49:00 2012
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 29 Mar 2012 15:49:00 -0400 (EDT)
Subject: [Engine-devel] 'Import VM/Template More Than Once' feature
In-Reply-To: <4F7423B1.5050607@redhat.com>
Message-ID: <0f0887c4-6ceb-4ec2-8f5b-dc1e8aea9d3f@zmail14.collab.prod.int.phx2.redhat.com>

I think that the necessity of this feature is a from UX point of view:
Avoiding the nasty can-do-action if the VM is in the system, and adding an important flow to the user.

Anyhow I think it's a light feature with minimum changes to the backend, most of the work is in the ui.

Thanks, 
Gilad.

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, March 29, 2012 10:56:17 AM
> Subject: Re: [Engine-devel] 'Import VM/Template More Than Once' feature
> 
> On 21/02/12 17:11, Gilad Chaplik wrote:
> > Hello all,
> > 
> > The 'Import VM/Template More Than Once' feature description can be
> > found under the following link:
> > 
> > http://www.ovirt.org/wiki/Features/ImportMoreThanOnce
> > 
> > Please review, and feel free to share your comments and thoughts.
> > 
> > Thanks,
> > Gilad.
> 
> I am missing the most obvious limitation of this feature in the
> summary
> of the feature.
> 
> This feature is limited to mode of collapsing the imported VM images
> AFAIR, if you import a VM based on a template, for each import, a
> collapsed image is created in the setup (It is like importing the
> template with each VM you have based on this template).
> 
> I think this limitation makes the feature unworthy, we should be able
> to
> support changing the ID's and importing only the needed storage
> layer.
> 
> 
> Livnat
> 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 


From smizrahi at redhat.com  Fri Mar 30 19:10:19 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Fri, 30 Mar 2012 15:10:19 -0400 (EDT)
Subject: [Engine-devel] advanced nfs options in vdsm
In-Reply-To: <06a7e4e4-397b-4a1e-a5d8-bb05c0584fcf@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <b24b591b-ba41-45e3-831c-d44f5210df38@zmail16.collab.prod.int.phx2.redhat.com>

The gerrit issue is linked in the wiki. It has all the information on when it was merged.

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, March 28, 2012 1:27:47 PM
> Subject: advanced nfs options in vdsm
> 
> Hi Saggi,
> 
> The wiki page of the Advanced NFS options says that the changes
> needed in vdsm are already done
> http://www.ovirt.org/wiki/Features/AdvancedNfsOptions
> Which VDSM release has this feature built in? Also, could you send me
> what changes have been done on vdsm?
> 
> Thank you,
> Laszlo
> 


From iheim at redhat.com  Fri Mar 30 21:24:07 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sat, 31 Mar 2012 00:24:07 +0300
Subject: [Engine-devel] 'Import VM/Template More Than Once' feature
In-Reply-To: <61ca8f92-6e3c-4088-86b8-013df5e92cc4@zmail14.collab.prod.int.phx2.redhat.com>
References: <61ca8f92-6e3c-4088-86b8-013df5e92cc4@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4F762477.60207@redhat.com>

On 03/29/2012 09:14 PM, Gilad Chaplik wrote:
> see inline
>
> Thanks,
> Gilad.
>
> ----- Original Message -----
>> From: "Itamar Heim"<iheim at redhat.com>
>> To: "Gilad Chaplik"<gchaplik at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, March 28, 2012 9:58:57 PM
>> Subject: Re: [Engine-devel] 'Import VM/Template More Than Once' feature
>>
>> On 02/21/2012 05:11 PM, Gilad Chaplik wrote:
>>> Hello all,
>>>
>>> The 'Import VM/Template More Than Once' feature description can be
>>> found under the following link:
>>>
>>> http://www.ovirt.org/wiki/Features/ImportMoreThanOnce
>>>
>>> Please review, and feel free to share your comments and thoughts.
>>
>> 1. "    Add 'Already Exists in Setup' column to import entity dialog:
>>         Run multiple queries for get_entity_by_id to check whether the
>> imported entities exist in the setup. "
>>
>> what if there are 1000 VMs to import?
>
> My mistake, meant it to be run search query on VMs with concating 'OR' between all vms ids (if search by vm ids is not supported I will add it).
> but if you prefer it I can remove the column.
>
>>
>> 2. "Add 'clone only existing entities' check box to Import Entity
>> Dialog: "
>>
>> I'd keep simple for first round to get feedback from users and assume
>> users want to either clone or not during import, rather than mixed
>> (i.e., i'd drop this option to clone some of the imported images - i
>> think it is confusing)
>>
>> which means maybe user should choose between importing already
>> existing
>> images or new ones.
>>
>> for existing ones, user should choose if to clone or overwrite.
>>
>
> Not sure what is override? delete the VM that is currently in setup and then import?
> Anyhow, I think it's quite important, especially if we remove the 'exist in setup' column, we want the user to avoid getting can-do-action.
> I agree that it is slightly confusing, I can rerun it through Eldan again, even though it's his design.
>

override wouldn't delete the VM, just override the disks iirc (will not 
touch configuration i guess. no idea what happens if configuration is 
different, or number of disks is different, etc.)


From smizrahi at redhat.com  Fri Mar 30 21:50:51 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Fri, 30 Mar 2012 17:50:51 -0400 (EDT)
Subject: [Engine-devel] Reloadable Configuration - Wiki Page
In-Reply-To: <4F74589D.3030001@redhat.com>
Message-ID: <3570b600-90ed-4f30-9ea9-a9818449dadf@zmail16.collab.prod.int.phx2.redhat.com>

I'm sorry if I'm moving the conversation sideways a bit but I was ill for a few days and missed out on all the fun :).
The whole debate about permissions is a causing my spidy sense to tingle.

My main question is, What are the options you actually want to make as engine configuration?
At least from my experience with VDSM 99% of the configuration options we have shouldn't be VDSM configuration but instance attributes.

To illustrate, the interval where you check liveness of hosts is not actually an Engine setting but a cluster or a host attribute. It should be set using the UI and the permissions to set it should be related to general permission on the object.
The interval in which to check for storage liveness is a data center setting, not an Engine setting as well.

In general most options in a system are tied to object instances. The only things that I can think of that are actual Engine configurations are DB location, memory settings of the JVM and other technical details that should be accessible and set by the local root user only. This is also why I thought it shouldn't be in the DB, because if it's in the DB it's actually shared between installation and it's like sharing apache's "max thread num" setting between hosts with different capabilities.

Technical limitations like not being able to update quartz tasks once they've been initiated should be circumvented or abstracted but not designed around. 

----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, March 29, 2012 8:42:05 AM
> Subject: Re: [Engine-devel] Reloadable Configuration - Wiki Page
> 
> On 29/03/12 12:13, Itamar Heim wrote:
> > On 03/29/2012 11:59 AM, Doron Fediuck wrote:
> >> On 29/03/12 10:54, Itamar Heim wrote:
> >>> On 03/29/2012 10:05 AM, Muli Salem wrote:
> >>>> Thanks for the comments, I updated the wiki page accordingly:
> >>>> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
> >>>>
> >>>> 1. Instead of the new DB column is_reloadable -->   Annotation
> >>>> to ConfigValues.
> >>>> 2. Found a way to update the Quartz jobs, at least basic issues
> >>>> such as interval size.
> >>>> 3. The values will be reloaded upon admin's decision to do so -
> >>>> with a new command in the engine-config CLI, since that is
> >>>> where admins make the changes.
> >>>
> >>> just wondering - how will the CLI do this at the technical level
> >>> (via REST API? signal to service, etc.)?
> >>
> >> Basically we need a script using the REST sdk to trigger
> >> re-configuration
> >> This script will need the engine's IP so it'll know where to find
> >> it.
> >> The thing is, REST also needs the admin's user and password to
> >> run...
> >>
> >> We can get it in 2 options:
> >>
> >> 1. Store Admin's user+pass in the engine's conf file.
> >> 2. Use engine-config to fetch the credentials.
> >>
> >> Once we have credentials, we can use it with a new script to
> >> trigger configuration reload.
> >> We can also incorporate this script into engine-config so admin
> >> won't need to know another
> >> script, and simply use a 'reload' verb.
> >>
> >> I'm not keen on storing the credentials in a conf' file, but
> >> (unfortunately) it wouldn't
> >> be a first time. Any better alternative is welcome (just as
> >> patches ;-).
> > 
> > true.
> > 
> >>
> >> A simple alternative to the whole credentials and IP need,
> >> is a simple periodic reload, as suggested initially.
> > 
> > 
> Any thoughts on this?
> 
> > 
> >>
> >> /d
> > 
> > isn't there some way to send a process signal or something like
> > that (not allowing remote access, but i think it uses the db
> > crednetials from a local file anyway, and i don't think running
> > config remotely is a must)
> > 
> Simply signaling a process such as "kill TRAP PID" is problematic
> since:
> - The engine core is a web-app on top of JBoss, how do we know which
> pid to trigger?
> - What happens if JBoss isn't running / using nohup / ... ?
> 
> > other options:
> > 1. require user to provide user/password (kind of funny for running
> > manage-domains utility, but possible
> This will make service xxx reload pointless, unless we decide to drop
> it and reduce to a simple
> script (embedded or not in the config utility).
> 
> > 2. use a way on the host to send a signal (change a file, process
> > signal, etc.)
> Great. This means we need to poll a folder or similar (DB)... sounds
> familiar?
> See above the periodic reload. We can do it better if we look for a
> key in the DB
> (enableReconfigure=true), to avoid reloading in the middle of an
> update process
> of several keys. We still need to be careful from concurrency, but I
> have solutions
> for this as well (do not allow updates to vdc_options until the key
> becomes false again,
> also set it to false on initial boot).
> 
> > 
> 3. Write a simple public reload servlet (maybe limit to local host
> only?), which
> we can call using simple curl http://xxx/reload?
>  
> As I see it now,
> I'd go for one of the following (in this order)-
> 2: periodically poll DB, reload only when allowed.
> 3: local servlet.
> 
> Thoughts?
> Better solutions?
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>