From emesika at redhat.com  Wed May  1 00:45:06 2013
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 30 Apr 2013 20:45:06 -0400 (EDT)
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
Message-ID: <1180678810.4442250.1367369106621.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "Eli Mesika" <emesika at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>
> Sent: Tuesday, April 30, 2013 10:41:20 PM
> Subject: Dropping encryption of database password
> 
> Hello,
> 
> Currently we store database password encrypted using
> org.picketbox.datasource.security.SecureIdentityLoginModule.
> 
> This is reverse encryption with common knowledge shared secret.
> 
> Using encryption with common knowledge shared secret is close to void
> protection.
> 
> So far we also stored the password as plain text at
> /etc/ovirt-engine/.pgpass, this is going to be removed as no component
> actually uses the .pgpass, however we do need to store non-java specific
> password in for utilities.
> 
> In master (aiming to 3.3), we store the database connection details in own
> file /etc/ovirt-engine/engine.conf.d/50-setup-database.conf owned by ovirt
> user and not world readable.
> 
> I would like to use the same 50-setup-database.conf to store plain text
> password and remove the java specific reversible encrypted password usage.
> 
> Bottom line...
> 1. We drop the .pgpass file.
> 2. We store database connection information in
> /etc/ovirt-engine/engine.conf.d/<file> that is readable only by ovirt usage.
> 3. We drop the java specific reversible encryption in favor of plain text.
> 
> Thoughts?

I see no problem in the .pgpass , only root can access it (it has 0600 mode , if it doesn't it is ignored by PG)
Apart from that , this is the standard way used by PG so why not using it , AFAIK this is considered safe & secured 


> Alon
> 


From liran.zelkha at gmail.com  Wed May  1 05:34:18 2013
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Wed, 1 May 2013 08:34:18 +0300
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <1180678810.4442250.1367369106621.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1180678810.4442250.1367369106621.JavaMail.root@redhat.com>
Message-ID: <CAJ3aYLeS4rMDFOR9qxvvg=Bqc2_g0X_3kGmA7zKhWcd7sJ4HbA@mail.gmail.com>

Why not do use the same technology like JBoss DataSource password
encryption?
http://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html/Encrypting_Data_Source_Passwords.html


On Wed, May 1, 2013 at 3:45 AM, Eli Mesika <emesika at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "Eli Mesika" <
> emesika at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>
> > Sent: Tuesday, April 30, 2013 10:41:20 PM
> > Subject: Dropping encryption of database password
> >
> > Hello,
> >
> > Currently we store database password encrypted using
> > org.picketbox.datasource.security.SecureIdentityLoginModule.
> >
> > This is reverse encryption with common knowledge shared secret.
> >
> > Using encryption with common knowledge shared secret is close to void
> > protection.
> >
> > So far we also stored the password as plain text at
> > /etc/ovirt-engine/.pgpass, this is going to be removed as no component
> > actually uses the .pgpass, however we do need to store non-java specific
> > password in for utilities.
> >
> > In master (aiming to 3.3), we store the database connection details in
> own
> > file /etc/ovirt-engine/engine.conf.d/50-setup-database.conf owned by
> ovirt
> > user and not world readable.
> >
> > I would like to use the same 50-setup-database.conf to store plain text
> > password and remove the java specific reversible encrypted password
> usage.
> >
> > Bottom line...
> > 1. We drop the .pgpass file.
> > 2. We store database connection information in
> > /etc/ovirt-engine/engine.conf.d/<file> that is readable only by ovirt
> usage.
> > 3. We drop the java specific reversible encryption in favor of plain
> text.
> >
> > Thoughts?
>
> I see no problem in the .pgpass , only root can access it (it has 0600
> mode , if it doesn't it is ignored by PG)
> Apart from that , this is the standard way used by PG so why not using it
> , AFAIK this is considered safe & secured
>
>
> > Alon
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130501/0cc55be3/attachment.html>

From alonbl at redhat.com  Wed May  1 05:55:05 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 1 May 2013 01:55:05 -0400 (EDT)
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <1180678810.4442250.1367369106621.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1180678810.4442250.1367369106621.JavaMail.root@redhat.com>
Message-ID: <1260211145.3193784.1367387705950.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "Juan Hernandez"
> <jhernand at redhat.com>
> Sent: Wednesday, May 1, 2013 3:45:06 AM
> Subject: Re: Dropping encryption of database password
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "Eli Mesika"
> > <emesika at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>
> > Sent: Tuesday, April 30, 2013 10:41:20 PM
> > Subject: Dropping encryption of database password
> > 
> > Hello,
> > 
> > Currently we store database password encrypted using
> > org.picketbox.datasource.security.SecureIdentityLoginModule.
> > 
> > This is reverse encryption with common knowledge shared secret.
> > 
> > Using encryption with common knowledge shared secret is close to void
> > protection.
> > 
> > So far we also stored the password as plain text at
> > /etc/ovirt-engine/.pgpass, this is going to be removed as no component
> > actually uses the .pgpass, however we do need to store non-java specific
> > password in for utilities.
> > 
> > In master (aiming to 3.3), we store the database connection details in own
> > file /etc/ovirt-engine/engine.conf.d/50-setup-database.conf owned by ovirt
> > user and not world readable.
> > 
> > I would like to use the same 50-setup-database.conf to store plain text
> > password and remove the java specific reversible encrypted password usage.
> > 
> > Bottom line...
> > 1. We drop the .pgpass file.
> > 2. We store database connection information in
> > /etc/ovirt-engine/engine.conf.d/<file> that is readable only by ovirt
> > usage.
> > 3. We drop the java specific reversible encryption in favor of plain text.
> > 
> > Thoughts?
> 
> I see no problem in the .pgpass , only root can access it (it has 0600 mode ,
> if it doesn't it is ignored by PG)
> Apart from that , this is the standard way used by PG so why not using it ,
> AFAIK this is considered safe & secured

In another words you are for storing password as plain text.... :)

> 
> 
> > Alon
> > 
> 


From alonbl at redhat.com  Wed May  1 05:58:00 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 1 May 2013 01:58:00 -0400 (EDT)
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <CAJ3aYLeS4rMDFOR9qxvvg=Bqc2_g0X_3kGmA7zKhWcd7sJ4HbA@mail.gmail.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1180678810.4442250.1367369106621.JavaMail.root@redhat.com>
	<CAJ3aYLeS4rMDFOR9qxvvg=Bqc2_g0X_3kGmA7zKhWcd7sJ4HbA@mail.gmail.com>
Message-ID: <2130060404.3193989.1367387880029.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Liran Zelkha" <liran.zelkha at gmail.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Wednesday, May 1, 2013 8:34:18 AM
> Subject: Re: [Engine-devel] Dropping encryption of database password
> 
> Why not do use the same technology like JBoss DataSource password
> encryption?
> http://docs.jboss.org/jbosssecurity/docs/6.0/security_guide/html/Encrypting_Data_Source_Passwords.html

As I wrote:
1. Out project is not java specific, we need to access the database in other tools as well, example: python.
2. Reversible encryption is a total void, what benefit is there to encrypt password which can be decrypted by anyone?
3. We currently store the same password at two files, one which is .pgpass as plain text and another is at the service configuration which is encrypted, what is the benefit in this duplication?

Thanks!
Alon

> 
> On Wed, May 1, 2013 at 3:45 AM, Eli Mesika <emesika at redhat.com> wrote:
> 
> >
> >
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "Eli Mesika" <
> > emesika at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>
> > > Sent: Tuesday, April 30, 2013 10:41:20 PM
> > > Subject: Dropping encryption of database password
> > >
> > > Hello,
> > >
> > > Currently we store database password encrypted using
> > > org.picketbox.datasource.security.SecureIdentityLoginModule.
> > >
> > > This is reverse encryption with common knowledge shared secret.
> > >
> > > Using encryption with common knowledge shared secret is close to void
> > > protection.
> > >
> > > So far we also stored the password as plain text at
> > > /etc/ovirt-engine/.pgpass, this is going to be removed as no component
> > > actually uses the .pgpass, however we do need to store non-java specific
> > > password in for utilities.
> > >
> > > In master (aiming to 3.3), we store the database connection details in
> > own
> > > file /etc/ovirt-engine/engine.conf.d/50-setup-database.conf owned by
> > ovirt
> > > user and not world readable.
> > >
> > > I would like to use the same 50-setup-database.conf to store plain text
> > > password and remove the java specific reversible encrypted password
> > usage.
> > >
> > > Bottom line...
> > > 1. We drop the .pgpass file.
> > > 2. We store database connection information in
> > > /etc/ovirt-engine/engine.conf.d/<file> that is readable only by ovirt
> > usage.
> > > 3. We drop the java specific reversible encryption in favor of plain
> > text.
> > >
> > > Thoughts?
> >
> > I see no problem in the .pgpass , only root can access it (it has 0600
> > mode , if it doesn't it is ignored by PG)
> > Apart from that , this is the standard way used by PG so why not using it
> > , AFAIK this is considered safe & secured
> >
> >
> > > Alon
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 


From amureini at redhat.com  Wed May  1 07:05:34 2013
From: amureini at redhat.com (Allon Mureinik)
Date: Wed, 1 May 2013 03:05:34 -0400 (EDT)
Subject: [Engine-devel] REST vs. UI validation
In-Reply-To: <179985819.7101058.1367306131556.JavaMail.root@redhat.com>
References: <80DC92D924DD7344818D4A17A1C995D7688D2B86@G9W0733.americas.hpqcorp.net>
	<179985819.7101058.1367306131556.JavaMail.root@redhat.com>
Message-ID: <1757042330.5303868.1367391934702.JavaMail.root@redhat.com>

REST shouldn't have any validations (perhaps maybe only that the passed type is correct, etc. - Michael, correct me if I'm wrong).

The real validations are in the backend, which both REST and the GUI invoke. Any validation the GUI does in addition to the backend is just a user-experience enhancement (e.g., if !@#^!^$) is not a valid DC name, there is no reason to send it to the backend).

Vered - I disagree that this is by design.
There is only one definition of what a correct value is, there should be no ambiguity about it[1]
If the GUI prohibits you from a legal configuration - it should be fixed.
if the backend allows an illegal configuration - a CDA should be added.
My two cents - this is not OK, please open bugs (or even better - send patches!) for the specific issues.

[1] Just to be clear, there is a difference between not being able to do something from the UI and having different validations.
For example, there is no GUI for scanning a storage domain (http://www.ovirt.org/Features/Domain_Scan). I'd prefer having a GUI for that too, but not having it is just a missing capability, not a disambiguity with REST.

----- Original Message -----
> From: "Vered Volansky" <vered at redhat.com>
> To: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, April 30, 2013 10:15:31 AM
> Subject: Re: [Engine-devel] REST vs. UI validation
> 
> 
> 
> ----- Original Message -----
> > From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, April 30, 2013 1:19:00 AM
> > Subject: [Engine-devel] REST vs. UI validation
> > 
> > I've been making use of the oVirt REST api, and have noticed that in
> > several
> > cases the validation done for a REST request is different than what the
> > admin UI does.  It seems that the UI is generally more restrictive on the
> > data it will accept than the backend.  So you can set things up using the
> > REST api that the UI wouldn't let you do.  Two examples I've hit recently,
> > both in the cluster policy (load balancing section):
> > 
> > - Cluster load balancing policy duration - the UI requires a value between
> > 1
> > and 100, but the REST api seems to let you set it to any integer.
> > 
> > - Cluster load balancing high and low thresholds / max and min service
> > levels
> > - The UI restricts the high value to 51-90% and the low value to 10-50%.
> > But the backend only requires that the values be 0-100% and that low can't
> > be greater than high.
> > 
> > So my question - is this intended behavior, or is it a bug that the
> > validation is different?  If similar validation should be done through both
> > the UI and REST api, should the UI be less restrictive, or the backend more
> > restrictive?
> 
> This is the intended behaviour.
> The UI is often more restrictive than the api.
> By definition the api is more lenient that the UI.
> 
> Regards,
> Vered
> > 
> > Thanks,
> > Kari
> > _______________________________________________
> > 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 vered at redhat.com  Wed May  1 07:34:00 2013
From: vered at redhat.com (Vered Volansky)
Date: Wed, 1 May 2013 03:34:00 -0400 (EDT)
Subject: [Engine-devel] REST vs. UI validation
In-Reply-To: <1757042330.5303868.1367391934702.JavaMail.root@redhat.com>
References: <80DC92D924DD7344818D4A17A1C995D7688D2B86@G9W0733.americas.hpqcorp.net>
	<179985819.7101058.1367306131556.JavaMail.root@redhat.com>
	<1757042330.5303868.1367391934702.JavaMail.root@redhat.com>
Message-ID: <1909631386.7905748.1367393640867.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Allon Mureinik" <amureini at redhat.com>
> To: "Vered Volansky" <vered at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, May 1, 2013 10:05:34 AM
> Subject: Re: [Engine-devel] REST vs. UI validation
> 
> REST shouldn't have any validations (perhaps maybe only that the passed type
> is correct, etc. - Michael, correct me if I'm wrong).
> 
I never said REST have any validations.
When using REST only the backend validations are invoked.
When using the UI there might be more validations only for UI before the backend validations are ever invoked.
These validations aren't invoked for REST.

> The real validations are in the backend, which both REST and the GUI invoke.
> Any validation the GUI does in addition to the backend is just a
> user-experience enhancement (e.g., if !@#^!^$) is not a valid DC name, there
> is no reason to send it to the backend).
> 
> Vered - I disagree that this is by design.
> There is only one definition of what a correct value is, there should be no
> ambiguity about it[1]
> If the GUI prohibits you from a legal configuration - it should be fixed.
> if the backend allows an illegal configuration - a CDA should be added.
> My two cents - this is not OK, please open bugs (or even better - send
> patches!) for the specific issues.

This was discussed with Michael (until he answers himself).
More info on the issue -
The backend validations are less restrictive than UI, but not contradicting it.
This IS by design and is not a bug in general.
The specific min-max differences example is for sure by design.
In some (but I guess not all) cases the reasoning is a thought to expand possible values in the future.

So this is how things are right now.
I agree it looks weird that you might be able to set "illegal" values in REST and then connect via UI and see these values.
I suppose it can always come up for devel discussion whether that should be changed.

> 
> [1] Just to be clear, there is a difference between not being able to do
> something from the UI and having different validations.
> For example, there is no GUI for scanning a storage domain
> (http://www.ovirt.org/Features/Domain_Scan). I'd prefer having a GUI for
> that too, but not having it is just a missing capability, not a disambiguity
> with REST.
> 
> ----- Original Message -----
> > From: "Vered Volansky" <vered at redhat.com>
> > To: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, April 30, 2013 10:15:31 AM
> > Subject: Re: [Engine-devel] REST vs. UI validation
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Tuesday, April 30, 2013 1:19:00 AM
> > > Subject: [Engine-devel] REST vs. UI validation
> > > 
> > > I've been making use of the oVirt REST api, and have noticed that in
> > > several
> > > cases the validation done for a REST request is different than what the
> > > admin UI does.  It seems that the UI is generally more restrictive on the
> > > data it will accept than the backend.  So you can set things up using the
> > > REST api that the UI wouldn't let you do.  Two examples I've hit
> > > recently,
> > > both in the cluster policy (load balancing section):
> > > 
> > > - Cluster load balancing policy duration - the UI requires a value
> > > between
> > > 1
> > > and 100, but the REST api seems to let you set it to any integer.
> > > 
> > > - Cluster load balancing high and low thresholds / max and min service
> > > levels
> > > - The UI restricts the high value to 51-90% and the low value to 10-50%.
> > > But the backend only requires that the values be 0-100% and that low
> > > can't
> > > be greater than high.
> > > 
> > > So my question - is this intended behavior, or is it a bug that the
> > > validation is different?  If similar validation should be done through
> > > both
> > > the UI and REST api, should the UI be less restrictive, or the backend
> > > more
> > > restrictive?
> > 
> > This is the intended behaviour.
> > The UI is often more restrictive than the api.
> > By definition the api is more lenient that the UI.
> > 
> > Regards,
> > Vered
> > > 
> > > Thanks,
> > > Kari
> > > _______________________________________________
> > > 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 danken at redhat.com  Wed May  1 07:59:45 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 1 May 2013 10:59:45 +0300
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
References: <1003840521.3117171.1367350310165.JavaMail.root@redhat.com>
	<670062783.3118840.1367350880599.JavaMail.root@redhat.com>
Message-ID: <20130501075945.GC16283@redhat.com>

On Tue, Apr 30, 2013 at 03:41:20PM -0400, Alon Bar-Lev wrote:
> Hello,
> 
> Currently we store database password encrypted using org.picketbox.datasource.security.SecureIdentityLoginModule.
> 
> This is reverse encryption with common knowledge shared secret.
> 
> Using encryption with common knowledge shared secret is close to void protection.
> 
> So far we also stored the password as plain text at /etc/ovirt-engine/.pgpass, this is going to be removed as no component actually uses the .pgpass, however we do need to store non-java specific password in for utilities.
> 
> In master (aiming to 3.3), we store the database connection details in own file /etc/ovirt-engine/engine.conf.d/50-setup-database.conf owned by ovirt user and not world readable.
> 
> I would like to use the same 50-setup-database.conf to store plain text password and remove the java specific reversible encrypted password usage.
> 
> Bottom line...
> 1. We drop the .pgpass file.
> 2. We store database connection information in /etc/ovirt-engine/engine.conf.d/<file> that is readable only by ovirt usage.
> 3. We drop the java specific reversible encryption in favor of plain text.
> 

+1.
Obfuscating passwords only gives a false sense of security.

However, many applications, such Firefox in its signons.sqlite, do that
to avoid revealing the password during a casual browse of the
filesystem.


From mpastern at redhat.com  Wed May  1 08:13:45 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 01 May 2013 11:13:45 +0300
Subject: [Engine-devel] ovirt-engine-sdk-python 3.3.0.2-1 released
In-Reply-To: <515D6051.3090604@redhat.com>
References: <515D6051.3090604@redhat.com>
Message-ID: <5180CEB9.2070408@redhat.com>


 - in ClusterGlusterVolumeBricks fixed add() parameters
 - to StorageDomainVM.delete() added async parameter
 - fixed parent tag parameter in the tags.add()/.update() methods
 - nic.network is no longer mandatory parameter for vnic creation
 - Implement Session-TTL header support #928313
 - refactor invocation flow #949189, #949187
 - user should not see admin permissions the DC #924357


More details can be found at [1].

[1] http://wiki.ovirt.org/Python-sdk-changelog


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Wed May  1 08:17:13 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 01 May 2013 11:17:13 +0300
Subject: [Engine-devel] ovirt-cli 3.3.0.2 released
In-Reply-To: <515AD224.5020709@redhat.com>
References: <515AD224.5020709@redhat.com>
Message-ID: <5180CF89.60400@redhat.com>


- datetime.datetime object has no attribute __dict__ #957519
- remove pexpect dependency
- Ping command success message need to be rephrased #918749
- spicec does not pass cert_file #953582
- Error in "update network --cluster-identifier --usages-usage" #950993
- List/Show suggests parent+child as single param #950398
- Error type "brick" does not exist." on replace brick #923196
- Implement Session-TTL header support #928314
- unclear error message when using unsupported 2 levels attribute #949642
- correlation_id is not attached to update command #950441
- connect --help will log the user out of the disconnected cli #890340
- "help add" fails to format the error when number of provided args in incorrect #922018



More details can be found at [1].

[1] http://wiki.ovirt.org/Cli-changelog



-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Wed May  1 08:29:18 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 01 May 2013 11:29:18 +0300
Subject: [Engine-devel] REST vs. UI validation
In-Reply-To: <1909631386.7905748.1367393640867.JavaMail.root@redhat.com>
References: <80DC92D924DD7344818D4A17A1C995D7688D2B86@G9W0733.americas.hpqcorp.net>
	<179985819.7101058.1367306131556.JavaMail.root@redhat.com>
	<1757042330.5303868.1367391934702.JavaMail.root@redhat.com>
	<1909631386.7905748.1367393640867.JavaMail.root@redhat.com>
Message-ID: <5180D25E.7020906@redhat.com>

On 05/01/2013 10:34 AM, Vered Volansky wrote:
> 
> 
> ----- Original Message -----
>> From: "Allon Mureinik" <amureini at redhat.com>
>> To: "Vered Volansky" <vered at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, May 1, 2013 10:05:34 AM
>> Subject: Re: [Engine-devel] REST vs. UI validation
>>
>> REST shouldn't have any validations (perhaps maybe only that the passed type
>> is correct, etc. - Michael, correct me if I'm wrong).
>>
> I never said REST have any validations.
> When using REST only the backend validations are invoked.
> When using the UI there might be more validations only for UI before the backend validations are ever invoked.
> These validations aren't invoked for REST.

this is correct.

> 
>> The real validations are in the backend, which both REST and the GUI invoke.
>> Any validation the GUI does in addition to the backend is just a
>> user-experience enhancement (e.g., if !@#^!^$) is not a valid DC name, there
>> is no reason to send it to the backend).

the reason for this is user experience in UI, e.g in some cases validation
can be done on a client side (by regex etc showing errors in popup/balloon)
instead of sending heavy request to the backend over the wire and getting an
error in reply.

>>
>> Vered - I disagree that this is by design.
>> There is only one definition of what a correct value is, there should be no
>> ambiguity about it[1]
>> If the GUI prohibits you from a legal configuration - it should be fixed.
>> if the backend allows an illegal configuration - a CDA should be added.
>> My two cents - this is not OK, please open bugs (or even better - send
>> patches!) for the specific issues.
> 
> This was discussed with Michael (until he answers himself).
> More info on the issue -
> The backend validations are less restrictive than UI, but not contradicting it.
> This IS by design and is not a bug in general.
> The specific min-max differences example is for sure by design.
> In some (but I guess not all) cases the reasoning is a thought to expand possible values in the future.
> 
> So this is how things are right now.
> I agree it looks weird that you might be able to set "illegal" values in REST and then connect via UI and see these values.
> I suppose it can always come up for devel discussion whether that should be changed.

you cannot set any illegal value in REST-API, UI is more restrictive indeed,
while api expose all backend capabilities (including those that are restricted in UI)

> 
>>
>> [1] Just to be clear, there is a difference between not being able to do
>> something from the UI and having different validations.
>> For example, there is no GUI for scanning a storage domain
>> (http://www.ovirt.org/Features/Domain_Scan). I'd prefer having a GUI for
>> that too, but not having it is just a missing capability, not a disambiguity
>> with REST.
>>
>> ----- Original Message -----
>>> From: "Vered Volansky" <vered at redhat.com>
>>> To: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Tuesday, April 30, 2013 10:15:31 AM
>>> Subject: Re: [Engine-devel] REST vs. UI validation
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
>>>> To: engine-devel at ovirt.org
>>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
>>>> Subject: [Engine-devel] REST vs. UI validation
>>>>
>>>> I've been making use of the oVirt REST api, and have noticed that in
>>>> several
>>>> cases the validation done for a REST request is different than what the
>>>> admin UI does.  It seems that the UI is generally more restrictive on the
>>>> data it will accept than the backend.  So you can set things up using the
>>>> REST api that the UI wouldn't let you do.  Two examples I've hit
>>>> recently,
>>>> both in the cluster policy (load balancing section):
>>>>
>>>> - Cluster load balancing policy duration - the UI requires a value
>>>> between
>>>> 1
>>>> and 100, but the REST api seems to let you set it to any integer.
>>>>
>>>> - Cluster load balancing high and low thresholds / max and min service
>>>> levels
>>>> - The UI restricts the high value to 51-90% and the low value to 10-50%.
>>>> But the backend only requires that the values be 0-100% and that low
>>>> can't
>>>> be greater than high.
>>>>
>>>> So my question - is this intended behavior, or is it a bug that the
>>>> validation is different?  If similar validation should be done through
>>>> both
>>>> the UI and REST api, should the UI be less restrictive, or the backend
>>>> more
>>>> restrictive?
>>>
>>> This is the intended behaviour.
>>> The UI is often more restrictive than the api.
>>> By definition the api is more lenient that the UI.
>>>
>>> Regards,
>>> Vered
>>>>
>>>> Thanks,
>>>> Kari
>>>> _______________________________________________
>>>> 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
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From emesika at redhat.com  Wed May  1 13:28:42 2013
From: emesika at redhat.com (Eli Mesika)
Date: Wed, 1 May 2013 09:28:42 -0400 (EDT)
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <1260211145.3193784.1367387705950.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1180678810.4442250.1367369106621.JavaMail.root@redhat.com>
	<1260211145.3193784.1367387705950.JavaMail.root@redhat.com>
Message-ID: <1238444147.4677106.1367414922363.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "Juan Hernandez"
> <jhernand at redhat.com>
> Sent: Wednesday, May 1, 2013 8:55:05 AM
> Subject: Re: Dropping encryption of database password
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "Yair Zaslavsky"
> > <yzaslavs at redhat.com>, "Juan Hernandez"
> > <jhernand at redhat.com>
> > Sent: Wednesday, May 1, 2013 3:45:06 AM
> > Subject: Re: Dropping encryption of database password
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "Eli Mesika"
> > > <emesika at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>
> > > Sent: Tuesday, April 30, 2013 10:41:20 PM
> > > Subject: Dropping encryption of database password
> > > 
> > > Hello,
> > > 
> > > Currently we store database password encrypted using
> > > org.picketbox.datasource.security.SecureIdentityLoginModule.
> > > 
> > > This is reverse encryption with common knowledge shared secret.
> > > 
> > > Using encryption with common knowledge shared secret is close to void
> > > protection.
> > > 
> > > So far we also stored the password as plain text at
> > > /etc/ovirt-engine/.pgpass, this is going to be removed as no component
> > > actually uses the .pgpass, however we do need to store non-java specific
> > > password in for utilities.
> > > 
> > > In master (aiming to 3.3), we store the database connection details in
> > > own
> > > file /etc/ovirt-engine/engine.conf.d/50-setup-database.conf owned by
> > > ovirt
> > > user and not world readable.
> > > 
> > > I would like to use the same 50-setup-database.conf to store plain text
> > > password and remove the java specific reversible encrypted password
> > > usage.
> > > 
> > > Bottom line...
> > > 1. We drop the .pgpass file.
> > > 2. We store database connection information in
> > > /etc/ovirt-engine/engine.conf.d/<file> that is readable only by ovirt
> > > usage.
> > > 3. We drop the java specific reversible encryption in favor of plain
> > > text.
> > > 
> > > Thoughts?
> > 
> > I see no problem in the .pgpass , only root can access it (it has 0600 mode
> > ,
> > if it doesn't it is ignored by PG)
> > Apart from that , this is the standard way used by PG so why not using it ,
> > AFAIK this is considered safe & secured
> 
> In another words you are for storing password as plain text.... :)

If the file is protected , I don't mind that the password is in plain text...

> 
> > 
> > 
> > > Alon
> > > 
> > 
> 


From bressers at redhat.com  Wed May  1 15:40:26 2013
From: bressers at redhat.com (Josh Bressers)
Date: Wed, 1 May 2013 11:40:26 -0400 (EDT)
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <1238444147.4677106.1367414922363.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1180678810.4442250.1367369106621.JavaMail.root@redhat.com>
	<1260211145.3193784.1367387705950.JavaMail.root@redhat.com>
	<1238444147.4677106.1367414922363.JavaMail.root@redhat.com>
Message-ID: <1016105867.4755820.1367422826733.JavaMail.root@redhat.com>

> > 
> > In another words you are for storing password as plain text.... :)
> 
> If the file is protected , I don't mind that the password is in plain text...
> 

Hi all,

Itamar pointed me at this thread. I'm part of the Red Hat Product Security
Team, we exist to help various projects and products with security needs
(such as advice in this instance).

I can't really comment on this without understanding some of the background
(sorry for not being up to speed, I don't have time to research this
today and I'm away tomorrow so my replies may be slow).

Can you explain to me what the passwords in question are used for?

Thanks.

-- 
Josh Bressers / Red Hat Product Security Team


From alonbl at redhat.com  Wed May  1 15:58:12 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 1 May 2013 11:58:12 -0400 (EDT)
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <1016105867.4755820.1367422826733.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1180678810.4442250.1367369106621.JavaMail.root@redhat.com>
	<1260211145.3193784.1367387705950.JavaMail.root@redhat.com>
	<1238444147.4677106.1367414922363.JavaMail.root@redhat.com>
	<1016105867.4755820.1367422826733.JavaMail.root@redhat.com>
Message-ID: <1143910845.3284067.1367423892389.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Josh Bressers" <bressers at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>, "pmatouse" <pmatouse at redhat.com>
> Sent: Wednesday, May 1, 2013 6:40:26 PM
> Subject: Re: [Engine-devel] Dropping encryption of database password
> 
> > > 
> > > In another words you are for storing password as plain text.... :)
> > 
> > If the file is protected , I don't mind that the password is in plain
> > text...
> > 
> 
> Hi all,

Hello,
 
> Itamar pointed me at this thread. I'm part of the Red Hat Product Security
> Team, we exist to help various projects and products with security needs
> (such as advice in this instance).
> 
> I can't really comment on this without understanding some of the background
> (sorry for not being up to speed, I don't have time to research this
> today and I'm away tomorrow so my replies may be slow).
> 
> Can you explain to me what the passwords in question are used for?

The password of the user used to access the database.

Regards,
Alon

> 
> Thanks.
> 
> --
> Josh Bressers / Red Hat Product Security Team
> 


From Kari.Whitcomb at hp.com  Wed May  1 17:12:09 2013
From: Kari.Whitcomb at hp.com (Whitcomb, Kari)
Date: Wed, 1 May 2013 17:12:09 +0000
Subject: [Engine-devel] REST vs. UI validation
In-Reply-To: <5180D25E.7020906@redhat.com>
References: <80DC92D924DD7344818D4A17A1C995D7688D2B86@G9W0733.americas.hpqcorp.net>
	<179985819.7101058.1367306131556.JavaMail.root@redhat.com>
	<1757042330.5303868.1367391934702.JavaMail.root@redhat.com>
	<1909631386.7905748.1367393640867.JavaMail.root@redhat.com>
	<5180D25E.7020906@redhat.com>
Message-ID: <80DC92D924DD7344818D4A17A1C995D7688DB4A2@G4W3212.americas.hpqcorp.net>

Thanks for the discussion.  One clarifying question below...

-Kari

> >>
> >> Vered - I disagree that this is by design.
> >> There is only one definition of what a correct value is, there should be no
> >> ambiguity about it[1]
> >> If the GUI prohibits you from a legal configuration - it should be fixed.
> >> if the backend allows an illegal configuration - a CDA should be added.
> >> My two cents - this is not OK, please open bugs (or even better - send
> >> patches!) for the specific issues.
> >
> > This was discussed with Michael (until he answers himself).
> > More info on the issue -
> > The backend validations are less restrictive than UI, but not contradicting it.
> > This IS by design and is not a bug in general.
> > The specific min-max differences example is for sure by design.
> > In some (but I guess not all) cases the reasoning is a thought to expand
> possible values in the future.
> >
> > So this is how things are right now.
> > I agree it looks weird that you might be able to set "illegal" values in REST
> and then connect via UI and see these values.
> > I suppose it can always come up for devel discussion whether that should be
> changed.
> 
> you cannot set any illegal value in REST-API, UI is more restrictive indeed,
> while api expose all backend capabilities (including those that are restricted in
> UI)

So if I understanding correctly... The backend validations are checking legality. The UI may in some cases (like the specific ones I mentioned) impose additional restrictions/validations that further narrow the allowed input and this is by design and not a bug.  Does that sum the current state about right?

Thanks,
Kari

> >>> ----- Original Message -----
> >>>> From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
> >>>> To: engine-devel at ovirt.org
> >>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
> >>>> Subject: [Engine-devel] REST vs. UI validation
> >>>>
> >>>> I've been making use of the oVirt REST api, and have noticed that in
> >>>> several
> >>>> cases the validation done for a REST request is different than what the
> >>>> admin UI does.  It seems that the UI is generally more restrictive on the
> >>>> data it will accept than the backend.  So you can set things up using the
> >>>> REST api that the UI wouldn't let you do.  Two examples I've hit
> >>>> recently,
> >>>> both in the cluster policy (load balancing section):
> >>>>
> >>>> - Cluster load balancing policy duration - the UI requires a value
> >>>> between
> >>>> 1
> >>>> and 100, but the REST api seems to let you set it to any integer.
> >>>>
> >>>> - Cluster load balancing high and low thresholds / max and min service
> >>>> levels
> >>>> - The UI restricts the high value to 51-90% and the low value to 10-50%.
> >>>> But the backend only requires that the values be 0-100% and that low
> >>>> can't
> >>>> be greater than high.
> >>>>
> >>>> So my question - is this intended behavior, or is it a bug that the
> >>>> validation is different?  If similar validation should be done through
> >>>> both
> >>>> the UI and REST api, should the UI be less restrictive, or the backend
> >>>> more
> >>>> restrictive?
> >>>>
> >>>> Thanks,
> >>>> Kari


From vered at redhat.com  Wed May  1 17:41:15 2013
From: vered at redhat.com (Vered Volansky)
Date: Wed, 1 May 2013 13:41:15 -0400 (EDT)
Subject: [Engine-devel] REST vs. UI validation
In-Reply-To: <80DC92D924DD7344818D4A17A1C995D7688DB4A2@G4W3212.americas.hpqcorp.net>
References: <80DC92D924DD7344818D4A17A1C995D7688D2B86@G9W0733.americas.hpqcorp.net>
	<179985819.7101058.1367306131556.JavaMail.root@redhat.com>
	<1757042330.5303868.1367391934702.JavaMail.root@redhat.com>
	<1909631386.7905748.1367393640867.JavaMail.root@redhat.com>
	<5180D25E.7020906@redhat.com>
	<80DC92D924DD7344818D4A17A1C995D7688DB4A2@G4W3212.americas.hpqcorp.net>
Message-ID: <769847321.8237733.1367430075403.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
> To: "Michael Pasternak" <mpastern at redhat.com>, "Vered Volansky" <vered at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, May 1, 2013 8:12:09 PM
> Subject: RE: [Engine-devel] REST vs. UI validation
> 
> Thanks for the discussion.  One clarifying question below...
> 
> -Kari
> 
> > >>
> > >> Vered - I disagree that this is by design.
> > >> There is only one definition of what a correct value is, there should be
> > >> no
> > >> ambiguity about it[1]
> > >> If the GUI prohibits you from a legal configuration - it should be
> > >> fixed.
> > >> if the backend allows an illegal configuration - a CDA should be added.
> > >> My two cents - this is not OK, please open bugs (or even better - send
> > >> patches!) for the specific issues.
> > >
> > > This was discussed with Michael (until he answers himself).
> > > More info on the issue -
> > > The backend validations are less restrictive than UI, but not
> > > contradicting it.
> > > This IS by design and is not a bug in general.
> > > The specific min-max differences example is for sure by design.
> > > In some (but I guess not all) cases the reasoning is a thought to expand
> > possible values in the future.
> > >
> > > So this is how things are right now.
> > > I agree it looks weird that you might be able to set "illegal" values in
> > > REST
> > and then connect via UI and see these values.
> > > I suppose it can always come up for devel discussion whether that should
> > > be
> > changed.
> > 
> > you cannot set any illegal value in REST-API, UI is more restrictive
> > indeed,
> > while api expose all backend capabilities (including those that are
> > restricted in
> > UI)
> 
> So if I understanding correctly... The backend validations are checking
> legality. The UI may in some cases (like the specific ones I mentioned)
> impose additional restrictions/validations that further narrow the allowed
> input and this is by design and not a bug.  Does that sum the current state
> about right?
Yep.
> 
> Thanks,
> Kari
> 
> > >>> ----- Original Message -----
> > >>>> From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
> > >>>> To: engine-devel at ovirt.org
> > >>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
> > >>>> Subject: [Engine-devel] REST vs. UI validation
> > >>>>
> > >>>> I've been making use of the oVirt REST api, and have noticed that in
> > >>>> several
> > >>>> cases the validation done for a REST request is different than what
> > >>>> the
> > >>>> admin UI does.  It seems that the UI is generally more restrictive on
> > >>>> the
> > >>>> data it will accept than the backend.  So you can set things up using
> > >>>> the
> > >>>> REST api that the UI wouldn't let you do.  Two examples I've hit
> > >>>> recently,
> > >>>> both in the cluster policy (load balancing section):
> > >>>>
> > >>>> - Cluster load balancing policy duration - the UI requires a value
> > >>>> between
> > >>>> 1
> > >>>> and 100, but the REST api seems to let you set it to any integer.
> > >>>>
> > >>>> - Cluster load balancing high and low thresholds / max and min service
> > >>>> levels
> > >>>> - The UI restricts the high value to 51-90% and the low value to
> > >>>> 10-50%.
> > >>>> But the backend only requires that the values be 0-100% and that low
> > >>>> can't
> > >>>> be greater than high.
> > >>>>
> > >>>> So my question - is this intended behavior, or is it a bug that the
> > >>>> validation is different?  If similar validation should be done through
> > >>>> both
> > >>>> the UI and REST api, should the UI be less restrictive, or the backend
> > >>>> more
> > >>>> restrictive?
> > >>>>
> > >>>> Thanks,
> > >>>> Kari
> 


From bressers at redhat.com  Wed May  1 18:13:24 2013
From: bressers at redhat.com (Josh Bressers)
Date: Wed, 1 May 2013 14:13:24 -0400 (EDT)
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <1143910845.3284067.1367423892389.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1180678810.4442250.1367369106621.JavaMail.root@redhat.com>
	<1260211145.3193784.1367387705950.JavaMail.root@redhat.com>
	<1238444147.4677106.1367414922363.JavaMail.root@redhat.com>
	<1016105867.4755820.1367422826733.JavaMail.root@redhat.com>
	<1143910845.3284067.1367423892389.JavaMail.root@redhat.com>
Message-ID: <675589215.4826984.1367432004194.JavaMail.root@redhat.com>

> > 
> > > > 
> > > > In another words you are for storing password as plain text.... :)
> > > 
> > > If the file is protected , I don't mind that the password is in plain
> > > text...
> > > 
> > 
> > Hi all,
> 
> Hello,
>  
> > Itamar pointed me at this thread. I'm part of the Red Hat Product Security
> > Team, we exist to help various projects and products with security needs
> > (such as advice in this instance).
> > 
> > I can't really comment on this without understanding some of the background
> > (sorry for not being up to speed, I don't have time to research this
> > today and I'm away tomorrow so my replies may be slow).
> > 
> > Can you explain to me what the passwords in question are used for?
> 
> The password of the user used to access the database.
> 

Ahh, so the subject is quite literal.

So in an instance like this it's not uncommon to store this password as
plaintext in a file. The important part is then to ensure that the file is
protected and can only be accessed on a need-to-know basis.

Using various scrambling techniques don't really provide any additional
security. Some claim it makes things worse as it provides a false sense of
security.

I would suggest you make a note about what processes and users can view or
modify this file and for what reasons. This should help identify things in
the future that should or shouldn't have this level of access.

Let me know if you have any questions.

Thanks.

-- 
Josh Bressers / Red Hat Product Security Team


From alonbl at redhat.com  Wed May  1 18:16:53 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 1 May 2013 14:16:53 -0400 (EDT)
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <675589215.4826984.1367432004194.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1180678810.4442250.1367369106621.JavaMail.root@redhat.com>
	<1260211145.3193784.1367387705950.JavaMail.root@redhat.com>
	<1238444147.4677106.1367414922363.JavaMail.root@redhat.com>
	<1016105867.4755820.1367422826733.JavaMail.root@redhat.com>
	<1143910845.3284067.1367423892389.JavaMail.root@redhat.com>
	<675589215.4826984.1367432004194.JavaMail.root@redhat.com>
Message-ID: <1342664622.3315228.1367432213069.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Josh Bressers" <bressers at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>, "pmatouse" <pmatouse at redhat.com>
> Sent: Wednesday, May 1, 2013 9:13:24 PM
> Subject: Re: [Engine-devel] Dropping encryption of database password
> 
> > > 
> > > > > 
> > > > > In another words you are for storing password as plain text.... :)
> > > > 
> > > > If the file is protected , I don't mind that the password is in plain
> > > > text...
> > > > 
> > > 
> > > Hi all,
> > 
> > Hello,
> >  
> > > Itamar pointed me at this thread. I'm part of the Red Hat Product
> > > Security
> > > Team, we exist to help various projects and products with security needs
> > > (such as advice in this instance).
> > > 
> > > I can't really comment on this without understanding some of the
> > > background
> > > (sorry for not being up to speed, I don't have time to research this
> > > today and I'm away tomorrow so my replies may be slow).
> > > 
> > > Can you explain to me what the passwords in question are used for?
> > 
> > The password of the user used to access the database.
> > 
> 
> Ahh, so the subject is quite literal.
> 
> So in an instance like this it's not uncommon to store this password as
> plaintext in a file. The important part is then to ensure that the file is
> protected and can only be accessed on a need-to-know basis.
> 
> Using various scrambling techniques don't really provide any additional
> security. Some claim it makes things worse as it provides a false sense of
> security.
> 
> I would suggest you make a note about what processes and users can view or
> modify this file and for what reasons. This should help identify things in
> the future that should or shouldn't have this level of access.
> 
> Let me know if you have any questions.
> 
> Thanks.

Thank you.
This is what I wrote in my initial post.
The only users who should access this password is ovirt user and root user.

Regards,
Alon Bar-Lev. 

> 
> --
> Josh Bressers / Red Hat Product Security Team
> 


From kroberts at redhat.com  Wed May  1 18:31:15 2013
From: kroberts at redhat.com (Keith Robertson)
Date: Wed, 01 May 2013 14:31:15 -0400
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <1342664622.3315228.1367432213069.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1180678810.4442250.1367369106621.JavaMail.root@redhat.com>
	<1260211145.3193784.1367387705950.JavaMail.root@redhat.com>
	<1238444147.4677106.1367414922363.JavaMail.root@redhat.com>
	<1016105867.4755820.1367422826733.JavaMail.root@redhat.com>
	<1143910845.3284067.1367423892389.JavaMail.root@redhat.com>
	<675589215.4826984.1367432004194.JavaMail.root@redhat.com>
	<1342664622.3315228.1367432213069.JavaMail.root@redhat.com>
Message-ID: <51815F73.4030208@redhat.com>

On 05/01/2013 02:16 PM, Alon Bar-Lev wrote:
> Thank you.
> This is what I wrote in my initial post.
> The only users who should access this password is ovirt user and root user.
>
> Regards,
> Alon Bar-Lev.
>
>> >
Alon,
I agree with the desire to store the PW in plaintext and in a 
non-obfuscated manner.  In this case, obfuscation really doesn't gain 
anything.

I would suggest; however, that the migration to plaintext be coordinated 
with a simultaneous patch to the the Log Collector.  It does have a 
dependency on the current architecture.

Keith


From alonbl at redhat.com  Wed May  1 18:40:13 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 1 May 2013 14:40:13 -0400 (EDT)
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <51815F73.4030208@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1260211145.3193784.1367387705950.JavaMail.root@redhat.com>
	<1238444147.4677106.1367414922363.JavaMail.root@redhat.com>
	<1016105867.4755820.1367422826733.JavaMail.root@redhat.com>
	<1143910845.3284067.1367423892389.JavaMail.root@redhat.com>
	<675589215.4826984.1367432004194.JavaMail.root@redhat.com>
	<1342664622.3315228.1367432213069.JavaMail.root@redhat.com>
	<51815F73.4030208@redhat.com>
Message-ID: <1026006636.3322172.1367433613876.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Keith Robertson" <kroberts at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Josh Bressers" <bressers at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>, "pmatouse" <pmatouse at redhat.com>, "Sandro Bonazzola" <sbonazzo at redhat.com>
> Sent: Wednesday, May 1, 2013 9:31:15 PM
> Subject: Re: [Engine-devel] Dropping encryption of database password
> 
> On 05/01/2013 02:16 PM, Alon Bar-Lev wrote:
> > Thank you.
> > This is what I wrote in my initial post.
> > The only users who should access this password is ovirt user and root user.
> >
> > Regards,
> > Alon Bar-Lev.
> >
> >> >
> Alon,
> I agree with the desire to store the PW in plaintext and in a
> non-obfuscated manner.  In this case, obfuscation really doesn't gain
> anything.
> 
> I would suggest; however, that the migration to plaintext be coordinated
> with a simultaneous patch to the the Log Collector.  It does have a
> dependency on the current architecture.
> 
> Keith
> 

Hi,

As far as I know it reads the plain text from .pgpass, we need to modify it to search within the alternate format as well.

Thanks,
Alon


From liqiang.net at gmail.com  Wed May  1 23:40:14 2013
From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=)
Date: Thu, 2 May 2013 07:40:14 +0800
Subject: [Engine-devel] Error: could not create ovirtsdk API object
In-Reply-To: <517D23DB.6010304@redhat.com>
References: <CAH=UCn6bZnQJRwWbDpnt-mcrrbEJq9T_aUJwva6r3HK+zm-1WA@mail.gmail.com>
	<517D23DB.6010304@redhat.com>
Message-ID: <CAH=UCn5jUyVCWQd3-eqhAFiG-MOrKMFAU9YJ-mw6L7_5dS1kZA@mail.gmail.com>

The bug is fix?

if not,What will I DO ?

Thanks,


2013/4/28 Itamar Heim <iheim at redhat.com>

> Bug 947753 - [AIO] 'Error: could not create ovirtsdk API object' during
> installation?




HI?All

?????

---
???????????
??

------------------------------------------------------------------------------


+ ????????????????(????1:1) +
------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130502/80bf6a7a/attachment.html>

From wlbleaboy at 126.com  Thu May  2 02:52:33 2013
From: wlbleaboy at 126.com (leaboy@126)
Date: Thu, 2 May 2013 10:52:33 +0800
Subject: [Engine-devel] about ovirt-engine-sdk
Message-ID: <000a01ce46e0$195dcf40$4c196dc0$@com>

Hi,all

         How can I use overt-engine-sdk in the python environment below
python2.7,

For example, when I use it in python 2.6.5 like thus:

 

percy at percy-desktop:~/thtf-client$ python --version

Python 2.6.5

percy at percy-desktop:~/thtf-client$ python

Python 2.6.5 (r265:79063, Oct  1 2012, 22:04:36) 

[GCC 4.4.3] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> from ovirtsdk.api import API

>>> from ovirtsdk.xml import params

>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
None, '~/.spicec/ca.crt', None, None, True)

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File "ovirtsdk/api.py", line 107, in __init__

    url='/api')

  File "ovirtsdk/infrastructure/proxy.py", line 129, in request

    last=last)

  File "ovirtsdk/infrastructure/proxy.py", line 171, in __doRequest

    return params.parseString(response_body) if response_body is not None
and response_body is not '' \

  File "ovirtsdk/xml/params.py", line 21229, in parseString

    rootObj.build(rootNode)

  File "ovirtsdk/xml/params.py", line 20304, in build

    self.buildAttributes(node, node.attrib, [])

  File "ovirtsdk/xml/params.py", line 20309, in buildAttributes

    super(API, self).buildAttributes(node, attrs, already_processed)

  File "ovirtsdk/xml/params.py", line 4160, in buildAttributes

    value = find_attr_value_('xsi:type', node)

  File "ovirtsdk/xml/params.py", line 316, in find_attr_value_

    namespace = node.nsmap.get(prefix)

AttributeError: nsmap

>>> 

 

 

But, when I use it in python 2.7.3, it's ok

 

leaboy at leaboy:~/workspace/thtf-client$ python --version

Python 2.7.3

leaboy at leaboy:~/workspace/thtf-client$ python

Python 2.7.3 (default, Aug  1 2012, 05:16:07) 

[GCC 4.6.3] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> from ovirtsdk.api import API

>>> from ovirtsdk.xml import params

>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
None, '~/.spicec/ca.crt', None, True)

>>> 

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

From wlbleaboy at 126.com  Thu May  2 02:53:54 2013
From: wlbleaboy at 126.com (leaboy@126)
Date: Thu, 2 May 2013 10:53:54 +0800
Subject: [Engine-devel] about ovirt-engine-sdk
Message-ID: <000f01ce46e0$490d4c70$db27e550$@com>

Hi,all

         How can I use overt-engine-sdk in the python environment below
python2.7,

For example, when I use it in python 2.6.5 like thus:

 

percy at percy-desktop:~/thtf-client$ python --version

Python 2.6.5

percy at percy-desktop:~/thtf-client$ python

Python 2.6.5 (r265:79063, Oct  1 2012, 22:04:36) 

[GCC 4.4.3] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> from ovirtsdk.api import API

>>> from ovirtsdk.xml import params

>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
None, '~/.spicec/ca.crt', None, None, True)

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File "ovirtsdk/api.py", line 107, in __init__

    url='/api')

  File "ovirtsdk/infrastructure/proxy.py", line 129, in request

    last=last)

  File "ovirtsdk/infrastructure/proxy.py", line 171, in __doRequest

    return params.parseString(response_body) if response_body is not None
and response_body is not '' \

  File "ovirtsdk/xml/params.py", line 21229, in parseString

    rootObj.build(rootNode)

  File "ovirtsdk/xml/params.py", line 20304, in build

    self.buildAttributes(node, node.attrib, [])

  File "ovirtsdk/xml/params.py", line 20309, in buildAttributes

    super(API, self).buildAttributes(node, attrs, already_processed)

  File "ovirtsdk/xml/params.py", line 4160, in buildAttributes

    value = find_attr_value_('xsi:type', node)

  File "ovirtsdk/xml/params.py", line 316, in find_attr_value_

    namespace = node.nsmap.get(prefix)

AttributeError: nsmap

>>> 

 

 

But, when I use it in python 2.7.3, it's ok

 

leaboy at leaboy:~/workspace/thtf-client$ python --version

Python 2.7.3

leaboy at leaboy:~/workspace/thtf-client$ python

Python 2.7.3 (default, Aug  1 2012, 05:16:07) 

[GCC 4.6.3] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> from ovirtsdk.api import API

>>> from ovirtsdk.xml import params

>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
None, '~/.spicec/ca.crt', None, True)

>>> 

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

From rgolan at redhat.com  Thu May  2 05:29:44 2013
From: rgolan at redhat.com (Roy Golan)
Date: Thu, 02 May 2013 08:29:44 +0300
Subject: [Engine-devel] REST vs. UI validation
In-Reply-To: <769847321.8237733.1367430075403.JavaMail.root@redhat.com>
References: <80DC92D924DD7344818D4A17A1C995D7688D2B86@G9W0733.americas.hpqcorp.net>
	<179985819.7101058.1367306131556.JavaMail.root@redhat.com>
	<1757042330.5303868.1367391934702.JavaMail.root@redhat.com>
	<1909631386.7905748.1367393640867.JavaMail.root@redhat.com>
	<5180D25E.7020906@redhat.com>
	<80DC92D924DD7344818D4A17A1C995D7688DB4A2@G4W3212.americas.hpqcorp.net>
	<769847321.8237733.1367430075403.JavaMail.root@redhat.com>
Message-ID: <5181F9C8.7070207@redhat.com>

On Wed 01 May 2013 08:41:15 PM IDT, Vered Volansky wrote:
>
>
> ----- Original Message -----
>> From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
>> To: "Michael Pasternak" <mpastern at redhat.com>, "Vered Volansky" <vered at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, May 1, 2013 8:12:09 PM
>> Subject: RE: [Engine-devel] REST vs. UI validation
>>
>> Thanks for the discussion.  One clarifying question below...
>>
>> -Kari
>>
>>>>>
>>>>> Vered - I disagree that this is by design.
>>>>> There is only one definition of what a correct value is, there should be
>>>>> no
>>>>> ambiguity about it[1]
>>>>> If the GUI prohibits you from a legal configuration - it should be
>>>>> fixed.
>>>>> if the backend allows an illegal configuration - a CDA should be added.
>>>>> My two cents - this is not OK, please open bugs (or even better - send
>>>>> patches!) for the specific issues.
>>>>
>>>> This was discussed with Michael (until he answers himself).
>>>> More info on the issue -
>>>> The backend validations are less restrictive than UI, but not
>>>> contradicting it.
>>>> This IS by design and is not a bug in general.
>>>> The specific min-max differences example is for sure by design.
>>>> In some (but I guess not all) cases the reasoning is a thought to expand
>>> possible values in the future.
>>>>
>>>> So this is how things are right now.
>>>> I agree it looks weird that you might be able to set "illegal" values in
>>>> REST
>>> and then connect via UI and see these values.
>>>> I suppose it can always come up for devel discussion whether that should
>>>> be
>>> changed.
>>>
>>> you cannot set any illegal value in REST-API, UI is more restrictive
>>> indeed,
>>> while api expose all backend capabilities (including those that are
>>> restricted in
>>> UI)
>>
>> So if I understanding correctly... The backend validations are checking
>> legality. The UI may in some cases (like the specific ones I mentioned)
>> impose additional restrictions/validations that further narrow the allowed
>> input and this is by design and not a bug.  Does that sum the current state
>> about right?
> Yep.
I disagree. The UI is validating input to fail as fast and save 
rountrips for better responsiveness and overall a better UX. This means 
validation are duplicated and sometimes, different - which I consider a 
bug - there is no good reason an action would be valid using the API 
and invalid with UI or vise versa.

the main chalenge is to share the validation code which might be 
achievablle if GWT will support our validation annotation on beans 
(jsr303)  - Vojetech this one I think you'll be able to help with

>>
>> Thanks,
>> Kari
>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
>>>>>>> To: engine-devel at ovirt.org
>>>>>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
>>>>>>> Subject: [Engine-devel] REST vs. UI validation
>>>>>>>
>>>>>>> I've been making use of the oVirt REST api, and have noticed that in
>>>>>>> several
>>>>>>> cases the validation done for a REST request is different than what
>>>>>>> the
>>>>>>> admin UI does.  It seems that the UI is generally more restrictive on
>>>>>>> the
>>>>>>> data it will accept than the backend.  So you can set things up using
>>>>>>> the
>>>>>>> REST api that the UI wouldn't let you do.  Two examples I've hit
>>>>>>> recently,
>>>>>>> both in the cluster policy (load balancing section):
>>>>>>>
>>>>>>> - Cluster load balancing policy duration - the UI requires a value
>>>>>>> between
>>>>>>> 1
>>>>>>> and 100, but the REST api seems to let you set it to any integer.
>>>>>>>
>>>>>>> - Cluster load balancing high and low thresholds / max and min service
>>>>>>> levels
>>>>>>> - The UI restricts the high value to 51-90% and the low value to
>>>>>>> 10-50%.
>>>>>>> But the backend only requires that the values be 0-100% and that low
>>>>>>> can't
>>>>>>> be greater than high.
>>>>>>>
>>>>>>> So my question - is this intended behavior, or is it a bug that the
>>>>>>> validation is different?  If similar validation should be done through
>>>>>>> both
>>>>>>> the UI and REST api, should the UI be less restrictive, or the backend
>>>>>>> more
>>>>>>> restrictive?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Kari
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel




From mpastern at redhat.com  Thu May  2 05:51:37 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Thu, 02 May 2013 08:51:37 +0300
Subject: [Engine-devel] REST vs. UI validation
In-Reply-To: <80DC92D924DD7344818D4A17A1C995D7688DB4A2@G4W3212.americas.hpqcorp.net>
References: <80DC92D924DD7344818D4A17A1C995D7688D2B86@G9W0733.americas.hpqcorp.net>
	<179985819.7101058.1367306131556.JavaMail.root@redhat.com>
	<1757042330.5303868.1367391934702.JavaMail.root@redhat.com>
	<1909631386.7905748.1367393640867.JavaMail.root@redhat.com>
	<5180D25E.7020906@redhat.com>
	<80DC92D924DD7344818D4A17A1C995D7688DB4A2@G4W3212.americas.hpqcorp.net>
Message-ID: <5181FEE9.8040808@redhat.com>

On 05/01/2013 08:12 PM, Whitcomb, Kari wrote:
> Thanks for the discussion.  One clarifying question below...
> 
> -Kari
> 
>>>>
>>>> Vered - I disagree that this is by design.
>>>> There is only one definition of what a correct value is, there should be no
>>>> ambiguity about it[1]
>>>> If the GUI prohibits you from a legal configuration - it should be fixed.
>>>> if the backend allows an illegal configuration - a CDA should be added.
>>>> My two cents - this is not OK, please open bugs (or even better - send
>>>> patches!) for the specific issues.
>>>
>>> This was discussed with Michael (until he answers himself).
>>> More info on the issue -
>>> The backend validations are less restrictive than UI, but not contradicting it.
>>> This IS by design and is not a bug in general.
>>> The specific min-max differences example is for sure by design.
>>> In some (but I guess not all) cases the reasoning is a thought to expand
>> possible values in the future.
>>>
>>> So this is how things are right now.
>>> I agree it looks weird that you might be able to set "illegal" values in REST
>> and then connect via UI and see these values.
>>> I suppose it can always come up for devel discussion whether that should be
>> changed.
>>
>> you cannot set any illegal value in REST-API, UI is more restrictive indeed,
>> while api expose all backend capabilities (including those that are restricted in
>> UI)
> 
> So if I understanding correctly... The backend validations are checking legality. The UI may in some cases (like the specific ones I mentioned) impose additional restrictions/validations that further narrow the allowed input and this is by design and not a bug.  Does that sum the current state about right?

yep.

> 
> Thanks,
> Kari
> 
>>>>> ----- Original Message -----
>>>>>> From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
>>>>>> To: engine-devel at ovirt.org
>>>>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
>>>>>> Subject: [Engine-devel] REST vs. UI validation
>>>>>>
>>>>>> I've been making use of the oVirt REST api, and have noticed that in
>>>>>> several
>>>>>> cases the validation done for a REST request is different than what the
>>>>>> admin UI does.  It seems that the UI is generally more restrictive on the
>>>>>> data it will accept than the backend.  So you can set things up using the
>>>>>> REST api that the UI wouldn't let you do.  Two examples I've hit
>>>>>> recently,
>>>>>> both in the cluster policy (load balancing section):
>>>>>>
>>>>>> - Cluster load balancing policy duration - the UI requires a value
>>>>>> between
>>>>>> 1
>>>>>> and 100, but the REST api seems to let you set it to any integer.
>>>>>>
>>>>>> - Cluster load balancing high and low thresholds / max and min service
>>>>>> levels
>>>>>> - The UI restricts the high value to 51-90% and the low value to 10-50%.
>>>>>> But the backend only requires that the values be 0-100% and that low
>>>>>> can't
>>>>>> be greater than high.
>>>>>>
>>>>>> So my question - is this intended behavior, or is it a bug that the
>>>>>> validation is different?  If similar validation should be done through
>>>>>> both
>>>>>> the UI and REST api, should the UI be less restrictive, or the backend
>>>>>> more
>>>>>> restrictive?
>>>>>>
>>>>>> Thanks,
>>>>>> Kari


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Thu May  2 06:05:43 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Thu, 02 May 2013 09:05:43 +0300
Subject: [Engine-devel] REST vs. UI validation
In-Reply-To: <5181F9C8.7070207@redhat.com>
References: <80DC92D924DD7344818D4A17A1C995D7688D2B86@G9W0733.americas.hpqcorp.net>
	<179985819.7101058.1367306131556.JavaMail.root@redhat.com>
	<1757042330.5303868.1367391934702.JavaMail.root@redhat.com>
	<1909631386.7905748.1367393640867.JavaMail.root@redhat.com>
	<5180D25E.7020906@redhat.com>
	<80DC92D924DD7344818D4A17A1C995D7688DB4A2@G4W3212.americas.hpqcorp.net>
	<769847321.8237733.1367430075403.JavaMail.root@redhat.com>
	<5181F9C8.7070207@redhat.com>
Message-ID: <51820237.8010406@redhat.com>


Hi Roy,

On 05/02/2013 08:29 AM, Roy Golan wrote:
> On Wed 01 May 2013 08:41:15 PM IDT, Vered Volansky wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
>>> To: "Michael Pasternak" <mpastern at redhat.com>, "Vered Volansky" <vered at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Wednesday, May 1, 2013 8:12:09 PM
>>> Subject: RE: [Engine-devel] REST vs. UI validation
>>>
>>> Thanks for the discussion.  One clarifying question below...
>>>
>>> -Kari
>>>
>>>>>>
>>>>>> Vered - I disagree that this is by design.
>>>>>> There is only one definition of what a correct value is, there should be
>>>>>> no
>>>>>> ambiguity about it[1]
>>>>>> If the GUI prohibits you from a legal configuration - it should be
>>>>>> fixed.
>>>>>> if the backend allows an illegal configuration - a CDA should be added.
>>>>>> My two cents - this is not OK, please open bugs (or even better - send
>>>>>> patches!) for the specific issues.
>>>>>
>>>>> This was discussed with Michael (until he answers himself).
>>>>> More info on the issue -
>>>>> The backend validations are less restrictive than UI, but not
>>>>> contradicting it.
>>>>> This IS by design and is not a bug in general.
>>>>> The specific min-max differences example is for sure by design.
>>>>> In some (but I guess not all) cases the reasoning is a thought to expand
>>>> possible values in the future.
>>>>>
>>>>> So this is how things are right now.
>>>>> I agree it looks weird that you might be able to set "illegal" values in
>>>>> REST
>>>> and then connect via UI and see these values.
>>>>> I suppose it can always come up for devel discussion whether that should
>>>>> be
>>>> changed.
>>>>
>>>> you cannot set any illegal value in REST-API, UI is more restrictive
>>>> indeed,
>>>> while api expose all backend capabilities (including those that are
>>>> restricted in
>>>> UI)
>>>
>>> So if I understanding correctly... The backend validations are checking
>>> legality. The UI may in some cases (like the specific ones I mentioned)
>>> impose additional restrictions/validations that further narrow the allowed
>>> input and this is by design and not a bug.  Does that sum the current state
>>> about right?
>> Yep.
> I disagree. The UI is validating input to fail as fast and save rountrips for better responsiveness and overall a better UX. This means validation are duplicated and
> sometimes, different - which I consider a bug - there is no good reason an action would be valid using the API and invalid with UI or vise versa.

you basically repeating told above, if you'll read this tread from the beginning,
kari gives two examples in "Cluster load balancing" both not even near to be "different",
it's just a different (UI) representation for same thing, UI actually hiding engine implementation
details over mentioned properties.

> 
> the main chalenge is to share the validation code which might be achievablle if GWT will support our validation annotation on beans (jsr303)  - Vojetech this one I think
> you'll be able to help with

this is nice to have approach and will work with static validations only (that does
not require dialogue with the engine), in any case api don't have any validation concept (except
of mandatory parameters existence) and should not have, as engine do this job, - and that what
we trying to make clear,

but again not always same validations as mentioned above will take place on both client and engine
sides.

> 
>>>
>>> Thanks,
>>> Kari
>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
>>>>>>>> Subject: [Engine-devel] REST vs. UI validation
>>>>>>>>
>>>>>>>> I've been making use of the oVirt REST api, and have noticed that in
>>>>>>>> several
>>>>>>>> cases the validation done for a REST request is different than what
>>>>>>>> the
>>>>>>>> admin UI does.  It seems that the UI is generally more restrictive on
>>>>>>>> the
>>>>>>>> data it will accept than the backend.  So you can set things up using
>>>>>>>> the
>>>>>>>> REST api that the UI wouldn't let you do.  Two examples I've hit
>>>>>>>> recently,
>>>>>>>> both in the cluster policy (load balancing section):
>>>>>>>>
>>>>>>>> - Cluster load balancing policy duration - the UI requires a value
>>>>>>>> between
>>>>>>>> 1
>>>>>>>> and 100, but the REST api seems to let you set it to any integer.
>>>>>>>>
>>>>>>>> - Cluster load balancing high and low thresholds / max and min service
>>>>>>>> levels
>>>>>>>> - The UI restricts the high value to 51-90% and the low value to
>>>>>>>> 10-50%.
>>>>>>>> But the backend only requires that the values be 0-100% and that low
>>>>>>>> can't
>>>>>>>> be greater than high.
>>>>>>>>
>>>>>>>> So my question - is this intended behavior, or is it a bug that the
>>>>>>>> validation is different?  If similar validation should be done through
>>>>>>>> both
>>>>>>>> the UI and REST api, should the UI be less restrictive, or the backend
>>>>>>>> more
>>>>>>>> restrictive?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Kari
>>>
>> _______________________________________________
>> 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


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Thu May  2 06:18:45 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Thu, 02 May 2013 09:18:45 +0300
Subject: [Engine-devel] about ovirt-engine-sdk
In-Reply-To: <000f01ce46e0$490d4c70$db27e550$@com>
References: <000f01ce46e0$490d4c70$db27e550$@com>
Message-ID: <51820545.9060904@redhat.com>


Hi,

On 05/02/2013 05:53 AM, leaboy at 126 wrote:
> Hi,all
> 
> How can I use overt-engine-sdk in the python environment below python2.7,
> 
> For example, when I use it in python 2.6.5 like thus:

what sdk version you're using?
how did you installed it?
what version of lxml you have installed?

> 
>  
> 
> percy at percy-desktop:~/thtf-client$ python --version
> 
> Python 2.6.5
> 
> percy at percy-desktop:~/thtf-client$ python
> 
> Python 2.6.5 (r265:79063, Oct  1 2012, 22:04:36)
> 
> [GCC 4.4.3] on linux2
> 
> Type "help", "copyright", "credits" or "license" for more information.
> 
>>>> from ovirtsdk.api import API
> 
>>>> from ovirtsdk.xml import params
> 
>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None, None, '~/.spicec/ca.crt', None, None, True)
> 
> *Traceback (most recent call last):*
> 
> *  File "<stdin>", line 1, in <module>*
> 
> *  File "ovirtsdk/api.py", line 107, in __init__*
> 
> *    url='/api')*
> 
> *  File "ovirtsdk/infrastructure/proxy.py", line 129, in request*
> 
> *    last=last)*
> 
> *  File "ovirtsdk/infrastructure/proxy.py", line 171, in __doRequest*
> 
> *    return params.parseString(response_body) if response_body is not None and response_body is not '' \*
> 
> *  File "ovirtsdk/xml/params.py", line 21229, in parseString*
> 
> *    rootObj.build(rootNode)*
> 
> *  File "ovirtsdk/xml/params.py", line 20304, in build*
> 
> *    self.buildAttributes(node, node.attrib, [])*
> 
> *  File "ovirtsdk/xml/params.py", line 20309, in buildAttributes*
> 
> *    super(API, self).buildAttributes(node, attrs, already_processed)*
> 
> *  File "ovirtsdk/xml/params.py", line 4160, in buildAttributes*
> 
> *    value = find_attr_value_('xsi:type', node)*
> 
> *  File "ovirtsdk/xml/params.py", line 316, in find_attr_value_*
> 
> *    namespace = node.nsmap.get(prefix)*
> 
> *AttributeError: nsmap*
> 
>>>> 
> 
>  
> 
>  
> 
> But, when I use it in python 2.7.3, it?s ok
> 
>  
> 
> leaboy at leaboy:~/workspace/thtf-client$ python --version
> 
> Python 2.7.3
> 
> leaboy at leaboy:~/workspace/thtf-client$ python
> 
> Python 2.7.3 (default, Aug  1 2012, 05:16:07)
> 
> [GCC 4.6.3] on linux2
> 
> Type "help", "copyright", "credits" or "license" for more information.
> 
>>>> from ovirtsdk.api import API
> 
>>>> from ovirtsdk.xml import params
> 
>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None, None, '~/.spicec/ca.crt', None, True)
> 
>>>> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From iheim at redhat.com  Thu May  2 06:57:00 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 02 May 2013 09:57:00 +0300
Subject: [Engine-devel] Error: could not create ovirtsdk API object
In-Reply-To: <CAH=UCn5jUyVCWQd3-eqhAFiG-MOrKMFAU9YJ-mw6L7_5dS1kZA@mail.gmail.com>
References: <CAH=UCn6bZnQJRwWbDpnt-mcrrbEJq9T_aUJwva6r3HK+zm-1WA@mail.gmail.com>
	<517D23DB.6010304@redhat.com>
	<CAH=UCn5jUyVCWQd3-eqhAFiG-MOrKMFAU9YJ-mw6L7_5dS1kZA@mail.gmail.com>
Message-ID: <51820E3C.5060304@redhat.com>

On 05/02/2013 02:40 AM, ?? wrote:
> The bug is fix?
> 
> if not,What will I DO ?
> 
> Thanks,
> 
> 
> 2013/4/28 Itamar Heim <iheim at redhat.com <mailto:iheim at redhat.com>>
> 
>     Bug 947753 - [AIO] 'Error: could not create ovirtsdk API object'
>     during installation?
> 
> 
> 
> 
> HI?All
> 
> ?????
> 
> ---
> ???????????
> ??
> 
> ------------------------------------------------------------------------------ 
> 
> 
> + ????????????????(????1:1) +
> ------------------------------------------------------------------------------

alex - is this part of ovirt 3.2.2?


From wei.d.chen at intel.com  Thu May  2 08:06:18 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Thu, 2 May 2013 08:06:18 +0000
Subject: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1
 running enviroment?
In-Reply-To: <5152C521.9090302@redhat.com>
References: <C5A0092C63E939488005F15F736A8112097A6EA2@SHSMSX101.ccr.corp.intel.com>
	<5152C521.9090302@redhat.com>
Message-ID: <C5A0092C63E939488005F15F736A8112097AB2BC@SHSMSX101.ccr.corp.intel.com>

Hi,

This is a very old thread, grep this mail out just because we still face some issues when we try to set up a workable ovirt environment with latest ovirt package repository.
My first question is since glusterfs-3.4 is required to setup ovirt, why we not add glusterfs-3.4 into ovirt package repository?

My another question is when we tried to add a host to default cluster, it complains "No package(s) available to install" in the step of installing "libvirt" and "vdsm", but these packages can be found from ovirt repository? how to fix this? some extra clue is we can install these packages with  fedora 18 repository, so, is it possible to specify a repository for ovirt node's installing? We just want to install all of these binaries from ovirt repository to avoid some version inconsistent issue.

The last one is whether it is possible to generate a trust_store.jks manually as we failed to find this file in our current environment.

Best Regards,
Dave Chen

From: Shireesh Anjal [mailto:sanjal at redhat.com]
Sent: Wednesday, March 27, 2013 6:09 PM
To: Chen, Wei D
Cc: engine-devel at ovirt.org
Subject: Re: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment?

On 03/26/2013 09:20 AM, Chen, Wei D wrote:

Hi,



We notice that ovirt-engine's version (rpm package and source code) has updated from 3.2.0 to 3.2.1. As our development process is always based on 3.2.0. Is there any way to re-setup 3.2.0 running environment?



Besides, we also cannot setup 3.2.1 ovrit-engine running environment as its dependent package glusterfs-3.4 cannot be found from ovirt repo or fedora18 repo. How can I fix this issue?  Thanks.

glusterfs-3.4.0alph2 packages can be obtained from following yum repo:

http://bits.gluster.org/pub/gluster/glusterfs/stage/

This is required only if the cluster in which you are adding the host has gluster service enabled.







Best Regards,

Dave Chen





_______________________________________________

Engine-devel mailing list

Engine-devel at ovirt.org<mailto:Engine-devel at ovirt.org>

http://lists.ovirt.org/mailman/listinfo/engine-devel

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

From wlbleaboy at 126.com  Thu May  2 08:06:44 2013
From: wlbleaboy at 126.com (leaboy@126)
Date: Thu, 2 May 2013 16:06:44 +0800
Subject: [Engine-devel] =?gb2312?b?tPC4tDogYWJvdXQgb3ZpcnQtZW5naW5lLXNk?=
	=?gb2312?b?aw==?=
In-Reply-To: <51820545.9060904@redhat.com>
References: <000f01ce46e0$490d4c70$db27e550$@com> <51820545.9060904@redhat.com>
Message-ID: <001401ce470b$fd5547c0$f7ffd740$@com>

The code I got in 2013-1-27 with git, I don't know which version I got, 
I didn't install it , I just use it like the example, 

 leaboy at leaboy:~/workspace/thtf-client$ python --version 
 Python 2.7.3 
 leaboy at leaboy:~/workspace/thtf-client$ python 
 Python 2.7.3 (default, Aug  1 2012, 05:16:07) 
 [GCC 4.6.3] on linux2 
 Type "help", "copyright", "credits" or "license" for more information.
 
 >>> from ovirtsdk.api import API 
 >>> from ovirtsdk.xml import params 
 >>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
None, '~/.spicec/ca.crt', None, True) 
 >>>

I use it successful in ubuntu 12.04 without any other operation,
Just import the modules with python 2.7.3

But when I use it in other OS, such as ubuntu 11, or embed linux for ARM,
With python 2.6.*, It does't work,



-----????-----
???: Michael Pasternak [mailto:mpastern at redhat.com] 
????: 2013?5?2? 14:19
???: leaboy at 126
??: engine-devel at ovirt.org
??: Re: about ovirt-engine-sdk


Hi,

On 05/02/2013 05:53 AM, leaboy at 126 wrote:
> Hi,all
> 
> How can I use overt-engine-sdk in the python environment below python2.7,
> 
> For example, when I use it in python 2.6.5 like thus:

what sdk version you're using?
how did you installed it?
what version of lxml you have installed?

> 
>  
> 
> percy at percy-desktop:~/thtf-client$ python --version
> 
> Python 2.6.5
> 
> percy at percy-desktop:~/thtf-client$ python
> 
> Python 2.6.5 (r265:79063, Oct  1 2012, 22:04:36)
> 
> [GCC 4.4.3] on linux2
> 
> Type "help", "copyright", "credits" or "license" for more information.
> 
>>>> from ovirtsdk.api import API
> 
>>>> from ovirtsdk.xml import params
> 
>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
None, '~/.spicec/ca.crt', None, None, True)
> 
> *Traceback (most recent call last):*
> 
> *  File "<stdin>", line 1, in <module>*
> 
> *  File "ovirtsdk/api.py", line 107, in __init__*
> 
> *    url='/api')*
> 
> *  File "ovirtsdk/infrastructure/proxy.py", line 129, in request*
> 
> *    last=last)*
> 
> *  File "ovirtsdk/infrastructure/proxy.py", line 171, in __doRequest*
> 
> *    return params.parseString(response_body) if response_body is not None
and response_body is not '' \*
> 
> *  File "ovirtsdk/xml/params.py", line 21229, in parseString*
> 
> *    rootObj.build(rootNode)*
> 
> *  File "ovirtsdk/xml/params.py", line 20304, in build*
> 
> *    self.buildAttributes(node, node.attrib, [])*
> 
> *  File "ovirtsdk/xml/params.py", line 20309, in buildAttributes*
> 
> *    super(API, self).buildAttributes(node, attrs, already_processed)*
> 
> *  File "ovirtsdk/xml/params.py", line 4160, in buildAttributes*
> 
> *    value = find_attr_value_('xsi:type', node)*
> 
> *  File "ovirtsdk/xml/params.py", line 316, in find_attr_value_*
> 
> *    namespace = node.nsmap.get(prefix)*
> 
> *AttributeError: nsmap*
> 
>>>> 
> 
>  
> 
>  
> 
> But, when I use it in python 2.7.3, it?s ok
> 
>  
> 
> leaboy at leaboy:~/workspace/thtf-client$ python --version
> 
> Python 2.7.3
> 
> leaboy at leaboy:~/workspace/thtf-client$ python
> 
> Python 2.7.3 (default, Aug  1 2012, 05:16:07)
> 
> [GCC 4.6.3] on linux2
> 
> Type "help", "copyright", "credits" or "license" for more information.
> 
>>>> from ovirtsdk.api import API
> 
>>>> from ovirtsdk.xml import params
> 
>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
None, '~/.spicec/ca.crt', None, True)
> 
>>>> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D




From mpastern at redhat.com  Thu May  2 08:23:22 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Thu, 02 May 2013 11:23:22 +0300
Subject: [Engine-devel] =?gb2312?b?tPC4tDogYWJvdXQgb3ZpcnQtZW5naW5lLXNk?=
	=?gb2312?b?aw==?=
In-Reply-To: <001401ce470b$fd5547c0$f7ffd740$@com>
References: <000f01ce46e0$490d4c70$db27e550$@com> <51820545.9060904@redhat.com>
	<001401ce470b$fd5547c0$f7ffd740$@com>
Message-ID: <5182227A.9010609@redhat.com>

On 05/02/2013 11:06 AM, leaboy at 126 wrote:
> The code I got in 2013-1-27 with git, I don't know which version I got, 
> I didn't install it , I just use it like the example, 

you should be installing sdk in some way, cause just fetching it from the git,
wasn't make it available in python,

i suggest you installing official releases (unless you would like to develop & contribute)
from pypi/easy_install.

> 
>  leaboy at leaboy:~/workspace/thtf-client$ python --version 
>  Python 2.7.3 
>  leaboy at leaboy:~/workspace/thtf-client$ python 
>  Python 2.7.3 (default, Aug  1 2012, 05:16:07) 
>  [GCC 4.6.3] on linux2 
>  Type "help", "copyright", "credits" or "license" for more information.
>  
>  >>> from ovirtsdk.api import API 
>  >>> from ovirtsdk.xml import params 
>  >>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
> None, '~/.spicec/ca.crt', None, True) 
>  >>>
> 
> I use it successful in ubuntu 12.04 without any other operation,
> Just import the modules with python 2.7.3
> 
> But when I use it in other OS, such as ubuntu 11, or embed linux for ARM,
> With python 2.6.*, It does't work,

i just verified it on [1], not sure about embed linux, in any case to
make it work, lxml should be installed.

[1]
python 2.6.6
python-lxml-2.2.3-1

> 
> 
> 
> -----????-----
> ???: Michael Pasternak [mailto:mpastern at redhat.com] 
> ????: 2013?5?2? 14:19
> ???: leaboy at 126
> ??: engine-devel at ovirt.org
> ??: Re: about ovirt-engine-sdk
> 
> 
> Hi,
> 
> On 05/02/2013 05:53 AM, leaboy at 126 wrote:
>> Hi,all
>>
>> How can I use overt-engine-sdk in the python environment below python2.7,
>>
>> For example, when I use it in python 2.6.5 like thus:
> 
> what sdk version you're using?
> how did you installed it?
> what version of lxml you have installed?
> 
>>
>>  
>>
>> percy at percy-desktop:~/thtf-client$ python --version
>>
>> Python 2.6.5
>>
>> percy at percy-desktop:~/thtf-client$ python
>>
>> Python 2.6.5 (r265:79063, Oct  1 2012, 22:04:36)
>>
>> [GCC 4.4.3] on linux2
>>
>> Type "help", "copyright", "credits" or "license" for more information.
>>
>>>>> from ovirtsdk.api import API
>>
>>>>> from ovirtsdk.xml import params
>>
>>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
> None, '~/.spicec/ca.crt', None, None, True)
>>
>> *Traceback (most recent call last):*
>>
>> *  File "<stdin>", line 1, in <module>*
>>
>> *  File "ovirtsdk/api.py", line 107, in __init__*
>>
>> *    url='/api')*
>>
>> *  File "ovirtsdk/infrastructure/proxy.py", line 129, in request*
>>
>> *    last=last)*
>>
>> *  File "ovirtsdk/infrastructure/proxy.py", line 171, in __doRequest*
>>
>> *    return params.parseString(response_body) if response_body is not None
> and response_body is not '' \*
>>
>> *  File "ovirtsdk/xml/params.py", line 21229, in parseString*
>>
>> *    rootObj.build(rootNode)*
>>
>> *  File "ovirtsdk/xml/params.py", line 20304, in build*
>>
>> *    self.buildAttributes(node, node.attrib, [])*
>>
>> *  File "ovirtsdk/xml/params.py", line 20309, in buildAttributes*
>>
>> *    super(API, self).buildAttributes(node, attrs, already_processed)*
>>
>> *  File "ovirtsdk/xml/params.py", line 4160, in buildAttributes*
>>
>> *    value = find_attr_value_('xsi:type', node)*
>>
>> *  File "ovirtsdk/xml/params.py", line 316, in find_attr_value_*
>>
>> *    namespace = node.nsmap.get(prefix)*
>>
>> *AttributeError: nsmap*
>>
>>>>>
>>
>>  
>>
>>  
>>
>> But, when I use it in python 2.7.3, it?s ok
>>
>>  
>>
>> leaboy at leaboy:~/workspace/thtf-client$ python --version
>>
>> Python 2.7.3
>>
>> leaboy at leaboy:~/workspace/thtf-client$ python
>>
>> Python 2.7.3 (default, Aug  1 2012, 05:16:07)
>>
>> [GCC 4.6.3] on linux2
>>
>> Type "help", "copyright", "credits" or "license" for more information.
>>
>>>>> from ovirtsdk.api import API
>>
>>>>> from ovirtsdk.xml import params
>>
>>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
> None, '~/.spicec/ca.crt', None, True)
>>
>>>>>
>>
> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From kiril at redhat.com  Thu May  2 08:24:26 2013
From: kiril at redhat.com (Kiril Nesenko)
Date: Thu, 2 May 2013 04:24:26 -0400 (EDT)
Subject: [Engine-devel] Sandro Bonazzola as a tools maintainer
In-Reply-To: <518221F2.8090407@redhat.com>
References: <51472FD2.7020806@redhat.com> <518221F2.8090407@redhat.com>
Message-ID: <1680512717.4903283.1367483066397.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Kiril Nesenko" <knesenko at redhat.com>
> Sent: Thursday, May 2, 2013 11:21:06 AM
> Subject: Fwd: Sandro Bonazzola as a tools maintainer
> 
> 
> 
> 
> -------- Messaggio originale --------
> Oggetto: 	Sandro Bonazzola as a tools maintainer
> Data: 	Mon, 18 Mar 2013 11:16:34 -0400
> Mittente: 	Keith Robertson <kroberts at redhat.com>
> A: 	engine-devel at ovirt.org <engine-devel at ovirt.org>
> CC: 	Moran Goldboim <mgoldboi at redhat.com>, Sandro Bonazzola
> <sbonazzo at redhat.com>
> 
> 
> 
> I would like to propose that we add Sandro Bonazzola as a maintainer for
> the Ovirt ISO Uploader, Image Uploader and Log Collector.  He too has
> been enormously helpful with the maintenance of the tools.
> 
> Thanks,
> Keith Robertson

+1

- Kiril
> 
> 
> 
> 


From wlbleaboy at 126.com  Thu May  2 09:17:24 2013
From: wlbleaboy at 126.com (leaboy@126)
Date: Thu, 2 May 2013 17:17:24 +0800
Subject: [Engine-devel] =?gb2312?b?tPC4tDogtPC4tDogYWJvdXQgb3ZpcnQtZW5n?=
	=?gb2312?b?aW5lLXNkaw==?=
In-Reply-To: <5182227A.9010609@redhat.com>
References: <000f01ce46e0$490d4c70$db27e550$@com> <51820545.9060904@redhat.com>
	<001401ce470b$fd5547c0$f7ffd740$@com> <5182227A.9010609@redhat.com>
Message-ID: <001501ce4715$dc801570$95804050$@com>

Thinks, I just missing lxml.
When I installed lxml , it works well.

-----????-----
???: Michael Pasternak [mailto:mpastern at redhat.com] 
????: 2013?5?2? 16:23
???: leaboy at 126
??: engine-devel at ovirt.org
??: Re: ??: about ovirt-engine-sdk

On 05/02/2013 11:06 AM, leaboy at 126 wrote:
> The code I got in 2013-1-27 with git, I don't know which version I got, 
> I didn't install it , I just use it like the example, 

you should be installing sdk in some way, cause just fetching it from the
git,
wasn't make it available in python,

i suggest you installing official releases (unless you would like to develop
& contribute)
from pypi/easy_install.

> 
>  leaboy at leaboy:~/workspace/thtf-client$ python --version 
>  Python 2.7.3 
>  leaboy at leaboy:~/workspace/thtf-client$ python 
>  Python 2.7.3 (default, Aug  1 2012, 05:16:07) 
>  [GCC 4.6.3] on linux2 
>  Type "help", "copyright", "credits" or "license" for more information.
>  
>  >>> from ovirtsdk.api import API 
>  >>> from ovirtsdk.xml import params 
>  >>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
> None, '~/.spicec/ca.crt', None, True) 
>  >>>
> 
> I use it successful in ubuntu 12.04 without any other operation,
> Just import the modules with python 2.7.3
> 
> But when I use it in other OS, such as ubuntu 11, or embed linux for ARM,
> With python 2.6.*, It does't work,

i just verified it on [1], not sure about embed linux, in any case to
make it work, lxml should be installed.

[1]
python 2.6.6
python-lxml-2.2.3-1

> 
> 
> 
> -----????-----
> ???: Michael Pasternak [mailto:mpastern at redhat.com] 
> ????: 2013?5?2? 14:19
> ???: leaboy at 126
> ??: engine-devel at ovirt.org
> ??: Re: about ovirt-engine-sdk
> 
> 
> Hi,
> 
> On 05/02/2013 05:53 AM, leaboy at 126 wrote:
>> Hi,all
>>
>> How can I use overt-engine-sdk in the python environment below python2.7,
>>
>> For example, when I use it in python 2.6.5 like thus:
> 
> what sdk version you're using?
> how did you installed it?
> what version of lxml you have installed?
> 
>>
>>  
>>
>> percy at percy-desktop:~/thtf-client$ python --version
>>
>> Python 2.6.5
>>
>> percy at percy-desktop:~/thtf-client$ python
>>
>> Python 2.6.5 (r265:79063, Oct  1 2012, 22:04:36)
>>
>> [GCC 4.4.3] on linux2
>>
>> Type "help", "copyright", "credits" or "license" for more information.
>>
>>>>> from ovirtsdk.api import API
>>
>>>>> from ovirtsdk.xml import params
>>
>>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
> None, '~/.spicec/ca.crt', None, None, True)
>>
>> *Traceback (most recent call last):*
>>
>> *  File "<stdin>", line 1, in <module>*
>>
>> *  File "ovirtsdk/api.py", line 107, in __init__*
>>
>> *    url='/api')*
>>
>> *  File "ovirtsdk/infrastructure/proxy.py", line 129, in request*
>>
>> *    last=last)*
>>
>> *  File "ovirtsdk/infrastructure/proxy.py", line 171, in __doRequest*
>>
>> *    return params.parseString(response_body) if response_body is not
None
> and response_body is not '' \*
>>
>> *  File "ovirtsdk/xml/params.py", line 21229, in parseString*
>>
>> *    rootObj.build(rootNode)*
>>
>> *  File "ovirtsdk/xml/params.py", line 20304, in build*
>>
>> *    self.buildAttributes(node, node.attrib, [])*
>>
>> *  File "ovirtsdk/xml/params.py", line 20309, in buildAttributes*
>>
>> *    super(API, self).buildAttributes(node, attrs, already_processed)*
>>
>> *  File "ovirtsdk/xml/params.py", line 4160, in buildAttributes*
>>
>> *    value = find_attr_value_('xsi:type', node)*
>>
>> *  File "ovirtsdk/xml/params.py", line 316, in find_attr_value_*
>>
>> *    namespace = node.nsmap.get(prefix)*
>>
>> *AttributeError: nsmap*
>>
>>>>>
>>
>>  
>>
>>  
>>
>> But, when I use it in python 2.7.3, it?s ok
>>
>>  
>>
>> leaboy at leaboy:~/workspace/thtf-client$ python --version
>>
>> Python 2.7.3
>>
>> leaboy at leaboy:~/workspace/thtf-client$ python
>>
>> Python 2.7.3 (default, Aug  1 2012, 05:16:07)
>>
>> [GCC 4.6.3] on linux2
>>
>> Type "help", "copyright", "credits" or "license" for more information.
>>
>>>>> from ovirtsdk.api import API
>>
>>>>> from ovirtsdk.xml import params
>>
>>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
> None, '~/.spicec/ca.crt', None, True)
>>
>>>>>
>>
> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D




From sanjal at redhat.com  Thu May  2 10:03:23 2013
From: sanjal at redhat.com (Shireesh Anjal)
Date: Thu, 02 May 2013 15:33:23 +0530
Subject: [Engine-devel] FeatureSupported and compatibility versions
In-Reply-To: <411669739.21262216.1363593613422.JavaMail.root@redhat.com>
References: <411669739.21262216.1363593613422.JavaMail.root@redhat.com>
Message-ID: <518239EB.3020603@redhat.com>

On 03/18/2013 01:30 PM, Omer Frenkel wrote:
>
> ----- Original Message -----
>> From: "Shireesh Anjal" <sanjal at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Monday, March 18, 2013 8:28:14 AM
>> Subject: [Engine-devel] FeatureSupported and compatibility versions
>>
>> Hi all,
>>
>> The current mechanism in oVirt to check whether a feature is
>> supported
>> in a particular compatibility version is to use the FeatureSupported
>> class. e.g.
>>
>> FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion())
>>
>> Checks whether the "network linking" feature is supported for the the
>> VM's cluster compatibility version. This internally checks whether
>> the
>> value of the corresponding config (NetworkLinkingSupported) for the
>> given compatibility version is true/false.
>>
>> I'm not sure if this is a good idea, since a feature is typically
>> supported "from" a particular version. E.g. Gluster support was
>> introduced in 3.1, and it continues to be available in all subsequent
>> versions. So I see no point in adding configuration for every version
>> indicating whether the feature is supported in that version or not. I
>> suggest to use either of the following options:
>>
>> 1) Instead of using a boolean config for each version, use a single
>> string config that indicates the "supported from" version e.g.
>> GlusterSupportedFrom = 3.1. There could be rare  cases where a
>> feature,
>> for some reason, is removed in some release. In such cases, we could
>> use
>> one additional config for the "supported to" version.
>>
>> 2) Continue with the boolean approach, but do not have entries for
>> every
>> version; rather make use of the "default value" for majority of
>> cases,
>> and add the explicit version mapping for the minority e.g.
>> GlusterSupported = true by default, and false in case of 3.0 (only
>> one
>> config required for 3.0)
>>
> i like this approach better,
> if one add new feature for 3.3 he should add it as 'true' in the config to be used as default,
> and explicitly add it as false for other unsupported versions.

For the record, this was the approach that was finally approved on the 
patch and merged (http://gerrit.ovirt.org/12970)
So I think now onwards, everyone can start using this approach for new 
features being added.

> if we do go this way, we need to make sure it works because i vaguely remember we had a bug in configuration,
> making us explicitly specify value for all versions.

I wrote a test case on DBConfigUtils that verifies that it does indeed 
work fine (http://gerrit.ovirt.org/13787), which has also been approved 
and merged.

>
>> Thoughts?
>>
>> Regards,
>> Shireesh
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From ofrenkel at redhat.com  Thu May  2 10:23:02 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Thu, 2 May 2013 06:23:02 -0400 (EDT)
Subject: [Engine-devel] FeatureSupported and compatibility versions
In-Reply-To: <518239EB.3020603@redhat.com>
References: <411669739.21262216.1363593613422.JavaMail.root@redhat.com>
	<518239EB.3020603@redhat.com>
Message-ID: <1647326442.8814811.1367490182404.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Shireesh Anjal" <sanjal at redhat.com>
> To: engine-devel at ovirt.org
> Cc: "Omer Frenkel" <ofrenkel at redhat.com>
> Sent: Thursday, May 2, 2013 1:03:23 PM
> Subject: Re: [Engine-devel] FeatureSupported and compatibility versions
> 
> On 03/18/2013 01:30 PM, Omer Frenkel wrote:
> >
> > ----- Original Message -----
> >> From: "Shireesh Anjal" <sanjal at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Monday, March 18, 2013 8:28:14 AM
> >> Subject: [Engine-devel] FeatureSupported and compatibility versions
> >>
> >> Hi all,
> >>
> >> The current mechanism in oVirt to check whether a feature is
> >> supported
> >> in a particular compatibility version is to use the FeatureSupported
> >> class. e.g.
> >>
> >> FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion())
> >>
> >> Checks whether the "network linking" feature is supported for the the
> >> VM's cluster compatibility version. This internally checks whether
> >> the
> >> value of the corresponding config (NetworkLinkingSupported) for the
> >> given compatibility version is true/false.
> >>
> >> I'm not sure if this is a good idea, since a feature is typically
> >> supported "from" a particular version. E.g. Gluster support was
> >> introduced in 3.1, and it continues to be available in all subsequent
> >> versions. So I see no point in adding configuration for every version
> >> indicating whether the feature is supported in that version or not. I
> >> suggest to use either of the following options:
> >>
> >> 1) Instead of using a boolean config for each version, use a single
> >> string config that indicates the "supported from" version e.g.
> >> GlusterSupportedFrom = 3.1. There could be rare  cases where a
> >> feature,
> >> for some reason, is removed in some release. In such cases, we could
> >> use
> >> one additional config for the "supported to" version.
> >>
> >> 2) Continue with the boolean approach, but do not have entries for
> >> every
> >> version; rather make use of the "default value" for majority of
> >> cases,
> >> and add the explicit version mapping for the minority e.g.
> >> GlusterSupported = true by default, and false in case of 3.0 (only
> >> one
> >> config required for 3.0)
> >>
> > i like this approach better,
> > if one add new feature for 3.3 he should add it as 'true' in the config to
> > be used as default,
> > and explicitly add it as false for other unsupported versions.
> 
> For the record, this was the approach that was finally approved on the
> patch and merged (http://gerrit.ovirt.org/12970)
> So I think now onwards, everyone can start using this approach for new
> features being added.
> 
> > if we do go this way, we need to make sure it works because i vaguely
> > remember we had a bug in configuration,
> > making us explicitly specify value for all versions.
> 
> I wrote a test case on DBConfigUtils that verifies that it does indeed
> work fine (http://gerrit.ovirt.org/13787), which has also been approved
> and merged.
> 

Thanks!

> >
> >> Thoughts?
> >>
> >> Regards,
> >> Shireesh
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 


From alourie at redhat.com  Thu May  2 10:41:37 2013
From: alourie at redhat.com (Alex Lourie)
Date: Thu, 02 May 2013 10:44:37 +0003
Subject: [Engine-devel] Error: could not create ovirtsdk API object
In-Reply-To: <51820E3C.5060304@redhat.com>
References: <CAH=UCn6bZnQJRwWbDpnt-mcrrbEJq9T_aUJwva6r3HK+zm-1WA@mail.gmail.com>
	<517D23DB.6010304@redhat.com>
	<CAH=UCn5jUyVCWQd3-eqhAFiG-MOrKMFAU9YJ-mw6L7_5dS1kZA@mail.gmail.com>
	<51820E3C.5060304@redhat.com>
Message-ID: <201305021041.r42Aff4H000846@int-mx10.intmail.prod.int.phx2.redhat.com>



On Thu, May 2, 2013 at 9:57 AM, Itamar Heim <iheim at redhat.com> wrote:
> On 05/02/2013 02:40 AM, ?? wrote:
>>  The bug is fix?
>>  
>>  if not,What will I DO ?
>> 
> 

Please attach the installation log files from /var/log/ovirt-engine/ 
folder.

>>  
>>  Thanks,
>>  
>>  
>>  2013/4/28 Itamar Heim <iheim at redhat.com <mailto:iheim at redhat.com>>
>>  
>>      Bug 947753 - [AIO] 'Error: could not create ovirtsdk API object'
>>      during installation?
>>  
>>  
>>  
>>  
>>  HI?All
>>  
>>  ?????
>>  
>>  ---
>>  ???????????
>>  ??
>>  
>>  
>> ------------------------------------------------------------------------------ 
>>  
>>  
>>  + ????????????????(????1:1) 
>> +
>>  
>> ------------------------------------------------------------------------------
>> 
> alex - is this part of ovirt 3.2.2?
> 
Not really - that bug could not be reproduced with latest master 
builds, thus it was closed.



From ecohen at redhat.com  Thu May  2 12:45:42 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Thu, 2 May 2013 08:45:42 -0400 (EDT)
Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google ID?
In-Reply-To: <125402215.8867580.1367496985550.JavaMail.root@redhat.com>
Message-ID: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>

Hi,

It seems that I cannot log into gerrit.ovirt.org web-interface with my 
google ID anymore: when attempting to sign-in, it asks me for my Open ID, 
and when providing my google ID - the page just refreshes without signing 
me in.
[see attached video]
[same behavior from FireFox and Chrome]
[tried deleting cookies/history/etc...]
[I experience no problems signing in with my google account to chrome/gmail]
[I can sign in to gerrit.ovirt.org with my Yahoo ID (as an "Anonymous Coward"...)]

did someone else experience that? any idea how to solve it?

----
Thanks,
Einav
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out-2.ogv
Type: video/ogg
Size: 2671808 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130502/7dcd4c30/attachment.ogv>

From tjelinek at redhat.com  Thu May  2 12:50:50 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Thu, 2 May 2013 08:50:50 -0400 (EDT)
Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
 ID?
In-Reply-To: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
References: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
Message-ID: <184698908.5705439.1367499050231.JavaMail.root@redhat.com>

I had this issue when I have enabled the google+ on my account - it changes something with openID.
Did you do this?

Tomas

----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, May 2, 2013 2:45:42 PM
> Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google ID?
> 
> Hi,
> 
> It seems that I cannot log into gerrit.ovirt.org web-interface with my
> google ID anymore: when attempting to sign-in, it asks me for my Open ID,
> and when providing my google ID - the page just refreshes without signing
> me in.
> [see attached video]
> [same behavior from FireFox and Chrome]
> [tried deleting cookies/history/etc...]
> [I experience no problems signing in with my google account to chrome/gmail]
> [I can sign in to gerrit.ovirt.org with my Yahoo ID (as an "Anonymous
> Coward"...)]
> 
> did someone else experience that? any idea how to solve it?
> 
> ----
> Thanks,
> Einav
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ecohen at redhat.com  Thu May  2 12:57:08 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Thu, 2 May 2013 08:57:08 -0400 (EDT)
Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
 ID?
In-Reply-To: <184698908.5705439.1367499050231.JavaMail.root@redhat.com>
References: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
	<184698908.5705439.1367499050231.JavaMail.root@redhat.com>
Message-ID: <508634044.8892415.1367499428468.JavaMail.root@redhat.com>

Hi Tomas,

> I had this issue when I have enabled the google+ on my account - it changes
> something with openID.
> Did you do this?

I enabled google+ on my account a *long* time ago, however problems with signing 
into gerrit started only today (yesterday it worked fine).
I haven't changed anything in my google account settings recently.
other ideas?...

> 
> Tomas
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, May 2, 2013 2:45:42 PM
> > Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google ID?
> > 
> > Hi,
> > 
> > It seems that I cannot log into gerrit.ovirt.org web-interface with my
> > google ID anymore: when attempting to sign-in, it asks me for my Open ID,
> > and when providing my google ID - the page just refreshes without signing
> > me in.
> > [see attached video]
> > [same behavior from FireFox and Chrome]
> > [tried deleting cookies/history/etc...]
> > [I experience no problems signing in with my google account to
> > chrome/gmail]
> > [I can sign in to gerrit.ovirt.org with my Yahoo ID (as an "Anonymous
> > Coward"...)]
> > 
> > did someone else experience that? any idea how to solve it?
> > 
> > ----
> > Thanks,
> > Einav
> > _______________________________________________
> > 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 asegurap at redhat.com  Thu May  2 13:04:29 2013
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Thu, 2 May 2013 09:04:29 -0400 (EDT)
Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
 ID?
In-Reply-To: <508634044.8892415.1367499428468.JavaMail.root@redhat.com>
References: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
	<184698908.5705439.1367499050231.JavaMail.root@redhat.com>
	<508634044.8892415.1367499428468.JavaMail.root@redhat.com>
Message-ID: <1552204727.3573226.1367499869639.JavaMail.root@redhat.com>

Did you try to do it with the browser in rpivate mode?

----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, May 2, 2013 2:57:08 PM
> Subject: Re: [Engine-devel] cannot sign in to gerrit.ovirt.org with google ID?
> 
> Hi Tomas,
> 
> > I had this issue when I have enabled the google+ on my account - it changes
> > something with openID.
> > Did you do this?
> 
> I enabled google+ on my account a *long* time ago, however problems with
> signing
> into gerrit started only today (yesterday it worked fine).
> I haven't changed anything in my google account settings recently.
> other ideas?...
> 
> > 
> > Tomas
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Thursday, May 2, 2013 2:45:42 PM
> > > Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
> > > ID?
> > > 
> > > Hi,
> > > 
> > > It seems that I cannot log into gerrit.ovirt.org web-interface with my
> > > google ID anymore: when attempting to sign-in, it asks me for my Open ID,
> > > and when providing my google ID - the page just refreshes without signing
> > > me in.
> > > [see attached video]
> > > [same behavior from FireFox and Chrome]
> > > [tried deleting cookies/history/etc...]
> > > [I experience no problems signing in with my google account to
> > > chrome/gmail]
> > > [I can sign in to gerrit.ovirt.org with my Yahoo ID (as an "Anonymous
> > > Coward"...)]
> > > 
> > > did someone else experience that? any idea how to solve it?
> > > 
> > > ----
> > > Thanks,
> > > Einav
> > > _______________________________________________
> > > 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 mperina at redhat.com  Thu May  2 13:06:58 2013
From: mperina at redhat.com (Martin Perina)
Date: Thu, 2 May 2013 09:06:58 -0400 (EDT)
Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
 ID?
In-Reply-To: <508634044.8892415.1367499428468.JavaMail.root@redhat.com>
References: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
	<184698908.5705439.1367499050231.JavaMail.root@redhat.com>
	<508634044.8892415.1367499428468.JavaMail.root@redhat.com>
Message-ID: <395725105.5960310.1367500018878.JavaMail.root@redhat.com>

Hi Einav,

I don't have any problems signing into gerrit.ovirt.org using my google account, I've just tried
it few minutes ago. You can try to look at your G+ account / Security settings / Connected
applications and sites, if gerrit.ovirt.org is among them.

Martin


----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, May 2, 2013 2:57:08 PM
> Subject: Re: [Engine-devel] cannot sign in to gerrit.ovirt.org with google ID?
> 
> Hi Tomas,
> 
> > I had this issue when I have enabled the google+ on my account - it changes
> > something with openID.
> > Did you do this?
> 
> I enabled google+ on my account a *long* time ago, however problems with
> signing
> into gerrit started only today (yesterday it worked fine).
> I haven't changed anything in my google account settings recently.
> other ideas?...
> 
> > 
> > Tomas
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Thursday, May 2, 2013 2:45:42 PM
> > > Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
> > > ID?
> > > 
> > > Hi,
> > > 
> > > It seems that I cannot log into gerrit.ovirt.org web-interface with my
> > > google ID anymore: when attempting to sign-in, it asks me for my Open ID,
> > > and when providing my google ID - the page just refreshes without signing
> > > me in.
> > > [see attached video]
> > > [same behavior from FireFox and Chrome]
> > > [tried deleting cookies/history/etc...]
> > > [I experience no problems signing in with my google account to
> > > chrome/gmail]
> > > [I can sign in to gerrit.ovirt.org with my Yahoo ID (as an "Anonymous
> > > Coward"...)]
> > > 
> > > did someone else experience that? any idea how to solve it?
> > > 
> > > ----
> > > Thanks,
> > > Einav
> > > _______________________________________________
> > > 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  Thu May  2 13:07:48 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Thu, 2 May 2013 09:07:48 -0400 (EDT)
Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
 ID?
In-Reply-To: <1552204727.3573226.1367499869639.JavaMail.root@redhat.com>
References: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
	<184698908.5705439.1367499050231.JavaMail.root@redhat.com>
	<508634044.8892415.1367499428468.JavaMail.root@redhat.com>
	<1552204727.3573226.1367499869639.JavaMail.root@redhat.com>
Message-ID: <389024500.8902349.1367500068451.JavaMail.root@redhat.com>

> ----- Original Message -----
> From: "Antoni Segura Puimedon" <asegurap at redhat.com>
> Sent: Thursday, May 2, 2013 9:04:29 AM
> 
> Did you try to do it with the browser in rpivate mode?

I tried it in both FireFox and Chrome, in regular mode and 
private/incognito mode - same behavior, cannot sign in.

> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, May 2, 2013 2:57:08 PM
> > Subject: Re: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
> > ID?
> > 
> > Hi Tomas,
> > 
> > > I had this issue when I have enabled the google+ on my account - it
> > > changes
> > > something with openID.
> > > Did you do this?
> > 
> > I enabled google+ on my account a *long* time ago, however problems with
> > signing
> > into gerrit started only today (yesterday it worked fine).
> > I haven't changed anything in my google account settings recently.
> > other ideas?...
> > 
> > > 
> > > Tomas
> > > 
> > > ----- Original Message -----
> > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Thursday, May 2, 2013 2:45:42 PM
> > > > Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
> > > > ID?
> > > > 
> > > > Hi,
> > > > 
> > > > It seems that I cannot log into gerrit.ovirt.org web-interface with my
> > > > google ID anymore: when attempting to sign-in, it asks me for my Open
> > > > ID,
> > > > and when providing my google ID - the page just refreshes without
> > > > signing
> > > > me in.
> > > > [see attached video]
> > > > [same behavior from FireFox and Chrome]
> > > > [tried deleting cookies/history/etc...]
> > > > [I experience no problems signing in with my google account to
> > > > chrome/gmail]
> > > > [I can sign in to gerrit.ovirt.org with my Yahoo ID (as an "Anonymous
> > > > Coward"...)]
> > > > 
> > > > did someone else experience that? any idea how to solve it?
> > > > 
> > > > ----
> > > > Thanks,
> > > > Einav
> > > > _______________________________________________
> > > > 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 ecohen at redhat.com  Thu May  2 13:12:10 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Thu, 2 May 2013 09:12:10 -0400 (EDT)
Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
 ID?
In-Reply-To: <395725105.5960310.1367500018878.JavaMail.root@redhat.com>
References: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
	<184698908.5705439.1367499050231.JavaMail.root@redhat.com>
	<508634044.8892415.1367499428468.JavaMail.root@redhat.com>
	<395725105.5960310.1367500018878.JavaMail.root@redhat.com>
Message-ID: <1484934718.8906886.1367500330855.JavaMail.root@redhat.com>

> ----- Original Message -----
> From: "Martin Perina" <mperina at redhat.com>
> Sent: Thursday, May 2, 2013 9:06:58 AM
> 
> Hi Einav,

Hi Martin,

> 
> I don't have any problems signing into gerrit.ovirt.org using my google
> account, I've just tried
> it few minutes ago. You can try to look at your G+ account / Security
> settings / Connected
> applications and sites, if gerrit.ovirt.org is among them.

yes, I already have gerrit.ovirt.org among them. thanks.

> 
> Martin
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, May 2, 2013 2:57:08 PM
> > Subject: Re: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
> > ID?
> > 
> > Hi Tomas,
> > 
> > > I had this issue when I have enabled the google+ on my account - it
> > > changes
> > > something with openID.
> > > Did you do this?
> > 
> > I enabled google+ on my account a *long* time ago, however problems with
> > signing
> > into gerrit started only today (yesterday it worked fine).
> > I haven't changed anything in my google account settings recently.
> > other ideas?...
> > 
> > > 
> > > Tomas
> > > 
> > > ----- Original Message -----
> > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Thursday, May 2, 2013 2:45:42 PM
> > > > Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
> > > > ID?
> > > > 
> > > > Hi,
> > > > 
> > > > It seems that I cannot log into gerrit.ovirt.org web-interface with my
> > > > google ID anymore: when attempting to sign-in, it asks me for my Open
> > > > ID,
> > > > and when providing my google ID - the page just refreshes without
> > > > signing
> > > > me in.
> > > > [see attached video]
> > > > [same behavior from FireFox and Chrome]
> > > > [tried deleting cookies/history/etc...]
> > > > [I experience no problems signing in with my google account to
> > > > chrome/gmail]
> > > > [I can sign in to gerrit.ovirt.org with my Yahoo ID (as an "Anonymous
> > > > Coward"...)]
> > > > 
> > > > did someone else experience that? any idea how to solve it?
> > > > 
> > > > ----
> > > > Thanks,
> > > > Einav
> > > > _______________________________________________
> > > > 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 mperina at redhat.com  Thu May  2 13:17:23 2013
From: mperina at redhat.com (Martin Perina)
Date: Thu, 2 May 2013 09:17:23 -0400 (EDT)
Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
 ID?
In-Reply-To: <1484934718.8906886.1367500330855.JavaMail.root@redhat.com>
References: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
	<184698908.5705439.1367499050231.JavaMail.root@redhat.com>
	<508634044.8892415.1367499428468.JavaMail.root@redhat.com>
	<395725105.5960310.1367500018878.JavaMail.root@redhat.com>
	<1484934718.8906886.1367500330855.JavaMail.root@redhat.com>
Message-ID: <225013733.5966819.1367500643514.JavaMail.root@redhat.com>


> > ----- Original Message -----
> > From: "Martin Perina" <mperina at redhat.com>
> > Sent: Thursday, May 2, 2013 9:06:58 AM
> > 
> > Hi Einav,
> 
> Hi Martin,
> 
> > 
> > I don't have any problems signing into gerrit.ovirt.org using my google
> > account, I've just tried
> > it few minutes ago. You can try to look at your G+ account / Security
> > settings / Connected
> > applications and sites, if gerrit.ovirt.org is among them.
> 
> yes, I already have gerrit.ovirt.org among them. thanks.
> 

So try to revoke it, restart browser and try to login to gerrit again.

Martin


From ecohen at redhat.com  Thu May  2 13:24:29 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Thu, 2 May 2013 09:24:29 -0400 (EDT)
Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
 ID?
In-Reply-To: <225013733.5966819.1367500643514.JavaMail.root@redhat.com>
References: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
	<184698908.5705439.1367499050231.JavaMail.root@redhat.com>
	<508634044.8892415.1367499428468.JavaMail.root@redhat.com>
	<395725105.5960310.1367500018878.JavaMail.root@redhat.com>
	<1484934718.8906886.1367500330855.JavaMail.root@redhat.com>
	<225013733.5966819.1367500643514.JavaMail.root@redhat.com>
Message-ID: <185377294.8915905.1367501069174.JavaMail.root@redhat.com>

> ----- Original Message -----
> From: "Martin Perina" <mperina at redhat.com>
> Sent: Thursday, May 2, 2013 9:17:23 AM
> 
> 
> > > ----- Original Message -----
> > > From: "Martin Perina" <mperina at redhat.com>
> > > Sent: Thursday, May 2, 2013 9:06:58 AM
> > > 
> > > Hi Einav,
> > 
> > Hi Martin,
> > 
> > > 
> > > I don't have any problems signing into gerrit.ovirt.org using my google
> > > account, I've just tried
> > > it few minutes ago. You can try to look at your G+ account / Security
> > > settings / Connected
> > > applications and sites, if gerrit.ovirt.org is among them.
> > 
> > yes, I already have gerrit.ovirt.org among them. thanks.
> > 
> 
> So try to revoke it, restart browser and try to login to gerrit again.

thanks Martin, tried that (and when trying to sign into gerrit with my google ID, 
it indeed asked me explicitly to allow using this google ID for gerrit.ovirt.org) - 
however, it didn't work - I am still not signed into gerrit.

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


From ecohen at redhat.com  Thu May  2 17:00:36 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Thu, 2 May 2013 13:00:36 -0400 (EDT)
Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
	ID?
In-Reply-To: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
References: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
Message-ID: <1938886505.9260370.1367514036247.JavaMail.root@redhat.com>

thanks for all of your replies, guys - I really appreciate it!

unfortunately, I still cannot sign into gerrit.
This is definitely a server-side problem, since I tried multiple browsers 
from multiple client machines, and the behavior is the same in all of them.
This is probably not a google openid problem, as I am able to use my google 
openid to sign into other web-sites/applications (e.g. stackoverflow.com).

so my guess is that the problem is with gerrit, however since other users 
don't seem to experience the same problem, I assume that it is something in 
particular in my gerrit user (again - on the server-side, e.g. my record in 
the gerrit DB got messed up for some reason or something similar).

if anyone has additional ideas and/or able to help me troubleshoot/solve the 
problem - it would be greatly appreciated!

Many thanks in advance.

----
Regards,
Einav

----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, May 2, 2013 8:45:42 AM
> Subject: cannot sign in to gerrit.ovirt.org with google ID?
> 
> Hi,
> 
> It seems that I cannot log into gerrit.ovirt.org web-interface with my
> google ID anymore: when attempting to sign-in, it asks me for my Open ID,
> and when providing my google ID - the page just refreshes without signing
> me in.
> [see attached video]
> [same behavior from FireFox and Chrome]
> [tried deleting cookies/history/etc...]
> [I experience no problems signing in with my google account to chrome/gmail]
> [I can sign in to gerrit.ovirt.org with my Yahoo ID (as an "Anonymous
> Coward"...)]
> 
> did someone else experience that? any idea how to solve it?
> 
> ----
> Thanks,
> Einav


From vszocs at redhat.com  Thu May  2 17:11:47 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 2 May 2013 13:11:47 -0400 (EDT)
Subject: [Engine-devel] REST vs. UI validation
In-Reply-To: <51820237.8010406@redhat.com>
References: <80DC92D924DD7344818D4A17A1C995D7688D2B86@G9W0733.americas.hpqcorp.net>
	<1757042330.5303868.1367391934702.JavaMail.root@redhat.com>
	<1909631386.7905748.1367393640867.JavaMail.root@redhat.com>
	<5180D25E.7020906@redhat.com>
	<80DC92D924DD7344818D4A17A1C995D7688DB4A2@G4W3212.americas.hpqcorp.net>
	<769847321.8237733.1367430075403.JavaMail.root@redhat.com>
	<5181F9C8.7070207@redhat.com> <51820237.8010406@redhat.com>
Message-ID: <1448280125.5837559.1367514707769.JavaMail.root@redhat.com>

Hi guys,

>> the main chalenge is to share the validation code which might be achievablle if GWT will support our validation annotation on beans (jsr303)  - Vojetech this one I think
>> you'll be able to help with
>
> this is nice to have approach and will work with static validations only (that does
> not require dialogue with the engine), in any case api don't have any validation concept (except
> of mandatory parameters existence) and should not have, as engine do this job, - and that what
> we trying to make clear,
>
> but again not always same validations as mentioned above will take place on both client and engine
> sides.

AFAIK Java bean validation annotations (JSR-303 a.k.a javax.validation) are used directly on backend business entities, i.e. org.ovirt.engine.core.common.businessentities.*

Today, GUI works directly with backend business entities, so we can support JSR-303 annotations in GWT code. However, in the long-term, we plan to use REST API, breaking bonds with Engine with regard to RPC/API protocol.

For static validations (not involving server interaction), we will very likely end up implementing custom validation code, unrelated to backend validation annotations. For dynamic validations, I think we should let server handle this, otherwise we're just introducing more roundtrips and code complexity.

Just an idea: as part of moving GUI to REST API, initiate some work on REST API JavaScript SDK that would include such "common" validation code. This SDK would be used by both WebAdmin, UserPortal, and any other web application talking to REST API. I'm the first one to volunteer for this, if it gets some green flag :)

Vojtech


----- Original Message -----
From: "Michael Pasternak" <mpastern at redhat.com>
To: "Roy Golan" <rgolan at redhat.com>
Cc: "Vered Volansky" <vered at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org
Sent: Thursday, May 2, 2013 8:05:43 AM
Subject: Re: [Engine-devel] REST vs. UI validation


Hi Roy,

On 05/02/2013 08:29 AM, Roy Golan wrote:
> On Wed 01 May 2013 08:41:15 PM IDT, Vered Volansky wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
>>> To: "Michael Pasternak" <mpastern at redhat.com>, "Vered Volansky" <vered at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Wednesday, May 1, 2013 8:12:09 PM
>>> Subject: RE: [Engine-devel] REST vs. UI validation
>>>
>>> Thanks for the discussion.  One clarifying question below...
>>>
>>> -Kari
>>>
>>>>>>
>>>>>> Vered - I disagree that this is by design.
>>>>>> There is only one definition of what a correct value is, there should be
>>>>>> no
>>>>>> ambiguity about it[1]
>>>>>> If the GUI prohibits you from a legal configuration - it should be
>>>>>> fixed.
>>>>>> if the backend allows an illegal configuration - a CDA should be added.
>>>>>> My two cents - this is not OK, please open bugs (or even better - send
>>>>>> patches!) for the specific issues.
>>>>>
>>>>> This was discussed with Michael (until he answers himself).
>>>>> More info on the issue -
>>>>> The backend validations are less restrictive than UI, but not
>>>>> contradicting it.
>>>>> This IS by design and is not a bug in general.
>>>>> The specific min-max differences example is for sure by design.
>>>>> In some (but I guess not all) cases the reasoning is a thought to expand
>>>> possible values in the future.
>>>>>
>>>>> So this is how things are right now.
>>>>> I agree it looks weird that you might be able to set "illegal" values in
>>>>> REST
>>>> and then connect via UI and see these values.
>>>>> I suppose it can always come up for devel discussion whether that should
>>>>> be
>>>> changed.
>>>>
>>>> you cannot set any illegal value in REST-API, UI is more restrictive
>>>> indeed,
>>>> while api expose all backend capabilities (including those that are
>>>> restricted in
>>>> UI)
>>>
>>> So if I understanding correctly... The backend validations are checking
>>> legality. The UI may in some cases (like the specific ones I mentioned)
>>> impose additional restrictions/validations that further narrow the allowed
>>> input and this is by design and not a bug.  Does that sum the current state
>>> about right?
>> Yep.
> I disagree. The UI is validating input to fail as fast and save rountrips for better responsiveness and overall a better UX. This means validation are duplicated and
> sometimes, different - which I consider a bug - there is no good reason an action would be valid using the API and invalid with UI or vise versa.

you basically repeating told above, if you'll read this tread from the beginning,
kari gives two examples in "Cluster load balancing" both not even near to be "different",
it's just a different (UI) representation for same thing, UI actually hiding engine implementation
details over mentioned properties.

> 
> the main chalenge is to share the validation code which might be achievablle if GWT will support our validation annotation on beans (jsr303)  - Vojetech this one I think
> you'll be able to help with

this is nice to have approach and will work with static validations only (that does
not require dialogue with the engine), in any case api don't have any validation concept (except
of mandatory parameters existence) and should not have, as engine do this job, - and that what
we trying to make clear,

but again not always same validations as mentioned above will take place on both client and engine
sides.

> 
>>>
>>> Thanks,
>>> Kari
>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Kari Whitcomb" <Kari.Whitcomb at hp.com>
>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
>>>>>>>> Subject: [Engine-devel] REST vs. UI validation
>>>>>>>>
>>>>>>>> I've been making use of the oVirt REST api, and have noticed that in
>>>>>>>> several
>>>>>>>> cases the validation done for a REST request is different than what
>>>>>>>> the
>>>>>>>> admin UI does.  It seems that the UI is generally more restrictive on
>>>>>>>> the
>>>>>>>> data it will accept than the backend.  So you can set things up using
>>>>>>>> the
>>>>>>>> REST api that the UI wouldn't let you do.  Two examples I've hit
>>>>>>>> recently,
>>>>>>>> both in the cluster policy (load balancing section):
>>>>>>>>
>>>>>>>> - Cluster load balancing policy duration - the UI requires a value
>>>>>>>> between
>>>>>>>> 1
>>>>>>>> and 100, but the REST api seems to let you set it to any integer.
>>>>>>>>
>>>>>>>> - Cluster load balancing high and low thresholds / max and min service
>>>>>>>> levels
>>>>>>>> - The UI restricts the high value to 51-90% and the low value to
>>>>>>>> 10-50%.
>>>>>>>> But the backend only requires that the values be 0-100% and that low
>>>>>>>> can't
>>>>>>>> be greater than high.
>>>>>>>>
>>>>>>>> So my question - is this intended behavior, or is it a bug that the
>>>>>>>> validation is different?  If similar validation should be done through
>>>>>>>> both
>>>>>>>> the UI and REST api, should the UI be less restrictive, or the backend
>>>>>>>> more
>>>>>>>> restrictive?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Kari
>>>
>> _______________________________________________
>> 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


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From danken at redhat.com  Thu May  2 19:16:44 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Thu, 2 May 2013 22:16:44 +0300
Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
	ID?
In-Reply-To: <1938886505.9260370.1367514036247.JavaMail.root@redhat.com>
References: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
	<1938886505.9260370.1367514036247.JavaMail.root@redhat.com>
Message-ID: <20130502191644.GD7432@redhat.com>

On Thu, May 02, 2013 at 01:00:36PM -0400, Einav Cohen wrote:
> thanks for all of your replies, guys - I really appreciate it!
> 
> unfortunately, I still cannot sign into gerrit.
> This is definitely a server-side problem, since I tried multiple browsers 
> from multiple client machines, and the behavior is the same in all of them.
> This is probably not a google openid problem, as I am able to use my google 
> openid to sign into other web-sites/applications (e.g. stackoverflow.com).
> 
> so my guess is that the problem is with gerrit, however since other users 
> don't seem to experience the same problem, I assume that it is something in 
> particular in my gerrit user (again - on the server-side, e.g. my record in 
> the gerrit DB got messed up for some reason or something similar).
> 
> if anyone has additional ideas and/or able to help me troubleshoot/solve the 
> problem - it would be greatly appreciated!
> 
> Many thanks in advance.

I can only say that yesterday I had a similar issue - I failed to login
with my fedora id. Instead of researching the problem I switched to my
google id, which worked. My fedora id worked fine several hours later.

So I do not have better ideas than asking your favorite gerrit admin to
link another identetity (yahoo, fedora) to your gerrit account, and hope
that the problem solves itself later on.

Dan.


From iheim at redhat.com  Thu May  2 19:24:35 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 02 May 2013 22:24:35 +0300
Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google
	ID?
In-Reply-To: <1938886505.9260370.1367514036247.JavaMail.root@redhat.com>
References: <218029138.8884656.1367498742684.JavaMail.root@redhat.com>
	<1938886505.9260370.1367514036247.JavaMail.root@redhat.com>
Message-ID: <5182BD73.2080604@redhat.com>

On 05/02/2013 08:00 PM, Einav Cohen wrote:
> thanks for all of your replies, guys - I really appreciate it!
>
> unfortunately, I still cannot sign into gerrit.
> This is definitely a server-side problem, since I tried multiple browsers
> from multiple client machines, and the behavior is the same in all of them.
> This is probably not a google openid problem, as I am able to use my google
> openid to sign into other web-sites/applications (e.g. stackoverflow.com).
>
> so my guess is that the problem is with gerrit, however since other users
> don't seem to experience the same problem, I assume that it is something in
> particular in my gerrit user (again - on the server-side, e.g. my record in
> the gerrit DB got messed up for some reason or something similar).
>
> if anyone has additional ideas and/or able to help me troubleshoot/solve the
> problem - it would be greatly appreciated!
>

(adding infra)

its not the previous problem all fedoraproject users had, due to 
fedoraproject changing their infra one night out of the blue.

before strarting to troubleshoot, tried service gerrit restart.
now works for einav.

lets hope doesn't become too recurrent.

since we are on a patched 2.4, and 2.5.2 seems to have bug fixes 
relevant to us, and since 2.6 is in rc (and has items in release notes 
which read "42x improvement on git clone and git fetch"), I'll look into 
upgrading into 2.5.2 in coming weeks.

the main difference in upgrade to 2.5.2 is the git mirroring to github 
is no longer part of gerrit, rather a plugin. so post the upgrade it 
will stop, then I'll activate it later on (divide and conquer).

if anyone has any thoughts/concerns, please raise them.
I'll most likely look into doing the upgrade on some sunday evening - it 
should take a few minutes of downtime (and i backup the VM fully before).

thanks,
    Itamar


From alonbl at redhat.com  Thu May  2 20:11:03 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 2 May 2013 16:11:03 -0400 (EDT)
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <915714786.3720369.1367525010526.JavaMail.root@redhat.com>
Message-ID: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>

Hello,

I get these (lots of these) using latest master... anyone knows what was changed?

At server.log I see:
---
2013-05-02 19:58:08,046 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 21) JBAS010280: Activating Infinispan subsystem.
<snip>
2013-05-02 19:58:10,155 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.mbean.server (missing) dependents: [service jboss.infinispan.ovirt-engine.config]

---

Thanks,
Alon

---

2013-05-02 20:02:10,012 ERROR [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy] (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Failed to lookup resource type: CACHE_CONTAINER. JNDI name: java:jboss/infinispan/ovirt-engine: javax.naming.NameNotFoundException: Error looking up infinispan/ovirt-engine, service service jboss.naming.context.java.jboss.infinispan.ovirt-engine is not started
        at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
        at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
        at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
        at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_17]
        at org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104) [utils.jar:]
        at org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23) [utils.jar:]
        at org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:12) [utils.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437) [dal.jar:]
        at org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318) [bll.jar:]
        at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332) [bll.jar:]
        at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534) [bll.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_17]

2013-05-02 20:02:10,059 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase] (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Error during log command: org.ovirt.engine.core.bll.SetNonOperationalVdsCommand. Exception java.lang.NullPointerException: java.lang.NullPointerException
        at org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:13) [utils.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437) [dal.jar:]
        at org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318) [bll.jar:]
        at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332) [bll.jar:]
        at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534) [bll.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_17]

2013-05-02 20:02:10,360 ERROR [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy] (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Failed to lookup resource type: CACHE_CONTAINER. JNDI name: java:jboss/infinispan/ovirt-engine: javax.naming.NameNotFoundException: Error looking up infinispan/ovirt-engine, service service jboss.naming.context.java.jboss.infinispan.ovirt-engine is not started
        at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
        at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
        at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
        at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_17]
        at org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104) [utils.jar:]
        at org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23) [utils.jar:]
        at org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:12) [utils.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437) [dal.jar:]
        at org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318) [bll.jar:]
        at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332) [bll.jar:]
        at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534) [bll.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_17]


2013-05-02 20:02:10,407 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase] (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Error during log command: org.ovirt.engine.core.bll.SetNonOperationalVdsCommand. Exception java.lang.NullPointerException: java.lang.NullPointerException
        at org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:13) [utils.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799) [dal.jar:]
        at org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437) [dal.jar:]
        at org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318) [bll.jar:]
        at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332) [bll.jar:]
        at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534) [bll.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_17]


From iheim at redhat.com  Thu May  2 20:45:55 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 02 May 2013 23:45:55 +0300
Subject: [Engine-devel] =?gb2312?b?tPC4tDogtPC4tDogYWJvdXQgb3ZpcnQtZW5n?=
 =?gb2312?b?aW5lLXNkaw==?=
In-Reply-To: <001501ce4715$dc801570$95804050$@com>
References: <000f01ce46e0$490d4c70$db27e550$@com> <51820545.9060904@redhat.com>
	<001401ce470b$fd5547c0$f7ffd740$@com> <5182227A.9010609@redhat.com>
	<001501ce4715$dc801570$95804050$@com>
Message-ID: <5182D083.6040903@redhat.com>

On 05/02/2013 12:17 PM, leaboy at 126 wrote:
> Thinks, I just missing lxml.
> When I installed lxml , it works well.

isn't it a dependency of the rpm?

> 
> -----????-----
> ???: Michael Pasternak [mailto:mpastern at redhat.com]
> ????: 2013?5?2? 16:23
> ???: leaboy at 126
> ??: engine-devel at ovirt.org
> ??: Re: ??: about ovirt-engine-sdk
> 
> On 05/02/2013 11:06 AM, leaboy at 126 wrote:
>> The code I got in 2013-1-27 with git, I don't know which version I got,
>> I didn't install it , I just use it like the example,
> 
> you should be installing sdk in some way, cause just fetching it from the
> git,
> wasn't make it available in python,
> 
> i suggest you installing official releases (unless you would like to develop
> & contribute)
> from pypi/easy_install.
> 
>>
>>   leaboy at leaboy:~/workspace/thtf-client$ python --version
>>   Python 2.7.3
>>   leaboy at leaboy:~/workspace/thtf-client$ python
>>   Python 2.7.3 (default, Aug  1 2012, 05:16:07)
>>   [GCC 4.6.3] on linux2
>>   Type "help", "copyright", "credits" or "license" for more information.
>>   
>>   >>> from ovirtsdk.api import API
>>   >>> from ovirtsdk.xml import params
>>   >>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
>> None, '~/.spicec/ca.crt', None, True)
>>   >>>
>>
>> I use it successful in ubuntu 12.04 without any other operation,
>> Just import the modules with python 2.7.3
>>
>> But when I use it in other OS, such as ubuntu 11, or embed linux for ARM,
>> With python 2.6.*, It does't work,
> 
> i just verified it on [1], not sure about embed linux, in any case to
> make it work, lxml should be installed.
> 
> [1]
> python 2.6.6
> python-lxml-2.2.3-1
> 
>>
>>
>>
>> -----????-----
>> ???: Michael Pasternak [mailto:mpastern at redhat.com]
>> ????: 2013?5?2? 14:19
>> ???: leaboy at 126
>> ??: engine-devel at ovirt.org
>> ??: Re: about ovirt-engine-sdk
>>
>>
>> Hi,
>>
>> On 05/02/2013 05:53 AM, leaboy at 126 wrote:
>>> Hi,all
>>>
>>> How can I use overt-engine-sdk in the python environment below python2.7,
>>>
>>> For example, when I use it in python 2.6.5 like thus:
>>
>> what sdk version you're using?
>> how did you installed it?
>> what version of lxml you have installed?
>>
>>>
>>>   
>>>
>>> percy at percy-desktop:~/thtf-client$ python --version
>>>
>>> Python 2.6.5
>>>
>>> percy at percy-desktop:~/thtf-client$ python
>>>
>>> Python 2.6.5 (r265:79063, Oct  1 2012, 22:04:36)
>>>
>>> [GCC 4.4.3] on linux2
>>>
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>>>> from ovirtsdk.api import API
>>>
>>>>>> from ovirtsdk.xml import params
>>>
>>>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
>> None, '~/.spicec/ca.crt', None, None, True)
>>>
>>> *Traceback (most recent call last):*
>>>
>>> *  File "<stdin>", line 1, in <module>*
>>>
>>> *  File "ovirtsdk/api.py", line 107, in __init__*
>>>
>>> *    url='/api')*
>>>
>>> *  File "ovirtsdk/infrastructure/proxy.py", line 129, in request*
>>>
>>> *    last=last)*
>>>
>>> *  File "ovirtsdk/infrastructure/proxy.py", line 171, in __doRequest*
>>>
>>> *    return params.parseString(response_body) if response_body is not
> None
>> and response_body is not '' \*
>>>
>>> *  File "ovirtsdk/xml/params.py", line 21229, in parseString*
>>>
>>> *    rootObj.build(rootNode)*
>>>
>>> *  File "ovirtsdk/xml/params.py", line 20304, in build*
>>>
>>> *    self.buildAttributes(node, node.attrib, [])*
>>>
>>> *  File "ovirtsdk/xml/params.py", line 20309, in buildAttributes*
>>>
>>> *    super(API, self).buildAttributes(node, attrs, already_processed)*
>>>
>>> *  File "ovirtsdk/xml/params.py", line 4160, in buildAttributes*
>>>
>>> *    value = find_attr_value_('xsi:type', node)*
>>>
>>> *  File "ovirtsdk/xml/params.py", line 316, in find_attr_value_*
>>>
>>> *    namespace = node.nsmap.get(prefix)*
>>>
>>> *AttributeError: nsmap*
>>>
>>>>>>
>>>
>>>   
>>>
>>>   
>>>
>>> But, when I use it in python 2.7.3, it?s ok
>>>
>>>   
>>>
>>> leaboy at leaboy:~/workspace/thtf-client$ python --version
>>>
>>> Python 2.7.3
>>>
>>> leaboy at leaboy:~/workspace/thtf-client$ python
>>>
>>> Python 2.7.3 (default, Aug  1 2012, 05:16:07)
>>>
>>> [GCC 4.6.3] on linux2
>>>
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>>>> from ovirtsdk.api import API
>>>
>>>>>> from ovirtsdk.xml import params
>>>
>>>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
>> None, '~/.spicec/ca.crt', None, True)
>>>
>>>>>>
>>>
>>
>>
> 
> 



From iheim at redhat.com  Thu May  2 20:52:38 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 02 May 2013 23:52:38 +0300
Subject: [Engine-devel] Sandro Bonazzola as a tools maintainer
In-Reply-To: <1680512717.4903283.1367483066397.JavaMail.root@redhat.com>
References: <51472FD2.7020806@redhat.com> <518221F2.8090407@redhat.com>
	<1680512717.4903283.1367483066397.JavaMail.root@redhat.com>
Message-ID: <5182D216.2060509@redhat.com>

On 05/02/2013 11:24 AM, Kiril Nesenko wrote:
>
>
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> To: "Kiril Nesenko" <knesenko at redhat.com>
>> Sent: Thursday, May 2, 2013 11:21:06 AM
>> Subject: Fwd: Sandro Bonazzola as a tools maintainer
>>
>>
>>
>>
>> -------- Messaggio originale --------
>> Oggetto: 	Sandro Bonazzola as a tools maintainer
>> Data: 	Mon, 18 Mar 2013 11:16:34 -0400
>> Mittente: 	Keith Robertson <kroberts at redhat.com>
>> A: 	engine-devel at ovirt.org <engine-devel at ovirt.org>
>> CC: 	Moran Goldboim <mgoldboi at redhat.com>, Sandro Bonazzola
>> <sbonazzo at redhat.com>
>>
>>
>>
>> I would like to propose that we add Sandro Bonazzola as a maintainer for
>> the Ovirt ISO Uploader, Image Uploader and Log Collector.  He too has
>> been enormously helpful with the maintenance of the tools.
>>
>> Thanks,
>> Keith Robertson
>
> +1
>
> - Kiril
>>
>>
>>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

added.
I've also split the old tools group to 3 new groups, one per tool (log 
collector, image uploader and iso uploader).




From paritak at packtpub.com  Thu May  2 13:10:09 2013
From: paritak at packtpub.com (Parita Khedekar)
Date: Thu, 02 May 2013 18:40:09 +0530
Subject: [Engine-devel] Author a "Getting started with oVirt 3.x" mini book
	for Packt.
Message-ID: <518265B1.3050000@packtpub.com>

Hi,

My name is Parita Khedekar and I am an Author Relationship Executive for 
Packt Publishing. We specialize in publishing IT related books, e-books, 
and articles that have been written by experts in the field.

We are currently looking out for prospective authors to write our Mini 
book of 80-100 Pages on _*Getting started with oVirt 3.x*_ targeted at 
Network Engineers, Virtualization Engineers, Desktop Engineers, 
Network/Desktop Architects.

I was wondering if anyone of you would be interested in authoring this 
title for Packt. As mentioned by Mr. Eyal Edri, this would be the right 
place to search for the best person to author this title.

Looking forward to hear from you and do let me know if you have any 
queries or doubts.

Regards,
-- 

**Parita Khedekar
** *Author Relationship Executive
PACKT Publishing
*www.packtpub.com <http://www.packtpub.com/>
* **MSN*: paritak at packtpub.com

<http://www.facebook.com/pages/Packt-Authors/146867485392878?ref%3Dts&layout=standard&show_faces=true&width=50&action=like&colorscheme=light&height=30%20target=><http://twitter.com/packtauthors> 
<paritak at packtpub.com%3C>
Interested in becoming an author? Visit http://authors.packtpub.com for 
all the information you need about writing for Packt.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130502/95a17e5d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: th_facebook_like_button_small.png
Type: image/png
Size: 7230 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130502/95a17e5d/attachment.png>

From yzaslavs at redhat.com  Fri May  3 04:10:37 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Fri, 3 May 2013 00:10:37 -0400 (EDT)
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
Message-ID: <1066256837.5335037.1367554237087.JavaMail.root@redhat.com>

Hi Alon,
I might check this later on today.
Did you follow Kublin's email about introducing infinispan? he sent it to engine-devel (you're supposed during the build to perform -P setup)

Yair


----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, May 2, 2013 11:11:03 PM
> Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
> 
> Hello,
> 
> I get these (lots of these) using latest master... anyone knows what was
> changed?
> 
> At server.log I see:
> ---
> 2013-05-02 19:58:08,046 INFO  [org.jboss.as.clustering.infinispan]
> (ServerService Thread Pool -- 21) JBAS010280: Activating Infinispan
> subsystem.
> <snip>
> 2013-05-02 19:58:10,155 INFO  [org.jboss.as.controller] (Controller Boot
> Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.mbean.server (missing) dependents: [service
>       jboss.infinispan.ovirt-engine.config]
> 
> ---
> 
> Thanks,
> Alon
> 
> ---
> 
> 2013-05-02 20:02:10,012 ERROR
> [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy]
> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Failed to lookup resource type:
> CACHE_CONTAINER. JNDI name: java:jboss/infinispan/ovirt-engine:
> javax.naming.NameNotFoundException: Error looking up
> infinispan/ovirt-engine, service service
> jboss.naming.context.java.jboss.infinispan.ovirt-engine is not started
>         at
>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
>         at
>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
>         at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
>         at javax.naming.InitialContext.lookup(InitialContext.java:411)
>         [rt.jar:1.7.0_17]
>         at
>         org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104)
>         [utils.jar:]
>         at
>         org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23)
>         [utils.jar:]
>         at
>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:12)
>         [utils.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
>         [bll.jar:]
>         at
>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
>         [bll.jar:]
>         at
>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
>         [bll.jar:]
>         at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
>         [bll.jar:]
>         at
>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
>         [bll.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         [rt.jar:1.7.0_17]
> 
> 2013-05-02 20:02:10,059 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase]
> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Error during log command:
> org.ovirt.engine.core.bll.SetNonOperationalVdsCommand. Exception
> java.lang.NullPointerException: java.lang.NullPointerException
>         at
>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:13)
>         [utils.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
>         [bll.jar:]
>         at
>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
>         [bll.jar:]
>         at
>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
>         [bll.jar:]
>         at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
>         [bll.jar:]
>         at
>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
>         [bll.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         [rt.jar:1.7.0_17]
> 
> 2013-05-02 20:02:10,360 ERROR
> [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy]
> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Failed to lookup resource type:
> CACHE_CONTAINER. JNDI name: java:jboss/infinispan/ovirt-engine:
> javax.naming.NameNotFoundException: Error looking up
> infinispan/ovirt-engine, service service
> jboss.naming.context.java.jboss.infinispan.ovirt-engine is not started
>         at
>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
>         at
>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
>         at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
>         at javax.naming.InitialContext.lookup(InitialContext.java:411)
>         [rt.jar:1.7.0_17]
>         at
>         org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104)
>         [utils.jar:]
>         at
>         org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23)
>         [utils.jar:]
>         at
>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:12)
>         [utils.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
>         [bll.jar:]
>         at
>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
>         [bll.jar:]
>         at
>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
>         [bll.jar:]
>         at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
>         [bll.jar:]
>         at
>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
>         [bll.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         [rt.jar:1.7.0_17]
> 
> 
> 2013-05-02 20:02:10,407 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase]
> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Error during log command:
> org.ovirt.engine.core.bll.SetNonOperationalVdsCommand. Exception
> java.lang.NullPointerException: java.lang.NullPointerException
>         at
>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:13)
>         [utils.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
>         [dal.jar:]
>         at
>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
>         [bll.jar:]
>         at
>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
>         [bll.jar:]
>         at
>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
>         [bll.jar:]
>         at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
>         [bll.jar:]
>         at
>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
>         [bll.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         [rt.jar:1.7.0_17]
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alonbl at redhat.com  Fri May  3 04:23:44 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Fri, 3 May 2013 00:23:44 -0400 (EDT)
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <1066256837.5335037.1367554237087.JavaMail.root@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<1066256837.5335037.1367554237087.JavaMail.root@redhat.com>
Message-ID: <928424823.3820639.1367555024185.JavaMail.root@redhat.com>


Hi,

Thanks... no I did not follow.

If -P setup is required then the Makefile should have been changed, else our production and rpms are broken now! Well... looking at the pom.xml, it looks like the jboss standalone is configured with -P setup is used, which is yet another hack introduced to developers... As they do not run our service, and suffer from lack of proper environment and configuration settings.

My work[1] is exactly to address this one, to eliminate the need for hacking the product and use our production startup sequence and installation. At ./packaging/services/ovirt-engine.xml.in we already have the infinispan settings.

So still need your help.
Thanks,
Alon

[1] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, May 3, 2013 7:10:37 AM
> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> 
> Hi Alon,
> I might check this later on today.
> Did you follow Kublin's email about introducing infinispan? he sent it to
> engine-devel (you're supposed during the build to perform -P setup)
> 
> Yair
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, May 2, 2013 11:11:03 PM
> > Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
> > 
> > Hello,
> > 
> > I get these (lots of these) using latest master... anyone knows what was
> > changed?
> > 
> > At server.log I see:
> > ---
> > 2013-05-02 19:58:08,046 INFO  [org.jboss.as.clustering.infinispan]
> > (ServerService Thread Pool -- 21) JBAS010280: Activating Infinispan
> > subsystem.
> > <snip>
> > 2013-05-02 19:58:10,155 INFO  [org.jboss.as.controller] (Controller Boot
> > Thread) JBAS014774: Service status report
> > JBAS014775:    New missing/unsatisfied dependencies:
> >       service jboss.mbean.server (missing) dependents: [service
> >       jboss.infinispan.ovirt-engine.config]
> > 
> > ---
> > 
> > Thanks,
> > Alon
> > 
> > ---
> > 
> > 2013-05-02 20:02:10,012 ERROR
> > [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy]
> > (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Failed to lookup resource
> > type:
> > CACHE_CONTAINER. JNDI name: java:jboss/infinispan/ovirt-engine:
> > javax.naming.NameNotFoundException: Error looking up
> > infinispan/ovirt-engine, service service
> > jboss.naming.context.java.jboss.infinispan.ovirt-engine is not started
> >         at
> >         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
> >         at
> >         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
> >         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
> >         at
> >         org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
> >         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
> >         at javax.naming.InitialContext.lookup(InitialContext.java:411)
> >         [rt.jar:1.7.0_17]
> >         at
> >         org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104)
> >         [utils.jar:]
> >         at
> >         org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23)
> >         [utils.jar:]
> >         at
> >         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:12)
> >         [utils.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
> >         [bll.jar:]
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >         [rt.jar:1.7.0_17]
> > 
> > 2013-05-02 20:02:10,059 ERROR
> > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase]
> > (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Error during log command:
> > org.ovirt.engine.core.bll.SetNonOperationalVdsCommand. Exception
> > java.lang.NullPointerException: java.lang.NullPointerException
> >         at
> >         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:13)
> >         [utils.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
> >         [bll.jar:]
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >         [rt.jar:1.7.0_17]
> > 
> > 2013-05-02 20:02:10,360 ERROR
> > [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy]
> > (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Failed to lookup resource
> > type:
> > CACHE_CONTAINER. JNDI name: java:jboss/infinispan/ovirt-engine:
> > javax.naming.NameNotFoundException: Error looking up
> > infinispan/ovirt-engine, service service
> > jboss.naming.context.java.jboss.infinispan.ovirt-engine is not started
> >         at
> >         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
> >         at
> >         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
> >         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
> >         at
> >         org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
> >         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
> >         at javax.naming.InitialContext.lookup(InitialContext.java:411)
> >         [rt.jar:1.7.0_17]
> >         at
> >         org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104)
> >         [utils.jar:]
> >         at
> >         org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23)
> >         [utils.jar:]
> >         at
> >         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:12)
> >         [utils.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
> >         [bll.jar:]
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >         [rt.jar:1.7.0_17]
> > 
> > 
> > 2013-05-02 20:02:10,407 ERROR
> > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase]
> > (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Error during log command:
> > org.ovirt.engine.core.bll.SetNonOperationalVdsCommand. Exception
> > java.lang.NullPointerException: java.lang.NullPointerException
> >         at
> >         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:13)
> >         [utils.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
> >         [dal.jar:]
> >         at
> >         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
> >         [bll.jar:]
> >         at
> >         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
> >         [bll.jar:]
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >         [rt.jar:1.7.0_17]
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From wei.d.chen at intel.com  Fri May  3 05:01:51 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Fri, 3 May 2013 05:01:51 +0000
Subject: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1
 running enviroment?
In-Reply-To: <C5A0092C63E939488005F15F736A8112097AB2BC@SHSMSX101.ccr.corp.intel.com>
References: <C5A0092C63E939488005F15F736A8112097A6EA2@SHSMSX101.ccr.corp.intel.com>
	<5152C521.9090302@redhat.com>
	<C5A0092C63E939488005F15F736A8112097AB2BC@SHSMSX101.ccr.corp.intel.com>
Message-ID: <C5A0092C63E939488005F15F736A8112097ABC05@SHSMSX101.ccr.corp.intel.com>

I got this error message when I want to add a host from webadmin,

"Failed to execute stage 'Package installation': [u'vdsm-gluster-4.10.3-10.fc18.noarch requires glusterfs >= 3.4.0']"

So, I install glusterfs-3.4.0alpha2-1.el6.x86_64.rpm manually as recommended, restart host and then I got follow error message instead.

Error:  Multilib version problems found. This often means that the root

       cause is something else and multilib version checking is just

       pointing it that there is a problem. Eg.:

         1. You have an upgrade for glusterfs which is missing some dependency that another package requires. Yum is trying to solve this by installing an older version of glusterfs of the different architecture. If you exclude the bad architecture yum will tell you what the root cause is (which package requires what).

         2. You have multiple architectures of glusterfs installed, but yum can only see an upgrade for one of those arcitectures. If you don't want/need both architectures anymore then you can remove the one with the missing update and everything will work.

         3. You have duplicate versions of glusterfs installed already.

       You can use "yum check" to get yum show these errors.

       ...you can also use --setopt=protected_multilib=false to remove

       this checking, however this is almost never the correct thing to

       do as something else is very likely to go wrong (often causing

       much more problems).



       Protected multilib versions: glusterfs-3.3.1-13.fc18.i686 != glusterfs-3.4.0alpha2-1.el6.x86_64

Our platform is based on x86_64, why we got above error message, really weird.

Best Regards,
Dave Chen

From: Chen, Wei D
Sent: Thursday, May 02, 2013 4:06 PM
To: Shireesh Anjal
Cc: engine-devel at ovirt.org
Subject: RE: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment?

Hi,

This is a very old thread, grep this mail out just because we still face some issues when we try to set up a workable ovirt environment with latest ovirt package repository.
My first question is since glusterfs-3.4 is required to setup ovirt, why we not add glusterfs-3.4 into ovirt package repository?

My another question is when we tried to add a host to default cluster, it complains "No package(s) available to install" in the step of installing "libvirt" and "vdsm", but these packages can be found from ovirt repository? how to fix this? some extra clue is we can install these packages with  fedora 18 repository, so, is it possible to specify a repository for ovirt node's installing? We just want to install all of these binaries from ovirt repository to avoid some version inconsistent issue.

The last one is whether it is possible to generate a trust_store.jks manually as we failed to find this file in our current environment.


Best Regards,
Dave Chen

From: Shireesh Anjal [mailto:sanjal at redhat.com]
Sent: Wednesday, March 27, 2013 6:09 PM
To: Chen, Wei D
Cc: engine-devel at ovirt.org<mailto:engine-devel at ovirt.org>
Subject: Re: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment?

On 03/26/2013 09:20 AM, Chen, Wei D wrote:

Hi,



We notice that ovirt-engine's version (rpm package and source code) has updated from 3.2.0 to 3.2.1. As our development process is always based on 3.2.0. Is there any way to re-setup 3.2.0 running environment?



Besides, we also cannot setup 3.2.1 ovrit-engine running environment as its dependent package glusterfs-3.4 cannot be found from ovirt repo or fedora18 repo. How can I fix this issue?  Thanks.

glusterfs-3.4.0alph2 packages can be obtained from following yum repo:

http://bits.gluster.org/pub/gluster/glusterfs/stage/

This is required only if the cluster in which you are adding the host has gluster service enabled.






Best Regards,

Dave Chen





_______________________________________________

Engine-devel mailing list

Engine-devel at ovirt.org<mailto:Engine-devel at ovirt.org>

http://lists.ovirt.org/mailman/listinfo/engine-devel

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

From sbonazzo at redhat.com  Fri May  3 06:19:30 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 03 May 2013 08:19:30 +0200
Subject: [Engine-devel] Sandro Bonazzola as a tools maintainer
In-Reply-To: <5182D216.2060509@redhat.com>
References: <51472FD2.7020806@redhat.com> <518221F2.8090407@redhat.com>
	<1680512717.4903283.1367483066397.JavaMail.root@redhat.com>
	<5182D216.2060509@redhat.com>
Message-ID: <518356F2.7070204@redhat.com>

Il 02/05/2013 22:52, Itamar Heim ha scritto:
> On 05/02/2013 11:24 AM, Kiril Nesenko wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>> To: "Kiril Nesenko" <knesenko at redhat.com>
>>> Sent: Thursday, May 2, 2013 11:21:06 AM
>>> Subject: Fwd: Sandro Bonazzola as a tools maintainer
>>>
>>>
>>>
>>>
>>> -------- Messaggio originale --------
>>> Oggetto:     Sandro Bonazzola as a tools maintainer
>>> Data:     Mon, 18 Mar 2013 11:16:34 -0400
>>> Mittente:     Keith Robertson <kroberts at redhat.com>
>>> A:     engine-devel at ovirt.org <engine-devel at ovirt.org>
>>> CC:     Moran Goldboim <mgoldboi at redhat.com>, Sandro Bonazzola
>>> <sbonazzo at redhat.com>
>>>
>>>
>>>
>>> I would like to propose that we add Sandro Bonazzola as a maintainer
>>> for
>>> the Ovirt ISO Uploader, Image Uploader and Log Collector.  He too has
>>> been enormously helpful with the maintenance of the tools.
>>>
>>> Thanks,
>>> Keith Robertson
>>
>> +1
>>
>> - Kiril
>>>
>>>
>>>
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
> added.
> I've also split the old tools group to 3 new groups, one per tool (log
> collector, image uploader and iso uploader).
>
>
Thanks!

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From wlbleaboy at 126.com  Fri May  3 07:03:28 2013
From: wlbleaboy at 126.com (leaboy@126)
Date: Fri, 3 May 2013 15:03:28 +0800
Subject: [Engine-devel] =?gb2312?b?tPC4tDogILTwuLQ6ILTwuLQ6IGFib3V0IG92?=
	=?gb2312?b?aXJ0LWVuZ2luZS1zZGs=?=
In-Reply-To: <5182D083.6040903@redhat.com>
References: <000f01ce46e0$490d4c70$db27e550$@com> <51820545.9060904@redhat.com>
	<001401ce470b$fd5547c0$f7ffd740$@com> <5182227A.9010609@redhat.com>
	<001501ce4715$dc801570$95804050$@com> <5182D083.6040903@redhat.com>
Message-ID: <002601ce47cc$50f38480$f2da8d80$@com>

I get the lxml code from http://lxml.de/2.3/#old-versions
And build it use : python setup.py build
in the directory lxml-2.2.3/build/lib.linux-armv71-2.6/
Copy the lxml to /usr/lib/python2.6/

-----????-----
???: Itamar Heim [mailto:iheim at redhat.com] 
????: 2013?5?3? 4:46
???: leaboy at 126
??: 'Michael Pasternak'; engine-devel at ovirt.org
??: Re: [Engine-devel] ??: ??: about ovirt-engine-sdk

On 05/02/2013 12:17 PM, leaboy at 126 wrote:
> Thinks, I just missing lxml.
> When I installed lxml , it works well.

isn't it a dependency of the rpm?

> 
> -----????-----
> ???: Michael Pasternak [mailto:mpastern at redhat.com]
> ????: 2013?5?2? 16:23
> ???: leaboy at 126
> ??: engine-devel at ovirt.org
> ??: Re: ??: about ovirt-engine-sdk
> 
> On 05/02/2013 11:06 AM, leaboy at 126 wrote:
>> The code I got in 2013-1-27 with git, I don't know which version I got,
>> I didn't install it , I just use it like the example,
> 
> you should be installing sdk in some way, cause just fetching it from the
> git,
> wasn't make it available in python,
> 
> i suggest you installing official releases (unless you would like to
develop
> & contribute)
> from pypi/easy_install.
> 
>>
>>   leaboy at leaboy:~/workspace/thtf-client$ python --version
>>   Python 2.7.3
>>   leaboy at leaboy:~/workspace/thtf-client$ python
>>   Python 2.7.3 (default, Aug  1 2012, 05:16:07)
>>   [GCC 4.6.3] on linux2
>>   Type "help", "copyright", "credits" or "license" for more information.
>>   
>>   >>> from ovirtsdk.api import API
>>   >>> from ovirtsdk.xml import params
>>   >>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
>> None, '~/.spicec/ca.crt', None, True)
>>   >>>
>>
>> I use it successful in ubuntu 12.04 without any other operation,
>> Just import the modules with python 2.7.3
>>
>> But when I use it in other OS, such as ubuntu 11, or embed linux for ARM,
>> With python 2.6.*, It does't work,
> 
> i just verified it on [1], not sure about embed linux, in any case to
> make it work, lxml should be installed.
> 
> [1]
> python 2.6.6
> python-lxml-2.2.3-1
> 
>>
>>
>>
>> -----????-----
>> ???: Michael Pasternak [mailto:mpastern at redhat.com]
>> ????: 2013?5?2? 14:19
>> ???: leaboy at 126
>> ??: engine-devel at ovirt.org
>> ??: Re: about ovirt-engine-sdk
>>
>>
>> Hi,
>>
>> On 05/02/2013 05:53 AM, leaboy at 126 wrote:
>>> Hi,all
>>>
>>> How can I use overt-engine-sdk in the python environment below
python2.7,
>>>
>>> For example, when I use it in python 2.6.5 like thus:
>>
>> what sdk version you're using?
>> how did you installed it?
>> what version of lxml you have installed?
>>
>>>
>>>   
>>>
>>> percy at percy-desktop:~/thtf-client$ python --version
>>>
>>> Python 2.6.5
>>>
>>> percy at percy-desktop:~/thtf-client$ python
>>>
>>> Python 2.6.5 (r265:79063, Oct  1 2012, 22:04:36)
>>>
>>> [GCC 4.4.3] on linux2
>>>
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>>>> from ovirtsdk.api import API
>>>
>>>>>> from ovirtsdk.xml import params
>>>
>>>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
>> None, '~/.spicec/ca.crt', None, None, True)
>>>
>>> *Traceback (most recent call last):*
>>>
>>> *  File "<stdin>", line 1, in <module>*
>>>
>>> *  File "ovirtsdk/api.py", line 107, in __init__*
>>>
>>> *    url='/api')*
>>>
>>> *  File "ovirtsdk/infrastructure/proxy.py", line 129, in request*
>>>
>>> *    last=last)*
>>>
>>> *  File "ovirtsdk/infrastructure/proxy.py", line 171, in __doRequest*
>>>
>>> *    return params.parseString(response_body) if response_body is not
> None
>> and response_body is not '' \*
>>>
>>> *  File "ovirtsdk/xml/params.py", line 21229, in parseString*
>>>
>>> *    rootObj.build(rootNode)*
>>>
>>> *  File "ovirtsdk/xml/params.py", line 20304, in build*
>>>
>>> *    self.buildAttributes(node, node.attrib, [])*
>>>
>>> *  File "ovirtsdk/xml/params.py", line 20309, in buildAttributes*
>>>
>>> *    super(API, self).buildAttributes(node, attrs, already_processed)*
>>>
>>> *  File "ovirtsdk/xml/params.py", line 4160, in buildAttributes*
>>>
>>> *    value = find_attr_value_('xsi:type', node)*
>>>
>>> *  File "ovirtsdk/xml/params.py", line 316, in find_attr_value_*
>>>
>>> *    namespace = node.nsmap.get(prefix)*
>>>
>>> *AttributeError: nsmap*
>>>
>>>>>>
>>>
>>>   
>>>
>>>   
>>>
>>> But, when I use it in python 2.7.3, it?s ok
>>>
>>>   
>>>
>>> leaboy at leaboy:~/workspace/thtf-client$ python --version
>>>
>>> Python 2.7.3
>>>
>>> leaboy at leaboy:~/workspace/thtf-client$ python
>>>
>>> Python 2.7.3 (default, Aug  1 2012, 05:16:07)
>>>
>>> [GCC 4.6.3] on linux2
>>>
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>>>> from ovirtsdk.api import API
>>>
>>>>>> from ovirtsdk.xml import params
>>>
>>>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
>> None, '~/.spicec/ca.crt', None, True)
>>>
>>>>>>
>>>
>>
>>
> 
> 




From mperina at redhat.com  Fri May  3 09:06:05 2013
From: mperina at redhat.com (Martin Perina)
Date: Fri, 3 May 2013 05:06:05 -0400 (EDT)
Subject: [Engine-devel] Device custom properties
In-Reply-To: <876156728.6355122.1367571870486.JavaMail.root@redhat.com>
Message-ID: <769095690.6355567.1367571965290.JavaMail.root@redhat.com>

Hi,
 
I'm currently trying to implement device custom properties infrastructure in ovirt-engine.
During discussion with Yair, we found out, that it's not clear, for what type of devices
custom properties should be available? In engine we have the VmDeviceType enum which
contains following values:
 
     FLOPPY("floppy", "14"),
     DISK("disk", "17"),
     CDROM("cdrom", "15"),
     INTERFACE("interface", "10"),
     BRIDGE("bridge", "3"),
     VIDEO("video", "20"),
     USB("usb", "23"),
     CONTROLLER("controller", "23"),
     REDIR("redir", "23"),
     SPICEVMC("spicevmc", "23"),
     QXL("qxl"),
     CIRRUS("cirrus"),
     SOUND("sound"),
     ICH6("ich6"),
     AC97("ac97"),
     MEMBALLOON("memballoon"),
     SMARTCARD("smartcard"),
     BALLOON("balloon"),
     OTHER("other", "0"),
     UNKNOWN("unknown", "-1");
 
But VmDevice class has two String attributes device and type. So for example a disk is a device
which has device set to disk and type set to disk (according to VmDeviceCommonUtils.isDisk method).
 
So my question is, if I have a custom properties for disk, will they be available for all disk
devices (disk, cdrom, floppy, ...) or only for real disk? So should we support custom properties
for all VmDeviceType enum value separately?

Thanks for suggestions

Martin


From alonbl at redhat.com  Fri May  3 10:09:51 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Fri, 3 May 2013 06:09:51 -0400 (EDT)
Subject: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1
 running enviroment?
In-Reply-To: <C5A0092C63E939488005F15F736A8112097AB2BC@SHSMSX101.ccr.corp.intel.com>
References: <C5A0092C63E939488005F15F736A8112097A6EA2@SHSMSX101.ccr.corp.intel.com>
	<5152C521.9090302@redhat.com>
	<C5A0092C63E939488005F15F736A8112097AB2BC@SHSMSX101.ccr.corp.intel.com>
Message-ID: <920837636.3883623.1367575791687.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Wei D Chen" <wei.d.chen at intel.com>
> To: "Shireesh Anjal" <sanjal at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, May 2, 2013 11:06:18 AM
> Subject: Re: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment?
> 
> 
> 
> Hi,
> 
> 
> 
> This is a very old thread, grep this mail out just because we still face some
> issues when we try to set up a workable ovirt environment with latest ovirt
> package repository.
> 
> My first question is since glusterfs-3.4 is required to setup ovirt, why we
> not add glusterfs-3.4 into ovirt package repository?

Good question.
But if you don't need gluster support, please remove the gluster feature from the ovirt cluster and try again.

> 
> 
> 
> My another question is when we tried to add a host to default cluster, it
> complains ?No package(s) available to install? in the step of installing
> ?libvirt? and ?vdsm?, but these packages can be found from ovirt repository?
> how to fix this? some extra clue is we can install these packages with
> fedora 18 repository, so, is it possible to specify a repository for ovirt
> node?s installing? We just want to install all of these binaries from ovirt
> repository to avoid some version inconsistent issue.
> 
> 
> 
> The last one is whether it is possible to generate a trust_store.jks manually
> as we failed to find this file in our current environment.
> 
> 
> 
> 
> 
> 
> Best Regards,
> 
> Dave Chen
> 
> 
> 
> 
> 
> From: Shireesh Anjal [mailto:sanjal at redhat.com]
> Sent: Wednesday, March 27, 2013 6:09 PM
> To: Chen, Wei D
> Cc: engine-devel at ovirt.org
> Subject: Re: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1
> running enviroment?
> 
> 
> 
> 
> 
> On 03/26/2013 09:20 AM, Chen, Wei D wrote:
> 
> 
> 
> Hi,
> We notice that ovirt-engine's version (rpm package and source code) has
> updated from 3.2.0 to 3.2.1. As our development process is always based on
> 3.2.0. Is there any way to re-setup 3.2.0 running environment?
> Besides, we also cannot setup 3.2.1 ovrit-engine running environment as its
> dependent package glusterfs-3.4 cannot be found from ovirt repo or fedora18
> repo. How can I fix this issue?? Thanks.
> 
> 
> 
> glusterfs-3.4.0alph2 packages can be obtained from following yum repo:
> 
> http://bits.gluster.org/pub/gluster/glusterfs/stage/
> 
> This is required only if the cluster in which you are adding the host has
> gluster service enabled.
> 
> 
> Best Regards,
> Dave Chen
> _______________________________________________
> 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 liqiang.net at gmail.com  Sat May  4 04:48:17 2013
From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=)
Date: Sat, 4 May 2013 12:48:17 +0800
Subject: [Engine-devel] engine-manage-domains add domain(RHDS) ERROR
Message-ID: <CAH=UCn4JJAuqD7LM4L2m8UgxysqayUdUwS=0q-nrPHp+ztAk8g@mail.gmail.com>

HI?All

COMMAND:
engine-manage-domains -action=add -domain='authen.startn.com'
-provider='RHDS' -user='admin' -interactive
No LDAP servers can be obtained for domain authen.startn.com

My redhat dir serv is 9.0 and OS:fedora 18.


========================
dig authen.startn.com

authen.startn.com.      86400   IN      A       10.0.10.182

startn.com.             86400   IN      NS      engine.startn.com.

engine.startn.com.      86400   IN      A       10.0.10.181

;; Query time: 0 msec
;; SERVER: 10.0.10.181#53(10.0.10.181)
;; WHEN: Sat May  4 12:46:27 2013
;; MSG SIZE  rcvd: 99

/var/log/ovirt-engine/engine-manage-domains.log
=================================
2013-05-04 12:15:13,523 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
2013-05-04 12:15:13,524 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf".
2013-05-04 12:15:13,525 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
2013-05-04 12:15:13,525 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
2013-05-04 12:15:13,526 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
2013-05-04 12:15:13,527 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_ENABLED" is "true".
2013-05-04 12:15:13,527 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_PORT" is "8702".
2013-05-04 12:15:13,527 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_APPS" is "engine.ear".
2013-05-04 12:15:13,527 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_PASSWORD" is
"28b00f35c5f550e36c5fd1b3cb28551c".
2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_SSL" is "false".
2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_URL" is
"jdbc:postgresql://localhost:5432/engine".
2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_USER" is "engine".
2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DEBUG_ADDRESS" is "".
2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_FQDN" is "engine.startn.com".
2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_GROUP" is "ovirt".
2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MAX" is "1g".
2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MIN" is "1g".
2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_ENABLED" is "false".
2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PORT" is "8701".
2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_ENABLED" is "false".
2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_PORT" is "8700".
2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MAX" is "256m".
2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MIN" is "256m".
2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROPERTIES" is "".
2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_ENABLED" is "true".
2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_INTERVAL" is "1".
2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_TIME" is "10".
2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USER" is "ovirt".
2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VERBOSE_GC" is "false".
2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
2013-05-04 12:15:19,904 ERROR [org.ovirt.engine.core.domains.ManageDomains]
No LDAP servers can be obtained for domain authen.startn.com
2013-05-04 12:18:46,015 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
2013-05-04 12:18:46,017 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf".
2013-05-04 12:18:46,017 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
2013-05-04 12:18:46,018 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
2013-05-04 12:18:46,021 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
2013-05-04 12:18:46,022 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_ENABLED" is "true".
2013-05-04 12:18:46,022 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_PORT" is "8702".
2013-05-04 12:18:46,022 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_APPS" is "engine.ear".
2013-05-04 12:18:46,022 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
2013-05-04 12:18:46,022 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
2013-05-04 12:18:46,022 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_PASSWORD" is
"28b00f35c5f550e36c5fd1b3cb28551c".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_SSL" is "false".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_URL" is
"jdbc:postgresql://localhost:5432/engine".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_USER" is "engine".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DEBUG_ADDRESS" is "".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_FQDN" is "engine.startn.com".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_GROUP" is "ovirt".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MAX" is "1g".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MIN" is "1g".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_ENABLED" is "false".
2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PORT" is "8701".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_ENABLED" is "false".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_PORT" is "8700".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MAX" is "256m".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MIN" is "256m".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROPERTIES" is "".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_ENABLED" is "true".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_INTERVAL" is "1".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_TIME" is "10".
2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
2013-05-04 12:18:46,025 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USER" is "ovirt".
2013-05-04 12:18:46,025 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
2013-05-04 12:18:46,025 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
2013-05-04 12:18:46,025 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VERBOSE_GC" is "false".
2013-05-04 12:18:46,025 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
2013-05-04 12:18:46,025 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
2013-05-04 12:18:52,391 ERROR [org.ovirt.engine.core.domains.ManageDomains]
No LDAP servers can be obtained for domain authen.startn.com
2013-05-04 12:19:14,503 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
2013-05-04 12:19:14,504 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf".
2013-05-04 12:19:14,505 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
2013-05-04 12:19:14,505 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
2013-05-04 12:19:14,506 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
2013-05-04 12:19:14,507 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_ENABLED" is "true".
2013-05-04 12:19:14,507 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_PORT" is "8702".
2013-05-04 12:19:14,507 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_APPS" is "engine.ear".
2013-05-04 12:19:14,507 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
2013-05-04 12:19:14,507 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_PASSWORD" is
"28b00f35c5f550e36c5fd1b3cb28551c".
2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_SSL" is "false".
2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_URL" is
"jdbc:postgresql://localhost:5432/engine".
2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_USER" is "engine".
2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DEBUG_ADDRESS" is "".
2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_FQDN" is "engine.startn.com".
2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_GROUP" is "ovirt".
2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MAX" is "1g".
2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MIN" is "1g".
2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_ENABLED" is "false".
2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PORT" is "8701".
2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_ENABLED" is "false".
2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_PORT" is "8700".
2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MAX" is "256m".
2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MIN" is "256m".
2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROPERTIES" is "".
2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_ENABLED" is "true".
2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_INTERVAL" is "1".
2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_TIME" is "10".
2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USER" is "ovirt".
2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VERBOSE_GC" is "false".
2013-05-04 12:19:14,512 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
2013-05-04 12:19:14,512 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
2013-05-04 12:19:20,852 ERROR [org.ovirt.engine.core.domains.ManageDomains]
No LDAP servers can be obtained for domain authen.startn.com
2013-05-04 12:20:48,088 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
2013-05-04 12:20:48,091 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf".
2013-05-04 12:20:48,093 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
2013-05-04 12:20:48,095 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
2013-05-04 12:20:48,097 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
2013-05-04 12:20:48,098 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_ENABLED" is "true".
2013-05-04 12:20:48,099 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_PORT" is "8702".
2013-05-04 12:20:48,099 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_APPS" is "engine.ear".
2013-05-04 12:20:48,099 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
2013-05-04 12:20:48,099 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
2013-05-04 12:20:48,099 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
2013-05-04 12:20:48,099 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
2013-05-04 12:20:48,100 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
2013-05-04 12:20:48,100 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
2013-05-04 12:20:48,100 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_PASSWORD" is
"28b00f35c5f550e36c5fd1b3cb28551c".
2013-05-04 12:20:48,100 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_SSL" is "false".
2013-05-04 12:20:48,101 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_URL" is
"jdbc:postgresql://localhost:5432/engine".
2013-05-04 12:20:48,101 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_USER" is "engine".
2013-05-04 12:20:48,102 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DEBUG_ADDRESS" is "".
2013-05-04 12:20:48,102 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
2013-05-04 12:20:48,102 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_FQDN" is "engine.startn.com".
2013-05-04 12:20:48,103 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_GROUP" is "ovirt".
2013-05-04 12:20:48,103 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MAX" is "1g".
2013-05-04 12:20:48,103 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MIN" is "1g".
2013-05-04 12:20:48,103 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_ENABLED" is "false".
2013-05-04 12:20:48,103 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PORT" is "8701".
2013-05-04 12:20:48,103 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
2013-05-04 12:20:48,104 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_ENABLED" is "false".
2013-05-04 12:20:48,104 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_PORT" is "8700".
2013-05-04 12:20:48,104 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
2013-05-04 12:20:48,104 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MAX" is "256m".
2013-05-04 12:20:48,104 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MIN" is "256m".
2013-05-04 12:20:48,104 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
2013-05-04 12:20:48,105 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROPERTIES" is "".
2013-05-04 12:20:48,105 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_ENABLED" is "true".
2013-05-04 12:20:48,105 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
2013-05-04 12:20:48,106 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
2013-05-04 12:20:48,106 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_INTERVAL" is "1".
2013-05-04 12:20:48,106 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_TIME" is "10".
2013-05-04 12:20:48,107 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
2013-05-04 12:20:48,107 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USER" is "ovirt".
2013-05-04 12:20:48,107 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
2013-05-04 12:20:48,108 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
2013-05-04 12:20:48,108 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VERBOSE_GC" is "false".
2013-05-04 12:20:48,108 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
2013-05-04 12:20:48,109 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
2013-05-04 12:21:28,086 ERROR [org.ovirt.engine.core.domains.ManageDomains]
No LDAP servers can be obtained for domain authen.startn.com
2013-05-04 12:22:55,261 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
2013-05-04 12:22:55,262 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf".
2013-05-04 12:22:55,263 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
2013-05-04 12:22:55,263 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
2013-05-04 12:22:55,264 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
2013-05-04 12:22:55,264 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_ENABLED" is "true".
2013-05-04 12:22:55,264 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_PORT" is "8702".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_APPS" is "engine.ear".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_PASSWORD" is
"28b00f35c5f550e36c5fd1b3cb28551c".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_SSL" is "false".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_URL" is
"jdbc:postgresql://localhost:5432/engine".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_USER" is "engine".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DEBUG_ADDRESS" is "".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_FQDN" is "engine.startn.com".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_GROUP" is "ovirt".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MAX" is "1g".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MIN" is "1g".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_ENABLED" is "false".
2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PORT" is "8701".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_ENABLED" is "false".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_PORT" is "8700".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MAX" is "256m".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MIN" is "256m".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROPERTIES" is "".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_ENABLED" is "true".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_INTERVAL" is "1".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_TIME" is "10".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USER" is "ovirt".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VERBOSE_GC" is "false".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
2013-05-04 12:23:01,655 ERROR [org.ovirt.engine.core.domains.ManageDomains]
No LDAP servers can be obtained for domain authen.startn.com
2013-05-04 12:26:30,138 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
2013-05-04 12:26:30,139 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf".
2013-05-04 12:26:30,140 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
2013-05-04 12:26:30,141 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
2013-05-04 12:26:30,142 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
2013-05-04 12:26:30,143 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_ENABLED" is "true".
2013-05-04 12:26:30,143 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_PORT" is "8702".
2013-05-04 12:26:30,143 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_APPS" is "engine.ear".
2013-05-04 12:26:30,144 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
2013-05-04 12:26:30,144 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
2013-05-04 12:26:30,144 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
2013-05-04 12:26:30,144 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
2013-05-04 12:26:30,144 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_PASSWORD" is
"28b00f35c5f550e36c5fd1b3cb28551c".
2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_SSL" is "false".
2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_URL" is
"jdbc:postgresql://localhost:5432/engine".
2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_USER" is "engine".
2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DEBUG_ADDRESS" is "".
2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_FQDN" is "engine.startn.com".
2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_GROUP" is "ovirt".
2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MAX" is "1g".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MIN" is "1g".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_ENABLED" is "false".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PORT" is "8701".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_ENABLED" is "false".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_PORT" is "8700".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MAX" is "256m".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MIN" is "256m".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROPERTIES" is "".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_ENABLED" is "true".
2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_INTERVAL" is "1".
2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_TIME" is "10".
2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USER" is "ovirt".
2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VERBOSE_GC" is "false".
2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
2013-05-04 12:26:36,792 ERROR [org.ovirt.engine.core.domains.ManageDomains]
No LDAP servers can be obtained for domain authen.startn.com
2013-05-04 12:29:03,597 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
2013-05-04 12:29:03,599 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf".
2013-05-04 12:29:03,600 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
2013-05-04 12:29:03,600 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
2013-05-04 12:29:03,601 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
2013-05-04 12:29:03,602 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_ENABLED" is "true".
2013-05-04 12:29:03,602 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_PORT" is "8702".
2013-05-04 12:29:03,602 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_APPS" is "engine.ear".
2013-05-04 12:29:03,602 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
2013-05-04 12:29:03,602 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
2013-05-04 12:29:03,602 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
2013-05-04 12:29:03,603 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
2013-05-04 12:29:03,603 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
2013-05-04 12:29:03,603 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
2013-05-04 12:29:03,603 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_PASSWORD" is
"28b00f35c5f550e36c5fd1b3cb28551c".
2013-05-04 12:29:03,603 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_SSL" is "false".
2013-05-04 12:29:03,603 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_URL" is
"jdbc:postgresql://localhost:5432/engine".
2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_USER" is "engine".
2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DEBUG_ADDRESS" is "".
2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_FQDN" is "engine.startn.com".
2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_GROUP" is "ovirt".
2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MAX" is "1g".
2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MIN" is "1g".
2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_ENABLED" is "false".
2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PORT" is "8701".
2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_ENABLED" is "false".
2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_PORT" is "8700".
2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MAX" is "256m".
2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MIN" is "256m".
2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROPERTIES" is "".
2013-05-04 12:29:03,606 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_ENABLED" is "true".
2013-05-04 12:29:03,606 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
2013-05-04 12:29:03,606 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
2013-05-04 12:29:03,606 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_INTERVAL" is "1".
2013-05-04 12:29:03,606 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_TIME" is "10".
2013-05-04 12:29:03,606 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
2013-05-04 12:29:03,607 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USER" is "ovirt".
2013-05-04 12:29:03,607 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
2013-05-04 12:29:03,607 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
2013-05-04 12:29:03,607 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VERBOSE_GC" is "false".
2013-05-04 12:29:03,607 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
2013-05-04 12:29:03,607 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
2013-05-04 12:29:10,148 ERROR [org.ovirt.engine.core.domains.ManageDomains]
No LDAP servers can be obtained for domain authen.startn.com
2013-05-04 12:33:33,832 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
2013-05-04 12:33:33,833 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf".
2013-05-04 12:33:33,833 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
2013-05-04 12:33:33,834 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
2013-05-04 12:33:33,835 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_ENABLED" is "true".
2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_PORT" is "8702".
2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_APPS" is "engine.ear".
2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_PASSWORD" is
"28b00f35c5f550e36c5fd1b3cb28551c".
2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_SSL" is "false".
2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_URL" is
"jdbc:postgresql://localhost:5432/engine".
2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_USER" is "engine".
2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DEBUG_ADDRESS" is "".
2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_FQDN" is "engine.startn.com".
2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_GROUP" is "ovirt".
2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MAX" is "1g".
2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MIN" is "1g".
2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_ENABLED" is "false".
2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PORT" is "8701".
2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_ENABLED" is "false".
2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_PORT" is "8700".
2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MAX" is "256m".
2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MIN" is "256m".
2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROPERTIES" is "".
2013-05-04 12:33:33,839 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_ENABLED" is "true".
2013-05-04 12:33:33,839 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_INTERVAL" is "1".
2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_TIME" is "10".
2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USER" is "ovirt".
2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VERBOSE_GC" is "false".
2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
2013-05-04 12:33:39,347 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
2013-05-04 12:33:39,348 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf".
2013-05-04 12:33:39,349 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
2013-05-04 12:33:39,350 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
2013-05-04 12:33:39,352 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
2013-05-04 12:33:39,352 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_ENABLED" is "true".
2013-05-04 12:33:39,352 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_PORT" is "8702".
2013-05-04 12:33:39,352 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_APPS" is "engine.ear".
2013-05-04 12:33:39,352 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_PASSWORD" is
"28b00f35c5f550e36c5fd1b3cb28551c".
2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_SSL" is "false".
2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_URL" is
"jdbc:postgresql://localhost:5432/engine".
2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_USER" is "engine".
2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DEBUG_ADDRESS" is "".
2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_FQDN" is "engine.startn.com".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_GROUP" is "ovirt".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MAX" is "1g".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MIN" is "1g".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_ENABLED" is "false".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PORT" is "8701".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_ENABLED" is "false".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_PORT" is "8700".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MAX" is "256m".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MIN" is "256m".
2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
2013-05-04 12:33:39,355 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROPERTIES" is "".
2013-05-04 12:33:39,355 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_ENABLED" is "true".
2013-05-04 12:33:39,355 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
2013-05-04 12:33:39,356 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
2013-05-04 12:33:39,356 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_INTERVAL" is "1".
2013-05-04 12:33:39,356 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_TIME" is "10".
2013-05-04 12:33:39,357 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
2013-05-04 12:33:39,357 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USER" is "ovirt".
2013-05-04 12:33:39,357 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
2013-05-04 12:33:39,357 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
2013-05-04 12:33:39,357 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VERBOSE_GC" is "false".
2013-05-04 12:33:39,358 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
2013-05-04 12:33:39,358 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
2013-05-04 12:33:45,853 ERROR [org.ovirt.engine.core.domains.ManageDomains]
No LDAP servers can be obtained for domain authen.startn.com
2013-05-04 12:40:54,140 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
2013-05-04 12:40:54,141 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf".
2013-05-04 12:40:54,142 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
2013-05-04 12:40:54,143 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
2013-05-04 12:40:54,145 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
2013-05-04 12:40:54,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_ENABLED" is "true".
2013-05-04 12:40:54,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_AJP_PORT" is "8702".
2013-05-04 12:40:54,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_APPS" is "engine.ear".
2013-05-04 12:40:54,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
2013-05-04 12:40:54,146 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
2013-05-04 12:40:54,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
2013-05-04 12:40:54,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
2013-05-04 12:40:54,147 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
2013-05-04 12:40:54,148 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
2013-05-04 12:40:54,148 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_PASSWORD" is
"28b00f35c5f550e36c5fd1b3cb28551c".
2013-05-04 12:40:54,148 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_SSL" is "false".
2013-05-04 12:40:54,148 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_URL" is
"jdbc:postgresql://localhost:5432/engine".
2013-05-04 12:40:54,149 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DB_USER" is "engine".
2013-05-04 12:40:54,149 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_DEBUG_ADDRESS" is "".
2013-05-04 12:40:54,149 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
2013-05-04 12:40:54,149 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_FQDN" is "engine.startn.com".
2013-05-04 12:40:54,150 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_GROUP" is "ovirt".
2013-05-04 12:40:54,150 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MAX" is "1g".
2013-05-04 12:40:54,150 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HEAP_MIN" is "1g".
2013-05-04 12:40:54,150 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_ENABLED" is "false".
2013-05-04 12:40:54,151 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PORT" is "8701".
2013-05-04 12:40:54,151 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
2013-05-04 12:40:54,151 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_ENABLED" is "false".
2013-05-04 12:40:54,151 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_HTTP_PORT" is "8700".
2013-05-04 12:40:54,152 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
2013-05-04 12:40:54,152 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MAX" is "256m".
2013-05-04 12:40:54,152 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PERM_MIN" is "256m".
2013-05-04 12:40:54,152 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
2013-05-04 12:40:54,153 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROPERTIES" is "".
2013-05-04 12:40:54,153 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_ENABLED" is "true".
2013-05-04 12:40:54,153 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
2013-05-04 12:40:54,153 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
2013-05-04 12:40:54,154 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_INTERVAL" is "1".
2013-05-04 12:40:54,154 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_STOP_TIME" is "10".
2013-05-04 12:40:54,154 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
2013-05-04 12:40:54,154 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USER" is "ovirt".
2013-05-04 12:40:54,155 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
2013-05-04 12:40:54,155 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
2013-05-04 12:40:54,155 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "ENGINE_VERBOSE_GC" is "false".
2013-05-04 12:40:54,155 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
2013-05-04 12:40:54,156 INFO  [org.ovirt.engine.core.utils.LocalConfig]
Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
2013-05-04 12:41:01,000 ERROR [org.ovirt.engine.core.domains.ManageDomains]
No LDAP servers can be obtained for domain authen.startn.com

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

From mperina at redhat.com  Sat May  4 05:13:44 2013
From: mperina at redhat.com (Martin Perina)
Date: Sat, 4 May 2013 01:13:44 -0400 (EDT)
Subject: [Engine-devel] Device custom properties
In-Reply-To: <769095690.6355567.1367571965290.JavaMail.root@redhat.com>
References: <769095690.6355567.1367571965290.JavaMail.root@redhat.com>
Message-ID: <647348214.6813403.1367644424985.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Martin Perina" <mperina at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Friday, May 3, 2013 11:06:05 AM
> Subject: [Engine-devel] Device custom properties
> 
> Hi,
>  
> I'm currently trying to implement device custom properties infrastructure in
> ovirt-engine.
> During discussion with Yair, we found out, that it's not clear, for what type
> of devices
> custom properties should be available? In engine we have the VmDeviceType
> enum which
> contains following values:
>  
>      FLOPPY("floppy", "14"),
>      DISK("disk", "17"),
>      CDROM("cdrom", "15"),
>      INTERFACE("interface", "10"),
>      BRIDGE("bridge", "3"),
>      VIDEO("video", "20"),
>      USB("usb", "23"),
>      CONTROLLER("controller", "23"),
>      REDIR("redir", "23"),
>      SPICEVMC("spicevmc", "23"),
>      QXL("qxl"),
>      CIRRUS("cirrus"),
>      SOUND("sound"),
>      ICH6("ich6"),
>      AC97("ac97"),
>      MEMBALLOON("memballoon"),
>      SMARTCARD("smartcard"),
>      BALLOON("balloon"),
>      OTHER("other", "0"),
>      UNKNOWN("unknown", "-1");
>  
> But VmDevice class has two String attributes device and type. So for example
> a disk is a device
> which has device set to disk and type set to disk (according to
> VmDeviceCommonUtils.isDisk method).
>  
> So my question is, if I have a custom properties for disk, will they be
> available for all disk
> devices (disk, cdrom, floppy, ...) or only for real disk? So should we
> support custom properties
> for all VmDeviceType enum value separately?
> 
> Thanks for suggestions
> 
> Martin



I've looked at VDSM code, here are device type even more detailed (please correct me if I'm wrong):

DEVICE         TYPE
'disk'         'disk', 'cdrom', 'floppy'
'interface'    'bridge'
'video'        'cirrus', 'std', 'vmware', 'qxl', 'none'
'sound'        'ac97', 'pcspk', 'sb16', 'es1370', 'hda', 'ich6'
'controller'   'ide', 'fdc', 'scsi', 'sata', 'usb', 'ccid', 'virtio-serial'
'balloon'      'memballoon'
'channel'      'unix', 'spicevmc', 'virtio-serial'
'console'      'console'
'smartcard'    'smartcard'
'watchdog'     'watchdog'

So I suggest to refactor engine device type to match VDSM side and engine will support device
custom properties to be set for these devices types:

'disk', 'interface', 'video', 'sound', 'controller', 'balloon', 'channel', 'console', 'smartcard', 'watchdog'

Is it ok?


Martin




From liuyang3240 at gmail.com  Sat May  4 06:18:39 2013
From: liuyang3240 at gmail.com (Kevein Liu)
Date: Sat, 4 May 2013 14:18:39 +0800
Subject: [Engine-devel] engine-manage-domains add domain(RHDS) ERROR
In-Reply-To: <CAH=UCn4JJAuqD7LM4L2m8UgxysqayUdUwS=0q-nrPHp+ztAk8g@mail.gmail.com>
References: <CAH=UCn4JJAuqD7LM4L2m8UgxysqayUdUwS=0q-nrPHp+ztAk8g@mail.gmail.com>
Message-ID: <FECCF0AC-D611-4D3B-AC2C-592664BCC85C@gmail.com>

Do you have SRV record in your DNS server?

Sent from my iPhone

? 2013-5-4?12:48??? <liqiang.net at gmail.com> ???

> 
> HI?All 
> 
> COMMAND:
> engine-manage-domains -action=add -domain='authen.startn.com' -provider='RHDS' -user='admin' -interactive        
> No LDAP servers can be obtained for domain authen.startn.com
> 
> My redhat dir serv is 9.0 and OS:fedora 18.
> 
> 
> ========================
> dig authen.startn.com
> 
> authen.startn.com.      86400   IN      A       10.0.10.182
> 
> startn.com.             86400   IN      NS      engine.startn.com.
> 
> engine.startn.com.      86400   IN      A       10.0.10.181
> 
> ;; Query time: 0 msec
> ;; SERVER: 10.0.10.181#53(10.0.10.181)
> ;; WHEN: Sat May  4 12:46:27 2013
> ;; MSG SIZE  rcvd: 99
> 
> /var/log/ovirt-engine/engine-manage-domains.log
> =================================
> 2013-05-04 12:15:13,523 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
> 2013-05-04 12:15:13,524 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf".
> 2013-05-04 12:15:13,525 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
> 2013-05-04 12:15:13,525 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
> 2013-05-04 12:15:13,526 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
> 2013-05-04 12:15:13,527 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_ENABLED" is "true".
> 2013-05-04 12:15:13,527 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_PORT" is "8702".
> 2013-05-04 12:15:13,527 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_APPS" is "engine.ear".
> 2013-05-04 12:15:13,527 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
> 2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
> 2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
> 2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
> 2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
> 2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
> 2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_PASSWORD" is "28b00f35c5f550e36c5fd1b3cb28551c".
> 2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_SSL" is "false".
> 2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_URL" is "jdbc:postgresql://localhost:5432/engine".
> 2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_USER" is "engine".
> 2013-05-04 12:15:13,528 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DEBUG_ADDRESS" is "".
> 2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
> 2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_FQDN" is "engine.startn.com".
> 2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_GROUP" is "ovirt".
> 2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MAX" is "1g".
> 2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MIN" is "1g".
> 2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_ENABLED" is "false".
> 2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PORT" is "8701".
> 2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
> 2013-05-04 12:15:13,529 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_ENABLED" is "false".
> 2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_PORT" is "8700".
> 2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
> 2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MAX" is "256m".
> 2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MIN" is "256m".
> 2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
> 2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROPERTIES" is "".
> 2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_ENABLED" is "true".
> 2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
> 2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
> 2013-05-04 12:15:13,530 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_INTERVAL" is "1".
> 2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_TIME" is "10".
> 2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
> 2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USER" is "ovirt".
> 2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
> 2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
> 2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VERBOSE_GC" is "false".
> 2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
> 2013-05-04 12:15:13,531 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
> 2013-05-04 12:15:19,904 ERROR [org.ovirt.engine.core.domains.ManageDomains] No LDAP servers can be obtained for domain authen.startn.com
> 2013-05-04 12:18:46,015 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
> 2013-05-04 12:18:46,017 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf".
> 2013-05-04 12:18:46,017 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
> 2013-05-04 12:18:46,018 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
> 2013-05-04 12:18:46,021 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
> 2013-05-04 12:18:46,022 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_ENABLED" is "true".
> 2013-05-04 12:18:46,022 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_PORT" is "8702".
> 2013-05-04 12:18:46,022 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_APPS" is "engine.ear".
> 2013-05-04 12:18:46,022 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
> 2013-05-04 12:18:46,022 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
> 2013-05-04 12:18:46,022 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_PASSWORD" is "28b00f35c5f550e36c5fd1b3cb28551c".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_SSL" is "false".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_URL" is "jdbc:postgresql://localhost:5432/engine".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_USER" is "engine".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DEBUG_ADDRESS" is "".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_FQDN" is "engine.startn.com".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_GROUP" is "ovirt".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MAX" is "1g".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MIN" is "1g".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_ENABLED" is "false".
> 2013-05-04 12:18:46,023 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PORT" is "8701".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_ENABLED" is "false".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_PORT" is "8700".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MAX" is "256m".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MIN" is "256m".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROPERTIES" is "".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_ENABLED" is "true".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_INTERVAL" is "1".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_TIME" is "10".
> 2013-05-04 12:18:46,024 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
> 2013-05-04 12:18:46,025 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USER" is "ovirt".
> 2013-05-04 12:18:46,025 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
> 2013-05-04 12:18:46,025 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
> 2013-05-04 12:18:46,025 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VERBOSE_GC" is "false".
> 2013-05-04 12:18:46,025 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
> 2013-05-04 12:18:46,025 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
> 2013-05-04 12:18:52,391 ERROR [org.ovirt.engine.core.domains.ManageDomains] No LDAP servers can be obtained for domain authen.startn.com
> 2013-05-04 12:19:14,503 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
> 2013-05-04 12:19:14,504 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf".
> 2013-05-04 12:19:14,505 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
> 2013-05-04 12:19:14,505 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
> 2013-05-04 12:19:14,506 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
> 2013-05-04 12:19:14,507 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_ENABLED" is "true".
> 2013-05-04 12:19:14,507 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_PORT" is "8702".
> 2013-05-04 12:19:14,507 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_APPS" is "engine.ear".
> 2013-05-04 12:19:14,507 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
> 2013-05-04 12:19:14,507 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
> 2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
> 2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
> 2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
> 2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
> 2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_PASSWORD" is "28b00f35c5f550e36c5fd1b3cb28551c".
> 2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_SSL" is "false".
> 2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_URL" is "jdbc:postgresql://localhost:5432/engine".
> 2013-05-04 12:19:14,508 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_USER" is "engine".
> 2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DEBUG_ADDRESS" is "".
> 2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
> 2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_FQDN" is "engine.startn.com".
> 2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_GROUP" is "ovirt".
> 2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MAX" is "1g".
> 2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MIN" is "1g".
> 2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_ENABLED" is "false".
> 2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PORT" is "8701".
> 2013-05-04 12:19:14,509 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
> 2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_ENABLED" is "false".
> 2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_PORT" is "8700".
> 2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
> 2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MAX" is "256m".
> 2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MIN" is "256m".
> 2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
> 2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROPERTIES" is "".
> 2013-05-04 12:19:14,510 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_ENABLED" is "true".
> 2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
> 2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
> 2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_INTERVAL" is "1".
> 2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_TIME" is "10".
> 2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
> 2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USER" is "ovirt".
> 2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
> 2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
> 2013-05-04 12:19:14,511 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VERBOSE_GC" is "false".
> 2013-05-04 12:19:14,512 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
> 2013-05-04 12:19:14,512 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
> 2013-05-04 12:19:20,852 ERROR [org.ovirt.engine.core.domains.ManageDomains] No LDAP servers can be obtained for domain authen.startn.com
> 2013-05-04 12:20:48,088 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
> 2013-05-04 12:20:48,091 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf".
> 2013-05-04 12:20:48,093 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
> 2013-05-04 12:20:48,095 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
> 2013-05-04 12:20:48,097 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
> 2013-05-04 12:20:48,098 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_ENABLED" is "true".
> 2013-05-04 12:20:48,099 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_PORT" is "8702".
> 2013-05-04 12:20:48,099 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_APPS" is "engine.ear".
> 2013-05-04 12:20:48,099 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
> 2013-05-04 12:20:48,099 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
> 2013-05-04 12:20:48,099 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
> 2013-05-04 12:20:48,099 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
> 2013-05-04 12:20:48,100 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
> 2013-05-04 12:20:48,100 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
> 2013-05-04 12:20:48,100 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_PASSWORD" is "28b00f35c5f550e36c5fd1b3cb28551c".
> 2013-05-04 12:20:48,100 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_SSL" is "false".
> 2013-05-04 12:20:48,101 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_URL" is "jdbc:postgresql://localhost:5432/engine".
> 2013-05-04 12:20:48,101 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_USER" is "engine".
> 2013-05-04 12:20:48,102 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DEBUG_ADDRESS" is "".
> 2013-05-04 12:20:48,102 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
> 2013-05-04 12:20:48,102 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_FQDN" is "engine.startn.com".
> 2013-05-04 12:20:48,103 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_GROUP" is "ovirt".
> 2013-05-04 12:20:48,103 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MAX" is "1g".
> 2013-05-04 12:20:48,103 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MIN" is "1g".
> 2013-05-04 12:20:48,103 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_ENABLED" is "false".
> 2013-05-04 12:20:48,103 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PORT" is "8701".
> 2013-05-04 12:20:48,103 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
> 2013-05-04 12:20:48,104 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_ENABLED" is "false".
> 2013-05-04 12:20:48,104 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_PORT" is "8700".
> 2013-05-04 12:20:48,104 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
> 2013-05-04 12:20:48,104 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MAX" is "256m".
> 2013-05-04 12:20:48,104 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MIN" is "256m".
> 2013-05-04 12:20:48,104 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
> 2013-05-04 12:20:48,105 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROPERTIES" is "".
> 2013-05-04 12:20:48,105 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_ENABLED" is "true".
> 2013-05-04 12:20:48,105 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
> 2013-05-04 12:20:48,106 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
> 2013-05-04 12:20:48,106 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_INTERVAL" is "1".
> 2013-05-04 12:20:48,106 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_TIME" is "10".
> 2013-05-04 12:20:48,107 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
> 2013-05-04 12:20:48,107 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USER" is "ovirt".
> 2013-05-04 12:20:48,107 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
> 2013-05-04 12:20:48,108 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
> 2013-05-04 12:20:48,108 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VERBOSE_GC" is "false".
> 2013-05-04 12:20:48,108 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
> 2013-05-04 12:20:48,109 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
> 2013-05-04 12:21:28,086 ERROR [org.ovirt.engine.core.domains.ManageDomains] No LDAP servers can be obtained for domain authen.startn.com
> 2013-05-04 12:22:55,261 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
> 2013-05-04 12:22:55,262 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf".
> 2013-05-04 12:22:55,263 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
> 2013-05-04 12:22:55,263 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
> 2013-05-04 12:22:55,264 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
> 2013-05-04 12:22:55,264 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_ENABLED" is "true".
> 2013-05-04 12:22:55,264 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_PORT" is "8702".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_APPS" is "engine.ear".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_PASSWORD" is "28b00f35c5f550e36c5fd1b3cb28551c".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_SSL" is "false".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_URL" is "jdbc:postgresql://localhost:5432/engine".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_USER" is "engine".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DEBUG_ADDRESS" is "".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_FQDN" is "engine.startn.com".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_GROUP" is "ovirt".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MAX" is "1g".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MIN" is "1g".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_ENABLED" is "false".
> 2013-05-04 12:22:55,265 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PORT" is "8701".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_ENABLED" is "false".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_PORT" is "8700".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MAX" is "256m".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MIN" is "256m".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROPERTIES" is "".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_ENABLED" is "true".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_INTERVAL" is "1".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_TIME" is "10".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USER" is "ovirt".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VERBOSE_GC" is "false".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
> 2013-05-04 12:22:55,266 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
> 2013-05-04 12:23:01,655 ERROR [org.ovirt.engine.core.domains.ManageDomains] No LDAP servers can be obtained for domain authen.startn.com
> 2013-05-04 12:26:30,138 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
> 2013-05-04 12:26:30,139 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf".
> 2013-05-04 12:26:30,140 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
> 2013-05-04 12:26:30,141 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
> 2013-05-04 12:26:30,142 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
> 2013-05-04 12:26:30,143 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_ENABLED" is "true".
> 2013-05-04 12:26:30,143 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_PORT" is "8702".
> 2013-05-04 12:26:30,143 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_APPS" is "engine.ear".
> 2013-05-04 12:26:30,144 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
> 2013-05-04 12:26:30,144 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
> 2013-05-04 12:26:30,144 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
> 2013-05-04 12:26:30,144 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
> 2013-05-04 12:26:30,144 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
> 2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
> 2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_PASSWORD" is "28b00f35c5f550e36c5fd1b3cb28551c".
> 2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_SSL" is "false".
> 2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_URL" is "jdbc:postgresql://localhost:5432/engine".
> 2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_USER" is "engine".
> 2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DEBUG_ADDRESS" is "".
> 2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
> 2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_FQDN" is "engine.startn.com".
> 2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_GROUP" is "ovirt".
> 2013-05-04 12:26:30,145 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MAX" is "1g".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MIN" is "1g".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_ENABLED" is "false".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PORT" is "8701".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_ENABLED" is "false".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_PORT" is "8700".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MAX" is "256m".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MIN" is "256m".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROPERTIES" is "".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_ENABLED" is "true".
> 2013-05-04 12:26:30,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
> 2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
> 2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_INTERVAL" is "1".
> 2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_TIME" is "10".
> 2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
> 2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USER" is "ovirt".
> 2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
> 2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
> 2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VERBOSE_GC" is "false".
> 2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
> 2013-05-04 12:26:30,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
> 2013-05-04 12:26:36,792 ERROR [org.ovirt.engine.core.domains.ManageDomains] No LDAP servers can be obtained for domain authen.startn.com
> 2013-05-04 12:29:03,597 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
> 2013-05-04 12:29:03,599 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf".
> 2013-05-04 12:29:03,600 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
> 2013-05-04 12:29:03,600 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
> 2013-05-04 12:29:03,601 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
> 2013-05-04 12:29:03,602 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_ENABLED" is "true".
> 2013-05-04 12:29:03,602 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_PORT" is "8702".
> 2013-05-04 12:29:03,602 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_APPS" is "engine.ear".
> 2013-05-04 12:29:03,602 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
> 2013-05-04 12:29:03,602 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
> 2013-05-04 12:29:03,602 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
> 2013-05-04 12:29:03,603 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
> 2013-05-04 12:29:03,603 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
> 2013-05-04 12:29:03,603 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
> 2013-05-04 12:29:03,603 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_PASSWORD" is "28b00f35c5f550e36c5fd1b3cb28551c".
> 2013-05-04 12:29:03,603 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_SSL" is "false".
> 2013-05-04 12:29:03,603 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_URL" is "jdbc:postgresql://localhost:5432/engine".
> 2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_USER" is "engine".
> 2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DEBUG_ADDRESS" is "".
> 2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
> 2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_FQDN" is "engine.startn.com".
> 2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_GROUP" is "ovirt".
> 2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MAX" is "1g".
> 2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MIN" is "1g".
> 2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_ENABLED" is "false".
> 2013-05-04 12:29:03,604 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PORT" is "8701".
> 2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
> 2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_ENABLED" is "false".
> 2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_PORT" is "8700".
> 2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
> 2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MAX" is "256m".
> 2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MIN" is "256m".
> 2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
> 2013-05-04 12:29:03,605 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROPERTIES" is "".
> 2013-05-04 12:29:03,606 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_ENABLED" is "true".
> 2013-05-04 12:29:03,606 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
> 2013-05-04 12:29:03,606 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
> 2013-05-04 12:29:03,606 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_INTERVAL" is "1".
> 2013-05-04 12:29:03,606 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_TIME" is "10".
> 2013-05-04 12:29:03,606 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
> 2013-05-04 12:29:03,607 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USER" is "ovirt".
> 2013-05-04 12:29:03,607 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
> 2013-05-04 12:29:03,607 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
> 2013-05-04 12:29:03,607 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VERBOSE_GC" is "false".
> 2013-05-04 12:29:03,607 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
> 2013-05-04 12:29:03,607 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
> 2013-05-04 12:29:10,148 ERROR [org.ovirt.engine.core.domains.ManageDomains] No LDAP servers can be obtained for domain authen.startn.com
> 2013-05-04 12:33:33,832 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
> 2013-05-04 12:33:33,833 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf".
> 2013-05-04 12:33:33,833 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
> 2013-05-04 12:33:33,834 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
> 2013-05-04 12:33:33,835 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
> 2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_ENABLED" is "true".
> 2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_PORT" is "8702".
> 2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_APPS" is "engine.ear".
> 2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
> 2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
> 2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
> 2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
> 2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
> 2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
> 2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_PASSWORD" is "28b00f35c5f550e36c5fd1b3cb28551c".
> 2013-05-04 12:33:33,836 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_SSL" is "false".
> 2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_URL" is "jdbc:postgresql://localhost:5432/engine".
> 2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_USER" is "engine".
> 2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DEBUG_ADDRESS" is "".
> 2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
> 2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_FQDN" is "engine.startn.com".
> 2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_GROUP" is "ovirt".
> 2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MAX" is "1g".
> 2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MIN" is "1g".
> 2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_ENABLED" is "false".
> 2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PORT" is "8701".
> 2013-05-04 12:33:33,837 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
> 2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_ENABLED" is "false".
> 2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_PORT" is "8700".
> 2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
> 2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MAX" is "256m".
> 2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MIN" is "256m".
> 2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
> 2013-05-04 12:33:33,838 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROPERTIES" is "".
> 2013-05-04 12:33:33,839 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_ENABLED" is "true".
> 2013-05-04 12:33:33,839 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
> 2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
> 2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_INTERVAL" is "1".
> 2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_TIME" is "10".
> 2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
> 2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USER" is "ovirt".
> 2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
> 2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
> 2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VERBOSE_GC" is "false".
> 2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
> 2013-05-04 12:33:33,840 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
> 2013-05-04 12:33:39,347 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
> 2013-05-04 12:33:39,348 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf".
> 2013-05-04 12:33:39,349 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
> 2013-05-04 12:33:39,350 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
> 2013-05-04 12:33:39,352 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
> 2013-05-04 12:33:39,352 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_ENABLED" is "true".
> 2013-05-04 12:33:39,352 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_PORT" is "8702".
> 2013-05-04 12:33:39,352 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_APPS" is "engine.ear".
> 2013-05-04 12:33:39,352 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
> 2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
> 2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
> 2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
> 2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
> 2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
> 2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_PASSWORD" is "28b00f35c5f550e36c5fd1b3cb28551c".
> 2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_SSL" is "false".
> 2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_URL" is "jdbc:postgresql://localhost:5432/engine".
> 2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_USER" is "engine".
> 2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DEBUG_ADDRESS" is "".
> 2013-05-04 12:33:39,353 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_FQDN" is "engine.startn.com".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_GROUP" is "ovirt".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MAX" is "1g".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MIN" is "1g".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_ENABLED" is "false".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PORT" is "8701".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_ENABLED" is "false".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_PORT" is "8700".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MAX" is "256m".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MIN" is "256m".
> 2013-05-04 12:33:39,354 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
> 2013-05-04 12:33:39,355 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROPERTIES" is "".
> 2013-05-04 12:33:39,355 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_ENABLED" is "true".
> 2013-05-04 12:33:39,355 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
> 2013-05-04 12:33:39,356 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
> 2013-05-04 12:33:39,356 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_INTERVAL" is "1".
> 2013-05-04 12:33:39,356 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_TIME" is "10".
> 2013-05-04 12:33:39,357 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
> 2013-05-04 12:33:39,357 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USER" is "ovirt".
> 2013-05-04 12:33:39,357 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
> 2013-05-04 12:33:39,357 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
> 2013-05-04 12:33:39,357 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VERBOSE_GC" is "false".
> 2013-05-04 12:33:39,358 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
> 2013-05-04 12:33:39,358 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
> 2013-05-04 12:33:45,853 ERROR [org.ovirt.engine.core.domains.ManageDomains] No LDAP servers can be obtained for domain authen.startn.com
> 2013-05-04 12:40:54,140 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/usr/share/ovirt-engine/conf/engine.conf.defaults".
> 2013-05-04 12:40:54,141 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf".
> 2013-05-04 12:40:54,142 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-database.conf".
> 2013-05-04 12:40:54,143 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-java.conf".
> 2013-05-04 12:40:54,145 INFO  [org.ovirt.engine.core.utils.LocalConfig] Loaded file "/etc/ovirt-engine/engine.conf.d/50-setup-protocols.conf".
> 2013-05-04 12:40:54,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_ENABLED" is "true".
> 2013-05-04 12:40:54,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_AJP_PORT" is "8702".
> 2013-05-04 12:40:54,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_APPS" is "engine.ear".
> 2013-05-04 12:40:54,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_CACHE" is "/var/cache/ovirt-engine".
> 2013-05-04 12:40:54,146 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CHECK_INTERVAL" is "1000".
> 2013-05-04 12:40:54,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_CONNECTION_TIMEOUT" is "300000".
> 2013-05-04 12:40:54,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_DRIVER" is "org.postgresql.Driver".
> 2013-05-04 12:40:54,147 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MAX_CONNECTIONS" is "100".
> 2013-05-04 12:40:54,148 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_MIN_CONNECTIONS" is "1".
> 2013-05-04 12:40:54,148 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_PASSWORD" is "28b00f35c5f550e36c5fd1b3cb28551c".
> 2013-05-04 12:40:54,148 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_SSL" is "false".
> 2013-05-04 12:40:54,148 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_URL" is "jdbc:postgresql://localhost:5432/engine".
> 2013-05-04 12:40:54,149 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DB_USER" is "engine".
> 2013-05-04 12:40:54,149 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_DEBUG_ADDRESS" is "".
> 2013-05-04 12:40:54,149 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_ETC" is "/etc/ovirt-engine".
> 2013-05-04 12:40:54,149 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_FQDN" is "engine.startn.com".
> 2013-05-04 12:40:54,150 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_GROUP" is "ovirt".
> 2013-05-04 12:40:54,150 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MAX" is "1g".
> 2013-05-04 12:40:54,150 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HEAP_MIN" is "1g".
> 2013-05-04 12:40:54,150 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_ENABLED" is "false".
> 2013-05-04 12:40:54,151 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PORT" is "8701".
> 2013-05-04 12:40:54,151 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTPS_PROTOCOLS" is "SSLv3,TLSv1,TLSv1.1,TLSv1.2".
> 2013-05-04 12:40:54,151 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_ENABLED" is "false".
> 2013-05-04 12:40:54,151 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_HTTP_PORT" is "8700".
> 2013-05-04 12:40:54,152 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_LOG" is "/var/log/ovirt-engine".
> 2013-05-04 12:40:54,152 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MAX" is "256m".
> 2013-05-04 12:40:54,152 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PERM_MIN" is "256m".
> 2013-05-04 12:40:54,152 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PKI" is "/etc/pki/ovirt-engine".
> 2013-05-04 12:40:54,153 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROPERTIES" is "".
> 2013-05-04 12:40:54,153 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_ENABLED" is "true".
> 2013-05-04 12:40:54,153 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTPS_PORT" is "443".
> 2013-05-04 12:40:54,153 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_PROXY_HTTP_PORT" is "80".
> 2013-05-04 12:40:54,154 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_INTERVAL" is "1".
> 2013-05-04 12:40:54,154 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_STOP_TIME" is "10".
> 2013-05-04 12:40:54,154 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_TMP" is "/var/tmp/ovirt-engine".
> 2013-05-04 12:40:54,154 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USER" is "ovirt".
> 2013-05-04 12:40:54,155 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_USR" is "/usr/share/ovirt-engine".
> 2013-05-04 12:40:54,155 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VAR" is "/var/lib/ovirt-engine".
> 2013-05-04 12:40:54,155 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "ENGINE_VERBOSE_GC" is "false".
> 2013-05-04 12:40:54,155 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JAVA_HOME" is "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64".
> 2013-05-04 12:40:54,156 INFO  [org.ovirt.engine.core.utils.LocalConfig] Value of property "JBOSS_HOME" is "/usr/share/jboss-as".
> 2013-05-04 12:41:01,000 ERROR [org.ovirt.engine.core.domains.ManageDomains] No LDAP servers can be obtained for domain authen.startn.com
> 
> =================================
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130504/dcdf99f5/attachment.html>

From liqiang.net at gmail.com  Sat May  4 07:07:25 2013
From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=)
Date: Sat, 4 May 2013 15:07:25 +0800
Subject: [Engine-devel] engine-manage-domains add domain(RHDS) ERROR
In-Reply-To: <FECCF0AC-D611-4D3B-AC2C-592664BCC85C@gmail.com>
References: <CAH=UCn4JJAuqD7LM4L2m8UgxysqayUdUwS=0q-nrPHp+ztAk8g@mail.gmail.com>
	<FECCF0AC-D611-4D3B-AC2C-592664BCC85C@gmail.com>
Message-ID: <CAH=UCn4_N2iy9LXOz4_tD0-Lu7h5aU9=zdS8rgHJT4Rr_fPtRQ@mail.gmail.com>

[root at localhost ~]# host -t SRV _ldap._tcp.startn.com
_ldap._tcp.startn.com has SRV record 10 0 389 authen.startn.com.
[root at localhost ~]# dig authen.startn.com

; <<>> DiG 9.9.2-rl.028.23-P2-RedHat-9.9.2-10.P2.fc18 <<>> authen.startn.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39385
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;authen.startn.com.             IN      A

;; ANSWER SECTION:
authen.startn.com.      86400   IN      A       10.0.10.182

;; AUTHORITY SECTION:
startn.com.             86400   IN      NS      engine.startn.com.

;; ADDITIONAL SECTION:
engine.startn.com.      86400   IN      A       10.0.10.181

2013/5/4 Kevein Liu <liuyang3240 at gmail.com>

> you have SRV record in your DNS server?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130504/d7f1f72a/attachment.html>

From liqiang.net at gmail.com  Sat May  4 07:17:03 2013
From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=)
Date: Sat, 4 May 2013 15:17:03 +0800
Subject: [Engine-devel] engine-manage-domains add domain(RHDS) ERROR
In-Reply-To: <CAH=UCn4_N2iy9LXOz4_tD0-Lu7h5aU9=zdS8rgHJT4Rr_fPtRQ@mail.gmail.com>
References: <CAH=UCn4JJAuqD7LM4L2m8UgxysqayUdUwS=0q-nrPHp+ztAk8g@mail.gmail.com>
	<FECCF0AC-D611-4D3B-AC2C-592664BCC85C@gmail.com>
	<CAH=UCn4_N2iy9LXOz4_tD0-Lu7h5aU9=zdS8rgHJT4Rr_fPtRQ@mail.gmail.com>
Message-ID: <CAH=UCn4UC=v5QO3=O7GFa3-USZd8tUi=hM00eQzUt=qyS544vQ@mail.gmail.com>

I try this COMMAND:
[root at localhost ~]# engine-manage-domains -action=add -domain='startn.com'
-provider='RHDS' -user='admin' -interactive

AND ERROR:
No KDC can be obtained for domain startn.com

What do I ? next

=====================
Red Hat Dir Serv ports list:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State

tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN

tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN

tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN

tcp        0      0 0.0.0.0:9830            0.0.0.0:*               LISTEN

tcp        0      0 10.0.10.182:9830        10.0.10.182:35534
TIME_WAIT
tcp        0      0 10.0.10.182:9830        10.0.10.182:35539
TIME_WAIT
tcp        0      0 10.0.10.182:9830        10.0.10.182:35547
TIME_WAIT
tcp        0      0 10.0.10.182:9830        10.0.10.182:35538
TIME_WAIT
tcp        0      0 10.0.10.182:9830        10.0.10.182:35540
TIME_WAIT
tcp        0      0 10.0.10.182:34931       10.0.10.182:389
TIME_WAIT
tcp        0      0 10.0.10.182:34933       10.0.10.182:389
TIME_WAIT
tcp        0      0 10.0.10.182:34945       10.0.10.182:389
TIME_WAIT
tcp        0      0 10.0.10.182:22          10.0.10.1:32820
ESTABLISHED
tcp        0      0 10.0.10.182:9830        10.0.10.182:35544
TIME_WAIT
tcp        0      0 10.0.10.182:9830        10.0.10.182:35533
TIME_WAIT
tcp        0      0 10.0.10.182:9830        10.0.10.182:35550
TIME_WAIT
tcp        0      0 10.0.10.182:9830        10.0.10.182:35529
TIME_WAIT
tcp        0      0 10.0.10.182:34939       10.0.10.182:389
TIME_WAIT
tcp        0      0 10.0.10.182:9830        10.0.10.182:35546
TIME_WAIT
tcp        0     52 10.0.10.182:22          10.0.10.1:32735
ESTABLISHED
tcp        0      0 10.0.10.182:34932       10.0.10.182:389
TIME_WAIT
tcp6       0      0 :::111                  :::*                    LISTEN

tcp6       0      0 :::22                   :::*                    LISTEN

tcp6       0      0 ::1:631                 :::*                    LISTEN

tcp6       0      0 :::389                  :::*                    LISTEN

tcp6       0      0 10.0.10.182:389         10.0.10.182:34941
TIME_WAIT
tcp6       0      0 10.0.10.182:389         10.0.10.182:34927
TIME_WAIT
tcp6       0      0 10.0.10.182:389         10.0.10.182:34928
TIME_WAIT
tcp6       0      0 10.0.10.182:389         10.0.10.182:34926
TIME_WAIT
tcp6       0      0 10.0.10.182:34875       10.0.10.182:389
ESTABLISHED
tcp6       0      0 10.0.10.182:389         10.0.10.182:34874
ESTABLISHED
tcp6       0      0 10.0.10.182:389         10.0.10.182:34937
TIME_WAIT
tcp6       0      0 10.0.10.182:389         10.0.10.182:34944
TIME_WAIT
tcp6       0      0 10.0.10.182:389         10.0.10.182:34875
ESTABLISHED
tcp6       0      0 10.0.10.182:389         10.0.10.182:34938
TIME_WAIT
tcp6       0      0 10.0.10.182:34874       10.0.10.182:389
ESTABLISHED
udp        0      0 0.0.0.0:68              0.0.0.0:*

udp        0      0 0.0.0.0:111             0.0.0.0:*

udp        0      0 0.0.0.0:60545           0.0.0.0:*

udp        0      0 0.0.0.0:5353            0.0.0.0:*

udp        0      0 0.0.0.0:44540           0.0.0.0:*

udp        0      0 0.0.0.0:631             0.0.0.0:*

udp        0      0 0.0.0.0:727             0.0.0.0:*

udp6       0      0 :::111                  :::*

udp6       0      0 :::727                  :::*

udp6       0      0 :::18283                :::*




HI?All

?????

---
???????????
??

------------------------------------------------------------------------------


+ ????????????????(????1:1) +
------------------------------------------------------------------------------


2013/5/4 ?? <liqiang.net at gmail.com>

> [root at localhost ~]# host -t SRV _ldap._tcp.startn.com
> _ldap._tcp.startn.com has SRV record 10 0 389 authen.startn.com.
> [root at localhost ~]# dig authen.startn.com
>
> ; <<>> DiG 9.9.2-rl.028.23-P2-RedHat-9.9.2-10.P2.fc18 <<>>
> authen.startn.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39385
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;authen.startn.com.             IN      A
>
> ;; ANSWER SECTION:
> authen.startn.com.      86400   IN      A       10.0.10.182
>
> ;; AUTHORITY SECTION:
> startn.com.             86400   IN      NS      engine.startn.com.
>
> ;; ADDITIONAL SECTION:
> engine.startn.com.      86400   IN      A       10.0.10.181
>
> 2013/5/4 Kevein Liu <liuyang3240 at gmail.com>
>
>> you have SRV record in your DNS server?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130504/3ddbfb9a/attachment.html>

From liuyang3240 at gmail.com  Sat May  4 08:31:03 2013
From: liuyang3240 at gmail.com (Kevein Liu)
Date: Sat, 4 May 2013 16:31:03 +0800
Subject: [Engine-devel] engine-manage-domains add domain(RHDS) ERROR
In-Reply-To: <CAH=UCn4_N2iy9LXOz4_tD0-Lu7h5aU9=zdS8rgHJT4Rr_fPtRQ@mail.gmail.com>
References: <CAH=UCn4JJAuqD7LM4L2m8UgxysqayUdUwS=0q-nrPHp+ztAk8g@mail.gmail.com>
	<FECCF0AC-D611-4D3B-AC2C-592664BCC85C@gmail.com>
	<CAH=UCn4_N2iy9LXOz4_tD0-Lu7h5aU9=zdS8rgHJT4Rr_fPtRQ@mail.gmail.com>
Message-ID: <BB9D7B9E-F398-4AA5-929E-6BC4BDF9284F@gmail.com>

Try nslookup -type=SRV _ldap.....

I forget the exact command

Sent from my iPhone

? 2013-5-4?15:07??? <liqiang.net at gmail.com> ???

> [root at localhost ~]# host -t SRV _ldap._tcp.startn.com
> _ldap._tcp.startn.com has SRV record 10 0 389 authen.startn.com.
> [root at localhost ~]# dig authen.startn.com
> 
> ; <<>> DiG 9.9.2-rl.028.23-P2-RedHat-9.9.2-10.P2.fc18 <<>> authen.startn.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39385
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;authen.startn.com.             IN      A
> 
> ;; ANSWER SECTION:
> authen.startn.com.      86400   IN      A       10.0.10.182
> 
> ;; AUTHORITY SECTION:
> startn.com.             86400   IN      NS      engine.startn.com.
> 
> ;; ADDITIONAL SECTION:
> engine.startn.com.      86400   IN      A       10.0.10.181
> 
> 2013/5/4 Kevein Liu <liuyang3240 at gmail.com>
>> you have SRV record in your DNS server?
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130504/f310979e/attachment.html>

From liqiang.net at gmail.com  Sat May  4 09:13:19 2013
From: liqiang.net at gmail.com (=?GB2312?B?wO7Hvw==?=)
Date: Sat, 4 May 2013 17:13:19 +0800
Subject: [Engine-devel] engine-manage-domains add domain(RHDS) ERROR
In-Reply-To: <BB9D7B9E-F398-4AA5-929E-6BC4BDF9284F@gmail.com>
References: <CAH=UCn4JJAuqD7LM4L2m8UgxysqayUdUwS=0q-nrPHp+ztAk8g@mail.gmail.com>
	<FECCF0AC-D611-4D3B-AC2C-592664BCC85C@gmail.com>
	<CAH=UCn4_N2iy9LXOz4_tD0-Lu7h5aU9=zdS8rgHJT4Rr_fPtRQ@mail.gmail.com>
	<BB9D7B9E-F398-4AA5-929E-6BC4BDF9284F@gmail.com>
Message-ID: <CAH=UCn4RC-DZ-tTq28AeFu7z17=tM++4B9MXpzSEi-nPCx-Sww@mail.gmail.com>

SRV IS OK.
but why KDC error?
? 2013-5-4 ??4:31?"Kevein Liu" <liuyang3240 at gmail.com>???

> Try nslookup -type=SRV _ldap.....
>
> I forget the exact command
>
> Sent from my iPhone
>
> ? 2013-5-4?15:07??? <liqiang.net at gmail.com> ???
>
> [root at localhost ~]# host -t SRV _ldap._tcp.startn.com
> _ldap._tcp.startn.com has SRV record 10 0 389 authen.startn.com.
> [root at localhost ~]# dig authen.startn.com
>
> ; <<>> DiG 9.9.2-rl.028.23-P2-RedHat-9.9.2-10.P2.fc18 <<>>
> authen.startn.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39385
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;authen.startn.com.             IN      A
>
> ;; ANSWER SECTION:
> authen.startn.com.      86400   IN      A       10.0.10.182
>
> ;; AUTHORITY SECTION:
> startn.com.             86400   IN      NS      engine.startn.com.
>
> ;; ADDITIONAL SECTION:
> engine.startn.com.      86400   IN      A       10.0.10.181
>
> 2013/5/4 Kevein Liu <liuyang3240 at gmail.com>
>
>> you have SRV record in your DNS server?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130504/87ca9329/attachment.html>

From alonbl at redhat.com  Sat May  4 22:35:39 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sat, 4 May 2013 18:35:39 -0400 (EDT)
Subject: [Engine-devel] [Users] Fedora-18 installation within VM hungs
 during filesystem prepreations (Was: Unanble to start spice console._
In-Reply-To: <20130504151701.Horde.TbUcwZir309RhYjdqMZnquA@imap.linux.ibm.com>
References: <20130503111514.Horde.IujuZpir309Rg-6yEIm1j7A@imap.linux.ibm.com>
	<993594296.4024635.1367606160519.JavaMail.root@redhat.com>
	<1720702638.4036574.1367608119330.JavaMail.root@redhat.com>
	<20130503154418.Horde.On3__Jir309RhD3CXo-RxdA@imap.linux.ibm.com>
	<800370315.4100605.1367653114913.JavaMail.root@redhat.com>
	<20130504151701.Horde.TbUcwZir309RhYjdqMZnquA@imap.linux.ibm.com>
Message-ID: <1306754769.4117523.1367706939155.JavaMail.root@redhat.com>



----- Original Message -----
> From: snmishra at linux.vnet.ibm.com
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Sent: Sunday, May 5, 2013 1:17:01 AM
> Subject: Re: [Users] Unanble to start spice console.
> 
> Well, I had to stop firewalld, iptables and selinux on both, the
> engine and host, to get it to work. Now, I am able to launch spice
> console.

Hmmm... this is quite intrusive... I would like to know what was the root cause.
selinux - I don't believe.
Can you please send me your /var/log/messages so I can see what was blocked?

> BUT, I am back to square one (remember I moved to otopi because my VM
> installs were hanging) ... When I try to start F18 installation on
> newly created VMs, it gets stuck at either "Preparing to install" or
> goes little further and stops at "Creating ext4 on
> /dev/mapper/fedora-root"

So let me understand... you have up and running engine, you can deploy host and its status is active.
Now when you create a VM it succeeds.
Then you boot from ISO image.
And the during installation within the VM we have an issue.
My first question... Do you use nested virtualization? as I did see this in my setup when using qemu provided with fedora-18 to run nested.
If not, can you please also attach /var/log/messages, and I guess vdsm logs... I hope Michal can instruct which resources are required for this.

> 
> Attached is the engine log. I tried pausing the VM, so ignore the
> error messages about failing to pause VM in engine.log. I have now
> waited for almost an hour with no progress on install, so I am sure
> that it is not just slow.
> 
> Thanks for your help. We need more people like you Alon. You are the best !!

You are most welcome!

> 
> -Sharad
> 
> Quoting Alon Bar-Lev <alonbl at redhat.com>:
> 
> > This is interesting.
> > Can you please attach complete engine.log?
> > I will try to forward it to someone who can help.
> > Thanks!
> >
> > ----- Original Message -----
> >> From: snmishra at linux.vnet.ibm.com
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Sent: Saturday, May 4, 2013 1:44:18 AM
> >> Subject: Re: [Users] Unanble to start spice console.
> >>
> >> Alon,
> >>
> >>     I updated my build env with the latest and noticed that
> >> GetCACertificateQuery.java is in there. After rebuilding and runnnig
> >> setup again, I am still unable to open spice console. Now I do NOT see
> >> the error dialod complaining about status code 500. Now when the
> >> console is selected, there is no activity. Looks  like the action is
> >> getting ignored. But I do see the following error message -
> >>
> >>
> >> 2013-05-03 18:43:00,261 INFO
> >> [org.ovirt.engine.core.bll.SetVmTicketCommand] (http--0.0.0.0-8080-4)
> >> [52e747b9] Running command: SetVmTicketCommand internal: false.
> >> Entities affected :  ID: 3bc7cc8c-16b6-491d-af57-edfe1a85178e Type: VM
> >> 2013-05-03 18:43:00,265 INFO
> >> [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand]
> >> (http--0.0.0.0-8080-4) [52e747b9] START,
> >> SetVmTicketVDSCommand(HostName = host26, HostId =
> >> 54e1b3f0-7b17-47b1-9302-c63d69d408bf,
> >> vmId=3bc7cc8c-16b6-491d-af57-edfe1a85178e, ticket=F7ewJvuonZqq,
> >> validTime=120,m userName=admin at internal,
> >> userId=fdfc627c-d875-11e0-90f0-83df133b58cc), log id: 4078d750
> >> 2013-05-03 18:43:00,286 INFO
> >> [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand]
> >> (http--0.0.0.0-8080-4) [52e747b9] FINISH, SetVmTicketVDSCommand, log
> >> id: 4078d750
> >>
> >> -Sharad
> >>
> >> Quoting Alon Bar-Lev <alonbl at redhat.com>:
> >>
> >> > Should be available now at the otopi branch at github.
> >> >
> >> > Please keep in mind that this is forced push, so you probably need:
> >> >
> >> > $ git fetch origin
> >> > $ git checkout master
> >> > $ git branch -D otopi
> >> > $ git checkout otopi
> >> >
> >> > Check if included:
> >> >
> >> > $ find . -name GetCACertificateQuery.java
> >> >
> >> > ----- Original Message -----
> >> >> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >> >> To: snmishra at linux.vnet.ibm.com
> >> >> Cc: users at ovirt.org
> >> >> Sent: Friday, May 3, 2013 9:36:00 PM
> >> >> Subject: Re: [Users] Unanble to start spice console.
> >> >>
> >> >> This is my doing.
> >> >> I removed this class as I did not find any component that called it,
> >> >> apparently I have been mistaken.
> >> >> I guess you are you using the otopi development environment, right?
> >> >> Will be fixed in few moments.
> >> >>
> >> >> Thanks for the report!
> >> >>
> >> >>
> >> >> ----- Original Message -----
> >> >> > From: snmishra at linux.vnet.ibm.com
> >> >> > To: users at ovirt.org
> >> >> > Sent: Friday, May 3, 2013 9:15:14 PM
> >> >> > Subject: [Users] Unanble to start spice console.
> >> >> >
> >> >> >
> >> >> > After defining a new VM, hit 'Run Once' and chose to install F18 by
> >> >> > attaching an iso. The green arrow comes up next to the new  defined
> >> >> > VM. When I select to start the console, Error dialog pops up with
> >> >> > message -
> >> >> >
> >> >> > "Error while executing action: A Request to the Server failed with
> >> >> > the
> >> >> > following  Status Code: 500"
> >> >> >
> >> >> > Engine log has following to report -
> >> >> >
> >> >> > 013-05-03 14:08:32,363 INFO
> >> >> > [org.ovirt.engine.core.bll.SetVmTicketCommand] (http--0.0.0.0-8080-3)
> >> >> > [385b5ed5] Running command: SetVmTicketCommand internal: false.
> >> >> > Entities affected :  ID: cc00379f-5e70-4e62-85c2-a2a9f5a59dd3 Type:
> >> >> > VM
> >> >> > 2013-05-03 14:08:32,369 INFO
> >> >> > [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand]
> >> >> > (http--0.0.0.0-8080-3) [385b5ed5] START,
> >> >> > SetVmTicketVDSCommand(HostName = host26, HostId =
> >> >> > 54e1b3f0-7b17-47b1-9302-c63d69d408bf,
> >> >> > vmId=cc00379f-5e70-4e62-85c2-a2a9f5a59dd3, ticket=+Q4Hkz4CCAjI,
> >> >> > validTime=120,m userName=admin at internal,
> >> >> > userId=fdfc627c-d875-11e0-90f0-83df133b58cc), log id: 73e73b73
> >> >> > 2013-05-03 14:08:32,389 INFO
> >> >> > [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand]
> >> >> > (http--0.0.0.0-8080-3) [385b5ed5] FINISH, SetVmTicketVDSCommand, log
> >> >> > id: 73e73b73
> >> >> > 2013-05-03 14:08:32,452 WARN
> >> >> > [org.ovirt.engine.core.bll.CommandsFactory] (http--0.0.0.0-8080-3)
> >> >> > Unable to find class for action: GetCACertificateQuery
> >> >> >
> >> >> > Thanks
> >> >> > Sharad
> >> >> >
> >> >> > _______________________________________________
> >> >> > Users mailing list
> >> >> > Users at ovirt.org
> >> >> > http://lists.ovirt.org/mailman/listinfo/users
> >> >> >
> >> >> _______________________________________________
> >> >> Users mailing list
> >> >> Users at ovirt.org
> >> >> http://lists.ovirt.org/mailman/listinfo/users
> >> >>
> >>
> >>
> >>
> >>
> 
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: engine.log
Type: text/x-log
Size: 2862442 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130504/5ee4f311/attachment.bin>

From mpastern at redhat.com  Sun May  5 07:05:08 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 05 May 2013 10:05:08 +0300
Subject: [Engine-devel] =?gb2312?b?tPC4tDogtPC4tDogYWJvdXQgb3ZpcnQtZW5n?=
 =?gb2312?b?aW5lLXNkaw==?=
In-Reply-To: <5182D083.6040903@redhat.com>
References: <000f01ce46e0$490d4c70$db27e550$@com> <51820545.9060904@redhat.com>
	<001401ce470b$fd5547c0$f7ffd740$@com> <5182227A.9010609@redhat.com>
	<001501ce4715$dc801570$95804050$@com> <5182D083.6040903@redhat.com>
Message-ID: <518604A4.3040305@redhat.com>

On 05/02/2013 11:45 PM, Itamar Heim wrote:
> On 05/02/2013 12:17 PM, leaboy at 126 wrote:
>> Thinks, I just missing lxml.
>> When I installed lxml , it works well.
> 
> isn't it a dependency of the rpm?\

it is, this why i was wondering how sdk was installed.

> 
>>
>> -----????-----
>> ???: Michael Pasternak [mailto:mpastern at redhat.com]
>> ????: 2013?5?2? 16:23
>> ???: leaboy at 126
>> ??: engine-devel at ovirt.org
>> ??: Re: ??: about ovirt-engine-sdk
>>
>> On 05/02/2013 11:06 AM, leaboy at 126 wrote:
>>> The code I got in 2013-1-27 with git, I don't know which version I got,
>>> I didn't install it , I just use it like the example,
>>
>> you should be installing sdk in some way, cause just fetching it from the
>> git,
>> wasn't make it available in python,
>>
>> i suggest you installing official releases (unless you would like to develop
>> & contribute)
>> from pypi/easy_install.
>>
>>>
>>>   leaboy at leaboy:~/workspace/thtf-client$ python --version
>>>   Python 2.7.3
>>>   leaboy at leaboy:~/workspace/thtf-client$ python
>>>   Python 2.7.3 (default, Aug  1 2012, 05:16:07)
>>>   [GCC 4.6.3] on linux2
>>>   Type "help", "copyright", "credits" or "license" for more information.
>>>   
>>>   >>> from ovirtsdk.api import API
>>>   >>> from ovirtsdk.xml import params
>>>   >>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
>>> None, '~/.spicec/ca.crt', None, True)
>>>   >>>
>>>
>>> I use it successful in ubuntu 12.04 without any other operation,
>>> Just import the modules with python 2.7.3
>>>
>>> But when I use it in other OS, such as ubuntu 11, or embed linux for ARM,
>>> With python 2.6.*, It does't work,
>>
>> i just verified it on [1], not sure about embed linux, in any case to
>> make it work, lxml should be installed.
>>
>> [1]
>> python 2.6.6
>> python-lxml-2.2.3-1
>>
>>>
>>>
>>>
>>> -----????-----
>>> ???: Michael Pasternak [mailto:mpastern at redhat.com]
>>> ????: 2013?5?2? 14:19
>>> ???: leaboy at 126
>>> ??: engine-devel at ovirt.org
>>> ??: Re: about ovirt-engine-sdk
>>>
>>>
>>> Hi,
>>>
>>> On 05/02/2013 05:53 AM, leaboy at 126 wrote:
>>>> Hi,all
>>>>
>>>> How can I use overt-engine-sdk in the python environment below python2.7,
>>>>
>>>> For example, when I use it in python 2.6.5 like thus:
>>>
>>> what sdk version you're using?
>>> how did you installed it?
>>> what version of lxml you have installed?
>>>
>>>>
>>>>   
>>>>
>>>> percy at percy-desktop:~/thtf-client$ python --version
>>>>
>>>> Python 2.6.5
>>>>
>>>> percy at percy-desktop:~/thtf-client$ python
>>>>
>>>> Python 2.6.5 (r265:79063, Oct  1 2012, 22:04:36)
>>>>
>>>> [GCC 4.4.3] on linux2
>>>>
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>
>>>>>>> from ovirtsdk.api import API
>>>>
>>>>>>> from ovirtsdk.xml import params
>>>>
>>>>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
>>> None, '~/.spicec/ca.crt', None, None, True)
>>>>
>>>> *Traceback (most recent call last):*
>>>>
>>>> *  File "<stdin>", line 1, in <module>*
>>>>
>>>> *  File "ovirtsdk/api.py", line 107, in __init__*
>>>>
>>>> *    url='/api')*
>>>>
>>>> *  File "ovirtsdk/infrastructure/proxy.py", line 129, in request*
>>>>
>>>> *    last=last)*
>>>>
>>>> *  File "ovirtsdk/infrastructure/proxy.py", line 171, in __doRequest*
>>>>
>>>> *    return params.parseString(response_body) if response_body is not
>> None
>>> and response_body is not '' \*
>>>>
>>>> *  File "ovirtsdk/xml/params.py", line 21229, in parseString*
>>>>
>>>> *    rootObj.build(rootNode)*
>>>>
>>>> *  File "ovirtsdk/xml/params.py", line 20304, in build*
>>>>
>>>> *    self.buildAttributes(node, node.attrib, [])*
>>>>
>>>> *  File "ovirtsdk/xml/params.py", line 20309, in buildAttributes*
>>>>
>>>> *    super(API, self).buildAttributes(node, attrs, already_processed)*
>>>>
>>>> *  File "ovirtsdk/xml/params.py", line 4160, in buildAttributes*
>>>>
>>>> *    value = find_attr_value_('xsi:type', node)*
>>>>
>>>> *  File "ovirtsdk/xml/params.py", line 316, in find_attr_value_*
>>>>
>>>> *    namespace = node.nsmap.get(prefix)*
>>>>
>>>> *AttributeError: nsmap*
>>>>
>>>>>>>
>>>>
>>>>   
>>>>
>>>>   
>>>>
>>>> But, when I use it in python 2.7.3, it?s ok
>>>>
>>>>   
>>>>
>>>> leaboy at leaboy:~/workspace/thtf-client$ python --version
>>>>
>>>> Python 2.7.3
>>>>
>>>> leaboy at leaboy:~/workspace/thtf-client$ python
>>>>
>>>> Python 2.7.3 (default, Aug  1 2012, 05:16:07)
>>>>
>>>> [GCC 4.6.3] on linux2
>>>>
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>
>>>>>>> from ovirtsdk.api import API
>>>>
>>>>>>> from ovirtsdk.xml import params
>>>>
>>>>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
>>> None, '~/.spicec/ca.crt', None, True)
>>>>
>>>>>>>
>>>>
>>>
>>>
>>
>>
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From emesika at redhat.com  Sun May  5 07:13:59 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 5 May 2013 03:13:59 -0400 (EDT)
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <1026006636.3322172.1367433613876.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1238444147.4677106.1367414922363.JavaMail.root@redhat.com>
	<1016105867.4755820.1367422826733.JavaMail.root@redhat.com>
	<1143910845.3284067.1367423892389.JavaMail.root@redhat.com>
	<675589215.4826984.1367432004194.JavaMail.root@redhat.com>
	<1342664622.3315228.1367432213069.JavaMail.root@redhat.com>
	<51815F73.4030208@redhat.com>
	<1026006636.3322172.1367433613876.JavaMail.root@redhat.com>
Message-ID: <496044646.5979164.1367738039314.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Keith Robertson" <kroberts at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "pmatouse" <pmatouse at redhat.com>
> Sent: Wednesday, May 1, 2013 9:40:13 PM
> Subject: Re: [Engine-devel] Dropping encryption of database password
> 
> 
> 
> ----- Original Message -----
> > From: "Keith Robertson" <kroberts at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Josh Bressers" <bressers at redhat.com>, "Juan Hernandez"
> > <jhernand at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "pmatouse" <pmatouse at redhat.com>, "Sandro
> > Bonazzola" <sbonazzo at redhat.com>
> > Sent: Wednesday, May 1, 2013 9:31:15 PM
> > Subject: Re: [Engine-devel] Dropping encryption of database password
> > 
> > On 05/01/2013 02:16 PM, Alon Bar-Lev wrote:
> > > Thank you.
> > > This is what I wrote in my initial post.
> > > The only users who should access this password is ovirt user and root
> > > user.
> > >
> > > Regards,
> > > Alon Bar-Lev.
> > >
> > >> >
> > Alon,
> > I agree with the desire to store the PW in plaintext and in a
> > non-obfuscated manner.  In this case, obfuscation really doesn't gain
> > anything.
> > 
> > I would suggest; however, that the migration to plaintext be coordinated
> > with a simultaneous patch to the the Log Collector.  It does have a
> > dependency on the current architecture.
> > 
> > Keith
> > 
> 
> Hi,
> 
> As far as I know it reads the plain text from .pgpass, we need to modify it
> to search within the alternate format as well.

We are using the original .pgpass file that is in 0600 mode ( have access only to root) 
If the file does not have this mode , it is ignored by Postgres
I see no security issue in that ...

Please see details in
http://www.postgresql.org/docs/9.0/static/libpq-pgpass.html



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


From alonbl at redhat.com  Sun May  5 07:17:28 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 5 May 2013 03:17:28 -0400 (EDT)
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <496044646.5979164.1367738039314.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1016105867.4755820.1367422826733.JavaMail.root@redhat.com>
	<1143910845.3284067.1367423892389.JavaMail.root@redhat.com>
	<675589215.4826984.1367432004194.JavaMail.root@redhat.com>
	<1342664622.3315228.1367432213069.JavaMail.root@redhat.com>
	<51815F73.4030208@redhat.com>
	<1026006636.3322172.1367433613876.JavaMail.root@redhat.com>
	<496044646.5979164.1367738039314.JavaMail.root@redhat.com>
Message-ID: <429079641.4126769.1367738248389.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Keith Robertson" <kroberts at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>, "Juan Hernandez"
> <jhernand at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "pmatouse" <pmatouse at redhat.com>
> Sent: Sunday, May 5, 2013 10:13:59 AM
> Subject: Re: [Engine-devel] Dropping encryption of database password
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Keith Robertson" <kroberts at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "pmatouse" <pmatouse at redhat.com>
> > Sent: Wednesday, May 1, 2013 9:40:13 PM
> > Subject: Re: [Engine-devel] Dropping encryption of database password
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Keith Robertson" <kroberts at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Josh Bressers" <bressers at redhat.com>, "Juan Hernandez"
> > > <jhernand at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, "pmatouse" <pmatouse at redhat.com>, "Sandro
> > > Bonazzola" <sbonazzo at redhat.com>
> > > Sent: Wednesday, May 1, 2013 9:31:15 PM
> > > Subject: Re: [Engine-devel] Dropping encryption of database password
> > > 
> > > On 05/01/2013 02:16 PM, Alon Bar-Lev wrote:
> > > > Thank you.
> > > > This is what I wrote in my initial post.
> > > > The only users who should access this password is ovirt user and root
> > > > user.
> > > >
> > > > Regards,
> > > > Alon Bar-Lev.
> > > >
> > > >> >
> > > Alon,
> > > I agree with the desire to store the PW in plaintext and in a
> > > non-obfuscated manner.  In this case, obfuscation really doesn't gain
> > > anything.
> > > 
> > > I would suggest; however, that the migration to plaintext be coordinated
> > > with a simultaneous patch to the the Log Collector.  It does have a
> > > dependency on the current architecture.
> > > 
> > > Keith
> > > 
> > 
> > Hi,
> > 
> > As far as I know it reads the plain text from .pgpass, we need to modify it
> > to search within the alternate format as well.
> 
> We are using the original .pgpass file that is in 0600 mode ( have access
> only to root)
> If the file does not have this mode , it is ignored by Postgres
> I see no security issue in that ...
> 
> Please see details in
> http://www.postgresql.org/docs/9.0/static/libpq-pgpass.html

I am going to drop the .pgpass file in favor of other configuration file and produce .pgpass on will.
This is because:
1. The proprietary format of .pgpass is not friendly to parsing.
2. It does not hold the SSL setting.
3. It does not hold the SSL host validation setting.
4. It will be more difficult to modify user password.

This file is also 0600 owned by engine but in key=value format, so no change as far as security is concerned.

Thanks!
Alon.

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


From emesika at redhat.com  Sun May  5 07:18:07 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 5 May 2013 03:18:07 -0400 (EDT)
Subject: [Engine-devel] Device custom properties
In-Reply-To: <647348214.6813403.1367644424985.JavaMail.root@redhat.com>
References: <769095690.6355567.1367571965290.JavaMail.root@redhat.com>
	<647348214.6813403.1367644424985.JavaMail.root@redhat.com>
Message-ID: <630764624.5980238.1367738287648.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Martin Perina" <mperina at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Saturday, May 4, 2013 8:13:44 AM
> Subject: Re: [Engine-devel] Device custom properties
> 
> 
> 
> ----- Original Message -----
> > From: "Martin Perina" <mperina at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Friday, May 3, 2013 11:06:05 AM
> > Subject: [Engine-devel] Device custom properties
> > 
> > Hi,
> >  
> > I'm currently trying to implement device custom properties infrastructure
> > in
> > ovirt-engine.
> > During discussion with Yair, we found out, that it's not clear, for what
> > type
> > of devices
> > custom properties should be available? In engine we have the VmDeviceType
> > enum which
> > contains following values:
> >  
> >      FLOPPY("floppy", "14"),
> >      DISK("disk", "17"),
> >      CDROM("cdrom", "15"),
> >      INTERFACE("interface", "10"),
> >      BRIDGE("bridge", "3"),
> >      VIDEO("video", "20"),
> >      USB("usb", "23"),
> >      CONTROLLER("controller", "23"),
> >      REDIR("redir", "23"),
> >      SPICEVMC("spicevmc", "23"),
> >      QXL("qxl"),
> >      CIRRUS("cirrus"),
> >      SOUND("sound"),
> >      ICH6("ich6"),
> >      AC97("ac97"),
> >      MEMBALLOON("memballoon"),
> >      SMARTCARD("smartcard"),
> >      BALLOON("balloon"),
> >      OTHER("other", "0"),
> >      UNKNOWN("unknown", "-1");
> >  
> > But VmDevice class has two String attributes device and type. So for
> > example
> > a disk is a device
> > which has device set to disk and type set to disk (according to
> > VmDeviceCommonUtils.isDisk method).
> >  
> > So my question is, if I have a custom properties for disk, will they be
> > available for all disk
> > devices (disk, cdrom, floppy, ...) or only for real disk? So should we
> > support custom properties
> > for all VmDeviceType enum value separately?
> > 
> > Thanks for suggestions
> > 
> > Martin

The reason for that difference is that we had types in the backend code only for managed devices . (i.e. devoices that are known and handled by the backend)
Any other device as balloon etc. is considered as unmanaged device , that means that VDSM tells us that it exists and therefore tell us its type as well...



> 
> 
> 
> I've looked at VDSM code, here are device type even more detailed (please
> correct me if I'm wrong):
> 
> DEVICE         TYPE
> 'disk'         'disk', 'cdrom', 'floppy'
> 'interface'    'bridge'
> 'video'        'cirrus', 'std', 'vmware', 'qxl', 'none'
> 'sound'        'ac97', 'pcspk', 'sb16', 'es1370', 'hda', 'ich6'
> 'controller'   'ide', 'fdc', 'scsi', 'sata', 'usb', 'ccid', 'virtio-serial'
> 'balloon'      'memballoon'
> 'channel'      'unix', 'spicevmc', 'virtio-serial'
> 'console'      'console'
> 'smartcard'    'smartcard'
> 'watchdog'     'watchdog'
> 
> So I suggest to refactor engine device type to match VDSM side and engine
> will support device
> custom properties to be set for these devices types:
> 
> 'disk', 'interface', 'video', 'sound', 'controller', 'balloon', 'channel',
> 'console', 'smartcard', 'watchdog'
> 
> Is it ok?
> 
> 
> Martin
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From wei.d.chen at intel.com  Sun May  5 11:55:46 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Sun, 5 May 2013 11:55:46 +0000
Subject: [Engine-devel] ovirt engine and node cannot work when IP address
	changed
Message-ID: <C5A0092C63E939488005F15F736A811209C119CB@SHSMSX102.ccr.corp.intel.com>

Hi,

Our engine and node rebooted for some reason, IP address for these hosts has been changed as we configured IP address with DHCP, the result is engine and node cannot work anymore. Any way to let our ovirt environment work again without reinstallation, any feedback is great appreciated.  

Best Regards,
Dave Chen




From liqiang.net at gmail.com  Sun May  5 13:44:43 2013
From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=)
Date: Sun, 5 May 2013 21:44:43 +0800
Subject: [Engine-devel] engine-manage-domains add domain(RHDS) ERROR
In-Reply-To: <CAH=UCn4RC-DZ-tTq28AeFu7z17=tM++4B9MXpzSEi-nPCx-Sww@mail.gmail.com>
References: <CAH=UCn4JJAuqD7LM4L2m8UgxysqayUdUwS=0q-nrPHp+ztAk8g@mail.gmail.com>
	<FECCF0AC-D611-4D3B-AC2C-592664BCC85C@gmail.com>
	<CAH=UCn4_N2iy9LXOz4_tD0-Lu7h5aU9=zdS8rgHJT4Rr_fPtRQ@mail.gmail.com>
	<BB9D7B9E-F398-4AA5-929E-6BC4BDF9284F@gmail.com>
	<CAH=UCn4RC-DZ-tTq28AeFu7z17=tM++4B9MXpzSEi-nPCx-Sww@mail.gmail.com>
Message-ID: <CAH=UCn6G_kwkUKBL01nsFj-z6JoLQ9FmTp1DEQVEUrQWoFP0LQ@mail.gmail.com>

The Error IS OK?

The SRV info error and I Fixed it .

Thanks,
Thanks,


HI?All

?????

---
???????????
??

------------------------------------------------------------------------------


+ ????????????????(????1:1) +
------------------------------------------------------------------------------


2013/5/4 ?? <liqiang.net at gmail.com>

> SRV IS OK.
> but why KDC error?
> ? 2013-5-4 ??4:31?"Kevein Liu" <liuyang3240 at gmail.com>???
>
> Try nslookup -type=SRV _ldap.....
>>
>> I forget the exact command
>>
>> Sent from my iPhone
>>
>> ? 2013-5-4?15:07??? <liqiang.net at gmail.com> ???
>>
>> [root at localhost ~]# host -t SRV _ldap._tcp.startn.com
>> _ldap._tcp.startn.com has SRV record 10 0 389 authen.startn.com.
>> [root at localhost ~]# dig authen.startn.com
>>
>> ; <<>> DiG 9.9.2-rl.028.23-P2-RedHat-9.9.2-10.P2.fc18 <<>>
>> authen.startn.com
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39385
>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;authen.startn.com.             IN      A
>>
>> ;; ANSWER SECTION:
>> authen.startn.com.      86400   IN      A       10.0.10.182
>>
>> ;; AUTHORITY SECTION:
>> startn.com.             86400   IN      NS      engine.startn.com.
>>
>> ;; ADDITIONAL SECTION:
>> engine.startn.com.      86400   IN      A       10.0.10.181
>>
>> 2013/5/4 Kevein Liu <liuyang3240 at gmail.com>
>>
>>> you have SRV record in your DNS server?
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130505/77aa324f/attachment.html>

From emesika at redhat.com  Sun May  5 14:15:24 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 5 May 2013 10:15:24 -0400 (EDT)
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <429079641.4126769.1367738248389.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1143910845.3284067.1367423892389.JavaMail.root@redhat.com>
	<675589215.4826984.1367432004194.JavaMail.root@redhat.com>
	<1342664622.3315228.1367432213069.JavaMail.root@redhat.com>
	<51815F73.4030208@redhat.com>
	<1026006636.3322172.1367433613876.JavaMail.root@redhat.com>
	<496044646.5979164.1367738039314.JavaMail.root@redhat.com>
	<429079641.4126769.1367738248389.JavaMail.root@redhat.com>
Message-ID: <1505023092.6007817.1367763324912.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Keith Robertson" <kroberts at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>, "pmatouse" <pmatouse at redhat.com>
> Sent: Sunday, May 5, 2013 10:17:28 AM
> Subject: Re: [Engine-devel] Dropping encryption of database password
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Keith Robertson" <kroberts at redhat.com>, "Alon Bar-Lev"
> > <alonbl at redhat.com>, "Juan Hernandez"
> > <jhernand at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "pmatouse"
> > <pmatouse at redhat.com>
> > Sent: Sunday, May 5, 2013 10:13:59 AM
> > Subject: Re: [Engine-devel] Dropping encryption of database password
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "Keith Robertson" <kroberts at redhat.com>
> > > Cc: "Juan Hernandez" <jhernand at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, "pmatouse" <pmatouse at redhat.com>
> > > Sent: Wednesday, May 1, 2013 9:40:13 PM
> > > Subject: Re: [Engine-devel] Dropping encryption of database password
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Keith Robertson" <kroberts at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "Josh Bressers" <bressers at redhat.com>, "Juan Hernandez"
> > > > <jhernand at redhat.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>, "pmatouse" <pmatouse at redhat.com>, "Sandro
> > > > Bonazzola" <sbonazzo at redhat.com>
> > > > Sent: Wednesday, May 1, 2013 9:31:15 PM
> > > > Subject: Re: [Engine-devel] Dropping encryption of database password
> > > > 
> > > > On 05/01/2013 02:16 PM, Alon Bar-Lev wrote:
> > > > > Thank you.
> > > > > This is what I wrote in my initial post.
> > > > > The only users who should access this password is ovirt user and root
> > > > > user.
> > > > >
> > > > > Regards,
> > > > > Alon Bar-Lev.
> > > > >
> > > > >> >
> > > > Alon,
> > > > I agree with the desire to store the PW in plaintext and in a
> > > > non-obfuscated manner.  In this case, obfuscation really doesn't gain
> > > > anything.
> > > > 
> > > > I would suggest; however, that the migration to plaintext be
> > > > coordinated
> > > > with a simultaneous patch to the the Log Collector.  It does have a
> > > > dependency on the current architecture.
> > > > 
> > > > Keith
> > > > 
> > > 
> > > Hi,
> > > 
> > > As far as I know it reads the plain text from .pgpass, we need to modify
> > > it
> > > to search within the alternate format as well.
> > 
> > We are using the original .pgpass file that is in 0600 mode ( have access
> > only to root)
> > If the file does not have this mode , it is ignored by Postgres
> > I see no security issue in that ...
> > 
> > Please see details in
> > http://www.postgresql.org/docs/9.0/static/libpq-pgpass.html
> 
> I am going to drop the .pgpass file in favor of other configuration file and
> produce .pgpass on will.
> This is because:
> 1. The proprietary format of .pgpass is not friendly to parsing.
> 2. It does not hold the SSL setting.
> 3. It does not hold the SSL host validation setting.
> 4. It will be more difficult to modify user password.
> 
> This file is also 0600 owned by engine but in key=value format, so no change
> as far as security is concerned.

That's OK from my point ....

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


From liuyang3240 at gmail.com  Sun May  5 15:08:09 2013
From: liuyang3240 at gmail.com (Kevein Liu)
Date: Sun, 5 May 2013 23:08:09 +0800
Subject: [Engine-devel] engine-manage-domains add domain(RHDS) ERROR
In-Reply-To: <CAH=UCn6G_kwkUKBL01nsFj-z6JoLQ9FmTp1DEQVEUrQWoFP0LQ@mail.gmail.com>
References: <CAH=UCn4JJAuqD7LM4L2m8UgxysqayUdUwS=0q-nrPHp+ztAk8g@mail.gmail.com>
	<FECCF0AC-D611-4D3B-AC2C-592664BCC85C@gmail.com>
	<CAH=UCn4_N2iy9LXOz4_tD0-Lu7h5aU9=zdS8rgHJT4Rr_fPtRQ@mail.gmail.com>
	<BB9D7B9E-F398-4AA5-929E-6BC4BDF9284F@gmail.com>
	<CAH=UCn4RC-DZ-tTq28AeFu7z17=tM++4B9MXpzSEi-nPCx-Sww@mail.gmail.com>
	<CAH=UCn6G_kwkUKBL01nsFj-z6JoLQ9FmTp1DEQVEUrQWoFP0LQ@mail.gmail.com>
Message-ID: <CAE8191A-F54F-4296-83CD-A11AC9CD2C3F@gmail.com>

Great! :-)

Sent from my iPhone

? 2013-5-5?21:44??? <liqiang.net at gmail.com> ???

> The Error IS OK?
> 
> The SRV info error and I Fixed it .
> 
> Thanks,
> Thanks,
> 
> 
> HI?All 
> 
> ?????
> 
> ---
> ???????????
> ??
> 
> ------------------------------------------------------------------------------  
>                                        
> + ????????????????(????1:1) +
> ------------------------------------------------------------------------------
> 
> 
> 2013/5/4 ?? <liqiang.net at gmail.com>
>> SRV IS OK.
>> but why KDC error?
>> 
>> ? 2013-5-4 ??4:31?"Kevein Liu" <liuyang3240 at gmail.com>???
>> 
>>> Try nslookup -type=SRV _ldap.....
>>> 
>>> I forget the exact command
>>> 
>>> Sent from my iPhone
>>> 
>>> ? 2013-5-4?15:07??? <liqiang.net at gmail.com> ???
>>> 
>>>> [root at localhost ~]# host -t SRV _ldap._tcp.startn.com
>>>> _ldap._tcp.startn.com has SRV record 10 0 389 authen.startn.com.
>>>> [root at localhost ~]# dig authen.startn.com
>>>> 
>>>> ; <<>> DiG 9.9.2-rl.028.23-P2-RedHat-9.9.2-10.P2.fc18 <<>> authen.startn.com
>>>> ;; global options: +cmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39385
>>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>>>> 
>>>> ;; OPT PSEUDOSECTION:
>>>> ; EDNS: version: 0, flags:; udp: 4096
>>>> ;; QUESTION SECTION:
>>>> ;authen.startn.com.             IN      A
>>>> 
>>>> ;; ANSWER SECTION:
>>>> authen.startn.com.      86400   IN      A       10.0.10.182
>>>> 
>>>> ;; AUTHORITY SECTION:
>>>> startn.com.             86400   IN      NS      engine.startn.com.
>>>> 
>>>> ;; ADDITIONAL SECTION:
>>>> engine.startn.com.      86400   IN      A       10.0.10.181
>>>> 
>>>> 2013/5/4 Kevein Liu <liuyang3240 at gmail.com>
>>>>> you have SRV record in your DNS server?
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130505/d17732c0/attachment.html>

From thildred at redhat.com  Mon May  6 01:15:04 2013
From: thildred at redhat.com (Tim Hildred)
Date: Sun, 5 May 2013 21:15:04 -0400 (EDT)
Subject: [Engine-devel] ovirt engine and node cannot work when IP
 address	changed
In-Reply-To: <C5A0092C63E939488005F15F736A811209C119CB@SHSMSX102.ccr.corp.intel.com>
References: <C5A0092C63E939488005F15F736A811209C119CB@SHSMSX102.ccr.corp.intel.com>
Message-ID: <1669122542.19198090.1367802904067.JavaMail.root@redhat.com>

> Our engine and node rebooted for some reason, IP address for these hosts has
> been changed as we configured IP address with DHCP, the result is engine and
> node cannot work anymore.

Does that mean you added the hosts using their IP addresses, and not by FQDN?

And, a can you access the engine at all?

> Any way to let our ovirt environment work again
> without reinstallation, any feedback is great appreciated.

Tim Hildred, RHCE
Content Author II - Engineering Content Services, Red Hat, Inc.
Brisbane, Australia
Email: thildred at redhat.com
Internal: 8588287
Mobile: +61 4 666 25242
IRC: thildred

----- Original Message -----
> From: "Wei D Chen" <wei.d.chen at intel.com>
> To: engine-devel at ovirt.org
> Sent: Sunday, May 5, 2013 9:55:46 PM
> Subject: [Engine-devel] ovirt engine and node cannot work when IP address	changed
> 
> Hi,
> 

> 
> Best Regards,
> Dave Chen
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From wei.d.chen at intel.com  Mon May  6 03:06:21 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Mon, 6 May 2013 03:06:21 +0000
Subject: [Engine-devel] ovirt engine and node cannot work when IP
 address	changed
In-Reply-To: <1669122542.19198090.1367802904067.JavaMail.root@redhat.com>
References: <C5A0092C63E939488005F15F736A811209C119CB@SHSMSX102.ccr.corp.intel.com>
	<1669122542.19198090.1367802904067.JavaMail.root@redhat.com>
Message-ID: <C5A0092C63E939488005F15F736A811209C19A4F@SHSMSX102.ccr.corp.intel.com>

Thanks Tim.

In the popup window of adding a new host, I am required to input the name as well as address, name is the hostname includes domain name, address is the IP address of the host.

We can access engine web portal but storage is not work. As to nodes, the status is non-responsive. Any solution to fix this and recover our environment?


Best Regards,
Dave Chen


> -----Original Message-----
> From: Tim Hildred [mailto:thildred at redhat.com]
> Sent: Monday, May 06, 2013 9:15 AM
> To: Chen, Wei D
> Cc: engine-devel at ovirt.org
> Subject: Re: [Engine-devel] ovirt engine and node cannot work when IP address
> changed
> 
> > Our engine and node rebooted for some reason, IP address for these
> > hosts has been changed as we configured IP address with DHCP, the
> > result is engine and node cannot work anymore.
> 
> Does that mean you added the hosts using their IP addresses, and not by
> FQDN?
> 
> And, a can you access the engine at all?
> 
> > Any way to let our ovirt environment work again without
> > reinstallation, any feedback is great appreciated.
> 
> Tim Hildred, RHCE
> Content Author II - Engineering Content Services, Red Hat, Inc.
> Brisbane, Australia
> Email: thildred at redhat.com
> Internal: 8588287
> Mobile: +61 4 666 25242
> IRC: thildred
> 
> ----- Original Message -----
> > From: "Wei D Chen" <wei.d.chen at intel.com>
> > To: engine-devel at ovirt.org
> > Sent: Sunday, May 5, 2013 9:55:46 PM
> > Subject: [Engine-devel] ovirt engine and node cannot work when IP address
> 	changed
> >
> > Hi,
> >
> 
> >
> > Best Regards,
> > Dave Chen
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >

From thildred at redhat.com  Mon May  6 04:46:15 2013
From: thildred at redhat.com (Tim Hildred)
Date: Mon, 6 May 2013 00:46:15 -0400 (EDT)
Subject: [Engine-devel] ovirt engine and node cannot work when IP
 address	changed
In-Reply-To: <C5A0092C63E939488005F15F736A811209C19A4F@SHSMSX102.ccr.corp.intel.com>
References: <C5A0092C63E939488005F15F736A811209C119CB@SHSMSX102.ccr.corp.intel.com>
	<1669122542.19198090.1367802904067.JavaMail.root@redhat.com>
	<C5A0092C63E939488005F15F736A811209C19A4F@SHSMSX102.ccr.corp.intel.com>
Message-ID: <1452181192.19219630.1367815575662.JavaMail.root@redhat.com>

> In the popup window of adding a new host, I am required to input the name as
> well as address, name is the hostname includes domain name, address is the
> IP address of the host.

Name is just arbitrary value, so you can call it "Host1" for example. 

In the "Address field", you can put either an IP, or a FQDN. If you have DNS in your environment, it may be a good idea to use the FQDN instead of the IP address in the "Address" field. That way, you can just update your DNS with the new IP address of your host, and not have to worry about updating it in the engine. 

In any case, you can remove the hosts from the Hosts tab of the engine, and re-add them using the "New Host" button. You won't have to reinstall anything on the host side, the engine will take each host through all of the installations steps, which should be fast because all of the required packages are installed already. You'll need to put your hosts into maintenance mode before removing them. 
> 
> We can access engine web portal but storage is not work. As to nodes, the
> status is non-responsive. Any solution to fix this and recover our
> environment?

Sounds like the engine still works, and I guess you are accessing the web portal using its IP address. 

What are you trying to get working? 

Did you want to access your engine using something like engine.yournet.com? If so, you'll need some form of DNS for that as well. Like I said before, if you have DNS already, then you can just change the IP address that engine.yournet.com resolves to in your DNS. What did you answer when setup asked you to provide a FQDN for your engine (in /var/log/ovirt-engine/engine-setup-SETUPDATE if you can't remember) ?

If you don't have any DNS, then you won't be able to use hostnames to address your hosts and engine. In this case, DHCP is not the way to go. 

Tim Hildred, RHCE
Content Author II - Engineering Content Services, Red Hat, Inc.
Brisbane, Australia
Email: thildred at redhat.com
Internal: 8588287
Mobile: +61 4 666 25242
IRC: thildred

----- Original Message -----
> From: "Wei D Chen" <wei.d.chen at intel.com>
> To: "Tim Hildred" <thildred at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, May 6, 2013 1:06:21 PM
> Subject: RE: [Engine-devel] ovirt engine and node cannot work when IP address	changed
> 
> Thanks Tim.
> 
> In the popup window of adding a new host, I am required to input the name as
> well as address, name is the hostname includes domain name, address is the
> IP address of the host.
> 
> We can access engine web portal but storage is not work. As to nodes, the
> status is non-responsive. Any solution to fix this and recover our
> environment?
> 
> 
> Best Regards,
> Dave Chen
> 
> 
> > -----Original Message-----
> > From: Tim Hildred [mailto:thildred at redhat.com]
> > Sent: Monday, May 06, 2013 9:15 AM
> > To: Chen, Wei D
> > Cc: engine-devel at ovirt.org
> > Subject: Re: [Engine-devel] ovirt engine and node cannot work when IP
> > address
> > changed
> > 
> > > Our engine and node rebooted for some reason, IP address for these
> > > hosts has been changed as we configured IP address with DHCP, the
> > > result is engine and node cannot work anymore.
> > 
> > Does that mean you added the hosts using their IP addresses, and not by
> > FQDN?
> > 
> > And, a can you access the engine at all?
> > 
> > > Any way to let our ovirt environment work again without
> > > reinstallation, any feedback is great appreciated.
> > 
> > Tim Hildred, RHCE
> > Content Author II - Engineering Content Services, Red Hat, Inc.
> > Brisbane, Australia
> > Email: thildred at redhat.com
> > Internal: 8588287
> > Mobile: +61 4 666 25242
> > IRC: thildred
> > 
> > ----- Original Message -----
> > > From: "Wei D Chen" <wei.d.chen at intel.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Sunday, May 5, 2013 9:55:46 PM
> > > Subject: [Engine-devel] ovirt engine and node cannot work when IP address
> > 	changed
> > >
> > > Hi,
> > >
> > 
> > >
> > > Best Regards,
> > > Dave Chen
> > >
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> 


From mpastern at redhat.com  Mon May  6 06:46:31 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 06 May 2013 09:46:31 +0300
Subject: [Engine-devel] [REST-API] Support passing auth information without
 having to use HTTP Authorization header #958874
Message-ID: <518751C7.8090208@redhat.com>



https://bugzilla.redhat.com/show_bug.cgi?id=958874

Hi Alon,

(In reply to comment #2)
>
> Regardless of this specific RFE I would like to write that I don't like the
> REST API session mechanism
> [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as it
> relays on cookies and not explicit API interaction.

authentication in RESTful application is a matter of debate, it can be achieved
in various ways, but session + cookie auth. method is very common and usually effective,

it's biggest disadvantage is that it's not exactly RESfull cause client
have to maintain (story) the cookie and not the server (but i wouldn't call it an
issue at all), besides that it's works perfectly well from the REST PoV,

also some may say that cookies are not strong enough and OAuth for instance
should be used instead, but this is a different story cause in our case, cookie
are for the clients (not browsers [1]) that can store them in a secure way or even
not to store at all (in-memory cookie).

[1] another disadvantage is that webbrowsers not able to access cookie namespace,
but lately i've suggested URI based authentication [2] to support web browsers
as well.

[2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html

the biggest advantage of the cookie is a session expiration that maintained
by the server and abstracted from the client what is much better from security
PoV than standard authentication mechanisms such as HTTP basic auth for instance
which can be potentially cached.

> I would have expected a
> 'ticket' to be retrieved and that 'ticket' to be disconnected from the
> application server objects. Although we can refer the 'cookie' as a ticket,
> however the requirement to parse it should not be required, there be a
> conflict between two separate applications running on same server, and there
> may be a problem to transfer credentials between servers.

well, this is not exactly correct:

1. client desn't have to decode/parse the cookie and pass credentials, all it need is
   just to store the cookie and pass it as is to server on every request.

2. "conflict between two separate applications running on same server"? different cookie
   uses different domain & path by spec., can you pls explain what do you mean by this?

>
> If we modify authentication we should support more authentication types, at
> least SPNEGO.
>
> In order to allow SPNEGO and other authentication mechanisms, we better
> force people to use single URI to perform the login and return authenticated
> 'ticket' to continue interaction with application.

this is good for the backend authentication, but is not for the RESTful application,
it's like buying an aeroplane and driving it on a road,

"force people to use single URI to perform the login" means SOAP while we wanted REST
where any URI is considered as entry point and actually a resource address that should
be accessible/manipulatable and authentication should be abstracted/disconnected from
this concept.

SPNEGO is only an implementation detail that can be abstracted for the API.

> This will be much simpler
> implementation at the api side and much more efficient, and as we are
> discussion application-to-application interaction there should be no user
> experience visible issues.

i'm not sure: "force people to use single URI to perform the login" and no
"no user experience visible issues."?

>
> What I recommend is purely applicative rest login command...

IIUC this is SOAP and not REST ...

> ---
> Input: authentication type, authentication credentials
>     authentication=http
>     authentication=password
>     credentials:
>         user=user
>         password=password
>     [OPTIONALLY] HTTP authentication headers
> Output:
>     ticket
>     ticket issue time (required to avoid clock sync)
>     ticket expiration time
> Logic:
> if authentication is http, use http authentication headers to establish user
> authentication. This will allow future SSO.
> if authentication is password, use embedded credentials.
> ---
>
> For every other rest call add http header:
>     oVirt-Authentication-Ticket: <ticket>

this is not any different from the today's session based auth. only
instead of  oVirt-Authentication-Ticket added cookie.

>
> The backend side will attach the correct security context to the action if
> the header is received.

this is how it's works today.

>
> No need for the prefer mechanism nor multiple authentications. It should be
> easy for javascript implementation to perform the authentication via the
> designated URI, and then pass the ticket if not expired, when expired to
> perform re-authentication with or without involving the user.

again this is how it works today, and you not solving web browser problem as
when ticket expires, they cannot re-authenticate with new oVirt-Authentication-Ticket
cause this header is cached and cannot be changed by the browser in runtime.

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From wlbleaboy at 126.com  Mon May  6 09:18:48 2013
From: wlbleaboy at 126.com (leaboy@126)
Date: Mon, 6 May 2013 17:18:48 +0800
Subject: [Engine-devel] =?gb2312?b?tPC4tDogILTwuLQ6ILTwuLQ6IGFib3V0IG92?=
	=?gb2312?b?aXJ0LWVuZ2luZS1zZGs=?=
In-Reply-To: <518604A4.3040305@redhat.com>
References: <000f01ce46e0$490d4c70$db27e550$@com> <51820545.9060904@redhat.com>
	<001401ce470b$fd5547c0$f7ffd740$@com> <5182227A.9010609@redhat.com>
	<001501ce4715$dc801570$95804050$@com>
	<5182D083.6040903@redhat.com> <518604A4.3040305@redhat.com>
Message-ID: <000301ce4a3a$b9069ce0$2b13d6a0$@com>

If I used setup.py, I could find missing lxml, ^_^
Thinks!

-----????-----
???: Michael Pasternak [mailto:mpastern at redhat.com] 
????: 2013?5?5? 15:05
???: Itamar Heim
??: leaboy at 126; engine-devel at ovirt.org
??: Re: [Engine-devel] ??: ??: about ovirt-engine-sdk

On 05/02/2013 11:45 PM, Itamar Heim wrote:
> On 05/02/2013 12:17 PM, leaboy at 126 wrote:
>> Thinks, I just missing lxml.
>> When I installed lxml , it works well.
> 
> isn't it a dependency of the rpm?\

it is, this why i was wondering how sdk was installed.

> 
>>
>> -----????-----
>> ???: Michael Pasternak [mailto:mpastern at redhat.com]
>> ????: 2013?5?2? 16:23
>> ???: leaboy at 126
>> ??: engine-devel at ovirt.org
>> ??: Re: ??: about ovirt-engine-sdk
>>
>> On 05/02/2013 11:06 AM, leaboy at 126 wrote:
>>> The code I got in 2013-1-27 with git, I don't know which version I got,
>>> I didn't install it , I just use it like the example,
>>
>> you should be installing sdk in some way, cause just fetching it from the
>> git,
>> wasn't make it available in python,
>>
>> i suggest you installing official releases (unless you would like to
develop
>> & contribute)
>> from pypi/easy_install.
>>
>>>
>>>   leaboy at leaboy:~/workspace/thtf-client$ python --version
>>>   Python 2.7.3
>>>   leaboy at leaboy:~/workspace/thtf-client$ python
>>>   Python 2.7.3 (default, Aug  1 2012, 05:16:07)
>>>   [GCC 4.6.3] on linux2
>>>   Type "help", "copyright", "credits" or "license" for more information.
>>>   
>>>   >>> from ovirtsdk.api import API
>>>   >>> from ovirtsdk.xml import params
>>>   >>> api = API('http://192.168.1.181', 'admin at internal', '111111',
None,
>>> None, '~/.spicec/ca.crt', None, True)
>>>   >>>
>>>
>>> I use it successful in ubuntu 12.04 without any other operation,
>>> Just import the modules with python 2.7.3
>>>
>>> But when I use it in other OS, such as ubuntu 11, or embed linux for
ARM,
>>> With python 2.6.*, It does't work,
>>
>> i just verified it on [1], not sure about embed linux, in any case to
>> make it work, lxml should be installed.
>>
>> [1]
>> python 2.6.6
>> python-lxml-2.2.3-1
>>
>>>
>>>
>>>
>>> -----????-----
>>> ???: Michael Pasternak [mailto:mpastern at redhat.com]
>>> ????: 2013?5?2? 14:19
>>> ???: leaboy at 126
>>> ??: engine-devel at ovirt.org
>>> ??: Re: about ovirt-engine-sdk
>>>
>>>
>>> Hi,
>>>
>>> On 05/02/2013 05:53 AM, leaboy at 126 wrote:
>>>> Hi,all
>>>>
>>>> How can I use overt-engine-sdk in the python environment below python2.
7,
>>>>
>>>> For example, when I use it in python 2.6.5 like thus:
>>>
>>> what sdk version you're using?
>>> how did you installed it?
>>> what version of lxml you have installed?
>>>
>>>>
>>>>   
>>>>
>>>> percy at percy-desktop:~/thtf-client$ python --version
>>>>
>>>> Python 2.6.5
>>>>
>>>> percy at percy-desktop:~/thtf-client$ python
>>>>
>>>> Python 2.6.5 (r265:79063, Oct  1 2012, 22:04:36)
>>>>
>>>> [GCC 4.4.3] on linux2
>>>>
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>
>>>>>>> from ovirtsdk.api import API
>>>>
>>>>>>> from ovirtsdk.xml import params
>>>>
>>>>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
>>> None, '~/.spicec/ca.crt', None, None, True)
>>>>
>>>> *Traceback (most recent call last):*
>>>>
>>>> *  File "<stdin>", line 1, in <module>*
>>>>
>>>> *  File "ovirtsdk/api.py", line 107, in __init__*
>>>>
>>>> *    url='/api')*
>>>>
>>>> *  File "ovirtsdk/infrastructure/proxy.py", line 129, in request*
>>>>
>>>> *    last=last)*
>>>>
>>>> *  File "ovirtsdk/infrastructure/proxy.py", line 171, in __doRequest*
>>>>
>>>> *    return params.parseString(response_body) if response_body is not
>> None
>>> and response_body is not '' \*
>>>>
>>>> *  File "ovirtsdk/xml/params.py", line 21229, in parseString*
>>>>
>>>> *    rootObj.build(rootNode)*
>>>>
>>>> *  File "ovirtsdk/xml/params.py", line 20304, in build*
>>>>
>>>> *    self.buildAttributes(node, node.attrib, [])*
>>>>
>>>> *  File "ovirtsdk/xml/params.py", line 20309, in buildAttributes*
>>>>
>>>> *    super(API, self).buildAttributes(node, attrs, already_processed)*
>>>>
>>>> *  File "ovirtsdk/xml/params.py", line 4160, in buildAttributes*
>>>>
>>>> *    value = find_attr_value_('xsi:type', node)*
>>>>
>>>> *  File "ovirtsdk/xml/params.py", line 316, in find_attr_value_*
>>>>
>>>> *    namespace = node.nsmap.get(prefix)*
>>>>
>>>> *AttributeError: nsmap*
>>>>
>>>>>>>
>>>>
>>>>   
>>>>
>>>>   
>>>>
>>>> But, when I use it in python 2.7.3, it?s ok
>>>>
>>>>   
>>>>
>>>> leaboy at leaboy:~/workspace/thtf-client$ python --version
>>>>
>>>> Python 2.7.3
>>>>
>>>> leaboy at leaboy:~/workspace/thtf-client$ python
>>>>
>>>> Python 2.7.3 (default, Aug  1 2012, 05:16:07)
>>>>
>>>> [GCC 4.6.3] on linux2
>>>>
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>
>>>>>>> from ovirtsdk.api import API
>>>>
>>>>>>> from ovirtsdk.xml import params
>>>>
>>>>>>> api = API('http://192.168.1.181', 'admin at internal', '111111', None,
>>> None, '~/.spicec/ca.crt', None, True)
>>>>
>>>>>>>
>>>>
>>>
>>>
>>
>>
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D




From yzaslavs at redhat.com  Mon May  6 12:45:16 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 6 May 2013 08:45:16 -0400 (EDT)
Subject: [Engine-devel] findbugs filters
In-Reply-To: <675883447.6895386.1367843997256.JavaMail.root@redhat.com>
Message-ID: <1732271593.6898666.1367844316318.JavaMail.root@redhat.com>

Hi all,
Thanks to Allon Mureinik and others, I introduced to bll module the following -
exclude-filters.xml file - take a look and see how we can ignore some findbugs reports.

For example, I just reviewed a patch by Shahar,

http://gerrit.ovirt.org/#/c/14227/ which I currently disagree with - if my opinion is accepted - a possible solution can be to add exclude-filters.xml file to vdsbroker module as well.





From kroberts at redhat.com  Mon May  6 13:29:39 2013
From: kroberts at redhat.com (Keith Robertson)
Date: Mon, 06 May 2013 09:29:39 -0400
Subject: [Engine-devel] Dropping encryption of database password
In-Reply-To: <429079641.4126769.1367738248389.JavaMail.root@redhat.com>
References: <670062783.3118840.1367350880599.JavaMail.root@redhat.com>
	<1016105867.4755820.1367422826733.JavaMail.root@redhat.com>
	<1143910845.3284067.1367423892389.JavaMail.root@redhat.com>
	<675589215.4826984.1367432004194.JavaMail.root@redhat.com>
	<1342664622.3315228.1367432213069.JavaMail.root@redhat.com>
	<51815F73.4030208@redhat.com>
	<1026006636.3322172.1367433613876.JavaMail.root@redhat.com>
	<496044646.5979164.1367738039314.JavaMail.root@redhat.com>
	<429079641.4126769.1367738248389.JavaMail.root@redhat.com>
Message-ID: <5187B043.1050705@redhat.com>

On 05/05/2013 03:17 AM, Alon Bar-Lev wrote:
> I am going to drop the .pgpass file in favor of other configuration file and produce .pgpass on will.
> This is because:
> 1. The proprietary format of .pgpass is not friendly to parsing.
Ack.  Please remove this for a key/value solution.


From sbonazzo at redhat.com  Mon May  6 15:32:08 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 06 May 2013 17:32:08 +0200
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use Apache
	proxy (https://bugzilla.redhat.com/905754)
Message-ID: <5187CCF8.9080600@redhat.com>

Hi,
I'm working on https://bugzilla.redhat.com/905754, trying to have Apache
proxy in all 3.3 installations.

I'm looking in the code and I've found a point where I'm in doubt about
how to handle the case.
The current engine-setup implementation perform some checks that change
the behavior of the installer documented as:

1. Check whether the relevant httpd configuration files were changed, as
it's an indication for the setup that the httpd application is being
actively used, Therefore we may need to ask (dynamic change) the user
whether to override this configuration.

2. Check if IPA is installed and drop port 80/443 support. What the
script really do is setting OVERRIDE_HTTPD_CONFIG default to False in
both cases and just for case 2 call also setHttpPortsToNonProxyDefault.


About 1, if we can consider Apache "owned" by the engine we can drop any
question to the user, else I think we need to ask what to do or abort
the setup considering the configuration as unsupported.

About 2, it seems that the best solution for that is to abort the setup
if IPA is found on the same system where
we're installing the engine.
As far I've understood having IPA and engine on the same host is not a
supported configuration.


What do you think about this?


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From alonbl at redhat.com  Mon May  6 16:40:05 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 6 May 2013 12:40:05 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <5187CCF8.9080600@redhat.com>
References: <5187CCF8.9080600@redhat.com>
Message-ID: <1990199020.4477969.1367858405918.JavaMail.root@redhat.com>

Hello,

I don't understand why you start discussion from start... there were some additional facts.

So first answer:
No we cannot assume we own the machine nor own the apache, nor own the postgresql. These assumptions made in the past were plain wrong and cause more harm than good, and eventually saved no resources nor efforts.

At master we altered the ajp proxy configuration to be less intrusive[1][2].

We split the http configuration into three:
1. Install ajp proxy per our URIs[1].
2. Optionally set root redirection from / to /ovirt-engine
3. Optionally configure mod_ssl with our certificate.

The mandatory apache configuration[1] does not alter any configuration file, hence the chance of conflict is the chance of conflict between ovirt-engine URIs and other product URIs.

ovirt-engine URIs:
---
/UserPortal
/OvirtEngineWeb
/webadmin
/docs
/spice
/ca.crt
/engine.ssh.key.txt
/rhevm.ssh.key.txt
/ovirt-engine-style.css
/console.vv
/api
/ovirt-engine
---

As we have done this without cooperation of developers we kept URIs as-is.

URIs that cannot be changed until next major:
/engine.ssh.key.txt
/rhevm.ssh.key.txt
/ca.crt
/api [I guess, although we can provide migration path alternative]

All the other can be moved into /ovirt-engine with cooperation of developers, especially UI and Virt developers, it should be easy to do this, and reduce the chance of conflict.

Regards,
Alon Bar-Lev.

[1] http://gerrit.ovirt.org/#/c/13318/
[2] http://gerrit.ovirt.org/#/c/14304/

----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "users" <users at ovirt.org>
> Sent: Monday, May 6, 2013 6:32:08 PM
> Subject: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)
> 
> Hi,
> I'm working on https://bugzilla.redhat.com/905754, trying to have Apache
> proxy in all 3.3 installations.
> 
> I'm looking in the code and I've found a point where I'm in doubt about
> how to handle the case.
> The current engine-setup implementation perform some checks that change
> the behavior of the installer documented as:
> 
> 1. Check whether the relevant httpd configuration files were changed, as
> it's an indication for the setup that the httpd application is being
> actively used, Therefore we may need to ask (dynamic change) the user
> whether to override this configuration.
> 
> 2. Check if IPA is installed and drop port 80/443 support. What the
> script really do is setting OVERRIDE_HTTPD_CONFIG default to False in
> both cases and just for case 2 call also setHttpPortsToNonProxyDefault.
> 
> 
> About 1, if we can consider Apache "owned" by the engine we can drop any
> question to the user, else I think we need to ask what to do or abort
> the setup considering the configuration as unsupported.
> 
> About 2, it seems that the best solution for that is to abort the setup
> if IPA is found on the same system where
> we're installing the engine.
> As far I've understood having IPA and engine on the same host is not a
> supported configuration.
> 
> 
> What do you think about this?
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From bazulay at redhat.com  Mon May  6 19:42:02 2013
From: bazulay at redhat.com (Barak Azulay)
Date: Mon, 6 May 2013 15:42:02 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
	Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <1990199020.4477969.1367858405918.JavaMail.root@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1990199020.4477969.1367858405918.JavaMail.root@redhat.com>
Message-ID: <6D858B39-39FD-410E-9E8B-912AEE950624@redhat.com>





On May 6, 2013, at 19:45, Alon Bar-Lev <alonbl at redhat.com> wrote:

> Hello,
> 
> I don't understand why you start discussion from start... there were some additional facts.
> 
> So first answer:
> No we cannot assume we own the machine nor own the apache, nor own the postgresql. These assumptions made in the past were plain wrong and cause more harm than good, and eventually saved no resources nor efforts.
> 
> At master we altered the ajp proxy configuration to be less intrusive[1][2].
> 
> We split the http configuration into three:
> 1. Install ajp proxy per our URIs[1].
> 2. Optionally set root redirection from / to /ovirt-engine
> 3. Optionally configure mod_ssl with our certificate.

I don't know if this was already brought up,

There is a conflict between our configuration and IPA's
IPA uses mod_nss and we use mod_proxy and mod_ssl , and this creates a conflict.

We can try move to mod_nss on upgrade and solve all issues

Barak



> 
> The mandatory apache configuration[1] does not alter any configuration file, hence the chance of conflict is the chance of conflict between ovirt-engine URIs and other product URIs.
> 
> ovirt-engine URIs:
> ---
> /UserPortal
> /OvirtEngineWeb
> /webadmin
> /docs
> /spice
> /ca.crt
> /engine.ssh.key.txt
> /rhevm.ssh.key.txt
> /ovirt-engine-style.css
> /console.vv
> /api
> /ovirt-engine
> ---
> 
> As we have done this without cooperation of developers we kept URIs as-is.
> 
> URIs that cannot be changed until next major:
> /engine.ssh.key.txt
> /rhevm.ssh.key.txt
> /ca.crt
> /api [I guess, although we can provide migration path alternative]
> 
> All the other can be moved into /ovirt-engine with cooperation of developers, especially UI and Virt developers, it should be easy to do this, and reduce the chance of conflict.
> 
> Regards,
> Alon Bar-Lev.
> 
> [1] http://gerrit.ovirt.org/#/c/13318/
> [2] http://gerrit.ovirt.org/#/c/14304/
> 
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Cc: "users" <users at ovirt.org>
>> Sent: Monday, May 6, 2013 6:32:08 PM
>> Subject: [Engine-devel] 3.3 scratch or upgraded installation must use Apache    proxy
>> (https://bugzilla.redhat.com/905754)
>> 
>> Hi,
>> I'm working on https://bugzilla.redhat.com/905754, trying to have Apache
>> proxy in all 3.3 installations.
>> 
>> I'm looking in the code and I've found a point where I'm in doubt about
>> how to handle the case.
>> The current engine-setup implementation perform some checks that change
>> the behavior of the installer documented as:
>> 
>> 1. Check whether the relevant httpd configuration files were changed, as
>> it's an indication for the setup that the httpd application is being
>> actively used, Therefore we may need to ask (dynamic change) the user
>> whether to override this configuration.
>> 
>> 2. Check if IPA is installed and drop port 80/443 support. What the
>> script really do is setting OVERRIDE_HTTPD_CONFIG default to False in
>> both cases and just for case 2 call also setHttpPortsToNonProxyDefault.
>> 
>> 
>> About 1, if we can consider Apache "owned" by the engine we can drop any
>> question to the user, else I think we need to ask what to do or abort
>> the setup considering the configuration as unsupported.
>> 
>> About 2, it seems that the best solution for that is to abort the setup
>> if IPA is found on the same system where
>> we're installing the engine.
>> As far I've understood having IPA and engine on the same host is not a
>> supported configuration.
>> 
>> 
>> What do you think about this?
>> 
>> 
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>> 
>> _______________________________________________
>> 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 alonbl at redhat.com  Mon May  6 20:11:58 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 6 May 2013 16:11:58 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <6D858B39-39FD-410E-9E8B-912AEE950624@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1990199020.4477969.1367858405918.JavaMail.root@redhat.com>
	<6D858B39-39FD-410E-9E8B-912AEE950624@redhat.com>
Message-ID: <190022898.4562887.1367871118558.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Barak Azulay" <bazulay at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> Sent: Monday, May 6, 2013 10:42:02 PM
> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)
> 
> 
> 
> 
> 
> On May 6, 2013, at 19:45, Alon Bar-Lev <alonbl at redhat.com> wrote:
> 
> > Hello,
> > 
> > I don't understand why you start discussion from start... there were some
> > additional facts.
> > 
> > So first answer:
> > No we cannot assume we own the machine nor own the apache, nor own the
> > postgresql. These assumptions made in the past were plain wrong and cause
> > more harm than good, and eventually saved no resources nor efforts.
> > 
> > At master we altered the ajp proxy configuration to be less
> > intrusive[1][2].
> > 
> > We split the http configuration into three:
> > 1. Install ajp proxy per our URIs[1].
> > 2. Optionally set root redirection from / to /ovirt-engine
> > 3. Optionally configure mod_ssl with our certificate.
> 
> I don't know if this was already brought up,
> 
> There is a conflict between our configuration and IPA's
> IPA uses mod_nss and we use mod_proxy and mod_ssl , and this creates a
> conflict.
> 
> We can try move to mod_nss on upgrade and solve all issues
> 
> Barak

The fact that ovirt-engine depends on mod_ssl is a mistake... well, at least I think so.
The product should not care how ssl is provided as long as it is provided.

Personally, I think that product should not attempt to configure ssl at all, but provide the instructions of how to do so... But never the less, let's try to keep this to avoid argument.

In case IPA is installed (and I really don't understand why should we care about IPA specifically, well, I actually do... as IPA makes the same faulty assumptions of 'owning' resources), the admin should just avoid selecting the 'set ovirt-engine as default page' and 'configure apache ssl', user should access ovirt-engine using:
http://host/ovirt-engine

It should work as long as there are no URI conflicts between products as I listed in previous message.

Regards,
Alon

> > 
> > The mandatory apache configuration[1] does not alter any configuration
> > file, hence the chance of conflict is the chance of conflict between
> > ovirt-engine URIs and other product URIs.
> > 
> > ovirt-engine URIs:
> > ---
> > /UserPortal
> > /OvirtEngineWeb
> > /webadmin
> > /docs
> > /spice
> > /ca.crt
> > /engine.ssh.key.txt
> > /rhevm.ssh.key.txt
> > /ovirt-engine-style.css
> > /console.vv
> > /api
> > /ovirt-engine
> > ---
> > 
> > As we have done this without cooperation of developers we kept URIs as-is.
> > 
> > URIs that cannot be changed until next major:
> > /engine.ssh.key.txt
> > /rhevm.ssh.key.txt
> > /ca.crt
> > /api [I guess, although we can provide migration path alternative]
> > 
> > All the other can be moved into /ovirt-engine with cooperation of
> > developers, especially UI and Virt developers, it should be easy to do
> > this, and reduce the chance of conflict.
> > 
> > Regards,
> > Alon Bar-Lev.
> > 
> > [1] http://gerrit.ovirt.org/#/c/13318/
> > [2] http://gerrit.ovirt.org/#/c/14304/
> > 
> > ----- Original Message -----
> >> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> >> To: "engine-devel" <engine-devel at ovirt.org>
> >> Cc: "users" <users at ovirt.org>
> >> Sent: Monday, May 6, 2013 6:32:08 PM
> >> Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
> >> Apache    proxy
> >> (https://bugzilla.redhat.com/905754)
> >> 
> >> Hi,
> >> I'm working on https://bugzilla.redhat.com/905754, trying to have Apache
> >> proxy in all 3.3 installations.
> >> 
> >> I'm looking in the code and I've found a point where I'm in doubt about
> >> how to handle the case.
> >> The current engine-setup implementation perform some checks that change
> >> the behavior of the installer documented as:
> >> 
> >> 1. Check whether the relevant httpd configuration files were changed, as
> >> it's an indication for the setup that the httpd application is being
> >> actively used, Therefore we may need to ask (dynamic change) the user
> >> whether to override this configuration.
> >> 
> >> 2. Check if IPA is installed and drop port 80/443 support. What the
> >> script really do is setting OVERRIDE_HTTPD_CONFIG default to False in
> >> both cases and just for case 2 call also setHttpPortsToNonProxyDefault.
> >> 
> >> 
> >> About 1, if we can consider Apache "owned" by the engine we can drop any
> >> question to the user, else I think we need to ask what to do or abort
> >> the setup considering the configuration as unsupported.
> >> 
> >> About 2, it seems that the best solution for that is to abort the setup
> >> if IPA is found on the same system where
> >> we're installing the engine.
> >> As far I've understood having IPA and engine on the same host is not a
> >> supported configuration.
> >> 
> >> 
> >> What do you think about this?
> >> 
> >> 
> >> --
> >> Sandro Bonazzola
> >> Better technology. Faster innovation. Powered by community collaboration.
> >> See how it works at redhat.com
> >> 
> >> _______________________________________________
> >> 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 asegurap at redhat.com  Mon May  6 23:50:04 2013
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Mon, 6 May 2013 19:50:04 -0400 (EDT)
Subject: [Engine-devel] Intel workshop in Shangai
In-Reply-To: <981451642.4613648.1367883812037.JavaMail.root@redhat.com>
Message-ID: <1646442733.4620259.1367884204884.JavaMail.root@redhat.com>

Hi List,

You might be interested in the Intel oVirt workshop schedule. Here it is:

 Wednesday, May 8, 2013 - Operations Track
08:30-09:00 	Opening remarks and Keynote : Intel Open Source Strategy    Jackson He (Intel)
09:00-10:00 	oVirt Introduction 	                                    Doron Fediuck (Red Hat)
10:00-11:00 	oVirt Architecture Overview                                 Dan Kenigsberg (Red Hat)
11:00-11:15 	Coffee Break
11:15 - 12:15 	Deploying and testing oVirt using nested virtualization     Mark Wu (IBM)
12:15-13:30 	Lunch
13:30-14:30 	oVirt SLA overview 	                                    Doron Fediuck (Red Hat)
14:30-15:00 	oVirt storage system and IBM's activity 	            Shu Ming (IBM)
15:00-15:15 	Coffee Break
15:15-16:15 	Troubleshooting oVirt                                       Tal Nisan (Red Hat)
16:15-17:00 	Converged Infrastructure with oVirt and Gluster             Theron Conrey (Red Hat) 


 Wednesday, May 8th, 2013 - oVirt / Gluster Integration Track
Time            Title                                                       Speaker
08:30-09:00 	Opening remarks and Keynote : Intel Open Source Strategy    Jackson He
09:00-10:00 	Gluster Community Overview and Roadmap                      John Mark Walker (Red Hat)
10:00-11:00 	Gluster Architecture Overview                               To be announced
11:00-11:15 	Coffee break
11:15-12:15 	oVirt Configurations and Gluster                            Tal Nisan (Red Hat)
12:15-13:30 	Lunch
13:30-14:30 	Converged Infrastructure with oVirt and Gluster             Theron Conrey (Red Hat)
14:30-15:30 	Gluster and Swift Object Store (UFO)                        John Mark Walker (Red Hat)
15:30-15:45 	Coffee break
15:45-16:45 	Developing with GlusterFS - translator framework, libgfapi and more 	Vijay Bellur (Red Hat) 


 Thursday, May 9, 2013 - Developer Track
Time            Title                                                       Speaker
09:00-10:00 	oVirt-node overview                                         Ying Cui and Guohua Ouyang (Red Hat)
10:00-11:00 	Packaging oVirt for Ubuntu                                  Zhengsheng Zhou (IBM)
11:00 - 11:15 	Coffee Break
11:15-12:15 	oVirt SLA- MoM as host level enforcement agent              Doron Fediuck (Red Hat)
12:15-13:30 	Lunch
13:30-14:30 	Trusted Compute Pools Deep Dive                             Gang Wei
14:30-15:30 	KVM Nested Virtualization                                   to be announced
15:30-15:45 	Coffee break
15:30-17:00 	The present and future of SetupNetwork in oVirt             Dan Kenisberg (Red Hat)
17:00-17:30 	Closing remarks and closing keynote 

 Thursday, May 9, 2013 - Self paced labs / oVirt Install
Time            Title                                                       Speaker
09:00-12:00 	oVirt Hands-on Workshop                                     To be announced
12:00-13:30 	Lunch
13:30-16:00 	oVirt and Gluster configurations                            To be announced 


From alonbl at redhat.com  Tue May  7 06:22:40 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 7 May 2013 02:22:40 -0400 (EDT)
Subject: [Engine-devel] otopi setup: Running into
	ERROR_CANNOT_FIND_ISO_IMAGE_PATH
In-Reply-To: <20130506213924.Horde.UMUAyJir309RiIV8pIkAXrA@imap.linux.ibm.com>
References: <20130506213924.Horde.UMUAyJir309RiIV8pIkAXrA@imap.linux.ibm.com>
Message-ID: <1742048597.4690757.1367907760424.JavaMail.root@redhat.com>

Hi,

I am forwarding this to the list as my knowledge in this is not too great...

Thanks,
Alon,

----- Forwarded Message -----
From: snmishra at linux.vnet.ibm.com
To: alonbl at redhat.com
Sent: Tuesday, May 7, 2013 7:39:24 AM
Subject: otopi: Running into ERROR_CANNOT_FIND_ISO_IMAGE_PATH


Alon,

   I am using the new otopi src after you fixed the get userid issue.

   I have one  F18 machine running engine.
   I have another F18 machine running host.
   I added host to engine.
   I added data and iso to engine from this host.
   DC, both starage domains, host are all up with green error.
   I define a new VM on the host.
   I choose to run it once and select the F18 image from iso storage.
   When I hit ok, I get this error -

  CanDoAction of action RunVmOnce failed.  
Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH


Engine log has the following -



2013-05-07 00:23:48,305 INFO   
[org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]  
(http--0.0.0.0-8080-6) START, GetIsoListVDSCommand( storagePoolId =  
5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false,  
compatabilityVersion = null), log id: 4beb79b2
2013-05-07 00:23:48,307 INFO   
[org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]  
(http--0.0.0.0-8080-6) START, HsmGetIsoListVDSCommand(HostName =  
host20, HostId = b6580f5d-4ba5-467e-858e-edf14a3be443,  
storagePoolId=5849b030-626e-47cb-ad90-3ce782d831b3), log id: 5082bc0e
2013-05-07 00:23:48,324 INFO   
[org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]  
(http--0.0.0.0-8080-6) FINISH, HsmGetIsoListVDSCommand, return:  
[Fedora-18-x86_64-Live-Desktop.iso], log id: 5082bc0e
2anDoAction of action RunVmOnce failed.  
Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH
2013-05-07 00:23:48,335 INFO   
[org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]  
(http--0.0.0.0-8080-6) START, GetFloppyListVDSCommand( storagePoolId =  
5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false,  
compatabilityVersion = null), log id: 635c3ac0
2013-05-07 00:23:48,349 INFO   
[org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]  
(http--0.0.0.0-8080-6) FINISH, GetFloppyListVDSCommand, return: [],  
log id: 635c3ac0
2013-05-07 00:24:41,959 INFO   
[org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]  
(http--0.0.0.0-8080-6) [31502a07] START, IsoPrefixVDSCommand(  
storagePoolId = 5849b030-626e-47cb-ad90-3ce782d831b3,  
ignoreFailoverLimit = false, compatabilityVersion = null), log id:  
231d7b7d
2013-05-07 00:24:41,960 INFO   
[org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]  
(http--0.0.0.0-8080-6) [31502a07] FINISH, IsoPrefixVDSCommand, return:  
/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/df072252-ab55-4c0b-8b54-0100a1efa4d6/images/11111111-1111-1111-1111-111111111111, log id:  
231d7b7d


ls -la from host machine shows -

[root at ovirt2 11111111-1111-1111-1111-111111111111]# ls -l
total 937988
-rw-r--r--. 1 vdsm kvm 960495616 May  7 00:21  
Fedora-18-x86_64-Live-Desktop.iso
[root at ovirt2 11111111-1111-1111-1111-111111111111]# pwd
/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/df072252-ab55-4c0b-8b54-0100a1efa4d6/images/11111111-1111-1111-1111-111111111111


and ...

[root at ovirt2 11111111-1111-1111-1111-111111111111]# ls -la
total 937996
drwxr-xr-x. 2 vdsm kvm      4096 May  7 00:21 .
drwxr-xr-x. 3 vdsm kvm      4096 May  6 23:45 ..
-rw-r--r--. 1 vdsm kvm 960495616 May  7 00:21  
Fedora-18-x86_64-Live-Desktop.iso
[root at ovirt2 11111111-1111-1111-1111-111111111111]# pwd
/home/iso/df072252-ab55-4c0b-8b54-0100a1efa4d6/images/11111111-1111-1111-1111-111111111111



From bigclouds at 163.com  Tue May  7 06:38:03 2013
From: bigclouds at 163.com (bigclouds)
Date: Tue, 7 May 2013 14:38:03 +0800 (CST)
Subject: [Engine-devel] engine log is disordered(mixed together)
Message-ID: <2ad35c6f.af6a.13e7db60e02.Coremail.bigclouds@163.com>

hi,all
log is mixed together.
 
 
ulouds..ceenteer.ccoree.blll.iinteerfaacess.BaackeendInternal$$$view7.enddActtionn(Unnknoown Soourcce)  [ceenteer-bbll..jarr:]
        att coom.mmassscloouds.cecenteer.ccoree.blll.EntityAsyncTask.ntityAsyncTask.EndCdCommmanddActtionn(EntiityAAsynncTaask..javva:1138)) [ccentter--blll.jaar:]]
        aat ccom..masssclloudds.ccentter.coore..blll.EntiityAAsynncTaskk.acccesss$000(0(EnttityyAsyncTcTaskk.jaava::26) [[centeer-blll.jaar:]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130507/8478bc9d/attachment.html>

From andrej.bagon at arnes.si  Tue May  7 09:58:29 2013
From: andrej.bagon at arnes.si (Andrej Bagon)
Date: Tue, 07 May 2013 11:58:29 +0200
Subject: [Engine-devel] ovirt user portal and attach a cd
In-Reply-To: <517E4629.5050001@arnes.si>
References: <517E2F37.3010807@arnes.si>
	<1682099686.6160454.1367226745207.JavaMail.root@redhat.com>
	<517E4629.5050001@arnes.si>
Message-ID: <5188D045.8030004@arnes.si>

How to use spice on windows, but anyway what about on linux?

Best Regards,
Andrej

On 04/29/2013 12:06 PM, Andrej Bagon wrote:
> We are using oVirt Engine Version: 3.2.1-1.beta1.el6 and linux
> environment (and vnc for console). Never tried spice console.
>
> Best Regards,
> Andrej
>
> On 04/29/2013 11:12 AM, Omer Frenkel wrote:
>> ----- Original Message -----
>>> From: "Andrej Bagon" <andrej.bagon at arnes.si>
>>> To: engine-devel at ovirt.org
>>> Sent: Monday, April 29, 2013 11:28:39 AM
>>> Subject: [Engine-devel] ovirt user portal and attach a cd
>>>
>>> Hi all,
>>>
>>> we would like to limit a user as much as possible and give him only
>>> actions that he needs with his VM. If we disallow a user the right in
>>> system|configure system|manipulate permissions), we give the user, in
>>> user portal, only basic mode. But then three is no option to attach a cd
>>> in the basic user portal. In basic mode user interface there is no
>>> chance in attaching a cd (as this is a basic operation a solution to
>>> this would be a button attaching a cd when starting a vm).
>>>
>>> If we allow the user to manipulate permissions, we get the extended menu
>>> back and the user is limited, but we found unacceptable when he is
>>> adding permission to the VM, he sees all the users (name, surname,
>>> email!) in the ovirt authentication mechanism? A solution to this would
>>> be authenticating to the directory service as a user an not as ovirt
>>> admin user - meaning that the user will see only users that we allowed
>>> he sees in the ldap directory.
>>>
>>> Thank you.
>>>
>>> Best Regards,
>>> Andrej
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> well if you only need to change cd for vm,
>> permission wise, the userRole and basic user portal are enough, 
>> iirc, if using spice (on windows?) that used to be possible, this may be related:
>> https://bugzilla.redhat.com/show_bug.cgi?id=957611
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From alonbl at redhat.com  Tue May  7 16:44:48 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 7 May 2013 12:44:48 -0400 (EDT)
Subject: [Engine-devel] [REST-API] Support passing auth information
 without having to use HTTP Authorization header #958874
In-Reply-To: <518751C7.8090208@redhat.com>
References: <518751C7.8090208@redhat.com>
Message-ID: <1665518752.4971723.1367945088296.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>,
> "Itamar Heim" <iheim at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, May 6, 2013 9:46:31 AM
> Subject: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
> 
> 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=958874
> 
> Hi Alon,
> 
> (In reply to comment #2)
> >
> > Regardless of this specific RFE I would like to write that I don't like the
> > REST API session mechanism
> > [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as it
> > relays on cookies and not explicit API interaction.
> 
> authentication in RESTful application is a matter of debate, it can be
> achieved
> in various ways, but session + cookie auth. method is very common and usually
> effective,
> 
> it's biggest disadvantage is that it's not exactly RESfull cause client
> have to maintain (story) the cookie and not the server (but i wouldn't call
> it an
> issue at all), besides that it's works perfectly well from the REST PoV,
> 
> also some may say that cookies are not strong enough and OAuth for instance
> should be used instead, but this is a different story cause in our case,
> cookie
> are for the clients (not browsers [1]) that can store them in a secure way or
> even
> not to store at all (in-memory cookie).
> 
> [1] another disadvantage is that webbrowsers not able to access cookie
> namespace,
> but lately i've suggested URI based authentication [2] to support web
> browsers
> as well.
> 
> [2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html
> 
> the biggest advantage of the cookie is a session expiration that maintained
> by the server and abstracted from the client what is much better from
> security
> PoV than standard authentication mechanisms such as HTTP basic auth for
> instance
> which can be potentially cached.

Expiration is always managed by server side, regardless the cookie vs ticket debate.

> 
> > I would have expected a
> > 'ticket' to be retrieved and that 'ticket' to be disconnected from the
> > application server objects. Although we can refer the 'cookie' as a ticket,
> > however the requirement to parse it should not be required, there be a
> > conflict between two separate applications running on same server, and
> > there
> > may be a problem to transfer credentials between servers.
> 
> well, this is not exactly correct:
> 
> 1. client desn't have to decode/parse the cookie and pass credentials, all it
> need is
>    just to store the cookie and pass it as is to server on every request.

You just described what cookies are.
And if I understand we want better control of application authentication, disconnected from 'default browser behavior'.

> 2. "conflict between two separate applications running on same server"?
> different cookie
>    uses different domain & path by spec., can you pls explain what do you
>    mean by this?

If you call the cookie JSESSIONID....
 
> >
> > If we modify authentication we should support more authentication types, at
> > least SPNEGO.
> >
> > In order to allow SPNEGO and other authentication mechanisms, we better
> > force people to use single URI to perform the login and return
> > authenticated
> > 'ticket' to continue interaction with application.
> 
> this is good for the backend authentication, but is not for the RESTful
> application,
> it's like buying an aeroplane and driving it on a road,

And why is that? who are you to decide what authentication mechanism is to be used by customers?
If customer has a policy of not transmitting passwords over the network, then SPENGO is your friend. 
But let's ignore it for now.

> "force people to use single URI to perform the login" means SOAP while we
> wanted REST
> where any URI is considered as entry point and actually a resource address
> that should
> be accessible/manipulatable and authentication should be
> abstracted/disconnected from
> this concept.

Again, you provide statements that are not written in stone.
Having custom authentication header breaks the 'plain simple rest'.
Having a URI is only makes it easier to manage this breakage.

> SPNEGO is only an implementation detail that can be abstracted for the API.

I don't follow.

> > This will be much simpler
> > implementation at the api side and much more efficient, and as we are
> > discussion application-to-application interaction there should be no user
> > experience visible issues.
> 
> i'm not sure: "force people to use single URI to perform the login" and no
> "no user experience visible issues."?

Please describe how the prefer mechanism suggested can be implemented in standard browser.
And if it cannot, and custom logic is required, why a custom logic that accesses a custom URI to perform login is any different.
 
> >
> > What I recommend is purely applicative rest login command...
> 
> IIUC this is SOAP and not REST ...

Again... please refrain from these kind of void statements.
SOAP is a protocol, it has specific format and rules.
It may or may not use this or any other suggested authentication mechanism.
 
> > ---
> > Input: authentication type, authentication credentials
> >     authentication=http
> >     authentication=password
> >     credentials:
> >         user=user
> >         password=password
> >     [OPTIONALLY] HTTP authentication headers
> > Output:
> >     ticket
> >     ticket issue time (required to avoid clock sync)
> >     ticket expiration time
> > Logic:
> > if authentication is http, use http authentication headers to establish
> > user
> > authentication. This will allow future SSO.
> > if authentication is password, use embedded credentials.
> > ---
> >
> > For every other rest call add http header:
> >     oVirt-Authentication-Ticket: <ticket>
> 
> this is not any different from the today's session based auth. only
> instead of  oVirt-Authentication-Ticket added cookie.

I did not claim otherwise, I wrote that I don't like cookies, I do like explicit headers.
As I wrote, cookies has limited storage at client, cookies may conflict, cookies has issues with clusters.
Headers do not.

> >
> > The backend side will attach the correct security context to the action if
> > the header is received.
> 
> this is how it's works today.

I could not imagine that.
 
> >
> > No need for the prefer mechanism nor multiple authentications. It should be
> > easy for javascript implementation to perform the authentication via the
> > designated URI, and then pass the ticket if not expired, when expired to
> > perform re-authentication with or without involving the user.
> 
> again this is how it works today, and you not solving web browser problem as
> when ticket expires, they cannot re-authenticate with new
> oVirt-Authentication-Ticket
> cause this header is cached and cannot be changed by the browser in runtime.

Header is cached? Can you please explain?
If I use XMLHTTPRequest() to perform the request, I control the headers explicitly.

Regards,
Alon


From alonbl at redhat.com  Wed May  8 10:01:58 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 8 May 2013 06:01:58 -0400 (EDT)
Subject: [Engine-devel] PKI related issue with current build environemnt
 (missing ENGINE_PKI_*)
In-Reply-To: <454493447.5257884.1368006769032.JavaMail.root@redhat.com>
Message-ID: <988948737.5258992.1368007318760.JavaMail.root@redhat.com>

Hello,

In change[1] we move the reference to PKI artifacts from database to configuration files.

For all of you who are hacking the product to work in development mode, there is an environment variable called ENGINE_DEFAULTS which causes the engine to load its default configuration from a file.

A template is available at ./packaging/conf/engine.conf.defaults.in

If you do not set this environment variable /usr/share/ovirt-engine/conf/engine.conf.defaults will be used, so if you have rpm based installation of ovirt-engine an incompatible/incomplete configuration will be loaded.

We now need additional variables:

ENGINE_PKI_CA=${ENGINE_PKI}/ca.pem
ENGINE_PKI_ENGINE_CERT=${ENGINE_PKI}/certs/engine.cer
ENGINE_PKI_TRUST_STORE=${ENGINE_PKI}/.truststore
ENGINE_PKI_TRUST_STORE_PASSWORD=
ENGINE_PKI_ENGINE_STORE=${ENGINE_PKI}/keys/engine.p12
ENGINE_PKI_ENGINE_STORE_PASSWORD=
ENGINE_PKI_ENGINE_STORE_ALIAS=1

Set ENGINE_PKI to point to where PKI resources resides, or just /etc/pki/ovirt-engine and if you actually use PKI, set the password to the correct password of your installations.

Regards,
Alon Bar-Lev

[1] http://gerrit.ovirt.org/#/c/14333/


From sbonazzo at redhat.com  Wed May  8 12:51:03 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 08 May 2013 14:51:03 +0200
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <190022898.4562887.1367871118558.JavaMail.root@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1990199020.4477969.1367858405918.JavaMail.root@redhat.com>
	<6D858B39-39FD-410E-9E8B-912AEE950624@redhat.com>
	<190022898.4562887.1367871118558.JavaMail.root@redhat.com>
Message-ID: <518A4A37.7040506@redhat.com>

Hello,
if I've understood correctly then:
- there is no reason for checking if user altered http configuration
- proxy doesn't depend on any other related http configuration we do and
does not alter any other configuration file, so we can do it without
asking anything
- if ipa is installed, engine-setup should issue a warning about it and
default to No for 'set ovirt-engine as default page' and 'configure
apache ssl'

I think I've enough info.
Thanks.


Il 06/05/2013 22:11, Alon Bar-Lev ha scritto:
>
> ----- Original Message -----
>> From: "Barak Azulay" <bazulay at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "users" <users at ovirt.org>
>> Sent: Monday, May 6, 2013 10:42:02 PM
>> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
>> (https://bugzilla.redhat.com/905754)
>>
>>
>>
>>
>>
>> On May 6, 2013, at 19:45, Alon Bar-Lev <alonbl at redhat.com> wrote:
>>
>>> Hello,
>>>
>>> I don't understand why you start discussion from start... there were some
>>> additional facts.
>>>
>>> So first answer:
>>> No we cannot assume we own the machine nor own the apache, nor own the
>>> postgresql. These assumptions made in the past were plain wrong and cause
>>> more harm than good, and eventually saved no resources nor efforts.
>>>
>>> At master we altered the ajp proxy configuration to be less
>>> intrusive[1][2].
>>>
>>> We split the http configuration into three:
>>> 1. Install ajp proxy per our URIs[1].
>>> 2. Optionally set root redirection from / to /ovirt-engine
>>> 3. Optionally configure mod_ssl with our certificate.
>> I don't know if this was already brought up,
>>
>> There is a conflict between our configuration and IPA's
>> IPA uses mod_nss and we use mod_proxy and mod_ssl , and this creates a
>> conflict.
>>
>> We can try move to mod_nss on upgrade and solve all issues
>>
>> Barak
> The fact that ovirt-engine depends on mod_ssl is a mistake... well, at least I think so.
> The product should not care how ssl is provided as long as it is provided.
>
> Personally, I think that product should not attempt to configure ssl at all, but provide the instructions of how to do so... But never the less, let's try to keep this to avoid argument.
>
> In case IPA is installed (and I really don't understand why should we care about IPA specifically, well, I actually do... as IPA makes the same faulty assumptions of 'owning' resources), the admin should just avoid selecting the 'set ovirt-engine as default page' and 'configure apache ssl', user should access ovirt-engine using:
> http://host/ovirt-engine
>
> It should work as long as there are no URI conflicts between products as I listed in previous message.
>
> Regards,
> Alon
>
>>> The mandatory apache configuration[1] does not alter any configuration
>>> file, hence the chance of conflict is the chance of conflict between
>>> ovirt-engine URIs and other product URIs.
>>>
>>> ovirt-engine URIs:
>>> ---
>>> /UserPortal
>>> /OvirtEngineWeb
>>> /webadmin
>>> /docs
>>> /spice
>>> /ca.crt
>>> /engine.ssh.key.txt
>>> /rhevm.ssh.key.txt
>>> /ovirt-engine-style.css
>>> /console.vv
>>> /api
>>> /ovirt-engine
>>> ---
>>>
>>> As we have done this without cooperation of developers we kept URIs as-is.
>>>
>>> URIs that cannot be changed until next major:
>>> /engine.ssh.key.txt
>>> /rhevm.ssh.key.txt
>>> /ca.crt
>>> /api [I guess, although we can provide migration path alternative]
>>>
>>> All the other can be moved into /ovirt-engine with cooperation of
>>> developers, especially UI and Virt developers, it should be easy to do
>>> this, and reduce the chance of conflict.
>>>
>>> Regards,
>>> Alon Bar-Lev.
>>>
>>> [1] http://gerrit.ovirt.org/#/c/13318/
>>> [2] http://gerrit.ovirt.org/#/c/14304/
>>>
>>> ----- Original Message -----
>>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>> Cc: "users" <users at ovirt.org>
>>>> Sent: Monday, May 6, 2013 6:32:08 PM
>>>> Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
>>>> Apache    proxy
>>>> (https://bugzilla.redhat.com/905754)
>>>>
>>>> Hi,
>>>> I'm working on https://bugzilla.redhat.com/905754, trying to have Apache
>>>> proxy in all 3.3 installations.
>>>>
>>>> I'm looking in the code and I've found a point where I'm in doubt about
>>>> how to handle the case.
>>>> The current engine-setup implementation perform some checks that change
>>>> the behavior of the installer documented as:
>>>>
>>>> 1. Check whether the relevant httpd configuration files were changed, as
>>>> it's an indication for the setup that the httpd application is being
>>>> actively used, Therefore we may need to ask (dynamic change) the user
>>>> whether to override this configuration.
>>>>
>>>> 2. Check if IPA is installed and drop port 80/443 support. What the
>>>> script really do is setting OVERRIDE_HTTPD_CONFIG default to False in
>>>> both cases and just for case 2 call also setHttpPortsToNonProxyDefault.
>>>>
>>>>
>>>> About 1, if we can consider Apache "owned" by the engine we can drop any
>>>> question to the user, else I think we need to ask what to do or abort
>>>> the setup considering the configuration as unsupported.
>>>>
>>>> About 2, it seems that the best solution for that is to abort the setup
>>>> if IPA is found on the same system where
>>>> we're installing the engine.
>>>> As far I've understood having IPA and engine on the same host is not a
>>>> supported configuration.
>>>>
>>>>
>>>> What do you think about this?
>>>>
>>>>
>>>> --
>>>> Sandro Bonazzola
>>>> Better technology. Faster innovation. Powered by community collaboration.
>>>> See how it works at redhat.com
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From bazulay at redhat.com  Wed May  8 13:00:34 2013
From: bazulay at redhat.com (Barak Azulay)
Date: Wed, 8 May 2013 09:00:34 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <518A4A37.7040506@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1990199020.4477969.1367858405918.JavaMail.root@redhat.com>
	<6D858B39-39FD-410E-9E8B-912AEE950624@redhat.com>
	<190022898.4562887.1367871118558.JavaMail.root@redhat.com>
	<518A4A37.7040506@redhat.com>
Message-ID: <1674151596.12805405.1368018034731.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> Sent: Wednesday, May 8, 2013 3:51:03 PM
> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)
> 
> Hello,
> if I've understood correctly then:
> - there is no reason for checking if user altered http configuration
> - proxy doesn't depend on any other related http configuration we do and
> does not alter any other configuration file, so we can do it without
> asking anything
> - if ipa is installed, engine-setup should issue a warning about it and
> default to No for 'set ovirt-engine as default page' and 'configure
> apache ssl'


AFAIU and I don't think it was changed, there is a conflict between IPA and mod_ssl (they did it ugly ... not in rpm level... that was the status a year ago) 

SO it will not work, as long we do not move to mod_nss.

In addition there wad an issue with mod_proxy and using 2 different SSL certificates (IPA & RHEV) on the same apache server.


please make sure all the above are solved.


Thanks
Barak
> 
> I think I've enough info.
> Thanks.
> 
> 
> Il 06/05/2013 22:11, Alon Bar-Lev ha scritto:
> >
> > ----- Original Message -----
> >> From: "Barak Azulay" <bazulay at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> >> Sent: Monday, May 6, 2013 10:42:02 PM
> >> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> >> Apache	proxy
> >> (https://bugzilla.redhat.com/905754)
> >>
> >>
> >>
> >>
> >>
> >> On May 6, 2013, at 19:45, Alon Bar-Lev <alonbl at redhat.com> wrote:
> >>
> >>> Hello,
> >>>
> >>> I don't understand why you start discussion from start... there were some
> >>> additional facts.
> >>>
> >>> So first answer:
> >>> No we cannot assume we own the machine nor own the apache, nor own the
> >>> postgresql. These assumptions made in the past were plain wrong and cause
> >>> more harm than good, and eventually saved no resources nor efforts.
> >>>
> >>> At master we altered the ajp proxy configuration to be less
> >>> intrusive[1][2].
> >>>
> >>> We split the http configuration into three:
> >>> 1. Install ajp proxy per our URIs[1].
> >>> 2. Optionally set root redirection from / to /ovirt-engine
> >>> 3. Optionally configure mod_ssl with our certificate.
> >> I don't know if this was already brought up,
> >>
> >> There is a conflict between our configuration and IPA's
> >> IPA uses mod_nss and we use mod_proxy and mod_ssl , and this creates a
> >> conflict.
> >>
> >> We can try move to mod_nss on upgrade and solve all issues
> >>
> >> Barak
> > The fact that ovirt-engine depends on mod_ssl is a mistake... well, at
> > least I think so.
> > The product should not care how ssl is provided as long as it is provided.
> >
> > Personally, I think that product should not attempt to configure ssl at
> > all, but provide the instructions of how to do so... But never the less,
> > let's try to keep this to avoid argument.
> >
> > In case IPA is installed (and I really don't understand why should we care
> > about IPA specifically, well, I actually do... as IPA makes the same
> > faulty assumptions of 'owning' resources), the admin should just avoid
> > selecting the 'set ovirt-engine as default page' and 'configure apache
> > ssl', user should access ovirt-engine using:
> > http://host/ovirt-engine
> >
> > It should work as long as there are no URI conflicts between products as I
> > listed in previous message.
> >
> > Regards,
> > Alon
> >
> >>> The mandatory apache configuration[1] does not alter any configuration
> >>> file, hence the chance of conflict is the chance of conflict between
> >>> ovirt-engine URIs and other product URIs.
> >>>
> >>> ovirt-engine URIs:
> >>> ---
> >>> /UserPortal
> >>> /OvirtEngineWeb
> >>> /webadmin
> >>> /docs
> >>> /spice
> >>> /ca.crt
> >>> /engine.ssh.key.txt
> >>> /rhevm.ssh.key.txt
> >>> /ovirt-engine-style.css
> >>> /console.vv
> >>> /api
> >>> /ovirt-engine
> >>> ---
> >>>
> >>> As we have done this without cooperation of developers we kept URIs
> >>> as-is.
> >>>
> >>> URIs that cannot be changed until next major:
> >>> /engine.ssh.key.txt
> >>> /rhevm.ssh.key.txt
> >>> /ca.crt
> >>> /api [I guess, although we can provide migration path alternative]
> >>>
> >>> All the other can be moved into /ovirt-engine with cooperation of
> >>> developers, especially UI and Virt developers, it should be easy to do
> >>> this, and reduce the chance of conflict.
> >>>
> >>> Regards,
> >>> Alon Bar-Lev.
> >>>
> >>> [1] http://gerrit.ovirt.org/#/c/13318/
> >>> [2] http://gerrit.ovirt.org/#/c/14304/
> >>>
> >>> ----- Original Message -----
> >>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> >>>> To: "engine-devel" <engine-devel at ovirt.org>
> >>>> Cc: "users" <users at ovirt.org>
> >>>> Sent: Monday, May 6, 2013 6:32:08 PM
> >>>> Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
> >>>> Apache    proxy
> >>>> (https://bugzilla.redhat.com/905754)
> >>>>
> >>>> Hi,
> >>>> I'm working on https://bugzilla.redhat.com/905754, trying to have Apache
> >>>> proxy in all 3.3 installations.
> >>>>
> >>>> I'm looking in the code and I've found a point where I'm in doubt about
> >>>> how to handle the case.
> >>>> The current engine-setup implementation perform some checks that change
> >>>> the behavior of the installer documented as:
> >>>>
> >>>> 1. Check whether the relevant httpd configuration files were changed, as
> >>>> it's an indication for the setup that the httpd application is being
> >>>> actively used, Therefore we may need to ask (dynamic change) the user
> >>>> whether to override this configuration.
> >>>>
> >>>> 2. Check if IPA is installed and drop port 80/443 support. What the
> >>>> script really do is setting OVERRIDE_HTTPD_CONFIG default to False in
> >>>> both cases and just for case 2 call also setHttpPortsToNonProxyDefault.
> >>>>
> >>>>
> >>>> About 1, if we can consider Apache "owned" by the engine we can drop any
> >>>> question to the user, else I think we need to ask what to do or abort
> >>>> the setup considering the configuration as unsupported.
> >>>>
> >>>> About 2, it seems that the best solution for that is to abort the setup
> >>>> if IPA is found on the same system where
> >>>> we're installing the engine.
> >>>> As far I've understood having IPA and engine on the same host is not a
> >>>> supported configuration.
> >>>>
> >>>>
> >>>> What do you think about this?
> >>>>
> >>>>
> >>>> --
> >>>> Sandro Bonazzola
> >>>> Better technology. Faster innovation. Powered by community
> >>>> collaboration.
> >>>> See how it works at redhat.com
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>>
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From alonbl at redhat.com  Wed May  8 14:20:51 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 8 May 2013 10:20:51 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <1674151596.12805405.1368018034731.JavaMail.root@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1990199020.4477969.1367858405918.JavaMail.root@redhat.com>
	<6D858B39-39FD-410E-9E8B-912AEE950624@redhat.com>
	<190022898.4562887.1367871118558.JavaMail.root@redhat.com>
	<518A4A37.7040506@redhat.com>
	<1674151596.12805405.1368018034731.JavaMail.root@redhat.com>
Message-ID: <129444276.5410211.1368022851515.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Barak Azulay" <bazulay at redhat.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> Sent: Wednesday, May 8, 2013 4:00:34 PM
> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)
> 
> 
> 
> ----- Original Message -----
> > From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> > Sent: Wednesday, May 8, 2013 3:51:03 PM
> > Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> > Apache	proxy
> > (https://bugzilla.redhat.com/905754)
> > 
> > Hello,
> > if I've understood correctly then:
> > - there is no reason for checking if user altered http configuration
> > - proxy doesn't depend on any other related http configuration we do and
> > does not alter any other configuration file, so we can do it without
> > asking anything
> > - if ipa is installed, engine-setup should issue a warning about it and
> > default to No for 'set ovirt-engine as default page' and 'configure
> > apache ssl'
> 
> 
> AFAIU and I don't think it was changed, there is a conflict between IPA and
> mod_ssl (they did it ugly ... not in rpm level... that was the status a year
> ago)
> 
> SO it will not work, as long we do not move to mod_nss.
> 
> In addition there wad an issue with mod_proxy and using 2 different SSL
> certificates (IPA & RHEV) on the same apache server.
> 
> 
> please make sure all the above are solved.

I just do not understand why we treat IPA in special way... it is as if we need to have knowledge of very application out there that hacks the apache.

Playing nice with mod_nss and not force mod_ssl or actually any is a positive move.

Thanks,
Alon

> 
> 
> Thanks
> Barak
> > 
> > I think I've enough info.
> > Thanks.
> > 
> > 
> > Il 06/05/2013 22:11, Alon Bar-Lev ha scritto:
> > >
> > > ----- Original Message -----
> > >> From: "Barak Azulay" <bazulay at redhat.com>
> > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "engine-devel"
> > >> <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> > >> Sent: Monday, May 6, 2013 10:42:02 PM
> > >> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must
> > >> use
> > >> Apache	proxy
> > >> (https://bugzilla.redhat.com/905754)
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On May 6, 2013, at 19:45, Alon Bar-Lev <alonbl at redhat.com> wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> I don't understand why you start discussion from start... there were
> > >>> some
> > >>> additional facts.
> > >>>
> > >>> So first answer:
> > >>> No we cannot assume we own the machine nor own the apache, nor own the
> > >>> postgresql. These assumptions made in the past were plain wrong and
> > >>> cause
> > >>> more harm than good, and eventually saved no resources nor efforts.
> > >>>
> > >>> At master we altered the ajp proxy configuration to be less
> > >>> intrusive[1][2].
> > >>>
> > >>> We split the http configuration into three:
> > >>> 1. Install ajp proxy per our URIs[1].
> > >>> 2. Optionally set root redirection from / to /ovirt-engine
> > >>> 3. Optionally configure mod_ssl with our certificate.
> > >> I don't know if this was already brought up,
> > >>
> > >> There is a conflict between our configuration and IPA's
> > >> IPA uses mod_nss and we use mod_proxy and mod_ssl , and this creates a
> > >> conflict.
> > >>
> > >> We can try move to mod_nss on upgrade and solve all issues
> > >>
> > >> Barak
> > > The fact that ovirt-engine depends on mod_ssl is a mistake... well, at
> > > least I think so.
> > > The product should not care how ssl is provided as long as it is
> > > provided.
> > >
> > > Personally, I think that product should not attempt to configure ssl at
> > > all, but provide the instructions of how to do so... But never the less,
> > > let's try to keep this to avoid argument.
> > >
> > > In case IPA is installed (and I really don't understand why should we
> > > care
> > > about IPA specifically, well, I actually do... as IPA makes the same
> > > faulty assumptions of 'owning' resources), the admin should just avoid
> > > selecting the 'set ovirt-engine as default page' and 'configure apache
> > > ssl', user should access ovirt-engine using:
> > > http://host/ovirt-engine
> > >
> > > It should work as long as there are no URI conflicts between products as
> > > I
> > > listed in previous message.
> > >
> > > Regards,
> > > Alon
> > >
> > >>> The mandatory apache configuration[1] does not alter any configuration
> > >>> file, hence the chance of conflict is the chance of conflict between
> > >>> ovirt-engine URIs and other product URIs.
> > >>>
> > >>> ovirt-engine URIs:
> > >>> ---
> > >>> /UserPortal
> > >>> /OvirtEngineWeb
> > >>> /webadmin
> > >>> /docs
> > >>> /spice
> > >>> /ca.crt
> > >>> /engine.ssh.key.txt
> > >>> /rhevm.ssh.key.txt
> > >>> /ovirt-engine-style.css
> > >>> /console.vv
> > >>> /api
> > >>> /ovirt-engine
> > >>> ---
> > >>>
> > >>> As we have done this without cooperation of developers we kept URIs
> > >>> as-is.
> > >>>
> > >>> URIs that cannot be changed until next major:
> > >>> /engine.ssh.key.txt
> > >>> /rhevm.ssh.key.txt
> > >>> /ca.crt
> > >>> /api [I guess, although we can provide migration path alternative]
> > >>>
> > >>> All the other can be moved into /ovirt-engine with cooperation of
> > >>> developers, especially UI and Virt developers, it should be easy to do
> > >>> this, and reduce the chance of conflict.
> > >>>
> > >>> Regards,
> > >>> Alon Bar-Lev.
> > >>>
> > >>> [1] http://gerrit.ovirt.org/#/c/13318/
> > >>> [2] http://gerrit.ovirt.org/#/c/14304/
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > >>>> To: "engine-devel" <engine-devel at ovirt.org>
> > >>>> Cc: "users" <users at ovirt.org>
> > >>>> Sent: Monday, May 6, 2013 6:32:08 PM
> > >>>> Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
> > >>>> Apache    proxy
> > >>>> (https://bugzilla.redhat.com/905754)
> > >>>>
> > >>>> Hi,
> > >>>> I'm working on https://bugzilla.redhat.com/905754, trying to have
> > >>>> Apache
> > >>>> proxy in all 3.3 installations.
> > >>>>
> > >>>> I'm looking in the code and I've found a point where I'm in doubt
> > >>>> about
> > >>>> how to handle the case.
> > >>>> The current engine-setup implementation perform some checks that
> > >>>> change
> > >>>> the behavior of the installer documented as:
> > >>>>
> > >>>> 1. Check whether the relevant httpd configuration files were changed,
> > >>>> as
> > >>>> it's an indication for the setup that the httpd application is being
> > >>>> actively used, Therefore we may need to ask (dynamic change) the user
> > >>>> whether to override this configuration.
> > >>>>
> > >>>> 2. Check if IPA is installed and drop port 80/443 support. What the
> > >>>> script really do is setting OVERRIDE_HTTPD_CONFIG default to False in
> > >>>> both cases and just for case 2 call also
> > >>>> setHttpPortsToNonProxyDefault.
> > >>>>
> > >>>>
> > >>>> About 1, if we can consider Apache "owned" by the engine we can drop
> > >>>> any
> > >>>> question to the user, else I think we need to ask what to do or abort
> > >>>> the setup considering the configuration as unsupported.
> > >>>>
> > >>>> About 2, it seems that the best solution for that is to abort the
> > >>>> setup
> > >>>> if IPA is found on the same system where
> > >>>> we're installing the engine.
> > >>>> As far I've understood having IPA and engine on the same host is not a
> > >>>> supported configuration.
> > >>>>
> > >>>>
> > >>>> What do you think about this?
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Sandro Bonazzola
> > >>>> Better technology. Faster innovation. Powered by community
> > >>>> collaboration.
> > >>>> See how it works at redhat.com
> > >>>>
> > >>>> _______________________________________________
> > >>>> 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
> > >>>
> > >>>
> > 
> > 
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community collaboration.
> > See how it works at redhat.com
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> 


From alonbl at redhat.com  Wed May  8 14:28:28 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 8 May 2013 10:28:28 -0400 (EDT)
Subject: [Engine-devel] [Users] 3.3 scratch or upgraded installation
 must use Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <129444276.5410211.1368022851515.JavaMail.root@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1990199020.4477969.1367858405918.JavaMail.root@redhat.com>
	<6D858B39-39FD-410E-9E8B-912AEE950624@redhat.com>
	<190022898.4562887.1367871118558.JavaMail.root@redhat.com>
	<518A4A37.7040506@redhat.com>
	<1674151596.12805405.1368018034731.JavaMail.root@redhat.com>
	<129444276.5410211.1368022851515.JavaMail.root@redhat.com>
Message-ID: <901811594.5412446.1368023308089.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Barak Azulay" <bazulay at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> Sent: Wednesday, May 8, 2013 5:20:51 PM
> Subject: Re: [Users] [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)
> 
> 
> 
> ----- Original Message -----
> > From: "Barak Azulay" <bazulay at redhat.com>
> > To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> > Sent: Wednesday, May 8, 2013 4:00:34 PM
> > Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> > Apache	proxy
> > (https://bugzilla.redhat.com/905754)
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> > > Sent: Wednesday, May 8, 2013 3:51:03 PM
> > > Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> > > Apache	proxy
> > > (https://bugzilla.redhat.com/905754)
> > > 
> > > Hello,
> > > if I've understood correctly then:
> > > - there is no reason for checking if user altered http configuration
> > > - proxy doesn't depend on any other related http configuration we do and
> > > does not alter any other configuration file, so we can do it without
> > > asking anything
> > > - if ipa is installed, engine-setup should issue a warning about it and
> > > default to No for 'set ovirt-engine as default page' and 'configure
> > > apache ssl'
> > 
> > 
> > AFAIU and I don't think it was changed, there is a conflict between IPA and
> > mod_ssl (they did it ugly ... not in rpm level... that was the status a
> > year
> > ago)
> > 
> > SO it will not work, as long we do not move to mod_nss.
> > 
> > In addition there wad an issue with mod_proxy and using 2 different SSL
> > certificates (IPA & RHEV) on the same apache server.
> > 
> > 
> > please make sure all the above are solved.
> 
> I just do not understand why we treat IPA in special way... it is as if we
> need to have knowledge of very application out there that hacks the apache.

What if IPA is installed after ovirt-engine?

> 
> Playing nice with mod_nss and not force mod_ssl or actually any is a positive
> move.
> 
> Thanks,
> Alon
> 
> > 
> > 
> > Thanks
> > Barak
> > > 
> > > I think I've enough info.
> > > Thanks.
> > > 
> > > 
> > > Il 06/05/2013 22:11, Alon Bar-Lev ha scritto:
> > > >
> > > > ----- Original Message -----
> > > >> From: "Barak Azulay" <bazulay at redhat.com>
> > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "engine-devel"
> > > >> <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> > > >> Sent: Monday, May 6, 2013 10:42:02 PM
> > > >> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must
> > > >> use
> > > >> Apache	proxy
> > > >> (https://bugzilla.redhat.com/905754)
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On May 6, 2013, at 19:45, Alon Bar-Lev <alonbl at redhat.com> wrote:
> > > >>
> > > >>> Hello,
> > > >>>
> > > >>> I don't understand why you start discussion from start... there were
> > > >>> some
> > > >>> additional facts.
> > > >>>
> > > >>> So first answer:
> > > >>> No we cannot assume we own the machine nor own the apache, nor own
> > > >>> the
> > > >>> postgresql. These assumptions made in the past were plain wrong and
> > > >>> cause
> > > >>> more harm than good, and eventually saved no resources nor efforts.
> > > >>>
> > > >>> At master we altered the ajp proxy configuration to be less
> > > >>> intrusive[1][2].
> > > >>>
> > > >>> We split the http configuration into three:
> > > >>> 1. Install ajp proxy per our URIs[1].
> > > >>> 2. Optionally set root redirection from / to /ovirt-engine
> > > >>> 3. Optionally configure mod_ssl with our certificate.
> > > >> I don't know if this was already brought up,
> > > >>
> > > >> There is a conflict between our configuration and IPA's
> > > >> IPA uses mod_nss and we use mod_proxy and mod_ssl , and this creates a
> > > >> conflict.
> > > >>
> > > >> We can try move to mod_nss on upgrade and solve all issues
> > > >>
> > > >> Barak
> > > > The fact that ovirt-engine depends on mod_ssl is a mistake... well, at
> > > > least I think so.
> > > > The product should not care how ssl is provided as long as it is
> > > > provided.
> > > >
> > > > Personally, I think that product should not attempt to configure ssl at
> > > > all, but provide the instructions of how to do so... But never the
> > > > less,
> > > > let's try to keep this to avoid argument.
> > > >
> > > > In case IPA is installed (and I really don't understand why should we
> > > > care
> > > > about IPA specifically, well, I actually do... as IPA makes the same
> > > > faulty assumptions of 'owning' resources), the admin should just avoid
> > > > selecting the 'set ovirt-engine as default page' and 'configure apache
> > > > ssl', user should access ovirt-engine using:
> > > > http://host/ovirt-engine
> > > >
> > > > It should work as long as there are no URI conflicts between products
> > > > as
> > > > I
> > > > listed in previous message.
> > > >
> > > > Regards,
> > > > Alon
> > > >
> > > >>> The mandatory apache configuration[1] does not alter any
> > > >>> configuration
> > > >>> file, hence the chance of conflict is the chance of conflict between
> > > >>> ovirt-engine URIs and other product URIs.
> > > >>>
> > > >>> ovirt-engine URIs:
> > > >>> ---
> > > >>> /UserPortal
> > > >>> /OvirtEngineWeb
> > > >>> /webadmin
> > > >>> /docs
> > > >>> /spice
> > > >>> /ca.crt
> > > >>> /engine.ssh.key.txt
> > > >>> /rhevm.ssh.key.txt
> > > >>> /ovirt-engine-style.css
> > > >>> /console.vv
> > > >>> /api
> > > >>> /ovirt-engine
> > > >>> ---
> > > >>>
> > > >>> As we have done this without cooperation of developers we kept URIs
> > > >>> as-is.
> > > >>>
> > > >>> URIs that cannot be changed until next major:
> > > >>> /engine.ssh.key.txt
> > > >>> /rhevm.ssh.key.txt
> > > >>> /ca.crt
> > > >>> /api [I guess, although we can provide migration path alternative]
> > > >>>
> > > >>> All the other can be moved into /ovirt-engine with cooperation of
> > > >>> developers, especially UI and Virt developers, it should be easy to
> > > >>> do
> > > >>> this, and reduce the chance of conflict.
> > > >>>
> > > >>> Regards,
> > > >>> Alon Bar-Lev.
> > > >>>
> > > >>> [1] http://gerrit.ovirt.org/#/c/13318/
> > > >>> [2] http://gerrit.ovirt.org/#/c/14304/
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > > >>>> To: "engine-devel" <engine-devel at ovirt.org>
> > > >>>> Cc: "users" <users at ovirt.org>
> > > >>>> Sent: Monday, May 6, 2013 6:32:08 PM
> > > >>>> Subject: [Engine-devel] 3.3 scratch or upgraded installation must
> > > >>>> use
> > > >>>> Apache    proxy
> > > >>>> (https://bugzilla.redhat.com/905754)
> > > >>>>
> > > >>>> Hi,
> > > >>>> I'm working on https://bugzilla.redhat.com/905754, trying to have
> > > >>>> Apache
> > > >>>> proxy in all 3.3 installations.
> > > >>>>
> > > >>>> I'm looking in the code and I've found a point where I'm in doubt
> > > >>>> about
> > > >>>> how to handle the case.
> > > >>>> The current engine-setup implementation perform some checks that
> > > >>>> change
> > > >>>> the behavior of the installer documented as:
> > > >>>>
> > > >>>> 1. Check whether the relevant httpd configuration files were
> > > >>>> changed,
> > > >>>> as
> > > >>>> it's an indication for the setup that the httpd application is being
> > > >>>> actively used, Therefore we may need to ask (dynamic change) the
> > > >>>> user
> > > >>>> whether to override this configuration.
> > > >>>>
> > > >>>> 2. Check if IPA is installed and drop port 80/443 support. What the
> > > >>>> script really do is setting OVERRIDE_HTTPD_CONFIG default to False
> > > >>>> in
> > > >>>> both cases and just for case 2 call also
> > > >>>> setHttpPortsToNonProxyDefault.
> > > >>>>
> > > >>>>
> > > >>>> About 1, if we can consider Apache "owned" by the engine we can drop
> > > >>>> any
> > > >>>> question to the user, else I think we need to ask what to do or
> > > >>>> abort
> > > >>>> the setup considering the configuration as unsupported.
> > > >>>>
> > > >>>> About 2, it seems that the best solution for that is to abort the
> > > >>>> setup
> > > >>>> if IPA is found on the same system where
> > > >>>> we're installing the engine.
> > > >>>> As far I've understood having IPA and engine on the same host is not
> > > >>>> a
> > > >>>> supported configuration.
> > > >>>>
> > > >>>>
> > > >>>> What do you think about this?
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Sandro Bonazzola
> > > >>>> Better technology. Faster innovation. Powered by community
> > > >>>> collaboration.
> > > >>>> See how it works at redhat.com
> > > >>>>
> > > >>>> _______________________________________________
> > > >>>> 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
> > > >>>
> > > >>>
> > > 
> > > 
> > > --
> > > Sandro Bonazzola
> > > Better technology. Faster innovation. Powered by community collaboration.
> > > See how it works at redhat.com
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > > 
> > > 
> > 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 


From bazulay at redhat.com  Wed May  8 19:02:29 2013
From: bazulay at redhat.com (Barak Azulay)
Date: Wed, 8 May 2013 15:02:29 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <129444276.5410211.1368022851515.JavaMail.root@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1990199020.4477969.1367858405918.JavaMail.root@redhat.com>
	<6D858B39-39FD-410E-9E8B-912AEE950624@redhat.com>
	<190022898.4562887.1367871118558.JavaMail.root@redhat.com>
	<518A4A37.7040506@redhat.com>
	<1674151596.12805405.1368018034731.JavaMail.root@redhat.com>
	<129444276.5410211.1368022851515.JavaMail.root@redhat.com>
Message-ID: <1259953792.13083016.1368039749490.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Barak Azulay" <bazulay at redhat.com>
> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> Sent: Wednesday, May 8, 2013 5:20:51 PM
> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)
> 
> 
> 
> ----- Original Message -----
> > From: "Barak Azulay" <bazulay at redhat.com>
> > To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> > Sent: Wednesday, May 8, 2013 4:00:34 PM
> > Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> > Apache	proxy
> > (https://bugzilla.redhat.com/905754)
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> > > Sent: Wednesday, May 8, 2013 3:51:03 PM
> > > Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> > > Apache	proxy
> > > (https://bugzilla.redhat.com/905754)
> > > 
> > > Hello,
> > > if I've understood correctly then:
> > > - there is no reason for checking if user altered http configuration
> > > - proxy doesn't depend on any other related http configuration we do and
> > > does not alter any other configuration file, so we can do it without
> > > asking anything
> > > - if ipa is installed, engine-setup should issue a warning about it and
> > > default to No for 'set ovirt-engine as default page' and 'configure
> > > apache ssl'
> > 
> > 
> > AFAIU and I don't think it was changed, there is a conflict between IPA and
> > mod_ssl (they did it ugly ... not in rpm level... that was the status a
> > year
> > ago)
> > 
> > SO it will not work, as long we do not move to mod_nss.
> > 
> > In addition there wad an issue with mod_proxy and using 2 different SSL
> > certificates (IPA & RHEV) on the same apache server.
> > 
> > 
> > please make sure all the above are solved.
> 
> I just do not understand why we treat IPA in special way... it is as if we
> need to have knowledge of very application out there that hacks the apache.
> 
> Playing nice with mod_nss and not force mod_ssl or actually any is a positive
> move.

The reason is that in 3.0 we supported IPA (and PMs even recommended to install it on the  same host as RHEVM so save HW)
So if someone continues with that deployment we should not break it.

Having said that - we need to handle any installation on any supported RHEL version, 
on those server one might have apache with other application, and you have said we should not assume we own the host.

Barak 


> 
> Thanks,
> Alon
> 
> > 
> > 
> > Thanks
> > Barak
> > > 
> > > I think I've enough info.
> > > Thanks.
> > > 
> > > 
> > > Il 06/05/2013 22:11, Alon Bar-Lev ha scritto:
> > > >
> > > > ----- Original Message -----
> > > >> From: "Barak Azulay" <bazulay at redhat.com>
> > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "engine-devel"
> > > >> <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> > > >> Sent: Monday, May 6, 2013 10:42:02 PM
> > > >> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must
> > > >> use
> > > >> Apache	proxy
> > > >> (https://bugzilla.redhat.com/905754)
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On May 6, 2013, at 19:45, Alon Bar-Lev <alonbl at redhat.com> wrote:
> > > >>
> > > >>> Hello,
> > > >>>
> > > >>> I don't understand why you start discussion from start... there were
> > > >>> some
> > > >>> additional facts.
> > > >>>
> > > >>> So first answer:
> > > >>> No we cannot assume we own the machine nor own the apache, nor own
> > > >>> the
> > > >>> postgresql. These assumptions made in the past were plain wrong and
> > > >>> cause
> > > >>> more harm than good, and eventually saved no resources nor efforts.
> > > >>>
> > > >>> At master we altered the ajp proxy configuration to be less
> > > >>> intrusive[1][2].
> > > >>>
> > > >>> We split the http configuration into three:
> > > >>> 1. Install ajp proxy per our URIs[1].
> > > >>> 2. Optionally set root redirection from / to /ovirt-engine
> > > >>> 3. Optionally configure mod_ssl with our certificate.
> > > >> I don't know if this was already brought up,
> > > >>
> > > >> There is a conflict between our configuration and IPA's
> > > >> IPA uses mod_nss and we use mod_proxy and mod_ssl , and this creates a
> > > >> conflict.
> > > >>
> > > >> We can try move to mod_nss on upgrade and solve all issues
> > > >>
> > > >> Barak
> > > > The fact that ovirt-engine depends on mod_ssl is a mistake... well, at
> > > > least I think so.
> > > > The product should not care how ssl is provided as long as it is
> > > > provided.
> > > >
> > > > Personally, I think that product should not attempt to configure ssl at
> > > > all, but provide the instructions of how to do so... But never the
> > > > less,
> > > > let's try to keep this to avoid argument.
> > > >
> > > > In case IPA is installed (and I really don't understand why should we
> > > > care
> > > > about IPA specifically, well, I actually do... as IPA makes the same
> > > > faulty assumptions of 'owning' resources), the admin should just avoid
> > > > selecting the 'set ovirt-engine as default page' and 'configure apache
> > > > ssl', user should access ovirt-engine using:
> > > > http://host/ovirt-engine
> > > >
> > > > It should work as long as there are no URI conflicts between products
> > > > as
> > > > I
> > > > listed in previous message.
> > > >
> > > > Regards,
> > > > Alon
> > > >
> > > >>> The mandatory apache configuration[1] does not alter any
> > > >>> configuration
> > > >>> file, hence the chance of conflict is the chance of conflict between
> > > >>> ovirt-engine URIs and other product URIs.
> > > >>>
> > > >>> ovirt-engine URIs:
> > > >>> ---
> > > >>> /UserPortal
> > > >>> /OvirtEngineWeb
> > > >>> /webadmin
> > > >>> /docs
> > > >>> /spice
> > > >>> /ca.crt
> > > >>> /engine.ssh.key.txt
> > > >>> /rhevm.ssh.key.txt
> > > >>> /ovirt-engine-style.css
> > > >>> /console.vv
> > > >>> /api
> > > >>> /ovirt-engine
> > > >>> ---
> > > >>>
> > > >>> As we have done this without cooperation of developers we kept URIs
> > > >>> as-is.
> > > >>>
> > > >>> URIs that cannot be changed until next major:
> > > >>> /engine.ssh.key.txt
> > > >>> /rhevm.ssh.key.txt
> > > >>> /ca.crt
> > > >>> /api [I guess, although we can provide migration path alternative]
> > > >>>
> > > >>> All the other can be moved into /ovirt-engine with cooperation of
> > > >>> developers, especially UI and Virt developers, it should be easy to
> > > >>> do
> > > >>> this, and reduce the chance of conflict.
> > > >>>
> > > >>> Regards,
> > > >>> Alon Bar-Lev.
> > > >>>
> > > >>> [1] http://gerrit.ovirt.org/#/c/13318/
> > > >>> [2] http://gerrit.ovirt.org/#/c/14304/
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > > >>>> To: "engine-devel" <engine-devel at ovirt.org>
> > > >>>> Cc: "users" <users at ovirt.org>
> > > >>>> Sent: Monday, May 6, 2013 6:32:08 PM
> > > >>>> Subject: [Engine-devel] 3.3 scratch or upgraded installation must
> > > >>>> use
> > > >>>> Apache    proxy
> > > >>>> (https://bugzilla.redhat.com/905754)
> > > >>>>
> > > >>>> Hi,
> > > >>>> I'm working on https://bugzilla.redhat.com/905754, trying to have
> > > >>>> Apache
> > > >>>> proxy in all 3.3 installations.
> > > >>>>
> > > >>>> I'm looking in the code and I've found a point where I'm in doubt
> > > >>>> about
> > > >>>> how to handle the case.
> > > >>>> The current engine-setup implementation perform some checks that
> > > >>>> change
> > > >>>> the behavior of the installer documented as:
> > > >>>>
> > > >>>> 1. Check whether the relevant httpd configuration files were
> > > >>>> changed,
> > > >>>> as
> > > >>>> it's an indication for the setup that the httpd application is being
> > > >>>> actively used, Therefore we may need to ask (dynamic change) the
> > > >>>> user
> > > >>>> whether to override this configuration.
> > > >>>>
> > > >>>> 2. Check if IPA is installed and drop port 80/443 support. What the
> > > >>>> script really do is setting OVERRIDE_HTTPD_CONFIG default to False
> > > >>>> in
> > > >>>> both cases and just for case 2 call also
> > > >>>> setHttpPortsToNonProxyDefault.
> > > >>>>
> > > >>>>
> > > >>>> About 1, if we can consider Apache "owned" by the engine we can drop
> > > >>>> any
> > > >>>> question to the user, else I think we need to ask what to do or
> > > >>>> abort
> > > >>>> the setup considering the configuration as unsupported.
> > > >>>>
> > > >>>> About 2, it seems that the best solution for that is to abort the
> > > >>>> setup
> > > >>>> if IPA is found on the same system where
> > > >>>> we're installing the engine.
> > > >>>> As far I've understood having IPA and engine on the same host is not
> > > >>>> a
> > > >>>> supported configuration.
> > > >>>>
> > > >>>>
> > > >>>> What do you think about this?
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Sandro Bonazzola
> > > >>>> Better technology. Faster innovation. Powered by community
> > > >>>> collaboration.
> > > >>>> See how it works at redhat.com
> > > >>>>
> > > >>>> _______________________________________________
> > > >>>> 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
> > > >>>
> > > >>>
> > > 
> > > 
> > > --
> > > Sandro Bonazzola
> > > Better technology. Faster innovation. Powered by community collaboration.
> > > See how it works at redhat.com
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > > 
> > > 
> > 
> 


From alonbl at redhat.com  Wed May  8 19:18:59 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 8 May 2013 15:18:59 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <1259953792.13083016.1368039749490.JavaMail.root@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1990199020.4477969.1367858405918.JavaMail.root@redhat.com>
	<6D858B39-39FD-410E-9E8B-912AEE950624@redhat.com>
	<190022898.4562887.1367871118558.JavaMail.root@redhat.com>
	<518A4A37.7040506@redhat.com>
	<1674151596.12805405.1368018034731.JavaMail.root@redhat.com>
	<129444276.5410211.1368022851515.JavaMail.root@redhat.com>
	<1259953792.13083016.1368039749490.JavaMail.root@redhat.com>
Message-ID: <2140554843.5508235.1368040739442.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Barak Azulay" <bazulay at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, May 8, 2013 10:02:29 PM
> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Barak Azulay" <bazulay at redhat.com>
> > Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> > Sent: Wednesday, May 8, 2013 5:20:51 PM
> > Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> > Apache	proxy
> > (https://bugzilla.redhat.com/905754)
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Barak Azulay" <bazulay at redhat.com>
> > > To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> > > Sent: Wednesday, May 8, 2013 4:00:34 PM
> > > Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> > > Apache	proxy
> > > (https://bugzilla.redhat.com/905754)
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> > > > Sent: Wednesday, May 8, 2013 3:51:03 PM
> > > > Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must
> > > > use
> > > > Apache	proxy
> > > > (https://bugzilla.redhat.com/905754)
> > > > 
> > > > Hello,
> > > > if I've understood correctly then:
> > > > - there is no reason for checking if user altered http configuration
> > > > - proxy doesn't depend on any other related http configuration we do
> > > > and
> > > > does not alter any other configuration file, so we can do it without
> > > > asking anything
> > > > - if ipa is installed, engine-setup should issue a warning about it and
> > > > default to No for 'set ovirt-engine as default page' and 'configure
> > > > apache ssl'
> > > 
> > > 
> > > AFAIU and I don't think it was changed, there is a conflict between IPA
> > > and
> > > mod_ssl (they did it ugly ... not in rpm level... that was the status a
> > > year
> > > ago)
> > > 
> > > SO it will not work, as long we do not move to mod_nss.
> > > 
> > > In addition there wad an issue with mod_proxy and using 2 different SSL
> > > certificates (IPA & RHEV) on the same apache server.
> > > 
> > > 
> > > please make sure all the above are solved.
> > 
> > I just do not understand why we treat IPA in special way... it is as if we
> > need to have knowledge of very application out there that hacks the apache.
> > 
> > Playing nice with mod_nss and not force mod_ssl or actually any is a
> > positive
> > move.
> 
> The reason is that in 3.0 we supported IPA (and PMs even recommended to
> install it on the  same host as RHEVM so save HW)
> So if someone continues with that deployment we should not break it.
> 
> Having said that - we need to handle any installation on any supported RHEL
> version,
> on those server one might have apache with other application, and you have
> said we should not assume we own the host.

Right.
First, we need to support any installation not just rhel.
Second, we can support only other well behaved products.
Until recently we were not well behaved... well we still not fully because we do not have our own configurable URI namespace.

We cannot control which applications are installed on the same host, however we can:

1. postgresql: support skipping the automatic provisioning [supported in the otopi setup]
2. apache: do not enforce specific apache SSL implementation [to be done].
3. apache: support skipping the automatic SSL configuration [supported].
4. apache: support skipping the root redirect to ovirt application [supported in otopi setup]
5. apache: move application to own name space, example /ovirt-engine [to be done, I will be happy if you can help pushing this]
6. firewall: support skipping configuration [supported]
7. packaging: remove the versionlock usage.
8. packaging: support proper upgrade path, compatible with packaging best practices.
9. files: rename all utilities and public artifacts from engine-* to ovirt-engine-*
[more?]

If we do the above we are acting as well behaved application, and can co-exist with other well behaved applications.

> 
> Barak
> 
> 
> > 
> > Thanks,
> > Alon
> > 
> > > 
> > > 
> > > Thanks
> > > Barak
> > > > 
> > > > I think I've enough info.
> > > > Thanks.
> > > > 
> > > > 
> > > > Il 06/05/2013 22:11, Alon Bar-Lev ha scritto:
> > > > >
> > > > > ----- Original Message -----
> > > > >> From: "Barak Azulay" <bazulay at redhat.com>
> > > > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > >> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "engine-devel"
> > > > >> <engine-devel at ovirt.org>, "users" <users at ovirt.org>
> > > > >> Sent: Monday, May 6, 2013 10:42:02 PM
> > > > >> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation
> > > > >> must
> > > > >> use
> > > > >> Apache	proxy
> > > > >> (https://bugzilla.redhat.com/905754)
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On May 6, 2013, at 19:45, Alon Bar-Lev <alonbl at redhat.com> wrote:
> > > > >>
> > > > >>> Hello,
> > > > >>>
> > > > >>> I don't understand why you start discussion from start... there
> > > > >>> were
> > > > >>> some
> > > > >>> additional facts.
> > > > >>>
> > > > >>> So first answer:
> > > > >>> No we cannot assume we own the machine nor own the apache, nor own
> > > > >>> the
> > > > >>> postgresql. These assumptions made in the past were plain wrong and
> > > > >>> cause
> > > > >>> more harm than good, and eventually saved no resources nor efforts.
> > > > >>>
> > > > >>> At master we altered the ajp proxy configuration to be less
> > > > >>> intrusive[1][2].
> > > > >>>
> > > > >>> We split the http configuration into three:
> > > > >>> 1. Install ajp proxy per our URIs[1].
> > > > >>> 2. Optionally set root redirection from / to /ovirt-engine
> > > > >>> 3. Optionally configure mod_ssl with our certificate.
> > > > >> I don't know if this was already brought up,
> > > > >>
> > > > >> There is a conflict between our configuration and IPA's
> > > > >> IPA uses mod_nss and we use mod_proxy and mod_ssl , and this creates
> > > > >> a
> > > > >> conflict.
> > > > >>
> > > > >> We can try move to mod_nss on upgrade and solve all issues
> > > > >>
> > > > >> Barak
> > > > > The fact that ovirt-engine depends on mod_ssl is a mistake... well,
> > > > > at
> > > > > least I think so.
> > > > > The product should not care how ssl is provided as long as it is
> > > > > provided.
> > > > >
> > > > > Personally, I think that product should not attempt to configure ssl
> > > > > at
> > > > > all, but provide the instructions of how to do so... But never the
> > > > > less,
> > > > > let's try to keep this to avoid argument.
> > > > >
> > > > > In case IPA is installed (and I really don't understand why should we
> > > > > care
> > > > > about IPA specifically, well, I actually do... as IPA makes the same
> > > > > faulty assumptions of 'owning' resources), the admin should just
> > > > > avoid
> > > > > selecting the 'set ovirt-engine as default page' and 'configure
> > > > > apache
> > > > > ssl', user should access ovirt-engine using:
> > > > > http://host/ovirt-engine
> > > > >
> > > > > It should work as long as there are no URI conflicts between products
> > > > > as
> > > > > I
> > > > > listed in previous message.
> > > > >
> > > > > Regards,
> > > > > Alon
> > > > >
> > > > >>> The mandatory apache configuration[1] does not alter any
> > > > >>> configuration
> > > > >>> file, hence the chance of conflict is the chance of conflict
> > > > >>> between
> > > > >>> ovirt-engine URIs and other product URIs.
> > > > >>>
> > > > >>> ovirt-engine URIs:
> > > > >>> ---
> > > > >>> /UserPortal
> > > > >>> /OvirtEngineWeb
> > > > >>> /webadmin
> > > > >>> /docs
> > > > >>> /spice
> > > > >>> /ca.crt
> > > > >>> /engine.ssh.key.txt
> > > > >>> /rhevm.ssh.key.txt
> > > > >>> /ovirt-engine-style.css
> > > > >>> /console.vv
> > > > >>> /api
> > > > >>> /ovirt-engine
> > > > >>> ---
> > > > >>>
> > > > >>> As we have done this without cooperation of developers we kept URIs
> > > > >>> as-is.
> > > > >>>
> > > > >>> URIs that cannot be changed until next major:
> > > > >>> /engine.ssh.key.txt
> > > > >>> /rhevm.ssh.key.txt
> > > > >>> /ca.crt
> > > > >>> /api [I guess, although we can provide migration path alternative]
> > > > >>>
> > > > >>> All the other can be moved into /ovirt-engine with cooperation of
> > > > >>> developers, especially UI and Virt developers, it should be easy to
> > > > >>> do
> > > > >>> this, and reduce the chance of conflict.
> > > > >>>
> > > > >>> Regards,
> > > > >>> Alon Bar-Lev.
> > > > >>>
> > > > >>> [1] http://gerrit.ovirt.org/#/c/13318/
> > > > >>> [2] http://gerrit.ovirt.org/#/c/14304/
> > > > >>>
> > > > >>> ----- Original Message -----
> > > > >>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > > > >>>> To: "engine-devel" <engine-devel at ovirt.org>
> > > > >>>> Cc: "users" <users at ovirt.org>
> > > > >>>> Sent: Monday, May 6, 2013 6:32:08 PM
> > > > >>>> Subject: [Engine-devel] 3.3 scratch or upgraded installation must
> > > > >>>> use
> > > > >>>> Apache    proxy
> > > > >>>> (https://bugzilla.redhat.com/905754)
> > > > >>>>
> > > > >>>> Hi,
> > > > >>>> I'm working on https://bugzilla.redhat.com/905754, trying to have
> > > > >>>> Apache
> > > > >>>> proxy in all 3.3 installations.
> > > > >>>>
> > > > >>>> I'm looking in the code and I've found a point where I'm in doubt
> > > > >>>> about
> > > > >>>> how to handle the case.
> > > > >>>> The current engine-setup implementation perform some checks that
> > > > >>>> change
> > > > >>>> the behavior of the installer documented as:
> > > > >>>>
> > > > >>>> 1. Check whether the relevant httpd configuration files were
> > > > >>>> changed,
> > > > >>>> as
> > > > >>>> it's an indication for the setup that the httpd application is
> > > > >>>> being
> > > > >>>> actively used, Therefore we may need to ask (dynamic change) the
> > > > >>>> user
> > > > >>>> whether to override this configuration.
> > > > >>>>
> > > > >>>> 2. Check if IPA is installed and drop port 80/443 support. What
> > > > >>>> the
> > > > >>>> script really do is setting OVERRIDE_HTTPD_CONFIG default to False
> > > > >>>> in
> > > > >>>> both cases and just for case 2 call also
> > > > >>>> setHttpPortsToNonProxyDefault.
> > > > >>>>
> > > > >>>>
> > > > >>>> About 1, if we can consider Apache "owned" by the engine we can
> > > > >>>> drop
> > > > >>>> any
> > > > >>>> question to the user, else I think we need to ask what to do or
> > > > >>>> abort
> > > > >>>> the setup considering the configuration as unsupported.
> > > > >>>>
> > > > >>>> About 2, it seems that the best solution for that is to abort the
> > > > >>>> setup
> > > > >>>> if IPA is found on the same system where
> > > > >>>> we're installing the engine.
> > > > >>>> As far I've understood having IPA and engine on the same host is
> > > > >>>> not
> > > > >>>> a
> > > > >>>> supported configuration.
> > > > >>>>
> > > > >>>>
> > > > >>>> What do you think about this?
> > > > >>>>
> > > > >>>>
> > > > >>>> --
> > > > >>>> Sandro Bonazzola
> > > > >>>> Better technology. Faster innovation. Powered by community
> > > > >>>> collaboration.
> > > > >>>> See how it works at redhat.com
> > > > >>>>
> > > > >>>> _______________________________________________
> > > > >>>> 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
> > > > >>>
> > > > >>>
> > > > 
> > > > 
> > > > --
> > > > Sandro Bonazzola
> > > > Better technology. Faster innovation. Powered by community
> > > > collaboration.
> > > > See how it works at redhat.com
> > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > > 
> > > > 
> > > 
> > 
> 


From mperina at redhat.com  Thu May  9 08:31:07 2013
From: mperina at redhat.com (Martin Perina)
Date: Thu, 9 May 2013 04:31:07 -0400 (EDT)
Subject: [Engine-devel] Device custom properties
In-Reply-To: <630764624.5980238.1367738287648.JavaMail.root@redhat.com>
References: <769095690.6355567.1367571965290.JavaMail.root@redhat.com>
	<647348214.6813403.1367644424985.JavaMail.root@redhat.com>
	<630764624.5980238.1367738287648.JavaMail.root@redhat.com>
Message-ID: <1294668272.9152957.1368088267298.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Martin Perina" <mperina at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Sunday, May 5, 2013 9:18:07 AM
> Subject: Re: [Engine-devel] Device custom properties
> 
> 
> 
> ----- Original Message -----
> > From: "Martin Perina" <mperina at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Saturday, May 4, 2013 8:13:44 AM
> > Subject: Re: [Engine-devel] Device custom properties
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Martin Perina" <mperina at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Friday, May 3, 2013 11:06:05 AM
> > > Subject: [Engine-devel] Device custom properties
> > > 
> > > Hi,
> > >  
> > > I'm currently trying to implement device custom properties infrastructure
> > > in
> > > ovirt-engine.
> > > During discussion with Yair, we found out, that it's not clear, for what
> > > type
> > > of devices
> > > custom properties should be available? In engine we have the VmDeviceType
> > > enum which
> > > contains following values:
> > >  
> > >      FLOPPY("floppy", "14"),
> > >      DISK("disk", "17"),
> > >      CDROM("cdrom", "15"),
> > >      INTERFACE("interface", "10"),
> > >      BRIDGE("bridge", "3"),
> > >      VIDEO("video", "20"),
> > >      USB("usb", "23"),
> > >      CONTROLLER("controller", "23"),
> > >      REDIR("redir", "23"),
> > >      SPICEVMC("spicevmc", "23"),
> > >      QXL("qxl"),
> > >      CIRRUS("cirrus"),
> > >      SOUND("sound"),
> > >      ICH6("ich6"),
> > >      AC97("ac97"),
> > >      MEMBALLOON("memballoon"),
> > >      SMARTCARD("smartcard"),
> > >      BALLOON("balloon"),
> > >      OTHER("other", "0"),
> > >      UNKNOWN("unknown", "-1");
> > >  
> > > But VmDevice class has two String attributes device and type. So for
> > > example
> > > a disk is a device
> > > which has device set to disk and type set to disk (according to
> > > VmDeviceCommonUtils.isDisk method).
> > >  
> > > So my question is, if I have a custom properties for disk, will they be
> > > available for all disk
> > > devices (disk, cdrom, floppy, ...) or only for real disk? So should we
> > > support custom properties
> > > for all VmDeviceType enum value separately?
> > > 
> > > Thanks for suggestions
> > > 
> > > Martin
> 
> The reason for that difference is that we had types in the backend code only
> for managed devices . (i.e. devoices that are known and handled by the
> backend)
> Any other device as balloon etc. is considered as unmanaged device , that
> means that VDSM tells us that it exists and therefore tell us its type as
> well...
> 
> 

Ok, I understand this.

But there are also OTHER and UNKNOWN device types in backend, but these types doesn't
corresponds to ANY type in VDSM. I don't want to refactor VmDevice device and type attributes
too much, so is it safe to expect that device attribute of VmDevice can only contain
one of VDSM device types ('disk', 'interface', 'video', 'sound', 'controller', 'balloon',
'channel', 'console', 'smartcard')? It's really important question, because replacing
String type with enum would save a lot of code in device custom properties implementation.

Martin



From mpastern at redhat.com  Thu May  9 09:27:35 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Thu, 09 May 2013 12:27:35 +0300
Subject: [Engine-devel] [REST-API] Support passing auth information
 without having to use HTTP Authorization header #958874
In-Reply-To: <1665518752.4971723.1367945088296.JavaMail.root@redhat.com>
References: <518751C7.8090208@redhat.com>
	<1665518752.4971723.1367945088296.JavaMail.root@redhat.com>
Message-ID: <518B6C07.1080504@redhat.com>

On 05/07/2013 07:44 PM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>,
>> "Itamar Heim" <iheim at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Monday, May 6, 2013 9:46:31 AM
>> Subject: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
>>
>>
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=958874
>>
>> Hi Alon,
>>
>> (In reply to comment #2)
>>>
>>> Regardless of this specific RFE I would like to write that I don't like the
>>> REST API session mechanism
>>> [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as it
>>> relays on cookies and not explicit API interaction.
>>
>> authentication in RESTful application is a matter of debate, it can be
>> achieved
>> in various ways, but session + cookie auth. method is very common and usually
>> effective,
>>
>> it's biggest disadvantage is that it's not exactly RESfull cause client
>> have to maintain (story) the cookie and not the server (but i wouldn't call
>> it an
>> issue at all), besides that it's works perfectly well from the REST PoV,
>>
>> also some may say that cookies are not strong enough and OAuth for instance
>> should be used instead, but this is a different story cause in our case,
>> cookie
>> are for the clients (not browsers [1]) that can store them in a secure way or
>> even
>> not to store at all (in-memory cookie).
>>
>> [1] another disadvantage is that webbrowsers not able to access cookie
>> namespace,
>> but lately i've suggested URI based authentication [2] to support web
>> browsers
>> as well.
>>
>> [2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html
>>
>> the biggest advantage of the cookie is a session expiration that maintained
>> by the server and abstracted from the client what is much better from
>> security
>> PoV than standard authentication mechanisms such as HTTP basic auth for
>> instance
>> which can be potentially cached.
> 
> Expiration is always managed by server side, regardless the cookie vs ticket debate.
> 
>>
>>> I would have expected a
>>> 'ticket' to be retrieved and that 'ticket' to be disconnected from the
>>> application server objects. Although we can refer the 'cookie' as a ticket,
>>> however the requirement to parse it should not be required, there be a
>>> conflict between two separate applications running on same server, and
>>> there
>>> may be a problem to transfer credentials between servers.
>>
>> well, this is not exactly correct:
>>
>> 1. client desn't have to decode/parse the cookie and pass credentials, all it
>> need is
>>    just to store the cookie and pass it as is to server on every request.
> 
> You just described what cookies are.
> And if I understand we want better control of application authentication, disconnected from 'default browser behavior'.
> 
>> 2. "conflict between two separate applications running on same server"?
>> different cookie
>>    uses different domain & path by spec., can you pls explain what do you
>>    mean by this?
> 
> If you call the cookie JSESSIONID....

different applications cannot live under same path,
this what for cookie has a "path" attribute,

but it can create a bit of confusion indeed, but you not
talking with more than one application in same time right ?!,
i.e container/client fetches the JSESSIONID cookie from the
specific request/response,

so i'm not sure how possibly client can get in reply two
cookies with a same name (even if all applications are using
same cookie)

>  
>>>
>>> If we modify authentication we should support more authentication types, at
>>> least SPNEGO.
>>>
>>> In order to allow SPNEGO and other authentication mechanisms, we better
>>> force people to use single URI to perform the login and return
>>> authenticated
>>> 'ticket' to continue interaction with application.
>>
>> this is good for the backend authentication, but is not for the RESTful
>> application, it's like buying an aeroplane and driving it on a road,
> 
> And why is that? who are you to decide what authentication mechanism is to be used by customers?

alon, you misunderstood, i'm not talking about authentication method,
but about your sentence ^ "we better force people to use single URI"

> If customer has a policy of not transmitting passwords over the network, then SPENGO is your friend. 
> But let's ignore it for now.

cookie is not any different from the SPENGO token in this meaning,
it's just another data container.

> 
>> "force people to use single URI to perform the login" means SOAP while we
>> wanted REST
>> where any URI is considered as entry point and actually a resource address
>> that should
>> be accessible/manipulatable and authentication should be
>> abstracted/disconnected from
>> this concept.
> 
> Again, you provide statements that are not written in stone.

this is main REST principal.

> Having custom authentication header breaks the 'plain simple rest'.
> Having a URI is only makes it easier to manage this breakage.

for us, but this is breaks a REST concept.

> 
>> SPNEGO is only an implementation detail that can be abstracted for the API.
> 
> I don't follow.
> 
>>> This will be much simpler
>>> implementation at the api side and much more efficient, and as we are
>>> discussion application-to-application interaction there should be no user
>>> experience visible issues.
>>
>> i'm not sure: "force people to use single URI to perform the login" and no
>> "no user experience visible issues."?
> 
> Please describe how the prefer mechanism suggested can be implemented in standard browser.

it cannot because authorization header has to be supplied only when
client wishes to reinitialize the JSESSION, and web browsers can't omit
it during the lifetime.

all this cause we don't support web browsers in api yet, session based
authentication mechanism was designed for http clients,

and this why we having this discussion, currently options are:

1. adapt session based authentication
2. introduce new concept

personally i prefer #1 as it's less noisy and easily achievable.

> And if it cannot, and custom logic is required, why a custom logic that accesses a custom URI to perform login is any different.

it's not RESTful

>  
>>>
>>> What I recommend is purely applicative rest login command...
>>
>> IIUC this is SOAP and not REST ...
> 
> Again... please refrain from these kind of void statements.
> SOAP is a protocol, it has specific format and rules.
> It may or may not use this or any other suggested authentication mechanism.

i'm not talking about the protocol, but about the conceptual differences
between SOAP and REST services.

SOAP is a RPC (Remote Procedure Call) and has single entry point on which
different methods are invoked, having single dedicated method for login
works in this case,

REST is a ROA (Resource Oriented Architecture), i.e everything is REST is a
resource, and you have to operate on these resources, authentication is only
an implementation detail that should not break this concept.

now saying this i think is clear that you have no place to put at the login()
method you've mentioned,

standard way for authentication in REST/HTTP is via 'authorization' header (per request),
optimizing this we've introduced new concept via sessionid,

user can choose between two by passing 'prefer:persistent_auth' header,

hope it's clear now, please let me know otherwise.

>  
>>> ---
>>> Input: authentication type, authentication credentials
>>>     authentication=http
>>>     authentication=password
>>>     credentials:
>>>         user=user
>>>         password=password
>>>     [OPTIONALLY] HTTP authentication headers
>>> Output:
>>>     ticket
>>>     ticket issue time (required to avoid clock sync)
>>>     ticket expiration time
>>> Logic:
>>> if authentication is http, use http authentication headers to establish
>>> user
>>> authentication. This will allow future SSO.
>>> if authentication is password, use embedded credentials.
>>> ---
>>>
>>> For every other rest call add http header:
>>>     oVirt-Authentication-Ticket: <ticket>
>>
>> this is not any different from the today's session based auth. only
>> instead of  oVirt-Authentication-Ticket added cookie.
> 
> I did not claim otherwise, I wrote that I don't like cookies, I do like explicit headers.
> As I wrote, cookies has limited storage at client, cookies may conflict, cookies has issues with clusters.
> Headers do not.

using headers has own drawbacks, WebAdmin core is not only entity that
requires authentication in the app, i'll give you one use-case:

today we have plugin interface in WebAdmin, WebAdmin may have different
plugins installed, to maintain different permissions for every plugin,
each will have to send own authorization data on every request,

as you see this turns to be truly complex, almost not feasible via headers,

btw in other thread i suggested to used URL parameters for passing authentication
tokens.

> 
>>>
>>> The backend side will attach the correct security context to the action if
>>> the header is received.
>>
>> this is how it's works today.
> 
> I could not imagine that.
>  
> 
> Regards,
> Alon
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From wlbleaboy at 126.com  Thu May  9 10:42:51 2013
From: wlbleaboy at 126.com (leaboy@126)
Date: Thu, 9 May 2013 18:42:51 +0800
Subject: [Engine-devel] =?gb2312?b?tPC4tDogRW5naW5lLWRldmVsIERpZ2VzdCwg?=
	=?gb2312?b?Vm9sIDIwLCBJc3N1ZSAyMw==?=
In-Reply-To: <mailman.13.1367942402.19042.engine-devel@ovirt.org>
References: <mailman.13.1367942402.19042.engine-devel@ovirt.org>
Message-ID: <000d01ce4ca1$f5952140$e0bf63c0$@com>

When admin create a vm, and give user a usb permission.
Now login to the vm, when you inject a usb-cd, I think it could be used.
I just guess it, not tested.

-----????-----
???: engine-devel-bounces at ovirt.org
[mailto:engine-devel-bounces at ovirt.org] ?? engine-devel-request at ovirt.org
????: 2013?5?8? 0:00
???: engine-devel at ovirt.org
??: Engine-devel Digest, Vol 20, Issue 23

Send Engine-devel mailing list submissions to
	engine-devel at ovirt.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.ovirt.org/mailman/listinfo/engine-devel
or, via email, send a message with subject or body 'help' to
	engine-devel-request at ovirt.org

You can reach the person managing the list at
	engine-devel-owner at ovirt.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Engine-devel digest..."


Today's Topics:

   1. Re: ovirt user portal and attach a cd (Andrej Bagon)


----------------------------------------------------------------------

Message: 1
Date: Tue, 07 May 2013 11:58:29 +0200
From: Andrej Bagon <andrej.bagon at arnes.si>
To: engine-devel at ovirt.org
Subject: Re: [Engine-devel] ovirt user portal and attach a cd
Message-ID: <5188D045.8030004 at arnes.si>
Content-Type: text/plain; charset=ISO-8859-1

How to use spice on windows, but anyway what about on linux?

Best Regards,
Andrej

On 04/29/2013 12:06 PM, Andrej Bagon wrote:
> We are using oVirt Engine Version: 3.2.1-1.beta1.el6 and linux
> environment (and vnc for console). Never tried spice console.
>
> Best Regards,
> Andrej
>
> On 04/29/2013 11:12 AM, Omer Frenkel wrote:
>> ----- Original Message -----
>>> From: "Andrej Bagon" <andrej.bagon at arnes.si>
>>> To: engine-devel at ovirt.org
>>> Sent: Monday, April 29, 2013 11:28:39 AM
>>> Subject: [Engine-devel] ovirt user portal and attach a cd
>>>
>>> Hi all,
>>>
>>> we would like to limit a user as much as possible and give him only
>>> actions that he needs with his VM. If we disallow a user the right in
>>> system|configure system|manipulate permissions), we give the user, in
>>> user portal, only basic mode. But then three is no option to attach a cd
>>> in the basic user portal. In basic mode user interface there is no
>>> chance in attaching a cd (as this is a basic operation a solution to
>>> this would be a button attaching a cd when starting a vm).
>>>
>>> If we allow the user to manipulate permissions, we get the extended menu
>>> back and the user is limited, but we found unacceptable when he is
>>> adding permission to the VM, he sees all the users (name, surname,
>>> email!) in the ovirt authentication mechanism? A solution to this would
>>> be authenticating to the directory service as a user an not as ovirt
>>> admin user - meaning that the user will see only users that we allowed
>>> he sees in the ldap directory.
>>>
>>> Thank you.
>>>
>>> Best Regards,
>>> Andrej
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> well if you only need to change cd for vm,
>> permission wise, the userRole and basic user portal are enough, 
>> iirc, if using spice (on windows?) that used to be possible, this may be
related:
>> https://bugzilla.redhat.com/show_bug.cgi?id=957611
>>
> _______________________________________________
> 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


End of Engine-devel Digest, Vol 20, Issue 23
********************************************




From mperina at redhat.com  Thu May  9 11:17:58 2013
From: mperina at redhat.com (Martin Perina)
Date: Thu, 9 May 2013 07:17:58 -0400 (EDT)
Subject: [Engine-devel] Device custom properties
In-Reply-To: <1294668272.9152957.1368088267298.JavaMail.root@redhat.com>
References: <769095690.6355567.1367571965290.JavaMail.root@redhat.com>
	<647348214.6813403.1367644424985.JavaMail.root@redhat.com>
	<630764624.5980238.1367738287648.JavaMail.root@redhat.com>
	<1294668272.9152957.1368088267298.JavaMail.root@redhat.com>
Message-ID: <1036148636.9251676.1368098278836.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Martin Perina" <mperina at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, May 9, 2013 10:31:07 AM
> Subject: Re: [Engine-devel] Device custom properties
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Martin Perina" <mperina at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Sunday, May 5, 2013 9:18:07 AM
> > Subject: Re: [Engine-devel] Device custom properties
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Martin Perina" <mperina at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Saturday, May 4, 2013 8:13:44 AM
> > > Subject: Re: [Engine-devel] Device custom properties
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Martin Perina" <mperina at redhat.com>
> > > > To: engine-devel at ovirt.org
> > > > Sent: Friday, May 3, 2013 11:06:05 AM
> > > > Subject: [Engine-devel] Device custom properties
> > > > 
> > > > Hi,
> > > >  
> > > > I'm currently trying to implement device custom properties
> > > > infrastructure
> > > > in
> > > > ovirt-engine.
> > > > During discussion with Yair, we found out, that it's not clear, for
> > > > what
> > > > type
> > > > of devices
> > > > custom properties should be available? In engine we have the
> > > > VmDeviceType
> > > > enum which
> > > > contains following values:
> > > >  
> > > >      FLOPPY("floppy", "14"),
> > > >      DISK("disk", "17"),
> > > >      CDROM("cdrom", "15"),
> > > >      INTERFACE("interface", "10"),
> > > >      BRIDGE("bridge", "3"),
> > > >      VIDEO("video", "20"),
> > > >      USB("usb", "23"),
> > > >      CONTROLLER("controller", "23"),
> > > >      REDIR("redir", "23"),
> > > >      SPICEVMC("spicevmc", "23"),
> > > >      QXL("qxl"),
> > > >      CIRRUS("cirrus"),
> > > >      SOUND("sound"),
> > > >      ICH6("ich6"),
> > > >      AC97("ac97"),
> > > >      MEMBALLOON("memballoon"),
> > > >      SMARTCARD("smartcard"),
> > > >      BALLOON("balloon"),
> > > >      OTHER("other", "0"),
> > > >      UNKNOWN("unknown", "-1");
> > > >  
> > > > But VmDevice class has two String attributes device and type. So for
> > > > example
> > > > a disk is a device
> > > > which has device set to disk and type set to disk (according to
> > > > VmDeviceCommonUtils.isDisk method).
> > > >  
> > > > So my question is, if I have a custom properties for disk, will they be
> > > > available for all disk
> > > > devices (disk, cdrom, floppy, ...) or only for real disk? So should we
> > > > support custom properties
> > > > for all VmDeviceType enum value separately?
> > > > 
> > > > Thanks for suggestions
> > > > 
> > > > Martin
> > 
> > The reason for that difference is that we had types in the backend code
> > only
> > for managed devices . (i.e. devoices that are known and handled by the
> > backend)
> > Any other device as balloon etc. is considered as unmanaged device , that
> > means that VDSM tells us that it exists and therefore tell us its type as
> > well...
> > 
> > 
> 
> Ok, I understand this.
> 
> But there are also OTHER and UNKNOWN device types in backend, but these types
> doesn't
> corresponds to ANY type in VDSM. I don't want to refactor VmDevice device and
> type attributes
> too much, so is it safe to expect that device attribute of VmDevice can only
> contain
> one of VDSM device types ('disk', 'interface', 'video', 'sound',
> 'controller', 'balloon',
> 'channel', 'console', 'smartcard')? It's really important question, because
> replacing
> String type with enum would save a lot of code in device custom properties
> implementation.
> 

Sorry, I wrote wrong attribute. Do you think it's safe to expect that type attribute
of VmDevice can only contain one of VDSM device types ('disk', 'interface', 'video', 'sound',
'controller', 'balloon', 'channel', 'console', 'smartcard')?

Martin


From yzaslavs at redhat.com  Thu May  9 19:41:08 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Thu, 9 May 2013 15:41:08 -0400 (EDT)
Subject: [Engine-devel] Device custom properties
In-Reply-To: <1036148636.9251676.1368098278836.JavaMail.root@redhat.com>
References: <769095690.6355567.1367571965290.JavaMail.root@redhat.com>
	<647348214.6813403.1367644424985.JavaMail.root@redhat.com>
	<630764624.5980238.1367738287648.JavaMail.root@redhat.com>
	<1294668272.9152957.1368088267298.JavaMail.root@redhat.com>
	<1036148636.9251676.1368098278836.JavaMail.root@redhat.com>
Message-ID: <2126652954.9344288.1368128468885.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Martin Perina" <mperina at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, May 9, 2013 2:17:58 PM
> Subject: Re: [Engine-devel] Device custom properties
> 
> 
> 
> ----- Original Message -----
> > From: "Martin Perina" <mperina at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Thursday, May 9, 2013 10:31:07 AM
> > Subject: Re: [Engine-devel] Device custom properties
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Martin Perina" <mperina at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Sunday, May 5, 2013 9:18:07 AM
> > > Subject: Re: [Engine-devel] Device custom properties
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Martin Perina" <mperina at redhat.com>
> > > > To: engine-devel at ovirt.org
> > > > Sent: Saturday, May 4, 2013 8:13:44 AM
> > > > Subject: Re: [Engine-devel] Device custom properties
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Martin Perina" <mperina at redhat.com>
> > > > > To: engine-devel at ovirt.org
> > > > > Sent: Friday, May 3, 2013 11:06:05 AM
> > > > > Subject: [Engine-devel] Device custom properties
> > > > > 
> > > > > Hi,
> > > > >  
> > > > > I'm currently trying to implement device custom properties
> > > > > infrastructure
> > > > > in
> > > > > ovirt-engine.
> > > > > During discussion with Yair, we found out, that it's not clear, for
> > > > > what
> > > > > type
> > > > > of devices
> > > > > custom properties should be available? In engine we have the
> > > > > VmDeviceType
> > > > > enum which
> > > > > contains following values:
> > > > >  
> > > > >      FLOPPY("floppy", "14"),
> > > > >      DISK("disk", "17"),
> > > > >      CDROM("cdrom", "15"),
> > > > >      INTERFACE("interface", "10"),
> > > > >      BRIDGE("bridge", "3"),
> > > > >      VIDEO("video", "20"),
> > > > >      USB("usb", "23"),
> > > > >      CONTROLLER("controller", "23"),
> > > > >      REDIR("redir", "23"),
> > > > >      SPICEVMC("spicevmc", "23"),
> > > > >      QXL("qxl"),
> > > > >      CIRRUS("cirrus"),
> > > > >      SOUND("sound"),
> > > > >      ICH6("ich6"),
> > > > >      AC97("ac97"),
> > > > >      MEMBALLOON("memballoon"),
> > > > >      SMARTCARD("smartcard"),
> > > > >      BALLOON("balloon"),
> > > > >      OTHER("other", "0"),
> > > > >      UNKNOWN("unknown", "-1");
> > > > >  
> > > > > But VmDevice class has two String attributes device and type. So for
> > > > > example
> > > > > a disk is a device
> > > > > which has device set to disk and type set to disk (according to
> > > > > VmDeviceCommonUtils.isDisk method).
> > > > >  
> > > > > So my question is, if I have a custom properties for disk, will they
> > > > > be
> > > > > available for all disk
> > > > > devices (disk, cdrom, floppy, ...) or only for real disk? So should
> > > > > we
> > > > > support custom properties
> > > > > for all VmDeviceType enum value separately?
> > > > > 
> > > > > Thanks for suggestions
> > > > > 
> > > > > Martin
> > > 
> > > The reason for that difference is that we had types in the backend code
> > > only
> > > for managed devices . (i.e. devoices that are known and handled by the
> > > backend)
> > > Any other device as balloon etc. is considered as unmanaged device , that
> > > means that VDSM tells us that it exists and therefore tell us its type as
> > > well...
> > > 
> > > 
> > 
> > Ok, I understand this.
> > 
> > But there are also OTHER and UNKNOWN device types in backend, but these
> > types
> > doesn't
> > corresponds to ANY type in VDSM. I don't want to refactor VmDevice device
> > and
> > type attributes
> > too much, so is it safe to expect that device attribute of VmDevice can
> > only
> > contain
> > one of VDSM device types ('disk', 'interface', 'video', 'sound',
> > 'controller', 'balloon',
> > 'channel', 'console', 'smartcard')? It's really important question, because
> > replacing
> > String type with enum would save a lot of code in device custom properties
> > implementation.
> > 
> 
> Sorry, I wrote wrong attribute. Do you think it's safe to expect that type
> attribute
> of VmDevice can only contain one of VDSM device types ('disk', 'interface',
> 'video', 'sound',
> 'controller', 'balloon', 'channel', 'console', 'smartcard')?

That sounds good to me.
I support this apporach.
> 
> Martin
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From wlbleaboy at 126.com  Fri May 10 02:06:10 2013
From: wlbleaboy at 126.com (leaboy@126)
Date: Fri, 10 May 2013 10:06:10 +0800
Subject: [Engine-devel] Build ovirt-engine with Eclipse
Message-ID: <001301ce4d22$f1559e30$d400da90$@com>

Hi, all:

         I want to know which IDE or environment you are using to develop
ovirt-engine,

Recently, I want to build and debug ovirt-engine with Eclipse, but when I
install all the 

plugins for build it in eclipse, and install jboss and postgre-sql, and then
how can I 

built it , and deploy it, and debug it . 

         I tried to use eclipse like
http://www.ovirt.org/Building_Ovirt_Engine/IDE , but

failed.

 

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

From yzaslavs at redhat.com  Fri May 10 04:08:10 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Fri, 10 May 2013 00:08:10 -0400 (EDT)
Subject: [Engine-devel] Build ovirt-engine with Eclipse
In-Reply-To: <001301ce4d22$f1559e30$d400da90$@com>
References: <001301ce4d22$f1559e30$d400da90$@com>
Message-ID: <1225961268.9448650.1368158890285.JavaMail.root@redhat.com>

Why did you fail? Provide info. 
I use Eclipse Juno. 

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

> From: "leaboy at 126" <wlbleaboy at 126.com>
> To: engine-devel at ovirt.org
> Sent: Friday, May 10, 2013 5:06:10 AM
> Subject: [Engine-devel] Build ovirt-engine with Eclipse

> Hi, all:

> I want to know which IDE or environment you are using to develop
> ovirt-engine,

> Recently, I want to build and debug ovirt-engine with Eclipse, but when I
> install all the

> plugins for build it in eclipse, and install jboss and postgre-sql, and then
> how can I

> built it , and deploy it, and debug it .

> I tried to use eclipse like http://www.ovirt.org/Building_Ovirt_Engine/IDE ,
> but

> failed.

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130510/6fd000f4/attachment.html>

From sbonazzo at redhat.com  Fri May 10 06:42:08 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 10 May 2013 08:42:08 +0200
Subject: [Engine-devel] [Users] Migrating engine-setup to otopi
In-Reply-To: <1312946802.45687257.1363256019367.JavaMail.root@redhat.com>
References: <1312946802.45687257.1363256019367.JavaMail.root@redhat.com>
Message-ID: <518C96C0.8000201@redhat.com>

Hi all,
The patch introducing the new implementation is now under review:
http://gerrit.ovirt.org/14612


Il 14/03/2013 11:13, Alex Lourie ha scritto:
> Hi All 
>
> Recent development of the otopi [1] framework allows us to migrate the engine-setup,
> upgrade and cleanup (and potentially other) utilities to implementation as an otopi
> plugin.
>
> Potential benefits of such a move are:
>
> 1. Be able to port engine to other distributions.
> 2. Be able to install engine in a development mode.
> 3. Be able to customize installation easily.
> 4. Share installation of components (reports, dwh).
> 5. Modular implementation, reduce maintenance costs.
> 6. Code reuse of installer code for multiple purposes (host-deploy,
> enigne-setup).
>   
> Currently we are in the process of creating a 'setup' plugin for 
> the otopi, and the progress can be monitored at [2]. The current
> roadmap for the feature is as follows:
>
> 1. Recreate the configuration utilities as plugins in otopi.
> 2. Support side-by side installation using both the old and the 
> new utilities.
> 3. Switch to the new utility when the confidence that it is on-par
> with an old one is high.
>
> Our goal is to have the new utilities ready for 3.3 release (at 
> least for the step 2 in the roadmap).
>
> We'd like to hear as much feedback as possible, so we could
> address it as soon as possible.
>
> Thanks!
>
> [1] http://gerrit.ovirt.org/#/q/project:otopi,n,z
> [2] http://www.ovirt.org/Features/Otopi_Infra_Migration
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From wanglibo at tongfangcloud.com  Fri May 10 02:05:11 2013
From: wanglibo at tongfangcloud.com (wanglibo)
Date: Fri, 10 May 2013 10:05:11 +0800
Subject: [Engine-devel] Build ovirt-engine with Eclipse
Message-ID: <000e01ce4d22$ce260cb0$6a722610$@com>

Hi, all:

         I want to know which IDE or environment you are using to develop
ovirt-engine,

Recently, I want to build and debug ovirt-engine with Eclipse, but when I
install all the 

plugins for build it in eclipse, and install jboss and postgre-sql, and then
how can I 

built it , and deploy it, and debug it . 

         I tried to use eclipse like
http://www.ovirt.org/Building_Ovirt_Engine/IDE , but

failed.

 

 

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

From iheim at redhat.com  Fri May 10 08:46:10 2013
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 10 May 2013 11:46:10 +0300
Subject: [Engine-devel] ovirt user portal and attach a cd
In-Reply-To: <5188D045.8030004@arnes.si>
References: <517E2F37.3010807@arnes.si>
	<1682099686.6160454.1367226745207.JavaMail.root@redhat.com>
	<517E4629.5050001@arnes.si> <5188D045.8030004@arnes.si>
Message-ID: <518CB3D2.5030605@redhat.com>

On 05/07/2013 12:58 PM, Andrej Bagon wrote:
> How to use spice on windows, but anyway what about on linux?

spice supports both windows and linux, and as mentioned, the change-cd 
feature.

this is a good starting point:
http://wiki.ovirt.org/How_to_Connect_to_SPICE_Console_With_Portal

>
> Best Regards,
> Andrej
>
> On 04/29/2013 12:06 PM, Andrej Bagon wrote:
>> We are using oVirt Engine Version: 3.2.1-1.beta1.el6 and linux
>> environment (and vnc for console). Never tried spice console.
>>
>> Best Regards,
>> Andrej
>>
>> On 04/29/2013 11:12 AM, Omer Frenkel wrote:
>>> ----- Original Message -----
>>>> From: "Andrej Bagon" <andrej.bagon at arnes.si>
>>>> To: engine-devel at ovirt.org
>>>> Sent: Monday, April 29, 2013 11:28:39 AM
>>>> Subject: [Engine-devel] ovirt user portal and attach a cd
>>>>
>>>> Hi all,
>>>>
>>>> we would like to limit a user as much as possible and give him only
>>>> actions that he needs with his VM. If we disallow a user the right in
>>>> system|configure system|manipulate permissions), we give the user, in
>>>> user portal, only basic mode. But then three is no option to attach a cd
>>>> in the basic user portal. In basic mode user interface there is no
>>>> chance in attaching a cd (as this is a basic operation a solution to
>>>> this would be a button attaching a cd when starting a vm).
>>>>
>>>> If we allow the user to manipulate permissions, we get the extended menu
>>>> back and the user is limited, but we found unacceptable when he is
>>>> adding permission to the VM, he sees all the users (name, surname,
>>>> email!) in the ovirt authentication mechanism? A solution to this would
>>>> be authenticating to the directory service as a user an not as ovirt
>>>> admin user - meaning that the user will see only users that we allowed
>>>> he sees in the ldap directory.
>>>>
>>>> Thank you.
>>>>
>>>> Best Regards,
>>>> Andrej
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>> well if you only need to change cd for vm,
>>> permission wise, the userRole and basic user portal are enough,
>>> iirc, if using spice (on windows?) that used to be possible, this may be related:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=957611
>>>
>> _______________________________________________
>> 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 andrej.bagon at arnes.si  Fri May 10 09:01:30 2013
From: andrej.bagon at arnes.si (Andrej Bagon)
Date: Fri, 10 May 2013 11:01:30 +0200
Subject: [Engine-devel] ovirt user portal and attach a cd
In-Reply-To: <518CB3D2.5030605@redhat.com>
References: <517E2F37.3010807@arnes.si>
	<1682099686.6160454.1367226745207.JavaMail.root@redhat.com>
	<517E4629.5050001@arnes.si> <5188D045.8030004@arnes.si>
	<518CB3D2.5030605@redhat.com>
Message-ID: <518CB76A.3090407@arnes.si>

Dear Itamar,

while pressing the http://elmarco.fedorapeople.org/spice.cab download
link there is a file Not Found. There is no .cab file in the directory
listing either.

Best Regards,
Andrej

On 05/10/2013 10:46 AM, Itamar Heim wrote:
> On 05/07/2013 12:58 PM, Andrej Bagon wrote:
>> How to use spice on windows, but anyway what about on linux?
>
> spice supports both windows and linux, and as mentioned, the change-cd
> feature.
>
> this is a good starting point:
> http://wiki.ovirt.org/How_to_Connect_to_SPICE_Console_With_Portal
>
>>
>> Best Regards,
>> Andrej
>>
>> On 04/29/2013 12:06 PM, Andrej Bagon wrote:
>>> We are using oVirt Engine Version: 3.2.1-1.beta1.el6 and linux
>>> environment (and vnc for console). Never tried spice console.
>>>
>>> Best Regards,
>>> Andrej
>>>
>>> On 04/29/2013 11:12 AM, Omer Frenkel wrote:
>>>> ----- Original Message -----
>>>>> From: "Andrej Bagon" <andrej.bagon at arnes.si>
>>>>> To: engine-devel at ovirt.org
>>>>> Sent: Monday, April 29, 2013 11:28:39 AM
>>>>> Subject: [Engine-devel] ovirt user portal and attach a cd
>>>>>
>>>>> Hi all,
>>>>>
>>>>> we would like to limit a user as much as possible and give him only
>>>>> actions that he needs with his VM. If we disallow a user the right in
>>>>> system|configure system|manipulate permissions), we give the user, in
>>>>> user portal, only basic mode. But then three is no option to
>>>>> attach a cd
>>>>> in the basic user portal. In basic mode user interface there is no
>>>>> chance in attaching a cd (as this is a basic operation a solution to
>>>>> this would be a button attaching a cd when starting a vm).
>>>>>
>>>>> If we allow the user to manipulate permissions, we get the
>>>>> extended menu
>>>>> back and the user is limited, but we found unacceptable when he is
>>>>> adding permission to the VM, he sees all the users (name, surname,
>>>>> email!) in the ovirt authentication mechanism? A solution to this
>>>>> would
>>>>> be authenticating to the directory service as a user an not as ovirt
>>>>> admin user - meaning that the user will see only users that we
>>>>> allowed
>>>>> he sees in the ldap directory.
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Best Regards,
>>>>> Andrej
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>> well if you only need to change cd for vm,
>>>> permission wise, the userRole and basic user portal are enough,
>>>> iirc, if using spice (on windows?) that used to be possible, this
>>>> may be related:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=957611
>>>>
>>> _______________________________________________
>>> 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  Fri May 10 09:09:59 2013
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 10 May 2013 12:09:59 +0300
Subject: [Engine-devel] ovirt user portal and attach a cd
In-Reply-To: <518CB76A.3090407@arnes.si>
References: <517E2F37.3010807@arnes.si>
	<1682099686.6160454.1367226745207.JavaMail.root@redhat.com>
	<517E4629.5050001@arnes.si> <5188D045.8030004@arnes.si>
	<518CB3D2.5030605@redhat.com> <518CB76A.3090407@arnes.si>
Message-ID: <518CB967.2060504@redhat.com>

On 05/10/2013 12:01 PM, Andrej Bagon wrote:
> Dear Itamar,
>
> while pressing the http://elmarco.fedorapeople.org/spice.cab download
> link there is a file Not Found. There is no .cab file in the directory
> listing either.

maybe spice-devel (cc'd) knows of a different one

>
> Best Regards,
> Andrej
>
> On 05/10/2013 10:46 AM, Itamar Heim wrote:
>> On 05/07/2013 12:58 PM, Andrej Bagon wrote:
>>> How to use spice on windows, but anyway what about on linux?
>>
>> spice supports both windows and linux, and as mentioned, the change-cd
>> feature.
>>
>> this is a good starting point:
>> http://wiki.ovirt.org/How_to_Connect_to_SPICE_Console_With_Portal
>>
>>>
>>> Best Regards,
>>> Andrej
>>>
>>> On 04/29/2013 12:06 PM, Andrej Bagon wrote:
>>>> We are using oVirt Engine Version: 3.2.1-1.beta1.el6 and linux
>>>> environment (and vnc for console). Never tried spice console.
>>>>
>>>> Best Regards,
>>>> Andrej
>>>>
>>>> On 04/29/2013 11:12 AM, Omer Frenkel wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Andrej Bagon" <andrej.bagon at arnes.si>
>>>>>> To: engine-devel at ovirt.org
>>>>>> Sent: Monday, April 29, 2013 11:28:39 AM
>>>>>> Subject: [Engine-devel] ovirt user portal and attach a cd
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> we would like to limit a user as much as possible and give him only
>>>>>> actions that he needs with his VM. If we disallow a user the right in
>>>>>> system|configure system|manipulate permissions), we give the user, in
>>>>>> user portal, only basic mode. But then three is no option to
>>>>>> attach a cd
>>>>>> in the basic user portal. In basic mode user interface there is no
>>>>>> chance in attaching a cd (as this is a basic operation a solution to
>>>>>> this would be a button attaching a cd when starting a vm).
>>>>>>
>>>>>> If we allow the user to manipulate permissions, we get the
>>>>>> extended menu
>>>>>> back and the user is limited, but we found unacceptable when he is
>>>>>> adding permission to the VM, he sees all the users (name, surname,
>>>>>> email!) in the ovirt authentication mechanism? A solution to this
>>>>>> would
>>>>>> be authenticating to the directory service as a user an not as ovirt
>>>>>> admin user - meaning that the user will see only users that we
>>>>>> allowed
>>>>>> he sees in the ldap directory.
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>> Best Regards,
>>>>>> Andrej
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>
>>>>> well if you only need to change cd for vm,
>>>>> permission wise, the userRole and basic user portal are enough,
>>>>> iirc, if using spice (on windows?) that used to be possible, this
>>>>> may be related:
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=957611
>>>>>
>>>> _______________________________________________
>>>> 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 deadhorseconsulting at gmail.com  Fri May 10 15:53:40 2013
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Fri, 10 May 2013 10:53:40 -0500
Subject: [Engine-devel] engine-setup rpm upgrade failing
Message-ID: <CAEWPe=ogWeBxtJxPZYZYRn_ftNhuOKm2gQN3K9Bm6fNaD=9HVg@mail.gmail.com>

Attempting to upgrade engine-setup rpm built from commit:
21d1ae55ad90b7448fea1ec2a389af176b70d528

With engine-setup rpm build from latest master
results in:

Transaction Check Error:
  file /usr/share/ovirt-engine/conf/engine-config-install.properties from
install of ovirt-engine-setup-3.3.0-17.fc18.noarch conflicts with file from
package ovirt-engine-3.3.0-16.fc18.noarch
  file /usr/share/ovirt-engine/conf/version from install of
ovirt-engine-setup-3.3.0-17.fc18.noarch conflicts with file from package
ovirt-engine-3.3.0-16.fc18.noarch

Error Summary
-------------

- DHC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130510/08082e7d/attachment.html>

From alonbl at redhat.com  Fri May 10 16:01:28 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Fri, 10 May 2013 12:01:28 -0400 (EDT)
Subject: [Engine-devel] engine-setup rpm upgrade failing
In-Reply-To: <CAEWPe=ogWeBxtJxPZYZYRn_ftNhuOKm2gQN3K9Bm6fNaD=9HVg@mail.gmail.com>
References: <CAEWPe=ogWeBxtJxPZYZYRn_ftNhuOKm2gQN3K9Bm6fNaD=9HVg@mail.gmail.com>
Message-ID: <665391550.6336156.1368201688686.JavaMail.root@redhat.com>


Hi,

This may have been caused by d9c374482a5ce8d468a51d8156ffa9b6a9d386b3 and solved by 80def80cb50700dfa7123199d9be7e19b30b57e6.

For now, if you can force rpm update to by pass it it would be great.

Thanks!
Alon

----- Original Message -----
> From: "Dead Horse" <deadhorseconsulting at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Friday, May 10, 2013 6:53:40 PM
> Subject: [Engine-devel] engine-setup rpm upgrade failing
> 
> Attempting to upgrade engine-setup rpm built from commit:
> 21d1ae55ad90b7448fea1ec2a389af176b70d528
> 
> With engine-setup rpm build from latest master
> results in:
> 
> Transaction Check Error:
> file /usr/share/ovirt-engine/conf/engine-config-install.properties from
> install of ovirt-engine-setup-3.3.0-17.fc18.noarch conflicts with file from
> package ovirt-engine-3.3.0-16.fc18.noarch
> file /usr/share/ovirt-engine/conf/version from install of
> ovirt-engine-setup-3.3.0-17.fc18.noarch conflicts with file from package
> ovirt-engine-3.3.0-16.fc18.noarch
> 
> Error Summary
> -------------
> 
> - DHC
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From deadhorseconsulting at gmail.com  Fri May 10 16:38:07 2013
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Fri, 10 May 2013 11:38:07 -0500
Subject: [Engine-devel] spice-xpi(firefox) plugin for Windows
In-Reply-To: <8EB4DD94-60E2-4B88-9E58-AF1BBC6765DA@redhat.com>
References: <20130417124545.GB13447@teriyaki.redhat.com>
	<CAEWPe=piRie7MveRfJ_i+S=bO-2tfiJmoum9JcdS6BPOHteHeA@mail.gmail.com>
	<8EB4DD94-60E2-4B88-9E58-AF1BBC6765DA@redhat.com>
Message-ID: <CAEWPe=pvGt3TySpLJN5UAaqs=zWGx9_L7fqN4+xPg-=fMhun8w@mail.gmail.com>

I played a bit with the MIME and browsers.
When switching between spice/vnc/rdp protocols since the connection file
that comes down is extension ".vv" this is an issue. Once you have
associated a MIME type of ".vv"
 one of the local clients (SPICE or VNC or RDP) the browser now thinks that
".vv" files should be used with whatever it was associated with only. This
is to say should the extension be something different for each protocol so
each protocol could be used and associated with a local client?

Also I have not yet been able to get RDP to work at all. On windows 7
systems under IE 9 is always greyed nor selectable (using latest master).
Using the connection files ".vv" and opening them with remote-viewer to
tight-vnc for example does not work at all. I have spice certificates and
ssl disabled as well so that cannot get in the way.

Any quick pointers on actually getting RDP to work or the connection files
to work with a local remote-viewer or vnc client?

- DHC


On Fri, Apr 19, 2013 at 3:08 AM, Michal Skrivanek <
michal.skrivanek at redhat.com> wrote:

>
> On 18 Apr 2013, at 17:57, Dead Horse wrote:
>
> Nicely done and this would definitely be useful. Nothing is more
> nauseating then being forced to use Internet Exploder to interact with an
> ovirt/KVM SPICE console under windows.
> For the plugin deployment this is definitely a point of pain. At the
> moment ovirt users wishing to use the SPICE Activex plugin must use an an
> dated version of the SPICE client packaged with the necessary SpiceX.dll. (
> http://elmarco.fedorapeople.org/spice.cab)
>
> They must also take manual steps to install and deploy the plugin on
> ovirt-engine server (this very painful to users). The versions of the SPICE
> client also made available to the community here:
> http://spice-space.org/download/gtk/windows/ are also a bit dated and do
> not include the plugin (SpiceX.dll).
>
> MIME file SPICE and VNC support is in oVirt master for couple of weeks
> now. This should work on all browsers with latest remote-viewer client.
>
>
> Perhaps a plugin deployment page linked from the main ovirt landing page
> would be a prudent way to deploy the plugin?
> In any event a working SPICE Plugin for Firefox and newer SPICE Client
> version under windows would be a very welcome sight indeed.
>
> definitely.
> Another alternative planned for 3.3 is SPICE HTML5, it has lots of
> limitations, but it's purely browser-based solution.
>
>
> I think one of the most frequently asked questions or gripes I see about
> ovirt is around SPICE console issues and concerns.
>
> indeed. And we'll have 3 solutions soon!:-)
>
> Thanks,
> michal
>
>
> - DHC
>
>
>
> On Wed, Apr 17, 2013 at 7:45 AM, Christophe Fergeau <cfergeau at redhat.com>wrote:
>
>> Hi everyone,
>>
>> Lately I've been hacking on getting the spice-xpi plugin to work on
>> Windows. This is the Firefox plugin that is used on Linux to implement
>> the portal SPICE console.
>>
>> This work has now been merged upstream (
>> http://cgit.freedesktop.org/spice/spice-xpi/ ), and I've pushed a
>> scratch build using mingw available from
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=5265107 (this will go
>> away in several days). Copying this dll + its dependencies to the
>> C:\Program Files\Mozilla Firefox\plugins directory are enough to get
>> a spice-xpi plugin to show up in about:plugins, and to then be able
>> to start a SPICE client from the spice-xpi test page (
>> http://teuf.fedorapeople.org/plugins/test.html ).
>> The dependencies I had to copy are:
>>
>> gspawn-win32-helper-console.exe
>> gspawn-win32-helper.exe
>> iconv.dll
>> libffi-6.dll
>> libgcc_s_sjlj-1.dll
>> libgio-2.0-0.dll
>> libglib-2.0-0.dll
>> libgmodule-2.0-0.dll
>> libgobject-2.0-0.dll
>> libgthread-2.0-0.dll
>> libintl-8.dll
>> libstdc++-6.dll
>> pthreadGC2.dll
>> zlib1.dll
>>
>> (I picked them from the various mingw-* fedora packages).
>>
>>
>> The reason for this email is that to be usable from oVirt, some portal
>> changes are needed as it currently only tries to use the spice-xpi plugin
>> on Linux platforms.
>> Another fuzzy bit is how to get this plugin to the users' machines...
>>
>>
>> And that's about all I had to say in that email ;) Let me know if that's
>> useful to oVirt, how you want to integrate this, ...
>>
>> Cheers,
>>
>> Christophe
>>
>> _______________________________________________
>> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130510/4f6088fa/attachment.html>

From djasa at redhat.com  Fri May 10 16:53:53 2013
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Fri, 10 May 2013 18:53:53 +0200
Subject: [Engine-devel] spice-xpi(firefox) plugin for Windows
In-Reply-To: <CAEWPe=pvGt3TySpLJN5UAaqs=zWGx9_L7fqN4+xPg-=fMhun8w@mail.gmail.com>
References: <20130417124545.GB13447@teriyaki.redhat.com>
	<CAEWPe=piRie7MveRfJ_i+S=bO-2tfiJmoum9JcdS6BPOHteHeA@mail.gmail.com>
	<8EB4DD94-60E2-4B88-9E58-AF1BBC6765DA@redhat.com>
	<CAEWPe=pvGt3TySpLJN5UAaqs=zWGx9_L7fqN4+xPg-=fMhun8w@mail.gmail.com>
Message-ID: <1368204833.7136.278.camel@cihla.usersys.redhat.com>

Hi,

writing from top of my head so this may not be 100 % accurate:

Dead Horse p??e v P? 10. 05. 2013 v 11:38 -0500:
> I played a bit with the MIME and browsers.
> 
> When switching between spice/vnc/rdp protocols since the connection
> file that comes down is extension ".vv" this is an issue. Once you
> have associated a MIME type of ".vv"
> 
>  one of the local clients (SPICE or VNC or RDP) the browser now thinks
> that ".vv" files should be used with whatever it was associated with
> only. This is to say should the extension be something different for
> each protocol so each protocol could be used and associated with a
> local client?

I guess that this exception should apply just for RDP because
{virt,remote}-viewer supports both spice and vnc AFAIK.
> 
> 
> Also I have not yet been able to get RDP to work at all. On windows 7
> systems under IE 9 is always greyed nor selectable (using latest
> master). Using the connection files ".vv" and opening them with
> remote-viewer to tight-vnc for example does not work at all. 

Given ^^^ and that another vnc client would need to add the .vv file
format support, I don't think that it's a good idea

> I have spice certificates and ssl disabled as well so that cannot get
> in the way.

Unlike spice and vnc, rdp server is not provided by qemu but by VM
itself, so in order to make it work, engine must learn VM IP address
from RHEV Agent (so RHEV Agent service must be up'n'running in the VM)
and the VM must be configured to accept incoming RDP connections.

Because {virt,remote}-viewer doesn't support RDP (AFAIK) and no other
client has support for .vv files, I don't think that they should be
generated for rdp connection so if engine indeed generates the files,
that sound like a bug for me (for the time being, till
{virt,remote}-viewer gains RDP support or some rdp client gets .vv file
format support).

David
> 
> 
> Any quick pointers on actually getting RDP to work or the connection
> files to work with a local remote-viewer or vnc client?
> 
> 
> - DHC
> 
> 
> 
> On Fri, Apr 19, 2013 at 3:08 AM, Michal Skrivanek
> <michal.skrivanek at redhat.com> wrote:
>         
>         On 18 Apr 2013, at 17:57, Dead Horse wrote:
>         
>         > Nicely done and this would definitely be useful. Nothing is
>         > more nauseating then being forced to use Internet Exploder
>         > to interact with an ovirt/KVM SPICE console under windows.
>         > For the plugin deployment this is definitely a point of
>         > pain. At the moment ovirt users wishing to use the SPICE
>         > Activex plugin must use an an dated version of the SPICE
>         > client packaged with the necessary SpiceX.dll.
>         > (http://elmarco.fedorapeople.org/spice.cab)
>         > 
>         > They must also take manual steps to install and deploy the
>         > plugin on ovirt-engine server (this very painful to users).
>         > The versions of the SPICE client also made available to the
>         > community here: http://spice-space.org/download/gtk/windows/
>         > are also a bit dated and do not include the plugin
>         > (SpiceX.dll).
>         > 
>         MIME file SPICE and VNC support is in oVirt master for couple
>         of weeks now. This should work on all browsers with latest
>         remote-viewer client.
>         
>         
>         > 
>         > 
>         > Perhaps a plugin deployment page linked from the main ovirt
>         > landing page would be a prudent way to deploy the plugin?
>         > 
>         > In any event a working SPICE Plugin for Firefox and newer
>         > SPICE Client version under windows would be a very welcome
>         > sight indeed.
>         > 
>         definitely.
>         Another alternative planned for 3.3 is SPICE HTML5, it has
>         lots of limitations, but it's purely browser-based solution.
>         
>         > 
>         > 
>         > I think one of the most frequently asked questions or gripes
>         > I see about ovirt is around SPICE console issues and
>         > concerns.
>         > 
>         indeed. And we'll have 3 solutions soon!:-)
>         
>         
>         Thanks,
>         michal
>         
>         > 
>         > 
>         > - DHC
>         > 
>         > 
>         > 
>         > 
>         > On Wed, Apr 17, 2013 at 7:45 AM, Christophe Fergeau
>         > <cfergeau at redhat.com> wrote:
>         >         Hi everyone,
>         >         
>         >         Lately I've been hacking on getting the spice-xpi
>         >         plugin to work on
>         >         Windows. This is the Firefox plugin that is used on
>         >         Linux to implement
>         >         the portal SPICE console.
>         >         
>         >         This work has now been merged upstream (
>         >         http://cgit.freedesktop.org/spice/spice-xpi/ ), and
>         >         I've pushed a
>         >         scratch build using mingw available from
>         >         http://koji.fedoraproject.org/koji/taskinfo?taskID=5265107 (this will go
>         >         away in several days). Copying this dll + its
>         >         dependencies to the
>         >         C:\Program Files\Mozilla Firefox\plugins directory
>         >         are enough to get
>         >         a spice-xpi plugin to show up in about:plugins, and
>         >         to then be able
>         >         to start a SPICE client from the spice-xpi test page
>         >         (
>         >         http://teuf.fedorapeople.org/plugins/test.html ).
>         >         The dependencies I had to copy are:
>         >         
>         >         gspawn-win32-helper-console.exe
>         >         gspawn-win32-helper.exe
>         >         iconv.dll
>         >         libffi-6.dll
>         >         libgcc_s_sjlj-1.dll
>         >         libgio-2.0-0.dll
>         >         libglib-2.0-0.dll
>         >         libgmodule-2.0-0.dll
>         >         libgobject-2.0-0.dll
>         >         libgthread-2.0-0.dll
>         >         libintl-8.dll
>         >         libstdc++-6.dll
>         >         pthreadGC2.dll
>         >         zlib1.dll
>         >         
>         >         (I picked them from the various mingw-* fedora
>         >         packages).
>         >         
>         >         
>         >         The reason for this email is that to be usable from
>         >         oVirt, some portal
>         >         changes are needed as it currently only tries to use
>         >         the spice-xpi plugin
>         >         on Linux platforms.
>         >         Another fuzzy bit is how to get this plugin to the
>         >         users' machines...
>         >         
>         >         
>         >         And that's about all I had to say in that email ;)
>         >         Let me know if that's
>         >         useful to oVirt, how you want to integrate this, ...
>         >         
>         >         Cheers,
>         >         
>         >         Christophe
>         >         
>         >         _______________________________________________
>         >         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

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3790 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130510/d3c8f313/attachment.bin>

From acathrow at redhat.com  Fri May 10 17:01:06 2013
From: acathrow at redhat.com (Andrew Cathrow)
Date: Fri, 10 May 2013 13:01:06 -0400 (EDT)
Subject: [Engine-devel] spice-xpi(firefox) plugin for Windows
In-Reply-To: <1368204833.7136.278.camel@cihla.usersys.redhat.com>
References: <20130417124545.GB13447@teriyaki.redhat.com>
	<CAEWPe=piRie7MveRfJ_i+S=bO-2tfiJmoum9JcdS6BPOHteHeA@mail.gmail.com>
	<8EB4DD94-60E2-4B88-9E58-AF1BBC6765DA@redhat.com>
	<CAEWPe=pvGt3TySpLJN5UAaqs=zWGx9_L7fqN4+xPg-=fMhun8w@mail.gmail.com>
	<1368204833.7136.278.camel@cihla.usersys.redhat.com>
Message-ID: <33073512.1136.1368205263930.JavaMail.acathrow@aic-desktop.cathrow.org>



----- Original Message -----
> From: "David Ja?a" <djasa at redhat.com>
> To: "Dead Horse" <deadhorseconsulting at gmail.com>
> Cc: engine-devel at ovirt.org, "Christophe Fergeau" <cfergeau at redhat.com>
> Sent: Friday, May 10, 2013 12:53:53 PM
> Subject: Re: [Engine-devel] spice-xpi(firefox) plugin for Windows
> 
> Hi,
> 
> writing from top of my head so this may not be 100 % accurate:
> 
> Dead Horse p??e v P? 10. 05. 2013 v 11:38 -0500:
> > I played a bit with the MIME and browsers.
> > 
> > When switching between spice/vnc/rdp protocols since the connection
> > file that comes down is extension ".vv" this is an issue. Once you
> > have associated a MIME type of ".vv"
> > 
> >  one of the local clients (SPICE or VNC or RDP) the browser now
> >  thinks
> > that ".vv" files should be used with whatever it was associated
> > with
> > only. This is to say should the extension be something different
> > for
> > each protocol so each protocol could be used and associated with a
> > local client?
> 
> I guess that this exception should apply just for RDP because
> {virt,remote}-viewer supports both spice and vnc AFAIK.
> > 
> > 
> > Also I have not yet been able to get RDP to work at all. On windows
> > 7
> > systems under IE 9 is always greyed nor selectable (using latest
> > master). Using the connection files ".vv" and opening them with
> > remote-viewer to tight-vnc for example does not work at all.
> 
> Given ^^^ and that another vnc client would need to add the .vv file
> format support, I don't think that it's a good idea
> 
> > I have spice certificates and ssl disabled as well so that cannot
> > get
> > in the way.
> 
> Unlike spice and vnc, rdp server is not provided by qemu but by VM
> itself, so in order to make it work, engine must learn VM IP address
> from RHEV Agent (so RHEV Agent service must be up'n'running in the
> VM)
> and the VM must be configured to accept incoming RDP connections.
> 
> Because {virt,remote}-viewer doesn't support RDP (AFAIK) and no other
> client has support for .vv files, I don't think that they should be
> generated for rdp connection so if engine indeed generates the files,
> that sound like a bug for me (for the time being, till
> {virt,remote}-viewer gains RDP support or some rdp client gets .vv
> file
> format support).

VV's are only created for Spice and VNC not for RDP today.





> 
> David
> > 
> > 
> > Any quick pointers on actually getting RDP to work or the
> > connection
> > files to work with a local remote-viewer or vnc client?
> > 
> > 
> > - DHC
> > 
> > 
> > 
> > On Fri, Apr 19, 2013 at 3:08 AM, Michal Skrivanek
> > <michal.skrivanek at redhat.com> wrote:
> >         
> >         On 18 Apr 2013, at 17:57, Dead Horse wrote:
> >         
> >         > Nicely done and this would definitely be useful. Nothing
> >         > is
> >         > more nauseating then being forced to use Internet
> >         > Exploder
> >         > to interact with an ovirt/KVM SPICE console under
> >         > windows.
> >         > For the plugin deployment this is definitely a point of
> >         > pain. At the moment ovirt users wishing to use the SPICE
> >         > Activex plugin must use an an dated version of the SPICE
> >         > client packaged with the necessary SpiceX.dll.
> >         > (http://elmarco.fedorapeople.org/spice.cab)
> >         > 
> >         > They must also take manual steps to install and deploy
> >         > the
> >         > plugin on ovirt-engine server (this very painful to
> >         > users).
> >         > The versions of the SPICE client also made available to
> >         > the
> >         > community here:
> >         > http://spice-space.org/download/gtk/windows/
> >         > are also a bit dated and do not include the plugin
> >         > (SpiceX.dll).
> >         > 
> >         MIME file SPICE and VNC support is in oVirt master for
> >         couple
> >         of weeks now. This should work on all browsers with latest
> >         remote-viewer client.
> >         
> >         
> >         > 
> >         > 
> >         > Perhaps a plugin deployment page linked from the main
> >         > ovirt
> >         > landing page would be a prudent way to deploy the plugin?
> >         > 
> >         > In any event a working SPICE Plugin for Firefox and newer
> >         > SPICE Client version under windows would be a very
> >         > welcome
> >         > sight indeed.
> >         > 
> >         definitely.
> >         Another alternative planned for 3.3 is SPICE HTML5, it has
> >         lots of limitations, but it's purely browser-based
> >         solution.
> >         
> >         > 
> >         > 
> >         > I think one of the most frequently asked questions or
> >         > gripes
> >         > I see about ovirt is around SPICE console issues and
> >         > concerns.
> >         > 
> >         indeed. And we'll have 3 solutions soon!:-)
> >         
> >         
> >         Thanks,
> >         michal
> >         
> >         > 
> >         > 
> >         > - DHC
> >         > 
> >         > 
> >         > 
> >         > 
> >         > On Wed, Apr 17, 2013 at 7:45 AM, Christophe Fergeau
> >         > <cfergeau at redhat.com> wrote:
> >         >         Hi everyone,
> >         >         
> >         >         Lately I've been hacking on getting the spice-xpi
> >         >         plugin to work on
> >         >         Windows. This is the Firefox plugin that is used
> >         >         on
> >         >         Linux to implement
> >         >         the portal SPICE console.
> >         >         
> >         >         This work has now been merged upstream (
> >         >         http://cgit.freedesktop.org/spice/spice-xpi/ ),
> >         >         and
> >         >         I've pushed a
> >         >         scratch build using mingw available from
> >         >         http://koji.fedoraproject.org/koji/taskinfo?taskID=5265107
> >         >         (this will go
> >         >         away in several days). Copying this dll + its
> >         >         dependencies to the
> >         >         C:\Program Files\Mozilla Firefox\plugins
> >         >         directory
> >         >         are enough to get
> >         >         a spice-xpi plugin to show up in about:plugins,
> >         >         and
> >         >         to then be able
> >         >         to start a SPICE client from the spice-xpi test
> >         >         page
> >         >         (
> >         >         http://teuf.fedorapeople.org/plugins/test.html ).
> >         >         The dependencies I had to copy are:
> >         >         
> >         >         gspawn-win32-helper-console.exe
> >         >         gspawn-win32-helper.exe
> >         >         iconv.dll
> >         >         libffi-6.dll
> >         >         libgcc_s_sjlj-1.dll
> >         >         libgio-2.0-0.dll
> >         >         libglib-2.0-0.dll
> >         >         libgmodule-2.0-0.dll
> >         >         libgobject-2.0-0.dll
> >         >         libgthread-2.0-0.dll
> >         >         libintl-8.dll
> >         >         libstdc++-6.dll
> >         >         pthreadGC2.dll
> >         >         zlib1.dll
> >         >         
> >         >         (I picked them from the various mingw-* fedora
> >         >         packages).
> >         >         
> >         >         
> >         >         The reason for this email is that to be usable
> >         >         from
> >         >         oVirt, some portal
> >         >         changes are needed as it currently only tries to
> >         >         use
> >         >         the spice-xpi plugin
> >         >         on Linux platforms.
> >         >         Another fuzzy bit is how to get this plugin to
> >         >         the
> >         >         users' machines...
> >         >         
> >         >         
> >         >         And that's about all I had to say in that email
> >         >         ;)
> >         >         Let me know if that's
> >         >         useful to oVirt, how you want to integrate this,
> >         >         ...
> >         >         
> >         >         Cheers,
> >         >         
> >         >         Christophe
> >         >         
> >         >         _______________________________________________
> >         >         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
> 
> --
> 
> David Ja?a, RHCE
> 
> SPICE QE based in Brno
> GPG Key:     22C33E24
> Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mkolesni at redhat.com  Sun May 12 09:42:14 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 12 May 2013 05:42:14 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <478978763.164674.1368350828218.JavaMail.root@redhat.com>
Message-ID: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>

Hi All, 

I would like to have your opinions on which inheritance type to use in the DB. 
We are adding an "external provider" entity to the system which will be able to provide various resources (networks, hosts, etc). 

These providers will be distinguishable by "type". 
The basic definition of a provider contains: 


    * name 
    * description 
    * url 
    * type 

Some providers might need additional properties such as: 


    * user 
    * password 

In Java this is easily represented by inheritance. 

In the DB however, there are 3 approaches that we can take: 


    1. No inheritance. This means that each type will wit in his own table, with no relation or re-use. 
    2. Single table inheritance. All types sit in a single table, and each has his corresponding columns. 
    3. Multiple table inheritance. Each type sists in his own table, where the PK is FK for the most basic table (providers). 

Pros for each approach: 


    1. None that I can think of. 
    2. No joins: Better performance Easier for developer to see the DB info Facilitate column reuse 
    3. Constraints can be set on each column 
Cons for each approach: 


    1. No reuse of DB entities + no compliance for column types Most cumbersome to query all providers 
    2. Can't put some constraints on non-base columns (esp. not null) 
    3. Joins are needed - opposite of the pros of 2. 

>From personal experience, I find #2 to be better and easier to work with & maintain. 

What are your thoughts? 

Regards, 
Mike 

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

From yzaslavs at redhat.com  Sun May 12 09:53:01 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 12 May 2013 05:53:01 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
Message-ID: <176765088.119212.1368352381011.JavaMail.root@redhat.com>

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

> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, May 12, 2013 12:42:14 PM
> Subject: [Engine-devel] What type of DB inheritance to use?

> Hi All,

> I would like to have your opinions on which inheritance type to use in the
> DB.
> We are adding an "external provider" entity to the system which will be able
> to provide various resources (networks, hosts, etc).

> These providers will be distinguishable by "type".
> The basic definition of a provider contains:

> * name
> * description
> * url
> * type

> Some providers might need additional properties such as:

> * user
> * password

> In Java this is easily represented by inheritance.

> In the DB however, there are 3 approaches that we can take:

> 1. No inheritance. This means that each type will wit in his own table, with
> no relation or re-use.
> 2. Single table inheritance. All types sit in a single table, and each has
> his corresponding columns.

You forgot to mention discriminator column at option 2 (how are you going to differ between sub types) which should be indexed. 

> 1.
> 2. Multiple table inheritance. Each type sists in his own table, where the PK
> is FK for the most basic table (providers).

> Pros for each approach:

> 1. None that I can think of.
> 2. No joins: Better performance Easier for developer to see the DB info
> Facilitate column reuse
> 3. Constraints can be set on each column
> Cons for each approach:

> 1. No reuse of DB entities + no compliance for column types Most cumbersome
> to query all providers
> 2. Can't put some constraints on non-base columns (esp. not null)
> 3. Joins are needed - opposite of the pros of 2

> 1.

> From personal experience, I find #2 to be better and easier to work with &
> maintain.

I think it really depends on the use-case, but I also had better experience with 2. 

> What are your thoughts?

> Regards,
> Mike

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130512/138c6331/attachment.html>

From liran.zelkha at gmail.com  Sun May 12 10:19:07 2013
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Sun, 12 May 2013 13:19:07 +0300
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <176765088.119212.1368352381011.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<176765088.119212.1368352381011.JavaMail.root@redhat.com>
Message-ID: <CAJ3aYLdniVuwCrPqE10yvoWo8WZj7k2KD3OUq1wEY_-urOfmGw@mail.gmail.com>

Hi

>From my experience, single table inheritance quickly grows into something
unmanagable, as more and more (child related) fields are added, each line
has a few relevant attributes, and a long list of NULL values.
I would go with option 3. With materialized views, the costs of joins can
be eliminated.


On Sun, May 12, 2013 at 12:53 PM, Yair Zaslavsky <yzaslavs at redhat.com>wrote:

>
>
> ------------------------------
>
> *From: *"Mike Kolesnik" <mkolesni at redhat.com>
> *To: *"engine-devel" <engine-devel at ovirt.org>
> *Sent: *Sunday, May 12, 2013 12:42:14 PM
> *Subject: *[Engine-devel] What type of DB inheritance to use?
>
> Hi All,
>
> I would like to have your opinions on which inheritance type to use in the
> DB.
> We are adding an "external provider" entity to the system which will be
> able to provide various resources (networks, hosts, etc).
>
> These providers will be distinguishable by "type".
> The basic definition of a provider contains:
>
>    - name
>    - description
>    - url
>    - type
>
> Some providers might need additional properties such as:
>
>    - user
>    - password
>
> In Java this is easily represented by inheritance.
>
> In the DB however, there are 3 approaches that we can take:
>
>    1. No inheritance.
>    This means that each type will wit in his own table, with no relation
>    or re-use.
>    2. Single table inheritance.
>    All types sit in a single table, and each has his corresponding
>    columns.
>
> You forgot to mention discriminator column  at option 2 (how are you going
> to differ between sub types) which should be indexed.
>
>
>    1.
>    2. Multiple table inheritance.
>    Each type sists in his own table, where the PK is FK for the most
>    basic table (providers).
>
>
> Pros for each approach:
>
>    1. None that I can think of.
>    2. No joins:
>        Better performance
>        Easier for developer to see the DB info
>        Facilitate column reuse
>    3. Constraints can be set on each column
>
> Cons for each approach:
>
>    1. No reuse of DB entities + no compliance for column types
>    Most cumbersome to query all providers
>    2. Can't put some constraints on non-base columns (esp. not null)
>    3. Joins are needed - opposite of the pros of 2
>
>
>    1.
>
> From personal experience, I find #2 to be better and easier to work with &
> maintain.
>
> I think it really depends on the use-case, but I also had better
> experience with 2.
>
>
>
> What are your thoughts?
>
> Regards,
> Mike
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130512/eeff2366/attachment.html>

From abonas at redhat.com  Sun May 12 11:42:40 2013
From: abonas at redhat.com (Alissa Bonas)
Date: Sun, 12 May 2013 07:42:40 -0400 (EDT)
Subject: [Engine-devel] Build ovirt-engine with Eclipse
In-Reply-To: <000e01ce4d22$ce260cb0$6a722610$@com>
References: <000e01ce4d22$ce260cb0$6a722610$@com>
Message-ID: <1046918966.257309.1368358960896.JavaMail.root@redhat.com>

Can you specify which problems did you encounter and at which stage of building the project? Did compilation fail? Tests?  Which error do you get?

I work with IntelliJ.

You can also try setup ovirt-engine with IntelliJ - see instructions below, and verify if it works for you, or whether you get the same problems as in Eclipse. 

http://www.ovirt.org/Building_oVirt_Engine/IDE#IntelliJ


----- Original Message -----
> From: "wanglibo" <wanglibo at tongfangcloud.com>
> To: engine-devel at ovirt.org
> Sent: Friday, May 10, 2013 5:05:11 AM
> Subject: [Engine-devel] Build ovirt-engine with Eclipse
> 
> 
> 
> Hi, all:
> 
> I want to know which IDE or environment you are using to develop
> ovirt-engine,
> 
> Recently, I want to build and debug ovirt-engine with Eclipse, but when I
> install all the
> 
> plugins for build it in eclipse, and install jboss and postgre-sql, and then
> how can I
> 
> built it , and deploy it, and debug it .
> 
> I tried to use eclipse like http://www.ovirt.org/Building_Ovirt_Engine/IDE ,
> but
> 
> failed.
> 
> 
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alonbl at redhat.com  Sun May 12 11:52:51 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 12 May 2013 07:52:51 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
In-Reply-To: <1534961780.272884.1368354892411.JavaMail.root@redhat.com>
Message-ID: <9423451.273926.1368359571790.JavaMail.root@redhat.com>

Hello all ovirt-engine developers,

When I first joined the ovirt project, it took me about two weeks to setup a development environment, I needed to work on a bug related to host-deploy so I needed an environment that could use the ssh, PKI, vdsm-bootstrap and communicate with vdsm using SSL, this was virtually impossible to do so without tweaking the product in a way that it is so different from production use, that I cannot guarantee that whatever tested in development will actually work in production.

I peeked at the installation script in a hope that I can create partial environment similar to production, but I found that the packaging implementation makes to much assumption and is very difficult to adopt. The fact that I do not use fedora/rhel for my development made it even worse.

I had no other option than to create rpms after each of my changes and test each in real production like setup.

It was obvious to me that the manual customization of developers to achieve working product will eventually break as product grow and move away from being developer friendly to production friendly. For example, product defaults cannot be these which serve developers, but these which serve production the best, or having a valid PKI setup cannot be optional any more as components do need to use it. Same for location of files and configuration, for example, if we write a pluggable infrastructure for branding, we cannot damage the interface just because developers runs the product in their own manual customization.

I took the opportunity handed to me to port the ovirt-engine to other distributions in order to provide a development environment that is similar to production setup. Together with Sandro Bonazzola and Alex Lourie we re-wrote the whole installation of the product which can also be used to setup the desired development environment.

Within this environment the product is set up using the same tools and configuration as in production, while the process does not require special privileges nor changes the state of the developer machine. 

A complete documentation is available[1], I preferred to use README within the source tree as wiki tend to quickly become obsolete, while documentation within source tree can be modified by the commit that introduces a change. I will redirect to this file from the current wiki once the site will be up.

In a nut shell, after installing prerequisites, build and install the product using:

$ make clean install-dev PREFIX=$HOME/ovirt-engine

This will run maven and create product installation at $HOME/ovirt-engine
Next, a setup phase is required just like in production, to initialize configuration and database:

$ $HOME/ovirt-engine/bin/engine-setup-2

You have now fully functional product, including PKI, SSL, host-deploy, tools.
No manual database updates are required, no lose of functionality.

All that is left is to start the engine service:

$ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start

Access to application:
   http://localhost:8080
   https://localhost:8443
Debugging port is opened at port 8787.

Farther information exists in the documentation[1].

There are several inherit benefits of the new environment, the major one is the ability to manage several environments in parallel on the same host. For example, if we develop two separate features on two branches we can install the product into $HOME/ovirt-engine-feature1 and $HOME/ovirt-engine-feature-2 and have a separate database for each, if we modify the ports jboss is listening to we can run two instances of engine at the same time!

We will be happy to work with all developers to assist in porting into the new development environment, the simplest is to create a new database for this effort. Moti has a sequence of converting the existing database owned by postgres to be owned by the engine, Moti, can you please share that?

We are sure there are missing bits, we will be happy to know these so we can improve.

I am aware that developers (especially java) are conservative, but I ask you to give us a chance, so that we make it easy for developers to join the project, and to allow us to drop the parallel effort of packaging to production and fixing the broken development environment. 

A special thanks to developers who took the time to test and provide feedback before the merged:
- Yaniv Bronheim
- Moti Asayag
- Limor Gavish
- Sharad Mishra
- Ofer Schreiber

We are hoping that after migration you will be find this environment useful and friendly,

Sandro Bonazzola,
Alex Lourie,
Alon Bar-Lev.

[1] http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD


From iheim at redhat.com  Sun May 12 12:14:40 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 12 May 2013 15:14:40 +0300
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
Message-ID: <518F87B0.2030202@redhat.com>

On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
> Hi All,
>
> I would like to have your opinions on which inheritance type to use in
> the DB.
> We are adding an "external provider" entity to the system which will be
> able to provide various resources (networks, hosts, etc).
>
> These providers will be distinguishable by "type".
> The basic definition of a provider contains:
>
>   * name
>   * description
>   * url
>   * type
>
> Some providers might need additional properties such as:
>
>   * user
>   * password

what type of provider won't require authentication?

>
> In Java this is easily represented by inheritance.
>
> In the DB however, there are 3 approaches that we can take:
>
>  1. No inheritance.
>     This means that each type will wit in his own table, with no
>     relation or re-use.
>  2. Single table inheritance.
>     All types sit in a single table, and each has his corresponding columns.
>  3. Multiple table inheritance.
>     Each type sists in his own table, where the PK is FK for the most
>     basic table (providers).
>
>
> Pros for each approach:
>
>  1. None that I can think of.
>  2. No joins:
>          Better performance
>          Easier for developer to see the DB info
>          Facilitate column reuse
>  3. Constraints can be set on each column
>
> Cons for each approach:
>
>  1. No reuse of DB entities + no compliance for column types
>     Most cumbersome to query all providers
>  2. Can't put some constraints on non-base columns (esp. not null)
>  3. Joins are needed - opposite of the pros of 2.
>
>  From personal experience, I find #2 to be better and easier to work
> with & maintain.
>
> What are your thoughts?
>
> Regards,
> Mike
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From mkolesni at redhat.com  Sun May 12 12:16:43 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 12 May 2013 08:16:43 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <518F87B0.2030202@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
Message-ID: <2022393695.178661.1368361003309.JavaMail.root@redhat.com>

----- Original Message -----
> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
> > Hi All,
> >
> > I would like to have your opinions on which inheritance type to use in
> > the DB.
> > We are adding an "external provider" entity to the system which will be
> > able to provide various resources (networks, hosts, etc).
> >
> > These providers will be distinguishable by "type".
> > The basic definition of a provider contains:
> >
> >   * name
> >   * description
> >   * url
> >   * type
> >
> > Some providers might need additional properties such as:
> >
> >   * user
> >   * password
> 
> what type of provider won't require authentication?

Quantum provider in the 1st implementation will not require these fields.
It will eventually require some sort of authentication, but not necessarily
these fields, or only these fields.

> 
> >
> > In Java this is easily represented by inheritance.
> >
> > In the DB however, there are 3 approaches that we can take:
> >
> >  1. No inheritance.
> >     This means that each type will wit in his own table, with no
> >     relation or re-use.
> >  2. Single table inheritance.
> >     All types sit in a single table, and each has his corresponding
> >     columns.
> >  3. Multiple table inheritance.
> >     Each type sists in his own table, where the PK is FK for the most
> >     basic table (providers).
> >
> >
> > Pros for each approach:
> >
> >  1. None that I can think of.
> >  2. No joins:
> >          Better performance
> >          Easier for developer to see the DB info
> >          Facilitate column reuse
> >  3. Constraints can be set on each column
> >
> > Cons for each approach:
> >
> >  1. No reuse of DB entities + no compliance for column types
> >     Most cumbersome to query all providers
> >  2. Can't put some constraints on non-base columns (esp. not null)
> >  3. Joins are needed - opposite of the pros of 2.
> >
> >  From personal experience, I find #2 to be better and easier to work
> > with & maintain.
> >
> > What are your thoughts?
> >
> > Regards,
> > Mike
> >
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 


From iheim at redhat.com  Sun May 12 12:43:37 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 12 May 2013 15:43:37 +0300
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <2022393695.178661.1368361003309.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
Message-ID: <518F8E79.20503@redhat.com>

On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
>>> Hi All,
>>>
>>> I would like to have your opinions on which inheritance type to use in
>>> the DB.
>>> We are adding an "external provider" entity to the system which will be
>>> able to provide various resources (networks, hosts, etc).
>>>
>>> These providers will be distinguishable by "type".
>>> The basic definition of a provider contains:
>>>
>>>    * name
>>>    * description
>>>    * url
>>>    * type
>>>
>>> Some providers might need additional properties such as:
>>>
>>>    * user
>>>    * password
>>
>> what type of provider won't require authentication?
>
> Quantum provider in the 1st implementation will not require these fields.
> It will eventually require some sort of authentication, but not necessarily
> these fields, or only these fields.

I'm not talking about a POC.
unless we pass through credentials of users for some actions, how do you 
use a provider without user/password (or client cert, etc. - i.e., all 
authentication methods are usually similar on the info you need to persist)?

>
>>
>>>
>>> In Java this is easily represented by inheritance.
>>>
>>> In the DB however, there are 3 approaches that we can take:
>>>
>>>   1. No inheritance.
>>>      This means that each type will wit in his own table, with no
>>>      relation or re-use.
>>>   2. Single table inheritance.
>>>      All types sit in a single table, and each has his corresponding
>>>      columns.
>>>   3. Multiple table inheritance.
>>>      Each type sists in his own table, where the PK is FK for the most
>>>      basic table (providers).
>>>
>>>
>>> Pros for each approach:
>>>
>>>   1. None that I can think of.
>>>   2. No joins:
>>>           Better performance
>>>           Easier for developer to see the DB info
>>>           Facilitate column reuse
>>>   3. Constraints can be set on each column
>>>
>>> Cons for each approach:
>>>
>>>   1. No reuse of DB entities + no compliance for column types
>>>      Most cumbersome to query all providers
>>>   2. Can't put some constraints on non-base columns (esp. not null)
>>>   3. Joins are needed - opposite of the pros of 2.
>>>
>>>   From personal experience, I find #2 to be better and easier to work
>>> with & maintain.
>>>
>>> What are your thoughts?
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>>



From mkolesni at redhat.com  Sun May 12 13:31:51 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 12 May 2013 09:31:51 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <518F8E79.20503@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
Message-ID: <152608682.188683.1368365511396.JavaMail.root@redhat.com>


----- Original Message -----
> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
> > ----- Original Message -----
> >> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
> >>> Hi All,
> >>>
> >>> I would like to have your opinions on which inheritance type to use in
> >>> the DB.
> >>> We are adding an "external provider" entity to the system which will be
> >>> able to provide various resources (networks, hosts, etc).
> >>>
> >>> These providers will be distinguishable by "type".
> >>> The basic definition of a provider contains:
> >>>
> >>>    * name
> >>>    * description
> >>>    * url
> >>>    * type
> >>>
> >>> Some providers might need additional properties such as:
> >>>
> >>>    * user
> >>>    * password
> >>
> >> what type of provider won't require authentication?
> >
> > Quantum provider in the 1st implementation will not require these fields.
> > It will eventually require some sort of authentication, but not necessarily
> > these fields, or only these fields.
> 
> I'm not talking about a POC.
> unless we pass through credentials of users for some actions, how do you
> use a provider without user/password (or client cert, etc. - i.e., all
> authentication methods are usually similar on the info you need to persist)?

I did not say that we will use Quantum without auth, only that these fields may or
may not necessarily be in the Quantum provider entity.

I think this is regardless of the main discussion here of inheritance, which I
think will happen regardless of how Quantum provider is implemented. If you wish
to discuss these details I'll be happy do it on a new thread, so that this one
can stay focused on the subject of DB inheritance.

> 
> >
> >>
> >>>
> >>> In Java this is easily represented by inheritance.
> >>>
> >>> In the DB however, there are 3 approaches that we can take:
> >>>
> >>>   1. No inheritance.
> >>>      This means that each type will wit in his own table, with no
> >>>      relation or re-use.
> >>>   2. Single table inheritance.
> >>>      All types sit in a single table, and each has his corresponding
> >>>      columns.
> >>>   3. Multiple table inheritance.
> >>>      Each type sists in his own table, where the PK is FK for the most
> >>>      basic table (providers).
> >>>
> >>>
> >>> Pros for each approach:
> >>>
> >>>   1. None that I can think of.
> >>>   2. No joins:
> >>>           Better performance
> >>>           Easier for developer to see the DB info
> >>>           Facilitate column reuse
> >>>   3. Constraints can be set on each column
> >>>
> >>> Cons for each approach:
> >>>
> >>>   1. No reuse of DB entities + no compliance for column types
> >>>      Most cumbersome to query all providers
> >>>   2. Can't put some constraints on non-base columns (esp. not null)
> >>>   3. Joins are needed - opposite of the pros of 2.
> >>>
> >>>   From personal experience, I find #2 to be better and easier to work
> >>> with & maintain.
> >>>
> >>> What are your thoughts?
> >>>
> >>> Regards,
> >>> Mike
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>
> >>
> 
> 


From iheim at redhat.com  Sun May 12 13:55:08 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 12 May 2013 16:55:08 +0300
Subject: [Engine-devel] VDSM Fake
In-Reply-To: <517FA451.20703@redhat.com>
References: <517F93FC.7000500@redhat.com>
	<1332904058.1994060.1367318924637.JavaMail.root@redhat.com>
	<517FA451.20703@redhat.com>
Message-ID: <518F9F3C.80506@redhat.com>

On 04/30/2013 02:00 PM, Libor Spevak wrote:
> I didn't have enough time to make a real stress test, I created 100
> hosts running 300 VMs, all-in-one - one server running Engine, DB, VDSM
> Fake. I put the VMs into running state and tried migration. It was
> rather responsive.
> The server had still enough resources.
>
> On 30.4.2013 12:48, Liran Zelkha wrote:
>> Awesome. I really need this for the stress tests I'm running. How many
>> hosts were you able to simulate with one web application?
>>
>> ----- Original Message -----
>> From: "Libor Spevak" <lspevak at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, April 30, 2013 12:50:52 PM
>> Subject: [Engine-devel] VDSM Fake
>>
>> Hi,
>>
>> let me introduce an experimental project called VDSM Fake. This is a
>> small Java web application simulating
>> selected VDSM features, but only from the Engine point of view.
>>
>> The aim was to get oVirt-Engine top performance characteristics in core
>> features simulating hundreds of fake hosts and VMs, and in ecologic way.
>>
>> More info:
>> http://www.ovirt.org/VDSM_Fake
>>
>> Sources:
>> git clone git://github.com/lspevak/ovirt-vdsmfake.git
>> git clone git://github.com/lspevak/ovirt-restapiconf.git
>>
>> Regards,
>> Libor
>>
>> _______________________________________________
>> 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

how different in what you can scale compared to fake vdsm?
http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks/faqemu


From iheim at redhat.com  Sun May 12 14:05:52 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 12 May 2013 17:05:52 +0300
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <152608682.188683.1368365511396.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
	<152608682.188683.1368365511396.JavaMail.root@redhat.com>
Message-ID: <518FA1C0.8050800@redhat.com>

On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
>
> ----- Original Message -----
>> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
>>> ----- Original Message -----
>>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
>>>>> Hi All,
>>>>>
>>>>> I would like to have your opinions on which inheritance type to use in
>>>>> the DB.
>>>>> We are adding an "external provider" entity to the system which will be
>>>>> able to provide various resources (networks, hosts, etc).
>>>>>
>>>>> These providers will be distinguishable by "type".
>>>>> The basic definition of a provider contains:
>>>>>
>>>>>     * name
>>>>>     * description
>>>>>     * url
>>>>>     * type
>>>>>
>>>>> Some providers might need additional properties such as:
>>>>>
>>>>>     * user
>>>>>     * password
>>>>
>>>> what type of provider won't require authentication?
>>>
>>> Quantum provider in the 1st implementation will not require these fields.
>>> It will eventually require some sort of authentication, but not necessarily
>>> these fields, or only these fields.
>>
>> I'm not talking about a POC.
>> unless we pass through credentials of users for some actions, how do you
>> use a provider without user/password (or client cert, etc. - i.e., all
>> authentication methods are usually similar on the info you need to persist)?
>
> I did not say that we will use Quantum without auth, only that these fields may or
> may not necessarily be in the Quantum provider entity.
>
> I think this is regardless of the main discussion here of inheritance, which I
> think will happen regardless of how Quantum provider is implemented. If you wish
> to discuss these details I'll be happy do it on a new thread, so that this one
> can stay focused on the subject of DB inheritance.

how many discrepancies do we expect between the various providers, to be 
actually defined at provider level rather than consumption level?

>
>>
>>>
>>>>
>>>>>
>>>>> In Java this is easily represented by inheritance.
>>>>>
>>>>> In the DB however, there are 3 approaches that we can take:
>>>>>
>>>>>    1. No inheritance.
>>>>>       This means that each type will wit in his own table, with no
>>>>>       relation or re-use.
>>>>>    2. Single table inheritance.
>>>>>       All types sit in a single table, and each has his corresponding
>>>>>       columns.
>>>>>    3. Multiple table inheritance.
>>>>>       Each type sists in his own table, where the PK is FK for the most
>>>>>       basic table (providers).
>>>>>
>>>>>
>>>>> Pros for each approach:
>>>>>
>>>>>    1. None that I can think of.
>>>>>    2. No joins:
>>>>>            Better performance
>>>>>            Easier for developer to see the DB info
>>>>>            Facilitate column reuse
>>>>>    3. Constraints can be set on each column
>>>>>
>>>>> Cons for each approach:
>>>>>
>>>>>    1. No reuse of DB entities + no compliance for column types
>>>>>       Most cumbersome to query all providers
>>>>>    2. Can't put some constraints on non-base columns (esp. not null)
>>>>>    3. Joins are needed - opposite of the pros of 2.
>>>>>
>>>>>    From personal experience, I find #2 to be better and easier to work
>>>>> with & maintain.
>>>>>
>>>>> What are your thoughts?
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>>
>>>>
>>
>>



From alonbl at redhat.com  Sun May 12 14:24:31 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 12 May 2013 10:24:31 -0400 (EDT)
Subject: [Engine-devel] [ANN] Technology preview of new ovirt-engine setup
In-Reply-To: <957684054.312477.1368365722915.JavaMail.root@redhat.com>
Message-ID: <575119832.313475.1368368671523.JavaMail.root@redhat.com>

Hello,

We[1] are working on a re-implementation of ovirt-engine setup to a more advanced and customizable implementation.

A significant feature is the ability to use the installer on different distributions, first was Gentoo[2], I am working on Ubuntu.

Another[3] major features is the ability to use the same setup procedure for production and development.

Among of other changes is the option to install product into existing database without having the DBA user, avoid redirection of root URI into application, ability to customize almost anything, and the option of localization.

Although this is technology preview and likely to break, we merged this so people may experience the new setup at early stage and provide feedback so we may solve as many issues as we can before product release.

So come on, you brave people... let's see you break our setup!

This should be available at tomorrow's nightly packages.

STATUS

Side-by-side installation

New installer and legacy installers are available side-by-side.

Legacy installer: engine-setup, engine-upgrade, engine-cleanup.
New installer: engine-seutp-2, engine-cleanup-2.

This means that once ovirt-engine is installed, there is an option to use the legacy setup or the new setup.

Compatibility

Onces setup is done by either, it cannot be updated by the other.
We will work toward having a solution of upgrade legacy to the new, but not the other way around.

Coverage

setup should be feature complete.
cleanup currently only clean files that were created by the setup, not these which were modified.
upgrade is implemented using re-execution of setup, currently only database upgrade is performed, no package upgrade.

Thank you,
Sandro Bonazzola,
Alex Lourie,
Alon Bar-Lev

[1] Sandro Bonazzola, Alex Lourie, Alon Bar-Lev
[2] https://wiki.gentoo.org/wiki/OVirt
[3] http://lists.ovirt.org/pipermail/engine-devel/2013-May/004532.html


From alonbl at redhat.com  Sun May 12 21:12:33 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 12 May 2013 17:12:33 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for
	ovirt-engine
In-Reply-To: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
Message-ID: <1692979816.341418.1368393153722.JavaMail.root@redhat.com>

Hello,

As promised, I updated the wiki pages of engine developer environment to refer to this[1] single new page, I hope in time we can merge all non-trivial contributions into the README.developer.

Feel free to contribute/fix as you experience issues.

Regards,
Alon Bar-Lev.

[1] http://www.ovirt.org/OVirt_Engine_Development_Environment

----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "Yaniv Bronheim" <ybronhei at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Limor Gavish" <lgavish at gmail.com>,
> "Sharad Mishra" <snmishra at us.ibm.com>, "Alex Lourie" <alourie at redhat.com>, "Sandro Bonazzola" <sbonazzo at redhat.com>,
> "arch" <arch at ovirt.org>, "Ofer Schreiber" <oschreib at redhat.com>
> Sent: Sunday, May 12, 2013 2:52:51 PM
> Subject: [ANN] New development environment for ovirt-engine
> 
> Hello all ovirt-engine developers,
> 
> When I first joined the ovirt project, it took me about two weeks to setup a
> development environment, I needed to work on a bug related to host-deploy so
> I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> communicate with vdsm using SSL, this was virtually impossible to do so
> without tweaking the product in a way that it is so different from
> production use, that I cannot guarantee that whatever tested in development
> will actually work in production.
> 
> I peeked at the installation script in a hope that I can create partial
> environment similar to production, but I found that the packaging
> implementation makes to much assumption and is very difficult to adopt. The
> fact that I do not use fedora/rhel for my development made it even worse.
> 
> I had no other option than to create rpms after each of my changes and test
> each in real production like setup.
> 
> It was obvious to me that the manual customization of developers to achieve
> working product will eventually break as product grow and move away from
> being developer friendly to production friendly. For example, product
> defaults cannot be these which serve developers, but these which serve
> production the best, or having a valid PKI setup cannot be optional any more
> as components do need to use it. Same for location of files and
> configuration, for example, if we write a pluggable infrastructure for
> branding, we cannot damage the interface just because developers runs the
> product in their own manual customization.
> 
> I took the opportunity handed to me to port the ovirt-engine to other
> distributions in order to provide a development environment that is similar
> to production setup. Together with Sandro Bonazzola and Alex Lourie we
> re-wrote the whole installation of the product which can also be used to
> setup the desired development environment.
> 
> Within this environment the product is set up using the same tools and
> configuration as in production, while the process does not require special
> privileges nor changes the state of the developer machine.
> 
> A complete documentation is available[1], I preferred to use README within
> the source tree as wiki tend to quickly become obsolete, while documentation
> within source tree can be modified by the commit that introduces a change. I
> will redirect to this file from the current wiki once the site will be up.
> 
> In a nut shell, after installing prerequisites, build and install the product
> using:
> 
> $ make clean install-dev PREFIX=$HOME/ovirt-engine
> 
> This will run maven and create product installation at $HOME/ovirt-engine
> Next, a setup phase is required just like in production, to initialize
> configuration and database:
> 
> $ $HOME/ovirt-engine/bin/engine-setup-2
> 
> You have now fully functional product, including PKI, SSL, host-deploy,
> tools.
> No manual database updates are required, no lose of functionality.
> 
> All that is left is to start the engine service:
> 
> $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> 
> Access to application:
>    http://localhost:8080
>    https://localhost:8443
> Debugging port is opened at port 8787.
> 
> Farther information exists in the documentation[1].
> 
> There are several inherit benefits of the new environment, the major one is
> the ability to manage several environments in parallel on the same host. For
> example, if we develop two separate features on two branches we can install
> the product into $HOME/ovirt-engine-feature1 and
> $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> modify the ports jboss is listening to we can run two instances of engine at
> the same time!
> 
> We will be happy to work with all developers to assist in porting into the
> new development environment, the simplest is to create a new database for
> this effort. Moti has a sequence of converting the existing database owned
> by postgres to be owned by the engine, Moti, can you please share that?
> 
> We are sure there are missing bits, we will be happy to know these so we can
> improve.
> 
> I am aware that developers (especially java) are conservative, but I ask you
> to give us a chance, so that we make it easy for developers to join the
> project, and to allow us to drop the parallel effort of packaging to
> production and fixing the broken development environment.
> 
> A special thanks to developers who took the time to test and provide feedback
> before the merged:
> - Yaniv Bronheim
> - Moti Asayag
> - Limor Gavish
> - Sharad Mishra
> - Ofer Schreiber
> 
> We are hoping that after migration you will be find this environment useful
> and friendly,
> 
> Sandro Bonazzola,
> Alex Lourie,
> Alon Bar-Lev.
> 
> [1]
> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD


From ovedo at redhat.com  Mon May 13 07:42:17 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Mon, 13 May 2013 03:42:17 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <518FA1C0.8050800@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
	<152608682.188683.1368365511396.JavaMail.root@redhat.com>
	<518FA1C0.8050800@redhat.com>
Message-ID: <1070318695.255850.1368430937329.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Mike Kolesnik" <mkolesni at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, May 12, 2013 5:05:52 PM
> Subject: Re: [Engine-devel] What type of DB inheritance to use?
> 
> On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
> >
> > ----- Original Message -----
> >> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
> >>> ----- Original Message -----
> >>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
> >>>>> Hi All,
> >>>>>
> >>>>> I would like to have your opinions on which inheritance type to use in
> >>>>> the DB.
> >>>>> We are adding an "external provider" entity to the system which will be
> >>>>> able to provide various resources (networks, hosts, etc).
> >>>>>
> >>>>> These providers will be distinguishable by "type".
> >>>>> The basic definition of a provider contains:
> >>>>>
> >>>>>     * name
> >>>>>     * description
> >>>>>     * url
> >>>>>     * type
> >>>>>
> >>>>> Some providers might need additional properties such as:
> >>>>>
> >>>>>     * user
> >>>>>     * password
> >>>>
> >>>> what type of provider won't require authentication?
> >>>
> >>> Quantum provider in the 1st implementation will not require these fields.
> >>> It will eventually require some sort of authentication, but not
> >>> necessarily
> >>> these fields, or only these fields.
> >>
> >> I'm not talking about a POC.
> >> unless we pass through credentials of users for some actions, how do you
> >> use a provider without user/password (or client cert, etc. - i.e., all
> >> authentication methods are usually similar on the info you need to
> >> persist)?
> >
> > I did not say that we will use Quantum without auth, only that these fields
> > may or
> > may not necessarily be in the Quantum provider entity.
> >
> > I think this is regardless of the main discussion here of inheritance,
> > which I
> > think will happen regardless of how Quantum provider is implemented. If you
> > wish
> > to discuss these details I'll be happy do it on a new thread, so that this
> > one
> > can stay focused on the subject of DB inheritance.
> 
> how many discrepancies do we expect between the various providers, to be
> actually defined at provider level rather than consumption level?
> 

IMO, the following fields will fit most providers, at least the ones we plan to support in the near future:
* id
* name
* type
* URL
* requires_authentication (boolean) to support development/POC/testing... mode
* username
* password

> >
> >>
> >>>
> >>>>
> >>>>>
> >>>>> In Java this is easily represented by inheritance.
> >>>>>
> >>>>> In the DB however, there are 3 approaches that we can take:
> >>>>>
> >>>>>    1. No inheritance.
> >>>>>       This means that each type will wit in his own table, with no
> >>>>>       relation or re-use.
> >>>>>    2. Single table inheritance.
> >>>>>       All types sit in a single table, and each has his corresponding
> >>>>>       columns.
> >>>>>    3. Multiple table inheritance.
> >>>>>       Each type sists in his own table, where the PK is FK for the most
> >>>>>       basic table (providers).
> >>>>>
> >>>>>
> >>>>> Pros for each approach:
> >>>>>
> >>>>>    1. None that I can think of.
> >>>>>    2. No joins:
> >>>>>            Better performance
> >>>>>            Easier for developer to see the DB info
> >>>>>            Facilitate column reuse
> >>>>>    3. Constraints can be set on each column
> >>>>>
> >>>>> Cons for each approach:
> >>>>>
> >>>>>    1. No reuse of DB entities + no compliance for column types
> >>>>>       Most cumbersome to query all providers
> >>>>>    2. Can't put some constraints on non-base columns (esp. not null)
> >>>>>    3. Joins are needed - opposite of the pros of 2.
> >>>>>
> >>>>>    From personal experience, I find #2 to be better and easier to work
> >>>>> with & maintain.
> >>>>>
> >>>>> What are your thoughts?
> >>>>>
> >>>>> Regards,
> >>>>> Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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 mkolesni at redhat.com  Mon May 13 07:44:34 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 13 May 2013 03:44:34 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <1070318695.255850.1368430937329.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
	<152608682.188683.1368365511396.JavaMail.root@redhat.com>
	<518FA1C0.8050800@redhat.com>
	<1070318695.255850.1368430937329.JavaMail.root@redhat.com>
Message-ID: <562781423.451106.1368431074616.JavaMail.root@redhat.com>

----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, May 12, 2013 5:05:52 PM
> > Subject: Re: [Engine-devel] What type of DB inheritance to use?
> > 
> > On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
> > >
> > > ----- Original Message -----
> > >> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
> > >>> ----- Original Message -----
> > >>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
> > >>>>> Hi All,
> > >>>>>
> > >>>>> I would like to have your opinions on which inheritance type to use
> > >>>>> in
> > >>>>> the DB.
> > >>>>> We are adding an "external provider" entity to the system which will
> > >>>>> be
> > >>>>> able to provide various resources (networks, hosts, etc).
> > >>>>>
> > >>>>> These providers will be distinguishable by "type".
> > >>>>> The basic definition of a provider contains:
> > >>>>>
> > >>>>>     * name
> > >>>>>     * description
> > >>>>>     * url
> > >>>>>     * type
> > >>>>>
> > >>>>> Some providers might need additional properties such as:
> > >>>>>
> > >>>>>     * user
> > >>>>>     * password
> > >>>>
> > >>>> what type of provider won't require authentication?
> > >>>
> > >>> Quantum provider in the 1st implementation will not require these
> > >>> fields.
> > >>> It will eventually require some sort of authentication, but not
> > >>> necessarily
> > >>> these fields, or only these fields.
> > >>
> > >> I'm not talking about a POC.
> > >> unless we pass through credentials of users for some actions, how do you
> > >> use a provider without user/password (or client cert, etc. - i.e., all
> > >> authentication methods are usually similar on the info you need to
> > >> persist)?
> > >
> > > I did not say that we will use Quantum without auth, only that these
> > > fields
> > > may or
> > > may not necessarily be in the Quantum provider entity.
> > >
> > > I think this is regardless of the main discussion here of inheritance,
> > > which I
> > > think will happen regardless of how Quantum provider is implemented. If
> > > you
> > > wish
> > > to discuss these details I'll be happy do it on a new thread, so that
> > > this
> > > one
> > > can stay focused on the subject of DB inheritance.
> > 
> > how many discrepancies do we expect between the various providers, to be
> > actually defined at provider level rather than consumption level?
> > 
> 
> IMO, the following fields will fit most providers, at least the ones we plan
> to support in the near future:
> * id
> * name
> * type
> * URL
> * requires_authentication (boolean) to support development/POC/testing...
> mode
> * username
> * password

Sounds good to me

> 
> > >
> > >>
> > >>>
> > >>>>
> > >>>>>
> > >>>>> In Java this is easily represented by inheritance.
> > >>>>>
> > >>>>> In the DB however, there are 3 approaches that we can take:
> > >>>>>
> > >>>>>    1. No inheritance.
> > >>>>>       This means that each type will wit in his own table, with no
> > >>>>>       relation or re-use.
> > >>>>>    2. Single table inheritance.
> > >>>>>       All types sit in a single table, and each has his corresponding
> > >>>>>       columns.
> > >>>>>    3. Multiple table inheritance.
> > >>>>>       Each type sists in his own table, where the PK is FK for the
> > >>>>>       most
> > >>>>>       basic table (providers).
> > >>>>>
> > >>>>>
> > >>>>> Pros for each approach:
> > >>>>>
> > >>>>>    1. None that I can think of.
> > >>>>>    2. No joins:
> > >>>>>            Better performance
> > >>>>>            Easier for developer to see the DB info
> > >>>>>            Facilitate column reuse
> > >>>>>    3. Constraints can be set on each column
> > >>>>>
> > >>>>> Cons for each approach:
> > >>>>>
> > >>>>>    1. No reuse of DB entities + no compliance for column types
> > >>>>>       Most cumbersome to query all providers
> > >>>>>    2. Can't put some constraints on non-base columns (esp. not null)
> > >>>>>    3. Joins are needed - opposite of the pros of 2.
> > >>>>>
> > >>>>>    From personal experience, I find #2 to be better and easier to
> > >>>>>    work
> > >>>>> with & maintain.
> > >>>>>
> > >>>>> What are your thoughts?
> > >>>>>
> > >>>>> Regards,
> > >>>>> Mike
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> 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  Mon May 13 06:29:05 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 13 May 2013 09:29:05 +0300
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <704578017.423156.1368426443470.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
	<152608682.188683.1368365511396.JavaMail.root@redhat.com>
	<518FA1C0.8050800@redhat.com>
	<172146744.404267.1368423210856.JavaMail.root@redhat.com>
	<519081BC.2010500@redhat.com>
	<704578017.423156.1368426443470.JavaMail.root@redhat.com>
Message-ID: <51908831.7030107@redhat.com>

On 05/13/2013 09:27 AM, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 05/13/2013 08:33 AM, Mike Kolesnik wrote:
>>> ----- Original Message -----
>>>> On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
>>>>>
>>>>> ----- Original Message -----
>>>>>> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
>>>>>>> ----- Original Message -----
>>>>>>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> I would like to have your opinions on which inheritance type to use
>>>>>>>>> in
>>>>>>>>> the DB.
>>>>>>>>> We are adding an "external provider" entity to the system which will
>>>>>>>>> be
>>>>>>>>> able to provide various resources (networks, hosts, etc).
>>>>>>>>>
>>>>>>>>> These providers will be distinguishable by "type".
>>>>>>>>> The basic definition of a provider contains:
>>>>>>>>>
>>>>>>>>>       * name
>>>>>>>>>       * description
>>>>>>>>>       * url
>>>>>>>>>       * type
>>>>>>>>>
>>>>>>>>> Some providers might need additional properties such as:
>>>>>>>>>
>>>>>>>>>       * user
>>>>>>>>>       * password
>>>>>>>>
>>>>>>>> what type of provider won't require authentication?
>>>>>>>
>>>>>>> Quantum provider in the 1st implementation will not require these
>>>>>>> fields.
>>>>>>> It will eventually require some sort of authentication, but not
>>>>>>> necessarily
>>>>>>> these fields, or only these fields.
>>>>>>
>>>>>> I'm not talking about a POC.
>>>>>> unless we pass through credentials of users for some actions, how do you
>>>>>> use a provider without user/password (or client cert, etc. - i.e., all
>>>>>> authentication methods are usually similar on the info you need to
>>>>>> persist)?
>>>>>
>>>>> I did not say that we will use Quantum without auth, only that these
>>>>> fields
>>>>> may or
>>>>> may not necessarily be in the Quantum provider entity.
>>>>>
>>>>> I think this is regardless of the main discussion here of inheritance,
>>>>> which I
>>>>> think will happen regardless of how Quantum provider is implemented. If
>>>>> you
>>>>> wish
>>>>> to discuss these details I'll be happy do it on a new thread, so that
>>>>> this
>>>>> one
>>>>> can stay focused on the subject of DB inheritance.
>>>>
>>>> how many discrepancies do we expect between the various providers, to be
>>>> actually defined at provider level rather than consumption level?
>>>
>>> I expect at least a few, there has to be some divergence.
>>>
>>> For instance, if we model Glance as a provider then it may require a
>>> "tenant name"
>>> field which is not something Quantum provider requires.
>>
>> actually, since these are both openstack services, why would one need a
>> tenant name and the other wouldn't?
>
> I don't know why this is the case since I'm not familiar with Glance, but
> from what I heard this is one of the fields it needs.
> Either way, we can't expect all OpenStack providers to be modelled the same
> until we model them, and then we will know if they have the same fields or not.
>
>>
>>> Both these providers will be probably linked to a keystone entity, while a
>>> host
>>> provider (such as Foreman) will not be since it doesn't work with keystone.
>>>
>>> We can't expect all providers to be the same, some divergence is bound to
>>> occur.
>>
>> true, but keystone is one of the few authentication aspects which are
>> going to be common to multiple providers, hence don't make sense to be
>> provider specific.
>
> It will be common for OpenStack based providers.
> How about UCSM for instance, should we want to integrate it as a provider?

i'm sure it will require user/password as well.
if we model authentication of providers outside of the providers table, 
it should be a general credentials solution for the various types of 
authentication, not provider specific.

>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> In Java this is easily represented by inheritance.
>>>>>>>>>
>>>>>>>>> In the DB however, there are 3 approaches that we can take:
>>>>>>>>>
>>>>>>>>>      1. No inheritance.
>>>>>>>>>         This means that each type will wit in his own table, with no
>>>>>>>>>         relation or re-use.
>>>>>>>>>      2. Single table inheritance.
>>>>>>>>>         All types sit in a single table, and each has his
>>>>>>>>>         corresponding
>>>>>>>>>         columns.
>>>>>>>>>      3. Multiple table inheritance.
>>>>>>>>>         Each type sists in his own table, where the PK is FK for the
>>>>>>>>>         most
>>>>>>>>>         basic table (providers).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Pros for each approach:
>>>>>>>>>
>>>>>>>>>      1. None that I can think of.
>>>>>>>>>      2. No joins:
>>>>>>>>>              Better performance
>>>>>>>>>              Easier for developer to see the DB info
>>>>>>>>>              Facilitate column reuse
>>>>>>>>>      3. Constraints can be set on each column
>>>>>>>>>
>>>>>>>>> Cons for each approach:
>>>>>>>>>
>>>>>>>>>      1. No reuse of DB entities + no compliance for column types
>>>>>>>>>         Most cumbersome to query all providers
>>>>>>>>>      2. Can't put some constraints on non-base columns (esp. not null)
>>>>>>>>>      3. Joins are needed - opposite of the pros of 2.
>>>>>>>>>
>>>>>>>>>      From personal experience, I find #2 to be better and easier to
>>>>>>>>>      work
>>>>>>>>> with & maintain.
>>>>>>>>>
>>>>>>>>> What are your thoughts?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>



From iheim at redhat.com  Mon May 13 07:46:48 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 13 May 2013 10:46:48 +0300
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <1070318695.255850.1368430937329.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
	<152608682.188683.1368365511396.JavaMail.root@redhat.com>
	<518FA1C0.8050800@redhat.com>
	<1070318695.255850.1368430937329.JavaMail.root@redhat.com>
Message-ID: <51909A68.7080109@redhat.com>

On 05/13/2013 10:42 AM, Oved Ourfalli wrote:
> IMO, the following fields will fit most providers, at least the ones we plan to support in the near future:
> * id
> * name
> * type
> * URL
> * requires_authentication (boolean) to support development/POC/testing... mode

redundant with empty username/password?

> * username
> * password

do keystone based services allow to authenticate directly to them, or 
you need an additional authentication url (to get the ticket)?


From iheim at redhat.com  Mon May 13 06:01:32 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 13 May 2013 09:01:32 +0300
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <172146744.404267.1368423210856.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
	<152608682.188683.1368365511396.JavaMail.root@redhat.com>
	<518FA1C0.8050800@redhat.com>
	<172146744.404267.1368423210856.JavaMail.root@redhat.com>
Message-ID: <519081BC.2010500@redhat.com>

On 05/13/2013 08:33 AM, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
>>>
>>> ----- Original Message -----
>>>> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
>>>>> ----- Original Message -----
>>>>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I would like to have your opinions on which inheritance type to use in
>>>>>>> the DB.
>>>>>>> We are adding an "external provider" entity to the system which will be
>>>>>>> able to provide various resources (networks, hosts, etc).
>>>>>>>
>>>>>>> These providers will be distinguishable by "type".
>>>>>>> The basic definition of a provider contains:
>>>>>>>
>>>>>>>      * name
>>>>>>>      * description
>>>>>>>      * url
>>>>>>>      * type
>>>>>>>
>>>>>>> Some providers might need additional properties such as:
>>>>>>>
>>>>>>>      * user
>>>>>>>      * password
>>>>>>
>>>>>> what type of provider won't require authentication?
>>>>>
>>>>> Quantum provider in the 1st implementation will not require these fields.
>>>>> It will eventually require some sort of authentication, but not
>>>>> necessarily
>>>>> these fields, or only these fields.
>>>>
>>>> I'm not talking about a POC.
>>>> unless we pass through credentials of users for some actions, how do you
>>>> use a provider without user/password (or client cert, etc. - i.e., all
>>>> authentication methods are usually similar on the info you need to
>>>> persist)?
>>>
>>> I did not say that we will use Quantum without auth, only that these fields
>>> may or
>>> may not necessarily be in the Quantum provider entity.
>>>
>>> I think this is regardless of the main discussion here of inheritance,
>>> which I
>>> think will happen regardless of how Quantum provider is implemented. If you
>>> wish
>>> to discuss these details I'll be happy do it on a new thread, so that this
>>> one
>>> can stay focused on the subject of DB inheritance.
>>
>> how many discrepancies do we expect between the various providers, to be
>> actually defined at provider level rather than consumption level?
>
> I expect at least a few, there has to be some divergence.
>
> For instance, if we model Glance as a provider then it may require a "tenant name"
> field which is not something Quantum provider requires.

actually, since these are both openstack services, why would one need a 
tenant name and the other wouldn't?

> Both these providers will be probably linked to a keystone entity, while a host
> provider (such as Foreman) will not be since it doesn't work with keystone.
>
> We can't expect all providers to be the same, some divergence is bound to occur.

true, but keystone is one of the few authentication aspects which are 
going to be common to multiple providers, hence don't make sense to be 
provider specific.

>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> In Java this is easily represented by inheritance.
>>>>>>>
>>>>>>> In the DB however, there are 3 approaches that we can take:
>>>>>>>
>>>>>>>     1. No inheritance.
>>>>>>>        This means that each type will wit in his own table, with no
>>>>>>>        relation or re-use.
>>>>>>>     2. Single table inheritance.
>>>>>>>        All types sit in a single table, and each has his corresponding
>>>>>>>        columns.
>>>>>>>     3. Multiple table inheritance.
>>>>>>>        Each type sists in his own table, where the PK is FK for the most
>>>>>>>        basic table (providers).
>>>>>>>
>>>>>>>
>>>>>>> Pros for each approach:
>>>>>>>
>>>>>>>     1. None that I can think of.
>>>>>>>     2. No joins:
>>>>>>>             Better performance
>>>>>>>             Easier for developer to see the DB info
>>>>>>>             Facilitate column reuse
>>>>>>>     3. Constraints can be set on each column
>>>>>>>
>>>>>>> Cons for each approach:
>>>>>>>
>>>>>>>     1. No reuse of DB entities + no compliance for column types
>>>>>>>        Most cumbersome to query all providers
>>>>>>>     2. Can't put some constraints on non-base columns (esp. not null)
>>>>>>>     3. Joins are needed - opposite of the pros of 2.
>>>>>>>
>>>>>>>     From personal experience, I find #2 to be better and easier to work
>>>>>>> with & maintain.
>>>>>>>
>>>>>>> What are your thoughts?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>



From mkolesni at redhat.com  Mon May 13 06:27:23 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 13 May 2013 02:27:23 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <519081BC.2010500@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
	<152608682.188683.1368365511396.JavaMail.root@redhat.com>
	<518FA1C0.8050800@redhat.com>
	<172146744.404267.1368423210856.JavaMail.root@redhat.com>
	<519081BC.2010500@redhat.com>
Message-ID: <704578017.423156.1368426443470.JavaMail.root@redhat.com>

----- Original Message -----
> On 05/13/2013 08:33 AM, Mike Kolesnik wrote:
> > ----- Original Message -----
> >> On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
> >>>
> >>> ----- Original Message -----
> >>>> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
> >>>>> ----- Original Message -----
> >>>>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
> >>>>>>> Hi All,
> >>>>>>>
> >>>>>>> I would like to have your opinions on which inheritance type to use
> >>>>>>> in
> >>>>>>> the DB.
> >>>>>>> We are adding an "external provider" entity to the system which will
> >>>>>>> be
> >>>>>>> able to provide various resources (networks, hosts, etc).
> >>>>>>>
> >>>>>>> These providers will be distinguishable by "type".
> >>>>>>> The basic definition of a provider contains:
> >>>>>>>
> >>>>>>>      * name
> >>>>>>>      * description
> >>>>>>>      * url
> >>>>>>>      * type
> >>>>>>>
> >>>>>>> Some providers might need additional properties such as:
> >>>>>>>
> >>>>>>>      * user
> >>>>>>>      * password
> >>>>>>
> >>>>>> what type of provider won't require authentication?
> >>>>>
> >>>>> Quantum provider in the 1st implementation will not require these
> >>>>> fields.
> >>>>> It will eventually require some sort of authentication, but not
> >>>>> necessarily
> >>>>> these fields, or only these fields.
> >>>>
> >>>> I'm not talking about a POC.
> >>>> unless we pass through credentials of users for some actions, how do you
> >>>> use a provider without user/password (or client cert, etc. - i.e., all
> >>>> authentication methods are usually similar on the info you need to
> >>>> persist)?
> >>>
> >>> I did not say that we will use Quantum without auth, only that these
> >>> fields
> >>> may or
> >>> may not necessarily be in the Quantum provider entity.
> >>>
> >>> I think this is regardless of the main discussion here of inheritance,
> >>> which I
> >>> think will happen regardless of how Quantum provider is implemented. If
> >>> you
> >>> wish
> >>> to discuss these details I'll be happy do it on a new thread, so that
> >>> this
> >>> one
> >>> can stay focused on the subject of DB inheritance.
> >>
> >> how many discrepancies do we expect between the various providers, to be
> >> actually defined at provider level rather than consumption level?
> >
> > I expect at least a few, there has to be some divergence.
> >
> > For instance, if we model Glance as a provider then it may require a
> > "tenant name"
> > field which is not something Quantum provider requires.
> 
> actually, since these are both openstack services, why would one need a
> tenant name and the other wouldn't?

I don't know why this is the case since I'm not familiar with Glance, but
from what I heard this is one of the fields it needs.
Either way, we can't expect all OpenStack providers to be modelled the same
until we model them, and then we will know if they have the same fields or not.

> 
> > Both these providers will be probably linked to a keystone entity, while a
> > host
> > provider (such as Foreman) will not be since it doesn't work with keystone.
> >
> > We can't expect all providers to be the same, some divergence is bound to
> > occur.
> 
> true, but keystone is one of the few authentication aspects which are
> going to be common to multiple providers, hence don't make sense to be
> provider specific.

It will be common for OpenStack based providers.
How about UCSM for instance, should we want to integrate it as a provider?

> 
> >
> >>
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> In Java this is easily represented by inheritance.
> >>>>>>>
> >>>>>>> In the DB however, there are 3 approaches that we can take:
> >>>>>>>
> >>>>>>>     1. No inheritance.
> >>>>>>>        This means that each type will wit in his own table, with no
> >>>>>>>        relation or re-use.
> >>>>>>>     2. Single table inheritance.
> >>>>>>>        All types sit in a single table, and each has his
> >>>>>>>        corresponding
> >>>>>>>        columns.
> >>>>>>>     3. Multiple table inheritance.
> >>>>>>>        Each type sists in his own table, where the PK is FK for the
> >>>>>>>        most
> >>>>>>>        basic table (providers).
> >>>>>>>
> >>>>>>>
> >>>>>>> Pros for each approach:
> >>>>>>>
> >>>>>>>     1. None that I can think of.
> >>>>>>>     2. No joins:
> >>>>>>>             Better performance
> >>>>>>>             Easier for developer to see the DB info
> >>>>>>>             Facilitate column reuse
> >>>>>>>     3. Constraints can be set on each column
> >>>>>>>
> >>>>>>> Cons for each approach:
> >>>>>>>
> >>>>>>>     1. No reuse of DB entities + no compliance for column types
> >>>>>>>        Most cumbersome to query all providers
> >>>>>>>     2. Can't put some constraints on non-base columns (esp. not null)
> >>>>>>>     3. Joins are needed - opposite of the pros of 2.
> >>>>>>>
> >>>>>>>     From personal experience, I find #2 to be better and easier to
> >>>>>>>     work
> >>>>>>> with & maintain.
> >>>>>>>
> >>>>>>> What are your thoughts?
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Mike
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Engine-devel mailing list
> >>>>>>> Engine-devel at ovirt.org
> >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
> 
> 


From mkolesni at redhat.com  Mon May 13 05:33:30 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 13 May 2013 01:33:30 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <518FA1C0.8050800@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
	<152608682.188683.1368365511396.JavaMail.root@redhat.com>
	<518FA1C0.8050800@redhat.com>
Message-ID: <172146744.404267.1368423210856.JavaMail.root@redhat.com>

----- Original Message -----
> On 05/12/2013 04:31 PM, Mike Kolesnik wrote:
> >
> > ----- Original Message -----
> >> On 05/12/2013 03:16 PM, Mike Kolesnik wrote:
> >>> ----- Original Message -----
> >>>> On 05/12/2013 12:42 PM, Mike Kolesnik wrote:
> >>>>> Hi All,
> >>>>>
> >>>>> I would like to have your opinions on which inheritance type to use in
> >>>>> the DB.
> >>>>> We are adding an "external provider" entity to the system which will be
> >>>>> able to provide various resources (networks, hosts, etc).
> >>>>>
> >>>>> These providers will be distinguishable by "type".
> >>>>> The basic definition of a provider contains:
> >>>>>
> >>>>>     * name
> >>>>>     * description
> >>>>>     * url
> >>>>>     * type
> >>>>>
> >>>>> Some providers might need additional properties such as:
> >>>>>
> >>>>>     * user
> >>>>>     * password
> >>>>
> >>>> what type of provider won't require authentication?
> >>>
> >>> Quantum provider in the 1st implementation will not require these fields.
> >>> It will eventually require some sort of authentication, but not
> >>> necessarily
> >>> these fields, or only these fields.
> >>
> >> I'm not talking about a POC.
> >> unless we pass through credentials of users for some actions, how do you
> >> use a provider without user/password (or client cert, etc. - i.e., all
> >> authentication methods are usually similar on the info you need to
> >> persist)?
> >
> > I did not say that we will use Quantum without auth, only that these fields
> > may or
> > may not necessarily be in the Quantum provider entity.
> >
> > I think this is regardless of the main discussion here of inheritance,
> > which I
> > think will happen regardless of how Quantum provider is implemented. If you
> > wish
> > to discuss these details I'll be happy do it on a new thread, so that this
> > one
> > can stay focused on the subject of DB inheritance.
> 
> how many discrepancies do we expect between the various providers, to be
> actually defined at provider level rather than consumption level?

I expect at least a few, there has to be some divergence.

For instance, if we model Glance as a provider then it may require a "tenant name"
field which is not something Quantum provider requires.
Both these providers will be probably linked to a keystone entity, while a host
provider (such as Foreman) will not be since it doesn't work with keystone.

We can't expect all providers to be the same, some divergence is bound to occur.

> 
> >
> >>
> >>>
> >>>>
> >>>>>
> >>>>> In Java this is easily represented by inheritance.
> >>>>>
> >>>>> In the DB however, there are 3 approaches that we can take:
> >>>>>
> >>>>>    1. No inheritance.
> >>>>>       This means that each type will wit in his own table, with no
> >>>>>       relation or re-use.
> >>>>>    2. Single table inheritance.
> >>>>>       All types sit in a single table, and each has his corresponding
> >>>>>       columns.
> >>>>>    3. Multiple table inheritance.
> >>>>>       Each type sists in his own table, where the PK is FK for the most
> >>>>>       basic table (providers).
> >>>>>
> >>>>>
> >>>>> Pros for each approach:
> >>>>>
> >>>>>    1. None that I can think of.
> >>>>>    2. No joins:
> >>>>>            Better performance
> >>>>>            Easier for developer to see the DB info
> >>>>>            Facilitate column reuse
> >>>>>    3. Constraints can be set on each column
> >>>>>
> >>>>> Cons for each approach:
> >>>>>
> >>>>>    1. No reuse of DB entities + no compliance for column types
> >>>>>       Most cumbersome to query all providers
> >>>>>    2. Can't put some constraints on non-base columns (esp. not null)
> >>>>>    3. Joins are needed - opposite of the pros of 2.
> >>>>>
> >>>>>    From personal experience, I find #2 to be better and easier to work
> >>>>> with & maintain.
> >>>>>
> >>>>> What are your thoughts?
> >>>>>
> >>>>> Regards,
> >>>>> Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>>>
> >>>>
> >>
> >>
> 
> 


From mkolesni at redhat.com  Mon May 13 08:05:47 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 13 May 2013 04:05:47 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <51909A68.7080109@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
	<152608682.188683.1368365511396.JavaMail.root@redhat.com>
	<518FA1C0.8050800@redhat.com>
	<1070318695.255850.1368430937329.JavaMail.root@redhat.com>
	<51909A68.7080109@redhat.com>
Message-ID: <1707564997.456394.1368432347988.JavaMail.root@redhat.com>

----- Original Message -----
> On 05/13/2013 10:42 AM, Oved Ourfalli wrote:
> > IMO, the following fields will fit most providers, at least the ones we
> > plan to support in the near future:
> > * id
> > * name
> > * type
> > * URL
> > * requires_authentication (boolean) to support development/POC/testing...
> > mode
> 
> redundant with empty username/password?

Empty user/password is an implementation details.
Seems logical to me to be explicit about it.

> 
> > * username
> > * password
> 
> do keystone based services allow to authenticate directly to them, or
> you need an additional authentication url (to get the ticket)?
> 

No, the OpenStack services require a header with the token:
"When Keystone is enabled, users that submit requests to the Quantum service must provide an authentication token in X-Auth-Token request header. You obtain the token by authenticating to the Keystone endpoint."

http://docs.openstack.org/api/openstack-network/2.0/content/Authentication-d1e444.html


From iheim at redhat.com  Mon May 13 08:11:21 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 13 May 2013 11:11:21 +0300
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <1707564997.456394.1368432347988.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
	<152608682.188683.1368365511396.JavaMail.root@redhat.com>
	<518FA1C0.8050800@redhat.com>
	<1070318695.255850.1368430937329.JavaMail.root@redhat.com>
	<51909A68.7080109@redhat.com>
	<1707564997.456394.1368432347988.JavaMail.root@redhat.com>
Message-ID: <5190A029.3030801@redhat.com>

On 05/13/2013 11:05 AM, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 05/13/2013 10:42 AM, Oved Ourfalli wrote:
>>> IMO, the following fields will fit most providers, at least the ones we
>>> plan to support in the near future:
>>> * id
>>> * name
>>> * type
>>> * URL
>>> * requires_authentication (boolean) to support development/POC/testing...
>>> mode
>>
>> redundant with empty username/password?
>
> Empty user/password is an implementation details.
> Seems logical to me to be explicit about it.
>
>>
>>> * username
>>> * password
>>
>> do keystone based services allow to authenticate directly to them, or
>> you need an additional authentication url (to get the ticket)?
>>
>
> No, the OpenStack services require a header with the token:
> "When Keystone is enabled, users that submit requests to the Quantum service must provide an authentication token in X-Auth-Token request header. You obtain the token by authenticating to the Keystone endpoint."
>
> http://docs.openstack.org/api/openstack-network/2.0/content/Authentication-d1e444.html
>

so you are missing an 'authentication url' field, although i think there 
was some discussion that until we expect more than a single keystone, 
may be a config


From mkolesni at redhat.com  Mon May 13 08:15:04 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 13 May 2013 04:15:04 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <5190A029.3030801@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
	<152608682.188683.1368365511396.JavaMail.root@redhat.com>
	<518FA1C0.8050800@redhat.com>
	<1070318695.255850.1368430937329.JavaMail.root@redhat.com>
	<51909A68.7080109@redhat.com>
	<1707564997.456394.1368432347988.JavaMail.root@redhat.com>
	<5190A029.3030801@redhat.com>
Message-ID: <1877632012.460071.1368432904783.JavaMail.root@redhat.com>

----- Original Message -----
> On 05/13/2013 11:05 AM, Mike Kolesnik wrote:
> > ----- Original Message -----
> >> On 05/13/2013 10:42 AM, Oved Ourfalli wrote:
> >>> IMO, the following fields will fit most providers, at least the ones we
> >>> plan to support in the near future:
> >>> * id
> >>> * name
> >>> * type
> >>> * URL
> >>> * requires_authentication (boolean) to support development/POC/testing...
> >>> mode
> >>
> >> redundant with empty username/password?
> >
> > Empty user/password is an implementation details.
> > Seems logical to me to be explicit about it.
> >
> >>
> >>> * username
> >>> * password
> >>
> >> do keystone based services allow to authenticate directly to them, or
> >> you need an additional authentication url (to get the ticket)?
> >>
> >
> > No, the OpenStack services require a header with the token:
> > "When Keystone is enabled, users that submit requests to the Quantum
> > service must provide an authentication token in X-Auth-Token request
> > header. You obtain the token by authenticating to the Keystone endpoint."
> >
> > http://docs.openstack.org/api/openstack-network/2.0/content/Authentication-d1e444.html
> >
> 
> so you are missing an 'authentication url' field, although i think there
> was some discussion that until we expect more than a single keystone,
> may be a config
> 

I think at this point it makes sense to keep as config value and in the next phase of
OpenStack providers integration we can model the keystone & tenant entities properly.
I do however, agree with oved, that the username/password should be kept per provider.


From lzelkha at redhat.com  Mon May 13 08:40:31 2013
From: lzelkha at redhat.com (Liran Zelkha)
Date: Mon, 13 May 2013 04:40:31 -0400 (EDT)
Subject: [Engine-devel] DB performance optimization
In-Reply-To: <1954616868.195291.1368434234522.JavaMail.root@redhat.com>
Message-ID: <800980980.196059.1368434431509.JavaMail.root@redhat.com>

Hi all,

There is a WIP for caching and DB performance optimization. Please look at - http://gerrit.ovirt.org/#/c/14188/4

To summarize, it includes automatic caching for some business entities (*_static for instance), break up of VDS to VDS_static, VDS_dynamic and VDS_statistics, and support for batch updates.

Please share if/where you think batch updates can be used (for a usage scenario, please check InterfaceDaoDbFacadeImpl.massUpdateStatisticsForVds()).

Future tasks will include update sensitivity, better Collection caching and trying to minimize getConnection() calls.

Would love your comments and ideas. 

Thanks.


From lhornyak at redhat.com  Mon May 13 09:28:59 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 13 May 2013 05:28:59 -0400 (EDT)
Subject: [Engine-devel] DB performance optimization
In-Reply-To: <800980980.196059.1368434431509.JavaMail.root@redhat.com>
References: <800980980.196059.1368434431509.JavaMail.root@redhat.com>
Message-ID: <386344321.209599.1368437339583.JavaMail.root@redhat.com>

Hi Liran,

Thanks for this patch, I have been asking for caching for a long while and I hope to see caching in the engine soon.

Beyond the comments I have made to your patch, I have some questions about the idea just to start the discussion.

So your cache solution is caching data based on SQL statements?
What will the cache do if we query the same data with two different SQL statements? e.g. you can query from views like vms and sometimes we only query the vm_static and we should get the same vm_static.
Also, how will you deal with updates? e.g. when you update the vm_static record, that vm_static record must be updated or invalidated but also the vm record from

Thx,
Laszlo

----- Original Message -----
> From: "Liran Zelkha" <lzelkha at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, May 13, 2013 10:40:31 AM
> Subject: [Engine-devel] DB performance optimization
> 
> Hi all,
> 
> There is a WIP for caching and DB performance optimization. Please look at -
> http://gerrit.ovirt.org/#/c/14188/4
> 
> To summarize, it includes automatic caching for some business entities
> (*_static for instance), break up of VDS to VDS_static, VDS_dynamic and
> VDS_statistics, and support for batch updates.
> 
> Please share if/where you think batch updates can be used (for a usage
> scenario, please check
> InterfaceDaoDbFacadeImpl.massUpdateStatisticsForVds()).
> 
> Future tasks will include update sensitivity, better Collection caching and
> trying to minimize getConnection() calls.
> 
> Would love your comments and ideas.
> 
> Thanks.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From cfergeau at redhat.com  Mon May 13 10:09:56 2013
From: cfergeau at redhat.com (Christophe Fergeau)
Date: Mon, 13 May 2013 12:09:56 +0200
Subject: [Engine-devel] [Spice-devel] ovirt user portal and attach a cd
In-Reply-To: <518CB967.2060504@redhat.com>
References: <517E2F37.3010807@arnes.si>
	<1682099686.6160454.1367226745207.JavaMail.root@redhat.com>
	<517E4629.5050001@arnes.si> <5188D045.8030004@arnes.si>
	<518CB3D2.5030605@redhat.com> <518CB76A.3090407@arnes.si>
	<518CB967.2060504@redhat.com>
Message-ID: <20130513100956.GF3471@teriyaki>

Hi,

On Fri, May 10, 2013 at 12:09:59PM +0300, Itamar Heim wrote:
> On 05/10/2013 12:01 PM, Andrej Bagon wrote:
> >while pressing the http://elmarco.fedorapeople.org/spice.cab download
> >link there is a file Not Found. There is no .cab file in the directory
> >listing either.
> 
> maybe spice-devel (cc'd) knows of a different one

I don't think there's an alternate link for this, my understanding is that
the spice.cab file was there for some private tests, this was not an
official release.

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/20130513/fb82fb57/attachment.sig>

From wlbleaboy at 126.com  Mon May 13 10:17:20 2013
From: wlbleaboy at 126.com (leaboy@126)
Date: Mon, 13 May 2013 18:17:20 +0800
Subject: [Engine-devel] ovirt-engine-sdk with C
Message-ID: <000101ce4fc3$0f359570$2da0c050$@com>

Hi?All

         I felt oivrt-engine-sdk coded with Python is slowly to connect

ovirt-engine and console vm when a user have many vms, So, I just

want to rewrite the sdk with C(ANSI C Language). Just rewrite a sdk

with C to connect overt-engine and console vm, would anyone give 

me some suggestion.

 

         Now, the problem is how can I connect to ovit-engine with C, and

how can I get some information of vms, and how ovirrt-engine can 

respond my action(start,stop, .eg)

 

 
Leaboy at beijing

                                                                 Thinks

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

From yzaslavs at redhat.com  Mon May 13 11:25:06 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 13 May 2013 07:25:06 -0400 (EDT)
Subject: [Engine-devel] DB performance optimization
In-Reply-To: <386344321.209599.1368437339583.JavaMail.root@redhat.com>
References: <800980980.196059.1368434431509.JavaMail.root@redhat.com>
	<386344321.209599.1368437339583.JavaMail.root@redhat.com>
Message-ID: <1097128629.359949.1368444306009.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Liran Zelkha" <lzelkha at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, May 13, 2013 12:28:59 PM
> Subject: Re: [Engine-devel] DB performance optimization
> 
> Hi Liran,
> 
> Thanks for this patch, I have been asking for caching for a long while and I
> hope to see caching in the engine soon.
> 
> Beyond the comments I have made to your patch, I have some questions about
> the idea just to start the discussion.
> 
> So your cache solution is caching data based on SQL statements?
> What will the cache do if we query the same data with two different SQL
> statements? e.g. you can query from views like vms and sometimes we only
> query the vm_static and we should get the same vm_static.
> Also, how will you deal with updates? e.g. when you update the vm_static
> record, that vm_static record must be updated or invalidated but also the vm
> record from
> 
> Thx,
> Laszlo

Laszlo - +1 on your requests for caching. (At least) I am aware to them, and we talked about this issue many times.
I am also happy we began this efforts.
I would like to state that your questions are good - I also asked Liran about them, and debated about them myself when I was thinking about caching.
Liran's approach is to build this caching step by step. You will see (and I'll let Liran elaborate) that even with this "simple" caching, we have an improvement.


> 
> ----- Original Message -----
> > From: "Liran Zelkha" <lzelkha at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Monday, May 13, 2013 10:40:31 AM
> > Subject: [Engine-devel] DB performance optimization
> > 
> > Hi all,
> > 
> > There is a WIP for caching and DB performance optimization. Please look at
> > -
> > http://gerrit.ovirt.org/#/c/14188/4
> > 
> > To summarize, it includes automatic caching for some business entities
> > (*_static for instance), break up of VDS to VDS_static, VDS_dynamic and
> > VDS_statistics, and support for batch updates.
> > 
> > Please share if/where you think batch updates can be used (for a usage
> > scenario, please check
> > InterfaceDaoDbFacadeImpl.massUpdateStatisticsForVds()).
> > 
> > Future tasks will include update sensitivity, better Collection caching and
> > trying to minimize getConnection() calls.
> > 
> > Would love your comments and ideas.
> > 
> > Thanks.
> > _______________________________________________
> > 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 mpastern at redhat.com  Mon May 13 12:04:30 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 13 May 2013 15:04:30 +0300
Subject: [Engine-devel] ovirt-engine-sdk with C
In-Reply-To: <000101ce4fc3$0f359570$2da0c050$@com>
References: <000101ce4fc3$0f359570$2da0c050$@com>
Message-ID: <5190D6CE.7090009@redhat.com>

On 05/13/2013 01:17 PM, leaboy at 126 wrote:
> Hi?All
> 
> I felt oivrt-engine-sdk coded with Python is slowly to connect
> 
> ovirt-engine and console vm when a user have many vms, 
> So, I just, want to rewrite the sdk with C(ANSI C Language). Just rewrite a sdk
> 
> with C to connect overt-engine and console vm, would anyone give

the amount of VMs should not effect private actions on vm, please show me
your code, maybe i can advice on this.

> 
> me some suggestion.
> 
>  
> 
>          Now, the problem is how can I connect to ovit-engine with C, and
> 
> how can I get some information of vms, and how ovirrt-engine can
> 
> respond my action(start,stop, .eg)
> 
>  
> 
>                                                                                     Leaboy at beijing
> 
>                                                                  Thinks
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From lzelkha at redhat.com  Mon May 13 10:15:31 2013
From: lzelkha at redhat.com (Liran Zelkha)
Date: Mon, 13 May 2013 06:15:31 -0400 (EDT)
Subject: [Engine-devel] DB performance optimization
In-Reply-To: <386344321.209599.1368437339583.JavaMail.root@redhat.com>
References: <800980980.196059.1368434431509.JavaMail.root@redhat.com>
	<386344321.209599.1368437339583.JavaMail.root@redhat.com>
Message-ID: <1634331954.217313.1368440131985.JavaMail.root@redhat.com>

Hi Laszlo,

I agree with both of your comments.
1. Duplicate data cache. Right now it is definitely possible. 
2. Updates. Right now there is only a time based invalidation, but that will be changed. We will add a feature to map between stored procedures and the tables they update, and will invalidate relevant data.

Caching on the SQL level is hard (harder than Hibernate 2nd level cache for instance) but that's what we have right now... (And I'm not sure that JPA/Hibernate will be better).

----- Original Message -----
From: "Laszlo Hornyak" <lhornyak at redhat.com>
To: "Liran Zelkha" <lzelkha at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>
Sent: Monday, May 13, 2013 12:28:59 PM
Subject: Re: [Engine-devel] DB performance optimization

Hi Liran,

Thanks for this patch, I have been asking for caching for a long while and I hope to see caching in the engine soon.

Beyond the comments I have made to your patch, I have some questions about the idea just to start the discussion.

So your cache solution is caching data based on SQL statements?
What will the cache do if we query the same data with two different SQL statements? e.g. you can query from views like vms and sometimes we only query the vm_static and we should get the same vm_static.
Also, how will you deal with updates? e.g. when you update the vm_static record, that vm_static record must be updated or invalidated but also the vm record from

Thx,
Laszlo

----- Original Message -----
> From: "Liran Zelkha" <lzelkha at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, May 13, 2013 10:40:31 AM
> Subject: [Engine-devel] DB performance optimization
> 
> Hi all,
> 
> There is a WIP for caching and DB performance optimization. Please look at -
> http://gerrit.ovirt.org/#/c/14188/4
> 
> To summarize, it includes automatic caching for some business entities
> (*_static for instance), break up of VDS to VDS_static, VDS_dynamic and
> VDS_statistics, and support for batch updates.
> 
> Please share if/where you think batch updates can be used (for a usage
> scenario, please check
> InterfaceDaoDbFacadeImpl.massUpdateStatisticsForVds()).
> 
> Future tasks will include update sensitivity, better Collection caching and
> trying to minimize getConnection() calls.
> 
> Would love your comments and ideas.
> 
> Thanks.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From vszocs at redhat.com  Mon May 13 14:23:30 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Mon, 13 May 2013 10:23:30 -0400 (EDT)
Subject: [Engine-devel] UI Plugins: issue with REST API keep-alive heartbeat
	fixed
In-Reply-To: <725259538.605644.1368454207299.JavaMail.root@redhat.com>
Message-ID: <1013558570.627274.1368455010052.JavaMail.root@redhat.com>

Hi guys,

just a quick update, recently we fixed an issue [1] with UI Plugin REST API integration trying to keep-alive the current REST API session, which was causing repeated "User logged in" events in GUI, along with new REST API session created each time the heartbeat request was fired. Please refer to commit message for more details on this issue.

There are some things to be aware of with regard to UI Plugin REST API integration:
- all plugins still receive a single session ID based on WebAdmin user credentials, i.e. keep the current "single-admin-session-for-all-plugins" behavior
- session timeout is set to 6 hours --> 2x more than default REST API session timeout
- WebAdmin will *not* try to keep-alive the session via periodic heartbeat requests, i.e. break the current "keep-session-alive-while-user-stays-authenticated" behavior

In practice, this means that after a user logs into WebAdmin, if no plugin interacts with the REST API session via provided ID for more than 6 hours, the session will time-out eventually. Unfortunately, for now, we can't support the session keep-alive mechanism due to issues with HTTP 'Authorization' header handling in web browsers, but with RFE [2] it would be possible to re-implement the session keep-alive mechanism.

On the other hand, we'll most likely revisit the current "single-admin-session-for-all-plugins" behavior in future, i.e. have special Engine users created for use with UI Plugin REST API integration, with permissions of such users under control by the admin. This would change the current behavior to something like "separate-user-session-for-each-plugin", with individual plugins able to create their own REST API session on demand.

Regards,
Vojtech

[1] http://gerrit.ovirt.org/#/c/14411/


From michal.skrivanek at redhat.com  Mon May 13 14:53:15 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Mon, 13 May 2013 16:53:15 +0200
Subject: [Engine-devel] spice-xpi(firefox) plugin for Windows
In-Reply-To: <1368204833.7136.278.camel@cihla.usersys.redhat.com>
References: <20130417124545.GB13447@teriyaki.redhat.com>
	<CAEWPe=piRie7MveRfJ_i+S=bO-2tfiJmoum9JcdS6BPOHteHeA@mail.gmail.com>
	<8EB4DD94-60E2-4B88-9E58-AF1BBC6765DA@redhat.com>
	<CAEWPe=pvGt3TySpLJN5UAaqs=zWGx9_L7fqN4+xPg-=fMhun8w@mail.gmail.com>
	<1368204833.7136.278.camel@cihla.usersys.redhat.com>
Message-ID: <F5D1ADEC-363E-4278-9644-2F9728182D85@redhat.com>


On May 10, 2013, at 18:53 , David Ja?a <djasa at redhat.com> wrote:

> Hi,
> 
> writing from top of my head so this may not be 100 % accurate:
> 
> Dead Horse p??e v P? 10. 05. 2013 v 11:38 -0500:
>> I played a bit with the MIME and browsers.
>> 
>> When switching between spice/vnc/rdp protocols since the connection
>> file that comes down is extension ".vv" this is an issue. Once you
>> have associated a MIME type of ".vv"
>> 
>> one of the local clients (SPICE or VNC or RDP) the browser now thinks
>> that ".vv" files should be used with whatever it was associated with
>> only. This is to say should the extension be something different for
>> each protocol so each protocol could be used and associated with a
>> local client?
> 
> I guess that this exception should apply just for RDP because
> {virt,remote}-viewer supports both spice and vnc AFAIK.
RDP is being worked on by Franta right now. It should make it for 3.3...

>> 
>> 
>> Also I have not yet been able to get RDP to work at all. On windows 7
>> systems under IE 9 is always greyed nor selectable (using latest
>> master). Using the connection files ".vv" and opening them with
>> remote-viewer to tight-vnc for example does not work at all. 
> 
> Given ^^^ and that another vnc client would need to add the .vv file
> format support, I don't think that it's a good idea
> 
>> I have spice certificates and ssl disabled as well so that cannot get
>> in the way.
> 
> Unlike spice and vnc, rdp server is not provided by qemu but by VM
> itself, so in order to make it work, engine must learn VM IP address
> from RHEV Agent (so RHEV Agent service must be up'n'running in the VM)
> and the VM must be configured to accept incoming RDP connections.
> 
> Because {virt,remote}-viewer doesn't support RDP (AFAIK) and no other
> client has support for .vv files, I don't think that they should be
> generated for rdp connection so if engine indeed generates the files,
> that sound like a bug for me (for the time being, till
> {virt,remote}-viewer gains RDP support or some rdp client gets .vv file
> format support).
> 
> David
>> 
>> 
>> Any quick pointers on actually getting RDP to work or the connection
>> files to work with a local remote-viewer or vnc client?
>> 
>> 
>> - DHC
>> 
>> 
>> 
>> On Fri, Apr 19, 2013 at 3:08 AM, Michal Skrivanek
>> <michal.skrivanek at redhat.com> wrote:
>> 
>>        On 18 Apr 2013, at 17:57, Dead Horse wrote:
>> 
>>> Nicely done and this would definitely be useful. Nothing is
>>> more nauseating then being forced to use Internet Exploder
>>> to interact with an ovirt/KVM SPICE console under windows.
>>> For the plugin deployment this is definitely a point of
>>> pain. At the moment ovirt users wishing to use the SPICE
>>> Activex plugin must use an an dated version of the SPICE
>>> client packaged with the necessary SpiceX.dll.
>>> (http://elmarco.fedorapeople.org/spice.cab)
>>> 
>>> They must also take manual steps to install and deploy the
>>> plugin on ovirt-engine server (this very painful to users).
>>> The versions of the SPICE client also made available to the
>>> community here: http://spice-space.org/download/gtk/windows/
>>> are also a bit dated and do not include the plugin
>>> (SpiceX.dll).
>>> 
>>        MIME file SPICE and VNC support is in oVirt master for couple
>>        of weeks now. This should work on all browsers with latest
>>        remote-viewer client.
>> 
>> 
>>> 
>>> 
>>> Perhaps a plugin deployment page linked from the main ovirt
>>> landing page would be a prudent way to deploy the plugin?
>>> 
>>> In any event a working SPICE Plugin for Firefox and newer
>>> SPICE Client version under windows would be a very welcome
>>> sight indeed.
>>> 
>>        definitely.
>>        Another alternative planned for 3.3 is SPICE HTML5, it has
>>        lots of limitations, but it's purely browser-based solution.
>> 
>>> 
>>> 
>>> I think one of the most frequently asked questions or gripes
>>> I see about ovirt is around SPICE console issues and
>>> concerns.
>>> 
>>        indeed. And we'll have 3 solutions soon!:-)
>> 
>> 
>>        Thanks,
>>        michal
>> 
>>> 
>>> 
>>> - DHC
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Apr 17, 2013 at 7:45 AM, Christophe Fergeau
>>> <cfergeau at redhat.com> wrote:
>>>        Hi everyone,
>>> 
>>>        Lately I've been hacking on getting the spice-xpi
>>>        plugin to work on
>>>        Windows. This is the Firefox plugin that is used on
>>>        Linux to implement
>>>        the portal SPICE console.
>>> 
>>>        This work has now been merged upstream (
>>>        http://cgit.freedesktop.org/spice/spice-xpi/ ), and
>>>        I've pushed a
>>>        scratch build using mingw available from
>>>        http://koji.fedoraproject.org/koji/taskinfo?taskID=5265107 (this will go
>>>        away in several days). Copying this dll + its
>>>        dependencies to the
>>>        C:\Program Files\Mozilla Firefox\plugins directory
>>>        are enough to get
>>>        a spice-xpi plugin to show up in about:plugins, and
>>>        to then be able
>>>        to start a SPICE client from the spice-xpi test page
>>>        (
>>>        http://teuf.fedorapeople.org/plugins/test.html ).
>>>        The dependencies I had to copy are:
>>> 
>>>        gspawn-win32-helper-console.exe
>>>        gspawn-win32-helper.exe
>>>        iconv.dll
>>>        libffi-6.dll
>>>        libgcc_s_sjlj-1.dll
>>>        libgio-2.0-0.dll
>>>        libglib-2.0-0.dll
>>>        libgmodule-2.0-0.dll
>>>        libgobject-2.0-0.dll
>>>        libgthread-2.0-0.dll
>>>        libintl-8.dll
>>>        libstdc++-6.dll
>>>        pthreadGC2.dll
>>>        zlib1.dll
>>> 
>>>        (I picked them from the various mingw-* fedora
>>>        packages).
>>> 
>>> 
>>>        The reason for this email is that to be usable from
>>>        oVirt, some portal
>>>        changes are needed as it currently only tries to use
>>>        the spice-xpi plugin
>>>        on Linux platforms.
>>>        Another fuzzy bit is how to get this plugin to the
>>>        users' machines...
>>> 
>>> 
>>>        And that's about all I had to say in that email ;)
>>>        Let me know if that's
>>>        useful to oVirt, how you want to integrate this, ...
>>> 
>>>        Cheers,
>>> 
>>>        Christophe
>>> 
>>>        _______________________________________________
>>>        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
> 
> -- 
> 
> David Ja?a, RHCE
> 
> SPICE QE based in Brno
> GPG Key:     22C33E24 
> Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
> 
> 



From bazulay at redhat.com  Mon May 13 19:34:02 2013
From: bazulay at redhat.com (Barak Azulay)
Date: Mon, 13 May 2013 15:34:02 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for
	ovirt-engine
In-Reply-To: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
Message-ID: <545E4A23-4E49-478F-B8E8-FBB7488C22ED@redhat.com>

Good work guys,

Thanks
Barak Azulay



On May 12, 2013, at 14:52, Alon Bar-Lev <alonbl at redhat.com> wrote:

> Hello all ovirt-engine developers,
> 
> When I first joined the ovirt project, it took me about two weeks to setup a development environment, I needed to work on a bug related to host-deploy so I needed an environment that could use the ssh, PKI, vdsm-bootstrap and communicate with vdsm using SSL, this was virtually impossible to do so without tweaking the product in a way that it is so different from production use, that I cannot guarantee that whatever tested in development will actually work in production.
> 
> I peeked at the installation script in a hope that I can create partial environment similar to production, but I found that the packaging implementation makes to much assumption and is very difficult to adopt. The fact that I do not use fedora/rhel for my development made it even worse.
> 
> I had no other option than to create rpms after each of my changes and test each in real production like setup.
> 
> It was obvious to me that the manual customization of developers to achieve working product will eventually break as product grow and move away from being developer friendly to production friendly. For example, product defaults cannot be these which serve developers, but these which serve production the best, or having a valid PKI setup cannot be optional any more as components do need to use it. Same for location of files and configuration, for example, if we write a pluggable infrastructure for branding, we cannot damage the interface just because developers runs the product in their own manual customization.
> 
> I took the opportunity handed to me to port the ovirt-engine to other distributions in order to provide a development environment that is similar to production setup. Together with Sandro Bonazzola and Alex Lourie we re-wrote the whole installation of the product which can also be used to setup the desired development environment.
> 
> Within this environment the product is set up using the same tools and configuration as in production, while the process does not require special privileges nor changes the state of the developer machine. 
> 
> A complete documentation is available[1], I preferred to use README within the source tree as wiki tend to quickly become obsolete, while documentation within source tree can be modified by the commit that introduces a change. I will redirect to this file from the current wiki once the site will be up.
> 
> In a nut shell, after installing prerequisites, build and install the product using:
> 
> $ make clean install-dev PREFIX=$HOME/ovirt-engine
> 
> This will run maven and create product installation at $HOME/ovirt-engine
> Next, a setup phase is required just like in production, to initialize configuration and database:
> 
> $ $HOME/ovirt-engine/bin/engine-setup-2
> 
> You have now fully functional product, including PKI, SSL, host-deploy, tools.
> No manual database updates are required, no lose of functionality.
> 
> All that is left is to start the engine service:
> 
> $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> 
> Access to application:
>   http://localhost:8080
>   https://localhost:8443
> Debugging port is opened at port 8787.
> 
> Farther information exists in the documentation[1].
> 
> There are several inherit benefits of the new environment, the major one is the ability to manage several environments in parallel on the same host. For example, if we develop two separate features on two branches we can install the product into $HOME/ovirt-engine-feature1 and $HOME/ovirt-engine-feature-2 and have a separate database for each, if we modify the ports jboss is listening to we can run two instances of engine at the same time!
> 
> We will be happy to work with all developers to assist in porting into the new development environment, the simplest is to create a new database for this effort. Moti has a sequence of converting the existing database owned by postgres to be owned by the engine, Moti, can you please share that?
> 
> We are sure there are missing bits, we will be happy to know these so we can improve.
> 
> I am aware that developers (especially java) are conservative, but I ask you to give us a chance, so that we make it easy for developers to join the project, and to allow us to drop the parallel effort of packaging to production and fixing the broken development environment. 
> 
> A special thanks to developers who took the time to test and provide feedback before the merged:
> - Yaniv Bronheim
> - Moti Asayag
> - Limor Gavish
> - Sharad Mishra
> - Ofer Schreiber
> 
> We are hoping that after migration you will be find this environment useful and friendly,
> 
> Sandro Bonazzola,
> Alex Lourie,
> Alon Bar-Lev.
> 
> [1] http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 
> 


From ecohen at redhat.com  Mon May 13 20:10:59 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Mon, 13 May 2013 16:10:59 -0400 (EDT)
Subject: [Engine-devel] UI Plugins: issue with REST API keep-alive
 heartbeat	fixed
In-Reply-To: <1013558570.627274.1368455010052.JavaMail.root@redhat.com>
References: <1013558570.627274.1368455010052.JavaMail.root@redhat.com>
Message-ID: <1733305282.1046497.1368475859539.JavaMail.root@redhat.com>

> ----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> Sent: Monday, May 13, 2013 10:23:30 AM
> 
> Hi guys,
> 
> just a quick update, recently we fixed an issue [1] with UI Plugin REST API
> integration trying to keep-alive the current REST API session, which was
> causing repeated "User logged in" events in GUI, along with new REST API
> session created each time the heartbeat request was fired. Please refer to
> commit message for more details on this issue.
> 
> There are some things to be aware of with regard to UI Plugin REST API
> integration:
> - all plugins still receive a single session ID based on WebAdmin user
> credentials, i.e. keep the current "single-admin-session-for-all-plugins"
> behavior
> - session timeout is set to 6 hours --> 2x more than default REST API session
> timeout
> - WebAdmin will *not* try to keep-alive the session via periodic heartbeat
> requests, i.e. break the current
> "keep-session-alive-while-user-stays-authenticated" behavior
> 
> In practice, this means that after a user logs into WebAdmin, if no plugin
> interacts with the REST API session via provided ID for more than 6 hours,
> the session will time-out eventually. Unfortunately, for now, we can't
> support the session keep-alive mechanism due to issues with HTTP
> 'Authorization' header handling in web browsers, but with RFE [2] it would
> be possible to re-implement the session keep-alive mechanism.
> 
> On the other hand, we'll most likely revisit the current
> "single-admin-session-for-all-plugins" behavior in future, i.e. have special
> Engine users created for use with UI Plugin REST API integration, with
> permissions of such users under control by the admin. This would change the
> current behavior to something like "separate-user-session-for-each-plugin",
> with individual plugins able to create their own REST API session on demand.
> 
> Regards,
> Vojtech
> 
> [1] http://gerrit.ovirt.org/#/c/14411/

Thanks, Vojtech - just adding the missing RFE reference ([2]):
[2] Bug 958861 - Support passing auth information without having to use HTTP Authorization header
[https://bugzilla.redhat.com/show_bug.cgi?id=958861]



From deadhorseconsulting at gmail.com  Mon May 13 21:47:46 2013
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Mon, 13 May 2013 16:47:46 -0500
Subject: [Engine-devel] cannot attach ISO with latest master
Message-ID: <CAEWPe=rogGmX_OBNb2f=aMuYucgUqYKiyksDEr75wxfME6uLYQ@mail.gmail.com>

Cannot attach images from the iso storage domain with latest master.
VDSM version is latest master as well
Host = EL6.4

2013-05-13 16:41:02,184 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
(ajp--127.0.0.1-8702-7) [5d889258] START, IsoPrefixVDSCommand(
storagePoolId = 0cba78bd-f1b7-438f-afac-acd59fab92ae, ignoreFailoverLimit =
false, compatabilityVersion = null), log id: a85d3c0
2013-05-13 16:41:02,196 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
(ajp--127.0.0.1-8702-7) [5d889258] FINISH, IsoPrefixVDSCommand, return:
/rhev/data-center/mnt/192.168.0.1:_ovirt_dalaran/d6276dc3-1714-4024-9b70-b7971ed5fe35/images/11111111-1111-1111-1111-111111111111,
log id: a85d3c0
2013-05-13 16:41:02,328 WARN  [org.ovirt.engine.core.bll.RunVmOnceCommand]
(ajp--127.0.0.1-8702-7) [5d889258] CanDoAction of action RunVmOnce failed.
Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH

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

From fsimonce at redhat.com  Mon May 13 23:07:31 2013
From: fsimonce at redhat.com (Federico Simoncelli)
Date: Mon, 13 May 2013 19:07:31 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <51909A68.7080109@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<518F87B0.2030202@redhat.com>
	<2022393695.178661.1368361003309.JavaMail.root@redhat.com>
	<518F8E79.20503@redhat.com>
	<152608682.188683.1368365511396.JavaMail.root@redhat.com>
	<518FA1C0.8050800@redhat.com>
	<1070318695.255850.1368430937329.JavaMail.root@redhat.com>
	<51909A68.7080109@redhat.com>
Message-ID: <121337772.855748.1368486451437.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, May 13, 2013 9:46:48 AM
> Subject: Re: [Engine-devel] What type of DB inheritance to use?
> 
> On 05/13/2013 10:42 AM, Oved Ourfalli wrote:
> > IMO, the following fields will fit most providers, at least the ones we
> > plan to support in the near future:
> > * id
> > * name
> > * type
> > * URL
> > * requires_authentication (boolean) to support development/POC/testing...
> > mode
> 
> redundant with empty username/password?
> 
> > * username
> > * password
> 
> do keystone based services allow to authenticate directly to them, or
> you need an additional authentication url (to get the ticket)?

You need the ticket, but we said that the keystone service (auth url, username
and password) are config values for the time being. Anyway in the future I expect
these providers to be linked to their keystone service. E.g.:

id name       username  password  url              auth_provider  tenant   ...
1  keystone1  myuser    mypass    http://keystone  <null>         <null>
2  glance1    <null>    <null>    http://glance    1              mytenant1
3  glance1    <null>    <null>    http://glance    1              mytenant2
4  quantum1   <null>    <null>    http://quantum   1              mytenant1

I expect quantum to be needing the tenant name too (as soon as it will be
integrated with keystone).

Given the username/password (created for the ovirt management), the user can
be added to the tenants (all the ones that the admin wants to consume) and
then ovirt will get the auth tokens with the relevant info, e.g. (pseudocode
with reference to the table above):

  keystone = new Keystone("http://keystone");
  glance1_token = keystone.authenticate("myuser", "mypass", "mytenant1");
  glance2_token = keystone.authenticate("myuser", "mypass", "mytenant2");
  quantum1_token = glance1_token;

  glance = new Glance("http://glance", glance1_token);
  glance.listImages();
  ....


-- 
Federico


From emesika at redhat.com  Tue May 14 00:45:41 2013
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 13 May 2013 20:45:41 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for
 ovirt-engine
In-Reply-To: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
Message-ID: <188337855.1067044.1368492341205.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>, "Limor Gavish" <lgavish at gmail.com>
> Sent: Sunday, May 12, 2013 2:52:51 PM
> Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> Hello all ovirt-engine developers,
> 
> When I first joined the ovirt project, it took me about two weeks to setup a
> development environment, I needed to work on a bug related to host-deploy so
> I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> communicate with vdsm using SSL, this was virtually impossible to do so
> without tweaking the product in a way that it is so different from
> production use, that I cannot guarantee that whatever tested in development
> will actually work in production.
> 
> I peeked at the installation script in a hope that I can create partial
> environment similar to production, but I found that the packaging
> implementation makes to much assumption and is very difficult to adopt. The
> fact that I do not use fedora/rhel for my development made it even worse.
> 
> I had no other option than to create rpms after each of my changes and test
> each in real production like setup.
> 
> It was obvious to me that the manual customization of developers to achieve
> working product will eventually break as product grow and move away from
> being developer friendly to production friendly. For example, product
> defaults cannot be these which serve developers, but these which serve
> production the best, or having a valid PKI setup cannot be optional any more
> as components do need to use it. Same for location of files and
> configuration, for example, if we write a pluggable infrastructure for
> branding, we cannot damage the interface just because developers runs the
> product in their own manual customization.
> 
> I took the opportunity handed to me to port the ovirt-engine to other
> distributions in order to provide a development environment that is similar
> to production setup. Together with Sandro Bonazzola and Alex Lourie we
> re-wrote the whole installation of the product which can also be used to
> setup the desired development environment.
> 
> Within this environment the product is set up using the same tools and
> configuration as in production, while the process does not require special
> privileges nor changes the state of the developer machine.
> 
> A complete documentation is available[1], I preferred to use README within
> the source tree as wiki tend to quickly become obsolete, while documentation
> within source tree can be modified by the commit that introduces a change. I
> will redirect to this file from the current wiki once the site will be up.
> 
> In a nut shell, after installing prerequisites, build and install the product
> using:
> 
> $ make clean install-dev PREFIX=$HOME/ovirt-engine
> 
> This will run maven and create product installation at $HOME/ovirt-engine
> Next, a setup phase is required just like in production, to initialize
> configuration and database:
> 
> $ $HOME/ovirt-engine/bin/engine-setup-2
> 
> You have now fully functional product, including PKI, SSL, host-deploy,
> tools.
> No manual database updates are required, no lose of functionality.
> 
> All that is left is to start the engine service:
> 
> $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> 
> Access to application:
>    http://localhost:8080
>    https://localhost:8443
> Debugging port is opened at port 8787.
> 
> Farther information exists in the documentation[1].
> 
> There are several inherit benefits of the new environment, the major one is
> the ability to manage several environments in parallel on the same host. For
> example, if we develop two separate features on two branches we can install
> the product into $HOME/ovirt-engine-feature1 and
> $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> modify the ports jboss is listening to we can run two instances of engine at
> the same time!

It is not clear to me why working on 2 bugs needs 2 installations of the development environment.
If you have 2 different git branches and a separate database for each, its enough , am I missing something ?
I was used to create a git branch with the name of the BZ# and use create_db.sh script to create a new database with the BZ# name.
Is this possible in the new method?
Also, does this mean that I will have to create/configure a new workspace for eclipse each time I am starting to work on a new bug?


Thanks


> 
> We will be happy to work with all developers to assist in porting into the
> new development environment, the simplest is to create a new database for
> this effort. Moti has a sequence of converting the existing database owned
> by postgres to be owned by the engine, Moti, can you please share that?
> 
> We are sure there are missing bits, we will be happy to know these so we can
> improve.
> 
> I am aware that developers (especially java) are conservative, but I ask you
> to give us a chance, so that we make it easy for developers to join the
> project, and to allow us to drop the parallel effort of packaging to
> production and fixing the broken development environment.
> 
> A special thanks to developers who took the time to test and provide feedback
> before the merged:
> - Yaniv Bronheim
> - Moti Asayag
> - Limor Gavish
> - Sharad Mishra
> - Ofer Schreiber
> 
> We are hoping that after migration you will be find this environment useful
> and friendly,
> 
> Sandro Bonazzola,
> Alex Lourie,
> Alon Bar-Lev.
> 
> [1]
> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Tue May 14 01:21:11 2013
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 13 May 2013 21:21:11 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <CAJ3aYLdniVuwCrPqE10yvoWo8WZj7k2KD3OUq1wEY_-urOfmGw@mail.gmail.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<176765088.119212.1368352381011.JavaMail.root@redhat.com>
	<CAJ3aYLdniVuwCrPqE10yvoWo8WZj7k2KD3OUq1wEY_-urOfmGw@mail.gmail.com>
Message-ID: <1368639807.1072346.1368494471922.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Liran Zelkha" <liran.zelkha at gmail.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, May 12, 2013 1:19:07 PM
> Subject: Re: [Engine-devel] What type of DB inheritance to use?
> 
> Hi
> 
> From my experience, single table inheritance quickly grows into something
> unmanagable, as more and more (child related) fields are added, each line
> has a few relevant attributes, and a long list of NULL values.
> I would go with option 3. With materialized views, the costs of joins can be
> eliminated.

+1

> 
> 
> On Sun, May 12, 2013 at 12:53 PM, Yair Zaslavsky < yzaslavs at redhat.com >
> wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> From: "Mike Kolesnik" < mkolesni at redhat.com >
> To: "engine-devel" < engine-devel at ovirt.org >
> Sent: Sunday, May 12, 2013 12:42:14 PM
> Subject: [Engine-devel] What type of DB inheritance to use?
> 
> Hi All,
> 
> I would like to have your opinions on which inheritance type to use in the
> DB.
> We are adding an "external provider" entity to the system which will be able
> to provide various resources (networks, hosts, etc).
> 
> These providers will be distinguishable by "type".
> The basic definition of a provider contains:
> 
> 
>     * name
>     * description
>     * url
>     * type
> Some providers might need additional properties such as:
> 
> 
>     * user
>     * password
> 
> In Java this is easily represented by inheritance.
> 
> In the DB however, there are 3 approaches that we can take:
> 
> 
>     1. No inheritance. This means that each type will wit in his own table,
>     with no relation or re-use.
>     2. Single table inheritance. All types sit in a single table, and each
>     has his corresponding columns.
> You forgot to mention discriminator column at option 2 (how are you going to
> differ between sub types) which should be indexed.
> 
> 
> 
> 
> 
>     1.
>     2. Multiple table inheritance. Each type sists in his own table, where
>     the PK is FK for the most basic table (providers).
> 
> Pros for each approach:
> 
> 
>     1. None that I can think of.
>     2. No joins: Better performance Easier for developer to see the DB info
>     Facilitate column reuse
>     3. Constraints can be set on each column
> Cons for each approach:
> 
> 
>     1. No reuse of DB entities + no compliance for column types Most
>     cumbersome to query all providers
>     2. Can't put some constraints on non-base columns (esp. not null)
>     3. Joins are needed - opposite of the pros of 2
> 
> 
> 
> 
> 
>     1.
> 
> From personal experience, I find #2 to be better and easier to work with &
> maintain.
> I think it really depends on the use-case, but I also had better experience
> with 2.
> 
> 
> 
> 
> 
> What are your thoughts?
> 
> Regards,
> Mike
> 
> 
> _______________________________________________
> 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 work.iec23801 at gmail.com  Tue May 14 02:27:11 2013
From: work.iec23801 at gmail.com (Jarod. w)
Date: Tue, 14 May 2013 10:27:11 +0800
Subject: [Engine-devel] ovirt-engine-sdk with C
In-Reply-To: <000101ce4fc3$0f359570$2da0c050$@com>
References: <000101ce4fc3$0f359570$2da0c050$@com>
Message-ID: <CAGEoUW8a4XP=VA_NHXd1wD6sqA5dBdPPauMPrQE0RiKQ4Za8Aw@mail.gmail.com>

2013/5/13 leaboy at 126 <wlbleaboy at 126.com>

>  Hi?All****
>
>          I felt oivrt-engine-sdk coded with Python is slowly to connect***
> *
>
> ovirt-engine and console vm when a user have many vms, So, I just****
>
> want to rewrite the sdk with C(ANSI C Language). Just rewrite a sdk****
>
> with C to connect overt-engine and console vm, would anyone give ****
>
> me some suggestion.
>
Do you want to use c to invoke ovirt engine RestAPI, right?
If yes, you can use libcurl to do the thing, and it'll make you happy.



> ****
>
> ** **
>
>          Now, the problem is how can I connect to ovit-engine with C, and*
> ***
>
> how can I get some information of vms, and how ovirrt-engine can ****
>
> respond my action(start,stop, .eg)
>
Agree with Michael Pasternak.
You should parse your code into the mail list, or someone can't help
you.


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


-- 
---
Best Regards
Jarod.W
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130514/1aed1a4f/attachment.html>

From yzaslavs at redhat.com  Tue May 14 02:39:19 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 13 May 2013 22:39:19 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for
 ovirt-engine
In-Reply-To: <188337855.1067044.1368492341205.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<188337855.1067044.1368492341205.JavaMail.root@redhat.com>
Message-ID: <975472192.855606.1368499159787.JavaMail.root@redhat.com>

Alon,
I have FC17, and followed the steps at the wiki , i defined the ovirt nightly repo 

[ovirt-nightly]
name=ovirt-nightly
baseurl=http://resources.ovirt.org/releases/nightly/rpm/Fedora/17/
enabled=1
gpgcheck=0
priority=1
protect=1

And performed yum install according to your guidelines.
It fails to find python-m2crypto

Can you please advise on the matter?

Many thanks,
Yair



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 3:45:41 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>, "Limor
> > Gavish" <lgavish at gmail.com>
> > Sent: Sunday, May 12, 2013 2:52:51 PM
> > Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
> > 
> > Hello all ovirt-engine developers,
> > 
> > When I first joined the ovirt project, it took me about two weeks to setup
> > a
> > development environment, I needed to work on a bug related to host-deploy
> > so
> > I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> > communicate with vdsm using SSL, this was virtually impossible to do so
> > without tweaking the product in a way that it is so different from
> > production use, that I cannot guarantee that whatever tested in development
> > will actually work in production.
> > 
> > I peeked at the installation script in a hope that I can create partial
> > environment similar to production, but I found that the packaging
> > implementation makes to much assumption and is very difficult to adopt. The
> > fact that I do not use fedora/rhel for my development made it even worse.
> > 
> > I had no other option than to create rpms after each of my changes and test
> > each in real production like setup.
> > 
> > It was obvious to me that the manual customization of developers to achieve
> > working product will eventually break as product grow and move away from
> > being developer friendly to production friendly. For example, product
> > defaults cannot be these which serve developers, but these which serve
> > production the best, or having a valid PKI setup cannot be optional any
> > more
> > as components do need to use it. Same for location of files and
> > configuration, for example, if we write a pluggable infrastructure for
> > branding, we cannot damage the interface just because developers runs the
> > product in their own manual customization.
> > 
> > I took the opportunity handed to me to port the ovirt-engine to other
> > distributions in order to provide a development environment that is similar
> > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > re-wrote the whole installation of the product which can also be used to
> > setup the desired development environment.
> > 
> > Within this environment the product is set up using the same tools and
> > configuration as in production, while the process does not require special
> > privileges nor changes the state of the developer machine.
> > 
> > A complete documentation is available[1], I preferred to use README within
> > the source tree as wiki tend to quickly become obsolete, while
> > documentation
> > within source tree can be modified by the commit that introduces a change.
> > I
> > will redirect to this file from the current wiki once the site will be up.
> > 
> > In a nut shell, after installing prerequisites, build and install the
> > product
> > using:
> > 
> > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > 
> > This will run maven and create product installation at $HOME/ovirt-engine
> > Next, a setup phase is required just like in production, to initialize
> > configuration and database:
> > 
> > $ $HOME/ovirt-engine/bin/engine-setup-2
> > 
> > You have now fully functional product, including PKI, SSL, host-deploy,
> > tools.
> > No manual database updates are required, no lose of functionality.
> > 
> > All that is left is to start the engine service:
> > 
> > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > 
> > Access to application:
> >    http://localhost:8080
> >    https://localhost:8443
> > Debugging port is opened at port 8787.
> > 
> > Farther information exists in the documentation[1].
> > 
> > There are several inherit benefits of the new environment, the major one is
> > the ability to manage several environments in parallel on the same host.
> > For
> > example, if we develop two separate features on two branches we can install
> > the product into $HOME/ovirt-engine-feature1 and
> > $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> > modify the ports jboss is listening to we can run two instances of engine
> > at
> > the same time!
> 
> It is not clear to me why working on 2 bugs needs 2 installations of the
> development environment.
> If you have 2 different git branches and a separate database for each, its
> enough , am I missing something ?
> I was used to create a git branch with the name of the BZ# and use
> create_db.sh script to create a new database with the BZ# name.
> Is this possible in the new method?
> Also, does this mean that I will have to create/configure a new workspace for
> eclipse each time I am starting to work on a new bug?
> 
> 
> Thanks
> 
> 
> > 
> > We will be happy to work with all developers to assist in porting into the
> > new development environment, the simplest is to create a new database for
> > this effort. Moti has a sequence of converting the existing database owned
> > by postgres to be owned by the engine, Moti, can you please share that?
> > 
> > We are sure there are missing bits, we will be happy to know these so we
> > can
> > improve.
> > 
> > I am aware that developers (especially java) are conservative, but I ask
> > you
> > to give us a chance, so that we make it easy for developers to join the
> > project, and to allow us to drop the parallel effort of packaging to
> > production and fixing the broken development environment.
> > 
> > A special thanks to developers who took the time to test and provide
> > feedback
> > before the merged:
> > - Yaniv Bronheim
> > - Moti Asayag
> > - Limor Gavish
> > - Sharad Mishra
> > - Ofer Schreiber
> > 
> > We are hoping that after migration you will be find this environment useful
> > and friendly,
> > 
> > Sandro Bonazzola,
> > Alex Lourie,
> > Alon Bar-Lev.
> > 
> > [1]
> > http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> > _______________________________________________
> > 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 alonbl at redhat.com  Tue May 14 05:58:06 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 14 May 2013 01:58:06 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for
 ovirt-engine
In-Reply-To: <975472192.855606.1368499159787.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<188337855.1067044.1368492341205.JavaMail.root@redhat.com>
	<975472192.855606.1368499159787.JavaMail.root@redhat.com>
Message-ID: <998811568.829527.1368511086124.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 5:39:19 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> Alon,
> I have FC17, and followed the steps at the wiki , i defined the ovirt nightly
> repo
> 
> [ovirt-nightly]
> name=ovirt-nightly
> baseurl=http://resources.ovirt.org/releases/nightly/rpm/Fedora/17/
> enabled=1
> gpgcheck=0
> priority=1
> protect=1
> 
> And performed yum install according to your guidelines.
> It fails to find python-m2crypto

Has nothing to do with ovirt :)
Try m2crypto please.

> 
> Can you please advise on the matter?
> 
> Many thanks,
> Yair
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > Sent: Tuesday, May 14, 2013 3:45:41 AM
> > Subject: Re: [Engine-devel] [ANN] New development environment for
> > ovirt-engine
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>,
> > > "Limor
> > > Gavish" <lgavish at gmail.com>
> > > Sent: Sunday, May 12, 2013 2:52:51 PM
> > > Subject: [Engine-devel] [ANN] New development environment for
> > > ovirt-engine
> > > 
> > > Hello all ovirt-engine developers,
> > > 
> > > When I first joined the ovirt project, it took me about two weeks to
> > > setup
> > > a
> > > development environment, I needed to work on a bug related to host-deploy
> > > so
> > > I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> > > communicate with vdsm using SSL, this was virtually impossible to do so
> > > without tweaking the product in a way that it is so different from
> > > production use, that I cannot guarantee that whatever tested in
> > > development
> > > will actually work in production.
> > > 
> > > I peeked at the installation script in a hope that I can create partial
> > > environment similar to production, but I found that the packaging
> > > implementation makes to much assumption and is very difficult to adopt.
> > > The
> > > fact that I do not use fedora/rhel for my development made it even worse.
> > > 
> > > I had no other option than to create rpms after each of my changes and
> > > test
> > > each in real production like setup.
> > > 
> > > It was obvious to me that the manual customization of developers to
> > > achieve
> > > working product will eventually break as product grow and move away from
> > > being developer friendly to production friendly. For example, product
> > > defaults cannot be these which serve developers, but these which serve
> > > production the best, or having a valid PKI setup cannot be optional any
> > > more
> > > as components do need to use it. Same for location of files and
> > > configuration, for example, if we write a pluggable infrastructure for
> > > branding, we cannot damage the interface just because developers runs the
> > > product in their own manual customization.
> > > 
> > > I took the opportunity handed to me to port the ovirt-engine to other
> > > distributions in order to provide a development environment that is
> > > similar
> > > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > > re-wrote the whole installation of the product which can also be used to
> > > setup the desired development environment.
> > > 
> > > Within this environment the product is set up using the same tools and
> > > configuration as in production, while the process does not require
> > > special
> > > privileges nor changes the state of the developer machine.
> > > 
> > > A complete documentation is available[1], I preferred to use README
> > > within
> > > the source tree as wiki tend to quickly become obsolete, while
> > > documentation
> > > within source tree can be modified by the commit that introduces a
> > > change.
> > > I
> > > will redirect to this file from the current wiki once the site will be
> > > up.
> > > 
> > > In a nut shell, after installing prerequisites, build and install the
> > > product
> > > using:
> > > 
> > > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > > 
> > > This will run maven and create product installation at $HOME/ovirt-engine
> > > Next, a setup phase is required just like in production, to initialize
> > > configuration and database:
> > > 
> > > $ $HOME/ovirt-engine/bin/engine-setup-2
> > > 
> > > You have now fully functional product, including PKI, SSL, host-deploy,
> > > tools.
> > > No manual database updates are required, no lose of functionality.
> > > 
> > > All that is left is to start the engine service:
> > > 
> > > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > > 
> > > Access to application:
> > >    http://localhost:8080
> > >    https://localhost:8443
> > > Debugging port is opened at port 8787.
> > > 
> > > Farther information exists in the documentation[1].
> > > 
> > > There are several inherit benefits of the new environment, the major one
> > > is
> > > the ability to manage several environments in parallel on the same host.
> > > For
> > > example, if we develop two separate features on two branches we can
> > > install
> > > the product into $HOME/ovirt-engine-feature1 and
> > > $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> > > modify the ports jboss is listening to we can run two instances of engine
> > > at
> > > the same time!
> > 
> > It is not clear to me why working on 2 bugs needs 2 installations of the
> > development environment.
> > If you have 2 different git branches and a separate database for each, its
> > enough , am I missing something ?
> > I was used to create a git branch with the name of the BZ# and use
> > create_db.sh script to create a new database with the BZ# name.
> > Is this possible in the new method?
> > Also, does this mean that I will have to create/configure a new workspace
> > for
> > eclipse each time I am starting to work on a new bug?
> > 
> > 
> > Thanks
> > 
> > 
> > > 
> > > We will be happy to work with all developers to assist in porting into
> > > the
> > > new development environment, the simplest is to create a new database for
> > > this effort. Moti has a sequence of converting the existing database
> > > owned
> > > by postgres to be owned by the engine, Moti, can you please share that?
> > > 
> > > We are sure there are missing bits, we will be happy to know these so we
> > > can
> > > improve.
> > > 
> > > I am aware that developers (especially java) are conservative, but I ask
> > > you
> > > to give us a chance, so that we make it easy for developers to join the
> > > project, and to allow us to drop the parallel effort of packaging to
> > > production and fixing the broken development environment.
> > > 
> > > A special thanks to developers who took the time to test and provide
> > > feedback
> > > before the merged:
> > > - Yaniv Bronheim
> > > - Moti Asayag
> > > - Limor Gavish
> > > - Sharad Mishra
> > > - Ofer Schreiber
> > > 
> > > We are hoping that after migration you will be find this environment
> > > useful
> > > and friendly,
> > > 
> > > Sandro Bonazzola,
> > > Alex Lourie,
> > > Alon Bar-Lev.
> > > 
> > > [1]
> > > http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> > > _______________________________________________
> > > 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 alonbl at redhat.com  Tue May 14 06:18:44 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 14 May 2013 02:18:44 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for
 ovirt-engine
In-Reply-To: <188337855.1067044.1368492341205.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<188337855.1067044.1368492341205.JavaMail.root@redhat.com>
Message-ID: <1732269511.831688.1368512324398.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 3:45:41 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>, "Limor
> > Gavish" <lgavish at gmail.com>
> > Sent: Sunday, May 12, 2013 2:52:51 PM
> > Subject: [Engine-devel] [ANN] New development environment for ovirt-engine
> > 
> > Hello all ovirt-engine developers,
> > 
> > When I first joined the ovirt project, it took me about two weeks to setup
> > a
> > development environment, I needed to work on a bug related to host-deploy
> > so
> > I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> > communicate with vdsm using SSL, this was virtually impossible to do so
> > without tweaking the product in a way that it is so different from
> > production use, that I cannot guarantee that whatever tested in development
> > will actually work in production.
> > 
> > I peeked at the installation script in a hope that I can create partial
> > environment similar to production, but I found that the packaging
> > implementation makes to much assumption and is very difficult to adopt. The
> > fact that I do not use fedora/rhel for my development made it even worse.
> > 
> > I had no other option than to create rpms after each of my changes and test
> > each in real production like setup.
> > 
> > It was obvious to me that the manual customization of developers to achieve
> > working product will eventually break as product grow and move away from
> > being developer friendly to production friendly. For example, product
> > defaults cannot be these which serve developers, but these which serve
> > production the best, or having a valid PKI setup cannot be optional any
> > more
> > as components do need to use it. Same for location of files and
> > configuration, for example, if we write a pluggable infrastructure for
> > branding, we cannot damage the interface just because developers runs the
> > product in their own manual customization.
> > 
> > I took the opportunity handed to me to port the ovirt-engine to other
> > distributions in order to provide a development environment that is similar
> > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > re-wrote the whole installation of the product which can also be used to
> > setup the desired development environment.
> > 
> > Within this environment the product is set up using the same tools and
> > configuration as in production, while the process does not require special
> > privileges nor changes the state of the developer machine.
> > 
> > A complete documentation is available[1], I preferred to use README within
> > the source tree as wiki tend to quickly become obsolete, while
> > documentation
> > within source tree can be modified by the commit that introduces a change.
> > I
> > will redirect to this file from the current wiki once the site will be up.
> > 
> > In a nut shell, after installing prerequisites, build and install the
> > product
> > using:
> > 
> > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > 
> > This will run maven and create product installation at $HOME/ovirt-engine
> > Next, a setup phase is required just like in production, to initialize
> > configuration and database:
> > 
> > $ $HOME/ovirt-engine/bin/engine-setup-2
> > 
> > You have now fully functional product, including PKI, SSL, host-deploy,
> > tools.
> > No manual database updates are required, no lose of functionality.
> > 
> > All that is left is to start the engine service:
> > 
> > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > 
> > Access to application:
> >    http://localhost:8080
> >    https://localhost:8443
> > Debugging port is opened at port 8787.
> > 
> > Farther information exists in the documentation[1].
> > 
> > There are several inherit benefits of the new environment, the major one is
> > the ability to manage several environments in parallel on the same host.
> > For
> > example, if we develop two separate features on two branches we can install
> > the product into $HOME/ovirt-engine-feature1 and
> > $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> > modify the ports jboss is listening to we can run two instances of engine
> > at
> > the same time!
> 
> It is not clear to me why working on 2 bugs needs 2 installations of the
> development environment.
> If you have 2 different git branches and a separate database for each, its
> enough , am I missing something ?

You have two different git branches, so you have two different binaries out of the build, right?
These binaries should reside some where.
Currently you are probably use maven deploy or something similar into single jboss, without proper environment, overriding each time the other branch's binaries.
What if there is a change in configuration between the two? more prerequisites, different service configuration? different database schema?

To make it easy, you can just duplicate the development environment, and be sure you are up and running.

If you still want to take the chance you can... just make install-dev PREFIX=$HOME/same-place and you will have the behavior of overriding the same environment, and hoping for the best.

> I was used to create a git branch with the name of the BZ# and use
> create_db.sh script to create a new database with the BZ# name.
> Is this possible in the new method?

Yes.
You create an empty database manually, let's say engine-branch1.
Then you install the environment to own location, let say make install-dev PREFIX=$HOME/ovirt-engine-branch1
When running engine-setup-2 you instruct the setup to use engine-branch1 database.
This database will be created out of the new branch's create_db.sh.
create_db.sh should not run manually now.

However, if you insist of creating a database manually and modify an existing environment to use the new database, it is possible as well.
Edit $PREFIX/etc/ovirt-engine/engine.conf.d/10-setup-database.conf, and specify where database is, then start the engine service.

> Also, does this mean that I will have to create/configure a new workspace for
> eclipse each time I am starting to work on a new bug?

This I do not know. How does it work now when you switch branches?

> 
> 
> Thanks
> 
> 
> > 
> > We will be happy to work with all developers to assist in porting into the
> > new development environment, the simplest is to create a new database for
> > this effort. Moti has a sequence of converting the existing database owned
> > by postgres to be owned by the engine, Moti, can you please share that?
> > 
> > We are sure there are missing bits, we will be happy to know these so we
> > can
> > improve.
> > 
> > I am aware that developers (especially java) are conservative, but I ask
> > you
> > to give us a chance, so that we make it easy for developers to join the
> > project, and to allow us to drop the parallel effort of packaging to
> > production and fixing the broken development environment.
> > 
> > A special thanks to developers who took the time to test and provide
> > feedback
> > before the merged:
> > - Yaniv Bronheim
> > - Moti Asayag
> > - Limor Gavish
> > - Sharad Mishra
> > - Ofer Schreiber
> > 
> > We are hoping that after migration you will be find this environment useful
> > and friendly,
> > 
> > Sandro Bonazzola,
> > Alex Lourie,
> > Alon Bar-Lev.
> > 
> > [1]
> > http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From yzaslavs at redhat.com  Tue May 14 06:55:52 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 14 May 2013 02:55:52 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for
 ovirt-engine
In-Reply-To: <998811568.829527.1368511086124.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<188337855.1067044.1368492341205.JavaMail.root@redhat.com>
	<975472192.855606.1368499159787.JavaMail.root@redhat.com>
	<998811568.829527.1368511086124.JavaMail.root@redhat.com>
Message-ID: <1540245909.911838.1368514552129.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 8:58:06 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > Sent: Tuesday, May 14, 2013 5:39:19 AM
> > Subject: Re: [Engine-devel] [ANN] New development environment for
> > ovirt-engine
> > 
> > Alon,
> > I have FC17, and followed the steps at the wiki , i defined the ovirt
> > nightly
> > repo
> > 
> > [ovirt-nightly]
> > name=ovirt-nightly
> > baseurl=http://resources.ovirt.org/releases/nightly/rpm/Fedora/17/
> > enabled=1
> > gpgcheck=0
> > priority=1
> > protect=1
> > 
> > And performed yum install according to your guidelines.
> > It fails to find python-m2crypto
> 
> Has nothing to do with ovirt :)
> Try m2crypto please.


Worked ! I would suggest updating the WIKI
However, now I fail at webadmin - commit hash cda607c80a19dd08585fc0271ea7d57e03f9a43f

[INFO] javac option: -s
[INFO] javac option: /home/yzaslavs/work/ovirt_git/ovirt-engine/frontend/webadmin/modules/webadmin/target/generated-sources/annotations
[INFO] diagnostic /home/yzaslavs/work/ovirt_git/ovirt-engine/frontend/webadmin/modules/gwt-common/target/gwt-common-3.3.0-SNAPSHOT.jar(org/ovirt/engine/ui/common/presenter/AbstractPopupPresenterWidget.java):27: error: method getCloseButton() is already defined in interface org.ovirt.engine.ui.common.presenter.AbstractPopupPresenterWidget.ViewDef
        HasClickHandlers getCloseButton();
                         ^
[INFO] diagnostic /home/yzaslavs/work/ovirt_git/ovirt-engine/frontend/webadmin/modules/gwt-common/target/gwt-common-3.3.0-SNAPSHOT.jar(org/ovirt/engine/ui/common/presenter/AbstractPopupPresenterWidget.java):32: error: method getCloseIconButton() is already defined in interface org.ovirt.engine.ui.common.presenter.AbstractPopupPresenterWidget.ViewDef
        HasClickHandlers getCloseIconButton();

Anyone got a clue?
                         




> 
> > 
> > Can you please advise on the matter?
> > 
> > Many thanks,
> > Yair
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > > Sent: Tuesday, May 14, 2013 3:45:41 AM
> > > Subject: Re: [Engine-devel] [ANN] New development environment for
> > > ovirt-engine
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>,
> > > > "Limor
> > > > Gavish" <lgavish at gmail.com>
> > > > Sent: Sunday, May 12, 2013 2:52:51 PM
> > > > Subject: [Engine-devel] [ANN] New development environment for
> > > > ovirt-engine
> > > > 
> > > > Hello all ovirt-engine developers,
> > > > 
> > > > When I first joined the ovirt project, it took me about two weeks to
> > > > setup
> > > > a
> > > > development environment, I needed to work on a bug related to
> > > > host-deploy
> > > > so
> > > > I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> > > > communicate with vdsm using SSL, this was virtually impossible to do so
> > > > without tweaking the product in a way that it is so different from
> > > > production use, that I cannot guarantee that whatever tested in
> > > > development
> > > > will actually work in production.
> > > > 
> > > > I peeked at the installation script in a hope that I can create partial
> > > > environment similar to production, but I found that the packaging
> > > > implementation makes to much assumption and is very difficult to adopt.
> > > > The
> > > > fact that I do not use fedora/rhel for my development made it even
> > > > worse.
> > > > 
> > > > I had no other option than to create rpms after each of my changes and
> > > > test
> > > > each in real production like setup.
> > > > 
> > > > It was obvious to me that the manual customization of developers to
> > > > achieve
> > > > working product will eventually break as product grow and move away
> > > > from
> > > > being developer friendly to production friendly. For example, product
> > > > defaults cannot be these which serve developers, but these which serve
> > > > production the best, or having a valid PKI setup cannot be optional any
> > > > more
> > > > as components do need to use it. Same for location of files and
> > > > configuration, for example, if we write a pluggable infrastructure for
> > > > branding, we cannot damage the interface just because developers runs
> > > > the
> > > > product in their own manual customization.
> > > > 
> > > > I took the opportunity handed to me to port the ovirt-engine to other
> > > > distributions in order to provide a development environment that is
> > > > similar
> > > > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > > > re-wrote the whole installation of the product which can also be used
> > > > to
> > > > setup the desired development environment.
> > > > 
> > > > Within this environment the product is set up using the same tools and
> > > > configuration as in production, while the process does not require
> > > > special
> > > > privileges nor changes the state of the developer machine.
> > > > 
> > > > A complete documentation is available[1], I preferred to use README
> > > > within
> > > > the source tree as wiki tend to quickly become obsolete, while
> > > > documentation
> > > > within source tree can be modified by the commit that introduces a
> > > > change.
> > > > I
> > > > will redirect to this file from the current wiki once the site will be
> > > > up.
> > > > 
> > > > In a nut shell, after installing prerequisites, build and install the
> > > > product
> > > > using:
> > > > 
> > > > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > > > 
> > > > This will run maven and create product installation at
> > > > $HOME/ovirt-engine
> > > > Next, a setup phase is required just like in production, to initialize
> > > > configuration and database:
> > > > 
> > > > $ $HOME/ovirt-engine/bin/engine-setup-2
> > > > 
> > > > You have now fully functional product, including PKI, SSL, host-deploy,
> > > > tools.
> > > > No manual database updates are required, no lose of functionality.
> > > > 
> > > > All that is left is to start the engine service:
> > > > 
> > > > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > > > 
> > > > Access to application:
> > > >    http://localhost:8080
> > > >    https://localhost:8443
> > > > Debugging port is opened at port 8787.
> > > > 
> > > > Farther information exists in the documentation[1].
> > > > 
> > > > There are several inherit benefits of the new environment, the major
> > > > one
> > > > is
> > > > the ability to manage several environments in parallel on the same
> > > > host.
> > > > For
> > > > example, if we develop two separate features on two branches we can
> > > > install
> > > > the product into $HOME/ovirt-engine-feature1 and
> > > > $HOME/ovirt-engine-feature-2 and have a separate database for each, if
> > > > we
> > > > modify the ports jboss is listening to we can run two instances of
> > > > engine
> > > > at
> > > > the same time!
> > > 
> > > It is not clear to me why working on 2 bugs needs 2 installations of the
> > > development environment.
> > > If you have 2 different git branches and a separate database for each,
> > > its
> > > enough , am I missing something ?
> > > I was used to create a git branch with the name of the BZ# and use
> > > create_db.sh script to create a new database with the BZ# name.
> > > Is this possible in the new method?
> > > Also, does this mean that I will have to create/configure a new workspace
> > > for
> > > eclipse each time I am starting to work on a new bug?
> > > 
> > > 
> > > Thanks
> > > 
> > > 
> > > > 
> > > > We will be happy to work with all developers to assist in porting into
> > > > the
> > > > new development environment, the simplest is to create a new database
> > > > for
> > > > this effort. Moti has a sequence of converting the existing database
> > > > owned
> > > > by postgres to be owned by the engine, Moti, can you please share that?
> > > > 
> > > > We are sure there are missing bits, we will be happy to know these so
> > > > we
> > > > can
> > > > improve.
> > > > 
> > > > I am aware that developers (especially java) are conservative, but I
> > > > ask
> > > > you
> > > > to give us a chance, so that we make it easy for developers to join the
> > > > project, and to allow us to drop the parallel effort of packaging to
> > > > production and fixing the broken development environment.
> > > > 
> > > > A special thanks to developers who took the time to test and provide
> > > > feedback
> > > > before the merged:
> > > > - Yaniv Bronheim
> > > > - Moti Asayag
> > > > - Limor Gavish
> > > > - Sharad Mishra
> > > > - Ofer Schreiber
> > > > 
> > > > We are hoping that after migration you will be find this environment
> > > > useful
> > > > and friendly,
> > > > 
> > > > Sandro Bonazzola,
> > > > Alex Lourie,
> > > > Alon Bar-Lev.
> > > > 
> > > > [1]
> > > > http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> > > > _______________________________________________
> > > > 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 alonbl at redhat.com  Tue May 14 06:58:46 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 14 May 2013 02:58:46 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for
 ovirt-engine
In-Reply-To: <1540245909.911838.1368514552129.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<188337855.1067044.1368492341205.JavaMail.root@redhat.com>
	<975472192.855606.1368499159787.JavaMail.root@redhat.com>
	<998811568.829527.1368511086124.JavaMail.root@redhat.com>
	<1540245909.911838.1368514552129.JavaMail.root@redhat.com>
Message-ID: <40963367.836876.1368514726698.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 9:55:52 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > Sent: Tuesday, May 14, 2013 8:58:06 AM
> > Subject: Re: [Engine-devel] [ANN] New development environment for
> > ovirt-engine
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > > Sent: Tuesday, May 14, 2013 5:39:19 AM
> > > Subject: Re: [Engine-devel] [ANN] New development environment for
> > > ovirt-engine
> > > 
> > > Alon,
> > > I have FC17, and followed the steps at the wiki , i defined the ovirt
> > > nightly
> > > repo
> > > 
> > > [ovirt-nightly]
> > > name=ovirt-nightly
> > > baseurl=http://resources.ovirt.org/releases/nightly/rpm/Fedora/17/
> > > enabled=1
> > > gpgcheck=0
> > > priority=1
> > > protect=1
> > > 
> > > And performed yum install according to your guidelines.
> > > It fails to find python-m2crypto
> > 
> > Has nothing to do with ovirt :)
> > Try m2crypto please.
> 
> 
> Worked ! I would suggest updating the WIKI
> However, now I fail at webadmin - commit hash
> cda607c80a19dd08585fc0271ea7d57e03f9a43f

Please open a new thread, this is unrelated.

> 
> [INFO] javac option: -s
> [INFO] javac option:
> /home/yzaslavs/work/ovirt_git/ovirt-engine/frontend/webadmin/modules/webadmin/target/generated-sources/annotations
> [INFO] diagnostic
> /home/yzaslavs/work/ovirt_git/ovirt-engine/frontend/webadmin/modules/gwt-common/target/gwt-common-3.3.0-SNAPSHOT.jar(org/ovirt/engine/ui/common/presenter/AbstractPopupPresenterWidget.java):27:
> error: method getCloseButton() is already defined in interface
> org.ovirt.engine.ui.common.presenter.AbstractPopupPresenterWidget.ViewDef
>         HasClickHandlers getCloseButton();
>                          ^
> [INFO] diagnostic
> /home/yzaslavs/work/ovirt_git/ovirt-engine/frontend/webadmin/modules/gwt-common/target/gwt-common-3.3.0-SNAPSHOT.jar(org/ovirt/engine/ui/common/presenter/AbstractPopupPresenterWidget.java):32:
> error: method getCloseIconButton() is already defined in interface
> org.ovirt.engine.ui.common.presenter.AbstractPopupPresenterWidget.ViewDef
>         HasClickHandlers getCloseIconButton();
> 
> Anyone got a clue?
>                          
> 
> 
> 
> 
> > 
> > > 
> > > Can you please advise on the matter?
> > > 
> > > Many thanks,
> > > Yair
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > > > Sent: Tuesday, May 14, 2013 3:45:41 AM
> > > > Subject: Re: [Engine-devel] [ANN] New development environment for
> > > > ovirt-engine
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>,
> > > > > "Limor
> > > > > Gavish" <lgavish at gmail.com>
> > > > > Sent: Sunday, May 12, 2013 2:52:51 PM
> > > > > Subject: [Engine-devel] [ANN] New development environment for
> > > > > ovirt-engine
> > > > > 
> > > > > Hello all ovirt-engine developers,
> > > > > 
> > > > > When I first joined the ovirt project, it took me about two weeks to
> > > > > setup
> > > > > a
> > > > > development environment, I needed to work on a bug related to
> > > > > host-deploy
> > > > > so
> > > > > I needed an environment that could use the ssh, PKI, vdsm-bootstrap
> > > > > and
> > > > > communicate with vdsm using SSL, this was virtually impossible to do
> > > > > so
> > > > > without tweaking the product in a way that it is so different from
> > > > > production use, that I cannot guarantee that whatever tested in
> > > > > development
> > > > > will actually work in production.
> > > > > 
> > > > > I peeked at the installation script in a hope that I can create
> > > > > partial
> > > > > environment similar to production, but I found that the packaging
> > > > > implementation makes to much assumption and is very difficult to
> > > > > adopt.
> > > > > The
> > > > > fact that I do not use fedora/rhel for my development made it even
> > > > > worse.
> > > > > 
> > > > > I had no other option than to create rpms after each of my changes
> > > > > and
> > > > > test
> > > > > each in real production like setup.
> > > > > 
> > > > > It was obvious to me that the manual customization of developers to
> > > > > achieve
> > > > > working product will eventually break as product grow and move away
> > > > > from
> > > > > being developer friendly to production friendly. For example, product
> > > > > defaults cannot be these which serve developers, but these which
> > > > > serve
> > > > > production the best, or having a valid PKI setup cannot be optional
> > > > > any
> > > > > more
> > > > > as components do need to use it. Same for location of files and
> > > > > configuration, for example, if we write a pluggable infrastructure
> > > > > for
> > > > > branding, we cannot damage the interface just because developers runs
> > > > > the
> > > > > product in their own manual customization.
> > > > > 
> > > > > I took the opportunity handed to me to port the ovirt-engine to other
> > > > > distributions in order to provide a development environment that is
> > > > > similar
> > > > > to production setup. Together with Sandro Bonazzola and Alex Lourie
> > > > > we
> > > > > re-wrote the whole installation of the product which can also be used
> > > > > to
> > > > > setup the desired development environment.
> > > > > 
> > > > > Within this environment the product is set up using the same tools
> > > > > and
> > > > > configuration as in production, while the process does not require
> > > > > special
> > > > > privileges nor changes the state of the developer machine.
> > > > > 
> > > > > A complete documentation is available[1], I preferred to use README
> > > > > within
> > > > > the source tree as wiki tend to quickly become obsolete, while
> > > > > documentation
> > > > > within source tree can be modified by the commit that introduces a
> > > > > change.
> > > > > I
> > > > > will redirect to this file from the current wiki once the site will
> > > > > be
> > > > > up.
> > > > > 
> > > > > In a nut shell, after installing prerequisites, build and install the
> > > > > product
> > > > > using:
> > > > > 
> > > > > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > > > > 
> > > > > This will run maven and create product installation at
> > > > > $HOME/ovirt-engine
> > > > > Next, a setup phase is required just like in production, to
> > > > > initialize
> > > > > configuration and database:
> > > > > 
> > > > > $ $HOME/ovirt-engine/bin/engine-setup-2
> > > > > 
> > > > > You have now fully functional product, including PKI, SSL,
> > > > > host-deploy,
> > > > > tools.
> > > > > No manual database updates are required, no lose of functionality.
> > > > > 
> > > > > All that is left is to start the engine service:
> > > > > 
> > > > > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py
> > > > > start
> > > > > 
> > > > > Access to application:
> > > > >    http://localhost:8080
> > > > >    https://localhost:8443
> > > > > Debugging port is opened at port 8787.
> > > > > 
> > > > > Farther information exists in the documentation[1].
> > > > > 
> > > > > There are several inherit benefits of the new environment, the major
> > > > > one
> > > > > is
> > > > > the ability to manage several environments in parallel on the same
> > > > > host.
> > > > > For
> > > > > example, if we develop two separate features on two branches we can
> > > > > install
> > > > > the product into $HOME/ovirt-engine-feature1 and
> > > > > $HOME/ovirt-engine-feature-2 and have a separate database for each,
> > > > > if
> > > > > we
> > > > > modify the ports jboss is listening to we can run two instances of
> > > > > engine
> > > > > at
> > > > > the same time!
> > > > 
> > > > It is not clear to me why working on 2 bugs needs 2 installations of
> > > > the
> > > > development environment.
> > > > If you have 2 different git branches and a separate database for each,
> > > > its
> > > > enough , am I missing something ?
> > > > I was used to create a git branch with the name of the BZ# and use
> > > > create_db.sh script to create a new database with the BZ# name.
> > > > Is this possible in the new method?
> > > > Also, does this mean that I will have to create/configure a new
> > > > workspace
> > > > for
> > > > eclipse each time I am starting to work on a new bug?
> > > > 
> > > > 
> > > > Thanks
> > > > 
> > > > 
> > > > > 
> > > > > We will be happy to work with all developers to assist in porting
> > > > > into
> > > > > the
> > > > > new development environment, the simplest is to create a new database
> > > > > for
> > > > > this effort. Moti has a sequence of converting the existing database
> > > > > owned
> > > > > by postgres to be owned by the engine, Moti, can you please share
> > > > > that?
> > > > > 
> > > > > We are sure there are missing bits, we will be happy to know these so
> > > > > we
> > > > > can
> > > > > improve.
> > > > > 
> > > > > I am aware that developers (especially java) are conservative, but I
> > > > > ask
> > > > > you
> > > > > to give us a chance, so that we make it easy for developers to join
> > > > > the
> > > > > project, and to allow us to drop the parallel effort of packaging to
> > > > > production and fixing the broken development environment.
> > > > > 
> > > > > A special thanks to developers who took the time to test and provide
> > > > > feedback
> > > > > before the merged:
> > > > > - Yaniv Bronheim
> > > > > - Moti Asayag
> > > > > - Limor Gavish
> > > > > - Sharad Mishra
> > > > > - Ofer Schreiber
> > > > > 
> > > > > We are hoping that after migration you will be find this environment
> > > > > useful
> > > > > and friendly,
> > > > > 
> > > > > Sandro Bonazzola,
> > > > > Alex Lourie,
> > > > > Alon Bar-Lev.
> > > > > 
> > > > > [1]
> > > > > http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> > > > > _______________________________________________
> > > > > 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 wlbleaboy at 126.com  Tue May 14 07:09:51 2013
From: wlbleaboy at 126.com (wlbleaboy@126)
Date: Tue, 14 May 2013 15:09:51 +0800
Subject: [Engine-devel] =?gb2312?b?tPC4tDogRW5naW5lLWRldmVsIERpZ2VzdCwg?=
	=?gb2312?b?Vm9sIDIwLCBJc3N1ZSAzOQ==?=
In-Reply-To: <mailman.3478.1368512325.2102.engine-devel@ovirt.org>
References: <mailman.3478.1368512325.2102.engine-devel@ovirt.org>
Message-ID: <000c01ce5072$08128b90$1837a2b0$@com>

Re: ovirt-engine-sdk with C (Jarod. w)
	Yes, you understanded my idea, I want to use c to invoke ovirt
engine RestAPI directly,
I'll try it(libcurl), but is there any exist example in ovirt-engine
project. I just want to connect
to ovirt-engine and get vms info, console vm and do some action(start,
stop.).
	
							thinks.

-----????-----
???: engine-devel-bounces at ovirt.org
[mailto:engine-devel-bounces at ovirt.org] ?? engine-devel-request at ovirt.org
????: 2013?5?14? 14:19
???: engine-devel at ovirt.org
??: Engine-devel Digest, Vol 20, Issue 39

Send Engine-devel mailing list submissions to
	engine-devel at ovirt.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.ovirt.org/mailman/listinfo/engine-devel
or, via email, send a message with subject or body 'help' to
	engine-devel-request at ovirt.org

You can reach the person managing the list at
	engine-devel-owner at ovirt.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Engine-devel digest..."


Today's Topics:

   1. Re: ovirt-engine-sdk with C (Jarod. w)
   2. Re: [ANN] New development environment for ovirt-engine
      (Yair Zaslavsky)
   3. Re: [ANN] New development environment for ovirt-engine
      (Alon Bar-Lev)
   4. Re: [ANN] New development environment for ovirt-engine
      (Alon Bar-Lev)


----------------------------------------------------------------------

Message: 1
Date: Tue, 14 May 2013 10:27:11 +0800
From: "Jarod. w" <work.iec23801 at gmail.com>
To: "leaboy at 126" <wlbleaboy at 126.com>
Cc: engine-devel at ovirt.org
Subject: Re: [Engine-devel] ovirt-engine-sdk with C
Message-ID:
	<CAGEoUW8a4XP=VA_NHXd1wD6sqA5dBdPPauMPrQE0RiKQ4Za8Aw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

2013/5/13 leaboy at 126 <wlbleaboy at 126.com>

>  Hi?All****
>
>          I felt oivrt-engine-sdk coded with Python is slowly to connect***
> *
>
> ovirt-engine and console vm when a user have many vms, So, I just****
>
> want to rewrite the sdk with C(ANSI C Language). Just rewrite a sdk****
>
> with C to connect overt-engine and console vm, would anyone give ****
>
> me some suggestion.
>
Do you want to use c to invoke ovirt engine RestAPI, right?
If yes, you can use libcurl to do the thing, and it'll make you happy.



> ****
>
> ** **
>
>          Now, the problem is how can I connect to ovit-engine with C, and*
> ***
>
> how can I get some information of vms, and how ovirrt-engine can ****
>
> respond my action(start,stop, .eg)
>
Agree with Michael Pasternak.
You should parse your code into the mail list, or someone can't help
you.


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


-- 
---
Best Regards
Jarod.W
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ovirt.org/pipermail/engine-devel/attachments/20130514/1aed1a4f
/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 13 May 2013 22:39:19 -0400 (EDT)
From: Yair Zaslavsky <yzaslavs at redhat.com>
To: Eli Mesika <emesika at redhat.com>
Cc: engine-devel <engine-devel at ovirt.org>, arch <arch at ovirt.org>
Subject: Re: [Engine-devel] [ANN] New development environment for
	ovirt-engine
Message-ID: <975472192.855606.1368499159787.JavaMail.root at redhat.com>
Content-Type: text/plain; charset=utf-8

Alon,
I have FC17, and followed the steps at the wiki , i defined the ovirt
nightly repo 

[ovirt-nightly]
name=ovirt-nightly
baseurl=http://resources.ovirt.org/releases/nightly/rpm/Fedora/17/
enabled=1
gpgcheck=0
priority=1
protect=1

And performed yum install according to your guidelines.
It fails to find python-m2crypto

Can you please advise on the matter?

Many thanks,
Yair



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 3:45:41 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for
ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>,
"Limor
> > Gavish" <lgavish at gmail.com>
> > Sent: Sunday, May 12, 2013 2:52:51 PM
> > Subject: [Engine-devel] [ANN] New development environment for
ovirt-engine
> > 
> > Hello all ovirt-engine developers,
> > 
> > When I first joined the ovirt project, it took me about two weeks to
setup
> > a
> > development environment, I needed to work on a bug related to
host-deploy
> > so
> > I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> > communicate with vdsm using SSL, this was virtually impossible to do so
> > without tweaking the product in a way that it is so different from
> > production use, that I cannot guarantee that whatever tested in
development
> > will actually work in production.
> > 
> > I peeked at the installation script in a hope that I can create partial
> > environment similar to production, but I found that the packaging
> > implementation makes to much assumption and is very difficult to adopt.
The
> > fact that I do not use fedora/rhel for my development made it even
worse.
> > 
> > I had no other option than to create rpms after each of my changes and
test
> > each in real production like setup.
> > 
> > It was obvious to me that the manual customization of developers to
achieve
> > working product will eventually break as product grow and move away from
> > being developer friendly to production friendly. For example, product
> > defaults cannot be these which serve developers, but these which serve
> > production the best, or having a valid PKI setup cannot be optional any
> > more
> > as components do need to use it. Same for location of files and
> > configuration, for example, if we write a pluggable infrastructure for
> > branding, we cannot damage the interface just because developers runs
the
> > product in their own manual customization.
> > 
> > I took the opportunity handed to me to port the ovirt-engine to other
> > distributions in order to provide a development environment that is
similar
> > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > re-wrote the whole installation of the product which can also be used to
> > setup the desired development environment.
> > 
> > Within this environment the product is set up using the same tools and
> > configuration as in production, while the process does not require
special
> > privileges nor changes the state of the developer machine.
> > 
> > A complete documentation is available[1], I preferred to use README
within
> > the source tree as wiki tend to quickly become obsolete, while
> > documentation
> > within source tree can be modified by the commit that introduces a
change.
> > I
> > will redirect to this file from the current wiki once the site will be
up.
> > 
> > In a nut shell, after installing prerequisites, build and install the
> > product
> > using:
> > 
> > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > 
> > This will run maven and create product installation at
$HOME/ovirt-engine
> > Next, a setup phase is required just like in production, to initialize
> > configuration and database:
> > 
> > $ $HOME/ovirt-engine/bin/engine-setup-2
> > 
> > You have now fully functional product, including PKI, SSL, host-deploy,
> > tools.
> > No manual database updates are required, no lose of functionality.
> > 
> > All that is left is to start the engine service:
> > 
> > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > 
> > Access to application:
> >    http://localhost:8080
> >    https://localhost:8443
> > Debugging port is opened at port 8787.
> > 
> > Farther information exists in the documentation[1].
> > 
> > There are several inherit benefits of the new environment, the major one
is
> > the ability to manage several environments in parallel on the same host.
> > For
> > example, if we develop two separate features on two branches we can
install
> > the product into $HOME/ovirt-engine-feature1 and
> > $HOME/ovirt-engine-feature-2 and have a separate database for each, if
we
> > modify the ports jboss is listening to we can run two instances of
engine
> > at
> > the same time!
> 
> It is not clear to me why working on 2 bugs needs 2 installations of the
> development environment.
> If you have 2 different git branches and a separate database for each, its
> enough , am I missing something ?
> I was used to create a git branch with the name of the BZ# and use
> create_db.sh script to create a new database with the BZ# name.
> Is this possible in the new method?
> Also, does this mean that I will have to create/configure a new workspace
for
> eclipse each time I am starting to work on a new bug?
> 
> 
> Thanks
> 
> 
> > 
> > We will be happy to work with all developers to assist in porting into
the
> > new development environment, the simplest is to create a new database
for
> > this effort. Moti has a sequence of converting the existing database
owned
> > by postgres to be owned by the engine, Moti, can you please share that?
> > 
> > We are sure there are missing bits, we will be happy to know these so we
> > can
> > improve.
> > 
> > I am aware that developers (especially java) are conservative, but I ask
> > you
> > to give us a chance, so that we make it easy for developers to join the
> > project, and to allow us to drop the parallel effort of packaging to
> > production and fixing the broken development environment.
> > 
> > A special thanks to developers who took the time to test and provide
> > feedback
> > before the merged:
> > - Yaniv Bronheim
> > - Moti Asayag
> > - Limor Gavish
> > - Sharad Mishra
> > - Ofer Schreiber
> > 
> > We are hoping that after migration you will be find this environment
useful
> > and friendly,
> > 
> > Sandro Bonazzola,
> > Alex Lourie,
> > Alon Bar-Lev.
> > 
> > [1]
> >
http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;
hb=HEAD
> > _______________________________________________
> > 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
> 


------------------------------

Message: 3
Date: Tue, 14 May 2013 01:58:06 -0400 (EDT)
From: Alon Bar-Lev <alonbl at redhat.com>
To: Yair Zaslavsky <yzaslavs at redhat.com>
Cc: engine-devel <engine-devel at ovirt.org>, arch <arch at ovirt.org>
Subject: Re: [Engine-devel] [ANN] New development environment for
	ovirt-engine
Message-ID: <998811568.829527.1368511086124.JavaMail.root at redhat.com>
Content-Type: text/plain; charset=utf-8



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "engine-devel"
<engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 5:39:19 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for
ovirt-engine
> 
> Alon,
> I have FC17, and followed the steps at the wiki , i defined the ovirt
nightly
> repo
> 
> [ovirt-nightly]
> name=ovirt-nightly
> baseurl=http://resources.ovirt.org/releases/nightly/rpm/Fedora/17/
> enabled=1
> gpgcheck=0
> priority=1
> protect=1
> 
> And performed yum install according to your guidelines.
> It fails to find python-m2crypto

Has nothing to do with ovirt :)
Try m2crypto please.

> 
> Can you please advise on the matter?
> 
> Many thanks,
> Yair
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > Sent: Tuesday, May 14, 2013 3:45:41 AM
> > Subject: Re: [Engine-devel] [ANN] New development environment for
> > ovirt-engine
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>,
> > > "Limor
> > > Gavish" <lgavish at gmail.com>
> > > Sent: Sunday, May 12, 2013 2:52:51 PM
> > > Subject: [Engine-devel] [ANN] New development environment for
> > > ovirt-engine
> > > 
> > > Hello all ovirt-engine developers,
> > > 
> > > When I first joined the ovirt project, it took me about two weeks to
> > > setup
> > > a
> > > development environment, I needed to work on a bug related to
host-deploy
> > > so
> > > I needed an environment that could use the ssh, PKI, vdsm-bootstrap
and
> > > communicate with vdsm using SSL, this was virtually impossible to do
so
> > > without tweaking the product in a way that it is so different from
> > > production use, that I cannot guarantee that whatever tested in
> > > development
> > > will actually work in production.
> > > 
> > > I peeked at the installation script in a hope that I can create
partial
> > > environment similar to production, but I found that the packaging
> > > implementation makes to much assumption and is very difficult to
adopt.
> > > The
> > > fact that I do not use fedora/rhel for my development made it even
worse.
> > > 
> > > I had no other option than to create rpms after each of my changes and
> > > test
> > > each in real production like setup.
> > > 
> > > It was obvious to me that the manual customization of developers to
> > > achieve
> > > working product will eventually break as product grow and move away
from
> > > being developer friendly to production friendly. For example, product
> > > defaults cannot be these which serve developers, but these which serve
> > > production the best, or having a valid PKI setup cannot be optional
any
> > > more
> > > as components do need to use it. Same for location of files and
> > > configuration, for example, if we write a pluggable infrastructure for
> > > branding, we cannot damage the interface just because developers runs
the
> > > product in their own manual customization.
> > > 
> > > I took the opportunity handed to me to port the ovirt-engine to other
> > > distributions in order to provide a development environment that is
> > > similar
> > > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > > re-wrote the whole installation of the product which can also be used
to
> > > setup the desired development environment.
> > > 
> > > Within this environment the product is set up using the same tools and
> > > configuration as in production, while the process does not require
> > > special
> > > privileges nor changes the state of the developer machine.
> > > 
> > > A complete documentation is available[1], I preferred to use README
> > > within
> > > the source tree as wiki tend to quickly become obsolete, while
> > > documentation
> > > within source tree can be modified by the commit that introduces a
> > > change.
> > > I
> > > will redirect to this file from the current wiki once the site will be
> > > up.
> > > 
> > > In a nut shell, after installing prerequisites, build and install the
> > > product
> > > using:
> > > 
> > > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > > 
> > > This will run maven and create product installation at
$HOME/ovirt-engine
> > > Next, a setup phase is required just like in production, to initialize
> > > configuration and database:
> > > 
> > > $ $HOME/ovirt-engine/bin/engine-setup-2
> > > 
> > > You have now fully functional product, including PKI, SSL,
host-deploy,
> > > tools.
> > > No manual database updates are required, no lose of functionality.
> > > 
> > > All that is left is to start the engine service:
> > > 
> > > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > > 
> > > Access to application:
> > >    http://localhost:8080
> > >    https://localhost:8443
> > > Debugging port is opened at port 8787.
> > > 
> > > Farther information exists in the documentation[1].
> > > 
> > > There are several inherit benefits of the new environment, the major
one
> > > is
> > > the ability to manage several environments in parallel on the same
host.
> > > For
> > > example, if we develop two separate features on two branches we can
> > > install
> > > the product into $HOME/ovirt-engine-feature1 and
> > > $HOME/ovirt-engine-feature-2 and have a separate database for each, if
we
> > > modify the ports jboss is listening to we can run two instances of
engine
> > > at
> > > the same time!
> > 
> > It is not clear to me why working on 2 bugs needs 2 installations of the
> > development environment.
> > If you have 2 different git branches and a separate database for each,
its
> > enough , am I missing something ?
> > I was used to create a git branch with the name of the BZ# and use
> > create_db.sh script to create a new database with the BZ# name.
> > Is this possible in the new method?
> > Also, does this mean that I will have to create/configure a new
workspace
> > for
> > eclipse each time I am starting to work on a new bug?
> > 
> > 
> > Thanks
> > 
> > 
> > > 
> > > We will be happy to work with all developers to assist in porting into
> > > the
> > > new development environment, the simplest is to create a new database
for
> > > this effort. Moti has a sequence of converting the existing database
> > > owned
> > > by postgres to be owned by the engine, Moti, can you please share
that?
> > > 
> > > We are sure there are missing bits, we will be happy to know these so
we
> > > can
> > > improve.
> > > 
> > > I am aware that developers (especially java) are conservative, but I
ask
> > > you
> > > to give us a chance, so that we make it easy for developers to join
the
> > > project, and to allow us to drop the parallel effort of packaging to
> > > production and fixing the broken development environment.
> > > 
> > > A special thanks to developers who took the time to test and provide
> > > feedback
> > > before the merged:
> > > - Yaniv Bronheim
> > > - Moti Asayag
> > > - Limor Gavish
> > > - Sharad Mishra
> > > - Ofer Schreiber
> > > 
> > > We are hoping that after migration you will be find this environment
> > > useful
> > > and friendly,
> > > 
> > > Sandro Bonazzola,
> > > Alex Lourie,
> > > Alon Bar-Lev.
> > > 
> > > [1]
> > >
http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;
hb=HEAD
> > > _______________________________________________
> > > 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
> > 
> 


------------------------------

Message: 4
Date: Tue, 14 May 2013 02:18:44 -0400 (EDT)
From: Alon Bar-Lev <alonbl at redhat.com>
To: Eli Mesika <emesika at redhat.com>
Cc: engine-devel <engine-devel at ovirt.org>, arch <arch at ovirt.org>
Subject: Re: [Engine-devel] [ANN] New development environment for
	ovirt-engine
Message-ID: <1732269511.831688.1368512324398.JavaMail.root at redhat.com>
Content-Type: text/plain; charset=utf-8



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 3:45:41 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for
ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>,
"Limor
> > Gavish" <lgavish at gmail.com>
> > Sent: Sunday, May 12, 2013 2:52:51 PM
> > Subject: [Engine-devel] [ANN] New development environment for
ovirt-engine
> > 
> > Hello all ovirt-engine developers,
> > 
> > When I first joined the ovirt project, it took me about two weeks to
setup
> > a
> > development environment, I needed to work on a bug related to
host-deploy
> > so
> > I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> > communicate with vdsm using SSL, this was virtually impossible to do so
> > without tweaking the product in a way that it is so different from
> > production use, that I cannot guarantee that whatever tested in
development
> > will actually work in production.
> > 
> > I peeked at the installation script in a hope that I can create partial
> > environment similar to production, but I found that the packaging
> > implementation makes to much assumption and is very difficult to adopt.
The
> > fact that I do not use fedora/rhel for my development made it even
worse.
> > 
> > I had no other option than to create rpms after each of my changes and
test
> > each in real production like setup.
> > 
> > It was obvious to me that the manual customization of developers to
achieve
> > working product will eventually break as product grow and move away from
> > being developer friendly to production friendly. For example, product
> > defaults cannot be these which serve developers, but these which serve
> > production the best, or having a valid PKI setup cannot be optional any
> > more
> > as components do need to use it. Same for location of files and
> > configuration, for example, if we write a pluggable infrastructure for
> > branding, we cannot damage the interface just because developers runs
the
> > product in their own manual customization.
> > 
> > I took the opportunity handed to me to port the ovirt-engine to other
> > distributions in order to provide a development environment that is
similar
> > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > re-wrote the whole installation of the product which can also be used to
> > setup the desired development environment.
> > 
> > Within this environment the product is set up using the same tools and
> > configuration as in production, while the process does not require
special
> > privileges nor changes the state of the developer machine.
> > 
> > A complete documentation is available[1], I preferred to use README
within
> > the source tree as wiki tend to quickly become obsolete, while
> > documentation
> > within source tree can be modified by the commit that introduces a
change.
> > I
> > will redirect to this file from the current wiki once the site will be
up.
> > 
> > In a nut shell, after installing prerequisites, build and install the
> > product
> > using:
> > 
> > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > 
> > This will run maven and create product installation at
$HOME/ovirt-engine
> > Next, a setup phase is required just like in production, to initialize
> > configuration and database:
> > 
> > $ $HOME/ovirt-engine/bin/engine-setup-2
> > 
> > You have now fully functional product, including PKI, SSL, host-deploy,
> > tools.
> > No manual database updates are required, no lose of functionality.
> > 
> > All that is left is to start the engine service:
> > 
> > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > 
> > Access to application:
> >    http://localhost:8080
> >    https://localhost:8443
> > Debugging port is opened at port 8787.
> > 
> > Farther information exists in the documentation[1].
> > 
> > There are several inherit benefits of the new environment, the major one
is
> > the ability to manage several environments in parallel on the same host.
> > For
> > example, if we develop two separate features on two branches we can
install
> > the product into $HOME/ovirt-engine-feature1 and
> > $HOME/ovirt-engine-feature-2 and have a separate database for each, if
we
> > modify the ports jboss is listening to we can run two instances of
engine
> > at
> > the same time!
> 
> It is not clear to me why working on 2 bugs needs 2 installations of the
> development environment.
> If you have 2 different git branches and a separate database for each, its
> enough , am I missing something ?

You have two different git branches, so you have two different binaries out
of the build, right?
These binaries should reside some where.
Currently you are probably use maven deploy or something similar into single
jboss, without proper environment, overriding each time the other branch's
binaries.
What if there is a change in configuration between the two? more
prerequisites, different service configuration? different database schema?

To make it easy, you can just duplicate the development environment, and be
sure you are up and running.

If you still want to take the chance you can... just make install-dev
PREFIX=$HOME/same-place and you will have the behavior of overriding the
same environment, and hoping for the best.

> I was used to create a git branch with the name of the BZ# and use
> create_db.sh script to create a new database with the BZ# name.
> Is this possible in the new method?

Yes.
You create an empty database manually, let's say engine-branch1.
Then you install the environment to own location, let say make install-dev
PREFIX=$HOME/ovirt-engine-branch1
When running engine-setup-2 you instruct the setup to use engine-branch1
database.
This database will be created out of the new branch's create_db.sh.
create_db.sh should not run manually now.

However, if you insist of creating a database manually and modify an
existing environment to use the new database, it is possible as well.
Edit $PREFIX/etc/ovirt-engine/engine.conf.d/10-setup-database.conf, and
specify where database is, then start the engine service.

> Also, does this mean that I will have to create/configure a new workspace
for
> eclipse each time I am starting to work on a new bug?

This I do not know. How does it work now when you switch branches?

> 
> 
> Thanks
> 
> 
> > 
> > We will be happy to work with all developers to assist in porting into
the
> > new development environment, the simplest is to create a new database
for
> > this effort. Moti has a sequence of converting the existing database
owned
> > by postgres to be owned by the engine, Moti, can you please share that?
> > 
> > We are sure there are missing bits, we will be happy to know these so we
> > can
> > improve.
> > 
> > I am aware that developers (especially java) are conservative, but I ask
> > you
> > to give us a chance, so that we make it easy for developers to join the
> > project, and to allow us to drop the parallel effort of packaging to
> > production and fixing the broken development environment.
> > 
> > A special thanks to developers who took the time to test and provide
> > feedback
> > before the merged:
> > - Yaniv Bronheim
> > - Moti Asayag
> > - Limor Gavish
> > - Sharad Mishra
> > - Ofer Schreiber
> > 
> > We are hoping that after migration you will be find this environment
useful
> > and friendly,
> > 
> > Sandro Bonazzola,
> > Alex Lourie,
> > Alon Bar-Lev.
> > 
> > [1]
> >
http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;
hb=HEAD
> > _______________________________________________
> > 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


End of Engine-devel Digest, Vol 20, Issue 39
********************************************




From fsimonce at redhat.com  Tue May 14 07:13:30 2013
From: fsimonce at redhat.com (Federico Simoncelli)
Date: Tue, 14 May 2013 03:13:30 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <1368639807.1072346.1368494471922.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<176765088.119212.1368352381011.JavaMail.root@redhat.com>
	<CAJ3aYLdniVuwCrPqE10yvoWo8WZj7k2KD3OUq1wEY_-urOfmGw@mail.gmail.com>
	<1368639807.1072346.1368494471922.JavaMail.root@redhat.com>
Message-ID: <1493980703.1034028.1368515610715.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Liran Zelkha" <liran.zelkha at gmail.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, May 14, 2013 3:21:11 AM
> Subject: Re: [Engine-devel] What type of DB inheritance to use?
> 
> 
> 
> ----- Original Message -----
> > From: "Liran Zelkha" <liran.zelkha at gmail.com>
> > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, May 12, 2013 1:19:07 PM
> > Subject: Re: [Engine-devel] What type of DB inheritance to use?
> > 
> > Hi
> > 
> > From my experience, single table inheritance quickly grows into something
> > unmanagable, as more and more (child related) fields are added, each line
> > has a few relevant attributes, and a long list of NULL values.
> > I would go with option 3. With materialized views, the costs of joins can
> > be
> > eliminated.
> 
> +1

I'd prefer option 3 too.

-- 
Federico


From mperina at redhat.com  Tue May 14 07:51:02 2013
From: mperina at redhat.com (Martin Perina)
Date: Tue, 14 May 2013 03:51:02 -0400 (EDT)
Subject: [Engine-devel] Engine config and device custom properties
In-Reply-To: <1718492816.1181184.1368517750953.JavaMail.root@redhat.com>
Message-ID: <99189519.1184200.1368517862249.JavaMail.root@redhat.com>

Hi,

I'm working on a patch to support custom device properties in ovirt-engine.
I would like that custom device properties format can be set using engine-config
command in a similar way as UserDefinedVMProperties. What is needed to be done
to support this?

Thanks

Martin


From masayag at redhat.com  Tue May 14 09:14:14 2013
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 14 May 2013 05:14:14 -0400 (EDT)
Subject: [Engine-devel] Engine config and device custom properties
In-Reply-To: <99189519.1184200.1368517862249.JavaMail.root@redhat.com>
References: <99189519.1184200.1368517862249.JavaMail.root@redhat.com>
Message-ID: <1070389200.1303205.1368522854792.JavaMail.root@redhat.com>

Hi Martin,

By looking at the code - there seems no validator for the format provided
by the user for the UserDefinedVMProperties.

It seems that the engine will write an exception to log specifying the format is invalid,
as the format is being validated during engine startup by
InitBackendServicesOnStartupBean.create() which invokes 
VmPropertiesUtils.getInstance().init()

Therefore there is a need to validate the format in earlier stage, when setting the values
for the properties via the engine-config.

1. Extend the engine-config value helpers with a new type:
DevicePropertiesValueHelper extends org.ovirt.engine.core.config.entity.helper.ValueHelper
and also a compliant DevicePropertiesValueHelperTest

2. DevicePropertiesValueHelper.validate() should reuse the parsing logic of the device properties
from VmPropertiesUtils.parseVMPropertiesRegex()

3. Define the value helper for you new property in
packaging/etc/engine-config/engine-config.properties:

CustomDeviceProperties.description="your description"
CustomDeviceProperties.type=DevicePropertiesValueHelper

You the new install-dev to easily test you changes.

Regards,
Moti

----- Original Message -----
> From: "Martin Perina" <mperina at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, May 14, 2013 10:51:02 AM
> Subject: [Engine-devel] Engine config and device custom properties
> 
> Hi,
> 
> I'm working on a patch to support custom device properties in ovirt-engine.
> I would like that custom device properties format can be set using
> engine-config
> command in a similar way as UserDefinedVMProperties. What is needed to be
> done
> to support this?
> 
> Thanks
> 
> Martin
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Tue May 14 10:32:39 2013
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 14 May 2013 06:32:39 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for
 ovirt-engine
In-Reply-To: <1732269511.831688.1368512324398.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<188337855.1067044.1368492341205.JavaMail.root@redhat.com>
	<1732269511.831688.1368512324398.JavaMail.root@redhat.com>
Message-ID: <1515903557.1242775.1368527559390.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> Sent: Tuesday, May 14, 2013 9:18:44 AM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "arch" <arch at ovirt.org>
> > Sent: Tuesday, May 14, 2013 3:45:41 AM
> > Subject: Re: [Engine-devel] [ANN] New development environment for
> > ovirt-engine
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Cc: "arch" <arch at ovirt.org>, "Sharad Mishra" <snmishra at us.ibm.com>,
> > > "Limor
> > > Gavish" <lgavish at gmail.com>
> > > Sent: Sunday, May 12, 2013 2:52:51 PM
> > > Subject: [Engine-devel] [ANN] New development environment for
> > > ovirt-engine
> > > 
> > > Hello all ovirt-engine developers,
> > > 
> > > When I first joined the ovirt project, it took me about two weeks to
> > > setup
> > > a
> > > development environment, I needed to work on a bug related to host-deploy
> > > so
> > > I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> > > communicate with vdsm using SSL, this was virtually impossible to do so
> > > without tweaking the product in a way that it is so different from
> > > production use, that I cannot guarantee that whatever tested in
> > > development
> > > will actually work in production.
> > > 
> > > I peeked at the installation script in a hope that I can create partial
> > > environment similar to production, but I found that the packaging
> > > implementation makes to much assumption and is very difficult to adopt.
> > > The
> > > fact that I do not use fedora/rhel for my development made it even worse.
> > > 
> > > I had no other option than to create rpms after each of my changes and
> > > test
> > > each in real production like setup.
> > > 
> > > It was obvious to me that the manual customization of developers to
> > > achieve
> > > working product will eventually break as product grow and move away from
> > > being developer friendly to production friendly. For example, product
> > > defaults cannot be these which serve developers, but these which serve
> > > production the best, or having a valid PKI setup cannot be optional any
> > > more
> > > as components do need to use it. Same for location of files and
> > > configuration, for example, if we write a pluggable infrastructure for
> > > branding, we cannot damage the interface just because developers runs the
> > > product in their own manual customization.
> > > 
> > > I took the opportunity handed to me to port the ovirt-engine to other
> > > distributions in order to provide a development environment that is
> > > similar
> > > to production setup. Together with Sandro Bonazzola and Alex Lourie we
> > > re-wrote the whole installation of the product which can also be used to
> > > setup the desired development environment.
> > > 
> > > Within this environment the product is set up using the same tools and
> > > configuration as in production, while the process does not require
> > > special
> > > privileges nor changes the state of the developer machine.
> > > 
> > > A complete documentation is available[1], I preferred to use README
> > > within
> > > the source tree as wiki tend to quickly become obsolete, while
> > > documentation
> > > within source tree can be modified by the commit that introduces a
> > > change.
> > > I
> > > will redirect to this file from the current wiki once the site will be
> > > up.
> > > 
> > > In a nut shell, after installing prerequisites, build and install the
> > > product
> > > using:
> > > 
> > > $ make clean install-dev PREFIX=$HOME/ovirt-engine
> > > 
> > > This will run maven and create product installation at $HOME/ovirt-engine
> > > Next, a setup phase is required just like in production, to initialize
> > > configuration and database:
> > > 
> > > $ $HOME/ovirt-engine/bin/engine-setup-2
> > > 
> > > You have now fully functional product, including PKI, SSL, host-deploy,
> > > tools.
> > > No manual database updates are required, no lose of functionality.
> > > 
> > > All that is left is to start the engine service:
> > > 
> > > $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> > > 
> > > Access to application:
> > >    http://localhost:8080
> > >    https://localhost:8443
> > > Debugging port is opened at port 8787.
> > > 
> > > Farther information exists in the documentation[1].
> > > 
> > > There are several inherit benefits of the new environment, the major one
> > > is
> > > the ability to manage several environments in parallel on the same host.
> > > For
> > > example, if we develop two separate features on two branches we can
> > > install
> > > the product into $HOME/ovirt-engine-feature1 and
> > > $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> > > modify the ports jboss is listening to we can run two instances of engine
> > > at
> > > the same time!
> > 
> > It is not clear to me why working on 2 bugs needs 2 installations of the
> > development environment.
> > If you have 2 different git branches and a separate database for each, its
> > enough , am I missing something ?
> 
> You have two different git branches, so you have two different binaries out
> of the build, right?
> These binaries should reside some where.
> Currently you are probably use maven deploy or something similar into single
> jboss, without proper environment, overriding each time the other branch's
> binaries.
> What if there is a change in configuration between the two? more
> prerequisites, different service configuration? different database schema?
> 
> To make it easy, you can just duplicate the development environment, and be
> sure you are up and running.
> 
> If you still want to take the chance you can... just make install-dev
> PREFIX=$HOME/same-place and you will have the behavior of overriding the
> same environment, and hoping for the best.

That's good , thanks

> 
> > I was used to create a git branch with the name of the BZ# and use
> > create_db.sh script to create a new database with the BZ# name.
> > Is this possible in the new method?
> 
> Yes.
> You create an empty database manually, let's say engine-branch1.
> Then you install the environment to own location, let say make install-dev
> PREFIX=$HOME/ovirt-engine-branch1
> When running engine-setup-2 you instruct the setup to use engine-branch1
> database.
> This database will be created out of the new branch's create_db.sh.
> create_db.sh should not run manually now.
> 
> However, if you insist of creating a database manually and modify an existing
> environment to use the new database, it is possible as well.
> Edit $PREFIX/etc/ovirt-engine/engine.conf.d/10-setup-database.conf, and
> specify where database is, then start the engine service.

Great, thanks

> 
> > Also, does this mean that I will have to create/configure a new workspace
> > for
> > eclipse each time I am starting to work on a new bug?
> 
> This I do not know. How does it work now when you switch branches?

I will check that, maybe this is unrelated ...

Thanks again , will test that ASAP
> 
> > 
> > 
> > Thanks
> > 
> > 
> > > 
> > > We will be happy to work with all developers to assist in porting into
> > > the
> > > new development environment, the simplest is to create a new database for
> > > this effort. Moti has a sequence of converting the existing database
> > > owned
> > > by postgres to be owned by the engine, Moti, can you please share that?
> > > 
> > > We are sure there are missing bits, we will be happy to know these so we
> > > can
> > > improve.
> > > 
> > > I am aware that developers (especially java) are conservative, but I ask
> > > you
> > > to give us a chance, so that we make it easy for developers to join the
> > > project, and to allow us to drop the parallel effort of packaging to
> > > production and fixing the broken development environment.
> > > 
> > > A special thanks to developers who took the time to test and provide
> > > feedback
> > > before the merged:
> > > - Yaniv Bronheim
> > > - Moti Asayag
> > > - Limor Gavish
> > > - Sharad Mishra
> > > - Ofer Schreiber
> > > 
> > > We are hoping that after migration you will be find this environment
> > > useful
> > > and friendly,
> > > 
> > > Sandro Bonazzola,
> > > Alex Lourie,
> > > Alon Bar-Lev.
> > > 
> > > [1]
> > > http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 


From masayag at redhat.com  Tue May 14 10:54:21 2013
From: masayag at redhat.com (Moti Asayag)
Date: Tue, 14 May 2013 06:54:21 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for
	ovirt-engine
In-Reply-To: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
Message-ID: <248944163.1356174.1368528861600.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "Yaniv Bronheim" <ybronhei at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "Limor Gavish" <lgavish at gmail.com>,
> "Sharad Mishra" <snmishra at us.ibm.com>, "Alex Lourie" <alourie at redhat.com>, "Sandro Bonazzola" <sbonazzo at redhat.com>,
> "arch" <arch at ovirt.org>, "Ofer Schreiber" <oschreib at redhat.com>
> Sent: Sunday, May 12, 2013 2:52:51 PM
> Subject: [ANN] New development environment for ovirt-engine
> 
> Hello all ovirt-engine developers,
> 
> When I first joined the ovirt project, it took me about two weeks to setup a
> development environment, I needed to work on a bug related to host-deploy so
> I needed an environment that could use the ssh, PKI, vdsm-bootstrap and
> communicate with vdsm using SSL, this was virtually impossible to do so
> without tweaking the product in a way that it is so different from
> production use, that I cannot guarantee that whatever tested in development
> will actually work in production.
> 
> I peeked at the installation script in a hope that I can create partial
> environment similar to production, but I found that the packaging
> implementation makes to much assumption and is very difficult to adopt. The
> fact that I do not use fedora/rhel for my development made it even worse.
> 
> I had no other option than to create rpms after each of my changes and test
> each in real production like setup.
> 
> It was obvious to me that the manual customization of developers to achieve
> working product will eventually break as product grow and move away from
> being developer friendly to production friendly. For example, product
> defaults cannot be these which serve developers, but these which serve
> production the best, or having a valid PKI setup cannot be optional any more
> as components do need to use it. Same for location of files and
> configuration, for example, if we write a pluggable infrastructure for
> branding, we cannot damage the interface just because developers runs the
> product in their own manual customization.
> 
> I took the opportunity handed to me to port the ovirt-engine to other
> distributions in order to provide a development environment that is similar
> to production setup. Together with Sandro Bonazzola and Alex Lourie we
> re-wrote the whole installation of the product which can also be used to
> setup the desired development environment.
> 
> Within this environment the product is set up using the same tools and
> configuration as in production, while the process does not require special
> privileges nor changes the state of the developer machine.
> 
> A complete documentation is available[1], I preferred to use README within
> the source tree as wiki tend to quickly become obsolete, while documentation
> within source tree can be modified by the commit that introduces a change. I
> will redirect to this file from the current wiki once the site will be up.
> 
> In a nut shell, after installing prerequisites, build and install the product
> using:
> 
> $ make clean install-dev PREFIX=$HOME/ovirt-engine
> 
> This will run maven and create product installation at $HOME/ovirt-engine
> Next, a setup phase is required just like in production, to initialize
> configuration and database:
> 
> $ $HOME/ovirt-engine/bin/engine-setup-2
> 
> You have now fully functional product, including PKI, SSL, host-deploy,
> tools.
> No manual database updates are required, no lose of functionality.
> 
> All that is left is to start the engine service:
> 
> $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> 
> Access to application:
>    http://localhost:8080
>    https://localhost:8443
> Debugging port is opened at port 8787.
> 
> Farther information exists in the documentation[1].
> 
> There are several inherit benefits of the new environment, the major one is
> the ability to manage several environments in parallel on the same host. For
> example, if we develop two separate features on two branches we can install
> the product into $HOME/ovirt-engine-feature1 and
> $HOME/ovirt-engine-feature-2 and have a separate database for each, if we
> modify the ports jboss is listening to we can run two instances of engine at
> the same time!
> 
> We will be happy to work with all developers to assist in porting into the
> new development environment, the simplest is to create a new database for
> this effort. Moti has a sequence of converting the existing database owned
> by postgres to be owned by the engine, Moti, can you please share that?
> 

Reusing an existing DB schema requires a bit more work since the installation 
of dev-env advise using database as a user and not a superuser like 'postgres'
user used to create the database originally. 
Therefore if wishes to use user 'engine' as in the instructions, there is a need
to change the current schema owner and also the ownership of all of its objects.

The easiest path I found for that purpose is:
1. Create a dump of the database using the script in [1].
2. Rename the owner in the dump file to the new owner (s/OWNER TO postgres/OWNER TO engine/g).
3. Import the dump file to the new DB owned by the engine user using [2] (provide -r flag to
drop the former db).

[1] ovirt-engine/backend/manager/dbscripts/backup.sh
[2] ovirt-engine/backend/manager/dbscripts/restore.sh

> We are sure there are missing bits, we will be happy to know these so we can
> improve.
> 
> I am aware that developers (especially java) are conservative, but I ask you
> to give us a chance, so that we make it easy for developers to join the
> project, and to allow us to drop the parallel effort of packaging to
> production and fixing the broken development environment.
> 
> A special thanks to developers who took the time to test and provide feedback
> before the merged:
> - Yaniv Bronheim
> - Moti Asayag
> - Limor Gavish
> - Sharad Mishra
> - Ofer Schreiber
> 
> We are hoping that after migration you will be find this environment useful
> and friendly,
> 
> Sandro Bonazzola,
> Alex Lourie,
> Alon Bar-Lev.
> 
> [1]
> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> 


From alourie at redhat.com  Tue May 14 13:28:05 2013
From: alourie at redhat.com (Alex Lourie)
Date: Tue, 14 May 2013 13:31:05 +0003
Subject: [Engine-devel] [ANN] New development environment for
	ovirt-engine
In-Reply-To: <248944163.1356174.1368528861600.JavaMail.root@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<248944163.1356174.1368528861600.JavaMail.root@redhat.com>
Message-ID: <201305141328.r4EDS6VD014561@int-mx11.intmail.prod.int.phx2.redhat.com>



On Tue, May 14, 2013 at 1:54 PM, Moti Asayag <masayag at redhat.com> wrote:
> 
> 
> ----- Original Message -----
>>  From: "Alon Bar-Lev" <alonbl at redhat.com>
>>  To: "engine-devel" <engine-devel at ovirt.org>
>>  Cc: "Yaniv Bronheim" <ybronhei at redhat.com>, "Moti Asayag" 
>> <masayag at redhat.com>, "Limor Gavish" <lgavish at gmail.com>,
>>  "Sharad Mishra" <snmishra at us.ibm.com>, "Alex Lourie" 
>> <alourie at redhat.com>, "Sandro Bonazzola" <sbonazzo at redhat.com>,
>>  "arch" <arch at ovirt.org>, "Ofer Schreiber" <oschreib at redhat.com>
>>  Sent: Sunday, May 12, 2013 2:52:51 PM
>>  Subject: [ANN] New development environment for ovirt-engine
>>  
>>  Hello all ovirt-engine developers,
>>  
>>  When I first joined the ovirt project, it took me about two weeks 
>> to setup a
>>  development environment, I needed to work on a bug related to 
>> host-deploy so
>>  I needed an environment that could use the ssh, PKI, vdsm-bootstrap 
>> and
>>  communicate with vdsm using SSL, this was virtually impossible to 
>> do so
>>  without tweaking the product in a way that it is so different from
>>  production use, that I cannot guarantee that whatever tested in 
>> development
>>  will actually work in production.
>>  
>>  I peeked at the installation script in a hope that I can create 
>> partial
>>  environment similar to production, but I found that the packaging
>>  implementation makes to much assumption and is very difficult to 
>> adopt. The
>>  fact that I do not use fedora/rhel for my development made it even 
>> worse.
>>  
>>  I had no other option than to create rpms after each of my changes 
>> and test
>>  each in real production like setup.
>>  
>>  It was obvious to me that the manual customization of developers to 
>> achieve
>>  working product will eventually break as product grow and move away 
>> from
>>  being developer friendly to production friendly. For example, 
>> product
>>  defaults cannot be these which serve developers, but these which 
>> serve
>>  production the best, or having a valid PKI setup cannot be optional 
>> any more
>>  as components do need to use it. Same for location of files and
>>  configuration, for example, if we write a pluggable infrastructure 
>> for
>>  branding, we cannot damage the interface just because developers 
>> runs the
>>  product in their own manual customization.
>>  
>>  I took the opportunity handed to me to port the ovirt-engine to 
>> other
>>  distributions in order to provide a development environment that is 
>> similar
>>  to production setup. Together with Sandro Bonazzola and Alex Lourie 
>> we
>>  re-wrote the whole installation of the product which can also be 
>> used to
>>  setup the desired development environment.
>>  
>>  Within this environment the product is set up using the same tools 
>> and
>>  configuration as in production, while the process does not require 
>> special
>>  privileges nor changes the state of the developer machine.
>>  
>>  A complete documentation is available[1], I preferred to use README 
>> within
>>  the source tree as wiki tend to quickly become obsolete, while 
>> documentation
>>  within source tree can be modified by the commit that introduces a 
>> change. I
>>  will redirect to this file from the current wiki once the site will 
>> be up.
>>  
>>  In a nut shell, after installing prerequisites, build and install 
>> the product
>>  using:
>>  
>>  $ make clean install-dev PREFIX=$HOME/ovirt-engine
>>  
>>  This will run maven and create product installation at 
>> $HOME/ovirt-engine
>>  Next, a setup phase is required just like in production, to 
>> initialize
>>  configuration and database:
>>  
>>  $ $HOME/ovirt-engine/bin/engine-setup-2
>>  
>>  You have now fully functional product, including PKI, SSL, 
>> host-deploy,
>>  tools.
>>  No manual database updates are required, no lose of functionality.
>>  
>>  All that is left is to start the engine service:
>>  
>>  $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py 
>> start
>>  
>>  Access to application:
>>     http://localhost:8080
>>     https://localhost:8443
>>  Debugging port is opened at port 8787.
>>  
>>  Farther information exists in the documentation[1].
>>  
>>  There are several inherit benefits of the new environment, the 
>> major one is
>>  the ability to manage several environments in parallel on the same 
>> host. For
>>  example, if we develop two separate features on two branches we can 
>> install
>>  the product into $HOME/ovirt-engine-feature1 and
>>  $HOME/ovirt-engine-feature-2 and have a separate database for each, 
>> if we
>>  modify the ports jboss is listening to we can run two instances of 
>> engine at
>>  the same time!
>>  
>>  We will be happy to work with all developers to assist in porting 
>> into the
>>  new development environment, the simplest is to create a new 
>> database for
>>  this effort. Moti has a sequence of converting the existing 
>> database owned
>>  by postgres to be owned by the engine, Moti, can you please share 
>> that?
>>  
>> 
> Reusing an existing DB schema requires a bit more work since the 
> installation 
> of dev-env advise using database as a user and not a superuser like 
> 'postgres'
> user used to create the database originally. 
> 

We no longer (since 3.1) create the DB in production with user 
postgres. All the DB operations are done with application user (engine 
by default), especially with remote DB installations. The application 
user doesn't have superuser privileges, only the ones required for DB 
creation and removal.

> 
> Therefore if wishes to use user 'engine' as in the instructions, 
> there is a need
> to change the current schema owner and also the ownership of all of 
> its objects.
> 
> The easiest path I found for that purpose is:
> 1. Create a dump of the database using the script in [1].
> 2. Rename the owner in the dump file to the new owner (s/OWNER TO 
> postgres/OWNER TO engine/g).
> 3. Import the dump file to the new DB owned by the engine user using 
> [2] (provide -r flag to
> drop the former db).
> 
> [1] ovirt-engine/backend/manager/dbscripts/backup.sh
> [2] ovirt-engine/backend/manager/dbscripts/restore.sh
> 
>>  We are sure there are missing bits, we will be happy to know these 
>> so we can
>>  improve.
>>  
>>  I am aware that developers (especially java) are conservative, but 
>> I ask you
>>  to give us a chance, so that we make it easy for developers to join 
>> the
>>  project, and to allow us to drop the parallel effort of packaging to
>>  production and fixing the broken development environment.
>>  
>>  A special thanks to developers who took the time to test and 
>> provide feedback
>>  before the merged:
>>  - Yaniv Bronheim
>>  - Moti Asayag
>>  - Limor Gavish
>>  - Sharad Mishra
>>  - Ofer Schreiber
>>  
>>  We are hoping that after migration you will be find this 
>> environment useful
>>  and friendly,
>>  
>>  Sandro Bonazzola,
>>  Alex Lourie,
>>  Alon Bar-Lev.
>>  
>>  [1]
>>  
>> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
>>  
>> 



From vszocs at redhat.com  Tue May 14 14:13:41 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 14 May 2013 10:13:41 -0400 (EDT)
Subject: [Engine-devel] [REST-API] Support passing auth information
 without having to use HTTP Authorization header #958874
In-Reply-To: <518B6C07.1080504@redhat.com>
References: <518751C7.8090208@redhat.com>
	<1665518752.4971723.1367945088296.JavaMail.root@redhat.com>
	<518B6C07.1080504@redhat.com>
Message-ID: <1148533336.1301072.1368540821616.JavaMail.root@redhat.com>

Hi guys,

I followed this thread, there are some interesting points, sending my comments below.

First of all, I understand that REST API should follow common REST principles, and implement additional features (such as authentication) seamlessly on top of these principles, if possible.

It's just that sometimes, especially in JavaScript/HTML world, there are known issues (limitations) for which a good REST API implementation should provide reasonable workarounds. For me, this means two things:
(a) issue with browser-specific HTTP 'Authorization' header handling for JavaScript apps [https://bugzilla.redhat.com/958861]
(b) issue with browser-specific cookie handling restriction for JavaScript apps [*]
[*] long story short: JavaScript app hosted from "/myapp/index.html" cannot access cookies for say "/api" path, only for "/myapp" path, i.e. cookies are under control of browser and not JavaScript app, more details: http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path

Both issues written above have something (very important) in common: "browser-specific" + browser having control (over 'Authorization' header / cookies) instead of JavaScript app..

@Michael: is there some RFE/document for your "URI based authentication" proposal? Assuming JSESSIONID could be passed via URI, we could use this as a workaround for browser-specific cookie handling restriction. In practice, this would mean any JavaScript (WebAdmin itself, UI Plugin, any other web app) could talk to REST API without relying on cookies entirely. Even better, if we could pass auth credentials via URI, we could talk to REST API without relying on HTTP 'Authorization' header entirely.

Also, I'm not strictly against HTTP Basic Auth used in REST API, I just pointed out some of its drawbacks (a while ago). Originally, I proposed to support alternative (extra) auth scheme that is better and more secure, but in the end, I guess we should settle for one reasonably good auth scheme. I looked at SPNEGO [http://en.wikipedia.org/wiki/SPNEGO] - it looks interesting, basically a protocol for negotiating specific auth scheme based on what server supports, the question is if we really need to support multiple auth schemes, or just one that is reasonably good.

One auth scheme I really like is [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html] - basically preventing password from being sent over the network entirely, which is always a good thing. The disadvantage is that the server has to know password ("secret key") in plain-text for the given user, in order to re-produce & compare signature (hash) of relevant request information. On the other hand, Gerrit REST API uses HTTP Digest Auth [https://gerrit-review.googlesource.com/Documentation/rest-api.html#_protocol_details] but IMHO Digest Auth is over-complicated protocol, most importantly its too complex for clients to implement.

> and this why we having this discussion, currently options are:
> 1. adapt session based authentication
> 2. introduce new concept

I'd vote for auth scheme that doesn't contradict general REST principles but is reasonably good (easy & secure). One thing is the auth protocol itself (HTTP Basic Auth), another is how auth-related information is transmitted between client and server (HTTP 'Authorization' header, JSESSIONID cookie) - for now I'd just proposed to revisit the "auth-related info transmission" part..

Regards,
Vojtech


----- Original Message -----
From: "Michael Pasternak" <mpastern at redhat.com>
To: "Alon Bar-Lev" <alonbl at redhat.com>
Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>, "Itamar Heim" <iheim at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Barak Azulay" <bazulay at redhat.com>
Sent: Thursday, May 9, 2013 11:27:35 AM
Subject: Re: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874

On 05/07/2013 07:44 PM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>,
>> "Itamar Heim" <iheim at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Monday, May 6, 2013 9:46:31 AM
>> Subject: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
>>
>>
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=958874
>>
>> Hi Alon,
>>
>> (In reply to comment #2)
>>>
>>> Regardless of this specific RFE I would like to write that I don't like the
>>> REST API session mechanism
>>> [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as it
>>> relays on cookies and not explicit API interaction.
>>
>> authentication in RESTful application is a matter of debate, it can be
>> achieved
>> in various ways, but session + cookie auth. method is very common and usually
>> effective,
>>
>> it's biggest disadvantage is that it's not exactly RESfull cause client
>> have to maintain (story) the cookie and not the server (but i wouldn't call
>> it an
>> issue at all), besides that it's works perfectly well from the REST PoV,
>>
>> also some may say that cookies are not strong enough and OAuth for instance
>> should be used instead, but this is a different story cause in our case,
>> cookie
>> are for the clients (not browsers [1]) that can store them in a secure way or
>> even
>> not to store at all (in-memory cookie).
>>
>> [1] another disadvantage is that webbrowsers not able to access cookie
>> namespace,
>> but lately i've suggested URI based authentication [2] to support web
>> browsers
>> as well.
>>
>> [2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html
>>
>> the biggest advantage of the cookie is a session expiration that maintained
>> by the server and abstracted from the client what is much better from
>> security
>> PoV than standard authentication mechanisms such as HTTP basic auth for
>> instance
>> which can be potentially cached.
> 
> Expiration is always managed by server side, regardless the cookie vs ticket debate.
> 
>>
>>> I would have expected a
>>> 'ticket' to be retrieved and that 'ticket' to be disconnected from the
>>> application server objects. Although we can refer the 'cookie' as a ticket,
>>> however the requirement to parse it should not be required, there be a
>>> conflict between two separate applications running on same server, and
>>> there
>>> may be a problem to transfer credentials between servers.
>>
>> well, this is not exactly correct:
>>
>> 1. client desn't have to decode/parse the cookie and pass credentials, all it
>> need is
>>    just to store the cookie and pass it as is to server on every request.
> 
> You just described what cookies are.
> And if I understand we want better control of application authentication, disconnected from 'default browser behavior'.
> 
>> 2. "conflict between two separate applications running on same server"?
>> different cookie
>>    uses different domain & path by spec., can you pls explain what do you
>>    mean by this?
> 
> If you call the cookie JSESSIONID....

different applications cannot live under same path,
this what for cookie has a "path" attribute,

but it can create a bit of confusion indeed, but you not
talking with more than one application in same time right ?!,
i.e container/client fetches the JSESSIONID cookie from the
specific request/response,

so i'm not sure how possibly client can get in reply two
cookies with a same name (even if all applications are using
same cookie)

>  
>>>
>>> If we modify authentication we should support more authentication types, at
>>> least SPNEGO.
>>>
>>> In order to allow SPNEGO and other authentication mechanisms, we better
>>> force people to use single URI to perform the login and return
>>> authenticated
>>> 'ticket' to continue interaction with application.
>>
>> this is good for the backend authentication, but is not for the RESTful
>> application, it's like buying an aeroplane and driving it on a road,
> 
> And why is that? who are you to decide what authentication mechanism is to be used by customers?

alon, you misunderstood, i'm not talking about authentication method,
but about your sentence ^ "we better force people to use single URI"

> If customer has a policy of not transmitting passwords over the network, then SPENGO is your friend. 
> But let's ignore it for now.

cookie is not any different from the SPENGO token in this meaning,
it's just another data container.

> 
>> "force people to use single URI to perform the login" means SOAP while we
>> wanted REST
>> where any URI is considered as entry point and actually a resource address
>> that should
>> be accessible/manipulatable and authentication should be
>> abstracted/disconnected from
>> this concept.
> 
> Again, you provide statements that are not written in stone.

this is main REST principal.

> Having custom authentication header breaks the 'plain simple rest'.
> Having a URI is only makes it easier to manage this breakage.

for us, but this is breaks a REST concept.

> 
>> SPNEGO is only an implementation detail that can be abstracted for the API.
> 
> I don't follow.
> 
>>> This will be much simpler
>>> implementation at the api side and much more efficient, and as we are
>>> discussion application-to-application interaction there should be no user
>>> experience visible issues.
>>
>> i'm not sure: "force people to use single URI to perform the login" and no
>> "no user experience visible issues."?
> 
> Please describe how the prefer mechanism suggested can be implemented in standard browser.

it cannot because authorization header has to be supplied only when
client wishes to reinitialize the JSESSION, and web browsers can't omit
it during the lifetime.

all this cause we don't support web browsers in api yet, session based
authentication mechanism was designed for http clients,

and this why we having this discussion, currently options are:

1. adapt session based authentication
2. introduce new concept

personally i prefer #1 as it's less noisy and easily achievable.

> And if it cannot, and custom logic is required, why a custom logic that accesses a custom URI to perform login is any different.

it's not RESTful

>  
>>>
>>> What I recommend is purely applicative rest login command...
>>
>> IIUC this is SOAP and not REST ...
> 
> Again... please refrain from these kind of void statements.
> SOAP is a protocol, it has specific format and rules.
> It may or may not use this or any other suggested authentication mechanism.

i'm not talking about the protocol, but about the conceptual differences
between SOAP and REST services.

SOAP is a RPC (Remote Procedure Call) and has single entry point on which
different methods are invoked, having single dedicated method for login
works in this case,

REST is a ROA (Resource Oriented Architecture), i.e everything is REST is a
resource, and you have to operate on these resources, authentication is only
an implementation detail that should not break this concept.

now saying this i think is clear that you have no place to put at the login()
method you've mentioned,

standard way for authentication in REST/HTTP is via 'authorization' header (per request),
optimizing this we've introduced new concept via sessionid,

user can choose between two by passing 'prefer:persistent_auth' header,

hope it's clear now, please let me know otherwise.

>  
>>> ---
>>> Input: authentication type, authentication credentials
>>>     authentication=http
>>>     authentication=password
>>>     credentials:
>>>         user=user
>>>         password=password
>>>     [OPTIONALLY] HTTP authentication headers
>>> Output:
>>>     ticket
>>>     ticket issue time (required to avoid clock sync)
>>>     ticket expiration time
>>> Logic:
>>> if authentication is http, use http authentication headers to establish
>>> user
>>> authentication. This will allow future SSO.
>>> if authentication is password, use embedded credentials.
>>> ---
>>>
>>> For every other rest call add http header:
>>>     oVirt-Authentication-Ticket: <ticket>
>>
>> this is not any different from the today's session based auth. only
>> instead of  oVirt-Authentication-Ticket added cookie.
> 
> I did not claim otherwise, I wrote that I don't like cookies, I do like explicit headers.
> As I wrote, cookies has limited storage at client, cookies may conflict, cookies has issues with clusters.
> Headers do not.

using headers has own drawbacks, WebAdmin core is not only entity that
requires authentication in the app, i'll give you one use-case:

today we have plugin interface in WebAdmin, WebAdmin may have different
plugins installed, to maintain different permissions for every plugin,
each will have to send own authorization data on every request,

as you see this turns to be truly complex, almost not feasible via headers,

btw in other thread i suggested to used URL parameters for passing authentication
tokens.

> 
>>>
>>> The backend side will attach the correct security context to the action if
>>> the header is received.
>>
>> this is how it's works today.
> 
> I could not imagine that.
>  
> 
> Regards,
> Alon
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From smizrahi at redhat.com  Tue May 14 14:35:20 2013
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Tue, 14 May 2013 10:35:20 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <1493980703.1034028.1368515610715.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<176765088.119212.1368352381011.JavaMail.root@redhat.com>
	<CAJ3aYLdniVuwCrPqE10yvoWo8WZj7k2KD3OUq1wEY_-urOfmGw@mail.gmail.com>
	<1368639807.1072346.1368494471922.JavaMail.root@redhat.com>
	<1493980703.1034028.1368515610715.JavaMail.root@redhat.com>
Message-ID: <290717449.1323115.1368542120760.JavaMail.root@redhat.com>

>From my experience inheritance in the database is usually a bad idea all together.
Fields like even if "user" and "password" fields exist in more than one provider type
they shouldn't share a table as their indexes and type validation have no reason to be
shared (even if they theoretically can)and it makes both suffer from forced standardisation.

I don't know what a "provider" is in your world but in the classic sense you should even
have all providers be part of the same object inheritance as you shouldn't have all
factories. A "Provider" is a function and not identity. In Java terms, and interface and
not a base class.

----- Original Message -----
> From: "Federico Simoncelli" <fsimonce at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, May 14, 2013 3:13:30 AM
> Subject: Re: [Engine-devel] What type of DB inheritance to use?
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Liran Zelkha" <liran.zelkha at gmail.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, May 14, 2013 3:21:11 AM
> > Subject: Re: [Engine-devel] What type of DB inheritance to use?
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Liran Zelkha" <liran.zelkha at gmail.com>
> > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Sunday, May 12, 2013 1:19:07 PM
> > > Subject: Re: [Engine-devel] What type of DB inheritance to use?
> > > 
> > > Hi
> > > 
> > > From my experience, single table inheritance quickly grows into something
> > > unmanagable, as more and more (child related) fields are added, each line
> > > has a few relevant attributes, and a long list of NULL values.
> > > I would go with option 3. With materialized views, the costs of joins can
> > > be
> > > eliminated.
> > 
> > +1
> 
> I'd prefer option 3 too.
> 
> --
> Federico
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From smizrahi at redhat.com  Tue May 14 14:40:10 2013
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Tue, 14 May 2013 10:40:10 -0400 (EDT)
Subject: [Engine-devel] What type of DB inheritance to use?
In-Reply-To: <290717449.1323115.1368542120760.JavaMail.root@redhat.com>
References: <1682384155.165721.1368351734157.JavaMail.root@redhat.com>
	<176765088.119212.1368352381011.JavaMail.root@redhat.com>
	<CAJ3aYLdniVuwCrPqE10yvoWo8WZj7k2KD3OUq1wEY_-urOfmGw@mail.gmail.com>
	<1368639807.1072346.1368494471922.JavaMail.root@redhat.com>
	<1493980703.1034028.1368515610715.JavaMail.root@redhat.com>
	<290717449.1323115.1368542120760.JavaMail.root@redhat.com>
Message-ID: <758161657.1326801.1368542410990.JavaMail.root@redhat.com>

Sorry, very tired. I read what I wrote and thought I should rephrase.

>From my experience inheritance in the database is usually a bad idea all
together.
Even if "user" and "password" fields exist in more than one
provider type
they shouldn't share a table as their indexes and type validation have no
reason to be > shared (even if they theoretically can)and it makes both
suffer from forced standardisation.

I don't know what a "Provider" in relation to your specific problem
but in the classic sense you shouldn't even have all providers be part
of the same type hatchery as you shouldn't have all factories or adapters.
A "Provider" is a trait and not identity. In Java terms, an interface and
not a base class.


----- Original Message -----
> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> To: "Federico Simoncelli" <fsimonce at redhat.com>
> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, May 14, 2013 10:35:20 AM
> Subject: Re: [Engine-devel] What type of DB inheritance to use?
> 
> From my experience inheritance in the database is usually a bad idea all
> together.
> Fields like even if "user" and "password" fields exist in more than one
> provider type
> they shouldn't share a table as their indexes and type validation have no
> reason to be
> shared (even if they theoretically can)and it makes both suffer from forced
> standardisation.
> 
> I don't know what a "provider" is in your world but in the classic sense you
> should even
> have all providers be part of the same object inheritance as you shouldn't
> have all
> factories. A "Provider" is a function and not identity. In Java terms, and
> interface and
> not a base class.
> 
> ----- Original Message -----
> > From: "Federico Simoncelli" <fsimonce at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, May 14, 2013 3:13:30 AM
> > Subject: Re: [Engine-devel] What type of DB inheritance to use?
> > 
> > ----- Original Message -----
> > > From: "Eli Mesika" <emesika at redhat.com>
> > > To: "Liran Zelkha" <liran.zelkha at gmail.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, May 14, 2013 3:21:11 AM
> > > Subject: Re: [Engine-devel] What type of DB inheritance to use?
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Liran Zelkha" <liran.zelkha at gmail.com>
> > > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Sunday, May 12, 2013 1:19:07 PM
> > > > Subject: Re: [Engine-devel] What type of DB inheritance to use?
> > > > 
> > > > Hi
> > > > 
> > > > From my experience, single table inheritance quickly grows into
> > > > something
> > > > unmanagable, as more and more (child related) fields are added, each
> > > > line
> > > > has a few relevant attributes, and a long list of NULL values.
> > > > I would go with option 3. With materialized views, the costs of joins
> > > > can
> > > > be
> > > > eliminated.
> > > 
> > > +1
> > 
> > I'd prefer option 3 too.
> > 
> > --
> > Federico
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From djasa at redhat.com  Tue May 14 15:49:20 2013
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Tue, 14 May 2013 17:49:20 +0200
Subject: [Engine-devel] [REST-API] Support passing auth information
 without having to use HTTP Authorization header #958874
In-Reply-To: <1148533336.1301072.1368540821616.JavaMail.root@redhat.com>
References: <518751C7.8090208@redhat.com>
	<1665518752.4971723.1367945088296.JavaMail.root@redhat.com>
	<518B6C07.1080504@redhat.com>
	<1148533336.1301072.1368540821616.JavaMail.root@redhat.com>
Message-ID: <1368546560.22513.12.camel@cihla.usersys.redhat.com>

Vojtech Szocs p??e v ?t 14. 05. 2013 v 10:13 -0400:
> Hi guys,
> 
> I followed this thread, there are some interesting points, sending my comments below.
> 
> First of all, I understand that REST API should follow common REST principles, and implement additional features (such as authentication) seamlessly on top of these principles, if possible.
> 
> It's just that sometimes, especially in JavaScript/HTML world, there are known issues (limitations) for which a good REST API implementation should provide reasonable workarounds. For me, this means two things:
> (a) issue with browser-specific HTTP 'Authorization' header handling for JavaScript apps [https://bugzilla.redhat.com/958861]
> (b) issue with browser-specific cookie handling restriction for JavaScript apps [*]
> [*] long story short: JavaScript app hosted from "/myapp/index.html" cannot access cookies for say "/api" path, only for "/myapp" path, i.e. cookies are under control of browser and not JavaScript app, more details: http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path
> 
> Both issues written above have something (very important) in common: "browser-specific" + browser having control (over 'Authorization' header / cookies) instead of JavaScript app..
> 
> @Michael: is there some RFE/document for your "URI based authentication" proposal? Assuming JSESSIONID could be passed via URI, we could use this as a workaround for browser-specific cookie handling restriction. In practice, this would mean any JavaScript (WebAdmin itself, UI Plugin, any other web app) could talk to REST API without relying on cookies entirely. Even better, if we could pass auth credentials via URI, we could talk to REST API without relying on HTTP 'Authorization' header entirely.
> 
> Also, I'm not strictly against HTTP Basic Auth used in REST API, I just pointed out some of its drawbacks (a while ago). Originally, I proposed to support alternative (extra) auth scheme that is better and more secure, but in the end, I guess we should settle for one reasonably good auth scheme. I looked at SPNEGO [http://en.wikipedia.org/wiki/SPNEGO] - it looks interesting, basically a protocol for negotiating specific auth scheme based on what server supports, the question is if we really need to support multiple auth schemes, or just one that is reasonably good.

Well, there are long-standing RFEs for kerberos support to the portals so it would make sense from that POV.

David

> 
> One auth scheme I really like is [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html] - basically preventing password from being sent over the network entirely, which is always a good thing. The disadvantage is that the server has to know password ("secret key") in plain-text for the given user, in order to re-produce & compare signature (hash) of relevant request information. On the other hand, Gerrit REST API uses HTTP Digest Auth [https://gerrit-review.googlesource.com/Documentation/rest-api.html#_protocol_details] but IMHO Digest Auth is over-complicated protocol, most importantly its too complex for clients to implement.
> 
> > and this why we having this discussion, currently options are:
> > 1. adapt session based authentication
> > 2. introduce new concept
> 
> I'd vote for auth scheme that doesn't contradict general REST principles but is reasonably good (easy & secure). One thing is the auth protocol itself (HTTP Basic Auth), another is how auth-related information is transmitted between client and server (HTTP 'Authorization' header, JSESSIONID cookie) - for now I'd just proposed to revisit the "auth-related info transmission" part..
> 
> Regards,
> Vojtech
> 
> 
> ----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>, "Itamar Heim" <iheim at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Barak Azulay" <bazulay at redhat.com>
> Sent: Thursday, May 9, 2013 11:27:35 AM
> Subject: Re: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
> 
> On 05/07/2013 07:44 PM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>,
> >> "Itamar Heim" <iheim at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Monday, May 6, 2013 9:46:31 AM
> >> Subject: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
> >>
> >>
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=958874
> >>
> >> Hi Alon,
> >>
> >> (In reply to comment #2)
> >>>
> >>> Regardless of this specific RFE I would like to write that I don't like the
> >>> REST API session mechanism
> >>> [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as it
> >>> relays on cookies and not explicit API interaction.
> >>
> >> authentication in RESTful application is a matter of debate, it can be
> >> achieved
> >> in various ways, but session + cookie auth. method is very common and usually
> >> effective,
> >>
> >> it's biggest disadvantage is that it's not exactly RESfull cause client
> >> have to maintain (story) the cookie and not the server (but i wouldn't call
> >> it an
> >> issue at all), besides that it's works perfectly well from the REST PoV,
> >>
> >> also some may say that cookies are not strong enough and OAuth for instance
> >> should be used instead, but this is a different story cause in our case,
> >> cookie
> >> are for the clients (not browsers [1]) that can store them in a secure way or
> >> even
> >> not to store at all (in-memory cookie).
> >>
> >> [1] another disadvantage is that webbrowsers not able to access cookie
> >> namespace,
> >> but lately i've suggested URI based authentication [2] to support web
> >> browsers
> >> as well.
> >>
> >> [2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html
> >>
> >> the biggest advantage of the cookie is a session expiration that maintained
> >> by the server and abstracted from the client what is much better from
> >> security
> >> PoV than standard authentication mechanisms such as HTTP basic auth for
> >> instance
> >> which can be potentially cached.
> > 
> > Expiration is always managed by server side, regardless the cookie vs ticket debate.
> > 
> >>
> >>> I would have expected a
> >>> 'ticket' to be retrieved and that 'ticket' to be disconnected from the
> >>> application server objects. Although we can refer the 'cookie' as a ticket,
> >>> however the requirement to parse it should not be required, there be a
> >>> conflict between two separate applications running on same server, and
> >>> there
> >>> may be a problem to transfer credentials between servers.
> >>
> >> well, this is not exactly correct:
> >>
> >> 1. client desn't have to decode/parse the cookie and pass credentials, all it
> >> need is
> >>    just to store the cookie and pass it as is to server on every request.
> > 
> > You just described what cookies are.
> > And if I understand we want better control of application authentication, disconnected from 'default browser behavior'.
> > 
> >> 2. "conflict between two separate applications running on same server"?
> >> different cookie
> >>    uses different domain & path by spec., can you pls explain what do you
> >>    mean by this?
> > 
> > If you call the cookie JSESSIONID....
> 
> different applications cannot live under same path,
> this what for cookie has a "path" attribute,
> 
> but it can create a bit of confusion indeed, but you not
> talking with more than one application in same time right ?!,
> i.e container/client fetches the JSESSIONID cookie from the
> specific request/response,
> 
> so i'm not sure how possibly client can get in reply two
> cookies with a same name (even if all applications are using
> same cookie)
> 
> >  
> >>>
> >>> If we modify authentication we should support more authentication types, at
> >>> least SPNEGO.
> >>>
> >>> In order to allow SPNEGO and other authentication mechanisms, we better
> >>> force people to use single URI to perform the login and return
> >>> authenticated
> >>> 'ticket' to continue interaction with application.
> >>
> >> this is good for the backend authentication, but is not for the RESTful
> >> application, it's like buying an aeroplane and driving it on a road,
> > 
> > And why is that? who are you to decide what authentication mechanism is to be used by customers?
> 
> alon, you misunderstood, i'm not talking about authentication method,
> but about your sentence ^ "we better force people to use single URI"
> 
> > If customer has a policy of not transmitting passwords over the network, then SPENGO is your friend. 
> > But let's ignore it for now.
> 
> cookie is not any different from the SPENGO token in this meaning,
> it's just another data container.
> 
> > 
> >> "force people to use single URI to perform the login" means SOAP while we
> >> wanted REST
> >> where any URI is considered as entry point and actually a resource address
> >> that should
> >> be accessible/manipulatable and authentication should be
> >> abstracted/disconnected from
> >> this concept.
> > 
> > Again, you provide statements that are not written in stone.
> 
> this is main REST principal.
> 
> > Having custom authentication header breaks the 'plain simple rest'.
> > Having a URI is only makes it easier to manage this breakage.
> 
> for us, but this is breaks a REST concept.
> 
> > 
> >> SPNEGO is only an implementation detail that can be abstracted for the API.
> > 
> > I don't follow.
> > 
> >>> This will be much simpler
> >>> implementation at the api side and much more efficient, and as we are
> >>> discussion application-to-application interaction there should be no user
> >>> experience visible issues.
> >>
> >> i'm not sure: "force people to use single URI to perform the login" and no
> >> "no user experience visible issues."?
> > 
> > Please describe how the prefer mechanism suggested can be implemented in standard browser.
> 
> it cannot because authorization header has to be supplied only when
> client wishes to reinitialize the JSESSION, and web browsers can't omit
> it during the lifetime.
> 
> all this cause we don't support web browsers in api yet, session based
> authentication mechanism was designed for http clients,
> 
> and this why we having this discussion, currently options are:
> 
> 1. adapt session based authentication
> 2. introduce new concept
> 
> personally i prefer #1 as it's less noisy and easily achievable.
> 
> > And if it cannot, and custom logic is required, why a custom logic that accesses a custom URI to perform login is any different.
> 
> it's not RESTful
> 
> >  
> >>>
> >>> What I recommend is purely applicative rest login command...
> >>
> >> IIUC this is SOAP and not REST ...
> > 
> > Again... please refrain from these kind of void statements.
> > SOAP is a protocol, it has specific format and rules.
> > It may or may not use this or any other suggested authentication mechanism.
> 
> i'm not talking about the protocol, but about the conceptual differences
> between SOAP and REST services.
> 
> SOAP is a RPC (Remote Procedure Call) and has single entry point on which
> different methods are invoked, having single dedicated method for login
> works in this case,
> 
> REST is a ROA (Resource Oriented Architecture), i.e everything is REST is a
> resource, and you have to operate on these resources, authentication is only
> an implementation detail that should not break this concept.
> 
> now saying this i think is clear that you have no place to put at the login()
> method you've mentioned,
> 
> standard way for authentication in REST/HTTP is via 'authorization' header (per request),
> optimizing this we've introduced new concept via sessionid,
> 
> user can choose between two by passing 'prefer:persistent_auth' header,
> 
> hope it's clear now, please let me know otherwise.
> 
> >  
> >>> ---
> >>> Input: authentication type, authentication credentials
> >>>     authentication=http
> >>>     authentication=password
> >>>     credentials:
> >>>         user=user
> >>>         password=password
> >>>     [OPTIONALLY] HTTP authentication headers
> >>> Output:
> >>>     ticket
> >>>     ticket issue time (required to avoid clock sync)
> >>>     ticket expiration time
> >>> Logic:
> >>> if authentication is http, use http authentication headers to establish
> >>> user
> >>> authentication. This will allow future SSO.
> >>> if authentication is password, use embedded credentials.
> >>> ---
> >>>
> >>> For every other rest call add http header:
> >>>     oVirt-Authentication-Ticket: <ticket>
> >>
> >> this is not any different from the today's session based auth. only
> >> instead of  oVirt-Authentication-Ticket added cookie.
> > 
> > I did not claim otherwise, I wrote that I don't like cookies, I do like explicit headers.
> > As I wrote, cookies has limited storage at client, cookies may conflict, cookies has issues with clusters.
> > Headers do not.
> 
> using headers has own drawbacks, WebAdmin core is not only entity that
> requires authentication in the app, i'll give you one use-case:
> 
> today we have plugin interface in WebAdmin, WebAdmin may have different
> plugins installed, to maintain different permissions for every plugin,
> each will have to send own authorization data on every request,
> 
> as you see this turns to be truly complex, almost not feasible via headers,
> 
> btw in other thread i suggested to used URL parameters for passing authentication
> tokens.
> 
> > 
> >>>
> >>> The backend side will attach the correct security context to the action if
> >>> the header is received.
> >>
> >> this is how it's works today.
> > 
> > I could not imagine that.
> >  
> > 
> > Regards,
> > Alon
> > 
> 
> 

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3790 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130514/5d5b26c4/attachment.bin>

From vszocs at redhat.com  Tue May 14 16:11:34 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 14 May 2013 12:11:34 -0400 (EDT)
Subject: [Engine-devel] UI Plugins: issue with REST API keep-alive
 heartbeat	fixed
In-Reply-To: <1733305282.1046497.1368475859539.JavaMail.root@redhat.com>
References: <1013558570.627274.1368455010052.JavaMail.root@redhat.com>
	<1733305282.1046497.1368475859539.JavaMail.root@redhat.com>
Message-ID: <95753864.1408339.1368547894563.JavaMail.root@redhat.com>

Thanks Einav, just realized I forgot to add [2] link to my email :)

Vojtech


----- Original Message -----
From: "Einav Cohen" <ecohen at redhat.com>
To: "Vojtech Szocs" <vszocs at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>, "Christopher Morrissey" <christopher.morrissey at netapp.com>
Sent: Monday, May 13, 2013 10:10:59 PM
Subject: Re: [Engine-devel] UI Plugins: issue with REST API keep-alive heartbeat	fixed

> ----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> Sent: Monday, May 13, 2013 10:23:30 AM
> 
> Hi guys,
> 
> just a quick update, recently we fixed an issue [1] with UI Plugin REST API
> integration trying to keep-alive the current REST API session, which was
> causing repeated "User logged in" events in GUI, along with new REST API
> session created each time the heartbeat request was fired. Please refer to
> commit message for more details on this issue.
> 
> There are some things to be aware of with regard to UI Plugin REST API
> integration:
> - all plugins still receive a single session ID based on WebAdmin user
> credentials, i.e. keep the current "single-admin-session-for-all-plugins"
> behavior
> - session timeout is set to 6 hours --> 2x more than default REST API session
> timeout
> - WebAdmin will *not* try to keep-alive the session via periodic heartbeat
> requests, i.e. break the current
> "keep-session-alive-while-user-stays-authenticated" behavior
> 
> In practice, this means that after a user logs into WebAdmin, if no plugin
> interacts with the REST API session via provided ID for more than 6 hours,
> the session will time-out eventually. Unfortunately, for now, we can't
> support the session keep-alive mechanism due to issues with HTTP
> 'Authorization' header handling in web browsers, but with RFE [2] it would
> be possible to re-implement the session keep-alive mechanism.
> 
> On the other hand, we'll most likely revisit the current
> "single-admin-session-for-all-plugins" behavior in future, i.e. have special
> Engine users created for use with UI Plugin REST API integration, with
> permissions of such users under control by the admin. This would change the
> current behavior to something like "separate-user-session-for-each-plugin",
> with individual plugins able to create their own REST API session on demand.
> 
> Regards,
> Vojtech
> 
> [1] http://gerrit.ovirt.org/#/c/14411/

Thanks, Vojtech - just adding the missing RFE reference ([2]):
[2] Bug 958861 - Support passing auth information without having to use HTTP Authorization header
[https://bugzilla.redhat.com/show_bug.cgi?id=958861]



From yzaslavs at redhat.com  Wed May 15 04:56:50 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 15 May 2013 00:56:50 -0400 (EDT)
Subject: [Engine-devel] Engine config and device custom properties
In-Reply-To: <1070389200.1303205.1368522854792.JavaMail.root@redhat.com>
References: <99189519.1184200.1368517862249.JavaMail.root@redhat.com>
	<1070389200.1303205.1368522854792.JavaMail.root@redhat.com>
Message-ID: <962495686.1499731.1368593810846.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Martin Perina" <mperina at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, May 14, 2013 12:14:14 PM
> Subject: Re: [Engine-devel] Engine config and device custom properties
> 
> Hi Martin,
> 
> By looking at the code - there seems no validator for the format provided
> by the user for the UserDefinedVMProperties.
> 
> It seems that the engine will write an exception to log specifying the format
> is invalid,
> as the format is being validated during engine startup by
> InitBackendServicesOnStartupBean.create() which invokes
> VmPropertiesUtils.getInstance().init()
> 
> Therefore there is a need to validate the format in earlier stage, when
> setting the values
> for the properties via the engine-config.
> 
> 1. Extend the engine-config value helpers with a new type:
> DevicePropertiesValueHelper extends
> org.ovirt.engine.core.config.entity.helper.ValueHelper
> and also a compliant DevicePropertiesValueHelperTest
> 
> 2. DevicePropertiesValueHelper.validate() should reuse the parsing logic of
> the device properties
> from VmPropertiesUtils.parseVMPropertiesRegex()
> 
> 3. Define the value helper for you new property in
> packaging/etc/engine-config/engine-config.properties:
> 
> CustomDeviceProperties.description="your description"
> CustomDeviceProperties.type=DevicePropertiesValueHelper
> 
> You the new install-dev to easily test you changes.
> 
> Regards,
> Moti

Moti gave a very good explanation.
Actually , the very first question should have been - would we like to have this configurable via engine config?
Are we going to defined a predefine set (i.e - in case of SAPAgent af predefined vm custom properties) or not.
I actually now think we should go for this.
Martin, the new value helper will not be able to validate on a specific key=value pair - the user will have to pass the entire string each time he changes this config value.
Moti - any comments here?

Anyway, this change can be done in parallel to Moti's work on custom device properties from network side (he will fill relevant values manually in the vdc_options table).

Yair

> 
> ----- Original Message -----
> > From: "Martin Perina" <mperina at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, May 14, 2013 10:51:02 AM
> > Subject: [Engine-devel] Engine config and device custom properties
> > 
> > Hi,
> > 
> > I'm working on a patch to support custom device properties in ovirt-engine.
> > I would like that custom device properties format can be set using
> > engine-config
> > command in a similar way as UserDefinedVMProperties. What is needed to be
> > done
> > to support this?
> > 
> > Thanks
> > 
> > Martin
> > _______________________________________________
> > 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 vszocs at redhat.com  Wed May 15 12:03:55 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 15 May 2013 08:03:55 -0400 (EDT)
Subject: [Engine-devel] [REST-API] Support passing auth information
 without having to use HTTP Authorization header #958874
In-Reply-To: <1368546560.22513.12.camel@cihla.usersys.redhat.com>
References: <518751C7.8090208@redhat.com>
	<1665518752.4971723.1367945088296.JavaMail.root@redhat.com>
	<518B6C07.1080504@redhat.com>
	<1148533336.1301072.1368540821616.JavaMail.root@redhat.com>
	<1368546560.22513.12.camel@cihla.usersys.redhat.com>
Message-ID: <1971345042.1984194.1368619435693.JavaMail.root@redhat.com>

Hi David,

> Well, there are long-standing RFEs for kerberos support to the portals so it would make sense from that POV.

Yeah, if we should support extra auth schemes like kerberos, in addition to existing auth scheme in REST API, SPNEGO makes sense in that case..

Vojech


----- Original Message -----
From: "David Ja?a" <djasa at redhat.com>
To: "engine-devel" <engine-devel at ovirt.org>
Sent: Tuesday, May 14, 2013 5:49:20 PM
Subject: Re: [Engine-devel] [REST-API] Support passing auth information without having to use HTTP Authorization header #958874

Vojtech Szocs p??e v ?t 14. 05. 2013 v 10:13 -0400:
> Hi guys,
> 
> I followed this thread, there are some interesting points, sending my comments below.
> 
> First of all, I understand that REST API should follow common REST principles, and implement additional features (such as authentication) seamlessly on top of these principles, if possible.
> 
> It's just that sometimes, especially in JavaScript/HTML world, there are known issues (limitations) for which a good REST API implementation should provide reasonable workarounds. For me, this means two things:
> (a) issue with browser-specific HTTP 'Authorization' header handling for JavaScript apps [https://bugzilla.redhat.com/958861]
> (b) issue with browser-specific cookie handling restriction for JavaScript apps [*]
> [*] long story short: JavaScript app hosted from "/myapp/index.html" cannot access cookies for say "/api" path, only for "/myapp" path, i.e. cookies are under control of browser and not JavaScript app, more details: http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path
> 
> Both issues written above have something (very important) in common: "browser-specific" + browser having control (over 'Authorization' header / cookies) instead of JavaScript app..
> 
> @Michael: is there some RFE/document for your "URI based authentication" proposal? Assuming JSESSIONID could be passed via URI, we could use this as a workaround for browser-specific cookie handling restriction. In practice, this would mean any JavaScript (WebAdmin itself, UI Plugin, any other web app) could talk to REST API without relying on cookies entirely. Even better, if we could pass auth credentials via URI, we could talk to REST API without relying on HTTP 'Authorization' header entirely.
> 
> Also, I'm not strictly against HTTP Basic Auth used in REST API, I just pointed out some of its drawbacks (a while ago). Originally, I proposed to support alternative (extra) auth scheme that is better and more secure, but in the end, I guess we should settle for one reasonably good auth scheme. I looked at SPNEGO [http://en.wikipedia.org/wiki/SPNEGO] - it looks interesting, basically a protocol for negotiating specific auth scheme based on what server supports, the question is if we really need to support multiple auth schemes, or just one that is reasonably good.

Well, there are long-standing RFEs for kerberos support to the portals so it would make sense from that POV.

David

> 
> One auth scheme I really like is [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html] - basically preventing password from being sent over the network entirely, which is always a good thing. The disadvantage is that the server has to know password ("secret key") in plain-text for the given user, in order to re-produce & compare signature (hash) of relevant request information. On the other hand, Gerrit REST API uses HTTP Digest Auth [https://gerrit-review.googlesource.com/Documentation/rest-api.html#_protocol_details] but IMHO Digest Auth is over-complicated protocol, most importantly its too complex for clients to implement.
> 
> > and this why we having this discussion, currently options are:
> > 1. adapt session based authentication
> > 2. introduce new concept
> 
> I'd vote for auth scheme that doesn't contradict general REST principles but is reasonably good (easy & secure). One thing is the auth protocol itself (HTTP Basic Auth), another is how auth-related information is transmitted between client and server (HTTP 'Authorization' header, JSESSIONID cookie) - for now I'd just proposed to revisit the "auth-related info transmission" part..
> 
> Regards,
> Vojtech
> 
> 
> ----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>, "Itamar Heim" <iheim at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Barak Azulay" <bazulay at redhat.com>
> Sent: Thursday, May 9, 2013 11:27:35 AM
> Subject: Re: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
> 
> On 05/07/2013 07:44 PM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>,
> >> "Itamar Heim" <iheim at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Monday, May 6, 2013 9:46:31 AM
> >> Subject: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
> >>
> >>
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=958874
> >>
> >> Hi Alon,
> >>
> >> (In reply to comment #2)
> >>>
> >>> Regardless of this specific RFE I would like to write that I don't like the
> >>> REST API session mechanism
> >>> [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as it
> >>> relays on cookies and not explicit API interaction.
> >>
> >> authentication in RESTful application is a matter of debate, it can be
> >> achieved
> >> in various ways, but session + cookie auth. method is very common and usually
> >> effective,
> >>
> >> it's biggest disadvantage is that it's not exactly RESfull cause client
> >> have to maintain (story) the cookie and not the server (but i wouldn't call
> >> it an
> >> issue at all), besides that it's works perfectly well from the REST PoV,
> >>
> >> also some may say that cookies are not strong enough and OAuth for instance
> >> should be used instead, but this is a different story cause in our case,
> >> cookie
> >> are for the clients (not browsers [1]) that can store them in a secure way or
> >> even
> >> not to store at all (in-memory cookie).
> >>
> >> [1] another disadvantage is that webbrowsers not able to access cookie
> >> namespace,
> >> but lately i've suggested URI based authentication [2] to support web
> >> browsers
> >> as well.
> >>
> >> [2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html
> >>
> >> the biggest advantage of the cookie is a session expiration that maintained
> >> by the server and abstracted from the client what is much better from
> >> security
> >> PoV than standard authentication mechanisms such as HTTP basic auth for
> >> instance
> >> which can be potentially cached.
> > 
> > Expiration is always managed by server side, regardless the cookie vs ticket debate.
> > 
> >>
> >>> I would have expected a
> >>> 'ticket' to be retrieved and that 'ticket' to be disconnected from the
> >>> application server objects. Although we can refer the 'cookie' as a ticket,
> >>> however the requirement to parse it should not be required, there be a
> >>> conflict between two separate applications running on same server, and
> >>> there
> >>> may be a problem to transfer credentials between servers.
> >>
> >> well, this is not exactly correct:
> >>
> >> 1. client desn't have to decode/parse the cookie and pass credentials, all it
> >> need is
> >>    just to store the cookie and pass it as is to server on every request.
> > 
> > You just described what cookies are.
> > And if I understand we want better control of application authentication, disconnected from 'default browser behavior'.
> > 
> >> 2. "conflict between two separate applications running on same server"?
> >> different cookie
> >>    uses different domain & path by spec., can you pls explain what do you
> >>    mean by this?
> > 
> > If you call the cookie JSESSIONID....
> 
> different applications cannot live under same path,
> this what for cookie has a "path" attribute,
> 
> but it can create a bit of confusion indeed, but you not
> talking with more than one application in same time right ?!,
> i.e container/client fetches the JSESSIONID cookie from the
> specific request/response,
> 
> so i'm not sure how possibly client can get in reply two
> cookies with a same name (even if all applications are using
> same cookie)
> 
> >  
> >>>
> >>> If we modify authentication we should support more authentication types, at
> >>> least SPNEGO.
> >>>
> >>> In order to allow SPNEGO and other authentication mechanisms, we better
> >>> force people to use single URI to perform the login and return
> >>> authenticated
> >>> 'ticket' to continue interaction with application.
> >>
> >> this is good for the backend authentication, but is not for the RESTful
> >> application, it's like buying an aeroplane and driving it on a road,
> > 
> > And why is that? who are you to decide what authentication mechanism is to be used by customers?
> 
> alon, you misunderstood, i'm not talking about authentication method,
> but about your sentence ^ "we better force people to use single URI"
> 
> > If customer has a policy of not transmitting passwords over the network, then SPENGO is your friend. 
> > But let's ignore it for now.
> 
> cookie is not any different from the SPENGO token in this meaning,
> it's just another data container.
> 
> > 
> >> "force people to use single URI to perform the login" means SOAP while we
> >> wanted REST
> >> where any URI is considered as entry point and actually a resource address
> >> that should
> >> be accessible/manipulatable and authentication should be
> >> abstracted/disconnected from
> >> this concept.
> > 
> > Again, you provide statements that are not written in stone.
> 
> this is main REST principal.
> 
> > Having custom authentication header breaks the 'plain simple rest'.
> > Having a URI is only makes it easier to manage this breakage.
> 
> for us, but this is breaks a REST concept.
> 
> > 
> >> SPNEGO is only an implementation detail that can be abstracted for the API.
> > 
> > I don't follow.
> > 
> >>> This will be much simpler
> >>> implementation at the api side and much more efficient, and as we are
> >>> discussion application-to-application interaction there should be no user
> >>> experience visible issues.
> >>
> >> i'm not sure: "force people to use single URI to perform the login" and no
> >> "no user experience visible issues."?
> > 
> > Please describe how the prefer mechanism suggested can be implemented in standard browser.
> 
> it cannot because authorization header has to be supplied only when
> client wishes to reinitialize the JSESSION, and web browsers can't omit
> it during the lifetime.
> 
> all this cause we don't support web browsers in api yet, session based
> authentication mechanism was designed for http clients,
> 
> and this why we having this discussion, currently options are:
> 
> 1. adapt session based authentication
> 2. introduce new concept
> 
> personally i prefer #1 as it's less noisy and easily achievable.
> 
> > And if it cannot, and custom logic is required, why a custom logic that accesses a custom URI to perform login is any different.
> 
> it's not RESTful
> 
> >  
> >>>
> >>> What I recommend is purely applicative rest login command...
> >>
> >> IIUC this is SOAP and not REST ...
> > 
> > Again... please refrain from these kind of void statements.
> > SOAP is a protocol, it has specific format and rules.
> > It may or may not use this or any other suggested authentication mechanism.
> 
> i'm not talking about the protocol, but about the conceptual differences
> between SOAP and REST services.
> 
> SOAP is a RPC (Remote Procedure Call) and has single entry point on which
> different methods are invoked, having single dedicated method for login
> works in this case,
> 
> REST is a ROA (Resource Oriented Architecture), i.e everything is REST is a
> resource, and you have to operate on these resources, authentication is only
> an implementation detail that should not break this concept.
> 
> now saying this i think is clear that you have no place to put at the login()
> method you've mentioned,
> 
> standard way for authentication in REST/HTTP is via 'authorization' header (per request),
> optimizing this we've introduced new concept via sessionid,
> 
> user can choose between two by passing 'prefer:persistent_auth' header,
> 
> hope it's clear now, please let me know otherwise.
> 
> >  
> >>> ---
> >>> Input: authentication type, authentication credentials
> >>>     authentication=http
> >>>     authentication=password
> >>>     credentials:
> >>>         user=user
> >>>         password=password
> >>>     [OPTIONALLY] HTTP authentication headers
> >>> Output:
> >>>     ticket
> >>>     ticket issue time (required to avoid clock sync)
> >>>     ticket expiration time
> >>> Logic:
> >>> if authentication is http, use http authentication headers to establish
> >>> user
> >>> authentication. This will allow future SSO.
> >>> if authentication is password, use embedded credentials.
> >>> ---
> >>>
> >>> For every other rest call add http header:
> >>>     oVirt-Authentication-Ticket: <ticket>
> >>
> >> this is not any different from the today's session based auth. only
> >> instead of  oVirt-Authentication-Ticket added cookie.
> > 
> > I did not claim otherwise, I wrote that I don't like cookies, I do like explicit headers.
> > As I wrote, cookies has limited storage at client, cookies may conflict, cookies has issues with clusters.
> > Headers do not.
> 
> using headers has own drawbacks, WebAdmin core is not only entity that
> requires authentication in the app, i'll give you one use-case:
> 
> today we have plugin interface in WebAdmin, WebAdmin may have different
> plugins installed, to maintain different permissions for every plugin,
> each will have to send own authorization data on every request,
> 
> as you see this turns to be truly complex, almost not feasible via headers,
> 
> btw in other thread i suggested to used URL parameters for passing authentication
> tokens.
> 
> > 
> >>>
> >>> The backend side will attach the correct security context to the action if
> >>> the header is received.
> >>
> >> this is how it's works today.
> > 
> > I could not imagine that.
> >  
> > 
> > Regards,
> > Alon
> > 
> 
> 

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24



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


From snmishra at linux.vnet.ibm.com  Wed May 15 20:28:31 2013
From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com)
Date: Wed, 15 May 2013 13:28:31 -0700
Subject: [Engine-devel] [ANN] New development environment for
 ovirt-engine
In-Reply-To: <545E4A23-4E49-478F-B8E8-FBB7488C22ED@redhat.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<545E4A23-4E49-478F-B8E8-FBB7488C22ED@redhat.com>
Message-ID: <20130515132831.Horde.D99wiJir309Rk_-v8oDzbjA@imap.linux.ibm.com>

Has anyone tried using this setup with eclipse and running jboss  
server from eclipse?

Thanks
Sharad Mishra

Quoting Barak Azulay <bazulay at redhat.com>:

> Good work guys,
>
> Thanks
> Barak Azulay
>
>
>
> On May 12, 2013, at 14:52, Alon Bar-Lev <alonbl at redhat.com> wrote:
>
>> Hello all ovirt-engine developers,
>>
>> When I first joined the ovirt project, it took me about two weeks  
>> to setup a development environment, I needed to work on a bug  
>> related to host-deploy so I needed an environment that could use  
>> the ssh, PKI, vdsm-bootstrap and communicate with vdsm using SSL,  
>> this was virtually impossible to do so without tweaking the product  
>> in a way that it is so different from production use, that I cannot  
>> guarantee that whatever tested in development will actually work in  
>> production.
>>
>> I peeked at the installation script in a hope that I can create  
>> partial environment similar to production, but I found that the  
>> packaging implementation makes to much assumption and is very  
>> difficult to adopt. The fact that I do not use fedora/rhel for my  
>> development made it even worse.
>>
>> I had no other option than to create rpms after each of my changes  
>> and test each in real production like setup.
>>
>> It was obvious to me that the manual customization of developers to  
>> achieve working product will eventually break as product grow and  
>> move away from being developer friendly to production friendly. For  
>> example, product defaults cannot be these which serve developers,  
>> but these which serve production the best, or having a valid PKI  
>> setup cannot be optional any more as components do need to use it.  
>> Same for location of files and configuration, for example, if we  
>> write a pluggable infrastructure for branding, we cannot damage the  
>> interface just because developers runs the product in their own  
>> manual customization.
>>
>> I took the opportunity handed to me to port the ovirt-engine to  
>> other distributions in order to provide a development environment  
>> that is similar to production setup. Together with Sandro Bonazzola  
>> and Alex Lourie we re-wrote the whole installation of the product  
>> which can also be used to setup the desired development environment.
>>
>> Within this environment the product is set up using the same tools  
>> and configuration as in production, while the process does not  
>> require special privileges nor changes the state of the developer  
>> machine.
>>
>> A complete documentation is available[1], I preferred to use README  
>> within the source tree as wiki tend to quickly become obsolete,  
>> while documentation within source tree can be modified by the  
>> commit that introduces a change. I will redirect to this file from  
>> the current wiki once the site will be up.
>>
>> In a nut shell, after installing prerequisites, build and install  
>> the product using:
>>
>> $ make clean install-dev PREFIX=$HOME/ovirt-engine
>>
>> This will run maven and create product installation at $HOME/ovirt-engine
>> Next, a setup phase is required just like in production, to  
>> initialize configuration and database:
>>
>> $ $HOME/ovirt-engine/bin/engine-setup-2
>>
>> You have now fully functional product, including PKI, SSL,  
>> host-deploy, tools.
>> No manual database updates are required, no lose of functionality.
>>
>> All that is left is to start the engine service:
>>
>> $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
>>
>> Access to application:
>>   http://localhost:8080
>>   https://localhost:8443
>> Debugging port is opened at port 8787.
>>
>> Farther information exists in the documentation[1].
>>
>> There are several inherit benefits of the new environment, the  
>> major one is the ability to manage several environments in parallel  
>> on the same host. For example, if we develop two separate features  
>> on two branches we can install the product into  
>> $HOME/ovirt-engine-feature1 and $HOME/ovirt-engine-feature-2 and  
>> have a separate database for each, if we modify the ports jboss is  
>> listening to we can run two instances of engine at the same time!
>>
>> We will be happy to work with all developers to assist in porting  
>> into the new development environment, the simplest is to create a  
>> new database for this effort. Moti has a sequence of converting the  
>> existing database owned by postgres to be owned by the engine,  
>> Moti, can you please share that?
>>
>> We are sure there are missing bits, we will be happy to know these  
>> so we can improve.
>>
>> I am aware that developers (especially java) are conservative, but  
>> I ask you to give us a chance, so that we make it easy for  
>> developers to join the project, and to allow us to drop the  
>> parallel effort of packaging to production and fixing the broken  
>> development environment.
>>
>> A special thanks to developers who took the time to test and  
>> provide feedback before the merged:
>> - Yaniv Bronheim
>> - Moti Asayag
>> - Limor Gavish
>> - Sharad Mishra
>> - Ofer Schreiber
>>
>> We are hoping that after migration you will be find this  
>> environment useful and friendly,
>>
>> Sandro Bonazzola,
>> Alex Lourie,
>> Alon Bar-Lev.
>>
>> [1]  
>> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel





From alonbl at redhat.com  Wed May 15 20:45:10 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 15 May 2013 16:45:10 -0400 (EDT)
Subject: [Engine-devel] [ANN] New development environment for
 ovirt-engine
In-Reply-To: <20130515132831.Horde.D99wiJir309Rk_-v8oDzbjA@imap.linux.ibm.com>
References: <9423451.273926.1368359571790.JavaMail.root@redhat.com>
	<545E4A23-4E49-478F-B8E8-FBB7488C22ED@redhat.com>
	<20130515132831.Horde.D99wiJir309Rk_-v8oDzbjA@imap.linux.ibm.com>
Message-ID: <1451057414.1569592.1368650710979.JavaMail.root@redhat.com>



----- Original Message -----
> From: snmishra at linux.vnet.ibm.com
> To: engine-devel at ovirt.org
> Sent: Wednesday, May 15, 2013 11:28:31 PM
> Subject: Re: [Engine-devel] [ANN] New development environment for ovirt-engine
> 
> Has anyone tried using this setup with eclipse and running jboss
> server from eclipse?

You probably don't need that.
You can have eclipse connect to the running service using debug port at localhost:8787

> 
> Thanks
> Sharad Mishra
> 
> Quoting Barak Azulay <bazulay at redhat.com>:
> 
> > Good work guys,
> >
> > Thanks
> > Barak Azulay
> >
> >
> >
> > On May 12, 2013, at 14:52, Alon Bar-Lev <alonbl at redhat.com> wrote:
> >
> >> Hello all ovirt-engine developers,
> >>
> >> When I first joined the ovirt project, it took me about two weeks
> >> to setup a development environment, I needed to work on a bug
> >> related to host-deploy so I needed an environment that could use
> >> the ssh, PKI, vdsm-bootstrap and communicate with vdsm using SSL,
> >> this was virtually impossible to do so without tweaking the product
> >> in a way that it is so different from production use, that I cannot
> >> guarantee that whatever tested in development will actually work in
> >> production.
> >>
> >> I peeked at the installation script in a hope that I can create
> >> partial environment similar to production, but I found that the
> >> packaging implementation makes to much assumption and is very
> >> difficult to adopt. The fact that I do not use fedora/rhel for my
> >> development made it even worse.
> >>
> >> I had no other option than to create rpms after each of my changes
> >> and test each in real production like setup.
> >>
> >> It was obvious to me that the manual customization of developers to
> >> achieve working product will eventually break as product grow and
> >> move away from being developer friendly to production friendly. For
> >> example, product defaults cannot be these which serve developers,
> >> but these which serve production the best, or having a valid PKI
> >> setup cannot be optional any more as components do need to use it.
> >> Same for location of files and configuration, for example, if we
> >> write a pluggable infrastructure for branding, we cannot damage the
> >> interface just because developers runs the product in their own
> >> manual customization.
> >>
> >> I took the opportunity handed to me to port the ovirt-engine to
> >> other distributions in order to provide a development environment
> >> that is similar to production setup. Together with Sandro Bonazzola
> >> and Alex Lourie we re-wrote the whole installation of the product
> >> which can also be used to setup the desired development environment.
> >>
> >> Within this environment the product is set up using the same tools
> >> and configuration as in production, while the process does not
> >> require special privileges nor changes the state of the developer
> >> machine.
> >>
> >> A complete documentation is available[1], I preferred to use README
> >> within the source tree as wiki tend to quickly become obsolete,
> >> while documentation within source tree can be modified by the
> >> commit that introduces a change. I will redirect to this file from
> >> the current wiki once the site will be up.
> >>
> >> In a nut shell, after installing prerequisites, build and install
> >> the product using:
> >>
> >> $ make clean install-dev PREFIX=$HOME/ovirt-engine
> >>
> >> This will run maven and create product installation at $HOME/ovirt-engine
> >> Next, a setup phase is required just like in production, to
> >> initialize configuration and database:
> >>
> >> $ $HOME/ovirt-engine/bin/engine-setup-2
> >>
> >> You have now fully functional product, including PKI, SSL,
> >> host-deploy, tools.
> >> No manual database updates are required, no lose of functionality.
> >>
> >> All that is left is to start the engine service:
> >>
> >> $ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
> >>
> >> Access to application:
> >>   http://localhost:8080
> >>   https://localhost:8443
> >> Debugging port is opened at port 8787.
> >>
> >> Farther information exists in the documentation[1].
> >>
> >> There are several inherit benefits of the new environment, the
> >> major one is the ability to manage several environments in parallel
> >> on the same host. For example, if we develop two separate features
> >> on two branches we can install the product into
> >> $HOME/ovirt-engine-feature1 and $HOME/ovirt-engine-feature-2 and
> >> have a separate database for each, if we modify the ports jboss is
> >> listening to we can run two instances of engine at the same time!
> >>
> >> We will be happy to work with all developers to assist in porting
> >> into the new development environment, the simplest is to create a
> >> new database for this effort. Moti has a sequence of converting the
> >> existing database owned by postgres to be owned by the engine,
> >> Moti, can you please share that?
> >>
> >> We are sure there are missing bits, we will be happy to know these
> >> so we can improve.
> >>
> >> I am aware that developers (especially java) are conservative, but
> >> I ask you to give us a chance, so that we make it easy for
> >> developers to join the project, and to allow us to drop the
> >> parallel effort of packaging to production and fixing the broken
> >> development environment.
> >>
> >> A special thanks to developers who took the time to test and
> >> provide feedback before the merged:
> >> - Yaniv Bronheim
> >> - Moti Asayag
> >> - Limor Gavish
> >> - Sharad Mishra
> >> - Ofer Schreiber
> >>
> >> We are hoping that after migration you will be find this
> >> environment useful and friendly,
> >>
> >> Sandro Bonazzola,
> >> Alex Lourie,
> >> Alon Bar-Lev.
> >>
> >> [1]
> >> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD
> >> _______________________________________________
> >> Arch mailing list
> >> Arch at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/arch
> >>
> >>
> > _______________________________________________
> > 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 ahadas at redhat.com  Thu May 16 09:41:08 2013
From: ahadas at redhat.com (Arik Hadas)
Date: Thu, 16 May 2013 05:41:08 -0400 (EDT)
Subject: [Engine-devel] Snapshots with RAM feature
In-Reply-To: <319368954.768893.1365494496958.JavaMail.root@redhat.com>
References: <319368954.768893.1365494496958.JavaMail.root@redhat.com>
Message-ID: <209661119.2153467.1368697268988.JavaMail.root@redhat.com>

Hi All,

The feature's wiki page has been massively updated
(http://www.ovirt.org/Features/RAM_Snapshots)

Major changes:

1. Withdraw the option of using the saved memory from snapshot when creating
a VM from snapshot as the initial memory state of the VM, as it turned out that
the VM configuration is stored inside the memory file.

2. Simplified the API between the engine and VDSM: using comma-separated string
to represent the memory volume (which can be empty) instead of map with 'mode'
and pool-domain-image-volume quartet values.

Again, All feedback is welcome!

Regards,
Arik

----- Original Message -----
> Hi All,
> 
> The proposed feature will make it possible to run a VM which was reverted to
> live snapshot
> or created from live snapshot with the same memory state as it was at the
> moment the live
> snapshot was taken.
> 
> http://www.ovirt.org/Features/RAM_Snapshots
> 
> All feedback is welcome!
> 
> Regards,
> Arik
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From deadhorseconsulting at gmail.com  Thu May 16 14:31:23 2013
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Thu, 16 May 2013 09:31:23 -0500
Subject: [Engine-devel] cannot attach ISO with latest master
In-Reply-To: <CAEWPe=rogGmX_OBNb2f=aMuYucgUqYKiyksDEr75wxfME6uLYQ@mail.gmail.com>
References: <CAEWPe=rogGmX_OBNb2f=aMuYucgUqYKiyksDEr75wxfME6uLYQ@mail.gmail.com>
Message-ID: <CAEWPe=qOXj6oXDb3G=naXFjBH_asHcConWrOJN0wi96CEmgKEg@mail.gmail.com>

This occurs only when using "Run Once" to attach an ISO to a VM.
It is still present in master as of this morning.
It was reported recently by another user on the user list as well.
- DHC


On Mon, May 13, 2013 at 4:47 PM, Dead Horse
<deadhorseconsulting at gmail.com>wrote:

> Cannot attach images from the iso storage domain with latest master.
> VDSM version is latest master as well
> Host = EL6.4
>
> 2013-05-13 16:41:02,184 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
> (ajp--127.0.0.1-8702-7) [5d889258] START, IsoPrefixVDSCommand(
> storagePoolId = 0cba78bd-f1b7-438f-afac-acd59fab92ae, ignoreFailoverLimit =
> false, compatabilityVersion = null), log id: a85d3c0
> 2013-05-13 16:41:02,196 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
> (ajp--127.0.0.1-8702-7) [5d889258] FINISH, IsoPrefixVDSCommand, return:
> /rhev/data-center/mnt/192.168.0.1:_ovirt_dalaran/d6276dc3-1714-4024-9b70-b7971ed5fe35/images/11111111-1111-1111-1111-111111111111,
> log id: a85d3c0
> 2013-05-13 16:41:02,328 WARN  [org.ovirt.engine.core.bll.RunVmOnceCommand]
> (ajp--127.0.0.1-8702-7) [5d889258] CanDoAction of action RunVmOnce failed.
> Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH
>
> - DHC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130516/78acc633/attachment.html>

From yzaslavs at redhat.com  Thu May 16 15:59:25 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Thu, 16 May 2013 11:59:25 -0400 (EDT)
Subject: [Engine-devel] [ANN] Development environment and Gentoo
 packaging	(preview)
In-Reply-To: <1822214342.9928213.1364513864623.JavaMail.root@redhat.com>
References: <1822214342.9928213.1364513864623.JavaMail.root@redhat.com>
Message-ID: <299488600.2743118.1368719965849.JavaMail.root@redhat.com>

Wanted to point out that today I completed setting up the env.
I checked engine-config and manage-domains.
We found two issues (worked on Alon's env - not on mine) and now all is fixed and merged upstream.

Alon - many thanks on this !! as someone who works on tools, you're really making my life easier!!

Yair


----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, March 29, 2013 1:37:44 AM
> Subject: [Engine-devel] [ANN] Development environment and Gentoo packaging	(preview)
> 
> Hello All,
> 
> We[1] are working to rewrite the current installer to something more portable
> and flexible.
> 
> Currently two milestones had been reached:
> 1. Ability to install almost fully functioning ovirt-engine at $HOME for
> development environment.
> 2. Porting ovirt-engine to run on different distribution, Gentoo.
> 
> We will be glad to receive feedback on either.
> 
> Code is located at github[2] for now, at otopi branch.
> 
> Instructions for setting up development environment are available[3].
> 
> Gentoo overlay for live ebuilds is available[4], the following packages are
> valid:
>  - app-emulation/otopi
>  - app-emulation/ovirt-host-deploy
>  - app-emulation/ovirt-jboss-bin
>  - app-emulation/ovirt-engine
> 
> Why Gentoo first? because source based distributions demands the highest
> level of customization, solving the complex issue ease to continue porting
> to binary based distributions.
> 
> Please remember that this is work in progress, and not guarantee to be stable
> or even work... The installer was re-written from scratch so expect issues
> at this point.
> 
> Any feedback is welcomed, we are focusing first in providing the
> functionality of the existing installer to be able to replace it entirely
> before going into new adventures.
> 
> Regards,
> Alon Bar-Lev.
> 
> [1] Alex Lourie, Sandro Bonazzola, Alon Bar-Lev
> [2] https://github.com/alonbl/ovirt-engine
> [3] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer
> [4] https://github.com/alonbl/ovirt-overlay
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From amureini at redhat.com  Thu May 16 16:22:15 2013
From: amureini at redhat.com (Allon Mureinik)
Date: Thu, 16 May 2013 12:22:15 -0400 (EDT)
Subject: [Engine-devel] cannot attach ISO with latest master
In-Reply-To: <CAEWPe=qOXj6oXDb3G=naXFjBH_asHcConWrOJN0wi96CEmgKEg@mail.gmail.com>
References: <CAEWPe=rogGmX_OBNb2f=aMuYucgUqYKiyksDEr75wxfME6uLYQ@mail.gmail.com>
	<CAEWPe=qOXj6oXDb3G=naXFjBH_asHcConWrOJN0wi96CEmgKEg@mail.gmail.com>
Message-ID: <491385764.2974520.1368721335846.JavaMail.root@redhat.com>

The following patch (still pending review) should do the trick: 
http://gerrit.ovirt.org/#/c/14818/ 

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

> From: "Dead Horse" <deadhorseconsulting at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, May 16, 2013 5:31:23 PM
> Subject: Re: [Engine-devel] cannot attach ISO with latest master

> This occurs only when using "Run Once" to attach an ISO to a VM.
> It is still present in master as of this morning.
> It was reported recently by another user on the user list as well.
> - DHC

> On Mon, May 13, 2013 at 4:47 PM, Dead Horse < deadhorseconsulting at gmail.com >
> wrote:

> > Cannot attach images from the iso storage domain with latest master.
> 
> > VDSM version is latest master as well
> 
> > Host = EL6.4
> 

> > 2013-05-13 16:41:02,184 INFO
> > [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
> > (ajp--127.0.0.1-8702-7) [5d889258] START, IsoPrefixVDSCommand(
> > storagePoolId
> > = 0cba78bd-f1b7-438f-afac-acd59fab92ae, ignoreFailoverLimit = false,
> > compatabilityVersion = null), log id: a85d3c0
> 
> > 2013-05-13 16:41:02,196 INFO
> > [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
> > (ajp--127.0.0.1-8702-7) [5d889258] FINISH, IsoPrefixVDSCommand, return:
> > /rhev/data-center/mnt/192.168.0.1:_ovirt_dalaran/d6276dc3-1714-4024-9b70-b7971ed5fe35/images/11111111-1111-1111-1111-111111111111,
> > log id: a85d3c0
> 
> > 2013-05-13 16:41:02,328 WARN [org.ovirt.engine.core.bll.RunVmOnceCommand]
> > (ajp--127.0.0.1-8702-7) [5d889258] CanDoAction of action RunVmOnce failed.
> > Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH
> 

> > - DHC
> 

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130516/09de467b/attachment.html>

From alonbl at redhat.com  Thu May 16 17:58:27 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 16 May 2013 13:58:27 -0400 (EDT)
Subject: [Engine-devel] [REST-API] Support passing auth information
 without having to use HTTP Authorization header #958874
In-Reply-To: <518B6C07.1080504@redhat.com>
References: <518751C7.8090208@redhat.com>
	<1665518752.4971723.1367945088296.JavaMail.root@redhat.com>
	<518B6C07.1080504@redhat.com>
Message-ID: <1192958387.1927204.1368727107293.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>, "Itamar Heim" <iheim at redhat.com>, "Juan
> Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Barak Azulay" <bazulay at redhat.com>
> Sent: Thursday, May 9, 2013 12:27:35 PM
> Subject: Re: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
> 
> On 05/07/2013 07:44 PM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Vojtech Szocs"
> >> <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>,
> >> "Itamar Heim" <iheim at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>,
> >> "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Monday, May 6, 2013 9:46:31 AM
> >> Subject: [REST-API] Support passing auth information without having to use
> >> HTTP Authorization header #958874
> >>
> >>
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=958874
> >>
> >> Hi Alon,
> >>
> >> (In reply to comment #2)
> >>>
> >>> Regardless of this specific RFE I would like to write that I don't like
> >>> the
> >>> REST API session mechanism
> >>> [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as it
> >>> relays on cookies and not explicit API interaction.
> >>
> >> authentication in RESTful application is a matter of debate, it can be
> >> achieved
> >> in various ways, but session + cookie auth. method is very common and
> >> usually
> >> effective,
> >>
> >> it's biggest disadvantage is that it's not exactly RESfull cause client
> >> have to maintain (story) the cookie and not the server (but i wouldn't
> >> call
> >> it an
> >> issue at all), besides that it's works perfectly well from the REST PoV,
> >>
> >> also some may say that cookies are not strong enough and OAuth for
> >> instance
> >> should be used instead, but this is a different story cause in our case,
> >> cookie
> >> are for the clients (not browsers [1]) that can store them in a secure way
> >> or
> >> even
> >> not to store at all (in-memory cookie).
> >>
> >> [1] another disadvantage is that webbrowsers not able to access cookie
> >> namespace,
> >> but lately i've suggested URI based authentication [2] to support web
> >> browsers
> >> as well.
> >>
> >> [2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html
> >>
> >> the biggest advantage of the cookie is a session expiration that
> >> maintained
> >> by the server and abstracted from the client what is much better from
> >> security
> >> PoV than standard authentication mechanisms such as HTTP basic auth for
> >> instance
> >> which can be potentially cached.
> > 
> > Expiration is always managed by server side, regardless the cookie vs
> > ticket debate.
> > 
> >>
> >>> I would have expected a
> >>> 'ticket' to be retrieved and that 'ticket' to be disconnected from the
> >>> application server objects. Although we can refer the 'cookie' as a
> >>> ticket,
> >>> however the requirement to parse it should not be required, there be a
> >>> conflict between two separate applications running on same server, and
> >>> there
> >>> may be a problem to transfer credentials between servers.
> >>
> >> well, this is not exactly correct:
> >>
> >> 1. client desn't have to decode/parse the cookie and pass credentials, all
> >> it
> >> need is
> >>    just to store the cookie and pass it as is to server on every request.
> > 
> > You just described what cookies are.
> > And if I understand we want better control of application authentication,
> > disconnected from 'default browser behavior'.
> > 
> >> 2. "conflict between two separate applications running on same server"?
> >> different cookie
> >>    uses different domain & path by spec., can you pls explain what do you
> >>    mean by this?
> > 
> > If you call the cookie JSESSIONID....
> 
> different applications cannot live under same path,
> this what for cookie has a "path" attribute,
> 
> but it can create a bit of confusion indeed, but you not
> talking with more than one application in same time right ?!,
> i.e container/client fetches the JSESSIONID cookie from the
> specific request/response,

I am taking exactly on that... good on demand authentication mechanism should allow concurrent multiple users processing. This is what API is all about.
Of course this can somehow achieved via cookie, but doing so is so complex that one probably wish to use plain header, or worse case a cookie that does not conflict with the application that loaded the static content.

> so i'm not sure how possibly client can get in reply two
> cookies with a same name (even if all applications are using
> same cookie)

Because of this, authorization mechanism should not use cookies.

> >>>
> >>> If we modify authentication we should support more authentication types,
> >>> at
> >>> least SPNEGO.
> >>>
> >>> In order to allow SPNEGO and other authentication mechanisms, we better
> >>> force people to use single URI to perform the login and return
> >>> authenticated
> >>> 'ticket' to continue interaction with application.
> >>
> >> this is good for the backend authentication, but is not for the RESTful
> >> application, it's like buying an aeroplane and driving it on a road,
> > 
> > And why is that? who are you to decide what authentication mechanism is to
> > be used by customers?
> 
> alon, you misunderstood, i'm not talking about authentication method,
> but about your sentence ^ "we better force people to use single URI"
> 
> > If customer has a policy of not transmitting passwords over the network,
> > then SPENGO is your friend.
> > But let's ignore it for now.
> 
> cookie is not any different from the SPENGO token in this meaning,
> it's just another data container.

Yes they are, they cannot provide challenge response sequence required to establish trust.

> 
> > 
> >> "force people to use single URI to perform the login" means SOAP while we
> >> wanted REST
> >> where any URI is considered as entry point and actually a resource address
> >> that should
> >> be accessible/manipulatable and authentication should be
> >> abstracted/disconnected from
> >> this concept.
> > 
> > Again, you provide statements that are not written in stone.
> 
> this is main REST principal.

I know very few principles that have no exceptions in software engineering.

> > Having custom authentication header breaks the 'plain simple rest'.
> > Having a URI is only makes it easier to manage this breakage.
> 
> for us, but this is breaks a REST concept.

Per your interpretation.
 
> > 
> >> SPNEGO is only an implementation detail that can be abstracted for the
> >> API.
> > 
> > I don't follow.
> > 
> >>> This will be much simpler
> >>> implementation at the api side and much more efficient, and as we are
> >>> discussion application-to-application interaction there should be no user
> >>> experience visible issues.
> >>
> >> i'm not sure: "force people to use single URI to perform the login" and no
> >> "no user experience visible issues."?
> > 
> > Please describe how the prefer mechanism suggested can be implemented in
> > standard browser.
> 
> it cannot because authorization header has to be supplied only when
> client wishes to reinitialize the JSESSION, and web browsers can't omit
> it during the lifetime.
> 
> all this cause we don't support web browsers in api yet, session based
> authentication mechanism was designed for http clients,
> 
> and this why we having this discussion, currently options are:
> 
> 1. adapt session based authentication
> 2. introduce new concept
> 
> personally i prefer #1 as it's less noisy and easily achievable.

But will force you to face more issues in future.

> > And if it cannot, and custom logic is required, why a custom logic that
> > accesses a custom URI to perform login is any different.
> 
> it's not RESTful

I am tired to answer this over and over...

> >  
> >>>
> >>> What I recommend is purely applicative rest login command...
> >>
> >> IIUC this is SOAP and not REST ...
> > 
> > Again... please refrain from these kind of void statements.
> > SOAP is a protocol, it has specific format and rules.
> > It may or may not use this or any other suggested authentication mechanism.
> 
> i'm not talking about the protocol, but about the conceptual differences
> between SOAP and REST services.
> 
> SOAP is a RPC (Remote Procedure Call) and has single entry point on which
> different methods are invoked, having single dedicated method for login
> works in this case,

So happy to know!

> REST is a ROA (Resource Oriented Architecture), i.e everything is REST is a
> resource, and you have to operate on these resources, authentication is only
> an implementation detail that should not break this concept.

REST accept cookie that was obtained from former authentication, so it breaks your above statement.
The cookie can and usually is acquired by different URI.

> now saying this i think is clear that you have no place to put at the login()
> method you've mentioned,

Exactly from which you took the cookie, in your language from the Session resource.
 
> standard way for authentication in REST/HTTP is via 'authorization' header
> (per request),
> optimizing this we've introduced new concept via sessionid,
> 
> user can choose between two by passing 'prefer:persistent_auth' header,
> 
> hope it's clear now, please let me know otherwise.

Well, it is  clear that this is not a discussion, but dictation...
So do whatever you think...

> 
> >  
> >>> ---
> >>> Input: authentication type, authentication credentials
> >>>     authentication=http
> >>>     authentication=password
> >>>     credentials:
> >>>         user=user
> >>>         password=password
> >>>     [OPTIONALLY] HTTP authentication headers
> >>> Output:
> >>>     ticket
> >>>     ticket issue time (required to avoid clock sync)
> >>>     ticket expiration time
> >>> Logic:
> >>> if authentication is http, use http authentication headers to establish
> >>> user
> >>> authentication. This will allow future SSO.
> >>> if authentication is password, use embedded credentials.
> >>> ---
> >>>
> >>> For every other rest call add http header:
> >>>     oVirt-Authentication-Ticket: <ticket>
> >>
> >> this is not any different from the today's session based auth. only
> >> instead of  oVirt-Authentication-Ticket added cookie.
> > 
> > I did not claim otherwise, I wrote that I don't like cookies, I do like
> > explicit headers.
> > As I wrote, cookies has limited storage at client, cookies may conflict,
> > cookies has issues with clusters.
> > Headers do not.
> 
> using headers has own drawbacks, WebAdmin core is not only entity that
> requires authentication in the app, i'll give you one use-case:
> 
> today we have plugin interface in WebAdmin, WebAdmin may have different
> plugins installed, to maintain different permissions for every plugin,
> each will have to send own authorization data on every request,
> 
> as you see this turns to be truly complex, almost not feasible via headers,

No I cannot, every plugin can either use the current state of application (JSESSIONID) or can authenticate and get its own ticket, pass it via its own requests.

> btw in other thread i suggested to used URL parameters for passing
> authentication
> tokens.

I do not follow how it is relevant, and why URL parameters are better than HTTP header.

> > 
> >>>
> >>> The backend side will attach the correct security context to the action
> >>> if
> >>> the header is received.
> >>
> >> this is how it's works today.
> > 
> > I could not imagine that.
> >  
> > 
> > Regards,
> > Alon
> > 


From deadhorseconsulting at gmail.com  Thu May 16 21:21:47 2013
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Thu, 16 May 2013 16:21:47 -0500
Subject: [Engine-devel] Odd Host Activation with mgmt-if
In-Reply-To: <CAEWPe=oX94UBGnph+5hePnJSyQBneU3-u7QCRwthzmJsZTBm3Q@mail.gmail.com>
References: <CAEWPe=oX94UBGnph+5hePnJSyQBneU3-u7QCRwthzmJsZTBm3Q@mail.gmail.com>
Message-ID: <CAEWPe=qtPwFC2_SEiFV+TdZjbptSy4pig2SOJE7iWAaBHR6YAw@mail.gmail.com>

Still puzzling on this all I get for an error when I see it is:
WARN  [org.ovirt.engine.core.bll.
network.host.SetupNetworksCommand] (pool-5-thread-42) [21543ac] CanDoAction
of action SetupNetworks failed.
Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
ovirtmgmt

Nothing is logged VDSM wise other then the above standard host activation
probe.

- DHC



On Mon, May 13, 2013 at 1:19 PM, Dead Horse
<deadhorseconsulting at gmail.com>wrote:

> Seeing this as of late when activating hosts. The odd this is that it
> reports a failure to activate the host (EL6.4) but still does it anyways.
>
> Engine side:
>
> 2013-05-13 12:53:38,547 INFO
> [org.ovirt.engine.core.bll.HandleVdsVersionCommand] (pool-5-thread-42)
> [21543ac] Running command: HandleVdsVersionCommand internal: true. Entities
> affected :  ID: 15f11023-9746-49de-b33f-e3cc7dca6f65 Type: VDS
> 2013-05-13 12:53:38,549 INFO
> [org.ovirt.engine.core.vdsbroker.ActivateVdsVDSCommand] (pool-5-thread-42)
> [21543ac] FINISH, ActivateVdsVDSCommand, return: Host[durotar], log id:
> 3796a7bd
> 2013-05-13 12:53:38,625 WARN
> [org.ovirt.engine.core.bll.network.host.SetupNetworksCommand]
> (pool-5-thread-42) [21543ac] CanDoAction of action SetupNetworks failed.
> Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
> ovirtmgmt
> 2013-05-13 12:53:39,368 INFO
> [org.ovirt.engine.core.bll.ActivateVdsCommand] (pool-5-thread-42) [21543ac]
> Activate finished. Lock released. Monitoring can run now for host durotar
> from data-center Azeroth
>
> VDSM Side:
>
> Thread-13::DEBUG::2013-05-13
> 12:53:37,841::BindingXMLRPC::933::vds::(wrapper) return getCapabilities
> with {'status': {'message': 'Done', 'code': 0}, 'info': {'HBAInventory':
> {'iSCSI': [{'InitiatorName': 'iqn.2012-09.net.azeroth:durotar'}], 'FC':
> []}, 'packages2': {'kernel': {'release': '358.6.1.el6.x86_64', 'buildtime':
> 1366751713.0, 'version': '2.6.32'}, 'glusterfs-rdma': {'release':
> '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'},
> 'glusterfs-fuse': {'release': '0.3.alpha3.el6', 'buildtime': 1367604893L,
> 'version': '3.4.0'}, 'spice-server': {'release': '12.el6', 'buildtime':
> 1361573005L, 'version': '0.12.0'}, 'vdsm': {'release': '17.el6',
> 'buildtime': 1368196305L, 'version': '4.10.3'}, 'qemu-kvm': {'release':
> '2.355.el6_4.2', 'buildtime': 1362691270L, 'version': '0.12.1.2'},
> 'qemu-img': {'release': '2.355.el6_4.2', 'buildtime': 1362691270L,
> 'version': '0.12.1.2'}, 'libvirt': {'release': '18.el6_4.4', 'buildtime':
> 1366301801L, 'version': '0.10.2'}, 'glusterfs': {'release':
> '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'}, 'mom':
> {'release': '1.el6', 'buildtime': 1349470062L, 'version': '0.3.0'},
> 'glusterfs-server': {'release': '0.3.alpha3.el6', 'buildtime': 1367604893L,
> 'version': '3.4.0'}}, 'cpuModel': 'Intel(R) Xeon(R) CPU           X5570  @
> 2.93GHz', 'hooks': {'before_vm_start': {'50_sriov': {'md5':
> '3ebc60cd2e4eb089820102285fad7c45'}, '50_pincpu': {'md5':
> '0b5fb99ff0e7acb9ad534b87c02c59e3'}, '50_qos': {'md5':
> '18b596a6b4e4bad80357f240ba122a5e'}, '50_vmfex': {'md5':
> '9f5abb892ddb6b3daa779985d38d9f55'}, '50_scratchpad': {'md5':
> '7db25a4b8cb04f6e7132cb7c2300c111'}, '50_numa': {'md5':
> '5008c2826714ac5b63748780aabd2f25'}, '50_floppy': {'md5':
> '202fe18705a7d4c50c40c126e8f8dbe8'}, '50_qemucmdline': {'md5':
> 'a884929ad6f5eb039887157288867409'}, '50_macspoof': {'md5': '25deea559772719
>
> - DHC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130516/e8ff4650/attachment.html>

From wlbleaboy at 126.com  Fri May 17 01:31:20 2013
From: wlbleaboy at 126.com (wlbleaboy@126)
Date: Fri, 17 May 2013 09:31:20 +0800
Subject: [Engine-devel] vm in pool can't be suspended
Message-ID: <000001ce529e$3d7e4980$b87adc80$@com>

Hi all:

         When I create some vms in pool, the vm in pool can't be suspended,

I don't know is a bug, or it's don't support.

 

 

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

From sbonazzo at redhat.com  Fri May 17 08:11:54 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 17 May 2013 10:11:54 +0200
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <2140554843.5508235.1368040739442.JavaMail.root@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1990199020.4477969.1367858405918.JavaMail.root@redhat.com>
	<6D858B39-39FD-410E-9E8B-912AEE950624@redhat.com>
	<190022898.4562887.1367871118558.JavaMail.root@redhat.com>
	<518A4A37.7040506@redhat.com>
	<1674151596.12805405.1368018034731.JavaMail.root@redhat.com>
	<129444276.5410211.1368022851515.JavaMail.root@redhat.com>
	<1259953792.13083016.1368039749490.JavaMail.root@redhat.com>
	<2140554843.5508235.1368040739442.JavaMail.root@redhat.com>
Message-ID: <5195E64A.3050806@redhat.com>

Il 08/05/2013 21:18, Alon Bar-Lev ha scritto:
> Right.
> First, we need to support any installation not just rhel.
> Second, we can support only other well behaved products.
> Until recently we were not well behaved... well we still not fully because we do not have our own configurable URI namespace.
>
> We cannot control which applications are installed on the same host, however we can:
>
> 1. postgresql: support skipping the automatic provisioning [supported in the otopi setup]
> 2. apache: do not enforce specific apache SSL implementation [to be done].
> 3. apache: support skipping the automatic SSL configuration [supported].
> 4. apache: support skipping the root redirect to ovirt application [supported in otopi setup]
> 5. apache: move application to own name space, example /ovirt-engine [to be done, I will be happy if you can help pushing this]
> 6. firewall: support skipping configuration [supported]
> 7. packaging: remove the versionlock usage.
> 8. packaging: support proper upgrade path, compatible with packaging best practices.
> 9. files: rename all utilities and public artifacts from engine-* to ovirt-engine-*
> [more?]
>
> If we do the above we are acting as well behaved application, and can co-exist with other well behaved applications.


Trying to set the point on this issue in order to start coding.

We split the http configuration into three:
1. Install ajp proxy per our URIs[1][2].
2. Optionally set root redirection from / to /ovirt-engine
3. Optionally configure mod_ssl with our certificate.

The mandatory apache configuration[1] does not alter any configuration file.
[1] http://gerrit.ovirt.org/13318
[2] http://gerrit.ovirt.org/14304

So there is no reason for checking if user has changed the http
configuration for just forcing proxy.

About IPA conflicts if I've understood correctly there is only collision
between mod_nss used by IPA and mod_ssl used if we enable mod_ssl
configuration.
It seems there was an issue with mod_proxy and using 2 different SSL
certificates (IPA & RHEV) on the same apache server.

So, I can force proxy enabled and I can force SSL configuration disabled
if IPA is detected.
I can leave root redirection optional in any case.

otopi implementation already force proxy enabled so there should be just
to disable ssl if IPA is detected.

During the discussion about this bug it was suggested also to avoid to
force dependency on mod_ssl or force migration to mod_nss during upgrade
allowing ipa and engine to coexist. I don't think that that issue should
be tracked by https://bugzilla.redhat.com/905754 so if there is the will
to either drop dependency on mod_ssl or migrate to mod_nss please open a
new bug about that.
That could solve also another question: what if IPA is installed after
ovirt-engine?

In order to act as well behaved application, and co-exist with other
well behaved applications there is more to do as Alon pointed out.
I think that any point not satisfied in order to behave correctly need a
bug to be opened.

When we'll behave correctly I'll remove any check on IPA presence,
totally ignoring it and removing any enforcement about its presence.

Am I missing something?

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From sabose at redhat.com  Fri May 17 09:34:31 2013
From: sabose at redhat.com (Sahina Bose)
Date: Fri, 17 May 2013 15:04:31 +0530
Subject: [Engine-devel] SQL procedure - row mapper
Message-ID: <5195F9A7.3090003@redhat.com>

Hi all,

In org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler , there's a 
map maintained for procedure name and SimpleJdbcCall.

If I have the same procedure with different row mappers, this results in 
an error - because the map already contains a mapping for the procedure 
name but with different row mapper.

Do we intend to support calling the same procedure with different 
RowMappers? If so, I can change this class to handle this.

thanks
sahina


From qw.iampaco at gmail.com  Fri May 17 10:00:37 2013
From: qw.iampaco at gmail.com (Paco qw)
Date: Fri, 17 May 2013 14:00:37 +0400
Subject: [Engine-devel] Build ovirt from srpms and install
Message-ID: <CAP5w-iKPQ8DbtH5zRR8LzHNpGje9z3+s0+5sdhKxUo_04f3cEA@mail.gmail.com>

Hi!

Trying to build an RPM of ovirt in Centos 6.2.
Srpms take away http://resources.ovirt.org/releases/3.2/rpm/EL/6/SRPMS/
execute commands engine-cleanup get an error

Installing:
Configuring oVirt Engine...                             [ DONE ]
Configuring JVM...                                      [ DONE ]
Creating CA...                                          [ DONE ]
Updating ovirt-engine service...                        [ DONE ]
Setting Database Configuration...                       [ DONE ]
Setting Database Security...                            [ DONE ]
Creating Database...                                 [ ERROR ]
Database creation failed
Please check log file
/var/log/ovirt-engine/engine-setup_2011_11_24_05_36_26.log for more
information

In log file - psql: FATAL:  database "engine" does not exist

]0;root at rhevm8:/usr/lib/jvm[root at rhevm8 jvm]#
]0;root at rhevm8:/usr/lib/jvm[root at rhevm8 jvm]#
]0;root at rhevm8:/usr/lib/jvm[root at rhevm8 jvm]#
]0;root at rhevm8:/usr/lib/jvm[root at rhevm8 jvm]# moll
java-1.7.0-openjdk-1.7.0.9.x86_64/jre/bin/bin/
cd
/usr/lib/jvm/ll /usr/lib/jvm/jre-1.7.0-openjdk.x86_64
more
/var/log/ovirt-engine/engine-setup_2011_11_24_05_17_02.log

/var/log/ovirt-engine/engine-setup_2011_11_24_05_17_02.log
c
/var/log/ovirt-engine/engine-setup_2011_11_24_05_17_02.log
a
/var/log/ovirt-engine/engine-setup_2011_11_24_05_17_02.log
t
/var/log/ovirt-engine/engine-setup_2011_11_24_05_17_02.log

2011-11-24 05:17:02::DEBUG::engine-setup::2279::root:: importing module
example_plugin_000, from file example_plugin_000.py
2011-11-24 05:17:02::DEBUG::example_plugin_000::17::root:: plugin
example_plugin_000 loaded
2011-11-24 05:17:02::DEBUG::common_utils::1282::root:: checking if
firewalld service is available
2011-11-24 05:17:02::DEBUG::common_utils::1282::root:: checking if iptables
service is available
2011-11-24 05:17:02::DEBUG::common_utils::434::root:: Executing command -->
'/sbin/ip addr'
2011-11-24 05:17:02::DEBUG::common_utils::472::root:: output = 1: lo:
<LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen
1000
    link/ether 00:21:5a:ac:0b:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.91.166/25 brd 192.168.91.255 scope global eth0
    inet6 fe80::221:5aff:feac:bb6/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:21:5a:ac:0b:dc brd ff:ff:ff:ff:ff:ff

2011-11-24 05:17:02::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:17:02::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:17:02::DEBUG::common_utils::593::root:: Found IP Address:
192.168.91.166
2011-11-24 05:17:02::DEBUG::engine-setup::2228::root:: initiating command
line option parser
2011-11-24 05:17:02::DEBUG::engine-setup::2195::root:: checking total memory
2011-11-24 05:17:02::DEBUG::common_utils::434::root:: Executing command -->
'/usr/bin/free -m'
2011-11-24 05:17:02::DEBUG::common_utils::472::root:: output =
total       used       free     shared    buffers     cached
Mem:         13928       7087       6841          0         44       6579
-/+ buffers/cache:        463      13465
Swap:        16111          0      16111

2011-11-24 05:17:02::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:17:02::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:17:02::DEBUG::engine-setup::2207::root:: Found a match,
amount of memory: 13928
2011-11-24 05:17:02::DEBUG::common_utils::332::root:: YUM: VERB: Loaded
plugins: fastestmirror, presto, versionlock
2011-11-24 05:17:02::DEBUG::engine-setup::2097::root:: Entered
main(configFile='None')
2011-11-24 05:17:02::DEBUG::engine-setup::1888::root:: stopping
ovirt-engine service
2011-11-24 05:17:02::DEBUG::common_utils::1266::root:: getting status for
ovirt-engine
2011-11-24 05:17:02::DEBUG::common_utils::1275::root:: executing action
ovirt-engine on service status
2011-11-24 05:17:02::DEBUG::common_utils::434::root:: Executing command -->
'/sbin/service ovirt-engine status'
2011-11-24 05:17:02::DEBUG::common_utils::472::root:: output = The engine
is not running.

2011-11-24 05:17:02::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:17:02::DEBUG::common_utils::474::root:: retcode = 3
2011-11-24 05:17:02::DEBUG::engine-setup::1597::root:: going over group
PORTS
2011-11-24 05:17:02::DEBUG::common_utils::1326::root:: retrieving version
for ipa-server rpm
2011-11-24 05:17:02::DEBUG::common_utils::332::root:: YUM: VERB: Loaded
plugins: fastestmirror, presto, versionlock
2011-11-24 05:17:02::DEBUG::common_utils::332::root:: YUM: VERB: Loading
mirror speeds from cached hostfile
2011-11-24 05:17:13::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: epel/metalink (0%)
2011-11-24 05:17:13::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: epel/metalink 20 k(100%)
2011-11-24 05:17:17::DEBUG::common_utils::332::root:: YUM: VERB:  * base:
centos-mirror.rbc.ru
2011-11-24 05:17:17::DEBUG::common_utils::332::root:: YUM: VERB:  *
c6-media:
2011-11-24 05:17:17::DEBUG::common_utils::332::root:: YUM: VERB:  * epel:
mirror.yandex.ru
2011-11-24 05:17:17::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: repomdia5nU5tmp.xml (0%)
2011-11-24 05:17:17::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: repomdia5nU5tmp.xml 3.7 k(100%)
2011-11-24 05:17:17::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: repomdsydpX3tmp.xml (0%)
2011-11-24 05:17:17::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: repomdsydpX3tmp.xml 4.0 k(100%)
2011-11-24 05:17:18::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: repomdtkXySWtmp.xml (0%)
2011-11-24 05:17:18::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: repomdtkXySWtmp.xml 1.3 k(100%)
2011-11-24 05:17:18::DEBUG::common_utils::1347::root:: getRpmVersion failed
Traceback (most recent call last):
  File "/usr/share/ovirt-engine/scripts/common_utils.py", line 1344, in
installed
    getRpmVersion(rpmName=rpm)
  File "/usr/share/ovirt-engine/scripts/common_utils.py", line 1338, in
getRpmVersion
    raise Exception(output_messages.ERR_READ_RPM_VER % rpmName)
Exception: Error reading version number for package ipa-server
2011-11-24 05:17:18::DEBUG::common_utils::1326::root:: retrieving version
for freeipa-server rpm
2011-11-24 05:17:18::DEBUG::common_utils::332::root:: YUM: VERB: Loaded
plugins: fastestmirror, presto, versionlock
2011-11-24 05:17:18::DEBUG::common_utils::332::root:: YUM: VERB: Loading
mirror speeds from cached hostfile
2011-11-24 05:17:20::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: epel/metalink (0%)
2011-11-24 05:17:20::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: epel/metalink 20 k(100%)
2011-11-24 05:17:24::DEBUG::common_utils::332::root:: YUM: VERB:  * base:
mirror.majorhost.net
2011-11-24 05:17:24::DEBUG::common_utils::332::root:: YUM: VERB:  *
c6-media:
2011-11-24 05:17:24::DEBUG::common_utils::332::root:: YUM: VERB:  * epel:
mirror.yandex.ru
2011-11-24 05:17:24::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: repomdJIgPbAtmp.xml (0%)
2011-11-24 05:17:24::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: repomdJIgPbAtmp.xml 3.7 k(100%)
2011-11-24 05:17:24::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: repomdYNz_Eutmp.xml (0%)
2011-11-24 05:17:24::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: repomdYNz_Eutmp.xml 4.0 k(100%)
2011-11-24 05:17:25::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: repomdQ8r269tmp.xml (0%)
2011-11-24 05:17:25::DEBUG::common_utils::332::root:: YUM: VERB:
Downloading: repomdQ8r269tmp.xml 1.3 k(100%)
2011-11-24 05:17:26::DEBUG::common_utils::1347::root:: getRpmVersion failed
Traceback (most recent call last):
  File "/usr/share/ovirt-engine/scripts/common_utils.py", line 1344, in
installed
    getRpmVersion(rpmName=rpm)
  File "/usr/share/ovirt-engine/scripts/common_utils.py", line 1338, in
getRpmVersion
    raise Exception(output_messages.ERR_READ_RPM_VER % rpmName)
Exception: Error reading version number for package freeipa-server
2011-11-24 05:17:26::INFO::engine-setup::1606::root:: Comparing
pre-conditions; condition: 'True', and match: 'True'
2011-11-24 05:17:28::INFO::engine_validators::199::root::
validateOverrideHttpdConfAndChangePortsAccordingly y as part of ['yes',
'no']
2011-11-24 05:17:28::INFO::engine_validators::182::root:: Validating y as
part of ['yes', 'no']
2011-11-24 05:17:28::DEBUG::engine_validators::207::root:: stopping httpd
service
2011-11-24 05:17:28::DEBUG::common_utils::1238::root:: stopping httpd
2011-11-24 05:17:28::DEBUG::common_utils::1275::root:: executing action
httpd on service stop
2011-11-24 05:17:28::DEBUG::common_utils::434::root:: Executing command -->
'/sbin/service httpd stop'
2011-11-24 05:17:28::DEBUG::common_utils::472::root:: output = Stopping
httpd: [FAILED]


2011-11-24 05:17:28::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:17:28::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:17:29::DEBUG::engine_validators::62::root:: Validating 80 as
a valid TCP Port
2011-11-24 05:17:29::DEBUG::common_utils::398::root:: Checking if TCP port
80 is open by any process
2011-11-24 05:17:29::DEBUG::common_utils::434::root:: Executing command -->
'/usr/sbin/lsof -i -n -P'
2011-11-24 05:17:29::DEBUG::common_utils::472::root:: output = COMMAND
PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
rpcbind   1225      rpc    6u  IPv4   9182      0t0  UDP *:111
rpcbind   1225      rpc    7u  IPv4   9186      0t0  UDP *:976
rpcbind   1225      rpc    8u  IPv4   9187      0t0  TCP *:111 (LISTEN)
rpcbind   1225      rpc    9u  IPv6   9189      0t0  UDP *:111
rpcbind   1225      rpc   10u  IPv6   9191      0t0  UDP *:976
rpcbind   1225      rpc   11u  IPv6   9192      0t0  TCP *:111 (LISTEN)
rpc.statd 1243  rpcuser    5r  IPv4   9372      0t0  UDP *:995
rpc.statd 1243  rpcuser    8u  IPv4   9376      0t0  UDP *:37288
rpc.statd 1243  rpcuser    9u  IPv4   9380      0t0  TCP *:45184 (LISTEN)
rpc.statd 1243  rpcuser   10u  IPv6   9384      0t0  UDP *:53291
rpc.statd 1243  rpcuser   11u  IPv6   9388      0t0  TCP *:59962 (LISTEN)
sshd      1350     root    3u  IPv4   9728      0t0  TCP *:22 (LISTEN)
sshd      1350     root    4u  IPv6   9730      0t0  TCP *:22 (LISTEN)
sshd      1386     root    3r  IPv4   9969      0t0  TCP 192.168.91.166:22->
62.231.2.201:16232 (ESTABLISHED)
sshd      1433     root    3r  IPv4  10426      0t0  TCP 192.168.91.166:22->
62.231.2.201:15167 (ESTABLISHED)
postmaste 7175 postgres    3u  IPv6  45181      0t0  TCP [::1]:5432 (LISTEN)
postmaste 7175 postgres    4u  IPv4  45182      0t0  TCP 127.0.0.1:5432(LISTEN)
postmaste 7175 postgres    7u  IPv6  45193      0t0  UDP
[::1]:58773->[::1]:58773
postmaste 7179 postgres    7u  IPv6  45193      0t0  UDP
[::1]:58773->[::1]:58773
postmaste 7180 postgres    7u  IPv6  45193      0t0  UDP
[::1]:58773->[::1]:58773
postmaste 7181 postgres    7u  IPv6  45193      0t0  UDP
[::1]:58773->[::1]:58773
postmaste 7182 postgres    7u  IPv6  45193      0t0  UDP
[::1]:58773->[::1]:58773
engine-se 8001     root   27u  IPv4  48231      0t0  TCP
192.168.91.166:33822->80.239.156.215:443 (ESTABLISHED)
engine-se 8001     root   33u  IPv4  48710      0t0  TCP
192.168.91.166:36829->80.68.249.121:80 (ESTABLISHED)

2011-11-24 05:17:29::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:17:29::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:17:29::DEBUG::common_utils::434::root:: Executing command -->
'/usr/sbin/semanage port -l'
2011-11-24 05:17:31::DEBUG::common_utils::472::root:: output = SELinux Port
Type              Proto    Port Number

afs_bos_port_t                 udp      7007
afs_client_port_t              udp      7001
afs_fs_port_t                  tcp      2040
afs_fs_port_t                  udp      7000, 7005
afs_ka_port_t                  udp      7004
afs_pt_port_t                  udp      7002
afs_vl_port_t                  udp      7003
agentx_port_t                  tcp      705
agentx_port_t                  udp      705
amanda_port_t                  tcp      10080-10083
amanda_port_t                  udp      10080-10082
amavisd_recv_port_t            tcp      10024
amavisd_send_port_t            tcp      10025
amqp_port_t                    tcp      5671, 5672
amqp_port_t                    udp      5671, 5672
aol_port_t                     tcp      5190-5193
aol_port_t                     udp      5190-5193
apcupsd_port_t                 tcp      3551
apcupsd_port_t                 udp      3551
apertus_ldp_port_t             tcp      539
apertus_ldp_port_t             udp      539
asterisk_port_t                tcp      1720
asterisk_port_t                udp      2427, 2727, 4569
audit_port_t                   tcp      60
auth_port_t                    tcp      113
bgp_port_t                     tcp      179, 2605
bgp_port_t                     udp      179, 2605
boinc_port_t                   tcp      31416
certmaster_port_t              tcp      51235
chronyd_port_t                 udp      323
clamd_port_t                   tcp      3310
clockspeed_port_t              udp      4041
cluster_port_t                 tcp      5149, 40040, 50006-50008
cluster_port_t                 udp      5149, 50006-50008
cma_port_t                     tcp      1050
cma_port_t                     udp      1050
cobbler_port_t                 tcp      25151
commplex_port_t                tcp      5000, 5001
commplex_port_t                udp      5000, 5001
comsat_port_t                  udp      512
ctdb_port_t                    tcp      4379
ctdb_port_t                    udp      4379
cvs_port_t                     tcp      2401
cvs_port_t                     udp      2401
cyphesis_port_t                tcp      6767, 6769, 6780-6799
cyphesis_port_t                udp      32771
dbskkd_port_t                  tcp      1178
dcc_port_t                     udp      6276, 6277
dccm_port_t                    tcp      5679
dccm_port_t                    udp      5679
dhcpc_port_t                   tcp      68, 546
dhcpc_port_t                   udp      68, 546
dhcpd_port_t                   tcp      547, 548, 647, 847, 7911
dhcpd_port_t                   udp      67, 547, 548, 647, 847
dict_port_t                    tcp      2628
distccd_port_t                 tcp      3632
dns_port_t                     tcp      53
dns_port_t                     udp      53
dogtag_port_t                  tcp      7390
epmap_port_t                   tcp      135
epmap_port_t                   udp      135
festival_port_t                tcp      1314
fingerd_port_t                 tcp      79
flash_port_t                   tcp      843, 1935
flash_port_t                   udp      1935
ftp_data_port_t                tcp      20
ftp_port_t                     tcp      21, 990
ftp_port_t                     udp      990
gatekeeper_port_t              tcp      1721, 7000
gatekeeper_port_t              udp      1718, 1719
giftd_port_t                   tcp      1213
git_port_t                     tcp      9418
git_port_t                     udp      9418
gopher_port_t                  tcp      70
gopher_port_t                  udp      70
gpsd_port_t                    tcp      2947
hddtemp_port_t                 tcp      7634
hi_reserved_port_t             tcp      512-1023
hi_reserved_port_t             udp      512-1023
howl_port_t                    tcp      5335
howl_port_t                    udp      5353
hplip_port_t                   tcp      1782, 2207, 2208, 8290, 50000,
50002, 8292, 9100, 9101, 9102, 9220, 9221, 9222, 9280, 9281, 9282, 9290,
9291, 9292
http_cache_port_t              tcp      3128, 8080, 8118, 8123, 10001-10010
http_cache_port_t              udp      3130
http_port_t                    tcp      80, 443, 488, 8008, 8009, 8443
i18n_input_port_t              tcp      9010
imaze_port_t                   tcp      5323
imaze_port_t                   udp      5323
inetd_child_port_t             tcp      1, 7, 9, 13, 19, 37, 512, 543, 544,
891, 892, 2105, 5666
inetd_child_port_t             udp      1, 7, 9, 13, 19, 37, 891, 892
innd_port_t                    tcp      119
ionixnetmon_port_t             tcp      7410
ionixnetmon_port_t             udp      7410
ipmi_port_t                    udp      623, 664
ipp_port_t                     tcp      631, 8610-8614
ipp_port_t                     udp      631, 8610-8614
ipsecnat_port_t                tcp      4500
ipsecnat_port_t                udp      4500
ircd_port_t                    tcp      6667
isakmp_port_t                  udp      500
iscsi_port_t                   tcp      3260
isns_port_t                    tcp      3205
isns_port_t                    udp      3205
jabber_client_port_t           tcp      5222, 5223
jabber_interserver_port_t      tcp      5269
jabber_router_port_t           tcp      5347
jboss_management_port_t        tcp      4712, 9123, 18001
jboss_management_port_t        udp      4712, 9123
kerberos_admin_port_t          tcp      749
kerberos_master_port_t         tcp      4444
kerberos_master_port_t         udp      4444
kerberos_password_port_t       tcp      464
kerberos_password_port_t       udp      464
kerberos_port_t                tcp      88, 750
kerberos_port_t                udp      88, 750
kismet_port_t                  tcp      2501
kprop_port_t                   tcp      754
ktalkd_port_t                  udp      517, 518
ldap_port_t                    tcp      389, 636, 3268
ldap_port_t                    udp      389, 636
lirc_port_t                    tcp      8765
lmtp_port_t                    tcp      24
lmtp_port_t                    udp      24
luci_port_t                    tcp      8084
mail_port_t                    tcp      2000, 3905
matahari_port_t                tcp      49000
matahari_port_t                udp      49000
memcache_port_t                tcp      11211
memcache_port_t                udp      11211
mmcc_port_t                    tcp      5050
mmcc_port_t                    udp      5050
monopd_port_t                  tcp      1234
movaz_ssc_port_t               tcp      5252
mpd_port_t                     tcp      6600
msnp_port_t                    tcp      1863
msnp_port_t                    udp      1863
mssql_port_t                   tcp      1433, 1434
mssql_port_t                   udp      1433, 1434
munin_port_t                   tcp      4949
munin_port_t                   udp      4949
mysqld_port_t                  tcp      1186, 3306, 63132-63164
mysqlmanagerd_port_t           tcp      2273
nessus_port_t                  tcp      1241
netport_port_t                 tcp      3129
netport_port_t                 udp      3129
netsupport_port_t              tcp      5404, 5405
netsupport_port_t              udp      5404, 5405
nmbd_port_t                    udp      137, 138
ntop_port_t                    tcp      3000, 3001
ntop_port_t                    udp      3000, 3001
ntp_port_t                     udp      123
ocsp_port_t                    tcp      9080
openvpn_port_t                 tcp      1194
openvpn_port_t                 udp      1194
oracle_port_t                  tcp      1521, 2483, 2484
oracle_port_t                  udp      1521, 2483, 2484
pegasus_http_port_t            tcp      5988
pegasus_https_port_t           tcp      5989
pgpkeyserver_port_t            tcp      11371
pgpkeyserver_port_t            udp      11371
pingd_port_t                   tcp      9125
piranha_port_t                 tcp      3636
pki_ca_port_t                  tcp      9180, 9701, 9443-9447
pki_kra_port_t                 tcp      10180, 10701, 10443-10446
pki_ocsp_port_t                tcp      11180, 11701, 11443-11446
pki_ra_port_t                  tcp      12888, 12889
pki_tks_port_t                 tcp      13180, 13701, 13443-13446
pki_tps_port_t                 tcp      7888, 7889
pktcable_port_t                tcp      2126, 3198
pktcable_port_t                udp      2126, 3198
pop_port_t                     tcp      106, 109, 110, 143, 220, 993, 995,
1109
portmap_port_t                 tcp      111
portmap_port_t                 udp      111
postfix_policyd_port_t         tcp      10031
postgresql_port_t              tcp      5432
postgrey_port_t                tcp      60000
prelude_port_t                 tcp      4690
prelude_port_t                 udp      4690
presence_port_t                tcp      5298
presence_port_t                udp      5298
printer_port_t                 tcp      515
ptal_port_t                    tcp      5703
pulseaudio_port_t              tcp      4713
puppet_port_t                  tcp      8140
pxe_port_t                     udp      4011
pyzor_port_t                   udp      24441
radacct_port_t                 udp      1646, 1813
radius_port_t                  udp      1645, 1812
radsec_port_t                  tcp      2083
razor_port_t                   tcp      2703
repository_port_t              tcp      6363
ricci_modcluster_port_t        tcp      16851
ricci_modcluster_port_t        udp      16851
ricci_port_t                   tcp      11111
ricci_port_t                   udp      11111
rlogind_port_t                 tcp      513
rndc_port_t                    tcp      953
router_port_t                  tcp      521
router_port_t                  udp      520, 521
rsh_port_t                     tcp      514
rsync_port_t                   tcp      873
rsync_port_t                   udp      873
rwho_port_t                    udp      513
sap_port_t                     tcp      9875
sap_port_t                     udp      9875
sieve_port_t                   tcp      4190
sip_port_t                     tcp      5060, 5061
sip_port_t                     udp      5060, 5061
sixxsconfig_port_t             tcp      3874
sixxsconfig_port_t             udp      3874
smbd_port_t                    tcp      137-139, 445
smtp_port_t                    tcp      25, 465, 587
snmp_port_t                    tcp      161-162, 199, 1161
snmp_port_t                    udp      161-162
soundd_port_t                  tcp      8000, 9433, 16001
spamd_port_t                   tcp      783
speech_port_t                  tcp      8036
squid_port_t                   tcp      3401, 4827
squid_port_t                   udp      3401, 4827
ssh_port_t                     tcp      22
streaming_port_t               tcp      1755
streaming_port_t               udp      1755
swat_port_t                    tcp      901
sype_port_t                    tcp      9911
sype_port_t                    udp      9911
syslogd_port_t                 tcp      6514
syslogd_port_t                 udp      514, 6514
telnetd_port_t                 tcp      23
tftp_port_t                    udp      69
tor_port_t                     tcp      6969, 9001, 9030, 9050, 9051
traceroute_port_t              udp      64000-64010
transproxy_port_t              tcp      8081
ups_port_t                     tcp      3493
uucpd_port_t                   tcp      540
varnishd_port_t                tcp      6081, 6082
virt_migration_port_t          tcp      49152-49216
virt_port_t                    tcp      16509, 16514
virt_port_t                    udp      16509, 16514
vnc_port_t                     tcp      5900-5999
wccp_port_t                    udp      2048
websm_port_t                   tcp      9090
websm_port_t                   udp      9090
whois_port_t                   tcp      43, 4321
whois_port_t                   udp      43, 4321
xdmcp_port_t                   tcp      177
xdmcp_port_t                   udp      177
xen_port_t                     tcp      8002
xfs_port_t                     tcp      7100
xserver_port_t                 tcp      6000-6150
zarafa_port_t                  tcp      236, 237
zebra_port_t                   tcp      2600-2604, 2606
zebra_port_t                   udp      2600-2604, 2606
zented_port_t                  tcp      1229
zented_port_t                  udp      1229
zope_port_t                    tcp      8021

2011-11-24 05:17:31::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:17:31::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:17:31::DEBUG::engine_validators::119::root:: http_port_t =
[80, 443, 488, 8008, 8009, 8443]
2011-11-24 05:17:31::DEBUG::engine_validators::62::root:: Validating 443 as
a valid TCP Port
2011-11-24 05:17:31::DEBUG::common_utils::398::root:: Checking if TCP port
443 is open by any process
2011-11-24 05:17:31::DEBUG::common_utils::434::root:: Executing command -->
'/usr/sbin/lsof -i -n -P'
2011-11-24 05:17:31::DEBUG::common_utils::472::root:: output = COMMAND
PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
rpcbind   1225      rpc    6u  IPv4   9182      0t0  UDP *:111
rpcbind   1225      rpc    7u  IPv4   9186      0t0  UDP *:976
rpcbind   1225      rpc    8u  IPv4   9187      0t0  TCP *:111 (LISTEN)
rpcbind   1225      rpc    9u  IPv6   9189      0t0  UDP *:111
rpcbind   1225      rpc   10u  IPv6   9191      0t0  UDP *:976
rpcbind   1225      rpc   11u  IPv6   9192      0t0  TCP *:111 (LISTEN)
rpc.statd 1243  rpcuser    5r  IPv4   9372      0t0  UDP *:995
rpc.statd 1243  rpcuser    8u  IPv4   9376      0t0  UDP *:37288
rpc.statd 1243  rpcuser    9u  IPv4   9380      0t0  TCP *:45184 (LISTEN)
rpc.statd 1243  rpcuser   10u  IPv6   9384      0t0  UDP *:53291
rpc.statd 1243  rpcuser   11u  IPv6   9388      0t0  TCP *:59962 (LISTEN)
sshd      1350     root    3u  IPv4   9728      0t0  TCP *:22 (LISTEN)
sshd      1350     root    4u  IPv6   9730      0t0  TCP *:22 (LISTEN)
sshd      1386     root    3r  IPv4   9969      0t0  TCP 192.168.91.166:22->
62.231.2.201:16232 (ESTABLISHED)
sshd      1433     root    3r  IPv4  10426      0t0  TCP 192.168.91.166:22->
62.231.2.201:15167 (ESTABLISHED)
postmaste 7175 postgres    3u  IPv6  45181      0t0  TCP [::1]:5432 (LISTEN)
postmaste 7175 postgres    4u  IPv4  45182      0t0  TCP 127.0.0.1:5432(LISTEN)
postmaste 7175 postgres    7u  IPv6  45193      0t0  UDP
[::1]:58773->[::1]:58773
postmaste 7179 postgres    7u  IPv6  45193      0t0  UDP
[::1]:58773->[::1]:58773
postmaste 7180 postgres    7u  IPv6  45193      0t0  UDP
[::1]:58773->[::1]:58773
postmaste 7181 postgres    7u  IPv6  45193      0t0  UDP
[::1]:58773->[::1]:58773
postmaste 7182 postgres    7u  IPv6  45193      0t0  UDP
[::1]:58773->[::1]:58773
engine-se 8001     root   27u  IPv4  48231      0t0  TCP
192.168.91.166:33822->80.239.156.215:443 (ESTABLISHED)
engine-se 8001     root   33u  IPv4  48710      0t0  TCP
192.168.91.166:36829->80.68.249.121:80 (CLOSE_WAIT)

2011-11-24 05:17:31::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:17:31::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:17:31::DEBUG::common_utils::434::root:: Executing command -->
'/usr/sbin/semanage port -l'
2011-11-24 05:17:33::DEBUG::common_utils::472::root:: output = SELinux Port
Type              Proto    Port Number

afs_bos_port_t                 udp      7007
afs_client_port_t              udp      7001
afs_fs_port_t                  tcp      2040
afs_fs_port_t                  udp      7000, 7005
afs_ka_port_t                  udp      7004
afs_pt_port_t                  udp      7002
afs_vl_port_t                  udp      7003
agentx_port_t                  tcp      705
agentx_port_t                  udp      705
amanda_port_t                  tcp      10080-10083
amanda_port_t                  udp      10080-10082
amavisd_recv_port_t            tcp      10024
amavisd_send_port_t            tcp      10025
amqp_port_t                    tcp      5671, 5672
amqp_port_t                    udp      5671, 5672
aol_port_t                     tcp      5190-5193
aol_port_t                     udp      5190-5193
apcupsd_port_t                 tcp      3551
apcupsd_port_t                 udp      3551
apertus_ldp_port_t             tcp      539
apertus_ldp_port_t             udp      539
asterisk_port_t                tcp      1720
asterisk_port_t                udp      2427, 2727, 4569
audit_port_t                   tcp      60
auth_port_t                    tcp      113
bgp_port_t                     tcp      179, 2605
bgp_port_t                     udp      179, 2605
boinc_port_t                   tcp      31416
certmaster_port_t              tcp      51235
chronyd_port_t                 udp      323
clamd_port_t                   tcp      3310
clockspeed_port_t              udp      4041
cluster_port_t                 tcp      5149, 40040, 50006-50008
cluster_port_t                 udp      5149, 50006-50008
cma_port_t                     tcp      1050
cma_port_t                     udp      1050
cobbler_port_t                 tcp      25151
commplex_port_t                tcp      5000, 5001
commplex_port_t                udp      5000, 5001
comsat_port_t                  udp      512
ctdb_port_t                    tcp      4379
ctdb_port_t                    udp      4379
cvs_port_t                     tcp      2401
cvs_port_t                     udp      2401
cyphesis_port_t                tcp      6767, 6769, 6780-6799
cyphesis_port_t                udp      32771
dbskkd_port_t                  tcp      1178
dcc_port_t                     udp      6276, 6277
dccm_port_t                    tcp      5679
dccm_port_t                    udp      5679
dhcpc_port_t                   tcp      68, 546
dhcpc_port_t                   udp      68, 546
dhcpd_port_t                   tcp      547, 548, 647, 847, 7911
dhcpd_port_t                   udp      67, 547, 548, 647, 847
dict_port_t                    tcp      2628
distccd_port_t                 tcp      3632
dns_port_t                     tcp      53
dns_port_t                     udp      53
dogtag_port_t                  tcp      7390
epmap_port_t                   tcp      135
epmap_port_t                   udp      135
festival_port_t                tcp      1314
fingerd_port_t                 tcp      79
flash_port_t                   tcp      843, 1935
flash_port_t                   udp      1935
ftp_data_port_t                tcp      20
ftp_port_t                     tcp      21, 990
ftp_port_t                     udp      990
gatekeeper_port_t              tcp      1721, 7000
gatekeeper_port_t              udp      1718, 1719
giftd_port_t                   tcp      1213
git_port_t                     tcp      9418
git_port_t                     udp      9418
gopher_port_t                  tcp      70
gopher_port_t                  udp      70
gpsd_port_t                    tcp      2947
hddtemp_port_t                 tcp      7634
hi_reserved_port_t             tcp      512-1023
hi_reserved_port_t             udp      512-1023
howl_port_t                    tcp      5335
howl_port_t                    udp      5353
hplip_port_t                   tcp      1782, 2207, 2208, 8290, 50000,
50002, 8292, 9100, 9101, 9102, 9220, 9221, 9222, 9280, 9281, 9282, 9290,
9291, 9292
http_cache_port_t              tcp      3128, 8080, 8118, 8123, 10001-10010
http_cache_port_t              udp      3130
http_port_t                    tcp      80, 443, 488, 8008, 8009, 8443
i18n_input_port_t              tcp      9010
imaze_port_t                   tcp      5323
imaze_port_t                   udp      5323
inetd_child_port_t             tcp      1, 7, 9, 13, 19, 37, 512, 543, 544,
891, 892, 2105, 5666
inetd_child_port_t             udp      1, 7, 9, 13, 19, 37, 891, 892
innd_port_t                    tcp      119
ionixnetmon_port_t             tcp      7410
ionixnetmon_port_t             udp      7410
ipmi_port_t                    udp      623, 664
ipp_port_t                     tcp      631, 8610-8614
ipp_port_t                     udp      631, 8610-8614
ipsecnat_port_t                tcp      4500
ipsecnat_port_t                udp      4500
ircd_port_t                    tcp      6667
isakmp_port_t                  udp      500
iscsi_port_t                   tcp      3260
isns_port_t                    tcp      3205
isns_port_t                    udp      3205
jabber_client_port_t           tcp      5222, 5223
jabber_interserver_port_t      tcp      5269
jabber_router_port_t           tcp      5347
jboss_management_port_t        tcp      4712, 9123, 18001
jboss_management_port_t        udp      4712, 9123
kerberos_admin_port_t          tcp      749
kerberos_master_port_t         tcp      4444
kerberos_master_port_t         udp      4444
kerberos_password_port_t       tcp      464
kerberos_password_port_t       udp      464
kerberos_port_t                tcp      88, 750
kerberos_port_t                udp      88, 750
kismet_port_t                  tcp      2501
kprop_port_t                   tcp      754
ktalkd_port_t                  udp      517, 518
ldap_port_t                    tcp      389, 636, 3268
ldap_port_t                    udp      389, 636
lirc_port_t                    tcp      8765
lmtp_port_t                    tcp      24
lmtp_port_t                    udp      24
luci_port_t                    tcp      8084
mail_port_t                    tcp      2000, 3905
matahari_port_t                tcp      49000
matahari_port_t                udp      49000
memcache_port_t                tcp      11211
memcache_port_t                udp      11211
mmcc_port_t                    tcp      5050
mmcc_port_t                    udp      5050
monopd_port_t                  tcp      1234
movaz_ssc_port_t               tcp      5252
mpd_port_t                     tcp      6600
msnp_port_t                    tcp      1863
msnp_port_t                    udp      1863
mssql_port_t                   tcp      1433, 1434
mssql_port_t                   udp      1433, 1434
munin_port_t                   tcp      4949
munin_port_t                   udp      4949
mysqld_port_t                  tcp      1186, 3306, 63132-63164
mysqlmanagerd_port_t           tcp      2273
nessus_port_t                  tcp      1241
netport_port_t                 tcp      3129
netport_port_t                 udp      3129
netsupport_port_t              tcp      5404, 5405
netsupport_port_t              udp      5404, 5405
nmbd_port_t                    udp      137, 138
ntop_port_t                    tcp      3000, 3001
ntop_port_t                    udp      3000, 3001
ntp_port_t                     udp      123
ocsp_port_t                    tcp      9080
openvpn_port_t                 tcp      1194
openvpn_port_t                 udp      1194
oracle_port_t                  tcp      1521, 2483, 2484
oracle_port_t                  udp      1521, 2483, 2484
pegasus_http_port_t            tcp      5988
pegasus_https_port_t           tcp      5989
pgpkeyserver_port_t            tcp      11371
pgpkeyserver_port_t            udp      11371
pingd_port_t                   tcp      9125
piranha_port_t                 tcp      3636
pki_ca_port_t                  tcp      9180, 9701, 9443-9447
pki_kra_port_t                 tcp      10180, 10701, 10443-10446
pki_ocsp_port_t                tcp      11180, 11701, 11443-11446
pki_ra_port_t                  tcp      12888, 12889
pki_tks_port_t                 tcp      13180, 13701, 13443-13446
pki_tps_port_t                 tcp      7888, 7889
pktcable_port_t                tcp      2126, 3198
pktcable_port_t                udp      2126, 3198
pop_port_t                     tcp      106, 109, 110, 143, 220, 993, 995,
1109
portmap_port_t                 tcp      111
portmap_port_t                 udp      111
postfix_policyd_port_t         tcp      10031
postgresql_port_t              tcp      5432
postgrey_port_t                tcp      60000
prelude_port_t                 tcp      4690
prelude_port_t                 udp      4690
presence_port_t                tcp      5298
presence_port_t                udp      5298
printer_port_t                 tcp      515
ptal_port_t                    tcp      5703
pulseaudio_port_t              tcp      4713
puppet_port_t                  tcp      8140
pxe_port_t                     udp      4011
pyzor_port_t                   udp      24441
radacct_port_t                 udp      1646, 1813
radius_port_t                  udp      1645, 1812
radsec_port_t                  tcp      2083
razor_port_t                   tcp      2703
repository_port_t              tcp      6363
ricci_modcluster_port_t        tcp      16851
ricci_modcluster_port_t        udp      16851
ricci_port_t                   tcp      11111
ricci_port_t                   udp      11111
rlogind_port_t                 tcp      513
rndc_port_t                    tcp      953
router_port_t                  tcp      521
router_port_t                  udp      520, 521
rsh_port_t                     tcp      514
rsync_port_t                   tcp      873
rsync_port_t                   udp      873
rwho_port_t                    udp      513
sap_port_t                     tcp      9875
sap_port_t                     udp      9875
sieve_port_t                   tcp      4190
sip_port_t                     tcp      5060, 5061
sip_port_t                     udp      5060, 5061
sixxsconfig_port_t             tcp      3874
sixxsconfig_port_t             udp      3874
smbd_port_t                    tcp      137-139, 445
smtp_port_t                    tcp      25, 465, 587
snmp_port_t                    tcp      161-162, 199, 1161
snmp_port_t                    udp      161-162
soundd_port_t                  tcp      8000, 9433, 16001
spamd_port_t                   tcp      783
speech_port_t                  tcp      8036
squid_port_t                   tcp      3401, 4827
squid_port_t                   udp      3401, 4827
ssh_port_t                     tcp      22
streaming_port_t               tcp      1755
streaming_port_t               udp      1755
swat_port_t                    tcp      901
sype_port_t                    tcp      9911
sype_port_t                    udp      9911
syslogd_port_t                 tcp      6514
syslogd_port_t                 udp      514, 6514
telnetd_port_t                 tcp      23
tftp_port_t                    udp      69
tor_port_t                     tcp      6969, 9001, 9030, 9050, 9051
traceroute_port_t              udp      64000-64010
transproxy_port_t              tcp      8081
ups_port_t                     tcp      3493
uucpd_port_t                   tcp      540
varnishd_port_t                tcp      6081, 6082
virt_migration_port_t          tcp      49152-49216
virt_port_t                    tcp      16509, 16514
virt_port_t                    udp      16509, 16514
vnc_port_t                     tcp      5900-5999
wccp_port_t                    udp      2048
websm_port_t                   tcp      9090
websm_port_t                   udp      9090
whois_port_t                   tcp      43, 4321
whois_port_t                   udp      43, 4321
xdmcp_port_t                   tcp      177
xdmcp_port_t                   udp      177
xen_port_t                     tcp      8002
xfs_port_t                     tcp      7100
xserver_port_t                 tcp      6000-6150
zarafa_port_t                  tcp      236, 237
zebra_port_t                   tcp      2600-2604, 2606
zebra_port_t                   udp      2600-2604, 2606
zented_port_t                  tcp      1229
zented_port_t                  udp      1229
zope_port_t                    tcp      8021

2011-11-24 05:17:33::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:17:33::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:17:33::DEBUG::engine_validators::119::root:: http_port_t =
[80, 443, 488, 8008, 8009, 8443]
2011-11-24 05:17:33::DEBUG::engine-setup::1597::root:: going over group
ALL_PARAMS
2011-11-24 05:17:33::INFO::engine-setup::1606::root:: Comparing
pre-conditions; condition: 'True', and match: 'True'
2011-11-24 05:17:33::DEBUG::engine-setup::575::root:: setting default value
(no) for key (RANDOM_PASSWORDS)
2011-11-24 05:17:33::DEBUG::engine-setup::575::root:: setting default value
(00:1A:4A:A8:5B:00-00:1A:4A:A8:5B:FF) for key (MAC_RANGE)
2011-11-24 05:17:34::INFO::engine_validators::307::root:: Validating
rhevm8.lab.topsonline.ru as a FQDN
2011-11-24 05:17:34::INFO::engine_validators::216::root:: validating
rhevm8.lab.topsonline.ru as a valid domain string
2011-11-24 05:17:34::DEBUG::common_utils::434::root:: Executing command -->
'/sbin/ip addr'
2011-11-24 05:17:34::DEBUG::common_utils::472::root:: output = 1: lo:
<LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen
1000
    link/ether 00:21:5a:ac:0b:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.91.166/25 brd 192.168.91.255 scope global eth0
    inet6 fe80::221:5aff:feac:bb6/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:21:5a:ac:0b:dc brd ff:ff:ff:ff:ff:ff

2011-11-24 05:17:34::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:17:34::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:17:34::DEBUG::common_utils::593::root:: Found IP Address:
192.168.91.166
2011-11-24 05:17:34::DEBUG::common_utils::434::root:: Executing command -->
'/usr/bin/nslookup rhevm8.lab.topsonline.ru'
2011-11-24 05:17:34::DEBUG::common_utils::472::root:: output = Server:
    192.168.90.11
Address:    192.168.90.11#53

Name:    rhevm8.lab.topsonline.ru
Address: 192.168.91.166


2011-11-24 05:17:34::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:17:34::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:17:34::DEBUG::engine_validators::526::root::
rhevm8.lab.topsonline.ru resolved into 192.168.91.166
2011-11-24 05:17:34::DEBUG::common_utils::434::root:: Executing command -->
'/usr/bin/nslookup 192.168.91.166'
2011-11-24 05:17:34::DEBUG::common_utils::472::root:: output = Server:
    192.168.90.11
Address:    192.168.90.11#53

166.91.168.192.in-addr.arpa    name = rhevm8.lab.topsonline.ru.


2011-11-24 05:17:34::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:17:34::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:17:34::DEBUG::engine_validators::526::root:: 192.168.91.166
resolved into rhevm8.lab.topsonline.ru
2011-11-24 05:17:39::DEBUG::engine_validators::161::root:: Validating
password
2011-11-24 05:17:42::DEBUG::engine-setup::654::root:: Param confirmation
passed, value for both questions is identical
2011-11-24 05:17:43::INFO::engine_validators::388::root:: validating
organization name
2011-11-24 05:17:44::INFO::engine_validators::182::root:: Validating both
as part of ['virt', 'gluster', 'both']
2011-11-24 05:17:47::INFO::engine_validators::182::root:: Validating FC as
part of ['NFS', 'FC', 'ISCSI', 'POSIXFS']
2011-11-24 05:17:48::INFO::engine_validators::182::root:: Validating local
as part of ['remote', 'local']
2011-11-24 05:17:48::DEBUG::engine-setup::1597::root:: going over group
REMOTE_DB
2011-11-24 05:17:48::INFO::engine-setup::1606::root:: Comparing
pre-conditions; condition: 'False', and match: 'True'
2011-11-24 05:17:48::DEBUG::engine-setup::1635::root:: no post condition
check for group REMOTE_DB
2011-11-24 05:17:48::DEBUG::engine-setup::1597::root:: going over group
LOCAL_DB
2011-11-24 05:17:48::INFO::engine-setup::1606::root:: Comparing
pre-conditions; condition: 'False', and match: 'False'
2011-11-24 05:17:51::DEBUG::engine_validators::161::root:: Validating
password
2011-11-24 05:17:53::DEBUG::engine-setup::654::root:: Param confirmation
passed, value for both questions is identical
2011-11-24 05:17:53::DEBUG::engine-setup::1597::root:: going over group NFS
2011-11-24 05:17:56::INFO::engine_validators::182::root:: Validating no as
part of ['yes', 'no']
2011-11-24 05:17:56::INFO::engine-setup::1606::root:: Comparing
pre-conditions; condition: 'no', and match: 'yes'
2011-11-24 05:17:56::DEBUG::engine-setup::1635::root:: no post condition
check for group NFS
2011-11-24 05:17:56::DEBUG::engine-setup::1597::root:: going over group
IPTABLES
2011-11-24 05:17:56::INFO::engine-setup::1606::root:: Comparing
pre-conditions; condition: 'True', and match: 'True'
2011-11-24 05:17:57::INFO::engine_validators::182::root:: Validating no as
part of ['None', 'IPTables']
2011-11-24 05:18:00::INFO::engine_validators::182::root:: Validating none
as part of ['None', 'IPTables']
2011-11-24 05:18:00::INFO::engine-setup::1678::root:: *** User input
summary ***
2011-11-24 05:18:00::INFO::engine-setup::1691::root::
override-httpd-config: yes
2011-11-24 05:18:00::INFO::engine-setup::1691::root:: http-port: 80
2011-11-24 05:18:00::INFO::engine-setup::1691::root:: https-port: 443
2011-11-24 05:18:00::INFO::engine-setup::1691::root:: host-fqdn:
rhevm8.lab.topsonline.ru
2011-11-24 05:18:00::INFO::engine-setup::1687::root:: auth-pass: ********
2011-11-24 05:18:00::INFO::engine-setup::1691::root:: org-name:
lab.topsonline.ru
2011-11-24 05:18:00::INFO::engine-setup::1691::root:: application-mode: both
2011-11-24 05:18:00::INFO::engine-setup::1691::root:: default-dc-type: FC
2011-11-24 05:18:00::INFO::engine-setup::1691::root:: db-remote-install:
local
2011-11-24 05:18:00::INFO::engine-setup::1687::root:: db-local-pass:
********
2011-11-24 05:18:00::INFO::engine-setup::1691::root:: config-nfs: no
2011-11-24 05:18:00::INFO::engine-setup::1691::root:: override-firewall:
none
2011-11-24 05:18:00::INFO::engine-setup::1693::root:: *** User input
summary ***
2011-11-24 05:18:00::DEBUG::common_utils::971::root:: asking user: Proceed
with the configuration listed above? (yes|no):
2011-11-24 05:18:02::DEBUG::common_utils::975::root:: user answered: y
2011-11-24 05:18:02::DEBUG::engine-setup::1712::root:: user chose to accept
user parameters
2011-11-24 05:18:02::DEBUG::engine-setup::2126::root:: {'ORG_NAME': '
lab.topsonline.ru', 'HOST_FQDN': 'rhevm8.lab.topsonline.ru',
'OVERRIDE_FIREWALL': 'none', 'HTTP_PORT': '80', 'APPLICATION_MODE': 'both',
'HTTPS_PORT': '443', 'AUTH_PASS_CONFIRMED': '********', 'DC_TYPE_ENUM':
<common_utils.Enum object at 0x298eb50>, 'AUTH_PASS': '********',
'DB_LOCAL_PASS': '********', 'RANDOM_PASSWORDS': 'no',
'OVERRIDE_HTTPD_CONFIG': 'yes', 'APPLICATION_MODE_ENUM': <common_utils.Enum
object at 0x254a810>, 'MAC_RANGE': '00:1A:4A:A8:5B:00-00:1A:4A:A8:5B:FF',
'DB_LOCAL_PASS_CONFIRMED': '********', 'CONFIG_NFS': 'no',
'DB_REMOTE_INSTALL': 'local', 'DC_TYPE': 'FC'}
2011-11-24 05:18:02::DEBUG::engine-setup::2129::root:: Entered
Configuration stage
2011-11-24 05:18:02::DEBUG::setup_sequences::59::root:: running
setMaxSharedMemory
2011-11-24 05:18:02::DEBUG::common_utils::434::root:: Executing command -->
'/sbin/sysctl -b kernel.shmmax'
2011-11-24 05:18:02::DEBUG::common_utils::472::root:: output = 68719476736
2011-11-24 05:18:02::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:18:02::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:18:02::DEBUG::engine-setup::1783::root:: current shared
memory max in kernel is 68719476736, there is no need to update the kernel
parameters
2011-11-24 05:18:02::DEBUG::setup_sequences::59::root:: running
_findJavaHome
2011-11-24 05:18:02::DEBUG::common_utils::434::root:: Executing command -->
'/usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java -version'
2011-11-24 05:18:02::DEBUG::common_utils::472::root:: output =
2011-11-24 05:18:02::DEBUG::common_utils::473::root:: stderr = java version
"1.7.0_09-icedtea"
OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

2011-11-24 05:18:02::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:18:02::DEBUG::common_utils::434::root:: Executing command -->
'/usr/lib/jvm/java-1.7.0-openjdk.x86_64/bin/java -version'
2011-11-24 05:18:02::DEBUG::common_utils::472::root:: output =
2011-11-24 05:18:02::DEBUG::common_utils::473::root:: stderr = java version
"1.7.0_09-icedtea"
OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

2011-11-24 05:18:02::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:18:02::DEBUG::common_utils::434::root:: Executing command -->
'/usr/lib/jvm/jre-1.5.0-gcj/bin/java -version'
2011-11-24 05:18:02::DEBUG::common_utils::472::root:: output = java version
"1.5.0"
gij (GNU libgcj) version 4.4.7 20120313 (Red Hat 4.4.7-3)

Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

2011-11-24 05:18:02::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:18:02::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:18:02::DEBUG::common_utils::1378::root:: Java version "1.5.0"
is not supported, it should start with "1.7.0".
2011-11-24 05:18:02::DEBUG::common_utils::1412::root:: The java version
"1.5.0" is not supported.
2011-11-24 05:18:02::DEBUG::common_utils::1430::root:: JVM path
"/usr/lib/jvm/jre-1.7.0-openjdk.x86_64" doesn't contain the Java compiler.
2011-11-24 05:18:02::DEBUG::setup_sequences::59::root:: running _createCA
2011-11-24 05:18:02::DEBUG::engine-setup::923::root:: updating
/etc/pki/ovirt-engine/cacert.template
2011-11-24 05:18:02::DEBUG::engine-setup::923::root:: updating
/etc/pki/ovirt-engine/cert.template
2011-11-24 05:18:02::DEBUG::engine-setup::797::root:: Date string is
111123011802+0000
2011-11-24 05:18:02::DEBUG::engine-setup::804::root:: truncated HOST_FQDN '
rhevm8.lab.topsonline.ru' to 'rhevm8.lab.topsonline.ru'. sized reduced to
24..
2011-11-24 05:18:02::DEBUG::engine-setup::806::root:: using unique CN:
'rhevm8.lab.topsonline.ru.77279' for CA certificate
2011-11-24 05:18:02::DEBUG::common_utils::434::root:: Executing command -->
'/etc/pki/ovirt-engine/installCA.sh rhevm8.lab.topsonline.ru US
lab.topsonline.ru engine ******** 111123011802+0000 /etc/pki/ovirt-engine
rhevm8.lab.topsonline.ru.77279'
2011-11-24 05:18:03::DEBUG::common_utils::472::root:: output =
} Creating CA...

> Importing CA certificate...

} Creating client certificates for oVirt...

}} Creating Engine Key...

}} Signing certificate request...

}} Creating PKCS#12 store...

}} Creating Engine Key...

}} Signing certificate request...

}} Creating PKCS#12 store...

2011-11-24 05:18:03::DEBUG::common_utils::473::root:: stderr = Generating
RSA private key, 2048 bit long modulus
...............+++
..................................................+++
e is 65537 (0x10001)
Using configuration from openssl.conf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
organizationName      :PRINTABLE:'lab.topsonline.ru'
commonName            :PRINTABLE:'CA-rhevm8.lab.topsonline.ru.77279'
Certificate is to be certified until Nov 21 01:18:02 2021 GMT (3650 days)

Write out database with 1 new entries
Data Base Updated
Certificate was added to keystore
Generating a 2048 bit RSA private key
...................+++
................+++
writing new private key to '/tmp/engine.8216.key'
-----
Using configuration from openssl.conf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
organizationName      :ASN.1 12:'lab.topsonline.ru'
commonName            :ASN.1 12:'rhevm8.lab.topsonline.ru'
Certificate is to be certified until Oct 28 01:18:03 2016 GMT (1800 days)

Write out database with 1 new entries
Data Base Updated
Generating a 2048 bit RSA private key
................................................................................................................+++
...................................................+++
writing new private key to '/tmp/engine.8216.key'
-----
Using configuration from openssl.conf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
organizationName      :ASN.1 12:'lab.topsonline.ru'
commonName            :ASN.1 12:'rhevm8.lab.topsonline.ru'
Certificate is to be certified until Oct 28 01:18:03 2016 GMT (1800 days)

Write out database with 1 new entries
Data Base Updated

2011-11-24 05:18:03::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:18:03::DEBUG::common_utils::434::root:: Executing command -->
'/usr/bin/openssl pkcs12 -in /etc/pki/ovirt-engine/keys/engine.p12 -passin
pass:******** -nodes -nocerts -out /etc/pki/ovirt-engine/keys/engine_id_rsa'
2011-11-24 05:18:03::DEBUG::common_utils::472::root:: output =
2011-11-24 05:18:03::DEBUG::common_utils::473::root:: stderr = MAC verified
OK

2011-11-24 05:18:03::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:18:03::DEBUG::common_utils::434::root:: Executing command -->
'/usr/bin/openssl pkcs12 -in /etc/pki/ovirt-engine/keys/apache.p12 -passin
pass:******** -nodes -nocerts -out
/etc/pki/ovirt-engine/keys/apache.key.nopass'
2011-11-24 05:18:03::DEBUG::common_utils::472::root:: output =
2011-11-24 05:18:03::DEBUG::common_utils::473::root:: stderr = MAC verified
OK

2011-11-24 05:18:03::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:18:03::DEBUG::common_utils::434::root:: Executing command -->
'/usr/bin/openssl x509 -in /etc/pki/ovirt-engine/ca.pem -fingerprint -noout'
2011-11-24 05:18:03::DEBUG::common_utils::472::root:: output = SHA1
Fingerprint=DC:C2:0F:0A:A6:18:0C:E7:99:42:A1:50:E2:C5:10:CD:E3:DE:6B:2B

2011-11-24 05:18:03::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:18:03::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:18:03::DEBUG::common_utils::434::root:: Executing command -->
'/usr/bin/ssh-keygen -yf /etc/pki/ovirt-engine/keys/engine_id_rsa'
2011-11-24 05:18:03::DEBUG::common_utils::472::root:: output = ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQDTS3g+L05Mrevw/yGIxmoOq6k1Obrrq/cKazaNIxu4zVojJtWa6nnK12l8khy3zcT323aKHN78RUg+caIusnVPgPsW2dUPjW377LObJHXhqzswNrpd3h9Z214nJ+axWKnH6rG7bqwHOIE5+ItHd7QWXOJ169+QwithMuI8fVdIyAHsVyeA/gV9irKcCZ9oElw2dd70WQgVSO72kcIui7mpEkIbdx3WcV+9bGJa6pszP26mlxY5/ifxsMFZwfALoZWLgtVURge8+HELJYQ7O0tjBXZjxPWVN4DOCUQoloVru2ePC7OP77sq424bmoSWXgG7P4VUAE7XBg5JmwIZeMgT

2011-11-24 05:18:03::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:18:03::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:18:03::DEBUG::common_utils::434::root:: Executing command -->
'/usr/bin/ssh-keygen -lf /tmp/tmpvYtF4U.pub'
2011-11-24 05:18:03::DEBUG::common_utils::472::root:: output = 2048
c0:2e:c5:ff:60:35:43:9c:31:ad:1b:b5:18:f6:91:b3 /tmp/tmpvYtF4U.pub (RSA)

2011-11-24 05:18:03::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:18:03::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:18:03::DEBUG::common_utils::1309::root:: chown
/etc/pki/ovirt-engine/private to 108:108
2011-11-24 05:18:03::DEBUG::engine-setup::910::root:: changing directory
permissions for /etc/pki/ovirt-engine/private to 0750
2011-11-24 05:18:03::DEBUG::common_utils::1309::root:: chown
/etc/pki/ovirt-engine/ca.pem to 108:108
2011-11-24 05:18:03::DEBUG::engine-setup::913::root:: changing file
permissions for /etc/pki/ovirt-engine/ca.pem to 0640
2011-11-24 05:18:03::DEBUG::common_utils::1309::root:: chown
/etc/pki/ovirt-engine/keys/engine.p12 to 108:108
2011-11-24 05:18:03::DEBUG::engine-setup::913::root:: changing file
permissions for /etc/pki/ovirt-engine/keys/engine.p12 to 0640
2011-11-24 05:18:03::DEBUG::common_utils::1309::root:: chown
/etc/pki/ovirt-engine/private/ca.pem to 108:108
2011-11-24 05:18:03::DEBUG::engine-setup::913::root:: changing file
permissions for /etc/pki/ovirt-engine/private/ca.pem to 0640
2011-11-24 05:18:03::DEBUG::common_utils::1309::root:: chown
/etc/pki/ovirt-engine/.truststore to 108:108
2011-11-24 05:18:03::DEBUG::engine-setup::913::root:: changing file
permissions for /etc/pki/ovirt-engine/.truststore to 0640
2011-11-24 05:18:03::DEBUG::setup_sequences::59::root:: running
_editSysconfig
2011-11-24 05:18:03::DEBUG::common_utils::781::root:: found existing pgpass
file /etc/ovirt-engine/.pgpass, fetching DB user value
2011-11-24 05:18:03::DEBUG::common_utils::1148::root:: Loading text file
handler
2011-11-24 05:18:03::DEBUG::common_utils::1180::root:: Engine has been
configured
2011-11-24 05:18:03::DEBUG::setup_sequences::59::root:: running
_updatePgPassFile
2011-11-24 05:18:03::DEBUG::engine-setup::1348::root:: found existing
pgpass file, backing current to
/etc/ovirt-engine/.pgpass.2011_11_24_05_18_03
2011-11-24 05:18:03::INFO::engine-setup::1372::root:: Using default db
credentials
2011-11-24 05:18:03::DEBUG::engine-setup::1973::root:: Checking if db is
already installed..
2011-11-24 05:18:03::DEBUG::engine-setup::1974::root:: Checking the
presence of .pgpass file
2011-11-24 05:18:03::DEBUG::common_utils::481::root:: running sql query
'select 1' on db server: 'localhost'.
2011-11-24 05:18:03::DEBUG::common_utils::434::root:: Executing command -->
'/usr/bin/psql -h localhost -p 5432 -U postgres -d engine -c select 1'
2011-11-24 05:18:03::DEBUG::common_utils::472::root:: output =
2011-11-24 05:18:03::DEBUG::common_utils::473::root:: stderr = psql:
FATAL:  database "engine" does not exist

2011-11-24 05:18:03::DEBUG::common_utils::474::root:: retcode = 2
2011-11-24 05:18:03::DEBUG::engine-setup::1973::root:: Checking if db is
already installed..
2011-11-24 05:18:03::DEBUG::engine-setup::1974::root:: Checking the
presence of .pgpass file
2011-11-24 05:18:03::DEBUG::common_utils::481::root:: running sql query
'select 1' on db server: 'localhost'.
2011-11-24 05:18:03::DEBUG::common_utils::434::root:: Executing command -->
'/usr/bin/psql -h localhost -p 5432 -U postgres -d engine -c select 1'
2011-11-24 05:18:03::DEBUG::common_utils::472::root:: output =
2011-11-24 05:18:03::DEBUG::common_utils::473::root:: stderr = psql:
FATAL:  database "engine" does not exist

2011-11-24 05:18:03::DEBUG::common_utils::474::root:: retcode = 2
2011-11-24 05:18:03::DEBUG::setup_sequences::59::root:: running
_encryptDBPass
2011-11-24 05:18:03::DEBUG::common_utils::434::root:: Executing command -->
'/usr/share/ovirt-engine/bin/engine-encrypt-passwd.sh ********'
2011-11-24 05:18:04::DEBUG::common_utils::472::root:: output = Encoded
password: -25bb02aac8b8140a64265f4892564719

2011-11-24 05:18:04::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:18:04::DEBUG::common_utils::474::root:: retcode = 0
2011-11-24 05:18:04::DEBUG::common_utils::676::root:: found new parsed
string: -25bb02aac8b8140a64265f4892564719
2011-11-24 05:18:04::DEBUG::setup_sequences::59::root:: running
_configEncryptedPass
2011-11-24 05:18:04::DEBUG::common_utils::1208::root:: Encrypting database
password.
2011-11-24 05:18:04::DEBUG::common_utils::781::root:: found existing pgpass
file /etc/ovirt-engine/.pgpass, fetching DB user value
2011-11-24 05:18:04::DEBUG::setup_sequences::59::root:: running _createDB
2011-11-24 05:18:04::DEBUG::engine-setup::1105::root:: installing postgres
db
2011-11-24 05:18:04::DEBUG::engine-setup::1108::root:: engine db creation
is logged at
/var/log/ovirt-engine//engine-db-install-2011_11_24_05_18_04.log
2011-11-24 05:18:04::DEBUG::common_utils::434::root:: Executing command -->
'/usr/share/ovirt-engine/dbscripts/engine-db-install.sh -l
engine-db-install-2011_11_24_05_18_04.log -w ******** -u postgres -s
localhost -p 5432 -r local'
2011-11-24 05:18:22::DEBUG::common_utils::472::root:: output = Running
local installation
error, failed creating enginedb

2011-11-24 05:18:22::DEBUG::common_utils::473::root:: stderr =
2011-11-24 05:18:22::DEBUG::common_utils::474::root:: retcode = 1
2011-11-24 05:18:22::DEBUG::setup_sequences::62::root:: Traceback (most
recent call last):
  File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in run
    function()
  File "/usr/bin/engine-setup", line 1124, in _createDB
    output, rc = utils.execCmd(cmdList=cmd, failOnError=True,
msg=output_messages.ERR_DB_CREATE_FAILED, maskList=masked_value_set)
  File "/usr/share/ovirt-engine/scripts/common_utils.py", line 477, in
execCmd
    raise Exception(msg)
Exception: Database creation failed

2011-11-24 05:18:22::DEBUG::engine-setup::1965::root:: *** The following
params were used as user input:
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root::
override-httpd-config: yes
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: http-port: 80
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: https-port: 443
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: random-passwords: no
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: mac-range:
00:1A:4A:A8:5B:00-00:1A:4A:A8:5B:FF
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: host-fqdn:
rhevm8.lab.topsonline.ru
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: auth-pass: ********
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: org-name:
lab.topsonline.ru
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: application-mode:
both
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: default-dc-type: FC
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: db-remote-install:
local
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: db-host: localhost
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: db-local-pass:
********
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: config-nfs: no
2011-11-24 05:18:22::DEBUG::engine-setup::1970::root:: override-firewall:
none
2011-11-24 05:18:22::ERROR::engine-setup::2385::root:: Traceback (most
recent call last):
  File "/usr/bin/engine-setup", line 2379, in <module>
    main(confFile)
  File "/usr/bin/engine-setup", line 2162, in main
    runSequences()
  File "/usr/bin/engine-setup", line 2085, in runSequences
    controller.runAllSequences()
  File "/usr/share/ovirt-engine/scripts/setup_controller.py", line 54, in
runAllSequences
    sequence.run()
  File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 154, in
run
    step.run()
  File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in run
    function()
  File "/usr/bin/engine-setup", line 1124, in _createDB
    output, rc = utils.execCmd(cmdList=cmd, failOnError=True,
msg=output_messages.ERR_DB_CREATE_FAILED, maskList=masked_value_set)
  File "/usr/share/ovirt-engine/scripts/common_utils.py", line 477, in
execCmd
    raise Exception(msg)
Exception: Database creation failed

]0;root at rhevm8:/usr/lib/jvm[root at rhevm8 jvm]#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130517/97d5a00e/attachment.html>

From lhornyak at redhat.com  Fri May 17 10:18:59 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Fri, 17 May 2013 06:18:59 -0400 (EDT)
Subject: [Engine-devel] SQL procedure - row mapper
In-Reply-To: <5195F9A7.3090003@redhat.com>
References: <5195F9A7.3090003@redhat.com>
Message-ID: <22874352.2868063.1368785939072.JavaMail.root@redhat.com>

Hi Sahina,

Could you share more details what you are trying to do?
A procedure always returns the same structure of data, so maybe it is more simple if you to return all the data you received from the plpgsql stored procedure and then just use the data mapped into the beans to build your own data structures.

Laszlo

----- Original Message -----
> From: "Sahina Bose" <sabose at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, May 17, 2013 11:34:31 AM
> Subject: [Engine-devel] SQL procedure - row mapper
> 
> Hi all,
> 
> In org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler , there's a
> map maintained for procedure name and SimpleJdbcCall.
> 
> If I have the same procedure with different row mappers, this results in
> an error - because the map already contains a mapping for the procedure
> name but with different row mapper.
> 
> Do we intend to support calling the same procedure with different
> RowMappers? If so, I can change this class to handle this.
> 
> thanks
> sahina
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From sabose at redhat.com  Fri May 17 10:43:08 2013
From: sabose at redhat.com (Sahina Bose)
Date: Fri, 17 May 2013 16:13:08 +0530
Subject: [Engine-devel] SQL procedure - row mapper
In-Reply-To: <22874352.2868063.1368785939072.JavaMail.root@redhat.com>
References: <5195F9A7.3090003@redhat.com>
	<22874352.2868063.1368785939072.JavaMail.root@redhat.com>
Message-ID: <519609BC.1040907@redhat.com>

Hi Laszlo,

I wanted a way to return a hook entity (GlusterHookEntity) as well as 
content of the hook. So had a single procedure getGlusterHookById(id 
UUID, includeContent BOOLEAN) but 2 dao methods
getGlusterHook - returns GlusterHookEntity
getGlusterHookContent - returns String (used a RowMapper to get only 
content from resultset)

But the second method caused a ClassCastException due to the first 
RowMapper being used.

Anyways, this is the patch where I changed the implementation to use 
separate sp - http://gerrit.ovirt.org/#/c/14832/

thanks!
sahina

On 05/17/2013 03:48 PM, Laszlo Hornyak wrote:
> Hi Sahina,
>
> Could you share more details what you are trying to do?
> A procedure always returns the same structure of data, so maybe it is more simple if you to return all the data you received from the plpgsql stored procedure and then just use the data mapped into the beans to build your own data structures.
>
> Laszlo
>
> ----- Original Message -----
>> From: "Sahina Bose" <sabose at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Friday, May 17, 2013 11:34:31 AM
>> Subject: [Engine-devel] SQL procedure - row mapper
>>
>> Hi all,
>>
>> In org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler , there's a
>> map maintained for procedure name and SimpleJdbcCall.
>>
>> If I have the same procedure with different row mappers, this results in
>> an error - because the map already contains a mapping for the procedure
>> name but with different row mapper.
>>
>> Do we intend to support calling the same procedure with different
>> RowMappers? If so, I can change this class to handle this.
>>
>> thanks
>> sahina
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From andrej.bagon at arnes.si  Fri May 17 11:49:18 2013
From: andrej.bagon at arnes.si (Andrej Bagon)
Date: Fri, 17 May 2013 13:49:18 +0200
Subject: [Engine-devel] [Spice-devel] ovirt user portal and attach a cd
In-Reply-To: <20130513100956.GF3471@teriyaki>
References: <517E2F37.3010807@arnes.si>
	<1682099686.6160454.1367226745207.JavaMail.root@redhat.com>
	<517E4629.5050001@arnes.si> <5188D045.8030004@arnes.si>
	<518CB3D2.5030605@redhat.com> <518CB76A.3090407@arnes.si>
	<518CB967.2060504@redhat.com> <20130513100956.GF3471@teriyaki>
Message-ID: <5196193E.60901@arnes.si>

Hi,

so is there a chance that a button run once will be placed in the basic
mode right next to the run, stop and suspend. A run once (with the same
feature that has in the expert mode) will deffenetly excuse the
permission "change cd" option.

Thank you.

Best Regards,
Andrej

On 05/13/2013 12:09 PM, Christophe Fergeau wrote:
> Hi,
>
> On Fri, May 10, 2013 at 12:09:59PM +0300, Itamar Heim wrote:
>> On 05/10/2013 12:01 PM, Andrej Bagon wrote:
>>> while pressing the http://elmarco.fedorapeople.org/spice.cab download
>>> link there is a file Not Found. There is no .cab file in the directory
>>> listing either.
>> maybe spice-devel (cc'd) knows of a different one
> I don't think there's an alternate link for this, my understanding is that
> the spice.cab file was there for some private tests, this was not an
> official release.
>
> Christophe



From iheim at redhat.com  Fri May 17 16:09:54 2013
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 17 May 2013 19:09:54 +0300
Subject: [Engine-devel] vm in pool can't be suspended
In-Reply-To: <000001ce529e$3d7e4980$b87adc80$@com>
References: <000001ce529e$3d7e4980$b87adc80$@com>
Message-ID: <51965652.9000807@redhat.com>

On 05/17/2013 04:31 AM, wlbleaboy at 126 wrote:
> Hi all:
>
>           When I create some vms in pool, the vm in pool can?t be suspended,
>
> I don?t know is a bug, or it?s don?t support.
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

iirc, not supported for pool based VMs.


From deadhorseconsulting at gmail.com  Fri May 17 21:30:08 2013
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Fri, 17 May 2013 16:30:08 -0500
Subject: [Engine-devel] cannot attach ISO with latest master
In-Reply-To: <491385764.2974520.1368721335846.JavaMail.root@redhat.com>
References: <CAEWPe=rogGmX_OBNb2f=aMuYucgUqYKiyksDEr75wxfME6uLYQ@mail.gmail.com>
	<CAEWPe=qOXj6oXDb3G=naXFjBH_asHcConWrOJN0wi96CEmgKEg@mail.gmail.com>
	<491385764.2974520.1368721335846.JavaMail.root@redhat.com>
Message-ID: <CAEWPe=pzouowFfeh1xiWYq_448Zeq6Vv_yT0va+cc+wiNgjd5g@mail.gmail.com>

I attempted to test the patch however the result was engine compilation
failure with the webadmin module.
- DHC


On Thu, May 16, 2013 at 11:22 AM, Allon Mureinik <amureini at redhat.com>wrote:

> The following patch (still pending review) should do the trick:
> http://gerrit.ovirt.org/#/c/14818/
>
>
> ------------------------------
>
> *From: *"Dead Horse" <deadhorseconsulting at gmail.com>
> *To: *engine-devel at ovirt.org
> *Sent: *Thursday, May 16, 2013 5:31:23 PM
> *Subject: *Re: [Engine-devel] cannot attach ISO with latest master
>
>
> This occurs only when using "Run Once" to attach an ISO to a VM.
> It is still present in master as of this morning.
> It was reported recently by another user on the user list as well.
> - DHC
>
>
> On Mon, May 13, 2013 at 4:47 PM, Dead Horse <deadhorseconsulting at gmail.com
> > wrote:
>
>> Cannot attach images from the iso storage domain with latest master.
>> VDSM version is latest master as well
>> Host = EL6.4
>>
>> 2013-05-13 16:41:02,184 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
>> (ajp--127.0.0.1-8702-7) [5d889258] START, IsoPrefixVDSCommand(
>> storagePoolId = 0cba78bd-f1b7-438f-afac-acd59fab92ae, ignoreFailoverLimit =
>> false, compatabilityVersion = null), log id: a85d3c0
>> 2013-05-13 16:41:02,196 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
>> (ajp--127.0.0.1-8702-7) [5d889258] FINISH, IsoPrefixVDSCommand, return:
>> /rhev/data-center/mnt/192.168.0.1:_ovirt_dalaran/d6276dc3-1714-4024-9b70-b7971ed5fe35/images/11111111-1111-1111-1111-111111111111,
>> log id: a85d3c0
>> 2013-05-13 16:41:02,328 WARN
>> [org.ovirt.engine.core.bll.RunVmOnceCommand] (ajp--127.0.0.1-8702-7)
>> [5d889258] CanDoAction of action RunVmOnce failed.
>> Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH
>>
>> - DHC
>>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130517/1e088b75/attachment.html>

From snmishra at linux.vnet.ibm.com  Sat May 18 22:19:43 2013
From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com)
Date: Sat, 18 May 2013 15:19:43 -0700
Subject: [Engine-devel] cannot attach ISO with latest master
In-Reply-To: <CAEWPe=pzouowFfeh1xiWYq_448Zeq6Vv_yT0va+cc+wiNgjd5g@mail.gmail.com>
References: <CAEWPe=rogGmX_OBNb2f=aMuYucgUqYKiyksDEr75wxfME6uLYQ@mail.gmail.com>
	<CAEWPe=qOXj6oXDb3G=naXFjBH_asHcConWrOJN0wi96CEmgKEg@mail.gmail.com>
	<491385764.2974520.1368721335846.JavaMail.root@redhat.com>
	<CAEWPe=pzouowFfeh1xiWYq_448Zeq6Vv_yT0va+cc+wiNgjd5g@mail.gmail.com>
Message-ID: <20130518151943.Horde.RppIEZir309Rl-5-wsEEluA@imap.linux.ibm.com>


Quoting Dead Horse <deadhorseconsulting at gmail.com>:

> I attempted to test the patch however the result was engine compilation
> failure with the webadmin module.

Worked for me with latest source + Allon's patch on F18.

-Sharad Mishra

> - DHC
>
>
> On Thu, May 16, 2013 at 11:22 AM, Allon Mureinik <amureini at redhat.com>wrote:
>
>> The following patch (still pending review) should do the trick:
>> http://gerrit.ovirt.org/#/c/14818/
>>
>>
>> ------------------------------
>>
>> *From: *"Dead Horse" <deadhorseconsulting at gmail.com>
>> *To: *engine-devel at ovirt.org
>> *Sent: *Thursday, May 16, 2013 5:31:23 PM
>> *Subject: *Re: [Engine-devel] cannot attach ISO with latest master
>>
>>
>> This occurs only when using "Run Once" to attach an ISO to a VM.
>> It is still present in master as of this morning.
>> It was reported recently by another user on the user list as well.
>> - DHC
>>
>>
>> On Mon, May 13, 2013 at 4:47 PM, Dead Horse <deadhorseconsulting at gmail.com
>> > wrote:
>>
>>> Cannot attach images from the iso storage domain with latest master.
>>> VDSM version is latest master as well
>>> Host = EL6.4
>>>
>>> 2013-05-13 16:41:02,184 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
>>> (ajp--127.0.0.1-8702-7) [5d889258] START, IsoPrefixVDSCommand(
>>> storagePoolId = 0cba78bd-f1b7-438f-afac-acd59fab92ae, ignoreFailoverLimit =
>>> false, compatabilityVersion = null), log id: a85d3c0
>>> 2013-05-13 16:41:02,196 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
>>> (ajp--127.0.0.1-8702-7) [5d889258] FINISH, IsoPrefixVDSCommand, return:
>>> /rhev/data-center/mnt/192.168.0.1:_ovirt_dalaran/d6276dc3-1714-4024-9b70-b7971ed5fe35/images/11111111-1111-1111-1111-111111111111,
>>> log id: a85d3c0
>>> 2013-05-13 16:41:02,328 WARN
>>> [org.ovirt.engine.core.bll.RunVmOnceCommand] (ajp--127.0.0.1-8702-7)
>>> [5d889258] CanDoAction of action RunVmOnce failed.
>>> Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH
>>>
>>> - DHC
>>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>>
>>





From jenkins at ovirt.org  Sat May 18 23:01:49 2013
From: jenkins at ovirt.org (Jenkins ci oVirt Server)
Date: Sun, 19 May 2013 00:01:49 +0100 (BST)
Subject: [Engine-devel] [oVirt jenkins] Weekly report on open tasks for
	ovirt-engine
Message-ID: <1662481514.2226.1368918110365.JavaMail.jenkins@jenkins.ovirt.org>

An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130519/81df3e4a/attachment.html>

From masayag at redhat.com  Sun May 19 06:39:33 2013
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 19 May 2013 02:39:33 -0400 (EDT)
Subject: [Engine-devel] Odd Host Activation with mgmt-if
In-Reply-To: <CAEWPe=qtPwFC2_SEiFV+TdZjbptSy4pig2SOJE7iWAaBHR6YAw@mail.gmail.com>
References: <CAEWPe=oX94UBGnph+5hePnJSyQBneU3-u7QCRwthzmJsZTBm3Q@mail.gmail.com>
	<CAEWPe=qtPwFC2_SEiFV+TdZjbptSy4pig2SOJE7iWAaBHR6YAw@mail.gmail.com>
Message-ID: <700182034.3868949.1368945573602.JavaMail.root@redhat.com>

Could you provide the output of the 'vdsClient -s 0 getVdsCapavilities' for the specific host?

----- Original Message -----
> From: "Dead Horse" <deadhorseconsulting at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Friday, May 17, 2013 12:21:47 AM
> Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> 
> Still puzzling on this all I get for an error when I see it is:
> WARN [org.ovirt.engine.core.bll.
> network.host.SetupNetworksCommand] (pool-5-thread-42) [21543ac] CanDoAction
> of action SetupNetworks failed.
> Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
> ovirtmgmt
> 
> Nothing is logged VDSM wise other then the above standard host activation
> probe.
> 
> - DHC
> 
> 
> 
> On Mon, May 13, 2013 at 1:19 PM, Dead Horse < deadhorseconsulting at gmail.com >
> wrote:
> 
> 
> 
> Seeing this as of late when activating hosts. The odd this is that it reports
> a failure to activate the host (EL6.4) but still does it anyways.
> 
> Engine side:
> 
> 2013-05-13 12:53:38,547 INFO
> [org.ovirt.engine.core.bll.HandleVdsVersionCommand] (pool-5-thread-42)
> [21543ac] Running command: HandleVdsVersionCommand internal: true. Entities
> affected : ID: 15f11023-9746-49de-b33f-e3cc7dca6f65 Type: VDS
> 2013-05-13 12:53:38,549 INFO
> [org.ovirt.engine.core.vdsbroker.ActivateVdsVDSCommand] (pool-5-thread-42)
> [21543ac] FINISH, ActivateVdsVDSCommand, return: Host[durotar], log id:
> 3796a7bd
> 2013-05-13 12:53:38,625 WARN
> [org.ovirt.engine.core.bll.network.host.SetupNetworksCommand]
> (pool-5-thread-42) [21543ac] CanDoAction of action SetupNetworks failed.
> Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
> ovirtmgmt
> 2013-05-13 12:53:39,368 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand]
> (pool-5-thread-42) [21543ac] Activate finished. Lock released. Monitoring
> can run now for host durotar from data-center Azeroth
> 
> VDSM Side:
> 
> Thread-13::DEBUG::2013-05-13 12:53:37,841::BindingXMLRPC::933::vds::(wrapper)
> return getCapabilities with {'status': {'message': 'Done', 'code': 0},
> 'info': {'HBAInventory': {'iSCSI': [{'InitiatorName':
> 'iqn.2012-09.net.azeroth:durotar'}], 'FC': []}, 'packages2': {'kernel':
> {'release': '358.6.1.el6.x86_64', 'buildtime': 1366751713.0, 'version':
> '2.6.32'}, 'glusterfs-rdma': {'release': '0.3.alpha3.el6', 'buildtime':
> 1367604893L, 'version': '3.4.0'}, 'glusterfs-fuse': {'release':
> '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'},
> 'spice-server': {'release': '12.el6', 'buildtime': 1361573005L, 'version':
> '0.12.0'}, 'vdsm': {'release': '17.el6', 'buildtime': 1368196305L,
> 'version': '4.10.3'}, 'qemu-kvm': {'release': '2.355.el6_4.2', 'buildtime':
> 1362691270L, 'version': '0.12.1.2'}, 'qemu-img': {'release':
> '2.355.el6_4.2', 'buildtime': 1362691270L, 'version': '0.12.1.2'},
> 'libvirt': {'release': '18.el6_4.4', 'buildtime': 1366301801L, 'version':
> '0.10.2'}, 'glusterfs': {'release': '0.3.alpha3.el6', 'buildtime':
> 1367604893L, 'version': '3.4.0'}, 'mom': {'release': '1.el6', 'buildtime':
> 1349470062L, 'version': '0.3.0'}, 'glusterfs-server': {'release':
> '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'}},
> 'cpuModel': 'Intel(R) Xeon(R) CPU X5570 @ 2.93GHz', 'hooks':
> {'before_vm_start': {'50_sriov': {'md5':
> '3ebc60cd2e4eb089820102285fad7c45'}, '50_pincpu': {'md5':
> '0b5fb99ff0e7acb9ad534b87c02c59e3'}, '50_qos': {'md5':
> '18b596a6b4e4bad80357f240ba122a5e'}, '50_vmfex': {'md5':
> '9f5abb892ddb6b3daa779985d38d9f55'}, '50_scratchpad': {'md5':
> '7db25a4b8cb04f6e7132cb7c2300c111'}, '50_numa': {'md5':
> '5008c2826714ac5b63748780aabd2f25'}, '50_floppy': {'md5':
> '202fe18705a7d4c50c40c126e8f8dbe8'}, '50_qemucmdline': {'md5':
> 'a884929ad6f5eb039887157288867409'}, '50_macspoof': {'md5': '25deea559772719
> 
> - DHC
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From oramraz at redhat.com  Sun May 19 06:43:15 2013
From: oramraz at redhat.com (Oded Ramraz)
Date: Sun, 19 May 2013 02:43:15 -0400 (EDT)
Subject: [Engine-devel] Odd Host Activation with mgmt-if
In-Reply-To: <700182034.3868949.1368945573602.JavaMail.root@redhat.com>
References: <CAEWPe=oX94UBGnph+5hePnJSyQBneU3-u7QCRwthzmJsZTBm3Q@mail.gmail.com>
	<CAEWPe=qtPwFC2_SEiFV+TdZjbptSy4pig2SOJE7iWAaBHR6YAw@mail.gmail.com>
	<700182034.3868949.1368945573602.JavaMail.root@redhat.com>
Message-ID: <1793944165.3869028.1368945795602.JavaMail.root@redhat.com>

small correction ( typo ) : 'vdsClient -s 0 getVdsCapabilities'

Oded.

----- Original Message -----
From: "Moti Asayag" <masayag at redhat.com>
To: "Dead Horse" <deadhorseconsulting at gmail.com>
Cc: engine-devel at ovirt.org
Sent: Sunday, May 19, 2013 9:39:33 AM
Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if

Could you provide the output of the 'vdsClient -s 0 getVdsCapavilities' for the specific host?

----- Original Message -----
> From: "Dead Horse" <deadhorseconsulting at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Friday, May 17, 2013 12:21:47 AM
> Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> 
> Still puzzling on this all I get for an error when I see it is:
> WARN [org.ovirt.engine.core.bll.
> network.host.SetupNetworksCommand] (pool-5-thread-42) [21543ac] CanDoAction
> of action SetupNetworks failed.
> Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
> ovirtmgmt
> 
> Nothing is logged VDSM wise other then the above standard host activation
> probe.
> 
> - DHC
> 
> 
> 
> On Mon, May 13, 2013 at 1:19 PM, Dead Horse < deadhorseconsulting at gmail.com >
> wrote:
> 
> 
> 
> Seeing this as of late when activating hosts. The odd this is that it reports
> a failure to activate the host (EL6.4) but still does it anyways.
> 
> Engine side:
> 
> 2013-05-13 12:53:38,547 INFO
> [org.ovirt.engine.core.bll.HandleVdsVersionCommand] (pool-5-thread-42)
> [21543ac] Running command: HandleVdsVersionCommand internal: true. Entities
> affected : ID: 15f11023-9746-49de-b33f-e3cc7dca6f65 Type: VDS
> 2013-05-13 12:53:38,549 INFO
> [org.ovirt.engine.core.vdsbroker.ActivateVdsVDSCommand] (pool-5-thread-42)
> [21543ac] FINISH, ActivateVdsVDSCommand, return: Host[durotar], log id:
> 3796a7bd
> 2013-05-13 12:53:38,625 WARN
> [org.ovirt.engine.core.bll.network.host.SetupNetworksCommand]
> (pool-5-thread-42) [21543ac] CanDoAction of action SetupNetworks failed.
> Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
> ovirtmgmt
> 2013-05-13 12:53:39,368 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand]
> (pool-5-thread-42) [21543ac] Activate finished. Lock released. Monitoring
> can run now for host durotar from data-center Azeroth
> 
> VDSM Side:
> 
> Thread-13::DEBUG::2013-05-13 12:53:37,841::BindingXMLRPC::933::vds::(wrapper)
> return getCapabilities with {'status': {'message': 'Done', 'code': 0},
> 'info': {'HBAInventory': {'iSCSI': [{'InitiatorName':
> 'iqn.2012-09.net.azeroth:durotar'}], 'FC': []}, 'packages2': {'kernel':
> {'release': '358.6.1.el6.x86_64', 'buildtime': 1366751713.0, 'version':
> '2.6.32'}, 'glusterfs-rdma': {'release': '0.3.alpha3.el6', 'buildtime':
> 1367604893L, 'version': '3.4.0'}, 'glusterfs-fuse': {'release':
> '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'},
> 'spice-server': {'release': '12.el6', 'buildtime': 1361573005L, 'version':
> '0.12.0'}, 'vdsm': {'release': '17.el6', 'buildtime': 1368196305L,
> 'version': '4.10.3'}, 'qemu-kvm': {'release': '2.355.el6_4.2', 'buildtime':
> 1362691270L, 'version': '0.12.1.2'}, 'qemu-img': {'release':
> '2.355.el6_4.2', 'buildtime': 1362691270L, 'version': '0.12.1.2'},
> 'libvirt': {'release': '18.el6_4.4', 'buildtime': 1366301801L, 'version':
> '0.10.2'}, 'glusterfs': {'release': '0.3.alpha3.el6', 'buildtime':
> 1367604893L, 'version': '3.4.0'}, 'mom': {'release': '1.el6', 'buildtime':
> 1349470062L, 'version': '0.3.0'}, 'glusterfs-server': {'release':
> '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'}},
> 'cpuModel': 'Intel(R) Xeon(R) CPU X5570 @ 2.93GHz', 'hooks':
> {'before_vm_start': {'50_sriov': {'md5':
> '3ebc60cd2e4eb089820102285fad7c45'}, '50_pincpu': {'md5':
> '0b5fb99ff0e7acb9ad534b87c02c59e3'}, '50_qos': {'md5':
> '18b596a6b4e4bad80357f240ba122a5e'}, '50_vmfex': {'md5':
> '9f5abb892ddb6b3daa779985d38d9f55'}, '50_scratchpad': {'md5':
> '7db25a4b8cb04f6e7132cb7c2300c111'}, '50_numa': {'md5':
> '5008c2826714ac5b63748780aabd2f25'}, '50_floppy': {'md5':
> '202fe18705a7d4c50c40c126e8f8dbe8'}, '50_qemucmdline': {'md5':
> 'a884929ad6f5eb039887157288867409'}, '50_macspoof': {'md5': '25deea559772719
> 
> - DHC
> 
> 
> _______________________________________________
> 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 mpastern at redhat.com  Sun May 19 09:50:37 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 19 May 2013 12:50:37 +0300
Subject: [Engine-devel] [REST-API] Support passing auth information
 without having to use HTTP Authorization header #958874
In-Reply-To: <1192958387.1927204.1368727107293.JavaMail.root@redhat.com>
References: <518751C7.8090208@redhat.com>
	<1665518752.4971723.1367945088296.JavaMail.root@redhat.com>
	<518B6C07.1080504@redhat.com>
	<1192958387.1927204.1368727107293.JavaMail.root@redhat.com>
Message-ID: <5198A06D.8010908@redhat.com>

On 05/16/2013 08:58 PM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>, "Itamar Heim" <iheim at redhat.com>, "Juan
>> Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Barak Azulay" <bazulay at redhat.com>
>> Sent: Thursday, May 9, 2013 12:27:35 PM
>> Subject: Re: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
>>
>> On 05/07/2013 07:44 PM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Vojtech Szocs"
>>>> <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>,
>>>> "Itamar Heim" <iheim at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>,
>>>> "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Monday, May 6, 2013 9:46:31 AM
>>>> Subject: [REST-API] Support passing auth information without having to use
>>>> HTTP Authorization header #958874
>>>>
>>>>
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=958874
>>>>
>>>> Hi Alon,
>>>>
>>>> (In reply to comment #2)
>>>>>
>>>>> Regardless of this specific RFE I would like to write that I don't like
>>>>> the
>>>>> REST API session mechanism
>>>>> [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as it
>>>>> relays on cookies and not explicit API interaction.
>>>>
>>>> authentication in RESTful application is a matter of debate, it can be
>>>> achieved
>>>> in various ways, but session + cookie auth. method is very common and
>>>> usually
>>>> effective,
>>>>
>>>> it's biggest disadvantage is that it's not exactly RESfull cause client
>>>> have to maintain (story) the cookie and not the server (but i wouldn't
>>>> call
>>>> it an
>>>> issue at all), besides that it's works perfectly well from the REST PoV,
>>>>
>>>> also some may say that cookies are not strong enough and OAuth for
>>>> instance
>>>> should be used instead, but this is a different story cause in our case,
>>>> cookie
>>>> are for the clients (not browsers [1]) that can store them in a secure way
>>>> or
>>>> even
>>>> not to store at all (in-memory cookie).
>>>>
>>>> [1] another disadvantage is that webbrowsers not able to access cookie
>>>> namespace,
>>>> but lately i've suggested URI based authentication [2] to support web
>>>> browsers
>>>> as well.
>>>>
>>>> [2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html
>>>>
>>>> the biggest advantage of the cookie is a session expiration that
>>>> maintained
>>>> by the server and abstracted from the client what is much better from
>>>> security
>>>> PoV than standard authentication mechanisms such as HTTP basic auth for
>>>> instance
>>>> which can be potentially cached.
>>>
>>> Expiration is always managed by server side, regardless the cookie vs
>>> ticket debate.
>>>
>>>>
>>>>> I would have expected a
>>>>> 'ticket' to be retrieved and that 'ticket' to be disconnected from the
>>>>> application server objects. Although we can refer the 'cookie' as a
>>>>> ticket,
>>>>> however the requirement to parse it should not be required, there be a
>>>>> conflict between two separate applications running on same server, and
>>>>> there
>>>>> may be a problem to transfer credentials between servers.
>>>>
>>>> well, this is not exactly correct:
>>>>
>>>> 1. client desn't have to decode/parse the cookie and pass credentials, all
>>>> it
>>>> need is
>>>>    just to store the cookie and pass it as is to server on every request.
>>>
>>> You just described what cookies are.
>>> And if I understand we want better control of application authentication,
>>> disconnected from 'default browser behavior'.
>>>
>>>> 2. "conflict between two separate applications running on same server"?
>>>> different cookie
>>>>    uses different domain & path by spec., can you pls explain what do you
>>>>    mean by this?
>>>
>>> If you call the cookie JSESSIONID....
>>
>> different applications cannot live under same path,
>> this what for cookie has a "path" attribute,
>>
>> but it can create a bit of confusion indeed, but you not
>> talking with more than one application in same time right ?!,
>> i.e container/client fetches the JSESSIONID cookie from the
>> specific request/response,
> 
> I am taking exactly on that... good on demand authentication mechanism should allow concurrent multiple users processing. This is what API is all about.

works like a charm with today's authentication methods.

> Of course this can somehow achieved via cookie, but doing so is so complex that one probably wish to use plain header, 

complex only for browsers.

> or worse case a cookie that does not conflict with the application that loaded the static content.
> 
>> so i'm not sure how possibly client can get in reply two
>> cookies with a same name (even if all applications are using
>> same cookie)
> 
> Because of this, authorization mechanism should not use cookies.

?, sorry, you lost me.

> 
>>>>>
>>>>> If we modify authentication we should support more authentication types,
>>>>> at
>>>>> least SPNEGO.
>>>>>
>>>>> In order to allow SPNEGO and other authentication mechanisms, we better
>>>>> force people to use single URI to perform the login and return
>>>>> authenticated
>>>>> 'ticket' to continue interaction with application.
>>>>
>>>> this is good for the backend authentication, but is not for the RESTful
>>>> application, it's like buying an aeroplane and driving it on a road,
>>>
>>> And why is that? who are you to decide what authentication mechanism is to
>>> be used by customers?
>>
>> alon, you misunderstood, i'm not talking about authentication method,
>> but about your sentence ^ "we better force people to use single URI"
>>
>>> If customer has a policy of not transmitting passwords over the network,
>>> then SPENGO is your friend.
>>> But let's ignore it for now.
>>
>> cookie is not any different from the SPENGO token in this meaning,
>> it's just another data container.
> 
> Yes they are, they cannot provide challenge response sequence required to establish trust.

you're right the GSSAPI negotiation mechanism is nowhere near the standard cookie auth, however
we where talking about passing the password over the wire, and this is what my response was
about, not conceptual differences between SPENGO & session-cookie+ssl auth.

> 
>>
>>>
>>>> "force people to use single URI to perform the login" means SOAP while we
>>>> wanted REST
>>>> where any URI is considered as entry point and actually a resource address
>>>> that should
>>>> be accessible/manipulatable and authentication should be
>>>> abstracted/disconnected from
>>>> this concept.
>>>
>>> Again, you provide statements that are not written in stone.
>>
>> this is main REST principal.
> 
> I know very few principles that have no exceptions in software engineering.
> 
>>> Having custom authentication header breaks the 'plain simple rest'.
>>> Having a URI is only makes it easier to manage this breakage.
>>
>> for us, but this is breaks a REST concept.
> 
> Per your interpretation.

this is not correct, you're welcome to read Roy Fielding doctoral dissertation on
top of which REST was build, (that's what i did before my first reply on REST related
threads).

and to put the things on a right shelf (so i won't be wrongly interpreted again),
i have nothing against the SPENGO - just nothing, my problem is forcing users to
access dedicated URI for authentication/authorization (as was suggested by
you) before being able to fetch/change resource representation.

again don't get me wrong, i'm not justifying Cookies (actually i even wasn't the
one that decided to use this mechanism), but saying "I know very few principles that
have no exceptions in software engineering" is not helping, anything can be done
differently, the question is 'why?' (i'd agree with this only if auth could not be
made differently, but obviously this is not the case)

>  
>>>
>>>> SPNEGO is only an implementation detail that can be abstracted for the
>>>> API.
>>>
>>> I don't follow.
>>>
>>>>> This will be much simpler
>>>>> implementation at the api side and much more efficient, and as we are
>>>>> discussion application-to-application interaction there should be no user
>>>>> experience visible issues.
>>>>
>>>> i'm not sure: "force people to use single URI to perform the login" and no
>>>> "no user experience visible issues."?
>>>
>>> Please describe how the prefer mechanism suggested can be implemented in
>>> standard browser.
>>
>> it cannot because authorization header has to be supplied only when
>> client wishes to reinitialize the JSESSION, and web browsers can't omit
>> it during the lifetime.
>>
>> all this cause we don't support web browsers in api yet, session based
>> authentication mechanism was designed for http clients,
>>
>> and this why we having this discussion, currently options are:
>>
>> 1. adapt session based authentication
>> 2. introduce new concept
>>
>> personally i prefer #1 as it's less noisy and easily achievable.
> 
> But will force you to face more issues in future.
> 
>>> And if it cannot, and custom logic is required, why a custom logic that
>>> accesses a custom URI to perform login is any different.
>>
>> it's not RESTful
> 
> I am tired to answer this over and over...
> 
>>>  
>>>>>
>>>>> What I recommend is purely applicative rest login command...
>>>>
>>>> IIUC this is SOAP and not REST ...
>>>
>>> Again... please refrain from these kind of void statements.
>>> SOAP is a protocol, it has specific format and rules.
>>> It may or may not use this or any other suggested authentication mechanism.
>>
>> i'm not talking about the protocol, but about the conceptual differences
>> between SOAP and REST services.
>>
>> SOAP is a RPC (Remote Procedure Call) and has single entry point on which
>> different methods are invoked, having single dedicated method for login
>> works in this case,
> 
> So happy to know!

Alone, none is trying to offend you, or your knowledge, just that a lot of people
CC'ed in this tread, so in sake of fair discussion (have everyone in sync), i'm
going to these levels.

> 
>> REST is a ROA (Resource Oriented Architecture), i.e everything is REST is a
>> resource, and you have to operate on these resources, authentication is only
>> an implementation detail that should not break this concept.
> 
> REST accept cookie that was obtained from former authentication, so it breaks your above statement.
> The cookie can and usually is acquired by different URI.

i never said this.

> 
>> now saying this i think is clear that you have no place to put at the login()
>> method you've mentioned,
> 
> Exactly from which you took the cookie, in your language from the Session resource.

:), you told something completely different at the beginning, it was:
"we better force people to use single URI to perform the login and return authenticated 'ticket'",
now by saying "session resource", i'll assume that you mean any resource (cause cookie can be obtained
from the any URI), e.g

/api
/api/vms/xxx
/api/vms/xxx/disks/yyy

i.e any of these can serve as an entry point to api and a place to obtain the ticket from,
and this is how it works today btw.,

so IIUC, this is one of the ways to go.

>  
>> standard way for authentication in REST/HTTP is via 'authorization' header
>> (per request),
>> optimizing this we've introduced new concept via sessionid,
>>
>> user can choose between two by passing 'prefer:persistent_auth' header,
>>
>> hope it's clear now, please let me know otherwise.
> 
> Well, it is  clear that this is not a discussion, but dictation...
> So do whatever you think...

this is not true, if it was like this i wouldn't start this discussion
to begin with,

the power of OS is that a lot of people sharing theirs knowledge and
at the end best approach is chosen,

not agreeing on some part/s of suggestion != exclusive locking, i'm
always open for new ideas and ready to learn from others.

>>> Regards,
>>> Alon
>>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From alonbl at redhat.com  Sun May 19 10:15:29 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 19 May 2013 06:15:29 -0400 (EDT)
Subject: [Engine-devel] Odd Host Activation with mgmt-if
In-Reply-To: <1793944165.3869028.1368945795602.JavaMail.root@redhat.com>
References: <CAEWPe=oX94UBGnph+5hePnJSyQBneU3-u7QCRwthzmJsZTBm3Q@mail.gmail.com>
	<CAEWPe=qtPwFC2_SEiFV+TdZjbptSy4pig2SOJE7iWAaBHR6YAw@mail.gmail.com>
	<700182034.3868949.1368945573602.JavaMail.root@redhat.com>
	<1793944165.3869028.1368945795602.JavaMail.root@redhat.com>
Message-ID: <58289927.2323676.1368958529064.JavaMail.root@redhat.com>


Most probably, when SSL is enabled and configured properly this will not work...

One need:

vdsClient -s <hostname_as_specified_in_certificate> ....

----- Original Message -----
> From: "Oded Ramraz" <oramraz at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Sunday, May 19, 2013 9:43:15 AM
> Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> 
> small correction ( typo ) : 'vdsClient -s 0 getVdsCapabilities'
> 
> Oded.
> 
> ----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Dead Horse" <deadhorseconsulting at gmail.com>
> Cc: engine-devel at ovirt.org
> Sent: Sunday, May 19, 2013 9:39:33 AM
> Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> 
> Could you provide the output of the 'vdsClient -s 0 getVdsCapavilities' for
> the specific host?
> 
> ----- Original Message -----
> > From: "Dead Horse" <deadhorseconsulting at gmail.com>
> > To: engine-devel at ovirt.org
> > Sent: Friday, May 17, 2013 12:21:47 AM
> > Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> > 
> > Still puzzling on this all I get for an error when I see it is:
> > WARN [org.ovirt.engine.core.bll.
> > network.host.SetupNetworksCommand] (pool-5-thread-42) [21543ac] CanDoAction
> > of action SetupNetworks failed.
> > Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
> > ovirtmgmt
> > 
> > Nothing is logged VDSM wise other then the above standard host activation
> > probe.
> > 
> > - DHC
> > 
> > 
> > 
> > On Mon, May 13, 2013 at 1:19 PM, Dead Horse < deadhorseconsulting at gmail.com
> > >
> > wrote:
> > 
> > 
> > 
> > Seeing this as of late when activating hosts. The odd this is that it
> > reports
> > a failure to activate the host (EL6.4) but still does it anyways.
> > 
> > Engine side:
> > 
> > 2013-05-13 12:53:38,547 INFO
> > [org.ovirt.engine.core.bll.HandleVdsVersionCommand] (pool-5-thread-42)
> > [21543ac] Running command: HandleVdsVersionCommand internal: true. Entities
> > affected : ID: 15f11023-9746-49de-b33f-e3cc7dca6f65 Type: VDS
> > 2013-05-13 12:53:38,549 INFO
> > [org.ovirt.engine.core.vdsbroker.ActivateVdsVDSCommand] (pool-5-thread-42)
> > [21543ac] FINISH, ActivateVdsVDSCommand, return: Host[durotar], log id:
> > 3796a7bd
> > 2013-05-13 12:53:38,625 WARN
> > [org.ovirt.engine.core.bll.network.host.SetupNetworksCommand]
> > (pool-5-thread-42) [21543ac] CanDoAction of action SetupNetworks failed.
> > Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
> > ovirtmgmt
> > 2013-05-13 12:53:39,368 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand]
> > (pool-5-thread-42) [21543ac] Activate finished. Lock released. Monitoring
> > can run now for host durotar from data-center Azeroth
> > 
> > VDSM Side:
> > 
> > Thread-13::DEBUG::2013-05-13
> > 12:53:37,841::BindingXMLRPC::933::vds::(wrapper)
> > return getCapabilities with {'status': {'message': 'Done', 'code': 0},
> > 'info': {'HBAInventory': {'iSCSI': [{'InitiatorName':
> > 'iqn.2012-09.net.azeroth:durotar'}], 'FC': []}, 'packages2': {'kernel':
> > {'release': '358.6.1.el6.x86_64', 'buildtime': 1366751713.0, 'version':
> > '2.6.32'}, 'glusterfs-rdma': {'release': '0.3.alpha3.el6', 'buildtime':
> > 1367604893L, 'version': '3.4.0'}, 'glusterfs-fuse': {'release':
> > '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'},
> > 'spice-server': {'release': '12.el6', 'buildtime': 1361573005L, 'version':
> > '0.12.0'}, 'vdsm': {'release': '17.el6', 'buildtime': 1368196305L,
> > 'version': '4.10.3'}, 'qemu-kvm': {'release': '2.355.el6_4.2', 'buildtime':
> > 1362691270L, 'version': '0.12.1.2'}, 'qemu-img': {'release':
> > '2.355.el6_4.2', 'buildtime': 1362691270L, 'version': '0.12.1.2'},
> > 'libvirt': {'release': '18.el6_4.4', 'buildtime': 1366301801L, 'version':
> > '0.10.2'}, 'glusterfs': {'release': '0.3.alpha3.el6', 'buildtime':
> > 1367604893L, 'version': '3.4.0'}, 'mom': {'release': '1.el6', 'buildtime':
> > 1349470062L, 'version': '0.3.0'}, 'glusterfs-server': {'release':
> > '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'}},
> > 'cpuModel': 'Intel(R) Xeon(R) CPU X5570 @ 2.93GHz', 'hooks':
> > {'before_vm_start': {'50_sriov': {'md5':
> > '3ebc60cd2e4eb089820102285fad7c45'}, '50_pincpu': {'md5':
> > '0b5fb99ff0e7acb9ad534b87c02c59e3'}, '50_qos': {'md5':
> > '18b596a6b4e4bad80357f240ba122a5e'}, '50_vmfex': {'md5':
> > '9f5abb892ddb6b3daa779985d38d9f55'}, '50_scratchpad': {'md5':
> > '7db25a4b8cb04f6e7132cb7c2300c111'}, '50_numa': {'md5':
> > '5008c2826714ac5b63748780aabd2f25'}, '50_floppy': {'md5':
> > '202fe18705a7d4c50c40c126e8f8dbe8'}, '50_qemucmdline': {'md5':
> > 'a884929ad6f5eb039887157288867409'}, '50_macspoof': {'md5':
> > '25deea559772719
> > 
> > - DHC
> > 
> > 
> > _______________________________________________
> > 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 ybronhei at redhat.com  Sun May 19 11:46:43 2013
From: ybronhei at redhat.com (Yaniv Bronheim)
Date: Sun, 19 May 2013 07:46:43 -0400 (EDT)
Subject: [Engine-devel] Odd Host Activation with mgmt-if
In-Reply-To: <58289927.2323676.1368958529064.JavaMail.root@redhat.com>
References: <CAEWPe=oX94UBGnph+5hePnJSyQBneU3-u7QCRwthzmJsZTBm3Q@mail.gmail.com>
	<CAEWPe=qtPwFC2_SEiFV+TdZjbptSy4pig2SOJE7iWAaBHR6YAw@mail.gmail.com>
	<700182034.3868949.1368945573602.JavaMail.root@redhat.com>
	<1793944165.3869028.1368945795602.JavaMail.root@redhat.com>
	<58289927.2323676.1368958529064.JavaMail.root@redhat.com>
Message-ID: <703471633.2325369.1368964003055.JavaMail.root@redhat.com>

Its true only if you add the host by using an hostname and not by explicit IP, with IP you can pass 0 to vdsClient and it works

----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Oded Ramraz" <oramraz at redhat.com>, "Moti Asayag" <masayag at redhat.com>
> Cc: engine-devel at ovirt.org, "Yaniv Bronheim" <ybronhei at redhat.com>
> Sent: Sunday, May 19, 2013 1:15:29 PM
> Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> 
> 
> Most probably, when SSL is enabled and configured properly this will not
> work...
> 
> One need:
> 
> vdsClient -s <hostname_as_specified_in_certificate> ....
> 
> ----- Original Message -----
> > From: "Oded Ramraz" <oramraz at redhat.com>
> > To: "Moti Asayag" <masayag at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Sunday, May 19, 2013 9:43:15 AM
> > Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> > 
> > small correction ( typo ) : 'vdsClient -s 0 getVdsCapabilities'
> > 
> > Oded.
> > 
> > ----- Original Message -----
> > From: "Moti Asayag" <masayag at redhat.com>
> > To: "Dead Horse" <deadhorseconsulting at gmail.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Sunday, May 19, 2013 9:39:33 AM
> > Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> > 
> > Could you provide the output of the 'vdsClient -s 0 getVdsCapavilities' for
> > the specific host?
> > 
> > ----- Original Message -----
> > > From: "Dead Horse" <deadhorseconsulting at gmail.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Friday, May 17, 2013 12:21:47 AM
> > > Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> > > 
> > > Still puzzling on this all I get for an error when I see it is:
> > > WARN [org.ovirt.engine.core.bll.
> > > network.host.SetupNetworksCommand] (pool-5-thread-42) [21543ac]
> > > CanDoAction
> > > of action SetupNetworks failed.
> > > Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
> > > ovirtmgmt
> > > 
> > > Nothing is logged VDSM wise other then the above standard host activation
> > > probe.
> > > 
> > > - DHC
> > > 
> > > 
> > > 
> > > On Mon, May 13, 2013 at 1:19 PM, Dead Horse <
> > > deadhorseconsulting at gmail.com
> > > >
> > > wrote:
> > > 
> > > 
> > > 
> > > Seeing this as of late when activating hosts. The odd this is that it
> > > reports
> > > a failure to activate the host (EL6.4) but still does it anyways.
> > > 
> > > Engine side:
> > > 
> > > 2013-05-13 12:53:38,547 INFO
> > > [org.ovirt.engine.core.bll.HandleVdsVersionCommand] (pool-5-thread-42)
> > > [21543ac] Running command: HandleVdsVersionCommand internal: true.
> > > Entities
> > > affected : ID: 15f11023-9746-49de-b33f-e3cc7dca6f65 Type: VDS
> > > 2013-05-13 12:53:38,549 INFO
> > > [org.ovirt.engine.core.vdsbroker.ActivateVdsVDSCommand]
> > > (pool-5-thread-42)
> > > [21543ac] FINISH, ActivateVdsVDSCommand, return: Host[durotar], log id:
> > > 3796a7bd
> > > 2013-05-13 12:53:38,625 WARN
> > > [org.ovirt.engine.core.bll.network.host.SetupNetworksCommand]
> > > (pool-5-thread-42) [21543ac] CanDoAction of action SetupNetworks failed.
> > > Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
> > > ovirtmgmt
> > > 2013-05-13 12:53:39,368 INFO
> > > [org.ovirt.engine.core.bll.ActivateVdsCommand]
> > > (pool-5-thread-42) [21543ac] Activate finished. Lock released. Monitoring
> > > can run now for host durotar from data-center Azeroth
> > > 
> > > VDSM Side:
> > > 
> > > Thread-13::DEBUG::2013-05-13
> > > 12:53:37,841::BindingXMLRPC::933::vds::(wrapper)
> > > return getCapabilities with {'status': {'message': 'Done', 'code': 0},
> > > 'info': {'HBAInventory': {'iSCSI': [{'InitiatorName':
> > > 'iqn.2012-09.net.azeroth:durotar'}], 'FC': []}, 'packages2': {'kernel':
> > > {'release': '358.6.1.el6.x86_64', 'buildtime': 1366751713.0, 'version':
> > > '2.6.32'}, 'glusterfs-rdma': {'release': '0.3.alpha3.el6', 'buildtime':
> > > 1367604893L, 'version': '3.4.0'}, 'glusterfs-fuse': {'release':
> > > '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'},
> > > 'spice-server': {'release': '12.el6', 'buildtime': 1361573005L,
> > > 'version':
> > > '0.12.0'}, 'vdsm': {'release': '17.el6', 'buildtime': 1368196305L,
> > > 'version': '4.10.3'}, 'qemu-kvm': {'release': '2.355.el6_4.2',
> > > 'buildtime':
> > > 1362691270L, 'version': '0.12.1.2'}, 'qemu-img': {'release':
> > > '2.355.el6_4.2', 'buildtime': 1362691270L, 'version': '0.12.1.2'},
> > > 'libvirt': {'release': '18.el6_4.4', 'buildtime': 1366301801L, 'version':
> > > '0.10.2'}, 'glusterfs': {'release': '0.3.alpha3.el6', 'buildtime':
> > > 1367604893L, 'version': '3.4.0'}, 'mom': {'release': '1.el6',
> > > 'buildtime':
> > > 1349470062L, 'version': '0.3.0'}, 'glusterfs-server': {'release':
> > > '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'}},
> > > 'cpuModel': 'Intel(R) Xeon(R) CPU X5570 @ 2.93GHz', 'hooks':
> > > {'before_vm_start': {'50_sriov': {'md5':
> > > '3ebc60cd2e4eb089820102285fad7c45'}, '50_pincpu': {'md5':
> > > '0b5fb99ff0e7acb9ad534b87c02c59e3'}, '50_qos': {'md5':
> > > '18b596a6b4e4bad80357f240ba122a5e'}, '50_vmfex': {'md5':
> > > '9f5abb892ddb6b3daa779985d38d9f55'}, '50_scratchpad': {'md5':
> > > '7db25a4b8cb04f6e7132cb7c2300c111'}, '50_numa': {'md5':
> > > '5008c2826714ac5b63748780aabd2f25'}, '50_floppy': {'md5':
> > > '202fe18705a7d4c50c40c126e8f8dbe8'}, '50_qemucmdline': {'md5':
> > > 'a884929ad6f5eb039887157288867409'}, '50_macspoof': {'md5':
> > > '25deea559772719
> > > 
> > > - DHC
> > > 
> > > 
> > > _______________________________________________
> > > 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 alonbl at redhat.com  Sun May 19 12:01:26 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 19 May 2013 08:01:26 -0400 (EDT)
Subject: [Engine-devel] Odd Host Activation with mgmt-if
In-Reply-To: <703471633.2325369.1368964003055.JavaMail.root@redhat.com>
References: <CAEWPe=oX94UBGnph+5hePnJSyQBneU3-u7QCRwthzmJsZTBm3Q@mail.gmail.com>
	<CAEWPe=qtPwFC2_SEiFV+TdZjbptSy4pig2SOJE7iWAaBHR6YAw@mail.gmail.com>
	<700182034.3868949.1368945573602.JavaMail.root@redhat.com>
	<1793944165.3869028.1368945795602.JavaMail.root@redhat.com>
	<58289927.2323676.1368958529064.JavaMail.root@redhat.com>
	<703471633.2325369.1368964003055.JavaMail.root@redhat.com>
Message-ID: <259919713.2325611.1368964886494.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yaniv Bronheim" <ybronhei at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Oded Ramraz" <oramraz at redhat.com>, "Moti Asayag" <masayag at redhat.com>, engine-devel at ovirt.org
> Sent: Sunday, May 19, 2013 2:46:43 PM
> Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> 
> Its true only if you add the host by using an hostname and not by explicit
> IP, with IP you can pass 0 to vdsClient and it works

I don't think so... even if you enrolled using ip address, it will fail as 0 tries to access using localhost as far as I remember.

> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Oded Ramraz" <oramraz at redhat.com>, "Moti Asayag" <masayag at redhat.com>
> > Cc: engine-devel at ovirt.org, "Yaniv Bronheim" <ybronhei at redhat.com>
> > Sent: Sunday, May 19, 2013 1:15:29 PM
> > Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> > 
> > 
> > Most probably, when SSL is enabled and configured properly this will not
> > work...
> > 
> > One need:
> > 
> > vdsClient -s <hostname_as_specified_in_certificate> ....
> > 
> > ----- Original Message -----
> > > From: "Oded Ramraz" <oramraz at redhat.com>
> > > To: "Moti Asayag" <masayag at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Sunday, May 19, 2013 9:43:15 AM
> > > Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> > > 
> > > small correction ( typo ) : 'vdsClient -s 0 getVdsCapabilities'
> > > 
> > > Oded.
> > > 
> > > ----- Original Message -----
> > > From: "Moti Asayag" <masayag at redhat.com>
> > > To: "Dead Horse" <deadhorseconsulting at gmail.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Sunday, May 19, 2013 9:39:33 AM
> > > Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> > > 
> > > Could you provide the output of the 'vdsClient -s 0 getVdsCapavilities'
> > > for
> > > the specific host?
> > > 
> > > ----- Original Message -----
> > > > From: "Dead Horse" <deadhorseconsulting at gmail.com>
> > > > To: engine-devel at ovirt.org
> > > > Sent: Friday, May 17, 2013 12:21:47 AM
> > > > Subject: Re: [Engine-devel] Odd Host Activation with mgmt-if
> > > > 
> > > > Still puzzling on this all I get for an error when I see it is:
> > > > WARN [org.ovirt.engine.core.bll.
> > > > network.host.SetupNetworksCommand] (pool-5-thread-42) [21543ac]
> > > > CanDoAction
> > > > of action SetupNetworks failed.
> > > > Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
> > > > ovirtmgmt
> > > > 
> > > > Nothing is logged VDSM wise other then the above standard host
> > > > activation
> > > > probe.
> > > > 
> > > > - DHC
> > > > 
> > > > 
> > > > 
> > > > On Mon, May 13, 2013 at 1:19 PM, Dead Horse <
> > > > deadhorseconsulting at gmail.com
> > > > >
> > > > wrote:
> > > > 
> > > > 
> > > > 
> > > > Seeing this as of late when activating hosts. The odd this is that it
> > > > reports
> > > > a failure to activate the host (EL6.4) but still does it anyways.
> > > > 
> > > > Engine side:
> > > > 
> > > > 2013-05-13 12:53:38,547 INFO
> > > > [org.ovirt.engine.core.bll.HandleVdsVersionCommand] (pool-5-thread-42)
> > > > [21543ac] Running command: HandleVdsVersionCommand internal: true.
> > > > Entities
> > > > affected : ID: 15f11023-9746-49de-b33f-e3cc7dca6f65 Type: VDS
> > > > 2013-05-13 12:53:38,549 INFO
> > > > [org.ovirt.engine.core.vdsbroker.ActivateVdsVDSCommand]
> > > > (pool-5-thread-42)
> > > > [21543ac] FINISH, ActivateVdsVDSCommand, return: Host[durotar], log id:
> > > > 3796a7bd
> > > > 2013-05-13 12:53:38,625 WARN
> > > > [org.ovirt.engine.core.bll.network.host.SetupNetworksCommand]
> > > > (pool-5-thread-42) [21543ac] CanDoAction of action SetupNetworks
> > > > failed.
> > > > Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
> > > > ovirtmgmt
> > > > 2013-05-13 12:53:39,368 INFO
> > > > [org.ovirt.engine.core.bll.ActivateVdsCommand]
> > > > (pool-5-thread-42) [21543ac] Activate finished. Lock released.
> > > > Monitoring
> > > > can run now for host durotar from data-center Azeroth
> > > > 
> > > > VDSM Side:
> > > > 
> > > > Thread-13::DEBUG::2013-05-13
> > > > 12:53:37,841::BindingXMLRPC::933::vds::(wrapper)
> > > > return getCapabilities with {'status': {'message': 'Done', 'code': 0},
> > > > 'info': {'HBAInventory': {'iSCSI': [{'InitiatorName':
> > > > 'iqn.2012-09.net.azeroth:durotar'}], 'FC': []}, 'packages2': {'kernel':
> > > > {'release': '358.6.1.el6.x86_64', 'buildtime': 1366751713.0, 'version':
> > > > '2.6.32'}, 'glusterfs-rdma': {'release': '0.3.alpha3.el6', 'buildtime':
> > > > 1367604893L, 'version': '3.4.0'}, 'glusterfs-fuse': {'release':
> > > > '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'},
> > > > 'spice-server': {'release': '12.el6', 'buildtime': 1361573005L,
> > > > 'version':
> > > > '0.12.0'}, 'vdsm': {'release': '17.el6', 'buildtime': 1368196305L,
> > > > 'version': '4.10.3'}, 'qemu-kvm': {'release': '2.355.el6_4.2',
> > > > 'buildtime':
> > > > 1362691270L, 'version': '0.12.1.2'}, 'qemu-img': {'release':
> > > > '2.355.el6_4.2', 'buildtime': 1362691270L, 'version': '0.12.1.2'},
> > > > 'libvirt': {'release': '18.el6_4.4', 'buildtime': 1366301801L,
> > > > 'version':
> > > > '0.10.2'}, 'glusterfs': {'release': '0.3.alpha3.el6', 'buildtime':
> > > > 1367604893L, 'version': '3.4.0'}, 'mom': {'release': '1.el6',
> > > > 'buildtime':
> > > > 1349470062L, 'version': '0.3.0'}, 'glusterfs-server': {'release':
> > > > '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'}},
> > > > 'cpuModel': 'Intel(R) Xeon(R) CPU X5570 @ 2.93GHz', 'hooks':
> > > > {'before_vm_start': {'50_sriov': {'md5':
> > > > '3ebc60cd2e4eb089820102285fad7c45'}, '50_pincpu': {'md5':
> > > > '0b5fb99ff0e7acb9ad534b87c02c59e3'}, '50_qos': {'md5':
> > > > '18b596a6b4e4bad80357f240ba122a5e'}, '50_vmfex': {'md5':
> > > > '9f5abb892ddb6b3daa779985d38d9f55'}, '50_scratchpad': {'md5':
> > > > '7db25a4b8cb04f6e7132cb7c2300c111'}, '50_numa': {'md5':
> > > > '5008c2826714ac5b63748780aabd2f25'}, '50_floppy': {'md5':
> > > > '202fe18705a7d4c50c40c126e8f8dbe8'}, '50_qemucmdline': {'md5':
> > > > 'a884929ad6f5eb039887157288867409'}, '50_macspoof': {'md5':
> > > > '25deea559772719
> > > > 
> > > > - DHC
> > > > 
> > > > 
> > > > _______________________________________________
> > > > 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 alonbl at redhat.com  Sun May 19 12:11:23 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 19 May 2013 08:11:23 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <5195E64A.3050806@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<190022898.4562887.1367871118558.JavaMail.root@redhat.com>
	<518A4A37.7040506@redhat.com>
	<1674151596.12805405.1368018034731.JavaMail.root@redhat.com>
	<129444276.5410211.1368022851515.JavaMail.root@redhat.com>
	<1259953792.13083016.1368039749490.JavaMail.root@redhat.com>
	<2140554843.5508235.1368040739442.JavaMail.root@redhat.com>
	<5195E64A.3050806@redhat.com>
Message-ID: <1128111575.2325743.1368965483403.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
> Sent: Friday, May 17, 2013 11:11:54 AM
> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)
> 
> Il 08/05/2013 21:18, Alon Bar-Lev ha scritto:
> > Right.
> > First, we need to support any installation not just rhel.
> > Second, we can support only other well behaved products.
> > Until recently we were not well behaved... well we still not fully because
> > we do not have our own configurable URI namespace.
> >
> > We cannot control which applications are installed on the same host,
> > however we can:
> >
> > 1. postgresql: support skipping the automatic provisioning [supported in
> > the otopi setup]
> > 2. apache: do not enforce specific apache SSL implementation [to be done].
> > 3. apache: support skipping the automatic SSL configuration [supported].
> > 4. apache: support skipping the root redirect to ovirt application
> > [supported in otopi setup]
> > 5. apache: move application to own name space, example /ovirt-engine [to be
> > done, I will be happy if you can help pushing this]
> > 6. firewall: support skipping configuration [supported]
> > 7. packaging: remove the versionlock usage.
> > 8. packaging: support proper upgrade path, compatible with packaging best
> > practices.
> > 9. files: rename all utilities and public artifacts from engine-* to
> > ovirt-engine-*
> > [more?]
> >
> > If we do the above we are acting as well behaved application, and can
> > co-exist with other well behaved applications.
> 
> 
> Trying to set the point on this issue in order to start coding.
> 
> We split the http configuration into three:
> 1. Install ajp proxy per our URIs[1][2].
> 2. Optionally set root redirection from / to /ovirt-engine
> 3. Optionally configure mod_ssl with our certificate.
> 
> The mandatory apache configuration[1] does not alter any configuration file.
> [1] http://gerrit.ovirt.org/13318
> [2] http://gerrit.ovirt.org/14304
> 
> So there is no reason for checking if user has changed the http
> configuration for just forcing proxy.
> 
> About IPA conflicts if I've understood correctly there is only collision
> between mod_nss used by IPA and mod_ssl used if we enable mod_ssl
> configuration.
> It seems there was an issue with mod_proxy and using 2 different SSL
> certificates (IPA & RHEV) on the same apache server.
> 
> So, I can force proxy enabled and I can force SSL configuration disabled
> if IPA is detected.
> I can leave root redirection optional in any case.
> 
> otopi implementation already force proxy enabled so there should be just
> to disable ssl if IPA is detected.
> 
> During the discussion about this bug it was suggested also to avoid to
> force dependency on mod_ssl or force migration to mod_nss during upgrade
> allowing ipa and engine to coexist. I don't think that that issue should
> be tracked by https://bugzilla.redhat.com/905754 so if there is the will
> to either drop dependency on mod_ssl or migrate to mod_nss please open a
> new bug about that.

Right. I just mentioned that so all will be aware of this abnormality.

> That could solve also another question: what if IPA is installed after
> ovirt-engine?
> 
> In order to act as well behaved application, and co-exist with other
> well behaved applications there is more to do as Alon pointed out.
> I think that any point not satisfied in order to behave correctly need a
> bug to be opened.
> 
> When we'll behave correctly I'll remove any check on IPA presence,
> totally ignoring it and removing any enforcement about its presence.
> 
> Am I missing something?

I don't think so... just am not sure what is the answer in the past for post IPA installation...

Thanks!
Alon


From amureini at redhat.com  Mon May 20 11:37:30 2013
From: amureini at redhat.com (Allon Mureinik)
Date: Mon, 20 May 2013 07:37:30 -0400 (EDT)
Subject: [Engine-devel] cannot attach ISO with latest master
In-Reply-To: <CAEWPe=pzouowFfeh1xiWYq_448Zeq6Vv_yT0va+cc+wiNgjd5g@mail.gmail.com>
References: <CAEWPe=rogGmX_OBNb2f=aMuYucgUqYKiyksDEr75wxfME6uLYQ@mail.gmail.com>
	<CAEWPe=qOXj6oXDb3G=naXFjBH_asHcConWrOJN0wi96CEmgKEg@mail.gmail.com>
	<491385764.2974520.1368721335846.JavaMail.root@redhat.com>
	<CAEWPe=pzouowFfeh1xiWYq_448Zeq6Vv_yT0va+cc+wiNgjd5g@mail.gmail.com>
Message-ID: <951737403.4297063.1369049850983.JavaMail.root@redhat.com>

Just pull the latest master - this patch was already merged. 
(Thanks Omer!) 

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

> From: "Dead Horse" <deadhorseconsulting at gmail.com>
> To: "Allon Mureinik" <amureini at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Saturday, May 18, 2013 12:30:08 AM
> Subject: Re: [Engine-devel] cannot attach ISO with latest master

> I attempted to test the patch however the result was engine compilation
> failure with the webadmin module.
> - DHC

> On Thu, May 16, 2013 at 11:22 AM, Allon Mureinik < amureini at redhat.com >
> wrote:

> > The following patch (still pending review) should do the trick:
> 
> > http://gerrit.ovirt.org/#/c/14818/
> 

> > > From: "Dead Horse" < deadhorseconsulting at gmail.com >
> > 
> 
> > > To: engine-devel at ovirt.org
> > 
> 
> > > Sent: Thursday, May 16, 2013 5:31:23 PM
> > 
> 
> > > Subject: Re: [Engine-devel] cannot attach ISO with latest master
> > 
> 

> > > This occurs only when using "Run Once" to attach an ISO to a VM.
> > 
> 
> > > It is still present in master as of this morning.
> > 
> 
> > > It was reported recently by another user on the user list as well.
> > 
> 
> > > - DHC
> > 
> 

> > > On Mon, May 13, 2013 at 4:47 PM, Dead Horse <
> > > deadhorseconsulting at gmail.com
> > > >
> > > wrote:
> > 
> 

> > > > Cannot attach images from the iso storage domain with latest master.
> > > 
> > 
> 
> > > > VDSM version is latest master as well
> > > 
> > 
> 
> > > > Host = EL6.4
> > > 
> > 
> 

> > > > 2013-05-13 16:41:02,184 INFO
> > > > [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
> > > > (ajp--127.0.0.1-8702-7) [5d889258] START, IsoPrefixVDSCommand(
> > > > storagePoolId
> > > > = 0cba78bd-f1b7-438f-afac-acd59fab92ae, ignoreFailoverLimit = false,
> > > > compatabilityVersion = null), log id: a85d3c0
> > > 
> > 
> 
> > > > 2013-05-13 16:41:02,196 INFO
> > > > [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
> > > > (ajp--127.0.0.1-8702-7) [5d889258] FINISH, IsoPrefixVDSCommand, return:
> > > > /rhev/data-center/mnt/192.168.0.1:_ovirt_dalaran/d6276dc3-1714-4024-9b70-b7971ed5fe35/images/11111111-1111-1111-1111-111111111111,
> > > > log id: a85d3c0
> > > 
> > 
> 
> > > > 2013-05-13 16:41:02,328 WARN
> > > > [org.ovirt.engine.core.bll.RunVmOnceCommand]
> > > > (ajp--127.0.0.1-8702-7) [5d889258] CanDoAction of action RunVmOnce
> > > > failed.
> > > > Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH
> > > 
> > 
> 

> > > > - DHC
> > > 
> > 
> 

> > > _______________________________________________
> > 
> 
> > > Engine-devel mailing list
> > 
> 
> > > Engine-devel at ovirt.org
> > 
> 
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130520/fcad935f/attachment.html>

From smizrahi at redhat.com  Mon May 20 14:51:40 2013
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Mon, 20 May 2013 10:51:40 -0400 (EDT)
Subject: [Engine-devel] VDSM Java Bindings
In-Reply-To: <1713369487.4699723.1369060846987.JavaMail.root@redhat.com>
Message-ID: <791949114.4706149.1369061500319.JavaMail.root@redhat.com>

A preliminary version on the Java bindings is up on gerrit ready for review. It's been
up for a while now but I noticed I forgot to notify the list.

It currently only supports the TCP transport as the Java implementation of
Proton gave me a lot of grief and I wanted to release things ASAP. Also, receiving unions
is still a bit problematic. The will always arrive as the base form of the union
since detection of the concrete type is not implemented yet. I also don't like how unions
works ATM and would like to come up with a system that makes them more easily detectable.

You can review the code here
http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:json_rpc_r,n,z

An example project showing how to set up a Java project and connect to a VDSM instance.
https://github.com/ficoos/vdsmhello

I would like to have more feedback about how the interface is exported and generated.
Getting the interface right is much more important to me at the moment than performance
tweaks and corner cases.


From bigclouds at 163.com  Mon May 20 15:44:38 2013
From: bigclouds at 163.com (bigclouds)
Date: Mon, 20 May 2013 23:44:38 +0800 (CST)
Subject: [Engine-devel] how to let engine run scripts with root privilege
Message-ID: <48b7b5d.160bb.13ec29d22e7.Coremail.bigclouds@163.com>

hi,
engine run as a normal user, but sometimes we need it to run scripts(start,stop services) which require root privilege.
how to do that?
 
thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130520/6de5cabb/attachment.html>

From alonbl at redhat.com  Mon May 20 15:48:01 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 20 May 2013 11:48:01 -0400 (EDT)
Subject: [Engine-devel] how to let engine run scripts with root privilege
In-Reply-To: <48b7b5d.160bb.13ec29d22e7.Coremail.bigclouds@163.com>
References: <48b7b5d.160bb.13ec29d22e7.Coremail.bigclouds@163.com>
Message-ID: <904238912.2523292.1369064881893.JavaMail.root@redhat.com>



----- Original Message -----
> From: "bigclouds" <bigclouds at 163.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, May 20, 2013 6:44:38 PM
> Subject: [Engine-devel] how to let engine run scripts with root privilege
> 
> hi,
> engine run as a normal user, but sometimes we need it to run
> scripts(start,stop services) which require root privilege.
> how to do that?
> thanks.

Use sudo?


From lhornyak at redhat.com  Mon May 20 15:51:31 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 20 May 2013 11:51:31 -0400 (EDT)
Subject: [Engine-devel] how to let engine run scripts with root privilege
In-Reply-To: <48b7b5d.160bb.13ec29d22e7.Coremail.bigclouds@163.com>
References: <48b7b5d.160bb.13ec29d22e7.Coremail.bigclouds@163.com>
Message-ID: <1106593315.3743386.1369065091008.JavaMail.root@redhat.com>

Hi,

Do you need to run these scripts on the engine environment? Not VDSM?

----- Original Message -----
> From: "bigclouds" <bigclouds at 163.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, May 20, 2013 5:44:38 PM
> Subject: [Engine-devel] how to let engine run scripts with root privilege
> 
> hi,
> engine run as a normal user, but sometimes we need it to run
> scripts(start,stop services) which require root privilege.
> how to do that?
> thanks.
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Tue May 21 06:54:26 2013
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 21 May 2013 02:54:26 -0400 (EDT)
Subject: [Engine-devel] SQL procedure - row mapper
In-Reply-To: <519609BC.1040907@redhat.com>
References: <5195F9A7.3090003@redhat.com>
	<22874352.2868063.1368785939072.JavaMail.root@redhat.com>
	<519609BC.1040907@redhat.com>
Message-ID: <700385805.4784522.1369119266555.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sahina Bose" <sabose at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, May 17, 2013 1:43:08 PM
> Subject: Re: [Engine-devel] SQL procedure - row mapper
> 
> Hi Laszlo,
> 
> I wanted a way to return a hook entity (GlusterHookEntity) as well as
> content of the hook. So had a single procedure getGlusterHookById(id
> UUID, includeContent BOOLEAN) but 2 dao methods
> getGlusterHook - returns GlusterHookEntity
> getGlusterHookContent - returns String (used a RowMapper to get only
> content from resultset)
> 
> But the second method caused a ClassCastException due to the first
> RowMapper being used.
> 
> Anyways, this is the patch where I changed the implementation to use
> separate sp - http://gerrit.ovirt.org/#/c/14832

This is the right way to do so , I will look at that patch 

> 
> thanks!
> sahina
> 
> On 05/17/2013 03:48 PM, Laszlo Hornyak wrote:
> > Hi Sahina,
> >
> > Could you share more details what you are trying to do?
> > A procedure always returns the same structure of data, so maybe it is more
> > simple if you to return all the data you received from the plpgsql stored
> > procedure and then just use the data mapped into the beans to build your
> > own data structures.
> >
> > Laszlo
> >
> > ----- Original Message -----
> >> From: "Sahina Bose" <sabose at redhat.com>
> >> To: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Friday, May 17, 2013 11:34:31 AM
> >> Subject: [Engine-devel] SQL procedure - row mapper
> >>
> >> Hi all,
> >>
> >> In org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler , there's a
> >> map maintained for procedure name and SimpleJdbcCall.
> >>
> >> If I have the same procedure with different row mappers, this results in
> >> an error - because the map already contains a mapping for the procedure
> >> name but with different row mapper.
> >>
> >> Do we intend to support calling the same procedure with different
> >> RowMappers? If so, I can change this class to handle this.
> >>
> >> thanks
> >> sahina
> >> _______________________________________________
> >> 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 mpastern at redhat.com  Tue May 21 09:53:07 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 21 May 2013 12:53:07 +0300
Subject: [Engine-devel] [REST-API] Support passing auth information
 without having to use HTTP Authorization header #958874
In-Reply-To: <1148533336.1301072.1368540821616.JavaMail.root@redhat.com>
References: <518751C7.8090208@redhat.com>
	<1665518752.4971723.1367945088296.JavaMail.root@redhat.com>
	<518B6C07.1080504@redhat.com>
	<1148533336.1301072.1368540821616.JavaMail.root@redhat.com>
Message-ID: <519B4403.8010908@redhat.com>

Hi Vojtech,

On 05/14/2013 05:13 PM, Vojtech Szocs wrote:
> Hi guys,
> 
> I followed this thread, there are some interesting points, sending my comments below.
> 
> First of all, I understand that REST API should follow common REST principles, and 
> implement additional features (such as authentication) seamlessly on top of these principles, if possible.
> 
> It's just that sometimes, especially in JavaScript/HTML world, there are known issues (limitations) for 
> which a good REST API implementation should provide reasonable workarounds. For me, this means two things:
> (a) issue with browser-specific HTTP 'Authorization' header handling for JavaScript apps [https://bugzilla.redhat.com/958861]
> (b) issue with browser-specific cookie handling restriction for JavaScript apps [*]

this is to avoid cross-site/cross-subdomain cookie attacks.

> [*] long story short: JavaScript app hosted from "/myapp/index.html" cannot access cookies for say "/api" 
> path, only for "/myapp" path, i.e. cookies are under control of browser and not JavaScript app, more details: http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path
> 
> Both issues written above have something (very important) in common: "browser-specific" + 
> browser having control (over 'Authorization' header / cookies) instead of JavaScript app..

none of these two is a REST specific, those just two (another) authentication methods,
and there are plenty of others that can be used.

> 
> @Michael: is there some RFE/document for your "URI based authentication" proposal? Assuming JSESSIONID 
> could be passed via URI, we could use this as a workaround for browser-specific cookie handling restriction. 
> In practice, this would mean any JavaScript (WebAdmin itself, UI Plugin, any other web app) could talk to REST
> API without relying on cookies entirely. Even better, if we could pass auth credentials via URI, we could talk to 
> REST API without relying on HTTP 'Authorization' header entirely.

in order to avoid link sharing problems and fixation attacks, for this pattern to work,
we will have to regenerating SID on each request,

this approach will give us a better view on given plugin activity via web server/proxy logs/etc.,
but doubt if it worth the effort, cause same may be tuned on the engine side,

i guess it's just another way to do the same.

> 
> Also, I'm not strictly against HTTP Basic Auth used in REST API, I just pointed out some of its drawbacks 
> (a while ago). Originally, I proposed to support alternative (extra) auth scheme that is better and more secure, 
> but in the end, I guess we should settle for one reasonably good auth scheme. I looked at SPNEGO [http://en.wikipedia.org/wiki/SPNEGO] 
> - it looks interesting, basically a protocol for negotiating specific auth scheme based on what server supports, the question is 
> if we really need to support multiple auth schemes, or just one that is reasonably good.

we may have to support kerberos auth in future. - SPNEGO/OAuth are good candidates for this.

> 
> One auth scheme I really like is [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html] - basically preventing 
> password from being sent over the network entirely, which is always a good thing. The disadvantage is that the server has to know 
> password ("secret key") in plain-text for the given user, in order to re-produce & compare signature (hash) of relevant request 
> information. 

and this is a giant "cons".

> On the other hand, Gerrit REST API uses HTTP Digest Auth [https://gerrit-review.googlesource.com/Documentation/rest-api.html#_protocol_details] 
> but IMHO Digest Auth is over-complicated protocol, most importantly its too complex for clients to implement.
> 
>> and this why we having this discussion, currently options are:
>> 1. adapt session based authentication
>> 2. introduce new concept
> 
> I'd vote for auth scheme that doesn't contradict general REST principles but is reasonably good (easy & secure). 
> One thing is the auth protocol itself (HTTP Basic Auth), another is how auth-related information is transmitted 
> between client and server (HTTP 'Authorization' header, JSESSIONID cookie) - for now I'd just proposed to revisit 
> the "auth-related info transmission" part..

i tend to agree on this, the most simple way of supporting browsers in this stage is among cookie,
obtaining SID from the headers.

> 
> Regards,
> Vojtech
> 

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From vszocs at redhat.com  Tue May 21 10:40:42 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 21 May 2013 06:40:42 -0400 (EDT)
Subject: [Engine-devel] [REST-API] Support passing auth information
 without having to use HTTP Authorization header #958874
In-Reply-To: <519B4403.8010908@redhat.com>
References: <518751C7.8090208@redhat.com>
	<1665518752.4971723.1367945088296.JavaMail.root@redhat.com>
	<518B6C07.1080504@redhat.com>
	<1148533336.1301072.1368540821616.JavaMail.root@redhat.com>
	<519B4403.8010908@redhat.com>
Message-ID: <1138191239.5277253.1369132842565.JavaMail.root@redhat.com>

Hi Michael,

----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "Einav Cohen" <ecohen at redhat.com>, "Itamar Heim" <iheim at redhat.com>, "Juan
> Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Barak Azulay" <bazulay at redhat.com>
> Sent: Tuesday, May 21, 2013 11:53:07 AM
> Subject: Re: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
> 
> Hi Vojtech,
> 
> On 05/14/2013 05:13 PM, Vojtech Szocs wrote:
> > Hi guys,
> > 
> > I followed this thread, there are some interesting points, sending my
> > comments below.
> > 
> > First of all, I understand that REST API should follow common REST
> > principles, and
> > implement additional features (such as authentication) seamlessly on top of
> > these principles, if possible.
> > 
> > It's just that sometimes, especially in JavaScript/HTML world, there are
> > known issues (limitations) for
> > which a good REST API implementation should provide reasonable workarounds.
> > For me, this means two things:
> > (a) issue with browser-specific HTTP 'Authorization' header handling for
> > JavaScript apps [https://bugzilla.redhat.com/958861]
> > (b) issue with browser-specific cookie handling restriction for JavaScript
> > apps [*]
> 
> this is to avoid cross-site/cross-subdomain cookie attacks.

You're right, but my point was, dealing with cookies in JavaScript/HTML world is problematic in general, and good API should provide reasonable workaround for this.

For example, a web application at "/myapp" interacts with "/restapi" via AJAX and due to same-path restriction (on top of same-origin), the application doesn't have full control over (cannot get/set) cookies obtained from "/restapi", it can only rely on the standard browser behavior, i.e. browser should take care of sending cookies for "/restapi" for any subsequent request to "/restapi".

> > [*] long story short: JavaScript app hosted from "/myapp/index.html" cannot
> > access cookies for say "/api"
> > path, only for "/myapp" path, i.e. cookies are under control of browser and
> > not JavaScript app, more details:
> > http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path
> > 
> > Both issues written above have something (very important) in common:
> > "browser-specific" +
> > browser having control (over 'Authorization' header / cookies) instead of
> > JavaScript app..
> 
> none of these two is a REST specific, those just two (another) authentication
> methods,

True, but both of these are currently required for Engine REST API persistent session mechanism to work, i.e. you have to use Authorization header for passing credentials, and you have to send JSESSIONID cookie in order to reuse given session.

> and there are plenty of others that can be used.

Yes, my original idea/suggestion was to use special (non-Authorization) header for credentials, and also special (non-Cookie) header for the JSESSIONID cookie.

> > 
> > @Michael: is there some RFE/document for your "URI based authentication"
> > proposal? Assuming JSESSIONID
> > could be passed via URI, we could use this as a workaround for
> > browser-specific cookie handling restriction.
> > In practice, this would mean any JavaScript (WebAdmin itself, UI Plugin,
> > any other web app) could talk to REST
> > API without relying on cookies entirely. Even better, if we could pass auth
> > credentials via URI, we could talk to
> > REST API without relying on HTTP 'Authorization' header entirely.
> 
> in order to avoid link sharing problems and fixation attacks, for this
> pattern to work,
> we will have to regenerating SID on each request,

I agree.

> this approach will give us a better view on given plugin activity via web
> server/proxy logs/etc.,
> but doubt if it worth the effort, cause same may be tuned on the engine side,

This approach would fix our two issues mentioned above: 1) need for Authorization header, 2) need for JSESSIONID cookie.

> i guess it's just another way to do the same.
> 
> > 
> > Also, I'm not strictly against HTTP Basic Auth used in REST API, I just
> > pointed out some of its drawbacks
> > (a while ago). Originally, I proposed to support alternative (extra) auth
> > scheme that is better and more secure,
> > but in the end, I guess we should settle for one reasonably good auth
> > scheme. I looked at SPNEGO [http://en.wikipedia.org/wiki/SPNEGO]
> > - it looks interesting, basically a protocol for negotiating specific auth
> > scheme based on what server supports, the question is
> > if we really need to support multiple auth schemes, or just one that is
> > reasonably good.
> 
> we may have to support kerberos auth in future. - SPNEGO/OAuth are good
> candidates for this.

I agree.

> > 
> > One auth scheme I really like is
> > [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html] -
> > basically preventing
> > password from being sent over the network entirely, which is always a good
> > thing. The disadvantage is that the server has to know
> > password ("secret key") in plain-text for the given user, in order to
> > re-produce & compare signature (hash) of relevant request
> > information.
> 
> and this is a giant "cons".

Yes, there's no silver bullet :)

But why is Amazon S3 using this auth scheme, if it has such a big con? (just teasing) :)

> > On the other hand, Gerrit REST API uses HTTP Digest Auth
> > [https://gerrit-review.googlesource.com/Documentation/rest-api.html#_protocol_details]
> > but IMHO Digest Auth is over-complicated protocol, most importantly its too
> > complex for clients to implement.
> > 
> >> and this why we having this discussion, currently options are:
> >> 1. adapt session based authentication
> >> 2. introduce new concept
> > 
> > I'd vote for auth scheme that doesn't contradict general REST principles
> > but is reasonably good (easy & secure).
> > One thing is the auth protocol itself (HTTP Basic Auth), another is how
> > auth-related information is transmitted
> > between client and server (HTTP 'Authorization' header, JSESSIONID cookie)
> > - for now I'd just proposed to revisit
> > the "auth-related info transmission" part..
> 
> i tend to agree on this, the most simple way of supporting browsers in this
> stage is among cookie,
> obtaining SID from the headers.

If it's non-Set-Cookie header, I'm all for it! As mentioned many times in this thread, cookie handling is problematic in JavaScript/HTML clients, which are not full-blown web clients, they are essentially sandboxed "tabs" running in a full-blown web client -> browser :)

> 
> > 
> > Regards,
> > Vojtech
> > 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From dkelson at gurulabs.com  Tue May 21 17:44:33 2013
From: dkelson at gurulabs.com (Dax Kelson)
Date: Tue, 21 May 2013 11:44:33 -0600
Subject: [Engine-devel] Any tips for running ovirt from trunk on Fedora 19
	Beta RC2?
Message-ID: <CAFDa5Q0EC5gDbBi2OwsjMLRWWAo=MJ8v==aOVcQ+AbxcR8aBiw@mail.gmail.com>

I did a git checkout and created rpms with "make rpm".

I used engine-setup-2. Is that correct? engine-setup fails btw

Going to the web page gives a error 503 "The server is temporarily
unable to service your request due to maintenance downtime or capacity
problems. Please try again later."

Under /var/log/ovirt-egine/ I see:

console.log

Exception in thread "main" javax.management.JMRuntimeException: Failed
to load MBeanServerBuilder class
org.jboss.as.jmx.PluggableMBeanServerBuilder:
java.lang.ClassNotFoundException:
org.jboss.as.jmx.PluggableMBeanServerBuilder from [Module
"org.jboss.as.standalone:main" from local module loader @72e1c560
(roots: /usr/share/ovirt-engine/modules,/var/tmp/ovirt-engine/modules)]
    at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:502)
    at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:538)
    at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:315)
    at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:230)
    at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:191)
    at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:466)
    at org.jboss.modules.Main.main(Main.java:286)
Caused by: java.lang.ClassNotFoundException:
org.jboss.as.jmx.PluggableMBeanServerBuilder from [Module
"org.jboss.as.standalone:main" from local module loader @72e1c560
(roots: /usr/share/ovirt-engine/modules,/var/tmp/ovirt-engine/modules)]
    at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
    at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
    at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
    at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
    at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
    at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:445)
    at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:487)
    ... 6 more
Traceback (most recent call last):
  File "/usr/lib64/python2.7/logging/handlers.py", line 859, in emit
    self._connect_unixsocket(self.address)
  File "/usr/lib64/python2.7/logging/handlers.py", line 777, in
_connect_unixsocket
    self.socket.connect(address)
  File "/usr/lib64/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 9] Bad file descriptor
Logged from file service.py, line 557

from boot.log

11:35:03,354 INFO  [org.jboss.modules] JBoss Modules version 1.1.1.GA
11:35:03,499 WARN  [org.jboss.modules] Failed to define class
org.jboss.as.jmx.PluggableMBeanServerBuilder in Module
"org.jboss.as.jmx:main" from local module loader @72e1c560 (roots:
/usr/share/ovirt-engine/modules,/var/tmp/ovirt-engine/modules):
org.jboss.modules.ModuleLoadError: Error loading module from
/var/tmp/ovirt-engine/modules/org/jboss/logging/main/module.xml
    at org.jboss.modules.ModuleLoadException.toError(ModuleLoadException.java:78)
    at org.jboss.modules.Module.getPathsUnchecked(Module.java:1181)
    at org.jboss.modules.Module.loadModuleClass(Module.java:512)
    at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
    at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
    at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
    at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
    at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
    at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_19]
    at java.lang.ClassLoader.defineClass(ClassLoader.java:791) [rt.jar:1.7.0_19]
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
[rt.jar:1.7.0_19]
    at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:327)
    at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:391)
    at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
    at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
    at org.jboss.modules.Module.loadModuleClass(Module.java:517)
    at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
    at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
    at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
    at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
    at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
    at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:445)
[rt.jar:1.7.0_19]
    at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:487)
[rt.jar:1.7.0_19]
    at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:538)
[rt.jar:1.7.0_19]
    at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:315)
[rt.jar:1.7.0_19]
    at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:230)
[rt.jar:1.7.0_19]
    at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:191)
[rt.jar:1.7.0_19]
    at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:466)
[rt.jar:1.7.0_19]
    at org.jboss.modules.Main.main(Main.java:286)
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[27,50]
Message: Failed to add resource root 'jboss-logging.jar' at path
'jboss-logging.jar'
    at org.jboss.modules.ModuleXmlParser.parseResourceRoot(ModuleXmlParser.java:898)
    at org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:854)
    at org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:676)
    at org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:548)
    at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:287)
    at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:242)
    at org.jboss.modules.LocalModuleLoader.parseModuleInfoFile(LocalModuleLoader.java:138)
    at org.jboss.modules.LocalModuleLoader.findModule(LocalModuleLoader.java:122)
    at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:275)
    at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:222)
    at org.jboss.modules.LocalModuleLoader.preloadModule(LocalModuleLoader.java:94)
    at org.jboss.modules.Module.addPaths(Module.java:841)
    at org.jboss.modules.Module.link(Module.java:1196)
    at org.jboss.modules.Module.getPaths(Module.java:1156)
    at org.jboss.modules.Module.getPathsUnchecked(Module.java:1179)
    ... 27 more


From lhornyak at redhat.com  Wed May 22 06:52:42 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 22 May 2013 02:52:42 -0400 (EDT)
Subject: [Engine-devel] searchbackend cleanup
In-Reply-To: <1648934874.4654930.1369205383605.JavaMail.root@redhat.com>
Message-ID: <659774595.4655406.1369205562850.JavaMail.root@redhat.com>

Hi,

I have a patchset for the searchbackend waiting for review. Anyone could give me +2?

http://gerrit.ovirt.org/14616/
http://gerrit.ovirt.org/14617/
http://gerrit.ovirt.org/14618/
http://gerrit.ovirt.org/14619/
http://gerrit.ovirt.org/14620/

Thx,
Laszlo


From wlbleaboy at 126.com  Wed May 22 06:59:24 2013
From: wlbleaboy at 126.com (wlbleaboy@126)
Date: Wed, 22 May 2013 14:59:24 +0800
Subject: [Engine-devel] about ovirt-shell
Message-ID: <000a01ce56b9$e602e150$b208a3f0$@com>

Hi all:

         When I connect to ovirt-engine use ovirt-shell like this: It's
failed, I don't know why.

The ovirt-engine is build and deployed by myself and base ovirt-engine 3.2

 

         But when I connect to the ovirt-engine use rmp installed,
ovirt-shell work well.

 

 

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

 

           Welcome to oVirt shell

 

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

        

    

[oVirt shell (disconnected)]# connect --url http://192.168.1.201 --user
admin at internal --password 111111

 

 

error: [ERROR]::No response returned from server. If you're using HTTP
protocol

against a SSL secured server, then try using HTTPS instead.

 

 

[oVirt shell (disconnected)]#

 

 

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

From masayag at redhat.com  Wed May 22 07:36:10 2013
From: masayag at redhat.com (Moti Asayag)
Date: Wed, 22 May 2013 10:36:10 +0300
Subject: [Engine-devel] about ovirt-shell
In-Reply-To: <000a01ce56b9$e602e150$b208a3f0$@com>
References: <000a01ce56b9$e602e150$b208a3f0$@com>
Message-ID: <519C756A.3080908@redhat.com>

On 05/22/2013 09:59 AM, wlbleaboy at 126 wrote:
> Hi all:
> 
>          When I connect to ovirt-engine use ovirt-shell like this: It?s
> failed, I don?t know why.
> 
> The ovirt-engine is build and deployed by myself and base ovirt-engine 3.2
> 
>  
> 
>          But when I connect to the ovirt-engine use rmp installed,
> ovirt-shell work well.
> 
>  
> 
>  
> 
> ++++++++++++++++++++++++++++++++++++++++++
> 
>  
> 
>            Welcome to oVirt shell
> 
>  
> 
>  ++++++++++++++++++++++++++++++++++++++++++
> 
>        
> 
>    
> 
> [oVirt shell (disconnected)]# connect --url http://192.168.1.201 --user
> admin at internal --password 111111

The URL should be in a format of http://address:port/api

for example:

if running from the command line, you can connect to it via (verify your
host address and port):

ovirt-shell -l http://localhost:8080/api -u admin at internal -c

and provide the password when prompted to.

> 
>  
> 
>  
> 
> error: [ERROR]::No response returned from server. If you're using HTTP
> protocol
> 
> against a SSL secured server, then try using HTTPS instead.
> 
>  
> 
>  
> 
> [oVirt shell (disconnected)]#
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From wlbleaboy at 126.com  Wed May 22 07:51:40 2013
From: wlbleaboy at 126.com (wlbleaboy@126)
Date: Wed, 22 May 2013 15:51:40 +0800
Subject: [Engine-devel] =?gb2312?b?tPC4tDogIGFib3V0IG92aXJ0LXNoZWxs?=
In-Reply-To: <519C756A.3080908@redhat.com>
References: <000a01ce56b9$e602e150$b208a3f0$@com> <519C756A.3080908@redhat.com>
Message-ID: <000f01ce56c1$335ec9d0$9a1c5d70$@com>

I got the failed info like this

error: [ERROR]::oVirt API connection failure, [Errno 185090050] _ssl.c:340:
error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib

when I used ovirt-shell -l https://192.168.1.198:443/api -u admin at internal
-c -A ~/.spicec/ca.crt

-----????-----
???: Moti Asayag [mailto:masayag at redhat.com] 
????: 2013?5?22? 15:36
???: wlbleaboy at 126
??: engine-devel at ovirt.org
??: Re: [Engine-devel] about ovirt-shell

On 05/22/2013 09:59 AM, wlbleaboy at 126 wrote:
> Hi all:
> 
>          When I connect to ovirt-engine use ovirt-shell like this: It?s
> failed, I don?t know why.
> 
> The ovirt-engine is build and deployed by myself and base ovirt-engine 3.2
> 
>  
> 
>          But when I connect to the ovirt-engine use rmp installed,
> ovirt-shell work well.
> 
>  
> 
>  
> 
> ++++++++++++++++++++++++++++++++++++++++++
> 
>  
> 
>            Welcome to oVirt shell
> 
>  
> 
>  ++++++++++++++++++++++++++++++++++++++++++
> 
>        
> 
>    
> 
> [oVirt shell (disconnected)]# connect --url http://192.168.1.201 --user
> admin at internal --password 111111

The URL should be in a format of http://address:port/api

for example:

if running from the command line, you can connect to it via (verify your
host address and port):

ovirt-shell -l http://localhost:8080/api -u admin at internal -c

and provide the password when prompted to.

> 
>  
> 
>  
> 
> error: [ERROR]::No response returned from server. If you're using HTTP
> protocol
> 
> against a SSL secured server, then try using HTTPS instead.
> 
>  
> 
>  
> 
> [oVirt shell (disconnected)]#
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 




From avishwan at redhat.com  Wed May 22 09:41:19 2013
From: avishwan at redhat.com (Aravinda)
Date: Wed, 22 May 2013 15:11:19 +0530
Subject: [Engine-devel] =?gb2312?b?tPC4tDogIGFib3V0IG92aXJ0LXNoZWxs?=
In-Reply-To: <000f01ce56c1$335ec9d0$9a1c5d70$@com>
References: <000a01ce56b9$e602e150$b208a3f0$@com> <519C756A.3080908@redhat.com>
	<000f01ce56c1$335ec9d0$9a1c5d70$@com>
Message-ID: <519C92BF.5010406@redhat.com>

On 05/22/2013 01:21 PM, wlbleaboy at 126 wrote:
> I got the failed info like this
>
> error: [ERROR]::oVirt API connection failure, [Errno 185090050] _ssl.c:340:
> error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib
>
> when I used ovirt-shell -l https://192.168.1.198:443/api -u admin at internal
> -c -A ~/.spicec/ca.crt
Try without -c
-c is to connect automatically using the credentials present in file
~/.ovirtshellrc


> -----????-----
> ???: Moti Asayag [mailto:masayag at redhat.com] 
> ????: 2013?5?22? 15:36
> ???: wlbleaboy at 126
> ??: engine-devel at ovirt.org
> ??: Re: [Engine-devel] about ovirt-shell
>
> On 05/22/2013 09:59 AM, wlbleaboy at 126 wrote:
>> Hi all:
>>
>>          When I connect to ovirt-engine use ovirt-shell like this: It?s
>> failed, I don?t know why.
>>
>> The ovirt-engine is build and deployed by myself and base ovirt-engine 3.2
>>
>>  
>>
>>          But when I connect to the ovirt-engine use rmp installed,
>> ovirt-shell work well.
>>
>>  
>>
>>  
>>
>> ++++++++++++++++++++++++++++++++++++++++++
>>
>>  
>>
>>            Welcome to oVirt shell
>>
>>  
>>
>>  ++++++++++++++++++++++++++++++++++++++++++
>>
>>        
>>
>>    
>>
>> [oVirt shell (disconnected)]# connect --url http://192.168.1.201 --user
>> admin at internal --password 111111
> The URL should be in a format of http://address:port/api
>
> for example:
>
> if running from the command line, you can connect to it via (verify your
> host address and port):
>
> ovirt-shell -l http://localhost:8080/api -u admin at internal -c
>
> and provide the password when prompted to.
>
>>  
>>
>>  
>>
>> error: [ERROR]::No response returned from server. If you're using HTTP
>> protocol
>>
>> against a SSL secured server, then try using HTTPS instead.
>>
>>  
>>
>>  
>>
>> [oVirt shell (disconnected)]#
>>
>>  
>>
>>  
>>
>>
>>
>> _______________________________________________
>> 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

--
Aravinda


From jhernand at redhat.com  Wed May 22 10:35:56 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 22 May 2013 12:35:56 +0200
Subject: [Engine-devel] Any reason to use UUID instead of name or dn?
Message-ID: <519C9F8C.3090404@redhat.com>

Hello all,

I am working on a series of changes with the objective to simplify the 
LDAP layer and make it more generic. One of the things that I would like 
to do is to use the name or dn attributes to identify the users/group 
instead of the UUIDs as we currently do. Can someone explain me if there 
is any powerful reason to use the directory specific UUIDs (objectGUID 
in ActiveDirectory, nsUniqueId in RHDS, etc) instead of user/group names 
or distinguished names?

Thanks in advance,
Juan Hernandez
-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From alonbl at redhat.com  Wed May 22 10:47:42 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 22 May 2013 06:47:42 -0400 (EDT)
Subject: [Engine-devel] Any reason to use UUID instead of name or dn?
In-Reply-To: <519C9F8C.3090404@redhat.com>
References: <519C9F8C.3090404@redhat.com>
Message-ID: <491682690.3222344.1369219662668.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, May 22, 2013 1:35:56 PM
> Subject: [Engine-devel] Any reason to use UUID instead of name or dn?
> 
> Hello all,
> 
> I am working on a series of changes with the objective to simplify the
> LDAP layer and make it more generic. One of the things that I would like
> to do is to use the name or dn attributes to identify the users/group
> instead of the UUIDs as we currently do. Can someone explain me if there
> is any powerful reason to use the directory specific UUIDs (objectGUID
> in ActiveDirectory, nsUniqueId in RHDS, etc) instead of user/group names
> or distinguished names?

Hi,

If you define an entity and then delete and define an entity at the same name, the new entity should not inherit the permissions of the previous entity.

So resource based security always hold unique identifier for entities, it can be UUID, UID or any unique string. 

Regards,
Alon.


From wlbleaboy at 126.com  Wed May 22 11:28:55 2013
From: wlbleaboy at 126.com (wlbleaboy@126)
Date: Wed, 22 May 2013 19:28:55 +0800
Subject: [Engine-devel] =?gb2312?b?tPC4tDogILTwuLQ6ICBhYm91dCBvdmlydC1z?=
	=?gb2312?b?aGVsbA==?=
In-Reply-To: <519C92BF.5010406@redhat.com>
References: <000a01ce56b9$e602e150$b208a3f0$@com> <519C756A.3080908@redhat.com>
	<000f01ce56c1$335ec9d0$9a1c5d70$@com> <519C92BF.5010406@redhat.com>
Message-ID: <001001ce56df$8d522630$a7f67290$@com>

Hi, all:
	I solved it.
The ovirtsdk I used is ovirt-engine-sdk 3.2.0.6, the ovirt-engine is 3.2,
Afternoon, I update ovirt-sdek-engine to 3.2.0.11, and when assign --ca-file
I use "/home/leaboy/.spicec/ca.crt" replace the " ~/.spicec/ca.crt"
And then, it work well.

-----????-----
???: Aravinda [mailto:avishwan at redhat.com] 
????: 2013?5?22? 17:41
???: wlbleaboy at 126
??: 'Moti Asayag'; engine-devel at ovirt.org
??: Re: [Engine-devel] ??: about ovirt-shell

On 05/22/2013 01:21 PM, wlbleaboy at 126 wrote:
> I got the failed info like this
>
> error: [ERROR]::oVirt API connection failure, [Errno 185090050]
_ssl.c:340:
> error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system
lib
>
> when I used ovirt-shell -l https://192.168.1.198:443/api -u admin at internal
> -c -A ~/.spicec/ca.crt
Try without -c
-c is to connect automatically using the credentials present in file
~/.ovirtshellrc


> -----????-----
> ???: Moti Asayag [mailto:masayag at redhat.com] 
> ????: 2013?5?22? 15:36
> ???: wlbleaboy at 126
> ??: engine-devel at ovirt.org
> ??: Re: [Engine-devel] about ovirt-shell
>
> On 05/22/2013 09:59 AM, wlbleaboy at 126 wrote:
>> Hi all:
>>
>>          When I connect to ovirt-engine use ovirt-shell like this: It?s
>> failed, I don?t know why.
>>
>> The ovirt-engine is build and deployed by myself and base ovirt-engine 3.
2
>>
>>  
>>
>>          But when I connect to the ovirt-engine use rmp installed,
>> ovirt-shell work well.
>>
>>  
>>
>>  
>>
>> ++++++++++++++++++++++++++++++++++++++++++
>>
>>  
>>
>>            Welcome to oVirt shell
>>
>>  
>>
>>  ++++++++++++++++++++++++++++++++++++++++++
>>
>>        
>>
>>    
>>
>> [oVirt shell (disconnected)]# connect --url http://192.168.1.201 --user
>> admin at internal --password 111111
> The URL should be in a format of http://address:port/api
>
> for example:
>
> if running from the command line, you can connect to it via (verify your
> host address and port):
>
> ovirt-shell -l http://localhost:8080/api -u admin at internal -c
>
> and provide the password when prompted to.
>
>>  
>>
>>  
>>
>> error: [ERROR]::No response returned from server. If you're using HTTP
>> protocol
>>
>> against a SSL secured server, then try using HTTPS instead.
>>
>>  
>>
>>  
>>
>> [oVirt shell (disconnected)]#
>>
>>  
>>
>>  
>>
>>
>>
>> _______________________________________________
>> 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

--
Aravinda




From wlbleaboy at 126.com  Wed May 22 11:38:13 2013
From: wlbleaboy at 126.com (wlbleaboy@126)
Date: Wed, 22 May 2013 19:38:13 +0800
Subject: [Engine-devel] about user roles
Message-ID: <001101ce56e0$d7d6e190$8784a4b0$@com>

Hi all:

         I have a question about user role.

Recently, I connect to ovirt-engine by ovirt-engine-sdk, use the
admin at internal 

login is ok, because admin have System Permissions. 

 

         But , when I have a domain named ovirt.test.com, and have a user
name leaboy

in ovirt.test.com, leaboy at ovirt.test.com can't to login ovirt-engine. I
think maybe leaboy

don't have permissions to login ovirt-engine. So , I want to know how can I
do let leaboy

login ovirt-engine, or some exist roles can let leaboy login.

 

                                               Thanks. 

 

 

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

From lhornyak at redhat.com  Wed May 22 12:19:21 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 22 May 2013 08:19:21 -0400 (EDT)
Subject: [Engine-devel] for a few clicks less
In-Reply-To: <1236261732.4741616.1369223662468.JavaMail.root@redhat.com>
Message-ID: <625194939.4750020.1369225161764.JavaMail.root@redhat.com>

Hi,

Today the default memory size when creating a VM is 512 MB, this is coming from the Blank template, which is not modifiable by user.
This amount of memory is not enough for a installation for most Linux distros (and possibly for other mainstream OS either) so I think it would make sense to increase the default memory size to 1024 MB, for most users, it would save some time.

This patch changes the memory size for new installations.
http://gerrit.ovirt.org/14747

Thx,
Laszlo


From iheim at redhat.com  Wed May 22 12:21:31 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 22 May 2013 15:21:31 +0300
Subject: [Engine-devel] for a few clicks less
In-Reply-To: <625194939.4750020.1369225161764.JavaMail.root@redhat.com>
References: <625194939.4750020.1369225161764.JavaMail.root@redhat.com>
Message-ID: <519CB84B.10204@redhat.com>

On 05/22/2013 03:19 PM, Laszlo Hornyak wrote:
> Hi,
>
> Today the default memory size when creating a VM is 512 MB, this is coming from the Blank template, which is not modifiable by user.
> This amount of memory is not enough for a installation for most Linux distros (and possibly for other mainstream OS either) so I think it would make sense to increase the default memory size to 1024 MB, for most users, it would save some time.
>
> This patch changes the memory size for new installations.
> http://gerrit.ovirt.org/14747
>
> Thx,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

makes sense to me.
looking at the patch - worth handling upgrade as well?


From iheim at redhat.com  Wed May 22 12:22:59 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 22 May 2013 15:22:59 +0300
Subject: [Engine-devel] about user roles
In-Reply-To: <001101ce56e0$d7d6e190$8784a4b0$@com>
References: <001101ce56e0$d7d6e190$8784a4b0$@com>
Message-ID: <519CB8A3.7030800@redhat.com>

On 05/22/2013 02:38 PM, wlbleaboy at 126 wrote:
> Hi all:
>
>           I have a question about user role.
>
> Recently, I connect to ovirt-engine by ovirt-engine-sdk, use the
> admin at internal
>
> login is ok, because admin have System Permissions.
>
>           But , when I have a domain named ovirt.test.com, and have a
> user name leaboy
>
> in ovirt.test.com, leaboy at ovirt.test.com <mailto:leaboy at ovirt.test.com>
> can?t to login ovirt-engine. I think maybe leaboy
>
> don?t have permissions to login ovirt-engine. So , I want to know how
> can I do let leaboy
>
> login ovirt-engine, or some exist roles can let leaboy login.
>
>                                                 Thanks.
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

you need to pass the ?filter? HTTP header, with a value of ?true".


From michal.skrivanek at redhat.com  Wed May 22 12:35:16 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Wed, 22 May 2013 14:35:16 +0200
Subject: [Engine-devel] for a few clicks less
In-Reply-To: <519CB84B.10204@redhat.com>
References: <625194939.4750020.1369225161764.JavaMail.root@redhat.com>
	<519CB84B.10204@redhat.com>
Message-ID: <B95DC182-12B6-4E47-A773-A50570A33F1B@redhat.com>


On May 22, 2013, at 14:21 , Itamar Heim <iheim at redhat.com> wrote:

> On 05/22/2013 03:19 PM, Laszlo Hornyak wrote:
>> Hi,
>> 
>> Today the default memory size when creating a VM is 512 MB, this is coming from the Blank template, which is not modifiable by user.
>> This amount of memory is not enough for a installation for most Linux distros (and possibly for other mainstream OS either) so I think it would make sense to increase the default memory size to 1024 MB, for most users, it would save some time.
>> 
>> This patch changes the memory size for new installations.
>> http://gerrit.ovirt.org/14747
Roy is working on integration with osinfo which should give you the recommended memory size per OS type.
short term for 3.3 your patch is probably better than nothing though:)

>> 
>> Thx,
>> Laszlo
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> 
> 
> makes sense to me.
> looking at the patch - worth handling upgrade as well?
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From lhornyak at redhat.com  Wed May 22 12:39:40 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 22 May 2013 08:39:40 -0400 (EDT)
Subject: [Engine-devel] for a few clicks less
In-Reply-To: <519CB84B.10204@redhat.com>
References: <625194939.4750020.1369225161764.JavaMail.root@redhat.com>
	<519CB84B.10204@redhat.com>
Message-ID: <358035420.4758003.1369226380940.JavaMail.root@redhat.com>

Handling the upgrade is easy but I am not sure users want it.
I will write another patch for upgrade.

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, May 22, 2013 2:21:31 PM
> Subject: Re: [Engine-devel] for a few clicks less
> 
> On 05/22/2013 03:19 PM, Laszlo Hornyak wrote:
> > Hi,
> >
> > Today the default memory size when creating a VM is 512 MB, this is coming
> > from the Blank template, which is not modifiable by user.
> > This amount of memory is not enough for a installation for most Linux
> > distros (and possibly for other mainstream OS either) so I think it would
> > make sense to increase the default memory size to 1024 MB, for most users,
> > it would save some time.
> >
> > This patch changes the memory size for new installations.
> > http://gerrit.ovirt.org/14747
> >
> > Thx,
> > Laszlo
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> makes sense to me.
> looking at the patch - worth handling upgrade as well?
> 


From qw.iampaco at gmail.com  Wed May 22 12:40:17 2013
From: qw.iampaco at gmail.com (Paco qw)
Date: Wed, 22 May 2013 16:40:17 +0400
Subject: [Engine-devel] error install on centos
Message-ID: <CAP5w-i+wcF1rJ3p-pmsyrRUEVDkRc2SjJ4OpJmvU2Scs981aLw@mail.gmail.com>

Hello everyone.
Ovirt install on Centos 6.2
Run engine-setup and get the error.


Installing:
Configuring oVirt Engine...                             [ DONE ]
Configuring JVM...                                      [ DONE ]
Creating CA...                                          [ DONE ]
Updating ovirt-engine service...                        [ DONE ]
Setting Database Configuration...                       [ DONE ]
Setting Database Security...                            [ DONE ]
Creating Database...                                 [ ERROR ]
Database creation failed
Please check log file
/var/log/ovirt-engine/engine-setup_2011_11_24_05_36_26.log for more
information

In log engine-db-install

#engine db installer log file on rhevm8.lab.topsonline.ru
[engine-db-install] verifying required rpms are installed.
postgresql-server-8.4.9-1.el6_1.1.x86_64
postgresql-8.4.9-1.el6_1.1.x86_64
postgresql-libs-8.4.9-1.el6_1.1.x86_64
[engine-db-install] verifying postgres service exists.
[engine-db-install] init postgres db.
[engine-db-install] psgql db already been initialized.
[engine-db-install] changing authentication scheme from peer to ident.
[engine-db-install] changing authentication scheme from ident to trust.
[engine-db-install] stop postgres service.
Stopping postgresql service: [  OK  ]
[engine-db-install] starting postgres service.
Starting postgresql service: [  OK  ]
[engine-db-install] validating that postgres service is running...retry 1
 ?column?
----------
        1
(1 row)

[engine-db-install] checking if engine db exists already..
psql: FATAL:  database "engine" does not exist
[engine-db-install] engine not installed.
[engine-db-install] updating db admin credentials
DROP ROLE
CREATE ROLE
[engine-db-install] creating engine db on postgres.
/usr/share/ovirt-engine/dbscripts ~
/usr/share/ovirt-engine/dbscripts /usr/share/ovirt-engine/dbscripts
Creating the database: engine
dropdb: database removal failed: ERROR:  database "engine" does not exist
user name is: engine
Creating tables...
Creating functions...
Creating common functions...
Inserting data  ...
Inserting pre-defined roles ...
Running upgrade scripts...
upgrade script detected a change in Config, View or Stored Procedure...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script upgrade/pre_upgrade/0000_config.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script upgrade/pre_upgrade/0010_custom.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/pre_upgrade/0020_add_comment_col_to_schema_version.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/pre_upgrade/0030_add_materialized_views_table.sql ...
Dropping materialized views...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script upgrade/03_00_0010_add_group_ids_to_users.sql
...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/03_00_0030_change_storage_format_type_to_str.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/03_00_0040_change_vm_dynamic_vm_ip_type.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/03_00_0050_make_blank_template_pulic.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script upgrade/03_00_0060_add_group_everyone.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script upgrade/03_00_0100_add_device_size_to_luns.sql
...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/03_00_0120_add_update_date_to_vm_templates.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/03_00_0130_change_dwh_history_timekeeping_date_type.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script upgrade/03_00_0150_update_roles.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script upgrade/03_00_0180_add_guest_disk_size.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script upgrade/03_00_0190_add_latency_vm_disks.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/03_00_0220_add_MaxAuditLogMessageLength_to_config.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/03_00_0260_change_app_list_type_to_text.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/03_00_0270_change_users_group_ids_field_to_text.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/03_00_0280_change_blank_template_default_display_type_to_spice.sql
...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script upgrade/03_00_0300_add_local_admin_user.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/03_00_0330_add_configuration_action_group_to_super_user_role.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/03_00_0360_upgrade_default_vds_group_thp.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script
upgrade/03_00_0380_add_otp_validity_to_vds_static.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script upgrade/03_00_0410_add_disks_usage.sql ...
./dbfunctions.sh: line 199: file: command not found
Running  upgrade sql script upgrade/03_00_0420_encrypt_pm_passwd.sh ...
psql:upgrade/03_00_0420_encrypt_pm_passwd.sh:25: ERROR:  syntax error at or
near "#!/"
LINE 1: #!/bin/bash
        ^


What am I doing wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130522/1840ab6d/attachment.html>

From lhornyak at redhat.com  Wed May 22 12:41:54 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 22 May 2013 08:41:54 -0400 (EDT)
Subject: [Engine-devel] for a few clicks less
In-Reply-To: <B95DC182-12B6-4E47-A773-A50570A33F1B@redhat.com>
References: <625194939.4750020.1369225161764.JavaMail.root@redhat.com>
	<519CB84B.10204@redhat.com>
	<B95DC182-12B6-4E47-A773-A50570A33F1B@redhat.com>
Message-ID: <1253171954.4758583.1369226514174.JavaMail.root@redhat.com>

That sounds cool :)
(I usually do not set the OS type, I am too lazy for that)

----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> To: "Roy Golan" <rgolan at redhat.com>, "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, May 22, 2013 2:35:16 PM
> Subject: Re: [Engine-devel] for a few clicks less
> 
> 
> On May 22, 2013, at 14:21 , Itamar Heim <iheim at redhat.com> wrote:
> 
> > On 05/22/2013 03:19 PM, Laszlo Hornyak wrote:
> >> Hi,
> >> 
> >> Today the default memory size when creating a VM is 512 MB, this is coming
> >> from the Blank template, which is not modifiable by user.
> >> This amount of memory is not enough for a installation for most Linux
> >> distros (and possibly for other mainstream OS either) so I think it would
> >> make sense to increase the default memory size to 1024 MB, for most
> >> users, it would save some time.
> >> 
> >> This patch changes the memory size for new installations.
> >> http://gerrit.ovirt.org/14747
> Roy is working on integration with osinfo which should give you the
> recommended memory size per OS type.
> short term for 3.3 your patch is probably better than nothing though:)
> 
> >> 
> >> Thx,
> >> Laszlo
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> 
> > 
> > makes sense to me.
> > looking at the patch - worth handling upgrade as well?
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 


From mpastern at redhat.com  Wed May 22 12:53:47 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 22 May 2013 15:53:47 +0300
Subject: [Engine-devel] about ovirt-shell
In-Reply-To: <000a01ce56b9$e602e150$b208a3f0$@com>
References: <000a01ce56b9$e602e150$b208a3f0$@com>
Message-ID: <519CBFDB.3070107@redhat.com>

On 05/22/2013 09:59 AM, wlbleaboy at 126 wrote:
> Hi all:
> 
>          When I connect to ovirt-engine use ovirt-shell like this: It?s failed, I don?t know why.
> 
> The ovirt-engine is build and deployed by myself and base ovirt-engine 3.2
> 
>  
> 
>          But when I connect to the ovirt-engine use rmp installed, ovirt-shell work well.
> 
>  
> 
>  
> 
> ++++++++++++++++++++++++++++++++++++++++++
> 
>  
> 
>            Welcome to oVirt shell
> 
>  
> 
>  ++++++++++++++++++++++++++++++++++++++++++
> 
>        
> 
>    
> 
> [oVirt shell (disconnected)]# connect --url http://192.168.1.201 --user admin at internal --password 111111
> 
>  
> 
>  
> 
> error: [ERROR]::No response returned from server. If you're using HTTP protocol
> 
> against a SSL secured server, then try using HTTPS instead.

the problem exactly as stated in this error message, e.g you're using http
protocol in your url, while server running over ssl, just do --url https://192.168.1.201

> 
>  
> 
>  
> 
> [oVirt shell (disconnected)]#
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From yzaslavs at redhat.com  Wed May 22 14:13:05 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 22 May 2013 10:13:05 -0400 (EDT)
Subject: [Engine-devel] Any reason to use UUID instead of name or dn?
In-Reply-To: <491682690.3222344.1369219662668.JavaMail.root@redhat.com>
References: <519C9F8C.3090404@redhat.com>
	<491682690.3222344.1369219662668.JavaMail.root@redhat.com>
Message-ID: <1057303287.5742147.1369231985648.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Juan Hernandez" <jhernand at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, May 22, 2013 1:47:42 PM
> Subject: Re: [Engine-devel] Any reason to use UUID instead of name or dn?
> 
> 
> 
> ----- Original Message -----
> > From: "Juan Hernandez" <jhernand at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Wednesday, May 22, 2013 1:35:56 PM
> > Subject: [Engine-devel] Any reason to use UUID instead of name or dn?
> > 
> > Hello all,
> > 
> > I am working on a series of changes with the objective to simplify the
> > LDAP layer and make it more generic. One of the things that I would like
> > to do is to use the name or dn attributes to identify the users/group
> > instead of the UUIDs as we currently do. Can someone explain me if there
> > is any powerful reason to use the directory specific UUIDs (objectGUID
> > in ActiveDirectory, nsUniqueId in RHDS, etc) instead of user/group names
> > or distinguished names?
> 
> Hi,
> 
> If you define an entity and then delete and define an entity at the same
> name, the new entity should not inherit the permissions of the previous
> entity.
> 
> So resource based security always hold unique identifier for entities, it can
> be UUID, UID or any unique string.
> 
> Regards,
> Alon.

Indeed, this is due to permissions issue, the UUIDs are used to calculate the "effective" permissions 

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


From wlbleaboy at 126.com  Thu May 23 01:13:26 2013
From: wlbleaboy at 126.com (wlbleaboy@126)
Date: Thu, 23 May 2013 09:13:26 +0800
Subject: [Engine-devel] =?gb2312?b?tPC4tDogIGFib3V0IHVzZXIgcm9sZXM=?=
In-Reply-To: <519CB8A3.7030800@redhat.com>
References: <001101ce56e0$d7d6e190$8784a4b0$@com> <519CB8A3.7030800@redhat.com>
Message-ID: <001601ce5752$bb298bc0$317ca340$@com>

Thanks very much, it works well.

-----????-----
???: Itamar Heim [mailto:iheim at redhat.com] 
????: 2013?5?22? 20:23
???: wlbleaboy at 126
??: engine-devel at ovirt.org
??: Re: [Engine-devel] about user roles

On 05/22/2013 02:38 PM, wlbleaboy at 126 wrote:
> Hi all:
>
>           I have a question about user role.
>
> Recently, I connect to ovirt-engine by ovirt-engine-sdk, use the
> admin at internal
>
> login is ok, because admin have System Permissions.
>
>           But , when I have a domain named ovirt.test.com, and have a
> user name leaboy
>
> in ovirt.test.com, leaboy at ovirt.test.com <mailto:leaboy at ovirt.test.com>
> can?t to login ovirt-engine. I think maybe leaboy
>
> don?t have permissions to login ovirt-engine. So , I want to know how
> can I do let leaboy
>
> login ovirt-engine, or some exist roles can let leaboy login.
>
>                                                 Thanks.
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

you need to pass the ?filter? HTTP header, with a value of ?true".




From mgoldboi at redhat.com  Thu May 23 10:50:31 2013
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Thu, 23 May 2013 13:50:31 +0300
Subject: [Engine-devel] [3.3 release process] feature freeze readiness
Message-ID: <519DF477.9000300@redhat.com>

we are about a week away from feature freeze of oVirt 3.3 (May 31st). In 
order to be able to converge to this date we would need your help 
(feature owners) understanding feature/overall status.

I have updated  OVirt 3.3 release-management page [1] with features 
status table [2]. having this complete table filled will help us 
determine this version readiness.

a test page addition is needed for each feature (link through the table) 
- this will enable us good visibility and testing of those features in 
test-day.

I have left the old 3.3 feature overview -just below the new table, to 
make sure i have taken all needed from that info. please verify all you 
need is in the table, since this part will be deleted on feature freeze 
readiness review - next Wednesday meeting.

completing filling this table should be done no later than Tuesday May 28th.

Thanks.

[1]http://www.ovirt.org/OVirt_3.3_release-management
[2]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table
[3]http://www.ovirt.org/OVirt_3.3_release-management#Features



From mburns at redhat.com  Thu May 23 11:58:58 2013
From: mburns at redhat.com (Mike Burns)
Date: Thu, 23 May 2013 07:58:58 -0400
Subject: [Engine-devel] [3.3 release process] feature freeze readiness
In-Reply-To: <519DF477.9000300@redhat.com>
References: <519DF477.9000300@redhat.com>
Message-ID: <519E0482.9000803@redhat.com>

On 05/23/2013 06:50 AM, Moran Goldboim wrote:
> we are about a week away from feature freeze of oVirt 3.3 (May 31st). In
> order to be able to converge to this date we would need your help
> (feature owners) understanding feature/overall status.
>
> I have updated  OVirt 3.3 release-management page [1] with features
> status table [2]. having this complete table filled will help us
> determine this version readiness.
>
> a test page addition is needed for each feature (link through the table)
> - this will enable us good visibility and testing of those features in
> test-day.
>
> I have left the old 3.3 feature overview -just below the new table, to
> make sure i have taken all needed from that info. please verify all you
> need is in the table, since this part will be deleted on feature freeze
> readiness review - next Wednesday meeting.
>
> completing filling this table should be done no later than Tuesday May
> 28th.

An example of a testing chart is available on [4]

Mike

[4] http://www.ovirt.org/Features/Node_vdsm_plugin#Testing

>
> Thanks.
>
> [1]http://www.ovirt.org/OVirt_3.3_release-management
> [2]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table
> [3]http://www.ovirt.org/OVirt_3.3_release-management#Features
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch



From sbonazzo at redhat.com  Thu May 23 14:01:58 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 23 May 2013 16:01:58 +0200
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <1128111575.2325743.1368965483403.JavaMail.root@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<190022898.4562887.1367871118558.JavaMail.root@redhat.com>
	<518A4A37.7040506@redhat.com>
	<1674151596.12805405.1368018034731.JavaMail.root@redhat.com>
	<129444276.5410211.1368022851515.JavaMail.root@redhat.com>
	<1259953792.13083016.1368039749490.JavaMail.root@redhat.com>
	<2140554843.5508235.1368040739442.JavaMail.root@redhat.com>
	<5195E64A.3050806@redhat.com>
	<1128111575.2325743.1368965483403.JavaMail.root@redhat.com>
Message-ID: <519E2156.2050103@redhat.com>

Il 19/05/2013 14:11, Alon Bar-Lev ha scritto:
>
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
>> Sent: Friday, May 17, 2013 11:11:54 AM
>> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
>> (https://bugzilla.redhat.com/905754)
>>
>> Il 08/05/2013 21:18, Alon Bar-Lev ha scritto:
>>> Right.
>>> First, we need to support any installation not just rhel.
>>> Second, we can support only other well behaved products.
>>> Until recently we were not well behaved... well we still not fully because
>>> we do not have our own configurable URI namespace.
>>>
>>> We cannot control which applications are installed on the same host,
>>> however we can:
>>>
>>> 1. postgresql: support skipping the automatic provisioning [supported in
>>> the otopi setup]
>>> 2. apache: do not enforce specific apache SSL implementation [to be done].
>>> 3. apache: support skipping the automatic SSL configuration [supported].
>>> 4. apache: support skipping the root redirect to ovirt application
>>> [supported in otopi setup]
>>> 5. apache: move application to own name space, example /ovirt-engine [to be
>>> done, I will be happy if you can help pushing this]
>>> 6. firewall: support skipping configuration [supported]
>>> 7. packaging: remove the versionlock usage.
>>> 8. packaging: support proper upgrade path, compatible with packaging best
>>> practices.
>>> 9. files: rename all utilities and public artifacts from engine-* to
>>> ovirt-engine-*
>>> [more?]
>>>
>>> If we do the above we are acting as well behaved application, and can
>>> co-exist with other well behaved applications.
>>
>> Trying to set the point on this issue in order to start coding.
>>
>> We split the http configuration into three:
>> 1. Install ajp proxy per our URIs[1][2].
>> 2. Optionally set root redirection from / to /ovirt-engine
>> 3. Optionally configure mod_ssl with our certificate.
>>
>> The mandatory apache configuration[1] does not alter any configuration file.
>> [1] http://gerrit.ovirt.org/13318
>> [2] http://gerrit.ovirt.org/14304
>>
>> So there is no reason for checking if user has changed the http
>> configuration for just forcing proxy.
>>
>> About IPA conflicts if I've understood correctly there is only collision
>> between mod_nss used by IPA and mod_ssl used if we enable mod_ssl
>> configuration.
>> It seems there was an issue with mod_proxy and using 2 different SSL
>> certificates (IPA & RHEV) on the same apache server.
>>
>> So, I can force proxy enabled and I can force SSL configuration disabled
>> if IPA is detected.
>> I can leave root redirection optional in any case.
>>
>> otopi implementation already force proxy enabled so there should be just
>> to disable ssl if IPA is detected.
>>
>> During the discussion about this bug it was suggested also to avoid to
>> force dependency on mod_ssl or force migration to mod_nss during upgrade
>> allowing ipa and engine to coexist. I don't think that that issue should
>> be tracked by https://bugzilla.redhat.com/905754 so if there is the will
>> to either drop dependency on mod_ssl or migrate to mod_nss please open a
>> new bug about that.
> Right. I just mentioned that so all will be aware of this abnormality.
>
>> That could solve also another question: what if IPA is installed after
>> ovirt-engine?
>>
>> In order to act as well behaved application, and co-exist with other
>> well behaved applications there is more to do as Alon pointed out.
>> I think that any point not satisfied in order to behave correctly need a
>> bug to be opened.
>>
>> When we'll behave correctly I'll remove any check on IPA presence,
>> totally ignoring it and removing any enforcement about its presence.
>>
>> Am I missing something?
> I don't think so... just am not sure what is the answer in the past for post IPA installation...
>
> Thanks!
> Alon

I think I was missing something.
I don't know if other distro do the same, but on Fedora 18
freeipa-server has a package conflict with mod_ssl.
So it is not possible having both IPA and the oVirt engine on the same host.
This should answer also for post IPA installation for Fedora.

I think the best thing to do here is just warn that we are requiring
mod_ssl when enabling SSL support so any service that has conflicts like
freeipa-server will have issues
and let the administrator decide what to do.


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From alonbl at redhat.com  Thu May 23 14:19:32 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 23 May 2013 10:19:32 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <519E2156.2050103@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1674151596.12805405.1368018034731.JavaMail.root@redhat.com>
	<129444276.5410211.1368022851515.JavaMail.root@redhat.com>
	<1259953792.13083016.1368039749490.JavaMail.root@redhat.com>
	<2140554843.5508235.1368040739442.JavaMail.root@redhat.com>
	<5195E64A.3050806@redhat.com>
	<1128111575.2325743.1368965483403.JavaMail.root@redhat.com>
	<519E2156.2050103@redhat.com>
Message-ID: <238702952.3712776.1369318772146.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
> Sent: Thursday, May 23, 2013 5:01:58 PM
> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)

<snip>

> I think I was missing something.
> I don't know if other distro do the same, but on Fedora 18
> freeipa-server has a package conflict with mod_ssl.
> So it is not possible having both IPA and the oVirt engine on the same host.
> This should answer also for post IPA installation for Fedora.
> 
> I think the best thing to do here is just warn that we are requiring
> mod_ssl when enabling SSL support so any service that has conflicts like
> freeipa-server will have issues
> and let the administrator decide what to do.

We cannot warn... we attempt to configure it... and we do depend on it...
So either it is installed before we run setup or we install it during(?!?!) setup.

Alon


From sbonazzo at redhat.com  Thu May 23 14:26:19 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 23 May 2013 16:26:19 +0200
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <238702952.3712776.1369318772146.JavaMail.root@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1674151596.12805405.1368018034731.JavaMail.root@redhat.com>
	<129444276.5410211.1368022851515.JavaMail.root@redhat.com>
	<1259953792.13083016.1368039749490.JavaMail.root@redhat.com>
	<2140554843.5508235.1368040739442.JavaMail.root@redhat.com>
	<5195E64A.3050806@redhat.com>
	<1128111575.2325743.1368965483403.JavaMail.root@redhat.com>
	<519E2156.2050103@redhat.com>
	<238702952.3712776.1369318772146.JavaMail.root@redhat.com>
Message-ID: <519E270B.10903@redhat.com>

Il 23/05/2013 16:19, Alon Bar-Lev ha scritto:
>
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
>> Sent: Thursday, May 23, 2013 5:01:58 PM
>> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
>> (https://bugzilla.redhat.com/905754)
> <snip>
>
>> I think I was missing something.
>> I don't know if other distro do the same, but on Fedora 18
>> freeipa-server has a package conflict with mod_ssl.
>> So it is not possible having both IPA and the oVirt engine on the same host.
>> This should answer also for post IPA installation for Fedora.
>>
>> I think the best thing to do here is just warn that we are requiring
>> mod_ssl when enabling SSL support so any service that has conflicts like
>> freeipa-server will have issues
>> and let the administrator decide what to do.
> We cannot warn... we attempt to configure it... and we do depend on it...
> So either it is installed before we run setup or we install it during(?!?!) setup.
>
> Alon

So let me try to revert the logic.
Can't we drop the dependency on mod_ssl and warn that if you want SSL
support you've to install mod_ssl allowing the user to abort, install
the module and run engine-setup again?


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From vitor.lima at eldorado.org.br  Thu May 23 14:37:59 2013
From: vitor.lima at eldorado.org.br (Vitor de Lima)
Date: Thu, 23 May 2013 14:37:59 +0000
Subject: [Engine-devel]  Clusters with empty processor name
Message-ID: <B2CAFC4D5E2D574A883EF61ACD5ADE3301000617@SERV070.corp.eldorado.org.br>

Hi everyone,

While I was figuring out how to implement the support for IBM POWER in the oVirt engine, I stumbled into an use case that can cause some confusion.
During the creation of a cluster, you can choose an empty processor name if you do not select the option "Enable Virt Service". As a result, it is possible to create a virtual machine inside a cluster without any attached hosts. So, if you create a VM this way, it is impossible to decide in which architecture it will run (if it is either x86-64 or POWER). Without knowing this, the engine cannot show the proper list of device models (for networks, disks, displays, ...) in the frontend.

It raises some questions:

- Why oVirt allows the creation of clusters without a processor name?
- What exactly is the "Virt Service"? Why are the processor  related checks only executed if this service is enabled?
- How can this use case be solved? Should the engine always enforce a proper CPU name in all clusters?
- If the engine enforces every cluster to have a CPU name, what should be done in the default Cluster?

Thanks,
Vitor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130523/6f436901/attachment.html>

From alourie at redhat.com  Thu May 23 14:53:10 2013
From: alourie at redhat.com (Alex Lourie)
Date: Thu, 23 May 2013 14:56:10 +0003
Subject: [Engine-devel] error install on centos
In-Reply-To: <CAP5w-i+wcF1rJ3p-pmsyrRUEVDkRc2SjJ4OpJmvU2Scs981aLw@mail.gmail.com>
References: <CAP5w-i+wcF1rJ3p-pmsyrRUEVDkRc2SjJ4OpJmvU2Scs981aLw@mail.gmail.com>
Message-ID: <201305231453.r4NErCZ0021163@int-mx02.intmail.prod.int.phx2.redhat.com>

Hi

Can you please attach the setup log (ovirt-engine-setup) and db 
creation log (engine-db-install) from /var/log/ovirt-engine ?

Thanks.

On Wed, May 22, 2013 at 3:40 PM, Paco qw <qw.iampaco at gmail.com> wrote:
> Hello everyone.
> Ovirt install on Centos 6.2
> Run engine-setup and get the error.
> 
> 
> Installing:
> Configuring oVirt 
> Engine...???????????????????????????? [ 
> DONE ]
> Configuring 
> JVM...????????????????????????????????????? 
> [ DONE ]
> Creating 
> CA...????????????????????????????????????????? 
> [ DONE ]
> Updating ovirt-engine 
> service...??????????????????????? [ DONE ]
> Setting Database 
> Configuration...?????????????????????? [ DONE ]
> Setting Database 
> Security...??????????????????????????? [ 
> DONE ]
> Creating 
> Database...???????????????????????????????? 
> [ ERROR ]
> Database creation failed
> Please check log file 
> /var/log/ovirt-engine/engine-setup_2011_11_24_05_36_26.log for more 
> information
> 
> In log engine-db-install
> 
> #engine db installer log file on rhevm8.lab.topsonline.ru
> [engine-db-install] verifying required rpms are installed.
> postgresql-server-8.4.9-1.el6_1.1.x86_64
> postgresql-8.4.9-1.el6_1.1.x86_64
> postgresql-libs-8.4.9-1.el6_1.1.x86_64
> [engine-db-install] verifying postgres service exists.
> [engine-db-install] init postgres db.
> [engine-db-install] psgql db already been initialized.
> [engine-db-install] changing authentication scheme from peer to ident.
> [engine-db-install] changing authentication scheme from ident to 
> trust.
> [engine-db-install] stop postgres service.
> Stopping postgresql service: [? OK? ]
> [engine-db-install] starting postgres service.
> Starting postgresql service: [? OK? ]
> [engine-db-install] validating that postgres service is 
> running...retry 1
> ??column?
> ----------
> ??????? 1
> (1 row)
> 
> [engine-db-install] checking if engine db exists already..
> psql: FATAL:? database "engine" does not exist
> [engine-db-install] engine not installed.
> [engine-db-install] updating db admin credentials
> DROP ROLE
> CREATE ROLE
> [engine-db-install] creating engine db on postgres.
> /usr/share/ovirt-engine/dbscripts ~
> /usr/share/ovirt-engine/dbscripts /usr/share/ovirt-engine/dbscripts
> Creating the database: engine
> dropdb: database removal failed: ERROR:? database "engine" does not 
> exist
> user name is: engine
> Creating tables...
> Creating functions...
> Creating common functions...
> Inserting data? ...
> Inserting pre-defined roles ...
> Running upgrade scripts...
> upgrade script detected a change in Config, View or Stored 
> Procedure...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script upgrade/pre_upgrade/0000_config.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script upgrade/pre_upgrade/0010_custom.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/pre_upgrade/0020_add_comment_col_to_schema_version.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/pre_upgrade/0030_add_materialized_views_table.sql ...
> Dropping materialized views...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0010_add_group_ids_to_users.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0030_change_storage_format_type_to_str.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0040_change_vm_dynamic_vm_ip_type.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0050_make_blank_template_pulic.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0060_add_group_everyone.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0100_add_device_size_to_luns.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0120_add_update_date_to_vm_templates.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0130_change_dwh_history_timekeeping_date_type.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script upgrade/03_00_0150_update_roles.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0180_add_guest_disk_size.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0190_add_latency_vm_disks.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0220_add_MaxAuditLogMessageLength_to_config.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0260_change_app_list_type_to_text.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0270_change_users_group_ids_field_to_text.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0280_change_blank_template_default_display_type_to_spice.sql 
> ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0300_add_local_admin_user.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0330_add_configuration_action_group_to_super_user_role.sql 
> ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0360_upgrade_default_vds_group_thp.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script 
> upgrade/03_00_0380_add_otp_validity_to_vds_static.sql ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script upgrade/03_00_0410_add_disks_usage.sql 
> ...
> ./dbfunctions.sh: line 199: file: command not found
> Running? upgrade sql script upgrade/03_00_0420_encrypt_pm_passwd.sh 
> ...
> psql:upgrade/03_00_0420_encrypt_pm_passwd.sh:25: ERROR:? syntax 
> error at or near "#!/"
> LINE 1: #!/bin/bash
> ??????? ^
> 
> 
> What am I doing wrong?



From alonbl at redhat.com  Thu May 23 15:07:31 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 23 May 2013 11:07:31 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <519E270B.10903@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1259953792.13083016.1368039749490.JavaMail.root@redhat.com>
	<2140554843.5508235.1368040739442.JavaMail.root@redhat.com>
	<5195E64A.3050806@redhat.com>
	<1128111575.2325743.1368965483403.JavaMail.root@redhat.com>
	<519E2156.2050103@redhat.com>
	<238702952.3712776.1369318772146.JavaMail.root@redhat.com>
	<519E270B.10903@redhat.com>
Message-ID: <559558905.3760220.1369321651987.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
> Sent: Thursday, May 23, 2013 5:26:19 PM
> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)
> 
> Il 23/05/2013 16:19, Alon Bar-Lev ha scritto:
> >
> > ----- Original Message -----
> >> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
> >> Sent: Thursday, May 23, 2013 5:01:58 PM
> >> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> >> Apache	proxy
> >> (https://bugzilla.redhat.com/905754)
> > <snip>
> >
> >> I think I was missing something.
> >> I don't know if other distro do the same, but on Fedora 18
> >> freeipa-server has a package conflict with mod_ssl.
> >> So it is not possible having both IPA and the oVirt engine on the same
> >> host.
> >> This should answer also for post IPA installation for Fedora.
> >>
> >> I think the best thing to do here is just warn that we are requiring
> >> mod_ssl when enabling SSL support so any service that has conflicts like
> >> freeipa-server will have issues
> >> and let the administrator decide what to do.
> > We cannot warn... we attempt to configure it... and we do depend on it...
> > So either it is installed before we run setup or we install it during(?!?!)
> > setup.
> >
> > Alon
> 
> So let me try to revert the logic.
> Can't we drop the dependency on mod_ssl and warn that if you want SSL
> support you've to install mod_ssl allowing the user to abort, install
> the module and run engine-setup again?

Right... this is just for 3.3...

This matches the logic of multiple execution of setup to add new components :)

Not sure this will be acceptable by those who like 'simple-on-click' installation.

Regards.
Alon


From alonbl at redhat.com  Thu May 23 15:08:17 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 23 May 2013 11:08:17 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <559558905.3760220.1369321651987.JavaMail.root@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<2140554843.5508235.1368040739442.JavaMail.root@redhat.com>
	<5195E64A.3050806@redhat.com>
	<1128111575.2325743.1368965483403.JavaMail.root@redhat.com>
	<519E2156.2050103@redhat.com>
	<238702952.3712776.1369318772146.JavaMail.root@redhat.com>
	<519E270B.10903@redhat.com>
	<559558905.3760220.1369321651987.JavaMail.root@redhat.com>
Message-ID: <749082029.3760515.1369321697355.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>,
> "Simon Grinberg" <simon at redhat.com>
> Sent: Thursday, May 23, 2013 6:07:31 PM
> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)
> 
> 
> 
> ----- Original Message -----
> > From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
> > Sent: Thursday, May 23, 2013 5:26:19 PM
> > Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> > Apache	proxy
> > (https://bugzilla.redhat.com/905754)
> > 
> > Il 23/05/2013 16:19, Alon Bar-Lev ha scritto:
> > >
> > > ----- Original Message -----
> > >> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel"
> > >> <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
> > >> Sent: Thursday, May 23, 2013 5:01:58 PM
> > >> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must
> > >> use
> > >> Apache	proxy
> > >> (https://bugzilla.redhat.com/905754)
> > > <snip>
> > >
> > >> I think I was missing something.
> > >> I don't know if other distro do the same, but on Fedora 18
> > >> freeipa-server has a package conflict with mod_ssl.
> > >> So it is not possible having both IPA and the oVirt engine on the same
> > >> host.
> > >> This should answer also for post IPA installation for Fedora.
> > >>
> > >> I think the best thing to do here is just warn that we are requiring
> > >> mod_ssl when enabling SSL support so any service that has conflicts like
> > >> freeipa-server will have issues
> > >> and let the administrator decide what to do.
> > > We cannot warn... we attempt to configure it... and we do depend on it...
> > > So either it is installed before we run setup or we install it
> > > during(?!?!)
> > > setup.
> > >
> > > Alon
> > 
> > So let me try to revert the logic.
> > Can't we drop the dependency on mod_ssl and warn that if you want SSL
> > support you've to install mod_ssl allowing the user to abort, install
> > the module and run engine-setup again?
> 
> Right... this is just for 3.3...
> 
> This matches the logic of multiple execution of setup to add new components
> :)
> 
> Not sure this will be acceptable by those who like 'simple-on-click'
> installation.
> 
> Regards.
> Alon

Oh... sorry, we cannot work without SSL... it is not just a matter of support.

We have to have valid SSL configuration or product will not work.

Alon


From sbonazzo at redhat.com  Thu May 23 15:11:01 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 23 May 2013 17:11:01 +0200
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <749082029.3760515.1369321697355.JavaMail.root@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<2140554843.5508235.1368040739442.JavaMail.root@redhat.com>
	<5195E64A.3050806@redhat.com>
	<1128111575.2325743.1368965483403.JavaMail.root@redhat.com>
	<519E2156.2050103@redhat.com>
	<238702952.3712776.1369318772146.JavaMail.root@redhat.com>
	<519E270B.10903@redhat.com>
	<559558905.3760220.1369321651987.JavaMail.root@redhat.com>
	<749082029.3760515.1369321697355.JavaMail.root@redhat.com>
Message-ID: <519E3185.8020805@redhat.com>

Il 23/05/2013 17:08, Alon Bar-Lev ha scritto:
>
> ----- Original Message -----
>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>,
>> "Simon Grinberg" <simon at redhat.com>
>> Sent: Thursday, May 23, 2013 6:07:31 PM
>> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
>> (https://bugzilla.redhat.com/905754)
>>
>>
>>
>> ----- Original Message -----
>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel"
>>> <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
>>> Sent: Thursday, May 23, 2013 5:26:19 PM
>>> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
>>> Apache	proxy
>>> (https://bugzilla.redhat.com/905754)
>>>
>>> Il 23/05/2013 16:19, Alon Bar-Lev ha scritto:
>>>> ----- Original Message -----
>>>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel"
>>>>> <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
>>>>> Sent: Thursday, May 23, 2013 5:01:58 PM
>>>>> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must
>>>>> use
>>>>> Apache	proxy
>>>>> (https://bugzilla.redhat.com/905754)
>>>> <snip>
>>>>
>>>>> I think I was missing something.
>>>>> I don't know if other distro do the same, but on Fedora 18
>>>>> freeipa-server has a package conflict with mod_ssl.
>>>>> So it is not possible having both IPA and the oVirt engine on the same
>>>>> host.
>>>>> This should answer also for post IPA installation for Fedora.
>>>>>
>>>>> I think the best thing to do here is just warn that we are requiring
>>>>> mod_ssl when enabling SSL support so any service that has conflicts like
>>>>> freeipa-server will have issues
>>>>> and let the administrator decide what to do.
>>>> We cannot warn... we attempt to configure it... and we do depend on it...
>>>> So either it is installed before we run setup or we install it
>>>> during(?!?!)
>>>> setup.
>>>>
>>>> Alon
>>> So let me try to revert the logic.
>>> Can't we drop the dependency on mod_ssl and warn that if you want SSL
>>> support you've to install mod_ssl allowing the user to abort, install
>>> the module and run engine-setup again?
>> Right... this is just for 3.3...
>>
>> This matches the logic of multiple execution of setup to add new components
>> :)
>>
>> Not sure this will be acceptable by those who like 'simple-on-click'
>> installation.
>>
>> Regards.
>> Alon
> Oh... sorry, we cannot work without SSL... it is not just a matter of support.
>
> We have to have valid SSL configuration or product will not work.
>
> Alon

We need the configuration in place also if we don't use mod_ssl?

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



From alonbl at redhat.com  Thu May 23 15:18:39 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 23 May 2013 11:18:39 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <519E3185.8020805@redhat.com>
References: <5187CCF8.9080600@redhat.com>
	<1128111575.2325743.1368965483403.JavaMail.root@redhat.com>
	<519E2156.2050103@redhat.com>
	<238702952.3712776.1369318772146.JavaMail.root@redhat.com>
	<519E270B.10903@redhat.com>
	<559558905.3760220.1369321651987.JavaMail.root@redhat.com>
	<749082029.3760515.1369321697355.JavaMail.root@redhat.com>
	<519E3185.8020805@redhat.com>
Message-ID: <1773526943.3764380.1369322319247.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>,
> "Simon Grinberg" <simon at redhat.com>
> Sent: Thursday, May 23, 2013 6:11:01 PM
> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)
> 
> Il 23/05/2013 17:08, Alon Bar-Lev ha scritto:
> >
> > ----- Original Message -----
> >> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> >> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>,
> >> "Simon Grinberg" <simon at redhat.com>
> >> Sent: Thursday, May 23, 2013 6:07:31 PM
> >> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> >> Apache	proxy
> >> (https://bugzilla.redhat.com/905754)
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> >>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel"
> >>> <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
> >>> Sent: Thursday, May 23, 2013 5:26:19 PM
> >>> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use
> >>> Apache	proxy
> >>> (https://bugzilla.redhat.com/905754)
> >>>
> >>> Il 23/05/2013 16:19, Alon Bar-Lev ha scritto:
> >>>> ----- Original Message -----
> >>>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> >>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel"
> >>>>> <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
> >>>>> Sent: Thursday, May 23, 2013 5:01:58 PM
> >>>>> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must
> >>>>> use
> >>>>> Apache	proxy
> >>>>> (https://bugzilla.redhat.com/905754)
> >>>> <snip>
> >>>>
> >>>>> I think I was missing something.
> >>>>> I don't know if other distro do the same, but on Fedora 18
> >>>>> freeipa-server has a package conflict with mod_ssl.
> >>>>> So it is not possible having both IPA and the oVirt engine on the same
> >>>>> host.
> >>>>> This should answer also for post IPA installation for Fedora.
> >>>>>
> >>>>> I think the best thing to do here is just warn that we are requiring
> >>>>> mod_ssl when enabling SSL support so any service that has conflicts
> >>>>> like
> >>>>> freeipa-server will have issues
> >>>>> and let the administrator decide what to do.
> >>>> We cannot warn... we attempt to configure it... and we do depend on
> >>>> it...
> >>>> So either it is installed before we run setup or we install it
> >>>> during(?!?!)
> >>>> setup.
> >>>>
> >>>> Alon
> >>> So let me try to revert the logic.
> >>> Can't we drop the dependency on mod_ssl and warn that if you want SSL
> >>> support you've to install mod_ssl allowing the user to abort, install
> >>> the module and run engine-setup again?
> >> Right... this is just for 3.3...
> >>
> >> This matches the logic of multiple execution of setup to add new
> >> components
> >> :)
> >>
> >> Not sure this will be acceptable by those who like 'simple-on-click'
> >> installation.
> >>
> >> Regards.
> >> Alon
> > Oh... sorry, we cannot work without SSL... it is not just a matter of
> > support.
> >
> > We have to have valid SSL configuration or product will not work.
> >
> > Alon
> 
> We need the configuration in place also if we don't use mod_ssl?

We need active SSL configuration, as the application automatically redirect users to https.

Alon


From wlbleaboy at 126.com  Fri May 24 07:42:41 2013
From: wlbleaboy at 126.com (wlbleaboy@126)
Date: Fri, 24 May 2013 15:42:41 +0800
Subject: [Engine-devel] which RESTful framework ovirt-engine used
Message-ID: <002001ce5852$46938a80$d3ba9f80$@com>

Hi all:

         Recently , I'm studying ovirt-engine' REST API, I want to know
which framework of RESTful

ovirt-engine used. 

         For example, if I wanted to build a web server with RESTful API
like ovirt-engine, which framework

or technology I need.

         When I search "RESTful" as a keyword in some opensource website, I
get results like this:

SemREST          --  A Java Framework for the Semantic Extension of RESTful
Web Services

JAX-RS              --       

Kauri

Jersey

RESTEasy

 

and so on.

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

From jhernand at redhat.com  Fri May 24 08:16:02 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Fri, 24 May 2013 10:16:02 +0200
Subject: [Engine-devel] which RESTful framework ovirt-engine used
In-Reply-To: <002001ce5852$46938a80$d3ba9f80$@com>
References: <002001ce5852$46938a80$d3ba9f80$@com>
Message-ID: <519F21C2.8090305@redhat.com>

On 05/24/2013 09:42 AM, wlbleaboy at 126 wrote:
> Hi all:
>
>           Recently , I?m studying ovirt-engine? REST API, I want to know
> which framework of RESTful
>
> ovirt-engine used.
>
>           For example, if I wanted to build a web server with RESTful
> API like ovirt-engine, which framework
>
> or technology I need.
>
>           When I search ?RESTful? as a keyword in some opensource
> website, I get results like this:
>
> *SemREST *--* A Java Framework for the Semantic Extension of RESTful Web
> Services*
>
> *JAX-RS              -- *
>
> *Kauri*
>
> *Jersey*
>
> *RESTEasy*
>
> **
>
> and so on?
>

The engine uses JAX-RS, which is the Java standard for REST, and the 
implementation of that standard that we use is RESTEasy, as it is 
already included inside JBoss AS.

-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From iheim at redhat.com  Fri May 24 12:15:44 2013
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 24 May 2013 15:15:44 +0300
Subject: [Engine-devel] Clusters with empty processor name
In-Reply-To: <B2CAFC4D5E2D574A883EF61ACD5ADE3301000617@SERV070.corp.eldorado.org.br>
References: <B2CAFC4D5E2D574A883EF61ACD5ADE3301000617@SERV070.corp.eldorado.org.br>
Message-ID: <519F59F0.80106@redhat.com>

On 05/23/2013 05:37 PM, Vitor de Lima wrote:
> Hi everyone,
>
> While I was figuring out how to implement the support for IBM POWER in
> the oVirt engine, I stumbled into an use case that can cause some confusion.
>
> During the creation of a cluster, you can choose an empty processor name
> if you do not select the option "Enable Virt Service". As a result, it
> is possible to create a virtual machine inside a cluster without any
> attached hosts. So, if you create a VM this way, it is impossible to
> decide in which architecture it will run (if it is either x86-64 or
> POWER). Without knowing this, the engine cannot show the proper list of
> device models (for networks, disks, displays, ...) in the frontend.
>
> It raises some questions:
>
> - Why oVirt allows the creation of clusters without a processor name?

so the first host added to the cluster will determine the cluster cpu level.

>
> - What exactly is the "Virt Service"? Why are the processor  related
> checks only executed if this service is enabled?

virt service means you want to run VMs on that cluster, and not just use 
it to host gluster based storage on that cluster.

>
> - How can this use case be solved? Should the engine always enforce a
> proper CPU name in all clusters?

are you sure use case is relevant - you can't use the cluster before 
adding a host to it?
in any case, i think the 'arch' parameter would be a must.
arch would determine the list of cpu families allowed, etc.

>
> - If the engine enforces every cluster to have a CPU name, what should
> be done in the default Cluster?
>
> Thanks,
>
> Vitor
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From masayag at redhat.com  Sun May 26 08:35:40 2013
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 26 May 2013 11:35:40 +0300
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <928424823.3820639.1367555024185.JavaMail.root@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<1066256837.5335037.1367554237087.JavaMail.root@redhat.com>
	<928424823.3820639.1367555024185.JavaMail.root@redhat.com>
Message-ID: <51A1C95C.90506@redhat.com>

On 05/03/2013 07:23 AM, Alon Bar-Lev wrote:
> 
> Hi,
> 
> Thanks... no I did not follow.
> 
> If -P setup is required then the Makefile should have been changed, else our production and rpms are broken now! Well... looking at the pom.xml, it looks like the jboss standalone is configured with -P setup is used, which is yet another hack introduced to developers... As they do not run our service, and suffer from lack of proper environment and configuration settings.
> 
> My work[1] is exactly to address this one, to eliminate the need for hacking the product and use our production startup sequence and installation. At ./packaging/services/ovirt-engine.xml.in we already have the infinispan settings.
> 
> So still need your help.
> Thanks,
> Alon

I've just started facing the same issue.
Also noticed this in the server.log:

JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.mbean.server (missing) dependents: [service
jboss.infinispan.ovirt-engine.config]

It seems that the generate ovirt-engine.xml under [1] replaces the
infinispan:1.1 version as noted on [2] with infinispan:1.2.

Is there any version analysing logic which replaces the template for
what seems to be a static part?

[1] var/tmp/ovirt-engine/config/ovirt-engine.xml
[2] share/ovirt-engine/services/ovirt-engine.xml.in

> 
> [1] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer
> 
> ----- Original Message -----
>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Friday, May 3, 2013 7:10:37 AM
>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
>>
>> Hi Alon,
>> I might check this later on today.
>> Did you follow Kublin's email about introducing infinispan? he sent it to
>> engine-devel (you're supposed during the build to perform -P setup)
>>
>> Yair
>>
>>
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>> To: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Thursday, May 2, 2013 11:11:03 PM
>>> Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
>>>
>>> Hello,
>>>
>>> I get these (lots of these) using latest master... anyone knows what was
>>> changed?
>>>
>>> At server.log I see:
>>> ---
>>> 2013-05-02 19:58:08,046 INFO  [org.jboss.as.clustering.infinispan]
>>> (ServerService Thread Pool -- 21) JBAS010280: Activating Infinispan
>>> subsystem.
>>> <snip>
>>> 2013-05-02 19:58:10,155 INFO  [org.jboss.as.controller] (Controller Boot
>>> Thread) JBAS014774: Service status report
>>> JBAS014775:    New missing/unsatisfied dependencies:
>>>       service jboss.mbean.server (missing) dependents: [service
>>>       jboss.infinispan.ovirt-engine.config]
>>>
>>> ---
>>>
>>> Thanks,
>>> Alon
>>>
>>> ---
>>>
>>> 2013-05-02 20:02:10,012 ERROR
>>> [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy]
>>> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Failed to lookup resource
>>> type:
>>> CACHE_CONTAINER. JNDI name: java:jboss/infinispan/ovirt-engine:
>>> javax.naming.NameNotFoundException: Error looking up
>>> infinispan/ovirt-engine, service service
>>> jboss.naming.context.java.jboss.infinispan.ovirt-engine is not started
>>>         at
>>>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
>>>         at
>>>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
>>>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
>>>         at
>>>         org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
>>>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
>>>         at javax.naming.InitialContext.lookup(InitialContext.java:411)
>>>         [rt.jar:1.7.0_17]
>>>         at
>>>         org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104)
>>>         [utils.jar:]
>>>         at
>>>         org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23)
>>>         [utils.jar:]
>>>         at
>>>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:12)
>>>         [utils.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
>>>         [bll.jar:]
>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>         [rt.jar:1.7.0_17]
>>>
>>> 2013-05-02 20:02:10,059 ERROR
>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase]
>>> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Error during log command:
>>> org.ovirt.engine.core.bll.SetNonOperationalVdsCommand. Exception
>>> java.lang.NullPointerException: java.lang.NullPointerException
>>>         at
>>>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:13)
>>>         [utils.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
>>>         [bll.jar:]
>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>         [rt.jar:1.7.0_17]
>>>
>>> 2013-05-02 20:02:10,360 ERROR
>>> [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy]
>>> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Failed to lookup resource
>>> type:
>>> CACHE_CONTAINER. JNDI name: java:jboss/infinispan/ovirt-engine:
>>> javax.naming.NameNotFoundException: Error looking up
>>> infinispan/ovirt-engine, service service
>>> jboss.naming.context.java.jboss.infinispan.ovirt-engine is not started
>>>         at
>>>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
>>>         at
>>>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
>>>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
>>>         at
>>>         org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
>>>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
>>>         at javax.naming.InitialContext.lookup(InitialContext.java:411)
>>>         [rt.jar:1.7.0_17]
>>>         at
>>>         org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104)
>>>         [utils.jar:]
>>>         at
>>>         org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23)
>>>         [utils.jar:]
>>>         at
>>>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:12)
>>>         [utils.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
>>>         [bll.jar:]
>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>         [rt.jar:1.7.0_17]
>>>
>>>
>>> 2013-05-02 20:02:10,407 ERROR
>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase]
>>> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Error during log command:
>>> org.ovirt.engine.core.bll.SetNonOperationalVdsCommand. Exception
>>> java.lang.NullPointerException: java.lang.NullPointerException
>>>         at
>>>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:13)
>>>         [utils.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
>>>         [dal.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
>>>         [bll.jar:]
>>>         at
>>>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
>>>         [bll.jar:]
>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>         [rt.jar:1.7.0_17]
>>> _______________________________________________
>>> 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 alonbl at redhat.com  Sun May 26 08:52:08 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 26 May 2013 04:52:08 -0400 (EDT)
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <51A1C95C.90506@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<1066256837.5335037.1367554237087.JavaMail.root@redhat.com>
	<928424823.3820639.1367555024185.JavaMail.root@redhat.com>
	<51A1C95C.90506@redhat.com>
Message-ID: <992076494.4291170.1369558328689.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, May 26, 2013 11:35:40 AM
> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> 
> On 05/03/2013 07:23 AM, Alon Bar-Lev wrote:
> > 
> > Hi,
> > 
> > Thanks... no I did not follow.
> > 
> > If -P setup is required then the Makefile should have been changed, else
> > our production and rpms are broken now! Well... looking at the pom.xml, it
> > looks like the jboss standalone is configured with -P setup is used, which
> > is yet another hack introduced to developers... As they do not run our
> > service, and suffer from lack of proper environment and configuration
> > settings.
> > 
> > My work[1] is exactly to address this one, to eliminate the need for
> > hacking the product and use our production startup sequence and
> > installation. At ./packaging/services/ovirt-engine.xml.in we already have
> > the infinispan settings.
> > 
> > So still need your help.
> > Thanks,
> > Alon
> 
> I've just started facing the same issue.
> Also noticed this in the server.log:
> 
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.mbean.server (missing) dependents: [service
> jboss.infinispan.ovirt-engine.config]
> 
> It seems that the generate ovirt-engine.xml under [1] replaces the
> infinispan:1.1 version as noted on [2] with infinispan:1.2.

I really don't understand the above statement? who/which component have 1.2?

> Is there any version analysing logic which replaces the template for
> what seems to be a static part?

It is not static[3], it generated based on configuration.

If it works with 1.2 then whoever introduced this new dependency should have taken care the production part of the product.

BTW: also the old hack of jboss backend/manager/conf/standalone.xml uses 1.1...
 
> [1] var/tmp/ovirt-engine/config/ovirt-engine.xml
> [2] share/ovirt-engine/services/ovirt-engine.xml.in

[3] packaging/services/ovirt-engine.xml.in
 
> > 
> > [1] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer
> > 
> > ----- Original Message -----
> >> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Friday, May 3, 2013 7:10:37 AM
> >> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>
> >> Hi Alon,
> >> I might check this later on today.
> >> Did you follow Kublin's email about introducing infinispan? he sent it to
> >> engine-devel (you're supposed during the build to perform -P setup)
> >>
> >> Yair
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >>> To: "engine-devel" <engine-devel at ovirt.org>
> >>> Sent: Thursday, May 2, 2013 11:11:03 PM
> >>> Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>>
> >>> Hello,
> >>>
> >>> I get these (lots of these) using latest master... anyone knows what was
> >>> changed?
> >>>
> >>> At server.log I see:
> >>> ---
> >>> 2013-05-02 19:58:08,046 INFO  [org.jboss.as.clustering.infinispan]
> >>> (ServerService Thread Pool -- 21) JBAS010280: Activating Infinispan
> >>> subsystem.
> >>> <snip>
> >>> 2013-05-02 19:58:10,155 INFO  [org.jboss.as.controller] (Controller Boot
> >>> Thread) JBAS014774: Service status report
> >>> JBAS014775:    New missing/unsatisfied dependencies:
> >>>       service jboss.mbean.server (missing) dependents: [service
> >>>       jboss.infinispan.ovirt-engine.config]
> >>>
> >>> ---
> >>>
> >>> Thanks,
> >>> Alon
> >>>
> >>> ---
> >>>
> >>> 2013-05-02 20:02:10,012 ERROR
> >>> [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy]
> >>> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Failed to lookup resource
> >>> type:
> >>> CACHE_CONTAINER. JNDI name: java:jboss/infinispan/ovirt-engine:
> >>> javax.naming.NameNotFoundException: Error looking up
> >>> infinispan/ovirt-engine, service service
> >>> jboss.naming.context.java.jboss.infinispan.ovirt-engine is not started
> >>>         at
> >>>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
> >>>         at
> >>>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
> >>>         at
> >>>         org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
> >>>         at
> >>>         org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
> >>>         at
> >>>         org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
> >>>         at javax.naming.InitialContext.lookup(InitialContext.java:411)
> >>>         [rt.jar:1.7.0_17]
> >>>         at
> >>>         org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104)
> >>>         [utils.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23)
> >>>         [utils.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:12)
> >>>         [utils.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
> >>>         [bll.jar:]
> >>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>         [rt.jar:1.7.0_17]
> >>>
> >>> 2013-05-02 20:02:10,059 ERROR
> >>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase]
> >>> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Error during log command:
> >>> org.ovirt.engine.core.bll.SetNonOperationalVdsCommand. Exception
> >>> java.lang.NullPointerException: java.lang.NullPointerException
> >>>         at
> >>>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:13)
> >>>         [utils.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
> >>>         [bll.jar:]
> >>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>         [rt.jar:1.7.0_17]
> >>>
> >>> 2013-05-02 20:02:10,360 ERROR
> >>> [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy]
> >>> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Failed to lookup resource
> >>> type:
> >>> CACHE_CONTAINER. JNDI name: java:jboss/infinispan/ovirt-engine:
> >>> javax.naming.NameNotFoundException: Error looking up
> >>> infinispan/ovirt-engine, service service
> >>> jboss.naming.context.java.jboss.infinispan.ovirt-engine is not started
> >>>         at
> >>>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
> >>>         at
> >>>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
> >>>         at
> >>>         org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
> >>>         at
> >>>         org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
> >>>         at
> >>>         org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
> >>>         at javax.naming.InitialContext.lookup(InitialContext.java:411)
> >>>         [rt.jar:1.7.0_17]
> >>>         at
> >>>         org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104)
> >>>         [utils.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23)
> >>>         [utils.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:12)
> >>>         [utils.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
> >>>         [bll.jar:]
> >>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>         [rt.jar:1.7.0_17]
> >>>
> >>>
> >>> 2013-05-02 20:02:10,407 ERROR
> >>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase]
> >>> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Error during log command:
> >>> org.ovirt.engine.core.bll.SetNonOperationalVdsCommand. Exception
> >>> java.lang.NullPointerException: java.lang.NullPointerException
> >>>         at
> >>>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:13)
> >>>         [utils.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
> >>>         [dal.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
> >>>         [bll.jar:]
> >>>         at
> >>>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
> >>>         [bll.jar:]
> >>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>>         [rt.jar:1.7.0_17]
> >>> _______________________________________________
> >>> 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  Sun May 26 09:19:14 2013
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 26 May 2013 12:19:14 +0300
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <992076494.4291170.1369558328689.JavaMail.root@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<1066256837.5335037.1367554237087.JavaMail.root@redhat.com>
	<928424823.3820639.1367555024185.JavaMail.root@redhat.com>
	<51A1C95C.90506@redhat.com>
	<992076494.4291170.1369558328689.JavaMail.root@redhat.com>
Message-ID: <51A1D392.5070606@redhat.com>

On 05/26/2013 11:52 AM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Moti Asayag" <masayag at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, May 26, 2013 11:35:40 AM
>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
>>
>> On 05/03/2013 07:23 AM, Alon Bar-Lev wrote:
>>>
>>> Hi,
>>>
>>> Thanks... no I did not follow.
>>>
>>> If -P setup is required then the Makefile should have been changed, else
>>> our production and rpms are broken now! Well... looking at the pom.xml, it
>>> looks like the jboss standalone is configured with -P setup is used, which
>>> is yet another hack introduced to developers... As they do not run our
>>> service, and suffer from lack of proper environment and configuration
>>> settings.
>>>
>>> My work[1] is exactly to address this one, to eliminate the need for
>>> hacking the product and use our production startup sequence and
>>> installation. At ./packaging/services/ovirt-engine.xml.in we already have
>>> the infinispan settings.
>>>
>>> So still need your help.
>>> Thanks,
>>> Alon
>>
>> I've just started facing the same issue.
>> Also noticed this in the server.log:
>>
>> JBAS014775:    New missing/unsatisfied dependencies:
>>       service jboss.mbean.server (missing) dependents: [service
>> jboss.infinispan.ovirt-engine.config]
>>
>> It seems that the generate ovirt-engine.xml under [1] replaces the
>> infinispan:1.1 version as noted on [2] with infinispan:1.2.
> 
> I really don't understand the above statement? who/which component have 1.2?
> 

the template ovirt-engine.xml.in contains:

<subsystem xmlns="urn:jboss:domain:infinispan:** 1.1 **"
default-cache-container="ovirt-engine">

vs

the generated var/tmp/ovirt-engine/config/ovirt-engine.xml which contains:

<subsystem xmlns="urn:jboss:domain:infinispan:** 1.2 **"
default-cache-container="ovirt-engine">

So it used to work with 1.1 (as defined in the template), but the
generated ovirt-engine.xml replaces the version to 1.2 which cause it
not to work.

So my question is how the engine-service.py decides to generate the
ovirt-engine.xml with "1.2" version, while the template has "1.1" for
infinispan subsystem element ?

>> Is there any version analysing logic which replaces the template for
>> what seems to be a static part?
> 
> It is not static[3], it generated based on configuration.
> 
> If it works with 1.2 then whoever introduced this new dependency should have taken care the production part of the product.
> 
> BTW: also the old hack of jboss backend/manager/conf/standalone.xml uses 1.1...
>  
>> [1] var/tmp/ovirt-engine/config/ovirt-engine.xml
>> [2] share/ovirt-engine/services/ovirt-engine.xml.in
> 
> [3] packaging/services/ovirt-engine.xml.in
>  
>>>
>>> [1] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer
>>>
>>> ----- Original Message -----
>>>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Friday, May 3, 2013 7:10:37 AM
>>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
>>>>
>>>> Hi Alon,
>>>> I might check this later on today.
>>>> Did you follow Kublin's email about introducing infinispan? he sent it to
>>>> engine-devel (you're supposed during the build to perform -P setup)
>>>>
>>>> Yair
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>> Sent: Thursday, May 2, 2013 11:11:03 PM
>>>>> Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
>>>>>
>>>>> Hello,
>>>>>
>>>>> I get these (lots of these) using latest master... anyone knows what was
>>>>> changed?
>>>>>
>>>>> At server.log I see:
>>>>> ---
>>>>> 2013-05-02 19:58:08,046 INFO  [org.jboss.as.clustering.infinispan]
>>>>> (ServerService Thread Pool -- 21) JBAS010280: Activating Infinispan
>>>>> subsystem.
>>>>> <snip>
>>>>> 2013-05-02 19:58:10,155 INFO  [org.jboss.as.controller] (Controller Boot
>>>>> Thread) JBAS014774: Service status report
>>>>> JBAS014775:    New missing/unsatisfied dependencies:
>>>>>       service jboss.mbean.server (missing) dependents: [service
>>>>>       jboss.infinispan.ovirt-engine.config]
>>>>>
>>>>> ---
>>>>>
>>>>> Thanks,
>>>>> Alon
>>>>>
>>>>> ---
>>>>>
>>>>> 2013-05-02 20:02:10,012 ERROR
>>>>> [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy]
>>>>> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Failed to lookup resource
>>>>> type:
>>>>> CACHE_CONTAINER. JNDI name: java:jboss/infinispan/ovirt-engine:
>>>>> javax.naming.NameNotFoundException: Error looking up
>>>>> infinispan/ovirt-engine, service service
>>>>> jboss.naming.context.java.jboss.infinispan.ovirt-engine is not started
>>>>>         at
>>>>>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
>>>>>         at
>>>>>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
>>>>>         at
>>>>>         org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
>>>>>         at
>>>>>         org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
>>>>>         at
>>>>>         org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
>>>>>         at javax.naming.InitialContext.lookup(InitialContext.java:411)
>>>>>         [rt.jar:1.7.0_17]
>>>>>         at
>>>>>         org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104)
>>>>>         [utils.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23)
>>>>>         [utils.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:12)
>>>>>         [utils.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
>>>>>         [bll.jar:]
>>>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>         [rt.jar:1.7.0_17]
>>>>>
>>>>> 2013-05-02 20:02:10,059 ERROR
>>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase]
>>>>> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Error during log command:
>>>>> org.ovirt.engine.core.bll.SetNonOperationalVdsCommand. Exception
>>>>> java.lang.NullPointerException: java.lang.NullPointerException
>>>>>         at
>>>>>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:13)
>>>>>         [utils.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
>>>>>         [bll.jar:]
>>>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>         [rt.jar:1.7.0_17]
>>>>>
>>>>> 2013-05-02 20:02:10,360 ERROR
>>>>> [org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy]
>>>>> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Failed to lookup resource
>>>>> type:
>>>>> CACHE_CONTAINER. JNDI name: java:jboss/infinispan/ovirt-engine:
>>>>> javax.naming.NameNotFoundException: Error looking up
>>>>> infinispan/ovirt-engine, service service
>>>>> jboss.naming.context.java.jboss.infinispan.ovirt-engine is not started
>>>>>         at
>>>>>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:126)
>>>>>         at
>>>>>         org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:74)
>>>>>         at
>>>>>         org.jboss.as.naming.NamingContext.lookup(NamingContext.java:178)
>>>>>         at
>>>>>         org.jboss.as.naming.InitialContext.lookup(InitialContext.java:123)
>>>>>         at
>>>>>         org.jboss.as.naming.NamingContext.lookup(NamingContext.java:214)
>>>>>         at javax.naming.InitialContext.lookup(InitialContext.java:411)
>>>>>         [rt.jar:1.7.0_17]
>>>>>         at
>>>>>         org.ovirt.engine.core.utils.ejb.EJBUtilsStrategy.findBean(EJBUtilsStrategy.java:104)
>>>>>         [utils.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.utils.ejb.EjbUtils.findBean(EjbUtils.java:23)
>>>>>         [utils.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:12)
>>>>>         [utils.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
>>>>>         [bll.jar:]
>>>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>         [rt.jar:1.7.0_17]
>>>>>
>>>>>
>>>>> 2013-05-02 20:02:10,407 ERROR
>>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase]
>>>>> (DefaultQuartzScheduler_Worker-7) [4b3a50f7] Error during log command:
>>>>> org.ovirt.engine.core.bll.SetNonOperationalVdsCommand. Exception
>>>>> java.lang.NullPointerException: java.lang.NullPointerException
>>>>>         at
>>>>>         org.ovirt.engine.core.utils.cache.CacheManager.getTimeoutBaseCache(CacheManager.java:13)
>>>>>         [utils.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBase.getLegal(TimeoutBase.java:51)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:809)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:803)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector.log(AuditLogDirector.java:799)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase.log(AuditLogableBase.java:437)
>>>>>         [dal.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.CommandBase.logCommand(CommandBase.java:1208)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1175)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:318)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:332)
>>>>>         [bll.jar:]
>>>>>         at
>>>>>         org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:534)
>>>>>         [bll.jar:]
>>>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>         [rt.jar:1.7.0_17]
>>>>> _______________________________________________
>>>>> 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 alonbl at redhat.com  Sun May 26 10:09:34 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 26 May 2013 06:09:34 -0400 (EDT)
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <51A1D392.5070606@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<1066256837.5335037.1367554237087.JavaMail.root@redhat.com>
	<928424823.3820639.1367555024185.JavaMail.root@redhat.com>
	<51A1C95C.90506@redhat.com>
	<992076494.4291170.1369558328689.JavaMail.root@redhat.com>
	<51A1D392.5070606@redhat.com>
Message-ID: <567306121.4292798.1369562974514.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, May 26, 2013 12:19:14 PM
> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> 
> On 05/26/2013 11:52 AM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Moti Asayag" <masayag at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>
> >> Sent: Sunday, May 26, 2013 11:35:40 AM
> >> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>
> >> On 05/03/2013 07:23 AM, Alon Bar-Lev wrote:
> >>>
> >>> Hi,
> >>>
> >>> Thanks... no I did not follow.
> >>>
> >>> If -P setup is required then the Makefile should have been changed, else
> >>> our production and rpms are broken now! Well... looking at the pom.xml,
> >>> it
> >>> looks like the jboss standalone is configured with -P setup is used,
> >>> which
> >>> is yet another hack introduced to developers... As they do not run our
> >>> service, and suffer from lack of proper environment and configuration
> >>> settings.
> >>>
> >>> My work[1] is exactly to address this one, to eliminate the need for
> >>> hacking the product and use our production startup sequence and
> >>> installation. At ./packaging/services/ovirt-engine.xml.in we already have
> >>> the infinispan settings.
> >>>
> >>> So still need your help.
> >>> Thanks,
> >>> Alon
> >>
> >> I've just started facing the same issue.
> >> Also noticed this in the server.log:
> >>
> >> JBAS014775:    New missing/unsatisfied dependencies:
> >>       service jboss.mbean.server (missing) dependents: [service
> >> jboss.infinispan.ovirt-engine.config]
> >>
> >> It seems that the generate ovirt-engine.xml under [1] replaces the
> >> infinispan:1.1 version as noted on [2] with infinispan:1.2.
> > 
> > I really don't understand the above statement? who/which component have
> > 1.2?
> > 
> 
> the template ovirt-engine.xml.in contains:
> 
> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.1 **"
> default-cache-container="ovirt-engine">
> 
> vs
> 
> the generated var/tmp/ovirt-engine/config/ovirt-engine.xml which contains:
> 
> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.2 **"
> default-cache-container="ovirt-engine">
> 
> So it used to work with 1.1 (as defined in the template), but the
> generated ovirt-engine.xml replaces the version to 1.2 which cause it
> not to work.
> 
> So my question is how the engine-service.py decides to generate the
> ovirt-engine.xml with "1.2" version, while the template has "1.1" for
> infinispan subsystem element ?

Hmmmm!!!!! Good catch! I have never thought that it is possible.

The template is generated ok with 1.1, after startup jboss re-write its own configuration and change this to 1.2!!!!

Juan, is that normal jboss behavior? Editing its own configuration file?

Regards,
Alon Bar-Lev


From shtripat at redhat.com  Mon May 27 07:09:58 2013
From: shtripat at redhat.com (Shubhendu Tripathi)
Date: Mon, 27 May 2013 12:39:58 +0530
Subject: [Engine-devel] Regarding access to ovirt.org for creating feature
	pages
Message-ID: <51A306C6.6010100@redhat.com>

Hi All,

I have joined RedHat this month and work with RHSC team.
I need to create a feature page on Ovirt WIKI, and so raised a request 
for the same to get an id created.

I have not received any confirmation till now.
Kindly let me know if something is missing or I need to follow some 
other process.

ID Created: shtripat
Email Id: shtripat at redhat.com

Thanks and Regards,
Shubhendu Tripathi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shtripat.vcf
Type: text/x-vcard
Size: 138 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130527/81a48be8/attachment.vcf>

From jhernand at redhat.com  Mon May 27 07:58:43 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 27 May 2013 09:58:43 +0200
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <567306121.4292798.1369562974514.JavaMail.root@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<1066256837.5335037.1367554237087.JavaMail.root@redhat.com>
	<928424823.3820639.1367555024185.JavaMail.root@redhat.com>
	<51A1C95C.90506@redhat.com>
	<992076494.4291170.1369558328689.JavaMail.root@redhat.com>
	<51A1D392.5070606@redhat.com>
	<567306121.4292798.1369562974514.JavaMail.root@redhat.com>
Message-ID: <51A31233.4070303@redhat.com>

On 05/26/2013 12:09 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Moti Asayag" <masayag at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, May 26, 2013 12:19:14 PM
>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
>>
>> On 05/26/2013 11:52 AM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
>>>> <engine-devel at ovirt.org>
>>>> Sent: Sunday, May 26, 2013 11:35:40 AM
>>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
>>>>
>>>> On 05/03/2013 07:23 AM, Alon Bar-Lev wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks... no I did not follow.
>>>>>
>>>>> If -P setup is required then the Makefile should have been changed, else
>>>>> our production and rpms are broken now! Well... looking at the pom.xml,
>>>>> it
>>>>> looks like the jboss standalone is configured with -P setup is used,
>>>>> which
>>>>> is yet another hack introduced to developers... As they do not run our
>>>>> service, and suffer from lack of proper environment and configuration
>>>>> settings.
>>>>>
>>>>> My work[1] is exactly to address this one, to eliminate the need for
>>>>> hacking the product and use our production startup sequence and
>>>>> installation. At ./packaging/services/ovirt-engine.xml.in we already have
>>>>> the infinispan settings.
>>>>>
>>>>> So still need your help.
>>>>> Thanks,
>>>>> Alon
>>>>
>>>> I've just started facing the same issue.
>>>> Also noticed this in the server.log:
>>>>
>>>> JBAS014775:    New missing/unsatisfied dependencies:
>>>>        service jboss.mbean.server (missing) dependents: [service
>>>> jboss.infinispan.ovirt-engine.config]
>>>>
>>>> It seems that the generate ovirt-engine.xml under [1] replaces the
>>>> infinispan:1.1 version as noted on [2] with infinispan:1.2.
>>>
>>> I really don't understand the above statement? who/which component have
>>> 1.2?
>>>
>>
>> the template ovirt-engine.xml.in contains:
>>
>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.1 **"
>> default-cache-container="ovirt-engine">
>>
>> vs
>>
>> the generated var/tmp/ovirt-engine/config/ovirt-engine.xml which contains:
>>
>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.2 **"
>> default-cache-container="ovirt-engine">
>>
>> So it used to work with 1.1 (as defined in the template), but the
>> generated ovirt-engine.xml replaces the version to 1.2 which cause it
>> not to work.
>>
>> So my question is how the engine-service.py decides to generate the
>> ovirt-engine.xml with "1.2" version, while the template has "1.1" for
>> infinispan subsystem element ?
>
> Hmmmm!!!!! Good catch! I have never thought that it is possible.
>
> The template is generated ok with 1.1, after startup jboss re-write its own configuration and change this to 1.2!!!!
>
> Juan, is that normal jboss behavior? Editing its own configuration file?
>

Yes, it is normal.

> Regards,
> Alon Bar-Lev
>


-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From alonbl at redhat.com  Mon May 27 08:01:25 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 27 May 2013 04:01:25 -0400 (EDT)
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <51A31233.4070303@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<1066256837.5335037.1367554237087.JavaMail.root@redhat.com>
	<928424823.3820639.1367555024185.JavaMail.root@redhat.com>
	<51A1C95C.90506@redhat.com>
	<992076494.4291170.1369558328689.JavaMail.root@redhat.com>
	<51A1D392.5070606@redhat.com>
	<567306121.4292798.1369562974514.JavaMail.root@redhat.com>
	<51A31233.4070303@redhat.com>
Message-ID: <627861666.4402347.1369641685702.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Monday, May 27, 2013 10:58:43 AM
> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> 
> On 05/26/2013 12:09 PM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Moti Asayag" <masayag at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>
> >> Sent: Sunday, May 26, 2013 12:19:14 PM
> >> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>
> >> On 05/26/2013 11:52 AM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> >>>> <engine-devel at ovirt.org>
> >>>> Sent: Sunday, May 26, 2013 11:35:40 AM
> >>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>>>
> >>>> On 05/03/2013 07:23 AM, Alon Bar-Lev wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Thanks... no I did not follow.
> >>>>>
> >>>>> If -P setup is required then the Makefile should have been changed,
> >>>>> else
> >>>>> our production and rpms are broken now! Well... looking at the pom.xml,
> >>>>> it
> >>>>> looks like the jboss standalone is configured with -P setup is used,
> >>>>> which
> >>>>> is yet another hack introduced to developers... As they do not run our
> >>>>> service, and suffer from lack of proper environment and configuration
> >>>>> settings.
> >>>>>
> >>>>> My work[1] is exactly to address this one, to eliminate the need for
> >>>>> hacking the product and use our production startup sequence and
> >>>>> installation. At ./packaging/services/ovirt-engine.xml.in we already
> >>>>> have
> >>>>> the infinispan settings.
> >>>>>
> >>>>> So still need your help.
> >>>>> Thanks,
> >>>>> Alon
> >>>>
> >>>> I've just started facing the same issue.
> >>>> Also noticed this in the server.log:
> >>>>
> >>>> JBAS014775:    New missing/unsatisfied dependencies:
> >>>>        service jboss.mbean.server (missing) dependents: [service
> >>>> jboss.infinispan.ovirt-engine.config]
> >>>>
> >>>> It seems that the generate ovirt-engine.xml under [1] replaces the
> >>>> infinispan:1.1 version as noted on [2] with infinispan:1.2.
> >>>
> >>> I really don't understand the above statement? who/which component have
> >>> 1.2?
> >>>
> >>
> >> the template ovirt-engine.xml.in contains:
> >>
> >> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.1 **"
> >> default-cache-container="ovirt-engine">
> >>
> >> vs
> >>
> >> the generated var/tmp/ovirt-engine/config/ovirt-engine.xml which contains:
> >>
> >> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.2 **"
> >> default-cache-container="ovirt-engine">
> >>
> >> So it used to work with 1.1 (as defined in the template), but the
> >> generated ovirt-engine.xml replaces the version to 1.2 which cause it
> >> not to work.
> >>
> >> So my question is how the engine-service.py decides to generate the
> >> ovirt-engine.xml with "1.2" version, while the template has "1.1" for
> >> infinispan subsystem element ?
> >
> > Hmmmm!!!!! Good catch! I have never thought that it is possible.
> >
> > The template is generated ok with 1.1, after startup jboss re-write its own
> > configuration and change this to 1.2!!!!
> >
> > Juan, is that normal jboss behavior? Editing its own configuration file?
> >
> 
> Yes, it is normal.

Hi,

What do you suggest to do if application requires specific component version and jboss enforce a different version?

If I understand correctly two versions of jboss can enforce a different version of components.

Thanks,
Alon


From sgrinber at redhat.com  Mon May 27 08:10:20 2013
From: sgrinber at redhat.com (Simon Grinberg)
Date: Mon, 27 May 2013 04:10:20 -0400 (EDT)
Subject: [Engine-devel] 3.3 scratch or upgraded installation must use
 Apache	proxy (https://bugzilla.redhat.com/905754)
In-Reply-To: <1773526943.3764380.1369322319247.JavaMail.root@redhat.com>
References: <5187CCF8.9080600@redhat.com> <519E2156.2050103@redhat.com>
	<238702952.3712776.1369318772146.JavaMail.root@redhat.com>
	<519E270B.10903@redhat.com>
	<559558905.3760220.1369321651987.JavaMail.root@redhat.com>
	<749082029.3760515.1369321697355.JavaMail.root@redhat.com>
	<519E3185.8020805@redhat.com>
	<1773526943.3764380.1369322319247.JavaMail.root@redhat.com>
Message-ID: <15578445.527.1369642118716.JavaMail.javamailuser@localhost>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Simon Grinberg" <simon at redhat.com>
> Sent: Thursday, May 23, 2013 6:18:39 PM
> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation must use Apache	proxy
> (https://bugzilla.redhat.com/905754)
> 
> 
> 
> ----- Original Message -----
> > From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>,
> > "Simon Grinberg" <simon at redhat.com>
> > Sent: Thursday, May 23, 2013 6:11:01 PM
> > Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation
> > must use Apache	proxy
> > (https://bugzilla.redhat.com/905754)
> > 
> > Il 23/05/2013 17:08, Alon Bar-Lev ha scritto:
> > >
> > > ----- Original Message -----
> > >> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > >> To: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > >> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel"
> > >> <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>,
> > >> "Simon Grinberg" <simon at redhat.com>
> > >> Sent: Thursday, May 23, 2013 6:07:31 PM
> > >> Subject: Re: [Engine-devel] 3.3 scratch or upgraded installation
> > >> must use
> > >> Apache	proxy
> > >> (https://bugzilla.redhat.com/905754)
> > >>
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > >>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >>> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel"
> > >>> <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
> > >>> Sent: Thursday, May 23, 2013 5:26:19 PM
> > >>> Subject: Re: [Engine-devel] 3.3 scratch or upgraded
> > >>> installation must use
> > >>> Apache	proxy
> > >>> (https://bugzilla.redhat.com/905754)
> > >>>
> > >>> Il 23/05/2013 16:19, Alon Bar-Lev ha scritto:
> > >>>> ----- Original Message -----
> > >>>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > >>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >>>>> Cc: "Barak Azulay" <bazulay at redhat.com>, "engine-devel"
> > >>>>> <engine-devel at ovirt.org>, "Alex Lourie" <alourie at redhat.com>
> > >>>>> Sent: Thursday, May 23, 2013 5:01:58 PM
> > >>>>> Subject: Re: [Engine-devel] 3.3 scratch or upgraded
> > >>>>> installation must
> > >>>>> use
> > >>>>> Apache	proxy
> > >>>>> (https://bugzilla.redhat.com/905754)
> > >>>> <snip>
> > >>>>
> > >>>>> I think I was missing something.
> > >>>>> I don't know if other distro do the same, but on Fedora 18
> > >>>>> freeipa-server has a package conflict with mod_ssl.
> > >>>>> So it is not possible having both IPA and the oVirt engine on
> > >>>>> the same
> > >>>>> host.
> > >>>>> This should answer also for post IPA installation for Fedora.

That should not be a problem.
Don't forget that one of the popular use cases for virtualization is to resolve conflict in services while still using the same amount of hardware. Instead of investing a huge effort to resolve conflicts you segregate services into virtual machines that in turn can share the same physical server. 


> > >>>>>
> > >>>>> I think the best thing to do here is just warn that we are
> > >>>>> requiring
> > >>>>> mod_ssl when enabling SSL support so any service that has
> > >>>>> conflicts
> > >>>>> like
> > >>>>> freeipa-server will have issues
> > >>>>> and let the administrator decide what to do.
> > >>>> We cannot warn... we attempt to configure it... and we do
> > >>>> depend on
> > >>>> it...
> > >>>> So either it is installed before we run setup or we install it
> > >>>> during(?!?!)
> > >>>> setup.
> > >>>>
> > >>>> Alon
> > >>> So let me try to revert the logic.
> > >>> Can't we drop the dependency on mod_ssl and warn that if you
> > >>> want SSL
> > >>> support you've to install mod_ssl allowing the user to abort,
> > >>> install
> > >>> the module and run engine-setup again?
> > >> Right... this is just for 3.3...
> > >>
> > >> This matches the logic of multiple execution of setup to add new
> > >> components
> > >> :)
> > >>
> > >> Not sure this will be acceptable by those who like
> > >> 'simple-on-click'
> > >> installation.

No it won't - but it's a moot point by now 


> > >>
> > >> Regards.
> > >> Alon
> > > Oh... sorry, we cannot work without SSL... it is not just a
> > > matter of
> > > support.
> > >
> > > We have to have valid SSL configuration or product will not work.
> > >
> > > Alon
> > 
> > We need the configuration in place also if we don't use mod_ssl?
> 
> We need active SSL configuration, as the application automatically
> redirect users to https.
> 
> Alon
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From jhernand at redhat.com  Mon May 27 08:13:15 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 27 May 2013 10:13:15 +0200
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <627861666.4402347.1369641685702.JavaMail.root@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<1066256837.5335037.1367554237087.JavaMail.root@redhat.com>
	<928424823.3820639.1367555024185.JavaMail.root@redhat.com>
	<51A1C95C.90506@redhat.com>
	<992076494.4291170.1369558328689.JavaMail.root@redhat.com>
	<51A1D392.5070606@redhat.com>
	<567306121.4292798.1369562974514.JavaMail.root@redhat.com>
	<51A31233.4070303@redhat.com>
	<627861666.4402347.1369641685702.JavaMail.root@redhat.com>
Message-ID: <51A3159B.5010808@redhat.com>

On 05/27/2013 10:01 AM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
>> <engine-devel at ovirt.org>
>> Sent: Monday, May 27, 2013 10:58:43 AM
>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
>>
>> On 05/26/2013 12:09 PM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
>>>> <engine-devel at ovirt.org>
>>>> Sent: Sunday, May 26, 2013 12:19:14 PM
>>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
>>>>
>>>> On 05/26/2013 11:52 AM, Alon Bar-Lev wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
>>>>>> <engine-devel at ovirt.org>
>>>>>> Sent: Sunday, May 26, 2013 11:35:40 AM
>>>>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
>>>>>>
>>>>>> On 05/03/2013 07:23 AM, Alon Bar-Lev wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Thanks... no I did not follow.
>>>>>>>
>>>>>>> If -P setup is required then the Makefile should have been changed,
>>>>>>> else
>>>>>>> our production and rpms are broken now! Well... looking at the pom.xml,
>>>>>>> it
>>>>>>> looks like the jboss standalone is configured with -P setup is used,
>>>>>>> which
>>>>>>> is yet another hack introduced to developers... As they do not run our
>>>>>>> service, and suffer from lack of proper environment and configuration
>>>>>>> settings.
>>>>>>>
>>>>>>> My work[1] is exactly to address this one, to eliminate the need for
>>>>>>> hacking the product and use our production startup sequence and
>>>>>>> installation. At ./packaging/services/ovirt-engine.xml.in we already
>>>>>>> have
>>>>>>> the infinispan settings.
>>>>>>>
>>>>>>> So still need your help.
>>>>>>> Thanks,
>>>>>>> Alon
>>>>>>
>>>>>> I've just started facing the same issue.
>>>>>> Also noticed this in the server.log:
>>>>>>
>>>>>> JBAS014775:    New missing/unsatisfied dependencies:
>>>>>>         service jboss.mbean.server (missing) dependents: [service
>>>>>> jboss.infinispan.ovirt-engine.config]
>>>>>>
>>>>>> It seems that the generate ovirt-engine.xml under [1] replaces the
>>>>>> infinispan:1.1 version as noted on [2] with infinispan:1.2.
>>>>>
>>>>> I really don't understand the above statement? who/which component have
>>>>> 1.2?
>>>>>
>>>>
>>>> the template ovirt-engine.xml.in contains:
>>>>
>>>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.1 **"
>>>> default-cache-container="ovirt-engine">
>>>>
>>>> vs
>>>>
>>>> the generated var/tmp/ovirt-engine/config/ovirt-engine.xml which contains:
>>>>
>>>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.2 **"
>>>> default-cache-container="ovirt-engine">
>>>>
>>>> So it used to work with 1.1 (as defined in the template), but the
>>>> generated ovirt-engine.xml replaces the version to 1.2 which cause it
>>>> not to work.
>>>>
>>>> So my question is how the engine-service.py decides to generate the
>>>> ovirt-engine.xml with "1.2" version, while the template has "1.1" for
>>>> infinispan subsystem element ?
>>>
>>> Hmmmm!!!!! Good catch! I have never thought that it is possible.
>>>
>>> The template is generated ok with 1.1, after startup jboss re-write its own
>>> configuration and change this to 1.2!!!!
>>>
>>> Juan, is that normal jboss behavior? Editing its own configuration file?
>>>
>>
>> Yes, it is normal.
>
> Hi,
>
> What do you suggest to do if application requires specific component version and jboss enforce a different version?
>

Change the application to use the version enforced by JBoss.

> If I understand correctly two versions of jboss can enforce a different version of components.
>
> Thanks,
> Alon
>


-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From alonbl at redhat.com  Mon May 27 08:19:44 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 27 May 2013 04:19:44 -0400 (EDT)
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <51A3159B.5010808@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<51A1C95C.90506@redhat.com>
	<992076494.4291170.1369558328689.JavaMail.root@redhat.com>
	<51A1D392.5070606@redhat.com>
	<567306121.4292798.1369562974514.JavaMail.root@redhat.com>
	<51A31233.4070303@redhat.com>
	<627861666.4402347.1369641685702.JavaMail.root@redhat.com>
	<51A3159B.5010808@redhat.com>
Message-ID: <1851240905.4406945.1369642784780.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Monday, May 27, 2013 11:13:15 AM
> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> 
> On 05/27/2013 10:01 AM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Juan Hernandez" <jhernand at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky"
> >> <yzaslavs at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>
> >> Sent: Monday, May 27, 2013 10:58:43 AM
> >> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>
> >> On 05/26/2013 12:09 PM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> >>>> <engine-devel at ovirt.org>
> >>>> Sent: Sunday, May 26, 2013 12:19:14 PM
> >>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>>>
> >>>> On 05/26/2013 11:52 AM, Alon Bar-Lev wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> >>>>>> <engine-devel at ovirt.org>
> >>>>>> Sent: Sunday, May 26, 2013 11:35:40 AM
> >>>>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>>>>>
> >>>>>> On 05/03/2013 07:23 AM, Alon Bar-Lev wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Thanks... no I did not follow.
> >>>>>>>
> >>>>>>> If -P setup is required then the Makefile should have been changed,
> >>>>>>> else
> >>>>>>> our production and rpms are broken now! Well... looking at the
> >>>>>>> pom.xml,
> >>>>>>> it
> >>>>>>> looks like the jboss standalone is configured with -P setup is used,
> >>>>>>> which
> >>>>>>> is yet another hack introduced to developers... As they do not run
> >>>>>>> our
> >>>>>>> service, and suffer from lack of proper environment and configuration
> >>>>>>> settings.
> >>>>>>>
> >>>>>>> My work[1] is exactly to address this one, to eliminate the need for
> >>>>>>> hacking the product and use our production startup sequence and
> >>>>>>> installation. At ./packaging/services/ovirt-engine.xml.in we already
> >>>>>>> have
> >>>>>>> the infinispan settings.
> >>>>>>>
> >>>>>>> So still need your help.
> >>>>>>> Thanks,
> >>>>>>> Alon
> >>>>>>
> >>>>>> I've just started facing the same issue.
> >>>>>> Also noticed this in the server.log:
> >>>>>>
> >>>>>> JBAS014775:    New missing/unsatisfied dependencies:
> >>>>>>         service jboss.mbean.server (missing) dependents: [service
> >>>>>> jboss.infinispan.ovirt-engine.config]
> >>>>>>
> >>>>>> It seems that the generate ovirt-engine.xml under [1] replaces the
> >>>>>> infinispan:1.1 version as noted on [2] with infinispan:1.2.
> >>>>>
> >>>>> I really don't understand the above statement? who/which component have
> >>>>> 1.2?
> >>>>>
> >>>>
> >>>> the template ovirt-engine.xml.in contains:
> >>>>
> >>>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.1 **"
> >>>> default-cache-container="ovirt-engine">
> >>>>
> >>>> vs
> >>>>
> >>>> the generated var/tmp/ovirt-engine/config/ovirt-engine.xml which
> >>>> contains:
> >>>>
> >>>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.2 **"
> >>>> default-cache-container="ovirt-engine">
> >>>>
> >>>> So it used to work with 1.1 (as defined in the template), but the
> >>>> generated ovirt-engine.xml replaces the version to 1.2 which cause it
> >>>> not to work.
> >>>>
> >>>> So my question is how the engine-service.py decides to generate the
> >>>> ovirt-engine.xml with "1.2" version, while the template has "1.1" for
> >>>> infinispan subsystem element ?
> >>>
> >>> Hmmmm!!!!! Good catch! I have never thought that it is possible.
> >>>
> >>> The template is generated ok with 1.1, after startup jboss re-write its
> >>> own
> >>> configuration and change this to 1.2!!!!
> >>>
> >>> Juan, is that normal jboss behavior? Editing its own configuration file?
> >>>
> >>
> >> Yes, it is normal.
> >
> > Hi,
> >
> > What do you suggest to do if application requires specific component
> > version and jboss enforce a different version?
> >
> 
> Change the application to use the version enforced by JBoss.

> 
> > If I understand correctly two versions of jboss can enforce a different
> > version of components.

So I ask again ^^^^.

If application should run under two versions of jboss which enforce two versions of a component, how can application cope?

> >
> > Thanks,
> > Alon
> >
> 
> 
> --
> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3?D, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.
> 


From jhernand at redhat.com  Mon May 27 08:20:56 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 27 May 2013 10:20:56 +0200
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <1851240905.4406945.1369642784780.JavaMail.root@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<51A1C95C.90506@redhat.com>
	<992076494.4291170.1369558328689.JavaMail.root@redhat.com>
	<51A1D392.5070606@redhat.com>
	<567306121.4292798.1369562974514.JavaMail.root@redhat.com>
	<51A31233.4070303@redhat.com>
	<627861666.4402347.1369641685702.JavaMail.root@redhat.com>
	<51A3159B.5010808@redhat.com>
	<1851240905.4406945.1369642784780.JavaMail.root@redhat.com>
Message-ID: <51A31768.30303@redhat.com>

On 05/27/2013 10:19 AM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
>> <engine-devel at ovirt.org>
>> Sent: Monday, May 27, 2013 11:13:15 AM
>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
>>
>> On 05/27/2013 10:01 AM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky"
>>>> <yzaslavs at redhat.com>, "engine-devel"
>>>> <engine-devel at ovirt.org>
>>>> Sent: Monday, May 27, 2013 10:58:43 AM
>>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
>>>>
>>>> On 05/26/2013 12:09 PM, Alon Bar-Lev wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
>>>>>> <engine-devel at ovirt.org>
>>>>>> Sent: Sunday, May 26, 2013 12:19:14 PM
>>>>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
>>>>>>
>>>>>> On 05/26/2013 11:52 AM, Alon Bar-Lev wrote:
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Moti Asayag" <masayag at redhat.com>
>>>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
>>>>>>>> <engine-devel at ovirt.org>
>>>>>>>> Sent: Sunday, May 26, 2013 11:35:40 AM
>>>>>>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
>>>>>>>>
>>>>>>>> On 05/03/2013 07:23 AM, Alon Bar-Lev wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Thanks... no I did not follow.
>>>>>>>>>
>>>>>>>>> If -P setup is required then the Makefile should have been changed,
>>>>>>>>> else
>>>>>>>>> our production and rpms are broken now! Well... looking at the
>>>>>>>>> pom.xml,
>>>>>>>>> it
>>>>>>>>> looks like the jboss standalone is configured with -P setup is used,
>>>>>>>>> which
>>>>>>>>> is yet another hack introduced to developers... As they do not run
>>>>>>>>> our
>>>>>>>>> service, and suffer from lack of proper environment and configuration
>>>>>>>>> settings.
>>>>>>>>>
>>>>>>>>> My work[1] is exactly to address this one, to eliminate the need for
>>>>>>>>> hacking the product and use our production startup sequence and
>>>>>>>>> installation. At ./packaging/services/ovirt-engine.xml.in we already
>>>>>>>>> have
>>>>>>>>> the infinispan settings.
>>>>>>>>>
>>>>>>>>> So still need your help.
>>>>>>>>> Thanks,
>>>>>>>>> Alon
>>>>>>>>
>>>>>>>> I've just started facing the same issue.
>>>>>>>> Also noticed this in the server.log:
>>>>>>>>
>>>>>>>> JBAS014775:    New missing/unsatisfied dependencies:
>>>>>>>>          service jboss.mbean.server (missing) dependents: [service
>>>>>>>> jboss.infinispan.ovirt-engine.config]
>>>>>>>>
>>>>>>>> It seems that the generate ovirt-engine.xml under [1] replaces the
>>>>>>>> infinispan:1.1 version as noted on [2] with infinispan:1.2.
>>>>>>>
>>>>>>> I really don't understand the above statement? who/which component have
>>>>>>> 1.2?
>>>>>>>
>>>>>>
>>>>>> the template ovirt-engine.xml.in contains:
>>>>>>
>>>>>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.1 **"
>>>>>> default-cache-container="ovirt-engine">
>>>>>>
>>>>>> vs
>>>>>>
>>>>>> the generated var/tmp/ovirt-engine/config/ovirt-engine.xml which
>>>>>> contains:
>>>>>>
>>>>>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.2 **"
>>>>>> default-cache-container="ovirt-engine">
>>>>>>
>>>>>> So it used to work with 1.1 (as defined in the template), but the
>>>>>> generated ovirt-engine.xml replaces the version to 1.2 which cause it
>>>>>> not to work.
>>>>>>
>>>>>> So my question is how the engine-service.py decides to generate the
>>>>>> ovirt-engine.xml with "1.2" version, while the template has "1.1" for
>>>>>> infinispan subsystem element ?
>>>>>
>>>>> Hmmmm!!!!! Good catch! I have never thought that it is possible.
>>>>>
>>>>> The template is generated ok with 1.1, after startup jboss re-write its
>>>>> own
>>>>> configuration and change this to 1.2!!!!
>>>>>
>>>>> Juan, is that normal jboss behavior? Editing its own configuration file?
>>>>>
>>>>
>>>> Yes, it is normal.
>>>
>>> Hi,
>>>
>>> What do you suggest to do if application requires specific component
>>> version and jboss enforce a different version?
>>>
>>
>> Change the application to use the version enforced by JBoss.
>
>>
>>> If I understand correctly two versions of jboss can enforce a different
>>> version of components.
>
> So I ask again ^^^^.
>
> If application should run under two versions of jboss which enforce two versions of a component, how can application cope?
>

I don't know.

>>>
>>> Thanks,
>>> Alon
>>>
>>
>>
>> --
>> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
>> 3?D, 28016 Madrid, Spain
>> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.
>>


-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From yzaslavs at redhat.com  Mon May 27 08:25:56 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 27 May 2013 04:25:56 -0400 (EDT)
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <51A3159B.5010808@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<51A1C95C.90506@redhat.com>
	<992076494.4291170.1369558328689.JavaMail.root@redhat.com>
	<51A1D392.5070606@redhat.com>
	<567306121.4292798.1369562974514.JavaMail.root@redhat.com>
	<51A31233.4070303@redhat.com>
	<627861666.4402347.1369641685702.JavaMail.root@redhat.com>
	<51A3159B.5010808@redhat.com>
Message-ID: <1681326236.8054493.1369643156526.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Monday, May 27, 2013 11:13:15 AM
> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> 
> On 05/27/2013 10:01 AM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Juan Hernandez" <jhernand at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky"
> >> <yzaslavs at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>
> >> Sent: Monday, May 27, 2013 10:58:43 AM
> >> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>
> >> On 05/26/2013 12:09 PM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> >>>> <engine-devel at ovirt.org>
> >>>> Sent: Sunday, May 26, 2013 12:19:14 PM
> >>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>>>
> >>>> On 05/26/2013 11:52 AM, Alon Bar-Lev wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> >>>>>> <engine-devel at ovirt.org>
> >>>>>> Sent: Sunday, May 26, 2013 11:35:40 AM
> >>>>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>>>>>
> >>>>>> On 05/03/2013 07:23 AM, Alon Bar-Lev wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Thanks... no I did not follow.
> >>>>>>>
> >>>>>>> If -P setup is required then the Makefile should have been changed,
> >>>>>>> else
> >>>>>>> our production and rpms are broken now! Well... looking at the
> >>>>>>> pom.xml,
> >>>>>>> it
> >>>>>>> looks like the jboss standalone is configured with -P setup is used,
> >>>>>>> which
> >>>>>>> is yet another hack introduced to developers... As they do not run
> >>>>>>> our
> >>>>>>> service, and suffer from lack of proper environment and configuration
> >>>>>>> settings.
> >>>>>>>
> >>>>>>> My work[1] is exactly to address this one, to eliminate the need for
> >>>>>>> hacking the product and use our production startup sequence and
> >>>>>>> installation. At ./packaging/services/ovirt-engine.xml.in we already
> >>>>>>> have
> >>>>>>> the infinispan settings.
> >>>>>>>
> >>>>>>> So still need your help.
> >>>>>>> Thanks,
> >>>>>>> Alon
> >>>>>>
> >>>>>> I've just started facing the same issue.
> >>>>>> Also noticed this in the server.log:
> >>>>>>
> >>>>>> JBAS014775:    New missing/unsatisfied dependencies:
> >>>>>>         service jboss.mbean.server (missing) dependents: [service
> >>>>>> jboss.infinispan.ovirt-engine.config]
> >>>>>>
> >>>>>> It seems that the generate ovirt-engine.xml under [1] replaces the
> >>>>>> infinispan:1.1 version as noted on [2] with infinispan:1.2.
> >>>>>
> >>>>> I really don't understand the above statement? who/which component have
> >>>>> 1.2?
> >>>>>
> >>>>
> >>>> the template ovirt-engine.xml.in contains:
> >>>>
> >>>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.1 **"
> >>>> default-cache-container="ovirt-engine">
> >>>>
> >>>> vs
> >>>>
> >>>> the generated var/tmp/ovirt-engine/config/ovirt-engine.xml which
> >>>> contains:
> >>>>
> >>>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.2 **"
> >>>> default-cache-container="ovirt-engine">
> >>>>
> >>>> So it used to work with 1.1 (as defined in the template), but the
> >>>> generated ovirt-engine.xml replaces the version to 1.2 which cause it
> >>>> not to work.
> >>>>
> >>>> So my question is how the engine-service.py decides to generate the
> >>>> ovirt-engine.xml with "1.2" version, while the template has "1.1" for
> >>>> infinispan subsystem element ?
> >>>
> >>> Hmmmm!!!!! Good catch! I have never thought that it is possible.
> >>>
> >>> The template is generated ok with 1.1, after startup jboss re-write its
> >>> own
> >>> configuration and change this to 1.2!!!!
> >>>
> >>> Juan, is that normal jboss behavior? Editing its own configuration file?
> >>>
> >>
> >> Yes, it is normal.
> >
> > Hi,
> >
> > What do you suggest to do if application requires specific component
> > version and jboss enforce a different version?
> >
> 
> Change the application to use the version enforced by JBoss.

Ok,
What version is it?
This also means that we might have to change the ovirt-engine.xml.in file whenever jboss gets upgrade?
> 
> > If I understand correctly two versions of jboss can enforce a different
> > version of components.
> >
> > Thanks,
> > Alon
> >
> 
> 
> --
> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3?D, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.
> 


From alonbl at redhat.com  Mon May 27 08:30:30 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 27 May 2013 04:30:30 -0400 (EDT)
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <51A31768.30303@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<51A1D392.5070606@redhat.com>
	<567306121.4292798.1369562974514.JavaMail.root@redhat.com>
	<51A31233.4070303@redhat.com>
	<627861666.4402347.1369641685702.JavaMail.root@redhat.com>
	<51A3159B.5010808@redhat.com>
	<1851240905.4406945.1369642784780.JavaMail.root@redhat.com>
	<51A31768.30303@redhat.com>
Message-ID: <1731689828.4408887.1369643430744.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Monday, May 27, 2013 11:20:56 AM
> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> 
> On 05/27/2013 10:19 AM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Juan Hernandez" <jhernand at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky"
> >> <yzaslavs at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>
> >> Sent: Monday, May 27, 2013 11:13:15 AM
> >> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>
> >> On 05/27/2013 10:01 AM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>> Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky"
> >>>> <yzaslavs at redhat.com>, "engine-devel"
> >>>> <engine-devel at ovirt.org>
> >>>> Sent: Monday, May 27, 2013 10:58:43 AM
> >>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>>>
> >>>> On 05/26/2013 12:09 PM, Alon Bar-Lev wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> >>>>>> <engine-devel at ovirt.org>
> >>>>>> Sent: Sunday, May 26, 2013 12:19:14 PM
> >>>>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>>>>>
> >>>>>> On 05/26/2013 11:52 AM, Alon Bar-Lev wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Moti Asayag" <masayag at redhat.com>
> >>>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> >>>>>>>> <engine-devel at ovirt.org>
> >>>>>>>> Sent: Sunday, May 26, 2013 11:35:40 AM
> >>>>>>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> >>>>>>>>
> >>>>>>>> On 05/03/2013 07:23 AM, Alon Bar-Lev wrote:
> >>>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> Thanks... no I did not follow.
> >>>>>>>>>
> >>>>>>>>> If -P setup is required then the Makefile should have been changed,
> >>>>>>>>> else
> >>>>>>>>> our production and rpms are broken now! Well... looking at the
> >>>>>>>>> pom.xml,
> >>>>>>>>> it
> >>>>>>>>> looks like the jboss standalone is configured with -P setup is
> >>>>>>>>> used,
> >>>>>>>>> which
> >>>>>>>>> is yet another hack introduced to developers... As they do not run
> >>>>>>>>> our
> >>>>>>>>> service, and suffer from lack of proper environment and
> >>>>>>>>> configuration
> >>>>>>>>> settings.
> >>>>>>>>>
> >>>>>>>>> My work[1] is exactly to address this one, to eliminate the need
> >>>>>>>>> for
> >>>>>>>>> hacking the product and use our production startup sequence and
> >>>>>>>>> installation. At ./packaging/services/ovirt-engine.xml.in we
> >>>>>>>>> already
> >>>>>>>>> have
> >>>>>>>>> the infinispan settings.
> >>>>>>>>>
> >>>>>>>>> So still need your help.
> >>>>>>>>> Thanks,
> >>>>>>>>> Alon
> >>>>>>>>
> >>>>>>>> I've just started facing the same issue.
> >>>>>>>> Also noticed this in the server.log:
> >>>>>>>>
> >>>>>>>> JBAS014775:    New missing/unsatisfied dependencies:
> >>>>>>>>          service jboss.mbean.server (missing) dependents: [service
> >>>>>>>> jboss.infinispan.ovirt-engine.config]
> >>>>>>>>
> >>>>>>>> It seems that the generate ovirt-engine.xml under [1] replaces the
> >>>>>>>> infinispan:1.1 version as noted on [2] with infinispan:1.2.
> >>>>>>>
> >>>>>>> I really don't understand the above statement? who/which component
> >>>>>>> have
> >>>>>>> 1.2?
> >>>>>>>
> >>>>>>
> >>>>>> the template ovirt-engine.xml.in contains:
> >>>>>>
> >>>>>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.1 **"
> >>>>>> default-cache-container="ovirt-engine">
> >>>>>>
> >>>>>> vs
> >>>>>>
> >>>>>> the generated var/tmp/ovirt-engine/config/ovirt-engine.xml which
> >>>>>> contains:
> >>>>>>
> >>>>>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.2 **"
> >>>>>> default-cache-container="ovirt-engine">
> >>>>>>
> >>>>>> So it used to work with 1.1 (as defined in the template), but the
> >>>>>> generated ovirt-engine.xml replaces the version to 1.2 which cause it
> >>>>>> not to work.
> >>>>>>
> >>>>>> So my question is how the engine-service.py decides to generate the
> >>>>>> ovirt-engine.xml with "1.2" version, while the template has "1.1" for
> >>>>>> infinispan subsystem element ?
> >>>>>
> >>>>> Hmmmm!!!!! Good catch! I have never thought that it is possible.
> >>>>>
> >>>>> The template is generated ok with 1.1, after startup jboss re-write its
> >>>>> own
> >>>>> configuration and change this to 1.2!!!!
> >>>>>
> >>>>> Juan, is that normal jboss behavior? Editing its own configuration
> >>>>> file?
> >>>>>
> >>>>
> >>>> Yes, it is normal.
> >>>
> >>> Hi,
> >>>
> >>> What do you suggest to do if application requires specific component
> >>> version and jboss enforce a different version?
> >>>
> >>
> >> Change the application to use the version enforced by JBoss.
> >
> >>
> >>> If I understand correctly two versions of jboss can enforce a different
> >>> version of components.
> >
> > So I ask again ^^^^.
> >
> > If application should run under two versions of jboss which enforce two
> > versions of a component, how can application cope?
> >
> 
> I don't know.

Can anyone help us solve the infinispan issue we have?

Summary
Application expects version 1.1 of this component(?).
Jboss enforce version 1.2 (and may be different in future).
Application has a lot of null pointer exception when using this component.

Bottom line
Application is not working.

Thanks,
Alon


From alonbl at redhat.com  Mon May 27 08:31:36 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 27 May 2013 04:31:36 -0400 (EDT)
Subject: [Engine-devel] Error looking up infinispan/ovirt-engine
In-Reply-To: <1681326236.8054493.1369643156526.JavaMail.root@redhat.com>
References: <1100068085.3722269.1367525463983.JavaMail.root@redhat.com>
	<992076494.4291170.1369558328689.JavaMail.root@redhat.com>
	<51A1D392.5070606@redhat.com>
	<567306121.4292798.1369562974514.JavaMail.root@redhat.com>
	<51A31233.4070303@redhat.com>
	<627861666.4402347.1369641685702.JavaMail.root@redhat.com>
	<51A3159B.5010808@redhat.com>
	<1681326236.8054493.1369643156526.JavaMail.root@redhat.com>
Message-ID: <1128556272.4408999.1369643496186.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Juan Hernandez" <jhernand at redhat.com>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "Moti Asayag" <masayag at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, May 27, 2013 11:25:56 AM
> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Juan Hernandez" <jhernand at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky"
> > <yzaslavs at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Monday, May 27, 2013 11:13:15 AM
> > Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> > 
> > On 05/27/2013 10:01 AM, Alon Bar-Lev wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Juan Hernandez" <jhernand at redhat.com>
> > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >> Cc: "Moti Asayag" <masayag at redhat.com>, "Yair Zaslavsky"
> > >> <yzaslavs at redhat.com>, "engine-devel"
> > >> <engine-devel at ovirt.org>
> > >> Sent: Monday, May 27, 2013 10:58:43 AM
> > >> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> > >>
> > >> On 05/26/2013 12:09 PM, Alon Bar-Lev wrote:
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Moti Asayag" <masayag at redhat.com>
> > >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> > >>>> <engine-devel at ovirt.org>
> > >>>> Sent: Sunday, May 26, 2013 12:19:14 PM
> > >>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> > >>>>
> > >>>> On 05/26/2013 11:52 AM, Alon Bar-Lev wrote:
> > >>>>>
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Moti Asayag" <masayag at redhat.com>
> > >>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >>>>>> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "engine-devel"
> > >>>>>> <engine-devel at ovirt.org>
> > >>>>>> Sent: Sunday, May 26, 2013 11:35:40 AM
> > >>>>>> Subject: Re: [Engine-devel] Error looking up infinispan/ovirt-engine
> > >>>>>>
> > >>>>>> On 05/03/2013 07:23 AM, Alon Bar-Lev wrote:
> > >>>>>>>
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>> Thanks... no I did not follow.
> > >>>>>>>
> > >>>>>>> If -P setup is required then the Makefile should have been changed,
> > >>>>>>> else
> > >>>>>>> our production and rpms are broken now! Well... looking at the
> > >>>>>>> pom.xml,
> > >>>>>>> it
> > >>>>>>> looks like the jboss standalone is configured with -P setup is
> > >>>>>>> used,
> > >>>>>>> which
> > >>>>>>> is yet another hack introduced to developers... As they do not run
> > >>>>>>> our
> > >>>>>>> service, and suffer from lack of proper environment and
> > >>>>>>> configuration
> > >>>>>>> settings.
> > >>>>>>>
> > >>>>>>> My work[1] is exactly to address this one, to eliminate the need
> > >>>>>>> for
> > >>>>>>> hacking the product and use our production startup sequence and
> > >>>>>>> installation. At ./packaging/services/ovirt-engine.xml.in we
> > >>>>>>> already
> > >>>>>>> have
> > >>>>>>> the infinispan settings.
> > >>>>>>>
> > >>>>>>> So still need your help.
> > >>>>>>> Thanks,
> > >>>>>>> Alon
> > >>>>>>
> > >>>>>> I've just started facing the same issue.
> > >>>>>> Also noticed this in the server.log:
> > >>>>>>
> > >>>>>> JBAS014775:    New missing/unsatisfied dependencies:
> > >>>>>>         service jboss.mbean.server (missing) dependents: [service
> > >>>>>> jboss.infinispan.ovirt-engine.config]
> > >>>>>>
> > >>>>>> It seems that the generate ovirt-engine.xml under [1] replaces the
> > >>>>>> infinispan:1.1 version as noted on [2] with infinispan:1.2.
> > >>>>>
> > >>>>> I really don't understand the above statement? who/which component
> > >>>>> have
> > >>>>> 1.2?
> > >>>>>
> > >>>>
> > >>>> the template ovirt-engine.xml.in contains:
> > >>>>
> > >>>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.1 **"
> > >>>> default-cache-container="ovirt-engine">
> > >>>>
> > >>>> vs
> > >>>>
> > >>>> the generated var/tmp/ovirt-engine/config/ovirt-engine.xml which
> > >>>> contains:
> > >>>>
> > >>>> <subsystem xmlns="urn:jboss:domain:infinispan:** 1.2 **"
> > >>>> default-cache-container="ovirt-engine">
> > >>>>
> > >>>> So it used to work with 1.1 (as defined in the template), but the
> > >>>> generated ovirt-engine.xml replaces the version to 1.2 which cause it
> > >>>> not to work.
> > >>>>
> > >>>> So my question is how the engine-service.py decides to generate the
> > >>>> ovirt-engine.xml with "1.2" version, while the template has "1.1" for
> > >>>> infinispan subsystem element ?
> > >>>
> > >>> Hmmmm!!!!! Good catch! I have never thought that it is possible.
> > >>>
> > >>> The template is generated ok with 1.1, after startup jboss re-write its
> > >>> own
> > >>> configuration and change this to 1.2!!!!
> > >>>
> > >>> Juan, is that normal jboss behavior? Editing its own configuration
> > >>> file?
> > >>>
> > >>
> > >> Yes, it is normal.
> > >
> > > Hi,
> > >
> > > What do you suggest to do if application requires specific component
> > > version and jboss enforce a different version?
> > >
> > 
> > Change the application to use the version enforced by JBoss.
> 
> Ok,
> What version is it?

1.2

> This also means that we might have to change the ovirt-engine.xml.in file
> whenever jboss gets upgrade?

No need... as jboss takes care of it... it just overrides whatever we put.
Yet another jboss magic.

> > 
> > > If I understand correctly two versions of jboss can enforce a different
> > > version of components.
> > >
> > > Thanks,
> > > Alon
> > >
> > 
> > 
> > --
> > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > 3?D, 28016 Madrid, Spain
> > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.
> > 
> 


From ecohen at redhat.com  Mon May 27 12:07:55 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Mon, 27 May 2013 08:07:55 -0400 (EDT)
Subject: [Engine-devel] findbugs [normal priority] - *please fix ASAP*
In-Reply-To: <334686227.12610612.1369656125275.JavaMail.root@redhat.com>
Message-ID: <1334031104.12612040.1369656475568.JavaMail.root@redhat.com>

lvernia:
find bugs error:
http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4323/findbugsResult/NORMAL/module.935532853/source.199038/#60
in file:
frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/Uri.java
caused by patch:
http://gerrit.ovirt.org/#/c/14695/ [webadmin: Added validation to ProviderModel, merged: May 27]

----

mkublin:
find bugs error:
http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4323/findbugsResult/NORMAL/module.-609324659/source.198236/#342
in file:
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/RunVmCommandBase.java
caused by patch:
http://gerrit.ovirt.org/#/c/13740/ [engine: Fixing perfomance issue between VdsRunTimeInfo and RunVmCommandBase, merged: Apr 10]

----
Thanks,
Einav


From yzaslavs at redhat.com  Mon May 27 12:17:03 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 27 May 2013 08:17:03 -0400 (EDT)
Subject: [Engine-devel] findbugs [normal priority] - *please fix ASAP*
In-Reply-To: <1334031104.12612040.1369656475568.JavaMail.root@redhat.com>
References: <1334031104.12612040.1369656475568.JavaMail.root@redhat.com>
Message-ID: <466583400.8209650.1369657023731.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, May 27, 2013 3:07:55 PM
> Subject: [Engine-devel] findbugs [normal priority] - *please fix ASAP*
> 
> lvernia:
> find bugs error:
> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4323/findbugsResult/NORMAL/module.935532853/source.199038/#60
> in file:
> frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/Uri.java
> caused by patch:
> http://gerrit.ovirt.org/#/c/14695/ [webadmin: Added validation to
> ProviderModel, merged: May 27]
> 
> ----
> 
> mkublin:
> find bugs error:
> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4323/findbugsResult/NORMAL/module.-609324659/source.198236/#342
> in file:
> backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/RunVmCommandBase.java
> caused by patch:
> http://gerrit.ovirt.org/#/c/13740/ [engine: Fixing perfomance issue between
> VdsRunTimeInfo and RunVmCommandBase, merged: Apr 10]

This should have been handled by the findbugs filter . The fact that it was not handled means we still have an issue with filters.
I'm taking a look.

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


From shweng at 163.com  Mon May 27 13:35:42 2013
From: shweng at 163.com (Edgar)
Date: Mon, 27 May 2013 21:35:42 +0800 (CST)
Subject: [Engine-devel]  How to get the number of all running VMs
Message-ID: <1469862c.141aa.13ee6339da3.Coremail.shweng@163.com>

Hi All,
 I need to get the number of All running VMs of the oVirt-engine.
 My thought is first get all hosts with "up" status and then traverse each host and count the 
 VM with state "Running" .


  Does this method feasible,and is there any easier way to count the running VMs of oVirt-engine?


 Best Regards


  


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

From ofrenkel at redhat.com  Mon May 27 14:02:37 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Mon, 27 May 2013 10:02:37 -0400 (EDT)
Subject: [Engine-devel] How to get the number of all running VMs
In-Reply-To: <1469862c.141aa.13ee6339da3.Coremail.shweng@163.com>
References: <1469862c.141aa.13ee6339da3.Coremail.shweng@163.com>
Message-ID: <1245316381.12676490.1369663357142.JavaMail.root@redhat.com>

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

> From: "Edgar" <shweng at 163.com>
> To: engine-devel at ovirt.org
> Sent: Monday, May 27, 2013 4:35:42 PM
> Subject: [Engine-devel] How to get the number of all running VMs

> Hi All,
> I need to get the number of All running VMs of the oVirt-engine.
> My thought is first get all hosts with "up" status and then traverse each
> host and count the
> VM with state "Running" .

> Does this method feasible,and is there any easier way to count the running
> VMs of oVirt-engine?

> Best Regards

you can use the webadmin, but not sure there is an easy way to see total count if there are more than one pages of results, 
just enter in the search: 
Vms: status != down and status != imagelocked and status != suspended 

you can use get the same with rest api: 
http://localhost:8700/api/vms?search=%22status%20!=%20down%20and%20status%20!=%20imagelocked%20and%20status%20!=%20suspended%22 
and parse the result 

or by using the db: 
select count(*) from vm_dynamic where status not in (0,15,13); 

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130527/f6c8cb01/attachment.html>

From vered at redhat.com  Mon May 27 15:18:58 2013
From: vered at redhat.com (Vered Volansky)
Date: Mon, 27 May 2013 11:18:58 -0400 (EDT)
Subject: [Engine-devel] Disk BE very small refactoring
In-Reply-To: <2047071517.12703814.1369667628627.JavaMail.root@redhat.com>
Message-ID: <1543112346.12706449.1369667938808.JavaMail.root@redhat.com>

Hi All,

Please express your opinion if you have any -

Currently Disk BE has a plugged property, which should be a property of the relationship between vm(or template) and a disk.
I plan to remove this property from the Disk entity, and add new entity, called DeviceDisk.
This should inherit from Disk and contain the vm/template guid and the plugged property at first round.
At second round it'll also contain the readOnly property, for RO disks, TBD right after.

Appreciate any input,
Vered


From yzaslavs at redhat.com  Mon May 27 15:22:58 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 27 May 2013 11:22:58 -0400 (EDT)
Subject: [Engine-devel] Disk BE very small refactoring
In-Reply-To: <1543112346.12706449.1369667938808.JavaMail.root@redhat.com>
References: <1543112346.12706449.1369667938808.JavaMail.root@redhat.com>
Message-ID: <1454073553.8350387.1369668178246.JavaMail.root@redhat.com>

Vered,
VmDevice has "isPlugged" field,
Why not have somehow in your inheritence (either Disk or a subclass) a field : "VmDevice device"
and have isPlugged method called "device.isPlugged()" ?

Then you can also add the readOnly property which is not represented at VmDevice.


Does this sound logical to you?

----- Original Message -----
> From: "Vered Volansky" <vered at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, May 27, 2013 6:18:58 PM
> Subject: [Engine-devel] Disk BE very small refactoring
> 
> Hi All,
> 
> Please express your opinion if you have any -
> 
> Currently Disk BE has a plugged property, which should be a property of the
> relationship between vm(or template) and a disk.
> I plan to remove this property from the Disk entity, and add new entity,
> called DeviceDisk.
> This should inherit from Disk and contain the vm/template guid and the
> plugged property at first round.
> At second round it'll also contain the readOnly property, for RO disks, TBD
> right after.
> 
> Appreciate any input,
> Vered
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mpastern at redhat.com  Mon May 27 15:35:35 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 27 May 2013 18:35:35 +0300
Subject: [Engine-devel] How to get the number of all running VMs
In-Reply-To: <1469862c.141aa.13ee6339da3.Coremail.shweng@163.com>
References: <1469862c.141aa.13ee6339da3.Coremail.shweng@163.com>
Message-ID: <51A37D47.5050801@redhat.com>

On 05/27/2013 04:35 PM, Edgar wrote:
> Hi All,
>  I need to get the number of All running VMs of the oVirt-engine.
>  My thought is first get all hosts with "up" status and then traverse each host and count the 
>  VM with state "Running" .

you can use ovirt-shell (3.3+) for this, just run 'summary' command:

[oVirt shell (connected)]# summary

hosts-active          : 0
hosts-total           : 0
storage_domains-active: 0
storage_domains-total : 0
users-active          : 1
users-total           : 1
vms-active            : 0
vms-total             : 3

> 
>   Does this method feasible,and is there any easier way to count the running VMs of oVirt-engine?
> 
>  Best Regards
> 
>   
> 
>  
> 
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From dfediuck at redhat.com  Mon May 27 15:37:43 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 27 May 2013 11:37:43 -0400 (EDT)
Subject: [Engine-devel] Regarding access to ovirt.org for creating
 feature	pages
In-Reply-To: <51A306C6.6010100@redhat.com>
References: <51A306C6.6010100@redhat.com>
Message-ID: <1288935691.12712355.1369669063963.JavaMail.root@redhat.com>

Adding the infra team.
Can you please take a look?

----- Original Message -----
> From: "Shubhendu Tripathi" <shtripat at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, May 27, 2013 10:09:58 AM
> Subject: [Engine-devel] Regarding access to ovirt.org for creating feature	pages
> 
> Hi All,
> 
> I have joined RedHat this month and work with RHSC team.
> I need to create a feature page on Ovirt WIKI, and so raised a request
> for the same to get an id created.
> 
> I have not received any confirmation till now.
> Kindly let me know if something is missing or I need to follow some
> other process.
> 
> ID Created: shtripat
> Email Id: shtripat at redhat.com
> 
> Thanks and Regards,
> Shubhendu Tripathi
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Mon May 27 15:42:52 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 27 May 2013 11:42:52 -0400 (EDT)
Subject: [Engine-devel] Disk BE very small refactoring
In-Reply-To: <1454073553.8350387.1369668178246.JavaMail.root@redhat.com>
References: <1543112346.12706449.1369667938808.JavaMail.root@redhat.com>
	<1454073553.8350387.1369668178246.JavaMail.root@redhat.com>
Message-ID: <691748503.8356250.1369669372750.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Vered Volansky" <vered at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, May 27, 2013 6:22:58 PM
> Subject: Re: [Engine-devel] Disk BE very small refactoring
> 
> Vered,
> VmDevice has "isPlugged" field,
> Why not have somehow in your inheritence (either Disk or a subclass) a field
> : "VmDevice device"
> and have isPlugged method called "device.isPlugged()" ?
> 
> Then you can also add the readOnly property which is not represented at
> VmDevice.
> 
> 
> Does this sound logical to you?

Vered, I forgot sharable disk may be associated with two VMs, hence having a field of VmDevice may be problematic.
However, maybe we need some interface (i.e - Device) which BothVmDevice and your class (or maybe an object of some class that will be contained in your class) will implement?

> 
> ----- Original Message -----
> > From: "Vered Volansky" <vered at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, May 27, 2013 6:18:58 PM
> > Subject: [Engine-devel] Disk BE very small refactoring
> > 
> > Hi All,
> > 
> > Please express your opinion if you have any -
> > 
> > Currently Disk BE has a plugged property, which should be a property of the
> > relationship between vm(or template) and a disk.
> > I plan to remove this property from the Disk entity, and add new entity,
> > called DeviceDisk.
> > This should inherit from Disk and contain the vm/template guid and the
> > plugged property at first round.
> > At second round it'll also contain the readOnly property, for RO disks, TBD
> > right after.
> > 
> > Appreciate any input,
> > Vered
> > _______________________________________________
> > 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 mpastern at redhat.com  Mon May 27 15:47:16 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 27 May 2013 18:47:16 +0300
Subject: [Engine-devel] How to get the number of all running VMs
In-Reply-To: <51A37D47.5050801@redhat.com>
References: <1469862c.141aa.13ee6339da3.Coremail.shweng@163.com>
	<51A37D47.5050801@redhat.com>
Message-ID: <51A38004.6070100@redhat.com>

On 05/27/2013 06:35 PM, Michael Pasternak wrote:
> On 05/27/2013 04:35 PM, Edgar wrote:
>> Hi All,
>>  I need to get the number of All running VMs of the oVirt-engine.
>>  My thought is first get all hosts with "up" status and then traverse each host and count the 
>>  VM with state "Running" .
> 
> you can use ovirt-shell (3.3+) for this, just run 'summary' command:
> 
> [oVirt shell (connected)]# summary
> 
> hosts-active          : 0
> hosts-total           : 0
> storage_domains-active: 0
> storage_domains-total : 0
> users-active          : 1
> users-total           : 1
> vms-active            : 0
> vms-total             : 3

btw, you can script it (see [1]), just do 'summary | grep vms-active'

[1] http://www.ovirt.org/CLI#Scripting

> 
>>
>>   Does this method feasible,and is there any easier way to count the running VMs of oVirt-engine?
>>
>>  Best Regards
>>
>>   
>>
>>  
>>
>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mkolesni at redhat.com  Tue May 28 07:09:12 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Tue, 28 May 2013 03:09:12 -0400 (EDT)
Subject: [Engine-devel] Disk BE very small refactoring
In-Reply-To: <691748503.8356250.1369669372750.JavaMail.root@redhat.com>
References: <1543112346.12706449.1369667938808.JavaMail.root@redhat.com>
	<1454073553.8350387.1369668178246.JavaMail.root@redhat.com>
	<691748503.8356250.1369669372750.JavaMail.root@redhat.com>
Message-ID: <2141716379.7196464.1369724952392.JavaMail.root@redhat.com>

----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > To: "Vered Volansky" <vered at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, May 27, 2013 6:22:58 PM
> > Subject: Re: [Engine-devel] Disk BE very small refactoring
> > 
> > Vered,
> > VmDevice has "isPlugged" field,
> > Why not have somehow in your inheritence (either Disk or a subclass) a
> > field
> > : "VmDevice device"
> > and have isPlugged method called "device.isPlugged()" ?
> > 
> > Then you can also add the readOnly property which is not represented at
> > VmDevice.
> > 
> > 
> > Does this sound logical to you?
> 
> Vered, I forgot sharable disk may be associated with two VMs, hence having a
> field of VmDevice may be problematic.

In this case there will be 2 VmDevice entities for the same disk, IIUC.
Why not just rely on the field there? Why does it need to be "flattened" on the Disk BE?

> However, maybe we need some interface (i.e - Device) which BothVmDevice and
> your class (or maybe an object of some class that will be contained in your
> class) will implement?
> 
> > 
> > ----- Original Message -----
> > > From: "Vered Volansky" <vered at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Monday, May 27, 2013 6:18:58 PM
> > > Subject: [Engine-devel] Disk BE very small refactoring
> > > 
> > > Hi All,
> > > 
> > > Please express your opinion if you have any -
> > > 
> > > Currently Disk BE has a plugged property, which should be a property of
> > > the
> > > relationship between vm(or template) and a disk.
> > > I plan to remove this property from the Disk entity, and add new entity,
> > > called DeviceDisk.
> > > This should inherit from Disk and contain the vm/template guid and the
> > > plugged property at first round.
> > > At second round it'll also contain the readOnly property, for RO disks,
> > > TBD
> > > right after.
> > > 
> > > Appreciate any input,
> > > Vered
> > > _______________________________________________
> > > 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  Tue May 28 08:24:41 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Tue, 28 May 2013 04:24:41 -0400 (EDT)
Subject: [Engine-devel] Disk BE very small refactoring
In-Reply-To: <1454073553.8350387.1369668178246.JavaMail.root@redhat.com>
References: <1543112346.12706449.1369667938808.JavaMail.root@redhat.com>
	<1454073553.8350387.1369668178246.JavaMail.root@redhat.com>
Message-ID: <1021461587.13107769.1369729481376.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Vered Volansky" <vered at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, May 27, 2013 6:22:58 PM
> Subject: Re: [Engine-devel] Disk BE very small refactoring
> 
> Vered,
> VmDevice has "isPlugged" field,
> Why not have somehow in your inheritence (either Disk or a subclass) a field
> : "VmDevice device"

disk id is the device id, no need for field to represent the relation.
the combination of disk-id and a specific entity (vm/template) will get you the other info

> and have isPlugged method called "device.isPlugged()" ?
> 
> Then you can also add the readOnly property which is not represented at
> VmDevice.
> 
> 
> Does this sound logical to you?
> 
> ----- Original Message -----
> > From: "Vered Volansky" <vered at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, May 27, 2013 6:18:58 PM
> > Subject: [Engine-devel] Disk BE very small refactoring
> > 
> > Hi All,
> > 
> > Please express your opinion if you have any -
> > 
> > Currently Disk BE has a plugged property, which should be a property of the
> > relationship between vm(or template) and a disk.
> > I plan to remove this property from the Disk entity, and add new entity,
> > called DeviceDisk.
> > This should inherit from Disk and contain the vm/template guid and the
> > plugged property at first round.
> > At second round it'll also contain the readOnly property, for RO disks, TBD
> > right after.
> > 
> > Appreciate any input,
> > Vered
> > _______________________________________________
> > 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 mlipchuk at redhat.com  Tue May 28 10:49:46 2013
From: mlipchuk at redhat.com (Maor Lipchuk)
Date: Tue, 28 May 2013 13:49:46 +0300
Subject: [Engine-devel] Disk BE very small refactoring
In-Reply-To: <1021461587.13107769.1369729481376.JavaMail.root@redhat.com>
References: <1543112346.12706449.1369667938808.JavaMail.root@redhat.com>
	<1454073553.8350387.1369668178246.JavaMail.root@redhat.com>
	<1021461587.13107769.1369729481376.JavaMail.root@redhat.com>
Message-ID: <51A48BCA.5020509@redhat.com>

I think the main problem is that we abuse the business entity to act as
an O/R mapping class to the DB and also to be used as a business entity
for presentation purposes.

I understand how Yair thought isPlugged could be fetched from vmDevice,
this is a confusing design, and it is just one example and more to come.

I suggest that if we already thinking of changing the class hierarchy,
we can start by implementing a package for presentation classes for
transient classes such as this instead enforcing complex hierarchy.

The query class will fetch all the data from the DB and initialized the
transient class and send it to the client.
I think it could be a good start and will solve many issues we might
encounter in the future.

Regards,
Maor

On 05/28/2013 11:24 AM, Omer Frenkel wrote:
> 
> 
> ----- Original Message -----
>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>> To: "Vered Volansky" <vered at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Monday, May 27, 2013 6:22:58 PM
>> Subject: Re: [Engine-devel] Disk BE very small refactoring
>>
>> Vered,
>> VmDevice has "isPlugged" field,
>> Why not have somehow in your inheritence (either Disk or a subclass) a field
>> : "VmDevice device"
> 
> disk id is the device id, no need for field to represent the relation.
> the combination of disk-id and a specific entity (vm/template) will get you the other info
> 
>> and have isPlugged method called "device.isPlugged()" ?
>>
>> Then you can also add the readOnly property which is not represented at
>> VmDevice.
>>
>>
>> Does this sound logical to you?
>>
>> ----- Original Message -----
>>> From: "Vered Volansky" <vered at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Sent: Monday, May 27, 2013 6:18:58 PM
>>> Subject: [Engine-devel] Disk BE very small refactoring
>>>
>>> Hi All,
>>>
>>> Please express your opinion if you have any -
>>>
>>> Currently Disk BE has a plugged property, which should be a property of the
>>> relationship between vm(or template) and a disk.
>>> I plan to remove this property from the Disk entity, and add new entity,
>>> called DeviceDisk.
>>> This should inherit from Disk and contain the vm/template guid and the
>>> plugged property at first round.
>>> At second round it'll also contain the readOnly property, for RO disks, TBD
>>> right after.
>>>
>>> Appreciate any input,
>>> Vered
>>> _______________________________________________
>>> 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 wlbleaboy at 126.com  Tue May 28 11:54:24 2013
From: wlbleaboy at 126.com (wlbleaboy@126)
Date: Tue, 28 May 2013 19:54:24 +0800
Subject: [Engine-devel] about ticket
Message-ID: <000801ce5b9a$1a068850$4e1398f0$@com>

Hi all:

         When I connect to a vm via spicec or spicy, I need a ticket, so I
get a ticket from ovirt-engine via 

ovirt-engine-sdk, and it works well.

         But I don't know how long can a ticket to use? For example, when I
got a ticket, it's validated 

In many minutes, or several hours, or always. Or in some other condition, a
ticket will invalidate.

         If a ticket have a time limits, where and how could I change it,
let it always can validated.

 

         I guess the ticket come from ovirt-node, when I via
ovirt-engine-sdk get a ticket, sdk will get 

ovirt-engine a POST action, and then engine-core give VDSM a command, VDSM
get it from ovirt-node

and return it to ovirt-engine. ovirt-engine-sdk use GET action to get it.

 

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

From ofrenkel at redhat.com  Tue May 28 12:45:24 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Tue, 28 May 2013 08:45:24 -0400 (EDT)
Subject: [Engine-devel] about ticket
In-Reply-To: <000801ce5b9a$1a068850$4e1398f0$@com>
References: <000801ce5b9a$1a068850$4e1398f0$@com>
Message-ID: <1477670883.13298650.1369745124284.JavaMail.root@redhat.com>

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

> From: "wlbleaboy at 126" <wlbleaboy at 126.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, May 28, 2013 2:54:24 PM
> Subject: [Engine-devel] about ticket

> Hi all:

> When I connect to a vm via spicec or spicy, I need a ticket, so I get a
> ticket from ovirt-engine via

> ovirt-engine-sdk, and it works well.

> But I don?t know how long can a ticket to use? For example, when I got a
> ticket, it?s validated

> In many minutes, or several hours, or always. Or in some other condition, a
> ticket will invalidate.

> If a ticket have a time limits, where and how could I change it, let it
> always can validated.

> I guess the ticket come from ovirt-node, when I via ovirt-engine-sdk get a
> ticket, sdk will get

> ovirt-engine a POST action, and then engine-core give VDSM a command, VDSM
> get it from ovirt-node

> and return it to ovirt-engine. ovirt-engine-sdk use GET action to get it.

you can use expiry with the sdk, 
default is 120sec 

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130528/d442673a/attachment.html>

From iheim at redhat.com  Tue May 28 13:14:51 2013
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 28 May 2013 16:14:51 +0300
Subject: [Engine-devel] about ticket
In-Reply-To: <000801ce5b9a$1a068850$4e1398f0$@com>
References: <000801ce5b9a$1a068850$4e1398f0$@com>
Message-ID: <51A4ADCB.8060907@redhat.com>

On 05/28/2013 02:54 PM, wlbleaboy at 126 wrote:
> When I connect to a vm via spicec or spicy, I need a ticket, so I get a
> ticket from ovirt-engine via
>
> ovirt-engine-sdk, and it works well.
>
> But I don?t know how long can a ticket to use? For example, when I got a
> ticket, it?s validated
>
> In many minutes, or several hours, or always. Or in some other
> condition, a ticket will invalidate.
>
> If a ticket have a time limits, where and how could I change it, let it
> always can validated.
>
> I guess the ticket come from ovirt-node, when I via ovirt-engine-sdk get
> a ticket, sdk will get
>
> ovirt-engine a POST action, and then engine-core give VDSM a command,
> VDSM get it from ovirt-node
>
> and return it to ovirt-engine. ovirt-engine-sdk use GET action to get it.
>

not exactly. engine generates the ticket, and sends it to the node.
the ticket expiration is on how long you have until you use it. once you 
do, the session can last "forever".
omer answered on ability to change the expiration


From mgoldboi at redhat.com  Tue May 28 14:01:11 2013
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Tue, 28 May 2013 17:01:11 +0300
Subject: [Engine-devel] [3.3 release process] feature freeze readiness
In-Reply-To: <519DF477.9000300@redhat.com>
References: <519DF477.9000300@redhat.com>
Message-ID: <51A4B8A7.4070809@redhat.com>

On 05/23/2013 01:50 PM, Moran Goldboim wrote:
> we are about a week away from feature freeze of oVirt 3.3 (May 31st). 
> In order to be able to converge to this date we would need your help 
> (feature owners) understanding feature/overall status.
>
> I have updated  OVirt 3.3 release-management page [1] with features 
> status table [2]. having this complete table filled will help us 
> determine this version readiness.
>
> a test page addition is needed for each feature (link through the 
> table) - this will enable us good visibility and testing of those 
> features in test-day.
>
> I have left the old 3.3 feature overview -just below the new table, to 
> make sure i have taken all needed from that info. please verify all 
> you need is in the table, since this part will be deleted on feature 
> freeze readiness review - next Wednesday meeting.
>
> completing filling this table should be done no later than Tuesday May 
> 28th.
>
> Thanks.
>
> [1]http://www.ovirt.org/OVirt_3.3_release-management
> [2]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table 
>
> [3]http://www.ovirt.org/OVirt_3.3_release-management#Features
>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch

Thanks for everyone who updated their status on the table.
Still there are missing features around virt, infra, storage and sla, 
please complete statuses on this missing features today so we can attend 
to understand the release status tomorrow's meeting.

Thanks.


From gchaplik at redhat.com  Tue May 28 14:34:11 2013
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Tue, 28 May 2013 10:34:11 -0400 (EDT)
Subject: [Engine-devel] oVirt Scheduler API Design
In-Reply-To: <1085554415.7417380.1369751356277.JavaMail.root@redhat.com>
Message-ID: <466692572.7422131.1369751651486.JavaMail.root@redhat.com>

Hi all, 

Attached links for oVirt Scheduler API design wiki page.

High level overview: http://www.ovirt.org/Features/oVirtScheduler
Detailed design: http://www.ovirt.org/Features/oVirtSchedulerAPI

You are more than welcome to share you thoughts.

Thanks, 
Gilad.


From yzaslavs at redhat.com  Tue May 28 15:28:41 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 28 May 2013 11:28:41 -0400 (EDT)
Subject: [Engine-devel] Async task manager changes for oVirt 3.3
In-Reply-To: <88963113.9049995.1369754894011.JavaMail.root@redhat.com>
Message-ID: <707262625.9051146.1369754921292.JavaMail.root@redhat.com>

Hi all,
The following pages describes the changes that we would like to insert/think it's feasible for async tasks at engine for oVirt 3.3.
Bare in mind these changes are a part of a bigger of set of changes we would like to introduce

http://www.ovirt.org/Features/AsyncTaskManagerChanges_3.3



From vered at redhat.com  Tue May 28 17:40:38 2013
From: vered at redhat.com (Vered Volansky)
Date: Tue, 28 May 2013 13:40:38 -0400 (EDT)
Subject: [Engine-devel] Disk BE very small refactoring
In-Reply-To: <51A48BCA.5020509@redhat.com>
References: <1543112346.12706449.1369667938808.JavaMail.root@redhat.com>
	<1454073553.8350387.1369668178246.JavaMail.root@redhat.com>
	<1021461587.13107769.1369729481376.JavaMail.root@redhat.com>
	<51A48BCA.5020509@redhat.com>
Message-ID: <2012114925.13632941.1369762838851.JavaMail.root@redhat.com>

I had a problem, didn't see all the replies till now.

I'll add some more info as to why we want to do this like we do.
It all started from adding the readOnly property to disks. It should have been handled like plugged is handled, yet plugged is a hack, and if we don't change that now, we'll only keep on adding unreasonable hacks.

So from the start -
Disk currently:
- Sometimes represents a disk in a vm context and sometimes not.
- Holds plugged property, which is only relevant when a disk is in a vm context, which already suggests this is not the natural place for it.
- Also holds bootable and interface, which cause limitations of use, but are not so obviously related to the relationship between Disk and Vm as plugged.
- Can be shared between several vm's, to some plugged and to some not plugged.
- Will soon be optionally RO in one VM and RW in another, which is exactly the same as plugged, and therefore plugged issue should be fixed first.

Every column in that shows a disk in the UI receives a Disk entity, and show its contents, while plugged/unplugged is ignored when not in a VM context.
The way things are now, using a VmDevice in the where we need it to show plug status, we'll also have to use it in all other columns, which is irrelevant and just totally not related.
So using VmDevice in UI is a no go.

The UI is the main limitation forcing us to use something that extends Disk, and what I described below is the easiest thing to implement in the time restrictions we have without changing the entire system.

I think this answers all the questions not already answered by others.
Regarding Maor suggestion - might be a good idea, but not in this scope or time-frame.

If there is any other/unanswered issue or objection to the design change please share.

I appreciate your inputs,
Vered


----- Original Message -----
> From: "Maor Lipchuk" <mlipchuk at redhat.com>
> To: "Vered Volansky" <vered at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, May 28, 2013 1:49:46 PM
> Subject: Re: [Engine-devel] Disk BE very small refactoring
> 
> I think the main problem is that we abuse the business entity to act as
> an O/R mapping class to the DB and also to be used as a business entity
> for presentation purposes.
> 
> I understand how Yair thought isPlugged could be fetched from vmDevice,
> this is a confusing design, and it is just one example and more to come.
> 
> I suggest that if we already thinking of changing the class hierarchy,
> we can start by implementing a package for presentation classes for
> transient classes such as this instead enforcing complex hierarchy.
> 
> The query class will fetch all the data from the DB and initialized the
> transient class and send it to the client.
> I think it could be a good start and will solve many issues we might
> encounter in the future.
> 
> Regards,
> Maor
> 
> On 05/28/2013 11:24 AM, Omer Frenkel wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> >> To: "Vered Volansky" <vered at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Monday, May 27, 2013 6:22:58 PM
> >> Subject: Re: [Engine-devel] Disk BE very small refactoring
> >>
> >> Vered,
> >> VmDevice has "isPlugged" field,
> >> Why not have somehow in your inheritence (either Disk or a subclass) a
> >> field
> >> : "VmDevice device"
> > 
> > disk id is the device id, no need for field to represent the relation.
> > the combination of disk-id and a specific entity (vm/template) will get you
> > the other info
> > 
> >> and have isPlugged method called "device.isPlugged()" ?
> >>
> >> Then you can also add the readOnly property which is not represented at
> >> VmDevice.
> >>
> >>
> >> Does this sound logical to you?
> >>
> >> ----- Original Message -----
> >>> From: "Vered Volansky" <vered at redhat.com>
> >>> To: engine-devel at ovirt.org
> >>> Sent: Monday, May 27, 2013 6:18:58 PM
> >>> Subject: [Engine-devel] Disk BE very small refactoring
> >>>
> >>> Hi All,
> >>>
> >>> Please express your opinion if you have any -
> >>>
> >>> Currently Disk BE has a plugged property, which should be a property of
> >>> the
> >>> relationship between vm(or template) and a disk.
> >>> I plan to remove this property from the Disk entity, and add new entity,
> >>> called DeviceDisk.
> >>> This should inherit from Disk and contain the vm/template guid and the
> >>> plugged property at first round.
> >>> At second round it'll also contain the readOnly property, for RO disks,
> >>> TBD
> >>> right after.
> >>>
> >>> Appreciate any input,
> >>> Vered
> >>> _______________________________________________
> >>> 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 ecohen at redhat.com  Tue May 28 21:03:35 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Tue, 28 May 2013 17:03:35 -0400 (EDT)
Subject: [Engine-devel] findbugs [normal priority] - *please fix ASAP*
In-Reply-To: <466583400.8209650.1369657023731.JavaMail.root@redhat.com>
References: <1334031104.12612040.1369656475568.JavaMail.root@redhat.com>
	<466583400.8209650.1369657023731.JavaMail.root@redhat.com>
Message-ID: <101604778.13743152.1369775015098.JavaMail.root@redhat.com>

many thanks Yair/Lior/Derez for checking/fixing/reviewing/verifying/merging.
findbugs is now back to green:
http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4338/

----
Regards,
Einav

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, May 27, 2013 8:17:03 AM
> Subject: Re: [Engine-devel] findbugs [normal priority] - *please fix ASAP*
> 
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Monday, May 27, 2013 3:07:55 PM
> > Subject: [Engine-devel] findbugs [normal priority] - *please fix ASAP*
> > 
> > lvernia:
> > find bugs error:
> > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4323/findbugsResult/NORMAL/module.935532853/source.199038/#60
> > in file:
> > frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/Uri.java
> > caused by patch:
> > http://gerrit.ovirt.org/#/c/14695/ [webadmin: Added validation to
> > ProviderModel, merged: May 27]
> > 
> > ----
> > 
> > mkublin:
> > find bugs error:
> > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4323/findbugsResult/NORMAL/module.-609324659/source.198236/#342
> > in file:
> > backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/RunVmCommandBase.java
> > caused by patch:
> > http://gerrit.ovirt.org/#/c/13740/ [engine: Fixing perfomance issue between
> > VdsRunTimeInfo and RunVmCommandBase, merged: Apr 10]
> 
> This should have been handled by the findbugs filter . The fact that it was
> not handled means we still have an issue with filters.
> I'm taking a look.
> 
> > 
> > ----
> > Thanks,
> > Einav
> > _______________________________________________
> > 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  Tue May 28 21:21:21 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 29 May 2013 00:21:21 +0300
Subject: [Engine-devel] oVirt updates - May 29th, 2013
Message-ID: <51A51FD1.40007@redhat.com>

1. From the Web

- interview with Theron on oVirt (chinese)
   http://www.infoq.com/cn/news/2013/05/conrey-on-ovirt

- interview with Dave Neary about his work (and oVirt)

http://www.techradar.com/news/software/what-went-wrong-with-meego-nokia-lost-faith-in-the-project--1147770

- Nagios monitoring plugin check_rhev3 1.2 released
   http://lists.ovirt.org/pipermail/users/2013-May/014389.html

- a blog on how to do HA for engine (written for rhev, should be
   relevant to oVirt as well)
   http://captainkvm.com/2013/05/providing-high-availability-for-rhev-m/


2. Video
- youtube available for IBM's session on connected Communities,
   Innovative Technologies: OpenStack, oVirt, and KVM
   http://www.youtube.com/watch?v=Pg7ShV-HvCE

- fog/foreman by ohad levy (fog supports oVirt)
   http://www.youtube.com/watch?v=JgaQ_ekR2JA


3. Conferences

- FOSDEM  presentations page uploaded
   http://www.ovirt.org/FOSDEM_2013

- some of the Shangahi presentations uploaded
   http://www.ovirt.org/Intel_Workshop_May_2013

- upcoming - LinuxCon Japan
   oVirt session in LinuxCon Japan (this week)

- upcoming - oVirt Developer days (with KVM Forum)
   Edinburgh, UK - October 21 - 23, 2013


4. Other

- help test the new oVirt installer and developer setup environments
   http://www.ovirt.org/OVirtEngineDevelopmentEnvironment

- RC for oVirt Node 3.0.0 is now available (but not compatible with
   ovirt-engine yet)

Thanks,
    Itamar


From ecohen at redhat.com  Tue May 28 21:53:47 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Tue, 28 May 2013 17:53:47 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <201305282105.r4SL5ccM002657@gerrit.ovirt.org>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<201305282105.r4SL5ccM002657@gerrit.ovirt.org>
Message-ID: <70378615.13764765.1369778027447.JavaMail.root@redhat.com>

when reviewing the code for the "redesign of vm related dialogs", Daniel has 
raised an interesting question: Why do we want the static header only in VM dialog?

(I assume that he refers to the top section of the New VM dialog as seen in [1], which 
contains the DC/Cluster, Quota, etc information, and is "static", i.e., it is always 
displayed, regardless of the selected side-tab within the dialog)

I agree with what Daniel is implying here: for consistency, we would probably want to 
introduce this static header to other dialogs, at least to the ones that also contain 
side-tabs in which it makes sense to turn the "header" to static 
[e.g. 
"New Host" (which contains a DC + Cluster "header") - see http://oi39.tinypic.com/2z84xnp.jpg, 
"New Cluster" (which contains a DC "header") - see http://oi40.tinypic.com/2vmyj2x.jpg]

[I assume, of course, that all the VM-like dialogs (e.g. New/Edit VM-Pool) will also have 
static headers - I don't know if the patch already takes care of that or not]

Thoughts?

[@Daniel - if you had something else in mind, and/or other dialogs in mind - please feel free 
to add/amend/etc]

----
Thanks,
Einav

[1] http://www.ovirt.org/images/9/9e/Instance_type.pdf

----- Original Message -----
> From: derez at redhat.com
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>, "Frank Kobzik" <fkobzik at redhat.com>,
> "Eldan Hildesheim" <info at eldanet.com>
> Sent: Tuesday, May 28, 2013 5:05:38 PM
> Subject: Change in ovirt-engine[master]: userportal,webadmin: redesign of vm related dialogs
> 
> Daniel Erez has posted comments on this change.
> 
> Change subject: userportal,webadmin: redesign of vm related dialogs
> ......................................................................
> 
> 
> Patch Set 5: (1 inline comment)
> 
> Code looks good.
> A few questions regarding the design:
> 1. Why do we want the static header only in VM dialog?
> 2. DC/Host are really relevant for all tabs?
> 3. Is it just a preparation for the final instance type dialog?
> 4. If it's indeed merely preparation, shouldn't it be merged only once we
> have the full picture of the new dialog?
> 
> ....................................................
> File
> frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> Line 21:
> Line 22: 		.header {
> Line 23: 			background-color: #D3D3D3;
> Line 24: 			border-bottom: 1px solid #CED8DF;
> Line 25: 			margin-bottom: 15px;
> is it supposed to be that large?
> Line 26: 			padding-top: 6px;
> Line 27: 			margin-top: 4px;
> Line 28: 			margin-right: 3px;
> Line 29: 			display: none;
> 
> 
> --
> To view, visit http://gerrit.ovirt.org/14635
> To unsubscribe, visit http://gerrit.ovirt.org/settings
> 
> Gerrit-MessageType: comment
> Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> Gerrit-PatchSet: 5
> Gerrit-Project: ovirt-engine
> Gerrit-Branch: master
> Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
> Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
> Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
> Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
> Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
> Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
> Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
> 


From derez at redhat.com  Tue May 28 22:18:20 2013
From: derez at redhat.com (Daniel Erez)
Date: Tue, 28 May 2013 18:18:20 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <70378615.13764765.1369778027447.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<201305282105.r4SL5ccM002657@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
Message-ID: <771394793.7670643.1369779500608.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim" <info at eldanet.com>, "Eldan Hildesheim" <ehildesh at redhat.com>
> Cc: "Tomas Jelinek" <tjelinek at redhat.com>, derez at redhat.com, "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, May 29, 2013 12:53:47 AM
> Subject: static header only in VM dialog?
> 
> when reviewing the code for the "redesign of vm related dialogs", Daniel has
> raised an interesting question: Why do we want the static header only in VM
> dialog?
> 
> (I assume that he refers to the top section of the New VM dialog as seen in
> [1], which
> contains the DC/Cluster, Quota, etc information, and is "static", i.e., it is
> always
> displayed, regardless of the selected side-tab within the dialog)
> 
> I agree with what Daniel is implying here: for consistency, we would probably
> want to
> introduce this static header to other dialogs, at least to the ones that also
> contain
> side-tabs in which it makes sense to turn the "header" to static
> [e.g.
> "New Host" (which contains a DC + Cluster "header") - see
> http://oi39.tinypic.com/2z84xnp.jpg,
> "New Cluster" (which contains a DC "header") - see
> http://oi40.tinypic.com/2vmyj2x.jpg]
> 
> [I assume, of course, that all the VM-like dialogs (e.g. New/Edit VM-Pool)
> will also have
> static headers - I don't know if the patch already takes care of that or not]
> 
> Thoughts?
> 
> [@Daniel - if you had something else in mind, and/or other dialogs in mind -
> please feel free
> to add/amend/etc]

Besides consistency matters, I wanted to understand what's the motivation of
keeping these widgets static. I.e. is it an essential preparation for the new
instance type dialog or a new concept for tab based dialogs
(as DC/Cluster values aren't necessarily relevant for each tab in the dialog)

> 
> ----
> Thanks,
> Einav
> 
> [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> 
> ----- Original Message -----
> > From: derez at redhat.com
> > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>,
> > "Frank Kobzik" <fkobzik at redhat.com>,
> > "Eldan Hildesheim" <info at eldanet.com>
> > Sent: Tuesday, May 28, 2013 5:05:38 PM
> > Subject: Change in ovirt-engine[master]: userportal,webadmin: redesign of
> > vm related dialogs
> > 
> > Daniel Erez has posted comments on this change.
> > 
> > Change subject: userportal,webadmin: redesign of vm related dialogs
> > ......................................................................
> > 
> > 
> > Patch Set 5: (1 inline comment)
> > 
> > Code looks good.
> > A few questions regarding the design:
> > 1. Why do we want the static header only in VM dialog?
> > 2. DC/Host are really relevant for all tabs?
> > 3. Is it just a preparation for the final instance type dialog?
> > 4. If it's indeed merely preparation, shouldn't it be merged only once we
> > have the full picture of the new dialog?
> > 
> > ....................................................
> > File
> > frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> > Line 21:
> > Line 22: 		.header {
> > Line 23: 			background-color: #D3D3D3;
> > Line 24: 			border-bottom: 1px solid #CED8DF;
> > Line 25: 			margin-bottom: 15px;
> > is it supposed to be that large?
> > Line 26: 			padding-top: 6px;
> > Line 27: 			margin-top: 4px;
> > Line 28: 			margin-right: 3px;
> > Line 29: 			display: none;
> > 
> > 
> > --
> > To view, visit http://gerrit.ovirt.org/14635
> > To unsubscribe, visit http://gerrit.ovirt.org/settings
> > 
> > Gerrit-MessageType: comment
> > Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> > Gerrit-PatchSet: 5
> > Gerrit-Project: ovirt-engine
> > Gerrit-Branch: master
> > Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
> > Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
> > Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
> > Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
> > Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
> > Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
> > Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
> > 
> 


From ecohen at redhat.com  Tue May 28 23:30:09 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Tue, 28 May 2013 19:30:09 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <771394793.7670643.1369779500608.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<201305282105.r4SL5ccM002657@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
	<771394793.7670643.1369779500608.JavaMail.root@redhat.com>
Message-ID: <1603402923.13784806.1369783809299.JavaMail.root@redhat.com>

> ----- Original Message -----
> From: "Daniel Erez" <derez at redhat.com>
> Sent: Tuesday, May 28, 2013 6:18:20 PM
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim" <info at eldanet.com>,
> > "Eldan Hildesheim" <ehildesh at redhat.com>
> > Cc: "Tomas Jelinek" <tjelinek at redhat.com>, derez at redhat.com, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Wednesday, May 29, 2013 12:53:47 AM
> > Subject: static header only in VM dialog?
> > 
> > when reviewing the code for the "redesign of vm related dialogs", Daniel
> > has
> > raised an interesting question: Why do we want the static header only in VM
> > dialog?
> > 
> > (I assume that he refers to the top section of the New VM dialog as seen in
> > [1], which
> > contains the DC/Cluster, Quota, etc information, and is "static", i.e., it
> > is
> > always
> > displayed, regardless of the selected side-tab within the dialog)
> > 
> > I agree with what Daniel is implying here: for consistency, we would
> > probably
> > want to
> > introduce this static header to other dialogs, at least to the ones that
> > also
> > contain
> > side-tabs in which it makes sense to turn the "header" to static
> > [e.g.
> > "New Host" (which contains a DC + Cluster "header") - see
> > http://oi39.tinypic.com/2z84xnp.jpg,
> > "New Cluster" (which contains a DC "header") - see
> > http://oi40.tinypic.com/2vmyj2x.jpg]
> > 
> > [I assume, of course, that all the VM-like dialogs (e.g. New/Edit VM-Pool)
> > will also have
> > static headers - I don't know if the patch already takes care of that or
> > not]
> > 
> > Thoughts?
> > 
> > [@Daniel - if you had something else in mind, and/or other dialogs in mind
> > -
> > please feel free
> > to add/amend/etc]
> 
> Besides consistency matters, I wanted to understand what's the motivation of
> keeping these widgets static. I.e. is it an essential preparation for the new
> instance type dialog or a new concept for tab based dialogs
> (as DC/Cluster values aren't necessarily relevant for each tab in the dialog)

[maybe Tomas/Eldan/Malini can help here as well]

these static widgets (as well as the type ahead list box [1], for example) are part of 
the instance types feature that had its design details published in [2] and [3], and the 
implementation was done according to this design. I don't see any reason to not utilize 
this newly-introduced concept in other side-tab-based dialogs as well, if it makes sense 
(ui consistency considerations are sufficient, IMO, but I could be wrong - maybe it is 
relevant/correct to introduce this new concept only in the VM-like dialogs).

regarding the specific concern about the DC/Cluster values that aren't necessarily relevant 
for each side-tab in the dialog: I agree with that statement, however:

- putting the "Instance Type" drop-down at the top static section is very useful (see [4] 
for explanation), and as the Instance Types list is derived from the selected DC, it makes 
sense (to me) to put the DC in that top static section as well.

- the DC/Cluster are relevant for some of the tabs in the dialog (Host, Resource Allocation?) 
so for consistency-within-the-dialog considerations, it is probably a good idea to simply 
always show these fields within this top static section.

[there is a good chance that I am missing your point here - please correct me if necessary]

[1] http://gerrit.ovirt.org/#/c/14936/

[2] http://www.ovirt.org/Features/Instance_Types

[3] http://www.ovirt.org/images/9/9e/Instance_type.pdf

[4] whenever changing the "Instance Type" value, you can automatically see how these changes 
affect the fields in the current tab on which you are standing (e.g. if you are standing on 
the "System" side-tab, you can change the "Instance Type" selected item and immediately see 
the changes within the "System" side-tab contents), and vice-versa: if you are changing a value 
that was originally propagated from the instance-type, you will see the instance-type automatically 
change to "custom"/"not applicable" as a result, so no need to "jump" between side-tabs in order 
to observe these changes.

> 
> > 
> > ----
> > Thanks,
> > Einav
> > 
> > [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> > 
> > ----- Original Message -----
> > > From: derez at redhat.com
> > > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> > > <ecohen at redhat.com>,
> > > "Frank Kobzik" <fkobzik at redhat.com>,
> > > "Eldan Hildesheim" <info at eldanet.com>
> > > Sent: Tuesday, May 28, 2013 5:05:38 PM
> > > Subject: Change in ovirt-engine[master]: userportal,webadmin: redesign of
> > > vm related dialogs
> > > 
> > > Daniel Erez has posted comments on this change.
> > > 
> > > Change subject: userportal,webadmin: redesign of vm related dialogs
> > > ......................................................................
> > > 
> > > 
> > > Patch Set 5: (1 inline comment)
> > > 
> > > Code looks good.
> > > A few questions regarding the design:
> > > 1. Why do we want the static header only in VM dialog?
> > > 2. DC/Host are really relevant for all tabs?
> > > 3. Is it just a preparation for the final instance type dialog?
> > > 4. If it's indeed merely preparation, shouldn't it be merged only once we
> > > have the full picture of the new dialog?
> > > 
> > > ....................................................
> > > File
> > > frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> > > Line 21:
> > > Line 22: 		.header {
> > > Line 23: 			background-color: #D3D3D3;
> > > Line 24: 			border-bottom: 1px solid #CED8DF;
> > > Line 25: 			margin-bottom: 15px;
> > > is it supposed to be that large?
> > > Line 26: 			padding-top: 6px;
> > > Line 27: 			margin-top: 4px;
> > > Line 28: 			margin-right: 3px;
> > > Line 29: 			display: none;
> > > 
> > > 
> > > --
> > > To view, visit http://gerrit.ovirt.org/14635
> > > To unsubscribe, visit http://gerrit.ovirt.org/settings
> > > 
> > > Gerrit-MessageType: comment
> > > Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> > > Gerrit-PatchSet: 5
> > > Gerrit-Project: ovirt-engine
> > > Gerrit-Branch: master
> > > Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
> > > Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
> > > Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
> > > Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
> > > Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
> > > Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
> > > Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
> > > 
> > 
> 


From lhornyak at redhat.com  Wed May 29 00:23:12 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 28 May 2013 20:23:12 -0400 (EDT)
Subject: [Engine-devel] oVirt Scheduler API Design
In-Reply-To: <466692572.7422131.1369751651486.JavaMail.root@redhat.com>
References: <466692572.7422131.1369751651486.JavaMail.root@redhat.com>
Message-ID: <1200340601.7384760.1369786992961.JavaMail.root@redhat.com>

Hi Gilad,

Some questions to start the discussion :)
External scheduler API:
 - Why are you mixing xml into json?
 - I am missing from the documentation how the external scheduler can communicate to the engine

Thx,
Laszlo

----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, May 28, 2013 4:34:11 PM
> Subject: [Engine-devel] oVirt Scheduler API Design
> 
> Hi all,
> 
> Attached links for oVirt Scheduler API design wiki page.
> 
> High level overview: http://www.ovirt.org/Features/oVirtScheduler
> Detailed design: http://www.ovirt.org/Features/oVirtSchedulerAPI
> 
> You are more than welcome to share you thoughts.
> 
> Thanks,
> Gilad.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From derez at redhat.com  Wed May 29 05:36:03 2013
From: derez at redhat.com (Daniel Erez)
Date: Wed, 29 May 2013 01:36:03 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<201305282105.r4SL5ccM002657@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
	<771394793.7670643.1369779500608.JavaMail.root@redhat.com>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
Message-ID: <559238979.7794816.1369805763901.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim" <info at eldanet.com>, "Eldan
> Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, May 29, 2013 2:30:09 AM
> Subject: Re: static header only in VM dialog?
> 
> > ----- Original Message -----
> > From: "Daniel Erez" <derez at redhat.com>
> > Sent: Tuesday, May 28, 2013 6:18:20 PM
> > 
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
> > > <info at eldanet.com>,
> > > "Eldan Hildesheim" <ehildesh at redhat.com>
> > > Cc: "Tomas Jelinek" <tjelinek at redhat.com>, derez at redhat.com,
> > > "engine-devel"
> > > <engine-devel at ovirt.org>
> > > Sent: Wednesday, May 29, 2013 12:53:47 AM
> > > Subject: static header only in VM dialog?
> > > 
> > > when reviewing the code for the "redesign of vm related dialogs", Daniel
> > > has
> > > raised an interesting question: Why do we want the static header only in
> > > VM
> > > dialog?
> > > 
> > > (I assume that he refers to the top section of the New VM dialog as seen
> > > in
> > > [1], which
> > > contains the DC/Cluster, Quota, etc information, and is "static", i.e.,
> > > it
> > > is
> > > always
> > > displayed, regardless of the selected side-tab within the dialog)
> > > 
> > > I agree with what Daniel is implying here: for consistency, we would
> > > probably
> > > want to
> > > introduce this static header to other dialogs, at least to the ones that
> > > also
> > > contain
> > > side-tabs in which it makes sense to turn the "header" to static
> > > [e.g.
> > > "New Host" (which contains a DC + Cluster "header") - see
> > > http://oi39.tinypic.com/2z84xnp.jpg,
> > > "New Cluster" (which contains a DC "header") - see
> > > http://oi40.tinypic.com/2vmyj2x.jpg]
> > > 
> > > [I assume, of course, that all the VM-like dialogs (e.g. New/Edit
> > > VM-Pool)
> > > will also have
> > > static headers - I don't know if the patch already takes care of that or
> > > not]
> > > 
> > > Thoughts?
> > > 
> > > [@Daniel - if you had something else in mind, and/or other dialogs in
> > > mind
> > > -
> > > please feel free
> > > to add/amend/etc]
> > 
> > Besides consistency matters, I wanted to understand what's the motivation
> > of
> > keeping these widgets static. I.e. is it an essential preparation for the
> > new
> > instance type dialog or a new concept for tab based dialogs
> > (as DC/Cluster values aren't necessarily relevant for each tab in the
> > dialog)
> 
> [maybe Tomas/Eldan/Malini can help here as well]
> 
> these static widgets (as well as the type ahead list box [1], for example)
> are part of
> the instance types feature that had its design details published in [2] and
> [3], and the
> implementation was done according to this design. I don't see any reason to
> not utilize
> this newly-introduced concept in other side-tab-based dialogs as well, if it
> makes sense
> (ui consistency considerations are sufficient, IMO, but I could be wrong -
> maybe it is
> relevant/correct to introduce this new concept only in the VM-like dialogs).
> 
> regarding the specific concern about the DC/Cluster values that aren't
> necessarily relevant
> for each side-tab in the dialog: I agree with that statement, however:
> 
> - putting the "Instance Type" drop-down at the top static section is very
> useful (see [4]
> for explanation), and as the Instance Types list is derived from the selected
> DC, it makes
> sense (to me) to put the DC in that top static section as well.
> 
> - the DC/Cluster are relevant for some of the tabs in the dialog (Host,
> Resource Allocation?)

Only for Host.
Resource Allocation is directly affected by the selected template.
Therefore, it sounds very confusing to me...
Unless we add template to the static header as well?
(which will be odd for the other tabs).

So I still don't get the motivation UX-wise.
E.g. it seems really weird to change the entire DC from Console tab
(or, as a matter of fact, from most other tabs).
In the new instance type dialog, which tabs could be directly affected by DC/Cluster?
IIUC, only Host? Do we really need a static header just for this tab?

> so for consistency-within-the-dialog considerations, it is probably a good
> idea to simply
> always show these fields within this top static section.
> 
> [there is a good chance that I am missing your point here - please correct me
> if necessary]
> 
> [1] http://gerrit.ovirt.org/#/c/14936/
> 
> [2] http://www.ovirt.org/Features/Instance_Types
> 
> [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> 
> [4] whenever changing the "Instance Type" value, you can automatically see
> how these changes
> affect the fields in the current tab on which you are standing (e.g. if you
> are standing on
> the "System" side-tab, you can change the "Instance Type" selected item and
> immediately see
> the changes within the "System" side-tab contents), and vice-versa: if you
> are changing a value
> that was originally propagated from the instance-type, you will see the
> instance-type automatically
> change to "custom"/"not applicable" as a result, so no need to "jump" between
> side-tabs in order
> to observe these changes.
> 
> > 
> > > 
> > > ----
> > > Thanks,
> > > Einav
> > > 
> > > [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> > > 
> > > ----- Original Message -----
> > > > From: derez at redhat.com
> > > > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> > > > <ecohen at redhat.com>,
> > > > "Frank Kobzik" <fkobzik at redhat.com>,
> > > > "Eldan Hildesheim" <info at eldanet.com>
> > > > Sent: Tuesday, May 28, 2013 5:05:38 PM
> > > > Subject: Change in ovirt-engine[master]: userportal,webadmin: redesign
> > > > of
> > > > vm related dialogs
> > > > 
> > > > Daniel Erez has posted comments on this change.
> > > > 
> > > > Change subject: userportal,webadmin: redesign of vm related dialogs
> > > > ......................................................................
> > > > 
> > > > 
> > > > Patch Set 5: (1 inline comment)
> > > > 
> > > > Code looks good.
> > > > A few questions regarding the design:
> > > > 1. Why do we want the static header only in VM dialog?
> > > > 2. DC/Host are really relevant for all tabs?
> > > > 3. Is it just a preparation for the final instance type dialog?
> > > > 4. If it's indeed merely preparation, shouldn't it be merged only once
> > > > we
> > > > have the full picture of the new dialog?
> > > > 
> > > > ....................................................
> > > > File
> > > > frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> > > > Line 21:
> > > > Line 22: 		.header {
> > > > Line 23: 			background-color: #D3D3D3;
> > > > Line 24: 			border-bottom: 1px solid #CED8DF;
> > > > Line 25: 			margin-bottom: 15px;
> > > > is it supposed to be that large?
> > > > Line 26: 			padding-top: 6px;
> > > > Line 27: 			margin-top: 4px;
> > > > Line 28: 			margin-right: 3px;
> > > > Line 29: 			display: none;
> > > > 
> > > > 
> > > > --
> > > > To view, visit http://gerrit.ovirt.org/14635
> > > > To unsubscribe, visit http://gerrit.ovirt.org/settings
> > > > 
> > > > Gerrit-MessageType: comment
> > > > Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> > > > Gerrit-PatchSet: 5
> > > > Gerrit-Project: ovirt-engine
> > > > Gerrit-Branch: master
> > > > Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
> > > > Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
> > > > Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
> > > > Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
> > > > Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
> > > > Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
> > > > Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
> > > > 
> > > 
> > 
> 


From omasad at redhat.com  Wed May 29 06:46:40 2013
From: omasad at redhat.com (Ofri Masad)
Date: Wed, 29 May 2013 02:46:40 -0400 (EDT)
Subject: [Engine-devel] oVirt Scheduler API Design
In-Reply-To: <1200340601.7384760.1369786992961.JavaMail.root@redhat.com>
References: <466692572.7422131.1369751651486.JavaMail.root@redhat.com>
	<1200340601.7384760.1369786992961.JavaMail.root@redhat.com>
Message-ID: <1660806754.4952252.1369810000755.JavaMail.root@redhat.com>

Hi Gilad,

two questions about the 'balance' api.
1. do we filter out all VMs which cannot be migrated before passing the list to the 'balance' method? otherwise, the user-implemented code may select a VM which cannot be migrated for some reason.
2. do we make sure that the user-implemented 'balance' method do not select the same VM over and over again? if the 'balance' selects a non-migrateable VM (like described in 1 above) the VM will not migrate and the exact same input will be passed again. (infinite loop)

thanks
Ofri  

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, May 29, 2013 3:23:12 AM
> Subject: Re: [Engine-devel] oVirt Scheduler API Design
> 
> Hi Gilad,
> 
> Some questions to start the discussion :)
> External scheduler API:
>  - Why are you mixing xml into json?
>  - I am missing from the documentation how the external scheduler can
>  communicate to the engine
> 
> Thx,
> Laszlo
> 
> ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, May 28, 2013 4:34:11 PM
> > Subject: [Engine-devel] oVirt Scheduler API Design
> > 
> > Hi all,
> > 
> > Attached links for oVirt Scheduler API design wiki page.
> > 
> > High level overview: http://www.ovirt.org/Features/oVirtScheduler
> > Detailed design: http://www.ovirt.org/Features/oVirtSchedulerAPI
> > 
> > You are more than welcome to share you thoughts.
> > 
> > Thanks,
> > Gilad.
> > _______________________________________________
> > 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 tjelinek at redhat.com  Wed May 29 07:03:00 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Wed, 29 May 2013 03:03:00 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <559238979.7794816.1369805763901.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<201305282105.r4SL5ccM002657@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
	<771394793.7670643.1369779500608.JavaMail.root@redhat.com>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
Message-ID: <1553759855.10414070.1369810980370.JavaMail.root@redhat.com>

just sending to a bigger group to cover all people which were part of the decision process to not make them surprised if we will change it :)

@Itamar, Andrew, Michal: just quickly summarize this thread:
Daniel have started to review the instance types related patches and has two concerns about the static header containing DC, Cluster etc.:
1: does not see the point of showing DC, Cluster etc for most of the side tabs (e.g. console)
2: if there is indeed a point, why not change all the dialogs with side tabs to have the static header e.g. new cluster. (please note that the currently
   reviewed patch implements this static header to all VM related dialogs like pool,template,vm)

regards,
Tomas 

PS: I don't know if any of you have seen my comments on rhev-dep about having the reviewer assigned from the beginning, but imagine how
awesome it would be having Daniel on our instance types meetings from the beginning, making him the part of the feature and having this 
questions already discussed, so by now he would be perfectly comfortable with the design, understand the motivation and agreed with it, 
so now he would only review the specific implementation (while he would already know my important code-design decisions and be part of them).
Don't get me wrong Daniel, I find your concerns extremely valid and worth discussing and thank you for rising them!

----- Original Message -----
> From: "Daniel Erez" <derez at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim" <info at eldanet.com>, "Eldan Hildesheim" <ehildesh at redhat.com>,
> "Tomas Jelinek" <tjelinek at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, May 29, 2013 7:36:03 AM
> Subject: Re: static header only in VM dialog?
> 
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>,
> > "Eldan Hildesheim" <info at eldanet.com>, "Eldan
> > Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, May 29, 2013 2:30:09 AM
> > Subject: Re: static header only in VM dialog?
> > 
> > > ----- Original Message -----
> > > From: "Daniel Erez" <derez at redhat.com>
> > > Sent: Tuesday, May 28, 2013 6:18:20 PM
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
> > > > <info at eldanet.com>,
> > > > "Eldan Hildesheim" <ehildesh at redhat.com>
> > > > Cc: "Tomas Jelinek" <tjelinek at redhat.com>, derez at redhat.com,
> > > > "engine-devel"
> > > > <engine-devel at ovirt.org>
> > > > Sent: Wednesday, May 29, 2013 12:53:47 AM
> > > > Subject: static header only in VM dialog?
> > > > 
> > > > when reviewing the code for the "redesign of vm related dialogs",
> > > > Daniel
> > > > has
> > > > raised an interesting question: Why do we want the static header only
> > > > in
> > > > VM
> > > > dialog?
> > > > 
> > > > (I assume that he refers to the top section of the New VM dialog as
> > > > seen
> > > > in
> > > > [1], which
> > > > contains the DC/Cluster, Quota, etc information, and is "static", i.e.,
> > > > it
> > > > is
> > > > always
> > > > displayed, regardless of the selected side-tab within the dialog)
> > > > 
> > > > I agree with what Daniel is implying here: for consistency, we would
> > > > probably
> > > > want to
> > > > introduce this static header to other dialogs, at least to the ones
> > > > that
> > > > also
> > > > contain
> > > > side-tabs in which it makes sense to turn the "header" to static
> > > > [e.g.
> > > > "New Host" (which contains a DC + Cluster "header") - see
> > > > http://oi39.tinypic.com/2z84xnp.jpg,
> > > > "New Cluster" (which contains a DC "header") - see
> > > > http://oi40.tinypic.com/2vmyj2x.jpg]
> > > > 
> > > > [I assume, of course, that all the VM-like dialogs (e.g. New/Edit
> > > > VM-Pool)
> > > > will also have
> > > > static headers - I don't know if the patch already takes care of that
> > > > or
> > > > not]
> > > > 
> > > > Thoughts?
> > > > 
> > > > [@Daniel - if you had something else in mind, and/or other dialogs in
> > > > mind
> > > > -
> > > > please feel free
> > > > to add/amend/etc]
> > > 
> > > Besides consistency matters, I wanted to understand what's the motivation
> > > of
> > > keeping these widgets static. I.e. is it an essential preparation for the
> > > new
> > > instance type dialog or a new concept for tab based dialogs
> > > (as DC/Cluster values aren't necessarily relevant for each tab in the
> > > dialog)
> > 
> > [maybe Tomas/Eldan/Malini can help here as well]
> > 
> > these static widgets (as well as the type ahead list box [1], for example)
> > are part of
> > the instance types feature that had its design details published in [2] and
> > [3], and the
> > implementation was done according to this design. I don't see any reason to
> > not utilize
> > this newly-introduced concept in other side-tab-based dialogs as well, if
> > it
> > makes sense
> > (ui consistency considerations are sufficient, IMO, but I could be wrong -
> > maybe it is
> > relevant/correct to introduce this new concept only in the VM-like
> > dialogs).
> > 
> > regarding the specific concern about the DC/Cluster values that aren't
> > necessarily relevant
> > for each side-tab in the dialog: I agree with that statement, however:
> > 
> > - putting the "Instance Type" drop-down at the top static section is very
> > useful (see [4]
> > for explanation), and as the Instance Types list is derived from the
> > selected
> > DC, it makes
> > sense (to me) to put the DC in that top static section as well.
> > 
> > - the DC/Cluster are relevant for some of the tabs in the dialog (Host,
> > Resource Allocation?)
> 
> Only for Host.
> Resource Allocation is directly affected by the selected template.
> Therefore, it sounds very confusing to me...
> Unless we add template to the static header as well?
> (which will be odd for the other tabs).
> 
> So I still don't get the motivation UX-wise.
> E.g. it seems really weird to change the entire DC from Console tab
> (or, as a matter of fact, from most other tabs).
> In the new instance type dialog, which tabs could be directly affected by
> DC/Cluster?
> IIUC, only Host? Do we really need a static header just for this tab?
> 
> > so for consistency-within-the-dialog considerations, it is probably a good
> > idea to simply
> > always show these fields within this top static section.
> > 
> > [there is a good chance that I am missing your point here - please correct
> > me
> > if necessary]
> > 
> > [1] http://gerrit.ovirt.org/#/c/14936/
> > 
> > [2] http://www.ovirt.org/Features/Instance_Types
> > 
> > [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> > 
> > [4] whenever changing the "Instance Type" value, you can automatically see
> > how these changes
> > affect the fields in the current tab on which you are standing (e.g. if you
> > are standing on
> > the "System" side-tab, you can change the "Instance Type" selected item and
> > immediately see
> > the changes within the "System" side-tab contents), and vice-versa: if you
> > are changing a value
> > that was originally propagated from the instance-type, you will see the
> > instance-type automatically
> > change to "custom"/"not applicable" as a result, so no need to "jump"
> > between
> > side-tabs in order
> > to observe these changes.
> > 
> > > 
> > > > 
> > > > ----
> > > > Thanks,
> > > > Einav
> > > > 
> > > > [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> > > > 
> > > > ----- Original Message -----
> > > > > From: derez at redhat.com
> > > > > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > > > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> > > > > <ecohen at redhat.com>,
> > > > > "Frank Kobzik" <fkobzik at redhat.com>,
> > > > > "Eldan Hildesheim" <info at eldanet.com>
> > > > > Sent: Tuesday, May 28, 2013 5:05:38 PM
> > > > > Subject: Change in ovirt-engine[master]: userportal,webadmin:
> > > > > redesign
> > > > > of
> > > > > vm related dialogs
> > > > > 
> > > > > Daniel Erez has posted comments on this change.
> > > > > 
> > > > > Change subject: userportal,webadmin: redesign of vm related dialogs
> > > > > ......................................................................
> > > > > 
> > > > > 
> > > > > Patch Set 5: (1 inline comment)
> > > > > 
> > > > > Code looks good.
> > > > > A few questions regarding the design:
> > > > > 1. Why do we want the static header only in VM dialog?
> > > > > 2. DC/Host are really relevant for all tabs?
> > > > > 3. Is it just a preparation for the final instance type dialog?
> > > > > 4. If it's indeed merely preparation, shouldn't it be merged only
> > > > > once
> > > > > we
> > > > > have the full picture of the new dialog?
> > > > > 
> > > > > ....................................................
> > > > > File
> > > > > frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> > > > > Line 21:
> > > > > Line 22: 		.header {
> > > > > Line 23: 			background-color: #D3D3D3;
> > > > > Line 24: 			border-bottom: 1px solid #CED8DF;
> > > > > Line 25: 			margin-bottom: 15px;
> > > > > is it supposed to be that large?
> > > > > Line 26: 			padding-top: 6px;
> > > > > Line 27: 			margin-top: 4px;
> > > > > Line 28: 			margin-right: 3px;
> > > > > Line 29: 			display: none;
> > > > > 
> > > > > 
> > > > > --
> > > > > To view, visit http://gerrit.ovirt.org/14635
> > > > > To unsubscribe, visit http://gerrit.ovirt.org/settings
> > > > > 
> > > > > Gerrit-MessageType: comment
> > > > > Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> > > > > Gerrit-PatchSet: 5
> > > > > Gerrit-Project: ovirt-engine
> > > > > Gerrit-Branch: master
> > > > > Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
> > > > > Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
> > > > > Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
> > > > > Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
> > > > > Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
> > > > > Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
> > > > > Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
> > > > > 
> > > > 
> > > 
> > 
> 


From dneary at redhat.com  Wed May 29 07:43:48 2013
From: dneary at redhat.com (Dave Neary)
Date: Wed, 29 May 2013 09:43:48 +0200
Subject: [Engine-devel] Regarding access to ovirt.org for creating
 feature pages
In-Reply-To: <51A306C6.6010100@redhat.com>
References: <51A306C6.6010100@redhat.com>
Message-ID: <51A5B1B4.6090008@redhat.com>

Hi Shubhendu,

Are you sorted now? Your user account is created, so you should be able
to create pages.

Thanks,
Dave.

On 05/27/2013 09:09 AM, Shubhendu Tripathi wrote:
> Hi All,
> 
> I have joined RedHat this month and work with RHSC team.
> I need to create a feature page on Ovirt WIKI, and so raised a request
> for the same to get an id created.
> 
> I have not received any confirmation till now.
> Kindly let me know if something is missing or I need to follow some
> other process.
> 
> ID Created: shtripat
> Email Id: shtripat at redhat.com
> 
> Thanks and Regards,
> Shubhendu Tripathi
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From dneary at redhat.com  Wed May 29 07:55:30 2013
From: dneary at redhat.com (Dave Neary)
Date: Wed, 29 May 2013 09:55:30 +0200
Subject: [Engine-devel] [3.3 release process] feature freeze readiness
In-Reply-To: <51A4B8A7.4070809@redhat.com>
References: <519DF477.9000300@redhat.com> <51A4B8A7.4070809@redhat.com>
Message-ID: <51A5B472.3030509@redhat.com>

Hi,

On 05/28/2013 04:01 PM, Moran Goldboim wrote:
> Thanks for everyone who updated their status on the table.
> Still there are missing features around virt, infra, storage and sla,
> please complete statuses on this missing features today so we can attend
> to understand the release status tomorrow's meeting.

The features still missing a status and owner are:

* GlusterFS Storage Domain
* Allow resign/force re-election of SPM

Also, a number of features have not set a release priority - especially
for red and orange features, we need to know whether the feature is
considered "must"/"should"/"optional" for 3.3, because those are the
ones that will end up delaying a release.

* RAM snapshots
* noVNC console
* Non Plugin RDP Invocation
* Instance Types

After that, we can start looking at red flag features to help set the
release date.

A few things jumped out at me:

== Red features marked as Must

For each of these, we need an estimate of how long the feature will take
to complete - these will almost certainly delay the release.

* Multiple Gateways
* Edit Connection Properties
* oVirt scheduler
* Scheduling API
* Networking QoS

Next priority is the orange musts - one in particular jumps out at me:
"Watchdog engine support" has a comment "REST API missing" - which
sounds ominous.

Thanks to everyone for filling this out! And thanks to Moran for taking
the lead on this, it's very useful.

Cheers,
Dave.
-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From gchaplik at redhat.com  Wed May 29 08:26:40 2013
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Wed, 29 May 2013 04:26:40 -0400 (EDT)
Subject: [Engine-devel] oVirt Scheduler API Design
In-Reply-To: <1660806754.4952252.1369810000755.JavaMail.root@redhat.com>
References: <466692572.7422131.1369751651486.JavaMail.root@redhat.com>
	<1200340601.7384760.1369786992961.JavaMail.root@redhat.com>
	<1660806754.4952252.1369810000755.JavaMail.root@redhat.com>
Message-ID: <288520236.7860929.1369816000707.JavaMail.root@redhat.com>

inline.

----- Original Message -----
> From: "Ofri Masad" <omasad at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, May 29, 2013 9:46:40 AM
> Subject: Re: [Engine-devel] oVirt Scheduler API Design
> 
> Hi Gilad,
> 
> two questions about the 'balance' api.
> 1. do we filter out all VMs which cannot be migrated before passing the list
> to the 'balance' method? otherwise, the user-implemented code may select a
> VM which cannot be migrated for some reason.
> 2. do we make sure that the user-implemented 'balance' method do not select
> the same VM over and over again? if the 'balance' selects a non-migrateable
> VM (like described in 1 above) the VM will not migrate and the exact same
> input will be passed again. (infinite loop)

hi Ofri, 
the answer is no for both questions.
balance is a periodic task that oVirt (we) use for VM balancing, the user can use it for all other actions exposed by the REST and not even use our mechanism (return VM=null), having said that I don't think we should make the api more complicated only because we want the user to work like us.
so yes the user is responsible to prevent loops and not selecting non-migratable vms.

> 
> thanks
> Ofri
> 
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, May 29, 2013 3:23:12 AM
> > Subject: Re: [Engine-devel] oVirt Scheduler API Design
> > 
> > Hi Gilad,
> > 
> > Some questions to start the discussion :)
> > External scheduler API:
> >  - Why are you mixing xml into json?

JSON is preferable. I use xml because the ovirt-python-sdk supports xml->python conversion, and when it'll support JSON we'll use that.


> >  - I am missing from the documentation how the external scheduler can
> >  communicate to the engine

XML-RPC
I think it's written there (somewhere :))

> > 
> > Thx,
> > Laszlo
> > 
> > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, May 28, 2013 4:34:11 PM
> > > Subject: [Engine-devel] oVirt Scheduler API Design
> > > 
> > > Hi all,
> > > 
> > > Attached links for oVirt Scheduler API design wiki page.
> > > 
> > > High level overview: http://www.ovirt.org/Features/oVirtScheduler
> > > Detailed design: http://www.ovirt.org/Features/oVirtSchedulerAPI
> > > 
> > > You are more than welcome to share you thoughts.
> > > 
> > > Thanks,
> > > Gilad.
> > > _______________________________________________
> > > 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  Wed May 29 09:12:33 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 29 May 2013 12:12:33 +0300
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <1553759855.10414070.1369810980370.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<201305282105.r4SL5ccM002657@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
	<771394793.7670643.1369779500608.JavaMail.root@redhat.com>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
	<1553759855.10414070.1369810980370.JavaMail.root@redhat.com>
Message-ID: <51A5C681.6040503@redhat.com>

On 05/29/2013 10:03 AM, Tomas Jelinek wrote:
..

> Daniel have started to review the instance types related patches and has two concerns about the static header containing DC, Cluster etc.:
> 1: does not see the point of showing DC, Cluster etc for most of the side tabs (e.g. console)
> 2: if there is indeed a point, why not change all the dialogs with side tabs to have the static header e.g. new cluster. (please note that the currently
>     reviewed patch implements this static header to all VM related dialogs like pool,template,vm)

may make sense to review for other dialogs as well. not sure all of them 
have the same concept of multiple fields affected by the instance type 
in various panes though.

...
> having Daniel on our instance types meetings from the beginning, making him the part of the feature and having this
> questions already discussed, so by now he would be perfectly comfortable with the design, understand the motivation and agreed with it,
> so now he would only review the specific implementation (while he would already know my important code-design decisions and be part of them).
> Don't get me wrong Daniel, I find your concerns extremely valid and worth discussing and thank you for rising them!

since there was a feature page, and some discussions on engine-devel 
around this, maybe considering the aspects of the change, would have 
been worth while sending to arch@ an invite to review it more thoroughly 
at concept level (not all features need this prior to patch level, but 
big ones/conceptual ones need them)

>
> ----- Original Message -----
>> From: "Daniel Erez" <derez at redhat.com>
>> To: "Einav Cohen" <ecohen at redhat.com>
>> Cc: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim" <info at eldanet.com>, "Eldan Hildesheim" <ehildesh at redhat.com>,
>> "Tomas Jelinek" <tjelinek at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Wednesday, May 29, 2013 7:36:03 AM
>> Subject: Re: static header only in VM dialog?
>>
>>
>>
>> ----- Original Message -----
>>> From: "Einav Cohen" <ecohen at redhat.com>
>>> To: "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>,
>>> "Eldan Hildesheim" <info at eldanet.com>, "Eldan
>>> Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Wednesday, May 29, 2013 2:30:09 AM
>>> Subject: Re: static header only in VM dialog?
>>>
>>>> ----- Original Message -----
>>>> From: "Daniel Erez" <derez at redhat.com>
>>>> Sent: Tuesday, May 28, 2013 6:18:20 PM
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Einav Cohen" <ecohen at redhat.com>
>>>>> To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
>>>>> <info at eldanet.com>,
>>>>> "Eldan Hildesheim" <ehildesh at redhat.com>
>>>>> Cc: "Tomas Jelinek" <tjelinek at redhat.com>, derez at redhat.com,
>>>>> "engine-devel"
>>>>> <engine-devel at ovirt.org>
>>>>> Sent: Wednesday, May 29, 2013 12:53:47 AM
>>>>> Subject: static header only in VM dialog?
>>>>>
>>>>> when reviewing the code for the "redesign of vm related dialogs",
>>>>> Daniel
>>>>> has
>>>>> raised an interesting question: Why do we want the static header only
>>>>> in
>>>>> VM
>>>>> dialog?
>>>>>
>>>>> (I assume that he refers to the top section of the New VM dialog as
>>>>> seen
>>>>> in
>>>>> [1], which
>>>>> contains the DC/Cluster, Quota, etc information, and is "static", i.e.,
>>>>> it
>>>>> is
>>>>> always
>>>>> displayed, regardless of the selected side-tab within the dialog)
>>>>>
>>>>> I agree with what Daniel is implying here: for consistency, we would
>>>>> probably
>>>>> want to
>>>>> introduce this static header to other dialogs, at least to the ones
>>>>> that
>>>>> also
>>>>> contain
>>>>> side-tabs in which it makes sense to turn the "header" to static
>>>>> [e.g.
>>>>> "New Host" (which contains a DC + Cluster "header") - see
>>>>> http://oi39.tinypic.com/2z84xnp.jpg,
>>>>> "New Cluster" (which contains a DC "header") - see
>>>>> http://oi40.tinypic.com/2vmyj2x.jpg]
>>>>>
>>>>> [I assume, of course, that all the VM-like dialogs (e.g. New/Edit
>>>>> VM-Pool)
>>>>> will also have
>>>>> static headers - I don't know if the patch already takes care of that
>>>>> or
>>>>> not]
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> [@Daniel - if you had something else in mind, and/or other dialogs in
>>>>> mind
>>>>> -
>>>>> please feel free
>>>>> to add/amend/etc]
>>>>
>>>> Besides consistency matters, I wanted to understand what's the motivation
>>>> of
>>>> keeping these widgets static. I.e. is it an essential preparation for the
>>>> new
>>>> instance type dialog or a new concept for tab based dialogs
>>>> (as DC/Cluster values aren't necessarily relevant for each tab in the
>>>> dialog)
>>>
>>> [maybe Tomas/Eldan/Malini can help here as well]
>>>
>>> these static widgets (as well as the type ahead list box [1], for example)
>>> are part of
>>> the instance types feature that had its design details published in [2] and
>>> [3], and the
>>> implementation was done according to this design. I don't see any reason to
>>> not utilize
>>> this newly-introduced concept in other side-tab-based dialogs as well, if
>>> it
>>> makes sense
>>> (ui consistency considerations are sufficient, IMO, but I could be wrong -
>>> maybe it is
>>> relevant/correct to introduce this new concept only in the VM-like
>>> dialogs).
>>>
>>> regarding the specific concern about the DC/Cluster values that aren't
>>> necessarily relevant
>>> for each side-tab in the dialog: I agree with that statement, however:
>>>
>>> - putting the "Instance Type" drop-down at the top static section is very
>>> useful (see [4]
>>> for explanation), and as the Instance Types list is derived from the
>>> selected
>>> DC, it makes
>>> sense (to me) to put the DC in that top static section as well.
>>>
>>> - the DC/Cluster are relevant for some of the tabs in the dialog (Host,
>>> Resource Allocation?)
>>
>> Only for Host.
>> Resource Allocation is directly affected by the selected template.
>> Therefore, it sounds very confusing to me...
>> Unless we add template to the static header as well?
>> (which will be odd for the other tabs).
>>
>> So I still don't get the motivation UX-wise.
>> E.g. it seems really weird to change the entire DC from Console tab
>> (or, as a matter of fact, from most other tabs).
>> In the new instance type dialog, which tabs could be directly affected by
>> DC/Cluster?
>> IIUC, only Host? Do we really need a static header just for this tab?
>>
>>> so for consistency-within-the-dialog considerations, it is probably a good
>>> idea to simply
>>> always show these fields within this top static section.
>>>
>>> [there is a good chance that I am missing your point here - please correct
>>> me
>>> if necessary]
>>>
>>> [1] http://gerrit.ovirt.org/#/c/14936/
>>>
>>> [2] http://www.ovirt.org/Features/Instance_Types
>>>
>>> [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
>>>
>>> [4] whenever changing the "Instance Type" value, you can automatically see
>>> how these changes
>>> affect the fields in the current tab on which you are standing (e.g. if you
>>> are standing on
>>> the "System" side-tab, you can change the "Instance Type" selected item and
>>> immediately see
>>> the changes within the "System" side-tab contents), and vice-versa: if you
>>> are changing a value
>>> that was originally propagated from the instance-type, you will see the
>>> instance-type automatically
>>> change to "custom"/"not applicable" as a result, so no need to "jump"
>>> between
>>> side-tabs in order
>>> to observe these changes.
>>>
>>>>
>>>>>
>>>>> ----
>>>>> Thanks,
>>>>> Einav
>>>>>
>>>>> [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: derez at redhat.com
>>>>>> To: "Tomas Jelinek" <tjelinek at redhat.com>
>>>>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
>>>>>> <ecohen at redhat.com>,
>>>>>> "Frank Kobzik" <fkobzik at redhat.com>,
>>>>>> "Eldan Hildesheim" <info at eldanet.com>
>>>>>> Sent: Tuesday, May 28, 2013 5:05:38 PM
>>>>>> Subject: Change in ovirt-engine[master]: userportal,webadmin:
>>>>>> redesign
>>>>>> of
>>>>>> vm related dialogs
>>>>>>
>>>>>> Daniel Erez has posted comments on this change.
>>>>>>
>>>>>> Change subject: userportal,webadmin: redesign of vm related dialogs
>>>>>> ......................................................................
>>>>>>
>>>>>>
>>>>>> Patch Set 5: (1 inline comment)
>>>>>>
>>>>>> Code looks good.
>>>>>> A few questions regarding the design:
>>>>>> 1. Why do we want the static header only in VM dialog?
>>>>>> 2. DC/Host are really relevant for all tabs?
>>>>>> 3. Is it just a preparation for the final instance type dialog?
>>>>>> 4. If it's indeed merely preparation, shouldn't it be merged only
>>>>>> once
>>>>>> we
>>>>>> have the full picture of the new dialog?
>>>>>>
>>>>>> ....................................................
>>>>>> File
>>>>>> frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
>>>>>> Line 21:
>>>>>> Line 22: 		.header {
>>>>>> Line 23: 			background-color: #D3D3D3;
>>>>>> Line 24: 			border-bottom: 1px solid #CED8DF;
>>>>>> Line 25: 			margin-bottom: 15px;
>>>>>> is it supposed to be that large?
>>>>>> Line 26: 			padding-top: 6px;
>>>>>> Line 27: 			margin-top: 4px;
>>>>>> Line 28: 			margin-right: 3px;
>>>>>> Line 29: 			display: none;
>>>>>>
>>>>>>
>>>>>> --
>>>>>> To view, visit http://gerrit.ovirt.org/14635
>>>>>> To unsubscribe, visit http://gerrit.ovirt.org/settings
>>>>>>
>>>>>> Gerrit-MessageType: comment
>>>>>> Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
>>>>>> Gerrit-PatchSet: 5
>>>>>> Gerrit-Project: ovirt-engine
>>>>>> Gerrit-Branch: master
>>>>>> Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
>>>>>> Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
>>>>>> Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
>>>>>> Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
>>>>>> Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
>>>>>> Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
>>>>>> Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
>>>>>>
>>>>>
>>>>
>>>
>>



From wlbleaboy at 126.com  Wed May 29 10:48:23 2013
From: wlbleaboy at 126.com (wlbleaboy@126)
Date: Wed, 29 May 2013 18:48:23 +0800
Subject: [Engine-devel] about IntelliJ
Message-ID: <001701ce5c5a$0bd65150$2382f3f0$@com>

Hi, all:

         Is there anyone used Intellij to build and deploy ovirt-engine

http://www.ovirt.org/Building_Ovirt_Engine/IDE#IntelliJ is not explicit,

 

 

 

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

From mlipchuk at redhat.com  Wed May 29 11:54:51 2013
From: mlipchuk at redhat.com (Maor Lipchuk)
Date: Wed, 29 May 2013 14:54:51 +0300
Subject: [Engine-devel] about IntelliJ
In-Reply-To: <001701ce5c5a$0bd65150$2382f3f0$@com>
References: <001701ce5c5a$0bd65150$2382f3f0$@com>
Message-ID: <51A5EC8B.8030007@redhat.com>

Hi, can u be more specific? what exactly is not explicit?

Regards,
Maor

On 05/29/2013 01:48 PM, wlbleaboy at 126 wrote:
> Hi, all:
> 
>          Is there anyone used Intellij to build and deploy ovirt-engine
> 
> http://www.ovirt.org/Building_Ovirt_Engine/IDE#IntelliJ is not explicit,
> 
>  
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 




From ecohen at redhat.com  Wed May 29 12:21:30 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Wed, 29 May 2013 08:21:30 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <559238979.7794816.1369805763901.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<201305282105.r4SL5ccM002657@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
	<771394793.7670643.1369779500608.JavaMail.root@redhat.com>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
Message-ID: <1910975758.14088419.1369830090869.JavaMail.root@redhat.com>

> ----- Original Message -----
> From: "Daniel Erez" <derez at redhat.com>
> Sent: Wednesday, May 29, 2013 1:36:03 AM
> 
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>,
> > "Eldan Hildesheim" <info at eldanet.com>, "Eldan
> > Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, May 29, 2013 2:30:09 AM
> > Subject: Re: static header only in VM dialog?
> > 
> > > ----- Original Message -----
> > > From: "Daniel Erez" <derez at redhat.com>
> > > Sent: Tuesday, May 28, 2013 6:18:20 PM
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
> > > > <info at eldanet.com>,
> > > > "Eldan Hildesheim" <ehildesh at redhat.com>
> > > > Cc: "Tomas Jelinek" <tjelinek at redhat.com>, derez at redhat.com,
> > > > "engine-devel"
> > > > <engine-devel at ovirt.org>
> > > > Sent: Wednesday, May 29, 2013 12:53:47 AM
> > > > Subject: static header only in VM dialog?
> > > > 
> > > > when reviewing the code for the "redesign of vm related dialogs",
> > > > Daniel
> > > > has
> > > > raised an interesting question: Why do we want the static header only
> > > > in
> > > > VM
> > > > dialog?
> > > > 
> > > > (I assume that he refers to the top section of the New VM dialog as
> > > > seen
> > > > in
> > > > [1], which
> > > > contains the DC/Cluster, Quota, etc information, and is "static", i.e.,
> > > > it
> > > > is
> > > > always
> > > > displayed, regardless of the selected side-tab within the dialog)
> > > > 
> > > > I agree with what Daniel is implying here: for consistency, we would
> > > > probably
> > > > want to
> > > > introduce this static header to other dialogs, at least to the ones
> > > > that
> > > > also
> > > > contain
> > > > side-tabs in which it makes sense to turn the "header" to static
> > > > [e.g.
> > > > "New Host" (which contains a DC + Cluster "header") - see
> > > > http://oi39.tinypic.com/2z84xnp.jpg,
> > > > "New Cluster" (which contains a DC "header") - see
> > > > http://oi40.tinypic.com/2vmyj2x.jpg]
> > > > 
> > > > [I assume, of course, that all the VM-like dialogs (e.g. New/Edit
> > > > VM-Pool)
> > > > will also have
> > > > static headers - I don't know if the patch already takes care of that
> > > > or
> > > > not]
> > > > 
> > > > Thoughts?
> > > > 
> > > > [@Daniel - if you had something else in mind, and/or other dialogs in
> > > > mind
> > > > -
> > > > please feel free
> > > > to add/amend/etc]
> > > 
> > > Besides consistency matters, I wanted to understand what's the motivation
> > > of
> > > keeping these widgets static. I.e. is it an essential preparation for the
> > > new
> > > instance type dialog or a new concept for tab based dialogs
> > > (as DC/Cluster values aren't necessarily relevant for each tab in the
> > > dialog)
> > 
> > [maybe Tomas/Eldan/Malini can help here as well]
> > 
> > these static widgets (as well as the type ahead list box [1], for example)
> > are part of
> > the instance types feature that had its design details published in [2] and
> > [3], and the
> > implementation was done according to this design. I don't see any reason to
> > not utilize
> > this newly-introduced concept in other side-tab-based dialogs as well, if
> > it
> > makes sense
> > (ui consistency considerations are sufficient, IMO, but I could be wrong -
> > maybe it is
> > relevant/correct to introduce this new concept only in the VM-like
> > dialogs).
> > 
> > regarding the specific concern about the DC/Cluster values that aren't
> > necessarily relevant
> > for each side-tab in the dialog: I agree with that statement, however:
> > 
> > - putting the "Instance Type" drop-down at the top static section is very
> > useful (see [4]
> > for explanation), and as the Instance Types list is derived from the
> > selected
> > DC, it makes
> > sense (to me) to put the DC in that top static section as well.
> > 
> > - the DC/Cluster are relevant for some of the tabs in the dialog (Host,
> > Resource Allocation?)
> 
> Only for Host.
> Resource Allocation is directly affected by the selected template.
> Therefore, it sounds very confusing to me...
> Unless we add template to the static header as well?

The answer is yes, in a sense: Instance Types + Images are actually 
somewhat "replacing" Templates [the general approach is to move to 
basing VMs on Instance Types + Images, rather than on Templates; 
it allows more flexibility in combining hardware configuration + image 
configuration for the VM, without (necessarily) editing each VM field 
separately].

So as I stated in my previous response: Having the "Instance Types" 
field (and "Image" field) in the top static section is very useful, as 
they affect the fields in most / a lot of the side-tabs.

Based on the above: 

Do you agree that it makes sense to have a top static section in general 
[even only for the "Instance Types" field and "Image" field (again, as 
they affect most / a lot of side-tabs fields)]? 
If so: Do you think that it makes sense to include the DC field in that  
top static section as well (at least due to the fact that the "Instance 
Types" list and "Images" list are derived from the selected DC)?

[Tomas/Malini/Eldan - if there is additional/different reasoning for putting 
the DC/Cluster field on the top static section - please share]

> (which will be odd for the other tabs).
> 
> So I still don't get the motivation UX-wise.
> E.g. it seems really weird to change the entire DC from Console tab
> (or, as a matter of fact, from most other tabs).
> In the new instance type dialog, which tabs could be directly affected by
> DC/Cluster?
> IIUC, only Host? Do we really need a static header just for this tab?
> 
> > so for consistency-within-the-dialog considerations, it is probably a good
> > idea to simply
> > always show these fields within this top static section.
> > 
> > [there is a good chance that I am missing your point here - please correct
> > me
> > if necessary]
> > 
> > [1] http://gerrit.ovirt.org/#/c/14936/
> > 
> > [2] http://www.ovirt.org/Features/Instance_Types
> > 
> > [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> > 
> > [4] whenever changing the "Instance Type" value, you can automatically see
> > how these changes
> > affect the fields in the current tab on which you are standing (e.g. if you
> > are standing on
> > the "System" side-tab, you can change the "Instance Type" selected item and
> > immediately see
> > the changes within the "System" side-tab contents), and vice-versa: if you
> > are changing a value
> > that was originally propagated from the instance-type, you will see the
> > instance-type automatically
> > change to "custom"/"not applicable" as a result, so no need to "jump"
> > between
> > side-tabs in order
> > to observe these changes.
> > 
> > > 
> > > > 
> > > > ----
> > > > Thanks,
> > > > Einav
> > > > 
> > > > [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> > > > 
> > > > ----- Original Message -----
> > > > > From: derez at redhat.com
> > > > > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > > > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> > > > > <ecohen at redhat.com>,
> > > > > "Frank Kobzik" <fkobzik at redhat.com>,
> > > > > "Eldan Hildesheim" <info at eldanet.com>
> > > > > Sent: Tuesday, May 28, 2013 5:05:38 PM
> > > > > Subject: Change in ovirt-engine[master]: userportal,webadmin:
> > > > > redesign
> > > > > of
> > > > > vm related dialogs
> > > > > 
> > > > > Daniel Erez has posted comments on this change.
> > > > > 
> > > > > Change subject: userportal,webadmin: redesign of vm related dialogs
> > > > > ......................................................................
> > > > > 
> > > > > 
> > > > > Patch Set 5: (1 inline comment)
> > > > > 
> > > > > Code looks good.
> > > > > A few questions regarding the design:
> > > > > 1. Why do we want the static header only in VM dialog?
> > > > > 2. DC/Host are really relevant for all tabs?
> > > > > 3. Is it just a preparation for the final instance type dialog?
> > > > > 4. If it's indeed merely preparation, shouldn't it be merged only
> > > > > once
> > > > > we
> > > > > have the full picture of the new dialog?
> > > > > 
> > > > > ....................................................
> > > > > File
> > > > > frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> > > > > Line 21:
> > > > > Line 22: 		.header {
> > > > > Line 23: 			background-color: #D3D3D3;
> > > > > Line 24: 			border-bottom: 1px solid #CED8DF;
> > > > > Line 25: 			margin-bottom: 15px;
> > > > > is it supposed to be that large?
> > > > > Line 26: 			padding-top: 6px;
> > > > > Line 27: 			margin-top: 4px;
> > > > > Line 28: 			margin-right: 3px;
> > > > > Line 29: 			display: none;
> > > > > 
> > > > > 
> > > > > --
> > > > > To view, visit http://gerrit.ovirt.org/14635
> > > > > To unsubscribe, visit http://gerrit.ovirt.org/settings
> > > > > 
> > > > > Gerrit-MessageType: comment
> > > > > Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> > > > > Gerrit-PatchSet: 5
> > > > > Gerrit-Project: ovirt-engine
> > > > > Gerrit-Branch: master
> > > > > Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
> > > > > Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
> > > > > Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
> > > > > Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
> > > > > Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
> > > > > Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
> > > > > Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
> > > > > 
> > > > 
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From eedri at redhat.com  Wed May 29 12:43:51 2013
From: eedri at redhat.com (Eyal Edri)
Date: Wed, 29 May 2013 08:43:51 -0400 (EDT)
Subject: [Engine-devel] findbugs [normal priority] - *please fix ASAP*
In-Reply-To: <101604778.13743152.1369775015098.JavaMail.root@redhat.com>
References: <1334031104.12612040.1369656475568.JavaMail.root@redhat.com>
	<466583400.8209650.1369657023731.JavaMail.root@redhat.com>
	<101604778.13743152.1369775015098.JavaMail.root@redhat.com>
Message-ID: <1557179548.450341.1369831431040.JavaMail.root@redhat.com>

thanks guys for the help, 

we're planning to add a findbugs jos to run per patch so you'll be able to see it before merging.

Eyal.

----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>, "Lior Vernia" <lvernia at redhat.com>, "Daniel Erez" <derez at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, May 29, 2013 12:03:35 AM
> Subject: Re: [Engine-devel] findbugs [normal priority] - *please fix ASAP*
> 
> many thanks Yair/Lior/Derez for checking/fixing/reviewing/verifying/merging.
> findbugs is now back to green:
> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4338/
> 
> ----
> Regards,
> Einav
> 
> ----- Original Message -----
> > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > To: "Einav Cohen" <ecohen at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Monday, May 27, 2013 8:17:03 AM
> > Subject: Re: [Engine-devel] findbugs [normal priority] - *please fix ASAP*
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Monday, May 27, 2013 3:07:55 PM
> > > Subject: [Engine-devel] findbugs [normal priority] - *please fix ASAP*
> > > 
> > > lvernia:
> > > find bugs error:
> > > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4323/findbugsResult/NORMAL/module.935532853/source.199038/#60
> > > in file:
> > > frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/Uri.java
> > > caused by patch:
> > > http://gerrit.ovirt.org/#/c/14695/ [webadmin: Added validation to
> > > ProviderModel, merged: May 27]
> > > 
> > > ----
> > > 
> > > mkublin:
> > > find bugs error:
> > > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4323/findbugsResult/NORMAL/module.-609324659/source.198236/#342
> > > in file:
> > > backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/RunVmCommandBase.java
> > > caused by patch:
> > > http://gerrit.ovirt.org/#/c/13740/ [engine: Fixing perfomance issue
> > > between
> > > VdsRunTimeInfo and RunVmCommandBase, merged: Apr 10]
> > 
> > This should have been handled by the findbugs filter . The fact that it was
> > not handled means we still have an issue with filters.
> > I'm taking a look.
> > 
> > > 
> > > ----
> > > Thanks,
> > > Einav
> > > _______________________________________________
> > > 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  Wed May 29 12:56:30 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 29 May 2013 15:56:30 +0300
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <559238979.7794816.1369805763901.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<201305282105.r4SL5ccM002657@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
	<771394793.7670643.1369779500608.JavaMail.root@redhat.com>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
Message-ID: <51A5FAFE.4010609@redhat.com>

On 05/29/2013 08:36 AM, Daniel Erez wrote:
...
>> relevant/correct to introduce this new concept only in the VM-like dialogs).
>>
>> regarding the specific concern about the DC/Cluster values that aren't
>> necessarily relevant
>> for each side-tab in the dialog: I agree with that statement, however:
>>
>> - putting the "Instance Type" drop-down at the top static section is very
>> useful (see [4]
>> for explanation), and as the Instance Types list is derived from the selected
>> DC, it makes
>> sense (to me) to put the DC in that top static section as well.
>>
>> - the DC/Cluster are relevant for some of the tabs in the dialog (Host,
>> Resource Allocation?)
>
> Only for Host.
> Resource Allocation is directly affected by the selected template.
> Therefore, it sounds very confusing to me...
> Unless we add template to the static header as well?
> (which will be odd for the other tabs).

isn't resource allocation affected by the vm type (optimized for 
server/desktop), rather than the template?

(and template is on the static header as well - images are a subset of 
templates, but you will see there both images and templates).

>
> So I still don't get the motivation UX-wise.
> E.g. it seems really weird to change the entire DC from Console tab
> (or, as a matter of fact, from most other tabs).
> In the new instance type dialog, which tabs could be directly affected by DC/Cluster?
> IIUC, only Host? Do we really need a static header just for this tab?
>
>> so for consistency-within-the-dialog considerations, it is probably a good
>> idea to simply
>> always show these fields within this top static section.
>>
>> [there is a good chance that I am missing your point here - please correct me
>> if necessary]
>>
>> [1] http://gerrit.ovirt.org/#/c/14936/
>>
>> [2] http://www.ovirt.org/Features/Instance_Types
>>
>> [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
>>
>> [4] whenever changing the "Instance Type" value, you can automatically see
>> how these changes
>> affect the fields in the current tab on which you are standing (e.g. if you
>> are standing on
>> the "System" side-tab, you can change the "Instance Type" selected item and
>> immediately see
>> the changes within the "System" side-tab contents), and vice-versa: if you
>> are changing a value
>> that was originally propagated from the instance-type, you will see the
>> instance-type automatically
>> change to "custom"/"not applicable" as a result, so no need to "jump" between
>> side-tabs in order
>> to observe these changes.
>>
>>>
>>>>
>>>> ----
>>>> Thanks,
>>>> Einav
>>>>
>>>> [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
>>>>
>>>> ----- Original Message -----
>>>>> From: derez at redhat.com
>>>>> To: "Tomas Jelinek" <tjelinek at redhat.com>
>>>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
>>>>> <ecohen at redhat.com>,
>>>>> "Frank Kobzik" <fkobzik at redhat.com>,
>>>>> "Eldan Hildesheim" <info at eldanet.com>
>>>>> Sent: Tuesday, May 28, 2013 5:05:38 PM
>>>>> Subject: Change in ovirt-engine[master]: userportal,webadmin: redesign
>>>>> of
>>>>> vm related dialogs
>>>>>
>>>>> Daniel Erez has posted comments on this change.
>>>>>
>>>>> Change subject: userportal,webadmin: redesign of vm related dialogs
>>>>> ......................................................................
>>>>>
>>>>>
>>>>> Patch Set 5: (1 inline comment)
>>>>>
>>>>> Code looks good.
>>>>> A few questions regarding the design:
>>>>> 1. Why do we want the static header only in VM dialog?
>>>>> 2. DC/Host are really relevant for all tabs?
>>>>> 3. Is it just a preparation for the final instance type dialog?
>>>>> 4. If it's indeed merely preparation, shouldn't it be merged only once
>>>>> we
>>>>> have the full picture of the new dialog?
>>>>>
>>>>> ....................................................
>>>>> File
>>>>> frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
>>>>> Line 21:
>>>>> Line 22: 		.header {
>>>>> Line 23: 			background-color: #D3D3D3;
>>>>> Line 24: 			border-bottom: 1px solid #CED8DF;
>>>>> Line 25: 			margin-bottom: 15px;
>>>>> is it supposed to be that large?
>>>>> Line 26: 			padding-top: 6px;
>>>>> Line 27: 			margin-top: 4px;
>>>>> Line 28: 			margin-right: 3px;
>>>>> Line 29: 			display: none;
>>>>>
>>>>>
>>>>> --
>>>>> To view, visit http://gerrit.ovirt.org/14635
>>>>> To unsubscribe, visit http://gerrit.ovirt.org/settings
>>>>>
>>>>> Gerrit-MessageType: comment
>>>>> Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
>>>>> Gerrit-PatchSet: 5
>>>>> Gerrit-Project: ovirt-engine
>>>>> Gerrit-Branch: master
>>>>> Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
>>>>> Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
>>>>> Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
>>>>> Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
>>>>> Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
>>>>> Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
>>>>> Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
>>>>>
>>>>
>>>
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From derez at redhat.com  Wed May 29 13:13:23 2013
From: derez at redhat.com (Daniel Erez)
Date: Wed, 29 May 2013 09:13:23 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <51A5FAFE.4010609@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<201305282105.r4SL5ccM002657@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
	<771394793.7670643.1369779500608.JavaMail.root@redhat.com>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
	<51A5FAFE.4010609@redhat.com>
Message-ID: <1971065309.8030155.1369833203217.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Daniel Erez" <derez at redhat.com>
> Cc: "Einav Cohen" <ecohen at redhat.com>, "Eldan Hildesheim" <info at eldanet.com>, "engine-devel"
> <engine-devel at ovirt.org>, "Eldan Hildesheim" <ehildesh at redhat.com>
> Sent: Wednesday, May 29, 2013 3:56:30 PM
> Subject: Re: [Engine-devel] static header only in VM dialog?
> 
> On 05/29/2013 08:36 AM, Daniel Erez wrote:
> ...
> >> relevant/correct to introduce this new concept only in the VM-like
> >> dialogs).
> >>
> >> regarding the specific concern about the DC/Cluster values that aren't
> >> necessarily relevant
> >> for each side-tab in the dialog: I agree with that statement, however:
> >>
> >> - putting the "Instance Type" drop-down at the top static section is very
> >> useful (see [4]
> >> for explanation), and as the Instance Types list is derived from the
> >> selected
> >> DC, it makes
> >> sense (to me) to put the DC in that top static section as well.
> >>
> >> - the DC/Cluster are relevant for some of the tabs in the dialog (Host,
> >> Resource Allocation?)
> >
> > Only for Host.
> > Resource Allocation is directly affected by the selected template.
> > Therefore, it sounds very confusing to me...
> > Unless we add template to the static header as well?
> > (which will be odd for the other tabs).
> 
> isn't resource allocation affected by the vm type (optimized for
> server/desktop), rather than the template?

Only Thin vs. Clone is affected by VM type.
But, SDs are affected by the selected template.

> 
> (and template is on the static header as well - images are a subset of
> templates, but you will see there both images and templates).

According to the current patch only DC and Cluster are static in the header.
Which means that until we have a full implementation merged the static
header would surely be confusing. Afterwards, I'm still not sure how most
tabs are influenced, e.g.: Initial Run / Console / Boot Options
are really related to the DC/Cluster/Instance Type?

> 
> >
> > So I still don't get the motivation UX-wise.
> > E.g. it seems really weird to change the entire DC from Console tab
> > (or, as a matter of fact, from most other tabs).
> > In the new instance type dialog, which tabs could be directly affected by
> > DC/Cluster?
> > IIUC, only Host? Do we really need a static header just for this tab?
> >
> >> so for consistency-within-the-dialog considerations, it is probably a good
> >> idea to simply
> >> always show these fields within this top static section.
> >>
> >> [there is a good chance that I am missing your point here - please correct
> >> me
> >> if necessary]
> >>
> >> [1] http://gerrit.ovirt.org/#/c/14936/
> >>
> >> [2] http://www.ovirt.org/Features/Instance_Types
> >>
> >> [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> >>
> >> [4] whenever changing the "Instance Type" value, you can automatically see
> >> how these changes
> >> affect the fields in the current tab on which you are standing (e.g. if
> >> you
> >> are standing on
> >> the "System" side-tab, you can change the "Instance Type" selected item
> >> and
> >> immediately see
> >> the changes within the "System" side-tab contents), and vice-versa: if you
> >> are changing a value
> >> that was originally propagated from the instance-type, you will see the
> >> instance-type automatically
> >> change to "custom"/"not applicable" as a result, so no need to "jump"
> >> between
> >> side-tabs in order
> >> to observe these changes.
> >>
> >>>
> >>>>
> >>>> ----
> >>>> Thanks,
> >>>> Einav
> >>>>
> >>>> [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: derez at redhat.com
> >>>>> To: "Tomas Jelinek" <tjelinek at redhat.com>
> >>>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> >>>>> <ecohen at redhat.com>,
> >>>>> "Frank Kobzik" <fkobzik at redhat.com>,
> >>>>> "Eldan Hildesheim" <info at eldanet.com>
> >>>>> Sent: Tuesday, May 28, 2013 5:05:38 PM
> >>>>> Subject: Change in ovirt-engine[master]: userportal,webadmin: redesign
> >>>>> of
> >>>>> vm related dialogs
> >>>>>
> >>>>> Daniel Erez has posted comments on this change.
> >>>>>
> >>>>> Change subject: userportal,webadmin: redesign of vm related dialogs
> >>>>> ......................................................................
> >>>>>
> >>>>>
> >>>>> Patch Set 5: (1 inline comment)
> >>>>>
> >>>>> Code looks good.
> >>>>> A few questions regarding the design:
> >>>>> 1. Why do we want the static header only in VM dialog?
> >>>>> 2. DC/Host are really relevant for all tabs?
> >>>>> 3. Is it just a preparation for the final instance type dialog?
> >>>>> 4. If it's indeed merely preparation, shouldn't it be merged only once
> >>>>> we
> >>>>> have the full picture of the new dialog?
> >>>>>
> >>>>> ....................................................
> >>>>> File
> >>>>> frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> >>>>> Line 21:
> >>>>> Line 22: 		.header {
> >>>>> Line 23: 			background-color: #D3D3D3;
> >>>>> Line 24: 			border-bottom: 1px solid #CED8DF;
> >>>>> Line 25: 			margin-bottom: 15px;
> >>>>> is it supposed to be that large?
> >>>>> Line 26: 			padding-top: 6px;
> >>>>> Line 27: 			margin-top: 4px;
> >>>>> Line 28: 			margin-right: 3px;
> >>>>> Line 29: 			display: none;
> >>>>>
> >>>>>
> >>>>> --
> >>>>> To view, visit http://gerrit.ovirt.org/14635
> >>>>> To unsubscribe, visit http://gerrit.ovirt.org/settings
> >>>>>
> >>>>> Gerrit-MessageType: comment
> >>>>> Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> >>>>> Gerrit-PatchSet: 5
> >>>>> Gerrit-Project: ovirt-engine
> >>>>> Gerrit-Branch: master
> >>>>> Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
> >>>>> Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
> >>>>> Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
> >>>>> Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
> >>>>> Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
> >>>>> Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
> >>>>> Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
> >>>>>
> >>>>
> >>>
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 


From iheim at redhat.com  Wed May 29 13:25:18 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 29 May 2013 16:25:18 +0300
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <1971065309.8030155.1369833203217.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<201305282105.r4SL5ccM002657@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
	<771394793.7670643.1369779500608.JavaMail.root@redhat.com>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
	<51A5FAFE.4010609@redhat.com>
	<1971065309.8030155.1369833203217.JavaMail.root@redhat.com>
Message-ID: <51A601BE.2000900@redhat.com>

On 05/29/2013 04:13 PM, Daniel Erez wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Daniel Erez" <derez at redhat.com>
>> Cc: "Einav Cohen" <ecohen at redhat.com>, "Eldan Hildesheim" <info at eldanet.com>, "engine-devel"
>> <engine-devel at ovirt.org>, "Eldan Hildesheim" <ehildesh at redhat.com>
>> Sent: Wednesday, May 29, 2013 3:56:30 PM
>> Subject: Re: [Engine-devel] static header only in VM dialog?
>>
>> On 05/29/2013 08:36 AM, Daniel Erez wrote:
>> ...
>>>> relevant/correct to introduce this new concept only in the VM-like
>>>> dialogs).
>>>>
>>>> regarding the specific concern about the DC/Cluster values that aren't
>>>> necessarily relevant
>>>> for each side-tab in the dialog: I agree with that statement, however:
>>>>
>>>> - putting the "Instance Type" drop-down at the top static section is very
>>>> useful (see [4]
>>>> for explanation), and as the Instance Types list is derived from the
>>>> selected
>>>> DC, it makes
>>>> sense (to me) to put the DC in that top static section as well.
>>>>
>>>> - the DC/Cluster are relevant for some of the tabs in the dialog (Host,
>>>> Resource Allocation?)
>>>
>>> Only for Host.
>>> Resource Allocation is directly affected by the selected template.
>>> Therefore, it sounds very confusing to me...
>>> Unless we add template to the static header as well?
>>> (which will be odd for the other tabs).
>>
>> isn't resource allocation affected by the vm type (optimized for
>> server/desktop), rather than the template?
>
> Only Thin vs. Clone is affected by VM type.
> But, SDs are affected by the selected template.

yes. i don't see how this changes things though, since changing 
image/template would be visible.

>
>>
>> (and template is on the static header as well - images are a subset of
>> templates, but you will see there both images and templates).
>
> According to the current patch only DC and Cluster are static in the header.
> Which means that until we have a full implementation merged the static
> header would surely be confusing. Afterwards, I'm still not sure how most
> tabs are influenced, e.g.: Initial Run / Console / Boot Options
> are really related to the DC/Cluster/Instance Type?

have you reviewed the table in the feature page mapping which fields 
related to instance type?

>
>>
>>>
>>> So I still don't get the motivation UX-wise.
>>> E.g. it seems really weird to change the entire DC from Console tab
>>> (or, as a matter of fact, from most other tabs).
>>> In the new instance type dialog, which tabs could be directly affected by
>>> DC/Cluster?
>>> IIUC, only Host? Do we really need a static header just for this tab?
>>>
>>>> so for consistency-within-the-dialog considerations, it is probably a good
>>>> idea to simply
>>>> always show these fields within this top static section.
>>>>
>>>> [there is a good chance that I am missing your point here - please correct
>>>> me
>>>> if necessary]
>>>>
>>>> [1] http://gerrit.ovirt.org/#/c/14936/
>>>>
>>>> [2] http://www.ovirt.org/Features/Instance_Types
>>>>
>>>> [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
>>>>
>>>> [4] whenever changing the "Instance Type" value, you can automatically see
>>>> how these changes
>>>> affect the fields in the current tab on which you are standing (e.g. if
>>>> you
>>>> are standing on
>>>> the "System" side-tab, you can change the "Instance Type" selected item
>>>> and
>>>> immediately see
>>>> the changes within the "System" side-tab contents), and vice-versa: if you
>>>> are changing a value
>>>> that was originally propagated from the instance-type, you will see the
>>>> instance-type automatically
>>>> change to "custom"/"not applicable" as a result, so no need to "jump"
>>>> between
>>>> side-tabs in order
>>>> to observe these changes.
>>>>
>>>>>
>>>>>>
>>>>>> ----
>>>>>> Thanks,
>>>>>> Einav
>>>>>>
>>>>>> [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: derez at redhat.com
>>>>>>> To: "Tomas Jelinek" <tjelinek at redhat.com>
>>>>>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
>>>>>>> <ecohen at redhat.com>,
>>>>>>> "Frank Kobzik" <fkobzik at redhat.com>,
>>>>>>> "Eldan Hildesheim" <info at eldanet.com>
>>>>>>> Sent: Tuesday, May 28, 2013 5:05:38 PM
>>>>>>> Subject: Change in ovirt-engine[master]: userportal,webadmin: redesign
>>>>>>> of
>>>>>>> vm related dialogs
>>>>>>>
>>>>>>> Daniel Erez has posted comments on this change.
>>>>>>>
>>>>>>> Change subject: userportal,webadmin: redesign of vm related dialogs
>>>>>>> ......................................................................
>>>>>>>
>>>>>>>
>>>>>>> Patch Set 5: (1 inline comment)
>>>>>>>
>>>>>>> Code looks good.
>>>>>>> A few questions regarding the design:
>>>>>>> 1. Why do we want the static header only in VM dialog?
>>>>>>> 2. DC/Host are really relevant for all tabs?
>>>>>>> 3. Is it just a preparation for the final instance type dialog?
>>>>>>> 4. If it's indeed merely preparation, shouldn't it be merged only once
>>>>>>> we
>>>>>>> have the full picture of the new dialog?
>>>>>>>
>>>>>>> ....................................................
>>>>>>> File
>>>>>>> frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
>>>>>>> Line 21:
>>>>>>> Line 22: 		.header {
>>>>>>> Line 23: 			background-color: #D3D3D3;
>>>>>>> Line 24: 			border-bottom: 1px solid #CED8DF;
>>>>>>> Line 25: 			margin-bottom: 15px;
>>>>>>> is it supposed to be that large?
>>>>>>> Line 26: 			padding-top: 6px;
>>>>>>> Line 27: 			margin-top: 4px;
>>>>>>> Line 28: 			margin-right: 3px;
>>>>>>> Line 29: 			display: none;
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> To view, visit http://gerrit.ovirt.org/14635
>>>>>>> To unsubscribe, visit http://gerrit.ovirt.org/settings
>>>>>>>
>>>>>>> Gerrit-MessageType: comment
>>>>>>> Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
>>>>>>> Gerrit-PatchSet: 5
>>>>>>> Gerrit-Project: ovirt-engine
>>>>>>> Gerrit-Branch: master
>>>>>>> Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
>>>>>>> Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
>>>>>>> Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
>>>>>>> Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
>>>>>>> Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
>>>>>>> Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
>>>>>>> Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>>



From Christopher.Morrissey at netapp.com  Wed May 29 15:38:28 2013
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Wed, 29 May 2013 15:38:28 +0000
Subject: [Engine-devel] Few detailed REST API questions
Message-ID: <D290AD8432118048947689BA3AE8A9B325C28E8F@SACEXCMBX04-PRD.hq.netapp.com>

Hi All,

I'm working with the REST API and have a question that I haven't been able to figure out. When destroying a storage domain, it appears that a host is required in the storage domain. Can this be any host that has access to that domain? 

The storage domain returned through the REST api does not have the host populated so I'm not sure how I would figure out a specific host to put in there other than to just make sure it's one that can access the domain.

-Chris

Chris Morrissey
Software Engineer
NetApp Inc.
919.476.4428




From ofrenkel at redhat.com  Thu May 30 08:29:40 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Thu, 30 May 2013 04:29:40 -0400 (EDT)
Subject: [Engine-devel] Disk BE very small refactoring
In-Reply-To: <2012114925.13632941.1369762838851.JavaMail.root@redhat.com>
References: <1543112346.12706449.1369667938808.JavaMail.root@redhat.com>
	<1454073553.8350387.1369668178246.JavaMail.root@redhat.com>
	<1021461587.13107769.1369729481376.JavaMail.root@redhat.com>
	<51A48BCA.5020509@redhat.com>
	<2012114925.13632941.1369762838851.JavaMail.root@redhat.com>
Message-ID: <1369501327.15118945.1369902580919.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Vered Volansky" <vered at redhat.com>
> To: "Maor Lipchuk" <mlipchuk at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, "Omer Frenkel"
> <ofrenkel at redhat.com>, "Mike Kolesnik" <mkolesni at redhat.com>, "Allon Mureinik" <amureini at redhat.com>, "Daniel Erez"
> <derez at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, May 28, 2013 8:40:38 PM
> Subject: Re: [Engine-devel] Disk BE very small refactoring
> 
> I had a problem, didn't see all the replies till now.
> 
> I'll add some more info as to why we want to do this like we do.
> It all started from adding the readOnly property to disks. It should have
> been handled like plugged is handled, yet plugged is a hack, and if we don't
> change that now, we'll only keep on adding unreasonable hacks.
> 

please explain why you think plugged is a hack? what is wrong with it?

> So from the start -
> Disk currently:
> - Sometimes represents a disk in a vm context and sometimes not.
> - Holds plugged property, which is only relevant when a disk is in a vm
> context, which already suggests this is not the natural place for it.
> - Also holds bootable and interface, which cause limitations of use, but are
> not so obviously related to the relationship between Disk and Vm as plugged.
> - Can be shared between several vm's, to some plugged and to some not
> plugged.
> - Will soon be optionally RO in one VM and RW in another, which is exactly
> the same as plugged, and therefore plugged issue should be fixed first.
> 
> Every column in that shows a disk in the UI receives a Disk entity, and show
> its contents, while plugged/unplugged is ignored when not in a VM context.
> The way things are now, using a VmDevice in the where we need it to show plug
> status, we'll also have to use it in all other columns, which is irrelevant
> and just totally not related.
> So using VmDevice in UI is a no go.
> 
> The UI is the main limitation forcing us to use something that extends Disk,
> and what I described below is the easiest thing to implement in the time
> restrictions we have without changing the entire system.
> 
> I think this answers all the questions not already answered by others.
> Regarding Maor suggestion - might be a good idea, but not in this scope or
> time-frame.
> 
> If there is any other/unanswered issue or objection to the design change
> please share.
> 
> I appreciate your inputs,
> Vered
> 

sorry i didnt understand why the current disk object isnt good enough,
you get a disk, some of its properties are valid only in some situations.
i think its easier to use instead of couple of different objects representing the same entity in different situations.

> 
> ----- Original Message -----
> > From: "Maor Lipchuk" <mlipchuk at redhat.com>
> > To: "Vered Volansky" <vered at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, May 28, 2013 1:49:46 PM
> > Subject: Re: [Engine-devel] Disk BE very small refactoring
> > 
> > I think the main problem is that we abuse the business entity to act as
> > an O/R mapping class to the DB and also to be used as a business entity
> > for presentation purposes.
> > 
> > I understand how Yair thought isPlugged could be fetched from vmDevice,
> > this is a confusing design, and it is just one example and more to come.
> > 
> > I suggest that if we already thinking of changing the class hierarchy,
> > we can start by implementing a package for presentation classes for
> > transient classes such as this instead enforcing complex hierarchy.
> > 
> > The query class will fetch all the data from the DB and initialized the
> > transient class and send it to the client.
> > I think it could be a good start and will solve many issues we might
> > encounter in the future.
> > 
> > Regards,
> > Maor
> > 
> > On 05/28/2013 11:24 AM, Omer Frenkel wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > >> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > >> To: "Vered Volansky" <vered at redhat.com>
> > >> Cc: engine-devel at ovirt.org
> > >> Sent: Monday, May 27, 2013 6:22:58 PM
> > >> Subject: Re: [Engine-devel] Disk BE very small refactoring
> > >>
> > >> Vered,
> > >> VmDevice has "isPlugged" field,
> > >> Why not have somehow in your inheritence (either Disk or a subclass) a
> > >> field
> > >> : "VmDevice device"
> > > 
> > > disk id is the device id, no need for field to represent the relation.
> > > the combination of disk-id and a specific entity (vm/template) will get
> > > you
> > > the other info
> > > 
> > >> and have isPlugged method called "device.isPlugged()" ?
> > >>
> > >> Then you can also add the readOnly property which is not represented at
> > >> VmDevice.
> > >>
> > >>
> > >> Does this sound logical to you?
> > >>
> > >> ----- Original Message -----
> > >>> From: "Vered Volansky" <vered at redhat.com>
> > >>> To: engine-devel at ovirt.org
> > >>> Sent: Monday, May 27, 2013 6:18:58 PM
> > >>> Subject: [Engine-devel] Disk BE very small refactoring
> > >>>
> > >>> Hi All,
> > >>>
> > >>> Please express your opinion if you have any -
> > >>>
> > >>> Currently Disk BE has a plugged property, which should be a property of
> > >>> the
> > >>> relationship between vm(or template) and a disk.
> > >>> I plan to remove this property from the Disk entity, and add new
> > >>> entity,
> > >>> called DeviceDisk.
> > >>> This should inherit from Disk and contain the vm/template guid and the
> > >>> plugged property at first round.
> > >>> At second round it'll also contain the readOnly property, for RO disks,
> > >>> TBD
> > >>> right after.
> > >>>
> > >>> Appreciate any input,
> > >>> Vered
> > >>> _______________________________________________
> > >>> 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 dfediuck at redhat.com  Thu May 30 08:45:15 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 30 May 2013 04:45:15 -0400 (EDT)
Subject: [Engine-devel] oVirt Scheduler API Design
In-Reply-To: <466692572.7422131.1369751651486.JavaMail.root@redhat.com>
References: <466692572.7422131.1369751651486.JavaMail.root@redhat.com>
Message-ID: <759987698.15126046.1369903515630.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, May 28, 2013 5:34:11 PM
> Subject: [Engine-devel] oVirt Scheduler API Design
> 
> Hi all,
> 
> Attached links for oVirt Scheduler API design wiki page.
> 
> High level overview: http://www.ovirt.org/Features/oVirtScheduler
> Detailed design: http://www.ovirt.org/Features/oVirtSchedulerAPI
> 
> You are more than welcome to share you thoughts.
> 
> Thanks,
> Gilad.

Adding to users' list for all those asking about the new oVirt
scheduling features. Feel free to review and feedback.


From shweng at 163.com  Thu May 30 09:28:42 2013
From: shweng at 163.com (Edgar)
Date: Thu, 30 May 2013 17:28:42 +0800 (CST)
Subject: [Engine-devel] setup ovirt-engine on graphic or web mode
Message-ID: <5e10b363.24fde.13ef4c48df1.Coremail.shweng@163.com>

Hi,All
so far as I know, we use engine-setup command to setup ovirt engine.
engine-setup coded in python which run in linux shell.it is not convenience 
to some people that not be familiar with Linux OS.
 
Currently,Does oVirt project has some tools or method that support to setup engine on graphic or web mode?
If no, Is there any plan or schedule to support this feature?
 
Thanks and Best Regards.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130530/0c91893c/attachment.html>

From emesika at redhat.com  Thu May 30 09:57:26 2013
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 30 May 2013 05:57:26 -0400 (EDT)
Subject: [Engine-devel] Disk BE very small refactoring
In-Reply-To: <1369501327.15118945.1369902580919.JavaMail.root@redhat.com>
References: <1543112346.12706449.1369667938808.JavaMail.root@redhat.com>
	<1454073553.8350387.1369668178246.JavaMail.root@redhat.com>
	<1021461587.13107769.1369729481376.JavaMail.root@redhat.com>
	<51A48BCA.5020509@redhat.com>
	<2012114925.13632941.1369762838851.JavaMail.root@redhat.com>
	<1369501327.15118945.1369902580919.JavaMail.root@redhat.com>
Message-ID: <798173905.9398505.1369907846932.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Vered Volansky" <vered at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, May 30, 2013 11:29:40 AM
> Subject: Re: [Engine-devel] Disk BE very small refactoring
> 
> 
> 
> ----- Original Message -----
> > From: "Vered Volansky" <vered at redhat.com>
> > To: "Maor Lipchuk" <mlipchuk at redhat.com>, "Yair Zaslavsky"
> > <yzaslavs at redhat.com>, "Omer Frenkel"
> > <ofrenkel at redhat.com>, "Mike Kolesnik" <mkolesni at redhat.com>, "Allon
> > Mureinik" <amureini at redhat.com>, "Daniel Erez"
> > <derez at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, May 28, 2013 8:40:38 PM
> > Subject: Re: [Engine-devel] Disk BE very small refactoring
> > 
> > I had a problem, didn't see all the replies till now.
> > 
> > I'll add some more info as to why we want to do this like we do.
> > It all started from adding the readOnly property to disks. It should have
> > been handled like plugged is handled, yet plugged is a hack, and if we
> > don't
> > change that now, we'll only keep on adding unreasonable hacks.
> > 
> 
> please explain why you think plugged is a hack? what is wrong with it?

You have is_readonly and is_plugged in the device level , this is far from being a hack and managed in the correct place since both may apply to multiple device types (disk, nics ....)

> 
> > So from the start -
> > Disk currently:
> > - Sometimes represents a disk in a vm context and sometimes not.
> > - Holds plugged property, which is only relevant when a disk is in a vm
> > context, which already suggests this is not the natural place for it.
> > - Also holds bootable and interface, which cause limitations of use, but
> > are
> > not so obviously related to the relationship between Disk and Vm as
> > plugged.
> > - Can be shared between several vm's, to some plugged and to some not
> > plugged.
> > - Will soon be optionally RO in one VM and RW in another, which is exactly
> > the same as plugged, and therefore plugged issue should be fixed first.
> > 
> > Every column in that shows a disk in the UI receives a Disk entity, and
> > show
> > its contents, while plugged/unplugged is ignored when not in a VM context.
> > The way things are now, using a VmDevice in the where we need it to show
> > plug
> > status, we'll also have to use it in all other columns, which is irrelevant
> > and just totally not related.
> > So using VmDevice in UI is a no go.
> > 
> > The UI is the main limitation forcing us to use something that extends
> > Disk,
> > and what I described below is the easiest thing to implement in the time
> > restrictions we have without changing the entire system.
> > 
> > I think this answers all the questions not already answered by others.
> > Regarding Maor suggestion - might be a good idea, but not in this scope or
> > time-frame.
> > 
> > If there is any other/unanswered issue or objection to the design change
> > please share.
> > 
> > I appreciate your inputs,
> > Vered
> > 
> 
> sorry i didnt understand why the current disk object isnt good enough,
> you get a disk, some of its properties are valid only in some situations.
> i think its easier to use instead of couple of different objects representing
> the same entity in different situations.

I totally agree with Omer, please specify what is impossible or hard to achieve with the current schema 

> 
> > 
> > ----- Original Message -----
> > > From: "Maor Lipchuk" <mlipchuk at redhat.com>
> > > To: "Vered Volansky" <vered at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Tuesday, May 28, 2013 1:49:46 PM
> > > Subject: Re: [Engine-devel] Disk BE very small refactoring
> > > 
> > > I think the main problem is that we abuse the business entity to act as
> > > an O/R mapping class to the DB and also to be used as a business entity
> > > for presentation purposes.
> > > 
> > > I understand how Yair thought isPlugged could be fetched from vmDevice,
> > > this is a confusing design, and it is just one example and more to come.
> > > 
> > > I suggest that if we already thinking of changing the class hierarchy,
> > > we can start by implementing a package for presentation classes for
> > > transient classes such as this instead enforcing complex hierarchy.
> > > 
> > > The query class will fetch all the data from the DB and initialized the
> > > transient class and send it to the client.
> > > I think it could be a good start and will solve many issues we might
> > > encounter in the future.
> > > 
> > > Regards,
> > > Maor
> > > 
> > > On 05/28/2013 11:24 AM, Omer Frenkel wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > >> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > >> To: "Vered Volansky" <vered at redhat.com>
> > > >> Cc: engine-devel at ovirt.org
> > > >> Sent: Monday, May 27, 2013 6:22:58 PM
> > > >> Subject: Re: [Engine-devel] Disk BE very small refactoring
> > > >>
> > > >> Vered,
> > > >> VmDevice has "isPlugged" field,
> > > >> Why not have somehow in your inheritence (either Disk or a subclass) a
> > > >> field
> > > >> : "VmDevice device"
> > > > 
> > > > disk id is the device id, no need for field to represent the relation.
> > > > the combination of disk-id and a specific entity (vm/template) will get
> > > > you
> > > > the other info
> > > > 
> > > >> and have isPlugged method called "device.isPlugged()" ?
> > > >>
> > > >> Then you can also add the readOnly property which is not represented
> > > >> at
> > > >> VmDevice.
> > > >>
> > > >>
> > > >> Does this sound logical to you?
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "Vered Volansky" <vered at redhat.com>
> > > >>> To: engine-devel at ovirt.org
> > > >>> Sent: Monday, May 27, 2013 6:18:58 PM
> > > >>> Subject: [Engine-devel] Disk BE very small refactoring
> > > >>>
> > > >>> Hi All,
> > > >>>
> > > >>> Please express your opinion if you have any -
> > > >>>
> > > >>> Currently Disk BE has a plugged property, which should be a property
> > > >>> of
> > > >>> the
> > > >>> relationship between vm(or template) and a disk.
> > > >>> I plan to remove this property from the Disk entity, and add new
> > > >>> entity,
> > > >>> called DeviceDisk.
> > > >>> This should inherit from Disk and contain the vm/template guid and
> > > >>> the
> > > >>> plugged property at first round.
> > > >>> At second round it'll also contain the readOnly property, for RO
> > > >>> disks,
> > > >>> TBD
> > > >>> right after.
> > > >>>
> > > >>> Appreciate any input,
> > > >>> Vered
> > > >>> _______________________________________________
> > > >>> 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
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From vfeenstr at redhat.com  Thu May 30 12:00:17 2013
From: vfeenstr at redhat.com (Vinzenz Feenstra)
Date: Thu, 30 May 2013 14:00:17 +0200
Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics
 Retrieval	Optimization
In-Reply-To: <20130317153038.GB4891@redhat.com>
References: <5145C765.9020602@redhat.com>
	<113426756.9189427.1363530495950.JavaMail.root@redhat.com>
	<20130317153038.GB4891@redhat.com>
Message-ID: <51A73F51.80402@redhat.com>

Hi,

I finally have an update for the proposal ready, after some thinking and 
throwing some ideas around with colleagues we came to the conclusion 
that the best approach might be as followed (without having dynamic 
return values)

I have set up some test engine with 'FakeVDSM' and I am tracking the 
data sent. The system has 250 hosts and about 10000 VMs running. I have 
captured 1.3 GiB TCP data within about 20 minutes only from the 
communication between the engine and the fake VDSM host. In a frame of 
23 minutes I have captured 13.560 getAllVMStats and getAllVdsStats 
calls, and 67827 calls to list.

getAllVmStats replies have produced in that time about 510MiB of data 
transmitted to the engine. This proposal below would reduce the overall 
amount of data significantly and we're preparing to work on a prototype 
for the engine backend as well so we can backup this statement with hard 
numbers.


Here's the proposal.


    VDSM <=> Engine data retrieval optimization


      Motivation:

Currently the oVirt Engine is polling a lot of data from VDSM every 15 
seconds. This should be optimized and the amount of data requested 
should be more specific.

For each VM the data currently contains much more information than 
actually needed which blows up the size of the XML content quite big. We 
could optimize this by splitting the reply on the getVmStats based on 
the needs of the engine into different requests. For this reason Omer 
Frenkel and me have split up the data into parts based on their usage.


      Changes


        New Verbs


          getAllRuntimeStats

Get runtime information of all VMs
Returns for each VM a map with UUID and a value of:

  * *@cpuSys* Ratio of CPU time spent by qemu on other than guest time
  * *@cpuUser* Ratio of CPU time spent by the guest VM
  * *@memUsage* The percent of memory in use by the guest
  * *@elapsedTime* The number of seconds that the VM has been running
  * *@status* The current status of the given VM
  * *@statsAge* The age of these statistics in seconds
  * *@hashes* Hashes of several statistics and information around VMs

Hashes consists of:

  * *@info* Hash for VmConfInfo data
  * *@config* Hash of the VM configuration XML
  * *@status* Hash of the VmStatusInfo data
  * *@guestDetails* Hash of the VmGuestDetails data


          getStatus

Get status information about a list of VMs
Parameters:

  * *@vmIDs* a list of UUIDs for VMs to query

Returns for each VM in vmIDs a map with UUID and a value of:

  * *timeOffset* The time difference from host to the VM in seconds
  * *monitorResponse* Indicates if the qemu monitor is responsive
  * *clientIp* The IP address of the client connected to the display
  * *username* the username associated with the current session
  * *session* The current state of user interaction with the VM
  * *guestIPs* A space separated string of assigned IPv4 addresses
  * *pauseCode* Indicates the reason a VM has been paused


          getConfInfo

Get configuration information about a list of VMs
Parameters:

  * *@vmIDs* a list of UUIDs for VMs to query

Returns for each VM in vmIDs a map with UUID and a value of:

  * *acpiEnable* Indicates if ACPI is enabled inside the VM
  * *displayPort* The port in use for unencrypted display data
  * *displaySecurePort* The port in use for encrypted display data
  * *displayType* The type of display in use
  * *displayIp* The IP address to use for accessing the VM display
  * *pid* The process ID of the underlying qemu process
  * *vmType* The type of VM
  * *kvmEnable* Indicates if KVM hardware acceleration is enabled
  * *cdrom* /*optional*/ The path to an ISO image used in the VM's
    CD-ROM device
  * *boot* /*optional*/ An alias for the type of device used to boot the VM


          getAllDeviceStats

VM device statistics containing information for getting statistics and 
SLA information
Returns for each VM a map with UUID and a value of:

  * *memoryStats* Memory statistics as reported by the guest agent
  * *balloonInfo* Guest memory balloon information
  * *disksUsage* Info about mounted filesystems as reported by the agent
  * *network* Network bandwidth/utilization statistics
  * *disks* Disk bandwidth/utilization statistics


          getGuestDetails

Get details from the guest OS from a list of VMs
Parameters:

  * *@vmIDs* a list of UUIDs for VMs to query

Returns for each VM in vmIDs a map with UUID and a value of:

  * *appsList* A list of installed applications with their versions
  * *netIfaces* Network device address info as reported by the agent


        Usage

Currently the engine is requesting currently every 3 seconds the vm list 
from each vdsm host and every 15 seconds all the data mentioned above 
for all VMs.

The change would be as follows:

The engine requests every 3 seconds getAllRuntimeStats from vdsm which 
will give the engine the most used data. If the engine has a mismatch of 
the hashes returned by getAllRuntimeStats it should request the data 
changed.

if hashes.info changed => request getConfInfo with all vmIDs on that 
host where the hash changed if hashes.status changed => request 
getStatus with all vmIDs on that host where the hash changed if 
hashes.guestDetails changed => request getGuestDetails with all vmIDs on 
that host where the hash changed

Request getAllDeviceStats periodically e.g. every 5 minutes, which 
should be sufficient for the DWH, in case it is not it could be even 
configurable.



On 03/17/2013 04:30 PM, Dan Kenigsberg wrote:
> On Sun, Mar 17, 2013 at 10:28:15AM -0400, Ayal Baron wrote:
>>
>> ----- Original Message -----
>>> On 17/03/13 15:13, Ayal Baron wrote:
>>>> ----- Original Message -----
>>>>> On 03/13/2013 11:55 PM, Ayal Baron wrote:
>>>>> ...
>>>>>>>>> The only reason we have this problem is because there is this
>>>>>>>>> thing against making multiple calls.
>>>>>>>>>
>>>>>>>>> Just split it up.
>>>>>>>>> getVmRuntimeStats() - transient things like mem and cpu%
>>>>>>>>> getVmInformation() - (semi)static things like disk\networking
>>>>>>>>> layout
>>>>>>>>> etc.
>>>>>>>>> Each updated at different intervals.
>>>>>>>> +1 on splitting the data up into 2 separate API calls.
>>>>>>>> You could potentially add a checksum (md5, or any other way) of
>>>>>>>> the
>>>>>>>> "static" data to getVmRuntimeStats and not bother even with
>>>>>>>> polling
>>>>>>>> the VmInformation if this hasn't changed.  Then you could poll
>>>>>>>> as
>>>>>>>> often as you'd like the stats and immediately see if you also
>>>>>>>> need
>>>>>>>> to retrieve VmInfo or not (you rarely would).
>>>>>>> +1 To Ayal's suggestion
>>>>>>> except that instead of the engine hashing the data VDSM sends
>>>>>>> the
>>>>>>> key which is opaque to the engine.
>>>>>>> This can be a local timestap or a generation number.
>>>>>> Of course vdsm does the hash, otherwise you'd need to pass all
>>>>>> the
>>>>>> data to engine which would beat the purpose.
>>>>> I thought you meant engine will be sending the hash of previous
>>>>> requests
>>>>> per VM to vdsm, then vdsm will reply back with vm's removed, vm's
>>>>> added,
>>>>> and the details for vm's that changed (i.e., engine would be doing
>>>>> something like if-modified-since-checksum per vm).
>>>>> benefit is reducing a round trip.
>>>>> but first would need to split to calls of stats (always changing)
>>>>> and
>>>>> slowly/never changing data.
>>>> If vdms accepts the hash then in your method engine would have to
>>>> periodically call getVmInfo(hash).
>>>> What I was suggesting is that getVmStats would return vmInfo hash
>>>> so that we could avoid calling getVmInfo altogether.
>>>> The stats *always* change so there is no need for checking if that
>>>> info has changed.
>>>> What we could do is avoid the split into 2 verbs by calling
>>>> getVmStats(hash) and then have getVmStats return everything if the
>>>> hash has changed or only the stats if it hasn't.  This would be
>>>> the least number of roundtrips and avoid the split.  If you don't
>>>> pass a hash it would return everything so this way it's also fully
>>>> backward compatible.
>>> For the 'static' data, why is there a need for a hash?
>>> If VDSM sends in each update a timestamp, can't RHEVM just use
>>> if-modified-since with the last timestamp it got from VDSM?
>>> Is it cheaper for VDSM to calculate the hash, than update the
>>> timestamp
>>> per change in any of the fields? It doesn't really need to update the
>>> timestamp per change, only for the first change since last update
>>> sent
>>> actually (so 'dirty' flag in a way, to signify data that RHEVM hasn't
>>> seen yet).
>>> Y.
>> As Saggi mentioned: "VDSM sends the key which is opaque to the engine. This can be a local timestap or a generation number."
>>
>> The content doesn't matter, what matters is that it has changed.
>> timestamp assumes that vdsm will track changes and send only delta.
>> Although possible this would be an overkill (for every value in the
>> dict you'd have to hold a timestamp of last change and send only those
>> which have changed since the timestamp which was passed by the user).
> If we're in the spirit of quoting Saggi, this suggestion is not
> compatible with "...mak[ing] the return value differ according to input
> ... is a big no no when talking about type safe APIs.".
>
> Dan.
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel


-- 
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

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

From wei.d.chen at intel.com  Thu May 30 15:21:01 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Thu, 30 May 2013 15:21:01 +0000
Subject: [Engine-devel] cannot execute command in the class of
	InitVdsOnUpCommand
Message-ID: <C5A0092C63E939488005F15F736A81120A5CE6FE@SHSMSX103.ccr.corp.intel.com>

Hi,

We suppose when one VDS is added into cluster, executeCommand method in InitVdsOnUpCommand.java will be invoked, so, some logic will be checked there. But per our experiment, this is depended on what we actually did.
Here are some cases:
1. when reboot VDS, the logic in " executeCommand" will be invoked.
2. when re-deploy engine, the logic in " executeCommand" will be invoked.
3. when we add a new VDS (vdsm is running) into cluster, the logic in " executeCommand" will not be invoked.

What we expect is the logic will also be invoked in the third case, but why it's not invoked? What's behind all of these?


Best Regards,
Dave Chen




From mrao at redhat.com  Thu May 30 15:56:59 2013
From: mrao at redhat.com (Malini Rao)
Date: Thu, 30 May 2013 11:56:59 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <1910975758.14088419.1369830090869.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<201305282105.r4SL5ccM002657@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
	<771394793.7670643.1369779500608.JavaMail.root@redhat.com>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
	<1910975758.14088419.1369830090869.JavaMail.root@redhat.com>
Message-ID: <841607815.31395487.1369929419144.JavaMail.root@redhat.com>

Sorry to join the thread late. The long weekend was followed by a conference for the UX team and hence the delay. See comments below inline - 

----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Daniel Erez" <derez at redhat.com>
> Cc: "Eldan Hildesheim" <info at eldanet.com>, "engine-devel" <engine-devel at ovirt.org>, "Eldan Hildesheim"
> <ehildesh at redhat.com>, "Malini Rao" <mrao at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
> Sent: Wednesday, May 29, 2013 8:21:30 AM
> Subject: Re: [Engine-devel] static header only in VM dialog?
> 
> > ----- Original Message -----
> > From: "Daniel Erez" <derez at redhat.com>
> > Sent: Wednesday, May 29, 2013 1:36:03 AM
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>,
> > > "Eldan Hildesheim" <info at eldanet.com>, "Eldan
> > > Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, May 29, 2013 2:30:09 AM
> > > Subject: Re: static header only in VM dialog?
> > > 
> > > > ----- Original Message -----
> > > > From: "Daniel Erez" <derez at redhat.com>
> > > > Sent: Tuesday, May 28, 2013 6:18:20 PM
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > > To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
> > > > > <info at eldanet.com>,
> > > > > "Eldan Hildesheim" <ehildesh at redhat.com>
> > > > > Cc: "Tomas Jelinek" <tjelinek at redhat.com>, derez at redhat.com,
> > > > > "engine-devel"
> > > > > <engine-devel at ovirt.org>
> > > > > Sent: Wednesday, May 29, 2013 12:53:47 AM
> > > > > Subject: static header only in VM dialog?
> > > > > 
> > > > > when reviewing the code for the "redesign of vm related dialogs",
> > > > > Daniel
> > > > > has
> > > > > raised an interesting question: Why do we want the static header only
> > > > > in
> > > > > VM
> > > > > dialog?
> > > > > 
> > > > > (I assume that he refers to the top section of the New VM dialog as
> > > > > seen
> > > > > in
> > > > > [1], which
> > > > > contains the DC/Cluster, Quota, etc information, and is "static",
> > > > > i.e.,
> > > > > it
> > > > > is
> > > > > always
> > > > > displayed, regardless of the selected side-tab within the dialog)
> > > > > 
> > > > > I agree with what Daniel is implying here: for consistency, we would
> > > > > probably
> > > > > want to
> > > > > introduce this static header to other dialogs, at least to the ones
> > > > > that
> > > > > also
> > > > > contain
> > > > > side-tabs in which it makes sense to turn the "header" to static
> > > > > [e.g.
> > > > > "New Host" (which contains a DC + Cluster "header") - see
> > > > > http://oi39.tinypic.com/2z84xnp.jpg,
> > > > > "New Cluster" (which contains a DC "header") - see
> > > > > http://oi40.tinypic.com/2vmyj2x.jpg]

MR:  Consistency is important but we need to make only UIs with similar purposes consistent and not aim for consistency where it will not serve a real Usability goal or worse get in the way. See next comment for more on UX motivation for this static panel for new VM creation where it was originally proposed.


> > > > > 
> > > > > [I assume, of course, that all the VM-like dialogs (e.g. New/Edit
> > > > > VM-Pool)
> > > > > will also have
> > > > > static headers - I don't know if the patch already takes care of that
> > > > > or
> > > > > not]
> > > > > 
> > > > > Thoughts?
> > > > > 
> > > > > [@Daniel - if you had something else in mind, and/or other dialogs in
> > > > > mind
> > > > > -
> > > > > please feel free
> > > > > to add/amend/etc]

MR: Before we proliferate this UI paradigm into other areas, let us look at the list of dialogs where we are considering this against the primary UX motivations with which this static panel was originally suggested. UX can help with this exercise on where it makes sense to have the static panel.

> > > > 
> > > > Besides consistency matters, I wanted to understand what's the
> > > > motivation
> > > > of
> > > > keeping these widgets static. I.e. is it an essential preparation for
> > > > the
> > > > new
> > > > instance type dialog or a new concept for tab based dialogs
> > > > (as DC/Cluster values aren't necessarily relevant for each tab in the
> > > > dialog)
> > > 
> > > [maybe Tomas/Eldan/Malini can help here as well]


MR: Here are the original motivations for this static panel. 

1. Context for dependencies - In the create VM dialog and the introduction of instance types and images, we came up with two core needs for the UI - There were some fields that were context-setting for other fields with dependencies. So, changing these context setting field values would alter the choices in other fields on one of the sub-tabs or eliminate or populate fields in these tabs. We wanted to ground the user with the context so that they can observe any changes that happen on a tab and determine what caused that change in the static panel. 

2. Basic and mandatory - In the create VM dialog and the introduction of instance types and images, we also had to represent different levels of definition needed. For e.g, there were some basic and mandatory fields that were minimally needed for the definition of a VM irrespective of whether the user was basic or advanced. These fields were included in the static panel or at the most in the very first sub tab if they were not a context setting field for any other dependent field. This way the user does not have to go anywhere else to do a basic definition of the VM. 

Then we had another layer of permissioning where the fields you had access to on various tabs depended on whether you were a basic or advanced user. But note, we did have scenarios where some advanced fields made it to the static panel because they were a context setter. 

So to summarize the motivation of why the static panel and what should go into the static panel - You need a static panel ONLY if you have certain fields (basic or advanced) that act as context setters for all or some of the other fields in the other sub-tabs. Static panels can further optionally be extended to present all the fields that are needed for basic definition of an object. If there is no dependency and there is a dialog with multiple sub-tabs, then we SHOULD NOT just create a static panel for the basic definition fields. These fields should populate the first sub tab. Let me know if any further clarifications are needed.

 

> > > 
> > > these static widgets (as well as the type ahead list box [1], for
> > > example)
> > > are part of
> > > the instance types feature that had its design details published in [2]
> > > and
> > > [3], and the
> > > implementation was done according to this design. I don't see any reason
> > > to
> > > not utilize
> > > this newly-introduced concept in other side-tab-based dialogs as well, if
> > > it
> > > makes sense
> > > (ui consistency considerations are sufficient, IMO, but I could be wrong
> > > -
> > > maybe it is
> > > relevant/correct to introduce this new concept only in the VM-like
> > > dialogs).


MR: The UX motivations for the static panel are generalizable even though they were designed for the New VM dialog. See above comment. But we need to gauge the reqs on each of the dialogs with subtabs against the core motivation and see if we need the static panel on it or not.


> > > 
> > > regarding the specific concern about the DC/Cluster values that aren't
> > > necessarily relevant
> > > for each side-tab in the dialog: I agree with that statement, 

MR: If any field recommended in the UX proposal is not useful as a context setter, then please let us know and we can move it to the first sub-tab.


however:
> > > 
> > > - putting the "Instance Type" drop-down at the top static section is very
> > > useful (see [4]
> > > for explanation), and as the Instance Types list is derived from the
> > > selected
> > > DC, it makes
> > > sense (to me) to put the DC in that top static section as well.

MR: Agree. That is probably why we ended up leaving the DC there.


> > > 
> > > - the DC/Cluster are relevant for some of the tabs in the dialog (Host,
> > > Resource Allocation?)
> > 
> > Only for Host.
> > Resource Allocation is directly affected by the selected template.
> > Therefore, it sounds very confusing to me...
> > Unless we add template to the static header as well?


MR: I think we incorporated the templates into the Image field and denoted it with an icon preceding the drop down choice. So, the template is in the static panel.


> 
> The answer is yes, in a sense: Instance Types + Images are actually
> somewhat "replacing" Templates [the general approach is to move to
> basing VMs on Instance Types + Images, rather than on Templates;
> it allows more flexibility in combining hardware configuration + image
> configuration for the VM, without (necessarily) editing each VM field
> separately].
> 
> So as I stated in my previous response: Having the "Instance Types"
> field (and "Image" field) in the top static section is very useful, as
> they affect the fields in most / a lot of the side-tabs.
> 
> Based on the above:
> 
> Do you agree that it makes sense to have a top static section in general
> [even only for the "Instance Types" field and "Image" field (again, as
> they affect most / a lot of side-tabs fields)]?
> If so: Do you think that it makes sense to include the DC field in that
> top static section as well (at least due to the fact that the "Instance
> Types" list and "Images" list are derived from the selected DC)?

MR: Yes makes sense to include DC in static panel because some of the other fields in the static panel are dependent on it.


> 
> [Tomas/Malini/Eldan - if there is additional/different reasoning for putting
> the DC/Cluster field on the top static section - please share]
> 
> > (which will be odd for the other tabs).
> > 
> > So I still don't get the motivation UX-wise.
> > E.g. it seems really weird to change the entire DC from Console tab
> > (or, as a matter of fact, from most other tabs).

MR: Not sure I understand. You can change DC when you are on ANY sub tab because the DC is a field in the static panel. The static panel is not the sub-tab.


> > In the new instance type dialog, which tabs could be directly affected by
> > DC/Cluster?
> > IIUC, only Host? Do we really need a static header just for this tab?

MR: Ideally, if we have only one sub-tab that has some dependencies with some basic fields, we should try to design the first sub-tab to have all those fields and eliminate the static panel. But if it is weird to have those additional fields on the very first sub-tab from a workflow perspective, then we should have the static panel even if the dependency is only on one sub-tab. The rule we are going by then is that it doesn't hurt to have context info on the top but it hurts more to not have that context info when needed.


> > 
> > > so for consistency-within-the-dialog considerations, it is probably a
> > > good
> > > idea to simply
> > > always show these fields within this top static section.
> > > 
> > > [there is a good chance that I am missing your point here - please
> > > correct
> > > me
> > > if necessary]
> > > 
> > > [1] http://gerrit.ovirt.org/#/c/14936/
> > > 
> > > [2] http://www.ovirt.org/Features/Instance_Types
> > > 
> > > [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> > > 
> > > [4] whenever changing the "Instance Type" value, you can automatically
> > > see
> > > how these changes
> > > affect the fields in the current tab on which you are standing (e.g. if
> > > you
> > > are standing on
> > > the "System" side-tab, you can change the "Instance Type" selected item
> > > and
> > > immediately see
> > > the changes within the "System" side-tab contents), and vice-versa: if
> > > you
> > > are changing a value
> > > that was originally propagated from the instance-type, you will see the
> > > instance-type automatically
> > > change to "custom"/"not applicable" as a result, so no need to "jump"
> > > between
> > > side-tabs in order
> > > to observe these changes.
> > > 
> > > > 
> > > > > 
> > > > > ----
> > > > > Thanks,
> > > > > Einav
> > > > > 
> > > > > [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: derez at redhat.com
> > > > > > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > > > > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> > > > > > <ecohen at redhat.com>,
> > > > > > "Frank Kobzik" <fkobzik at redhat.com>,
> > > > > > "Eldan Hildesheim" <info at eldanet.com>
> > > > > > Sent: Tuesday, May 28, 2013 5:05:38 PM
> > > > > > Subject: Change in ovirt-engine[master]: userportal,webadmin:
> > > > > > redesign
> > > > > > of
> > > > > > vm related dialogs
> > > > > > 
> > > > > > Daniel Erez has posted comments on this change.
> > > > > > 
> > > > > > Change subject: userportal,webadmin: redesign of vm related dialogs
> > > > > > ......................................................................
> > > > > > 
> > > > > > 
> > > > > > Patch Set 5: (1 inline comment)
> > > > > > 
> > > > > > Code looks good.
> > > > > > A few questions regarding the design:
> > > > > > 1. Why do we want the static header only in VM dialog?
> > > > > > 2. DC/Host are really relevant for all tabs?
> > > > > > 3. Is it just a preparation for the final instance type dialog?
> > > > > > 4. If it's indeed merely preparation, shouldn't it be merged only
> > > > > > once
> > > > > > we
> > > > > > have the full picture of the new dialog?
> > > > > > 
> > > > > > ....................................................
> > > > > > File
> > > > > > frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> > > > > > Line 21:
> > > > > > Line 22: 		.header {
> > > > > > Line 23: 			background-color: #D3D3D3;
> > > > > > Line 24: 			border-bottom: 1px solid #CED8DF;
> > > > > > Line 25: 			margin-bottom: 15px;
> > > > > > is it supposed to be that large?
> > > > > > Line 26: 			padding-top: 6px;
> > > > > > Line 27: 			margin-top: 4px;
> > > > > > Line 28: 			margin-right: 3px;
> > > > > > Line 29: 			display: none;
> > > > > > 
> > > > > > 
> > > > > > --
> > > > > > To view, visit http://gerrit.ovirt.org/14635
> > > > > > To unsubscribe, visit http://gerrit.ovirt.org/settings
> > > > > > 
> > > > > > Gerrit-MessageType: comment
> > > > > > Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> > > > > > Gerrit-PatchSet: 5
> > > > > > Gerrit-Project: ovirt-engine
> > > > > > Gerrit-Branch: master
> > > > > > Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
> > > > > > Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
> > > > > > Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
> > > > > > Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
> > > > > > Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
> > > > > > Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
> > > > > > Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
> > > > > > 
> > > > > 
> > > > 
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> 


From tjelinek at redhat.com  Fri May 31 06:22:57 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Fri, 31 May 2013 02:22:57 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <841607815.31395487.1369929419144.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<201305282105.r4SL5ccM002657@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
	<771394793.7670643.1369779500608.JavaMail.root@redhat.com>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
	<1910975758.14088419.1369830090869.JavaMail.root@redhat.com>
	<841607815.31395487.1369929419144.JavaMail.root@redhat.com>
Message-ID: <2014639425.11839457.1369981377910.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Malini Rao" <mrao at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "Daniel Erez" <derez at redhat.com>, "Eldan Hildesheim" <info at eldanet.com>, "engine-devel" <engine-devel at ovirt.org>,
> "Eldan Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
> Sent: Thursday, May 30, 2013 5:56:59 PM
> Subject: Re: [Engine-devel] static header only in VM dialog?
> 
> Sorry to join the thread late. The long weekend was followed by a conference
> for the UX team and hence the delay. See comments below inline -
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Daniel Erez" <derez at redhat.com>
> > Cc: "Eldan Hildesheim" <info at eldanet.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "Eldan Hildesheim"
> > <ehildesh at redhat.com>, "Malini Rao" <mrao at redhat.com>, "Tomas Jelinek"
> > <tjelinek at redhat.com>
> > Sent: Wednesday, May 29, 2013 8:21:30 AM
> > Subject: Re: [Engine-devel] static header only in VM dialog?
> > 
> > > ----- Original Message -----
> > > From: "Daniel Erez" <derez at redhat.com>
> > > Sent: Wednesday, May 29, 2013 1:36:03 AM
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > To: "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>,
> > > > "Eldan Hildesheim" <info at eldanet.com>, "Eldan
> > > > Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek"
> > > > <tjelinek at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Wednesday, May 29, 2013 2:30:09 AM
> > > > Subject: Re: static header only in VM dialog?
> > > > 
> > > > > ----- Original Message -----
> > > > > From: "Daniel Erez" <derez at redhat.com>
> > > > > Sent: Tuesday, May 28, 2013 6:18:20 PM
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > > > To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
> > > > > > <info at eldanet.com>,
> > > > > > "Eldan Hildesheim" <ehildesh at redhat.com>
> > > > > > Cc: "Tomas Jelinek" <tjelinek at redhat.com>, derez at redhat.com,
> > > > > > "engine-devel"
> > > > > > <engine-devel at ovirt.org>
> > > > > > Sent: Wednesday, May 29, 2013 12:53:47 AM
> > > > > > Subject: static header only in VM dialog?
> > > > > > 
> > > > > > when reviewing the code for the "redesign of vm related dialogs",
> > > > > > Daniel
> > > > > > has
> > > > > > raised an interesting question: Why do we want the static header
> > > > > > only
> > > > > > in
> > > > > > VM
> > > > > > dialog?
> > > > > > 
> > > > > > (I assume that he refers to the top section of the New VM dialog as
> > > > > > seen
> > > > > > in
> > > > > > [1], which
> > > > > > contains the DC/Cluster, Quota, etc information, and is "static",
> > > > > > i.e.,
> > > > > > it
> > > > > > is
> > > > > > always
> > > > > > displayed, regardless of the selected side-tab within the dialog)
> > > > > > 
> > > > > > I agree with what Daniel is implying here: for consistency, we
> > > > > > would
> > > > > > probably
> > > > > > want to
> > > > > > introduce this static header to other dialogs, at least to the ones
> > > > > > that
> > > > > > also
> > > > > > contain
> > > > > > side-tabs in which it makes sense to turn the "header" to static
> > > > > > [e.g.
> > > > > > "New Host" (which contains a DC + Cluster "header") - see
> > > > > > http://oi39.tinypic.com/2z84xnp.jpg,
> > > > > > "New Cluster" (which contains a DC "header") - see
> > > > > > http://oi40.tinypic.com/2vmyj2x.jpg]
> 
> MR:  Consistency is important but we need to make only UIs with similar
> purposes consistent and not aim for consistency where it will not serve a
> real Usability goal or worse get in the way. See next comment for more on UX
> motivation for this static panel for new VM creation where it was originally
> proposed.
> 
> 
> > > > > > 
> > > > > > [I assume, of course, that all the VM-like dialogs (e.g. New/Edit
> > > > > > VM-Pool)
> > > > > > will also have
> > > > > > static headers - I don't know if the patch already takes care of
> > > > > > that
> > > > > > or
> > > > > > not]
> > > > > > 
> > > > > > Thoughts?
> > > > > > 
> > > > > > [@Daniel - if you had something else in mind, and/or other dialogs
> > > > > > in
> > > > > > mind
> > > > > > -
> > > > > > please feel free
> > > > > > to add/amend/etc]
> 
> MR: Before we proliferate this UI paradigm into other areas, let us look at
> the list of dialogs where we are considering this against the primary UX
> motivations with which this static panel was originally suggested. UX can
> help with this exercise on where it makes sense to have the static panel.
> 
> > > > > 
> > > > > Besides consistency matters, I wanted to understand what's the
> > > > > motivation
> > > > > of
> > > > > keeping these widgets static. I.e. is it an essential preparation for
> > > > > the
> > > > > new
> > > > > instance type dialog or a new concept for tab based dialogs
> > > > > (as DC/Cluster values aren't necessarily relevant for each tab in the
> > > > > dialog)
> > > > 
> > > > [maybe Tomas/Eldan/Malini can help here as well]
> 
> 
> MR: Here are the original motivations for this static panel.
> 
> 1. Context for dependencies - In the create VM dialog and the introduction of
> instance types and images, we came up with two core needs for the UI - There
> were some fields that were context-setting for other fields with
> dependencies. So, changing these context setting field values would alter
> the choices in other fields on one of the sub-tabs or eliminate or populate
> fields in these tabs. We wanted to ground the user with the context so that
> they can observe any changes that happen on a tab and determine what caused
> that change in the static panel.
> 
> 2. Basic and mandatory - In the create VM dialog and the introduction of
> instance types and images, we also had to represent different levels of
> definition needed. For e.g, there were some basic and mandatory fields that
> were minimally needed for the definition of a VM irrespective of whether the
> user was basic or advanced. These fields were included in the static panel
> or at the most in the very first sub tab if they were not a context setting
> field for any other dependent field. This way the user does not have to go
> anywhere else to do a basic definition of the VM.
> 
> Then we had another layer of permissioning where the fields you had access to
> on various tabs depended on whether you were a basic or advanced user. But
> note, we did have scenarios where some advanced fields made it to the static
> panel because they were a context setter.
> 
> So to summarize the motivation of why the static panel and what should go
> into the static panel - You need a static panel ONLY if you have certain
> fields (basic or advanced) that act as context setters for all or some of
> the other fields in the other sub-tabs. Static panels can further optionally
> be extended to present all the fields that are needed for basic definition
> of an object. If there is no dependency and there is a dialog with multiple
> sub-tabs, then we SHOULD NOT just create a static panel for the basic
> definition fields. These fields should populate the first sub tab. Let me
> know if any further clarifications are needed.
> 
>  
> 
> > > > 
> > > > these static widgets (as well as the type ahead list box [1], for
> > > > example)
> > > > are part of
> > > > the instance types feature that had its design details published in [2]
> > > > and
> > > > [3], and the
> > > > implementation was done according to this design. I don't see any
> > > > reason
> > > > to
> > > > not utilize
> > > > this newly-introduced concept in other side-tab-based dialogs as well,
> > > > if
> > > > it
> > > > makes sense
> > > > (ui consistency considerations are sufficient, IMO, but I could be
> > > > wrong
> > > > -
> > > > maybe it is
> > > > relevant/correct to introduce this new concept only in the VM-like
> > > > dialogs).
> 
> 
> MR: The UX motivations for the static panel are generalizable even though
> they were designed for the New VM dialog. See above comment. But we need to
> gauge the reqs on each of the dialogs with subtabs against the core
> motivation and see if we need the static panel on it or not.
> 
> 
> > > > 
> > > > regarding the specific concern about the DC/Cluster values that aren't
> > > > necessarily relevant
> > > > for each side-tab in the dialog: I agree with that statement,
> 
> MR: If any field recommended in the UX proposal is not useful as a context
> setter, then please let us know and we can move it to the first sub-tab.
> 
> 
> however:
> > > > 
> > > > - putting the "Instance Type" drop-down at the top static section is
> > > > very
> > > > useful (see [4]
> > > > for explanation), and as the Instance Types list is derived from the
> > > > selected
> > > > DC, it makes
> > > > sense (to me) to put the DC in that top static section as well.
> 
> MR: Agree. That is probably why we ended up leaving the DC there.
> 
> 
> > > > 
> > > > - the DC/Cluster are relevant for some of the tabs in the dialog (Host,
> > > > Resource Allocation?)
> > > 
> > > Only for Host.
> > > Resource Allocation is directly affected by the selected template.
> > > Therefore, it sounds very confusing to me...
> > > Unless we add template to the static header as well?
> 
> 
> MR: I think we incorporated the templates into the Image field and denoted it
> with an icon preceding the drop down choice. So, the template is in the
> static panel.
Just a small note:  the first patch we are talking about (http://gerrit.ovirt.org/#/c/14635)
adds only Data Center, Cluster and Quota to the header. 
There is a second patch (http://gerrit.ovirt.org/#/c/15011/) which moves the OS type and 
template to the header.
The Image and Instance Type fields are not implemented yet. The current patches just redesigns
the current UX according to the mockups - the new entities will be integrated after we will have
an agreement and this batch of patches will be merged.
> 
> 
> > 
> > The answer is yes, in a sense: Instance Types + Images are actually
> > somewhat "replacing" Templates [the general approach is to move to
> > basing VMs on Instance Types + Images, rather than on Templates;
> > it allows more flexibility in combining hardware configuration + image
> > configuration for the VM, without (necessarily) editing each VM field
> > separately].
> > 
> > So as I stated in my previous response: Having the "Instance Types"
> > field (and "Image" field) in the top static section is very useful, as
> > they affect the fields in most / a lot of the side-tabs.
> > 
> > Based on the above:
> > 
> > Do you agree that it makes sense to have a top static section in general
> > [even only for the "Instance Types" field and "Image" field (again, as
> > they affect most / a lot of side-tabs fields)]?
> > If so: Do you think that it makes sense to include the DC field in that
> > top static section as well (at least due to the fact that the "Instance
> > Types" list and "Images" list are derived from the selected DC)?
> 
> MR: Yes makes sense to include DC in static panel because some of the other
> fields in the static panel are dependent on it.
> 
> 
> > 
> > [Tomas/Malini/Eldan - if there is additional/different reasoning for
> > putting
> > the DC/Cluster field on the top static section - please share]
> > 
> > > (which will be odd for the other tabs).
> > > 
> > > So I still don't get the motivation UX-wise.
> > > E.g. it seems really weird to change the entire DC from Console tab
> > > (or, as a matter of fact, from most other tabs).
> 
> MR: Not sure I understand. You can change DC when you are on ANY sub tab
> because the DC is a field in the static panel. The static panel is not the
> sub-tab.
> 
> 
> > > In the new instance type dialog, which tabs could be directly affected by
> > > DC/Cluster?
> > > IIUC, only Host? Do we really need a static header just for this tab?
> 
> MR: Ideally, if we have only one sub-tab that has some dependencies with some
> basic fields, we should try to design the first sub-tab to have all those
> fields and eliminate the static panel. But if it is weird to have those
> additional fields on the very first sub-tab from a workflow perspective,
> then we should have the static panel even if the dependency is only on one
> sub-tab. The rule we are going by then is that it doesn't hurt to have
> context info on the top but it hurts more to not have that context info when
> needed.
> 
> 
> > > 
> > > > so for consistency-within-the-dialog considerations, it is probably a
> > > > good
> > > > idea to simply
> > > > always show these fields within this top static section.
> > > > 
> > > > [there is a good chance that I am missing your point here - please
> > > > correct
> > > > me
> > > > if necessary]
> > > > 
> > > > [1] http://gerrit.ovirt.org/#/c/14936/
> > > > 
> > > > [2] http://www.ovirt.org/Features/Instance_Types
> > > > 
> > > > [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> > > > 
> > > > [4] whenever changing the "Instance Type" value, you can automatically
> > > > see
> > > > how these changes
> > > > affect the fields in the current tab on which you are standing (e.g. if
> > > > you
> > > > are standing on
> > > > the "System" side-tab, you can change the "Instance Type" selected item
> > > > and
> > > > immediately see
> > > > the changes within the "System" side-tab contents), and vice-versa: if
> > > > you
> > > > are changing a value
> > > > that was originally propagated from the instance-type, you will see the
> > > > instance-type automatically
> > > > change to "custom"/"not applicable" as a result, so no need to "jump"
> > > > between
> > > > side-tabs in order
> > > > to observe these changes.
> > > > 
> > > > > 
> > > > > > 
> > > > > > ----
> > > > > > Thanks,
> > > > > > Einav
> > > > > > 
> > > > > > [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: derez at redhat.com
> > > > > > > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > > > > > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> > > > > > > <ecohen at redhat.com>,
> > > > > > > "Frank Kobzik" <fkobzik at redhat.com>,
> > > > > > > "Eldan Hildesheim" <info at eldanet.com>
> > > > > > > Sent: Tuesday, May 28, 2013 5:05:38 PM
> > > > > > > Subject: Change in ovirt-engine[master]: userportal,webadmin:
> > > > > > > redesign
> > > > > > > of
> > > > > > > vm related dialogs
> > > > > > > 
> > > > > > > Daniel Erez has posted comments on this change.
> > > > > > > 
> > > > > > > Change subject: userportal,webadmin: redesign of vm related
> > > > > > > dialogs
> > > > > > > ......................................................................
> > > > > > > 
> > > > > > > 
> > > > > > > Patch Set 5: (1 inline comment)
> > > > > > > 
> > > > > > > Code looks good.
> > > > > > > A few questions regarding the design:
> > > > > > > 1. Why do we want the static header only in VM dialog?
> > > > > > > 2. DC/Host are really relevant for all tabs?
> > > > > > > 3. Is it just a preparation for the final instance type dialog?
> > > > > > > 4. If it's indeed merely preparation, shouldn't it be merged only
> > > > > > > once
> > > > > > > we
> > > > > > > have the full picture of the new dialog?
> > > > > > > 
> > > > > > > ....................................................
> > > > > > > File
> > > > > > > frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> > > > > > > Line 21:
> > > > > > > Line 22: 		.header {
> > > > > > > Line 23: 			background-color: #D3D3D3;
> > > > > > > Line 24: 			border-bottom: 1px solid #CED8DF;
> > > > > > > Line 25: 			margin-bottom: 15px;
> > > > > > > is it supposed to be that large?
> > > > > > > Line 26: 			padding-top: 6px;
> > > > > > > Line 27: 			margin-top: 4px;
> > > > > > > Line 28: 			margin-right: 3px;
> > > > > > > Line 29: 			display: none;
> > > > > > > 
> > > > > > > 
> > > > > > > --
> > > > > > > To view, visit http://gerrit.ovirt.org/14635
> > > > > > > To unsubscribe, visit http://gerrit.ovirt.org/settings
> > > > > > > 
> > > > > > > Gerrit-MessageType: comment
> > > > > > > Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> > > > > > > Gerrit-PatchSet: 5
> > > > > > > Gerrit-Project: ovirt-engine
> > > > > > > Gerrit-Branch: master
> > > > > > > Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
> > > > > > > Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
> > > > > > > Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
> > > > > > > Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
> > > > > > > Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
> > > > > > > Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
> > > > > > > Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
> > > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > > 
> > > 
> > 
> 


From eedri at redhat.com  Fri May 31 06:34:49 2013
From: eedri at redhat.com (Eyal Edri)
Date: Fri, 31 May 2013 02:34:49 -0400 (EDT)
Subject: [Engine-devel] [JENKINS][GERRIT][ANN] new jenkins jobs added to run
 per patch on ovirt-engine
In-Reply-To: <241411444.1546622.1369981917738.JavaMail.root@redhat.com>
Message-ID: <2110907785.1548621.1369982089698.JavaMail.root@redhat.com>

fyi,

starting from now a new jenkins job [1] will run on every patch in ovirt-engine that has java files in it. 
the job will verify:

 1. compilation
 2. findbugs (HIGH + NORMAL)

if your patch will fail in one of the above, jenkins will give -1 to the patch and you'll have to send a new patchset to fix it.
if the failure was not justified (infra error/network/etc...) - contact infra at ovirt.org and you can re-trigger your job manually [2],
by searching for your commit sha or changeid.


Eyal Edri
ovirt infra team.


[1] http://jenkins.ovirt.org/job/ovirt_engine_find_bugs_gerrit/
[2] http://jenkins.ovirt.org/gerrit_manual_trigger/?


From ecohen at redhat.com  Fri May 31 11:44:59 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Fri, 31 May 2013 07:44:59 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <2014639425.11839457.1369981377910.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
	<771394793.7670643.1369779500608.JavaMail.root@redhat.com>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
	<1910975758.14088419.1369830090869.JavaMail.root@redhat.com>
	<841607815.31395487.1369929419144.JavaMail.root@redhat.com>
	<2014639425.11839457.1369981377910.JavaMail.root@redhat.com>
Message-ID: <1493549047.16382669.1370000699204.JavaMail.root@redhat.com>

> ----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> Sent: Friday, May 31, 2013 2:22:57 AM
> 
> 
> 
> ----- Original Message -----
> > From: "Malini Rao" <mrao at redhat.com>
> > To: "Einav Cohen" <ecohen at redhat.com>
> > Cc: "Daniel Erez" <derez at redhat.com>, "Eldan Hildesheim"
> > <info at eldanet.com>, "engine-devel" <engine-devel at ovirt.org>,
> > "Eldan Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek"
> > <tjelinek at redhat.com>
> > Sent: Thursday, May 30, 2013 5:56:59 PM
> > Subject: Re: [Engine-devel] static header only in VM dialog?
> > 
> > Sorry to join the thread late. The long weekend was followed by a
> > conference
> > for the UX team and hence the delay. See comments below inline -
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "Daniel Erez" <derez at redhat.com>
> > > Cc: "Eldan Hildesheim" <info at eldanet.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, "Eldan Hildesheim"
> > > <ehildesh at redhat.com>, "Malini Rao" <mrao at redhat.com>, "Tomas Jelinek"
> > > <tjelinek at redhat.com>
> > > Sent: Wednesday, May 29, 2013 8:21:30 AM
> > > Subject: Re: [Engine-devel] static header only in VM dialog?
> > > 
> > > > ----- Original Message -----
> > > > From: "Daniel Erez" <derez at redhat.com>
> > > > Sent: Wednesday, May 29, 2013 1:36:03 AM
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > > To: "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>,
> > > > > "Eldan Hildesheim" <info at eldanet.com>, "Eldan
> > > > > Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek"
> > > > > <tjelinek at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Wednesday, May 29, 2013 2:30:09 AM
> > > > > Subject: Re: static header only in VM dialog?
> > > > > 
> > > > > > ----- Original Message -----
> > > > > > From: "Daniel Erez" <derez at redhat.com>
> > > > > > Sent: Tuesday, May 28, 2013 6:18:20 PM
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > > > > To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
> > > > > > > <info at eldanet.com>,
> > > > > > > "Eldan Hildesheim" <ehildesh at redhat.com>
> > > > > > > Cc: "Tomas Jelinek" <tjelinek at redhat.com>, derez at redhat.com,
> > > > > > > "engine-devel"
> > > > > > > <engine-devel at ovirt.org>
> > > > > > > Sent: Wednesday, May 29, 2013 12:53:47 AM
> > > > > > > Subject: static header only in VM dialog?
> > > > > > > 
> > > > > > > when reviewing the code for the "redesign of vm related dialogs",
> > > > > > > Daniel
> > > > > > > has
> > > > > > > raised an interesting question: Why do we want the static header
> > > > > > > only
> > > > > > > in
> > > > > > > VM
> > > > > > > dialog?
> > > > > > > 
> > > > > > > (I assume that he refers to the top section of the New VM dialog
> > > > > > > as
> > > > > > > seen
> > > > > > > in
> > > > > > > [1], which
> > > > > > > contains the DC/Cluster, Quota, etc information, and is "static",
> > > > > > > i.e.,
> > > > > > > it
> > > > > > > is
> > > > > > > always
> > > > > > > displayed, regardless of the selected side-tab within the dialog)
> > > > > > > 
> > > > > > > I agree with what Daniel is implying here: for consistency, we
> > > > > > > would
> > > > > > > probably
> > > > > > > want to
> > > > > > > introduce this static header to other dialogs, at least to the
> > > > > > > ones
> > > > > > > that
> > > > > > > also
> > > > > > > contain
> > > > > > > side-tabs in which it makes sense to turn the "header" to static
> > > > > > > [e.g.
> > > > > > > "New Host" (which contains a DC + Cluster "header") - see
> > > > > > > http://oi39.tinypic.com/2z84xnp.jpg,
> > > > > > > "New Cluster" (which contains a DC "header") - see
> > > > > > > http://oi40.tinypic.com/2vmyj2x.jpg]
> > 
> > MR:  Consistency is important but we need to make only UIs with similar
> > purposes consistent and not aim for consistency where it will not serve a
> > real Usability goal or worse get in the way. See next comment for more on
> > UX
> > motivation for this static panel for new VM creation where it was
> > originally
> > proposed.
> > 
> > 
> > > > > > > 
> > > > > > > [I assume, of course, that all the VM-like dialogs (e.g. New/Edit
> > > > > > > VM-Pool)
> > > > > > > will also have
> > > > > > > static headers - I don't know if the patch already takes care of
> > > > > > > that
> > > > > > > or
> > > > > > > not]
> > > > > > > 
> > > > > > > Thoughts?
> > > > > > > 
> > > > > > > [@Daniel - if you had something else in mind, and/or other
> > > > > > > dialogs
> > > > > > > in
> > > > > > > mind
> > > > > > > -
> > > > > > > please feel free
> > > > > > > to add/amend/etc]
> > 
> > MR: Before we proliferate this UI paradigm into other areas, let us look at
> > the list of dialogs where we are considering this against the primary UX
> > motivations with which this static panel was originally suggested. UX can
> > help with this exercise on where it makes sense to have the static panel.
> > 
> > > > > > 
> > > > > > Besides consistency matters, I wanted to understand what's the
> > > > > > motivation
> > > > > > of
> > > > > > keeping these widgets static. I.e. is it an essential preparation
> > > > > > for
> > > > > > the
> > > > > > new
> > > > > > instance type dialog or a new concept for tab based dialogs
> > > > > > (as DC/Cluster values aren't necessarily relevant for each tab in
> > > > > > the
> > > > > > dialog)
> > > > > 
> > > > > [maybe Tomas/Eldan/Malini can help here as well]
> > 
> > 
> > MR: Here are the original motivations for this static panel.
> > 
> > 1. Context for dependencies - In the create VM dialog and the introduction
> > of
> > instance types and images, we came up with two core needs for the UI -
> > There
> > were some fields that were context-setting for other fields with
> > dependencies. So, changing these context setting field values would alter
> > the choices in other fields on one of the sub-tabs or eliminate or populate
> > fields in these tabs. We wanted to ground the user with the context so that
> > they can observe any changes that happen on a tab and determine what caused
> > that change in the static panel.
> > 
> > 2. Basic and mandatory - In the create VM dialog and the introduction of
> > instance types and images, we also had to represent different levels of
> > definition needed. For e.g, there were some basic and mandatory fields that
> > were minimally needed for the definition of a VM irrespective of whether
> > the
> > user was basic or advanced. These fields were included in the static panel
> > or at the most in the very first sub tab if they were not a context setting
> > field for any other dependent field. This way the user does not have to go
> > anywhere else to do a basic definition of the VM.
> > 
> > Then we had another layer of permissioning where the fields you had access
> > to
> > on various tabs depended on whether you were a basic or advanced user. But
> > note, we did have scenarios where some advanced fields made it to the
> > static
> > panel because they were a context setter.
> > 
> > So to summarize the motivation of why the static panel and what should go
> > into the static panel - You need a static panel ONLY if you have certain
> > fields (basic or advanced) that act as context setters for all or some of
> > the other fields in the other sub-tabs. Static panels can further
> > optionally
> > be extended to present all the fields that are needed for basic definition
> > of an object. If there is no dependency and there is a dialog with multiple
> > sub-tabs, then we SHOULD NOT just create a static panel for the basic
> > definition fields. These fields should populate the first sub tab. Let me
> > know if any further clarifications are needed.
> > 
> >  
> > 
> > > > > 
> > > > > these static widgets (as well as the type ahead list box [1], for
> > > > > example)
> > > > > are part of
> > > > > the instance types feature that had its design details published in
> > > > > [2]
> > > > > and
> > > > > [3], and the
> > > > > implementation was done according to this design. I don't see any
> > > > > reason
> > > > > to
> > > > > not utilize
> > > > > this newly-introduced concept in other side-tab-based dialogs as
> > > > > well,
> > > > > if
> > > > > it
> > > > > makes sense
> > > > > (ui consistency considerations are sufficient, IMO, but I could be
> > > > > wrong
> > > > > -
> > > > > maybe it is
> > > > > relevant/correct to introduce this new concept only in the VM-like
> > > > > dialogs).
> > 
> > 
> > MR: The UX motivations for the static panel are generalizable even though
> > they were designed for the New VM dialog. See above comment. But we need to
> > gauge the reqs on each of the dialogs with subtabs against the core
> > motivation and see if we need the static panel on it or not.
> > 
> > 
> > > > > 
> > > > > regarding the specific concern about the DC/Cluster values that
> > > > > aren't
> > > > > necessarily relevant
> > > > > for each side-tab in the dialog: I agree with that statement,
> > 
> > MR: If any field recommended in the UX proposal is not useful as a context
> > setter, then please let us know and we can move it to the first sub-tab.
> > 
> > 
> > however:
> > > > > 
> > > > > - putting the "Instance Type" drop-down at the top static section is
> > > > > very
> > > > > useful (see [4]
> > > > > for explanation), and as the Instance Types list is derived from the
> > > > > selected
> > > > > DC, it makes
> > > > > sense (to me) to put the DC in that top static section as well.
> > 
> > MR: Agree. That is probably why we ended up leaving the DC there.
> > 
> > 
> > > > > 
> > > > > - the DC/Cluster are relevant for some of the tabs in the dialog
> > > > > (Host,
> > > > > Resource Allocation?)
> > > > 
> > > > Only for Host.
> > > > Resource Allocation is directly affected by the selected template.
> > > > Therefore, it sounds very confusing to me...
> > > > Unless we add template to the static header as well?
> > 
> > 
> > MR: I think we incorporated the templates into the Image field and denoted
> > it
> > with an icon preceding the drop down choice. So, the template is in the
> > static panel.
> 
> Just a small note:  the first patch we are talking about
> (http://gerrit.ovirt.org/#/c/14635)
> adds only Data Center, Cluster and Quota to the header.
> There is a second patch (http://gerrit.ovirt.org/#/c/15011/) which moves the
> OS type and
> template to the header.
> The Image and Instance Type fields are not implemented yet. The current
> patches just redesigns
> the current UX according to the mockups - the new entities will be integrated
> after we will have
> an agreement and this batch of patches will be merged.

OK, that explains a lot... :) many thanks, Tomas, for the clarification.

I understand now Daniels's concern; it indeed doesn't make much sense for the 
DC/Cluster and Quota fields to be the only fields in the top static section.
However, as this is a preparation for the Instance Types fields patches, it 
makes sense that we will first do the preparation work (i.e. change/reorganize 
the existing dialog layout), and then incorporate the Instance Types fields into 
it (given that it is being done *shortly* afterwards), or simply do everything 
altogether.

@Tomas - ideally, the code that actually adds the Instance Types fields should have 
been part of this patch chain (either in more patches, or in "larger" patches), as again - 
I agree with Daniel that it makes no sense to having a static header in the VM dialogs 
with only DC/Cluster and Quota in them [1].
However, there is a chance that it would have been resulted in very large patches / a 
very long series of patches, which would have been even harder to review/rebase/etc.

how long will it take for you to have the patches that actually add the Instance Types 
fields ready (once the first batch is merged)? as long as it will be done shortly afterwards, 
then your approach seems ok (again - my main concern is [1]).

[1] my main concern is that this batch of patches (dialog reorg) will make it into ovirt 
3.3, but the second batch (which will contain the actual Instance Types fields) won't make 
it in time [see the ovirt 3.3 schedule in: http://www.ovirt.org/OVirt_3.3_release-management - 
ovirt 3.3 feature freeze is today (?!)]; so I wouldn't want to see ovirt 3.3 being released 
with only the first patch batch merged into it. either both batches should be there, or 
both batches should not be there.

> > 
> > 
> > > 
> > > The answer is yes, in a sense: Instance Types + Images are actually
> > > somewhat "replacing" Templates [the general approach is to move to
> > > basing VMs on Instance Types + Images, rather than on Templates;
> > > it allows more flexibility in combining hardware configuration + image
> > > configuration for the VM, without (necessarily) editing each VM field
> > > separately].
> > > 
> > > So as I stated in my previous response: Having the "Instance Types"
> > > field (and "Image" field) in the top static section is very useful, as
> > > they affect the fields in most / a lot of the side-tabs.
> > > 
> > > Based on the above:
> > > 
> > > Do you agree that it makes sense to have a top static section in general
> > > [even only for the "Instance Types" field and "Image" field (again, as
> > > they affect most / a lot of side-tabs fields)]?
> > > If so: Do you think that it makes sense to include the DC field in that
> > > top static section as well (at least due to the fact that the "Instance
> > > Types" list and "Images" list are derived from the selected DC)?
> > 
> > MR: Yes makes sense to include DC in static panel because some of the other
> > fields in the static panel are dependent on it.
> > 
> > 
> > > 
> > > [Tomas/Malini/Eldan - if there is additional/different reasoning for
> > > putting
> > > the DC/Cluster field on the top static section - please share]
> > > 
> > > > (which will be odd for the other tabs).
> > > > 
> > > > So I still don't get the motivation UX-wise.
> > > > E.g. it seems really weird to change the entire DC from Console tab
> > > > (or, as a matter of fact, from most other tabs).
> > 
> > MR: Not sure I understand. You can change DC when you are on ANY sub tab
> > because the DC is a field in the static panel. The static panel is not the
> > sub-tab.
> > 
> > 
> > > > In the new instance type dialog, which tabs could be directly affected
> > > > by
> > > > DC/Cluster?
> > > > IIUC, only Host? Do we really need a static header just for this tab?
> > 
> > MR: Ideally, if we have only one sub-tab that has some dependencies with
> > some
> > basic fields, we should try to design the first sub-tab to have all those
> > fields and eliminate the static panel. But if it is weird to have those
> > additional fields on the very first sub-tab from a workflow perspective,
> > then we should have the static panel even if the dependency is only on one
> > sub-tab. The rule we are going by then is that it doesn't hurt to have
> > context info on the top but it hurts more to not have that context info
> > when
> > needed.
> > 
> > 
> > > > 
> > > > > so for consistency-within-the-dialog considerations, it is probably a
> > > > > good
> > > > > idea to simply
> > > > > always show these fields within this top static section.
> > > > > 
> > > > > [there is a good chance that I am missing your point here - please
> > > > > correct
> > > > > me
> > > > > if necessary]
> > > > > 
> > > > > [1] http://gerrit.ovirt.org/#/c/14936/
> > > > > 
> > > > > [2] http://www.ovirt.org/Features/Instance_Types
> > > > > 
> > > > > [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> > > > > 
> > > > > [4] whenever changing the "Instance Type" value, you can
> > > > > automatically
> > > > > see
> > > > > how these changes
> > > > > affect the fields in the current tab on which you are standing (e.g.
> > > > > if
> > > > > you
> > > > > are standing on
> > > > > the "System" side-tab, you can change the "Instance Type" selected
> > > > > item
> > > > > and
> > > > > immediately see
> > > > > the changes within the "System" side-tab contents), and vice-versa:
> > > > > if
> > > > > you
> > > > > are changing a value
> > > > > that was originally propagated from the instance-type, you will see
> > > > > the
> > > > > instance-type automatically
> > > > > change to "custom"/"not applicable" as a result, so no need to "jump"
> > > > > between
> > > > > side-tabs in order
> > > > > to observe these changes.
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > ----
> > > > > > > Thanks,
> > > > > > > Einav
> > > > > > > 
> > > > > > > [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: derez at redhat.com
> > > > > > > > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > > > > > > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> > > > > > > > <ecohen at redhat.com>,
> > > > > > > > "Frank Kobzik" <fkobzik at redhat.com>,
> > > > > > > > "Eldan Hildesheim" <info at eldanet.com>
> > > > > > > > Sent: Tuesday, May 28, 2013 5:05:38 PM
> > > > > > > > Subject: Change in ovirt-engine[master]: userportal,webadmin:
> > > > > > > > redesign
> > > > > > > > of
> > > > > > > > vm related dialogs
> > > > > > > > 
> > > > > > > > Daniel Erez has posted comments on this change.
> > > > > > > > 
> > > > > > > > Change subject: userportal,webadmin: redesign of vm related
> > > > > > > > dialogs
> > > > > > > > ......................................................................
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Patch Set 5: (1 inline comment)
> > > > > > > > 
> > > > > > > > Code looks good.
> > > > > > > > A few questions regarding the design:
> > > > > > > > 1. Why do we want the static header only in VM dialog?
> > > > > > > > 2. DC/Host are really relevant for all tabs?
> > > > > > > > 3. Is it just a preparation for the final instance type dialog?
> > > > > > > > 4. If it's indeed merely preparation, shouldn't it be merged
> > > > > > > > only
> > > > > > > > once
> > > > > > > > we
> > > > > > > > have the full picture of the new dialog?
> > > > > > > > 
> > > > > > > > ....................................................
> > > > > > > > File
> > > > > > > > frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> > > > > > > > Line 21:
> > > > > > > > Line 22: 		.header {
> > > > > > > > Line 23: 			background-color: #D3D3D3;
> > > > > > > > Line 24: 			border-bottom: 1px solid #CED8DF;
> > > > > > > > Line 25: 			margin-bottom: 15px;
> > > > > > > > is it supposed to be that large?
> > > > > > > > Line 26: 			padding-top: 6px;
> > > > > > > > Line 27: 			margin-top: 4px;
> > > > > > > > Line 28: 			margin-right: 3px;
> > > > > > > > Line 29: 			display: none;
> > > > > > > > 
> > > > > > > > 
> > > > > > > > --
> > > > > > > > To view, visit http://gerrit.ovirt.org/14635
> > > > > > > > To unsubscribe, visit http://gerrit.ovirt.org/settings
> > > > > > > > 
> > > > > > > > Gerrit-MessageType: comment
> > > > > > > > Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> > > > > > > > Gerrit-PatchSet: 5
> > > > > > > > Gerrit-Project: ovirt-engine
> > > > > > > > Gerrit-Branch: master
> > > > > > > > Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
> > > > > > > > Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
> > > > > > > > Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
> > > > > > > > Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
> > > > > > > > Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
> > > > > > > > Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
> > > > > > > > Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > > 
> > > > 
> > > 
> > 
> 


From michal.skrivanek at redhat.com  Fri May 31 12:10:39 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Fri, 31 May 2013 14:10:39 +0200
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <1493549047.16382669.1370000699204.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<70378615.13764765.1369778027447.JavaMail.root@redhat.com>
	<771394793.7670643.1369779500608.JavaMail.root@redhat.com>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
	<1910975758.14088419.1369830090869.JavaMail.root@redhat.com>
	<841607815.31395487.1369929419144.JavaMail.root@redhat.com>
	<2014639425.11839457.1369981377910.JavaMail.root@redhat.com>
	<1493549047.16382669.1370000699204.JavaMail.root@redhat.com>
Message-ID: <73EDF069-94CA-4BEC-8464-F1006BA4954C@redhat.com>


On 31 May 2013, at 13:44, Einav Cohen wrote:

>> ----- Original Message -----
>> From: "Tomas Jelinek" <tjelinek at redhat.com>
>> Sent: Friday, May 31, 2013 2:22:57 AM
>> 
>> 
>> 
>> ----- Original Message -----
>>> From: "Malini Rao" <mrao at redhat.com>
>>> To: "Einav Cohen" <ecohen at redhat.com>
>>> Cc: "Daniel Erez" <derez at redhat.com>, "Eldan Hildesheim"
>>> <info at eldanet.com>, "engine-devel" <engine-devel at ovirt.org>,
>>> "Eldan Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek"
>>> <tjelinek at redhat.com>
>>> Sent: Thursday, May 30, 2013 5:56:59 PM
>>> Subject: Re: [Engine-devel] static header only in VM dialog?
>>> 
>>> Sorry to join the thread late. The long weekend was followed by a
>>> conference
>>> for the UX team and hence the delay. See comments below inline -
>>> 
>>> ----- Original Message -----
>>>> From: "Einav Cohen" <ecohen at redhat.com>
>>>> To: "Daniel Erez" <derez at redhat.com>
>>>> Cc: "Eldan Hildesheim" <info at eldanet.com>, "engine-devel"
>>>> <engine-devel at ovirt.org>, "Eldan Hildesheim"
>>>> <ehildesh at redhat.com>, "Malini Rao" <mrao at redhat.com>, "Tomas Jelinek"
>>>> <tjelinek at redhat.com>
>>>> Sent: Wednesday, May 29, 2013 8:21:30 AM
>>>> Subject: Re: [Engine-devel] static header only in VM dialog?
>>>> 
>>>>> ----- Original Message -----
>>>>> From: "Daniel Erez" <derez at redhat.com>
>>>>> Sent: Wednesday, May 29, 2013 1:36:03 AM
>>>>> 
>>>>> 
>>>>> 
>>>>> ----- Original Message -----
>>>>>> From: "Einav Cohen" <ecohen at redhat.com>
>>>>>> To: "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>,
>>>>>> "Eldan Hildesheim" <info at eldanet.com>, "Eldan
>>>>>> Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek"
>>>>>> <tjelinek at redhat.com>
>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>> Sent: Wednesday, May 29, 2013 2:30:09 AM
>>>>>> Subject: Re: static header only in VM dialog?
>>>>>> 
>>>>>>> ----- Original Message -----
>>>>>>> From: "Daniel Erez" <derez at redhat.com>
>>>>>>> Sent: Tuesday, May 28, 2013 6:18:20 PM
>>>>>>> 
>>>>>>> 
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Einav Cohen" <ecohen at redhat.com>
>>>>>>>> To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
>>>>>>>> <info at eldanet.com>,
>>>>>>>> "Eldan Hildesheim" <ehildesh at redhat.com>
>>>>>>>> Cc: "Tomas Jelinek" <tjelinek at redhat.com>, derez at redhat.com,
>>>>>>>> "engine-devel"
>>>>>>>> <engine-devel at ovirt.org>
>>>>>>>> Sent: Wednesday, May 29, 2013 12:53:47 AM
>>>>>>>> Subject: static header only in VM dialog?
>>>>>>>> 
>>>>>>>> when reviewing the code for the "redesign of vm related dialogs",
>>>>>>>> Daniel
>>>>>>>> has
>>>>>>>> raised an interesting question: Why do we want the static header
>>>>>>>> only
>>>>>>>> in
>>>>>>>> VM
>>>>>>>> dialog?
>>>>>>>> 
>>>>>>>> (I assume that he refers to the top section of the New VM dialog
>>>>>>>> as
>>>>>>>> seen
>>>>>>>> in
>>>>>>>> [1], which
>>>>>>>> contains the DC/Cluster, Quota, etc information, and is "static",
>>>>>>>> i.e.,
>>>>>>>> it
>>>>>>>> is
>>>>>>>> always
>>>>>>>> displayed, regardless of the selected side-tab within the dialog)
>>>>>>>> 
>>>>>>>> I agree with what Daniel is implying here: for consistency, we
>>>>>>>> would
>>>>>>>> probably
>>>>>>>> want to
>>>>>>>> introduce this static header to other dialogs, at least to the
>>>>>>>> ones
>>>>>>>> that
>>>>>>>> also
>>>>>>>> contain
>>>>>>>> side-tabs in which it makes sense to turn the "header" to static
>>>>>>>> [e.g.
>>>>>>>> "New Host" (which contains a DC + Cluster "header") - see
>>>>>>>> http://oi39.tinypic.com/2z84xnp.jpg,
>>>>>>>> "New Cluster" (which contains a DC "header") - see
>>>>>>>> http://oi40.tinypic.com/2vmyj2x.jpg]
>>> 
>>> MR:  Consistency is important but we need to make only UIs with similar
>>> purposes consistent and not aim for consistency where it will not serve a
>>> real Usability goal or worse get in the way. See next comment for more on
>>> UX
>>> motivation for this static panel for new VM creation where it was
>>> originally
>>> proposed.
>>> 
>>> 
>>>>>>>> 
>>>>>>>> [I assume, of course, that all the VM-like dialogs (e.g. New/Edit
>>>>>>>> VM-Pool)
>>>>>>>> will also have
>>>>>>>> static headers - I don't know if the patch already takes care of
>>>>>>>> that
>>>>>>>> or
>>>>>>>> not]
>>>>>>>> 
>>>>>>>> Thoughts?
>>>>>>>> 
>>>>>>>> [@Daniel - if you had something else in mind, and/or other
>>>>>>>> dialogs
>>>>>>>> in
>>>>>>>> mind
>>>>>>>> -
>>>>>>>> please feel free
>>>>>>>> to add/amend/etc]
>>> 
>>> MR: Before we proliferate this UI paradigm into other areas, let us look at
>>> the list of dialogs where we are considering this against the primary UX
>>> motivations with which this static panel was originally suggested. UX can
>>> help with this exercise on where it makes sense to have the static panel.
>>> 
>>>>>>> 
>>>>>>> Besides consistency matters, I wanted to understand what's the
>>>>>>> motivation
>>>>>>> of
>>>>>>> keeping these widgets static. I.e. is it an essential preparation
>>>>>>> for
>>>>>>> the
>>>>>>> new
>>>>>>> instance type dialog or a new concept for tab based dialogs
>>>>>>> (as DC/Cluster values aren't necessarily relevant for each tab in
>>>>>>> the
>>>>>>> dialog)
>>>>>> 
>>>>>> [maybe Tomas/Eldan/Malini can help here as well]
>>> 
>>> 
>>> MR: Here are the original motivations for this static panel.
>>> 
>>> 1. Context for dependencies - In the create VM dialog and the introduction
>>> of
>>> instance types and images, we came up with two core needs for the UI -
>>> There
>>> were some fields that were context-setting for other fields with
>>> dependencies. So, changing these context setting field values would alter
>>> the choices in other fields on one of the sub-tabs or eliminate or populate
>>> fields in these tabs. We wanted to ground the user with the context so that
>>> they can observe any changes that happen on a tab and determine what caused
>>> that change in the static panel.
>>> 
>>> 2. Basic and mandatory - In the create VM dialog and the introduction of
>>> instance types and images, we also had to represent different levels of
>>> definition needed. For e.g, there were some basic and mandatory fields that
>>> were minimally needed for the definition of a VM irrespective of whether
>>> the
>>> user was basic or advanced. These fields were included in the static panel
>>> or at the most in the very first sub tab if they were not a context setting
>>> field for any other dependent field. This way the user does not have to go
>>> anywhere else to do a basic definition of the VM.
>>> 
>>> Then we had another layer of permissioning where the fields you had access
>>> to
>>> on various tabs depended on whether you were a basic or advanced user. But
>>> note, we did have scenarios where some advanced fields made it to the
>>> static
>>> panel because they were a context setter.
>>> 
>>> So to summarize the motivation of why the static panel and what should go
>>> into the static panel - You need a static panel ONLY if you have certain
>>> fields (basic or advanced) that act as context setters for all or some of
>>> the other fields in the other sub-tabs. Static panels can further
>>> optionally
>>> be extended to present all the fields that are needed for basic definition
>>> of an object. If there is no dependency and there is a dialog with multiple
>>> sub-tabs, then we SHOULD NOT just create a static panel for the basic
>>> definition fields. These fields should populate the first sub tab. Let me
>>> know if any further clarifications are needed.
>>> 
>>> 
>>> 
>>>>>> 
>>>>>> these static widgets (as well as the type ahead list box [1], for
>>>>>> example)
>>>>>> are part of
>>>>>> the instance types feature that had its design details published in
>>>>>> [2]
>>>>>> and
>>>>>> [3], and the
>>>>>> implementation was done according to this design. I don't see any
>>>>>> reason
>>>>>> to
>>>>>> not utilize
>>>>>> this newly-introduced concept in other side-tab-based dialogs as
>>>>>> well,
>>>>>> if
>>>>>> it
>>>>>> makes sense
>>>>>> (ui consistency considerations are sufficient, IMO, but I could be
>>>>>> wrong
>>>>>> -
>>>>>> maybe it is
>>>>>> relevant/correct to introduce this new concept only in the VM-like
>>>>>> dialogs).
>>> 
>>> 
>>> MR: The UX motivations for the static panel are generalizable even though
>>> they were designed for the New VM dialog. See above comment. But we need to
>>> gauge the reqs on each of the dialogs with subtabs against the core
>>> motivation and see if we need the static panel on it or not.
>>> 
>>> 
>>>>>> 
>>>>>> regarding the specific concern about the DC/Cluster values that
>>>>>> aren't
>>>>>> necessarily relevant
>>>>>> for each side-tab in the dialog: I agree with that statement,
>>> 
>>> MR: If any field recommended in the UX proposal is not useful as a context
>>> setter, then please let us know and we can move it to the first sub-tab.
>>> 
>>> 
>>> however:
>>>>>> 
>>>>>> - putting the "Instance Type" drop-down at the top static section is
>>>>>> very
>>>>>> useful (see [4]
>>>>>> for explanation), and as the Instance Types list is derived from the
>>>>>> selected
>>>>>> DC, it makes
>>>>>> sense (to me) to put the DC in that top static section as well.
>>> 
>>> MR: Agree. That is probably why we ended up leaving the DC there.
>>> 
>>> 
>>>>>> 
>>>>>> - the DC/Cluster are relevant for some of the tabs in the dialog
>>>>>> (Host,
>>>>>> Resource Allocation?)
>>>>> 
>>>>> Only for Host.
>>>>> Resource Allocation is directly affected by the selected template.
>>>>> Therefore, it sounds very confusing to me...
>>>>> Unless we add template to the static header as well?
>>> 
>>> 
>>> MR: I think we incorporated the templates into the Image field and denoted
>>> it
>>> with an icon preceding the drop down choice. So, the template is in the
>>> static panel.
>> 
>> Just a small note:  the first patch we are talking about
>> (http://gerrit.ovirt.org/#/c/14635)
>> adds only Data Center, Cluster and Quota to the header.
>> There is a second patch (http://gerrit.ovirt.org/#/c/15011/) which moves the
>> OS type and
>> template to the header.
>> The Image and Instance Type fields are not implemented yet. The current
>> patches just redesigns
>> the current UX according to the mockups - the new entities will be integrated
>> after we will have
>> an agreement and this batch of patches will be merged.
> 
> OK, that explains a lot... :) many thanks, Tomas, for the clarification.
> 
> I understand now Daniels's concern; it indeed doesn't make much sense for the 
> DC/Cluster and Quota fields to be the only fields in the top static section.
> However, as this is a preparation for the Instance Types fields patches, it 
> makes sense that we will first do the preparation work (i.e. change/reorganize 
> the existing dialog layout), and then incorporate the Instance Types fields into 
> it (given that it is being done *shortly* afterwards), or simply do everything 
> altogether.
> 
> @Tomas - ideally, the code that actually adds the Instance Types fields should have 
> been part of this patch chain (either in more patches, or in "larger" patches), as again - 
> I agree with Daniel that it makes no sense to having a static header in the VM dialogs 
> with only DC/Cluster and Quota in them [1].
> However, there is a chance that it would have been resulted in very large patches / a 
> very long series of patches, which would have been even harder to review/rebase/etc.
> 
> how long will it take for you to have the patches that actually add the Instance Types 
> fields ready (once the first batch is merged)? as long as it will be done shortly afterwards, 
> then your approach seems ok (again - my main concern is [1]).
> 
> [1] my main concern is that this batch of patches (dialog reorg) will make it into ovirt 
> 3.3, but the second batch (which will contain the actual Instance Types fields) won't make 
> it in time [see the ovirt 3.3 schedule in: http://www.ovirt.org/OVirt_3.3_release-management - 
> ovirt 3.3 feature freeze is today (?!)]; so I wouldn't want to see ovirt 3.3 being released 
> with only the first patch batch merged into it. either both batches should be there, or 
> both batches should not be there.
There was a discussion about postponing it, but not much further it seems. 
In any case It may not be necessarily wrong to have dialog reorg in 3.3 without insttypes as it will at least get people to get used to it and we can gather feedback. It's not that it removes any functionality, on the contrary, e.g. the type ahead feature even solves some of the bugs we already have.

> 
>>> 
>>> 
>>>> 
>>>> The answer is yes, in a sense: Instance Types + Images are actually
>>>> somewhat "replacing" Templates [the general approach is to move to
>>>> basing VMs on Instance Types + Images, rather than on Templates;
>>>> it allows more flexibility in combining hardware configuration + image
>>>> configuration for the VM, without (necessarily) editing each VM field
>>>> separately].
>>>> 
>>>> So as I stated in my previous response: Having the "Instance Types"
>>>> field (and "Image" field) in the top static section is very useful, as
>>>> they affect the fields in most / a lot of the side-tabs.
>>>> 
>>>> Based on the above:
>>>> 
>>>> Do you agree that it makes sense to have a top static section in general
>>>> [even only for the "Instance Types" field and "Image" field (again, as
>>>> they affect most / a lot of side-tabs fields)]?
>>>> If so: Do you think that it makes sense to include the DC field in that
>>>> top static section as well (at least due to the fact that the "Instance
>>>> Types" list and "Images" list are derived from the selected DC)?
>>> 
>>> MR: Yes makes sense to include DC in static panel because some of the other
>>> fields in the static panel are dependent on it.
>>> 
>>> 
>>>> 
>>>> [Tomas/Malini/Eldan - if there is additional/different reasoning for
>>>> putting
>>>> the DC/Cluster field on the top static section - please share]
>>>> 
>>>>> (which will be odd for the other tabs).
>>>>> 
>>>>> So I still don't get the motivation UX-wise.
>>>>> E.g. it seems really weird to change the entire DC from Console tab
>>>>> (or, as a matter of fact, from most other tabs).
>>> 
>>> MR: Not sure I understand. You can change DC when you are on ANY sub tab
>>> because the DC is a field in the static panel. The static panel is not the
>>> sub-tab.
>>> 
>>> 
>>>>> In the new instance type dialog, which tabs could be directly affected
>>>>> by
>>>>> DC/Cluster?
>>>>> IIUC, only Host? Do we really need a static header just for this tab?
>>> 
>>> MR: Ideally, if we have only one sub-tab that has some dependencies with
>>> some
>>> basic fields, we should try to design the first sub-tab to have all those
>>> fields and eliminate the static panel. But if it is weird to have those
>>> additional fields on the very first sub-tab from a workflow perspective,
>>> then we should have the static panel even if the dependency is only on one
>>> sub-tab. The rule we are going by then is that it doesn't hurt to have
>>> context info on the top but it hurts more to not have that context info
>>> when
>>> needed.
>>> 
>>> 
>>>>> 
>>>>>> so for consistency-within-the-dialog considerations, it is probably a
>>>>>> good
>>>>>> idea to simply
>>>>>> always show these fields within this top static section.
>>>>>> 
>>>>>> [there is a good chance that I am missing your point here - please
>>>>>> correct
>>>>>> me
>>>>>> if necessary]
>>>>>> 
>>>>>> [1] http://gerrit.ovirt.org/#/c/14936/
>>>>>> 
>>>>>> [2] http://www.ovirt.org/Features/Instance_Types
>>>>>> 
>>>>>> [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
>>>>>> 
>>>>>> [4] whenever changing the "Instance Type" value, you can
>>>>>> automatically
>>>>>> see
>>>>>> how these changes
>>>>>> affect the fields in the current tab on which you are standing (e.g.
>>>>>> if
>>>>>> you
>>>>>> are standing on
>>>>>> the "System" side-tab, you can change the "Instance Type" selected
>>>>>> item
>>>>>> and
>>>>>> immediately see
>>>>>> the changes within the "System" side-tab contents), and vice-versa:
>>>>>> if
>>>>>> you
>>>>>> are changing a value
>>>>>> that was originally propagated from the instance-type, you will see
>>>>>> the
>>>>>> instance-type automatically
>>>>>> change to "custom"/"not applicable" as a result, so no need to "jump"
>>>>>> between
>>>>>> side-tabs in order
>>>>>> to observe these changes.
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> ----
>>>>>>>> Thanks,
>>>>>>>> Einav
>>>>>>>> 
>>>>>>>> [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
>>>>>>>> 
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: derez at redhat.com
>>>>>>>>> To: "Tomas Jelinek" <tjelinek at redhat.com>
>>>>>>>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
>>>>>>>>> <ecohen at redhat.com>,
>>>>>>>>> "Frank Kobzik" <fkobzik at redhat.com>,
>>>>>>>>> "Eldan Hildesheim" <info at eldanet.com>
>>>>>>>>> Sent: Tuesday, May 28, 2013 5:05:38 PM
>>>>>>>>> Subject: Change in ovirt-engine[master]: userportal,webadmin:
>>>>>>>>> redesign
>>>>>>>>> of
>>>>>>>>> vm related dialogs
>>>>>>>>> 
>>>>>>>>> Daniel Erez has posted comments on this change.
>>>>>>>>> 
>>>>>>>>> Change subject: userportal,webadmin: redesign of vm related
>>>>>>>>> dialogs
>>>>>>>>> ......................................................................
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Patch Set 5: (1 inline comment)
>>>>>>>>> 
>>>>>>>>> Code looks good.
>>>>>>>>> A few questions regarding the design:
>>>>>>>>> 1. Why do we want the static header only in VM dialog?
>>>>>>>>> 2. DC/Host are really relevant for all tabs?
>>>>>>>>> 3. Is it just a preparation for the final instance type dialog?
>>>>>>>>> 4. If it's indeed merely preparation, shouldn't it be merged
>>>>>>>>> only
>>>>>>>>> once
>>>>>>>>> we
>>>>>>>>> have the full picture of the new dialog?
>>>>>>>>> 
>>>>>>>>> ....................................................
>>>>>>>>> File
>>>>>>>>> frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
>>>>>>>>> Line 21:
>>>>>>>>> Line 22: 		.header {
>>>>>>>>> Line 23: 			background-color: #D3D3D3;
>>>>>>>>> Line 24: 			border-bottom: 1px solid #CED8DF;
>>>>>>>>> Line 25: 			margin-bottom: 15px;
>>>>>>>>> is it supposed to be that large?
>>>>>>>>> Line 26: 			padding-top: 6px;
>>>>>>>>> Line 27: 			margin-top: 4px;
>>>>>>>>> Line 28: 			margin-right: 3px;
>>>>>>>>> Line 29: 			display: none;
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> To view, visit http://gerrit.ovirt.org/14635
>>>>>>>>> To unsubscribe, visit http://gerrit.ovirt.org/settings
>>>>>>>>> 
>>>>>>>>> Gerrit-MessageType: comment
>>>>>>>>> Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
>>>>>>>>> Gerrit-PatchSet: 5
>>>>>>>>> Gerrit-Project: ovirt-engine
>>>>>>>>> Gerrit-Branch: master
>>>>>>>>> Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
>>>>>>>>> Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
>>>>>>>>> Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
>>>>>>>>> Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
>>>>>>>>> Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
>>>>>>>>> Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
>>>>>>>>> Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 



From tjelinek at redhat.com  Fri May 31 12:41:13 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Fri, 31 May 2013 08:41:13 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <73EDF069-94CA-4BEC-8464-F1006BA4954C@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
	<1910975758.14088419.1369830090869.JavaMail.root@redhat.com>
	<841607815.31395487.1369929419144.JavaMail.root@redhat.com>
	<2014639425.11839457.1369981377910.JavaMail.root@redhat.com>
	<1493549047.16382669.1370000699204.JavaMail.root@redhat.com>
	<73EDF069-94CA-4BEC-8464-F1006BA4954C@redhat.com>
Message-ID: <1291121466.11965200.1370004073321.JavaMail.root@redhat.com>

Adding also Omer because he is doing the BE of the instance types feature.

----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "Tomas Jelinek" <tjelinek at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>, "Eldan
> Hildesheim" <info at eldanet.com>, "engine-devel" <engine-devel at ovirt.org>, "Eldan Hildesheim" <ehildesh at redhat.com>
> Sent: Friday, May 31, 2013 2:10:39 PM
> Subject: Re: [Engine-devel] static header only in VM dialog?
> 
> 
> On 31 May 2013, at 13:44, Einav Cohen wrote:
> 
> >> ----- Original Message -----
> >> From: "Tomas Jelinek" <tjelinek at redhat.com>
> >> Sent: Friday, May 31, 2013 2:22:57 AM
> >> 
> >> 
> >> 
> >> ----- Original Message -----
> >>> From: "Malini Rao" <mrao at redhat.com>
> >>> To: "Einav Cohen" <ecohen at redhat.com>
> >>> Cc: "Daniel Erez" <derez at redhat.com>, "Eldan Hildesheim"
> >>> <info at eldanet.com>, "engine-devel" <engine-devel at ovirt.org>,
> >>> "Eldan Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek"
> >>> <tjelinek at redhat.com>
> >>> Sent: Thursday, May 30, 2013 5:56:59 PM
> >>> Subject: Re: [Engine-devel] static header only in VM dialog?
> >>> 
> >>> Sorry to join the thread late. The long weekend was followed by a
> >>> conference
> >>> for the UX team and hence the delay. See comments below inline -
> >>> 
> >>> ----- Original Message -----
> >>>> From: "Einav Cohen" <ecohen at redhat.com>
> >>>> To: "Daniel Erez" <derez at redhat.com>
> >>>> Cc: "Eldan Hildesheim" <info at eldanet.com>, "engine-devel"
> >>>> <engine-devel at ovirt.org>, "Eldan Hildesheim"
> >>>> <ehildesh at redhat.com>, "Malini Rao" <mrao at redhat.com>, "Tomas Jelinek"
> >>>> <tjelinek at redhat.com>
> >>>> Sent: Wednesday, May 29, 2013 8:21:30 AM
> >>>> Subject: Re: [Engine-devel] static header only in VM dialog?
> >>>> 
> >>>>> ----- Original Message -----
> >>>>> From: "Daniel Erez" <derez at redhat.com>
> >>>>> Sent: Wednesday, May 29, 2013 1:36:03 AM
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> ----- Original Message -----
> >>>>>> From: "Einav Cohen" <ecohen at redhat.com>
> >>>>>> To: "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>,
> >>>>>> "Eldan Hildesheim" <info at eldanet.com>, "Eldan
> >>>>>> Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek"
> >>>>>> <tjelinek at redhat.com>
> >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>> Sent: Wednesday, May 29, 2013 2:30:09 AM
> >>>>>> Subject: Re: static header only in VM dialog?
> >>>>>> 
> >>>>>>> ----- Original Message -----
> >>>>>>> From: "Daniel Erez" <derez at redhat.com>
> >>>>>>> Sent: Tuesday, May 28, 2013 6:18:20 PM
> >>>>>>> 
> >>>>>>> 
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Einav Cohen" <ecohen at redhat.com>
> >>>>>>>> To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
> >>>>>>>> <info at eldanet.com>,
> >>>>>>>> "Eldan Hildesheim" <ehildesh at redhat.com>
> >>>>>>>> Cc: "Tomas Jelinek" <tjelinek at redhat.com>, derez at redhat.com,
> >>>>>>>> "engine-devel"
> >>>>>>>> <engine-devel at ovirt.org>
> >>>>>>>> Sent: Wednesday, May 29, 2013 12:53:47 AM
> >>>>>>>> Subject: static header only in VM dialog?
> >>>>>>>> 
> >>>>>>>> when reviewing the code for the "redesign of vm related dialogs",
> >>>>>>>> Daniel
> >>>>>>>> has
> >>>>>>>> raised an interesting question: Why do we want the static header
> >>>>>>>> only
> >>>>>>>> in
> >>>>>>>> VM
> >>>>>>>> dialog?
> >>>>>>>> 
> >>>>>>>> (I assume that he refers to the top section of the New VM dialog
> >>>>>>>> as
> >>>>>>>> seen
> >>>>>>>> in
> >>>>>>>> [1], which
> >>>>>>>> contains the DC/Cluster, Quota, etc information, and is "static",
> >>>>>>>> i.e.,
> >>>>>>>> it
> >>>>>>>> is
> >>>>>>>> always
> >>>>>>>> displayed, regardless of the selected side-tab within the dialog)
> >>>>>>>> 
> >>>>>>>> I agree with what Daniel is implying here: for consistency, we
> >>>>>>>> would
> >>>>>>>> probably
> >>>>>>>> want to
> >>>>>>>> introduce this static header to other dialogs, at least to the
> >>>>>>>> ones
> >>>>>>>> that
> >>>>>>>> also
> >>>>>>>> contain
> >>>>>>>> side-tabs in which it makes sense to turn the "header" to static
> >>>>>>>> [e.g.
> >>>>>>>> "New Host" (which contains a DC + Cluster "header") - see
> >>>>>>>> http://oi39.tinypic.com/2z84xnp.jpg,
> >>>>>>>> "New Cluster" (which contains a DC "header") - see
> >>>>>>>> http://oi40.tinypic.com/2vmyj2x.jpg]
> >>> 
> >>> MR:  Consistency is important but we need to make only UIs with similar
> >>> purposes consistent and not aim for consistency where it will not serve a
> >>> real Usability goal or worse get in the way. See next comment for more on
> >>> UX
> >>> motivation for this static panel for new VM creation where it was
> >>> originally
> >>> proposed.
> >>> 
> >>> 
> >>>>>>>> 
> >>>>>>>> [I assume, of course, that all the VM-like dialogs (e.g. New/Edit
> >>>>>>>> VM-Pool)
> >>>>>>>> will also have
> >>>>>>>> static headers - I don't know if the patch already takes care of
> >>>>>>>> that
> >>>>>>>> or
> >>>>>>>> not]
> >>>>>>>> 
> >>>>>>>> Thoughts?
> >>>>>>>> 
> >>>>>>>> [@Daniel - if you had something else in mind, and/or other
> >>>>>>>> dialogs
> >>>>>>>> in
> >>>>>>>> mind
> >>>>>>>> -
> >>>>>>>> please feel free
> >>>>>>>> to add/amend/etc]
> >>> 
> >>> MR: Before we proliferate this UI paradigm into other areas, let us look
> >>> at
> >>> the list of dialogs where we are considering this against the primary UX
> >>> motivations with which this static panel was originally suggested. UX can
> >>> help with this exercise on where it makes sense to have the static panel.
> >>> 
> >>>>>>> 
> >>>>>>> Besides consistency matters, I wanted to understand what's the
> >>>>>>> motivation
> >>>>>>> of
> >>>>>>> keeping these widgets static. I.e. is it an essential preparation
> >>>>>>> for
> >>>>>>> the
> >>>>>>> new
> >>>>>>> instance type dialog or a new concept for tab based dialogs
> >>>>>>> (as DC/Cluster values aren't necessarily relevant for each tab in
> >>>>>>> the
> >>>>>>> dialog)
> >>>>>> 
> >>>>>> [maybe Tomas/Eldan/Malini can help here as well]
> >>> 
> >>> 
> >>> MR: Here are the original motivations for this static panel.
> >>> 
> >>> 1. Context for dependencies - In the create VM dialog and the
> >>> introduction
> >>> of
> >>> instance types and images, we came up with two core needs for the UI -
> >>> There
> >>> were some fields that were context-setting for other fields with
> >>> dependencies. So, changing these context setting field values would alter
> >>> the choices in other fields on one of the sub-tabs or eliminate or
> >>> populate
> >>> fields in these tabs. We wanted to ground the user with the context so
> >>> that
> >>> they can observe any changes that happen on a tab and determine what
> >>> caused
> >>> that change in the static panel.
> >>> 
> >>> 2. Basic and mandatory - In the create VM dialog and the introduction of
> >>> instance types and images, we also had to represent different levels of
> >>> definition needed. For e.g, there were some basic and mandatory fields
> >>> that
> >>> were minimally needed for the definition of a VM irrespective of whether
> >>> the
> >>> user was basic or advanced. These fields were included in the static
> >>> panel
> >>> or at the most in the very first sub tab if they were not a context
> >>> setting
> >>> field for any other dependent field. This way the user does not have to
> >>> go
> >>> anywhere else to do a basic definition of the VM.
> >>> 
> >>> Then we had another layer of permissioning where the fields you had
> >>> access
> >>> to
> >>> on various tabs depended on whether you were a basic or advanced user.
> >>> But
> >>> note, we did have scenarios where some advanced fields made it to the
> >>> static
> >>> panel because they were a context setter.
> >>> 
> >>> So to summarize the motivation of why the static panel and what should go
> >>> into the static panel - You need a static panel ONLY if you have certain
> >>> fields (basic or advanced) that act as context setters for all or some of
> >>> the other fields in the other sub-tabs. Static panels can further
> >>> optionally
> >>> be extended to present all the fields that are needed for basic
> >>> definition
> >>> of an object. If there is no dependency and there is a dialog with
> >>> multiple
> >>> sub-tabs, then we SHOULD NOT just create a static panel for the basic
> >>> definition fields. These fields should populate the first sub tab. Let me
> >>> know if any further clarifications are needed.
> >>> 
> >>> 
> >>> 
> >>>>>> 
> >>>>>> these static widgets (as well as the type ahead list box [1], for
> >>>>>> example)
> >>>>>> are part of
> >>>>>> the instance types feature that had its design details published in
> >>>>>> [2]
> >>>>>> and
> >>>>>> [3], and the
> >>>>>> implementation was done according to this design. I don't see any
> >>>>>> reason
> >>>>>> to
> >>>>>> not utilize
> >>>>>> this newly-introduced concept in other side-tab-based dialogs as
> >>>>>> well,
> >>>>>> if
> >>>>>> it
> >>>>>> makes sense
> >>>>>> (ui consistency considerations are sufficient, IMO, but I could be
> >>>>>> wrong
> >>>>>> -
> >>>>>> maybe it is
> >>>>>> relevant/correct to introduce this new concept only in the VM-like
> >>>>>> dialogs).
> >>> 
> >>> 
> >>> MR: The UX motivations for the static panel are generalizable even though
> >>> they were designed for the New VM dialog. See above comment. But we need
> >>> to
> >>> gauge the reqs on each of the dialogs with subtabs against the core
> >>> motivation and see if we need the static panel on it or not.
> >>> 
> >>> 
> >>>>>> 
> >>>>>> regarding the specific concern about the DC/Cluster values that
> >>>>>> aren't
> >>>>>> necessarily relevant
> >>>>>> for each side-tab in the dialog: I agree with that statement,
> >>> 
> >>> MR: If any field recommended in the UX proposal is not useful as a
> >>> context
> >>> setter, then please let us know and we can move it to the first sub-tab.
> >>> 
> >>> 
> >>> however:
> >>>>>> 
> >>>>>> - putting the "Instance Type" drop-down at the top static section is
> >>>>>> very
> >>>>>> useful (see [4]
> >>>>>> for explanation), and as the Instance Types list is derived from the
> >>>>>> selected
> >>>>>> DC, it makes
> >>>>>> sense (to me) to put the DC in that top static section as well.
> >>> 
> >>> MR: Agree. That is probably why we ended up leaving the DC there.
> >>> 
> >>> 
> >>>>>> 
> >>>>>> - the DC/Cluster are relevant for some of the tabs in the dialog
> >>>>>> (Host,
> >>>>>> Resource Allocation?)
> >>>>> 
> >>>>> Only for Host.
> >>>>> Resource Allocation is directly affected by the selected template.
> >>>>> Therefore, it sounds very confusing to me...
> >>>>> Unless we add template to the static header as well?
> >>> 
> >>> 
> >>> MR: I think we incorporated the templates into the Image field and
> >>> denoted
> >>> it
> >>> with an icon preceding the drop down choice. So, the template is in the
> >>> static panel.
> >> 
> >> Just a small note:  the first patch we are talking about
> >> (http://gerrit.ovirt.org/#/c/14635)
> >> adds only Data Center, Cluster and Quota to the header.
> >> There is a second patch (http://gerrit.ovirt.org/#/c/15011/) which moves
> >> the
> >> OS type and
> >> template to the header.
> >> The Image and Instance Type fields are not implemented yet. The current
> >> patches just redesigns
> >> the current UX according to the mockups - the new entities will be
> >> integrated
> >> after we will have
> >> an agreement and this batch of patches will be merged.
> > 
> > OK, that explains a lot... :) many thanks, Tomas, for the clarification.
> > 
> > I understand now Daniels's concern; it indeed doesn't make much sense for
> > the
> > DC/Cluster and Quota fields to be the only fields in the top static
> > section.
> > However, as this is a preparation for the Instance Types fields patches, it
> > makes sense that we will first do the preparation work (i.e.
> > change/reorganize
> > the existing dialog layout), and then incorporate the Instance Types fields
> > into
> > it (given that it is being done *shortly* afterwards), or simply do
> > everything
> > altogether.
> > 
> > @Tomas - ideally, the code that actually adds the Instance Types fields
> > should have
> > been part of this patch chain (either in more patches, or in "larger"
> > patches), as again -
> > I agree with Daniel that it makes no sense to having a static header in the
> > VM dialogs
> > with only DC/Cluster and Quota in them [1].
> > However, there is a chance that it would have been resulted in very large
> > patches / a
> > very long series of patches, which would have been even harder to
> > review/rebase/etc.
> > 
> > how long will it take for you to have the patches that actually add the
> > Instance Types
> > fields ready (once the first batch is merged)? as long as it will be done
> > shortly afterwards,
> > then your approach seems ok (again - my main concern is [1]).
Adding Omer for his estimate as he is doing the backend part of the instance types. It is hard to estimate, but
I would say it will take a ~week to implement and an unpredictable time to review and merge (the first part
of this batch is in gerrit since may 10th and is far from being merged...). 
> > 
> > [1] my main concern is that this batch of patches (dialog reorg) will make
> > it into ovirt
> > 3.3, but the second batch (which will contain the actual Instance Types
> > fields) won't make
> > it in time [see the ovirt 3.3 schedule in:
> > http://www.ovirt.org/OVirt_3.3_release-management -
> > ovirt 3.3 feature freeze is today (?!)]; so I wouldn't want to see ovirt
> > 3.3 being released
> > with only the first patch batch merged into it. either both batches should
> > be there, or
> > both batches should not be there.
well, I don't see a problem having only the first part in. Given that the template = instance type + image
and the templates are added to the header in this batch, the reasoning behind having the instance types and
images in the header can be applied to having the templates in the header (which BTW will be true even after adding instance types and images)

Also, this batch of patches brings other values to the users like:
- type ahead combo boxes
- unifies new server/desktop to new vm (so can have server with more displays or soundcard etc) 
- simplifies the VM dialogs (with show/hide advanced options button and system tab)
- adds the possibility to edit the NIC/network assignment directly from the VM dialog
- unifies the cluster and DC to one field so no need to select them one-by-one

This all are useful features which can bring some value to the user and make perfect sense without instance types.

To put it to wider context: the feature is called "Instance Types" but a more fitting name would be something like
"Simplify VM based entity management". The reason is that today it is quite hard to make a new VM or edit it etc. because
when you open a e.g. new VM dialog, you are flooded with tons of config options and you have no idea (if you open it first time) what
do you have to edit. And even you finally fill it, you still need to go to some subtabs for e.g. create a NIC and assign it a network.
Or, if you want to select a template to base your VM on, you have to first go to the templates tab and to find out which template is for what
(the current batch will show at least the description next to the template thanks to the type ahead combo which is already a big help).

The effort here is to simplify this. The already implemented patches are some steps which simplify the VM management. The instance types
will make next step in simplifying it. But I don't see a reason why not to go step-by-step.

Please also consider all the time and risk of regression which is carried by each rebase. And the longer the patch sits in gerrit, the bigger the risk is.

But anyway, I understand that the freeze is today so I don't see a way to make it in...

> There was a discussion about postponing it, but not much further it seems.
> In any case It may not be necessarily wrong to have dialog reorg in 3.3
> without insttypes as it will at least get people to get used to it and we
> can gather feedback. It's not that it removes any functionality, on the
> contrary, e.g. the type ahead feature even solves some of the bugs we
> already have.
> 
> > 
> >>> 
> >>> 
> >>>> 
> >>>> The answer is yes, in a sense: Instance Types + Images are actually
> >>>> somewhat "replacing" Templates [the general approach is to move to
> >>>> basing VMs on Instance Types + Images, rather than on Templates;
> >>>> it allows more flexibility in combining hardware configuration + image
> >>>> configuration for the VM, without (necessarily) editing each VM field
> >>>> separately].
> >>>> 
> >>>> So as I stated in my previous response: Having the "Instance Types"
> >>>> field (and "Image" field) in the top static section is very useful, as
> >>>> they affect the fields in most / a lot of the side-tabs.
> >>>> 
> >>>> Based on the above:
> >>>> 
> >>>> Do you agree that it makes sense to have a top static section in general
> >>>> [even only for the "Instance Types" field and "Image" field (again, as
> >>>> they affect most / a lot of side-tabs fields)]?
> >>>> If so: Do you think that it makes sense to include the DC field in that
> >>>> top static section as well (at least due to the fact that the "Instance
> >>>> Types" list and "Images" list are derived from the selected DC)?
> >>> 
> >>> MR: Yes makes sense to include DC in static panel because some of the
> >>> other
> >>> fields in the static panel are dependent on it.
> >>> 
> >>> 
> >>>> 
> >>>> [Tomas/Malini/Eldan - if there is additional/different reasoning for
> >>>> putting
> >>>> the DC/Cluster field on the top static section - please share]
> >>>> 
> >>>>> (which will be odd for the other tabs).
> >>>>> 
> >>>>> So I still don't get the motivation UX-wise.
> >>>>> E.g. it seems really weird to change the entire DC from Console tab
> >>>>> (or, as a matter of fact, from most other tabs).
> >>> 
> >>> MR: Not sure I understand. You can change DC when you are on ANY sub tab
> >>> because the DC is a field in the static panel. The static panel is not
> >>> the
> >>> sub-tab.
> >>> 
> >>> 
> >>>>> In the new instance type dialog, which tabs could be directly affected
> >>>>> by
> >>>>> DC/Cluster?
> >>>>> IIUC, only Host? Do we really need a static header just for this tab?
> >>> 
> >>> MR: Ideally, if we have only one sub-tab that has some dependencies with
> >>> some
> >>> basic fields, we should try to design the first sub-tab to have all those
> >>> fields and eliminate the static panel. But if it is weird to have those
> >>> additional fields on the very first sub-tab from a workflow perspective,
> >>> then we should have the static panel even if the dependency is only on
> >>> one
> >>> sub-tab. The rule we are going by then is that it doesn't hurt to have
> >>> context info on the top but it hurts more to not have that context info
> >>> when
> >>> needed.
> >>> 
> >>> 
> >>>>> 
> >>>>>> so for consistency-within-the-dialog considerations, it is probably a
> >>>>>> good
> >>>>>> idea to simply
> >>>>>> always show these fields within this top static section.
> >>>>>> 
> >>>>>> [there is a good chance that I am missing your point here - please
> >>>>>> correct
> >>>>>> me
> >>>>>> if necessary]
> >>>>>> 
> >>>>>> [1] http://gerrit.ovirt.org/#/c/14936/
> >>>>>> 
> >>>>>> [2] http://www.ovirt.org/Features/Instance_Types
> >>>>>> 
> >>>>>> [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> >>>>>> 
> >>>>>> [4] whenever changing the "Instance Type" value, you can
> >>>>>> automatically
> >>>>>> see
> >>>>>> how these changes
> >>>>>> affect the fields in the current tab on which you are standing (e.g.
> >>>>>> if
> >>>>>> you
> >>>>>> are standing on
> >>>>>> the "System" side-tab, you can change the "Instance Type" selected
> >>>>>> item
> >>>>>> and
> >>>>>> immediately see
> >>>>>> the changes within the "System" side-tab contents), and vice-versa:
> >>>>>> if
> >>>>>> you
> >>>>>> are changing a value
> >>>>>> that was originally propagated from the instance-type, you will see
> >>>>>> the
> >>>>>> instance-type automatically
> >>>>>> change to "custom"/"not applicable" as a result, so no need to "jump"
> >>>>>> between
> >>>>>> side-tabs in order
> >>>>>> to observe these changes.
> >>>>>> 
> >>>>>>> 
> >>>>>>>> 
> >>>>>>>> ----
> >>>>>>>> Thanks,
> >>>>>>>> Einav
> >>>>>>>> 
> >>>>>>>> [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> >>>>>>>> 
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: derez at redhat.com
> >>>>>>>>> To: "Tomas Jelinek" <tjelinek at redhat.com>
> >>>>>>>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> >>>>>>>>> <ecohen at redhat.com>,
> >>>>>>>>> "Frank Kobzik" <fkobzik at redhat.com>,
> >>>>>>>>> "Eldan Hildesheim" <info at eldanet.com>
> >>>>>>>>> Sent: Tuesday, May 28, 2013 5:05:38 PM
> >>>>>>>>> Subject: Change in ovirt-engine[master]: userportal,webadmin:
> >>>>>>>>> redesign
> >>>>>>>>> of
> >>>>>>>>> vm related dialogs
> >>>>>>>>> 
> >>>>>>>>> Daniel Erez has posted comments on this change.
> >>>>>>>>> 
> >>>>>>>>> Change subject: userportal,webadmin: redesign of vm related
> >>>>>>>>> dialogs
> >>>>>>>>> ......................................................................
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> Patch Set 5: (1 inline comment)
> >>>>>>>>> 
> >>>>>>>>> Code looks good.
> >>>>>>>>> A few questions regarding the design:
> >>>>>>>>> 1. Why do we want the static header only in VM dialog?
> >>>>>>>>> 2. DC/Host are really relevant for all tabs?
> >>>>>>>>> 3. Is it just a preparation for the final instance type dialog?
> >>>>>>>>> 4. If it's indeed merely preparation, shouldn't it be merged
> >>>>>>>>> only
> >>>>>>>>> once
> >>>>>>>>> we
> >>>>>>>>> have the full picture of the new dialog?
> >>>>>>>>> 
> >>>>>>>>> ....................................................
> >>>>>>>>> File
> >>>>>>>>> frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> >>>>>>>>> Line 21:
> >>>>>>>>> Line 22: 		.header {
> >>>>>>>>> Line 23: 			background-color: #D3D3D3;
> >>>>>>>>> Line 24: 			border-bottom: 1px solid #CED8DF;
> >>>>>>>>> Line 25: 			margin-bottom: 15px;
> >>>>>>>>> is it supposed to be that large?
> >>>>>>>>> Line 26: 			padding-top: 6px;
> >>>>>>>>> Line 27: 			margin-top: 4px;
> >>>>>>>>> Line 28: 			margin-right: 3px;
> >>>>>>>>> Line 29: 			display: none;
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> --
> >>>>>>>>> To view, visit http://gerrit.ovirt.org/14635
> >>>>>>>>> To unsubscribe, visit http://gerrit.ovirt.org/settings
> >>>>>>>>> 
> >>>>>>>>> Gerrit-MessageType: comment
> >>>>>>>>> Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> >>>>>>>>> Gerrit-PatchSet: 5
> >>>>>>>>> Gerrit-Project: ovirt-engine
> >>>>>>>>> Gerrit-Branch: master
> >>>>>>>>> Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
> >>>>>>>>> Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
> >>>>>>>>> Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
> >>>>>>>>> Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
> >>>>>>>>> Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
> >>>>>>>>> Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
> >>>>>>>>> Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
> >>>>>>>>> 
> >>>>>>>> 
> >>>>>>> 
> >>>>>> 
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>> 
> >>>>> 
> >>>>> 
> >>>> 
> >>> 
> >> 
> 
> 


From ecohen at redhat.com  Fri May 31 15:56:33 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Fri, 31 May 2013 11:56:33 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <73EDF069-94CA-4BEC-8464-F1006BA4954C@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
	<1910975758.14088419.1369830090869.JavaMail.root@redhat.com>
	<841607815.31395487.1369929419144.JavaMail.root@redhat.com>
	<2014639425.11839457.1369981377910.JavaMail.root@redhat.com>
	<1493549047.16382669.1370000699204.JavaMail.root@redhat.com>
	<73EDF069-94CA-4BEC-8464-F1006BA4954C@redhat.com>
Message-ID: <909641716.16748965.1370015793965.JavaMail.root@redhat.com>

> > ...
> > 
> > [1] my main concern is that this batch of patches (dialog reorg) will make
> > it into ovirt
> > 3.3, but the second batch (which will contain the actual Instance Types
> > fields) won't make
> > it in time [see the ovirt 3.3 schedule in:
> > http://www.ovirt.org/OVirt_3.3_release-management -
> > ovirt 3.3 feature freeze is today (?!)]; so I wouldn't want to see ovirt
> > 3.3 being released
> > with only the first patch batch merged into it. either both batches should
> > be there, or
> > both batches should not be there.
> 
> There was a discussion about postponing it, but not much further it seems.
> In any case It may not be necessarily wrong to have dialog reorg in 3.3
> without insttypes as it will at least get people to get used to it and we
> can gather feedback. It's not that it removes any functionality, on the
> contrary, e.g. the type ahead feature even solves some of the bugs we
> already have.

indeed - it doesn't remove functionality, and I agree that it would be a good 
opportunity to get feedback about some things such as the type-ahead list box, 
however the top static header in particular with only the DC/Cluster + Quota 
in it may seem strange / annoying, as it would just seem like something that 
takes up "real estate" in the dialog in *all* side-tab without a real good reason. 

so there are pros and cons for introducing only the first patch batch to ovirt-3.3, 
I guess; Ideally, I would suggest to maybe re-organize the patches a bit differently, 
so that the top static header in particular wouldn't be part of this first patch batch, 
i.e., I would suggest introducing the top static header along with adding the Instance 
Types fields [which, to my understanding, is exactly what Daniel has originally suggested 
on the patch [1] in his gerrit comment(s) from May 28/29 (depends on the timezone) - 
only now I fully understand his concern (I think/hope)...].

not sure how easy it is to do though - I know that *a lot* of time and effort were 
already invested in these patches as they are now, and I wouldn't want that the reviewing/
merging process will be held off for much longer. 

To sum up: these are the options, as I see them:

1) keep the current patch batch as is and:

   a. merge it in time for ovirt-3.3, or:

   b. merge it post ovirt-3.3.

- or -

2) go with what Daniel has suggested in his gerrit comment: reorganize the patches so that 
the top static header would be introduced only along with the instance types fields [that 
way, it won't matter what makes it into ovirt-3.3 - the first patch batch, or both (or none)].

I am in favor of (1.b) or (2). However, weighing the cons of (1.a) against the pros of (1.a) / 
cons of (1.b) or against the effort that (2) will require, and taking into consideration the 
effort that was already invested, I am not strongly against (1.a) as well.

[1] http://gerrit.ovirt.org/#/c/14635/

> ...
 


From iheim at redhat.com  Fri May 31 16:03:09 2013
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 31 May 2013 19:03:09 +0300
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <909641716.16748965.1370015793965.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<1603402923.13784806.1369783809299.JavaMail.root@redhat.com>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
	<1910975758.14088419.1369830090869.JavaMail.root@redhat.com>
	<841607815.31395487.1369929419144.JavaMail.root@redhat.com>
	<2014639425.11839457.1369981377910.JavaMail.root@redhat.com>
	<1493549047.16382669.1370000699204.JavaMail.root@redhat.com>
	<73EDF069-94CA-4BEC-8464-F1006BA4954C@redhat.com>
	<909641716.16748965.1370015793965.JavaMail.root@redhat.com>
Message-ID: <51A8C9BD.5040706@redhat.com>

On 05/31/2013 06:56 PM, Einav Cohen wrote:
>>> ...
>>>
>>> [1] my main concern is that this batch of patches (dialog reorg) will make
>>> it into ovirt
>>> 3.3, but the second batch (which will contain the actual Instance Types
>>> fields) won't make
>>> it in time [see the ovirt 3.3 schedule in:
>>> http://www.ovirt.org/OVirt_3.3_release-management -
>>> ovirt 3.3 feature freeze is today (?!)]; so I wouldn't want to see ovirt
>>> 3.3 being released
>>> with only the first patch batch merged into it. either both batches should
>>> be there, or
>>> both batches should not be there.
>>
>> There was a discussion about postponing it, but not much further it seems.
>> In any case It may not be necessarily wrong to have dialog reorg in 3.3
>> without insttypes as it will at least get people to get used to it and we
>> can gather feedback. It's not that it removes any functionality, on the
>> contrary, e.g. the type ahead feature even solves some of the bugs we
>> already have.
>
> indeed - it doesn't remove functionality, and I agree that it would be a good
> opportunity to get feedback about some things such as the type-ahead list box,
> however the top static header in particular with only the DC/Cluster + Quota
> in it may seem strange / annoying, as it would just seem like something that
> takes up "real estate" in the dialog in *all* side-tab without a real good reason.

but the optimize for desktop/server already start to affect other panes?

>
> so there are pros and cons for introducing only the first patch batch to ovirt-3.3,
> I guess; Ideally, I would suggest to maybe re-organize the patches a bit differently,
> so that the top static header in particular wouldn't be part of this first patch batch,
> i.e., I would suggest introducing the top static header along with adding the Instance
> Types fields [which, to my understanding, is exactly what Daniel has originally suggested
> on the patch [1] in his gerrit comment(s) from May 28/29 (depends on the timezone) -
> only now I fully understand his concern (I think/hope)...].
>
> not sure how easy it is to do though - I know that *a lot* of time and effort were
> already invested in these patches as they are now, and I wouldn't want that the reviewing/
> merging process will be held off for much longer.
>
> To sum up: these are the options, as I see them:
>
> 1) keep the current patch batch as is and:
>
>     a. merge it in time for ovirt-3.3, or:
>
>     b. merge it post ovirt-3.3.
>
> - or -
>
> 2) go with what Daniel has suggested in his gerrit comment: reorganize the patches so that
> the top static header would be introduced only along with the instance types fields [that
> way, it won't matter what makes it into ovirt-3.3 - the first patch batch, or both (or none)].
>
> I am in favor of (1.b) or (2). However, weighing the cons of (1.a) against the pros of (1.a) /
> cons of (1.b) or against the effort that (2) will require, and taking into consideration the
> effort that was already invested, I am not strongly against (1.a) as well.
>
> [1] http://gerrit.ovirt.org/#/c/14635/
>
>> ...
>
>



From ecohen at redhat.com  Fri May 31 16:28:19 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Fri, 31 May 2013 12:28:19 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <51A8C9BD.5040706@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<1910975758.14088419.1369830090869.JavaMail.root@redhat.com>
	<841607815.31395487.1369929419144.JavaMail.root@redhat.com>
	<2014639425.11839457.1369981377910.JavaMail.root@redhat.com>
	<1493549047.16382669.1370000699204.JavaMail.root@redhat.com>
	<73EDF069-94CA-4BEC-8464-F1006BA4954C@redhat.com>
	<909641716.16748965.1370015793965.JavaMail.root@redhat.com>
	<51A8C9BD.5040706@redhat.com>
Message-ID: <1754688018.16770394.1370017699165.JavaMail.root@redhat.com>

> ----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> Sent: Friday, May 31, 2013 12:03:09 PM
> 
> On 05/31/2013 06:56 PM, Einav Cohen wrote:
> >>> ...
> >>>
> >>> [1] my main concern is that this batch of patches (dialog reorg) will
> >>> make
> >>> it into ovirt
> >>> 3.3, but the second batch (which will contain the actual Instance Types
> >>> fields) won't make
> >>> it in time [see the ovirt 3.3 schedule in:
> >>> http://www.ovirt.org/OVirt_3.3_release-management -
> >>> ovirt 3.3 feature freeze is today (?!)]; so I wouldn't want to see ovirt
> >>> 3.3 being released
> >>> with only the first patch batch merged into it. either both batches
> >>> should
> >>> be there, or
> >>> both batches should not be there.
> >>
> >> There was a discussion about postponing it, but not much further it seems.
> >> In any case It may not be necessarily wrong to have dialog reorg in 3.3
> >> without insttypes as it will at least get people to get used to it and we
> >> can gather feedback. It's not that it removes any functionality, on the
> >> contrary, e.g. the type ahead feature even solves some of the bugs we
> >> already have.
> >
> > indeed - it doesn't remove functionality, and I agree that it would be a
> > good
> > opportunity to get feedback about some things such as the type-ahead list
> > box,
> > however the top static header in particular with only the DC/Cluster +
> > Quota
> > in it may seem strange / annoying, as it would just seem like something
> > that
> > takes up "real estate" in the dialog in *all* side-tab without a real good
> > reason.
> 
> but the optimize for desktop/server already start to affect other panes?

quoting Tomas:

"""
the first patch we are talking about (http://gerrit.ovirt.org/#/c/14635)
adds only Data Center, Cluster and Quota to the header. 
There is a second patch (http://gerrit.ovirt.org/#/c/15011/) which moves the OS type and 
template to the header.
"""

so IIUC, the first patch batch [2] will include moving the following fields into the 
static header:

- DataCenter/Cluster
- Quota
- OS type
- Template

@Tomas - I suggest that you will clarify:

A) which fields exactly are going to be included in the top static header of the New VM 
dialog *in your current patch batch* [2], and:

B) which side-tabs in the New VM dialog will be affected by the fields in (A).

[there is a chance that the fields in (A) already affect a lot of the side-tabs, which means 
that it would actually make sense to introduce the top static section in the current patch 
batch, even without the Instance Types / Images fields included in it, which is what (I think) 
Itamar is implying]


[2] the current patch batch, to my understanding, is:

http://gerrit.ovirt.org/#/c/14635/
http://gerrit.ovirt.org/#/c/14810/
http://gerrit.ovirt.org/#/c/14936/
http://gerrit.ovirt.org/#/c/15011/
http://gerrit.ovirt.org/#/c/15048/
http://gerrit.ovirt.org/#/c/15102/
http://gerrit.ovirt.org/#/c/15199/


> 
> >
> > so there are pros and cons for introducing only the first patch batch to
> > ovirt-3.3,
> > I guess; Ideally, I would suggest to maybe re-organize the patches a bit
> > differently,
> > so that the top static header in particular wouldn't be part of this first
> > patch batch,
> > i.e., I would suggest introducing the top static header along with adding
> > the Instance
> > Types fields [which, to my understanding, is exactly what Daniel has
> > originally suggested
> > on the patch [1] in his gerrit comment(s) from May 28/29 (depends on the
> > timezone) -
> > only now I fully understand his concern (I think/hope)...].
> >
> > not sure how easy it is to do though - I know that *a lot* of time and
> > effort were
> > already invested in these patches as they are now, and I wouldn't want that
> > the reviewing/
> > merging process will be held off for much longer.
> >
> > To sum up: these are the options, as I see them:
> >
> > 1) keep the current patch batch as is and:
> >
> >     a. merge it in time for ovirt-3.3, or:
> >
> >     b. merge it post ovirt-3.3.
> >
> > - or -
> >
> > 2) go with what Daniel has suggested in his gerrit comment: reorganize the
> > patches so that
> > the top static header would be introduced only along with the instance
> > types fields [that
> > way, it won't matter what makes it into ovirt-3.3 - the first patch batch,
> > or both (or none)].
> >
> > I am in favor of (1.b) or (2). However, weighing the cons of (1.a) against
> > the pros of (1.a) /
> > cons of (1.b) or against the effort that (2) will require, and taking into
> > consideration the
> > effort that was already invested, I am not strongly against (1.a) as well.
> >
> > [1] http://gerrit.ovirt.org/#/c/14635/
> >
> >> ...
> >
> >
> 
> 


From derez at redhat.com  Fri May 31 16:28:54 2013
From: derez at redhat.com (Daniel Erez)
Date: Fri, 31 May 2013 12:28:54 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <909641716.16748965.1370015793965.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<559238979.7794816.1369805763901.JavaMail.root@redhat.com>
	<1910975758.14088419.1369830090869.JavaMail.root@redhat.com>
	<841607815.31395487.1369929419144.JavaMail.root@redhat.com>
	<2014639425.11839457.1369981377910.JavaMail.root@redhat.com>
	<1493549047.16382669.1370000699204.JavaMail.root@redhat.com>
	<73EDF069-94CA-4BEC-8464-F1006BA4954C@redhat.com>
	<909641716.16748965.1370015793965.JavaMail.root@redhat.com>
Message-ID: <613894007.9673380.1370017734535.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: "Eldan Hildesheim" <info at eldanet.com>, "engine-devel" <engine-devel at ovirt.org>, "Eldan Hildesheim"
> <ehildesh at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>, "Itamar Heim"
> <iheim at redhat.com>
> Sent: Friday, May 31, 2013 6:56:33 PM
> Subject: Re: [Engine-devel] static header only in VM dialog?
> 
> > > ...
> > > 
> > > [1] my main concern is that this batch of patches (dialog reorg) will
> > > make
> > > it into ovirt
> > > 3.3, but the second batch (which will contain the actual Instance Types
> > > fields) won't make
> > > it in time [see the ovirt 3.3 schedule in:
> > > http://www.ovirt.org/OVirt_3.3_release-management -
> > > ovirt 3.3 feature freeze is today (?!)]; so I wouldn't want to see ovirt
> > > 3.3 being released
> > > with only the first patch batch merged into it. either both batches
> > > should
> > > be there, or
> > > both batches should not be there.
> > 
> > There was a discussion about postponing it, but not much further it seems.
> > In any case It may not be necessarily wrong to have dialog reorg in 3.3
> > without insttypes as it will at least get people to get used to it and we
> > can gather feedback. It's not that it removes any functionality, on the
> > contrary, e.g. the type ahead feature even solves some of the bugs we
> > already have.
> 
> indeed - it doesn't remove functionality, and I agree that it would be a good
> opportunity to get feedback about some things such as the type-ahead list
> box,
> however the top static header in particular with only the DC/Cluster + Quota
> in it may seem strange / annoying, as it would just seem like something that
> takes up "real estate" in the dialog in *all* side-tab without a real good
> reason.
> 
> so there are pros and cons for introducing only the first patch batch to
> ovirt-3.3,
> I guess; Ideally, I would suggest to maybe re-organize the patches a bit
> differently,
> so that the top static header in particular wouldn't be part of this first
> patch batch,
> i.e., I would suggest introducing the top static header along with adding the
> Instance
> Types fields [which, to my understanding, is exactly what Daniel has
> originally suggested
> on the patch [1] in his gerrit comment(s) from May 28/29 (depends on the
> timezone) -
> only now I fully understand his concern (I think/hope)...].

Exactly, I prefer that the static header will be introduced along with the new dialog
I.e. squashed with the final dialog patch (with instance types fields).
I understand that the static header might make sense for the final dialog
(though I still don't like the idea that it's relevant only for some side-tabs).
Added my remarks to the patch: http://gerrit.ovirt.org/#/c/14635/

> 
> not sure how easy it is to do though - I know that *a lot* of time and effort
> were
> already invested in these patches as they are now, and I wouldn't want that
> the reviewing/
> merging process will be held off for much longer.
> 
> To sum up: these are the options, as I see them:
> 
> 1) keep the current patch batch as is and:
> 
>    a. merge it in time for ovirt-3.3, or:
> 
>    b. merge it post ovirt-3.3.
> 
> - or -
> 
> 2) go with what Daniel has suggested in his gerrit comment: reorganize the
> patches so that
> the top static header would be introduced only along with the instance types
> fields [that
> way, it won't matter what makes it into ovirt-3.3 - the first patch batch, or
> both (or none)].
> 
> I am in favor of (1.b) or (2). However, weighing the cons of (1.a) against
> the pros of (1.a) /
> cons of (1.b) or against the effort that (2) will require, and taking into
> consideration the
> effort that was already invested, I am not strongly against (1.a) as well.
> 
> [1] http://gerrit.ovirt.org/#/c/14635/
> 
> > ...
>  
> 


From ecohen at redhat.com  Fri May 31 17:18:53 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Fri, 31 May 2013 13:18:53 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <613894007.9673380.1370017734535.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<1910975758.14088419.1369830090869.JavaMail.root@redhat.com>
	<841607815.31395487.1369929419144.JavaMail.root@redhat.com>
	<2014639425.11839457.1369981377910.JavaMail.root@redhat.com>
	<1493549047.16382669.1370000699204.JavaMail.root@redhat.com>
	<73EDF069-94CA-4BEC-8464-F1006BA4954C@redhat.com>
	<909641716.16748965.1370015793965.JavaMail.root@redhat.com>
	<613894007.9673380.1370017734535.JavaMail.root@redhat.com>
Message-ID: <1035434474.16802346.1370020733824.JavaMail.root@redhat.com>

> ----- Original Message -----
> From: "Daniel Erez" <derez at redhat.com>
> Sent: Friday, May 31, 2013 12:28:54 PM
> 
> 
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Tomas Jelinek"
> > <tjelinek at redhat.com>
> > Cc: "Eldan Hildesheim" <info at eldanet.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "Eldan Hildesheim"
> > <ehildesh at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Malini Rao"
> > <mrao at redhat.com>, "Itamar Heim"
> > <iheim at redhat.com>
> > Sent: Friday, May 31, 2013 6:56:33 PM
> > Subject: Re: [Engine-devel] static header only in VM dialog?
> > 
> > > > ...
> > > > 
> > > > [1] my main concern is that this batch of patches (dialog reorg) will
> > > > make
> > > > it into ovirt
> > > > 3.3, but the second batch (which will contain the actual Instance Types
> > > > fields) won't make
> > > > it in time [see the ovirt 3.3 schedule in:
> > > > http://www.ovirt.org/OVirt_3.3_release-management -
> > > > ovirt 3.3 feature freeze is today (?!)]; so I wouldn't want to see
> > > > ovirt
> > > > 3.3 being released
> > > > with only the first patch batch merged into it. either both batches
> > > > should
> > > > be there, or
> > > > both batches should not be there.
> > > 
> > > There was a discussion about postponing it, but not much further it
> > > seems.
> > > In any case It may not be necessarily wrong to have dialog reorg in 3.3
> > > without insttypes as it will at least get people to get used to it and we
> > > can gather feedback. It's not that it removes any functionality, on the
> > > contrary, e.g. the type ahead feature even solves some of the bugs we
> > > already have.
> > 
> > indeed - it doesn't remove functionality, and I agree that it would be a
> > good
> > opportunity to get feedback about some things such as the type-ahead list
> > box,
> > however the top static header in particular with only the DC/Cluster +
> > Quota
> > in it may seem strange / annoying, as it would just seem like something
> > that
> > takes up "real estate" in the dialog in *all* side-tab without a real good
> > reason.
> > 
> > so there are pros and cons for introducing only the first patch batch to
> > ovirt-3.3,
> > I guess; Ideally, I would suggest to maybe re-organize the patches a bit
> > differently,
> > so that the top static header in particular wouldn't be part of this first
> > patch batch,
> > i.e., I would suggest introducing the top static header along with adding
> > the
> > Instance
> > Types fields [which, to my understanding, is exactly what Daniel has
> > originally suggested
> > on the patch [1] in his gerrit comment(s) from May 28/29 (depends on the
> > timezone) -
> > only now I fully understand his concern (I think/hope)...].
> 
> Exactly, I prefer that the static header will be introduced along with the
> new dialog
> I.e. squashed with the final dialog patch (with instance types fields).
> I understand that the static header might make sense for the final dialog

- I am actually waiting for Tomas's response on what exactly is going to be included 
within the top static header of the dialog in his current 7-patches batch (see my 
previous response in the thread) - there is a chance that it makes some sense to 
introduce the top static section at this stage (instead of waiting for the "final 
dialog patch" in which the Instance Types and Image fields will be introduced), as 
it already affects a "nice" amount of side-tabs.

- even if the fields that are included in the top static header in the current 
patch-batch don't really justify introducing the top static section at this stage, 
there are other things that (IMO) should be taken into consideration when deciding 
how to proceed [see my (1.a), (1.b), (2) "essay" in one of my previous responses 
in the thread]

> (though I still don't like the idea that it's relevant only for some
> side-tabs).

I think that UX wise (and Malini/Eldan can comment on that), if the top section affect 
a significant amount of side-tabs, it is better that this section would be displayed 
in *all* side tabs, rather than have it visible only in the relevant side-tabs, which 
can be a bit irritating to the eye when "jumping" between side-tabs.

[of course, I assume that completely different, creative solutions can be found, but 
even if so - I suggest to think about them in a later stage, after introducing the 
Instance Types feature into the system / getting some more feedback on the current 
top static header solution]

> Added my remarks to the patch: http://gerrit.ovirt.org/#/c/14635/
> 
> > 
> > not sure how easy it is to do though - I know that *a lot* of time and
> > effort
> > were
> > already invested in these patches as they are now, and I wouldn't want that
> > the reviewing/
> > merging process will be held off for much longer.
> > 
> > To sum up: these are the options, as I see them:
> > 
> > 1) keep the current patch batch as is and:
> > 
> >    a. merge it in time for ovirt-3.3, or:
> > 
> >    b. merge it post ovirt-3.3.
> > 
> > - or -
> > 
> > 2) go with what Daniel has suggested in his gerrit comment: reorganize the
> > patches so that
> > the top static header would be introduced only along with the instance
> > types
> > fields [that
> > way, it won't matter what makes it into ovirt-3.3 - the first patch batch,
> > or
> > both (or none)].
> > 
> > I am in favor of (1.b) or (2). However, weighing the cons of (1.a) against
> > the pros of (1.a) /
> > cons of (1.b) or against the effort that (2) will require, and taking into
> > consideration the
> > effort that was already invested, I am not strongly against (1.a) as well.
> > 
> > [1] http://gerrit.ovirt.org/#/c/14635/
> > 
> > > ...
> >  
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From mrao at redhat.com  Fri May 31 17:28:42 2013
From: mrao at redhat.com (Malini Rao)
Date: Fri, 31 May 2013 13:28:42 -0400 (EDT)
Subject: [Engine-devel] static header only in VM dialog?
In-Reply-To: <1035434474.16802346.1370020733824.JavaMail.root@redhat.com>
References: <gerrit.1368170341473.Icad8098e286f821da25fac22fd0a840a42f105c9@gerrit.ovirt.org>
	<841607815.31395487.1369929419144.JavaMail.root@redhat.com>
	<2014639425.11839457.1369981377910.JavaMail.root@redhat.com>
	<1493549047.16382669.1370000699204.JavaMail.root@redhat.com>
	<73EDF069-94CA-4BEC-8464-F1006BA4954C@redhat.com>
	<909641716.16748965.1370015793965.JavaMail.root@redhat.com>
	<613894007.9673380.1370017734535.JavaMail.root@redhat.com>
	<1035434474.16802346.1370020733824.JavaMail.root@redhat.com>
Message-ID: <1032392108.32086738.1370021322340.JavaMail.root@redhat.com>





----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Daniel Erez" <derez at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>, "Malini Rao" <mrao at redhat.com>, "Eldan
> Hildesheim" <info at eldanet.com>, "Eldan Hildesheim" <ehildesh at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Itamar Heim" <iheim at redhat.com>
> Sent: Friday, May 31, 2013 1:18:53 PM
> Subject: Re: [Engine-devel] static header only in VM dialog?
> 
> > ----- Original Message -----
> > From: "Daniel Erez" <derez at redhat.com>
> > Sent: Friday, May 31, 2013 12:28:54 PM
> > 
> > 
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen at redhat.com>
> > > To: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Tomas Jelinek"
> > > <tjelinek at redhat.com>
> > > Cc: "Eldan Hildesheim" <info at eldanet.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, "Eldan Hildesheim"
> > > <ehildesh at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Malini Rao"
> > > <mrao at redhat.com>, "Itamar Heim"
> > > <iheim at redhat.com>
> > > Sent: Friday, May 31, 2013 6:56:33 PM
> > > Subject: Re: [Engine-devel] static header only in VM dialog?
> > > 
> > > > > ...
> > > > > 
> > > > > [1] my main concern is that this batch of patches (dialog reorg) will
> > > > > make
> > > > > it into ovirt
> > > > > 3.3, but the second batch (which will contain the actual Instance
> > > > > Types
> > > > > fields) won't make
> > > > > it in time [see the ovirt 3.3 schedule in:
> > > > > http://www.ovirt.org/OVirt_3.3_release-management -
> > > > > ovirt 3.3 feature freeze is today (?!)]; so I wouldn't want to see
> > > > > ovirt
> > > > > 3.3 being released
> > > > > with only the first patch batch merged into it. either both batches
> > > > > should
> > > > > be there, or
> > > > > both batches should not be there.
> > > > 
> > > > There was a discussion about postponing it, but not much further it
> > > > seems.
> > > > In any case It may not be necessarily wrong to have dialog reorg in 3.3
> > > > without insttypes as it will at least get people to get used to it and
> > > > we
> > > > can gather feedback. It's not that it removes any functionality, on the
> > > > contrary, e.g. the type ahead feature even solves some of the bugs we
> > > > already have.
> > > 
> > > indeed - it doesn't remove functionality, and I agree that it would be a
> > > good
> > > opportunity to get feedback about some things such as the type-ahead list
> > > box,
> > > however the top static header in particular with only the DC/Cluster +
> > > Quota
> > > in it may seem strange / annoying, as it would just seem like something
> > > that
> > > takes up "real estate" in the dialog in *all* side-tab without a real
> > > good
> > > reason.
> > > 
> > > so there are pros and cons for introducing only the first patch batch to
> > > ovirt-3.3,
> > > I guess; Ideally, I would suggest to maybe re-organize the patches a bit
> > > differently,
> > > so that the top static header in particular wouldn't be part of this
> > > first
> > > patch batch,
> > > i.e., I would suggest introducing the top static header along with adding
> > > the
> > > Instance
> > > Types fields [which, to my understanding, is exactly what Daniel has
> > > originally suggested
> > > on the patch [1] in his gerrit comment(s) from May 28/29 (depends on the
> > > timezone) -
> > > only now I fully understand his concern (I think/hope)...].
> > 
> > Exactly, I prefer that the static header will be introduced along with the
> > new dialog
> > I.e. squashed with the final dialog patch (with instance types fields).
> > I understand that the static header might make sense for the final dialog
> 
> - I am actually waiting for Tomas's response on what exactly is going to be
> included
> within the top static header of the dialog in his current 7-patches batch
> (see my
> previous response in the thread) - there is a chance that it makes some sense
> to
> introduce the top static section at this stage (instead of waiting for the
> "final
> dialog patch" in which the Instance Types and Image fields will be
> introduced), as
> it already affects a "nice" amount of side-tabs.
> 
> - even if the fields that are included in the top static header in the
> current
> patch-batch don't really justify introducing the top static section at this
> stage,
> there are other things that (IMO) should be taken into consideration when
> deciding
> how to proceed [see my (1.a), (1.b), (2) "essay" in one of my previous
> responses
> in the thread]
> 
> > (though I still don't like the idea that it's relevant only for some
> > side-tabs).
> 
> I think that UX wise (and Malini/Eldan can comment on that), if the top
> section affect
> a significant amount of side-tabs, it is better that this section would be
> displayed
> in *all* side tabs, rather than have it visible only in the relevant
> side-tabs, which
> can be a bit irritating to the eye when "jumping" between side-tabs.


MR - Yes, if we have a static top panel, it should be truly static- i.e, it should stay displayed irrespective of whether the currently selected side tab has a dependency or context info on the static panel or not.  


> 
> [of course, I assume that completely different, creative solutions can be
> found, but
> even if so - I suggest to think about them in a later stage, after
> introducing the
> Instance Types feature into the system / getting some more feedback on the
> current
> top static header solution]
> 
> > Added my remarks to the patch: http://gerrit.ovirt.org/#/c/14635/
> > 
> > > 
> > > not sure how easy it is to do though - I know that *a lot* of time and
> > > effort
> > > were
> > > already invested in these patches as they are now, and I wouldn't want
> > > that
> > > the reviewing/
> > > merging process will be held off for much longer.
> > > 
> > > To sum up: these are the options, as I see them:
> > > 
> > > 1) keep the current patch batch as is and:
> > > 
> > >    a. merge it in time for ovirt-3.3, or:
> > > 
> > >    b. merge it post ovirt-3.3.
> > > 
> > > - or -
> > > 
> > > 2) go with what Daniel has suggested in his gerrit comment: reorganize
> > > the
> > > patches so that
> > > the top static header would be introduced only along with the instance
> > > types
> > > fields [that
> > > way, it won't matter what makes it into ovirt-3.3 - the first patch
> > > batch,
> > > or
> > > both (or none)].
> > > 
> > > I am in favor of (1.b) or (2). However, weighing the cons of (1.a)
> > > against
> > > the pros of (1.a) /
> > > cons of (1.b) or against the effort that (2) will require, and taking
> > > into
> > > consideration the
> > > effort that was already invested, I am not strongly against (1.a) as
> > > well.
> > > 
> > > [1] http://gerrit.ovirt.org/#/c/14635/
> > > 
> > > > ...
> > >  
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> 


From mburns at redhat.com  Fri May 31 18:09:32 2013
From: mburns at redhat.com (Mike Burns)
Date: Fri, 31 May 2013 14:09:32 -0400
Subject: [Engine-devel] ovirt fails to install on f19 from fedora repos
Message-ID: <51A8E75C.7010805@redhat.com>

A couple problems came up today on IRC.

* Current version of oVirt in Fedora is 3.1.
* installing oVirt on F19 beta (from fedora repos, not ovirt.org) fails 
because classpathx-mail was removed from fedora and is a dependency for 
ovirt-engine-notification-service

AFAICT, the notification-service was obsoleted in 3.2 at some point. 
Can we either get ovirt-engine rpms updated in F19 or removed completely?

Mike


From jenkins at ovirt.org  Fri May 31 23:02:10 2013
From: jenkins at ovirt.org (Jenkins ci oVirt Server)
Date: Sat, 1 Jun 2013 00:02:10 +0100 (BST)
Subject: [Engine-devel] [oVirt jenkins] Weekly report on open tasks for
	ovirt-engine
Message-ID: <1067594688.4422.1370041331369.JavaMail.jenkins@jenkins.ovirt.org>

An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130601/663e7e87/attachment.html>