From lpeer at redhat.com  Tue Jan  1 07:05:03 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 01 Jan 2013 09:05:03 +0200
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <1061251071.59555727.1356966301141.JavaMail.root@redhat.com>
References: <1061251071.59555727.1356966301141.JavaMail.root@redhat.com>
Message-ID: <50E28A9F.1030503@redhat.com>

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

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

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

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

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

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

> 
> 2. Use local JBoss profile.
> Have everything we need in my-standalone.conf and start running jboss
> with a local profile. This conf file may be generated or copied once
> when running mvn -Psetup 
> 
> We can also inject the relevant environment variables to the global
> standalone.conf as we do for debugging, but this cannot be used in
> the students use case, unless we have host-level config.
> 
> I know many are still in vacation due to the holidays, so we should
> wait for a few more days before making a final decision. Still feel
> free to ack / nack / suggest your own.
> 
> Doron 
> 



From alonbl at redhat.com  Tue Jan  1 07:30:20 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 1 Jan 2013 02:30:20 -0500 (EST)
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <50E28A9F.1030503@redhat.com>
Message-ID: <75009959.6944220.1357025420112.JavaMail.root@redhat.com>



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

I strongly reject to have default suitable for DEVELOPMENT mode.
This was indeed the situation in the past, and may (and have) cause DEVELOPMENT setting to leak into PRODUCTION.
In development mode, the developer should explicitly state that he want to use DEVELOPMENT settings either by configuration or by environment, this way no DEVELOPMENT settings will effect intended PRODUCTION settings.

> 
> > My use case is exactly what Juan describes, but I think the
> > resolution
> > should be different. ie- contributers should be able to git clone
> > and once they setup jboss & postgres they should be able to have
> > something running.
> > 
> > We cannot assume /etc is a location contributers can access. Think
> > of university students who would like to see how ovirt works using
> > university's machines. In the past they may have had issues with
> > JBoss, but that's already handled by profiles. So there's really
> > no need for oVirt to ask them more than that. I know UI plugins
> > are using this infra, but remember that the plugins are completely
> > optional and should not block basic operation.
> > 
> > Some more concerns this issue raises are related to release
> > versions;
> > What happens when we need to support more than one jboss and/or
> > release version?
> > 
> > So here are 2 options we should consider in order to allow local
> > config without additional requirements:
> > 
> > 1. Use defaults.
> > System should boot and start in whichever way we decide without
> > anything else needed. Local configuration can override these
> > defaults if it exists, but it should simply work.
> 
> The engine.conf.defaults holds default values for the keys, so I
> guess
> that by defaults you mean a way to have this file as part of our
> deploying | setup process and only for overriding values we should
> use
> /etc/sysconfig/ovirt-engine, which seems to be the original intention
> of
> the writer (according to the file documentation), I wonder where it
> went
> wrong...
> 
> > 
> > 2. Use local JBoss profile.
> > Have everything we need in my-standalone.conf and start running
> > jboss
> > with a local profile. This conf file may be generated or copied
> > once
> > when running mvn -Psetup
> > 
> > We can also inject the relevant environment variables to the global
> > standalone.conf as we do for debugging, but this cannot be used in
> > the students use case, unless we have host-level config.
> > 
> > I know many are still in vacation due to the holidays, so we should
> > wait for a few more days before making a final decision. Still feel
> > free to ack / nack / suggest your own.
> > 
> > Doron
> > 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dfediuck at redhat.com  Tue Jan  1 07:43:50 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 1 Jan 2013 02:43:50 -0500 (EST)
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <75009959.6944220.1357025420112.JavaMail.root@redhat.com>
Message-ID: <765263975.59706017.1357026230188.JavaMail.root@redhat.com>



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

Which can easily be handled when thinking of the difference between
(git clone + mvn -Psetup,dep) VS (yum install).

The first one can simply work. The latter in handled by the RPM.
No need to impose additional burdens on developers which are
already handled for production setups. Think of user management,
PKI infra, etc. All handled in production, and not needed for
the basic (git clone + mvn -Psetup,dep).

> > 
> > > My use case is exactly what Juan describes, but I think the
> > > resolution
> > > should be different. ie- contributers should be able to git clone
> > > and once they setup jboss & postgres they should be able to have
> > > something running.
> > > 
> > > We cannot assume /etc is a location contributers can access.
> > > Think
> > > of university students who would like to see how ovirt works
> > > using
> > > university's machines. In the past they may have had issues with
> > > JBoss, but that's already handled by profiles. So there's really
> > > no need for oVirt to ask them more than that. I know UI plugins
> > > are using this infra, but remember that the plugins are
> > > completely
> > > optional and should not block basic operation.
> > > 
> > > Some more concerns this issue raises are related to release
> > > versions;
> > > What happens when we need to support more than one jboss and/or
> > > release version?
> > > 
> > > So here are 2 options we should consider in order to allow local
> > > config without additional requirements:
> > > 
> > > 1. Use defaults.
> > > System should boot and start in whichever way we decide without
> > > anything else needed. Local configuration can override these
> > > defaults if it exists, but it should simply work.
> > 
> > The engine.conf.defaults holds default values for the keys, so I
> > guess
> > that by defaults you mean a way to have this file as part of our
> > deploying | setup process and only for overriding values we should
> > use
> > /etc/sysconfig/ovirt-engine, which seems to be the original
> > intention
> > of
> > the writer (according to the file documentation), I wonder where it
> > went
> > wrong...
> > 
> > > 
> > > 2. Use local JBoss profile.
> > > Have everything we need in my-standalone.conf and start running
> > > jboss
> > > with a local profile. This conf file may be generated or copied
> > > once
> > > when running mvn -Psetup
> > > 
> > > We can also inject the relevant environment variables to the
> > > global
> > > standalone.conf as we do for debugging, but this cannot be used
> > > in
> > > the students use case, unless we have host-level config.
> > > 
> > > I know many are still in vacation due to the holidays, so we
> > > should
> > > wait for a few more days before making a final decision. Still
> > > feel
> > > free to ack / nack / suggest your own.
> > > 
> > > Doron
> > > 
> > 
> > _______________________________________________
> > 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 Jan  1 07:56:05 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 1 Jan 2013 02:56:05 -0500 (EST)
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <765263975.59706017.1357026230188.JavaMail.root@redhat.com>
Message-ID: <93122783.6944332.1357026965164.JavaMail.root@redhat.com>



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

Yes, we can do this many ways.
I did not read the entire new sequence, I will be happy if you refer me to it.
However, this is what I think is expected...

$ make PREFIX=$HOME/ovirt-engine-root
$ make PREFIX=$HOME/ovirt-engine-root DEVELOPMENT=1 install

The DEVELOPMENT=1 will generate the correct conf.d configuration file to override PRODUCTION settings with DEVELOPMENT settings.

Optionally, we may require:
. $HOME/ovirt-engine-root/vars

To add stuff into environment, before we can use the programs.

Then you have all you need at PREFIX, including a start/stop script.

Alon


From dfediuck at redhat.com  Tue Jan  1 08:08:32 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 1 Jan 2013 03:08:32 -0500 (EST)
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <93122783.6944332.1357026965164.JavaMail.root@redhat.com>
Message-ID: <1327522027.59707326.1357027712072.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org, "Livnat Peer" <lpeer at redhat.com>
> Sent: Tuesday, January 1, 2013 9:56:05 AM
> Subject: Re: [Engine-devel] Engine local configuration
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org,
> > "Livnat Peer" <lpeer at redhat.com>
> > Sent: Tuesday, January 1, 2013 9:43:50 AM
> > Subject: Re: [Engine-devel] Engine local configuration
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "Livnat Peer" <lpeer at redhat.com>
> > > Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > > engine-devel at ovirt.org
> > > Sent: Tuesday, January 1, 2013 9:30:20 AM
> > > Subject: Re: [Engine-devel] Engine local configuration
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Livnat Peer" <lpeer at redhat.com>
> > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > > > engine-devel at ovirt.org
> > > > Sent: Tuesday, January 1, 2013 9:05:03 AM
> > > > Subject: Re: [Engine-devel] Engine local configuration
> > > > 
> > > > On 12/31/2012 05:05 PM, Doron Fediuck wrote:
> > > > > 
> > > > > ----- Original Message -----
> > > > >> From: "Juan Hernandez" <jhernand at redhat.com>
> > > > >> To: "Roy Golan" <rgolan at redhat.com>
> > > > >> Cc: engine-devel at ovirt.org
> > > > >> Sent: Friday, December 14, 2012 1:25:57 PM
> > > > >> Subject: Re: [Engine-devel] Error on starting webadmin
> > > > >>
> > > > >> On 12/13/2012 03:55 PM, Roy Golan wrote:
> > > > >>> On 12/13/2012 04:49 PM, Vojtech Szocs wrote:
> > > > >>>>> this is making the contribution process more complex.
> > > > >>>>> lets
> > > > >>>>> think
> > > > >>>>> of a
> > > > >>>>> lighter way to get a developing setup.
> > > > >>>> I agree, I just wanted to have the local Engine
> > > > >>>> configuration
> > > > >>>> steps documented for reference.. If there's a better way
> > > > >>>> to
> > > > >>>> do
> > > > >>>> it, I'm for it.
> > > > >>>>
> > > > >>>> Vojtech
> > > > >>>
> > > > >>> having LocalConfig look for "engine.conf.defaults" system
> > > > >>> property
> > > > >>> before fallback to System.getenv("ENGINE_DEFAULTS");
> > > > >>>   +  concatenating
> > > > >>>   -Dengine.conf.defaults=$HOME/.engine.conf.defaults
> > > > >>> to  JAVA_OPTS  on standalone.conf
> > > > >>
> > > > >> How is the system property simpler than the environment
> > > > >> variable?
> > > > >>
> > > > >> I agree that this makes the development process a bit more
> > > > >> complex
> > > > >> at
> > > > >> the moment, but I think that the way to make it simpler is
> > > > >> not
> > > > >> to
> > > > >> continue adding things to standalone.conf. I think that we
> > > > >> should
> > > > >> move
> > > > >> towards a development environment that is closer to the
> > > > >> production
> > > > >> environment, not the other way around. Ideally the developer
> > > > >> should
> > > > >> be
> > > > >> able to do something like "make install" to have the engine
> > > > >> deployed
> > > > >> to
> > > > >> a directory structure similar to what he have in the
> > > > >> production
> > > > >> environment. Then you should be able to go to the bin
> > > > >> directory
> > > > >> inside
> > > > >> that structure and start the engine (and the other tools)
> > > > >> using
> > > > >> the
> > > > >> same
> > > > >> script that we use in production environments. If we achieve
> > > > >> this
> > > > >> goal
> > > > >> then we have a simple development environment setup and also
> > > > >> we
> > > > >> have
> > > > >> all
> > > > >> developers testing almost the same thing that will go into
> > > > >> the
> > > > >> production environments. At the moment we don't have that,
> > > > >> most
> > > > >> times
> > > > >> you are testing something quite different (in terms of
> > > > >> directory
> > > > >> structure, configuration, etc) to what will be installed in
> > > > >> production
> > > > >> environments. I am working in that direction.
> > > > >>
> > > > > 
> > > > > Hi Guys,
> > > > > Sorry to resume this discussion, but I find the current
> > > > > situation
> > > > > unfriendly to most developers. I understand there's a need
> > > > > for
> > > > > specific configurations, but it seems to me that this has
> > > > > taken
> > > > > one step too far for most developers.
> > > > > 
> > > > > Further more, I expect to see such fundamental concepts being
> > > > > initially discussed here, and not settle with a technical
> > > > > ack,
> > > > > only to be a part of a thread called: "Error on starting
> > > > > webadmin".
> > > > > In this context I expect the verified flag to mean "This was
> > > > > discussed and verified with contributers in the relevant
> > > > > list".
> > > > > 
> > > > 
> > > > Hi Doron,
> > > > Thanks for bringing this on the list, I agree with everything
> > > > you
> > > > wrote
> > > > and could not put it any better myself.
> > > > 
> > > > I configured an environment from scratch yesterday and the
> > > > additional
> > > > step to have this config file in /etc does not feel right, not
> > > > to
> > > > mentioned that this is not documented in the wiki installation
> > > > page.
> > > > 
> > > > I think one of the guidelines we kept so far for setting a
> > > > development
> > > > environment and making it as easy as possible for new
> > > > developers
> > > > is
> > > > that
> > > > no manual step is needed on top of using the setup profile and
> > > > this
> > > > definitely breaks this assumption (at least with the way it is
> > > > handled
> > > > today).
> > > 
> > > I strongly reject to have default suitable for DEVELOPMENT mode.
> > > This was indeed the situation in the past, and may (and have)
> > > cause
> > > DEVELOPMENT setting to leak into PRODUCTION.
> > > In development mode, the developer should explicitly state that
> > > he
> > > want to use DEVELOPMENT settings either by configuration or by
> > > environment, this way no DEVELOPMENT settings will effect
> > > intended
> > > PRODUCTION settings.
> > > 
> > 
> > Which can easily be handled when thinking of the difference between
> > (git clone + mvn -Psetup,dep) VS (yum install).
> > 
> > The first one can simply work. The latter in handled by the RPM.
> > No need to impose additional burdens on developers which are
> > already handled for production setups. Think of user management,
> > PKI infra, etc. All handled in production, and not needed for
> > the basic (git clone + mvn -Psetup,dep).
> 
> Yes, we can do this many ways.
> I did not read the entire new sequence, I will be happy if you refer
> me to it.
> However, this is what I think is expected...
> 
> $ make PREFIX=$HOME/ovirt-engine-root
> $ make PREFIX=$HOME/ovirt-engine-root DEVELOPMENT=1 install
> 
> The DEVELOPMENT=1 will generate the correct conf.d configuration file
> to override PRODUCTION settings with DEVELOPMENT settings.
> 
> Optionally, we may require:
> . $HOME/ovirt-engine-root/vars
> 
> To add stuff into environment, before we can use the programs.
> 
> Then you have all you need at PREFIX, including a start/stop script.
> 
> Alon
> 

All we are saying is DEVELOPMENT=1 is the default, since the code
is built differently for production, and installed accordingly.
Additionally you may have more than one devel setup, for example for
different versions. So unless you override something (such as keystore
pass, jboss location) mvn -Pdep should simply work, and make XXX will
ensure whatever you need to override is done properly.



From alonbl at redhat.com  Tue Jan  1 08:10:13 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 1 Jan 2013 03:10:13 -0500 (EST)
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <50E2978B.7060503@redhat.com>
Message-ID: <979439809.6944389.1357027813416.JavaMail.root@redhat.com>



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

The development environment should be similar to the production environment as much as we can.
Hence, running engine-setup in development environment is something I would like to see.
The maven magic is not enough to setup such environment.
However, maven magic can be used to update existing environment with new java artifacts.

> 
> >>
> >>> My use case is exactly what Juan describes, but I think the
> >>> resolution
> >>> should be different. ie- contributers should be able to git clone
> >>> and once they setup jboss & postgres they should be able to have
> >>> something running.
> >>>
> >>> We cannot assume /etc is a location contributers can access.
> >>> Think
> >>> of university students who would like to see how ovirt works
> >>> using
> >>> university's machines. In the past they may have had issues with
> >>> JBoss, but that's already handled by profiles. So there's really
> >>> no need for oVirt to ask them more than that. I know UI plugins
> >>> are using this infra, but remember that the plugins are
> >>> completely
> >>> optional and should not block basic operation.
> >>>
> >>> Some more concerns this issue raises are related to release
> >>> versions;
> >>> What happens when we need to support more than one jboss and/or
> >>> release version?
> >>>
> >>> So here are 2 options we should consider in order to allow local
> >>> config without additional requirements:
> >>>
> >>> 1. Use defaults.
> >>> System should boot and start in whichever way we decide without
> >>> anything else needed. Local configuration can override these
> >>> defaults if it exists, but it should simply work.
> >>
> >> The engine.conf.defaults holds default values for the keys, so I
> >> guess
> >> that by defaults you mean a way to have this file as part of our
> >> deploying | setup process and only for overriding values we should
> >> use
> >> /etc/sysconfig/ovirt-engine, which seems to be the original
> >> intention
> >> of
> >> the writer (according to the file documentation), I wonder where
> >> it
> >> went
> >> wrong...
> >>
> >>>
> >>> 2. Use local JBoss profile.
> >>> Have everything we need in my-standalone.conf and start running
> >>> jboss
> >>> with a local profile. This conf file may be generated or copied
> >>> once
> >>> when running mvn -Psetup
> >>>
> >>> We can also inject the relevant environment variables to the
> >>> global
> >>> standalone.conf as we do for debugging, but this cannot be used
> >>> in
> >>> the students use case, unless we have host-level config.
> >>>
> >>> I know many are still in vacation due to the holidays, so we
> >>> should
> >>> wait for a few more days before making a final decision. Still
> >>> feel
> >>> free to ack / nack / suggest your own.
> >>>
> >>> Doron
> >>>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 


From alonbl at redhat.com  Tue Jan  1 08:15:37 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 1 Jan 2013 03:15:37 -0500 (EST)
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <1327522027.59707326.1357027712072.JavaMail.root@redhat.com>
Message-ID: <1618467007.6944403.1357028137584.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org, "Livnat Peer" <lpeer at redhat.com>
> Sent: Tuesday, January 1, 2013 10:08:32 AM
> Subject: Re: [Engine-devel] Engine local configuration
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org,
> > "Livnat Peer" <lpeer at redhat.com>
> > Sent: Tuesday, January 1, 2013 9:56:05 AM
> > Subject: Re: [Engine-devel] Engine local configuration
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > > engine-devel at ovirt.org,
> > > "Livnat Peer" <lpeer at redhat.com>
> > > Sent: Tuesday, January 1, 2013 9:43:50 AM
> > > Subject: Re: [Engine-devel] Engine local configuration
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > To: "Livnat Peer" <lpeer at redhat.com>
> > > > Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > > > engine-devel at ovirt.org
> > > > Sent: Tuesday, January 1, 2013 9:30:20 AM
> > > > Subject: Re: [Engine-devel] Engine local configuration
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Livnat Peer" <lpeer at redhat.com>
> > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > > > > engine-devel at ovirt.org
> > > > > Sent: Tuesday, January 1, 2013 9:05:03 AM
> > > > > Subject: Re: [Engine-devel] Engine local configuration
> > > > > 
> > > > > On 12/31/2012 05:05 PM, Doron Fediuck wrote:
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > >> From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > >> To: "Roy Golan" <rgolan at redhat.com>
> > > > > >> Cc: engine-devel at ovirt.org
> > > > > >> Sent: Friday, December 14, 2012 1:25:57 PM
> > > > > >> Subject: Re: [Engine-devel] Error on starting webadmin
> > > > > >>
> > > > > >> On 12/13/2012 03:55 PM, Roy Golan wrote:
> > > > > >>> On 12/13/2012 04:49 PM, Vojtech Szocs wrote:
> > > > > >>>>> this is making the contribution process more complex.
> > > > > >>>>> lets
> > > > > >>>>> think
> > > > > >>>>> of a
> > > > > >>>>> lighter way to get a developing setup.
> > > > > >>>> I agree, I just wanted to have the local Engine
> > > > > >>>> configuration
> > > > > >>>> steps documented for reference.. If there's a better way
> > > > > >>>> to
> > > > > >>>> do
> > > > > >>>> it, I'm for it.
> > > > > >>>>
> > > > > >>>> Vojtech
> > > > > >>>
> > > > > >>> having LocalConfig look for "engine.conf.defaults" system
> > > > > >>> property
> > > > > >>> before fallback to System.getenv("ENGINE_DEFAULTS");
> > > > > >>>   +  concatenating
> > > > > >>>   -Dengine.conf.defaults=$HOME/.engine.conf.defaults
> > > > > >>> to  JAVA_OPTS  on standalone.conf
> > > > > >>
> > > > > >> How is the system property simpler than the environment
> > > > > >> variable?
> > > > > >>
> > > > > >> I agree that this makes the development process a bit more
> > > > > >> complex
> > > > > >> at
> > > > > >> the moment, but I think that the way to make it simpler is
> > > > > >> not
> > > > > >> to
> > > > > >> continue adding things to standalone.conf. I think that we
> > > > > >> should
> > > > > >> move
> > > > > >> towards a development environment that is closer to the
> > > > > >> production
> > > > > >> environment, not the other way around. Ideally the
> > > > > >> developer
> > > > > >> should
> > > > > >> be
> > > > > >> able to do something like "make install" to have the
> > > > > >> engine
> > > > > >> deployed
> > > > > >> to
> > > > > >> a directory structure similar to what he have in the
> > > > > >> production
> > > > > >> environment. Then you should be able to go to the bin
> > > > > >> directory
> > > > > >> inside
> > > > > >> that structure and start the engine (and the other tools)
> > > > > >> using
> > > > > >> the
> > > > > >> same
> > > > > >> script that we use in production environments. If we
> > > > > >> achieve
> > > > > >> this
> > > > > >> goal
> > > > > >> then we have a simple development environment setup and
> > > > > >> also
> > > > > >> we
> > > > > >> have
> > > > > >> all
> > > > > >> developers testing almost the same thing that will go into
> > > > > >> the
> > > > > >> production environments. At the moment we don't have that,
> > > > > >> most
> > > > > >> times
> > > > > >> you are testing something quite different (in terms of
> > > > > >> directory
> > > > > >> structure, configuration, etc) to what will be installed
> > > > > >> in
> > > > > >> production
> > > > > >> environments. I am working in that direction.
> > > > > >>
> > > > > > 
> > > > > > Hi Guys,
> > > > > > Sorry to resume this discussion, but I find the current
> > > > > > situation
> > > > > > unfriendly to most developers. I understand there's a need
> > > > > > for
> > > > > > specific configurations, but it seems to me that this has
> > > > > > taken
> > > > > > one step too far for most developers.
> > > > > > 
> > > > > > Further more, I expect to see such fundamental concepts
> > > > > > being
> > > > > > initially discussed here, and not settle with a technical
> > > > > > ack,
> > > > > > only to be a part of a thread called: "Error on starting
> > > > > > webadmin".
> > > > > > In this context I expect the verified flag to mean "This
> > > > > > was
> > > > > > discussed and verified with contributers in the relevant
> > > > > > list".
> > > > > > 
> > > > > 
> > > > > Hi Doron,
> > > > > Thanks for bringing this on the list, I agree with everything
> > > > > you
> > > > > wrote
> > > > > and could not put it any better myself.
> > > > > 
> > > > > I configured an environment from scratch yesterday and the
> > > > > additional
> > > > > step to have this config file in /etc does not feel right,
> > > > > not
> > > > > to
> > > > > mentioned that this is not documented in the wiki
> > > > > installation
> > > > > page.
> > > > > 
> > > > > I think one of the guidelines we kept so far for setting a
> > > > > development
> > > > > environment and making it as easy as possible for new
> > > > > developers
> > > > > is
> > > > > that
> > > > > no manual step is needed on top of using the setup profile
> > > > > and
> > > > > this
> > > > > definitely breaks this assumption (at least with the way it
> > > > > is
> > > > > handled
> > > > > today).
> > > > 
> > > > I strongly reject to have default suitable for DEVELOPMENT
> > > > mode.
> > > > This was indeed the situation in the past, and may (and have)
> > > > cause
> > > > DEVELOPMENT setting to leak into PRODUCTION.
> > > > In development mode, the developer should explicitly state that
> > > > he
> > > > want to use DEVELOPMENT settings either by configuration or by
> > > > environment, this way no DEVELOPMENT settings will effect
> > > > intended
> > > > PRODUCTION settings.
> > > > 
> > > 
> > > Which can easily be handled when thinking of the difference
> > > between
> > > (git clone + mvn -Psetup,dep) VS (yum install).
> > > 
> > > The first one can simply work. The latter in handled by the RPM.
> > > No need to impose additional burdens on developers which are
> > > already handled for production setups. Think of user management,
> > > PKI infra, etc. All handled in production, and not needed for
> > > the basic (git clone + mvn -Psetup,dep).
> > 
> > Yes, we can do this many ways.
> > I did not read the entire new sequence, I will be happy if you
> > refer
> > me to it.
> > However, this is what I think is expected...
> > 
> > $ make PREFIX=$HOME/ovirt-engine-root
> > $ make PREFIX=$HOME/ovirt-engine-root DEVELOPMENT=1 install
> > 
> > The DEVELOPMENT=1 will generate the correct conf.d configuration
> > file
> > to override PRODUCTION settings with DEVELOPMENT settings.
> > 
> > Optionally, we may require:
> > . $HOME/ovirt-engine-root/vars
> > 
> > To add stuff into environment, before we can use the programs.
> > 
> > Then you have all you need at PREFIX, including a start/stop
> > script.
> > 
> > Alon
> > 
> 
> All we are saying is DEVELOPMENT=1 is the default, since the code
> is built differently for production, and installed accordingly.
> Additionally you may have more than one devel setup, for example for
> different versions. So unless you override something (such as
> keystore
> pass, jboss location) mvn -Pdep should simply work, and make XXX will
> ensure whatever you need to override is done properly.
> 
> 

No, you miss the point.
I want to be able to have a full blown product installed for development as well.
The only difference is the PREFIX and may be some other stuff I don't think of that are specific of development.
I put the DEVELOPMENT=1 to focus the discussion.

I should have written the following steps to be more clear:
$ OEHOME=$HOME/ovirt-engine-root
$ make PREFIX=$OEHOME
$ make PREFIX=$OEHOME DEVELOPMENT=1 install
$ cd ${OEHOME}
$ . ./ovirt-engine.vars
$ engine-setup
<snip>
$ sbin/engie-service.py start

We probably need more vars on the make install, such as JBOSS_HOME, but the idea is that you have fully functional product in development mode, including PKI and support scripts.

Regards,
Alon


From dfediuck at redhat.com  Tue Jan  1 08:30:29 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 1 Jan 2013 03:30:29 -0500 (EST)
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <1618467007.6944403.1357028137584.JavaMail.root@redhat.com>
Message-ID: <1557460382.59707880.1357029029572.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
> Sent: Tuesday, January 1, 2013 10:15:37 AM
> Subject: Re: [Engine-devel] Engine local configuration
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org,
> > "Livnat Peer" <lpeer at redhat.com>
> > Sent: Tuesday, January 1, 2013 10:08:32 AM
> > Subject: Re: [Engine-devel] Engine local configuration
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > > engine-devel at ovirt.org,
> > > "Livnat Peer" <lpeer at redhat.com>
> > > Sent: Tuesday, January 1, 2013 9:56:05 AM
> > > Subject: Re: [Engine-devel] Engine local configuration
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > > > engine-devel at ovirt.org,
> > > > "Livnat Peer" <lpeer at redhat.com>
> > > > Sent: Tuesday, January 1, 2013 9:43:50 AM
> > > > Subject: Re: [Engine-devel] Engine local configuration
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > To: "Livnat Peer" <lpeer at redhat.com>
> > > > > Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > > > > engine-devel at ovirt.org
> > > > > Sent: Tuesday, January 1, 2013 9:30:20 AM
> > > > > Subject: Re: [Engine-devel] Engine local configuration
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Livnat Peer" <lpeer at redhat.com>
> > > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > > > > > engine-devel at ovirt.org
> > > > > > Sent: Tuesday, January 1, 2013 9:05:03 AM
> > > > > > Subject: Re: [Engine-devel] Engine local configuration
> > > > > > 
> > > > > > On 12/31/2012 05:05 PM, Doron Fediuck wrote:
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > >> From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > > >> To: "Roy Golan" <rgolan at redhat.com>
> > > > > > >> Cc: engine-devel at ovirt.org
> > > > > > >> Sent: Friday, December 14, 2012 1:25:57 PM
> > > > > > >> Subject: Re: [Engine-devel] Error on starting webadmin
> > > > > > >>
> > > > > > >> On 12/13/2012 03:55 PM, Roy Golan wrote:
> > > > > > >>> On 12/13/2012 04:49 PM, Vojtech Szocs wrote:
> > > > > > >>>>> this is making the contribution process more complex.
> > > > > > >>>>> lets
> > > > > > >>>>> think
> > > > > > >>>>> of a
> > > > > > >>>>> lighter way to get a developing setup.
> > > > > > >>>> I agree, I just wanted to have the local Engine
> > > > > > >>>> configuration
> > > > > > >>>> steps documented for reference.. If there's a better
> > > > > > >>>> way
> > > > > > >>>> to
> > > > > > >>>> do
> > > > > > >>>> it, I'm for it.
> > > > > > >>>>
> > > > > > >>>> Vojtech
> > > > > > >>>
> > > > > > >>> having LocalConfig look for "engine.conf.defaults"
> > > > > > >>> system
> > > > > > >>> property
> > > > > > >>> before fallback to System.getenv("ENGINE_DEFAULTS");
> > > > > > >>>   +  concatenating
> > > > > > >>>   -Dengine.conf.defaults=$HOME/.engine.conf.defaults
> > > > > > >>> to  JAVA_OPTS  on standalone.conf
> > > > > > >>
> > > > > > >> How is the system property simpler than the environment
> > > > > > >> variable?
> > > > > > >>
> > > > > > >> I agree that this makes the development process a bit
> > > > > > >> more
> > > > > > >> complex
> > > > > > >> at
> > > > > > >> the moment, but I think that the way to make it simpler
> > > > > > >> is
> > > > > > >> not
> > > > > > >> to
> > > > > > >> continue adding things to standalone.conf. I think that
> > > > > > >> we
> > > > > > >> should
> > > > > > >> move
> > > > > > >> towards a development environment that is closer to the
> > > > > > >> production
> > > > > > >> environment, not the other way around. Ideally the
> > > > > > >> developer
> > > > > > >> should
> > > > > > >> be
> > > > > > >> able to do something like "make install" to have the
> > > > > > >> engine
> > > > > > >> deployed
> > > > > > >> to
> > > > > > >> a directory structure similar to what he have in the
> > > > > > >> production
> > > > > > >> environment. Then you should be able to go to the bin
> > > > > > >> directory
> > > > > > >> inside
> > > > > > >> that structure and start the engine (and the other
> > > > > > >> tools)
> > > > > > >> using
> > > > > > >> the
> > > > > > >> same
> > > > > > >> script that we use in production environments. If we
> > > > > > >> achieve
> > > > > > >> this
> > > > > > >> goal
> > > > > > >> then we have a simple development environment setup and
> > > > > > >> also
> > > > > > >> we
> > > > > > >> have
> > > > > > >> all
> > > > > > >> developers testing almost the same thing that will go
> > > > > > >> into
> > > > > > >> the
> > > > > > >> production environments. At the moment we don't have
> > > > > > >> that,
> > > > > > >> most
> > > > > > >> times
> > > > > > >> you are testing something quite different (in terms of
> > > > > > >> directory
> > > > > > >> structure, configuration, etc) to what will be installed
> > > > > > >> in
> > > > > > >> production
> > > > > > >> environments. I am working in that direction.
> > > > > > >>
> > > > > > > 
> > > > > > > Hi Guys,
> > > > > > > Sorry to resume this discussion, but I find the current
> > > > > > > situation
> > > > > > > unfriendly to most developers. I understand there's a
> > > > > > > need
> > > > > > > for
> > > > > > > specific configurations, but it seems to me that this has
> > > > > > > taken
> > > > > > > one step too far for most developers.
> > > > > > > 
> > > > > > > Further more, I expect to see such fundamental concepts
> > > > > > > being
> > > > > > > initially discussed here, and not settle with a technical
> > > > > > > ack,
> > > > > > > only to be a part of a thread called: "Error on starting
> > > > > > > webadmin".
> > > > > > > In this context I expect the verified flag to mean "This
> > > > > > > was
> > > > > > > discussed and verified with contributers in the relevant
> > > > > > > list".
> > > > > > > 
> > > > > > 
> > > > > > Hi Doron,
> > > > > > Thanks for bringing this on the list, I agree with
> > > > > > everything
> > > > > > you
> > > > > > wrote
> > > > > > and could not put it any better myself.
> > > > > > 
> > > > > > I configured an environment from scratch yesterday and the
> > > > > > additional
> > > > > > step to have this config file in /etc does not feel right,
> > > > > > not
> > > > > > to
> > > > > > mentioned that this is not documented in the wiki
> > > > > > installation
> > > > > > page.
> > > > > > 
> > > > > > I think one of the guidelines we kept so far for setting a
> > > > > > development
> > > > > > environment and making it as easy as possible for new
> > > > > > developers
> > > > > > is
> > > > > > that
> > > > > > no manual step is needed on top of using the setup profile
> > > > > > and
> > > > > > this
> > > > > > definitely breaks this assumption (at least with the way it
> > > > > > is
> > > > > > handled
> > > > > > today).
> > > > > 
> > > > > I strongly reject to have default suitable for DEVELOPMENT
> > > > > mode.
> > > > > This was indeed the situation in the past, and may (and have)
> > > > > cause
> > > > > DEVELOPMENT setting to leak into PRODUCTION.
> > > > > In development mode, the developer should explicitly state
> > > > > that
> > > > > he
> > > > > want to use DEVELOPMENT settings either by configuration or
> > > > > by
> > > > > environment, this way no DEVELOPMENT settings will effect
> > > > > intended
> > > > > PRODUCTION settings.
> > > > > 
> > > > 
> > > > Which can easily be handled when thinking of the difference
> > > > between
> > > > (git clone + mvn -Psetup,dep) VS (yum install).
> > > > 
> > > > The first one can simply work. The latter in handled by the
> > > > RPM.
> > > > No need to impose additional burdens on developers which are
> > > > already handled for production setups. Think of user
> > > > management,
> > > > PKI infra, etc. All handled in production, and not needed for
> > > > the basic (git clone + mvn -Psetup,dep).
> > > 
> > > Yes, we can do this many ways.
> > > I did not read the entire new sequence, I will be happy if you
> > > refer
> > > me to it.
> > > However, this is what I think is expected...
> > > 
> > > $ make PREFIX=$HOME/ovirt-engine-root
> > > $ make PREFIX=$HOME/ovirt-engine-root DEVELOPMENT=1 install
> > > 
> > > The DEVELOPMENT=1 will generate the correct conf.d configuration
> > > file
> > > to override PRODUCTION settings with DEVELOPMENT settings.
> > > 
> > > Optionally, we may require:
> > > . $HOME/ovirt-engine-root/vars
> > > 
> > > To add stuff into environment, before we can use the programs.
> > > 
> > > Then you have all you need at PREFIX, including a start/stop
> > > script.
> > > 
> > > Alon
> > > 
> > 
> > All we are saying is DEVELOPMENT=1 is the default, since the code
> > is built differently for production, and installed accordingly.
> > Additionally you may have more than one devel setup, for example
> > for
> > different versions. So unless you override something (such as
> > keystore
> > pass, jboss location) mvn -Pdep should simply work, and make XXX
> > will
> > ensure whatever you need to override is done properly.
> > 
> > 
> 
> No, you miss the point.
> I want to be able to have a full blown product installed for
> development as well.
> The only difference is the PREFIX and may be some other stuff I don't
> think of that are specific of development.
> I put the DEVELOPMENT=1 to focus the discussion.
> 
> I should have written the following steps to be more clear:
> $ OEHOME=$HOME/ovirt-engine-root
> $ make PREFIX=$OEHOME
> $ make PREFIX=$OEHOME DEVELOPMENT=1 install
> $ cd ${OEHOME}
> $ . ./ovirt-engine.vars
> $ engine-setup
> <snip>
> $ sbin/engie-service.py start
> 
> We probably need more vars on the make install, such as JBOSS_HOME,
> but the idea is that you have fully functional product in
> development mode, including PKI and support scripts.
> 
> Regards,
> Alon

Alon,
most universities today will not give you admin privileges.
We must be able to download the code and run it without additional
requirements. It is possible to run jboss with local configuration
(per user). So we should minimize the restrictions and not impose
new once. Running the installation script is nice to have, but
should be completely optional. Especially if you'd like to see it
being deployed in various distro's. So at least developers should
be able to git clone, compile and run. Everything else is packaging.


From lpeer at redhat.com  Tue Jan  1 08:00:11 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 01 Jan 2013 10:00:11 +0200
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <75009959.6944220.1357025420112.JavaMail.root@redhat.com>
References: <75009959.6944220.1357025420112.JavaMail.root@redhat.com>
Message-ID: <50E2978B.7060503@redhat.com>

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

The setup profile is relevant only for development and not used in
production. So having this file copied/handled as part of the setup
profile has no risk in it.

>>
>>> My use case is exactly what Juan describes, but I think the
>>> resolution
>>> should be different. ie- contributers should be able to git clone
>>> and once they setup jboss & postgres they should be able to have
>>> something running.
>>>
>>> We cannot assume /etc is a location contributers can access. Think
>>> of university students who would like to see how ovirt works using
>>> university's machines. In the past they may have had issues with
>>> JBoss, but that's already handled by profiles. So there's really
>>> no need for oVirt to ask them more than that. I know UI plugins
>>> are using this infra, but remember that the plugins are completely
>>> optional and should not block basic operation.
>>>
>>> Some more concerns this issue raises are related to release
>>> versions;
>>> What happens when we need to support more than one jboss and/or
>>> release version?
>>>
>>> So here are 2 options we should consider in order to allow local
>>> config without additional requirements:
>>>
>>> 1. Use defaults.
>>> System should boot and start in whichever way we decide without
>>> anything else needed. Local configuration can override these
>>> defaults if it exists, but it should simply work.
>>
>> The engine.conf.defaults holds default values for the keys, so I
>> guess
>> that by defaults you mean a way to have this file as part of our
>> deploying | setup process and only for overriding values we should
>> use
>> /etc/sysconfig/ovirt-engine, which seems to be the original intention
>> of
>> the writer (according to the file documentation), I wonder where it
>> went
>> wrong...
>>
>>>
>>> 2. Use local JBoss profile.
>>> Have everything we need in my-standalone.conf and start running
>>> jboss
>>> with a local profile. This conf file may be generated or copied
>>> once
>>> when running mvn -Psetup
>>>
>>> We can also inject the relevant environment variables to the global
>>> standalone.conf as we do for debugging, but this cannot be used in
>>> the students use case, unless we have host-level config.
>>>
>>> I know many are still in vacation due to the holidays, so we should
>>> wait for a few more days before making a final decision. Still feel
>>> free to ack / nack / suggest your own.
>>>
>>> Doron
>>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From alonbl at redhat.com  Tue Jan  1 09:51:35 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 1 Jan 2013 04:51:35 -0500 (EST)
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <1557460382.59707880.1357029029572.JavaMail.root@redhat.com>
Message-ID: <1068403699.6945070.1357033895864.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
> Sent: Tuesday, January 1, 2013 10:30:29 AM
> Subject: Re: [Engine-devel] Engine local configuration
> > > All we are saying is DEVELOPMENT=1 is the default, since the code
> > > is built differently for production, and installed accordingly.
> > > Additionally you may have more than one devel setup, for example
> > > for
> > > different versions. So unless you override something (such as
> > > keystore
> > > pass, jboss location) mvn -Pdep should simply work, and make XXX
> > > will
> > > ensure whatever you need to override is done properly.
> > > 
> > > 
> > 
> > No, you miss the point.
> > I want to be able to have a full blown product installed for
> > development as well.
> > The only difference is the PREFIX and may be some other stuff I
> > don't
> > think of that are specific of development.
> > I put the DEVELOPMENT=1 to focus the discussion.
> > 
> > I should have written the following steps to be more clear:
> > $ OEHOME=$HOME/ovirt-engine-root
> > $ make PREFIX=$OEHOME
> > $ make PREFIX=$OEHOME DEVELOPMENT=1 install
> > $ cd ${OEHOME}
> > $ . ./ovirt-engine.vars
> > $ engine-setup
> > <snip>
> > $ sbin/engie-service.py start
> > 
> > We probably need more vars on the make install, such as JBOSS_HOME,
> > but the idea is that you have fully functional product in
> > development mode, including PKI and support scripts.
> > 
> > Regards,
> > Alon
> 
> Alon,
> most universities today will not give you admin privileges.
> We must be able to download the code and run it without additional
> requirements. It is possible to run jboss with local configuration
> (per user). So we should minimize the restrictions and not impose
> new once. Running the installation script is nice to have, but
> should be completely optional. Especially if you'd like to see it
> being deployed in various distro's. So at least developers should
> be able to git clone, compile and run. Everything else is packaging.
> 

You don't need any admin to install at PREFIX=$HOME/ovirt-engine-root

We should make sure that we can run all components within PREFIX without root.

As far as I can tell, we do not actually need root access for 99% of the implementation, one of the trivial differences is to replace systemctl start/stop with direct script execution in non-root mode.

Alon


From jhernand at redhat.com  Tue Jan  1 10:17:33 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 01 Jan 2013 11:17:33 +0100
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <1068403699.6945070.1357033895864.JavaMail.root@redhat.com>
References: <1068403699.6945070.1357033895864.JavaMail.root@redhat.com>
Message-ID: <50E2B7BD.1010107@redhat.com>

On 01/01/2013 10:51 AM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Doron Fediuck" <dfediuck at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
>> Sent: Tuesday, January 1, 2013 10:30:29 AM
>> Subject: Re: [Engine-devel] Engine local configuration
>>>> All we are saying is DEVELOPMENT=1 is the default, since the code
>>>> is built differently for production, and installed accordingly.
>>>> Additionally you may have more than one devel setup, for example
>>>> for
>>>> different versions. So unless you override something (such as
>>>> keystore
>>>> pass, jboss location) mvn -Pdep should simply work, and make XXX
>>>> will
>>>> ensure whatever you need to override is done properly.
>>>>
>>>>
>>>
>>> No, you miss the point.
>>> I want to be able to have a full blown product installed for
>>> development as well.
>>> The only difference is the PREFIX and may be some other stuff I
>>> don't
>>> think of that are specific of development.
>>> I put the DEVELOPMENT=1 to focus the discussion.
>>>
>>> I should have written the following steps to be more clear:
>>> $ OEHOME=$HOME/ovirt-engine-root
>>> $ make PREFIX=$OEHOME
>>> $ make PREFIX=$OEHOME DEVELOPMENT=1 install
>>> $ cd ${OEHOME}
>>> $ . ./ovirt-engine.vars
>>> $ engine-setup
>>> <snip>
>>> $ sbin/engie-service.py start
>>>
>>> We probably need more vars on the make install, such as JBOSS_HOME,
>>> but the idea is that you have fully functional product in
>>> development mode, including PKI and support scripts.
>>>
>>> Regards,
>>> Alon
>>
>> Alon,
>> most universities today will not give you admin privileges.
>> We must be able to download the code and run it without additional
>> requirements. It is possible to run jboss with local configuration
>> (per user). So we should minimize the restrictions and not impose
>> new once. Running the installation script is nice to have, but
>> should be completely optional. Especially if you'd like to see it
>> being deployed in various distro's. So at least developers should
>> be able to git clone, compile and run. Everything else is packaging.
>>
> 
> You don't need any admin to install at PREFIX=$HOME/ovirt-engine-root
> 
> We should make sure that we can run all components within PREFIX without root.
> 
> As far as I can tell, we do not actually need root access for 99% of the implementation, one of the trivial differences is to replace systemctl start/stop with direct script execution in non-root mode.
> 
> Alon

As I mentioned on my first response to this thread I have been working
on trying to make the build system able to install the engine to a
directory chosen by the developer, and without root permissions. This is
the patch that I prepared for that, please take a look at the commit
message:

http://gerrit.ovirt.org/10539

The idea is that the developer can chose a directory and then just run
the following:

  ./make.py --build --install --devel --target /that/directory

Even the complexity of this command line can be hidden in a make target,
or made the default, so the developer will only need to run something
like this:

  make install

This will prepare an environment similar to the production environment,
with the same directory structure (except the /that/directory prefix)
where the engine can run, so to start it the developer only needs to go
to that directory and execute the same script that we use in production
environments:

  cd /that/directory/usr/bin
  ./engine-service start

This will also automatically configure the engine for remote debugging
(adding ENGINE_DEBUG_ADDRESS=0.0.0.0:8787 to the configuration) so that
the developer can connect to the engine with her/his favorite IDE and
start debugging immediately.

The make.py script also includes options to create Eclipse project files
and to configure the Eclipse workspace, which I think is very useful,
specially for new developers:

  ./make.py --eclipse-projects

That creates the .project and .classpath files for Eclipse and adds the
required variables to the workspace, so after that all what the
developer has to do to start working is open Eclipse and import the
projects.

The patch is not yet ready to merge, as there are a few missing things,
like changing the ownership of files when running as root, but I would
appreciate if you can test it.

-- 
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 dfediuck at redhat.com  Tue Jan  1 10:41:27 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 1 Jan 2013 05:41:27 -0500 (EST)
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <50E2B7BD.1010107@redhat.com>
Message-ID: <1668189142.59717508.1357036887902.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, January 1, 2013 12:17:33 PM
> Subject: Re: [Engine-devel] Engine local configuration
> 
> On 01/01/2013 10:51 AM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Doron Fediuck" <dfediuck at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
> >> Sent: Tuesday, January 1, 2013 10:30:29 AM
> >> Subject: Re: [Engine-devel] Engine local configuration
> >>>> All we are saying is DEVELOPMENT=1 is the default, since the
> >>>> code
> >>>> is built differently for production, and installed accordingly.
> >>>> Additionally you may have more than one devel setup, for example
> >>>> for
> >>>> different versions. So unless you override something (such as
> >>>> keystore
> >>>> pass, jboss location) mvn -Pdep should simply work, and make XXX
> >>>> will
> >>>> ensure whatever you need to override is done properly.
> >>>>
> >>>>
> >>>
> >>> No, you miss the point.
> >>> I want to be able to have a full blown product installed for
> >>> development as well.
> >>> The only difference is the PREFIX and may be some other stuff I
> >>> don't
> >>> think of that are specific of development.
> >>> I put the DEVELOPMENT=1 to focus the discussion.
> >>>
> >>> I should have written the following steps to be more clear:
> >>> $ OEHOME=$HOME/ovirt-engine-root
> >>> $ make PREFIX=$OEHOME
> >>> $ make PREFIX=$OEHOME DEVELOPMENT=1 install
> >>> $ cd ${OEHOME}
> >>> $ . ./ovirt-engine.vars
> >>> $ engine-setup
> >>> <snip>
> >>> $ sbin/engie-service.py start
> >>>
> >>> We probably need more vars on the make install, such as
> >>> JBOSS_HOME,
> >>> but the idea is that you have fully functional product in
> >>> development mode, including PKI and support scripts.
> >>>
> >>> Regards,
> >>> Alon
> >>
> >> Alon,
> >> most universities today will not give you admin privileges.
> >> We must be able to download the code and run it without additional
> >> requirements. It is possible to run jboss with local configuration
> >> (per user). So we should minimize the restrictions and not impose
> >> new once. Running the installation script is nice to have, but
> >> should be completely optional. Especially if you'd like to see it
> >> being deployed in various distro's. So at least developers should
> >> be able to git clone, compile and run. Everything else is
> >> packaging.
> >>
> > 
> > You don't need any admin to install at
> > PREFIX=$HOME/ovirt-engine-root
> > 
> > We should make sure that we can run all components within PREFIX
> > without root.
> > 
> > As far as I can tell, we do not actually need root access for 99%
> > of the implementation, one of the trivial differences is to
> > replace systemctl start/stop with direct script execution in
> > non-root mode.
> > 
> > Alon
> 
> As I mentioned on my first response to this thread I have been
> working
> on trying to make the build system able to install the engine to a
> directory chosen by the developer, and without root permissions. This
> is
> the patch that I prepared for that, please take a look at the commit
> message:
> 
> http://gerrit.ovirt.org/10539
> 
> The idea is that the developer can chose a directory and then just
> run
> the following:
> 
>   ./make.py --build --install --devel --target /that/directory
> 
> Even the complexity of this command line can be hidden in a make
> target,
> or made the default, so the developer will only need to run something
> like this:
> 
>   make install
> 
> This will prepare an environment similar to the production
> environment,
> with the same directory structure (except the /that/directory prefix)
> where the engine can run, so to start it the developer only needs to
> go
> to that directory and execute the same script that we use in
> production
> environments:
> 
>   cd /that/directory/usr/bin
>   ./engine-service start
> 
> This will also automatically configure the engine for remote
> debugging
> (adding ENGINE_DEBUG_ADDRESS=0.0.0.0:8787 to the configuration) so
> that
> the developer can connect to the engine with her/his favorite IDE and
> start debugging immediately.
> 
> The make.py script also includes options to create Eclipse project
> files
> and to configure the Eclipse workspace, which I think is very useful,
> specially for new developers:
> 
>   ./make.py --eclipse-projects
> 
> That creates the .project and .classpath files for Eclipse and adds
> the
> required variables to the workspace, so after that all what the
> developer has to do to start working is open Eclipse and import the
> projects.
> 
> The patch is not yet ready to merge, as there are a few missing
> things,
> like changing the ownership of files when running as root, but I
> would
> appreciate if you can test it.
> 

Alon & Juan,
as a one-time setup which can auto-generate /local/ configuration
based on target=`pwd`, this is something which makes sense, assuming
engine-config and other utils will work. Otherwise this is meaningless.
Additionally I'd expect engine developers to be able to perform
mvn clean install -Pdep after the one-time setup and be able to
work as they used to.

Additionally and just as important;

- Such a discussion should be the base, and not postmortem of this
  feature. It should lead to a design followed by implementation
  and not the other way around.

- The patch that created the current state shouldn't have been merged
  in the first place. It should have been taken into a feature branch,
  where other dependent patches will reside such as the one Juan just
  mentioned (10539). So such an important feature can be properly evaluated
  and then merged as a complete feature.

Juan, is there a design we can read somewhere? The patch commit message
is a good start, but as Alon suggested it may be lacking systemd handling,
etc. So it would be nice to have all this written somewhere, once you
return from your vacation. Additionally, as already mentioned, current
hybrid state is not very inviting both for new and exiting contributers.
Will it be possible to wither revert the existing or add an initial
'make xxx' to auto-generate whatever needed for existing code to work?



From ovedo at redhat.com  Tue Jan  1 10:50:30 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Tue, 1 Jan 2013 05:50:30 -0500 (EST)
Subject: [Engine-devel] Engine local configuration
In-Reply-To: <1668189142.59717508.1357036887902.JavaMail.root@redhat.com>
Message-ID: <1636450387.69883461.1357037430764.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Juan Hernandez" <jhernand at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, January 1, 2013 12:41:27 PM
> Subject: Re: [Engine-devel] Engine local configuration
> 
> 
> ----- Original Message -----
> > From: "Juan Hernandez" <jhernand at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, January 1, 2013 12:17:33 PM
> > Subject: Re: [Engine-devel] Engine local configuration
> > 
> > On 01/01/2013 10:51 AM, Alon Bar-Lev wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > >> From: "Doron Fediuck" <dfediuck at redhat.com>
> > >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >> Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > >> engine-devel at ovirt.org
> > >> Sent: Tuesday, January 1, 2013 10:30:29 AM
> > >> Subject: Re: [Engine-devel] Engine local configuration
> > >>>> All we are saying is DEVELOPMENT=1 is the default, since the
> > >>>> code
> > >>>> is built differently for production, and installed
> > >>>> accordingly.
> > >>>> Additionally you may have more than one devel setup, for
> > >>>> example
> > >>>> for
> > >>>> different versions. So unless you override something (such as
> > >>>> keystore
> > >>>> pass, jboss location) mvn -Pdep should simply work, and make
> > >>>> XXX
> > >>>> will
> > >>>> ensure whatever you need to override is done properly.
> > >>>>
> > >>>>
> > >>>
> > >>> No, you miss the point.
> > >>> I want to be able to have a full blown product installed for
> > >>> development as well.
> > >>> The only difference is the PREFIX and may be some other stuff I
> > >>> don't
> > >>> think of that are specific of development.
> > >>> I put the DEVELOPMENT=1 to focus the discussion.
> > >>>
> > >>> I should have written the following steps to be more clear:
> > >>> $ OEHOME=$HOME/ovirt-engine-root
> > >>> $ make PREFIX=$OEHOME
> > >>> $ make PREFIX=$OEHOME DEVELOPMENT=1 install
> > >>> $ cd ${OEHOME}
> > >>> $ . ./ovirt-engine.vars
> > >>> $ engine-setup
> > >>> <snip>
> > >>> $ sbin/engie-service.py start
> > >>>
> > >>> We probably need more vars on the make install, such as
> > >>> JBOSS_HOME,
> > >>> but the idea is that you have fully functional product in
> > >>> development mode, including PKI and support scripts.
> > >>>
> > >>> Regards,
> > >>> Alon
> > >>
> > >> Alon,
> > >> most universities today will not give you admin privileges.
> > >> We must be able to download the code and run it without
> > >> additional
> > >> requirements. It is possible to run jboss with local
> > >> configuration
> > >> (per user). So we should minimize the restrictions and not
> > >> impose
> > >> new once. Running the installation script is nice to have, but
> > >> should be completely optional. Especially if you'd like to see
> > >> it
> > >> being deployed in various distro's. So at least developers
> > >> should
> > >> be able to git clone, compile and run. Everything else is
> > >> packaging.
> > >>
> > > 
> > > You don't need any admin to install at
> > > PREFIX=$HOME/ovirt-engine-root
> > > 
> > > We should make sure that we can run all components within PREFIX
> > > without root.
> > > 
> > > As far as I can tell, we do not actually need root access for 99%
> > > of the implementation, one of the trivial differences is to
> > > replace systemctl start/stop with direct script execution in
> > > non-root mode.
> > > 
> > > Alon
> > 
> > As I mentioned on my first response to this thread I have been
> > working
> > on trying to make the build system able to install the engine to a
> > directory chosen by the developer, and without root permissions.
> > This
> > is
> > the patch that I prepared for that, please take a look at the
> > commit
> > message:
> > 
> > http://gerrit.ovirt.org/10539
> > 
> > The idea is that the developer can chose a directory and then just
> > run
> > the following:
> > 
> >   ./make.py --build --install --devel --target /that/directory
> > 
> > Even the complexity of this command line can be hidden in a make
> > target,
> > or made the default, so the developer will only need to run
> > something
> > like this:
> > 
> >   make install
> > 
> > This will prepare an environment similar to the production
> > environment,
> > with the same directory structure (except the /that/directory
> > prefix)
> > where the engine can run, so to start it the developer only needs
> > to
> > go
> > to that directory and execute the same script that we use in
> > production
> > environments:
> > 
> >   cd /that/directory/usr/bin
> >   ./engine-service start
> > 
> > This will also automatically configure the engine for remote
> > debugging
> > (adding ENGINE_DEBUG_ADDRESS=0.0.0.0:8787 to the configuration) so
> > that
> > the developer can connect to the engine with her/his favorite IDE
> > and
> > start debugging immediately.
> > 
> > The make.py script also includes options to create Eclipse project
> > files
> > and to configure the Eclipse workspace, which I think is very
> > useful,
> > specially for new developers:
> > 
> >   ./make.py --eclipse-projects
> > 
> > That creates the .project and .classpath files for Eclipse and adds
> > the
> > required variables to the workspace, so after that all what the
> > developer has to do to start working is open Eclipse and import the
> > projects.
> > 
> > The patch is not yet ready to merge, as there are a few missing
> > things,
> > like changing the ownership of files when running as root, but I
> > would
> > appreciate if you can test it.
> > 
> 
> Alon & Juan,
> as a one-time setup which can auto-generate /local/ configuration
> based on target=`pwd`, this is something which makes sense, assuming
> engine-config and other utils will work. Otherwise this is
> meaningless.
This of course should be the goal. One can argue whether we should do it in one phase, or start with a basic patch, adding support of the different utilities in subsequent patches.
(I guess that doing that in subsequent patches will allow solving this issue today, improving it gradually to support all the different utilities).


> Additionally I'd expect engine developers to be able to perform
> mvn clean install -Pdep after the one-time setup and be able to
> work as they used to.
> 

That makes sense. But in addition we should have the ability to run setup again / upgrade, to allow testing changes in utilities, installer, etc, as these are components that aren't deployed in Jboss.

> Additionally and just as important;
> 
> - Such a discussion should be the base, and not postmortem of this
>   feature. It should lead to a design followed by implementation
>   and not the other way around.
> 
> - The patch that created the current state shouldn't have been merged
>   in the first place. It should have been taken into a feature
>   branch,
>   where other dependent patches will reside such as the one Juan just
>   mentioned (10539). So such an important feature can be properly
>   evaluated
>   and then merged as a complete feature.
> 
> Juan, is there a design we can read somewhere? The patch commit
> message
> is a good start, but as Alon suggested it may be lacking systemd
> handling,
> etc. So it would be nice to have all this written somewhere, once you
> return from your vacation. Additionally, as already mentioned,
> current
> hybrid state is not very inviting both for new and exiting
> contributers.
> Will it be possible to wither revert the existing or add an initial
> 'make xxx' to auto-generate whatever needed for existing code to
> work?
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dfediuck at redhat.com  Tue Jan  1 14:07:53 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 1 Jan 2013 09:07:53 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <1712458861.59731197.1357049002592.JavaMail.root@redhat.com>
Message-ID: <1538827661.59732405.1357049273884.JavaMail.root@redhat.com>

Hi,
Recently I saw many patches with multiple code re-formatting.
When looking into it, we saw that many people didn't use the project
policy, and now we have many files with bad formatting.

So I just posted a big ugly fix for this[1], and hopefully if accepted
people should start using the right conventions and reduce the amount
of non-relevant changes we see in the patches.

I'm aware of the fact that this may create some issues when porting
patches, but better sooner than later.
Doron.

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


From alonbl at redhat.com  Tue Jan  1 14:17:18 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 1 Jan 2013 09:17:18 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <1538827661.59732405.1357049273884.JavaMail.root@redhat.com>
Message-ID: <209822390.6949182.1357049838605.JavaMail.root@redhat.com>



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

Hi,

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

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

Regards,
Alon


From dfediuck at redhat.com  Tue Jan  1 14:28:15 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 1 Jan 2013 09:28:15 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <209822390.6949182.1357049838605.JavaMail.root@redhat.com>
Message-ID: <733719503.59733237.1357050495266.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 1, 2013 4:17:18 PM
> Subject: Re: [Engine-devel] Java code formatting
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, January 1, 2013 4:07:53 PM
> > Subject: [Engine-devel] Java code formatting
> > 
> > Hi,
> > Recently I saw many patches with multiple code re-formatting.
> > When looking into it, we saw that many people didn't use the
> > project
> > policy, and now we have many files with bad formatting.
> > 
> > So I just posted a big ugly fix for this[1], and hopefully if
> > accepted
> > people should start using the right conventions and reduce the
> > amount
> > of non-relevant changes we see in the patches.
> > 
> > I'm aware of the fact that this may create some issues when porting
> > patches, but better sooner than later.
> > Doron.
> > 
> > [1] http://gerrit.ovirt.org/#/c/10541/1
> 
> Hi,
> 
> These automatic conversions are not better than current state, also I
> don't think that this is that important. If you want machine written
> code, then also provide commit hook to reformat anything, and
> probably machines to read it.
> 
> I, personally, think that this change over the sources I manage did
> not do any good.
> 
> Regards,
> Alon

Alon,
there's a formatting convention for the project set long ago.
If you feel it needs to be fixed, go ahead and suggest a fix for
the xml.
Otherwise we end up in the current chaos, where every 2nd or 3rd
patch carries unneeded changes. 


From alonbl at redhat.com  Tue Jan  1 14:33:20 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 1 Jan 2013 09:33:20 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <733719503.59733237.1357050495266.JavaMail.root@redhat.com>
Message-ID: <1488911495.6949567.1357050800240.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 1, 2013 4:28:15 PM
> Subject: Re: [Engine-devel] Java code formatting
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, January 1, 2013 4:17:18 PM
> > Subject: Re: [Engine-devel] Java code formatting
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, January 1, 2013 4:07:53 PM
> > > Subject: [Engine-devel] Java code formatting
> > > 
> > > Hi,
> > > Recently I saw many patches with multiple code re-formatting.
> > > When looking into it, we saw that many people didn't use the
> > > project
> > > policy, and now we have many files with bad formatting.
> > > 
> > > So I just posted a big ugly fix for this[1], and hopefully if
> > > accepted
> > > people should start using the right conventions and reduce the
> > > amount
> > > of non-relevant changes we see in the patches.
> > > 
> > > I'm aware of the fact that this may create some issues when
> > > porting
> > > patches, but better sooner than later.
> > > Doron.
> > > 
> > > [1] http://gerrit.ovirt.org/#/c/10541/1
> > 
> > Hi,
> > 
> > These automatic conversions are not better than current state, also
> > I
> > don't think that this is that important. If you want machine
> > written
> > code, then also provide commit hook to reformat anything, and
> > probably machines to read it.
> > 
> > I, personally, think that this change over the sources I manage did
> > not do any good.
> > 
> > Regards,
> > Alon
> 
> Alon,
> there's a formatting convention for the project set long ago.
> If you feel it needs to be fixed, go ahead and suggest a fix for
> the xml.
> Otherwise we end up in the current chaos, where every 2nd or 3rd
> patch carries unneeded changes.
> 

What do you mean unneeded changes? how do you prevent this in future?

Alon


From dfediuck at redhat.com  Tue Jan  1 14:48:22 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 1 Jan 2013 09:48:22 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <1488911495.6949567.1357050800240.JavaMail.root@redhat.com>
Message-ID: <1835469937.59734797.1357051702007.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 1, 2013 4:33:20 PM
> Subject: Re: [Engine-devel] Java code formatting
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, January 1, 2013 4:28:15 PM
> > Subject: Re: [Engine-devel] Java code formatting
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, January 1, 2013 4:17:18 PM
> > > Subject: Re: [Engine-devel] Java code formatting
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Tuesday, January 1, 2013 4:07:53 PM
> > > > Subject: [Engine-devel] Java code formatting
> > > > 
> > > > Hi,
> > > > Recently I saw many patches with multiple code re-formatting.
> > > > When looking into it, we saw that many people didn't use the
> > > > project
> > > > policy, and now we have many files with bad formatting.
> > > > 
> > > > So I just posted a big ugly fix for this[1], and hopefully if
> > > > accepted
> > > > people should start using the right conventions and reduce the
> > > > amount
> > > > of non-relevant changes we see in the patches.
> > > > 
> > > > I'm aware of the fact that this may create some issues when
> > > > porting
> > > > patches, but better sooner than later.
> > > > Doron.
> > > > 
> > > > [1] http://gerrit.ovirt.org/#/c/10541/1
> > > 
> > > Hi,
> > > 
> > > These automatic conversions are not better than current state,
> > > also
> > > I
> > > don't think that this is that important. If you want machine
> > > written
> > > code, then also provide commit hook to reformat anything, and
> > > probably machines to read it.
> > > 
> > > I, personally, think that this change over the sources I manage
> > > did
> > > not do any good.
> > > 
> > > Regards,
> > > Alon
> > 
> > Alon,
> > there's a formatting convention for the project set long ago.
> > If you feel it needs to be fixed, go ahead and suggest a fix for
> > the xml.
> > Otherwise we end up in the current chaos, where every 2nd or 3rd
> > patch carries unneeded changes.
> > 
> 
> What do you mean unneeded changes? how do you prevent this in future?
> 
> Alon

Unneeded changes is when you get one line of code fixed due to a bug,
and many others re-indented.
Best prevention is if people would make sure to use the same conventions.
We also have a checkstyle which monitors important issues such as trailing
white spaces, localization, etc.


From alonbl at redhat.com  Tue Jan  1 14:53:49 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 1 Jan 2013 09:53:49 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <1835469937.59734797.1357051702007.JavaMail.root@redhat.com>
Message-ID: <1931486449.6949849.1357052029180.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 1, 2013 4:48:22 PM
> Subject: Re: [Engine-devel] Java code formatting
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, January 1, 2013 4:33:20 PM
> > Subject: Re: [Engine-devel] Java code formatting
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, January 1, 2013 4:28:15 PM
> > > Subject: Re: [Engine-devel] Java code formatting
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Tuesday, January 1, 2013 4:17:18 PM
> > > > Subject: Re: [Engine-devel] Java code formatting
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Tuesday, January 1, 2013 4:07:53 PM
> > > > > Subject: [Engine-devel] Java code formatting
> > > > > 
> > > > > Hi,
> > > > > Recently I saw many patches with multiple code re-formatting.
> > > > > When looking into it, we saw that many people didn't use the
> > > > > project
> > > > > policy, and now we have many files with bad formatting.
> > > > > 
> > > > > So I just posted a big ugly fix for this[1], and hopefully if
> > > > > accepted
> > > > > people should start using the right conventions and reduce
> > > > > the
> > > > > amount
> > > > > of non-relevant changes we see in the patches.
> > > > > 
> > > > > I'm aware of the fact that this may create some issues when
> > > > > porting
> > > > > patches, but better sooner than later.
> > > > > Doron.
> > > > > 
> > > > > [1] http://gerrit.ovirt.org/#/c/10541/1
> > > > 
> > > > Hi,
> > > > 
> > > > These automatic conversions are not better than current state,
> > > > also
> > > > I
> > > > don't think that this is that important. If you want machine
> > > > written
> > > > code, then also provide commit hook to reformat anything, and
> > > > probably machines to read it.
> > > > 
> > > > I, personally, think that this change over the sources I manage
> > > > did
> > > > not do any good.
> > > > 
> > > > Regards,
> > > > Alon
> > > 
> > > Alon,
> > > there's a formatting convention for the project set long ago.
> > > If you feel it needs to be fixed, go ahead and suggest a fix for
> > > the xml.
> > > Otherwise we end up in the current chaos, where every 2nd or 3rd
> > > patch carries unneeded changes.
> > > 
> > 
> > What do you mean unneeded changes? how do you prevent this in
> > future?
> > 
> > Alon
> 
> Unneeded changes is when you get one line of code fixed due to a bug,
> and many others re-indented.
> Best prevention is if people would make sure to use the same
> conventions.
> We also have a checkstyle which monitors important issues such as
> trailing
> white spaces, localization, etc.
> 

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

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

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

Alon


From dfediuck at redhat.com  Tue Jan  1 15:00:20 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 1 Jan 2013 10:00:20 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <1931486449.6949849.1357052029180.JavaMail.root@redhat.com>
Message-ID: <283678361.59735242.1357052420198.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 1, 2013 4:53:49 PM
> Subject: Re: [Engine-devel] Java code formatting
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, January 1, 2013 4:48:22 PM
> > Subject: Re: [Engine-devel] Java code formatting
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, January 1, 2013 4:33:20 PM
> > > Subject: Re: [Engine-devel] Java code formatting
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Tuesday, January 1, 2013 4:28:15 PM
> > > > Subject: Re: [Engine-devel] Java code formatting
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Tuesday, January 1, 2013 4:17:18 PM
> > > > > Subject: Re: [Engine-devel] Java code formatting
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Tuesday, January 1, 2013 4:07:53 PM
> > > > > > Subject: [Engine-devel] Java code formatting
> > > > > > 
> > > > > > Hi,
> > > > > > Recently I saw many patches with multiple code
> > > > > > re-formatting.
> > > > > > When looking into it, we saw that many people didn't use
> > > > > > the
> > > > > > project
> > > > > > policy, and now we have many files with bad formatting.
> > > > > > 
> > > > > > So I just posted a big ugly fix for this[1], and hopefully
> > > > > > if
> > > > > > accepted
> > > > > > people should start using the right conventions and reduce
> > > > > > the
> > > > > > amount
> > > > > > of non-relevant changes we see in the patches.
> > > > > > 
> > > > > > I'm aware of the fact that this may create some issues when
> > > > > > porting
> > > > > > patches, but better sooner than later.
> > > > > > Doron.
> > > > > > 
> > > > > > [1] http://gerrit.ovirt.org/#/c/10541/1
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > These automatic conversions are not better than current
> > > > > state,
> > > > > also
> > > > > I
> > > > > don't think that this is that important. If you want machine
> > > > > written
> > > > > code, then also provide commit hook to reformat anything, and
> > > > > probably machines to read it.
> > > > > 
> > > > > I, personally, think that this change over the sources I
> > > > > manage
> > > > > did
> > > > > not do any good.
> > > > > 
> > > > > Regards,
> > > > > Alon
> > > > 
> > > > Alon,
> > > > there's a formatting convention for the project set long ago.
> > > > If you feel it needs to be fixed, go ahead and suggest a fix
> > > > for
> > > > the xml.
> > > > Otherwise we end up in the current chaos, where every 2nd or
> > > > 3rd
> > > > patch carries unneeded changes.
> > > > 
> > > 
> > > What do you mean unneeded changes? how do you prevent this in
> > > future?
> > > 
> > > Alon
> > 
> > Unneeded changes is when you get one line of code fixed due to a
> > bug,
> > and many others re-indented.
> > Best prevention is if people would make sure to use the same
> > conventions.
> > We also have a checkstyle which monitors important issues such as
> > trailing
> > white spaces, localization, etc.
> > 
> 
> But how do you prevent this in future, not all working in same editor
> nor same styles.
> You can say that once in a while you perform cross over auto
> re-format...
> I am not native Java programmer but this sounds very strange thing to
> do, I don't think I know of any project that does that.
> 
> The main problem is that people commit stuff they don't touch due to
> their editor behavior, which tread the whole source as if it was at
> its disposal, while cation should be taken not to modify extra
> stuff.
> 
> So maybe just to reject patches that touches lines which are not
> belong to the patch it-self.
> 
> Alon

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


From alonbl at redhat.com  Tue Jan  1 15:05:09 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 1 Jan 2013 10:05:09 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <283678361.59735242.1357052420198.JavaMail.root@redhat.com>
Message-ID: <1304234069.6949896.1357052709075.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 1, 2013 5:00:20 PM
> Subject: Re: [Engine-devel] Java code formatting
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, January 1, 2013 4:53:49 PM
> > Subject: Re: [Engine-devel] Java code formatting
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, January 1, 2013 4:48:22 PM
> > > Subject: Re: [Engine-devel] Java code formatting
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Tuesday, January 1, 2013 4:33:20 PM
> > > > Subject: Re: [Engine-devel] Java code formatting
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Tuesday, January 1, 2013 4:28:15 PM
> > > > > Subject: Re: [Engine-devel] Java code formatting
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Tuesday, January 1, 2013 4:17:18 PM
> > > > > > Subject: Re: [Engine-devel] Java code formatting
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > Sent: Tuesday, January 1, 2013 4:07:53 PM
> > > > > > > Subject: [Engine-devel] Java code formatting
> > > > > > > 
> > > > > > > Hi,
> > > > > > > Recently I saw many patches with multiple code
> > > > > > > re-formatting.
> > > > > > > When looking into it, we saw that many people didn't use
> > > > > > > the
> > > > > > > project
> > > > > > > policy, and now we have many files with bad formatting.
> > > > > > > 
> > > > > > > So I just posted a big ugly fix for this[1], and
> > > > > > > hopefully
> > > > > > > if
> > > > > > > accepted
> > > > > > > people should start using the right conventions and
> > > > > > > reduce
> > > > > > > the
> > > > > > > amount
> > > > > > > of non-relevant changes we see in the patches.
> > > > > > > 
> > > > > > > I'm aware of the fact that this may create some issues
> > > > > > > when
> > > > > > > porting
> > > > > > > patches, but better sooner than later.
> > > > > > > Doron.
> > > > > > > 
> > > > > > > [1] http://gerrit.ovirt.org/#/c/10541/1
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > These automatic conversions are not better than current
> > > > > > state,
> > > > > > also
> > > > > > I
> > > > > > don't think that this is that important. If you want
> > > > > > machine
> > > > > > written
> > > > > > code, then also provide commit hook to reformat anything,
> > > > > > and
> > > > > > probably machines to read it.
> > > > > > 
> > > > > > I, personally, think that this change over the sources I
> > > > > > manage
> > > > > > did
> > > > > > not do any good.
> > > > > > 
> > > > > > Regards,
> > > > > > Alon
> > > > > 
> > > > > Alon,
> > > > > there's a formatting convention for the project set long ago.
> > > > > If you feel it needs to be fixed, go ahead and suggest a fix
> > > > > for
> > > > > the xml.
> > > > > Otherwise we end up in the current chaos, where every 2nd or
> > > > > 3rd
> > > > > patch carries unneeded changes.
> > > > > 
> > > > 
> > > > What do you mean unneeded changes? how do you prevent this in
> > > > future?
> > > > 
> > > > Alon
> > > 
> > > Unneeded changes is when you get one line of code fixed due to a
> > > bug,
> > > and many others re-indented.
> > > Best prevention is if people would make sure to use the same
> > > conventions.
> > > We also have a checkstyle which monitors important issues such as
> > > trailing
> > > white spaces, localization, etc.
> > > 
> > 
> > But how do you prevent this in future, not all working in same
> > editor
> > nor same styles.
> > You can say that once in a while you perform cross over auto
> > re-format...
> > I am not native Java programmer but this sounds very strange thing
> > to
> > do, I don't think I know of any project that does that.
> > 
> > The main problem is that people commit stuff they don't touch due
> > to
> > their editor behavior, which tread the whole source as if it was at
> > its disposal, while cation should be taken not to modify extra
> > stuff.
> > 
> > So maybe just to reject patches that touches lines which are not
> > belong to the patch it-self.
> > 
> > Alon
> 
> I'm fine with rejecting patches with irrelevant changes.
> Still sometimes you get new files and this repeats itself.
> The whole point of a convention is that people keep it.
> Most major IDEs today can use the same formatting XML we now have.
> So it's really a matter of self-discipline.
> 

OK, I suggest we start rejecting patches with irrelevant changes, and placing these irrelevant changes in their own patch to be relevant.

I don't think that we can enforce XML formatting for all editors out there... unless there is a cli utility to reformat before commit, or even do this at gerrit side, we should be somewhat flexible.

But these are only my two cents.

Alon


From dfediuck at redhat.com  Tue Jan  1 15:39:00 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 1 Jan 2013 10:39:00 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <1304234069.6949896.1357052709075.JavaMail.root@redhat.com>
Message-ID: <373211121.59738834.1357054740418.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 1, 2013 5:05:09 PM
> Subject: Re: [Engine-devel] Java code formatting
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, January 1, 2013 5:00:20 PM
> > Subject: Re: [Engine-devel] Java code formatting
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, January 1, 2013 4:53:49 PM
> > > Subject: Re: [Engine-devel] Java code formatting
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Tuesday, January 1, 2013 4:48:22 PM
> > > > Subject: Re: [Engine-devel] Java code formatting
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Tuesday, January 1, 2013 4:33:20 PM
> > > > > Subject: Re: [Engine-devel] Java code formatting
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Tuesday, January 1, 2013 4:28:15 PM
> > > > > > Subject: Re: [Engine-devel] Java code formatting
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > Sent: Tuesday, January 1, 2013 4:17:18 PM
> > > > > > > Subject: Re: [Engine-devel] Java code formatting
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > Sent: Tuesday, January 1, 2013 4:07:53 PM
> > > > > > > > Subject: [Engine-devel] Java code formatting
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > Recently I saw many patches with multiple code
> > > > > > > > re-formatting.
> > > > > > > > When looking into it, we saw that many people didn't
> > > > > > > > use
> > > > > > > > the
> > > > > > > > project
> > > > > > > > policy, and now we have many files with bad formatting.
> > > > > > > > 
> > > > > > > > So I just posted a big ugly fix for this[1], and
> > > > > > > > hopefully
> > > > > > > > if
> > > > > > > > accepted
> > > > > > > > people should start using the right conventions and
> > > > > > > > reduce
> > > > > > > > the
> > > > > > > > amount
> > > > > > > > of non-relevant changes we see in the patches.
> > > > > > > > 
> > > > > > > > I'm aware of the fact that this may create some issues
> > > > > > > > when
> > > > > > > > porting
> > > > > > > > patches, but better sooner than later.
> > > > > > > > Doron.
> > > > > > > > 
> > > > > > > > [1] http://gerrit.ovirt.org/#/c/10541/1
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > These automatic conversions are not better than current
> > > > > > > state,
> > > > > > > also
> > > > > > > I
> > > > > > > don't think that this is that important. If you want
> > > > > > > machine
> > > > > > > written
> > > > > > > code, then also provide commit hook to reformat anything,
> > > > > > > and
> > > > > > > probably machines to read it.
> > > > > > > 
> > > > > > > I, personally, think that this change over the sources I
> > > > > > > manage
> > > > > > > did
> > > > > > > not do any good.
> > > > > > > 
> > > > > > > Regards,
> > > > > > > Alon
> > > > > > 
> > > > > > Alon,
> > > > > > there's a formatting convention for the project set long
> > > > > > ago.
> > > > > > If you feel it needs to be fixed, go ahead and suggest a
> > > > > > fix
> > > > > > for
> > > > > > the xml.
> > > > > > Otherwise we end up in the current chaos, where every 2nd
> > > > > > or
> > > > > > 3rd
> > > > > > patch carries unneeded changes.
> > > > > > 
> > > > > 
> > > > > What do you mean unneeded changes? how do you prevent this in
> > > > > future?
> > > > > 
> > > > > Alon
> > > > 
> > > > Unneeded changes is when you get one line of code fixed due to
> > > > a
> > > > bug,
> > > > and many others re-indented.
> > > > Best prevention is if people would make sure to use the same
> > > > conventions.
> > > > We also have a checkstyle which monitors important issues such
> > > > as
> > > > trailing
> > > > white spaces, localization, etc.
> > > > 
> > > 
> > > But how do you prevent this in future, not all working in same
> > > editor
> > > nor same styles.
> > > You can say that once in a while you perform cross over auto
> > > re-format...
> > > I am not native Java programmer but this sounds very strange
> > > thing
> > > to
> > > do, I don't think I know of any project that does that.
> > > 
> > > The main problem is that people commit stuff they don't touch due
> > > to
> > > their editor behavior, which tread the whole source as if it was
> > > at
> > > its disposal, while cation should be taken not to modify extra
> > > stuff.
> > > 
> > > So maybe just to reject patches that touches lines which are not
> > > belong to the patch it-self.
> > > 
> > > Alon
> > 
> > I'm fine with rejecting patches with irrelevant changes.
> > Still sometimes you get new files and this repeats itself.
> > The whole point of a convention is that people keep it.
> > Most major IDEs today can use the same formatting XML we now have.
> > So it's really a matter of self-discipline.
> > 
> 
> OK, I suggest we start rejecting patches with irrelevant changes, and
> placing these irrelevant changes in their own patch to be relevant.
> 
> I don't think that we can enforce XML formatting for all editors out
> there... unless there is a cli utility to reformat before commit, or
> even do this at gerrit side, we should be somewhat flexible.
> 
> But these are only my two cents.
> 
> Alon

Thanks to Ofri we can now both automate it and monitor it using
http://maven-java-formatter-plugin.googlecode.com/svn/site/0.3.1/examples.html.

We should be able to add it to the root pom and make sure it won't
happen again.


From lpeer at redhat.com  Tue Jan  1 15:58:15 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 01 Jan 2013 17:58:15 +0200
Subject: [Engine-devel] Java code formatting
In-Reply-To: <373211121.59738834.1357054740418.JavaMail.root@redhat.com>
References: <373211121.59738834.1357054740418.JavaMail.root@redhat.com>
Message-ID: <50E30797.1080707@redhat.com>

On 01/01/2013 05:39 PM, Doron Fediuck wrote:
> 
> 
> ----- Original Message -----
>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>> To: "Doron Fediuck" <dfediuck at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Tuesday, January 1, 2013 5:05:09 PM
>> Subject: Re: [Engine-devel] Java code formatting
>>
>>
>>
>> ----- Original Message -----
>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Tuesday, January 1, 2013 5:00:20 PM
>>> Subject: Re: [Engine-devel] Java code formatting
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Tuesday, January 1, 2013 4:53:49 PM
>>>> Subject: Re: [Engine-devel] Java code formatting
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>> Sent: Tuesday, January 1, 2013 4:48:22 PM
>>>>> Subject: Re: [Engine-devel] Java code formatting
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>> Sent: Tuesday, January 1, 2013 4:33:20 PM
>>>>>> Subject: Re: [Engine-devel] Java code formatting
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>> Sent: Tuesday, January 1, 2013 4:28:15 PM
>>>>>>> Subject: Re: [Engine-devel] Java code formatting
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>> Sent: Tuesday, January 1, 2013 4:17:18 PM
>>>>>>>> Subject: Re: [Engine-devel] Java code formatting
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>> Sent: Tuesday, January 1, 2013 4:07:53 PM
>>>>>>>>> Subject: [Engine-devel] Java code formatting
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> Recently I saw many patches with multiple code
>>>>>>>>> re-formatting.
>>>>>>>>> When looking into it, we saw that many people didn't
>>>>>>>>> use
>>>>>>>>> the
>>>>>>>>> project
>>>>>>>>> policy, and now we have many files with bad formatting.
>>>>>>>>>
>>>>>>>>> So I just posted a big ugly fix for this[1], and
>>>>>>>>> hopefully
>>>>>>>>> if
>>>>>>>>> accepted
>>>>>>>>> people should start using the right conventions and
>>>>>>>>> reduce
>>>>>>>>> the
>>>>>>>>> amount
>>>>>>>>> of non-relevant changes we see in the patches.
>>>>>>>>>
>>>>>>>>> I'm aware of the fact that this may create some issues
>>>>>>>>> when
>>>>>>>>> porting
>>>>>>>>> patches, but better sooner than later.
>>>>>>>>> Doron.
>>>>>>>>>
>>>>>>>>> [1] http://gerrit.ovirt.org/#/c/10541/1
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> These automatic conversions are not better than current
>>>>>>>> state,
>>>>>>>> also
>>>>>>>> I
>>>>>>>> don't think that this is that important. If you want
>>>>>>>> machine
>>>>>>>> written
>>>>>>>> code, then also provide commit hook to reformat anything,
>>>>>>>> and
>>>>>>>> probably machines to read it.
>>>>>>>>
>>>>>>>> I, personally, think that this change over the sources I
>>>>>>>> manage
>>>>>>>> did
>>>>>>>> not do any good.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alon
>>>>>>>
>>>>>>> Alon,
>>>>>>> there's a formatting convention for the project set long
>>>>>>> ago.
>>>>>>> If you feel it needs to be fixed, go ahead and suggest a
>>>>>>> fix
>>>>>>> for
>>>>>>> the xml.
>>>>>>> Otherwise we end up in the current chaos, where every 2nd
>>>>>>> or
>>>>>>> 3rd
>>>>>>> patch carries unneeded changes.
>>>>>>>
>>>>>>
>>>>>> What do you mean unneeded changes? how do you prevent this in
>>>>>> future?
>>>>>>
>>>>>> Alon
>>>>>
>>>>> Unneeded changes is when you get one line of code fixed due to
>>>>> a
>>>>> bug,
>>>>> and many others re-indented.
>>>>> Best prevention is if people would make sure to use the same
>>>>> conventions.
>>>>> We also have a checkstyle which monitors important issues such
>>>>> as
>>>>> trailing
>>>>> white spaces, localization, etc.
>>>>>
>>>>
>>>> But how do you prevent this in future, not all working in same
>>>> editor
>>>> nor same styles.
>>>> You can say that once in a while you perform cross over auto
>>>> re-format...
>>>> I am not native Java programmer but this sounds very strange
>>>> thing
>>>> to
>>>> do, I don't think I know of any project that does that.
>>>>
>>>> The main problem is that people commit stuff they don't touch due
>>>> to
>>>> their editor behavior, which tread the whole source as if it was
>>>> at
>>>> its disposal, while cation should be taken not to modify extra
>>>> stuff.
>>>>
>>>> So maybe just to reject patches that touches lines which are not
>>>> belong to the patch it-self.
>>>>
>>>> Alon
>>>
>>> I'm fine with rejecting patches with irrelevant changes.
>>> Still sometimes you get new files and this repeats itself.
>>> The whole point of a convention is that people keep it.
>>> Most major IDEs today can use the same formatting XML we now have.
>>> So it's really a matter of self-discipline.
>>>
>>
>> OK, I suggest we start rejecting patches with irrelevant changes, and
>> placing these irrelevant changes in their own patch to be relevant.
>>
>> I don't think that we can enforce XML formatting for all editors out
>> there... unless there is a cli utility to reformat before commit, or
>> even do this at gerrit side, we should be somewhat flexible.
>>
>> But these are only my two cents.
>>
>> Alon
> 
> Thanks to Ofri we can now both automate it and monitor it using
> http://maven-java-formatter-plugin.googlecode.com/svn/site/0.3.1/examples.html.
> 
> We should be able to add it to the root pom and make sure it won't
> happen again.

>From a quick look this plugin looks like formatted and not
format-validator, if this is the case it is less useful as we can't add
a jenkins job to monitor the expected formatting.

I think that we should clean the formatting (once again...) in our code
base only after we'll have a valid way to enforce it, otherwise we are
going to have the same thread every few months (we already had it twice
or more) and we all hate this massive formatting patches that comes
after the thread...

Livnat


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



From lhornyak at redhat.com  Tue Jan  1 17:45:40 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 1 Jan 2013 12:45:40 -0500 (EST)
Subject: [Engine-devel] Patches awaiting review.
In-Reply-To: <20121225143236.Horde.YVMvZJir309Q2imEC4Dh1QA@imap.linux.ibm.com>
Message-ID: <708004627.13523695.1357062340331.JavaMail.root@redhat.com>

Hi Sharad,

I am on it. Could you help me rebasing your changes? Some needs manual merge.

Thank you,
Laszlo

----- Original Message -----
> From: snmishra at linux.vnet.ibm.com
> To: engine-devel at ovirt.org
> Sent: Tuesday, December 25, 2012 11:32:36 PM
> Subject: [Engine-devel] Patches awaiting review.
> 
> 
> Following patches are waiting for review -
> 
> http://gerrit.ovirt.org/#/c/10072/
> http://gerrit.ovirt.org/#/c/10085/
> http://gerrit.ovirt.org/#/c/10086/
> http://gerrit.ovirt.org/#/c/10087/
> http://gerrit.ovirt.org/#/c/10042/
> 
> Thanks
> Sharad Mishra
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lhornyak at redhat.com  Tue Jan  1 18:49:18 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 1 Jan 2013 13:49:18 -0500 (EST)
Subject: [Engine-devel] Patches awaiting review.
In-Reply-To: <708004627.13523695.1357062340331.JavaMail.root@redhat.com>
Message-ID: <699921395.13524578.1357066158903.JavaMail.root@redhat.com>

All merged - except the abandoned ones.

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: snmishra at linux.vnet.ibm.com
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, January 1, 2013 6:45:40 PM
> Subject: Re: [Engine-devel] Patches awaiting review.
> 
> Hi Sharad,
> 
> I am on it. Could you help me rebasing your changes? Some needs
> manual merge.
> 
> Thank you,
> Laszlo
> 
> ----- Original Message -----
> > From: snmishra at linux.vnet.ibm.com
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, December 25, 2012 11:32:36 PM
> > Subject: [Engine-devel] Patches awaiting review.
> > 
> > 
> > Following patches are waiting for review -
> > 
> > http://gerrit.ovirt.org/#/c/10072/
> > http://gerrit.ovirt.org/#/c/10085/
> > http://gerrit.ovirt.org/#/c/10086/
> > http://gerrit.ovirt.org/#/c/10087/
> > http://gerrit.ovirt.org/#/c/10042/
> > 
> > Thanks
> > Sharad Mishra
> > 
> > _______________________________________________
> > 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 Jan  1 21:25:44 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Tue, 1 Jan 2013 16:25:44 -0500 (EST)
Subject: [Engine-devel] [Vojtech Szocs] oVirt UI Plugins overview
Message-ID: <636294573.59796099.1357075544790.JavaMail.root@redhat.com>

The following is a new meeting request:

Subject: [Vojtech Szocs] oVirt UI Plugins overview 
Organizer: "Einav Cohen" <ecohen at redhat.com> 

Location: Intercall Conference code: 7128867405# 
Time: Thursday, January 3, 2013, 8:00:00 AM - 9:00:00 AM GMT -05:00 US/Canada Eastern
 
Invitees: arch at ovirt.org; engine-devel at ovirt.org; jrankin at redhat.com; rluxenbe at redhat.com; amit at tonian.com; vszocs at redhat.com 


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

Intercall dial-in numbers:
https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405

Intercall conf code:
7128867405#

elluminate session:
https://sas.elluminate.com/m.jnlp?sid=819&password=M.6BD0C502D1CD17B559EE5EE9F9FB09
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130101/4a399392/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 3446 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130101/4a399392/attachment.ics>

From mkolesni at redhat.com  Wed Jan  2 06:37:48 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Wed, 2 Jan 2013 01:37:48 -0500 (EST)
Subject: [Engine-devel] Fwd: Change in ovirt-engine[master]: engine: Add
 FeatureSupported class
In-Reply-To: <50E19E5A.4010304@redhat.com>
Message-ID: <447709700.6880414.1357108668581.JavaMail.root@redhat.com>

Hi all,

I've added a new class FeatueSupported.

The purpose of the class is to encapsulate all the calls to "feature support" config values.
I think it will be better to add all "feature support" calls to this class from now on, as it makes it easier to read the code and also abstracts the actual implementation details from us (the configuration mechanism that is currently used for this).

For example, instead of writing:
    Config.<Boolean> GetValue(ConfigValues.NetworkLinkingSupported, getVm().getVdsGroupCompatibilityVersion().getValue())

We write:
    FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion())

I'm sure you can agree that the later one makes more sense and is easier to understand when looking at the code.

Regards,
Mike

-------- Original Message --------
Subject: Change in ovirt-engine[master]: engine: Add FeatureSupported class
Date: Sun, 30 Dec 2012 09:40:19 -0500
From: mkolesni at redhat.com
Reply-To: engine-devel at ovirt.org
To: undisclosed-recipients:;

Mike Kolesnik has submitted this change and it was merged.

Change subject: engine: Add FeatureSupported class
......................................................................


engine: Add FeatureSupported class

This is a convenience class that allows to check if a feature is
supported for a given version while keeping the actual implementation
decoupled from the code.

Future patches can add more features except the one extracted here.

Change-Id: I9d0adb696f3767ce165bfd9e78ba76a68778c91a
Signed-off-by: Mike Kolesnik <mkolesni at redhat.com>
---
M 
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/RunVmCommand.java
M 
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/network/vm/UpdateVmInterfaceCommand.java
A 
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/validator/FeatureSupported.java
M 
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/validator/VmNicValidator.java
4 files changed, 32 insertions(+), 12 deletions(-)

Approvals:
   Mike Kolesnik: Verified; Looks good to me, approved


--
To view, visit http://gerrit.ovirt.org/10486
To unsubscribe, visit http://gerrit.ovirt.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I9d0adb696f3767ce165bfd9e78ba76a68778c91a
Gerrit-PatchSet: 2
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Mike Kolesnik <mkolesni at redhat.com>
Gerrit-Reviewer: Mike Kolesnik <mkolesni at redhat.com>
Gerrit-Reviewer: Moti Asayag <masayag at redhat.com>
Gerrit-Reviewer: Muli Salem <msalem at redhat.com>
_______________________________________________
Engine-commits mailing list
Engine-commits at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-commits




From dfediuck at redhat.com  Wed Jan  2 08:24:23 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Wed, 2 Jan 2013 03:24:23 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <50E30797.1080707@redhat.com>
Message-ID: <1867450919.59970598.1357115063374.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 1, 2013 5:58:15 PM
> Subject: Re: [Engine-devel] Java code formatting
> 
> On 01/01/2013 05:39 PM, Doron Fediuck wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >> To: "Doron Fediuck" <dfediuck at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Tuesday, January 1, 2013 5:05:09 PM
> >> Subject: Re: [Engine-devel] Java code formatting
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Doron Fediuck" <dfediuck at redhat.com>
> >>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>> Sent: Tuesday, January 1, 2013 5:00:20 PM
> >>> Subject: Re: [Engine-devel] Java code formatting
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>> Sent: Tuesday, January 1, 2013 4:53:49 PM
> >>>> Subject: Re: [Engine-devel] Java code formatting
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> >>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>> Sent: Tuesday, January 1, 2013 4:48:22 PM
> >>>>> Subject: Re: [Engine-devel] Java code formatting
> >>>>>
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>> Sent: Tuesday, January 1, 2013 4:33:20 PM
> >>>>>> Subject: Re: [Engine-devel] Java code formatting
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> >>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>> Sent: Tuesday, January 1, 2013 4:28:15 PM
> >>>>>>> Subject: Re: [Engine-devel] Java code formatting
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> >>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>>> Sent: Tuesday, January 1, 2013 4:17:18 PM
> >>>>>>>> Subject: Re: [Engine-devel] Java code formatting
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> >>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>>>> Sent: Tuesday, January 1, 2013 4:07:53 PM
> >>>>>>>>> Subject: [Engine-devel] Java code formatting
> >>>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>> Recently I saw many patches with multiple code
> >>>>>>>>> re-formatting.
> >>>>>>>>> When looking into it, we saw that many people didn't
> >>>>>>>>> use
> >>>>>>>>> the
> >>>>>>>>> project
> >>>>>>>>> policy, and now we have many files with bad formatting.
> >>>>>>>>>
> >>>>>>>>> So I just posted a big ugly fix for this[1], and
> >>>>>>>>> hopefully
> >>>>>>>>> if
> >>>>>>>>> accepted
> >>>>>>>>> people should start using the right conventions and
> >>>>>>>>> reduce
> >>>>>>>>> the
> >>>>>>>>> amount
> >>>>>>>>> of non-relevant changes we see in the patches.
> >>>>>>>>>
> >>>>>>>>> I'm aware of the fact that this may create some issues
> >>>>>>>>> when
> >>>>>>>>> porting
> >>>>>>>>> patches, but better sooner than later.
> >>>>>>>>> Doron.
> >>>>>>>>>
> >>>>>>>>> [1] http://gerrit.ovirt.org/#/c/10541/1
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> These automatic conversions are not better than current
> >>>>>>>> state,
> >>>>>>>> also
> >>>>>>>> I
> >>>>>>>> don't think that this is that important. If you want
> >>>>>>>> machine
> >>>>>>>> written
> >>>>>>>> code, then also provide commit hook to reformat anything,
> >>>>>>>> and
> >>>>>>>> probably machines to read it.
> >>>>>>>>
> >>>>>>>> I, personally, think that this change over the sources I
> >>>>>>>> manage
> >>>>>>>> did
> >>>>>>>> not do any good.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Alon
> >>>>>>>
> >>>>>>> Alon,
> >>>>>>> there's a formatting convention for the project set long
> >>>>>>> ago.
> >>>>>>> If you feel it needs to be fixed, go ahead and suggest a
> >>>>>>> fix
> >>>>>>> for
> >>>>>>> the xml.
> >>>>>>> Otherwise we end up in the current chaos, where every 2nd
> >>>>>>> or
> >>>>>>> 3rd
> >>>>>>> patch carries unneeded changes.
> >>>>>>>
> >>>>>>
> >>>>>> What do you mean unneeded changes? how do you prevent this in
> >>>>>> future?
> >>>>>>
> >>>>>> Alon
> >>>>>
> >>>>> Unneeded changes is when you get one line of code fixed due to
> >>>>> a
> >>>>> bug,
> >>>>> and many others re-indented.
> >>>>> Best prevention is if people would make sure to use the same
> >>>>> conventions.
> >>>>> We also have a checkstyle which monitors important issues such
> >>>>> as
> >>>>> trailing
> >>>>> white spaces, localization, etc.
> >>>>>
> >>>>
> >>>> But how do you prevent this in future, not all working in same
> >>>> editor
> >>>> nor same styles.
> >>>> You can say that once in a while you perform cross over auto
> >>>> re-format...
> >>>> I am not native Java programmer but this sounds very strange
> >>>> thing
> >>>> to
> >>>> do, I don't think I know of any project that does that.
> >>>>
> >>>> The main problem is that people commit stuff they don't touch
> >>>> due
> >>>> to
> >>>> their editor behavior, which tread the whole source as if it was
> >>>> at
> >>>> its disposal, while cation should be taken not to modify extra
> >>>> stuff.
> >>>>
> >>>> So maybe just to reject patches that touches lines which are not
> >>>> belong to the patch it-self.
> >>>>
> >>>> Alon
> >>>
> >>> I'm fine with rejecting patches with irrelevant changes.
> >>> Still sometimes you get new files and this repeats itself.
> >>> The whole point of a convention is that people keep it.
> >>> Most major IDEs today can use the same formatting XML we now
> >>> have.
> >>> So it's really a matter of self-discipline.
> >>>
> >>
> >> OK, I suggest we start rejecting patches with irrelevant changes,
> >> and
> >> placing these irrelevant changes in their own patch to be
> >> relevant.
> >>
> >> I don't think that we can enforce XML formatting for all editors
> >> out
> >> there... unless there is a cli utility to reformat before commit,
> >> or
> >> even do this at gerrit side, we should be somewhat flexible.
> >>
> >> But these are only my two cents.
> >>
> >> Alon
> > 
> > Thanks to Ofri we can now both automate it and monitor it using
> > http://maven-java-formatter-plugin.googlecode.com/svn/site/0.3.1/examples.html.
> > 
> > We should be able to add it to the root pom and make sure it won't
> > happen again.
> 
> From a quick look this plugin looks like formatted and not
> format-validator, if this is the case it is less useful as we can't
> add
> a jenkins job to monitor the expected formatting.
> 
> I think that we should clean the formatting (once again...) in our
> code
> base only after we'll have a valid way to enforce it, otherwise we
> are
> going to have the same thread every few months (we already had it
> twice
> or more) and we all hate this massive formatting patches that comes
> after the thread...
> 
> Livnat
> 

Livnat,
it's easy enough to have a Jenkins job running this plugin.
Then git status will tell you if something changed, and if so
you email the changes to patch owner (and nack the patch). We
had similar jobs in WPF era and it's quite simple to handle.
So I see no reason why not to start it now. The sooner we start,
less noise and unneeded code changes will be added.

better


From mkolesni at redhat.com  Wed Jan  2 10:01:42 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Wed, 2 Jan 2013 05:01:42 -0500 (EST)
Subject: [Engine-devel] Add FeatureSupported class
In-Reply-To: <447709700.6880414.1357108668581.JavaMail.root@redhat.com>
Message-ID: <248559623.6915437.1357120902072.JavaMail.root@redhat.com>

Hi all,

I've added a new class FeatueSupported.

The purpose of the class is to encapsulate all the calls to "feature support" config values.
I think it will be better to add all "feature support" calls to this class from now on, as it makes it easier to read the code and also abstracts the actual implementation details from us (the configuration mechanism that is currently used for this).

For example, instead of writing:
    Config.<Boolean> GetValue(ConfigValues.NetworkLinkingSupported, getVm().getVdsGroupCompatibilityVersion().getValue())

We write:
    FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion())

I'm sure you can agree that the later one makes more sense and is easier to understand when looking at the code.

(Mail resent with updated subject)

Regards,
Mike

-------- Original Message --------
Subject: Change in ovirt-engine[master]: engine: Add FeatureSupported class
Date: Sun, 30 Dec 2012 09:40:19 -0500
From: mkolesni at redhat.com
Reply-To: engine-devel at ovirt.org
To: undisclosed-recipients:;

Mike Kolesnik has submitted this change and it was merged.

Change subject: engine: Add FeatureSupported class
......................................................................


engine: Add FeatureSupported class

This is a convenience class that allows to check if a feature is
supported for a given version while keeping the actual implementation
decoupled from the code.

Future patches can add more features except the one extracted here.

Change-Id: I9d0adb696f3767ce165bfd9e78ba76a68778c91a
Signed-off-by: Mike Kolesnik <mkolesni at redhat.com>
---
M 
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/RunVmCommand.java
M 
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/network/vm/UpdateVmInterfaceCommand.java
A 
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/validator/FeatureSupported.java
M 
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/validator/VmNicValidator.java
4 files changed, 32 insertions(+), 12 deletions(-)

Approvals:
   Mike Kolesnik: Verified; Looks good to me, approved


--
To view, visit http://gerrit.ovirt.org/10486
To unsubscribe, visit http://gerrit.ovirt.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: I9d0adb696f3767ce165bfd9e78ba76a68778c91a
Gerrit-PatchSet: 2
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Mike Kolesnik <mkolesni at redhat.com>
Gerrit-Reviewer: Mike Kolesnik <mkolesni at redhat.com>
Gerrit-Reviewer: Moti Asayag <masayag at redhat.com>
Gerrit-Reviewer: Muli Salem <msalem at redhat.com>
_______________________________________________
Engine-commits mailing list
Engine-commits at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-commits


From snmishra at linux.vnet.ibm.com  Wed Jan  2 15:29:54 2013
From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com)
Date: Wed, 02 Jan 2013 07:29:54 -0800
Subject: [Engine-devel] Patches awaiting review.
In-Reply-To: <699921395.13524578.1357066158903.JavaMail.root@redhat.com>
References: <699921395.13524578.1357066158903.JavaMail.root@redhat.com>
Message-ID: <20130102072954.Horde.SPWW8Jir309Q5FJyBqWVY8A@imap.linux.ibm.com>


Quoting Laszlo Hornyak <lhornyak at redhat.com>:

> All merged - except the abandoned ones.

Thanks Laszlo.
Jan 1st was holiday for us so didn't see your earlier message  
regarding help rebasing.

-sharad mishra

>
> ----- Original Message -----
>> From: "Laszlo Hornyak" <lhornyak at redhat.com>
>> To: snmishra at linux.vnet.ibm.com
>> Cc: engine-devel at ovirt.org
>> Sent: Tuesday, January 1, 2013 6:45:40 PM
>> Subject: Re: [Engine-devel] Patches awaiting review.
>>
>> Hi Sharad,
>>
>> I am on it. Could you help me rebasing your changes? Some needs
>> manual merge.
>>
>> Thank you,
>> Laszlo
>>
>> ----- Original Message -----
>> > From: snmishra at linux.vnet.ibm.com
>> > To: engine-devel at ovirt.org
>> > Sent: Tuesday, December 25, 2012 11:32:36 PM
>> > Subject: [Engine-devel] Patches awaiting review.
>> >
>> >
>> > Following patches are waiting for review -
>> >
>> > http://gerrit.ovirt.org/#/c/10072/
>> > http://gerrit.ovirt.org/#/c/10085/
>> > http://gerrit.ovirt.org/#/c/10086/
>> > http://gerrit.ovirt.org/#/c/10087/
>> > http://gerrit.ovirt.org/#/c/10042/
>> >
>> > Thanks
>> > Sharad Mishra
>> >
>> > _______________________________________________
>> > Engine-devel mailing list
>> > Engine-devel at ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>





From yzaslavs at redhat.com  Wed Jan  2 16:28:28 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 2 Jan 2013 11:28:28 -0500 (EST)
Subject: [Engine-devel] Patches awaiting review.
In-Reply-To: <20130102072954.Horde.SPWW8Jir309Q5FJyBqWVY8A@imap.linux.ibm.com>
Message-ID: <170310873.52118526.1357144108426.JavaMail.root@redhat.com>



----- Original Message -----
> From: snmishra at linux.vnet.ibm.com
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 2, 2013 5:29:54 PM
> Subject: Re: [Engine-devel] Patches awaiting review.
> 
> 
> Quoting Laszlo Hornyak <lhornyak at redhat.com>:
> 
> > All merged - except the abandoned ones.
> 
> Thanks Laszlo.
> Jan 1st was holiday for us so didn't see your earlier message
> regarding help rebasing.
> 
> -sharad mishra

Thanks for the effort Laszlo!

> 
> >
> > ----- Original Message -----
> >> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> >> To: snmishra at linux.vnet.ibm.com
> >> Cc: engine-devel at ovirt.org
> >> Sent: Tuesday, January 1, 2013 6:45:40 PM
> >> Subject: Re: [Engine-devel] Patches awaiting review.
> >>
> >> Hi Sharad,
> >>
> >> I am on it. Could you help me rebasing your changes? Some needs
> >> manual merge.
> >>
> >> Thank you,
> >> Laszlo
> >>
> >> ----- Original Message -----
> >> > From: snmishra at linux.vnet.ibm.com
> >> > To: engine-devel at ovirt.org
> >> > Sent: Tuesday, December 25, 2012 11:32:36 PM
> >> > Subject: [Engine-devel] Patches awaiting review.
> >> >
> >> >
> >> > Following patches are waiting for review -
> >> >
> >> > http://gerrit.ovirt.org/#/c/10072/
> >> > http://gerrit.ovirt.org/#/c/10085/
> >> > http://gerrit.ovirt.org/#/c/10086/
> >> > http://gerrit.ovirt.org/#/c/10087/
> >> > http://gerrit.ovirt.org/#/c/10042/
> >> >
> >> > Thanks
> >> > Sharad Mishra
> >> >
> >> > _______________________________________________
> >> > 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 Christopher.Morrissey at netapp.com  Wed Jan  2 21:44:07 2013
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Wed, 2 Jan 2013 21:44:07 +0000
Subject: [Engine-devel] [vdsm] FW: Querying for and registering unknown
 disk images on a storage domain
In-Reply-To: <50D73810.80605@redhat.com>
References: <D290AD8432118048947689BA3AE8A9B3094E3FDC@SACEXCMBX04-PRD.hq.netapp.com>
	<50D70E6A.9060407@linux.vnet.ibm.com> <50D73810.80605@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3094EED1A@SACEXCMBX04-PRD.hq.netapp.com>



-Chris


> -----Original Message-----
> From: Itamar Heim [mailto:iheim at redhat.com]
> Sent: Sunday, December 23, 2012 11:58 AM
> To: Shu Ming
> Cc: Morrissey, Christopher; engine-devel at ovirt.org; vdsm-
> devel at lists.fedorahosted.org
> Subject: Re: [vdsm] [Engine-devel] FW: Querying for and registering
> unknown disk images on a storage domain
> 
> On 12/23/2012 04:00 PM, Shu Ming wrote:
> > 2012-12-20 23:18, Morrissey, Christopher:
> >>
> >> Hi All,
> >>
> >> I?ve been working on a bit of functionality for the engine that will
> >> allow a user to query a domain for new disk images
> >> (GetUnregisteredImagesQuery) for which the engine was previously
> >> unaware and a separate command to register those images
> >> (ImportImageCommand). These commands will be exposed through the
> REST API.
> >>
> >> This functionality is needed as we are developing an extension/plugin
> >> to oVirt that will allow a NetApp storage controller to handle
> >> cloning the actual disks outside of oVirt and need to import them
> >> once they are cloned. We?ll be using other existing APIs to attach
> >> the disk to the necessary VM once the disk is cloned. On the NetApp
> >> side, we?ll ensure the disk is coalesced before cloning so as to
> >> avoid the issues of registering snapshots.
> >>
> >   I am just curious about how the third party tool like NetApp to make
> > sure the disk of a running VM coalesced before cloning? By an agent in
> > the VM to flush file-system cache out to the disk?
> 
> I'd expect either a livesnapshot before, or doing this on a VM which is down.
>

Yes, we were planning on only allowing this type of operation on a VM which has been stopped and if it is not a template, we would create a template in the background which would ensure the disk is coalesced. All of this being done through the REST API which from what I can tell is currently possible.
 
> >
> >> GetUnregisteredImagesQuery will be accessible through the disks
> >> resource collection on a storage domain. A ?disks? resource
> >> collection does not yet exist and will need to be added. To access
> >> the unregistered images, a parameter (maybe ?unregistered=true?)
> >> would be passed. So the path to ?GET? the unregistered disk images on
> >> a domain would be something like
> >> /api/storagedomains/f0dbcb33-69d3-4899-9352-
> 8e8a02f01bbd/disks?unregistered=true.
> >> This will return a list of disk images that can be each used as input
> >> to the ImportImageCommand to get them added to oVirt.
> >>
> >> ImportImageCommand will be accessible through ?POST?ing a disk to
> >> /api/disks?import=true. The disk will be added to the oVirt DB based
> >> on the information supplied and afterward would be available to
> >> attach to a VM.
> >>
> >> When querying for unregistered disk images, the
> >> GetUnregisteredImagesQuery command will use the getImagesList()
> VDSM
> >> command. Currently this only reports the GUIDs of all disk images in
> >> a domain. I had been using the getVolumesList() and getVolumeInfo()
> >> VDSM commands to fill in the information so that valid disk image
> >> objects could be registered in oVirt. It seems these two functions
> >> are set to be removed since they are too invasive into the internal
> >> VDSM workings. The VDSM team will need to either return more
> >> information about each disk as part of the getImagesList() function
> >> or add a new function getImageInfo() that will give the same
> >> information for a given image GUID.
> >>
> >
> > Here is the project proposal for floating disk in oVirt.  I think
> > unregistered images are also floating disks.
> > http://www.ovirt.org/Features/DetailedFloatingDisk
> 
> floating disks are disks the engine is aware of, but not associated to any VM.
> the scan domain feature is to add "orphan" disks - disks on the storage the
> engine isn't aware of to begin with.

From plysab at gmail.com  Thu Jan  3 03:23:32 2013
From: plysab at gmail.com (ly pan)
Date: Thu, 3 Jan 2013 11:23:32 +0800
Subject: [Engine-devel] Problem in ovirt-reports sso
Message-ID: <CANDY9WP4P5z6P-Rfnvu7qe+dzgrFiw_mw16yAg25nBph2hUgCQ@mail.gmail.com>

Hello, I have a reports problem which has got me for many days now.
The reports sso feature is not functioning in my invironment.
I followed the steps from the wiki page:
http://www.ovirt.org/How_to_setup_a_oVirt_Reports_development_environment
http://www.ovirt.org/Features/Design/Reports_Dashboard
and the patch related to sso:
http://gerrit.ovirt.org/#change,3355

here is my steps:
1. install jasperreports 4.7.0 using the bundled tomcat and the existing DB
2. modify the db password in ovirt.xml
3. import the reports using js-import.sh
4. add the EngineSimplePreAuthFilter in applicationContext-security-web.xml
5. add Reports.xml to the wenadmin folder and change
RedirectServletReportsPage in db
6. generate a keystore using keytool and update
EngineSimplePreAuthFilter in applicationContext-security-web.xml
7. install the ovirt-dwh rpm package made from source and run
ovirt-engine-dwh-setup
8. start the ovirt-engine service and the tomcat

And all the projects, ovirt-dwh, ovirt-reports, ovirt-engine, is build
from the latest source.

When I browse to the dashboard in webadmin portal,it just shows a
jasper login page,
so the sso is not functioning, right?
I can login and browse jasper reports in a browser page normally.
So I try to login in dashboard using reports user, tomcat gives me a Exception:

"java.lang.IllegalArgumentException: An id is required to lookup a
FlowDefinition"

What might be the problem? Am I missing anything?
Any help would be appriciated, thanks.


From ovedo at redhat.com  Thu Jan  3 12:43:45 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Thu, 3 Jan 2013 07:43:45 -0500 (EST)
Subject: [Engine-devel] Problem in ovirt-reports sso
In-Reply-To: <CANDY9WP4P5z6P-Rfnvu7qe+dzgrFiw_mw16yAg25nBph2hUgCQ@mail.gmail.com>
Message-ID: <1894798363.71058747.1357217025202.JavaMail.root@redhat.com>

See comments/questions inline.

Oved

----- Original Message -----
> From: "ly pan" <plysab at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, January 3, 2013 5:23:32 AM
> Subject: [Engine-devel] Problem in ovirt-reports sso
> 
> Hello, I have a reports problem which has got me for many days now.
> The reports sso feature is not functioning in my invironment.
> I followed the steps from the wiki page:
> http://www.ovirt.org/How_to_setup_a_oVirt_Reports_development_environment
> http://www.ovirt.org/Features/Design/Reports_Dashboard
> and the patch related to sso:
> http://gerrit.ovirt.org/#change,3355
> 
> here is my steps:
> 1. install jasperreports 4.7.0 using the bundled tomcat and the
> existing DB
> 2. modify the db password in ovirt.xml
> 3. import the reports using js-import.sh
> 4. add the EngineSimplePreAuthFilter in
> applicationContext-security-web.xml
Can you share that file with us? (obviously remove sensitive data from it, such as keystore password).

> 5. add Reports.xml to the wenadmin folder and change
> RedirectServletReportsPage in db
> 6. generate a keystore using keytool and update
> EngineSimplePreAuthFilter in applicationContext-security-web.xml
You're supposed to create a trust store, that trusts the certificate of the oVirt engine. Did you do that?

> 7. install the ovirt-dwh rpm package made from source and run
> ovirt-engine-dwh-setup
> 8. start the ovirt-engine service and the tomcat
> 
> And all the projects, ovirt-dwh, ovirt-reports, ovirt-engine, is
> build
> from the latest source.
> 
> When I browse to the dashboard in webadmin portal,it just shows a
> jasper login page,
> so the sso is not functioning, right?
Can you please attach the jboss logs? (engine.log and server.log).

> I can login and browse jasper reports in a browser page normally.
> So I try to login in dashboard using reports user, tomcat gives me a
> Exception:
> 
> "java.lang.IllegalArgumentException: An id is required to lookup a
> FlowDefinition"
> 
Not sure if that error is related or not, but hopefully the logs will point us to the problem.

> What might be the problem? Am I missing anything?
> Any help would be appriciated, thanks.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ovedo at redhat.com  Thu Jan  3 16:03:53 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Thu, 3 Jan 2013 11:03:53 -0500 (EST)
Subject: [Engine-devel] Problem in ovirt-reports sso
In-Reply-To: <CANDY9WN6+zMRtow8wBLPo=w++ezBG0Zzde_v1vyQk=BkOcytAw@mail.gmail.com>
Message-ID: <1245799349.71215375.1357229033847.JavaMail.root@redhat.com>

Hey,

First of all, you forgot to add the EngineSimplePreAuthFilter to the filter chain (you just added the bean).
See http://gerrit.ovirt.org/#/c/3355/:

* Adding the EngineSimplePreAuthFilter filter to the filter chain for /**:

/**=httpSessionContextIntegrationFilter,multipartRequestWrapperFilter,webAppSecurityFilter,jsCsrfGuardFilter,${bean.loggingFilter},${bean.userPreferencesFilter},${bean.authenticationProcessingFilter},${bean.userPreferencesFilter},${bean.basicProcessingFilter},EngineSimplePreAuthFilter,requestParameterAuthenticationFilter,JIAuthenticationSynchronizer,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor,switchUserProcessingFilter,iPadSupportFilter

You basically defined the pre authentication filter, but it wasn't used in your filter chain.

As for http / https for the jasper server, not sure they should be equal (i.e., both http or both https). I think it should work well even if one is secured while the other isn't.
First try to add the the Filter to the filter chain, and let's see what happens.

Also, you can set the following options in the EngineSimplePreAuthFilter bean in case of ssl issues (in case you want to skip validation just to see that it works, without the need to troubleshoot exactly what's the problem):
sslIgnoreCertErrors
sslIgnoreHostVerification

You set them by adding the lines
            <property name="sslIgnoreCertErrors" value="true"/>
            <property name="sslIgnoreHostVerification" value="true"/>
to the bean definition (in addition to all the other options you used):

So, in your resulting file you should have:

/**=httpSessionContextIntegrationFilter,multipartRequestWrapperFilter,webAppSecurityFilter,jsCsrfGuardFilter,${bean.loggingFilter},${bean.userPreferencesFilter},${bean.authenticationProcessingFilter},${bean.userPreferencesFilter},${bean.basicProcessingFilter},EngineSimplePreAuthFilter,requestParameterAuthenticationFilter,JIAuthenticationSynchronizer,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor,switchUserProcessingFilter,iPadSupportFilter

and also have (if you choose to change the ssl definitions to be more permissive):

    <bean id="EngineSimplePreAuthFilter" class="org.ovirt.authentication.EngineSimplePreAuthFilter">
        <property name="authenticationManager">
            <ref bean="authenticationManager"></ref>
        </property>
        <property name="servletURL" value="http://localhost/OvirtEngineWeb/ValidateSession"></property>
        <property name="pollingTimeout" value="60"></property>
        <property name="trustStorePath" value="/etc/pki/ovirt-engine/.truststore"></property>
        <property name="trustStorePassword" value=""></property>
        <property name="sslIgnoreCertErrors" value="true"/>
        <property name="sslIgnoreHostVerification" value="true"/>
    </bean>

Also, try looking out for the jasper server log in case of problems.

btw, does the report server work well for you when working with it not through the webadmin? Make sure it does before you bother to troubleshoot the SSO.

Hope it helps,
Oved


----- Original Message -----
> From: "ly pan" <plysab at gmail.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, January 3, 2013 5:43:25 PM
> Subject: Re: [Engine-devel] Problem in ovirt-reports sso
> 
> Thanks for the help, Oved
> 
> I want to add some info:
> 1. my environment is fc17, my browser is firefox.
> 2. I access admin portal using https (rpm has done that for me) while
> my jasper configuration is http
>     in db's RedirectServletReportsPage and
> applicationContext-security-web.xml, every time I browse to
>     dashboard the browser prompt me with the message about
>     unencrypted
> connection in encrypted page.
>     Should I use https for jasper as well?
>     If this is the case, what configuration shoud be added?
> 
> Thanks!
> 
> ly pan
> 
> 
> 2013/1/3 Oved Ourfalli <ovedo at redhat.com>:
> > See comments/questions inline.
> >
> > Oved
> >
> > ----- Original Message -----
> >> From: "ly pan" <plysab at gmail.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Thursday, January 3, 2013 5:23:32 AM
> >> Subject: [Engine-devel] Problem in ovirt-reports sso
> >>
> >> Hello, I have a reports problem which has got me for many days
> >> now.
> >> The reports sso feature is not functioning in my invironment.
> >> I followed the steps from the wiki page:
> >> http://www.ovirt.org/How_to_setup_a_oVirt_Reports_development_environment
> >> http://www.ovirt.org/Features/Design/Reports_Dashboard
> >> and the patch related to sso:
> >> http://gerrit.ovirt.org/#change,3355
> >>
> >> here is my steps:
> >> 1. install jasperreports 4.7.0 using the bundled tomcat and the
> >> existing DB
> >> 2. modify the db password in ovirt.xml
> >> 3. import the reports using js-import.sh
> >> 4. add the EngineSimplePreAuthFilter in
> >> applicationContext-security-web.xml
> > Can you share that file with us? (obviously remove sensitive data
> > from it, such as keystore password).
> Of course, see the attached files.
> >
> >> 5. add Reports.xml to the wenadmin folder and change
> >> RedirectServletReportsPage in db
> >> 6. generate a keystore using keytool and update
> >> EngineSimplePreAuthFilter in applicationContext-security-web.xml
> > You're supposed to create a trust store, that trusts the
> > certificate of the oVirt engine. Did you do that?
> I didn't add the certificate to truststore,my bad. But I changed the
> trustStore file to the existing /etc/pki/ovirt-engine/.truststore
> in applicationContext-security-web.xml, nothing changed at all.
> >
> >> 7. install the ovirt-dwh rpm package made from source and run
> >> ovirt-engine-dwh-setup
> >> 8. start the ovirt-engine service and the tomcat
> >>
> >> And all the projects, ovirt-dwh, ovirt-reports, ovirt-engine, is
> >> build
> >> from the latest source.
> >>
> >> When I browse to the dashboard in webadmin portal,it just shows a
> >> jasper login page,
> >> so the sso is not functioning, right?
> > Can you please attach the jboss logs? (engine.log and server.log).
> these two logs have no new messages when I browse to the dashboard,I
> think it is not necesssary...but I'll attach it anyhow,
> and please skip the earlier log messages about wrong db password.
> >
> >> I can login and browse jasper reports in a browser page normally.
> >> So I try to login in dashboard using reports user, tomcat gives me
> >> a
> >> Exception:
> >>
> >> "java.lang.IllegalArgumentException: An id is required to lookup a
> >> FlowDefinition"
> >>
> > Not sure if that error is related or not, but hopefully the logs
> > will point us to the problem.
> the full stack trace is in the attach file catalina.out from tomcat
> logs.
> 
> >
> >> What might be the problem? Am I missing anything?
> >> Any help would be appriciated, thanks.
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 


From plysab at gmail.com  Thu Jan  3 15:43:25 2013
From: plysab at gmail.com (ly pan)
Date: Thu, 3 Jan 2013 23:43:25 +0800
Subject: [Engine-devel] Problem in ovirt-reports sso
In-Reply-To: <1894798363.71058747.1357217025202.JavaMail.root@redhat.com>
References: <CANDY9WP4P5z6P-Rfnvu7qe+dzgrFiw_mw16yAg25nBph2hUgCQ@mail.gmail.com>
	<1894798363.71058747.1357217025202.JavaMail.root@redhat.com>
Message-ID: <CANDY9WN6+zMRtow8wBLPo=w++ezBG0Zzde_v1vyQk=BkOcytAw@mail.gmail.com>

Thanks for the help, Oved

I want to add some info:
1. my environment is fc17, my browser is firefox.
2. I access admin portal using https (rpm has done that for me) while
my jasper configuration is http
    in db's RedirectServletReportsPage and
applicationContext-security-web.xml, every time I browse to
    dashboard the browser prompt me with the message about unencrypted
connection in encrypted page.
    Should I use https for jasper as well?
    If this is the case, what configuration shoud be added?

Thanks!

ly pan


2013/1/3 Oved Ourfalli <ovedo at redhat.com>:
> See comments/questions inline.
>
> Oved
>
> ----- Original Message -----
>> From: "ly pan" <plysab at gmail.com>
>> To: engine-devel at ovirt.org
>> Sent: Thursday, January 3, 2013 5:23:32 AM
>> Subject: [Engine-devel] Problem in ovirt-reports sso
>>
>> Hello, I have a reports problem which has got me for many days now.
>> The reports sso feature is not functioning in my invironment.
>> I followed the steps from the wiki page:
>> http://www.ovirt.org/How_to_setup_a_oVirt_Reports_development_environment
>> http://www.ovirt.org/Features/Design/Reports_Dashboard
>> and the patch related to sso:
>> http://gerrit.ovirt.org/#change,3355
>>
>> here is my steps:
>> 1. install jasperreports 4.7.0 using the bundled tomcat and the
>> existing DB
>> 2. modify the db password in ovirt.xml
>> 3. import the reports using js-import.sh
>> 4. add the EngineSimplePreAuthFilter in
>> applicationContext-security-web.xml
> Can you share that file with us? (obviously remove sensitive data from it, such as keystore password).
Of course, see the attached files.
>
>> 5. add Reports.xml to the wenadmin folder and change
>> RedirectServletReportsPage in db
>> 6. generate a keystore using keytool and update
>> EngineSimplePreAuthFilter in applicationContext-security-web.xml
> You're supposed to create a trust store, that trusts the certificate of the oVirt engine. Did you do that?
I didn't add the certificate to truststore,my bad. But I changed the
trustStore file to the existing /etc/pki/ovirt-engine/.truststore
in applicationContext-security-web.xml, nothing changed at all.
>
>> 7. install the ovirt-dwh rpm package made from source and run
>> ovirt-engine-dwh-setup
>> 8. start the ovirt-engine service and the tomcat
>>
>> And all the projects, ovirt-dwh, ovirt-reports, ovirt-engine, is
>> build
>> from the latest source.
>>
>> When I browse to the dashboard in webadmin portal,it just shows a
>> jasper login page,
>> so the sso is not functioning, right?
> Can you please attach the jboss logs? (engine.log and server.log).
these two logs have no new messages when I browse to the dashboard,I
think it is not necesssary...but I'll attach it anyhow,
and please skip the earlier log messages about wrong db password.
>
>> I can login and browse jasper reports in a browser page normally.
>> So I try to login in dashboard using reports user, tomcat gives me a
>> Exception:
>>
>> "java.lang.IllegalArgumentException: An id is required to lookup a
>> FlowDefinition"
>>
> Not sure if that error is related or not, but hopefully the logs will point us to the problem.
the full stack trace is in the attach file catalina.out from tomcat logs.

>
>> What might be the problem? Am I missing anything?
>> Any help would be appriciated, thanks.
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: applicationContext-security-web.xml
Type: text/xml
Size: 18131 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130103/27633fa4/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.log
Type: application/octet-stream
Size: 291678 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130103/27633fa4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: engine.log
Type: application/octet-stream
Size: 479573 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130103/27633fa4/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: catalina.out
Type: application/octet-stream
Size: 13126 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130103/27633fa4/attachment-0002.obj>

From plysab at gmail.com  Thu Jan  3 18:33:47 2013
From: plysab at gmail.com (ly pan)
Date: Fri, 4 Jan 2013 02:33:47 +0800
Subject: [Engine-devel] Problem in ovirt-reports sso
In-Reply-To: <1245799349.71215375.1357229033847.JavaMail.root@redhat.com>
References: <CANDY9WN6+zMRtow8wBLPo=w++ezBG0Zzde_v1vyQk=BkOcytAw@mail.gmail.com>
	<1245799349.71215375.1357229033847.JavaMail.root@redhat.com>
Message-ID: <CANDY9WNgao_pU0MVzo2jnuhfCYG-nziyHRB8mqVzf2_wBB6q+g@mail.gmail.com>

Thanks for the help Oved, you are my savior.

Regards
ly pan

2013/1/4 Oved Ourfalli <ovedo at redhat.com>:
> Hey,
>
> First of all, you forgot to add the EngineSimplePreAuthFilter to the filter chain (you just added the bean).
Indeed this is what is causing the problem...
Now I can browse the reports using 'show report' feature, thanks a lot :)
However when I browse to dashboard, it shows 'Specified page not
found', I think this is not related to this sso topic now, I'll look
into this later.
> See http://gerrit.ovirt.org/#/c/3355/:
>
> * Adding the EngineSimplePreAuthFilter filter to the filter chain for /**:
>
> /**=httpSessionContextIntegrationFilter,multipartRequestWrapperFilter,webAppSecurityFilter,jsCsrfGuardFilter,${bean.loggingFilter},${bean.userPreferencesFilter},${bean.authenticationProcessingFilter},${bean.userPreferencesFilter},${bean.basicProcessingFilter},EngineSimplePreAuthFilter,requestParameterAuthenticationFilter,JIAuthenticationSynchronizer,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor,switchUserProcessingFilter,iPadSupportFilter
>
> You basically defined the pre authentication filter, but it wasn't used in your filter chain.
>
> As for http / https for the jasper server, not sure they should be equal (i.e., both http or both https). I think it should work well even if one is secured while the other isn't.
> First try to add the the Filter to the filter chain, and let's see what happens.
>
> Also, you can set the following options in the EngineSimplePreAuthFilter bean in case of ssl issues (in case you want to skip validation just to see that it works, without the need to troubleshoot exactly what's the problem):
> sslIgnoreCertErrors
> sslIgnoreHostVerification
>
> You set them by adding the lines
>             <property name="sslIgnoreCertErrors" value="true"/>
>             <property name="sslIgnoreHostVerification" value="true"/>
> to the bean definition (in addition to all the other options you used):
>
> So, in your resulting file you should have:
>
> /**=httpSessionContextIntegrationFilter,multipartRequestWrapperFilter,webAppSecurityFilter,jsCsrfGuardFilter,${bean.loggingFilter},${bean.userPreferencesFilter},${bean.authenticationProcessingFilter},${bean.userPreferencesFilter},${bean.basicProcessingFilter},EngineSimplePreAuthFilter,requestParameterAuthenticationFilter,JIAuthenticationSynchronizer,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor,switchUserProcessingFilter,iPadSupportFilter
>
> and also have (if you choose to change the ssl definitions to be more permissive):
>
>     <bean id="EngineSimplePreAuthFilter" class="org.ovirt.authentication.EngineSimplePreAuthFilter">
>         <property name="authenticationManager">
>             <ref bean="authenticationManager"></ref>
>         </property>
>         <property name="servletURL" value="http://localhost/OvirtEngineWeb/ValidateSession"></property>
>         <property name="pollingTimeout" value="60"></property>
>         <property name="trustStorePath" value="/etc/pki/ovirt-engine/.truststore"></property>
>         <property name="trustStorePassword" value=""></property>
>         <property name="sslIgnoreCertErrors" value="true"/>
>         <property name="sslIgnoreHostVerification" value="true"/>
>     </bean>
>
> Also, try looking out for the jasper server log in case of problems.
>
> btw, does the report server work well for you when working with it not through the webadmin? Make sure it does before you bother to troubleshoot the SSO.
>
> Hope it helps,
> Oved
>
>
> ----- Original Message -----
>> From: "ly pan" <plysab at gmail.com>
>> To: "Oved Ourfalli" <ovedo at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Thursday, January 3, 2013 5:43:25 PM
>> Subject: Re: [Engine-devel] Problem in ovirt-reports sso
>>
>> Thanks for the help, Oved
>>
>> I want to add some info:
>> 1. my environment is fc17, my browser is firefox.
>> 2. I access admin portal using https (rpm has done that for me) while
>> my jasper configuration is http
>>     in db's RedirectServletReportsPage and
>> applicationContext-security-web.xml, every time I browse to
>>     dashboard the browser prompt me with the message about
>>     unencrypted
>> connection in encrypted page.
>>     Should I use https for jasper as well?
>>     If this is the case, what configuration shoud be added?
>>
>> Thanks!
>>
>> ly pan
>>
>>
>> 2013/1/3 Oved Ourfalli <ovedo at redhat.com>:
>> > See comments/questions inline.
>> >
>> > Oved
>> >
>> > ----- Original Message -----
>> >> From: "ly pan" <plysab at gmail.com>
>> >> To: engine-devel at ovirt.org
>> >> Sent: Thursday, January 3, 2013 5:23:32 AM
>> >> Subject: [Engine-devel] Problem in ovirt-reports sso
>> >>
>> >> Hello, I have a reports problem which has got me for many days
>> >> now.
>> >> The reports sso feature is not functioning in my invironment.
>> >> I followed the steps from the wiki page:
>> >> http://www.ovirt.org/How_to_setup_a_oVirt_Reports_development_environment
>> >> http://www.ovirt.org/Features/Design/Reports_Dashboard
>> >> and the patch related to sso:
>> >> http://gerrit.ovirt.org/#change,3355
>> >>
>> >> here is my steps:
>> >> 1. install jasperreports 4.7.0 using the bundled tomcat and the
>> >> existing DB
>> >> 2. modify the db password in ovirt.xml
>> >> 3. import the reports using js-import.sh
>> >> 4. add the EngineSimplePreAuthFilter in
>> >> applicationContext-security-web.xml
>> > Can you share that file with us? (obviously remove sensitive data
>> > from it, such as keystore password).
>> Of course, see the attached files.
>> >
>> >> 5. add Reports.xml to the wenadmin folder and change
>> >> RedirectServletReportsPage in db
>> >> 6. generate a keystore using keytool and update
>> >> EngineSimplePreAuthFilter in applicationContext-security-web.xml
>> > You're supposed to create a trust store, that trusts the
>> > certificate of the oVirt engine. Did you do that?
>> I didn't add the certificate to truststore,my bad. But I changed the
>> trustStore file to the existing /etc/pki/ovirt-engine/.truststore
>> in applicationContext-security-web.xml, nothing changed at all.
>> >
>> >> 7. install the ovirt-dwh rpm package made from source and run
>> >> ovirt-engine-dwh-setup
>> >> 8. start the ovirt-engine service and the tomcat
>> >>
>> >> And all the projects, ovirt-dwh, ovirt-reports, ovirt-engine, is
>> >> build
>> >> from the latest source.
>> >>
>> >> When I browse to the dashboard in webadmin portal,it just shows a
>> >> jasper login page,
>> >> so the sso is not functioning, right?
>> > Can you please attach the jboss logs? (engine.log and server.log).
>> these two logs have no new messages when I browse to the dashboard,I
>> think it is not necesssary...but I'll attach it anyhow,
>> and please skip the earlier log messages about wrong db password.
>> >
>> >> I can login and browse jasper reports in a browser page normally.
>> >> So I try to login in dashboard using reports user, tomcat gives me
>> >> a
>> >> Exception:
>> >>
>> >> "java.lang.IllegalArgumentException: An id is required to lookup a
>> >> FlowDefinition"
>> >>
>> > Not sure if that error is related or not, but hopefully the logs
>> > will point us to the problem.
>> the full stack trace is in the attach file catalina.out from tomcat
>> logs.
>>
>> >
>> >> What might be the problem? Am I missing anything?
>> >> Any help would be appriciated, thanks.
>> >> _______________________________________________
>> >> Engine-devel mailing list
>> >> Engine-devel at ovirt.org
>> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >>
>>


From djasa at redhat.com  Fri Jan  4 14:37:13 2013
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Fri, 04 Jan 2013 15:37:13 +0100
Subject: [Engine-devel] Java code formatting
In-Reply-To: <1867450919.59970598.1357115063374.JavaMail.root@redhat.com>
References: <1867450919.59970598.1357115063374.JavaMail.root@redhat.com>
Message-ID: <1357310233.3532.50.camel@dhcp-29-7.brq.redhat.com>

Doron Fediuck p??e v St 02. 01. 2013 v 03:24 -0500:
> 
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, January 1, 2013 5:58:15 PM
> > Subject: Re: [Engine-devel] Java code formatting
> > 
> > On 01/01/2013 05:39 PM, Doron Fediuck wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > >> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > >> To: "Doron Fediuck" <dfediuck at redhat.com>
> > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > >> Sent: Tuesday, January 1, 2013 5:05:09 PM
> > >> Subject: Re: [Engine-devel] Java code formatting
> > >>
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > >>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > >>> Sent: Tuesday, January 1, 2013 5:00:20 PM
> > >>> Subject: Re: [Engine-devel] Java code formatting
> > >>>
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > >>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > >>>> Sent: Tuesday, January 1, 2013 4:53:49 PM
> > >>>> Subject: Re: [Engine-devel] Java code formatting
> > >>>>
> > >>>>
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > >>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > >>>>> Sent: Tuesday, January 1, 2013 4:48:22 PM
> > >>>>> Subject: Re: [Engine-devel] Java code formatting
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > >>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > >>>>>> Sent: Tuesday, January 1, 2013 4:33:20 PM
> > >>>>>> Subject: Re: [Engine-devel] Java code formatting
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> ----- Original Message -----
> > >>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > >>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > >>>>>>> Sent: Tuesday, January 1, 2013 4:28:15 PM
> > >>>>>>> Subject: Re: [Engine-devel] Java code formatting
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> ----- Original Message -----
> > >>>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > >>>>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > >>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > >>>>>>>> Sent: Tuesday, January 1, 2013 4:17:18 PM
> > >>>>>>>> Subject: Re: [Engine-devel] Java code formatting
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> ----- Original Message -----
> > >>>>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > >>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> > >>>>>>>>> Sent: Tuesday, January 1, 2013 4:07:53 PM
> > >>>>>>>>> Subject: [Engine-devel] Java code formatting
> > >>>>>>>>>
> > >>>>>>>>> Hi,
> > >>>>>>>>> Recently I saw many patches with multiple code
> > >>>>>>>>> re-formatting.
> > >>>>>>>>> When looking into it, we saw that many people didn't
> > >>>>>>>>> use
> > >>>>>>>>> the
> > >>>>>>>>> project
> > >>>>>>>>> policy, and now we have many files with bad formatting.
> > >>>>>>>>>
> > >>>>>>>>> So I just posted a big ugly fix for this[1], and
> > >>>>>>>>> hopefully
> > >>>>>>>>> if
> > >>>>>>>>> accepted
> > >>>>>>>>> people should start using the right conventions and
> > >>>>>>>>> reduce
> > >>>>>>>>> the
> > >>>>>>>>> amount
> > >>>>>>>>> of non-relevant changes we see in the patches.
> > >>>>>>>>>
> > >>>>>>>>> I'm aware of the fact that this may create some issues
> > >>>>>>>>> when
> > >>>>>>>>> porting
> > >>>>>>>>> patches, but better sooner than later.
> > >>>>>>>>> Doron.
> > >>>>>>>>>
> > >>>>>>>>> [1] http://gerrit.ovirt.org/#/c/10541/1
> > >>>>>>>>
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> These automatic conversions are not better than current
> > >>>>>>>> state,
> > >>>>>>>> also
> > >>>>>>>> I
> > >>>>>>>> don't think that this is that important. If you want
> > >>>>>>>> machine
> > >>>>>>>> written
> > >>>>>>>> code, then also provide commit hook to reformat anything,
> > >>>>>>>> and
> > >>>>>>>> probably machines to read it.
> > >>>>>>>>
> > >>>>>>>> I, personally, think that this change over the sources I
> > >>>>>>>> manage
> > >>>>>>>> did
> > >>>>>>>> not do any good.
> > >>>>>>>>
> > >>>>>>>> Regards,
> > >>>>>>>> Alon
> > >>>>>>>
> > >>>>>>> Alon,
> > >>>>>>> there's a formatting convention for the project set long
> > >>>>>>> ago.
> > >>>>>>> If you feel it needs to be fixed, go ahead and suggest a
> > >>>>>>> fix
> > >>>>>>> for
> > >>>>>>> the xml.
> > >>>>>>> Otherwise we end up in the current chaos, where every 2nd
> > >>>>>>> or
> > >>>>>>> 3rd
> > >>>>>>> patch carries unneeded changes.
> > >>>>>>>
> > >>>>>>
> > >>>>>> What do you mean unneeded changes? how do you prevent this in
> > >>>>>> future?
> > >>>>>>
> > >>>>>> Alon
> > >>>>>
> > >>>>> Unneeded changes is when you get one line of code fixed due to
> > >>>>> a
> > >>>>> bug,
> > >>>>> and many others re-indented.
> > >>>>> Best prevention is if people would make sure to use the same
> > >>>>> conventions.
> > >>>>> We also have a checkstyle which monitors important issues such
> > >>>>> as
> > >>>>> trailing
> > >>>>> white spaces, localization, etc.
> > >>>>>
> > >>>>
> > >>>> But how do you prevent this in future, not all working in same
> > >>>> editor
> > >>>> nor same styles.
> > >>>> You can say that once in a while you perform cross over auto
> > >>>> re-format...
> > >>>> I am not native Java programmer but this sounds very strange
> > >>>> thing
> > >>>> to
> > >>>> do, I don't think I know of any project that does that.
> > >>>>
> > >>>> The main problem is that people commit stuff they don't touch
> > >>>> due
> > >>>> to
> > >>>> their editor behavior, which tread the whole source as if it was
> > >>>> at
> > >>>> its disposal, while cation should be taken not to modify extra
> > >>>> stuff.
> > >>>>
> > >>>> So maybe just to reject patches that touches lines which are not
> > >>>> belong to the patch it-self.
> > >>>>
> > >>>> Alon
> > >>>
> > >>> I'm fine with rejecting patches with irrelevant changes.
> > >>> Still sometimes you get new files and this repeats itself.
> > >>> The whole point of a convention is that people keep it.
> > >>> Most major IDEs today can use the same formatting XML we now
> > >>> have.
> > >>> So it's really a matter of self-discipline.
> > >>>
> > >>
> > >> OK, I suggest we start rejecting patches with irrelevant changes,
> > >> and
> > >> placing these irrelevant changes in their own patch to be
> > >> relevant.
> > >>
> > >> I don't think that we can enforce XML formatting for all editors
> > >> out
> > >> there... unless there is a cli utility to reformat before commit,
> > >> or
> > >> even do this at gerrit side, we should be somewhat flexible.
> > >>
> > >> But these are only my two cents.
> > >>
> > >> Alon
> > > 
> > > Thanks to Ofri we can now both automate it and monitor it using
> > > http://maven-java-formatter-plugin.googlecode.com/svn/site/0.3.1/examples.html.
> > > 
> > > We should be able to add it to the root pom and make sure it won't
> > > happen again.
> > 
> > From a quick look this plugin looks like formatted and not
> > format-validator, if this is the case it is less useful as we can't
> > add
> > a jenkins job to monitor the expected formatting.
> > 
> > I think that we should clean the formatting (once again...) in our
> > code
> > base only after we'll have a valid way to enforce it, otherwise we
> > are
> > going to have the same thread every few months (we already had it
> > twice
> > or more) and we all hate this massive formatting patches that comes
> > after the thread...
> > 
> > Livnat
> > 
> 
> Livnat,
> it's easy enough to have a Jenkins job running this plugin.

Isn't Jenkins too late in the game for checks of incoming code? IIRC
there do exist pre-commit hooks for gerrit that run pylint/pyflakes on
python files, that should IMO be the very place to check Java coding
style, too.

David

> Then git status will tell you if something changed, and if so
> you email the changes to patch owner (and nack the patch). We
> had similar jobs in WPF era and it's quite simple to handle.
> So I see no reason why not to start it now. The sooner we start,
> less noise and unneeded code changes will be added.
> 
> better
> _______________________________________________
> 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 eedri at redhat.com  Fri Jan  4 15:39:52 2013
From: eedri at redhat.com (Eyal Edri)
Date: Fri, 4 Jan 2013 10:39:52 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <1357310233.3532.50.camel@dhcp-29-7.brq.redhat.com>
Message-ID: <1385442776.2768400.1357313992851.JavaMail.root@redhat.com>



----- Original Message -----
> From: "David Ja?a" <djasa at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, January 4, 2013 4:37:13 PM
> Subject: Re: [Engine-devel] Java code formatting
> 
> Doron Fediuck p??e v St 02. 01. 2013 v 03:24 -0500:
> > 
> > ----- Original Message -----
> > > From: "Livnat Peer" <lpeer at redhat.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, January 1, 2013 5:58:15 PM
> > > Subject: Re: [Engine-devel] Java code formatting
> > > 
> > > On 01/01/2013 05:39 PM, Doron Fediuck wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > >> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > >> Sent: Tuesday, January 1, 2013 5:05:09 PM
> > > >> Subject: Re: [Engine-devel] Java code formatting
> > > >>
> > > >>
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > >>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > >>> Sent: Tuesday, January 1, 2013 5:00:20 PM
> > > >>> Subject: Re: [Engine-devel] Java code formatting
> > > >>>
> > > >>>
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > >>>> Sent: Tuesday, January 1, 2013 4:53:49 PM
> > > >>>> Subject: Re: [Engine-devel] Java code formatting
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> ----- Original Message -----
> > > >>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > >>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > >>>>> Sent: Tuesday, January 1, 2013 4:48:22 PM
> > > >>>>> Subject: Re: [Engine-devel] Java code formatting
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> ----- Original Message -----
> > > >>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > >>>>>> Sent: Tuesday, January 1, 2013 4:33:20 PM
> > > >>>>>> Subject: Re: [Engine-devel] Java code formatting
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> ----- Original Message -----
> > > >>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > >>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > >>>>>>> Sent: Tuesday, January 1, 2013 4:28:15 PM
> > > >>>>>>> Subject: Re: [Engine-devel] Java code formatting
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> ----- Original Message -----
> > > >>>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > >>>>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > >>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > >>>>>>>> Sent: Tuesday, January 1, 2013 4:17:18 PM
> > > >>>>>>>> Subject: Re: [Engine-devel] Java code formatting
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> ----- Original Message -----
> > > >>>>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > >>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> > > >>>>>>>>> Sent: Tuesday, January 1, 2013 4:07:53 PM
> > > >>>>>>>>> Subject: [Engine-devel] Java code formatting
> > > >>>>>>>>>
> > > >>>>>>>>> Hi,
> > > >>>>>>>>> Recently I saw many patches with multiple code
> > > >>>>>>>>> re-formatting.
> > > >>>>>>>>> When looking into it, we saw that many people didn't
> > > >>>>>>>>> use
> > > >>>>>>>>> the
> > > >>>>>>>>> project
> > > >>>>>>>>> policy, and now we have many files with bad formatting.
> > > >>>>>>>>>
> > > >>>>>>>>> So I just posted a big ugly fix for this[1], and
> > > >>>>>>>>> hopefully
> > > >>>>>>>>> if
> > > >>>>>>>>> accepted
> > > >>>>>>>>> people should start using the right conventions and
> > > >>>>>>>>> reduce
> > > >>>>>>>>> the
> > > >>>>>>>>> amount
> > > >>>>>>>>> of non-relevant changes we see in the patches.
> > > >>>>>>>>>
> > > >>>>>>>>> I'm aware of the fact that this may create some issues
> > > >>>>>>>>> when
> > > >>>>>>>>> porting
> > > >>>>>>>>> patches, but better sooner than later.
> > > >>>>>>>>> Doron.
> > > >>>>>>>>>
> > > >>>>>>>>> [1] http://gerrit.ovirt.org/#/c/10541/1
> > > >>>>>>>>
> > > >>>>>>>> Hi,
> > > >>>>>>>>
> > > >>>>>>>> These automatic conversions are not better than current
> > > >>>>>>>> state,
> > > >>>>>>>> also
> > > >>>>>>>> I
> > > >>>>>>>> don't think that this is that important. If you want
> > > >>>>>>>> machine
> > > >>>>>>>> written
> > > >>>>>>>> code, then also provide commit hook to reformat
> > > >>>>>>>> anything,
> > > >>>>>>>> and
> > > >>>>>>>> probably machines to read it.
> > > >>>>>>>>
> > > >>>>>>>> I, personally, think that this change over the sources I
> > > >>>>>>>> manage
> > > >>>>>>>> did
> > > >>>>>>>> not do any good.
> > > >>>>>>>>
> > > >>>>>>>> Regards,
> > > >>>>>>>> Alon
> > > >>>>>>>
> > > >>>>>>> Alon,
> > > >>>>>>> there's a formatting convention for the project set long
> > > >>>>>>> ago.
> > > >>>>>>> If you feel it needs to be fixed, go ahead and suggest a
> > > >>>>>>> fix
> > > >>>>>>> for
> > > >>>>>>> the xml.
> > > >>>>>>> Otherwise we end up in the current chaos, where every 2nd
> > > >>>>>>> or
> > > >>>>>>> 3rd
> > > >>>>>>> patch carries unneeded changes.
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>> What do you mean unneeded changes? how do you prevent this
> > > >>>>>> in
> > > >>>>>> future?
> > > >>>>>>
> > > >>>>>> Alon
> > > >>>>>
> > > >>>>> Unneeded changes is when you get one line of code fixed due
> > > >>>>> to
> > > >>>>> a
> > > >>>>> bug,
> > > >>>>> and many others re-indented.
> > > >>>>> Best prevention is if people would make sure to use the
> > > >>>>> same
> > > >>>>> conventions.
> > > >>>>> We also have a checkstyle which monitors important issues
> > > >>>>> such
> > > >>>>> as
> > > >>>>> trailing
> > > >>>>> white spaces, localization, etc.
> > > >>>>>
> > > >>>>
> > > >>>> But how do you prevent this in future, not all working in
> > > >>>> same
> > > >>>> editor
> > > >>>> nor same styles.
> > > >>>> You can say that once in a while you perform cross over auto
> > > >>>> re-format...
> > > >>>> I am not native Java programmer but this sounds very strange
> > > >>>> thing
> > > >>>> to
> > > >>>> do, I don't think I know of any project that does that.
> > > >>>>
> > > >>>> The main problem is that people commit stuff they don't
> > > >>>> touch
> > > >>>> due
> > > >>>> to
> > > >>>> their editor behavior, which tread the whole source as if it
> > > >>>> was
> > > >>>> at
> > > >>>> its disposal, while cation should be taken not to modify
> > > >>>> extra
> > > >>>> stuff.
> > > >>>>
> > > >>>> So maybe just to reject patches that touches lines which are
> > > >>>> not
> > > >>>> belong to the patch it-self.
> > > >>>>
> > > >>>> Alon
> > > >>>
> > > >>> I'm fine with rejecting patches with irrelevant changes.
> > > >>> Still sometimes you get new files and this repeats itself.
> > > >>> The whole point of a convention is that people keep it.
> > > >>> Most major IDEs today can use the same formatting XML we now
> > > >>> have.
> > > >>> So it's really a matter of self-discipline.
> > > >>>
> > > >>
> > > >> OK, I suggest we start rejecting patches with irrelevant
> > > >> changes,
> > > >> and
> > > >> placing these irrelevant changes in their own patch to be
> > > >> relevant.
> > > >>
> > > >> I don't think that we can enforce XML formatting for all
> > > >> editors
> > > >> out
> > > >> there... unless there is a cli utility to reformat before
> > > >> commit,
> > > >> or
> > > >> even do this at gerrit side, we should be somewhat flexible.
> > > >>
> > > >> But these are only my two cents.
> > > >>
> > > >> Alon
> > > > 
> > > > Thanks to Ofri we can now both automate it and monitor it using
> > > > http://maven-java-formatter-plugin.googlecode.com/svn/site/0.3.1/examples.html.
> > > > 
> > > > We should be able to add it to the root pom and make sure it
> > > > won't
> > > > happen again.
> > > 
> > > From a quick look this plugin looks like formatted and not
> > > format-validator, if this is the case it is less useful as we
> > > can't
> > > add
> > > a jenkins job to monitor the expected formatting.
> > > 
> > > I think that we should clean the formatting (once again...) in
> > > our
> > > code
> > > base only after we'll have a valid way to enforce it, otherwise
> > > we
> > > are
> > > going to have the same thread every few months (we already had it
> > > twice
> > > or more) and we all hate this massive formatting patches that
> > > comes
> > > after the thread...
> > > 
> > > Livnat
> > > 
> > 
> > Livnat,
> > it's easy enough to have a Jenkins job running this plugin.
> 
> Isn't Jenkins too late in the game for checks of incoming code? IIRC
> there do exist pre-commit hooks for gerrit that run pylint/pyflakes
> on
> python files, that should IMO be the very place to check Java coding
> style, too.

if the jenkins jobs will run per gerrit patch and not per commit, (it's possible to run it via jenkins, like run other jobs per patch).
then it's not too late, and less messy than defining specific hooks for it.

Eyal.

> 
> David
> 
> > Then git status will tell you if something changed, and if so
> > you email the changes to patch owner (and nack the patch). We
> > had similar jobs in WPF era and it's quite simple to handle.
> > So I see no reason why not to start it now. The sooner we start,
> > less noise and unneeded code changes will be added.
> > 
> > better
> > _______________________________________________
> > 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 dfediuck at redhat.com  Sun Jan  6 14:30:23 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 6 Jan 2013 09:30:23 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <1385442776.2768400.1357313992851.JavaMail.root@redhat.com>
Message-ID: <1931536635.82860.1357482623740.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, January 4, 2013 5:39:52 PM
> Subject: Re: [Engine-devel] Java code formatting
> 
> 
> 
> ----- Original Message -----
> > From: "David Ja?a" <djasa at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, January 4, 2013 4:37:13 PM
> > Subject: Re: [Engine-devel] Java code formatting
> > 
> > Doron Fediuck p??e v St 02. 01. 2013 v 03:24 -0500:
> > > 
> > > ----- Original Message -----
> > > > From: "Livnat Peer" <lpeer at redhat.com>
> > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Tuesday, January 1, 2013 5:58:15 PM
> > > > Subject: Re: [Engine-devel] Java code formatting
> > > > 
> > > > On 01/01/2013 05:39 PM, Doron Fediuck wrote:
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > >> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > >> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > >> Sent: Tuesday, January 1, 2013 5:05:09 PM
> > > > >> Subject: Re: [Engine-devel] Java code formatting
> > > > >>
> > > > >>
> > > > >>
> > > > >> ----- Original Message -----
> > > > >>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > >>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > >>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > >>> Sent: Tuesday, January 1, 2013 5:00:20 PM
> > > > >>> Subject: Re: [Engine-devel] Java code formatting
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> ----- Original Message -----
> > > > >>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > >>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > >>>> Sent: Tuesday, January 1, 2013 4:53:49 PM
> > > > >>>> Subject: Re: [Engine-devel] Java code formatting
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> ----- Original Message -----
> > > > >>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > >>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > >>>>> Sent: Tuesday, January 1, 2013 4:48:22 PM
> > > > >>>>> Subject: Re: [Engine-devel] Java code formatting
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> ----- Original Message -----
> > > > >>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > >>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > >>>>>> Sent: Tuesday, January 1, 2013 4:33:20 PM
> > > > >>>>>> Subject: Re: [Engine-devel] Java code formatting
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> ----- Original Message -----
> > > > >>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > >>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > >>>>>>> Sent: Tuesday, January 1, 2013 4:28:15 PM
> > > > >>>>>>> Subject: Re: [Engine-devel] Java code formatting
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> ----- Original Message -----
> > > > >>>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > >>>>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > >>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > >>>>>>>> Sent: Tuesday, January 1, 2013 4:17:18 PM
> > > > >>>>>>>> Subject: Re: [Engine-devel] Java code formatting
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> ----- Original Message -----
> > > > >>>>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > >>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> > > > >>>>>>>>> Sent: Tuesday, January 1, 2013 4:07:53 PM
> > > > >>>>>>>>> Subject: [Engine-devel] Java code formatting
> > > > >>>>>>>>>
> > > > >>>>>>>>> Hi,
> > > > >>>>>>>>> Recently I saw many patches with multiple code
> > > > >>>>>>>>> re-formatting.
> > > > >>>>>>>>> When looking into it, we saw that many people didn't
> > > > >>>>>>>>> use
> > > > >>>>>>>>> the
> > > > >>>>>>>>> project
> > > > >>>>>>>>> policy, and now we have many files with bad
> > > > >>>>>>>>> formatting.
> > > > >>>>>>>>>
> > > > >>>>>>>>> So I just posted a big ugly fix for this[1], and
> > > > >>>>>>>>> hopefully
> > > > >>>>>>>>> if
> > > > >>>>>>>>> accepted
> > > > >>>>>>>>> people should start using the right conventions and
> > > > >>>>>>>>> reduce
> > > > >>>>>>>>> the
> > > > >>>>>>>>> amount
> > > > >>>>>>>>> of non-relevant changes we see in the patches.
> > > > >>>>>>>>>
> > > > >>>>>>>>> I'm aware of the fact that this may create some
> > > > >>>>>>>>> issues
> > > > >>>>>>>>> when
> > > > >>>>>>>>> porting
> > > > >>>>>>>>> patches, but better sooner than later.
> > > > >>>>>>>>> Doron.
> > > > >>>>>>>>>
> > > > >>>>>>>>> [1] http://gerrit.ovirt.org/#/c/10541/1
> > > > >>>>>>>>
> > > > >>>>>>>> Hi,
> > > > >>>>>>>>
> > > > >>>>>>>> These automatic conversions are not better than
> > > > >>>>>>>> current
> > > > >>>>>>>> state,
> > > > >>>>>>>> also
> > > > >>>>>>>> I
> > > > >>>>>>>> don't think that this is that important. If you want
> > > > >>>>>>>> machine
> > > > >>>>>>>> written
> > > > >>>>>>>> code, then also provide commit hook to reformat
> > > > >>>>>>>> anything,
> > > > >>>>>>>> and
> > > > >>>>>>>> probably machines to read it.
> > > > >>>>>>>>
> > > > >>>>>>>> I, personally, think that this change over the sources
> > > > >>>>>>>> I
> > > > >>>>>>>> manage
> > > > >>>>>>>> did
> > > > >>>>>>>> not do any good.
> > > > >>>>>>>>
> > > > >>>>>>>> Regards,
> > > > >>>>>>>> Alon
> > > > >>>>>>>
> > > > >>>>>>> Alon,
> > > > >>>>>>> there's a formatting convention for the project set
> > > > >>>>>>> long
> > > > >>>>>>> ago.
> > > > >>>>>>> If you feel it needs to be fixed, go ahead and suggest
> > > > >>>>>>> a
> > > > >>>>>>> fix
> > > > >>>>>>> for
> > > > >>>>>>> the xml.
> > > > >>>>>>> Otherwise we end up in the current chaos, where every
> > > > >>>>>>> 2nd
> > > > >>>>>>> or
> > > > >>>>>>> 3rd
> > > > >>>>>>> patch carries unneeded changes.
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>> What do you mean unneeded changes? how do you prevent
> > > > >>>>>> this
> > > > >>>>>> in
> > > > >>>>>> future?
> > > > >>>>>>
> > > > >>>>>> Alon
> > > > >>>>>
> > > > >>>>> Unneeded changes is when you get one line of code fixed
> > > > >>>>> due
> > > > >>>>> to
> > > > >>>>> a
> > > > >>>>> bug,
> > > > >>>>> and many others re-indented.
> > > > >>>>> Best prevention is if people would make sure to use the
> > > > >>>>> same
> > > > >>>>> conventions.
> > > > >>>>> We also have a checkstyle which monitors important issues
> > > > >>>>> such
> > > > >>>>> as
> > > > >>>>> trailing
> > > > >>>>> white spaces, localization, etc.
> > > > >>>>>
> > > > >>>>
> > > > >>>> But how do you prevent this in future, not all working in
> > > > >>>> same
> > > > >>>> editor
> > > > >>>> nor same styles.
> > > > >>>> You can say that once in a while you perform cross over
> > > > >>>> auto
> > > > >>>> re-format...
> > > > >>>> I am not native Java programmer but this sounds very
> > > > >>>> strange
> > > > >>>> thing
> > > > >>>> to
> > > > >>>> do, I don't think I know of any project that does that.
> > > > >>>>
> > > > >>>> The main problem is that people commit stuff they don't
> > > > >>>> touch
> > > > >>>> due
> > > > >>>> to
> > > > >>>> their editor behavior, which tread the whole source as if
> > > > >>>> it
> > > > >>>> was
> > > > >>>> at
> > > > >>>> its disposal, while cation should be taken not to modify
> > > > >>>> extra
> > > > >>>> stuff.
> > > > >>>>
> > > > >>>> So maybe just to reject patches that touches lines which
> > > > >>>> are
> > > > >>>> not
> > > > >>>> belong to the patch it-self.
> > > > >>>>
> > > > >>>> Alon
> > > > >>>
> > > > >>> I'm fine with rejecting patches with irrelevant changes.
> > > > >>> Still sometimes you get new files and this repeats itself.
> > > > >>> The whole point of a convention is that people keep it.
> > > > >>> Most major IDEs today can use the same formatting XML we
> > > > >>> now
> > > > >>> have.
> > > > >>> So it's really a matter of self-discipline.
> > > > >>>
> > > > >>
> > > > >> OK, I suggest we start rejecting patches with irrelevant
> > > > >> changes,
> > > > >> and
> > > > >> placing these irrelevant changes in their own patch to be
> > > > >> relevant.
> > > > >>
> > > > >> I don't think that we can enforce XML formatting for all
> > > > >> editors
> > > > >> out
> > > > >> there... unless there is a cli utility to reformat before
> > > > >> commit,
> > > > >> or
> > > > >> even do this at gerrit side, we should be somewhat flexible.
> > > > >>
> > > > >> But these are only my two cents.
> > > > >>
> > > > >> Alon
> > > > > 
> > > > > Thanks to Ofri we can now both automate it and monitor it
> > > > > using
> > > > > http://maven-java-formatter-plugin.googlecode.com/svn/site/0.3.1/examples.html.
> > > > > 
> > > > > We should be able to add it to the root pom and make sure it
> > > > > won't
> > > > > happen again.
> > > > 
> > > > From a quick look this plugin looks like formatted and not
> > > > format-validator, if this is the case it is less useful as we
> > > > can't
> > > > add
> > > > a jenkins job to monitor the expected formatting.
> > > > 
> > > > I think that we should clean the formatting (once again...) in
> > > > our
> > > > code
> > > > base only after we'll have a valid way to enforce it, otherwise
> > > > we
> > > > are
> > > > going to have the same thread every few months (we already had
> > > > it
> > > > twice
> > > > or more) and we all hate this massive formatting patches that
> > > > comes
> > > > after the thread...
> > > > 
> > > > Livnat
> > > > 
> > > 
> > > Livnat,
> > > it's easy enough to have a Jenkins job running this plugin.
> > 
> > Isn't Jenkins too late in the game for checks of incoming code?
> > IIRC
> > there do exist pre-commit hooks for gerrit that run pylint/pyflakes
> > on
> > python files, that should IMO be the very place to check Java
> > coding
> > style, too.
> 
> if the jenkins jobs will run per gerrit patch and not per commit,
> (it's possible to run it via jenkins, like run other jobs per
> patch).
> then it's not too late, and less messy than defining specific hooks
> for it.
> 
> Eyal.
> 

Right, we actually had something similar in the past
while .NET was still around...

> > 
> > David
> > 
> > > Then git status will tell you if something changed, and if so
> > > you email the changes to patch owner (and nack the patch). We
> > > had similar jobs in WPF era and it's quite simple to handle.
> > > So I see no reason why not to start it now. The sooner we start,
> > > less noise and unneeded code changes will be added.
> > > 
> > > better
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > --
> > 
> > David Ja?a, RHCE
> > 


From yzaslavs at redhat.com  Mon Jan  7 01:12:55 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 6 Jan 2013 20:12:55 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <1931536635.82860.1357482623740.JavaMail.root@redhat.com>
Message-ID: <1129634922.112963.1357521175724.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Eyal Edri" <eedri at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, January 6, 2013 4:30:23 PM
> Subject: Re: [Engine-devel] Java code formatting
> 
> 
> ----- Original Message -----
> > From: "Eyal Edri" <eedri at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, January 4, 2013 5:39:52 PM
> > Subject: Re: [Engine-devel] Java code formatting
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "David Ja?a" <djasa at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Friday, January 4, 2013 4:37:13 PM
> > > Subject: Re: [Engine-devel] Java code formatting
> > > 
> > > Doron Fediuck p??e v St 02. 01. 2013 v 03:24 -0500:
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Livnat Peer" <lpeer at redhat.com>
> > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Tuesday, January 1, 2013 5:58:15 PM
> > > > > Subject: Re: [Engine-devel] Java code formatting
> > > > > 
> > > > > On 01/01/2013 05:39 PM, Doron Fediuck wrote:
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > >> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > >> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > >> Sent: Tuesday, January 1, 2013 5:05:09 PM
> > > > > >> Subject: Re: [Engine-devel] Java code formatting
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> ----- Original Message -----
> > > > > >>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > >>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > >>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > >>> Sent: Tuesday, January 1, 2013 5:00:20 PM
> > > > > >>> Subject: Re: [Engine-devel] Java code formatting
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> ----- Original Message -----
> > > > > >>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > >>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > >>>> Sent: Tuesday, January 1, 2013 4:53:49 PM
> > > > > >>>> Subject: Re: [Engine-devel] Java code formatting
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> ----- Original Message -----
> > > > > >>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > >>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > >>>>> Sent: Tuesday, January 1, 2013 4:48:22 PM
> > > > > >>>>> Subject: Re: [Engine-devel] Java code formatting
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> ----- Original Message -----
> > > > > >>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > >>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > >>>>>> Sent: Tuesday, January 1, 2013 4:33:20 PM
> > > > > >>>>>> Subject: Re: [Engine-devel] Java code formatting
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>> ----- Original Message -----
> > > > > >>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > >>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > >>>>>>> Sent: Tuesday, January 1, 2013 4:28:15 PM
> > > > > >>>>>>> Subject: Re: [Engine-devel] Java code formatting
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>> ----- Original Message -----
> > > > > >>>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > >>>>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > >>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > >>>>>>>> Sent: Tuesday, January 1, 2013 4:17:18 PM
> > > > > >>>>>>>> Subject: Re: [Engine-devel] Java code formatting
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> ----- Original Message -----
> > > > > >>>>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > >>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > >>>>>>>>> Sent: Tuesday, January 1, 2013 4:07:53 PM
> > > > > >>>>>>>>> Subject: [Engine-devel] Java code formatting
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Hi,
> > > > > >>>>>>>>> Recently I saw many patches with multiple code
> > > > > >>>>>>>>> re-formatting.
> > > > > >>>>>>>>> When looking into it, we saw that many people
> > > > > >>>>>>>>> didn't
> > > > > >>>>>>>>> use
> > > > > >>>>>>>>> the
> > > > > >>>>>>>>> project
> > > > > >>>>>>>>> policy, and now we have many files with bad
> > > > > >>>>>>>>> formatting.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> So I just posted a big ugly fix for this[1], and
> > > > > >>>>>>>>> hopefully
> > > > > >>>>>>>>> if
> > > > > >>>>>>>>> accepted
> > > > > >>>>>>>>> people should start using the right conventions and
> > > > > >>>>>>>>> reduce
> > > > > >>>>>>>>> the
> > > > > >>>>>>>>> amount
> > > > > >>>>>>>>> of non-relevant changes we see in the patches.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> I'm aware of the fact that this may create some
> > > > > >>>>>>>>> issues
> > > > > >>>>>>>>> when
> > > > > >>>>>>>>> porting
> > > > > >>>>>>>>> patches, but better sooner than later.
> > > > > >>>>>>>>> Doron.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> [1] http://gerrit.ovirt.org/#/c/10541/1
> > > > > >>>>>>>>
> > > > > >>>>>>>> Hi,
> > > > > >>>>>>>>
> > > > > >>>>>>>> These automatic conversions are not better than
> > > > > >>>>>>>> current
> > > > > >>>>>>>> state,
> > > > > >>>>>>>> also
> > > > > >>>>>>>> I
> > > > > >>>>>>>> don't think that this is that important. If you want
> > > > > >>>>>>>> machine
> > > > > >>>>>>>> written
> > > > > >>>>>>>> code, then also provide commit hook to reformat
> > > > > >>>>>>>> anything,
> > > > > >>>>>>>> and
> > > > > >>>>>>>> probably machines to read it.
> > > > > >>>>>>>>
> > > > > >>>>>>>> I, personally, think that this change over the
> > > > > >>>>>>>> sources
> > > > > >>>>>>>> I
> > > > > >>>>>>>> manage
> > > > > >>>>>>>> did
> > > > > >>>>>>>> not do any good.
> > > > > >>>>>>>>
> > > > > >>>>>>>> Regards,
> > > > > >>>>>>>> Alon
> > > > > >>>>>>>
> > > > > >>>>>>> Alon,
> > > > > >>>>>>> there's a formatting convention for the project set
> > > > > >>>>>>> long
> > > > > >>>>>>> ago.
> > > > > >>>>>>> If you feel it needs to be fixed, go ahead and
> > > > > >>>>>>> suggest
> > > > > >>>>>>> a
> > > > > >>>>>>> fix
> > > > > >>>>>>> for
> > > > > >>>>>>> the xml.
> > > > > >>>>>>> Otherwise we end up in the current chaos, where every
> > > > > >>>>>>> 2nd
> > > > > >>>>>>> or
> > > > > >>>>>>> 3rd
> > > > > >>>>>>> patch carries unneeded changes.
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>> What do you mean unneeded changes? how do you prevent
> > > > > >>>>>> this
> > > > > >>>>>> in
> > > > > >>>>>> future?
> > > > > >>>>>>
> > > > > >>>>>> Alon
> > > > > >>>>>
> > > > > >>>>> Unneeded changes is when you get one line of code fixed
> > > > > >>>>> due
> > > > > >>>>> to
> > > > > >>>>> a
> > > > > >>>>> bug,
> > > > > >>>>> and many others re-indented.
> > > > > >>>>> Best prevention is if people would make sure to use the
> > > > > >>>>> same
> > > > > >>>>> conventions.
> > > > > >>>>> We also have a checkstyle which monitors important
> > > > > >>>>> issues
> > > > > >>>>> such
> > > > > >>>>> as
> > > > > >>>>> trailing
> > > > > >>>>> white spaces, localization, etc.
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>> But how do you prevent this in future, not all working
> > > > > >>>> in
> > > > > >>>> same
> > > > > >>>> editor
> > > > > >>>> nor same styles.
> > > > > >>>> You can say that once in a while you perform cross over
> > > > > >>>> auto
> > > > > >>>> re-format...
> > > > > >>>> I am not native Java programmer but this sounds very
> > > > > >>>> strange
> > > > > >>>> thing
> > > > > >>>> to
> > > > > >>>> do, I don't think I know of any project that does that.
> > > > > >>>>
> > > > > >>>> The main problem is that people commit stuff they don't
> > > > > >>>> touch
> > > > > >>>> due
> > > > > >>>> to
> > > > > >>>> their editor behavior, which tread the whole source as
> > > > > >>>> if
> > > > > >>>> it
> > > > > >>>> was
> > > > > >>>> at
> > > > > >>>> its disposal, while cation should be taken not to modify
> > > > > >>>> extra
> > > > > >>>> stuff.
> > > > > >>>>
> > > > > >>>> So maybe just to reject patches that touches lines which
> > > > > >>>> are
> > > > > >>>> not
> > > > > >>>> belong to the patch it-self.
> > > > > >>>>
> > > > > >>>> Alon
> > > > > >>>
> > > > > >>> I'm fine with rejecting patches with irrelevant changes.
> > > > > >>> Still sometimes you get new files and this repeats
> > > > > >>> itself.
> > > > > >>> The whole point of a convention is that people keep it.
> > > > > >>> Most major IDEs today can use the same formatting XML we
> > > > > >>> now
> > > > > >>> have.
> > > > > >>> So it's really a matter of self-discipline.
> > > > > >>>
> > > > > >>
> > > > > >> OK, I suggest we start rejecting patches with irrelevant
> > > > > >> changes,
> > > > > >> and
> > > > > >> placing these irrelevant changes in their own patch to be
> > > > > >> relevant.
> > > > > >>
> > > > > >> I don't think that we can enforce XML formatting for all
> > > > > >> editors
> > > > > >> out
> > > > > >> there... unless there is a cli utility to reformat before
> > > > > >> commit,
> > > > > >> or
> > > > > >> even do this at gerrit side, we should be somewhat
> > > > > >> flexible.
> > > > > >>
> > > > > >> But these are only my two cents.
> > > > > >>
> > > > > >> Alon
> > > > > > 
> > > > > > Thanks to Ofri we can now both automate it and monitor it
> > > > > > using
> > > > > > http://maven-java-formatter-plugin.googlecode.com/svn/site/0.3.1/examples.html.
> > > > > > 
> > > > > > We should be able to add it to the root pom and make sure
> > > > > > it
> > > > > > won't
> > > > > > happen again.
> > > > > 
> > > > > From a quick look this plugin looks like formatted and not
> > > > > format-validator, if this is the case it is less useful as we
> > > > > can't
> > > > > add
> > > > > a jenkins job to monitor the expected formatting.
> > > > > 
> > > > > I think that we should clean the formatting (once again...)
> > > > > in
> > > > > our
> > > > > code
> > > > > base only after we'll have a valid way to enforce it,
> > > > > otherwise
> > > > > we
> > > > > are
> > > > > going to have the same thread every few months (we already
> > > > > had
> > > > > it
> > > > > twice
> > > > > or more) and we all hate this massive formatting patches that
> > > > > comes
> > > > > after the thread...
> > > > > 
> > > > > Livnat
> > > > > 
> > > > 
> > > > Livnat,
> > > > it's easy enough to have a Jenkins job running this plugin.
> > > 
> > > Isn't Jenkins too late in the game for checks of incoming code?
> > > IIRC
> > > there do exist pre-commit hooks for gerrit that run
> > > pylint/pyflakes
> > > on
> > > python files, that should IMO be the very place to check Java
> > > coding
> > > style, too.
> > 
> > if the jenkins jobs will run per gerrit patch and not per commit,
> > (it's possible to run it via jenkins, like run other jobs per
> > patch).
> > then it's not too late, and less messy than defining specific hooks
> > for it.
> > 
> > Eyal.

Sorry for (very) late response - what would be the price (i.e - build time) for running this plugin while performing "mvn clean install" on ovirt-engine?
I know that sometimes people forget to run tests (which is bad) but I do believe (and hope ;) ) they do compile before send patches to gerrit.

> > 
> 
> Right, we actually had something similar in the past
> while .NET was still around...
> 
> > > 
> > > David
> > > 
> > > > Then git status will tell you if something changed, and if so
> > > > you email the changes to patch owner (and nack the patch). We
> > > > had similar jobs in WPF era and it's quite simple to handle.
> > > > So I see no reason why not to start it now. The sooner we
> > > > start,
> > > > less noise and unneeded code changes will be added.
> > > > 
> > > > better
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > > --
> > > 
> > > David Ja?a, RHCE
> > > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From shuming at linux.vnet.ibm.com  Mon Jan  7 08:58:26 2013
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Mon, 07 Jan 2013 16:58:26 +0800
Subject: [Engine-devel] ovirt nightly FC17 public repositories broken?
Message-ID: <50EA8E32.5030809@linux.vnet.ibm.com>

Hi,

Any one was encountering this error message when using yum on ovirt
public repositories?
http://ovirt.org/releases/nightly/rpm/Fedora/17/repodata/primary.xml.gz
<http://ovirt.org/releases/nightly/rpm/Fedora/17/repodata/primary.xml.gz>:
[Errno -1] Metadata file does not match checksum

My vdsm host and engine server was installed with FC17+virt-review, so I
used FC17 nightly releases to update my VDSM and engine packages. After
a bit investigation, I found these issues.


[root at node1-sming ovirt-nightly]# ls -lh *
-rw-r--r--. 1 root root 0 Jan 7 16:47 cachecookie
-rw-r--r--. 1 root root 702K Jan 7 14:22 filelists.xml.gz
-rw-r--r--. 1 root root 132K Jan 7 14:22 other.xml.gz
-rw-r--r--. 1 root root 279K Jan 7 14:22 primary.xml.gz
-rw-r--r--. 1 root root 1.4K Jan 5 14:35 repomd.xml *<---the date was
always Jan 5 different from other files even
http://resources.ovirt.org/releases/nightly**/rpm/Fedora/17/repodata/
showed it was Jan 7, also I tried to use wget to download this file and
got the same thing.**
*
[root at node1-sming ovirt-nightly]# sha1sum other.xml.gz filelists.xml.gz
primary.xml.gz
453559e86950af07c876931f318d1e92ab58f289 other.xml.gz
5318e237c0f4d2ea3d1ec24e82b9f9bbe9d23a31 filelists.xml.gz
e667267d45b576844a5f2cb27ce7bcfb8bb9b4f0 primary.xml.gz

[root at node1-sming ovirt-nightly]# cat repomd.xml |grep open-checksum
<open-checksum
type="sha256">ce6a5243ee81c124d0fe48d103174b93fabe60573e80b5851888298373d3be9e</open-checksum>

<open-checksum
type="sha256">554a301c526d335ca4a7985e7fc7b0374bca8c061ff5addbd164de81996dc5a0</open-checksum>

<open-checksum
type="sha256">be3f9e6860cd9a4ac4f3f5000ad503175e7ac79a43185a778d4ab732c0d8190c</open-checksum>


*Note: These checksum from repmod.xml were quite different from the
result of sha1sum above.*

Any clues here?

-- 
---
?? Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626  Tieline: 9051626 E-mail: shuming at cn.ibm.com or shuming at linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC

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

From lhornyak at redhat.com  Mon Jan  7 17:37:10 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 7 Jan 2013 12:37:10 -0500 (EST)
Subject: [Engine-devel] vdsbroker
In-Reply-To: <1131422584.379204.1357579911177.JavaMail.root@redhat.com>
Message-ID: <1335710062.380546.1357580230281.JavaMail.root@redhat.com>

hi,

Is there any documentation about vdsbroker? Just trying to understand the concepts.

Thx,
Laszlo


From yzaslavs at redhat.com  Mon Jan  7 18:12:02 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 7 Jan 2013 13:12:02 -0500 (EST)
Subject: [Engine-devel] vdsbroker
In-Reply-To: <1335710062.380546.1357580230281.JavaMail.root@redhat.com>
Message-ID: <156742398.681319.1357582322561.JavaMail.root@redhat.com>

What do you need to know?
I'm not familiar with detailed documentation of it, but maybe we can help you on this thread (and share our knowledge with others)

Yair


----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, January 7, 2013 7:37:10 PM
> Subject: [Engine-devel] vdsbroker
> 
> hi,
> 
> Is there any documentation about vdsbroker? Just trying to understand
> the concepts.
> 
> Thx,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From Christopher.Morrissey at netapp.com  Tue Jan  8 14:13:44 2013
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Tue, 8 Jan 2013 14:13:44 +0000
Subject: [Engine-devel] Question about closing UI plugin dialog
Message-ID: <D290AD8432118048947689BA3AE8A9B3094F2A90@SACEXCMBX04-PRD.hq.netapp.com>

Hi All,

I've been working on a plugin for the UI that launches a dialog using the showDialog() API. Our UI is actually contained in a frame inside the dialog and is loaded from a separate server. The only information needed for our UI comes in either through the URL as parameters or from the oVirt REST API. The issue is that once the clicks the OK or Cancel buttons in our UI we need to message to the oVirt UI to close the dialog.

It looks like using the window.postMessage() API would be great for this, but it doesn't work across windows in IE. Would it be possible to change the code that launches the window to open a window that contains a bit of javascript that sets up a listener for closing the dialog and then launches the URL in an iFrame in the window? Of course, if it were in a native GWT dialog this wouldn't be a problem. ;)

-Chris

Chris Morrissey
Software Engineer
NetApp Inc.
919.476.4428




From ecohen at redhat.com  Tue Jan  8 16:00:14 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Tue, 8 Jan 2013 11:00:14 -0500 (EST)
Subject: [Engine-devel] problem when upgrading engine db?
In-Reply-To: <863921959.1551052.1357660672184.JavaMail.root@redhat.com>
Message-ID: <1581227274.1553312.1357660814259.JavaMail.root@redhat.com>

Hi Eli,

When I tried to upgrade my oVirt engine DB (using backend/manager/dbscripts/upgrade.sh) I received the following output:

----
upgrade script detected a change in Config, View or Stored Procedure...
psql:drop_old_uuid_functions.sql:2: ERROR:  cannot drop function uuid_nil() because extension uuid-ossp requires it
HINT:  You can drop extension uuid-ossp instead.
psql:drop_old_uuid_functions.sql:3: ERROR:  cannot drop function uuid_ns_dns() because extension uuid-ossp requires it
HINT:  You can drop extension uuid-ossp instead.
psql:drop_old_uuid_functions.sql:4: ERROR:  cannot drop function uuid_ns_url() because extension uuid-ossp requires it
HINT:  You can drop extension uuid-ossp instead.
psql:drop_old_uuid_functions.sql:5: ERROR:  cannot drop function uuid_ns_oid() because extension uuid-ossp requires it
HINT:  You can drop extension uuid-ossp instead.
psql:drop_old_uuid_functions.sql:6: ERROR:  cannot drop function uuid_ns_x500() because extension uuid-ossp requires it
HINT:  You can drop extension uuid-ossp instead.
psql:drop_old_uuid_functions.sql:7: ERROR:  cannot drop function uuid_generate_v1() because extension uuid-ossp requires it
HINT:  You can drop extension uuid-ossp instead.
psql:drop_old_uuid_functions.sql:8: ERROR:  cannot drop function uuid_generate_v1mc() because extension uuid-ossp requires it
HINT:  You can drop extension uuid-ossp instead.
psql:drop_old_uuid_functions.sql:9: ERROR:  cannot drop function uuid_generate_v3(uuid,text) because extension uuid-ossp requires it
HINT:  You can drop extension uuid-ossp instead.
psql:drop_old_uuid_functions.sql:10: ERROR:  cannot drop function uuid_generate_v4() because extension uuid-ossp requires it
HINT:  You can drop extension uuid-ossp instead.
psql:drop_old_uuid_functions.sql:11: ERROR:  cannot drop function uuid_generate_v5(uuid,text) because extension uuid-ossp requires it
HINT:  You can drop extension uuid-ossp instead.
Running  upgrade sql script upgrade/pre_upgrade/0000_config.sql ...
Running  upgrade sql script upgrade/pre_upgrade/0010_custom.sql ...
Running  upgrade sql script upgrade/pre_upgrade/0020_add_comment_col_to_schema_version.sql ...
Creating views...
Creating stored procedures...
... 
[ regular output continues ] 
...
----

Is that expected?

----
Thanks,
Einav


From lhornyak at redhat.com  Wed Jan  9 10:21:48 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 9 Jan 2013 05:21:48 -0500 (EST)
Subject: [Engine-devel] failing junit tests
In-Reply-To: <356230256.1158852.1357726712454.JavaMail.root@redhat.com>
Message-ID: <402470676.1159171.1357726908308.JavaMail.root@redhat.com>

Hi,

There are some failing junit tests in engine this morning. It is my bad, I am working on it. Sorry for the inconvinience.

Laszlo


From vszocs at redhat.com  Thu Jan 10 00:11:12 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 9 Jan 2013 19:11:12 -0500 (EST)
Subject: [Engine-devel] Question about closing UI plugin dialog
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3094F2A90@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <1570240113.167806.1357776672683.JavaMail.root@redhat.com>

Hi Chris,

current showDialog() implementation uses native browser popup window via window.open() function. UI rendered within such popup window can close the window by itself simply via window.close() function [1].

However, as we're planning to move away from using native browser popup windows and making showDialog() implementation integrate with Web Admin dialog UI infrastructure, there are two possible ways to go:

a) OK/Cancel buttons rendered as part of custom dialog content (as described by Chris)
   - buttons are contained within the iframe content HTML
   - Web Admin will transmit custom dialog ID to iframe, e.g. iframeWindow.postMessage('customDialog123', iframeWindowDomain)
   - within the iframe window, clicking a button would invoke parentWindow.postMessage('close-customDialog123', parentWindowDomain)
   - Web Admin will receive 'close-customDialog123' message and will close the custom dialog

Pros: buttons and content in the same window context
Cons: cross-window communication overhead that relies on window.postMessage()

b) OK/Cancel buttons rendered as part of Web Admin dialog UI (NOT part of custom dialog content)
   - this was my initial idea of implementing custom dialog buttons
   - buttons will be defined via separate argument to showDialog() function, e.g. showDialog(title, contentUrl, width, height, buttons)
     where 'buttons' follow similar concept as 'actionButtonInterface' in addMainTabActionButton() API, e.g. { onClick: function() {...} }
   - closing custom dialog can be done right within the onClick handler function

Pros: no need for window.postMessage() stuff, button definitions are part of UI plugin (JavaScript) code
Cons: buttons and content in different window contexts

Chris, let me know what you think.

Note: window.postMessage() should work in IE8 and above, I've tested [2] in IE8/WinXP/SP3 without any problems. However, [3] mentions that "In IE8, it is possible to use win.postMessage for iframes only", I assume this is what you meant by saying that "it doesn't work across windows in IE"? Not sure if this is still an issue for us when using iframe instead of native browser popup window, but we'll have to investigate..

Regards,
Vojtech

[1] http://stackoverflow.com/a/2076307
[2] http://stevesouders.com/misc/test-postmessage.php
[3] http://javascript.info/tutorial/cross-window-messaging-with-postmessage


----- Original Message -----
From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
To: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org
Cc: "Itamar Heim" <iheim at redhat.com>, "George Costea" <George.Costea at netapp.com>
Sent: Tuesday, January 8, 2013 3:13:44 PM
Subject: Question about closing UI plugin dialog

Hi All,

I've been working on a plugin for the UI that launches a dialog using the showDialog() API. Our UI is actually contained in a frame inside the dialog and is loaded from a separate server. The only information needed for our UI comes in either through the URL as parameters or from the oVirt REST API. The issue is that once the clicks the OK or Cancel buttons in our UI we need to message to the oVirt UI to close the dialog.

It looks like using the window.postMessage() API would be great for this, but it doesn't work across windows in IE. Would it be possible to change the code that launches the window to open a window that contains a bit of javascript that sets up a listener for closing the dialog and then launches the URL in an iFrame in the window? Of course, if it were in a native GWT dialog this wouldn't be a problem. ;)

-Chris

Chris Morrissey
Software Engineer
NetApp Inc.
919.476.4428




From mburns at redhat.com  Thu Jan 10 01:07:58 2013
From: mburns at redhat.com (Mike Burns)
Date: Wed, 09 Jan 2013 20:07:58 -0500
Subject: [Engine-devel] ATTN: Project Maintainers: Code Freeze/Branch/Beta
	Build deadlines
Message-ID: <1357780078.2865.26.camel@beelzebub.mburnsfire.net>

(Sorry for cross posting, trying to ensure I hit all the relevant
maintainers)

If you are the primary maintainer of a sub-project in oVirt, this
message is for you.

At the Weekly oVirt Meeting, the final devel freeze and beta dates were
decided.  

Freeze:  2013-01-14
Beta Post: 2013-01-15

Action items:

* You project should create a new branch in gerrit for the release
* You should create a formal build of your project for the beta post
* Get the formal build of your project into the hands of someone who can
post it [1][2]

These should all be done by EOD on 2013-01-14 (with the exception of
ovirt-node-iso) [3]

Packages that this impacts:

      * mom
      * otopi
      * ovirt-engine
      * ovirt-engine-cli
      * ovirt-engine-sdk
      * ovirt-guest-agent
      * ovirt-host-deploy
      * ovirt-image-uploader
      * ovirt-iso-uploader
      * ovirt-log-collector
      * ovirt-node
      * ovirt-node-iso
      * vdsm

Thanks

Mike Burns

[1] This is only necessary if the package is *not* already in fedora
repos (must be in actual fedora repos, not just updates-testing or koji)
[2] Communicate with mburns, mgoldboi, oschreib to deliver the packages
[3] ovirt-node-iso requires some of the other packages to be available
prior to creating the image.  This image will be created either on
2013-01-14 or 2013-01-15 and posted along with the rest of the Beta.



From Christopher.Morrissey at netapp.com  Thu Jan 10 02:37:04 2013
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Thu, 10 Jan 2013 02:37:04 +0000
Subject: [Engine-devel] Question about closing UI plugin dialog
In-Reply-To: <1570240113.167806.1357776672683.JavaMail.root@redhat.com>
References: <D290AD8432118048947689BA3AE8A9B3094F2A90@SACEXCMBX04-PRD.hq.netapp.com>
	<1570240113.167806.1357776672683.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3094F4FBA@SACEXCMBX04-PRD.hq.netapp.com>


-Chris


> -----Original Message-----
> From: Vojtech Szocs [mailto:vszocs at redhat.com]
> Sent: Wednesday, January 09, 2013 7:11 PM
> To: Morrissey, Christopher
> Cc: Itamar Heim; Costea, George; engine-devel at ovirt.org
> Subject: Re: Question about closing UI plugin dialog
> 
> Hi Chris,
> 
> current showDialog() implementation uses native browser popup window via
> window.open() function. UI rendered within such popup window can close
> the window by itself simply via window.close() function [1].

Ha, of course window.close() will work! Not sure what I was thinking.

> 
> However, as we're planning to move away from using native browser popup
> windows and making showDialog() implementation integrate with Web
> Admin dialog UI infrastructure, there are two possible ways to go:
> 
> a) OK/Cancel buttons rendered as part of custom dialog content (as
> described by Chris)
>    - buttons are contained within the iframe content HTML
>    - Web Admin will transmit custom dialog ID to iframe, e.g.
> iframeWindow.postMessage('customDialog123', iframeWindowDomain)
>    - within the iframe window, clicking a button would invoke
> parentWindow.postMessage('close-customDialog123',
> parentWindowDomain)
>    - Web Admin will receive 'close-customDialog123' message and will close
> the custom dialog
> 
> Pros: buttons and content in the same window context
> Cons: cross-window communication overhead that relies on
> window.postMessage()
> 
> b) OK/Cancel buttons rendered as part of Web Admin dialog UI (NOT part of
> custom dialog content)
>    - this was my initial idea of implementing custom dialog buttons
>    - buttons will be defined via separate argument to showDialog() function,
> e.g. showDialog(title, contentUrl, width, height, buttons)
>      where 'buttons' follow similar concept as 'actionButtonInterface' in
> addMainTabActionButton() API, e.g. { onClick: function() {...} }
>    - closing custom dialog can be done right within the onClick handler function
> 
> Pros: no need for window.postMessage() stuff, button definitions are part of
> UI plugin (JavaScript) code
> Cons: buttons and content in different window contexts
> 

This has a big drawback in that the content often needs to perform actions when the OK button is pressed. This design makes it very difficult and will at least need to use the Window.postMessage() to signal to the content that the dialog is closing. What's worse is that the content may want to stop the window from closing because of an error or keep it open while the actions defined in it are performed (e.g. change the dialog content to a progress bar or something similar). I think it's much better to have the OK and cancel buttons controlled by the content than having the oVirt dialog controlling it.

> Chris, let me know what you think.
> 
> Note: window.postMessage() should work in IE8 and above, I've tested [2] in
> IE8/WinXP/SP3 without any problems. However, [3] mentions that "In IE8, it
> is possible to use win.postMessage for iframes only", I assume this is what
> you meant by saying that "it doesn't work across windows in IE"? Not sure if
> this is still an issue for us when using iframe instead of native browser popup
> window, but we'll have to investigate..

This will not be a problem when we're in an iframe. In fact, that is the only place it will work in IE 8 and 9.

> 
> Regards,
> Vojtech
> 
> [1] http://stackoverflow.com/a/2076307
> [2] http://stevesouders.com/misc/test-postmessage.php
> [3] http://javascript.info/tutorial/cross-window-messaging-with-
> postmessage
> 
> 
> ----- Original Message -----
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org
> Cc: "Itamar Heim" <iheim at redhat.com>, "George Costea"
> <George.Costea at netapp.com>
> Sent: Tuesday, January 8, 2013 3:13:44 PM
> Subject: Question about closing UI plugin dialog
> 
> Hi All,
> 
> I've been working on a plugin for the UI that launches a dialog using the
> showDialog() API. Our UI is actually contained in a frame inside the dialog and
> is loaded from a separate server. The only information needed for our UI
> comes in either through the URL as parameters or from the oVirt REST API.
> The issue is that once the clicks the OK or Cancel buttons in our UI we need
> to message to the oVirt UI to close the dialog.
> 
> It looks like using the window.postMessage() API would be great for this, but
> it doesn't work across windows in IE. Would it be possible to change the code
> that launches the window to open a window that contains a bit of javascript
> that sets up a listener for closing the dialog and then launches the URL in an
> iFrame in the window? Of course, if it were in a native GWT dialog this
> wouldn't be a problem. ;)
> 
> -Chris
> 
> Chris Morrissey
> Software Engineer
> NetApp Inc.
> 919.476.4428
> 


From vszocs at redhat.com  Thu Jan 10 17:29:36 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 10 Jan 2013 12:29:36 -0500 (EST)
Subject: [Engine-devel] Question about closing UI plugin dialog
In-Reply-To: <D290AD8432118048947689BA3AE8A9B3094F4FBA@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <884423855.485787.1357838976859.JavaMail.root@redhat.com>

Hi Chris,

I agree with your point, having OK/Cancel buttons controlled by the content within the same (iframe) window context sounds reasonable. On the other hand, we shouldn't restrict showDialog() API in a way that iframe window *must* provide means (buttons) of closing the dialog, as other UI plugins might just want to add Close button via showDialog() API.

So I think a combination of both options (a+b) can be implemented. If your plugin doesn't want to add Close button via showDialog() API, that's OK, you can have OK/Cancel buttons provided by the iframe window.

> This will not be a problem when we're in an iframe. In fact, that is the only place it will work in IE 8 and 9.

:) besides postMessage(), we can also use a trick with iframe updating its URL hash fragment, and Web Admin monitoring iframe URL hash fragment value. But I'd like to try using postMessage() first.

Regards,
Vojtech


----- Original Message -----
From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
To: "Vojtech Szocs" <vszocs at redhat.com>
Cc: "Itamar Heim" <iheim at redhat.com>, "George Costea" <George.Costea at netapp.com>, engine-devel at ovirt.org
Sent: Thursday, January 10, 2013 3:37:04 AM
Subject: RE: Question about closing UI plugin dialog


-Chris


> -----Original Message-----
> From: Vojtech Szocs [mailto:vszocs at redhat.com]
> Sent: Wednesday, January 09, 2013 7:11 PM
> To: Morrissey, Christopher
> Cc: Itamar Heim; Costea, George; engine-devel at ovirt.org
> Subject: Re: Question about closing UI plugin dialog
> 
> Hi Chris,
> 
> current showDialog() implementation uses native browser popup window via
> window.open() function. UI rendered within such popup window can close
> the window by itself simply via window.close() function [1].

Ha, of course window.close() will work! Not sure what I was thinking.

> 
> However, as we're planning to move away from using native browser popup
> windows and making showDialog() implementation integrate with Web
> Admin dialog UI infrastructure, there are two possible ways to go:
> 
> a) OK/Cancel buttons rendered as part of custom dialog content (as
> described by Chris)
>    - buttons are contained within the iframe content HTML
>    - Web Admin will transmit custom dialog ID to iframe, e.g.
> iframeWindow.postMessage('customDialog123', iframeWindowDomain)
>    - within the iframe window, clicking a button would invoke
> parentWindow.postMessage('close-customDialog123',
> parentWindowDomain)
>    - Web Admin will receive 'close-customDialog123' message and will close
> the custom dialog
> 
> Pros: buttons and content in the same window context
> Cons: cross-window communication overhead that relies on
> window.postMessage()
> 
> b) OK/Cancel buttons rendered as part of Web Admin dialog UI (NOT part of
> custom dialog content)
>    - this was my initial idea of implementing custom dialog buttons
>    - buttons will be defined via separate argument to showDialog() function,
> e.g. showDialog(title, contentUrl, width, height, buttons)
>      where 'buttons' follow similar concept as 'actionButtonInterface' in
> addMainTabActionButton() API, e.g. { onClick: function() {...} }
>    - closing custom dialog can be done right within the onClick handler function
> 
> Pros: no need for window.postMessage() stuff, button definitions are part of
> UI plugin (JavaScript) code
> Cons: buttons and content in different window contexts
> 

This has a big drawback in that the content often needs to perform actions when the OK button is pressed. This design makes it very difficult and will at least need to use the Window.postMessage() to signal to the content that the dialog is closing. What's worse is that the content may want to stop the window from closing because of an error or keep it open while the actions defined in it are performed (e.g. change the dialog content to a progress bar or something similar). I think it's much better to have the OK and cancel buttons controlled by the content than having the oVirt dialog controlling it.

> Chris, let me know what you think.
> 
> Note: window.postMessage() should work in IE8 and above, I've tested [2] in
> IE8/WinXP/SP3 without any problems. However, [3] mentions that "In IE8, it
> is possible to use win.postMessage for iframes only", I assume this is what
> you meant by saying that "it doesn't work across windows in IE"? Not sure if
> this is still an issue for us when using iframe instead of native browser popup
> window, but we'll have to investigate..

This will not be a problem when we're in an iframe. In fact, that is the only place it will work in IE 8 and 9.

> 
> Regards,
> Vojtech
> 
> [1] http://stackoverflow.com/a/2076307
> [2] http://stevesouders.com/misc/test-postmessage.php
> [3] http://javascript.info/tutorial/cross-window-messaging-with-
> postmessage
> 
> 
> ----- Original Message -----
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org
> Cc: "Itamar Heim" <iheim at redhat.com>, "George Costea"
> <George.Costea at netapp.com>
> Sent: Tuesday, January 8, 2013 3:13:44 PM
> Subject: Question about closing UI plugin dialog
> 
> Hi All,
> 
> I've been working on a plugin for the UI that launches a dialog using the
> showDialog() API. Our UI is actually contained in a frame inside the dialog and
> is loaded from a separate server. The only information needed for our UI
> comes in either through the URL as parameters or from the oVirt REST API.
> The issue is that once the clicks the OK or Cancel buttons in our UI we need
> to message to the oVirt UI to close the dialog.
> 
> It looks like using the window.postMessage() API would be great for this, but
> it doesn't work across windows in IE. Would it be possible to change the code
> that launches the window to open a window that contains a bit of javascript
> that sets up a listener for closing the dialog and then launches the URL in an
> iFrame in the window? Of course, if it were in a native GWT dialog this
> wouldn't be a problem. ;)
> 
> -Chris
> 
> Chris Morrissey
> Software Engineer
> NetApp Inc.
> 919.476.4428
> 



From Christopher.Morrissey at netapp.com  Thu Jan 10 17:38:40 2013
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Thu, 10 Jan 2013 17:38:40 +0000
Subject: [Engine-devel] Question about closing UI plugin dialog
In-Reply-To: <884423855.485787.1357838976859.JavaMail.root@redhat.com>
References: <D290AD8432118048947689BA3AE8A9B3094F4FBA@SACEXCMBX04-PRD.hq.netapp.com>
	<884423855.485787.1357838976859.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B3094F5ACD@SACEXCMBX04-PRD.hq.netapp.com>



-Chris


> -----Original Message-----
> From: Vojtech Szocs [mailto:vszocs at redhat.com]
> Sent: Thursday, January 10, 2013 12:30 PM
> To: Morrissey, Christopher
> Cc: Itamar Heim; Costea, George; engine-devel at ovirt.org
> Subject: Re: Question about closing UI plugin dialog
> 
> Hi Chris,
> 
> I agree with your point, having OK/Cancel buttons controlled by the content
> within the same (iframe) window context sounds reasonable. On the other
> hand, we shouldn't restrict showDialog() API in a way that iframe window
> *must* provide means (buttons) of closing the dialog, as other UI plugins
> might just want to add Close button via showDialog() API.
> 
> So I think a combination of both options (a+b) can be implemented. If your
> plugin doesn't want to add Close button via showDialog() API, that's OK, you
> can have OK/Cancel buttons provided by the iframe window.

That sounds like a good plan.

> 
> > This will not be a problem when we're in an iframe. In fact, that is the only
> place it will work in IE 8 and 9.
> 
> :) besides postMessage(), we can also use a trick with iframe updating its URL
> hash fragment, and Web Admin monitoring iframe URL hash fragment value.
> But I'd like to try using postMessage() first.
> 

Yes, that is an option but I also agree that using postMessage() is cleaner and hopefully will get us what we need.

> Regards,
> Vojtech
> 
> 
> ----- Original Message -----
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "George Costea"
> <George.Costea at netapp.com>, engine-devel at ovirt.org
> Sent: Thursday, January 10, 2013 3:37:04 AM
> Subject: RE: Question about closing UI plugin dialog
> 
> 
> -Chris
> 
> 
> > -----Original Message-----
> > From: Vojtech Szocs [mailto:vszocs at redhat.com]
> > Sent: Wednesday, January 09, 2013 7:11 PM
> > To: Morrissey, Christopher
> > Cc: Itamar Heim; Costea, George; engine-devel at ovirt.org
> > Subject: Re: Question about closing UI plugin dialog
> >
> > Hi Chris,
> >
> > current showDialog() implementation uses native browser popup window
> > via
> > window.open() function. UI rendered within such popup window can close
> > the window by itself simply via window.close() function [1].
> 
> Ha, of course window.close() will work! Not sure what I was thinking.
> 
> >
> > However, as we're planning to move away from using native browser
> > popup windows and making showDialog() implementation integrate with
> > Web Admin dialog UI infrastructure, there are two possible ways to go:
> >
> > a) OK/Cancel buttons rendered as part of custom dialog content (as
> > described by Chris)
> >    - buttons are contained within the iframe content HTML
> >    - Web Admin will transmit custom dialog ID to iframe, e.g.
> > iframeWindow.postMessage('customDialog123', iframeWindowDomain)
> >    - within the iframe window, clicking a button would invoke
> > parentWindow.postMessage('close-customDialog123',
> > parentWindowDomain)
> >    - Web Admin will receive 'close-customDialog123' message and will
> > close the custom dialog
> >
> > Pros: buttons and content in the same window context
> > Cons: cross-window communication overhead that relies on
> > window.postMessage()
> >
> > b) OK/Cancel buttons rendered as part of Web Admin dialog UI (NOT part
> > of custom dialog content)
> >    - this was my initial idea of implementing custom dialog buttons
> >    - buttons will be defined via separate argument to showDialog()
> > function, e.g. showDialog(title, contentUrl, width, height, buttons)
> >      where 'buttons' follow similar concept as 'actionButtonInterface'
> > in
> > addMainTabActionButton() API, e.g. { onClick: function() {...} }
> >    - closing custom dialog can be done right within the onClick
> > handler function
> >
> > Pros: no need for window.postMessage() stuff, button definitions are
> > part of UI plugin (JavaScript) code
> > Cons: buttons and content in different window contexts
> >
> 
> This has a big drawback in that the content often needs to perform actions
> when the OK button is pressed. This design makes it very difficult and will at
> least need to use the Window.postMessage() to signal to the content that
> the dialog is closing. What's worse is that the content may want to stop the
> window from closing because of an error or keep it open while the actions
> defined in it are performed (e.g. change the dialog content to a progress bar
> or something similar). I think it's much better to have the OK and cancel
> buttons controlled by the content than having the oVirt dialog controlling it.
> 
> > Chris, let me know what you think.
> >
> > Note: window.postMessage() should work in IE8 and above, I've tested
> > [2] in
> > IE8/WinXP/SP3 without any problems. However, [3] mentions that "In
> > IE8, it is possible to use win.postMessage for iframes only", I assume
> > this is what you meant by saying that "it doesn't work across windows
> > in IE"? Not sure if this is still an issue for us when using iframe
> > instead of native browser popup window, but we'll have to investigate..
> 
> This will not be a problem when we're in an iframe. In fact, that is the only
> place it will work in IE 8 and 9.
> 
> >
> > Regards,
> > Vojtech
> >
> > [1] http://stackoverflow.com/a/2076307
> > [2] http://stevesouders.com/misc/test-postmessage.php
> > [3] http://javascript.info/tutorial/cross-window-messaging-with-
> > postmessage
> >
> >
> > ----- Original Message -----
> > From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> > To: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org
> > Cc: "Itamar Heim" <iheim at redhat.com>, "George Costea"
> > <George.Costea at netapp.com>
> > Sent: Tuesday, January 8, 2013 3:13:44 PM
> > Subject: Question about closing UI plugin dialog
> >
> > Hi All,
> >
> > I've been working on a plugin for the UI that launches a dialog using
> > the
> > showDialog() API. Our UI is actually contained in a frame inside the
> > dialog and is loaded from a separate server. The only information
> > needed for our UI comes in either through the URL as parameters or from
> the oVirt REST API.
> > The issue is that once the clicks the OK or Cancel buttons in our UI
> > we need to message to the oVirt UI to close the dialog.
> >
> > It looks like using the window.postMessage() API would be great for
> > this, but it doesn't work across windows in IE. Would it be possible
> > to change the code that launches the window to open a window that
> > contains a bit of javascript that sets up a listener for closing the
> > dialog and then launches the URL in an iFrame in the window? Of
> > course, if it were in a native GWT dialog this wouldn't be a problem.
> > ;)
> >
> > -Chris
> >
> > Chris Morrissey
> > Software Engineer
> > NetApp Inc.
> > 919.476.4428
> >


From shuming at linux.vnet.ibm.com  Fri Jan 11 00:45:47 2013
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Fri, 11 Jan 2013 08:45:47 +0800
Subject: [Engine-devel] Live storage migration status in oVirt 3.2
Message-ID: <50EF60BB.1040803@linux.vnet.ibm.com>

Hi,

I am reviewing the live storage migration with my oVirt environment
updated from the public nightly repository two weeks ago.  I found that
the "move" button was still gray as before when the VM was up.  Only
after I deactivated the disk, did the button become into non-gray state.
 I am wondering if the live storage migration will be supported in oVirt
3.2 release or not.

BTW: These patches below should enable the live storage migration
already, but I can not see  it enabled in my engine.

http://gerrit.ovirt.org/5252  Change I91e641cb: pool: live storage
migration implementation

http://gerrit.ovirt.org/8105  Change subject: core: Live Storage
Migration commands
http://gerrit.ovirt.org/8103  Change subject: core: VDS Commands for
Live Storage Migration
http://gerrit.ovirt.org/8102  Change subject: core: Adding VDSM API for
Live Storage Migration
http://gerrit.ovirt.org/8470  Change subject: webadmin: Adding Live
Storage Migration support
http://gerrit.ovirt.org/8857 core: disable LiveStorageMigration on 3.1

-- 
---
?? Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626  Tieline: 9051626 E-mail: shuming at cn.ibm.com or
shuming at linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
District, Beijing 100193, PRC




From derez at redhat.com  Fri Jan 11 11:07:40 2013
From: derez at redhat.com (Daniel Erez)
Date: Fri, 11 Jan 2013 06:07:40 -0500 (EST)
Subject: [Engine-devel] Live storage migration status in oVirt 3.2
In-Reply-To: <50EF60BB.1040803@linux.vnet.ibm.com>
Message-ID: <2138026762.2830320.1357902460875.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Shu Ming" <shuming at linux.vnet.ibm.com>
> To: engine-devel at ovirt.org, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> Cc: "Federico Simoncelli" <fsimonce at redhat.com>, derez at redhat.com
> Sent: Friday, January 11, 2013 2:45:47 AM
> Subject: Live storage migration status in oVirt 3.2
> 
> Hi,
> 
> I am reviewing the live storage migration with my oVirt environment
> updated from the public nightly repository two weeks ago.  I found
> that
> the "move" button was still gray as before when the VM was up.  Only
> after I deactivated the disk, did the button become into non-gray
> state.
>  I am wondering if the live storage migration will be supported in
>  oVirt
> 3.2 release or not.
> 
> BTW: These patches below should enable the live storage migration
> already, but I can not see  it enabled in my engine.
> 
> http://gerrit.ovirt.org/5252  Change I91e641cb: pool: live storage
> migration implementation
> 
> http://gerrit.ovirt.org/8105  Change subject: core: Live Storage
> Migration commands
> http://gerrit.ovirt.org/8103  Change subject: core: VDS Commands for
> Live Storage Migration
> http://gerrit.ovirt.org/8102  Change subject: core: Adding VDSM API
> for
> Live Storage Migration
> http://gerrit.ovirt.org/8470  Change subject: webadmin: Adding Live
> Storage Migration support
> http://gerrit.ovirt.org/8857 core: disable LiveStorageMigration on
> 3.1
> 
> --
> ---
> ?? Shu Ming
> Open Virtualization Engineerning; CSTL, IBM Corp.
> Tel: 86-10-82451626  Tieline: 9051626 E-mail: shuming at cn.ibm.com or
> shuming at linux.vnet.ibm.com
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
> District, Beijing 100193, PRC
> 

Hi Shu,

When a VM is up, the "move" button is enabled only for Data Center version 3.2.
Can you please verify that the selected disk resides on a 3.2 Data Center?

Best Regards,
Daniel

> 
>


From eedri at redhat.com  Sat Jan 12 18:36:33 2013
From: eedri at redhat.com (Eyal Edri)
Date: Sat, 12 Jan 2013 13:36:33 -0500 (EST)
Subject: [Engine-devel] ovirt-engine unit tests are broken
Message-ID: <127520354.3977897.1358015793228.JavaMail.root@redhat.com>

fyi,

since build # unit tests are broken.

last commits:


From eedri at redhat.com  Sat Jan 12 18:37:58 2013
From: eedri at redhat.com (Eyal Edri)
Date: Sat, 12 Jan 2013 13:37:58 -0500 (EST)
Subject: [Engine-devel] ovirt-engine unit tests are broken
In-Reply-To: <127520354.3977897.1358015793228.JavaMail.root@redhat.com>
Message-ID: <157578066.3978035.1358015878814.JavaMail.root@redhat.com>

sorry, sent w/o details:

last changes after stable build:

http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/3115/changes#detail0

test failing: org.ovirt.engine.core.bll.CommandBaseTest.testHandlersInEndWithFailure

----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, "Yair Zaslavsky" <yzaslavs at redhat.com>
> Sent: Saturday, January 12, 2013 8:36:33 PM
> Subject: [Engine-devel] ovirt-engine unit tests are broken
> 
> fyi,
> 
> since build # unit tests are broken.
> 
> last commits:
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mkolesni at redhat.com  Sun Jan 13 13:16:01 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 13 Jan 2013 08:16:01 -0500 (EST)
Subject: [Engine-devel] jpa annotations
In-Reply-To: <849327049.17660937.1355915307567.JavaMail.root@redhat.com>
Message-ID: <1367360314.3590338.1358082961061.JavaMail.root@redhat.com>

----- Original Message -----
> 
> 
> ----- 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: Tuesday, December 18, 2012 11:52:39 PM
> > Subject: Re: [Engine-devel] jpa annotations
> > 
> > On 12/18/2012 03:55 PM, Laszlo Hornyak wrote:
> > > Hi,
> > >
> > > We have JPA annotations on the backend entity beans, but they
> > > have
> > > never been actually used as far as I know and now that I looked
> > > into VmTemplate for example we do not even have a vm_template
> > > table anymore, while VmTemplate still refers to it.
> > > Any plans with the JPA?
> > >
> > 
> > I'm assuming they are from the work on moving to hibernate started
> > a
> > long time ago, and question is are we going to finish it anytime
> > soon.

Yes it was done a couple of year ago but never made it past a "POC" state.

> It's not a case of finishing it, it's a case of redoing it.
> These annotations are not being maintainted anymore, and a large
> percent of them are now irrelevant.

Indeed, they are mostly getting in the way and interfering with understanding the code..

As I see it there are 3 options:
 1. Do nothing and just live with them.
 2. Remove them completely and all hibernate related work.
 3. Write DAOs that work with hibernate and start using them.

For me #1 is not that great since currently it's just garbage that sits there unmaintained..
I would like to see #3 happen but I think that it's easier to do #2 first, and then each DAO can be treated separately (there's already the infrastructure for that in place).

I know it might seem wasteful to do #2 instead of #3 but:
 * We don't have anyone to pick up #3 and work on it to get it to a good state.
 * The hibernate work that's been done is really cross product, but I don't see why we wouldn't do it in an iterative way instead of forcing all DAOs to switch in one fell swoop..
 * The work that has been done, is not that much that we would "cry" over deleting it..

Your thoughts?

Regards,
Mike


From yzaslavs at redhat.com  Sun Jan 13 13:37:19 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 13 Jan 2013 08:37:19 -0500 (EST)
Subject: [Engine-devel] jpa annotations
In-Reply-To: <1367360314.3590338.1358082961061.JavaMail.root@redhat.com>
Message-ID: <283558426.5867234.1358084239871.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, January 13, 2013 3:16:01 PM
> Subject: Re: [Engine-devel] jpa annotations
> 
> ----- Original Message -----
> > 
> > 
> > ----- 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: Tuesday, December 18, 2012 11:52:39 PM
> > > Subject: Re: [Engine-devel] jpa annotations
> > > 
> > > On 12/18/2012 03:55 PM, Laszlo Hornyak wrote:
> > > > Hi,
> > > >
> > > > We have JPA annotations on the backend entity beans, but they
> > > > have
> > > > never been actually used as far as I know and now that I looked
> > > > into VmTemplate for example we do not even have a vm_template
> > > > table anymore, while VmTemplate still refers to it.
> > > > Any plans with the JPA?
> > > >
> > > 
> > > I'm assuming they are from the work on moving to hibernate
> > > started
> > > a
> > > long time ago, and question is are we going to finish it anytime
> > > soon.
> 
> Yes it was done a couple of year ago but never made it past a "POC"
> state.
> 
> > It's not a case of finishing it, it's a case of redoing it.
> > These annotations are not being maintainted anymore, and a large
> > percent of them are now irrelevant.
> 
> Indeed, they are mostly getting in the way and interfering with
> understanding the code..
> 
> As I see it there are 3 options:
>  1. Do nothing and just live with them.
>  2. Remove them completely and all hibernate related work.
>  3. Write DAOs that work with hibernate and start using them.
> 
> For me #1 is not that great since currently it's just garbage that
> sits there unmaintained..
> I would like to see #3 happen but I think that it's easier to do #2
> first, and then each DAO can be treated separately (there's already
> the infrastructure for that in place).
> 
> I know it might seem wasteful to do #2 instead of #3 but:
>  * We don't have anyone to pick up #3 and work on it to get it to a
>  good state.
>  * The hibernate work that's been done is really cross product, but I
>  don't see why we wouldn't do it in an iterative way instead of
>  forcing all DAOs to switch in one fell swoop..
>  * The work that has been done, is not that much that we would "cry"
>  over deleting it..

+1 and I think we should revisit our basic approach to hibernate (for example - a question - maybe we should have
separate modelling for db related entities that reflect hibernate + DTOs that are used in bll - our current common entities).
In addition there was no serious work done on transactions in context of hibernate.


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


From shuming at linux.vnet.ibm.com  Sun Jan 13 14:23:17 2013
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Sun, 13 Jan 2013 22:23:17 +0800
Subject: [Engine-devel] Live storage migration status in oVirt 3.2
In-Reply-To: <2138026762.2830320.1357902460875.JavaMail.root@redhat.com>
References: <2138026762.2830320.1357902460875.JavaMail.root@redhat.com>
Message-ID: <50F2C355.5070906@linux.vnet.ibm.com>

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

I checked my data center compatibility version is 3.1.  However, it is 
interesting that the compatibility version of the cluster in the data 
center is 3.2  Does the data center allow a higher version cluster?  I 
will try to upgrade the data center version and try the migration again.

>
> Best Regards,
> Daniel
>
>>


-- 
---
?? Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626  Tieline: 9051626 E-mail: shuming at cn.ibm.com or shuming at linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC




From lhornyak at redhat.com  Sun Jan 13 16:23:40 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Sun, 13 Jan 2013 11:23:40 -0500 (EST)
Subject: [Engine-devel] jpa annotations
In-Reply-To: <1367360314.3590338.1358082961061.JavaMail.root@redhat.com>
Message-ID: <1995990563.2259709.1358094220079.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, January 13, 2013 3:16:01 PM
> Subject: Re: [Engine-devel] jpa annotations
> 
> ----- Original Message -----
> > 
> > 
> > ----- 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: Tuesday, December 18, 2012 11:52:39 PM
> > > Subject: Re: [Engine-devel] jpa annotations
> > > 
> > > On 12/18/2012 03:55 PM, Laszlo Hornyak wrote:
> > > > Hi,
> > > >
> > > > We have JPA annotations on the backend entity beans, but they
> > > > have
> > > > never been actually used as far as I know and now that I looked
> > > > into VmTemplate for example we do not even have a vm_template
> > > > table anymore, while VmTemplate still refers to it.
> > > > Any plans with the JPA?
> > > >
> > > 
> > > I'm assuming they are from the work on moving to hibernate
> > > started
> > > a
> > > long time ago, and question is are we going to finish it anytime
> > > soon.
> 
> Yes it was done a couple of year ago but never made it past a "POC"
> state.
> 
> > It's not a case of finishing it, it's a case of redoing it.
> > These annotations are not being maintainted anymore, and a large
> > percent of them are now irrelevant.
> 
> Indeed, they are mostly getting in the way and interfering with
> understanding the code..
> 
> As I see it there are 3 options:
>  1. Do nothing and just live with them.
>  2. Remove them completely and all hibernate related work.
>  3. Write DAOs that work with hibernate and start using them.
> 
> For me #1 is not that great since currently it's just garbage that
> sits there unmaintained..
> I would like to see #3 happen but I think that it's easier to do #2
> first, and then each DAO can be treated separately (there's already
> the infrastructure for that in place).
> 
> I know it might seem wasteful to do #2 instead of #3 but:
>  * We don't have anyone to pick up #3 and work on it to get it to a
>  good state.
>  * The hibernate work that's been done is really cross product, but I
>  don't see why we wouldn't do it in an iterative way instead of
>  forcing all DAOs to switch in one fell swoop..
>  * The work that has been done, is not that much that we would "cry"
>  over deleting it..
> 
> Your thoughts?

I would really like #3, I would join the effort in my own time.
I could agree with #2 as a temporary solution to clean up the code.
#1 is like the boiling frog http://en.wikipedia.org/wiki/Boiling_frog

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


From lpeer at redhat.com  Sun Jan 13 17:15:19 2013
From: lpeer at redhat.com (Livnat Peer)
Date: Sun, 13 Jan 2013 19:15:19 +0200
Subject: [Engine-devel] Live storage migration status in oVirt 3.2
In-Reply-To: <50F2C355.5070906@linux.vnet.ibm.com>
References: <2138026762.2830320.1357902460875.JavaMail.root@redhat.com>
	<50F2C355.5070906@linux.vnet.ibm.com>
Message-ID: <50F2EBA7.5090509@redhat.com>

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

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

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


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



From dfediuck at redhat.com  Sun Jan 13 17:54:46 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 13 Jan 2013 12:54:46 -0500 (EST)
Subject: [Engine-devel] Java code formatting
In-Reply-To: <1129634922.112963.1357521175724.JavaMail.root@redhat.com>
Message-ID: <2048632257.3977652.1358099686036.JavaMail.root@redhat.com>

This should be a jenkins job, not a local one.

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, January 7, 2013 3:12:55 AM
> Subject: Re: [Engine-devel] Java code formatting
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Eyal Edri" <eedri at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, January 6, 2013 4:30:23 PM
> > Subject: Re: [Engine-devel] Java code formatting
> > 
> > 
> > ----- Original Message -----
> > > From: "Eyal Edri" <eedri at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Friday, January 4, 2013 5:39:52 PM
> > > Subject: Re: [Engine-devel] Java code formatting
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "David Ja?a" <djasa at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Friday, January 4, 2013 4:37:13 PM
> > > > Subject: Re: [Engine-devel] Java code formatting
> > > > 
> > > > Doron Fediuck p??e v St 02. 01. 2013 v 03:24 -0500:
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Livnat Peer" <lpeer at redhat.com>
> > > > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Tuesday, January 1, 2013 5:58:15 PM
> > > > > > Subject: Re: [Engine-devel] Java code formatting
> > > > > > 
> > > > > > On 01/01/2013 05:39 PM, Doron Fediuck wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > >> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > >> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > >> Sent: Tuesday, January 1, 2013 5:05:09 PM
> > > > > > >> Subject: Re: [Engine-devel] Java code formatting
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> ----- Original Message -----
> > > > > > >>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > >>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > >>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > >>> Sent: Tuesday, January 1, 2013 5:00:20 PM
> > > > > > >>> Subject: Re: [Engine-devel] Java code formatting
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> ----- Original Message -----
> > > > > > >>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > >>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > >>>> Sent: Tuesday, January 1, 2013 4:53:49 PM
> > > > > > >>>> Subject: Re: [Engine-devel] Java code formatting
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> ----- Original Message -----
> > > > > > >>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > >>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > >>>>> Sent: Tuesday, January 1, 2013 4:48:22 PM
> > > > > > >>>>> Subject: Re: [Engine-devel] Java code formatting
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>> ----- Original Message -----
> > > > > > >>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > >>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > >>>>>> Sent: Tuesday, January 1, 2013 4:33:20 PM
> > > > > > >>>>>> Subject: Re: [Engine-devel] Java code formatting
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>> ----- Original Message -----
> > > > > > >>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > >>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > >>>>>>> Sent: Tuesday, January 1, 2013 4:28:15 PM
> > > > > > >>>>>>> Subject: Re: [Engine-devel] Java code formatting
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>> ----- Original Message -----
> > > > > > >>>>>>>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > > >>>>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > >>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > >>>>>>>> Sent: Tuesday, January 1, 2013 4:17:18 PM
> > > > > > >>>>>>>> Subject: Re: [Engine-devel] Java code formatting
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> ----- Original Message -----
> > > > > > >>>>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > > >>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > >>>>>>>>> Sent: Tuesday, January 1, 2013 4:07:53 PM
> > > > > > >>>>>>>>> Subject: [Engine-devel] Java code formatting
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Hi,
> > > > > > >>>>>>>>> Recently I saw many patches with multiple code
> > > > > > >>>>>>>>> re-formatting.
> > > > > > >>>>>>>>> When looking into it, we saw that many people
> > > > > > >>>>>>>>> didn't
> > > > > > >>>>>>>>> use
> > > > > > >>>>>>>>> the
> > > > > > >>>>>>>>> project
> > > > > > >>>>>>>>> policy, and now we have many files with bad
> > > > > > >>>>>>>>> formatting.
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> So I just posted a big ugly fix for this[1], and
> > > > > > >>>>>>>>> hopefully
> > > > > > >>>>>>>>> if
> > > > > > >>>>>>>>> accepted
> > > > > > >>>>>>>>> people should start using the right conventions
> > > > > > >>>>>>>>> and
> > > > > > >>>>>>>>> reduce
> > > > > > >>>>>>>>> the
> > > > > > >>>>>>>>> amount
> > > > > > >>>>>>>>> of non-relevant changes we see in the patches.
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> I'm aware of the fact that this may create some
> > > > > > >>>>>>>>> issues
> > > > > > >>>>>>>>> when
> > > > > > >>>>>>>>> porting
> > > > > > >>>>>>>>> patches, but better sooner than later.
> > > > > > >>>>>>>>> Doron.
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> [1] http://gerrit.ovirt.org/#/c/10541/1
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Hi,
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> These automatic conversions are not better than
> > > > > > >>>>>>>> current
> > > > > > >>>>>>>> state,
> > > > > > >>>>>>>> also
> > > > > > >>>>>>>> I
> > > > > > >>>>>>>> don't think that this is that important. If you
> > > > > > >>>>>>>> want
> > > > > > >>>>>>>> machine
> > > > > > >>>>>>>> written
> > > > > > >>>>>>>> code, then also provide commit hook to reformat
> > > > > > >>>>>>>> anything,
> > > > > > >>>>>>>> and
> > > > > > >>>>>>>> probably machines to read it.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> I, personally, think that this change over the
> > > > > > >>>>>>>> sources
> > > > > > >>>>>>>> I
> > > > > > >>>>>>>> manage
> > > > > > >>>>>>>> did
> > > > > > >>>>>>>> not do any good.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Regards,
> > > > > > >>>>>>>> Alon
> > > > > > >>>>>>>
> > > > > > >>>>>>> Alon,
> > > > > > >>>>>>> there's a formatting convention for the project set
> > > > > > >>>>>>> long
> > > > > > >>>>>>> ago.
> > > > > > >>>>>>> If you feel it needs to be fixed, go ahead and
> > > > > > >>>>>>> suggest
> > > > > > >>>>>>> a
> > > > > > >>>>>>> fix
> > > > > > >>>>>>> for
> > > > > > >>>>>>> the xml.
> > > > > > >>>>>>> Otherwise we end up in the current chaos, where
> > > > > > >>>>>>> every
> > > > > > >>>>>>> 2nd
> > > > > > >>>>>>> or
> > > > > > >>>>>>> 3rd
> > > > > > >>>>>>> patch carries unneeded changes.
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>> What do you mean unneeded changes? how do you
> > > > > > >>>>>> prevent
> > > > > > >>>>>> this
> > > > > > >>>>>> in
> > > > > > >>>>>> future?
> > > > > > >>>>>>
> > > > > > >>>>>> Alon
> > > > > > >>>>>
> > > > > > >>>>> Unneeded changes is when you get one line of code
> > > > > > >>>>> fixed
> > > > > > >>>>> due
> > > > > > >>>>> to
> > > > > > >>>>> a
> > > > > > >>>>> bug,
> > > > > > >>>>> and many others re-indented.
> > > > > > >>>>> Best prevention is if people would make sure to use
> > > > > > >>>>> the
> > > > > > >>>>> same
> > > > > > >>>>> conventions.
> > > > > > >>>>> We also have a checkstyle which monitors important
> > > > > > >>>>> issues
> > > > > > >>>>> such
> > > > > > >>>>> as
> > > > > > >>>>> trailing
> > > > > > >>>>> white spaces, localization, etc.
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>> But how do you prevent this in future, not all working
> > > > > > >>>> in
> > > > > > >>>> same
> > > > > > >>>> editor
> > > > > > >>>> nor same styles.
> > > > > > >>>> You can say that once in a while you perform cross
> > > > > > >>>> over
> > > > > > >>>> auto
> > > > > > >>>> re-format...
> > > > > > >>>> I am not native Java programmer but this sounds very
> > > > > > >>>> strange
> > > > > > >>>> thing
> > > > > > >>>> to
> > > > > > >>>> do, I don't think I know of any project that does
> > > > > > >>>> that.
> > > > > > >>>>
> > > > > > >>>> The main problem is that people commit stuff they
> > > > > > >>>> don't
> > > > > > >>>> touch
> > > > > > >>>> due
> > > > > > >>>> to
> > > > > > >>>> their editor behavior, which tread the whole source as
> > > > > > >>>> if
> > > > > > >>>> it
> > > > > > >>>> was
> > > > > > >>>> at
> > > > > > >>>> its disposal, while cation should be taken not to
> > > > > > >>>> modify
> > > > > > >>>> extra
> > > > > > >>>> stuff.
> > > > > > >>>>
> > > > > > >>>> So maybe just to reject patches that touches lines
> > > > > > >>>> which
> > > > > > >>>> are
> > > > > > >>>> not
> > > > > > >>>> belong to the patch it-self.
> > > > > > >>>>
> > > > > > >>>> Alon
> > > > > > >>>
> > > > > > >>> I'm fine with rejecting patches with irrelevant
> > > > > > >>> changes.
> > > > > > >>> Still sometimes you get new files and this repeats
> > > > > > >>> itself.
> > > > > > >>> The whole point of a convention is that people keep it.
> > > > > > >>> Most major IDEs today can use the same formatting XML
> > > > > > >>> we
> > > > > > >>> now
> > > > > > >>> have.
> > > > > > >>> So it's really a matter of self-discipline.
> > > > > > >>>
> > > > > > >>
> > > > > > >> OK, I suggest we start rejecting patches with irrelevant
> > > > > > >> changes,
> > > > > > >> and
> > > > > > >> placing these irrelevant changes in their own patch to
> > > > > > >> be
> > > > > > >> relevant.
> > > > > > >>
> > > > > > >> I don't think that we can enforce XML formatting for all
> > > > > > >> editors
> > > > > > >> out
> > > > > > >> there... unless there is a cli utility to reformat
> > > > > > >> before
> > > > > > >> commit,
> > > > > > >> or
> > > > > > >> even do this at gerrit side, we should be somewhat
> > > > > > >> flexible.
> > > > > > >>
> > > > > > >> But these are only my two cents.
> > > > > > >>
> > > > > > >> Alon
> > > > > > > 
> > > > > > > Thanks to Ofri we can now both automate it and monitor it
> > > > > > > using
> > > > > > > http://maven-java-formatter-plugin.googlecode.com/svn/site/0.3.1/examples.html.
> > > > > > > 
> > > > > > > We should be able to add it to the root pom and make sure
> > > > > > > it
> > > > > > > won't
> > > > > > > happen again.
> > > > > > 
> > > > > > From a quick look this plugin looks like formatted and not
> > > > > > format-validator, if this is the case it is less useful as
> > > > > > we
> > > > > > can't
> > > > > > add
> > > > > > a jenkins job to monitor the expected formatting.
> > > > > > 
> > > > > > I think that we should clean the formatting (once again...)
> > > > > > in
> > > > > > our
> > > > > > code
> > > > > > base only after we'll have a valid way to enforce it,
> > > > > > otherwise
> > > > > > we
> > > > > > are
> > > > > > going to have the same thread every few months (we already
> > > > > > had
> > > > > > it
> > > > > > twice
> > > > > > or more) and we all hate this massive formatting patches
> > > > > > that
> > > > > > comes
> > > > > > after the thread...
> > > > > > 
> > > > > > Livnat
> > > > > > 
> > > > > 
> > > > > Livnat,
> > > > > it's easy enough to have a Jenkins job running this plugin.
> > > > 
> > > > Isn't Jenkins too late in the game for checks of incoming code?
> > > > IIRC
> > > > there do exist pre-commit hooks for gerrit that run
> > > > pylint/pyflakes
> > > > on
> > > > python files, that should IMO be the very place to check Java
> > > > coding
> > > > style, too.
> > > 
> > > if the jenkins jobs will run per gerrit patch and not per commit,
> > > (it's possible to run it via jenkins, like run other jobs per
> > > patch).
> > > then it's not too late, and less messy than defining specific
> > > hooks
> > > for it.
> > > 
> > > Eyal.
> 
> Sorry for (very) late response - what would be the price (i.e - build
> time) for running this plugin while performing "mvn clean install"
> on ovirt-engine?
> I know that sometimes people forget to run tests (which is bad) but I
> do believe (and hope ;) ) they do compile before send patches to
> gerrit.
> 
> > > 
> > 
> > Right, we actually had something similar in the past
> > while .NET was still around...
> > 
> > > > 
> > > > David
> > > > 
> > > > > Then git status will tell you if something changed, and if so
> > > > > you email the changes to patch owner (and nack the patch). We
> > > > > had similar jobs in WPF era and it's quite simple to handle.
> > > > > So I see no reason why not to start it now. The sooner we
> > > > > start,
> > > > > less noise and unneeded code changes will be added.
> > > > > 
> > > > > better
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > > --
> > > > 
> > > > David Ja?a, RHCE
> > > > 
> > _______________________________________________
> > 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 Jan 13 19:24:49 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 13 Jan 2013 21:24:49 +0200
Subject: [Engine-devel] ovirt-engine-sdk-python 3.2.0.8 released
In-Reply-To: <50E00C5A.6010502@redhat.com>
References: <50ACB562.5040705@redhat.com> <50E00C5A.6010502@redhat.com>
Message-ID: <50F30A01.90206@redhat.com>


* Sun Jan  13 2013 Michael Pasternak <mpastern at redhat.com> - 3.2.0.8-1
 - events can be added now (user defined events)
 - events can be removed now
 - vm can be removed now, but it's disk/s kept (added disks.detach_only property to VMDisks)
 - to host add()/update() methods() added power_management.agents parameter
 - host can be added now by cluster.name (not only cluster-id)
 - to disk added permissions sub-collection
 - to NIC added "linked" property
 - to NIC added "plugged" property
 - to VM added ReportedDevices sub-collection (holds data reported by the guest agent)
 - to VMNIC added ReportedDevices sub-collection (holds data reported by the guest agent)
 - to PowerManagement added Agents collection
 - to VMDisk added move() action
 - to cluster added "threads_as_cores" property
 - to CpuTopology added "threads" property (indicating amount of available threads)
 - to Host added "libvirt_version" property
 - to Host added "hardware_information" property


For 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  Sun Jan 13 19:29:39 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 13 Jan 2013 21:29:39 +0200
Subject: [Engine-devel] ovirt-cli 3.2.0.9 released
In-Reply-To: <50E00C69.80402@redhat.com>
References: <50A8EA1F.700@redhat.com> <50E00C69.80402@redhat.com>
Message-ID: <50F30B23.7010107@redhat.com>

* Sun Jan  13 2013 Michael Pasternak <mpastern at redhat.com> - 3.2.0.9-1
- ovirt-cli DistributionNotFound exception on f18 #881011
- adding to help message ovirt-shell configuration details #890800
- wrong error when passing empty collection based option #890525
- wrong error when passing empty kwargs #891080

For more details can be found at [1].

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

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From wei.d.chen at intel.com  Mon Jan 14 08:35:35 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Mon, 14 Jan 2013 08:35:35 +0000
Subject: [Engine-devel] build ovrit-engine from source code failed
Message-ID: <C5A0092C63E939488005F15F736A811210C2B8@SHSMSX101.ccr.corp.intel.com>

Hi,

We just wanna build ovirt-engine from source code, we follow the instruction from the ovirt wiki website http://wiki.ovirt.org/wiki/Building_Ovirt_Engine, but failed at last.
All the steps run without errors, however, after I open webadmin, there are no responses when I click any button.

Env:
1. OS: FC17
2. Source code: ovirt 3.2 on Master branch at git://gerrit.ovirt.org/ovirt-engine

Would you also give us some suggestion on how to build ovirt-engine from source code?

Best Regards,
Dave Chen

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

From jhernand at redhat.com  Mon Jan 14 09:48:45 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 14 Jan 2013 10:48:45 +0100
Subject: [Engine-devel] build ovrit-engine from source code failed
In-Reply-To: <C5A0092C63E939488005F15F736A811210C2B8@SHSMSX101.ccr.corp.intel.com>
References: <C5A0092C63E939488005F15F736A811210C2B8@SHSMSX101.ccr.corp.intel.com>
Message-ID: <50F3D47D.5010305@redhat.com>

On 01/14/2013 09:35 AM, Chen, Wei D wrote:
> Hi,
> 
>  
> 
> We just wanna build ovirt-engine from source code, we follow the
> instruction from the ovirt wiki website
> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine, but failed at last.
> 
> All the steps run without errors, however, after I open webadmin, there
> are no responses when I click any button.
> 
>  
> 
> Env:
> 
> 1. OS: FC17
> 
> 2. Source code: ovirt 3.2 on Master branch at
> git://gerrit.ovirt.org/ovirt-engine
> 
>  
> 
> Would you also give us some suggestion on how to build ovirt-engine from
> source code?

If the build completed but things don't work once installed then there
should be some information in the logs in output of the application
server. Can you share that?

-- 
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  Mon Jan 14 11:18:13 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 14 Jan 2013 13:18:13 +0200
Subject: [Engine-devel] [vdsm] RFC: New Storage API
In-Reply-To: <1661336497.13921817.1354657960654.JavaMail.root@redhat.com>
References: <1661336497.13921817.1354657960654.JavaMail.root@redhat.com>
Message-ID: <50F3E975.50300@redhat.com>

On 12/04/2012 11:52 PM, Saggi Mizrahi wrote:
> I've been throwing a lot of bits out about the new storage API and I think it's time to talk a bit.
> I will purposefully try and keep implementation details away and concentrate about how the API looks and how you use it.
>
> First major change is in terminology, there is no long a storage domain but a storage repository.
> This change is done because so many things are already called domain in the system and this will make things less confusing for new-commers with a libvirt background.
>
> One other changes is that repositories no longer have a UUID.
> The UUID was only used in the pool members manifest and is no longer needed.
>
>
> connectStorageRepository(repoId, repoFormat, connectionParameters={}):
> repoId - is a transient name that will be used to refer to the connected domain, it is not persisted and doesn't have to be the same across the cluster.
> repoFormat - Similar to what used to be type (eg. localfs-1.0, nfs-3.4, clvm-1.2).
> connectionParameters - This is format specific and will used to tell VDSM how to connect to the repo.
>
> disconnectStorageRepository(self, repoId):
>
>
> In the new API there are only images, some images are mutable and some are not.
> mutable images are also called VirtualDisks
> immutable images are also called Snapshots
>
> There are no explicit templates, you can create as many images as you want from any snapshot.
>
> There are 4 major image operations:
>
>
> createVirtualDisk(targetRepoId, size, baseSnapshotId=None,
>                    userData={}, options={}):
>
> targetRepoId - ID of a connected repo where the disk will be created
> size - The size of the image you wish to create
> baseSnapshotId - the ID of the snapshot you want the base the new virtual disk on
> userData - optional data that will be attached to the new VD, could be anything that the user desires.
> options - options to modify VDSMs default behavior
>
> returns the id of the new VD
>
> createSnapshot(targetRepoId, baseVirtualDiskId,
>                 userData={}, options={}):
> targetRepoId - The ID of a connected repo where the new sanpshot will be created and the original image exists as well.
> size - The size of the image you wish to create
> baseVirtualDisk - the ID of a mutable image (Virtual Disk) you want to snapshot
> userData - optional data that will be attached to the new Snapshot, could be anything that the user desires.
> options - options to modify VDSMs default behavior
>
> returns the id of the new Snapshot
>
> copyImage(targetRepoId, imageId, baseImageId=None, userData={}, options={})
> targetRepoId - The ID of a connected repo where the new image will be created
> imageId - The image you wish to copy
> baseImageId - if specified, the new image will contain only the diff between image and Id.
>                If None the new image will contain all the bits of image Id. This can be used to copy partial parts of images for export.
> userData - optional data that will be attached to the new image, could be anything that the user desires.
> options - options to modify VDSMs default behavior
>
> return the Id of the new image. In case of copying an immutable image the ID will be identical to the original image as they contain the same data. However the user should not assume that and always use the value returned from the method.
>
> removeImage(repositoryId, imageId, options={}):
> repositoryId - The ID of a connected repo where the image to delete resides
> imageId - The id of the image you wish to delete.
>
>
> ----
> getImageStatus(repositoryId, imageId)
> repositoryId - The ID of a connected repo where the image to check resides
> imageId - The id of the image you wish to check.
>
> All operations return once the operations has been committed to disk NOT when the operation actually completes.
> This is done so that:
> - operation come to a stable state as quickly as possible.
> - In case where there is an SDM, only small portion of the operation actually needs to be performed on the SDM host.
> - No matter how many times the operation fails and on how many hosts, you can always resume the operation and choose when to do it.
> - You can stop an operation at any time and remove the resulting object making a distinction between "stop because the host is overloaded" to "I don't want that image"
>
> This means that after calling any operation that creates a new image the user must then call getImageStatus() to check what is the status of the image.
> The status of the image can be either optimized, degraded, or broken.
> "Optimized" means that the image is available and you can run VMs of it.
> "Degraded" means that the image is available and will run VMs but it might be a better way VDSM can represent the underlying data.
> "Broken" means that the image can't be used at the moment, probably because not all the data has been set up on the volume.
>
> Apart from that VDSM will also return the last persisted status information which will conatin
> hostID - the last host to try and optimize of fix the image
> stage - X/Y (eg. 1/10) the last persisted stage of the fix.
> percent_complete - -1 or 0-100, the last persisted completion percentage of the aforementioned stage. -1 means that no progress is available for that operation.
> last_error - This will only be filled if the operation failed because of something other then IO or a VDSM crash for obvious reasons.
>               It will usually be set if the task was manually stopped
>
> The user can either be satisfied with that information or as the host specified in host ID if it is still working on that image by checking it's running tasks.
>
> checkStorageRepository(self, repositoryId, options={}):
> A method to go over a storage repository and scan for any existing problems. This includes degraded\broken images and deleted images that have no yet been physically deleted\merged.
> It returns a list of Fix objects.
> Fix objects come in 4 types:
> clean - cleans data, run them to get more space.
> optimize - run them to optimize a degraded image
> merge - Merges two images together. Doing this sometimes
>          makes more images ready optimizing or cleaning.
>          The reason it is different from optimize is that
>          unmerged images are considered optimized.
> mend - mends a broken image
>
> The user can read these types and prioritize fixes. Fixes also contain opaque FIX data and they should be sent as received to
> fixStorageRepository(self, repositoryId, fix, options={}):
>
> That will start a fix operation.
>
>
> All major operations automatically start the appropriate "Fix" to bring the created object to an optimize\degraded state (the one that is quicker) unless one of the options is
> AutoFix=False. This is only useful for repos that might not be able to create volumes on all hosts (SDM) but would like to have the actual IO distributed in the cluster.
>
> Other common options is the strategy option:
> It has currently 2 possible values
> space and performance - In case VDSM has 2 ways of completing the same operation it will tell it to value one over the other. For example, whether to copy all the data or just create a qcow based of a snapshot.
> The default is space.
>
> You might have also noticed that it is never explicitly specified where to look for existing images. This is done purposefully, VDSM will always look in all connected repositories for existing objects.
> For very large setups this might be problematic. To mitigate the problem you have these options:
> participatingRepositories=[repoId, ...] which tell VDSM to narrow the search to just these repositories
> and
> imageHints={imgId: repoId} which will force VDSM to look for those image ID just in those repositories and fail if it doesn't find them there.
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>

you are using VirtualDisk and Snapshot for mutable and immutable.
the terminology of "image" for immutable and "volume" for mutable seems 
to be the one used by ec2/openstack/etc. - any thoughts on using similar 
terminology?
(though i think they also differ in forcing all images to be in an image 
repo, and all volumes in a volume repo, while we allow to mix them in 
same repo).


From iheim at redhat.com  Mon Jan 14 11:19:14 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 14 Jan 2013 13:19:14 +0200
Subject: [Engine-devel] [vdsm] RFC: New Storage API
In-Reply-To: <2088165976.15522700.1354910021174.JavaMail.root@redhat.com>
References: <2088165976.15522700.1354910021174.JavaMail.root@redhat.com>
Message-ID: <50F3E9B2.2060109@redhat.com>

On 12/07/2012 09:53 PM, Saggi Mizrahi wrote:
>
...
>>>>>
>>>>> connectStorageRepository(repoId, repoFormat,
>>>>> connectionParameters={}):
>>>>> repoId - is a transient name that will be used to refer to the
>>>>> connected domain, it is not persisted and doesn't have to be the
>>>>> same across the cluster.
>>>>> repoFormat - Similar to what used to be type (eg. localfs-1.0,
>>>>> nfs-3.4, clvm-1.2).
>>>>> connectionParameters - This is format specific and will used to
>>>>> tell VDSM how to connect to the repo.
>>>>
>>>> Where does repoID come from? I think repoID doesn't exist before
>>>> connectStorageRepository() return.  Isn't repoID a return value of
>>>> connectStorageRepository()?
>>> No, repoIDs are no longer part of the domain, they are just a
>>> transient handle.
>>> The user can put whatever it wants there as long as it isn't
>>> already taken by another currently connected domain.
>>
>> So what happens when user mistakenly gives a repoID that is in use
>> before.. there should be something in the return value that specifies
>> the error and/or reason for error so that user can try with a
>> new/diff
>> repoID ?
> Asi I said, connect fails if the repoId is in use ATM.

so how do add connections to the repo without first disconnecting it 
("extend storage domain" flow)?


From amureini at redhat.com  Mon Jan 14 13:36:02 2013
From: amureini at redhat.com (Allon Mureinik)
Date: Mon, 14 Jan 2013 08:36:02 -0500 (EST)
Subject: [Engine-devel] jpa annotations
In-Reply-To: <1367360314.3590338.1358082961061.JavaMail.root@redhat.com>
Message-ID: <2008434050.4310787.1358170562722.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "Itamar Heim" <iheim at redhat.com>, "Allon Mureinik" <amureini at redhat.com>
> Sent: Sunday, January 13, 2013 3:16:01 PM
> Subject: Re: [Engine-devel] jpa annotations
> 
> ----- Original Message -----
> > 
> > 
> > ----- 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: Tuesday, December 18, 2012 11:52:39 PM
> > > Subject: Re: [Engine-devel] jpa annotations
> > > 
> > > On 12/18/2012 03:55 PM, Laszlo Hornyak wrote:
> > > > Hi,
> > > >
> > > > We have JPA annotations on the backend entity beans, but they
> > > > have
> > > > never been actually used as far as I know and now that I looked
> > > > into VmTemplate for example we do not even have a vm_template
> > > > table anymore, while VmTemplate still refers to it.
> > > > Any plans with the JPA?
> > > >
> > > 
> > > I'm assuming they are from the work on moving to hibernate
> > > started
> > > a
> > > long time ago, and question is are we going to finish it anytime
> > > soon.
> 
> Yes it was done a couple of year ago but never made it past a "POC"
> state.
> 
> > It's not a case of finishing it, it's a case of redoing it.
> > These annotations are not being maintainted anymore, and a large
> > percent of them are now irrelevant.
> 
> Indeed, they are mostly getting in the way and interfering with
> understanding the code..
> 
> As I see it there are 3 options:
>  1. Do nothing and just live with them.
>  2. Remove them completely and all hibernate related work.
>  3. Write DAOs that work with hibernate and start using them.
> 
> For me #1 is not that great since currently it's just garbage that
> sits there unmaintained..
> I would like to see #3 happen but I think that it's easier to do #2
> first, and then each DAO can be treated separately (there's already
> the infrastructure for that in place).
> 
> I know it might seem wasteful to do #2 instead of #3 but:
>  * We don't have anyone to pick up #3 and work on it to get it to a
>  good state.
>  * The hibernate work that's been done is really cross product, but I
>  don't see why we wouldn't do it in an iterative way instead of
>  forcing all DAOs to switch in one fell swoop..
>  * The work that has been done, is not that much that we would "cry"
>  over deleting it..

#1 is just bad, as I think we can all agree.
As Edmund Burke (probably did not) say - "All that is necessary for the triumph of evil is that good men do nothing."

re #2 and #3 - considering the state that these annotation are currently in, #3 probably includes removing more than 50% of the current annotations, so...
+2 on doing #2.


> 
> Your thoughts?
> 
> Regards,
> Mike
> 


From tnisan at redhat.com  Mon Jan 14 14:56:58 2013
From: tnisan at redhat.com (Tal Nisan)
Date: Mon, 14 Jan 2013 16:56:58 +0200
Subject: [Engine-devel] jpa annotations
In-Reply-To: <2008434050.4310787.1358170562722.JavaMail.root@redhat.com>
References: <2008434050.4310787.1358170562722.JavaMail.root@redhat.com>
Message-ID: <50F41CBA.6070104@redhat.com>

+2 for #2, seems like most of the work done is adding the annotations, 
most of which are not relevant anyway so if we want to get back someday 
to the Hibernate effort we will have to check each one individually 
anyway, better do it from scratch.



On 01/14/2013 03:36 PM, Allon Mureinik wrote:
>
> ----- Original Message -----
>> From: "Mike Kolesnik"<mkolesni at redhat.com>
>> To: "engine-devel"<engine-devel at ovirt.org>
>> Cc: "Itamar Heim"<iheim at redhat.com>, "Allon Mureinik"<amureini at redhat.com>
>> Sent: Sunday, January 13, 2013 3:16:01 PM
>> Subject: Re: [Engine-devel] jpa annotations
>>
>> ----- Original Message -----
>>>
>>> ----- 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: Tuesday, December 18, 2012 11:52:39 PM
>>>> Subject: Re: [Engine-devel] jpa annotations
>>>>
>>>> On 12/18/2012 03:55 PM, Laszlo Hornyak wrote:
>>>>> Hi,
>>>>>
>>>>> We have JPA annotations on the backend entity beans, but they
>>>>> have
>>>>> never been actually used as far as I know and now that I looked
>>>>> into VmTemplate for example we do not even have a vm_template
>>>>> table anymore, while VmTemplate still refers to it.
>>>>> Any plans with the JPA?
>>>>>
>>>> I'm assuming they are from the work on moving to hibernate
>>>> started
>>>> a
>>>> long time ago, and question is are we going to finish it anytime
>>>> soon.
>> Yes it was done a couple of year ago but never made it past a "POC"
>> state.
>>
>>> It's not a case of finishing it, it's a case of redoing it.
>>> These annotations are not being maintainted anymore, and a large
>>> percent of them are now irrelevant.
>> Indeed, they are mostly getting in the way and interfering with
>> understanding the code..
>>
>> As I see it there are 3 options:
>>   1. Do nothing and just live with them.
>>   2. Remove them completely and all hibernate related work.
>>   3. Write DAOs that work with hibernate and start using them.
>>
>> For me #1 is not that great since currently it's just garbage that
>> sits there unmaintained..
>> I would like to see #3 happen but I think that it's easier to do #2
>> first, and then each DAO can be treated separately (there's already
>> the infrastructure for that in place).
>>
>> I know it might seem wasteful to do #2 instead of #3 but:
>>   * We don't have anyone to pick up #3 and work on it to get it to a
>>   good state.
>>   * The hibernate work that's been done is really cross product, but I
>>   don't see why we wouldn't do it in an iterative way instead of
>>   forcing all DAOs to switch in one fell swoop..
>>   * The work that has been done, is not that much that we would "cry"
>>   over deleting it..
> #1 is just bad, as I think we can all agree.
> As Edmund Burke (probably did not) say - "All that is necessary for the triumph of evil is that good men do nothing."
>
> re #2 and #3 - considering the state that these annotation are currently in, #3 probably includes removing more than 50% of the current annotations, so...
> +2 on doing #2.
>
>
>> Your thoughts?
>>
>> Regards,
>> Mike
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From smizrahi at redhat.com  Mon Jan 14 17:03:44 2013
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Mon, 14 Jan 2013 12:03:44 -0500 (EST)
Subject: [Engine-devel] [vdsm] RFC: New Storage API
In-Reply-To: <50F3E975.50300@redhat.com>
Message-ID: <251418789.1544680.1358183024067.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, January 14, 2013 6:18:13 AM
> Subject: Re: [vdsm] RFC: New Storage API
> 
> On 12/04/2012 11:52 PM, Saggi Mizrahi wrote:
> > I've been throwing a lot of bits out about the new storage API and
> > I think it's time to talk a bit.
> > I will purposefully try and keep implementation details away and
> > concentrate about how the API looks and how you use it.
> >
> > First major change is in terminology, there is no long a storage
> > domain but a storage repository.
> > This change is done because so many things are already called
> > domain in the system and this will make things less confusing for
> > new-commers with a libvirt background.
> >
> > One other changes is that repositories no longer have a UUID.
> > The UUID was only used in the pool members manifest and is no
> > longer needed.
> >
> >
> > connectStorageRepository(repoId, repoFormat,
> > connectionParameters={}):
> > repoId - is a transient name that will be used to refer to the
> > connected domain, it is not persisted and doesn't have to be the
> > same across the cluster.
> > repoFormat - Similar to what used to be type (eg. localfs-1.0,
> > nfs-3.4, clvm-1.2).
> > connectionParameters - This is format specific and will used to
> > tell VDSM how to connect to the repo.
> >
> > disconnectStorageRepository(self, repoId):
> >
> >
> > In the new API there are only images, some images are mutable and
> > some are not.
> > mutable images are also called VirtualDisks
> > immutable images are also called Snapshots
> >
> > There are no explicit templates, you can create as many images as
> > you want from any snapshot.
> >
> > There are 4 major image operations:
> >
> >
> > createVirtualDisk(targetRepoId, size, baseSnapshotId=None,
> >                    userData={}, options={}):
> >
> > targetRepoId - ID of a connected repo where the disk will be
> > created
> > size - The size of the image you wish to create
> > baseSnapshotId - the ID of the snapshot you want the base the new
> > virtual disk on
> > userData - optional data that will be attached to the new VD, could
> > be anything that the user desires.
> > options - options to modify VDSMs default behavior
> >
> > returns the id of the new VD
> >
> > createSnapshot(targetRepoId, baseVirtualDiskId,
> >                 userData={}, options={}):
> > targetRepoId - The ID of a connected repo where the new sanpshot
> > will be created and the original image exists as well.
> > size - The size of the image you wish to create
> > baseVirtualDisk - the ID of a mutable image (Virtual Disk) you want
> > to snapshot
> > userData - optional data that will be attached to the new Snapshot,
> > could be anything that the user desires.
> > options - options to modify VDSMs default behavior
> >
> > returns the id of the new Snapshot
> >
> > copyImage(targetRepoId, imageId, baseImageId=None, userData={},
> > options={})
> > targetRepoId - The ID of a connected repo where the new image will
> > be created
> > imageId - The image you wish to copy
> > baseImageId - if specified, the new image will contain only the
> > diff between image and Id.
> >                If None the new image will contain all the bits of
> >                image Id. This can be used to copy partial parts of
> >                images for export.
> > userData - optional data that will be attached to the new image,
> > could be anything that the user desires.
> > options - options to modify VDSMs default behavior
> >
> > return the Id of the new image. In case of copying an immutable
> > image the ID will be identical to the original image as they
> > contain the same data. However the user should not assume that and
> > always use the value returned from the method.
> >
> > removeImage(repositoryId, imageId, options={}):
> > repositoryId - The ID of a connected repo where the image to delete
> > resides
> > imageId - The id of the image you wish to delete.
> >
> >
> > ----
> > getImageStatus(repositoryId, imageId)
> > repositoryId - The ID of a connected repo where the image to check
> > resides
> > imageId - The id of the image you wish to check.
> >
> > All operations return once the operations has been committed to
> > disk NOT when the operation actually completes.
> > This is done so that:
> > - operation come to a stable state as quickly as possible.
> > - In case where there is an SDM, only small portion of the
> > operation actually needs to be performed on the SDM host.
> > - No matter how many times the operation fails and on how many
> > hosts, you can always resume the operation and choose when to do
> > it.
> > - You can stop an operation at any time and remove the resulting
> > object making a distinction between "stop because the host is
> > overloaded" to "I don't want that image"
> >
> > This means that after calling any operation that creates a new
> > image the user must then call getImageStatus() to check what is
> > the status of the image.
> > The status of the image can be either optimized, degraded, or
> > broken.
> > "Optimized" means that the image is available and you can run VMs
> > of it.
> > "Degraded" means that the image is available and will run VMs but
> > it might be a better way VDSM can represent the underlying data.
> > "Broken" means that the image can't be used at the moment, probably
> > because not all the data has been set up on the volume.
> >
> > Apart from that VDSM will also return the last persisted status
> > information which will conatin
> > hostID - the last host to try and optimize of fix the image
> > stage - X/Y (eg. 1/10) the last persisted stage of the fix.
> > percent_complete - -1 or 0-100, the last persisted completion
> > percentage of the aforementioned stage. -1 means that no progress
> > is available for that operation.
> > last_error - This will only be filled if the operation failed
> > because of something other then IO or a VDSM crash for obvious
> > reasons.
> >               It will usually be set if the task was manually
> >               stopped
> >
> > The user can either be satisfied with that information or as the
> > host specified in host ID if it is still working on that image by
> > checking it's running tasks.
> >
> > checkStorageRepository(self, repositoryId, options={}):
> > A method to go over a storage repository and scan for any existing
> > problems. This includes degraded\broken images and deleted images
> > that have no yet been physically deleted\merged.
> > It returns a list of Fix objects.
> > Fix objects come in 4 types:
> > clean - cleans data, run them to get more space.
> > optimize - run them to optimize a degraded image
> > merge - Merges two images together. Doing this sometimes
> >          makes more images ready optimizing or cleaning.
> >          The reason it is different from optimize is that
> >          unmerged images are considered optimized.
> > mend - mends a broken image
> >
> > The user can read these types and prioritize fixes. Fixes also
> > contain opaque FIX data and they should be sent as received to
> > fixStorageRepository(self, repositoryId, fix, options={}):
> >
> > That will start a fix operation.
> >
> >
> > All major operations automatically start the appropriate "Fix" to
> > bring the created object to an optimize\degraded state (the one
> > that is quicker) unless one of the options is
> > AutoFix=False. This is only useful for repos that might not be able
> > to create volumes on all hosts (SDM) but would like to have the
> > actual IO distributed in the cluster.
> >
> > Other common options is the strategy option:
> > It has currently 2 possible values
> > space and performance - In case VDSM has 2 ways of completing the
> > same operation it will tell it to value one over the other. For
> > example, whether to copy all the data or just create a qcow based
> > of a snapshot.
> > The default is space.
> >
> > You might have also noticed that it is never explicitly specified
> > where to look for existing images. This is done purposefully, VDSM
> > will always look in all connected repositories for existing
> > objects.
> > For very large setups this might be problematic. To mitigate the
> > problem you have these options:
> > participatingRepositories=[repoId, ...] which tell VDSM to narrow
> > the search to just these repositories
> > and
> > imageHints={imgId: repoId} which will force VDSM to look for those
> > image ID just in those repositories and fail if it doesn't find
> > them there.
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >
> 
> you are using VirtualDisk and Snapshot for mutable and immutable.
> the terminology of "image" for immutable and "volume" for mutable
> seems
> to be the one used by ec2/openstack/etc. - any thoughts on using
> similar
> terminology?
> (though i think they also differ in forcing all images to be in an
> image
> repo, and all volumes in a volume repo, while we allow to mix them in
> same repo).
> 
We have volumes internally though, I wanted to call them slabs but Ayal and Edu feel strongly about calling them volumes and the current naming system in general.


From mpastern at redhat.com  Mon Jan 14 20:24:02 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 14 Jan 2013 22:24:02 +0200
Subject: [Engine-devel] oVirt Java-SDK
In-Reply-To: <OF42317BCF.3152CEF2-ON87257AF3.0065B709-87257AF3.0065B70D@uscmail.uscourts.gov>
References: <OF42317BCF.3152CEF2-ON87257AF3.0065B709-87257AF3.0065B70D@uscmail.uscourts.gov>
Message-ID: <50F46962.8030007@redhat.com>

Hi Lawrence,

On 01/14/2013 08:31 PM, Lawrence_Sepulveda at nmcourt.fed.us wrote:
>  
> Hello Michael.  I wanted to extend my thanks for your great work on the oVirt Java-SDK.  We are running a RHEV 3.0 stack and I have been reviewing the oVirt
> Java-SDK to integrate w/Nagios for monitoring purposes.  That said, I'd like to request some minor changes to the Java API that would permit easier access for subclassing. 
> If there is another more appropriate channel to make these suggestions, please let me know so I may follow through.
>  
> In the org.ovirt.engine.sdk.Api class:
> - Add protected createConnectionsPoolBuilder(), createHttpProxyBuilder() and createHttpProxyBroker() methods that are called from the Api constructor(s)

ConnectionsPoolBuilder, HttpProxyBuilder using 'builder' design pattern, adding methods
accepting builder's parameters and invoking builder after analysing these params, will delegitimize
this pattern.

>  
> In the org.ovirt.engine.sdk.web.ConnectionsPoolBuilder class:
> - Change private to protected for createDefaultHttpClient(), createPoolingClientConnectionManager() and createSchemaRegistry() methods
> - Change private to protected for get() accessor methods

The thing is that sdk creating abstraction over transport layer so all mentioned ConnectionsPoolBuilder methods
are considered sdk internals, may i ask why do you need this (use-case)?

>  
> Thank you again for the great work on this API.  I am finding this API to be exactly what I was needing to monitor our RHEV 3.0 stack.  

Thank you very much for your kind words, i really appreciate that.

> If I should redirect these requests to another communication channel, please let me know.

CC'ing engine-devel ML.

>  
> Thank you,
> 
> -- 
> Lawrence Sepulveda
> Systems Engineer
> U.S. District Court
> District of New Mexico
> 333 Lomas Blvd., NW
> Albuquerque, NM 87102
> Phone: (505) 348-2085
> Fax: (505) 348-2028
> lsepulveda at nmcourt.fed.us
> --


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From abaron at redhat.com  Mon Jan 14 21:34:05 2013
From: abaron at redhat.com (Ayal Baron)
Date: Mon, 14 Jan 2013 16:34:05 -0500 (EST)
Subject: [Engine-devel] [vdsm] RFC: New Storage API
In-Reply-To: <251418789.1544680.1358183024067.JavaMail.root@redhat.com>
Message-ID: <1039705302.6025163.1358199245420.JavaMail.root@redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>,
> > "engine-devel" <engine-devel at ovirt.org>
> > Sent: Monday, January 14, 2013 6:18:13 AM
> > Subject: Re: [vdsm] RFC: New Storage API
> > 
> > On 12/04/2012 11:52 PM, Saggi Mizrahi wrote:
> > > I've been throwing a lot of bits out about the new storage API
> > > and
> > > I think it's time to talk a bit.
> > > I will purposefully try and keep implementation details away and
> > > concentrate about how the API looks and how you use it.
> > >
> > > First major change is in terminology, there is no long a storage
> > > domain but a storage repository.
> > > This change is done because so many things are already called
> > > domain in the system and this will make things less confusing for
> > > new-commers with a libvirt background.
> > >
> > > One other changes is that repositories no longer have a UUID.
> > > The UUID was only used in the pool members manifest and is no
> > > longer needed.
> > >
> > >
> > > connectStorageRepository(repoId, repoFormat,
> > > connectionParameters={}):
> > > repoId - is a transient name that will be used to refer to the
> > > connected domain, it is not persisted and doesn't have to be the
> > > same across the cluster.
> > > repoFormat - Similar to what used to be type (eg. localfs-1.0,
> > > nfs-3.4, clvm-1.2).
> > > connectionParameters - This is format specific and will used to
> > > tell VDSM how to connect to the repo.
> > >
> > > disconnectStorageRepository(self, repoId):
> > >
> > >
> > > In the new API there are only images, some images are mutable and
> > > some are not.
> > > mutable images are also called VirtualDisks
> > > immutable images are also called Snapshots
> > >
> > > There are no explicit templates, you can create as many images as
> > > you want from any snapshot.
> > >
> > > There are 4 major image operations:
> > >
> > >
> > > createVirtualDisk(targetRepoId, size, baseSnapshotId=None,
> > >                    userData={}, options={}):
> > >
> > > targetRepoId - ID of a connected repo where the disk will be
> > > created
> > > size - The size of the image you wish to create
> > > baseSnapshotId - the ID of the snapshot you want the base the new
> > > virtual disk on
> > > userData - optional data that will be attached to the new VD,
> > > could
> > > be anything that the user desires.
> > > options - options to modify VDSMs default behavior
> > >
> > > returns the id of the new VD
> > >
> > > createSnapshot(targetRepoId, baseVirtualDiskId,
> > >                 userData={}, options={}):
> > > targetRepoId - The ID of a connected repo where the new sanpshot
> > > will be created and the original image exists as well.
> > > size - The size of the image you wish to create
> > > baseVirtualDisk - the ID of a mutable image (Virtual Disk) you
> > > want
> > > to snapshot
> > > userData - optional data that will be attached to the new
> > > Snapshot,
> > > could be anything that the user desires.
> > > options - options to modify VDSMs default behavior
> > >
> > > returns the id of the new Snapshot
> > >
> > > copyImage(targetRepoId, imageId, baseImageId=None, userData={},
> > > options={})
> > > targetRepoId - The ID of a connected repo where the new image
> > > will
> > > be created
> > > imageId - The image you wish to copy
> > > baseImageId - if specified, the new image will contain only the
> > > diff between image and Id.
> > >                If None the new image will contain all the bits of
> > >                image Id. This can be used to copy partial parts
> > >                of
> > >                images for export.
> > > userData - optional data that will be attached to the new image,
> > > could be anything that the user desires.
> > > options - options to modify VDSMs default behavior
> > >
> > > return the Id of the new image. In case of copying an immutable
> > > image the ID will be identical to the original image as they
> > > contain the same data. However the user should not assume that
> > > and
> > > always use the value returned from the method.
> > >
> > > removeImage(repositoryId, imageId, options={}):
> > > repositoryId - The ID of a connected repo where the image to
> > > delete
> > > resides
> > > imageId - The id of the image you wish to delete.
> > >
> > >
> > > ----
> > > getImageStatus(repositoryId, imageId)
> > > repositoryId - The ID of a connected repo where the image to
> > > check
> > > resides
> > > imageId - The id of the image you wish to check.
> > >
> > > All operations return once the operations has been committed to
> > > disk NOT when the operation actually completes.
> > > This is done so that:
> > > - operation come to a stable state as quickly as possible.
> > > - In case where there is an SDM, only small portion of the
> > > operation actually needs to be performed on the SDM host.
> > > - No matter how many times the operation fails and on how many
> > > hosts, you can always resume the operation and choose when to do
> > > it.
> > > - You can stop an operation at any time and remove the resulting
> > > object making a distinction between "stop because the host is
> > > overloaded" to "I don't want that image"
> > >
> > > This means that after calling any operation that creates a new
> > > image the user must then call getImageStatus() to check what is
> > > the status of the image.
> > > The status of the image can be either optimized, degraded, or
> > > broken.
> > > "Optimized" means that the image is available and you can run VMs
> > > of it.
> > > "Degraded" means that the image is available and will run VMs but
> > > it might be a better way VDSM can represent the underlying data.
> > > "Broken" means that the image can't be used at the moment,
> > > probably
> > > because not all the data has been set up on the volume.
> > >
> > > Apart from that VDSM will also return the last persisted status
> > > information which will conatin
> > > hostID - the last host to try and optimize of fix the image
> > > stage - X/Y (eg. 1/10) the last persisted stage of the fix.
> > > percent_complete - -1 or 0-100, the last persisted completion
> > > percentage of the aforementioned stage. -1 means that no progress
> > > is available for that operation.
> > > last_error - This will only be filled if the operation failed
> > > because of something other then IO or a VDSM crash for obvious
> > > reasons.
> > >               It will usually be set if the task was manually
> > >               stopped
> > >
> > > The user can either be satisfied with that information or as the
> > > host specified in host ID if it is still working on that image by
> > > checking it's running tasks.
> > >
> > > checkStorageRepository(self, repositoryId, options={}):
> > > A method to go over a storage repository and scan for any
> > > existing
> > > problems. This includes degraded\broken images and deleted images
> > > that have no yet been physically deleted\merged.
> > > It returns a list of Fix objects.
> > > Fix objects come in 4 types:
> > > clean - cleans data, run them to get more space.
> > > optimize - run them to optimize a degraded image
> > > merge - Merges two images together. Doing this sometimes
> > >          makes more images ready optimizing or cleaning.
> > >          The reason it is different from optimize is that
> > >          unmerged images are considered optimized.
> > > mend - mends a broken image
> > >
> > > The user can read these types and prioritize fixes. Fixes also
> > > contain opaque FIX data and they should be sent as received to
> > > fixStorageRepository(self, repositoryId, fix, options={}):
> > >
> > > That will start a fix operation.
> > >
> > >
> > > All major operations automatically start the appropriate "Fix" to
> > > bring the created object to an optimize\degraded state (the one
> > > that is quicker) unless one of the options is
> > > AutoFix=False. This is only useful for repos that might not be
> > > able
> > > to create volumes on all hosts (SDM) but would like to have the
> > > actual IO distributed in the cluster.
> > >
> > > Other common options is the strategy option:
> > > It has currently 2 possible values
> > > space and performance - In case VDSM has 2 ways of completing the
> > > same operation it will tell it to value one over the other. For
> > > example, whether to copy all the data or just create a qcow based
> > > of a snapshot.
> > > The default is space.
> > >
> > > You might have also noticed that it is never explicitly specified
> > > where to look for existing images. This is done purposefully,
> > > VDSM
> > > will always look in all connected repositories for existing
> > > objects.
> > > For very large setups this might be problematic. To mitigate the
> > > problem you have these options:
> > > participatingRepositories=[repoId, ...] which tell VDSM to narrow
> > > the search to just these repositories
> > > and
> > > imageHints={imgId: repoId} which will force VDSM to look for
> > > those
> > > image ID just in those repositories and fail if it doesn't find
> > > them there.
> > > _______________________________________________
> > > vdsm-devel mailing list
> > > vdsm-devel at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > >
> > 
> > you are using VirtualDisk and Snapshot for mutable and immutable.
> > the terminology of "image" for immutable and "volume" for mutable
> > seems
> > to be the one used by ec2/openstack/etc. - any thoughts on using
> > similar
> > terminology?
> > (though i think they also differ in forcing all images to be in an
> > image
> > repo, and all volumes in a volume repo, while we allow to mix them
> > in
> > same repo).
> > 
> We have volumes internally though, I wanted to call them slabs but
> Ayal and Edu feel strongly about calling them volumes and the
> current naming system in general.

image and volume are overused everywhere and it would be extremely confusing to have multiple meanings to the same terms in the same system (we have image today which means virtual disk and volume which means a part of a virtual disk).
Personally I don't like the distinction between image and volume done in ec2/openstack/etc seeing as they're treated as different types of entities there while the only real difference is mutability (images are read-only, volumes are read-write).
To move to the industry terminology we would need to first change all references we have today to image and volume in the system (I would say also in ovirt-engine side) to align with the new meaning.
Despite my personal dislike of the terms, I definitely see the value in converging on the same terminology as the rest of the industry but to do so would be an arduous task which is out of scope of this discussion imo (patches welcome though ;)


> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


From abaron at redhat.com  Mon Jan 14 21:56:05 2013
From: abaron at redhat.com (Ayal Baron)
Date: Mon, 14 Jan 2013 16:56:05 -0500 (EST)
Subject: [Engine-devel] [vdsm] RFC: New Storage API
In-Reply-To: <1082511649.19310839.1355760817552.JavaMail.root@redhat.com>
Message-ID: <912822960.6030533.1358200565625.JavaMail.root@redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
> > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > Cc: "Shu Ming" <shuming at linux.vnet.ibm.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "VDSM Project Development"
> > <vdsm-devel at lists.fedorahosted.org>, "Deepak C Shetty"
> > <deepakcs at linux.vnet.ibm.com>
> > Sent: Sunday, December 16, 2012 11:40:01 PM
> > Subject: Re: [vdsm] RFC: New Storage API
> > 
> > On 12/08/2012 01:23 AM, Saggi Mizrahi wrote:
> > >
> > > ----- Original Message -----
> > >> From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
> > >> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > >> Cc: "Shu Ming" <shuming at linux.vnet.ibm.com>, "engine-devel"
> > >> <engine-devel at ovirt.org>, "VDSM Project Development"
> > >> <vdsm-devel at lists.fedorahosted.org>, "Deepak C Shetty"
> > >> <deepakcs at linux.vnet.ibm.com>
> > >> Sent: Friday, December 7, 2012 12:23:15 AM
> > >> Subject: Re: [vdsm] RFC: New Storage API
> > >>
> > >> On 12/06/2012 10:22 PM, Saggi Mizrahi wrote:
> > >>> ----- Original Message -----
> > >>>> From: "Shu Ming" <shuming at linux.vnet.ibm.com>
> > >>>> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > >>>> Cc: "VDSM Project Development"
> > >>>> <vdsm-devel at lists.fedorahosted.org>, "engine-devel"
> > >>>> <engine-devel at ovirt.org>
> > >>>> Sent: Thursday, December 6, 2012 11:02:02 AM
> > >>>> Subject: Re: [vdsm] RFC: New Storage API
> > >>>>
> > >>>> Saggi,
> > >>>>
> > >>>> Thanks for sharing your thought and I get some comments below.
> > >>>>
> > >>>>
> > >>>> Saggi Mizrahi:
> > >>>>> I've been throwing a lot of bits out about the new storage
> > >>>>> API
> > >>>>> and
> > >>>>> I think it's time to talk a bit.
> > >>>>> I will purposefully try and keep implementation details away
> > >>>>> and
> > >>>>> concentrate about how the API looks and how you use it.
> > >>>>>
> > >>>>> First major change is in terminology, there is no long a
> > >>>>> storage
> > >>>>> domain but a storage repository.
> > >>>>> This change is done because so many things are already called
> > >>>>> domain in the system and this will make things less confusing
> > >>>>> for
> > >>>>> new-commers with a libvirt background.
> > >>>>>
> > >>>>> One other changes is that repositories no longer have a UUID.
> > >>>>> The UUID was only used in the pool members manifest and is no
> > >>>>> longer needed.
> > >>>>>
> > >>>>>
> > >>>>> connectStorageRepository(repoId, repoFormat,
> > >>>>> connectionParameters={}):
> > >>>>> repoId - is a transient name that will be used to refer to
> > >>>>> the
> > >>>>> connected domain, it is not persisted and doesn't have to be
> > >>>>> the
> > >>>>> same across the cluster.
> > >>>>> repoFormat - Similar to what used to be type (eg.
> > >>>>> localfs-1.0,
> > >>>>> nfs-3.4, clvm-1.2).
> > >>>>> connectionParameters - This is format specific and will used
> > >>>>> to
> > >>>>> tell VDSM how to connect to the repo.
> > >>>> Where does repoID come from? I think repoID doesn't exist
> > >>>> before
> > >>>> connectStorageRepository() return.  Isn't repoID a return
> > >>>> value
> > >>>> of
> > >>>> connectStorageRepository()?
> > >>> No, repoIDs are no longer part of the domain, they are just a
> > >>> transient handle.
> > >>> The user can put whatever it wants there as long as it isn't
> > >>> already taken by another currently connected domain.
> > >> So what happens when user mistakenly gives a repoID that is in
> > >> use
> > >> before.. there should be something in the return value that
> > >> specifies
> > >> the error and/or reason for error so that user can try with a
> > >> new/diff
> > >> repoID ?
> > > Asi I said, connect fails if the repoId is in use ATM.
> > >>>>> disconnectStorageRepository(self, repoId)
> > >>>>>
> > >>>>>
> > >>>>> In the new API there are only images, some images are mutable
> > >>>>> and
> > >>>>> some are not.
> > >>>>> mutable images are also called VirtualDisks
> > >>>>> immutable images are also called Snapshots
> > >>>>>
> > >>>>> There are no explicit templates, you can create as many
> > >>>>> images
> > >>>>> as
> > >>>>> you want from any snapshot.
> > >>>>>
> > >>>>> There are 4 major image operations:
> > >>>>>
> > >>>>>
> > >>>>> createVirtualDisk(targetRepoId, size, baseSnapshotId=None,
> > >>>>>                      userData={}, options={}):
> > >>>>>
> > >>>>> targetRepoId - ID of a connected repo where the disk will be
> > >>>>> created
> > >>>>> size - The size of the image you wish to create
> > >>>>> baseSnapshotId - the ID of the snapshot you want the base the
> > >>>>> new
> > >>>>> virtual disk on
> > >>>>> userData - optional data that will be attached to the new VD,
> > >>>>> could
> > >>>>> be anything that the user desires.
> > >>>>> options - options to modify VDSMs default behavior
> > >> IIUC, i can use options to do storage offloads ? For eg. I can
> > >> create
> > >> a
> > >> LUN that represents this VD on my storage array based on the
> > >> 'options'
> > >> parameter ? Is this the intended way to use 'options' ?
> > > No, this has nothing to do with offloads.
> > > If by "offloads" you mean having other VDSM hosts to the heavy
> > > lifting then this is what the option autoFix=False and the fix
> > > mechanism is for.
> > > If you are talking about advanced scsi features (ie. write same)
> > > they will be used automatically whenever possible.
> > > In any case, how we manage LUNs (if they are even used) is an
> > > implementation detail.
> > 
> > I am a bit more interested in how storage array offloads ( by that
> > I
> > mean, offload VD creation, snapshot, clone etc to the storage array
> > when
> > available/possible) can be done from VDSM ?
> > In the past there were talks of using libSM to do that. How does
> > that
> > strategy play in this new Storage API scenario ? I agree its implmn
> > detail, but how & where does that implm sit and how it would be
> > triggered is not very clear to me. Looking at createVD args, it
> > sounded
> > like 'options' seems to be a trigger point for deciding whether to
> > use
> > storage offloads or not, but you spoke otherwise :) Can you provide
> > your
> > vision on how VDSM can understand the storage array capabilities &
> > exploit storgae array offloads in this New Storage API context ? --
> > Thanks deepak
> Some will be used automatically whenever possible (storage
> offloading).
> Features that favor a specific strategy will be activated when the
> proper strategy (space, performance) option is selected.
> In cases when only the user can know whether to use a feature or not
> we will have options to turn that on.
> In any case every domain exports a capability list through
> GetRepositoryCapabilities() that returns a list off repository
> capabilities.
> Some capabilities are VDSM specific like CLUSTERED or REQUIRES_SRM.
> Some are storage capabilities like NATIVE_SNAPSHOTS,
> NATIVE_THIN_PROVISIONING, SPARSE_VOLUMES, etc...
> 
> We are also considering an override mechanism where you can disable
> features in storage that supports it by setting it in the domain
> options. This will be done with NO_XXXXX (eg. NO_NATIVE_SNAPSHOTS).
> This will make the domain not use or expose the capability through
> the API. I assume it will only be used for testing or in cases where
> the storage array is known to have problems with a certain feature.
> Not everything can be disables as an example there is no real way to
> disable NATIVE_THING_PROVISIONING or SPARSE_VOLUMES.

Saggi, there are several different discussions going on here which I think require some clearing up (and perhaps splitting).
what I think is missing here:
1. distinction of what we believe should be at repo level and what at disk level 
    e.g. pre/postZero at repo level, native snapshots as described above would also be repo level (not defined per disk) etc.
2. how/where storage offload would work? is there a single implementation for repos which detects automatically storage capabilities or repo class for each storage type
3. and biggest topic is probably - a mapping of the image operations and details about the flows (did you send something about that?) - i.e. create vdisk flow, copy, etc.



> > 
> > 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


From smizrahi at redhat.com  Mon Jan 14 22:31:28 2013
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Mon, 14 Jan 2013 17:31:28 -0500 (EST)
Subject: [Engine-devel] [vdsm] RFC: New Storage API
In-Reply-To: <912822960.6030533.1358200565625.JavaMail.root@redhat.com>
Message-ID: <896073905.1639647.1358202688715.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "Deepak
> C Shetty" <deepakcs at linux.vnet.ibm.com>
> Sent: Monday, January 14, 2013 4:56:05 PM
> Subject: Re: [vdsm] RFC: New Storage API
> 
> 
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
> > > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > Cc: "Shu Ming" <shuming at linux.vnet.ibm.com>, "engine-devel"
> > > <engine-devel at ovirt.org>, "VDSM Project Development"
> > > <vdsm-devel at lists.fedorahosted.org>, "Deepak C Shetty"
> > > <deepakcs at linux.vnet.ibm.com>
> > > Sent: Sunday, December 16, 2012 11:40:01 PM
> > > Subject: Re: [vdsm] RFC: New Storage API
> > > 
> > > On 12/08/2012 01:23 AM, Saggi Mizrahi wrote:
> > > >
> > > > ----- Original Message -----
> > > >> From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
> > > >> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > >> Cc: "Shu Ming" <shuming at linux.vnet.ibm.com>, "engine-devel"
> > > >> <engine-devel at ovirt.org>, "VDSM Project Development"
> > > >> <vdsm-devel at lists.fedorahosted.org>, "Deepak C Shetty"
> > > >> <deepakcs at linux.vnet.ibm.com>
> > > >> Sent: Friday, December 7, 2012 12:23:15 AM
> > > >> Subject: Re: [vdsm] RFC: New Storage API
> > > >>
> > > >> On 12/06/2012 10:22 PM, Saggi Mizrahi wrote:
> > > >>> ----- Original Message -----
> > > >>>> From: "Shu Ming" <shuming at linux.vnet.ibm.com>
> > > >>>> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > >>>> Cc: "VDSM Project Development"
> > > >>>> <vdsm-devel at lists.fedorahosted.org>, "engine-devel"
> > > >>>> <engine-devel at ovirt.org>
> > > >>>> Sent: Thursday, December 6, 2012 11:02:02 AM
> > > >>>> Subject: Re: [vdsm] RFC: New Storage API
> > > >>>>
> > > >>>> Saggi,
> > > >>>>
> > > >>>> Thanks for sharing your thought and I get some comments
> > > >>>> below.
> > > >>>>
> > > >>>>
> > > >>>> Saggi Mizrahi:
> > > >>>>> I've been throwing a lot of bits out about the new storage
> > > >>>>> API
> > > >>>>> and
> > > >>>>> I think it's time to talk a bit.
> > > >>>>> I will purposefully try and keep implementation details
> > > >>>>> away
> > > >>>>> and
> > > >>>>> concentrate about how the API looks and how you use it.
> > > >>>>>
> > > >>>>> First major change is in terminology, there is no long a
> > > >>>>> storage
> > > >>>>> domain but a storage repository.
> > > >>>>> This change is done because so many things are already
> > > >>>>> called
> > > >>>>> domain in the system and this will make things less
> > > >>>>> confusing
> > > >>>>> for
> > > >>>>> new-commers with a libvirt background.
> > > >>>>>
> > > >>>>> One other changes is that repositories no longer have a
> > > >>>>> UUID.
> > > >>>>> The UUID was only used in the pool members manifest and is
> > > >>>>> no
> > > >>>>> longer needed.
> > > >>>>>
> > > >>>>>
> > > >>>>> connectStorageRepository(repoId, repoFormat,
> > > >>>>> connectionParameters={}):
> > > >>>>> repoId - is a transient name that will be used to refer to
> > > >>>>> the
> > > >>>>> connected domain, it is not persisted and doesn't have to
> > > >>>>> be
> > > >>>>> the
> > > >>>>> same across the cluster.
> > > >>>>> repoFormat - Similar to what used to be type (eg.
> > > >>>>> localfs-1.0,
> > > >>>>> nfs-3.4, clvm-1.2).
> > > >>>>> connectionParameters - This is format specific and will
> > > >>>>> used
> > > >>>>> to
> > > >>>>> tell VDSM how to connect to the repo.
> > > >>>> Where does repoID come from? I think repoID doesn't exist
> > > >>>> before
> > > >>>> connectStorageRepository() return.  Isn't repoID a return
> > > >>>> value
> > > >>>> of
> > > >>>> connectStorageRepository()?
> > > >>> No, repoIDs are no longer part of the domain, they are just a
> > > >>> transient handle.
> > > >>> The user can put whatever it wants there as long as it isn't
> > > >>> already taken by another currently connected domain.
> > > >> So what happens when user mistakenly gives a repoID that is in
> > > >> use
> > > >> before.. there should be something in the return value that
> > > >> specifies
> > > >> the error and/or reason for error so that user can try with a
> > > >> new/diff
> > > >> repoID ?
> > > > Asi I said, connect fails if the repoId is in use ATM.
> > > >>>>> disconnectStorageRepository(self, repoId)
> > > >>>>>
> > > >>>>>
> > > >>>>> In the new API there are only images, some images are
> > > >>>>> mutable
> > > >>>>> and
> > > >>>>> some are not.
> > > >>>>> mutable images are also called VirtualDisks
> > > >>>>> immutable images are also called Snapshots
> > > >>>>>
> > > >>>>> There are no explicit templates, you can create as many
> > > >>>>> images
> > > >>>>> as
> > > >>>>> you want from any snapshot.
> > > >>>>>
> > > >>>>> There are 4 major image operations:
> > > >>>>>
> > > >>>>>
> > > >>>>> createVirtualDisk(targetRepoId, size, baseSnapshotId=None,
> > > >>>>>                      userData={}, options={}):
> > > >>>>>
> > > >>>>> targetRepoId - ID of a connected repo where the disk will
> > > >>>>> be
> > > >>>>> created
> > > >>>>> size - The size of the image you wish to create
> > > >>>>> baseSnapshotId - the ID of the snapshot you want the base
> > > >>>>> the
> > > >>>>> new
> > > >>>>> virtual disk on
> > > >>>>> userData - optional data that will be attached to the new
> > > >>>>> VD,
> > > >>>>> could
> > > >>>>> be anything that the user desires.
> > > >>>>> options - options to modify VDSMs default behavior
> > > >> IIUC, i can use options to do storage offloads ? For eg. I can
> > > >> create
> > > >> a
> > > >> LUN that represents this VD on my storage array based on the
> > > >> 'options'
> > > >> parameter ? Is this the intended way to use 'options' ?
> > > > No, this has nothing to do with offloads.
> > > > If by "offloads" you mean having other VDSM hosts to the heavy
> > > > lifting then this is what the option autoFix=False and the fix
> > > > mechanism is for.
> > > > If you are talking about advanced scsi features (ie. write
> > > > same)
> > > > they will be used automatically whenever possible.
> > > > In any case, how we manage LUNs (if they are even used) is an
> > > > implementation detail.
> > > 
> > > I am a bit more interested in how storage array offloads ( by
> > > that
> > > I
> > > mean, offload VD creation, snapshot, clone etc to the storage
> > > array
> > > when
> > > available/possible) can be done from VDSM ?
> > > In the past there were talks of using libSM to do that. How does
> > > that
> > > strategy play in this new Storage API scenario ? I agree its
> > > implmn
> > > detail, but how & where does that implm sit and how it would be
> > > triggered is not very clear to me. Looking at createVD args, it
> > > sounded
> > > like 'options' seems to be a trigger point for deciding whether
> > > to
> > > use
> > > storage offloads or not, but you spoke otherwise :) Can you
> > > provide
> > > your
> > > vision on how VDSM can understand the storage array capabilities
> > > &
> > > exploit storgae array offloads in this New Storage API context ?
> > > --
> > > Thanks deepak
> > Some will be used automatically whenever possible (storage
> > offloading).
> > Features that favor a specific strategy will be activated when the
> > proper strategy (space, performance) option is selected.
> > In cases when only the user can know whether to use a feature or
> > not
> > we will have options to turn that on.
> > In any case every domain exports a capability list through
> > GetRepositoryCapabilities() that returns a list off repository
> > capabilities.
> > Some capabilities are VDSM specific like CLUSTERED or REQUIRES_SRM.
> > Some are storage capabilities like NATIVE_SNAPSHOTS,
> > NATIVE_THIN_PROVISIONING, SPARSE_VOLUMES, etc...
> > 
> > We are also considering an override mechanism where you can disable
> > features in storage that supports it by setting it in the domain
> > options. This will be done with NO_XXXXX (eg. NO_NATIVE_SNAPSHOTS).
> > This will make the domain not use or expose the capability through
> > the API. I assume it will only be used for testing or in cases
> > where
> > the storage array is known to have problems with a certain feature.
> > Not everything can be disables as an example there is no real way
> > to
> > disable NATIVE_THING_PROVISIONING or SPARSE_VOLUMES.
> 
> Saggi, there are several different discussions going on here which I
> think require some clearing up (and perhaps splitting).
> what I think is missing here:
> 1. distinction of what we believe should be at repo level and what at
> disk level
>     e.g. pre/postZero at repo level, native snapshots as described
>     above would also be repo level (not defined per disk) etc.
No option is inherently repo or disk based (even the ones you mantioned).
It all depends on the VDSM version you are interacting with. I am open to
the suggestion on having a way to query whether certain options are
supported by what operation and in what level dynamically.

As for post-zeroing, currently it is kind of insulting to our users that
we push it as a solution to prevent new VMs from reading old VMs data. It
is just not what it does. It will be replaced with pre-zeroing.

The only reason I see for post zeroing is the "wipe HDD before selling it off"
use case but I don't see how it is valid in virtualized environments especially
with enterprise storage.

> 2. how/where storage offload would work? is there a single
> implementation for repos which detects automatically storage
> capabilities or repo class for each storage type
They will be used automatically if available and supported by VDSM and the
repo format. It doesn't matter to this section of the API whether the user
will have to manually create repositories in specific formats or if it will
be automatic. As it seems, it will probably be automatically.
> 3. and biggest topic is probably - a mapping of the image operations
> and details about the flows (did you send something about that?) -
> i.e. create vdisk flow, copy, etc.
The flows you suggest here are basic flows supported with a single API call.

Because of the nature of image states users need to have a mechanism to
track said image states and make sure fixes are running (if desired)

Everyone is welcome to give it a shot and see how they can implement high
level flows using this API in their own systems. I don't mind helping people
figure it out, just ask.
> 
> 
> 
> > > 
> > > 
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > 
> 


From abaron at redhat.com  Mon Jan 14 23:23:32 2013
From: abaron at redhat.com (Ayal Baron)
Date: Mon, 14 Jan 2013 18:23:32 -0500 (EST)
Subject: [Engine-devel] [vdsm] RFC: New Storage API
In-Reply-To: <896073905.1639647.1358202688715.JavaMail.root@redhat.com>
Message-ID: <1498912724.6046913.1358205812143.JavaMail.root@redhat.com>



----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Ayal Baron" <abaron at redhat.com>
> > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "VDSM Project
> > Development" <vdsm-devel at lists.fedorahosted.org>, "Deepak
> > C Shetty" <deepakcs at linux.vnet.ibm.com>
> > Sent: Monday, January 14, 2013 4:56:05 PM
> > Subject: Re: [vdsm] RFC: New Storage API
> > 
> > 
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
> > > > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > > Cc: "Shu Ming" <shuming at linux.vnet.ibm.com>, "engine-devel"
> > > > <engine-devel at ovirt.org>, "VDSM Project Development"
> > > > <vdsm-devel at lists.fedorahosted.org>, "Deepak C Shetty"
> > > > <deepakcs at linux.vnet.ibm.com>
> > > > Sent: Sunday, December 16, 2012 11:40:01 PM
> > > > Subject: Re: [vdsm] RFC: New Storage API
> > > > 
> > > > On 12/08/2012 01:23 AM, Saggi Mizrahi wrote:
> > > > >
> > > > > ----- Original Message -----
> > > > >> From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
> > > > >> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > > >> Cc: "Shu Ming" <shuming at linux.vnet.ibm.com>, "engine-devel"
> > > > >> <engine-devel at ovirt.org>, "VDSM Project Development"
> > > > >> <vdsm-devel at lists.fedorahosted.org>, "Deepak C Shetty"
> > > > >> <deepakcs at linux.vnet.ibm.com>
> > > > >> Sent: Friday, December 7, 2012 12:23:15 AM
> > > > >> Subject: Re: [vdsm] RFC: New Storage API
> > > > >>
> > > > >> On 12/06/2012 10:22 PM, Saggi Mizrahi wrote:
> > > > >>> ----- Original Message -----
> > > > >>>> From: "Shu Ming" <shuming at linux.vnet.ibm.com>
> > > > >>>> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > > >>>> Cc: "VDSM Project Development"
> > > > >>>> <vdsm-devel at lists.fedorahosted.org>, "engine-devel"
> > > > >>>> <engine-devel at ovirt.org>
> > > > >>>> Sent: Thursday, December 6, 2012 11:02:02 AM
> > > > >>>> Subject: Re: [vdsm] RFC: New Storage API
> > > > >>>>
> > > > >>>> Saggi,
> > > > >>>>
> > > > >>>> Thanks for sharing your thought and I get some comments
> > > > >>>> below.
> > > > >>>>
> > > > >>>>
> > > > >>>> Saggi Mizrahi:
> > > > >>>>> I've been throwing a lot of bits out about the new
> > > > >>>>> storage
> > > > >>>>> API
> > > > >>>>> and
> > > > >>>>> I think it's time to talk a bit.
> > > > >>>>> I will purposefully try and keep implementation details
> > > > >>>>> away
> > > > >>>>> and
> > > > >>>>> concentrate about how the API looks and how you use it.
> > > > >>>>>
> > > > >>>>> First major change is in terminology, there is no long a
> > > > >>>>> storage
> > > > >>>>> domain but a storage repository.
> > > > >>>>> This change is done because so many things are already
> > > > >>>>> called
> > > > >>>>> domain in the system and this will make things less
> > > > >>>>> confusing
> > > > >>>>> for
> > > > >>>>> new-commers with a libvirt background.
> > > > >>>>>
> > > > >>>>> One other changes is that repositories no longer have a
> > > > >>>>> UUID.
> > > > >>>>> The UUID was only used in the pool members manifest and
> > > > >>>>> is
> > > > >>>>> no
> > > > >>>>> longer needed.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> connectStorageRepository(repoId, repoFormat,
> > > > >>>>> connectionParameters={}):
> > > > >>>>> repoId - is a transient name that will be used to refer
> > > > >>>>> to
> > > > >>>>> the
> > > > >>>>> connected domain, it is not persisted and doesn't have to
> > > > >>>>> be
> > > > >>>>> the
> > > > >>>>> same across the cluster.
> > > > >>>>> repoFormat - Similar to what used to be type (eg.
> > > > >>>>> localfs-1.0,
> > > > >>>>> nfs-3.4, clvm-1.2).
> > > > >>>>> connectionParameters - This is format specific and will
> > > > >>>>> used
> > > > >>>>> to
> > > > >>>>> tell VDSM how to connect to the repo.
> > > > >>>> Where does repoID come from? I think repoID doesn't exist
> > > > >>>> before
> > > > >>>> connectStorageRepository() return.  Isn't repoID a return
> > > > >>>> value
> > > > >>>> of
> > > > >>>> connectStorageRepository()?
> > > > >>> No, repoIDs are no longer part of the domain, they are just
> > > > >>> a
> > > > >>> transient handle.
> > > > >>> The user can put whatever it wants there as long as it
> > > > >>> isn't
> > > > >>> already taken by another currently connected domain.
> > > > >> So what happens when user mistakenly gives a repoID that is
> > > > >> in
> > > > >> use
> > > > >> before.. there should be something in the return value that
> > > > >> specifies
> > > > >> the error and/or reason for error so that user can try with
> > > > >> a
> > > > >> new/diff
> > > > >> repoID ?
> > > > > Asi I said, connect fails if the repoId is in use ATM.
> > > > >>>>> disconnectStorageRepository(self, repoId)
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> In the new API there are only images, some images are
> > > > >>>>> mutable
> > > > >>>>> and
> > > > >>>>> some are not.
> > > > >>>>> mutable images are also called VirtualDisks
> > > > >>>>> immutable images are also called Snapshots
> > > > >>>>>
> > > > >>>>> There are no explicit templates, you can create as many
> > > > >>>>> images
> > > > >>>>> as
> > > > >>>>> you want from any snapshot.
> > > > >>>>>
> > > > >>>>> There are 4 major image operations:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> createVirtualDisk(targetRepoId, size,
> > > > >>>>> baseSnapshotId=None,
> > > > >>>>>                      userData={}, options={}):
> > > > >>>>>
> > > > >>>>> targetRepoId - ID of a connected repo where the disk will
> > > > >>>>> be
> > > > >>>>> created
> > > > >>>>> size - The size of the image you wish to create
> > > > >>>>> baseSnapshotId - the ID of the snapshot you want the base
> > > > >>>>> the
> > > > >>>>> new
> > > > >>>>> virtual disk on
> > > > >>>>> userData - optional data that will be attached to the new
> > > > >>>>> VD,
> > > > >>>>> could
> > > > >>>>> be anything that the user desires.
> > > > >>>>> options - options to modify VDSMs default behavior
> > > > >> IIUC, i can use options to do storage offloads ? For eg. I
> > > > >> can
> > > > >> create
> > > > >> a
> > > > >> LUN that represents this VD on my storage array based on the
> > > > >> 'options'
> > > > >> parameter ? Is this the intended way to use 'options' ?
> > > > > No, this has nothing to do with offloads.
> > > > > If by "offloads" you mean having other VDSM hosts to the
> > > > > heavy
> > > > > lifting then this is what the option autoFix=False and the
> > > > > fix
> > > > > mechanism is for.
> > > > > If you are talking about advanced scsi features (ie. write
> > > > > same)
> > > > > they will be used automatically whenever possible.
> > > > > In any case, how we manage LUNs (if they are even used) is an
> > > > > implementation detail.
> > > > 
> > > > I am a bit more interested in how storage array offloads ( by
> > > > that
> > > > I
> > > > mean, offload VD creation, snapshot, clone etc to the storage
> > > > array
> > > > when
> > > > available/possible) can be done from VDSM ?
> > > > In the past there were talks of using libSM to do that. How
> > > > does
> > > > that
> > > > strategy play in this new Storage API scenario ? I agree its
> > > > implmn
> > > > detail, but how & where does that implm sit and how it would be
> > > > triggered is not very clear to me. Looking at createVD args, it
> > > > sounded
> > > > like 'options' seems to be a trigger point for deciding whether
> > > > to
> > > > use
> > > > storage offloads or not, but you spoke otherwise :) Can you
> > > > provide
> > > > your
> > > > vision on how VDSM can understand the storage array
> > > > capabilities
> > > > &
> > > > exploit storgae array offloads in this New Storage API context
> > > > ?
> > > > --
> > > > Thanks deepak
> > > Some will be used automatically whenever possible (storage
> > > offloading).
> > > Features that favor a specific strategy will be activated when
> > > the
> > > proper strategy (space, performance) option is selected.
> > > In cases when only the user can know whether to use a feature or
> > > not
> > > we will have options to turn that on.
> > > In any case every domain exports a capability list through
> > > GetRepositoryCapabilities() that returns a list off repository
> > > capabilities.
> > > Some capabilities are VDSM specific like CLUSTERED or
> > > REQUIRES_SRM.
> > > Some are storage capabilities like NATIVE_SNAPSHOTS,
> > > NATIVE_THIN_PROVISIONING, SPARSE_VOLUMES, etc...
> > > 
> > > We are also considering an override mechanism where you can
> > > disable
> > > features in storage that supports it by setting it in the domain
> > > options. This will be done with NO_XXXXX (eg.
> > > NO_NATIVE_SNAPSHOTS).
> > > This will make the domain not use or expose the capability
> > > through
> > > the API. I assume it will only be used for testing or in cases
> > > where
> > > the storage array is known to have problems with a certain
> > > feature.
> > > Not everything can be disables as an example there is no real way
> > > to
> > > disable NATIVE_THING_PROVISIONING or SPARSE_VOLUMES.
> > 
> > Saggi, there are several different discussions going on here which
> > I
> > think require some clearing up (and perhaps splitting).
> > what I think is missing here:
> > 1. distinction of what we believe should be at repo level and what
> > at
> > disk level
> >     e.g. pre/postZero at repo level, native snapshots as described
> >     above would also be repo level (not defined per disk) etc.
> No option is inherently repo or disk based (even the ones you
> mantioned).
> It all depends on the VDSM version you are interacting with. I am
> open to
> the suggestion on having a way to query whether certain options are
> supported by what operation and in what level dynamically.
> 
> As for post-zeroing, currently it is kind of insulting to our users
> that
> we push it as a solution to prevent new VMs from reading old VMs
> data. It
> is just not what it does. It will be replaced with pre-zeroing.
> 
> The only reason I see for post zeroing is the "wipe HDD before
> selling it off"
> use case but I don't see how it is valid in virtualized environments
> especially
> with enterprise storage.

I have 2 problems with this:
1. you're assuming 'enterprise' storage and in cloud this is many times not the case at all.  On local storage it's pretty safe to assume that what you see is what you get (on block devices at least).
2. we have requests to in fact add additional wiping algorithms to really clean things up exactly for the 'wipe HDD before selling it off' scenario (only valid of course if we actually write on the relevant sectors which is something we cannot guarantee, but with the right disclaimers, this should be fine).

Rethinking this, at most post-zero is wasteful, but storage array should guarantee that next time data is read from disk then zeros are served (if it doesn't then it's a security flaw on the storage side which we shouldn't care about).

> 
> > 2. how/where storage offload would work? is there a single
> > implementation for repos which detects automatically storage
> > capabilities or repo class for each storage type
> They will be used automatically if available and supported by VDSM
> and the
> repo format. It doesn't matter to this section of the API whether the
> user
> will have to manually create repositories in specific formats or if
> it will
> be automatic. As it seems, it will probably be automatically.
> > 3. and biggest topic is probably - a mapping of the image
> > operations
> > and details about the flows (did you send something about that?) -
> > i.e. create vdisk flow, copy, etc.
> The flows you suggest here are basic flows supported with a single
> API call.
> 
> Because of the nature of image states users need to have a mechanism
> to
> track said image states and make sure fixes are running (if desired)
> 
> Everyone is welcome to give it a shot and see how they can implement
> high
> level flows using this API in their own systems. I don't mind helping
> people
> figure it out, just ask.

Actually I meant the new images API flows here (i.e. the internals, not how to use it).

> > 
> > 
> > 
> > > > 
> > > > 
> > > _______________________________________________
> > > vdsm-devel mailing list
> > > vdsm-devel at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > 
> > 
> 


From mpastern at redhat.com  Tue Jan 15 14:40:46 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 15 Jan 2013 16:40:46 +0200
Subject: [Engine-devel] ovirt-engine-sdk-java 1.0.0.1 released
Message-ID: <50F56A6E.1090909@redhat.com>

Hi all,

I'm happy to announce first official release of ovirt-engine-sdk-java, change log
between sdk announcement and 1.0.0.1 is:

   * Tue Jan  15 2013 Michael Pasternak <mpastern at redhat.com> - 1.0.0.1-1
    - implement parametrized list() methods
    - events can be added now (user defined events)
    - events can be removed now
    - host can be added now by using cluster.name (not only cluster-id)
    - NIC now has "linked" property
    - NIC now has "plugged" property
    - VM has now ReportedDevices sub-collection
    - VMNIC has now ReportedDevices sub-collection
    - to host add/update added power_management.agents parameter
    - to disk added permissions sub-collection
    - to PowerManagement added Agents collection
    - to VMDisk added move() action
    - to host added hooks sub-collection
    - to cluster added threads_as_cores property
    - to host added hardwareInformation property
    - to host added OS property
    - added force flag to the host.delete() method
    - added host.power_management.pm_proxy sub-collection
    - added permissions sub-collection to the network
    - added search capabilities to api.networks collection
    - added deletion protection support to template/vm via .delete_protected property

More details can be found at [1].

[1] http://www.ovirt.org/Java-sdk-changelog

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Tue Jan 15 14:41:16 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 15 Jan 2013 16:41:16 +0200
Subject: [Engine-devel] ovirt-engine-sdk-java package available via maven
	distribution now
Message-ID: <50F56A8C.7080209@redhat.com>


All you need to work with oVirt java-sdk is add it as dependency
to your pom.xml,

for more details see [1].

[1] http://www.ovirt.org/Java-sdk#Maven_deployment

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Tue Jan 15 15:28:25 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 15 Jan 2013 17:28:25 +0200
Subject: [Engine-devel] [Users] ovirt-engine-sdk-java package available
 via maven distribution now
In-Reply-To: <50F56A8C.7080209@redhat.com>
References: <50F56A8C.7080209@redhat.com>
Message-ID: <50F57599.2000805@redhat.com>

On 01/15/2013 04:41 PM, Michael Pasternak wrote:
> 
> All you need to work with oVirt java-sdk is add it as dependency
> to your pom.xml,
> 
> for more details see [1].
> 
> [1] http://www.ovirt.org/Java-sdk#Maven_deployment
> 


=> javaDoc can be downloaded via "mvn dependency:resolve -Dclassifier=javadoc" command

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From Chris.Frantz at hp.com  Tue Jan 15 19:57:11 2013
From: Chris.Frantz at hp.com (Frantz, Chris)
Date: Tue, 15 Jan 2013 19:57:11 +0000
Subject: [Engine-devel] Unable to add a Host
Message-ID: <A24D665DC3ECC245A2EA0D9A958F80B631C2995B@G9W0733.americas.hpqcorp.net>

Hello,

I've just built and deployed the latest ovirt-engine (and otopi and ovirt-host-deploy), but I'm unable to add a host to my default cluster.

When I try to add a host, I get a message like this in the event log:

Host vsr19e1b4 installation failed. CallableStatementCallback; SQL [{call insertauditlog(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: invalid byte sequence for encoding "UTF8": 0x00; nested exception is org.postgresql.util.PSQLException: ERROR: invalid byte sequence for encoding "UTF8": 0x00.

If I log into the target host and examine /tmp/ovirt-host-deploy-*.log, I see something rather peculiar:

2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:213 DIALOG:SEND       ***CONFIRM DEPLOY_PROCEED Proceed with ovirt-host-deploy
2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:213 DIALOG:SEND       ### Continuing will configure this host for serving as hypervisor. Are you sure you want to continue? (yes/no)
2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:213 DIALOG:SEND       ### Response is CONFIRM DEPLOY_PROCEED=yes|no or ABORT DEPLOY_PROCEED
2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:213 DIALOG:RECEIVE   [10240 nul bytes]CONFIRM DEPLOY_PROCEED=yes
2013-01-14 12:45:59 DEBUG otopi.context context._executeMethod:127 method exception
Traceback (most recent call last):
  File "/tmp/ovirt-tOAzfQ4mqS/pythonlib/otopi/context.py", line 117, in _executeMethod
    method['method']()
  File "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/ovirt-host-deploy/core/misc.py", line 74, in _confirm
    prompt=True,
  File "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/otopi/dialog/machine.py", line 338, in confirm
    code=opcode,

It seems that the confirmation message is received, but is preceded by 10k worth of nuls.  Has anyone seen anything like this before?  An ideas on what I've got wrong?

Thanks,
--Chris

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

From smizrahi at redhat.com  Tue Jan 15 21:37:49 2013
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Tue, 15 Jan 2013 16:37:49 -0500 (EST)
Subject: [Engine-devel] [vdsm] RFC: New Storage API
In-Reply-To: <1498912724.6046913.1358205812143.JavaMail.root@redhat.com>
Message-ID: <698094480.2068491.1358285869750.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "Deepak
> C Shetty" <deepakcs at linux.vnet.ibm.com>
> Sent: Monday, January 14, 2013 6:23:32 PM
> Subject: Re: [vdsm] RFC: New Storage API
> 
> 
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > From: "Ayal Baron" <abaron at redhat.com>
> > > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>, "VDSM Project
> > > Development" <vdsm-devel at lists.fedorahosted.org>, "Deepak
> > > C Shetty" <deepakcs at linux.vnet.ibm.com>
> > > Sent: Monday, January 14, 2013 4:56:05 PM
> > > Subject: Re: [vdsm] RFC: New Storage API
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
> > > > > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > > > Cc: "Shu Ming" <shuming at linux.vnet.ibm.com>, "engine-devel"
> > > > > <engine-devel at ovirt.org>, "VDSM Project Development"
> > > > > <vdsm-devel at lists.fedorahosted.org>, "Deepak C Shetty"
> > > > > <deepakcs at linux.vnet.ibm.com>
> > > > > Sent: Sunday, December 16, 2012 11:40:01 PM
> > > > > Subject: Re: [vdsm] RFC: New Storage API
> > > > > 
> > > > > On 12/08/2012 01:23 AM, Saggi Mizrahi wrote:
> > > > > >
> > > > > > ----- Original Message -----
> > > > > >> From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
> > > > > >> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > > > >> Cc: "Shu Ming" <shuming at linux.vnet.ibm.com>,
> > > > > >> "engine-devel"
> > > > > >> <engine-devel at ovirt.org>, "VDSM Project Development"
> > > > > >> <vdsm-devel at lists.fedorahosted.org>, "Deepak C Shetty"
> > > > > >> <deepakcs at linux.vnet.ibm.com>
> > > > > >> Sent: Friday, December 7, 2012 12:23:15 AM
> > > > > >> Subject: Re: [vdsm] RFC: New Storage API
> > > > > >>
> > > > > >> On 12/06/2012 10:22 PM, Saggi Mizrahi wrote:
> > > > > >>> ----- Original Message -----
> > > > > >>>> From: "Shu Ming" <shuming at linux.vnet.ibm.com>
> > > > > >>>> To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > > > >>>> Cc: "VDSM Project Development"
> > > > > >>>> <vdsm-devel at lists.fedorahosted.org>, "engine-devel"
> > > > > >>>> <engine-devel at ovirt.org>
> > > > > >>>> Sent: Thursday, December 6, 2012 11:02:02 AM
> > > > > >>>> Subject: Re: [vdsm] RFC: New Storage API
> > > > > >>>>
> > > > > >>>> Saggi,
> > > > > >>>>
> > > > > >>>> Thanks for sharing your thought and I get some comments
> > > > > >>>> below.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> Saggi Mizrahi:
> > > > > >>>>> I've been throwing a lot of bits out about the new
> > > > > >>>>> storage
> > > > > >>>>> API
> > > > > >>>>> and
> > > > > >>>>> I think it's time to talk a bit.
> > > > > >>>>> I will purposefully try and keep implementation details
> > > > > >>>>> away
> > > > > >>>>> and
> > > > > >>>>> concentrate about how the API looks and how you use it.
> > > > > >>>>>
> > > > > >>>>> First major change is in terminology, there is no long
> > > > > >>>>> a
> > > > > >>>>> storage
> > > > > >>>>> domain but a storage repository.
> > > > > >>>>> This change is done because so many things are already
> > > > > >>>>> called
> > > > > >>>>> domain in the system and this will make things less
> > > > > >>>>> confusing
> > > > > >>>>> for
> > > > > >>>>> new-commers with a libvirt background.
> > > > > >>>>>
> > > > > >>>>> One other changes is that repositories no longer have a
> > > > > >>>>> UUID.
> > > > > >>>>> The UUID was only used in the pool members manifest and
> > > > > >>>>> is
> > > > > >>>>> no
> > > > > >>>>> longer needed.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> connectStorageRepository(repoId, repoFormat,
> > > > > >>>>> connectionParameters={}):
> > > > > >>>>> repoId - is a transient name that will be used to refer
> > > > > >>>>> to
> > > > > >>>>> the
> > > > > >>>>> connected domain, it is not persisted and doesn't have
> > > > > >>>>> to
> > > > > >>>>> be
> > > > > >>>>> the
> > > > > >>>>> same across the cluster.
> > > > > >>>>> repoFormat - Similar to what used to be type (eg.
> > > > > >>>>> localfs-1.0,
> > > > > >>>>> nfs-3.4, clvm-1.2).
> > > > > >>>>> connectionParameters - This is format specific and will
> > > > > >>>>> used
> > > > > >>>>> to
> > > > > >>>>> tell VDSM how to connect to the repo.
> > > > > >>>> Where does repoID come from? I think repoID doesn't
> > > > > >>>> exist
> > > > > >>>> before
> > > > > >>>> connectStorageRepository() return.  Isn't repoID a
> > > > > >>>> return
> > > > > >>>> value
> > > > > >>>> of
> > > > > >>>> connectStorageRepository()?
> > > > > >>> No, repoIDs are no longer part of the domain, they are
> > > > > >>> just
> > > > > >>> a
> > > > > >>> transient handle.
> > > > > >>> The user can put whatever it wants there as long as it
> > > > > >>> isn't
> > > > > >>> already taken by another currently connected domain.
> > > > > >> So what happens when user mistakenly gives a repoID that
> > > > > >> is
> > > > > >> in
> > > > > >> use
> > > > > >> before.. there should be something in the return value
> > > > > >> that
> > > > > >> specifies
> > > > > >> the error and/or reason for error so that user can try
> > > > > >> with
> > > > > >> a
> > > > > >> new/diff
> > > > > >> repoID ?
> > > > > > Asi I said, connect fails if the repoId is in use ATM.
> > > > > >>>>> disconnectStorageRepository(self, repoId)
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> In the new API there are only images, some images are
> > > > > >>>>> mutable
> > > > > >>>>> and
> > > > > >>>>> some are not.
> > > > > >>>>> mutable images are also called VirtualDisks
> > > > > >>>>> immutable images are also called Snapshots
> > > > > >>>>>
> > > > > >>>>> There are no explicit templates, you can create as many
> > > > > >>>>> images
> > > > > >>>>> as
> > > > > >>>>> you want from any snapshot.
> > > > > >>>>>
> > > > > >>>>> There are 4 major image operations:
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> createVirtualDisk(targetRepoId, size,
> > > > > >>>>> baseSnapshotId=None,
> > > > > >>>>>                      userData={}, options={}):
> > > > > >>>>>
> > > > > >>>>> targetRepoId - ID of a connected repo where the disk
> > > > > >>>>> will
> > > > > >>>>> be
> > > > > >>>>> created
> > > > > >>>>> size - The size of the image you wish to create
> > > > > >>>>> baseSnapshotId - the ID of the snapshot you want the
> > > > > >>>>> base
> > > > > >>>>> the
> > > > > >>>>> new
> > > > > >>>>> virtual disk on
> > > > > >>>>> userData - optional data that will be attached to the
> > > > > >>>>> new
> > > > > >>>>> VD,
> > > > > >>>>> could
> > > > > >>>>> be anything that the user desires.
> > > > > >>>>> options - options to modify VDSMs default behavior
> > > > > >> IIUC, i can use options to do storage offloads ? For eg. I
> > > > > >> can
> > > > > >> create
> > > > > >> a
> > > > > >> LUN that represents this VD on my storage array based on
> > > > > >> the
> > > > > >> 'options'
> > > > > >> parameter ? Is this the intended way to use 'options' ?
> > > > > > No, this has nothing to do with offloads.
> > > > > > If by "offloads" you mean having other VDSM hosts to the
> > > > > > heavy
> > > > > > lifting then this is what the option autoFix=False and the
> > > > > > fix
> > > > > > mechanism is for.
> > > > > > If you are talking about advanced scsi features (ie. write
> > > > > > same)
> > > > > > they will be used automatically whenever possible.
> > > > > > In any case, how we manage LUNs (if they are even used) is
> > > > > > an
> > > > > > implementation detail.
> > > > > 
> > > > > I am a bit more interested in how storage array offloads ( by
> > > > > that
> > > > > I
> > > > > mean, offload VD creation, snapshot, clone etc to the storage
> > > > > array
> > > > > when
> > > > > available/possible) can be done from VDSM ?
> > > > > In the past there were talks of using libSM to do that. How
> > > > > does
> > > > > that
> > > > > strategy play in this new Storage API scenario ? I agree its
> > > > > implmn
> > > > > detail, but how & where does that implm sit and how it would
> > > > > be
> > > > > triggered is not very clear to me. Looking at createVD args,
> > > > > it
> > > > > sounded
> > > > > like 'options' seems to be a trigger point for deciding
> > > > > whether
> > > > > to
> > > > > use
> > > > > storage offloads or not, but you spoke otherwise :) Can you
> > > > > provide
> > > > > your
> > > > > vision on how VDSM can understand the storage array
> > > > > capabilities
> > > > > &
> > > > > exploit storgae array offloads in this New Storage API
> > > > > context
> > > > > ?
> > > > > --
> > > > > Thanks deepak
> > > > Some will be used automatically whenever possible (storage
> > > > offloading).
> > > > Features that favor a specific strategy will be activated when
> > > > the
> > > > proper strategy (space, performance) option is selected.
> > > > In cases when only the user can know whether to use a feature
> > > > or
> > > > not
> > > > we will have options to turn that on.
> > > > In any case every domain exports a capability list through
> > > > GetRepositoryCapabilities() that returns a list off repository
> > > > capabilities.
> > > > Some capabilities are VDSM specific like CLUSTERED or
> > > > REQUIRES_SRM.
> > > > Some are storage capabilities like NATIVE_SNAPSHOTS,
> > > > NATIVE_THIN_PROVISIONING, SPARSE_VOLUMES, etc...
> > > > 
> > > > We are also considering an override mechanism where you can
> > > > disable
> > > > features in storage that supports it by setting it in the
> > > > domain
> > > > options. This will be done with NO_XXXXX (eg.
> > > > NO_NATIVE_SNAPSHOTS).
> > > > This will make the domain not use or expose the capability
> > > > through
> > > > the API. I assume it will only be used for testing or in cases
> > > > where
> > > > the storage array is known to have problems with a certain
> > > > feature.
> > > > Not everything can be disables as an example there is no real
> > > > way
> > > > to
> > > > disable NATIVE_THING_PROVISIONING or SPARSE_VOLUMES.
> > > 
> > > Saggi, there are several different discussions going on here
> > > which
> > > I
> > > think require some clearing up (and perhaps splitting).
> > > what I think is missing here:
> > > 1. distinction of what we believe should be at repo level and
> > > what
> > > at
> > > disk level
> > >     e.g. pre/postZero at repo level, native snapshots as
> > >     described
> > >     above would also be repo level (not defined per disk) etc.
> > No option is inherently repo or disk based (even the ones you
> > mantioned).
> > It all depends on the VDSM version you are interacting with. I am
> > open to
> > the suggestion on having a way to query whether certain options are
> > supported by what operation and in what level dynamically.
> > 
> > As for post-zeroing, currently it is kind of insulting to our users
> > that
> > we push it as a solution to prevent new VMs from reading old VMs
> > data. It
> > is just not what it does. It will be replaced with pre-zeroing.
> > 
> > The only reason I see for post zeroing is the "wipe HDD before
> > selling it off"
> > use case but I don't see how it is valid in virtualized
> > environments
> > especially
> > with enterprise storage.
> 
> I have 2 problems with this:
> 1. you're assuming 'enterprise' storage and in cloud this is many
> times not the case at all.  On local storage it's pretty safe to
> assume that what you see is what you get (on block devices at
> least).
> 2. we have requests to in fact add additional wiping algorithms to
> really clean things up exactly for the 'wipe HDD before selling it
> off' scenario (only valid of course if we actually write on the
> relevant sectors which is something we cannot guarantee, but with
> the right disclaimers, this should be fine).
> 
> Rethinking this, at most post-zero is wasteful, but storage array
> should guarantee that next time data is read from disk then zeros
> are served (if it doesn't then it's a security flaw on the storage
> side which we shouldn't care about).
> 
> > 
> > > 2. how/where storage offload would work? is there a single
> > > implementation for repos which detects automatically storage
> > > capabilities or repo class for each storage type
> > They will be used automatically if available and supported by VDSM
> > and the
> > repo format. It doesn't matter to this section of the API whether
> > the
> > user
> > will have to manually create repositories in specific formats or if
> > it will
> > be automatic. As it seems, it will probably be automatically.
> > > 3. and biggest topic is probably - a mapping of the image
> > > operations
> > > and details about the flows (did you send something about that?)
> > > -
> > > i.e. create vdisk flow, copy, etc.
> > The flows you suggest here are basic flows supported with a single
> > API call.
> > 
> > Because of the nature of image states users need to have a
> > mechanism
> > to
> > track said image states and make sure fixes are running (if
> > desired)
> > 
> > Everyone is welcome to give it a shot and see how they can
> > implement
> > high
> > level flows using this API in their own systems. I don't mind
> > helping
> > people
> > figure it out, just ask.
> 
> Actually I meant the new images API flows here (i.e. the internals,
> not how to use it).
Well the internals are out of the scope of this discussion. I don't
think it matters. There is some stuff I put on the wiki but it is
a bit out of date at the moment, though the general principles remain
the same.

Further more, the main idea driving the the API is separating
implementation from it.

- Using intent (space vs performance) instead of implementations details
  (qcow vs raw).

- Removing explicit chains
- making the result of a copy operation allowed against any disk instead
  of forcing the user to understand copy\move(copyOP)\move(moveOP).

- Having fixes be opaque only describing purpose (merge\clean\optimize)
  instead of what the actually do.

- Making properties like SPM be dynamic and queried by the user instead
  of inherent to the repo format making it easier to support new
  implementation that share similar traits and remove\add constraints to
  the implementation between versions.

This, again, means that VDSM can implement the intent in any way it sees
fit as long as it keeps the semantics intact.

To make the burden of semantics to a minimum, the fact that images can be
created and remain in a "broken" or "degraded" state is introduced. This
means that even if a process takes a lot of time or might require specific
rare constraints, it can still be implemented through the creations of
intermediate states which leave the image in "degraded" state making the
VM operational but still giving room for further operations.

Having createXXXX() just mean.
I promise to try my best to create XXXXX here is the object ID YYYYYYY
gives way to just about any implementation desirable. You can even have
it put a file on the disk with the ID and the word "broken" and then
send an email to a person who will manually write the bits to another
file finishing by writing the path to the new disk and the word
"optimized" in it.

The well known open\read\write\close APIs are implemented in many ways
with many file systems. I also hope that when my implementation is
retired because everyone finds out how horrible it is the interface
could remain consistent.

The question I'm asking is whether the minimal set of operations given
and there very minimal set of commitments is enough for people to implement
higher level concepts as long as the semantics are kept by the
implementation.
> > > 
> > > 
> > > 
> > > > > 
> > > > > 
> > > > _______________________________________________
> > > > vdsm-devel mailing list
> > > > vdsm-devel at lists.fedorahosted.org
> > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > > 
> > > 
> > 
> 


From wei.d.chen at intel.com  Wed Jan 16 03:15:42 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Wed, 16 Jan 2013 03:15:42 +0000
Subject: [Engine-devel] Can not add a data storage
Message-ID: <C5A0092C63E939488005F15F736A8112111364@SHSMSX101.ccr.corp.intel.com>

Hi,

We are trying to setup separate ovirt engine/node environment, everything goes well except at the step of adding a data storage. It just says encountered some exception and failed to attach storage domain storage to data center default from admin portal. I found these error message like follow after checking engine.log
"
2013-01-16 10:50:38,518 WARN  [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase] (ajp--127.0.0.1-8702-7) [64091e1d] Weird return value: Class Name: org.ovirt.engine.core.vdsbroker.vdsbroker.StatusForXmlRpc
mCode                         661
mMessage                      Cannot acquire host id: ('23e02bc1-a9fa-4aee-b13a-255715aa96b9', SanlockException(-203, 'Sanlock lockspace add failure', 'Sanlock exception'))

2013-01-16 10:50:38,520 WARN  [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase] (ajp--127.0.0.1-8702-7) [64091e1d] Weird return value: Class Name: org.ovirt.engine.core.vdsbroker.vdsbroker.StatusForXmlRpc
mCode                         661
mMessage                      Cannot acquire host id: ('23e02bc1-a9fa-4aee-b13a-255715aa96b9', SanlockException(-203, 'Sanlock lockspace add failure', 'Sanlock exception'))
"

Some extra information:
Operation System:
Engine: Fedora17, Node: Fedora18.
Ovirt repo used for both engine and node: baseurl=http://ovirt.org/releases/nightly/rpm/Fedora/$releasever/

On engine's server I can mount the nfs directory created on node from successfully. Would you give us some suggestion on how to resolve this issue. Thanks in advance!




Best Regards,
Dave Chen

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

From alonbl at redhat.com  Wed Jan 16 07:45:34 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 16 Jan 2013 02:45:34 -0500 (EST)
Subject: [Engine-devel] Unable to add a Host
In-Reply-To: <A24D665DC3ECC245A2EA0D9A958F80B631C2995B@G9W0733.americas.hpqcorp.net>
Message-ID: <1669305395.1992733.1358322334735.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Chris Frantz" <Chris.Frantz at hp.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 15, 2013 9:57:11 PM
> Subject: [Engine-devel] Unable to add a Host
> 
> 
> 
> 
> 
> Hello,
> 
> 
> 
> I?ve just built and deployed the latest ovirt-engine (and otopi and
> ovirt-host-deploy), but I?m unable to add a host to my default
> cluster.
> 
> 
> 
> When I try to add a host, I get a message like this in the event log:
> 
> 
> 
> Host vsr19e1b4 installation failed. CallableStatementCallback; SQL
> [{call insertauditlog(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: invalid byte sequence for
> encoding "UTF8": 0x00; nested exception is
> org.postgresql.util.PSQLException: ERROR: invalid byte sequence for
> encoding "UTF8": 0x00.
> 
> 
> 
> If I log into the target host and examine
> /tmp/ovirt-host-deploy-*.log, I see something rather peculiar:
> 
> 
> 
> 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:213 DIALOG:SEND ***CONFIRM DEPLOY_PROCEED Proceed
> with ovirt-host-deploy
> 
> 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:213 DIALOG:SEND ### Continuing will configure
> this host for serving as hypervisor. Are you sure you want to
> continue? (yes/no)
> 
> 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:213 DIALOG:SEND ### Response is CONFIRM
> DEPLOY_PROCEED=yes|no or ABORT DEPLOY_PROCEED
> 
> 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:213 DIALOG:RECEIVE [10240 nul bytes]CONFIRM
> DEPLOY_PROCEED=yes
> 
> 2013-01-14 12:45:59 DEBUG otopi.context context._executeMethod:127
> method exception
> 
> Traceback (most recent call last):
> 
> File "/tmp/ovirt-tOAzfQ4mqS/pythonlib/otopi/context.py", line 117, in
> _executeMethod
> 
> method['method']()
> 
> File
> "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/ovirt-host-deploy/core/misc.py",
> line 74, in _confirm
> 
> prompt=True,
> 
> File "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/otopi/dialog/machine.py",
> line 338, in confirm
> 
> code=opcode,
> 
> 
> 
> It seems that the confirmation message is received, but is preceded
> by 10k worth of nuls. Has anyone seen anything like this before? An
> ideas on what I?ve got wrong?

This is strange... can you: stop engine, rm /var/log/ovirt-engine/engine.log, start engine, reproduce and attach engine.log?

Thanks!
Alon


From oschreib at redhat.com  Wed Jan 16 11:24:08 2013
From: oschreib at redhat.com (Ofer Schreiber)
Date: Wed, 16 Jan 2013 06:24:08 -0500 (EST)
Subject: [Engine-devel] 3.2 Beta build
Message-ID: <1020132204.4918845.1358335448270.JavaMail.root@redhat.com>

Hey,

I'm going to build ovirt-engine-3.2 beta build in one hour from now.
Please push important patches, and inform me if you know of any blocker.

Thanks,
Ofer Schreiber.


From mpastern at redhat.com  Wed Jan 16 14:38:02 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 16 Jan 2013 16:38:02 +0200
Subject: [Engine-devel] ovirt-engine-sdk-java 1.0.0.2 released
In-Reply-To: <50F56A6E.1090909@redhat.com>
References: <50F56A6E.1090909@redhat.com>
Message-ID: <50F6BB4A.7040602@redhat.com>


Basically this release addresses an issue when [1] constructor is used
with NULLs as optional parameters,

[1] public Api(String url, String username, String password, String key_file,
              String cert_file, String ca_file, Integer port, Integer timeout,
              Boolean persistentAuth, Boolean insecure, Boolean filter, Boolean debug)

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From thomas at parker.iz34.com  Wed Jan 16 15:00:06 2013
From: thomas at parker.iz34.com (thomas at parker.iz34.com)
Date: Wed, 16 Jan 2013 16:00:06 +0100
Subject: [Engine-devel] Change in ovirt-engine[master]: webadmin: Fix
	remove bricks	confirmation message
In-Reply-To: <201301161457.r0GEvZmK031911@gerrit.ovirt.org>
References: <201301161457.r0GEvZmK031911@gerrit.ovirt.org>
Message-ID: <201301161457.r0GEvZmK031911@gerrit.ovirt.org>

Gilad Chaplik has submitted this change and it was merged.

Change subject: webadmin: Fix remove bricks confirmation message
.....................................................................


webadmin: Fix remove bricks confirmation message

Changed the hash name to not add the remove message template.
And updated the confirmation message for replicate volumes
to make it uniform.

Change-Id: Id931875d12aeb0acb646702c84bb3c07344eaa33
Bug-Url: https://bugzilla.redhat.com/893947
Signed-off-by: Kanagaraj M <kmayilsa at redhat.com>
---
M frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/models/gluster/VolumeBrickListModel.java
M frontend/webadmin/modules/uicompat/src/main/java/org/ovirt/engine/ui/uicompat/Constants.java
M frontend/webadmin/modules/uicompat/src/main/java/org/ovirt/engine/ui/uicompat/Messages.java
3 files changed, 3 insertions(+), 3 deletions(-)

Approvals:
  Gilad Chaplik: Verified; Looks good to me, approved


--
To view, visit http://gerrit.ovirt.org/11090
To unsubscribe, visit http://gerrit.ovirt.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: Id931875d12aeb0acb646702c84bb3c07344eaa33
Gerrit-PatchSet: 3
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Kanagaraj M <kmayilsa at redhat.com>
Gerrit-Reviewer: Gilad Chaplik <gchaplik at redhat.com>
Gerrit-Reviewer: Kanagaraj M <kmayilsa at redhat.com>
Gerrit-Reviewer: Shireesh Anjal <sanjal at redhat.com>
_______________________________________________
Engine-commits mailing list
Engine-commits at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-commits
-------------- next part --------------
A non-text attachment was scrubbed...
Name: originalBody.txt
Type: application/octet-stream
Size: 1633 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130116/686d94a4/attachment.obj>

From thomas at parker.iz34.com  Wed Jan 16 15:20:11 2013
From: thomas at parker.iz34.com (thomas at parker.iz34.com)
Date: Wed, 16 Jan 2013 16:20:11 +0100
Subject: [Engine-devel] Change in ovirt-engine[master]: webadmin: Adding
	confirmation for	replicate gluster volumes
In-Reply-To: <201301161517.r0GFHF8U000349@gerrit.ovirt.org>
References: <201301161517.r0GFHF8U000349@gerrit.ovirt.org>
Message-ID: <201301161517.r0GFHF8U000349@gerrit.ovirt.org>

Gilad Chaplik has submitted this change and it was merged.

Change subject: webadmin: Adding confirmation for replicate gluster volumes
.....................................................................


webadmin: Adding confirmation for replicate gluster volumes

While creating a Replicate or Distributed Replicate volume,
if more than one brick is added from the same server,
a confirmation popup will be shown. The same warning will
be shown while adding bricks after creating volume.

In the Add Bricks dialog, a NOTE will be shown in the
bottom explaining the Replicate/Stripe groups will be
created based on the order of the bricks.

Change-Id: Id783c1404eb79b32981bbf137d4228675f3e960f
Bug-Url: https://bugzilla.redhat.com/871261
Signed-off-by: Kanagaraj M <kmayilsa at redhat.com>
---
M frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/models/gluster/VolumeBrickListModel.java
M frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/models/gluster/VolumeBrickModel.java
M frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/models/gluster/VolumeModel.java
M frontend/webadmin/modules/uicompat/src/main/java/org/ovirt/engine/ui/uicompat/Constants.java
M frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/ApplicationConstants.java
M frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/section/main/presenter/popup/gluster/VolumePopupPresenterWidget.java
M frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/section/main/view/popup/gluster/AddBrickPopupView.java
M frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/section/main/view/popup/gluster/AddBrickPopupView.ui.xml
8 files changed, 218 insertions(+), 8 deletions(-)

Approvals:
  Gilad Chaplik: Verified; Looks good to me, approved


--
To view, visit http://gerrit.ovirt.org/10018
To unsubscribe, visit http://gerrit.ovirt.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: Id783c1404eb79b32981bbf137d4228675f3e960f
Gerrit-PatchSet: 5
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Kanagaraj M <kmayilsa at redhat.com>
Gerrit-Reviewer: Gilad Chaplik <gchaplik at redhat.com>
Gerrit-Reviewer: Kanagaraj M <kmayilsa at redhat.com>
Gerrit-Reviewer: Shireesh Anjal <sanjal at redhat.com>
_______________________________________________
Engine-commits mailing list
Engine-commits at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-commits
-------------- next part --------------
A non-text attachment was scrubbed...
Name: originalBody.txt
Type: application/octet-stream
Size: 2575 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130116/146279dc/attachment.obj>

From Chris.Frantz at hp.com  Wed Jan 16 15:44:31 2013
From: Chris.Frantz at hp.com (Frantz, Chris)
Date: Wed, 16 Jan 2013 15:44:31 +0000
Subject: [Engine-devel] Unable to add a Host
In-Reply-To: <1669305395.1992733.1358322334735.JavaMail.root@redhat.com>
References: <A24D665DC3ECC245A2EA0D9A958F80B631C2995B@G9W0733.americas.hpqcorp.net>
	<1669305395.1992733.1358322334735.JavaMail.root@redhat.com>
Message-ID: <A24D665DC3ECC245A2EA0D9A958F80B631C2CC49@G4W3215.americas.hpqcorp.net>

Alon,

I've attached engine.log and ovirt-host-deploy-*.log.

My ovirt dev box is a Fedora 17 VM.
Ovirt-engine: commit 70bbca687d42f4d058009397d05791d469d4c56c
Otopi: commit 0bdd754f24c42b005d2543f6fe7705cd4d0a5f50
Ovirt-host-deploy: commit aa0edd45b03da0b07be660742a611342395c52fb

$ java -version
java version "1.7.0_03-icedtea"
OpenJDK Runtime Environment (fedora-2.2.1.fc17.8-x86_64)
OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode)

--Chris


-----Original Message-----
From: Alon Bar-Lev [mailto:alonbl at redhat.com] 
Sent: Wednesday, January 16, 2013 1:46 AM
To: Frantz, Chris
Cc: engine-devel
Subject: Re: [Engine-devel] Unable to add a Host



----- Original Message -----
> From: "Chris Frantz" <Chris.Frantz at hp.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 15, 2013 9:57:11 PM
> Subject: [Engine-devel] Unable to add a Host
> 
> 
> 
> 
> 
> Hello,
> 
> 
> 
> I?ve just built and deployed the latest ovirt-engine (and otopi and 
> ovirt-host-deploy), but I?m unable to add a host to my default 
> cluster.
> 
> 
> 
> When I try to add a host, I get a message like this in the event log:
> 
> 
> 
> Host vsr19e1b4 installation failed. CallableStatementCallback; SQL 
> [{call insertauditlog(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 
> ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: invalid byte sequence for 
> encoding "UTF8": 0x00; nested exception is
> org.postgresql.util.PSQLException: ERROR: invalid byte sequence for 
> encoding "UTF8": 0x00.
> 
> 
> 
> If I log into the target host and examine 
> /tmp/ovirt-host-deploy-*.log, I see something rather peculiar:
> 
> 
> 
> 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:213 DIALOG:SEND ***CONFIRM DEPLOY_PROCEED Proceed 
> with ovirt-host-deploy
> 
> 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:213 DIALOG:SEND ### Continuing will configure this 
> host for serving as hypervisor. Are you sure you want to continue? 
> (yes/no)
> 
> 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:213 DIALOG:SEND ### Response is CONFIRM 
> DEPLOY_PROCEED=yes|no or ABORT DEPLOY_PROCEED
> 
> 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:213 DIALOG:RECEIVE [10240 nul bytes]CONFIRM 
> DEPLOY_PROCEED=yes
> 
> 2013-01-14 12:45:59 DEBUG otopi.context context._executeMethod:127 
> method exception
> 
> Traceback (most recent call last):
> 
> File "/tmp/ovirt-tOAzfQ4mqS/pythonlib/otopi/context.py", line 117, in 
> _executeMethod
> 
> method['method']()
> 
> File
> "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/ovirt-host-deploy/core/misc.py",
> line 74, in _confirm
> 
> prompt=True,
> 
> File "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/otopi/dialog/machine.py",
> line 338, in confirm
> 
> code=opcode,
> 
> 
> 
> It seems that the confirmation message is received, but is preceded by 
> 10k worth of nuls. Has anyone seen anything like this before? An ideas 
> on what I?ve got wrong?

This is strange... can you: stop engine, rm /var/log/ovirt-engine/engine.log, start engine, reproduce and attach engine.log?

Thanks!
Alon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: engine.log
Type: application/octet-stream
Size: 53903 bytes
Desc: engine.log
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130116/eb0736be/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ovirt-host-deploy-20130116093015.log
Type: application/octet-stream
Size: 63843 bytes
Desc: ovirt-host-deploy-20130116093015.log
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130116/eb0736be/attachment-0001.obj>

From alonbl at redhat.com  Wed Jan 16 15:59:08 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 16 Jan 2013 10:59:08 -0500 (EST)
Subject: [Engine-devel] Unable to add a Host
In-Reply-To: <A24D665DC3ECC245A2EA0D9A958F80B631C2CC49@G4W3215.americas.hpqcorp.net>
Message-ID: <2010462236.2169516.1358351948168.JavaMail.root@redhat.com>

Just to make sure, before we dig farther...

Can you please paste the output of:

$ rpm -q apache-sshd
$ rpm -q apache-commons-compress

Thanks!

----- Original Message -----
> From: "Chris Frantz" <Chris.Frantz at hp.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, January 16, 2013 5:44:31 PM
> Subject: RE: [Engine-devel] Unable to add a Host
> 
> Alon,
> 
> I've attached engine.log and ovirt-host-deploy-*.log.
> 
> My ovirt dev box is a Fedora 17 VM.
> Ovirt-engine: commit 70bbca687d42f4d058009397d05791d469d4c56c
> Otopi: commit 0bdd754f24c42b005d2543f6fe7705cd4d0a5f50
> Ovirt-host-deploy: commit aa0edd45b03da0b07be660742a611342395c52fb
> 
> $ java -version
> java version "1.7.0_03-icedtea"
> OpenJDK Runtime Environment (fedora-2.2.1.fc17.8-x86_64)
> OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode)
> 
> --Chris
> 
> 
> -----Original Message-----
> From: Alon Bar-Lev [mailto:alonbl at redhat.com]
> Sent: Wednesday, January 16, 2013 1:46 AM
> To: Frantz, Chris
> Cc: engine-devel
> Subject: Re: [Engine-devel] Unable to add a Host
> 
> 
> 
> ----- Original Message -----
> > From: "Chris Frantz" <Chris.Frantz at hp.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, January 15, 2013 9:57:11 PM
> > Subject: [Engine-devel] Unable to add a Host
> > 
> > 
> > 
> > 
> > 
> > Hello,
> > 
> > 
> > 
> > I?ve just built and deployed the latest ovirt-engine (and otopi and
> > ovirt-host-deploy), but I?m unable to add a host to my default
> > cluster.
> > 
> > 
> > 
> > When I try to add a host, I get a message like this in the event
> > log:
> > 
> > 
> > 
> > Host vsr19e1b4 installation failed. CallableStatementCallback; SQL
> > [{call insertauditlog(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> > ?,
> > ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: invalid byte sequence for
> > encoding "UTF8": 0x00; nested exception is
> > org.postgresql.util.PSQLException: ERROR: invalid byte sequence for
> > encoding "UTF8": 0x00.
> > 
> > 
> > 
> > If I log into the target host and examine
> > /tmp/ovirt-host-deploy-*.log, I see something rather peculiar:
> > 
> > 
> > 
> > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > dialog.__logString:213 DIALOG:SEND ***CONFIRM DEPLOY_PROCEED
> > Proceed
> > with ovirt-host-deploy
> > 
> > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > dialog.__logString:213 DIALOG:SEND ### Continuing will configure
> > this
> > host for serving as hypervisor. Are you sure you want to continue?
> > (yes/no)
> > 
> > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > dialog.__logString:213 DIALOG:SEND ### Response is CONFIRM
> > DEPLOY_PROCEED=yes|no or ABORT DEPLOY_PROCEED
> > 
> > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > dialog.__logString:213 DIALOG:RECEIVE [10240 nul bytes]CONFIRM
> > DEPLOY_PROCEED=yes
> > 
> > 2013-01-14 12:45:59 DEBUG otopi.context context._executeMethod:127
> > method exception
> > 
> > Traceback (most recent call last):
> > 
> > File "/tmp/ovirt-tOAzfQ4mqS/pythonlib/otopi/context.py", line 117,
> > in
> > _executeMethod
> > 
> > method['method']()
> > 
> > File
> > "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/ovirt-host-deploy/core/misc.py",
> > line 74, in _confirm
> > 
> > prompt=True,
> > 
> > File "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/otopi/dialog/machine.py",
> > line 338, in confirm
> > 
> > code=opcode,
> > 
> > 
> > 
> > It seems that the confirmation message is received, but is preceded
> > by
> > 10k worth of nuls. Has anyone seen anything like this before? An
> > ideas
> > on what I?ve got wrong?
> 
> This is strange... can you: stop engine, rm
> /var/log/ovirt-engine/engine.log, start engine, reproduce and attach
> engine.log?
> 
> Thanks!
> Alon
> 


From Chris.Frantz at hp.com  Wed Jan 16 16:05:57 2013
From: Chris.Frantz at hp.com (Frantz, Chris)
Date: Wed, 16 Jan 2013 16:05:57 +0000
Subject: [Engine-devel] Unable to add a Host
In-Reply-To: <2010462236.2169516.1358351948168.JavaMail.root@redhat.com>
References: <A24D665DC3ECC245A2EA0D9A958F80B631C2CC49@G4W3215.americas.hpqcorp.net>
	<2010462236.2169516.1358351948168.JavaMail.root@redhat.com>
Message-ID: <A24D665DC3ECC245A2EA0D9A958F80B631C2DE6F@G4W3215.americas.hpqcorp.net>

I don't have either of those installed.

They do exist in my .m2/repository however:

[cfrantz at cjf-ovirt-dev2 apache]$ pwd
/home/cfrantz/.m2/repository/org/apache
[cfrantz at cjf-ovirt-dev2 apache]$ find sshd
sshd
sshd/sshd-core
sshd/sshd-core/0.7.0
sshd/sshd-core/0.7.0/sshd-core-0.7.0.pom.sha1
sshd/sshd-core/0.7.0/sshd-core-0.7.0.pom
sshd/sshd-core/0.7.0/sshd-core-0.7.0.jar
sshd/sshd-core/0.7.0/sshd-core-0.7.0.jar.sha1
sshd/sshd-core/0.7.0/_maven.repositories
sshd/sshd-core/0.6.0
sshd/sshd-core/0.6.0/sshd-core-0.6.0.pom.sha1
sshd/sshd-core/0.6.0/sshd-core-0.6.0.jar
sshd/sshd-core/0.6.0/sshd-core-0.6.0.jar.sha1
sshd/sshd-core/0.6.0/sshd-core-0.6.0.pom
sshd/sshd-core/0.6.0/_maven.repositories
sshd/sshd
sshd/sshd/0.7.0
sshd/sshd/0.7.0/sshd-0.7.0.pom
sshd/sshd/0.7.0/sshd-0.7.0.pom.sha1
sshd/sshd/0.7.0/_maven.repositories
sshd/sshd/0.6.0
sshd/sshd/0.6.0/sshd-0.6.0.pom
sshd/sshd/0.6.0/_maven.repositories
sshd/sshd/0.6.0/sshd-0.6.0.pom.sha1

[cfrantz at cjf-ovirt-dev2 apache]$ find commons/commons-compress/
commons/commons-compress/
commons/commons-compress/1.3
commons/commons-compress/1.3/commons-compress-1.3.jar
commons/commons-compress/1.3/commons-compress-1.3.jar.sha1
commons/commons-compress/1.3/commons-compress-1.3.pom
commons/commons-compress/1.3/commons-compress-1.3.pom.sha1
commons/commons-compress/1.3/_maven.repositories

--Chris


-----Original Message-----
From: Alon Bar-Lev [mailto:alonbl at redhat.com] 
Sent: Wednesday, January 16, 2013 9:59 AM
To: Frantz, Chris
Cc: engine-devel
Subject: Re: [Engine-devel] Unable to add a Host

Just to make sure, before we dig farther...

Can you please paste the output of:

$ rpm -q apache-sshd
$ rpm -q apache-commons-compress

Thanks!

----- Original Message -----
> From: "Chris Frantz" <Chris.Frantz at hp.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, January 16, 2013 5:44:31 PM
> Subject: RE: [Engine-devel] Unable to add a Host
> 
> Alon,
> 
> I've attached engine.log and ovirt-host-deploy-*.log.
> 
> My ovirt dev box is a Fedora 17 VM.
> Ovirt-engine: commit 70bbca687d42f4d058009397d05791d469d4c56c
> Otopi: commit 0bdd754f24c42b005d2543f6fe7705cd4d0a5f50
> Ovirt-host-deploy: commit aa0edd45b03da0b07be660742a611342395c52fb
> 
> $ java -version
> java version "1.7.0_03-icedtea"
> OpenJDK Runtime Environment (fedora-2.2.1.fc17.8-x86_64) OpenJDK 
> 64-Bit Server VM (build 23.0-b21, mixed mode)
> 
> --Chris
> 
> 
> -----Original Message-----
> From: Alon Bar-Lev [mailto:alonbl at redhat.com]
> Sent: Wednesday, January 16, 2013 1:46 AM
> To: Frantz, Chris
> Cc: engine-devel
> Subject: Re: [Engine-devel] Unable to add a Host
> 
> 
> 
> ----- Original Message -----
> > From: "Chris Frantz" <Chris.Frantz at hp.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, January 15, 2013 9:57:11 PM
> > Subject: [Engine-devel] Unable to add a Host
> > 
> > 
> > 
> > 
> > 
> > Hello,
> > 
> > 
> > 
> > I?ve just built and deployed the latest ovirt-engine (and otopi and 
> > ovirt-host-deploy), but I?m unable to add a host to my default 
> > cluster.
> > 
> > 
> > 
> > When I try to add a host, I get a message like this in the event
> > log:
> > 
> > 
> > 
> > Host vsr19e1b4 installation failed. CallableStatementCallback; SQL 
> > [{call insertauditlog(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 
> > ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: invalid byte sequence for 
> > encoding "UTF8": 0x00; nested exception is
> > org.postgresql.util.PSQLException: ERROR: invalid byte sequence for 
> > encoding "UTF8": 0x00.
> > 
> > 
> > 
> > If I log into the target host and examine 
> > /tmp/ovirt-host-deploy-*.log, I see something rather peculiar:
> > 
> > 
> > 
> > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > dialog.__logString:213 DIALOG:SEND ***CONFIRM DEPLOY_PROCEED Proceed 
> > with ovirt-host-deploy
> > 
> > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > dialog.__logString:213 DIALOG:SEND ### Continuing will configure 
> > this host for serving as hypervisor. Are you sure you want to 
> > continue?
> > (yes/no)
> > 
> > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > dialog.__logString:213 DIALOG:SEND ### Response is CONFIRM 
> > DEPLOY_PROCEED=yes|no or ABORT DEPLOY_PROCEED
> > 
> > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > dialog.__logString:213 DIALOG:RECEIVE [10240 nul bytes]CONFIRM 
> > DEPLOY_PROCEED=yes
> > 
> > 2013-01-14 12:45:59 DEBUG otopi.context context._executeMethod:127 
> > method exception
> > 
> > Traceback (most recent call last):
> > 
> > File "/tmp/ovirt-tOAzfQ4mqS/pythonlib/otopi/context.py", line 117, 
> > in _executeMethod
> > 
> > method['method']()
> > 
> > File
> > "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/ovirt-host-deploy/core/misc.py"
> > ,
> > line 74, in _confirm
> > 
> > prompt=True,
> > 
> > File "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/otopi/dialog/machine.py",
> > line 338, in confirm
> > 
> > code=opcode,
> > 
> > 
> > 
> > It seems that the confirmation message is received, but is preceded 
> > by 10k worth of nuls. Has anyone seen anything like this before? An 
> > ideas on what I?ve got wrong?
> 
> This is strange... can you: stop engine, rm 
> /var/log/ovirt-engine/engine.log, start engine, reproduce and attach 
> engine.log?
> 
> Thanks!
> Alon
> 

From alonbl at redhat.com  Wed Jan 16 16:18:40 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 16 Jan 2013 11:18:40 -0500 (EST)
Subject: [Engine-devel] Unable to add a Host
In-Reply-To: <A24D665DC3ECC245A2EA0D9A958F80B631C2DE6F@G4W3215.americas.hpqcorp.net>
Message-ID: <1311123494.2175609.1358353120667.JavaMail.root@redhat.com>

Hmmm... how do you run the engine? not from installation?

Can you please try to use apache-commons-compress-1.4.1?

----- Original Message -----
> From: "Chris Frantz" <Chris.Frantz at hp.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, January 16, 2013 6:05:57 PM
> Subject: RE: [Engine-devel] Unable to add a Host
> 
> I don't have either of those installed.
> 
> They do exist in my .m2/repository however:
> 
> [cfrantz at cjf-ovirt-dev2 apache]$ pwd
> /home/cfrantz/.m2/repository/org/apache
> [cfrantz at cjf-ovirt-dev2 apache]$ find sshd
> sshd
> sshd/sshd-core
> sshd/sshd-core/0.7.0
> sshd/sshd-core/0.7.0/sshd-core-0.7.0.pom.sha1
> sshd/sshd-core/0.7.0/sshd-core-0.7.0.pom
> sshd/sshd-core/0.7.0/sshd-core-0.7.0.jar
> sshd/sshd-core/0.7.0/sshd-core-0.7.0.jar.sha1
> sshd/sshd-core/0.7.0/_maven.repositories
> sshd/sshd-core/0.6.0
> sshd/sshd-core/0.6.0/sshd-core-0.6.0.pom.sha1
> sshd/sshd-core/0.6.0/sshd-core-0.6.0.jar
> sshd/sshd-core/0.6.0/sshd-core-0.6.0.jar.sha1
> sshd/sshd-core/0.6.0/sshd-core-0.6.0.pom
> sshd/sshd-core/0.6.0/_maven.repositories
> sshd/sshd
> sshd/sshd/0.7.0
> sshd/sshd/0.7.0/sshd-0.7.0.pom
> sshd/sshd/0.7.0/sshd-0.7.0.pom.sha1
> sshd/sshd/0.7.0/_maven.repositories
> sshd/sshd/0.6.0
> sshd/sshd/0.6.0/sshd-0.6.0.pom
> sshd/sshd/0.6.0/_maven.repositories
> sshd/sshd/0.6.0/sshd-0.6.0.pom.sha1
> 
> [cfrantz at cjf-ovirt-dev2 apache]$ find commons/commons-compress/
> commons/commons-compress/
> commons/commons-compress/1.3
> commons/commons-compress/1.3/commons-compress-1.3.jar
> commons/commons-compress/1.3/commons-compress-1.3.jar.sha1
> commons/commons-compress/1.3/commons-compress-1.3.pom
> commons/commons-compress/1.3/commons-compress-1.3.pom.sha1
> commons/commons-compress/1.3/_maven.repositories
> 
> --Chris
> 
> 
> -----Original Message-----
> From: Alon Bar-Lev [mailto:alonbl at redhat.com]
> Sent: Wednesday, January 16, 2013 9:59 AM
> To: Frantz, Chris
> Cc: engine-devel
> Subject: Re: [Engine-devel] Unable to add a Host
> 
> Just to make sure, before we dig farther...
> 
> Can you please paste the output of:
> 
> $ rpm -q apache-sshd
> $ rpm -q apache-commons-compress
> 
> Thanks!
> 
> ----- Original Message -----
> > From: "Chris Frantz" <Chris.Frantz at hp.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, January 16, 2013 5:44:31 PM
> > Subject: RE: [Engine-devel] Unable to add a Host
> > 
> > Alon,
> > 
> > I've attached engine.log and ovirt-host-deploy-*.log.
> > 
> > My ovirt dev box is a Fedora 17 VM.
> > Ovirt-engine: commit 70bbca687d42f4d058009397d05791d469d4c56c
> > Otopi: commit 0bdd754f24c42b005d2543f6fe7705cd4d0a5f50
> > Ovirt-host-deploy: commit aa0edd45b03da0b07be660742a611342395c52fb
> > 
> > $ java -version
> > java version "1.7.0_03-icedtea"
> > OpenJDK Runtime Environment (fedora-2.2.1.fc17.8-x86_64) OpenJDK
> > 64-Bit Server VM (build 23.0-b21, mixed mode)
> > 
> > --Chris
> > 
> > 
> > -----Original Message-----
> > From: Alon Bar-Lev [mailto:alonbl at redhat.com]
> > Sent: Wednesday, January 16, 2013 1:46 AM
> > To: Frantz, Chris
> > Cc: engine-devel
> > Subject: Re: [Engine-devel] Unable to add a Host
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Chris Frantz" <Chris.Frantz at hp.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, January 15, 2013 9:57:11 PM
> > > Subject: [Engine-devel] Unable to add a Host
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Hello,
> > > 
> > > 
> > > 
> > > I?ve just built and deployed the latest ovirt-engine (and otopi
> > > and
> > > ovirt-host-deploy), but I?m unable to add a host to my default
> > > cluster.
> > > 
> > > 
> > > 
> > > When I try to add a host, I get a message like this in the event
> > > log:
> > > 
> > > 
> > > 
> > > Host vsr19e1b4 installation failed. CallableStatementCallback;
> > > SQL
> > > [{call insertauditlog(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> > > ?,
> > > ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: invalid byte sequence
> > > for
> > > encoding "UTF8": 0x00; nested exception is
> > > org.postgresql.util.PSQLException: ERROR: invalid byte sequence
> > > for
> > > encoding "UTF8": 0x00.
> > > 
> > > 
> > > 
> > > If I log into the target host and examine
> > > /tmp/ovirt-host-deploy-*.log, I see something rather peculiar:
> > > 
> > > 
> > > 
> > > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > > dialog.__logString:213 DIALOG:SEND ***CONFIRM DEPLOY_PROCEED
> > > Proceed
> > > with ovirt-host-deploy
> > > 
> > > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > > dialog.__logString:213 DIALOG:SEND ### Continuing will configure
> > > this host for serving as hypervisor. Are you sure you want to
> > > continue?
> > > (yes/no)
> > > 
> > > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > > dialog.__logString:213 DIALOG:SEND ### Response is CONFIRM
> > > DEPLOY_PROCEED=yes|no or ABORT DEPLOY_PROCEED
> > > 
> > > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > > dialog.__logString:213 DIALOG:RECEIVE [10240 nul bytes]CONFIRM
> > > DEPLOY_PROCEED=yes
> > > 
> > > 2013-01-14 12:45:59 DEBUG otopi.context
> > > context._executeMethod:127
> > > method exception
> > > 
> > > Traceback (most recent call last):
> > > 
> > > File "/tmp/ovirt-tOAzfQ4mqS/pythonlib/otopi/context.py", line
> > > 117,
> > > in _executeMethod
> > > 
> > > method['method']()
> > > 
> > > File
> > > "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/ovirt-host-deploy/core/misc.py"
> > > ,
> > > line 74, in _confirm
> > > 
> > > prompt=True,
> > > 
> > > File
> > > "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/otopi/dialog/machine.py",
> > > line 338, in confirm
> > > 
> > > code=opcode,
> > > 
> > > 
> > > 
> > > It seems that the confirmation message is received, but is
> > > preceded
> > > by 10k worth of nuls. Has anyone seen anything like this before?
> > > An
> > > ideas on what I?ve got wrong?
> > 
> > This is strange... can you: stop engine, rm
> > /var/log/ovirt-engine/engine.log, start engine, reproduce and
> > attach
> > engine.log?
> > 
> > Thanks!
> > Alon
> > 
> 


From Chris.Frantz at hp.com  Wed Jan 16 16:24:50 2013
From: Chris.Frantz at hp.com (Frantz, Chris)
Date: Wed, 16 Jan 2013 16:24:50 +0000
Subject: [Engine-devel] Unable to add a Host
In-Reply-To: <1311123494.2175609.1358353120667.JavaMail.root@redhat.com>
References: <A24D665DC3ECC245A2EA0D9A958F80B631C2DE6F@G4W3215.americas.hpqcorp.net>
	<1311123494.2175609.1358353120667.JavaMail.root@redhat.com>
Message-ID: <A24D665DC3ECC245A2EA0D9A958F80B631C2DE89@G4W3215.americas.hpqcorp.net>

I'm building from sources, following the instructions on the Wiki.


-----Original Message-----
From: Alon Bar-Lev [mailto:alonbl at redhat.com] 
Sent: Wednesday, January 16, 2013 10:19 AM
To: Frantz, Chris
Cc: engine-devel
Subject: Re: [Engine-devel] Unable to add a Host

Hmmm... how do you run the engine? not from installation?

Can you please try to use apache-commons-compress-1.4.1?

----- Original Message -----
> From: "Chris Frantz" <Chris.Frantz at hp.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, January 16, 2013 6:05:57 PM
> Subject: RE: [Engine-devel] Unable to add a Host
> 
> I don't have either of those installed.
> 
> They do exist in my .m2/repository however:
> 
> [cfrantz at cjf-ovirt-dev2 apache]$ pwd
> /home/cfrantz/.m2/repository/org/apache
> [cfrantz at cjf-ovirt-dev2 apache]$ find sshd sshd sshd/sshd-core
> sshd/sshd-core/0.7.0
> sshd/sshd-core/0.7.0/sshd-core-0.7.0.pom.sha1
> sshd/sshd-core/0.7.0/sshd-core-0.7.0.pom
> sshd/sshd-core/0.7.0/sshd-core-0.7.0.jar
> sshd/sshd-core/0.7.0/sshd-core-0.7.0.jar.sha1
> sshd/sshd-core/0.7.0/_maven.repositories
> sshd/sshd-core/0.6.0
> sshd/sshd-core/0.6.0/sshd-core-0.6.0.pom.sha1
> sshd/sshd-core/0.6.0/sshd-core-0.6.0.jar
> sshd/sshd-core/0.6.0/sshd-core-0.6.0.jar.sha1
> sshd/sshd-core/0.6.0/sshd-core-0.6.0.pom
> sshd/sshd-core/0.6.0/_maven.repositories
> sshd/sshd
> sshd/sshd/0.7.0
> sshd/sshd/0.7.0/sshd-0.7.0.pom
> sshd/sshd/0.7.0/sshd-0.7.0.pom.sha1
> sshd/sshd/0.7.0/_maven.repositories
> sshd/sshd/0.6.0
> sshd/sshd/0.6.0/sshd-0.6.0.pom
> sshd/sshd/0.6.0/_maven.repositories
> sshd/sshd/0.6.0/sshd-0.6.0.pom.sha1
> 
> [cfrantz at cjf-ovirt-dev2 apache]$ find commons/commons-compress/ 
> commons/commons-compress/
> commons/commons-compress/1.3
> commons/commons-compress/1.3/commons-compress-1.3.jar
> commons/commons-compress/1.3/commons-compress-1.3.jar.sha1
> commons/commons-compress/1.3/commons-compress-1.3.pom
> commons/commons-compress/1.3/commons-compress-1.3.pom.sha1
> commons/commons-compress/1.3/_maven.repositories
> 
> --Chris
> 
> 
> -----Original Message-----
> From: Alon Bar-Lev [mailto:alonbl at redhat.com]
> Sent: Wednesday, January 16, 2013 9:59 AM
> To: Frantz, Chris
> Cc: engine-devel
> Subject: Re: [Engine-devel] Unable to add a Host
> 
> Just to make sure, before we dig farther...
> 
> Can you please paste the output of:
> 
> $ rpm -q apache-sshd
> $ rpm -q apache-commons-compress
> 
> Thanks!
> 
> ----- Original Message -----
> > From: "Chris Frantz" <Chris.Frantz at hp.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, January 16, 2013 5:44:31 PM
> > Subject: RE: [Engine-devel] Unable to add a Host
> > 
> > Alon,
> > 
> > I've attached engine.log and ovirt-host-deploy-*.log.
> > 
> > My ovirt dev box is a Fedora 17 VM.
> > Ovirt-engine: commit 70bbca687d42f4d058009397d05791d469d4c56c
> > Otopi: commit 0bdd754f24c42b005d2543f6fe7705cd4d0a5f50
> > Ovirt-host-deploy: commit aa0edd45b03da0b07be660742a611342395c52fb
> > 
> > $ java -version
> > java version "1.7.0_03-icedtea"
> > OpenJDK Runtime Environment (fedora-2.2.1.fc17.8-x86_64) OpenJDK 
> > 64-Bit Server VM (build 23.0-b21, mixed mode)
> > 
> > --Chris
> > 
> > 
> > -----Original Message-----
> > From: Alon Bar-Lev [mailto:alonbl at redhat.com]
> > Sent: Wednesday, January 16, 2013 1:46 AM
> > To: Frantz, Chris
> > Cc: engine-devel
> > Subject: Re: [Engine-devel] Unable to add a Host
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Chris Frantz" <Chris.Frantz at hp.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, January 15, 2013 9:57:11 PM
> > > Subject: [Engine-devel] Unable to add a Host
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Hello,
> > > 
> > > 
> > > 
> > > I?ve just built and deployed the latest ovirt-engine (and otopi 
> > > and ovirt-host-deploy), but I?m unable to add a host to my default 
> > > cluster.
> > > 
> > > 
> > > 
> > > When I try to add a host, I get a message like this in the event
> > > log:
> > > 
> > > 
> > > 
> > > Host vsr19e1b4 installation failed. CallableStatementCallback; SQL 
> > > [{call insertauditlog(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 
> > > ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: invalid byte sequence 
> > > for encoding "UTF8": 0x00; nested exception is
> > > org.postgresql.util.PSQLException: ERROR: invalid byte sequence 
> > > for encoding "UTF8": 0x00.
> > > 
> > > 
> > > 
> > > If I log into the target host and examine 
> > > /tmp/ovirt-host-deploy-*.log, I see something rather peculiar:
> > > 
> > > 
> > > 
> > > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > > dialog.__logString:213 DIALOG:SEND ***CONFIRM DEPLOY_PROCEED 
> > > Proceed with ovirt-host-deploy
> > > 
> > > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > > dialog.__logString:213 DIALOG:SEND ### Continuing will configure 
> > > this host for serving as hypervisor. Are you sure you want to 
> > > continue?
> > > (yes/no)
> > > 
> > > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > > dialog.__logString:213 DIALOG:SEND ### Response is CONFIRM 
> > > DEPLOY_PROCEED=yes|no or ABORT DEPLOY_PROCEED
> > > 
> > > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > > dialog.__logString:213 DIALOG:RECEIVE [10240 nul bytes]CONFIRM 
> > > DEPLOY_PROCEED=yes
> > > 
> > > 2013-01-14 12:45:59 DEBUG otopi.context
> > > context._executeMethod:127
> > > method exception
> > > 
> > > Traceback (most recent call last):
> > > 
> > > File "/tmp/ovirt-tOAzfQ4mqS/pythonlib/otopi/context.py", line 117, 
> > > in _executeMethod
> > > 
> > > method['method']()
> > > 
> > > File
> > > "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/ovirt-host-deploy/core/misc.py"
> > > ,
> > > line 74, in _confirm
> > > 
> > > prompt=True,
> > > 
> > > File
> > > "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/otopi/dialog/machine.py",
> > > line 338, in confirm
> > > 
> > > code=opcode,
> > > 
> > > 
> > > 
> > > It seems that the confirmation message is received, but is 
> > > preceded by 10k worth of nuls. Has anyone seen anything like this 
> > > before?
> > > An
> > > ideas on what I?ve got wrong?
> > 
> > This is strange... can you: stop engine, rm 
> > /var/log/ovirt-engine/engine.log, start engine, reproduce and attach 
> > engine.log?
> > 
> > Thanks!
> > Alon
> > 
> 

From alonbl at redhat.com  Wed Jan 16 16:32:12 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 16 Jan 2013 11:32:12 -0500 (EST)
Subject: [Engine-devel] Unable to add a Host
In-Reply-To: <A24D665DC3ECC245A2EA0D9A958F80B631C2DE89@G4W3215.americas.hpqcorp.net>
Message-ID: <167306888.2178712.1358353932608.JavaMail.root@redhat.com>

I never tried that with host deploy :)
Will be interesting...
Can you please try to replace at pom.xml:
    <commons-compress.version>1.3</commons-compress.version>
with:
    <commons-compress.version>1.4.1</commons-compress.version>


----- Original Message -----
> From: "Chris Frantz" <Chris.Frantz at hp.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, January 16, 2013 6:24:50 PM
> Subject: RE: [Engine-devel] Unable to add a Host
> 
> I'm building from sources, following the instructions on the Wiki.
> 
> 
> -----Original Message-----
> From: Alon Bar-Lev [mailto:alonbl at redhat.com]
> Sent: Wednesday, January 16, 2013 10:19 AM
> To: Frantz, Chris
> Cc: engine-devel
> Subject: Re: [Engine-devel] Unable to add a Host
> 
> Hmmm... how do you run the engine? not from installation?
> 
> Can you please try to use apache-commons-compress-1.4.1?
> 
> ----- Original Message -----
> > From: "Chris Frantz" <Chris.Frantz at hp.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, January 16, 2013 6:05:57 PM
> > Subject: RE: [Engine-devel] Unable to add a Host
> > 
> > I don't have either of those installed.
> > 
> > They do exist in my .m2/repository however:
> > 
> > [cfrantz at cjf-ovirt-dev2 apache]$ pwd
> > /home/cfrantz/.m2/repository/org/apache
> > [cfrantz at cjf-ovirt-dev2 apache]$ find sshd sshd sshd/sshd-core
> > sshd/sshd-core/0.7.0
> > sshd/sshd-core/0.7.0/sshd-core-0.7.0.pom.sha1
> > sshd/sshd-core/0.7.0/sshd-core-0.7.0.pom
> > sshd/sshd-core/0.7.0/sshd-core-0.7.0.jar
> > sshd/sshd-core/0.7.0/sshd-core-0.7.0.jar.sha1
> > sshd/sshd-core/0.7.0/_maven.repositories
> > sshd/sshd-core/0.6.0
> > sshd/sshd-core/0.6.0/sshd-core-0.6.0.pom.sha1
> > sshd/sshd-core/0.6.0/sshd-core-0.6.0.jar
> > sshd/sshd-core/0.6.0/sshd-core-0.6.0.jar.sha1
> > sshd/sshd-core/0.6.0/sshd-core-0.6.0.pom
> > sshd/sshd-core/0.6.0/_maven.repositories
> > sshd/sshd
> > sshd/sshd/0.7.0
> > sshd/sshd/0.7.0/sshd-0.7.0.pom
> > sshd/sshd/0.7.0/sshd-0.7.0.pom.sha1
> > sshd/sshd/0.7.0/_maven.repositories
> > sshd/sshd/0.6.0
> > sshd/sshd/0.6.0/sshd-0.6.0.pom
> > sshd/sshd/0.6.0/_maven.repositories
> > sshd/sshd/0.6.0/sshd-0.6.0.pom.sha1
> > 
> > [cfrantz at cjf-ovirt-dev2 apache]$ find commons/commons-compress/
> > commons/commons-compress/
> > commons/commons-compress/1.3
> > commons/commons-compress/1.3/commons-compress-1.3.jar
> > commons/commons-compress/1.3/commons-compress-1.3.jar.sha1
> > commons/commons-compress/1.3/commons-compress-1.3.pom
> > commons/commons-compress/1.3/commons-compress-1.3.pom.sha1
> > commons/commons-compress/1.3/_maven.repositories
> > 
> > --Chris
> > 
> > 
> > -----Original Message-----
> > From: Alon Bar-Lev [mailto:alonbl at redhat.com]
> > Sent: Wednesday, January 16, 2013 9:59 AM
> > To: Frantz, Chris
> > Cc: engine-devel
> > Subject: Re: [Engine-devel] Unable to add a Host
> > 
> > Just to make sure, before we dig farther...
> > 
> > Can you please paste the output of:
> > 
> > $ rpm -q apache-sshd
> > $ rpm -q apache-commons-compress
> > 
> > Thanks!
> > 
> > ----- Original Message -----
> > > From: "Chris Frantz" <Chris.Frantz at hp.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, January 16, 2013 5:44:31 PM
> > > Subject: RE: [Engine-devel] Unable to add a Host
> > > 
> > > Alon,
> > > 
> > > I've attached engine.log and ovirt-host-deploy-*.log.
> > > 
> > > My ovirt dev box is a Fedora 17 VM.
> > > Ovirt-engine: commit 70bbca687d42f4d058009397d05791d469d4c56c
> > > Otopi: commit 0bdd754f24c42b005d2543f6fe7705cd4d0a5f50
> > > Ovirt-host-deploy: commit
> > > aa0edd45b03da0b07be660742a611342395c52fb
> > > 
> > > $ java -version
> > > java version "1.7.0_03-icedtea"
> > > OpenJDK Runtime Environment (fedora-2.2.1.fc17.8-x86_64) OpenJDK
> > > 64-Bit Server VM (build 23.0-b21, mixed mode)
> > > 
> > > --Chris
> > > 
> > > 
> > > -----Original Message-----
> > > From: Alon Bar-Lev [mailto:alonbl at redhat.com]
> > > Sent: Wednesday, January 16, 2013 1:46 AM
> > > To: Frantz, Chris
> > > Cc: engine-devel
> > > Subject: Re: [Engine-devel] Unable to add a Host
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Chris Frantz" <Chris.Frantz at hp.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Tuesday, January 15, 2013 9:57:11 PM
> > > > Subject: [Engine-devel] Unable to add a Host
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > 
> > > > 
> > > > I?ve just built and deployed the latest ovirt-engine (and otopi
> > > > and ovirt-host-deploy), but I?m unable to add a host to my
> > > > default
> > > > cluster.
> > > > 
> > > > 
> > > > 
> > > > When I try to add a host, I get a message like this in the
> > > > event
> > > > log:
> > > > 
> > > > 
> > > > 
> > > > Host vsr19e1b4 installation failed. CallableStatementCallback;
> > > > SQL
> > > > [{call insertauditlog(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> > > > ?,
> > > > ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: invalid byte
> > > > sequence
> > > > for encoding "UTF8": 0x00; nested exception is
> > > > org.postgresql.util.PSQLException: ERROR: invalid byte sequence
> > > > for encoding "UTF8": 0x00.
> > > > 
> > > > 
> > > > 
> > > > If I log into the target host and examine
> > > > /tmp/ovirt-host-deploy-*.log, I see something rather peculiar:
> > > > 
> > > > 
> > > > 
> > > > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > > > dialog.__logString:213 DIALOG:SEND ***CONFIRM DEPLOY_PROCEED
> > > > Proceed with ovirt-host-deploy
> > > > 
> > > > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > > > dialog.__logString:213 DIALOG:SEND ### Continuing will
> > > > configure
> > > > this host for serving as hypervisor. Are you sure you want to
> > > > continue?
> > > > (yes/no)
> > > > 
> > > > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > > > dialog.__logString:213 DIALOG:SEND ### Response is CONFIRM
> > > > DEPLOY_PROCEED=yes|no or ABORT DEPLOY_PROCEED
> > > > 
> > > > 2013-01-14 12:45:59 DEBUG otopi.plugins.otopi.dialog.machine
> > > > dialog.__logString:213 DIALOG:RECEIVE [10240 nul bytes]CONFIRM
> > > > DEPLOY_PROCEED=yes
> > > > 
> > > > 2013-01-14 12:45:59 DEBUG otopi.context
> > > > context._executeMethod:127
> > > > method exception
> > > > 
> > > > Traceback (most recent call last):
> > > > 
> > > > File "/tmp/ovirt-tOAzfQ4mqS/pythonlib/otopi/context.py", line
> > > > 117,
> > > > in _executeMethod
> > > > 
> > > > method['method']()
> > > > 
> > > > File
> > > > "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/ovirt-host-deploy/core/misc.py"
> > > > ,
> > > > line 74, in _confirm
> > > > 
> > > > prompt=True,
> > > > 
> > > > File
> > > > "/tmp/ovirt-tOAzfQ4mqS/otopi-plugins/otopi/dialog/machine.py",
> > > > line 338, in confirm
> > > > 
> > > > code=opcode,
> > > > 
> > > > 
> > > > 
> > > > It seems that the confirmation message is received, but is
> > > > preceded by 10k worth of nuls. Has anyone seen anything like
> > > > this
> > > > before?
> > > > An
> > > > ideas on what I?ve got wrong?
> > > 
> > > This is strange... can you: stop engine, rm
> > > /var/log/ovirt-engine/engine.log, start engine, reproduce and
> > > attach
> > > engine.log?
> > > 
> > > Thanks!
> > > Alon
> > > 
> > 
> 


From jbrooks at redhat.com  Wed Jan 16 23:05:36 2013
From: jbrooks at redhat.com (Jason Brooks)
Date: Wed, 16 Jan 2013 15:05:36 -0800
Subject: [Engine-devel] Can not add a data storage
In-Reply-To: <C5A0092C63E939488005F15F736A8112111364@SHSMSX101.ccr.corp.intel.com>
References: <C5A0092C63E939488005F15F736A8112111364@SHSMSX101.ccr.corp.intel.com>
Message-ID: <50F73240.2090804@redhat.com>

On 01/15/2013 07:15 PM, Chen, Wei D wrote:
> Hi,
>
> We are trying to setup separate ovirt engine/node environment,
> everything goes well except at the step of adding a data storage. It
> just says encountered some exception and failed to attach storage domain
> storage to data center default from admin portal. I found these error
> message like follow after checking engine.log
>
> ?
>
> 2013-01-16 10:50:38,518 WARN
> [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase]
> (ajp--127.0.0.1-8702-7) [64091e1d] Weird return value: Class Name:
> org.ovirt.engine.core.vdsbroker.vdsbroker.StatusForXmlRpc
>
> mCode                         661
>
> mMessage                      Cannot acquire host id:
> ('23e02bc1-a9fa-4aee-b13a-255715aa96b9', SanlockException(-203, 'Sanlock
> lockspace add failure', 'Sanlock exception'))
>
> 2013-01-16 10:50:38,520 WARN
> [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase]
> (ajp--127.0.0.1-8702-7) [64091e1d] Weird return value: Class Name:
> org.ovirt.engine.core.vdsbroker.vdsbroker.StatusForXmlRpc
>
> mCode                         661
>
> mMessage                      Cannot acquire host id:
> ('23e02bc1-a9fa-4aee-b13a-255715aa96b9', SanlockException(-203, 'Sanlock
> lockspace add failure', 'Sanlock exception'))

I encountered an issue like this today with my F18+3.2 alpha all in one 
install. Putting SELinux into permissive mode enabled me to proceed.

Regards, Jason

>
> ?
>
> Some extra information:
>
> Operation System:
>
> Engine: Fedora17, Node: Fedora18.
>
> Ovirt repo used for both engine and node:
> baseurl=http://ovirt.org/releases/nightly/rpm/Fedora/$releasever/
>
> On engine?s server I can mount the nfs directory created on node from
> successfully. Would you give us some suggestion on how to resolve this
> issue. Thanks in advance!
>
> 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  Thu Jan 17 01:52:01 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Thu, 17 Jan 2013 01:52:01 +0000
Subject: [Engine-devel] Error while trying to read parameter HTTP_PORT from
	user
Message-ID: <C5A0092C63E939488005F15F736A8112114522@SHSMSX101.ccr.corp.intel.com>

Hi,
  There is a problem in setup ovirt-engine, "Error while trying to read parameter HTTP_PORT from user."
The env is setup with ovirt-engine 3.2.0 from http://www.ovirt.org/Building_oVirt_engine , at last i try to
input 'make' to configure ovirt engine.

Selinux is 'SELINUX=enforcing' in /etc/selinux/config
Iptalbles is running, and the below ports in open.

iptables -I INPUT 1 -p tcp --dport 443  -j ACCEPT
iptables -I INPUT 1 -p tcp --dport 80   -j ACCEPT
iptables -I INPUT 1 -p tcp --dport 4457 -j ACCEPT
iptables -I INPUT 1 -p tcp --dport 8443 -j ACCEPT
iptables -I INPUT 1 -p tcp --dport 8083 -j ACCEPT
iptables -I INPUT 1 -p tcp --dport 1090 -j ACCEPT


/usr/share/jboss-as/bin/standalone.sh can run too.

The below is printing out information when I input engine-setup:
###################################
#engine-setup
Welcome to oVirt Engine setup utility
In order to proceed the installer must stop the ovirt-engine service
Would you like to stop the ovirt-engine service? (yes|no): yes
oVirt Engine uses httpd to proxy requests to the application server.
It looks like the httpd installed locally is being actively used.
The installer can override current configuration .
Alternatively you can use JBoss directly (on ports higher than 1024)
Do you wish to override current httpd configuration and restart the service? ['yes'| 'no']  [yes] : yse
Error: response is not part of the following accepted answers: yes, no
oVirt Engine uses httpd to proxy requests to the application server.
It looks like the httpd installed locally is being actively used.
The installer can override current configuration .
Alternatively you can use JBoss directly (on ports higher than 1024)
Do you wish to override current httpd configuration and restart the service? ['yes'| 'no']  [yes] : yes
HTTP Port  [80] : 80
Error while trying to read parameter HTTP_PORT from user.
Please check log file /var/log/ovirt-engine/engine-setup_2013_01_17_04_18_17.log for more information
Below is /var/log/ovirt-engine/engine-setup_2013_01_17_04_18_17.log
###########/var/log/ovirt-engine/engine-setup_2013_01_17_04_18_17.log ##########

2013-01-17 04:18:17::DEBUG::common_utils::1255::root:: checking if firewalld service is available
2013-01-17 04:18:17::DEBUG::common_utils::430::root:: Executing command --> '/bin/systemctl show firewalld'
2013-01-17 04:18:17::DEBUG::common_utils::468::root:: output =
2013-01-17 04:18:17::DEBUG::common_utils::469::root:: stderr = Failed to issue method call: Unit name firewalld is not valid.

2013-01-17 04:18:17::DEBUG::common_utils::470::root:: retcode = 1
2013-01-17 04:18:17::DEBUG::common_utils::1255::root:: checking if iptables service is available
2013-01-17 04:18:17::DEBUG::common_utils::430::root:: Executing command --> '/bin/systemctl show iptables'
2013-01-17 04:18:17::DEBUG::common_utils::468::root:: output =
2013-01-17 04:18:17::DEBUG::common_utils::469::root:: stderr = Failed to issue method call: Unit name iptables is not valid.

2013-01-17 04:18:17::DEBUG::common_utils::470::root:: retcode = 1
2013-01-17 04:18:17::DEBUG::common_utils::430::root:: Executing command --> '/sbin/ip addr'
2013-01-17 04:18:17::DEBUG::common_utils::468::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: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 2c:41:38:a8:41:13 brd ff:ff:ff:ff:ff:ff
    inet 10.239.131.232/24 brd 10.239.131.255 scope global em1
    inet6 fe80::2e41:38ff:fea8:4113/64 scope link
       valid_lft forever preferred_lft forever

2013-01-17 04:18:17::DEBUG::common_utils::469::root:: stderr =
2013-01-17 04:18:17::DEBUG::common_utils::470::root:: retcode = 0
2013-01-17 04:18:17::DEBUG::common_utils::589::root:: Found IP Address: 10.239.131.232
2013-01-17 04:18:17::DEBUG::engine-setup::2139::root:: initiating command line option parser
2013-01-17 04:18:17::DEBUG::engine-setup::2106::root:: checking total memory
2013-01-17 04:18:17::DEBUG::common_utils::430::root:: Executing command --> '/usr/bin/free -m'
2013-01-17 04:18:17::DEBUG::common_utils::468::root:: output =              total       used       free     shared    buffers     cached
Mem:          7945        627       7317          0         15        406
-/+ buffers/cache:        205       7739
Swap:         9983          0       9983

2013-01-17 04:18:17::DEBUG::common_utils::469::root:: stderr =
2013-01-17 04:18:17::DEBUG::common_utils::470::root:: retcode = 0
2013-01-17 04:18:17::DEBUG::engine-setup::2118::root:: Found a match, amount of memory: 7945
2013-01-17 04:18:17::DEBUG::engine-setup::2008::root:: Entered main(configFile='None')
2013-01-17 04:18:17::DEBUG::engine-setup::1802::root:: stopping ovirt-engine service
2013-01-17 04:18:17::DEBUG::common_utils::967::root:: asking user: Would you like to stop the ovirt-engine service? (yes|no):
2013-01-17 04:18:19::DEBUG::common_utils::971::root:: user answered: yes
2013-01-17 04:18:19::DEBUG::common_utils::1211::root:: stopping ovirt-engine
2013-01-17 04:18:19::DEBUG::common_utils::1248::root:: executing action ovirt-engine on service stop
2013-01-17 04:18:19::DEBUG::common_utils::430::root:: Executing command --> '/sbin/service ovirt-engine stop'
2013-01-17 04:18:19::DEBUG::common_utils::468::root:: output =
2013-01-17 04:18:19::DEBUG::common_utils::469::root:: stderr =
2013-01-17 04:18:19::DEBUG::common_utils::470::root:: retcode = 0
2013-01-17 04:18:19::DEBUG::engine-setup::1532::root:: going over group PORTS
2013-01-17 04:18:19::DEBUG::common_utils::1289::root:: retrieving version for ipa-server rpm
2013-01-17 04:18:19::DEBUG::common_utils::1310::root:: getRpmVersion failed
Traceback (most recent call last):
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 1307, in installed
    getRpmVersion(rpmName=rpm)
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 1301, in getRpmVersion
    raise Exception(output_messages.ERR_READ_RPM_VER % rpmName)
Exception: Error reading version number for package ipa-server
2013-01-17 04:18:19::DEBUG::common_utils::1289::root:: retrieving version for freeipa-server rpm
2013-01-17 04:18:19::DEBUG::common_utils::1310::root:: getRpmVersion failed
Traceback (most recent call last):
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 1307, in installed
    getRpmVersion(rpmName=rpm)
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 1301, in getRpmVersion
    raise Exception(output_messages.ERR_READ_RPM_VER % rpmName)
Exception: Error reading version number for package freeipa-server
2013-01-17 04:18:19::INFO::engine-setup::1541::root:: Comparing pre-conditions; condition: 'True', and match: 'True'
2013-01-17 04:18:20::INFO::engine_validators::199::root:: validateOverrideHttpdConfAndChangePortsAccordingly yse as part of ['yes', 'no']
2013-01-17 04:18:20::INFO::engine_validators::182::root:: Validating yse as part of ['yes', 'no']
2013-01-17 04:18:22::INFO::engine_validators::199::root:: validateOverrideHttpdConfAndChangePortsAccordingly yes as part of ['yes', 'no']
2013-01-17 04:18:22::INFO::engine_validators::182::root:: Validating yes as part of ['yes', 'no']
2013-01-17 04:18:22::DEBUG::engine_validators::207::root:: stopping httpd service
2013-01-17 04:18:22::DEBUG::common_utils::1211::root:: stopping httpd
2013-01-17 04:18:22::DEBUG::common_utils::1248::root:: executing action httpd on service stop
2013-01-17 04:18:22::DEBUG::common_utils::430::root:: Executing command --> '/sbin/service httpd stop'
2013-01-17 04:18:22::DEBUG::common_utils::468::root:: output =
2013-01-17 04:18:22::DEBUG::common_utils::469::root:: stderr =
2013-01-17 04:18:22::DEBUG::common_utils::470::root:: retcode = 0
2013-01-17 04:18:24::DEBUG::engine_validators::62::root:: Validating 80 as a valid TCP Port
2013-01-17 04:18:24::DEBUG::common_utils::394::root:: Checking if TCP port 80 is open by any process
2013-01-17 04:18:24::DEBUG::common_utils::430::root:: Executing command --> '/usr/sbin/lsof -i -n -P'
2013-01-17 04:18:24::ERROR::engine-setup::601::root:: Traceback (most recent call last):
  File "/usr/local/bin/engine-setup", line 574, in _getInputFromUser
    if param.getKey("VALIDATION_FUNC")(userInput, param.getKey("OPTION_LIST")):
  File "/usr/local/share/ovirt-engine/scripts/engine_validators.py", line 81, in validatePort
    (portOpen, process, pid) = utils.isTcpPortOpen(param)
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 399, in isTcpPortOpen
    output, rc = execCmd(cmdList=cmd, failOnError=True, msg=output_messages.ERR_EXP_LSOF)
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 454, in execCmd
    env=env,
  File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1249, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

2013-01-17 04:18:25::ERROR::engine-setup::1577::root:: Traceback (most recent call last):
  File "/usr/local/bin/engine-setup", line 1546, in _handleInteractiveParams
    input_param(param)
  File "/usr/local/bin/engine-setup", line 628, in input_param
    _getInputFromUser(param)
  File "/usr/local/bin/engine-setup", line 602, in _getInputFromUser
    raise Exception(output_messages.ERR_EXP_READ_INPUT_PARAM % (param.getKey("CONF_NAME")))
Exception: Error while trying to read parameter HTTP_PORT from user.

2013-01-17 04:18:25::DEBUG::engine-setup::1875::root:: *** The following params were used as user input:
2013-01-17 04:18:25::DEBUG::engine-setup::1880::root:: override-httpd-config: yes
2013-01-17 04:18:25::ERROR::engine-setup::2295::root:: Traceback (most recent call last):
  File "/usr/local/bin/engine-setup", line 2290, in <module>
    main(confFile)
  File "/usr/local/bin/engine-setup", line 2028, in main
    _handleParams(configFile)
  File "/usr/local/bin/engine-setup", line 1589, in _handleParams
   _handleInteractiveParams()
  File "/usr/local/bin/engine-setup", line 1546, in _handleInteractiveParams
    input_param(param)
  File "/usr/local/bin/engine-setup", line 628, in input_param
    _getInputFromUser(param)
  File "/usr/local/bin/engine-setup", line 602, in _getInputFromUser
    raise Exception(output_messages.ERR_EXP_READ_INPUT_PARAM % (param.getKey("CONF_NAME")))
Exception: Error while trying to read parameter HTTP_PORT from user.


Best Regards,
Dave Chen

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

From oschreib at redhat.com  Thu Jan 17 07:38:47 2013
From: oschreib at redhat.com (Ofer Schreiber)
Date: Thu, 17 Jan 2013 02:38:47 -0500 (EST)
Subject: [Engine-devel] engine 3.2 branching completed
Message-ID: <1885937409.5446688.1358408327759.JavaMail.root@redhat.com>

Hey,

A new branch, engine_3.2, has been created. (starting from git hash 98770a60be484706f2c916447254d04d7ac7dcbd)
ovirt-engine-3.2 will be created from this branch.

If you have any important blocker, please remember to push changes to this branch as well.

Thanks.
---
Ofer Schreiber
Red Hat Israel, Ra'anana

+972-9-7692347
www.redhat.com


From jhernand at redhat.com  Thu Jan 17 11:04:28 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Thu, 17 Jan 2013 12:04:28 +0100
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
Message-ID: <50F7DABC.3070801@redhat.com>

Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT in the 
master branch:

http://gerrit.ovirt.org/11143
-- 
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 lhornyak at redhat.com  Thu Jan 17 13:20:30 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Thu, 17 Jan 2013 08:20:30 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <50F7DABC.3070801@redhat.com>
Message-ID: <278562976.3646241.1358428830513.JavaMail.root@redhat.com>

Nice to see -SNAPSHOT in the version.

----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, January 17, 2013 1:04:28 PM
> Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT in
> the
> master branch:
> 
> http://gerrit.ovirt.org/11143
> --
> 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.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alonbl at redhat.com  Thu Jan 17 13:24:37 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 17 Jan 2013 08:24:37 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <50F7DABC.3070801@redhat.com>
Message-ID: <680117766.2393918.1358429077312.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, January 17, 2013 1:04:28 PM
> Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT in
> the
> master branch:

Usually you put SNAPSHOT to maven artifacts but _master suffix to tarball and package, no?

> 
> http://gerrit.ovirt.org/11143
> --
> 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.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From awels at redhat.com  Thu Jan 17 22:00:13 2013
From: awels at redhat.com (Alexander Wels)
Date: Thu, 17 Jan 2013 17:00:13 -0500
Subject: [Engine-devel] Unable to add second Data domain to my Data Center.
Message-ID: <3704436.14KyoNIg2M@awels>

Hello,

I am trying to setup a host for a seperate oVirt engine/node environment 
(version 3.1). I managed to get my host up and running and active in my Data 
Center. I managed to create 4 storage domains on that host. 2 Data domains and 
1 ISO domain and one Export domain.

I am successful in attaching the ISO/Export/smaller Data domain to my Data 
Center. The web admin interface is indicating they are active. I activated my 
smaller test Data domain because I was having some issues earlier getting my 
storage attached. I worked through those issues and now I want to attach my 
actual Data storage so I can detach the test one. Whenever I attempt to attach 
the storage I get an error message and when I look in the vdsm log I see the 
following:

Thread-2801::ERROR::2013-01-17 16:55:22,340::task::853::TaskManager.Task::
(_setError) Task=`fe1ac39e-7681-4043-b2b7-b6e2611e1c10`::Unexpected error
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/task.py", line 861, in _run
    return fn(*args, **kargs)
  File "/usr/share/vdsm/logUtils.py", line 38, in wrapper
    res = f(*args, **kwargs)
  File "/usr/share/vdsm/storage/hsm.py", line 960, in attachStorageDomain
    pool.attachSD(sdUUID)
  File "/usr/share/vdsm/storage/securable.py", line 63, in wrapper
    return f(self, *args, **kwargs)
  File "/usr/share/vdsm/storage/sp.py", line 919, in attachSD
    dom.acquireClusterLock(self.id)
  File "/usr/share/vdsm/storage/sd.py", line 429, in acquireClusterLock
    self._clusterLock.acquire(hostID)
  File "/usr/share/vdsm/storage/safelease.py", line 205, in acquire
    "Cannot acquire cluster lock", str(e))
AcquireLockFailure: Cannot obtain lock: 
"id=807c2e91-52c3-4779-9ebb-771b96bf5a4c, rc=28, out=Cannot acquire cluster 
lock, err=(28, 'Sanlock resource not acquired', 'No space left on device')"
Thread-2801::DEBUG::2013-01-17 16:55:22,341::task::872::TaskManager.Task::
(_run) Task=`fe1ac39e-7681-4043-b2b7-b6e2611e1c10`::Task._run: 
fe1ac39e-7681-4043-b2b7-b6e2611e1c10 ('807c2e91-52c3-4779-9ebb-771b96bf5a4c', 
'58
49b030-626e-47cb-ad90-3ce782d831b3') {} failed - stopping task

Which seems to indicate the disk is full. Which is not the case as this is a 
brand new machine with a fresh install and a 1T drive in it. The error does 
point to sanlock so when I look at the sanlock log I see this:

2013-01-17 16:55:22-0500 4161 [3187]: r12 cmd_acquire 3,14,3830 invalid 
lockspace found -1 failed 0 name 807c2e91-52c3-4779-9ebb-771b96bf5a4c

I googled around for that particular error message and I couldn't find anyone 
with any suggestions as to the source of that problem. 

Could someone please give me a pointer of where to look or help me debug the 
issue.

Thanks,
Alexander



From wei.d.chen at intel.com  Fri Jan 18 13:39:28 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Fri, 18 Jan 2013 13:39:28 +0000
Subject: [Engine-devel] Upgrading Database Schema...error
Message-ID: <C5A0092C63E939488005F15F736A81121147EE@SHSMSX101.ccr.corp.intel.com>

Hi ,
  There is a problem in engine-setup-- "Upgrading Database Schema...error". The env is setup with ovirt-engine 3.2.0 from http://www.ovirt.org/Building_oVirt_engine,
The below are printing out info and log. Could you help me to check it?  Thanks in advance.


***
Installing:
Configuring oVirt-engine...                             [ DONE ]
Configuring JVM...                                    [ DONE ]
Creating CA...                                        [ DONE ]
Updating ovirt-engine service...                          [ DONE ]
Setting Database Configuration...                        [ DONE ]
Setting Database Security...                            [ DONE ]
Upgrading Database Schema...                         [ ERROR ]
Database backup failed

###############  log  ###################

2013-01-18 08:05:50::DEBUG::common_utils::469::root:: stderr =
2013-01-18 08:05:50::DEBUG::common_utils::470::root:: retcode = 0
2013-01-18 08:05:50::DEBUG::engine-setup::2125::root:: Found a match, amount of memory: 7945
2013-01-18 08:05:50::DEBUG::engine-setup::2015::root:: Entered main(configFile='None')
2013-01-18 08:05:50::DEBUG::engine-setup::1809::root:: stopping ovirt-engine service
2013-01-18 08:05:50::DEBUG::common_utils::967::root:: asking user: Would you like to stop the ovirt-engine service? (yes|no):
2013-01-18 08:05:51::DEBUG::common_utils::971::root:: user answered: yes
2013-01-18 08:05:51::DEBUG::common_utils::1213::root:: stopping ovirt-engine
2013-01-18 08:05:51::DEBUG::common_utils::1250::root:: executing action ovirt-engine on service stop
2013-01-18 08:05:51::DEBUG::common_utils::430::root:: Executing command --> '/sbin/service ovirt-engine stop'
2013-01-18 08:05:51::DEBUG::common_utils::468::root:: output =
2013-01-18 08:05:51::DEBUG::common_utils::469::root:: stderr =
2013-01-18 08:05:51::DEBUG::common_utils::470::root:: retcode = 0
2013-01-18 08:05:51::DEBUG::engine-setup::1539::root:: going over group PORTS
2013-01-18 08:05:51::DEBUG::common_utils::1291::root:: retrieving version for ipa-server rpm
2013-01-18 08:05:51::DEBUG::common_utils::1312::root:: getRpmVersion failed
Traceback (most recent call last):
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 1309, in installed
    getRpmVersion(rpmName=rpm)
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 1303, in getRpmVersion
    raise Exception(output_messages.ERR_READ_RPM_VER % rpmName)
Exception: Error reading version number for package ipa-server
2013-01-18 08:05:51::DEBUG::common_utils::1291::root:: retrieving version for freeipa-server rpm
2013-01-18 08:05:51::DEBUG::common_utils::1312::root:: getRpmVersion failed
Traceback (most recent call last):
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 1309, in installed
    getRpmVersion(rpmName=rpm)
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 1303, in getRpmVersion
    raise Exception(output_messages.ERR_READ_RPM_VER % rpmName)
Exception: Error reading version number for package freeipa-server
2013-01-18 08:05:51::INFO::engine-setup::1548::root:: Comparing pre-conditions; condition: 'True', and match: 'True'
2013-01-18 08:05:52::INFO::engine_validators::199::root:: validateOverrideHttpdConfAndChangePortsAccordingly yes as part of ['yes', 'no']
2013-01-18 08:05:52::INFO::engine_validators::182::root:: Validating yes as part of ['yes', 'no']
2013-01-18 08:05:52::DEBUG::engine_validators::207::root:: stopping httpd service
2013-01-18 08:05:52::DEBUG::common_utils::1213::root:: stopping httpd
2013-01-18 08:05:52::DEBUG::common_utils::1250::root:: executing action httpd on service stop
2013-01-18 08:05:52::DEBUG::common_utils::430::root:: Executing command --> '/sbin/service httpd stop'
2013-01-18 08:05:52::DEBUG::common_utils::468::root:: output =
2013-01-18 08:05:52::DEBUG::common_utils::469::root:: stderr =
2013-01-18 08:05:52::DEBUG::common_utils::470::root:: retcode = 0
2013-01-18 08:05:52::DEBUG::engine-setup::1539::root:: going over group ALL_PARAMS
2013-01-18 08:05:52::INFO::engine-setup::1548::root:: Comparing pre-conditions; condition: 'True', and match: 'True'
2013-01-18 08:05:52::DEBUG::engine-setup::551::root:: setting default value (no) for key (RANDOM_PASSWORDS)
2013-01-18 08:05:52::DEBUG::engine-setup::551::root:: setting default value (00:1A:4A:EF:83:00-00:1A:4A:EF:83:FF) for key (MAC_RANGE)
2013-01-18 08:05:56::INFO::engine_validators::307::root:: Validating localhost as a FQDN
2013-01-18 08:05:56::INFO::engine_validators::216::root:: validating localhost as a valid domain string
2013-01-18 08:05:56::DEBUG::common_utils::967::root:: asking user: User input failed validation, do you still wish to use it? (yes|no):
2013-01-18 08:05:57::DEBUG::common_utils::971::root:: user answered: yes
2013-01-18 08:05:59::DEBUG::engine_validators::161::root:: Validating password
2013-01-18 08:05:59::WARNING::engine_validators::175::root:: Password failed check
2013-01-18 08:05:59::WARNING::engine_validators::176::root:: Traceback (most recent call last):
  File "/usr/local/share/ovirt-engine/scripts/engine_validators.py", line 173, in validatePassword
    cracklib.FascistCheck(param)
ValueError: it is too simplistic/systematic

2013-01-18 08:06:01::DEBUG::engine-setup::630::root:: Param confirmation passed, value for both questions is identical
2013-01-18 08:06:05::INFO::engine_validators::388::root:: validating organization name
2013-01-18 08:06:07::INFO::engine_validators::182::root:: Validating NFS as part of ['NFS', 'FC', 'ISCSI', 'POSIXFS']
2013-01-18 08:06:09::INFO::engine_validators::182::root:: Validating local as part of ['remote', 'local']
2013-01-18 08:06:09::DEBUG::engine-setup::1539::root:: going over group REMOTE_DB
2013-01-18 08:06:09::INFO::engine-setup::1548::root:: Comparing pre-conditions; condition: 'False', and match: 'True'
2013-01-18 08:06:09::DEBUG::engine-setup::1577::root:: no post condition check for group REMOTE_DB
2013-01-18 08:06:09::DEBUG::engine-setup::1539::root:: going over group LOCAL_DB
2013-01-18 08:06:09::INFO::engine-setup::1548::root:: Comparing pre-conditions; condition: 'False', and match: 'False'
2013-01-18 08:06:11::DEBUG::engine_validators::161::root:: Validating password
2013-01-18 08:06:11::WARNING::engine_validators::175::root:: Password failed check
2013-01-18 08:06:11::WARNING::engine_validators::176::root:: Traceback (most recent call last):
  File "/usr/local/share/ovirt-engine/scripts/engine_validators.py", line 173, in validatePassword
    cracklib.FascistCheck(param)
ValueError: it is too simplistic/systematic

2013-01-18 08:06:13::DEBUG::engine-setup::630::root:: Param confirmation passed, value for both questions is identical
2013-01-18 08:06:13::DEBUG::engine-setup::1539::root:: going over group NFS
2013-01-18 08:06:14::INFO::engine_validators::182::root:: Validating yes as part of ['yes', 'no']
2013-01-18 08:06:14::INFO::engine-setup::1548::root:: Comparing pre-conditions; condition: 'yes', and match: 'yes'
2013-01-18 08:06:17::INFO::engine_validators::26::root:: validating /var/lib/exports/iso as a valid mount point
2013-01-18 08:06:17::DEBUG::engine_validators::552::root:: attempting to write temp file to /var/lib
2013-01-18 08:06:17::DEBUG::common_utils::636::root:: Checking available space on /var/lib
2013-01-18 08:06:17::DEBUG::common_utils::641::root:: Available space on /var/lib is 45004
2013-01-18 08:06:17::DEBUG::engine-setup::551::root:: setting default value (ISO_DOMAIN) for key (ISO_DOMAIN_NAME)
2013-01-18 08:06:17::DEBUG::engine-setup::1539::root:: going over group IPTABLES
2013-01-18 08:06:17::INFO::engine-setup::1548::root:: Comparing pre-conditions; condition: 'True', and match: 'True'
2013-01-18 08:06:19::INFO::engine_validators::182::root:: Validating None as part of ['None']
2013-01-18 08:06:19::INFO::engine-setup::1618::root:: *** User input summary ***
2013-01-18 08:06:19::INFO::engine-setup::1631::root:: override-httpd-config: yes
2013-01-18 08:06:19::INFO::engine-setup::1631::root:: http-port: 80
2013-01-18 08:06:19::INFO::engine-setup::1631::root:: https-port: 443
2013-01-18 08:06:19::INFO::engine-setup::1631::root:: host-fqdn: localhost
2013-01-18 08:06:19::INFO::engine-setup::1627::root:: auth-pass: ********
2013-01-18 08:06:19::INFO::engine-setup::1631::root:: org-name: sh.intel.com
2013-01-18 08:06:19::INFO::engine-setup::1631::root:: default-dc-type: NFS
2013-01-18 08:06:19::INFO::engine-setup::1631::root:: db-remote-install: local
2013-01-18 08:06:19::INFO::engine-setup::1627::root:: db-local-pass: ********
2013-01-18 08:06:19::INFO::engine-setup::1631::root:: nfs-mp: /var/lib/exports/iso
2013-01-18 08:06:19::INFO::engine-setup::1631::root:: config-nfs: yes
2013-01-18 08:06:19::INFO::engine-setup::1631::root:: override-firewall: None
2013-01-18 08:06:19::INFO::engine-setup::1633::root:: *** User input summary ***
2013-01-18 08:06:19::DEBUG::common_utils::967::root:: asking user: Proceed with the configuration listed above? (yes|no):
2013-01-18 08:06:20::DEBUG::common_utils::971::root:: user answered: yes
2013-01-18 08:06:20::DEBUG::engine-setup::1652::root:: user chose to accept user parameters
2013-01-18 08:06:20::DEBUG::engine-setup::2044::root:: {'ORG_NAME': 'sh.intel.com', 'HOST_FQDN': 'localhost', 'OVERRIDE_FIREWALL': 'None', 'HTTP_PORT': '80', 'HTTPS_PORT': '443', 'DC_TYPE': 'NFS', 'DC_TYPE_ENUM': <common_utils.Enum object at 0x19b9bd0>, 'AUTH_PASS': '********', 'DB_LOCAL_PASS': '********', 'RANDOM_PASSWORDS': 'no', 'ISO_DOMAIN_NAME': 'ISO_DOMAIN', 'AUTH_PASS_CONFIRMED': '********', 'OVERRIDE_HTTPD_CONFIG': 'yes', 'MAC_RANGE': '00:1A:4A:EF:83:00-00:1A:4A:EF:83:FF', 'DB_LOCAL_PASS_CONFIRMED': '********', 'CONFIG_NFS': 'yes', 'DB_REMOTE_INSTALL': 'local', 'NFS_MP': '/var/lib/exports/iso'}
2013-01-18 08:06:20::DEBUG::engine-setup::2047::root:: Entered Configuration stage
2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running setMaxSharedMemory
2013-01-18 08:06:20::DEBUG::common_utils::430::root:: Executing command --> '/sbin/sysctl -b kernel.shmmax'
2013-01-18 08:06:20::DEBUG::common_utils::468::root:: output = 35554432
2013-01-18 08:06:20::DEBUG::common_utils::469::root:: stderr =
2013-01-18 08:06:20::DEBUG::common_utils::470::root:: retcode = 0
2013-01-18 08:06:20::DEBUG::engine-setup::1721::root:: current shared memory max in kernel is 35554432, there is no need to update the kernel parameters
2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running _findJavaHome
2013-01-18 08:06:20::DEBUG::common_utils::430::root:: Executing command --> '/usr/lib/jvm/java-1.7.0-openjdk.x86_64/bin/java -version'
2013-01-18 08:06:20::DEBUG::common_utils::468::root:: output =
2013-01-18 08:06:20::DEBUG::common_utils::469::root:: stderr = java version "1.7.0_b147-icedtea"
OpenJDK Runtime Environment (fedora-2.1.fc17.6-x86_64)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)

2013-01-18 08:06:20::DEBUG::common_utils::470::root:: retcode = 0
2013-01-18 08:06:20::DEBUG::common_utils::430::root:: Executing command --> '/usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java -version'
2013-01-18 08:06:20::DEBUG::common_utils::468::root:: output =
2013-01-18 08:06:20::DEBUG::common_utils::469::root:: stderr = java version "1.7.0_b147-icedtea"
OpenJDK Runtime Environment (fedora-2.1.fc17.6-x86_64)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)

2013-01-18 08:06:20::DEBUG::common_utils::470::root:: retcode = 0
2013-01-18 08:06:20::DEBUG::common_utils::1395::root:: JVM path "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64" doesn't contain the Java compiler.
2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running _createCA
2013-01-18 08:06:20::WARNING::engine-setup::867::root:: Keystore already exists, skipped certificates creation phase
2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running _editSysconfig
2013-01-18 08:06:20::DEBUG::common_utils::777::root:: found existing pgpass file /etc/ovirt-engine/.pgpass, fetching DB user value
2013-01-18 08:06:20::DEBUG::common_utils::1121::root:: Loading text file handler
2013-01-18 08:06:20::DEBUG::common_utils::1153::root:: Engine has been configured
2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running _updatePgPassFile
2013-01-18 08:06:20::DEBUG::engine-setup::1289::root:: found existing pgpass file, backing current to /etc/ovirt-engine/.pgpass.2013_01_18_08_06_20
2013-01-18 08:06:20::INFO::engine-setup::1313::root:: Using default db credentials
2013-01-18 08:06:20::DEBUG::engine-setup::1890::root:: Checking if db is already installed..
2013-01-18 08:06:20::DEBUG::engine-setup::1891::root:: Checking the presence of .pgpass file
2013-01-18 08:06:20::DEBUG::common_utils::477::root:: running sql query 'select 1' on db server: 'localhost'.
2013-01-18 08:06:20::DEBUG::common_utils::430::root:: Executing command --> '/usr/bin/psql -h localhost -p 5432 -U postgres -d engine -c select 1'
2013-01-18 08:06:20::DEBUG::common_utils::468::root:: output =  ?column?
----------
        1
(1 row)


2013-01-18 08:06:20::DEBUG::common_utils::469::root:: stderr =
2013-01-18 08:06:20::DEBUG::common_utils::470::root:: retcode = 0
2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running _encryptDBPass
2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running _configEncryptedPass
2013-01-18 08:06:20::DEBUG::common_utils::1183::root:: Encrypting database password.
2013-01-18 08:06:20::DEBUG::common_utils::777::root:: found existing pgpass file /etc/ovirt-engine/.pgpass, fetching DB user value
2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running stopRhevmDbRelatedServices
2013-01-18 08:06:20::DEBUG::common_utils::1237::root:: Service was not stopped. there for we're not starting it
2013-01-18 08:06:20::DEBUG::common_utils::1237::root:: Service was not stopped. there for we're not starting it
2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running _upgradeDB
2013-01-18 08:06:20::DEBUG::engine-setup::1082::root:: backing up engine db to file /var/lib/ovirt-engine/backups/tmpmGCzCX.sql
2013-01-18 08:06:20::DEBUG::common_utils::823::root:: engine DB Backup started
2013-01-18 08:06:20::DEBUG::common_utils::430::root:: Executing command --> '/usr/bin/pg_dump -C -E UTF8 --disable-dollar-quoting --disable-triggers --format=p -f /var/lib/ovirt-engine/backups/tmpmGCzCX.sql -U engine -h localhost -p 5432 engine'
2013-01-18 08:06:20::DEBUG::common_utils::468::root:: output =
2013-01-18 08:06:20::DEBUG::common_utils::469::root:: stderr = pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  permission denied for relation tags_vm_pool_map
pg_dump: The command was: LOCK TABLE public.tags_vm_pool_map IN ACCESS SHARE MODE

2013-01-18 08:06:20::DEBUG::common_utils::470::root:: retcode = 1
2013-01-18 08:06:20::DEBUG::setup_sequences::62::root:: Traceback (most recent call last):
  File "/usr/local/share/ovirt-engine/scripts/setup_sequences.py", line 60, in run
    function()
  File "/usr/local/bin/engine-setup", line 1085, in _upgradeDB
    utils.backupDB(basedefs.DB_NAME, getDbUser(), dbBackupFile, getDbHostName(), getDbPort())
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 837, in backupDB
    output, rc = execCmd(cmdList=cmd, failOnError=True, msg=output_messages.ERR_DB_BACKUP, envDict=getPgPassEnv())
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 473, in execCmd
    raise Exception(msg)
Exception: Database backup failed

2013-01-18 08:06:20::DEBUG::engine-setup::1882::root:: *** The following params were used as user input:
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: override-httpd-config: yes
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: http-port: 80
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: https-port: 443
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: random-passwords: no
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: mac-range: 00:1A:4A:EF:83:00-00:1A:4A:EF:83:FF
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: host-fqdn: localhost
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: auth-pass: ********
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: org-name: sh.intel.com
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: default-dc-type: NFS
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: db-remote-install: local
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: db-host: localhost
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: db-local-pass: ********
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: nfs-mp: /var/lib/exports/iso
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: iso-domain-name: ISO_DOMAIN
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: config-nfs: yes
2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: override-firewall: None
2013-01-18 08:06:20::ERROR::engine-setup::2303::root:: Traceback (most recent call last):
  File "/usr/local/bin/engine-setup", line 2297, in <module>
    main(confFile)
  File "/usr/local/bin/engine-setup", line 2080, in main
    runSequences()
  File "/usr/local/bin/engine-setup", line 2002, in runSequences
    controller.runAllSequences()
  File "/usr/local/share/ovirt-engine/scripts/setup_controller.py", line 54, in runAllSequences
    sequence.run()
  File "/usr/local/share/ovirt-engine/scripts/setup_sequences.py", line 154, in run
    step.run()
  File "/usr/local/share/ovirt-engine/scripts/setup_sequences.py", line 60, in run
    function()
  File "/usr/local/bin/engine-setup", line 1085, in _upgradeDB
    utils.backupDB(basedefs.DB_NAME, getDbUser(), dbBackupFile, getDbHostName(), getDbPort())
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 837, in backupDB
    output, rc = execCmd(cmdList=cmd, failOnError=True, msg=output_messages.ERR_DB_BACKUP, envDict=getPgPassEnv())
  File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line 473, in execCmd
    raise Exception(msg)
Exception: Database backup failed


Best Regards,
Dave Chen

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

From derez at redhat.com  Thu Jan 17 22:01:54 2013
From: derez at redhat.com (Daniel Erez)
Date: Thu, 17 Jan 2013 17:01:54 -0500 (EST)
Subject: [Engine-devel] UI Plugin - Shell-In-A-Box
In-Reply-To: <440871596.5854136.1358459076932.JavaMail.root@redhat.com>
Message-ID: <1351843185.5858674.1358460114653.JavaMail.root@redhat.com>

Hi all,

I've created a new UI plugin to the WebAdmin for making ssh connections
to hosts using a web based AJAX terminal emulator.

Details, explanations and screenshots on my blog:
http://derezvir.blogspot.co.il/2013/01/ovirt-webadmin-shellinabox-ui-plugin.html

Please feel free to comment/contact me if you find it useful or have any trouble installing it... :)

Regards,
Daniel


From mpastern at redhat.com  Sun Jan 20 13:24:58 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 20 Jan 2013 15:24:58 +0200
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <50F7DABC.3070801@redhat.com>
References: <50F7DABC.3070801@redhat.com>
Message-ID: <50FBF02A.2070805@redhat.com>

On 01/17/2013 01:04 PM, Juan Hernandez wrote:
> Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT in the master branch:

+1

> 
> http://gerrit.ovirt.org/11143


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From eedri at redhat.com  Sun Jan 20 20:55:17 2013
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 20 Jan 2013 15:55:17 -0500 (EST)
Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_dao_unit_tests -
 Build # 3091 - Still Failing!
In-Reply-To: <1736255227.2330.1358714619537.JavaMail.jenkins@jenkins.ovirt.org>
Message-ID: <50615386.1413810.1358715317349.JavaMail.root@redhat.com>

looks like this patch cause new unit test failure, can you check?

http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git&a=commit&h=6fa50420e5c8365bea80125dc3e559d9edb57396

thanks

eyal edri
ovirt infra 

----- Original Message -----
> From: "Jenkins oVirt Server" <jenkins at ovirt.org>
> To: eedri at redhat.com, engine-patches at ovirt.org, oliel at redhat.com, yzaslavs at redhat.com, infra at ovirt.org,
> gerrit2 at gerrit.ovirt.org
> Sent: Sunday, January 20, 2013 10:43:39 PM
> Subject: [oVirt Jenkins] ovirt_engine_dao_unit_tests - Build # 3091 - Still Failing!
> 
> Project: http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/
> Build: http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/3091/
> Build Number: 3091
> Build Status:  Still Failing
> Triggered By: Started by upstream project "ovirt_engine" build number
> 4,062
> 
> -------------------------------------
> Changes Since Last Success:
> -------------------------------------
> Changes for Build #3084
> [gerrit2] core, db: add cluster view
> 
> [gerrit2] webadmin: show data center name for each cluster
> 
> 
> Changes for Build #3085
> [asaf] restapi: A check for possible NPE BackendVmsResource:remove
> method
> 
> 
> Changes for Build #3086
> [gerrit2] core: improve error msg text in storage connection
> 
> 
> Changes for Build #3087
> 
> Changes for Build #3088
> 
> Changes for Build #3089
> [gerrit2] webadmin: move disks popup - fix alignment
> 
> [gerrit2] core: prevent failure on concurrent live snapshots
> 
> 
> Changes for Build #3090
> [gerrit2] core: required space validation - destination domain
> 
> 
> Changes for Build #3091
> [gerrit2] engine: VmDeviceUtils cleanup
> 
> [gerrit2] engine: VmDeviceUtils cleanup 2
> 
> 
> 
> 
> -----------------
> Failed Tests:
> -----------------
> 1 tests failed.
> FAILED:
>  org.ovirt.engine.core.dao.GeneralDbDAOTest.testBusinessEntitiesColumnSize
> 
> Error Message:
> null
> 
> Stack Trace:
> java.lang.AssertionError
> 	at org.junit.Assert.fail(Assert.java:92)
> 	at org.junit.Assert.assertTrue(Assert.java:43)
> 	at org.junit.Assert.assertTrue(Assert.java:54)
> 	at
> 	org.ovirt.engine.core.dao.GeneralDbDAOTest.testBusinessEntitiesColumnSize(GeneralDbDAOTest.java:109)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at
> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at
> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at
> 	org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> 	at
> 	org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> 	at
> 	org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> 	at
> 	org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> 	at
> 	org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 	at
> 	org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
> 	at
> 	org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:83)
> 	at
> 	org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
> 	at
> 	org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
> 	at
> 	org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> 	at
> 	org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 	at
> 	org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
> 	at
> 	org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> 	at
> 	org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
> 	at
> 	org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> 	at
> 	org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> 	at
> 	org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at
> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at
> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at
> 	org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> 	at
> 	org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> 	at
> 	org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> 	at
> 	org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> 	at
> 	org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
> 
> 
>  
> 
> ------------------
> Build Log:
> ------------------
> [...truncated 2360 lines...]
> [INFO] oVirt Engine API Definition ....................... SUCCESS
> [23.693s]
> [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS
> [0.343s]
> [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS
> [10.271s]
> [INFO] oVirt RESTful API Backend Integration Type Mappers  SUCCESS
> [14.818s]
> [INFO] oVirt RESTful API Backend Integration JAX-RS Resources
>  SUCCESS [40.124s]
> [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS
> [1.910s]
> [INFO] oVirt Engine Web Root ............................. SUCCESS
> [2.551s]
> [INFO] oVirt Configuration Tool .......................... SUCCESS
> [6.414s]
> [INFO] Notifier Service package .......................... SUCCESS
> [0.141s]
> [INFO] Notifier Service .................................. SUCCESS
> [5.686s]
> [INFO] Notifier Service Resources ........................ SUCCESS
> [1.920s]
> [INFO] oVirt Modules :: Frontend ......................... SUCCESS
> [0.009s]
> [INFO] oVirt APIs ........................................ SUCCESS
> [0.263s]
> [INFO] oVirt generic API ................................. SUCCESS
> [4.969s]
> [INFO] oVirt Modules :: Webadmin ......................... SUCCESS
> [0.032s]
> [INFO] oVirt Modules - ui ................................ SUCCESS
> [0.029s]
> [INFO] Extensions for GWT ................................ SUCCESS
> [4.873s]
> [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS
> [5.718s]
> [INFO] Frontend for GWT UI Projects ...................... SUCCESS
> [10.426s]
> [INFO] UICommonWeb ....................................... SUCCESS
> [1:01.569s]
> [INFO] oVirt GWT UI common infrastructure ................ SUCCESS
> [57.257s]
> [INFO] WebAdmin .......................................... SUCCESS
> [1:02.782s]
> [INFO] UserPortal ........................................ SUCCESS
> [27.034s]
> [INFO] oVirt WARs ........................................ SUCCESS
> [0.061s]
> [INFO] oVirt Web Application Module ...................... SUCCESS
> [4.323s]
> [INFO] oVirt Server EAR .................................. SUCCESS
> [19.885s]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 11:01.731s
> [INFO] Finished at: Sun Jan 20 15:42:41 EST 2013
> [INFO] Final Memory: 320M/653M
> [INFO]
> ------------------------------------------------------------------------
> [ovirt_engine_dao_unit_tests] $
> /home/jenkins/tools/Maven/3.0.4/bin/mvn -f
> backend/manager/modules/dal/pom.xml
> -Dmaven.repo.local=/home/jenkins/workspace/ovirt_engine_dao_unit_tests/.repository
> test -Penable-dao-tests
> -Dengine.db.url.escaped=jdbc:postgresql://localhost/ovirt_engine_dao_unit_tests_3091
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective
> model for org.ovirt.engine.core:dal:jar:3.2.0
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-resources-plugin is missing. @ line
> 124, column 15
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-surefire-plugin is missing. @ line
> 180, column 15
> [WARNING] 'build.plugins.plugin.version' for
> org.codehaus.mojo:exec-maven-plugin is missing. @ line 144, column
> 15
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer
> support building such malformed projects.
> [WARNING]
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Data Access Layer 3.2.0
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @
> dal ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 208 resources
> [INFO] Copying 8 resources
> [INFO] Copying 9 resources
> [INFO] Copying 1 resource
> [INFO]
> [INFO] --- maven-resources-plugin:2.5:copy-resources (copy-resources)
> @ dal ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 1 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
> dal ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-checkstyle-plugin:2.6:check (default) @ dal ---
> [INFO] Starting audit...
> Audit done.
> 
> [INFO]
> [INFO] --- maven-resources-plugin:2.5:testResources
> (default-testResources) @ dal ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 9 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:testCompile
> (default-testCompile) @ dal ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-surefire-plugin:2.10:test (default-test) @ dal ---
> [INFO] Surefire report directory:
> /home/jenkins/workspace/ovirt_engine_dao_unit_tests/backend/manager/modules/dal/target/surefire-reports
> 
> -------------------------------------------------------
>  T E S T S
> -------------------------------------------------------
> Running org.ovirt.engine.core.dao.AdGroupDAOTest
> log4j:WARN No appenders could be found for logger
> (org.springframework.test.context.junit4.SpringJUnit4ClassRunner).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
> for more info.
> SLF4J: The requested version 1.5.11 by your slf4j binding is not
> compatible with [1.5.5, 1.5.6]
> SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for
> further details.
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 10.723 sec
> Running org.ovirt.engine.core.dao.ActionGroupDAOTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.249
> sec
> Running org.ovirt.engine.core.dao.ImageDaoTest
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.552
> sec
> Running org.ovirt.engine.core.dao.VdsStaticDAOTest
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.325
> sec
> Running org.ovirt.engine.core.dao.VmDynamicDAOTest
> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.372 sec
> Running org.ovirt.engine.core.dao.ImageStorageDomainMapDaoTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.131
> sec
> Running org.ovirt.engine.core.dao.DiskImageDynamicDAOTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.177
> sec
> Running org.ovirt.engine.core.dao.VmDAOTest
> Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.304 sec
> Running org.ovirt.engine.core.dao.VmStatisticsDAOTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.212
> sec
> Running org.ovirt.engine.core.dao.VmDeviceDAOTest
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 1.756 sec
> Running org.ovirt.engine.core.dao.VdsSpmIdMapDAOTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.386
> sec
> Running org.ovirt.engine.core.dao.network.InterfaceDaoTest
> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.59
> sec
> Running org.ovirt.engine.core.dao.network.NetworkViewDaoTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026
> sec
> Running org.ovirt.engine.core.dao.network.NetworkClusterDaoTest
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.579 sec
> Running org.ovirt.engine.core.dao.network.NetworkDaoTest
> Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.694 sec
> Running org.ovirt.engine.core.dao.network.VmNetworkStatisticsDaoTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.236
> sec
> Running org.ovirt.engine.core.dao.network.VmNetworkInterfaceDaoTest
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.617 sec
> Running org.ovirt.engine.core.dao.gluster.GlusterVolumeDaoTest
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 1.088 sec
> Running org.ovirt.engine.core.dao.gluster.GlusterOptionDaoTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.087
> sec
> Running org.ovirt.engine.core.dao.gluster.GlusterBrickDaoTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.054
> sec
> Running org.ovirt.engine.core.dao.RoleGroupMapDAOTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1
> sec
> Running org.ovirt.engine.core.dao.VdsStatisticsDAOTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001
> sec
> Running org.ovirt.engine.core.dao.EventDAOTest
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.151 sec
> Running org.ovirt.engine.core.dao.StepDaoTest
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.175 sec
> Running org.ovirt.engine.core.dao.StorageDomainStaticDAOTest
> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.355 sec
> Running org.ovirt.engine.core.dao.SnapshotDaoTest
> Tests run: 35, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.75
> sec
> Running org.ovirt.engine.core.dao.VdsGroupDAOTest
> Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.589 sec
> Running org.ovirt.engine.core.dao.JobDaoTest
> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.197 sec
> Running org.ovirt.engine.core.dao.StorageDomainDAOTest
> Tests run: 33, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.053 sec
> Running org.ovirt.engine.core.dao.LunDAOTest
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.294
> sec
> Running org.ovirt.engine.core.dao.AsyncTaskDAOTest
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 1.246 sec
> Running org.ovirt.engine.core.dao.MultiThreadedDAOTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.43
> sec
> Running org.ovirt.engine.core.dao.JobSubjectEntityDaoTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.043
> sec
> Running org.ovirt.engine.core.dao.VdsDAOTest
> Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 1.703 sec
> Running org.ovirt.engine.core.dao.GeneralDbDAOTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.418
> sec <<< FAILURE!
> Running org.ovirt.engine.core.dao.StorageServerConnectionDAOTest
> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.234 sec
> Running org.ovirt.engine.core.dao.QuotaDAOTest
> Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.822 sec
> Running org.ovirt.engine.core.dao.VmPoolDAOTest
> Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.882 sec
> Running org.ovirt.engine.core.dao.VmStaticDAOTest
> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.459 sec
> Running org.ovirt.engine.core.dao.DbFacadeDAOTest
> Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 1.635 sec
> Running org.ovirt.engine.core.dao.StoragePoolDAOTest
> Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.344 sec
> Running org.ovirt.engine.core.dao.TagDAOTest
> Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.952 sec
> Running org.ovirt.engine.core.dao.StoragePoolIsoMapDAOTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.155
> sec
> Running org.ovirt.engine.core.dao.BusinessEntitySnapshotDAOTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09
> sec
> Running org.ovirt.engine.core.dao.BaseDiskDaoTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.128
> sec
> Running org.ovirt.engine.core.dao.PermissionDAOTest
> Tests run: 45, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.43
> sec
> Running org.ovirt.engine.core.dao.DiskLunMapDaoTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.066
> sec
> Running org.ovirt.engine.core.dao.BookmarkDAOTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09
> sec
> Running org.ovirt.engine.core.dao.VdsDynamicDAOTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046
> sec
> Running org.ovirt.engine.core.dao.DiskImageDAOTest
> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.608 sec
> Running org.ovirt.engine.core.dao.DiskDaoTest
> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.551 sec
> Running
> org.ovirt.engine.core.dao.StorageServerConnectionLunMapDAOTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.122
> sec
> Running org.ovirt.engine.core.dao.StorageDomainDynamicDAOTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.143
> sec
> Running org.ovirt.engine.core.dao.RoleDAOTest
> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.171 sec
> Running org.ovirt.engine.core.dao.AuditLogDAOTest
> Tests run: 23, Failures: 0, Errors: 0, Skipped: 2, Time elapsed:
> 0.886 sec
> Running org.ovirt.engine.core.dao.VmGuestAgentInterfaceDaoTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.368
> sec
> Running org.ovirt.engine.core.dao.VmTemplateDAOTest
> Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.393 sec
> Running org.ovirt.engine.core.dao.DbUserDAOTest
> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.42
> sec
> Running org.ovirt.engine.core.dao.VmAndTemplatesGenerationsDaoTest
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.003 sec
> Running org.ovirt.engine.core.dao.RepoFileMetaDataDAOTest
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.197 sec
> Running org.ovirt.engine.core.dao.VdcOptionDAOTest
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.247
> sec
> 
> Results :
> 
> Failed tests:
>   testBusinessEntitiesColumnSize(org.ovirt.engine.core.dao.GeneralDbDAOTest)
> 
> Tests run: 836, Failures: 1, Errors: 0, Skipped: 2
> 
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 1:11.748s
> [INFO] Finished at: Sun Jan 20 15:44:07 EST 2013
> [INFO] Final Memory: 12M/490M
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.10:test
> (default-test) on project dal: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> /home/jenkins/workspace/ovirt_engine_dao_unit_tests/backend/manager/modules/dal/target/surefire-reports
> for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug
> logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> Build step 'Invoke top-level Maven targets' marked build as failure
> Performing Post build task...
> Match found for :INFO : True
> Logical operation result is TRUE
> Running script  : dropdb -U postgres ${JOB_NAME}_${BUILD_NUMBER} ||
> /bin/true
> [ovirt_engine_dao_unit_tests] $ /bin/sh -xe
> /tmp/hudson1484332558942245432.sh
> + dropdb -U postgres ovirt_engine_dao_unit_tests_3091
> POST BUILD TASK : SUCCESS
> END OF POST BUILD TASK : 0
> Recording test results
> IRC notifier plugin: Sending notification to: #ovirt-jenkins
> Email was triggered for: Failure
> Sending email for trigger: Failure
> 


From gpadgett at redhat.com  Mon Jan 21 06:26:18 2013
From: gpadgett at redhat.com (Greg Padgett)
Date: Mon, 21 Jan 2013 01:26:18 -0500
Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_dao_unit_tests -
 Build # 3091 - Still Failing!
In-Reply-To: <50615386.1413810.1358715317349.JavaMail.root@redhat.com>
References: <50615386.1413810.1358715317349.JavaMail.root@redhat.com>
Message-ID: <50FCDF8A.2030405@redhat.com>

On 01/20/2013 03:55 PM, Eyal Edri wrote:
> looks like this patch cause new unit test failure, can you check?
>
> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git&a=commit&h=6fa50420e5c8365bea80125dc3e559d9edb57396
>
> thanks
>
> eyal edri
> ovirt infra

Thanks, indeed it does.  Fix submitted: http://gerrit.ovirt.org/11236

>
> ----- Original Message -----
>> From: "Jenkins oVirt Server" <jenkins at ovirt.org>
>> To: eedri at redhat.com, engine-patches at ovirt.org, oliel at redhat.com, yzaslavs at redhat.com, infra at ovirt.org,
>> gerrit2 at gerrit.ovirt.org
>> Sent: Sunday, January 20, 2013 10:43:39 PM
>> Subject: [oVirt Jenkins] ovirt_engine_dao_unit_tests - Build # 3091 - Still Failing!
>>
>> Project: http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/
>> Build: http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/3091/
>> Build Number: 3091
>> Build Status:  Still Failing
>> Triggered By: Started by upstream project "ovirt_engine" build number
>> 4,062
>>
>> -------------------------------------
>> Changes Since Last Success:
>> -------------------------------------
>> Changes for Build #3084
>> [gerrit2] core, db: add cluster view
>>
>> [gerrit2] webadmin: show data center name for each cluster
>>
>>
>> Changes for Build #3085
>> [asaf] restapi: A check for possible NPE BackendVmsResource:remove
>> method
>>
>>
>> Changes for Build #3086
>> [gerrit2] core: improve error msg text in storage connection
>>
>>
>> Changes for Build #3087
>>
>> Changes for Build #3088
>>
>> Changes for Build #3089
>> [gerrit2] webadmin: move disks popup - fix alignment
>>
>> [gerrit2] core: prevent failure on concurrent live snapshots
>>
>>
>> Changes for Build #3090
>> [gerrit2] core: required space validation - destination domain
>>
>>
>> Changes for Build #3091
>> [gerrit2] engine: VmDeviceUtils cleanup
>>
>> [gerrit2] engine: VmDeviceUtils cleanup 2
>>
>>
>>
>>
>> -----------------
>> Failed Tests:
>> -----------------
>> 1 tests failed.
>> FAILED:
>>   org.ovirt.engine.core.dao.GeneralDbDAOTest.testBusinessEntitiesColumnSize
>>
>> Error Message:
>> null
>>
>> Stack Trace:
>> java.lang.AssertionError
>> 	at org.junit.Assert.fail(Assert.java:92)
>> 	at org.junit.Assert.assertTrue(Assert.java:43)
>> 	at org.junit.Assert.assertTrue(Assert.java:54)
>> 	at
>> 	org.ovirt.engine.core.dao.GeneralDbDAOTest.testBusinessEntitiesColumnSize(GeneralDbDAOTest.java:109)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at
>> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> 	at
>> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.lang.reflect.Method.invoke(Method.java:601)
>> 	at
>> 	org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>> 	at
>> 	org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>> 	at
>> 	org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>> 	at
>> 	org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>> 	at
>> 	org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>> 	at
>> 	org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
>> 	at
>> 	org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:83)
>> 	at
>> 	org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
>> 	at
>> 	org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
>> 	at
>> 	org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>> 	at
>> 	org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>> 	at
>> 	org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
>> 	at
>> 	org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
>> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>> 	at
>> 	org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
>> 	at
>> 	org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
>> 	at
>> 	org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
>> 	at
>> 	org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at
>> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> 	at
>> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.lang.reflect.Method.invoke(Method.java:601)
>> 	at
>> 	org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
>> 	at
>> 	org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
>> 	at
>> 	org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
>> 	at
>> 	org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
>> 	at
>> 	org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
>>
>>
>>
>>
>> ------------------
>> Build Log:
>> ------------------
>> [...truncated 2360 lines...]
>> [INFO] oVirt Engine API Definition ....................... SUCCESS
>> [23.693s]
>> [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS
>> [0.343s]
>> [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS
>> [10.271s]
>> [INFO] oVirt RESTful API Backend Integration Type Mappers  SUCCESS
>> [14.818s]
>> [INFO] oVirt RESTful API Backend Integration JAX-RS Resources
>>   SUCCESS [40.124s]
>> [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS
>> [1.910s]
>> [INFO] oVirt Engine Web Root ............................. SUCCESS
>> [2.551s]
>> [INFO] oVirt Configuration Tool .......................... SUCCESS
>> [6.414s]
>> [INFO] Notifier Service package .......................... SUCCESS
>> [0.141s]
>> [INFO] Notifier Service .................................. SUCCESS
>> [5.686s]
>> [INFO] Notifier Service Resources ........................ SUCCESS
>> [1.920s]
>> [INFO] oVirt Modules :: Frontend ......................... SUCCESS
>> [0.009s]
>> [INFO] oVirt APIs ........................................ SUCCESS
>> [0.263s]
>> [INFO] oVirt generic API ................................. SUCCESS
>> [4.969s]
>> [INFO] oVirt Modules :: Webadmin ......................... SUCCESS
>> [0.032s]
>> [INFO] oVirt Modules - ui ................................ SUCCESS
>> [0.029s]
>> [INFO] Extensions for GWT ................................ SUCCESS
>> [4.873s]
>> [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS
>> [5.718s]
>> [INFO] Frontend for GWT UI Projects ...................... SUCCESS
>> [10.426s]
>> [INFO] UICommonWeb ....................................... SUCCESS
>> [1:01.569s]
>> [INFO] oVirt GWT UI common infrastructure ................ SUCCESS
>> [57.257s]
>> [INFO] WebAdmin .......................................... SUCCESS
>> [1:02.782s]
>> [INFO] UserPortal ........................................ SUCCESS
>> [27.034s]
>> [INFO] oVirt WARs ........................................ SUCCESS
>> [0.061s]
>> [INFO] oVirt Web Application Module ...................... SUCCESS
>> [4.323s]
>> [INFO] oVirt Server EAR .................................. SUCCESS
>> [19.885s]
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] BUILD SUCCESS
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 11:01.731s
>> [INFO] Finished at: Sun Jan 20 15:42:41 EST 2013
>> [INFO] Final Memory: 320M/653M
>> [INFO]
>> ------------------------------------------------------------------------
>> [ovirt_engine_dao_unit_tests] $
>> /home/jenkins/tools/Maven/3.0.4/bin/mvn -f
>> backend/manager/modules/dal/pom.xml
>> -Dmaven.repo.local=/home/jenkins/workspace/ovirt_engine_dao_unit_tests/.repository
>> test -Penable-dao-tests
>> -Dengine.db.url.escaped=jdbc:postgresql://localhost/ovirt_engine_dao_unit_tests_3091
>> [INFO] Scanning for projects...
>> [WARNING]
>> [WARNING] Some problems were encountered while building the effective
>> model for org.ovirt.engine.core:dal:jar:3.2.0
>> [WARNING] 'build.plugins.plugin.version' for
>> org.apache.maven.plugins:maven-resources-plugin is missing. @ line
>> 124, column 15
>> [WARNING] 'build.plugins.plugin.version' for
>> org.apache.maven.plugins:maven-surefire-plugin is missing. @ line
>> 180, column 15
>> [WARNING] 'build.plugins.plugin.version' for
>> org.codehaus.mojo:exec-maven-plugin is missing. @ line 144, column
>> 15
>> [WARNING]
>> [WARNING] It is highly recommended to fix these problems because they
>> threaten the stability of your build.
>> [WARNING]
>> [WARNING] For this reason, future Maven versions might no longer
>> support building such malformed projects.
>> [WARNING]
>> [INFO]
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Building Data Access Layer 3.2.0
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @
>> dal ---
>> [debug] execute contextualize
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] Copying 208 resources
>> [INFO] Copying 8 resources
>> [INFO] Copying 9 resources
>> [INFO] Copying 1 resource
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.5:copy-resources (copy-resources)
>> @ dal ---
>> [debug] execute contextualize
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] Copying 1 resource
>> [INFO]
>> [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
>> dal ---
>> [INFO] Nothing to compile - all classes are up to date
>> [INFO]
>> [INFO] --- maven-checkstyle-plugin:2.6:check (default) @ dal ---
>> [INFO] Starting audit...
>> Audit done.
>>
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.5:testResources
>> (default-testResources) @ dal ---
>> [debug] execute contextualize
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] Copying 9 resources
>> [INFO]
>> [INFO] --- maven-compiler-plugin:2.3.2:testCompile
>> (default-testCompile) @ dal ---
>> [INFO] Nothing to compile - all classes are up to date
>> [INFO]
>> [INFO] --- maven-surefire-plugin:2.10:test (default-test) @ dal ---
>> [INFO] Surefire report directory:
>> /home/jenkins/workspace/ovirt_engine_dao_unit_tests/backend/manager/modules/dal/target/surefire-reports
>>
>> -------------------------------------------------------
>>   T E S T S
>> -------------------------------------------------------
>> Running org.ovirt.engine.core.dao.AdGroupDAOTest
>> log4j:WARN No appenders could be found for logger
>> (org.springframework.test.context.junit4.SpringJUnit4ClassRunner).
>> log4j:WARN Please initialize the log4j system properly.
>> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
>> for more info.
>> SLF4J: The requested version 1.5.11 by your slf4j binding is not
>> compatible with [1.5.5, 1.5.6]
>> SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for
>> further details.
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 10.723 sec
>> Running org.ovirt.engine.core.dao.ActionGroupDAOTest
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.249
>> sec
>> Running org.ovirt.engine.core.dao.ImageDaoTest
>> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.552
>> sec
>> Running org.ovirt.engine.core.dao.VdsStaticDAOTest
>> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.325
>> sec
>> Running org.ovirt.engine.core.dao.VmDynamicDAOTest
>> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.372 sec
>> Running org.ovirt.engine.core.dao.ImageStorageDomainMapDaoTest
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.131
>> sec
>> Running org.ovirt.engine.core.dao.DiskImageDynamicDAOTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.177
>> sec
>> Running org.ovirt.engine.core.dao.VmDAOTest
>> Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 3.304 sec
>> Running org.ovirt.engine.core.dao.VmStatisticsDAOTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.212
>> sec
>> Running org.ovirt.engine.core.dao.VmDeviceDAOTest
>> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 1.756 sec
>> Running org.ovirt.engine.core.dao.VdsSpmIdMapDAOTest
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.386
>> sec
>> Running org.ovirt.engine.core.dao.network.InterfaceDaoTest
>> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.59
>> sec
>> Running org.ovirt.engine.core.dao.network.NetworkViewDaoTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026
>> sec
>> Running org.ovirt.engine.core.dao.network.NetworkClusterDaoTest
>> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.579 sec
>> Running org.ovirt.engine.core.dao.network.NetworkDaoTest
>> Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.694 sec
>> Running org.ovirt.engine.core.dao.network.VmNetworkStatisticsDaoTest
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.236
>> sec
>> Running org.ovirt.engine.core.dao.network.VmNetworkInterfaceDaoTest
>> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.617 sec
>> Running org.ovirt.engine.core.dao.gluster.GlusterVolumeDaoTest
>> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 1.088 sec
>> Running org.ovirt.engine.core.dao.gluster.GlusterOptionDaoTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.087
>> sec
>> Running org.ovirt.engine.core.dao.gluster.GlusterBrickDaoTest
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.054
>> sec
>> Running org.ovirt.engine.core.dao.RoleGroupMapDAOTest
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1
>> sec
>> Running org.ovirt.engine.core.dao.VdsStatisticsDAOTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001
>> sec
>> Running org.ovirt.engine.core.dao.EventDAOTest
>> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.151 sec
>> Running org.ovirt.engine.core.dao.StepDaoTest
>> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.175 sec
>> Running org.ovirt.engine.core.dao.StorageDomainStaticDAOTest
>> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.355 sec
>> Running org.ovirt.engine.core.dao.SnapshotDaoTest
>> Tests run: 35, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.75
>> sec
>> Running org.ovirt.engine.core.dao.VdsGroupDAOTest
>> Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.589 sec
>> Running org.ovirt.engine.core.dao.JobDaoTest
>> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.197 sec
>> Running org.ovirt.engine.core.dao.StorageDomainDAOTest
>> Tests run: 33, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 2.053 sec
>> Running org.ovirt.engine.core.dao.LunDAOTest
>> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.294
>> sec
>> Running org.ovirt.engine.core.dao.AsyncTaskDAOTest
>> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 1.246 sec
>> Running org.ovirt.engine.core.dao.MultiThreadedDAOTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.43
>> sec
>> Running org.ovirt.engine.core.dao.JobSubjectEntityDaoTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.043
>> sec
>> Running org.ovirt.engine.core.dao.VdsDAOTest
>> Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 1.703 sec
>> Running org.ovirt.engine.core.dao.GeneralDbDAOTest
>> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.418
>> sec <<< FAILURE!
>> Running org.ovirt.engine.core.dao.StorageServerConnectionDAOTest
>> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.234 sec
>> Running org.ovirt.engine.core.dao.QuotaDAOTest
>> Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.822 sec
>> Running org.ovirt.engine.core.dao.VmPoolDAOTest
>> Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.882 sec
>> Running org.ovirt.engine.core.dao.VmStaticDAOTest
>> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.459 sec
>> Running org.ovirt.engine.core.dao.DbFacadeDAOTest
>> Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 1.635 sec
>> Running org.ovirt.engine.core.dao.StoragePoolDAOTest
>> Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.344 sec
>> Running org.ovirt.engine.core.dao.TagDAOTest
>> Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.952 sec
>> Running org.ovirt.engine.core.dao.StoragePoolIsoMapDAOTest
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.155
>> sec
>> Running org.ovirt.engine.core.dao.BusinessEntitySnapshotDAOTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09
>> sec
>> Running org.ovirt.engine.core.dao.BaseDiskDaoTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.128
>> sec
>> Running org.ovirt.engine.core.dao.PermissionDAOTest
>> Tests run: 45, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.43
>> sec
>> Running org.ovirt.engine.core.dao.DiskLunMapDaoTest
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.066
>> sec
>> Running org.ovirt.engine.core.dao.BookmarkDAOTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09
>> sec
>> Running org.ovirt.engine.core.dao.VdsDynamicDAOTest
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046
>> sec
>> Running org.ovirt.engine.core.dao.DiskImageDAOTest
>> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.608 sec
>> Running org.ovirt.engine.core.dao.DiskDaoTest
>> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.551 sec
>> Running
>> org.ovirt.engine.core.dao.StorageServerConnectionLunMapDAOTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.122
>> sec
>> Running org.ovirt.engine.core.dao.StorageDomainDynamicDAOTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.143
>> sec
>> Running org.ovirt.engine.core.dao.RoleDAOTest
>> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.171 sec
>> Running org.ovirt.engine.core.dao.AuditLogDAOTest
>> Tests run: 23, Failures: 0, Errors: 0, Skipped: 2, Time elapsed:
>> 0.886 sec
>> Running org.ovirt.engine.core.dao.VmGuestAgentInterfaceDaoTest
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.368
>> sec
>> Running org.ovirt.engine.core.dao.VmTemplateDAOTest
>> Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.393 sec
>> Running org.ovirt.engine.core.dao.DbUserDAOTest
>> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.42
>> sec
>> Running org.ovirt.engine.core.dao.VmAndTemplatesGenerationsDaoTest
>> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.003 sec
>> Running org.ovirt.engine.core.dao.RepoFileMetaDataDAOTest
>> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 0.197 sec
>> Running org.ovirt.engine.core.dao.VdcOptionDAOTest
>> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.247
>> sec
>>
>> Results :
>>
>> Failed tests:
>>    testBusinessEntitiesColumnSize(org.ovirt.engine.core.dao.GeneralDbDAOTest)
>>
>> Tests run: 836, Failures: 1, Errors: 0, Skipped: 2
>>
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 1:11.748s
>> [INFO] Finished at: Sun Jan 20 15:44:07 EST 2013
>> [INFO] Final Memory: 12M/490M
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-surefire-plugin:2.10:test
>> (default-test) on project dal: There are test failures.
>> [ERROR]
>> [ERROR] Please refer to
>> /home/jenkins/workspace/ovirt_engine_dao_unit_tests/backend/manager/modules/dal/target/surefire-reports
>> for the individual test results.
>> [ERROR] -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with
>> the -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug
>> logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
>> Build step 'Invoke top-level Maven targets' marked build as failure
>> Performing Post build task...
>> Match found for :INFO : True
>> Logical operation result is TRUE
>> Running script  : dropdb -U postgres ${JOB_NAME}_${BUILD_NUMBER} ||
>> /bin/true
>> [ovirt_engine_dao_unit_tests] $ /bin/sh -xe
>> /tmp/hudson1484332558942245432.sh
>> + dropdb -U postgres ovirt_engine_dao_unit_tests_3091
>> POST BUILD TASK : SUCCESS
>> END OF POST BUILD TASK : 0
>> Recording test results
>> IRC notifier plugin: Sending notification to: #ovirt-jenkins
>> Email was triggered for: Failure
>> Sending email for trigger: Failure
>>



From yzaslavs at redhat.com  Mon Jan 21 06:27:36 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 21 Jan 2013 01:27:36 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <50FBF02A.2070805@redhat.com>
Message-ID: <1335359114.12496216.1358749656386.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Juan Hernandez" <jhernand at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Sunday, January 20, 2013 3:24:58 PM
> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> On 01/17/2013 01:04 PM, Juan Hernandez wrote:
> > Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT in
> > the master branch:
> 
> +1
I agree, and this is not the only place where should start marking "3.3.0" - what about upgrade scripts?

> 
> > 
> > http://gerrit.ovirt.org/11143
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Mon Jan 21 07:03:42 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 21 Jan 2013 02:03:42 -0500 (EST)
Subject: [Engine-devel] Upgrading Database Schema...error
In-Reply-To: <C5A0092C63E939488005F15F736A81121147EE@SHSMSX101.ccr.corp.intel.com>
Message-ID: <1557296299.12515389.1358751822463.JavaMail.root@redhat.com>

Hi, 
I see the following erorr - 

xecuting command --> '/usr/bin/pg_dump -C -E UTF8 --disable-dollar-quoting --disable-triggers --format=p -f /var/lib/ovirt-engine/backups/tmpmGCzCX.sql -U engine -h localhost -p 5432 engine' 
2013-01-18 08:06:20: EBUG::common_utils::468::root:: output = 
2013-01-18 08:06:20: EBUG::common_utils::469::root:: stderr = pg_dump: SQL command failed 
pg_dump: Error message from server: ERROR: permission denied for relation tags_vm_pool_map 

Can you please provide more info on how you created the db? (i.e - command line of running create_db.sh or create_db_devel.sh) 
When I encountered such issues it was because I created the db (i.e - run create_db.sh or create_db_devel.sh) with user A, but tried to backup/restore with user B 

Thanks, 
Yair 

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

> From: "Wei D Chen" <wei.d.chen at intel.com>
> To: "engine-devel at ovirt.org" <engine-devel at ovirt.org>
> Cc: "Quan Xu" <quan.xu at intel.com>
> Sent: Friday, January 18, 2013 3:39:28 PM
> Subject: [Engine-devel] Upgrading Database Schema...error

> Hi ,
> There is a problem in engine-setup-- ?Upgrading Database
> Schema...error?. The env is setup with ovirt-engine 3.2.0 from
> http://www.ovirt.org/Building_oVirt_engine ,
> The below are printing out info and log. Could you help me to check
> it? Thanks in advance.

> ***
> Installing:
> Configuring oVirt-engine... [ DONE ]
> Configuring JVM... [ DONE ]
> Creating CA... [ DONE ]
> Updating ovirt-engine service... [ DONE ]
> Setting Database Configuration... [ DONE ]
> Setting Database Security... [ DONE ]
> Upgrading Database Schema... [ ERROR ]
> Database backup failed

> ############### log ###################

> 2013-01-18 08:05:50::DEBUG::common_utils::469::root:: stderr =
> 2013-01-18 08:05:50::DEBUG::common_utils::470::root:: retcode = 0
> 2013-01-18 08:05:50::DEBUG::engine-setup::2125::root:: Found a match,
> amount of memory: 7945
> 2013-01-18 08:05:50::DEBUG::engine-setup::2015::root:: Entered
> main(configFile='None')
> 2013-01-18 08:05:50::DEBUG::engine-setup::1809::root:: stopping
> ovirt-engine service
> 2013-01-18 08:05:50::DEBUG::common_utils::967::root:: asking user:
> Would you like to stop the ovirt-engine service? (yes|no):
> 2013-01-18 08:05:51::DEBUG::common_utils::971::root:: user answered:
> yes
> 2013-01-18 08:05:51::DEBUG::common_utils::1213::root:: stopping
> ovirt-engine
> 2013-01-18 08:05:51::DEBUG::common_utils::1250::root:: executing
> action ovirt-engine on service stop
> 2013-01-18 08:05:51::DEBUG::common_utils::430::root:: Executing
> command --> '/sbin/service ovirt-engine stop'
> 2013-01-18 08:05:51::DEBUG::common_utils::468::root:: output =
> 2013-01-18 08:05:51::DEBUG::common_utils::469::root:: stderr =
> 2013-01-18 08:05:51::DEBUG::common_utils::470::root:: retcode = 0
> 2013-01-18 08:05:51::DEBUG::engine-setup::1539::root:: going over
> group PORTS
> 2013-01-18 08:05:51::DEBUG::common_utils::1291::root:: retrieving
> version for ipa-server rpm
> 2013-01-18 08:05:51::DEBUG::common_utils::1312::root:: getRpmVersion
> failed
> Traceback (most recent call last):
> File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 1309, in installed
> getRpmVersion(rpmName=rpm)
> File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 1303, in getRpmVersion
> raise Exception(output_messages.ERR_READ_RPM_VER % rpmName)
> Exception: Error reading version number for package ipa-server
> 2013-01-18 08:05:51::DEBUG::common_utils::1291::root:: retrieving
> version for freeipa-server rpm
> 2013-01-18 08:05:51::DEBUG::common_utils::1312::root:: getRpmVersion
> failed
> Traceback (most recent call last):
> File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 1309, in installed
> getRpmVersion(rpmName=rpm)
> File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 1303, in getRpmVersion
> raise Exception(output_messages.ERR_READ_RPM_VER % rpmName)
> Exception: Error reading version number for package freeipa-server
> 2013-01-18 08:05:51::INFO::engine-setup::1548::root:: Comparing
> pre-conditions; condition: 'True', and match: 'True'
> 2013-01-18 08:05:52::INFO::engine_validators::199::root::
> validateOverrideHttpdConfAndChangePortsAccordingly yes as part of
> ['yes', 'no']
> 2013-01-18 08:05:52::INFO::engine_validators::182::root:: Validating
> yes as part of ['yes', 'no']
> 2013-01-18 08:05:52::DEBUG::engine_validators::207::root:: stopping
> httpd service
> 2013-01-18 08:05:52::DEBUG::common_utils::1213::root:: stopping httpd
> 2013-01-18 08:05:52::DEBUG::common_utils::1250::root:: executing
> action httpd on service stop
> 2013-01-18 08:05:52::DEBUG::common_utils::430::root:: Executing
> command --> '/sbin/service httpd stop'
> 2013-01-18 08:05:52::DEBUG::common_utils::468::root:: output =
> 2013-01-18 08:05:52::DEBUG::common_utils::469::root:: stderr =
> 2013-01-18 08:05:52::DEBUG::common_utils::470::root:: retcode = 0
> 2013-01-18 08:05:52::DEBUG::engine-setup::1539::root:: going over
> group ALL_PARAMS
> 2013-01-18 08:05:52::INFO::engine-setup::1548::root:: Comparing
> pre-conditions; condition: 'True', and match: 'True'
> 2013-01-18 08:05:52::DEBUG::engine-setup::551::root:: setting default
> value (no) for key (RANDOM_PASSWORDS)
> 2013-01-18 08:05:52::DEBUG::engine-setup::551::root:: setting default
> value (00:1A:4A:EF:83:00-00:1A:4A:EF:83:FF) for key (MAC_RANGE)
> 2013-01-18 08:05:56::INFO::engine_validators::307::root:: Validating
> localhost as a FQDN
> 2013-01-18 08:05:56::INFO::engine_validators::216::root:: validating
> localhost as a valid domain string
> 2013-01-18 08:05:56::DEBUG::common_utils::967::root:: asking user:
> User input failed validation, do you still wish to use it? (yes|no):
> 2013-01-18 08:05:57::DEBUG::common_utils::971::root:: user answered:
> yes
> 2013-01-18 08:05:59::DEBUG::engine_validators::161::root:: Validating
> password
> 2013-01-18 08:05:59::WARNING::engine_validators::175::root:: Password
> failed check
> 2013-01-18 08:05:59::WARNING::engine_validators::176::root::
> Traceback (most recent call last):
> File "/usr/local/share/ovirt-engine/scripts/engine_validators.py",
> line 173, in validatePassword
> cracklib.FascistCheck(param)
> ValueError: it is too simplistic/systematic

> 2013-01-18 08:06:01::DEBUG::engine-setup::630::root:: Param
> confirmation passed, value for both questions is identical
> 2013-01-18 08:06:05::INFO::engine_validators::388::root:: validating
> organization name
> 2013-01-18 08:06:07::INFO::engine_validators::182::root:: Validating
> NFS as part of ['NFS', 'FC', 'ISCSI', 'POSIXFS']
> 2013-01-18 08:06:09::INFO::engine_validators::182::root:: Validating
> local as part of ['remote', 'local']
> 2013-01-18 08:06:09::DEBUG::engine-setup::1539::root:: going over
> group REMOTE_DB
> 2013-01-18 08:06:09::INFO::engine-setup::1548::root:: Comparing
> pre-conditions; condition: 'False', and match: 'True'
> 2013-01-18 08:06:09::DEBUG::engine-setup::1577::root:: no post
> condition check for group REMOTE_DB
> 2013-01-18 08:06:09::DEBUG::engine-setup::1539::root:: going over
> group LOCAL_DB
> 2013-01-18 08:06:09::INFO::engine-setup::1548::root:: Comparing
> pre-conditions; condition: 'False', and match: 'False'
> 2013-01-18 08:06:11::DEBUG::engine_validators::161::root:: Validating
> password
> 2013-01-18 08:06:11::WARNING::engine_validators::175::root:: Password
> failed check
> 2013-01-18 08:06:11::WARNING::engine_validators::176::root::
> Traceback (most recent call last):
> File "/usr/local/share/ovirt-engine/scripts/engine_validators.py",
> line 173, in validatePassword
> cracklib.FascistCheck(param)
> ValueError: it is too simplistic/systematic

> 2013-01-18 08:06:13::DEBUG::engine-setup::630::root:: Param
> confirmation passed, value for both questions is identical
> 2013-01-18 08:06:13::DEBUG::engine-setup::1539::root:: going over
> group NFS
> 2013-01-18 08:06:14::INFO::engine_validators::182::root:: Validating
> yes as part of ['yes', 'no']
> 2013-01-18 08:06:14::INFO::engine-setup::1548::root:: Comparing
> pre-conditions; condition: 'yes', and match: 'yes'
> 2013-01-18 08:06:17::INFO::engine_validators::26::root:: validating
> /var/lib/exports/iso as a valid mount point
> 2013-01-18 08:06:17::DEBUG::engine_validators::552::root:: attempting
> to write temp file to /var/lib
> 2013-01-18 08:06:17::DEBUG::common_utils::636::root:: Checking
> available space on /var/lib
> 2013-01-18 08:06:17::DEBUG::common_utils::641::root:: Available space
> on /var/lib is 45004
> 2013-01-18 08:06:17::DEBUG::engine-setup::551::root:: setting default
> value (ISO_DOMAIN) for key (ISO_DOMAIN_NAME)
> 2013-01-18 08:06:17::DEBUG::engine-setup::1539::root:: going over
> group IPTABLES
> 2013-01-18 08:06:17::INFO::engine-setup::1548::root:: Comparing
> pre-conditions; condition: 'True', and match: 'True'
> 2013-01-18 08:06:19::INFO::engine_validators::182::root:: Validating
> None as part of ['None']
> 2013-01-18 08:06:19::INFO::engine-setup::1618::root:: *** User input
> summary ***
> 2013-01-18 08:06:19::INFO::engine-setup::1631::root::
> override-httpd-config: yes
> 2013-01-18 08:06:19::INFO::engine-setup::1631::root:: http-port: 80
> 2013-01-18 08:06:19::INFO::engine-setup::1631::root:: https-port: 443
> 2013-01-18 08:06:19::INFO::engine-setup::1631::root:: host-fqdn:
> localhost
> 2013-01-18 08:06:19::INFO::engine-setup::1627::root:: auth-pass:
> ********
> 2013-01-18 08:06:19::INFO::engine-setup::1631::root:: org-name:
> sh.intel.com
> 2013-01-18 08:06:19::INFO::engine-setup::1631::root::
> default-dc-type: NFS
> 2013-01-18 08:06:19::INFO::engine-setup::1631::root::
> db-remote-install: local
> 2013-01-18 08:06:19::INFO::engine-setup::1627::root:: db-local-pass:
> ********
> 2013-01-18 08:06:19::INFO::engine-setup::1631::root:: nfs-mp:
> /var/lib/exports/iso
> 2013-01-18 08:06:19::INFO::engine-setup::1631::root:: config-nfs: yes
> 2013-01-18 08:06:19::INFO::engine-setup::1631::root::
> override-firewall: None
> 2013-01-18 08:06:19::INFO::engine-setup::1633::root:: *** User input
> summary ***
> 2013-01-18 08:06:19::DEBUG::common_utils::967::root:: asking user:
> Proceed with the configuration listed above? (yes|no):
> 2013-01-18 08:06:20::DEBUG::common_utils::971::root:: user answered:
> yes
> 2013-01-18 08:06:20::DEBUG::engine-setup::1652::root:: user chose to
> accept user parameters
> 2013-01-18 08:06:20::DEBUG::engine-setup::2044::root:: {'ORG_NAME':
> 'sh.intel.com', 'HOST_FQDN': 'localhost', 'OVERRIDE_FIREWALL':
> 'None', 'HTTP_PORT': '80', 'HTTPS_PORT': '443', 'DC_TYPE': 'NFS',
> 'DC_TYPE_ENUM': <common_utils.Enum object at 0x19b9bd0>,
> 'AUTH_PASS': '********', 'DB_LOCAL_PASS': '********',
> 'RANDOM_PASSWORDS': 'no', 'ISO_DOMAIN_NAME': 'ISO_DOMAIN',
> 'AUTH_PASS_CONFIRMED': '********', 'OVERRIDE_HTTPD_CONFIG': 'yes',
> 'MAC_RANGE': '00:1A:4A:EF:83:00-00:1A:4A:EF:83:FF',
> 'DB_LOCAL_PASS_CONFIRMED': '********', 'CONFIG_NFS': 'yes',
> 'DB_REMOTE_INSTALL': 'local', 'NFS_MP': '/var/lib/exports/iso'}
> 2013-01-18 08:06:20::DEBUG::engine-setup::2047::root:: Entered
> Configuration stage
> 2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running
> setMaxSharedMemory
> 2013-01-18 08:06:20::DEBUG::common_utils::430::root:: Executing
> command --> '/sbin/sysctl -b kernel.shmmax'
> 2013-01-18 08:06:20::DEBUG::common_utils::468::root:: output =
> 35554432
> 2013-01-18 08:06:20::DEBUG::common_utils::469::root:: stderr =
> 2013-01-18 08:06:20::DEBUG::common_utils::470::root:: retcode = 0
> 2013-01-18 08:06:20::DEBUG::engine-setup::1721::root:: current shared
> memory max in kernel is 35554432, there is no need to update the
> kernel parameters
> 2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running
> _findJavaHome
> 2013-01-18 08:06:20::DEBUG::common_utils::430::root:: Executing
> command --> '/usr/lib/jvm/java-1.7.0-openjdk.x86_64/bin/java
> -version'
> 2013-01-18 08:06:20::DEBUG::common_utils::468::root:: output =
> 2013-01-18 08:06:20::DEBUG::common_utils::469::root:: stderr = java
> version "1.7.0_b147-icedtea"
> OpenJDK Runtime Environment (fedora-2.1.fc17.6-x86_64)
> OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)

> 2013-01-18 08:06:20::DEBUG::common_utils::470::root:: retcode = 0
> 2013-01-18 08:06:20::DEBUG::common_utils::430::root:: Executing
> command --> '/usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
> -version'
> 2013-01-18 08:06:20::DEBUG::common_utils::468::root:: output =
> 2013-01-18 08:06:20::DEBUG::common_utils::469::root:: stderr = java
> version "1.7.0_b147-icedtea"
> OpenJDK Runtime Environment (fedora-2.1.fc17.6-x86_64)
> OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)

> 2013-01-18 08:06:20::DEBUG::common_utils::470::root:: retcode = 0
> 2013-01-18 08:06:20::DEBUG::common_utils::1395::root:: JVM path
> "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64" doesn't contain the Java
> compiler.
> 2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running
> _createCA
> 2013-01-18 08:06:20::WARNING::engine-setup::867::root:: Keystore
> already exists, skipped certificates creation phase
> 2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running
> _editSysconfig
> 2013-01-18 08:06:20::DEBUG::common_utils::777::root:: found existing
> pgpass file /etc/ovirt-engine/.pgpass, fetching DB user value
> 2013-01-18 08:06:20::DEBUG::common_utils::1121::root:: Loading text
> file handler
> 2013-01-18 08:06:20::DEBUG::common_utils::1153::root:: Engine has
> been configured
> 2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running
> _updatePgPassFile
> 2013-01-18 08:06:20::DEBUG::engine-setup::1289::root:: found existing
> pgpass file, backing current to
> /etc/ovirt-engine/.pgpass.2013_01_18_08_06_20
> 2013-01-18 08:06:20::INFO::engine-setup::1313::root:: Using default
> db credentials
> 2013-01-18 08:06:20::DEBUG::engine-setup::1890::root:: Checking if db
> is already installed..
> 2013-01-18 08:06:20::DEBUG::engine-setup::1891::root:: Checking the
> presence of .pgpass file
> 2013-01-18 08:06:20::DEBUG::common_utils::477::root:: running sql
> query 'select 1' on db server: 'localhost'.
> 2013-01-18 08:06:20::DEBUG::common_utils::430::root:: Executing
> command --> '/usr/bin/psql -h localhost -p 5432 -U postgres -d
> engine -c select 1'
> 2013-01-18 08:06:20::DEBUG::common_utils::468::root:: output =
> ?column?
> ----------
> 1
> (1 row)

> 2013-01-18 08:06:20::DEBUG::common_utils::469::root:: stderr =
> 2013-01-18 08:06:20::DEBUG::common_utils::470::root:: retcode = 0
> 2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running
> _encryptDBPass
> 2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running
> _configEncryptedPass
> 2013-01-18 08:06:20::DEBUG::common_utils::1183::root:: Encrypting
> database password.
> 2013-01-18 08:06:20::DEBUG::common_utils::777::root:: found existing
> pgpass file /etc/ovirt-engine/.pgpass, fetching DB user value
> 2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running
> stopRhevmDbRelatedServices
> 2013-01-18 08:06:20::DEBUG::common_utils::1237::root:: Service was
> not stopped. there for we're not starting it
> 2013-01-18 08:06:20::DEBUG::common_utils::1237::root:: Service was
> not stopped. there for we're not starting it
> 2013-01-18 08:06:20::DEBUG::setup_sequences::59::root:: running
> _upgradeDB
> 2013-01-18 08:06:20::DEBUG::engine-setup::1082::root:: backing up
> engine db to file /var/lib/ovirt-engine/backups/tmpmGCzCX.sql
> 2013-01-18 08:06:20::DEBUG::common_utils::823::root:: engine DB
> Backup started
> 2013-01-18 08:06:20::DEBUG::common_utils::430::root:: Executing
> command --> '/usr/bin/pg_dump -C -E UTF8 --disable-dollar-quoting
> --disable-triggers --format=p -f
> /var/lib/ovirt-engine/backups/tmpmGCzCX.sql -U engine -h localhost
> -p 5432 engine'
> 2013-01-18 08:06:20::DEBUG::common_utils::468::root:: output =
> 2013-01-18 08:06:20::DEBUG::common_utils::469::root:: stderr =
> pg_dump: SQL command failed
> pg_dump: Error message from server: ERROR: permission denied for
> relation tags_vm_pool_map
> pg_dump: The command was: LOCK TABLE public.tags_vm_pool_map IN
> ACCESS SHARE MODE

> 2013-01-18 08:06:20::DEBUG::common_utils::470::root:: retcode = 1
> 2013-01-18 08:06:20::DEBUG::setup_sequences::62::root:: Traceback
> (most recent call last):
> File "/usr/local/share/ovirt-engine/scripts/setup_sequences.py", line
> 60, in run
> function()
> File "/usr/local/bin/engine-setup", line 1085, in _upgradeDB
> utils.backupDB(basedefs.DB_NAME, getDbUser(), dbBackupFile,
> getDbHostName(), getDbPort())
> File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 837, in backupDB
> output, rc = execCmd(cmdList=cmd, failOnError=True,
> msg=output_messages.ERR_DB_BACKUP, envDict=getPgPassEnv())
> File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 473, in execCmd
> raise Exception(msg)
> Exception: Database backup failed

> 2013-01-18 08:06:20::DEBUG::engine-setup::1882::root:: *** The
> following params were used as user input:
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root::
> override-httpd-config: yes
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: http-port: 80
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: https-port:
> 443
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root::
> random-passwords: no
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: mac-range:
> 00:1A:4A:EF:83:00-00:1A:4A:EF:83:FF
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: host-fqdn:
> localhost
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: auth-pass:
> ********
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: org-name:
> sh.intel.com
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root::
> default-dc-type: NFS
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root::
> db-remote-install: local
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: db-host:
> localhost
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: db-local-pass:
> ********
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: nfs-mp:
> /var/lib/exports/iso
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root::
> iso-domain-name: ISO_DOMAIN
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root:: config-nfs:
> yes
> 2013-01-18 08:06:20::DEBUG::engine-setup::1887::root::
> override-firewall: None
> 2013-01-18 08:06:20::ERROR::engine-setup::2303::root:: Traceback
> (most recent call last):
> File "/usr/local/bin/engine-setup", line 2297, in <module>
> main(confFile)
> File "/usr/local/bin/engine-setup", line 2080, in main
> runSequences()
> File "/usr/local/bin/engine-setup", line 2002, in runSequences
> controller.runAllSequences()
> File "/usr/local/share/ovirt-engine/scripts/setup_controller.py",
> line 54, in runAllSequences
> sequence.run()
> File "/usr/local/share/ovirt-engine/scripts/setup_sequences.py", line
> 154, in run
> step.run()
> File "/usr/local/share/ovirt-engine/scripts/setup_sequences.py", line
> 60, in run
> function()
> File "/usr/local/bin/engine-setup", line 1085, in _upgradeDB
> utils.backupDB(basedefs.DB_NAME, getDbUser(), dbBackupFile,
> getDbHostName(), getDbPort())
> File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 837, in backupDB
> output, rc = execCmd(cmdList=cmd, failOnError=True,
> msg=output_messages.ERR_DB_BACKUP, envDict=getPgPassEnv())
> File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 473, in execCmd
> raise Exception(msg)
> Exception: Database backup failed

> Best Regards,
> Dave Chen

> _______________________________________________
> 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/20130121/285c0efd/attachment.html>

From ofrenkel at redhat.com  Mon Jan 21 08:28:42 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Mon, 21 Jan 2013 03:28:42 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <1335359114.12496216.1358749656386.JavaMail.root@redhat.com>
Message-ID: <931532731.7675833.1358756922734.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Michael Pasternak" <mpastern at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, January 21, 2013 8:27:36 AM
> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Pasternak" <mpastern at redhat.com>
> > To: "Juan Hernandez" <jhernand at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Sunday, January 20, 2013 3:24:58 PM
> > Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> > 
> > On 01/17/2013 01:04 PM, Juan Hernandez wrote:
> > > Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT
> > > in
> > > the master branch:
> > 
> > +1
> I agree, and this is not the only place where should start marking

and cluster compatibility version..

> "3.3.0" - what about upgrade scripts?
> 
> > 
> > > 
> > > http://gerrit.ovirt.org/11143
> > 
> > 
> > --
> > 
> > Michael Pasternak
> > RedHat, ENG-Virtualization R&D
> > _______________________________________________
> > 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 Jan 21 08:45:02 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 21 Jan 2013 10:45:02 +0200
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <931532731.7675833.1358756922734.JavaMail.root@redhat.com>
References: <931532731.7675833.1358756922734.JavaMail.root@redhat.com>
Message-ID: <50FD000E.6050900@redhat.com>

On 01/21/2013 10:28 AM, Omer Frenkel wrote:
> 
> 
> ----- Original Message -----
>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>> To: "Michael Pasternak" <mpastern at redhat.com>
>> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
>> Sent: Monday, January 21, 2013 8:27:36 AM
>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>
>>
>>
>> ----- Original Message -----
>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>> To: "Juan Hernandez" <jhernand at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Sunday, January 20, 2013 3:24:58 PM
>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>
>>> On 01/17/2013 01:04 PM, Juan Hernandez wrote:
>>>> Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT
>>>> in
>>>> the master branch:
>>>
>>> +1
>> I agree, and this is not the only place where should start marking
> 
> and cluster compatibility version..

all above is true, but Juan meant preparing MVN infra for the next
development iteration, while you're talking about engine internals,
maybe we should file BZs on that (as next version tasks) or should we
define new process of preparing for the next version that will include both?

> 
>> "3.3.0" - what about upgrade scripts?
>>
>>>
>>>>
>>>> http://gerrit.ovirt.org/11143
>>>
>>>
>>> --
>>>
>>> Michael Pasternak
>>> RedHat, ENG-Virtualization R&D
>>> _______________________________________________
>>> 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 jhernand at redhat.com  Mon Jan 21 10:25:03 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 21 Jan 2013 11:25:03 +0100
Subject: [Engine-devel] Error while trying to read parameter HTTP_PORT
 from user
In-Reply-To: <C5A0092C63E939488005F15F736A8112114522@SHSMSX101.ccr.corp.intel.com>
References: <C5A0092C63E939488005F15F736A8112114522@SHSMSX101.ccr.corp.intel.com>
Message-ID: <50FD177F.6070409@redhat.com>

On 01/17/2013 02:52 AM, Chen, Wei D wrote:
> Hi,
>
>    There is a problem in setup ovirt-engine,?Error while trying to read
> parameter HTTP_PORT from user.?
>
> The env is setup with ovirt-engine 3.2.0 from
> http://www.ovirt.org/Building_oVirt_engine , at last i try to
>
> input ?make? to configure ovirt engine.
>
> Selinux is ?SELINUX=enforcing? in /etc/selinux/config
>
> Iptalbles is running, and the below ports in open.
>
> iptables -I INPUT 1 -p tcp --dport 443  -j ACCEPT
>
> iptables -I INPUT 1 -p tcp --dport 80   -j ACCEPT
>
> iptables -I INPUT 1 -p tcp --dport 4457 -j ACCEPT
>
> iptables -I INPUT 1 -p tcp --dport 8443 -j ACCEPT
>
> iptables -I INPUT 1 -p tcp --dport 8083 -j ACCEPT
>
> iptables -I INPUT 1 -p tcp --dport 1090 -j ACCEPT
>
> /usr/share/jboss-as/bin/standalone.sh can run too.
>
> The below is printing out information when I input engine-setup:
>
> ###################################
>
> #engine-setup
>
> Welcome to oVirt Engine setup utility
>
> In order to proceed the installer must stop the ovirt-engine service
>
> Would you like to stop the ovirt-engine service? (yes|no): yes
>
> oVirt Engine uses httpd to proxy requests to the application server.
>
> It looks like the httpd installed locally is being actively used.
>
> The installer can override current configuration .
>
> Alternatively you can use JBoss directly (on ports higher than 1024)
>
> Do you wish to override current httpd configuration and restart the
> service? ['yes'| 'no']  [yes] : yse
>
> Error: response is not part of the following accepted answers: yes, no
>
> oVirt Engine uses httpd to proxy requests to the application server.
>
> It looks like the httpd installed locally is being actively used.
>
> The installer can override current configuration .
>
> Alternatively you can use JBoss directly (on ports higher than 1024)
>
> Do you wish to override current httpd configuration and restart the
> service? ['yes'| 'no']  [yes] : yes
>
> HTTP Port  [80] : 80
>
> Error while trying to read parameter HTTP_PORT from user.
>
> Please check log file
> /var/log/ovirt-engine/engine-setup_2013_01_17_04_18_17.log for more
> information
>
> Below is /var/log/ovirt-engine/engine-setup_2013_01_17_04_18_17.log
>
> ###########/var/log/ovirt-engine/engine-setup_2013_01_17_04_18_17.log
> ##########
>
> 2013-01-17 04:18:17::DEBUG::common_utils::1255::root:: checking if
> firewalld service is available
>
> 2013-01-17 04:18:17::DEBUG::common_utils::430::root:: Executing command
> --> '/bin/systemctl show firewalld'
>
> 2013-01-17 04:18:17::DEBUG::common_utils::468::root:: output =
>
> 2013-01-17 04:18:17::DEBUG::common_utils::469::root:: stderr = Failed to
> issue method call: Unit name firewalld is not valid.
>
> 2013-01-17 04:18:17::DEBUG::common_utils::470::root:: retcode = 1
>
> 2013-01-17 04:18:17::DEBUG::common_utils::1255::root:: checking if
> iptables service is available
>
> 2013-01-17 04:18:17::DEBUG::common_utils::430::root:: Executing command
> --> '/bin/systemctl show iptables'
>
> 2013-01-17 04:18:17::DEBUG::common_utils::468::root:: output =
>
> 2013-01-17 04:18:17::DEBUG::common_utils::469::root:: stderr = Failed to
> issue method call: Unit name iptables is not valid.
>
> 2013-01-17 04:18:17::DEBUG::common_utils::470::root:: retcode = 1
>
> 2013-01-17 04:18:17::DEBUG::common_utils::430::root:: Executing command
> --> '/sbin/ip addr'
>
> 2013-01-17 04:18:17::DEBUG::common_utils::468::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: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
>
>      link/ether 2c:41:38:a8:41:13 brd ff:ff:ff:ff:ff:ff
>
>      inet 10.239.131.232/24 brd 10.239.131.255 scope global em1
>
>      inet6 fe80::2e41:38ff:fea8:4113/64 scope link
>
>         valid_lft forever preferred_lft forever
>
> 2013-01-17 04:18:17::DEBUG::common_utils::469::root:: stderr =
>
> 2013-01-17 04:18:17::DEBUG::common_utils::470::root:: retcode = 0
>
> 2013-01-17 04:18:17::DEBUG::common_utils::589::root:: Found IP Address:
> 10.239.131.232
>
> 2013-01-17 04:18:17::DEBUG::engine-setup::2139::root:: initiating
> command line option parser
>
> 2013-01-17 04:18:17::DEBUG::engine-setup::2106::root:: checking total memory
>
> 2013-01-17 04:18:17::DEBUG::common_utils::430::root:: Executing command
> --> '/usr/bin/free -m'
>
> 2013-01-17 04:18:17::DEBUG::common_utils::468::root:: output
> =              total       used       free     shared    buffers     cached
>
> Mem:          7945        627       7317          0         15        406
>
> -/+ buffers/cache:        205       7739
>
> Swap:         9983          0       9983
>
> 2013-01-17 04:18:17::DEBUG::common_utils::469::root:: stderr =
>
> 2013-01-17 04:18:17::DEBUG::common_utils::470::root:: retcode = 0
>
> 2013-01-17 04:18:17::DEBUG::engine-setup::2118::root:: Found a match,
> amount of memory: 7945
>
> 2013-01-17 04:18:17::DEBUG::engine-setup::2008::root:: Entered
> main(configFile='None')
>
> 2013-01-17 04:18:17::DEBUG::engine-setup::1802::root:: stopping
> ovirt-engine service
>
> 2013-01-17 04:18:17::DEBUG::common_utils::967::root:: asking user: Would
> you like to stop the ovirt-engine service? (yes|no):
>
> 2013-01-17 04:18:19::DEBUG::common_utils::971::root:: user answered: yes
>
> 2013-01-17 04:18:19::DEBUG::common_utils::1211::root:: stopping ovirt-engine
>
> 2013-01-17 04:18:19::DEBUG::common_utils::1248::root:: executing action
> ovirt-engine on service stop
>
> 2013-01-17 04:18:19::DEBUG::common_utils::430::root:: Executing command
> --> '/sbin/service ovirt-engine stop'
>
> 2013-01-17 04:18:19::DEBUG::common_utils::468::root:: output =
>
> 2013-01-17 04:18:19::DEBUG::common_utils::469::root:: stderr =
>
> 2013-01-17 04:18:19::DEBUG::common_utils::470::root:: retcode = 0
>
> 2013-01-17 04:18:19::DEBUG::engine-setup::1532::root:: going over group
> PORTS
>
> 2013-01-17 04:18:19::DEBUG::common_utils::1289::root:: retrieving
> version for ipa-server rpm
>
> 2013-01-17 04:18:19::DEBUG::common_utils::1310::root:: getRpmVersion failed
>
> Traceback (most recent call last):
>
>    File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 1307, in installed
>
>      getRpmVersion(rpmName=rpm)
>
>    File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 1301, in getRpmVersion
>
>      raise Exception(output_messages.ERR_READ_RPM_VER % rpmName)
>
> Exception: Error reading version number for package ipa-server
>
> 2013-01-17 04:18:19::DEBUG::common_utils::1289::root:: retrieving
> version for freeipa-server rpm
>
> 2013-01-17 04:18:19::DEBUG::common_utils::1310::root:: getRpmVersion failed
>
> Traceback (most recent call last):
>
>    File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 1307, in installed
>
>      getRpmVersion(rpmName=rpm)
>
>    File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 1301, in getRpmVersion
>
>      raise Exception(output_messages.ERR_READ_RPM_VER % rpmName)
>
> Exception: Error reading version number for package freeipa-server
>
> 2013-01-17 04:18:19::INFO::engine-setup::1541::root:: Comparing
> pre-conditions; condition: 'True', and match: 'True'
>
> 2013-01-17 04:18:20::INFO::engine_validators::199::root::
> validateOverrideHttpdConfAndChangePortsAccordingly yse as part of
> ['yes', 'no']
>
> 2013-01-17 04:18:20::INFO::engine_validators::182::root:: Validating yse
> as part of ['yes', 'no']
>
> 2013-01-17 04:18:22::INFO::engine_validators::199::root::
> validateOverrideHttpdConfAndChangePortsAccordingly yes as part of
> ['yes', 'no']
>
> 2013-01-17 04:18:22::INFO::engine_validators::182::root:: Validating yes
> as part of ['yes', 'no']
>
> 2013-01-17 04:18:22::DEBUG::engine_validators::207::root:: stopping
> httpd service
>
> 2013-01-17 04:18:22::DEBUG::common_utils::1211::root:: stopping httpd
>
> 2013-01-17 04:18:22::DEBUG::common_utils::1248::root:: executing action
> httpd on service stop
>
> 2013-01-17 04:18:22::DEBUG::common_utils::430::root:: Executing command
> --> '/sbin/service httpd stop'
>
> 2013-01-17 04:18:22::DEBUG::common_utils::468::root:: output =
>
> 2013-01-17 04:18:22::DEBUG::common_utils::469::root:: stderr =
>
> 2013-01-17 04:18:22::DEBUG::common_utils::470::root:: retcode = 0
>
> 2013-01-17 04:18:24::DEBUG::engine_validators::62::root:: Validating 80
> as a valid TCP Port
>
> 2013-01-17 04:18:24::DEBUG::common_utils::394::root:: Checking if TCP
> port 80 is open by any process
>
> 2013-01-17 04:18:24::DEBUG::common_utils::430::root:: Executing command
> --> '/usr/sbin/lsof -i -n -P'
>
> 2013-01-17 04:18:24::ERROR::engine-setup::601::root:: Traceback (most
> recent call last):
>
>    File "/usr/local/bin/engine-setup", line 574, in _getInputFromUser
>
>      if param.getKey("VALIDATION_FUNC")(userInput,
> param.getKey("OPTION_LIST")):
>
>    File "/usr/local/share/ovirt-engine/scripts/engine_validators.py",
> line 81, in validatePort
>
>      (portOpen, process, pid) = utils.isTcpPortOpen(param)
>
>    File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 399, in isTcpPortOpen
>
>      output, rc = execCmd(cmdList=cmd, failOnError=True,
> msg=output_messages.ERR_EXP_LSOF)
>
>    File "/usr/local/share/ovirt-engine/scripts/common_utils.py", line
> 454, in execCmd
>
>      env=env,
>
>    File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
>
>      errread, errwrite)
>
>    File "/usr/lib64/python2.7/subprocess.py", line 1249, in _execute_child
>
>      raise child_exception
>
> OSError: [Errno 2] No such file or directory
>
> 2013-01-17 04:18:25::ERROR::engine-setup::1577::root:: Traceback (most
> recent call last):
>
>    File "/usr/local/bin/engine-setup", line 1546, in
> _handleInteractiveParams
>
>      input_param(param)
>
>    File "/usr/local/bin/engine-setup", line 628, in input_param
>
>      _getInputFromUser(param)
>
>    File "/usr/local/bin/engine-setup", line 602, in _getInputFromUser
>
>      raise Exception(output_messages.ERR_EXP_READ_INPUT_PARAM %
> (param.getKey("CONF_NAME")))
>
> Exception: Error while trying to read parameter HTTP_PORT from user.
>
> 2013-01-17 04:18:25::DEBUG::engine-setup::1875::root:: *** The following
> params were used as user input:
>
> 2013-01-17 04:18:25::DEBUG::engine-setup::1880::root::
> override-httpd-config: yes
>
> 2013-01-17 04:18:25::ERROR::engine-setup::2295::root:: Traceback (most
> recent call last):
>
>    File "/usr/local/bin/engine-setup", line 2290, in <module>
>
>      main(confFile)
>
>    File "/usr/local/bin/engine-setup", line 2028, in main
>
>      _handleParams(configFile)
>
>    File "/usr/local/bin/engine-setup", line 1589, in _handleParams
>
>     _handleInteractiveParams()
>
>    File "/usr/local/bin/engine-setup", line 1546, in
> _handleInteractiveParams
>
>      input_param(param)
>
>    File "/usr/local/bin/engine-setup", line 628, in input_param
>
>      _getInputFromUser(param)
>
>    File "/usr/local/bin/engine-setup", line 602, in _getInputFromUser
>
>      raise Exception(output_messages.ERR_EXP_READ_INPUT_PARAM %
> (param.getKey("CONF_NAME")))
>
> Exception: Error while trying to read parameter HTTP_PORT from user.
>
> Best Regards,
>
> Dave Chen

Apparently the engine-setup tool is failing because it is not finding 
the "lsof" command. Do you have that package installed? If not install 
it with "yum install lsof", then try again.

-- 
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 sanjal at redhat.com  Mon Jan 21 12:08:14 2013
From: sanjal at redhat.com (Shireesh Anjal)
Date: Mon, 21 Jan 2013 17:38:14 +0530
Subject: [Engine-devel] RFE: Actions on tasks (jobs)
Message-ID: <50FD2FAE.9020006@redhat.com>

Hi,

We plan to introduce support for gluster tasks in oVirt, using the 
current Jobs/steps framework. Which means, any gluster async task 
started on a cluster will be shown as a Job in the "Tasks" tab. While 
this helps in listing and monitoring the status of all gluster tasks, we 
have a requirement to support a set of actions on such tasks. One should 
be able to select a task, and then, if supported for that task, perform 
one or more of the following actions on it:

- pause
- resume
- abort
- commit

I think this can probably be achieved by introducing a generic mechanism 
for performing actions on task, allowing each type of task to define 
what actions are allowed on it in it's current state.

Requesting opinions/suggestions on possible ways to achieve this 
requirement.

Thanks,
Shireesh


From yzaslavs at redhat.com  Mon Jan 21 12:17:19 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 21 Jan 2013 07:17:19 -0500 (EST)
Subject: [Engine-devel] RFE: Actions on tasks (jobs)
In-Reply-To: <50FD2FAE.9020006@redhat.com>
Message-ID: <1521459639.12650229.1358770639297.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Shireesh Anjal" <sanjal at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, January 21, 2013 2:08:14 PM
> Subject: [Engine-devel] RFE: Actions on tasks (jobs)
> 
> Hi,
> 
> We plan to introduce support for gluster tasks in oVirt, using the
> current Jobs/steps framework. Which means, any gluster async task
> started on a cluster will be shown as a Job in the "Tasks" tab. While
> this helps in listing and monitoring the status of all gluster tasks,
> we
> have a requirement to support a set of actions on such tasks. One
> should
> be able to select a task, and then, if supported for that task,
> perform
> one or more of the following actions on it:
> 
> - pause
> - resume
> - abort
> - commit
> 
> I think this can probably be achieved by introducing a generic
> mechanism
> for performing actions on task, allowing each type of task to define
> what actions are allowed on it in it's current state.
> 
> Requesting opinions/suggestions on possible ways to achieve this
> requirement.

Several points - 
1. By performing actions - you probably mean the entry point to engine will be BllCommand? StopTaskCommand for example?
If so, we need to think about the permission of the command. who can stop a for example? What is its role?
2. You mentioned task type - does this mean extending the AsyncTaskType enum? Are you going to have your own Tasks enum?
 
> Thanks,
> Shireesh
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ecohen at redhat.com  Mon Jan 21 14:16:24 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Mon, 21 Jan 2013 09:16:24 -0500 (EST)
Subject: [Engine-devel] Unable to add second Data domain to my Data
 Center.
In-Reply-To: <3704436.14KyoNIg2M@awels>
Message-ID: <902309745.7860600.1358777784946.JavaMail.root@redhat.com>

hi, ping on that issue - any chance that someone can help with that?

some more info:

Host is fedora 17, with the following installed:
vdsm-4.10.0-10.fc17.x86_64
sanlock-2.4-3.fc17.x86_64
libvirt-0.9.11.8-2.fc17.x86_64

engine is latest oVirt-engine upstream.

when starting vdsm, getting the following error:

2013-01-18 07:56:18-0500 20 [1184]: sanlock daemon started 2.4 aio 1 10 renew 20 80 host 8828a575-4ace-4da0-b78e-53b26559a507.host1.loca time 1358513778
2013-01-18 07:56:18-0500 20 [1184]: wdmd connect failed for watchdog handling

following steps in [1] solve the above error, afterwards first Data NFS storage domain (V3) can be added successfully to the Data-Center. 
Attempting to add a second Data NFS storage-domain (V3) to the same data-center fails - see vdsm log [2] and san-lock log [3].
Attempting to add an ISO NFS storage-domain (V1) succeeds.

any idea?

thanks in advance.


[1] http://comments.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/1395

[2] vdsm log:

> Thread-2801::ERROR::2013-01-17
> 16:55:22,340::task::853::TaskManager.Task::
> (_setError) Task=`fe1ac39e-7681-4043-b2b7-b6e2611e1c10`::Unexpected
> error
> Traceback (most recent call last):
>   File "/usr/share/vdsm/storage/task.py", line 861, in _run
>     return fn(*args, **kargs)
>   File "/usr/share/vdsm/logUtils.py", line 38, in wrapper
>     res = f(*args, **kwargs)
>   File "/usr/share/vdsm/storage/hsm.py", line 960, in
>   attachStorageDomain
>     pool.attachSD(sdUUID)
>   File "/usr/share/vdsm/storage/securable.py", line 63, in wrapper
>     return f(self, *args, **kwargs)
>   File "/usr/share/vdsm/storage/sp.py", line 919, in attachSD
>     dom.acquireClusterLock(self.id)
>   File "/usr/share/vdsm/storage/sd.py", line 429, in
>   acquireClusterLock
>     self._clusterLock.acquire(hostID)
>   File "/usr/share/vdsm/storage/safelease.py", line 205, in acquire
>     "Cannot acquire cluster lock", str(e))
> AcquireLockFailure: Cannot obtain lock:
> "id=807c2e91-52c3-4779-9ebb-771b96bf5a4c, rc=28, out=Cannot acquire
> cluster
> lock, err=(28, 'Sanlock resource not acquired', 'No space left on
> device')"
> Thread-2801::DEBUG::2013-01-17
> 16:55:22,341::task::872::TaskManager.Task::
> (_run) Task=`fe1ac39e-7681-4043-b2b7-b6e2611e1c10`::Task._run:
> fe1ac39e-7681-4043-b2b7-b6e2611e1c10
> ('807c2e91-52c3-4779-9ebb-771b96bf5a4c',
> '58
> 49b030-626e-47cb-ad90-3ce782d831b3') {} failed - stopping task

[3] sanlock log:

> 2013-01-17 16:55:22-0500 4161 [3187]: r12 cmd_acquire 3,14,3830
> invalid
> lockspace found -1 failed 0 name 807c2e91-52c3-4779-9ebb-771b96bf5a4c


----- Original Message -----
> From: "Alexander Wels" <awels at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, January 17, 2013 5:00:13 PM
> Subject: [Engine-devel] Unable to add second Data domain to my Data Center.
> 
> Hello,
> 
> I am trying to setup a host for a seperate oVirt engine/node
> environment
> (version 3.1). I managed to get my host up and running and active in
> my Data
> Center. I managed to create 4 storage domains on that host. 2 Data
> domains and
> 1 ISO domain and one Export domain.
> 
> I am successful in attaching the ISO/Export/smaller Data domain to my
> Data
> Center. The web admin interface is indicating they are active. I
> activated my
> smaller test Data domain because I was having some issues earlier
> getting my
> storage attached. I worked through those issues and now I want to
> attach my
> actual Data storage so I can detach the test one. Whenever I attempt
> to attach
> the storage I get an error message and when I look in the vdsm log I
> see the
> following:
> 
> Thread-2801::ERROR::2013-01-17
> 16:55:22,340::task::853::TaskManager.Task::
> (_setError) Task=`fe1ac39e-7681-4043-b2b7-b6e2611e1c10`::Unexpected
> error
> Traceback (most recent call last):
>   File "/usr/share/vdsm/storage/task.py", line 861, in _run
>     return fn(*args, **kargs)
>   File "/usr/share/vdsm/logUtils.py", line 38, in wrapper
>     res = f(*args, **kwargs)
>   File "/usr/share/vdsm/storage/hsm.py", line 960, in
>   attachStorageDomain
>     pool.attachSD(sdUUID)
>   File "/usr/share/vdsm/storage/securable.py", line 63, in wrapper
>     return f(self, *args, **kwargs)
>   File "/usr/share/vdsm/storage/sp.py", line 919, in attachSD
>     dom.acquireClusterLock(self.id)
>   File "/usr/share/vdsm/storage/sd.py", line 429, in
>   acquireClusterLock
>     self._clusterLock.acquire(hostID)
>   File "/usr/share/vdsm/storage/safelease.py", line 205, in acquire
>     "Cannot acquire cluster lock", str(e))
> AcquireLockFailure: Cannot obtain lock:
> "id=807c2e91-52c3-4779-9ebb-771b96bf5a4c, rc=28, out=Cannot acquire
> cluster
> lock, err=(28, 'Sanlock resource not acquired', 'No space left on
> device')"
> Thread-2801::DEBUG::2013-01-17
> 16:55:22,341::task::872::TaskManager.Task::
> (_run) Task=`fe1ac39e-7681-4043-b2b7-b6e2611e1c10`::Task._run:
> fe1ac39e-7681-4043-b2b7-b6e2611e1c10
> ('807c2e91-52c3-4779-9ebb-771b96bf5a4c',
> '58
> 49b030-626e-47cb-ad90-3ce782d831b3') {} failed - stopping task
> 
> Which seems to indicate the disk is full. Which is not the case as
> this is a
> brand new machine with a fresh install and a 1T drive in it. The
> error does
> point to sanlock so when I look at the sanlock log I see this:
> 
> 2013-01-17 16:55:22-0500 4161 [3187]: r12 cmd_acquire 3,14,3830
> invalid
> lockspace found -1 failed 0 name 807c2e91-52c3-4779-9ebb-771b96bf5a4c
> 
> I googled around for that particular error message and I couldn't
> find anyone
> with any suggestions as to the source of that problem.
> 
> Could someone please give me a pointer of where to look or help me
> debug the
> issue.
> 
> Thanks,
> Alexander
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From masayag at redhat.com  Mon Jan 21 15:19:16 2013
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 21 Jan 2013 17:19:16 +0200
Subject: [Engine-devel] RFE: Actions on tasks (jobs)
In-Reply-To: <50FD2FAE.9020006@redhat.com>
References: <50FD2FAE.9020006@redhat.com>
Message-ID: <50FD5C74.1020301@redhat.com>

On 01/21/2013 02:08 PM, Shireesh Anjal wrote:
> Hi,
> 
> We plan to introduce support for gluster tasks in oVirt, using the
> current Jobs/steps framework. Which means, any gluster async task
> started on a cluster will be shown as a Job in the "Tasks" tab. While
> this helps in listing and monitoring the status of all gluster tasks, we
> have a requirement to support a set of actions on such tasks. One should
> be able to select a task, and then, if supported for that task, perform
> one or more of the following actions on it:
> 
> - pause
> - resume
> - abort
> - commit

Could you explain what is the meaning of 'commit' in this context?
In addition, is there a need for a 'restart' action ?

Generally, a command (user-action / internal action) is mapped to a Job
when it's monitored.

The job may contain several steps where each step might represent an
async-task (i.e task running on a node, vdsm task).

There are two levels of control: controlling a specific vdsm task/step
or controlling the entire job.

I think that the granularity of the action should be on Job level, since
a step's result (assuming cancelled step is considered failed) will
determine the job's status as failed/aborted - therefore the rest of
running steps should also be aborted.

If needed, supporting 'restart' operation could also be relatively
easily support for job level (requires saving the action's parameters
for a re-run).

The Jobs cleanup manager should take care of cleaning cancelled jobs and
to keep paused jobs.

Does the suggested actions supported by the AsyncTaskManager and by VDSM ?

> 
> I think this can probably be achieved by introducing a generic mechanism
> for performing actions on task, allowing each type of task to define
> what actions are allowed on it in it's current state.
> 
> Requesting opinions/suggestions on possible ways to achieve this
> requirement.
> 
> Thanks,
> Shireesh
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From tjelinek at redhat.com  Tue Jan 22 13:09:51 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Tue, 22 Jan 2013 08:09:51 -0500 (EST)
Subject: [Engine-devel]  Instance Types Feature
In-Reply-To: <886250486.4799357.1358859572927.JavaMail.root@redhat.com>
Message-ID: <1556079335.4805444.1358860191899.JavaMail.root@redhat.com>

Hi All,

this is the proposed new feature called instance types:
http://www.ovirt.org/Features/Instance_Types

Long story short - it should basically split the VM template into:
- "hardware profile" called instance types
- "software profile" called image

This should enable to do something like: Create a new "small" VM and attach a disk with "RHEL + Postgres" installed.

Any comments are more than welcome!

Tomas


From sanjal at redhat.com  Tue Jan 22 14:18:49 2013
From: sanjal at redhat.com (Shireesh Anjal)
Date: Tue, 22 Jan 2013 19:48:49 +0530
Subject: [Engine-devel] RFE: Actions on tasks (jobs)
In-Reply-To: <1521459639.12650229.1358770639297.JavaMail.root@redhat.com>
References: <1521459639.12650229.1358770639297.JavaMail.root@redhat.com>
Message-ID: <50FE9FC9.4000501@redhat.com>

On Monday 21 January 2013 05:47 PM, Yair Zaslavsky wrote:
>
> ----- Original Message -----
>> From: "Shireesh Anjal" <sanjal at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Monday, January 21, 2013 2:08:14 PM
>> Subject: [Engine-devel] RFE: Actions on tasks (jobs)
>>
>> Hi,
>>
>> We plan to introduce support for gluster tasks in oVirt, using the
>> current Jobs/steps framework. Which means, any gluster async task
>> started on a cluster will be shown as a Job in the "Tasks" tab. While
>> this helps in listing and monitoring the status of all gluster tasks,
>> we
>> have a requirement to support a set of actions on such tasks. One
>> should
>> be able to select a task, and then, if supported for that task,
>> perform
>> one or more of the following actions on it:
>>
>> - pause
>> - resume
>> - abort
>> - commit
>>
>> I think this can probably be achieved by introducing a generic
>> mechanism
>> for performing actions on task, allowing each type of task to define
>> what actions are allowed on it in it's current state.
>>
>> Requesting opinions/suggestions on possible ways to achieve this
>> requirement.
> Several points -
> 1. By performing actions - you probably mean the entry point to engine will be BllCommand? StopTaskCommand for example?
> If so, we need to think about the permission of the command. who can stop a for example? What is its role?

I see that Job extends BusinessEntity<Guid>, and hence should be 
possible to assign permissions on it, just like any other entity? Though 
I think this doesn't fit directly in the current UI, as jobs is not a 
main tab. In case of gluster, I would add this permission to the 
'GlusterAdmin' role.

> 2. You mentioned task type - does this mean extending the AsyncTaskType enum? Are you going to have your own Tasks enum?

I'm not sure about AsyncTaskType, as I believe it is related to the vdsm 
async tasks and AsyncTaskManager, and I don't think we'll be going there.

In our case, the command being executed in the job itself could be 
synonymous to the task type. What I mean by task type specific actions 
is, not all actions are applicable on all types of tasks. e.g. "commit" 
is applicable only to a "replace brick" task, and not to "rebalance 
volume" task, whereas "abort" is applicable to both. So the 
corresponding command should dictate what action can be performed on the 
task.

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



From sanjal at redhat.com  Tue Jan 22 14:28:40 2013
From: sanjal at redhat.com (Shireesh Anjal)
Date: Tue, 22 Jan 2013 19:58:40 +0530
Subject: [Engine-devel] RFE: Actions on tasks (jobs)
In-Reply-To: <50FD5C74.1020301@redhat.com>
References: <50FD2FAE.9020006@redhat.com> <50FD5C74.1020301@redhat.com>
Message-ID: <50FEA218.5060608@redhat.com>

On Monday 21 January 2013 08:49 PM, Moti Asayag wrote:
> On 01/21/2013 02:08 PM, Shireesh Anjal wrote:
>> Hi,
>>
>> We plan to introduce support for gluster tasks in oVirt, using the
>> current Jobs/steps framework. Which means, any gluster async task
>> started on a cluster will be shown as a Job in the "Tasks" tab. While
>> this helps in listing and monitoring the status of all gluster tasks, we
>> have a requirement to support a set of actions on such tasks. One should
>> be able to select a task, and then, if supported for that task, perform
>> one or more of the following actions on it:
>>
>> - pause
>> - resume
>> - abort
>> - commit
> Could you explain what is the meaning of 'commit' in this context?

The "replace brick" task in gluster migrates all data from an existing 
brick to the new brick which is replacing it. After all the data is 
migrated, user needs to perform a "commit" for the new brick to come 
into effect.
http://gluster.org/community/documentation/index.php/Gluster_3.1:_Migrating_Volumes

> In addition, is there a need for a 'restart' action ?

At present, we don't need such an action as far as gluster is concerned.

> Generally, a command (user-action / internal action) is mapped to a Job
> when it's monitored.
>
> The job may contain several steps where each step might represent an
> async-task (i.e task running on a node, vdsm task).
>
> There are two levels of control: controlling a specific vdsm task/step
> or controlling the entire job.
>
> I think that the granularity of the action should be on Job level, since
> a step's result (assuming cancelled step is considered failed) will
> determine the job's status as failed/aborted - therefore the rest of
> running steps should also be aborted.

+1

> If needed, supporting 'restart' operation could also be relatively
> easily support for job level (requires saving the action's parameters
> for a re-run).
>
> The Jobs cleanup manager should take care of cleaning cancelled jobs and
> to keep paused jobs.
>
> Does the suggested actions supported by the AsyncTaskManager and by VDSM ?

No. These are not vdsm tasks. They'll be managed completely by 
glusterfs. We plan to introduce gluster specific verbs in vdsm for 
starting/managing/monitoring these tasks. http://gerrit.ovirt.org/10200

And then have a background periodic job in engine to fetch and update 
the status of the same in the Job repository.

>
>> I think this can probably be achieved by introducing a generic mechanism
>> for performing actions on task, allowing each type of task to define
>> what actions are allowed on it in it's current state.
>>
>> Requesting opinions/suggestions on possible ways to achieve this
>> requirement.
>>
>> Thanks,
>> Shireesh
>> _______________________________________________
>> 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/20130122/a8d773f0/attachment.html>

From iheim at redhat.com  Tue Jan 22 14:42:28 2013
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 22 Jan 2013 06:42:28 -0800
Subject: [Engine-devel] RFE: Actions on tasks (jobs)
In-Reply-To: <50FE9FC9.4000501@redhat.com>
References: <1521459639.12650229.1358770639297.JavaMail.root@redhat.com>
	<50FE9FC9.4000501@redhat.com>
Message-ID: <50FEA554.7000701@redhat.com>

On 22/01/2013 06:18, Shireesh Anjal wrote:
> On Monday 21 January 2013 05:47 PM, Yair Zaslavsky wrote:
>>
>> ----- Original Message -----
>>> From: "Shireesh Anjal" <sanjal at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Sent: Monday, January 21, 2013 2:08:14 PM
>>> Subject: [Engine-devel] RFE: Actions on tasks (jobs)
>>>
>>> Hi,
>>>
>>> We plan to introduce support for gluster tasks in oVirt, using the
>>> current Jobs/steps framework. Which means, any gluster async task
>>> started on a cluster will be shown as a Job in the "Tasks" tab. While
>>> this helps in listing and monitoring the status of all gluster tasks,
>>> we
>>> have a requirement to support a set of actions on such tasks. One
>>> should
>>> be able to select a task, and then, if supported for that task,
>>> perform
>>> one or more of the following actions on it:
>>>
>>> - pause
>>> - resume
>>> - abort
>>> - commit
>>>
>>> I think this can probably be achieved by introducing a generic
>>> mechanism
>>> for performing actions on task, allowing each type of task to define
>>> what actions are allowed on it in it's current state.
>>>
>>> Requesting opinions/suggestions on possible ways to achieve this
>>> requirement.
>> Several points -
>> 1. By performing actions - you probably mean the entry point to engine
>> will be BllCommand? StopTaskCommand for example?
>> If so, we need to think about the permission of the command. who can
>> stop a for example? What is its role?
>
> I see that Job extends BusinessEntity<Guid>, and hence should be
> possible to assign permissions on it, just like any other entity? Though
> I think this doesn't fit directly in the current UI, as jobs is not a
> main tab. In case of gluster, I would add this permission to the
> 'GlusterAdmin' role.

jobs are transient, so permissions are probably implied/created as part 
of job creation.
the tricky part is if you have two admins, one for each cluster, how do 
you check for permissions on the job for the relevant actiongroup.

based on DC? cluster? volume? on all of the entities associated with the 
job, on any of the entities related to the job, for each job via a 
single entity declared as the one relevant for permission checks, etc.

>
>> 2. You mentioned task type - does this mean extending the
>> AsyncTaskType enum? Are you going to have your own Tasks enum?
>
> I'm not sure about AsyncTaskType, as I believe it is related to the vdsm
> async tasks and AsyncTaskManager, and I don't think we'll be going there.
>
> In our case, the command being executed in the job itself could be
> synonymous to the task type. What I mean by task type specific actions
> is, not all actions are applicable on all types of tasks. e.g. "commit"
> is applicable only to a "replace brick" task, and not to "rebalance
> volume" task, whereas "abort" is applicable to both. So the
> corresponding command should dictate what action can be performed on the
> task.


From sanjal at redhat.com  Tue Jan 22 14:47:05 2013
From: sanjal at redhat.com (Shireesh Anjal)
Date: Tue, 22 Jan 2013 20:17:05 +0530
Subject: [Engine-devel] RFE: Health Indication on UI
Message-ID: <50FEA669.2070004@redhat.com>

Hi,

Currently, oVirt is intelligent to understand the relationship 
hierarchies of various entities in the system, and even allows setting 
permissions based on this hierarchy. Can this information further be 
used to enhance the health monitoring of various entities in the system? 
Let me take an example.

Consider this hierarchy (gluster):

System -> Cluster -> Volume -> Brick

If one or more bricks of a volume are down, which indicates a problem, 
following entities should be overlaid with a warning symbol (say, a 
yellow exclamation mark)
  - Volume to which the brick(s) belong(s)
  - it's parent cluster
  - System

This helps in highlighting what parts of the system are affected by 
failures/problems at the lowest level entities, and gives a better idea 
of the overall health of the entire environment to the administrator.

Thoughts?

Thanks,
Shireesh


From sanjal at redhat.com  Tue Jan 22 14:53:48 2013
From: sanjal at redhat.com (Shireesh Anjal)
Date: Tue, 22 Jan 2013 20:23:48 +0530
Subject: [Engine-devel] RFE: Actions on tasks (jobs)
In-Reply-To: <50FEA554.7000701@redhat.com>
References: <1521459639.12650229.1358770639297.JavaMail.root@redhat.com>
	<50FE9FC9.4000501@redhat.com> <50FEA554.7000701@redhat.com>
Message-ID: <50FEA7FC.2050004@redhat.com>

On Tuesday 22 January 2013 08:12 PM, Itamar Heim wrote:
> On 22/01/2013 06:18, Shireesh Anjal wrote:
>> On Monday 21 January 2013 05:47 PM, Yair Zaslavsky wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Shireesh Anjal" <sanjal at redhat.com>
>>>> To: engine-devel at ovirt.org
>>>> Sent: Monday, January 21, 2013 2:08:14 PM
>>>> Subject: [Engine-devel] RFE: Actions on tasks (jobs)
>>>>
>>>> Hi,
>>>>
>>>> We plan to introduce support for gluster tasks in oVirt, using the
>>>> current Jobs/steps framework. Which means, any gluster async task
>>>> started on a cluster will be shown as a Job in the "Tasks" tab. While
>>>> this helps in listing and monitoring the status of all gluster tasks,
>>>> we
>>>> have a requirement to support a set of actions on such tasks. One
>>>> should
>>>> be able to select a task, and then, if supported for that task,
>>>> perform
>>>> one or more of the following actions on it:
>>>>
>>>> - pause
>>>> - resume
>>>> - abort
>>>> - commit
>>>>
>>>> I think this can probably be achieved by introducing a generic
>>>> mechanism
>>>> for performing actions on task, allowing each type of task to define
>>>> what actions are allowed on it in it's current state.
>>>>
>>>> Requesting opinions/suggestions on possible ways to achieve this
>>>> requirement.
>>> Several points -
>>> 1. By performing actions - you probably mean the entry point to engine
>>> will be BllCommand? StopTaskCommand for example?
>>> If so, we need to think about the permission of the command. who can
>>> stop a for example? What is its role?
>>
>> I see that Job extends BusinessEntity<Guid>, and hence should be
>> possible to assign permissions on it, just like any other entity? Though
>> I think this doesn't fit directly in the current UI, as jobs is not a
>> main tab. In case of gluster, I would add this permission to the
>> 'GlusterAdmin' role.
>
> jobs are transient, so permissions are probably implied/created as 
> part of job creation.
> the tricky part is if you have two admins, one for each cluster, how 
> do you check for permissions on the job for the relevant actiongroup.
>
> based on DC? cluster? volume? on all of the entities associated with 
> the job, on any of the entities related to the job, for each job via a 
> single entity declared as the one relevant for permission checks, etc.

My vote is for "single entity declared as the one relevant for 
permission checks". I guess it would cover most scenarios - it 
definitely does for the gluster use case.

>
>>
>>> 2. You mentioned task type - does this mean extending the
>>> AsyncTaskType enum? Are you going to have your own Tasks enum?
>>
>> I'm not sure about AsyncTaskType, as I believe it is related to the vdsm
>> async tasks and AsyncTaskManager, and I don't think we'll be going 
>> there.
>>
>> In our case, the command being executed in the job itself could be
>> synonymous to the task type. What I mean by task type specific actions
>> is, not all actions are applicable on all types of tasks. e.g. "commit"
>> is applicable only to a "replace brick" task, and not to "rebalance
>> volume" task, whereas "abort" is applicable to both. So the
>> corresponding command should dictate what action can be performed on the
>> task.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From iheim at redhat.com  Tue Jan 22 14:53:54 2013
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 22 Jan 2013 06:53:54 -0800
Subject: [Engine-devel] RFE: Health Indication on UI
In-Reply-To: <50FEA669.2070004@redhat.com>
References: <50FEA669.2070004@redhat.com>
Message-ID: <50FEA802.9060102@redhat.com>

On 22/01/2013 06:47, Shireesh Anjal wrote:
> Hi,
>
> Currently, oVirt is intelligent to understand the relationship
> hierarchies of various entities in the system, and even allows setting
> permissions based on this hierarchy. Can this information further be
> used to enhance the health monitoring of various entities in the system?
> Let me take an example.
>
> Consider this hierarchy (gluster):
>
> System -> Cluster -> Volume -> Brick
>
> If one or more bricks of a volume are down, which indicates a problem,
> following entities should be overlaid with a warning symbol (say, a
> yellow exclamation mark)
>   - Volume to which the brick(s) belong(s)
>   - it's parent cluster
>   - System
>
> This helps in highlighting what parts of the system are affected by
> failures/problems at the lowest level entities, and gives a better idea
> of the overall health of the entire environment to the administrator.
>
> Thoughts?
>
> Thanks,
> Shireesh
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

interesting idea.
i wonder if the tree could represent this, and if it would require some 
refresh for status to update.

i wonder if the scheme should be based on status of entities, which 
requires specific logic, or on some sort of an alert like mechanism 
(since alerts are similar to "problems" which you describe above).
then you can leverage the fact events/alerts include all entities in the 
hierarchy, so very easy to highlight an entity as with an 
"issue/alert/problem" based on it having any open alerts/problems.


From shuming at linux.vnet.ibm.com  Tue Jan 22 15:36:57 2013
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Tue, 22 Jan 2013 23:36:57 +0800
Subject: [Engine-devel] [vdsm] RFC: New Storage API
In-Reply-To: <1039705302.6025163.1358199245420.JavaMail.root@redhat.com>
References: <1039705302.6025163.1358199245420.JavaMail.root@redhat.com>
Message-ID: <50FEB219.8020902@linux.vnet.ibm.com>

2013-1-15 5:34, Ayal Baron:
> image and volume are overused everywhere and it would be extremely confusing to have multiple meanings to the same terms in the same system (we have image today which means virtual disk and volume which means a part of a virtual disk).
> Personally I don't like the distinction between image and volume done in ec2/openstack/etc seeing as they're treated as different types of entities there while the only real difference is mutability (images are read-only, volumes are read-write).
> To move to the industry terminology we would need to first change all references we have today to image and volume in the system (I would say also in ovirt-engine side) to align with the new meaning.
> Despite my personal dislike of the terms, I definitely see the value in converging on the same terminology as the rest of the industry but to do so would be an arduous task which is out of scope of this discussion imo (patches welcome though ;)

Another distinction between Openstack and oVirt is how the 
Nova/ovirt-engine look upon storage systems. In Openstack, a stand alone 
storage service(Cinder) exports the raw storage block device to Nova. On 
the other hand, in oVirt, storage system is highly bounded with the 
cluster scheduling system which integrates storage sub-system, VM 
dispatching sub-system, ISO image sub systems. This combination make all 
of the sub-system integrated in a whole which is easy to deploy, but it 
make the sub-system more opaque and not harder to reuse and maintain. 
This new storage API proposal give us an opportunity to distinct these 
sub-systems as new components which export better, loose-coupling APIs 
to VDSM.


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


-- 
---
?? Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626  Tieline: 9051626 E-mail:shuming at cn.ibm.com  orshuming at linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC




From lhornyak at redhat.com  Tue Jan 22 18:16:32 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 22 Jan 2013 13:16:32 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <1556079335.4805444.1358860191899.JavaMail.root@redhat.com>
Message-ID: <944488104.4879593.1358878592341.JavaMail.root@redhat.com>

Hi Tomas,

I like the idea in general, but for me the instance types looks like a feature that is typical in public clouds, while in private clouds it looks more like a cool extra feature for special cases. Therefore in my opinion it would be great to keep the old template solution as well to keep it simple for most users. A template could be an instance type and an image together. Only the description overlap, and that could be solved.

Thanks,
Laszlo

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, January 22, 2013 3:09:51 PM
> Subject: [Engine-devel]  Instance Types Feature
> 
> Hi All,
> 
> this is the proposed new feature called instance types:
> http://www.ovirt.org/Features/Instance_Types
> 
> Long story short - it should basically split the VM template into:
> - "hardware profile" called instance types
> - "software profile" called image
> 
> This should enable to do something like: Create a new "small" VM and
> attach a disk with "RHEL + Postgres" installed.
> 
> Any comments are more than welcome!
> 
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From agl at us.ibm.com  Tue Jan 22 19:20:19 2013
From: agl at us.ibm.com (Adam Litke)
Date: Tue, 22 Jan 2013 13:20:19 -0600
Subject: [Engine-devel] [vdsm]   RFC: New Storage API
In-Reply-To: <50FEB219.8020902@linux.vnet.ibm.com>
References: <1039705302.6025163.1358199245420.JavaMail.root@redhat.com>
	<50FEB219.8020902@linux.vnet.ibm.com>
Message-ID: <20130122192018.GG26579@aglitke.ibm.com>

On Tue, Jan 22, 2013 at 11:36:57PM +0800, Shu Ming wrote:
> 2013-1-15 5:34, Ayal Baron:
> >image and volume are overused everywhere and it would be extremely confusing to have multiple meanings to the same terms in the same system (we have image today which means virtual disk and volume which means a part of a virtual disk).
> >Personally I don't like the distinction between image and volume done in ec2/openstack/etc seeing as they're treated as different types of entities there while the only real difference is mutability (images are read-only, volumes are read-write).
> >To move to the industry terminology we would need to first change all references we have today to image and volume in the system (I would say also in ovirt-engine side) to align with the new meaning.
> >Despite my personal dislike of the terms, I definitely see the value in converging on the same terminology as the rest of the industry but to do so would be an arduous task which is out of scope of this discussion imo (patches welcome though ;)
> 
> Another distinction between Openstack and oVirt is how the
> Nova/ovirt-engine look upon storage systems. In Openstack, a stand
> alone storage service(Cinder) exports the raw storage block device
> to Nova. On the other hand, in oVirt, storage system is highly
> bounded with the cluster scheduling system which integrates storage
> sub-system, VM dispatching sub-system, ISO image sub systems. This
> combination make all of the sub-system integrated in a whole which
> is easy to deploy, but it make the sub-system more opaque and not
> harder to reuse and maintain. This new storage API proposal give us
> an opportunity to distinct these sub-systems as new components which
> export better, loose-coupling APIs to VDSM.

A very good point and an important goal in my opinion.  I'd like to see
ovirt-engine become more of a GUI for configuring the storage component (like it
does for Gluster) rather than the centralized manager of storage.  The clustered
storage should be able to take care of itself as long as the peer hosts can
negotiate the SDM role.  

It would be cool if someone could actually dedicate a non-virtualization host
where its only job is to handle SDM operations.  Such a host could choose to
only deploy the standalone HSM service and not the complete vdsm package.

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From lhornyak at redhat.com  Tue Jan 22 22:28:42 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 22 Jan 2013 17:28:42 -0500 (EST)
Subject: [Engine-devel] maven build trick
In-Reply-To: <1710634114.4335433.1358773025941.JavaMail.root@redhat.com>
Message-ID: <737017503.4973033.1358893722669.JavaMail.root@redhat.com>

hi,

I recommend that you add this script to your build script:
rm -rf ~/.m2/repository/org/ovirt

This will remove the generated ovirt artifacts from your local maven repo.

Why is this needed:
If you remove some artifact from the build, that other artifacts are built on, these artifacts will still be able to resolve the missing dependency from the local repo (which is wrong). In this way, your build can still depend on an outdated artifact without breaking the build. This is why you do not notice that the build is broken, maven will just take it as a third party artifact.

Thx,
Laszlo


From alonbl at redhat.com  Tue Jan 22 22:31:31 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 22 Jan 2013 17:31:31 -0500 (EST)
Subject: [Engine-devel] maven build trick
In-Reply-To: <737017503.4973033.1358893722669.JavaMail.root@redhat.com>
Message-ID: <1435050874.3421170.1358893891637.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, January 23, 2013 12:28:42 AM
> Subject: [Engine-devel] maven build trick
> 
> hi,
> 
> I recommend that you add this script to your build script:
> rm -rf ~/.m2/repository/org/ovirt

This will remove artifacts of other projects as well.

For now, better doing:
rm -rf ~/.m2/repository/org/ovirt/engine

> 
> This will remove the generated ovirt artifacts from your local maven
> repo.
> 
> Why is this needed:
> If you remove some artifact from the build, that other artifacts are
> built on, these artifacts will still be able to resolve the missing
> dependency from the local repo (which is wrong). In this way, your
> build can still depend on an outdated artifact without breaking the
> build. This is why you do not notice that the build is broken, maven
> will just take it as a third party artifact.
> 
> Thx,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From smizrahi at redhat.com  Tue Jan 22 22:44:09 2013
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Tue, 22 Jan 2013 17:44:09 -0500 (EST)
Subject: [Engine-devel] [vdsm]   RFC: New Storage API
In-Reply-To: <20130122192018.GG26579@aglitke.ibm.com>
Message-ID: <814675014.5137565.1358894649475.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: "Shu Ming" <shuming at linux.vnet.ibm.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> Sent: Tuesday, January 22, 2013 2:20:19 PM
> Subject: Re: [vdsm] [Engine-devel]  RFC: New Storage API
> 
> On Tue, Jan 22, 2013 at 11:36:57PM +0800, Shu Ming wrote:
> > 2013-1-15 5:34, Ayal Baron:
> > >image and volume are overused everywhere and it would be extremely
> > >confusing to have multiple meanings to the same terms in the same
> > >system (we have image today which means virtual disk and volume
> > >which means a part of a virtual disk).
> > >Personally I don't like the distinction between image and volume
> > >done in ec2/openstack/etc seeing as they're treated as different
> > >types of entities there while the only real difference is
> > >mutability (images are read-only, volumes are read-write).
> > >To move to the industry terminology we would need to first change
> > >all references we have today to image and volume in the system (I
> > >would say also in ovirt-engine side) to align with the new
> > >meaning.
> > >Despite my personal dislike of the terms, I definitely see the
> > >value in converging on the same terminology as the rest of the
> > >industry but to do so would be an arduous task which is out of
> > >scope of this discussion imo (patches welcome though ;)
> > 
> > Another distinction between Openstack and oVirt is how the
> > Nova/ovirt-engine look upon storage systems. In Openstack, a stand
> > alone storage service(Cinder) exports the raw storage block device
> > to Nova. On the other hand, in oVirt, storage system is highly
> > bounded with the cluster scheduling system which integrates storage
> > sub-system, VM dispatching sub-system, ISO image sub systems. This
> > combination make all of the sub-system integrated in a whole which
> > is easy to deploy, but it make the sub-system more opaque and not
> > harder to reuse and maintain. This new storage API proposal give us
> > an opportunity to distinct these sub-systems as new components
> > which
> > export better, loose-coupling APIs to VDSM.
> 
> A very good point and an important goal in my opinion.  I'd like to
> see
> ovirt-engine become more of a GUI for configuring the storage
> component (like it
> does for Gluster) rather than the centralized manager of storage.
>  The clustered
> storage should be able to take care of itself as long as the peer
> hosts can
> negotiate the SDM role.
> 
> It would be cool if someone could actually dedicate a
> non-virtualization host
> where its only job is to handle SDM operations.  Such a host could
> choose to
> only deploy the standalone HSM service and not the complete vdsm
> package.

OpenStack and oVirt have different architectures and goals.

Even though they are both marketed as IaaS solutions they are designed for
different purposes.

OpenStack is designed around the idea of simplifying the *development* and
*integration* of IaaS subsystems through standardization of interfaces. If you
design a system that requires access to some type of infrastructural resource
you can develop against the OpenStack API for that specific resource and you
can consume different underlying implementations of the subsystem.
Alternatively if you are creating a new subsystem implementations one of your
exposed APIs can be the appropriate OpenStack API.

In short, they are a group of loosely coupled services meant to be used
replicated and distributed in a cluster. Everyone can create they own
implementations of the APIs.

oVirt is designed around the idea of simplifying the *management* of said infrastructure.

The ovirt-engine is the cluster manager and VDSM is the host-manager. Every
host in the cluster has a host manager installed on it (VDSM) and some
(currently only 1) might have the cluster-manager (ovirt-engine) and they are
the effective brain. oVirt ideally only has managing entities. VDSM APIs
delegate to other subsystems tasks that are in it's scope, the subsystems have
their own APIs. For VMs you have libvirt, for networking you have the linux
management tools and maybe netcf for policy we now have MOM. For iscsi we have
iscsiadm, etc. The only odd one out is the image provisioning subsystem which I
will get in to, don't worry.

This means, if you didn't already gather, that no host managed by ovirt can
exist without either VDSM or the ovirt-engine living on it. That being said, I
am a huge proponent of making all subsystems optional. Meaning you can have
VDSM that doesn't have the libvirt or networking glue bits and just has
storage, and gluster.

To put it simply, no host without a *managing* entity on it.

But, as you all have pointed out, VDSM is redundant. There is no reason why the
engine can't just directly ask libvirt to do things. There is no reason why we
can't make a general iscsi management API and expose it on it's own,
independent from other services. VDSM is frankensteinesque abomination of
misplaced BL and pass-through APIs.

This is why everyone are having a hard time figuring out what to do with it. I
have people on one side bothering me about putting more *management* logic in.
On the other side people are calling for standardized APIs which can't exist
with engine specific management logic.

To sum up this long rant, if you want to split up the bits that make VDSM in to
independent subsystems just don't work on VDSM because VDSM (excluding the
storage subsystem) is just glue anyway. Better just write another OpenStack
back-end for something.

As for the storage core. It is the only thing in VDSM that is not glue
and actually needs to sit on the host. The new storage code I'm writing is
actually developed in the hope that it will be independent from the rest of
VDSM and VDSM will just have glue, like everything else.


> 
> --
> Adam Litke <agl at us.ibm.com>
> IBM Linux Technology Center
> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


From dmichel at odecltd.com  Wed Jan 23 10:31:41 2013
From: dmichel at odecltd.com (David Michel (ODEC Ltd.))
Date: Wed, 23 Jan 2013 12:31:41 +0200
Subject: [Engine-devel] ovirt node
Message-ID: <1358937101.4603.2.camel@lucie-desktop>

hi 
  
    i cannot add ovirt node to ovirt-engine 
    ssh error occur although i can connect to the node using ssh from
engine machine 
    please i need your help to solve this issue 

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

From lhornyak at redhat.com  Wed Jan 23 10:46:23 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 23 Jan 2013 05:46:23 -0500 (EST)
Subject: [Engine-devel] ovirt node
In-Reply-To: <1358937101.4603.2.camel@lucie-desktop>
Message-ID: <1204662722.5096630.1358937983056.JavaMail.root@redhat.com>

hi David,

Could you share your engine log and version?
Also, the users mailing list may be better for this thread.

Laszlo

----- Original Message -----
> From: "David Michel (ODEC Ltd.)" <dmichel at odecltd.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, January 23, 2013 12:31:41 PM
> Subject: [Engine-devel] ovirt node
> 
> 
> hi
> 
> i cannot add ovirt node to ovirt-engine
> ssh error occur although i can connect to the node using ssh from
> engine machine
> please i need your help to solve this issue
> 
> thanks
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From navinp1281 at gmail.com  Wed Jan 23 11:54:35 2013
From: navinp1281 at gmail.com (navin p)
Date: Wed, 23 Jan 2013 17:24:35 +0530
Subject: [Engine-devel] ovirt engine sdk
Message-ID: <CAKVd3pXQeG0VpV=49Oi=hdvxMs6c-T_xTrGzWzTxE2isySw0Dg@mail.gmail.com>

Hi,
    I've written the following python program after configuring ovirt.


from ovirtsdk.xml import params
from ovirtsdk.api import API



api=API(url='http://XYZ:80',username='ABC',password='123')

print "\n**********************VMS************************\n"

vmlist = api.vms.list()
hostlist = api.hosts.list()
evenlist = api.events.list();


for vm in vmlist:
    print vm.name,vm.memory,vm.id,vm.os.kernel,vm.cluster.id,vm.start_time

print "\n**********************HOSTS ********************\n"

for host in hostlist:
    print host.name

#print "\n**********************EVENTS ********************\n"

#for evt in evenlist:
 #   print evt.description

It prints the output as

*********************VMS************************

fedora18 2147483648 3e4634b7-82a9-4c4f-8599-0f9092a9258e None
99408929-82cf-4dc7-a532-9d998063fa95 None
testdtop1 536870912 c256a1d9-2e3f-42e8-9020-6d08d21d2d73 None
99408929-82cf-4dc7-a532-9d998063fa95 2013-01-23T09:59:36.726Z
testvm1 268435456 f6b2a97d-34b2-4a62-adae-ac0504b96558 None
99408929-82cf-4dc7-a532-9d998063fa95 2013-01-23T09:55:06.727Z
testvmfedora18 536870912 25c14ee6-65dd-4785-af0c-a8df3f87573f None
99408929-82cf-4dc7-a532-9d998063fa95 None

**********************HOSTS ********************

omwin.ind.hp.com

Now i want to get the statistics for each vm like the memory used and
memory installed etc in python. How do i go about getting them ? Do we have
something like a header file in C or C++ where i can see the member
variables and then get the statistics ?


Regards,
Navin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130123/55a5fc44/attachment.html>

From mpastern at redhat.com  Wed Jan 23 12:45:24 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 23 Jan 2013 14:45:24 +0200
Subject: [Engine-devel] ovirt engine sdk
In-Reply-To: <CAKVd3pXQeG0VpV=49Oi=hdvxMs6c-T_xTrGzWzTxE2isySw0Dg@mail.gmail.com>
References: <CAKVd3pXQeG0VpV=49Oi=hdvxMs6c-T_xTrGzWzTxE2isySw0Dg@mail.gmail.com>
Message-ID: <50FFDB64.6080801@redhat.com>


Hi Navin,

On 01/23/2013 01:54 PM, navin p wrote:
> Hi,
>     I've written the following python program after configuring ovirt.
> 
> 
> from ovirtsdk.xml import params
> from ovirtsdk.api import API
> 
> 
> 
> api=API(url='http://XYZ:80',username='ABC',password='123')
> 
> print "\n**********************VMS************************\n"
> 
> vmlist = api.vms.list()
> hostlist = api.hosts.list()
> evenlist = api.events.list();
> 
> 
> for vm in vmlist:
>     print vm.name <http://vm.name>,vm.memory,vm.id <http://vm.id>,vm.os.kernel,vm.cluster.id <http://vm.cluster.id>,vm.start_time
>   
> print "\n**********************HOSTS ********************\n"
> 
> for host in hostlist:
>     print host.name <http://host.name>
> 
> #print "\n**********************EVENTS ********************\n"
> 
> #for evt in evenlist:
>  #   print evt.description
> 
> It prints the output as 
> 
> *********************VMS************************
> 
> fedora18 2147483648 3e4634b7-82a9-4c4f-8599-0f9092a9258e None 99408929-82cf-4dc7-a532-9d998063fa95 None
> testdtop1 536870912 c256a1d9-2e3f-42e8-9020-6d08d21d2d73 None 99408929-82cf-4dc7-a532-9d998063fa95 2013-01-23T09:59:36.726Z
> testvm1 268435456 f6b2a97d-34b2-4a62-adae-ac0504b96558 None 99408929-82cf-4dc7-a532-9d998063fa95 2013-01-23T09:55:06.727Z
> testvmfedora18 536870912 25c14ee6-65dd-4785-af0c-a8df3f87573f None 99408929-82cf-4dc7-a532-9d998063fa95 None
> 
> **********************HOSTS ********************
> 
> omwin.ind.hp.com <http://omwin.ind.hp.com>
> 
> Now i want to get the statistics for each vm like the memory used and memory installed etc in python. How do i go about getting them ? 

vm object has statistics sub-collection, you can access it by: vm.statistics.list(),

> Do we have something like a header
> file in C or C++ where i can see the member variables and then get the statistics ?

in python, you can see object's attributes by accessing __dict__/__getattr__/dir(object)/etc.,
vm.__dict__ will do the job for you, however i'd suggest you using some IDE (i'm using Eclipse + PyDev plugin),
this way you'll be able accessing object attributes simply by Ctrl+SPACE auto-completion.

> 
> 
> Regards,
> Navin
> 
> 
> 
> _______________________________________________
> 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 navinp1281 at gmail.com  Wed Jan 23 13:53:17 2013
From: navinp1281 at gmail.com (navin p)
Date: Wed, 23 Jan 2013 19:23:17 +0530
Subject: [Engine-devel] ovirt engine sdk
In-Reply-To: <50FFDB64.6080801@redhat.com>
References: <CAKVd3pXQeG0VpV=49Oi=hdvxMs6c-T_xTrGzWzTxE2isySw0Dg@mail.gmail.com>
	<50FFDB64.6080801@redhat.com>
Message-ID: <CAKVd3pUTNt4Wk97=uBDuWK3Gynf5X7RMR+QBh3ntjzr54shMfg@mail.gmail.com>

Hi Michael,

Thanks for your help.

On Wed, Jan 23, 2013 at 6:15 PM, Michael Pasternak <mpastern at redhat.com>wrote:

>
>
> in python, you can see object's attributes by accessing
> __dict__/__getattr__/dir(object)/etc.,
> vm.__dict__ will do the job for you, however i'd suggest you using some
> IDE (i'm using Eclipse + PyDev plugin),
> this way you'll be able accessing object attributes simply by Ctrl+SPACE
> auto-completion.
>
>   Do i have import something for Ctrl+SPACE to work ? It doesn't work for
me atleast for list attributes.

for vm in vmlist:
    print vm.name,vm.memory,vm.id,vm.os.kernel,vm.cluster.id,vm.start_time
    #print help(vm.statistics.list())
    vmslist = vm.statistics.list()
    for i in vmslist:
       print i.get_name()

prints

memory.installed
memory.used
cpu.current.guest
cpu.current.hypervisor
cpu.current.total

but i need the values of memory.installed and memory.used .

Also where do i get the Java SDK and jars ? I looked at maven but it was
1.0 version of SDK.


Regards,
Navin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130123/935d9c56/attachment.html>

From mpastern at redhat.com  Wed Jan 23 14:12:58 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 23 Jan 2013 16:12:58 +0200
Subject: [Engine-devel] ovirt engine sdk
In-Reply-To: <CAKVd3pUTNt4Wk97=uBDuWK3Gynf5X7RMR+QBh3ntjzr54shMfg@mail.gmail.com>
References: <CAKVd3pXQeG0VpV=49Oi=hdvxMs6c-T_xTrGzWzTxE2isySw0Dg@mail.gmail.com>	<50FFDB64.6080801@redhat.com>
	<CAKVd3pUTNt4Wk97=uBDuWK3Gynf5X7RMR+QBh3ntjzr54shMfg@mail.gmail.com>
Message-ID: <50FFEFEA.20501@redhat.com>

On 01/23/2013 03:53 PM, navin p wrote:
> Hi Michael,
>  
> Thanks for your help.
> 
> On Wed, Jan 23, 2013 at 6:15 PM, Michael Pasternak <mpastern at redhat.com <mailto:mpastern at redhat.com>> wrote:
> 
> 
> 
>     in python, you can see object's attributes by accessing __dict__/__getattr__/dir(object)/etc.,
>     vm.__dict__ will do the job for you, however i'd suggest you using some IDE (i'm using Eclipse + PyDev plugin),
>     this way you'll be able accessing object attributes simply by Ctrl+SPACE auto-completion.
> 
>   Do i have import something for Ctrl+SPACE to work ? It doesn't work for me atleast for list attributes.
> 
> for vm in vmlist:
>     print vm.name <http://vm.name>,vm.memory,vm.id <http://vm.id>,vm.os.kernel,vm.cluster.id <http://vm.cluster.id>,vm.start_time
>     #print help(vm.statistics.list())
>     vmslist = vm.statistics.list()
>     for i in vmslist:
>        print i.get_name()
> 
> prints
> 
> memory.installed
> memory.used
> cpu.current.guest
> cpu.current.hypervisor
> cpu.current.total
> 
> but i need the values of memory.installed and memory.used .

statistic holders are complex types, you can fetch data by:

i.unit // the unit of the holder data
i.values.value[0].datum // actual data


> 
> Also where do i get the Java SDK and jars ? I looked at maven but it was 1.0 version of SDK.

central repo has 1.0.0.2-1, see [1], deployment details can be found at [2], wiki at [3].

[1] http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.ovirt.engine.sdk%22
[2] http://www.ovirt.org/Java-sdk#Maven_deployment
[3] http://www.ovirt.org/Java-sdk

> 
> 
> Regards,
> Navin 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From lhornyak at redhat.com  Wed Jan 23 14:34:07 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 23 Jan 2013 09:34:07 -0500 (EST)
Subject: [Engine-devel] default Vm memory size
In-Reply-To: <382377130.5152657.1358951314211.JavaMail.root@redhat.com>
Message-ID: <138432545.5154522.1358951647708.JavaMail.root@redhat.com>

Hi,

The default Vm size is 512 MB now. I think A bit more could be useful, e.g. a fedora installer won't start with 512 MB.
What about 1024 MB?

thx,
Laszlo


From rgolan at redhat.com  Wed Jan 23 15:00:57 2013
From: rgolan at redhat.com (Roy Golan)
Date: Wed, 23 Jan 2013 17:00:57 +0200
Subject: [Engine-devel] default Vm memory size
In-Reply-To: <138432545.5154522.1358951647708.JavaMail.root@redhat.com>
References: <138432545.5154522.1358951647708.JavaMail.root@redhat.com>
Message-ID: <50FFFB29.2080601@redhat.com>

On 01/23/2013 04:34 PM, Laszlo Hornyak wrote:
> Hi,
>
> The default Vm size is 512 MB now. I think A bit more could be useful, e.g. a fedora installer won't start with 512 MB.
> What about 1024 MB?
Upcoming "Instance Types" would be the means to handle that rather than 
the "Blank" template.
Also there's work around integrating libosinfo for validating for 
minimum RAM per guest OS.
>
> thx,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From iheim at redhat.com  Wed Jan 23 18:12:09 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 23 Jan 2013 10:12:09 -0800
Subject: [Engine-devel] default Vm memory size
In-Reply-To: <50FFFB29.2080601@redhat.com>
References: <138432545.5154522.1358951647708.JavaMail.root@redhat.com>
	<50FFFB29.2080601@redhat.com>
Message-ID: <510027F9.4000706@redhat.com>

On 23/01/2013 07:00, Roy Golan wrote:
> On 01/23/2013 04:34 PM, Laszlo Hornyak wrote:
>> Hi,
>>
>> The default Vm size is 512 MB now. I think A bit more could be useful,
>> e.g. a fedora installer won't start with 512 MB.
>> What about 1024 MB?
> Upcoming "Instance Types" would be the means to handle that rather than
> the "Blank" template.
> Also there's work around integrating libosinfo for validating for
> minimum RAM per guest OS.

but until then, why not change the default to 1GB which i hope is a one 
liner?


From cheryntan at redhat.com  Thu Jan 24 07:47:44 2013
From: cheryntan at redhat.com (Cheryn Tan)
Date: Thu, 24 Jan 2013 02:47:44 -0500 (EST)
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <1189738178.10108119.1359013646313.JavaMail.root@redhat.com>
Message-ID: <365279346.10108140.1359013664441.JavaMail.root@redhat.com>

Hi all,

I'm preparing the oVirt 3.2 release notes, starting with the features listed here: http://www.ovirt.org/OVirt_3.2_release-management#Features

Can you please go through the list, and reply to this thread if:
a) There are features being released for 3.2 which should be documented, but are not on the list; or
b) Some of the planned features on this list are not being released for 3.2; or
c) Some of the features on this list are being released for 3.2, but should not be documented.

For features which aren't on the wiki, please send a short description or Bugzilla numbers of each feature.

Please reply no later than Jan 28.

Thank you very much for your help!
Cheryn


From sanjal at redhat.com  Thu Jan 24 09:00:38 2013
From: sanjal at redhat.com (Shireesh Anjal)
Date: Thu, 24 Jan 2013 14:30:38 +0530
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <365279346.10108140.1359013664441.JavaMail.root@redhat.com>
References: <365279346.10108140.1359013664441.JavaMail.root@redhat.com>
Message-ID: <5100F836.3000203@redhat.com>

Following gluster related features were planned, but are not yet ready 
to be released:

  * Unidirectional Gluster Geo-replication support
    <http://www.ovirt.org/Features/Gluster_Geo_Replication>
  * Support for asynchronous Gluster volume tasks
    <http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management>
  * Gluster Volume Performance Statistics
    <http://www.ovirt.org/Features/Gluster_Volume_Performance_Statistics>


Features that are not on the wiki, but will be released are:

  * Bug 901443 <https://bugzilla.redhat.com/show_bug.cgi?id=901443> -
    engine-setup should prompt for application mode
  * oVirt log collector enhanced to collect gluster logs if applicable
    <http://gerrit.ovirt.org/9765>


Regards,
Shireesh

On Thursday 24 January 2013 01:17 PM, Cheryn Tan wrote:
> Hi all,
>
> I'm preparing the oVirt 3.2 release notes, starting with the features listed here: http://www.ovirt.org/OVirt_3.2_release-management#Features
>
> Can you please go through the list, and reply to this thread if:
> a) There are features being released for 3.2 which should be documented, but are not on the list; or
> b) Some of the planned features on this list are not being released for 3.2; or
> c) Some of the features on this list are being released for 3.2, but should not be documented.
>
> For features which aren't on the wiki, please send a short description or Bugzilla numbers of each feature.
>
> Please reply no later than Jan 28.
>
> Thank you very much for your help!
> Cheryn
> _______________________________________________
> 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/20130124/a5214e04/attachment.html>

From ofrenkel at redhat.com  Thu Jan 24 12:54:16 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Thu, 24 Jan 2013 07:54:16 -0500 (EST)
Subject: [Engine-devel] default Vm memory size
In-Reply-To: <510027F9.4000706@redhat.com>
Message-ID: <1988615859.10317556.1359032056047.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Roy Golan" <rgolan at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 23, 2013 8:12:09 PM
> Subject: Re: [Engine-devel] default Vm memory size
> 
> On 23/01/2013 07:00, Roy Golan wrote:
> > On 01/23/2013 04:34 PM, Laszlo Hornyak wrote:
> >> Hi,
> >>
> >> The default Vm size is 512 MB now. I think A bit more could be
> >> useful,
> >> e.g. a fedora installer won't start with 512 MB.
> >> What about 1024 MB?
> > Upcoming "Instance Types" would be the means to handle that rather
> > than
> > the "Blank" template.
> > Also there's work around integrating libosinfo for validating for
> > minimum RAM per guest OS.
> 
> but until then, why not change the default to 1GB which i hope is a
> one
> liner?

+1 (its a db update liner - change blank template mem)

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


From lhornyak at redhat.com  Thu Jan 24 14:19:57 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Thu, 24 Jan 2013 09:19:57 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <1623772994.5808524.1359037153120.JavaMail.root@redhat.com>
Message-ID: <1570564188.5808831.1359037197536.JavaMail.root@redhat.com>

Hi,

Watchdog support in engine will add watchdog to the ovirt UI and REST API. Watchdog cards will be mainly used in HA vm's.

http://www.ovirt.org/Features/Watchdog_engine_support

Your feedback is welcome!

Thank you,
Laszlo


From yzaslavs at redhat.com  Thu Jan 24 15:01:28 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Thu, 24 Jan 2013 10:01:28 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <1570564188.5808831.1359037197536.JavaMail.root@redhat.com>
Message-ID: <1117388774.14888854.1359039688786.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, January 24, 2013 4:19:57 PM
> Subject: [Engine-devel] Watchdog support Feature
> 
> Hi,
> 
> Watchdog support in engine will add watchdog to the ovirt UI and REST
> API. Watchdog cards will be mainly used in HA vm's.
> 
> http://www.ovirt.org/Features/Watchdog_engine_support
> 
> Your feedback is welcome!

Although I'm sure you're aware of it - I'm reminding you that you should handle backward compatibility for this feature -
So you should have an entry at vdc_options for this + use the FeatureEnabled infra

Regarding the action types at db - I would suggest sticking to varchar.



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


From lhornyak at redhat.com  Thu Jan 24 15:06:13 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Thu, 24 Jan 2013 10:06:13 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <1117388774.14888854.1359039688786.JavaMail.root@redhat.com>
Message-ID: <237877634.5880015.1359039973201.JavaMail.root@redhat.com>

Hi Yair,

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, January 24, 2013 5:01:28 PM
> Subject: Re: [Engine-devel] Watchdog support Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, January 24, 2013 4:19:57 PM
> > Subject: [Engine-devel] Watchdog support Feature
> > 
> > Hi,
> > 
> > Watchdog support in engine will add watchdog to the ovirt UI and
> > REST
> > API. Watchdog cards will be mainly used in HA vm's.
> > 
> > http://www.ovirt.org/Features/Watchdog_engine_support
> > 
> > Your feedback is welcome!
> 
> Although I'm sure you're aware of it - I'm reminding you that you
> should handle backward compatibility for this feature -
> So you should have an entry at vdc_options for this + use the
> FeatureEnabled infra

Good point, thx!


> 
> Regarding the action types at db - I would suggest sticking to
> varchar.

Well, at the moment all enums are stored as int, so varchar too will be something new.

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


From yzaslavs at redhat.com  Thu Jan 24 15:21:35 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Thu, 24 Jan 2013 10:21:35 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <237877634.5880015.1359039973201.JavaMail.root@redhat.com>
Message-ID: <812421951.14905486.1359040895688.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, January 24, 2013 5:06:13 PM
> Subject: Re: [Engine-devel] Watchdog support Feature
> 
> Hi Yair,
> 
> ----- Original Message -----
> > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, January 24, 2013 5:01:28 PM
> > Subject: Re: [Engine-devel] Watchdog support Feature
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Thursday, January 24, 2013 4:19:57 PM
> > > Subject: [Engine-devel] Watchdog support Feature
> > > 
> > > Hi,
> > > 
> > > Watchdog support in engine will add watchdog to the ovirt UI and
> > > REST
> > > API. Watchdog cards will be mainly used in HA vm's.
> > > 
> > > http://www.ovirt.org/Features/Watchdog_engine_support
> > > 
> > > Your feedback is welcome!
> > 
> > Although I'm sure you're aware of it - I'm reminding you that you
> > should handle backward compatibility for this feature -
> > So you should have an entry at vdc_options for this + use the
> > FeatureEnabled infra
> 
> Good point, thx!
> 
> 
> > 
> > Regarding the action types at db - I would suggest sticking to
> > varchar.
> 
> Well, at the moment all enums are stored as int, so varchar too will
> be something new.

Hi,
Sorry, to keep consistency let's go for int - I thought for some reason that you're in dilemma between varchar or something else ( http://www.postgresql.org/docs/9.1/static/datatype-enum.html ) and I automatically thought about one of the two options.

Yair


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


From iheim at redhat.com  Thu Jan 24 15:30:07 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 24 Jan 2013 07:30:07 -0800
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <365279346.10108140.1359013664441.JavaMail.root@redhat.com>
References: <365279346.10108140.1359013664441.JavaMail.root@redhat.com>
Message-ID: <5101537F.9020706@redhat.com>

On 23/01/2013 23:47, Cheryn Tan wrote:
> Hi all,
>
> I'm preparing the oVirt 3.2 release notes, starting with the features listed here: http://www.ovirt.org/OVirt_3.2_release-management#Features
>
> Can you please go through the list, and reply to this thread if:
> a) There are features being released for 3.2 which should be documented, but are not on the list; or
> b) Some of the planned features on this list are not being released for 3.2; or
> c) Some of the features on this list are being released for 3.2, but should not be documented.
>
> For features which aren't on the wiki, please send a short description or Bugzilla numbers of each feature.
>
> Please reply no later than Jan 28.
>
> Thank you very much for your help!
> Cheryn
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

I think most of these made it to 3.2, i'll point fingers at others to 
give more details... (doesn't mean others weren't involved in them, just 
picked someone to give the details for release notes).

SSIA:
Add support for Opteron G5 (Seoul)
Add Support for Intel Haswell CPU
windows 8/12 - add os type
windows 8/12 - default in user portal should be rdp
    (till we have spice support...)
expand tree by default with list of DCs

federico:
storage live migration

tomas:
Configure Smartcard for VM including Portal support
Allow e1000 to be selected as nic type for Windows VM dynamic

frantisek:
checkbox at vm level to prevent accidental deletion

shahar:
vm payload issues (with cd-rom)

Arik
Changing the name of the virtual machines, created from
    a pool through web-admin-portal

Alona:
network as a main tab
network permissions
network main tab: search for networks (and api)
network main tab: show vms by logical network
hot-plug network - change networks on the fly

Igor:
hotplug nic hook

Muli:
display the VM interface IP per vnic
report ipv6 addresses from guest

vojtech:
ui plugins

Greg:
cluster policy on hyperthreads usage

Laszlo:
-cpu host

Ofri:
quota - add to resource tab in power user portal

moran:
ovirt-live

daniel erez:
slm: move multiple disks (one by one)
unicode enablement for OVF fields
disks subtab/api under storage domain

Tal:
delete disk on vm delete flag (for image vs. volume)

Liron:
move OVF update out of reconstruct master and all other flows as an
    independent sync process

Eli:
inject events
bootstrap: fetch logs to engine
power management proxy (DC or cluster)
multiple fencing devices
add ilo2/ilo4 in text

Yaniv Bronhaim:
collect hardware (bios) information

juan:
engine-vdsm ssl session caching

michael kublin:
auto-recovery: last host in status up

Alon Bar-Lev:
bootstrap: install rhev-h without communication to
    engine 443
bootstrap: pki: use PKCS#12 format to store keys
bootstrap: rewrite (ovirt-host-deploy)
bootstrap: rewrite (otopi)

Yair:
rhevm-manage-domains hardcodes the DC's address instead
    of using DNS lookups

Yaniv Dary:
"cloud provider"" report
Report Daily list of people logged into Spice consoles
    and their activity "
add status of storage domain to dwh/reports
DC Dashboard should display Storage Domains count
single vm uptime - rhevm-reports should be able to
    report uptime against virtual machines
Storage Inventory Report - New report

michael pasternak:
sdk - allow simultaneous connections to multiple servers
cli - disable output redirection to ease testing efforts
java sdk

Doron:
tuned profile for host

doron/adam:
not sure about status of vdsm-mom in 3.2?


shireesh - what about:
Forced removal of a host
Configuration sync with Gluster CLI
Import of existing gluster clusters

Thanks,
    Itamar


From jhernand at redhat.com  Thu Jan 24 15:46:14 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Thu, 24 Jan 2013 16:46:14 +0100
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <5101537F.9020706@redhat.com>
References: <365279346.10108140.1359013664441.JavaMail.root@redhat.com>
	<5101537F.9020706@redhat.com>
Message-ID: <51015746.8060000@redhat.com>

> engine-vdsm ssl session caching

The performance of the SSL communication between the ovirt-engine and 
VDSM has been improved with the implementation SSL session caching. This 
means that the engine doesn't have to perform a new SSL handshake for 
each request. In environments with many hypervisors this has a 
significant impact on the use of CPU in the machine where ovirt-engine 
is running.

-- 
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 ofrenkel at redhat.com  Thu Jan 24 15:53:20 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Thu, 24 Jan 2013 10:53:20 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <1570564188.5808831.1359037197536.JavaMail.root@redhat.com>
Message-ID: <57584708.10474041.1359042800017.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, January 24, 2013 4:19:57 PM
> Subject: [Engine-devel] Watchdog support Feature
> 
> Hi,
> 
> Watchdog support in engine will add watchdog to the ovirt UI and REST
> API. Watchdog cards will be mainly used in HA vm's.
> 
> http://www.ovirt.org/Features/Watchdog_engine_support
> 
> Your feedback is welcome!

IIUC, this is a device in vdsm,
which means it will be stored in vm-devices table once the vm is run, right?
if so, no need for the boolean in the vm table, just manage the device for it as other devices..

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



From agl at us.ibm.com  Thu Jan 24 15:54:44 2013
From: agl at us.ibm.com (Adam Litke)
Date: Thu, 24 Jan 2013 09:54:44 -0600
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <5101537F.9020706@redhat.com>
References: <365279346.10108140.1359013664441.JavaMail.root@redhat.com>
	<5101537F.9020706@redhat.com>
Message-ID: <20130124155443.GL26579@aglitke.ibm.com>

On Thu, Jan 24, 2013 at 07:30:07AM -0800, Itamar Heim wrote:
> doron/adam:
> not sure about status of vdsm-mom in 3.2?

mom is enabled by default for hosts in 3.2 and will control KSM only.  No
user-visible changes are expected as this is primarily an infrastructure change
to enable more advanced SLA in the next release.

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center



From ykaul at redhat.com  Thu Jan 24 15:55:58 2013
From: ykaul at redhat.com (Yaniv Kaul)
Date: Thu, 24 Jan 2013 17:55:58 +0200
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <57584708.10474041.1359042800017.JavaMail.root@redhat.com>
References: <57584708.10474041.1359042800017.JavaMail.root@redhat.com>
Message-ID: <5101598E.8030809@redhat.com>

On 24/01/13 17:53, Omer Frenkel wrote:
>
> ----- Original Message -----
>> From: "Laszlo Hornyak" <lhornyak at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Thursday, January 24, 2013 4:19:57 PM
>> Subject: [Engine-devel] Watchdog support Feature
>>
>> Hi,
>>
>> Watchdog support in engine will add watchdog to the ovirt UI and REST
>> API. Watchdog cards will be mainly used in HA vm's.
>>
>> http://www.ovirt.org/Features/Watchdog_engine_support
>>
>> Your feedback is welcome!
> IIUC, this is a device in vdsm,
> which means it will be stored in vm-devices table once the vm is run, right?
> if so, no need for the boolean in the vm table, just manage the device for it as other devices..

Are all watchdogs available to all operating systems?
Y.

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



From iheim at redhat.com  Thu Jan 24 15:54:12 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 24 Jan 2013 07:54:12 -0800
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <5101598E.8030809@redhat.com>
References: <57584708.10474041.1359042800017.JavaMail.root@redhat.com>
	<5101598E.8030809@redhat.com>
Message-ID: <51015924.4010803@redhat.com>

On 24/01/2013 07:55, Yaniv Kaul wrote:
> Are all watchdogs available to all operating systems?

ask libosinfo :)


From sanjal at redhat.com  Thu Jan 24 16:01:18 2013
From: sanjal at redhat.com (Shireesh Anjal)
Date: Thu, 24 Jan 2013 11:01:18 -0500 (EST)
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <5101537F.9020706@redhat.com>
Message-ID: <1964323925.6114582.1359043278233.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Cheryn Tan" <cheryntan at redhat.com>
> Cc: "Juan Antonio Hernandez Fernandez" <jhernand at redhat.com>, engine-devel at ovirt.org, "Shireesh Anjal"
> <sanjal at redhat.com>
> Sent: Thursday, January 24, 2013 9:00:07 PM
> Subject: Re: [Engine-devel] 3.2 features for release notes
> 
> On 23/01/2013 23:47, Cheryn Tan wrote:
> > Hi all,
> >
> > I'm preparing the oVirt 3.2 release notes, starting with the
> > features listed here:
> > http://www.ovirt.org/OVirt_3.2_release-management#Features
> >
> > Can you please go through the list, and reply to this thread if:
> > a) There are features being released for 3.2 which should be
> > documented, but are not on the list; or
> > b) Some of the planned features on this list are not being released
> > for 3.2; or
> > c) Some of the features on this list are being released for 3.2,
> > but should not be documented.
> >
> > For features which aren't on the wiki, please send a short
> > description or Bugzilla numbers of each feature.
> >
> > Please reply no later than Jan 28.
> >
> > Thank you very much for your help!
> > Cheryn
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> I think most of these made it to 3.2, i'll point fingers at others to
> give more details... (doesn't mean others weren't involved in them,
> just
> picked someone to give the details for release notes).
> 
> SSIA:
> Add support for Opteron G5 (Seoul)
> Add Support for Intel Haswell CPU
> windows 8/12 - add os type
> windows 8/12 - default in user portal should be rdp
>     (till we have spice support...)
> expand tree by default with list of DCs
> 
> federico:
> storage live migration
> 
> tomas:
> Configure Smartcard for VM including Portal support
> Allow e1000 to be selected as nic type for Windows VM dynamic
> 
> frantisek:
> checkbox at vm level to prevent accidental deletion
> 
> shahar:
> vm payload issues (with cd-rom)
> 
> Arik
> Changing the name of the virtual machines, created from
>     a pool through web-admin-portal
> 
> Alona:
> network as a main tab
> network permissions
> network main tab: search for networks (and api)
> network main tab: show vms by logical network
> hot-plug network - change networks on the fly
> 
> Igor:
> hotplug nic hook
> 
> Muli:
> display the VM interface IP per vnic
> report ipv6 addresses from guest
> 
> vojtech:
> ui plugins
> 
> Greg:
> cluster policy on hyperthreads usage
> 
> Laszlo:
> -cpu host
> 
> Ofri:
> quota - add to resource tab in power user portal
> 
> moran:
> ovirt-live
> 
> daniel erez:
> slm: move multiple disks (one by one)
> unicode enablement for OVF fields
> disks subtab/api under storage domain
> 
> Tal:
> delete disk on vm delete flag (for image vs. volume)
> 
> Liron:
> move OVF update out of reconstruct master and all other flows as an
>     independent sync process
> 
> Eli:
> inject events
> bootstrap: fetch logs to engine
> power management proxy (DC or cluster)
> multiple fencing devices
> add ilo2/ilo4 in text
> 
> Yaniv Bronhaim:
> collect hardware (bios) information
> 
> juan:
> engine-vdsm ssl session caching
> 
> michael kublin:
> auto-recovery: last host in status up
> 
> Alon Bar-Lev:
> bootstrap: install rhev-h without communication to
>     engine 443
> bootstrap: pki: use PKCS#12 format to store keys
> bootstrap: rewrite (ovirt-host-deploy)
> bootstrap: rewrite (otopi)
> 
> Yair:
> rhevm-manage-domains hardcodes the DC's address instead
>     of using DNS lookups
> 
> Yaniv Dary:
> "cloud provider"" report
> Report Daily list of people logged into Spice consoles
>     and their activity "
> add status of storage domain to dwh/reports
> DC Dashboard should display Storage Domains count
> single vm uptime - rhevm-reports should be able to
>     report uptime against virtual machines
> Storage Inventory Report - New report
> 
> michael pasternak:
> sdk - allow simultaneous connections to multiple servers
> cli - disable output redirection to ease testing efforts
> java sdk
> 
> Doron:
> tuned profile for host
> 
> doron/adam:
> not sure about status of vdsm-mom in 3.2?
> 
> 
> shireesh - what about:
> Forced removal of a host

Thanks - I had missed this one - https://bugzilla.redhat.com/show_bug.cgi?id=882807

> Configuration sync with Gluster CLI

Was planned, and feature page exists (http://www.ovirt.org/Features/Gluster_Sync_Configuration_With_CLI)

> Import of existing gluster clusters

Was planned, and feature page exists (http://www.ovirt.org/Features/Gluster_Import_Existing_Cluster)

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


From alonbl at redhat.com  Thu Jan 24 16:03:18 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 24 Jan 2013 11:03:18 -0500 (EST)
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <5101537F.9020706@redhat.com>
Message-ID: <989800270.3849109.1359043398840.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Cheryn Tan" <cheryntan at redhat.com>
> Cc: engine-devel at ovirt.org, "Federico Simoncelli" <fsimonce at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>, "Roy
> Golan" <rgolan at redhat.com>, "Shahar Havivi" <shavivi at redhat.com>, "Frantisek Kobzik" <fkobzik at redhat.com>, "Arik
> Hadas" <ahadas at redhat.com>, "Alona Kaplan" <alkaplan at redhat.com>, "Igor Lvovsky" <ilvovsky at redhat.com>, "Muli Salem"
> <msalem at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, "Greg Padgett" <gpadgett at redhat.com>, "Doron Fediuck"
> <dfediuck at redhat.com>, omasad at redhat.com, "Moran Goldboim" <mgoldboi at redhat.com>, "Daniel Erez" <derez at redhat.com>,
> "Tal Nisan" <tnisan at redhat.com>, "Liron Aravot" <laravot at redhat.com>, "Eli Mesika" <emesika at redhat.com>, "Yaniv
> Bronheim" <ybronhei at redhat.com>, "Juan Antonio Hernandez Fernandez" <jhernand at redhat.com>, "Alon Bar-Lev"
> <alonbl at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, agl at us.ibm.com, "Shireesh Anjal" <sanjal at redhat.com>,
> "Yaniv Dary" <ydary at redhat.com>, "Michael Pasternak" <mpastern at redhat.com>
> Sent: Thursday, January 24, 2013 5:30:07 PM
> Subject: Re: [Engine-devel] 3.2 features for release notes
> 
> On 23/01/2013 23:47, Cheryn Tan wrote:
> > Hi all,
> >
> > I'm preparing the oVirt 3.2 release notes, starting with the
> > features listed here:
> > http://www.ovirt.org/OVirt_3.2_release-management#Features
> >
> > Can you please go through the list, and reply to this thread if:
> > a) There are features being released for 3.2 which should be
> > documented, but are not on the list; or
> > b) Some of the planned features on this list are not being released
> > for 3.2; or
> > c) Some of the features on this list are being released for 3.2,
> > but should not be documented.
> >
> > For features which aren't on the wiki, please send a short
> > description or Bugzilla numbers of each feature.
> >
> > Please reply no later than Jan 28.
> >
> > Thank you very much for your help!
> > Cheryn
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> I think most of these made it to 3.2, i'll point fingers at others to
> give more details... (doesn't mean others weren't involved in them,
> just
> picked someone to give the details for release notes).
> 
> SSIA:
> Add support for Opteron G5 (Seoul)
> Add Support for Intel Haswell CPU
> windows 8/12 - add os type
> windows 8/12 - default in user portal should be rdp
>     (till we have spice support...)
> expand tree by default with list of DCs
> 
> federico:
> storage live migration
> 
> tomas:
> Configure Smartcard for VM including Portal support
> Allow e1000 to be selected as nic type for Windows VM dynamic
> 
> frantisek:
> checkbox at vm level to prevent accidental deletion
> 
> shahar:
> vm payload issues (with cd-rom)
> 
> Arik
> Changing the name of the virtual machines, created from
>     a pool through web-admin-portal
> 
> Alona:
> network as a main tab
> network permissions
> network main tab: search for networks (and api)
> network main tab: show vms by logical network
> hot-plug network - change networks on the fly
> 
> Igor:
> hotplug nic hook
> 
> Muli:
> display the VM interface IP per vnic
> report ipv6 addresses from guest
> 
> vojtech:
> ui plugins
> 
> Greg:
> cluster policy on hyperthreads usage
> 
> Laszlo:
> -cpu host
> 
> Ofri:
> quota - add to resource tab in power user portal
> 
> moran:
> ovirt-live
> 
> daniel erez:
> slm: move multiple disks (one by one)
> unicode enablement for OVF fields
> disks subtab/api under storage domain
> 
> Tal:
> delete disk on vm delete flag (for image vs. volume)
> 
> Liron:
> move OVF update out of reconstruct master and all other flows as an
>     independent sync process
> 
> Eli:
> inject events
> bootstrap: fetch logs to engine
> power management proxy (DC or cluster)
> multiple fencing devices
> add ilo2/ilo4 in text
> 
> Yaniv Bronhaim:
> collect hardware (bios) information
> 
> juan:
> engine-vdsm ssl session caching
> 
> michael kublin:
> auto-recovery: last host in status up
> 
> Alon Bar-Lev:
> bootstrap: install rhev-h without communication to
>     engine 443
> bootstrap: pki: use PKCS#12 format to store keys
> bootstrap: rewrite (ovirt-host-deploy)
> bootstrap: rewrite (otopi)

http://www.ovirt.org/Featrues/Bootstrap_Improvements
http://www.ovirt.org/Features/PKI_Improvements

> 
> Yair:
> rhevm-manage-domains hardcodes the DC's address instead
>     of using DNS lookups
> 
> Yaniv Dary:
> "cloud provider"" report
> Report Daily list of people logged into Spice consoles
>     and their activity "
> add status of storage domain to dwh/reports
> DC Dashboard should display Storage Domains count
> single vm uptime - rhevm-reports should be able to
>     report uptime against virtual machines
> Storage Inventory Report - New report
> 
> michael pasternak:
> sdk - allow simultaneous connections to multiple servers
> cli - disable output redirection to ease testing efforts
> java sdk
> 
> Doron:
> tuned profile for host
> 
> doron/adam:
> not sure about status of vdsm-mom in 3.2?
> 
> 
> shireesh - what about:
> Forced removal of a host
> Configuration sync with Gluster CLI
> Import of existing gluster clusters
> 
> Thanks,
>     Itamar
> 


From fsimonce at redhat.com  Thu Jan 24 16:20:19 2013
From: fsimonce at redhat.com (Federico Simoncelli)
Date: Thu, 24 Jan 2013 11:20:19 -0500 (EST)
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <5101537F.9020706@redhat.com>
Message-ID: <274237970.6122031.1359044419109.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Cheryn Tan" <cheryntan at redhat.com>
> Cc: engine-devel at ovirt.org, "Federico Simoncelli" <fsimonce at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>, "Roy
> Golan" <rgolan at redhat.com>, "Shahar Havivi" <shavivi at redhat.com>, "Frantisek Kobzik" <fkobzik at redhat.com>, "Arik
> Hadas" <ahadas at redhat.com>, "Alona Kaplan" <alkaplan at redhat.com>, "Igor Lvovsky" <ilvovsky at redhat.com>, "Muli Salem"
> <msalem at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, "Greg Padgett" <gpadgett at redhat.com>, "Doron Fediuck"
> <dfediuck at redhat.com>, omasad at redhat.com, "Moran Goldboim" <mgoldboi at redhat.com>, "Daniel Erez" <derez at redhat.com>,
> "Tal Nisan" <tnisan at redhat.com>, "Liron Aravot" <laravot at redhat.com>, "Eli Mesika" <emesika at redhat.com>, "Yaniv
> Bronheim" <ybronhei at redhat.com>, "Juan Antonio Hernandez Fernandez" <jhernand at redhat.com>, "Alon Bar-Lev"
> <alonbl at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, agl at us.ibm.com, "Shireesh Anjal" <sanjal at redhat.com>,
> "Yaniv Dary" <ydary at redhat.com>, "Michael Pasternak" <mpastern at redhat.com>
> Sent: Thursday, January 24, 2013 4:30:07 PM
> Subject: Re: [Engine-devel] 3.2 features for release notes
> 
> On 23/01/2013 23:47, Cheryn Tan wrote:
> > Hi all,
> >
> > I'm preparing the oVirt 3.2 release notes, starting with the
> > features listed here:
> > http://www.ovirt.org/OVirt_3.2_release-management#Features
> >
> > Can you please go through the list, and reply to this thread if:
> > a) There are features being released for 3.2 which should be
> > documented, but are not on the list; or
> > b) Some of the planned features on this list are not being released
> > for 3.2; or
> > c) Some of the features on this list are being released for 3.2,
> > but should not be documented.
> >
> > For features which aren't on the wiki, please send a short
> > description or Bugzilla numbers of each feature.
> >
> > Please reply no later than Jan 28.
> >
> > Thank you very much for your help!
> > Cheryn
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> I think most of these made it to 3.2, i'll point fingers at others to
> give more details... (doesn't mean others weren't involved in them,
> just
> picked someone to give the details for release notes).
> 
> SSIA:
> Add support for Opteron G5 (Seoul)
> Add Support for Intel Haswell CPU
> windows 8/12 - add os type
> windows 8/12 - default in user portal should be rdp
>     (till we have spice support...)
> expand tree by default with list of DCs
> 
> federico:
> storage live migration

I think that we should also advertise domain V3 (live upgrade) and
live snapshots (I think they weren't present in ovirt-3.1 iirc)

-- 
Federico


From shaharh at redhat.com  Thu Jan 24 16:20:28 2013
From: shaharh at redhat.com (Shahar Havivi)
Date: Thu, 24 Jan 2013 18:20:28 +0200
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <5101537F.9020706@redhat.com>
References: <365279346.10108140.1359013664441.JavaMail.root@redhat.com>
	<5101537F.9020706@redhat.com>
Message-ID: <20130124162026.GA15224@redhat.com>

> vm payload issues (with cd-rom)
Enable payload cd-rom as well as an iso domain cd-rom.
User couldn't use iso domain cd-rom if he choose to have a payload in a form
of a cd-rom.


From tjelinek at redhat.com  Fri Jan 25 09:55:43 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Fri, 25 Jan 2013 04:55:43 -0500 (EST)
Subject: [Engine-devel] [engine-devel] frontend builders proposal
In-Reply-To: <169654012.6485280.1359104009588.JavaMail.root@redhat.com>
Message-ID: <890129319.6505852.1359107743604.JavaMail.root@redhat.com>

Hi All,

as many of you may know, the way how the frontend and backend models are built on frontend (uicommonweb project) is not really ideal. Currently this logic is copy pasted over and over again to different places where it is needed with minor changes to fulfill the specific requirements. It is not only aesthetically problematic, but I recall tons of bugs caused by introducing a new field and forgetting to add it to every place it is used in GUI.

Now, as there will be big changes in the VM/Template models (http://www.ovirt.org/Features/Instance_Types), so the way how the VM, Template, Pool and also the newly created Instance Types models are being built has to be touched anyhow, it is a great opportunity to rethink the way how we do it. 

I have created a simple infrastructure (http://gerrit.ovirt.org/#/c/10874/) which could be used for it, and a PoC patch which uses this infrastructure (http://gerrit.ovirt.org/#/c/11354/). Please note that the PoC is not really impressive in means of removing duplications, I wanted to start with the simplest possibility.

The principles behind the infrastructure:
- have small, well named, easy to understand and reuse builders
- this builders can be chained together or embedded to each other to build the full resulting object (composite pattern)
- this builders can be asynchronous, and the next builder in the chain has to be executed only when the current is completely done

The structure:
- the base is an interface called Builder which has a method build(source, destination, rest)
- the builder implementing this interface 
  + will get the source and destination objects
  + copies whatever he wants from source to destination
  + when done, executes build on the first element of the rest
    + this may sound awkward, but this is the way how the async calls can be "linearized" in a general way, not embedding anonymous class into anonymous 
      class into anonymous class... as we do it today.
    + for synchronous builders, there is a BaseSyncBuilder which takes care of this boilerplate calling of next and exposes a simple method 
      build(S source, D destination)
  + to simplify the creating and running the chain of builders, there is a BuilderExecutor class (can be created as sync or async)

So, a simple example - even more simple than the PoC patch :)

//create the first builder
class FirstLetterBuilder extends BaseSyncBuilder<String, StringBuilder> {
 @Override
 protected void build(String source, StringBuilder destination) {
     // copy the first letter to the destination
     destination.append(source.charAt(0));
 }
}

//create the second builder
class SecondLetterBuilder extends BaseSyncBuilder<String, StringBuilder> {
 @Override
 protected void build(String source, StringBuilder destination) {
     // copy the second letter to the destination
     destination.append(source.charAt(1));
 }
}

// usage
...
// create the destination object
StringBuilder res = new StringBuilder();

// configure the executor with the two builders
BuilderExecutor<String, StringBuilder> executor = new BuilderExecutor<String, StringBuilder>(
        new FirstLetterBuilder(),
        new SecondLetterBuilder()
        );      

// execute the builder chain ("ab" is the source, res the destination)
executor.build("ab", res);

// use the result
...

That's it. And the nice part is, that this FirstLetterBuilder and SecondLetterBuilder can be reused anywhere or combined with any other builders.

Any comments on this will be more than welcome!

Thank you,
Tomas


From tjelinek at redhat.com  Fri Jan 25 12:32:20 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Fri, 25 Jan 2013 07:32:20 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <944488104.4879593.1358878592341.JavaMail.root@redhat.com>
Message-ID: <165967728.6579170.1359117140365.JavaMail.root@redhat.com>

Hi Laszlo,

it is not useful just for public clouds - it can be pretty useful for private as well. But to keep the previous way, it could be done this way:
- on the advanced screen (after clicking "show advanced options" you can specify the template)
- by default you pick on basic view the instance type (e.g. HW profile) and the Image (e.g. disk with some metadata such as OS type). But, you can select custom instance type (equivalent to  blank template) and no Image. In this case the template appears also on basic view and you can select it.

What do you think?

Tomas

----- Original Message -----
From: "Laszlo Hornyak" <lhornyak at redhat.com>
To: "Tomas Jelinek" <tjelinek at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Tuesday, January 22, 2013 7:16:32 PM
Subject: Re: [Engine-devel]  Instance Types Feature

Hi Tomas,

I like the idea in general, but for me the instance types looks like a feature that is typical in public clouds, while in private clouds it looks more like a cool extra feature for special cases. Therefore in my opinion it would be great to keep the old template solution as well to keep it simple for most users. A template could be an instance type and an image together. Only the description overlap, and that could be solved.

Thanks,
Laszlo

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, January 22, 2013 3:09:51 PM
> Subject: [Engine-devel]  Instance Types Feature
> 
> Hi All,
> 
> this is the proposed new feature called instance types:
> http://www.ovirt.org/Features/Instance_Types
> 
> Long story short - it should basically split the VM template into:
> - "hardware profile" called instance types
> - "software profile" called image
> 
> This should enable to do something like: Create a new "small" VM and
> attach a disk with "RHEL + Postgres" installed.
> 
> Any comments are more than welcome!
> 
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From eedri at redhat.com  Fri Jan 25 12:32:50 2013
From: eedri at redhat.com (Eyal Edri)
Date: Fri, 25 Jan 2013 07:32:50 -0500 (EST)
Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_unit_tests - Build
 # 3216 - Still unstable!
In-Reply-To: <1339447508.3219.1359107350456.JavaMail.jenkins@jenkins.ovirt.org>
Message-ID: <263448869.4479303.1359117170498.JavaMail.root@redhat.com>

fyi,

seems like this patch introduced new unit test failure, please check,

http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git&a=commit&h=207cda518399d0474154d5c3a9c363bcc43b6a72
http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/3212/


Eyal.
Infra team.

----- Original Message -----
> From: "Jenkins oVirt Server" <jenkins at ovirt.org>
> To: eedri at redhat.com, engine-patches at ovirt.org, oliel at redhat.com, yzaslavs at redhat.com
> Sent: Friday, January 25, 2013 11:49:10 AM
> Subject: [oVirt Jenkins] ovirt_engine_unit_tests - Build # 3216 - Still unstable!
> 
> Project: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/
> Build: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/3216/
> Build Number: 3216
> Build Status:  Still unstable
> Triggered By: Started by upstream project "ovirt_engine" build number
> 4,107, Started by upstream project "ovirt_engine" build number 4,109
> 
> -------------------------------------
> Changes Since Last Success:
> -------------------------------------
> Changes for Build #3212
> [gerrit2] engine: consolidate VM and Poll queries
> 
> 
> Changes for Build #3213
> [gerrit2] core:unlock_entity.sh is not finding a locked ...
> 
> [gerrit2] core:unlock_entity.sh is not unlocking the vm...
> 
> [emesika] core:If no power management configured or fails...
> 
> 
> Changes for Build #3214
> 
> Changes for Build #3215
> [gerrit2] packaging: Starting ssh before adding host in AIO
> 
> [gerrit2] packaging: Updated spec to use sdk version that supports
> ssl.
> 
> [gerrit2] spelling: s/mster/master/
> 
> 
> Changes for Build #3216
> 
> 
> 
> -----------------
> Failed Tests:
> -----------------
> 1 tests failed.
> FAILED:
>  org.ovirt.engine.core.bll.GetAllVmPoolsAttachedToUserQueryTest.testQueryIsAUserQuery
> 
> Error Message:
> A query tested for filtered access should not be an admin query
> 
> Stack Trace:
> java.lang.AssertionError: A query tested for filtered access should
> not be an admin query
> 	at org.junit.Assert.fail(Assert.java:93)
> 	at org.junit.Assert.assertTrue(Assert.java:43)
> 	at org.junit.Assert.assertFalse(Assert.java:68)
> 	at
> 	org.ovirt.engine.core.bll.AbstractUserQueryTest.testQueryIsAUserQuery(AbstractUserQueryTest.java:58)
> 	at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> 	at
> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at
> 	org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> 	at
> 	org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> 	at
> 	org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> 	at
> 	org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> 	at
> 	org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> 	at
> 	org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> 	at
> 	org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> 	at
> 	org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> 	at
> 	org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> 	at
> 	org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at
> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at
> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at
> 	org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> 	at
> 	org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> 	at
> 	org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> 	at
> 	org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> 	at
> 	org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
> 
> 
>  
> 
> ------------------
> Build Log:
> ------------------
> [...truncated 6074 lines...]
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/maven-artifact-manager/2.0.8/maven-artifact-manager-2.0.8.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/maven-artifact-manager/2.0.8/maven-artifact-manager-2.0.8.pom
> (3 KB at 164.8 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/maven-repository-metadata/2.0.8/maven-repository-metadata-2.0.8.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/maven-repository-metadata/2.0.8/maven-repository-metadata-2.0.8.pom
> (2 KB at 142.8 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/maven-plugin-registry/2.0.8/maven-plugin-registry-2.0.8.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/maven-plugin-registry/2.0.8/maven-plugin-registry-2.0.8.pom
> (2 KB at 57.4 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.0/maven-common-artifact-filters-1.0.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.0/maven-common-artifact-filters-1.0.pom
> (2 KB at 164.0 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.pom
> (2 KB at 164.0 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting/2.0.4/maven-reporting-2.0.4.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting/2.0.4/maven-reporting-2.0.4.pom
> (700 B at 25.3 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-core/1.0-alpha-7/doxia-core-1.0-alpha-7.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-core/1.0-alpha-7/doxia-core-1.0-alpha-7.pom
> (2 KB at 109.7 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/oro/oro/2.0.7/oro-2.0.7.pom
> Downloaded: http://repo1.maven.org/maven2/oro/oro/2.0.7/oro-2.0.7.pom
> (141 B at 9.8 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-api/2.0.4/maven-reporting-api-2.0.4.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-api/2.0.4/maven-reporting-api-2.0.4.pom
> (902 B at 80.1 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-7/doxia-site-renderer-1.0-alpha-7.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-7/doxia-site-renderer-1.0-alpha-7.pom
> (2 KB at 127.6 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.pom
> (8 KB at 570.5 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-7/plexus-container-default-1.0-alpha-7.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-7/plexus-container-default-1.0-alpha-7.pom
> (2 KB at 104.9 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/plexus/plexus-containers/1.0.2/plexus-containers-1.0.2.pom
> Downloaded:
> http://repo1.maven.org/maven2/plexus/plexus-containers/1.0.2/plexus-containers-1.0.2.pom
> (471 B at 38.3 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/plexus/plexus-root/1.0.3/plexus-root-1.0.3.pom
> Downloaded:
> http://repo1.maven.org/maven2/plexus/plexus-root/1.0.3/plexus-root-1.0.3.pom
> (6 KB at 489.8 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/plexus/plexus-utils/1.0.2/plexus-utils-1.0.2.pom
> Downloaded:
> http://repo1.maven.org/maven2/plexus/plexus-utils/1.0.2/plexus-utils-1.0.2.pom
> (740 B at 60.2 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.pom
> Downloaded:
> http://repo1.maven.org/maven2/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.pom
> (168 B at 13.7 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/velocity/velocity/1.4/velocity-1.4.pom
> Downloaded:
> http://repo1.maven.org/maven2/velocity/velocity/1.4/velocity-1.4.pom
> (3 KB at 174.3 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/velocity/velocity-dep/1.4/velocity-dep-1.4.pom
> Downloaded:
> http://repo1.maven.org/maven2/velocity/velocity-dep/1.4/velocity-dep-1.4.pom
> (2 KB at 154.3 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-7/doxia-decoration-model-1.0-alpha-7.pom
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-7/doxia-decoration-model-1.0-alpha-7.pom
> (2 KB at 99.0 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.4.6/plexus-utils-1.4.6.jar
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/shared/maven-shared-io/1.0/maven-shared-io-1.0.jar
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/shared/maven-dependency-analyzer/1.1/maven-dependency-analyzer-1.1.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.4.6/plexus-utils-1.4.6.jar
> (200 KB at 6431.1 KB/sec)
> Downloading: http://repo1.maven.org/maven2/asm/asm/3.0/asm-3.0.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/shared/maven-shared-io/1.0/maven-shared-io-1.0.jar
> (33 KB at 1052.7 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.0/maven-common-artifact-filters-1.0.jar
> Downloaded: http://repo1.maven.org/maven2/asm/asm/3.0/asm-3.0.jar (42
> KB at 2085.4 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.jar
> Downloading:
> http://repo1.maven.org/maven2/commons-collections/commons-collections/2.1/commons-collections-2.1.jar
> Downloading:
> http://repo1.maven.org/maven2/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.0/maven-common-artifact-filters-1.0.jar
> (27 KB at 1565.7 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-core/1.0-alpha-7/doxia-core-1.0-alpha-7.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.jar
> (14 KB at 833.5 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/oro/oro/2.0.7/oro-2.0.7.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/shared/maven-dependency-analyzer/1.1/maven-dependency-analyzer-1.1.jar
> (27 KB at 400.2 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-7/doxia-site-renderer-1.0-alpha-7.jar
> Downloaded: http://repo1.maven.org/maven2/oro/oro/2.0.7/oro-2.0.7.jar
> (64 KB at 1936.1 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-core/1.0-alpha-7/doxia-core-1.0-alpha-7.jar
> (226 KB at 6274.1 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/plexus/plexus-utils/1.0.2/plexus-utils-1.0.2.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-7/doxia-site-renderer-1.0-alpha-7.jar
> (13 KB at 538.3 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar
> Downloaded:
> http://repo1.maven.org/maven2/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
> (38 KB at 675.0 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/velocity/velocity/1.4/velocity-1.4.jar
> Downloaded:
> http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.jar
> (8 KB at 222.3 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/velocity/velocity-dep/1.4/velocity-dep-1.4.jar
> Downloaded:
> http://repo1.maven.org/maven2/plexus/plexus-utils/1.0.2/plexus-utils-1.0.2.jar
> (157 KB at 3915.6 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-7/doxia-decoration-model-1.0-alpha-7.jar
> Downloaded:
> http://repo1.maven.org/maven2/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar
> (26 KB at 673.4 KB/sec)
> Downloaded:
> http://repo1.maven.org/maven2/commons-collections/commons-collections/2.1/commons-collections-2.1.jar
> (162 KB at 1645.4 KB/sec)
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-7/doxia-decoration-model-1.0-alpha-7.jar
> (38 KB at 2193.0 KB/sec)
> Downloaded:
> http://repo1.maven.org/maven2/velocity/velocity/1.4/velocity-1.4.jar
> (353 KB at 4898.7 KB/sec)
> Downloaded:
> http://repo1.maven.org/maven2/velocity/velocity-dep/1.4/velocity-dep-1.4.jar
> (506 KB at 10758.0 KB/sec)
> [INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar
> [INFO] Copying quartz-2.1.2.jar to
> /home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/quartz/quartz-2.1.2.jar
> mojoSucceeded
> org.apache.maven.plugins:maven-dependency-plugin:2.1(copy-quartz-jar)
> [INFO] Installing
> /home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/engine.ear
> to
> /home/jenkins/workspace/ovirt_engine_unit_tests/.repository/org/ovirt/engine/engine-server-ear/3.2.0/engine-server-ear-3.2.0.ear
> mojoStarted
> org.apache.maven.plugins:maven-install-plugin:2.3.1(default-install)
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> engine-server-ear ---
> [INFO] Installing
> /home/jenkins/workspace/ovirt_engine_unit_tests/ear/pom.xml to
> /home/jenkins/workspace/ovirt_engine_unit_tests/.repository/org/ovirt/engine/engine-server-ear/3.2.0/engine-server-ear-3.2.0.pom
> mojoSucceeded
> org.apache.maven.plugins:maven-install-plugin:2.3.1(default-install)
> projectSucceeded org.ovirt.engine:engine-server-ear:3.2.0
> sessionEnded
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] ovirt-root ........................................ SUCCESS
> [8.538s]
> [INFO] oVirt Build Tools root ............................ SUCCESS
> [0.238s]
> [INFO] oVirt checkstyle .................................. SUCCESS
> [6.895s]
> [INFO] oVirt Checkstyle Checks ........................... SUCCESS
> [2.763s]
> [INFO] oVirt Modules - backend ........................... SUCCESS
> [0.246s]
> [INFO] oVirt Manager ..................................... SUCCESS
> [0.234s]
> [INFO] oVirt DB Scripts .................................. SUCCESS
> [0.950s]
> [INFO] oVirt Modules - manager ........................... SUCCESS
> [6.026s]
> [INFO] CSharp Compatibility .............................. SUCCESS
> [14.711s]
> [INFO] Encryption Libraries .............................. SUCCESS
> [5.150s]
> [INFO] oVirt Tools ....................................... SUCCESS
> [0.619s]
> [INFO] oVirt Tools Common Library ........................ SUCCESS
> [4.614s]
> [INFO] Common Code ....................................... SUCCESS
> [28.455s]
> [INFO] Common utilities .................................. SUCCESS
> [32.168s]
> [INFO] Data Access Layer ................................. SUCCESS
> [30.996s]
> [INFO] engine beans ...................................... SUCCESS
> [0.304s]
> [INFO] engine scheduler bean ............................. SUCCESS
> [5.388s]
> [INFO] Vds broker ........................................ SUCCESS
> [14.906s]
> [INFO] Search Backend .................................... SUCCESS
> [8.260s]
> [INFO] Backend Logic @Service bean ....................... SUCCESS
> [1:16.188s]
> [INFO] oVirt RESTful API Backend Integration ............. SUCCESS
> [8.478s]
> [INFO] oVirt RESTful API interface ....................... SUCCESS
> [0.334s]
> [INFO] oVirt Engine API Definition ....................... SUCCESS
> [25.865s]
> [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS
> [0.311s]
> [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS
> [17.147s]
> [INFO] oVirt RESTful API Backend Integration Type Mappers  SUCCESS
> [51.144s]
> [INFO] oVirt RESTful API Backend Integration JAX-RS Resources
>  SUCCESS [54.674s]
> [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS
> [2.285s]
> [INFO] oVirt Engine Web Root ............................. SUCCESS
> [2.731s]
> [INFO] oVirt Configuration Tool .......................... SUCCESS
> [3.816s]
> [INFO] Notifier Service package .......................... SUCCESS
> [0.171s]
> [INFO] Notifier Service .................................. SUCCESS
> [4.180s]
> [INFO] Notifier Service Resources ........................ SUCCESS
> [2.233s]
> [INFO] oVirt Modules :: Frontend ......................... SUCCESS
> [0.182s]
> [INFO] oVirt Modules :: Webadmin ......................... SUCCESS
> [0.187s]
> [INFO] oVirt Modules - ui ................................ SUCCESS
> [0.185s]
> [INFO] Extensions for GWT ................................ SUCCESS
> [4.740s]
> [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS
> [6.985s]
> [INFO] Frontend for GWT UI Projects ...................... SUCCESS
> [6.357s]
> [INFO] UICommonWeb ....................................... SUCCESS
> [27.230s]
> [INFO] oVirt GWT UI common infrastructure ................ SUCCESS
> [33.023s]
> [INFO] WebAdmin .......................................... SUCCESS
> [28.203s]
> [INFO] UserPortal ........................................ SUCCESS
> [12.630s]
> [INFO] oVirt WARs ........................................ SUCCESS
> [0.165s]
> [INFO] oVirt Web Application Module ...................... SUCCESS
> [2.619s]
> [INFO] oVirt Server EAR .................................. SUCCESS
> [8.673s]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 9:19.320s
> [INFO] Finished at: Fri Jan 25 04:49:19 EST 2013
> [INFO] Final Memory: 319M/676M
> [INFO]
> ------------------------------------------------------------------------
> Projects to build: [MavenProject: org.ovirt.engine:root:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/pom.xml,
> MavenProject: org.ovirt.engine:build-tools-root:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/pom.xml,
> MavenProject: org.ovirt.engine:checkstyles:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/checkstyles/pom.xml,
> MavenProject: org.ovirt.engine:ovirt-checkstyle-extension:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/ovirt-checkstyle-extension/pom.xml,
> MavenProject: org.ovirt.engine.core:backend:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/pom.xml,
> MavenProject: org.ovirt.engine.core:manager:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/pom.xml,
> MavenProject: org.ovirt.engine.core:dbscripts:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/dbscripts/pom.xml,
> MavenProject: org.ovirt.engine.core:manager-modules:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/pom.xml,
> MavenProject: org.ovirt.engine.core:compat:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/pom.xml,
> MavenProject: org.ovirt.engine.core:engineencryptutils:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/engineencryptutils/pom.xml,
> MavenProject: org.ovirt.engine.core:manager-tools:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/pom.xml,
> MavenProject: org.ovirt.engine.core:engine-tools-common:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-tools-common/pom.xml,
> MavenProject: org.ovirt.engine.core:common:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/pom.xml,
> MavenProject: org.ovirt.engine.core:utils:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/utils/pom.xml,
> MavenProject: org.ovirt.engine.core:dal:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/dal/pom.xml,
> MavenProject: org.ovirt.engine.core:beans:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/pom.xml,
> MavenProject: org.ovirt.engine.core:scheduler:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/scheduler/pom.xml,
> MavenProject: org.ovirt.engine.core:vdsbroker:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/vdsbroker/pom.xml,
> MavenProject: org.ovirt.engine.core:searchbackend:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/pom.xml,
> MavenProject: org.ovirt.engine.core:bll:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/bll/pom.xml,
> MavenProject: org.ovirt.engine.api:restapi-parent:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/pom.xml,
> MavenProject: org.ovirt.engine.api:interface:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/pom.xml,
> MavenProject: org.ovirt.engine.api:restapi-definition:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/definition/pom.xml,
> MavenProject: org.ovirt.engine.api:common-parent:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/pom.xml,
> MavenProject: org.ovirt.engine.api:interface-common-jaxrs:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/jaxrs/pom.xml,
> MavenProject: org.ovirt.engine.api:restapi-types:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/types/pom.xml,
> MavenProject: org.ovirt.engine.api:restapi-jaxrs:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/jaxrs/pom.xml,
> MavenProject: org.ovirt.engine.api:restapi-webapp:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/webapp/pom.xml,
> MavenProject: org.ovirt.engine.core:root-war:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/root/pom.xml,
> MavenProject: org.ovirt.engine.core:engine-config:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-config/pom.xml,
> MavenProject: org.ovirt.engine.core:engine-notifier:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/pom.xml,
> MavenProject: org.ovirt.engine.core:engine-notifier-service:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-service/pom.xml,
> MavenProject: org.ovirt.engine.core:engine-notifier-resources:3.2.0
> @
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-resources/pom.xml,
> MavenProject: org.ovirt.engine.ui:frontend-all:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/pom.xml,
> MavenProject: org.ovirt.engine.ui:webadmin-all:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/pom.xml,
> MavenProject: org.ovirt.engine.ui:webadmin-modules:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/pom.xml,
> MavenProject: org.ovirt.engine.ui:gwt-extension:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/pom.xml,
> MavenProject: org.ovirt.engine.ui:uicompat:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicompat/pom.xml,
> MavenProject: org.ovirt.engine.ui:frontend:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/frontend/pom.xml,
> MavenProject: org.ovirt.engine.ui:uicommonweb:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/pom.xml,
> MavenProject: org.ovirt.engine.ui:gwt-common:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-common/pom.xml,
> MavenProject: org.ovirt.engine.ui:webadmin:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/webadmin/pom.xml,
> MavenProject: org.ovirt.engine.ui:userportal:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/userportal-gwtp/pom.xml,
> MavenProject: org.ovirt.engine.ui:wars:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/pom.xml,
> MavenProject: org.ovirt.engine.ui:rmw-war:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/rmw-war/pom.xml,
> MavenProject: org.ovirt.engine:engine-server-ear:3.2.0 @
> /home/jenkins/workspace/ovirt_engine_unit_tests/ear/pom.xml]
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0-sources.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/root/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/root/target/root-war-3.2.0.war
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/webapp/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/webapp/target/restapi-webapp-3.2.0.war
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-tools-common/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-tools-common/target/engine-tools-common-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-tools-common/target/engine-tools-common-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/target/common-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/target/common-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/target/common-3.2.0-sources.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-common/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-common/target/gwt-common-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-common/target/gwt-common-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/checkstyles/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/checkstyles/target/checkstyles-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/checkstyles/target/checkstyles-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/scheduler/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/scheduler/target/scheduler-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/scheduler/target/scheduler-3.2.0-client.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-resources/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-resources/target/engine-notifier-resources-3.2.0.zip
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-config/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-config/target/engine-config-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-config/target/engine-config-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/engineencryptutils/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/engineencryptutils/target/engineencryptutils-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/engineencryptutils/target/engineencryptutils-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-service/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-service/target/engine-notifier-service-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-service/target/engine-notifier-service-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/utils/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/utils/target/utils-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/utils/target/utils-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/definition/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/definition/target/restapi-definition-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/definition/target/restapi-definition-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/types/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/types/target/restapi-types-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/types/target/restapi-types-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicompat/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicompat/target/uicompat-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicompat/target/uicompat-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/ovirt-checkstyle-extension/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/ovirt-checkstyle-extension/target/ovirt-checkstyle-extension-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/ovirt-checkstyle-extension/target/ovirt-checkstyle-extension-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/jaxrs/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/jaxrs/target/restapi-jaxrs-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/jaxrs/target/restapi-jaxrs-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/frontend/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/frontend/target/frontend-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/frontend/target/frontend-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/rmw-war/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/rmw-war/target/rmw-war-3.2.0.war
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/dal/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/dal/target/dal-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/dal/target/dal-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/ear/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/engine.ear
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/webadmin/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/webadmin/target/webadmin-3.2.0.war
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/target/searchbackend-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/target/searchbackend-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/target/searchbackend-3.2.0-sources.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0-sources.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/target/compat-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/target/compat-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/target/compat-3.2.0-sources.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/jaxrs/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/jaxrs/target/interface-common-jaxrs-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/jaxrs/target/interface-common-jaxrs-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/userportal-gwtp/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.2.0.war
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/vdsbroker/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/vdsbroker/target/vdsbroker-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/vdsbroker/target/vdsbroker-3.2.0-tests.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/bll/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/bll/target/bll-3.2.0.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/bll/target/bll-3.2.0-client.jar
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/dbscripts/pom.xml
> Waiting for Jenkins to finish collecting data
> channel stopped
> IRC notifier plugin: Sending notification to: #ovirt-jenkins
> Email was triggered for: Unstable
> Sending email for trigger: Unstable
> 


From iheim at redhat.com  Fri Jan 25 16:34:27 2013
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 25 Jan 2013 08:34:27 -0800
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <1570564188.5808831.1359037197536.JavaMail.root@redhat.com>
References: <1570564188.5808831.1359037197536.JavaMail.root@redhat.com>
Message-ID: <5102B413.4050100@redhat.com>

On 24/01/2013 06:19, Laszlo Hornyak wrote:
> Hi,
>
> Watchdog support in engine will add watchdog to the ovirt UI and REST API. Watchdog cards will be mainly used in HA vm's.
>
> http://www.ovirt.org/Features/Watchdog_engine_support
>
> Your feedback is welcome!
>
> Thank you,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

looks like a nice, simple, addition.
dave, anyone more intimate with the watchdog worth giving another look?


From dfediuck at redhat.com  Sat Jan 26 12:08:03 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sat, 26 Jan 2013 07:08:03 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <51015924.4010803@redhat.com>
Message-ID: <517901966.11666513.1359202083889.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Yaniv Kaul" <ykaul at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, January 24, 2013 5:54:12 PM
> Subject: Re: [Engine-devel] Watchdog support Feature
> 
> On 24/01/2013 07:55, Yaniv Kaul wrote:
> > Are all watchdogs available to all operating systems?
> 
> ask libosinfo :)


Ric' Jones has a known post about it[1].
If you look into it[2], you can see a few Linux distro's are supported (Red Hat,
Debian & Suse) plus I was able to get it in Fedora's default repo.
For Microsoft OS's you may download drivers from Intel's web site.

[1] http://rwmj.wordpress.com/2010/03/03/what-is-a-watchdog/#comment-4959
[2] http://watchdog.git.sourceforge.net/git/gitweb.cgi?p=watchdog/watchdog;a=tree


From emesika at redhat.com  Sat Jan 26 20:58:57 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sat, 26 Jan 2013 15:58:57 -0500 (EST)
Subject: [Engine-devel] [engine-devel] frontend builders proposal
In-Reply-To: <890129319.6505852.1359107743604.JavaMail.root@redhat.com>
Message-ID: <231822069.11211316.1359233937038.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Friday, January 25, 2013 11:55:43 AM
> Subject: [Engine-devel] [engine-devel] frontend builders proposal
> 
> Hi All,
> 
> as many of you may know, the way how the frontend and backend models
> are built on frontend (uicommonweb project) is not really ideal.
> Currently this logic is copy pasted over and over again to different
> places where it is needed with minor changes to fulfill the specific
> requirements. It is not only aesthetically problematic, but I recall
> tons of bugs caused by introducing a new field and forgetting to add
> it to every place it is used in GUI.
> 
> Now, as there will be big changes in the VM/Template models
> (http://www.ovirt.org/Features/Instance_Types), so the way how the
> VM, Template, Pool and also the newly created Instance Types models
> are being built has to be touched anyhow, it is a great opportunity
> to rethink the way how we do it.
> 
> I have created a simple infrastructure
> (http://gerrit.ovirt.org/#/c/10874/) which could be used for it, and
> a PoC patch which uses this infrastructure
> (http://gerrit.ovirt.org/#/c/11354/). Please note that the PoC is
> not really impressive in means of removing duplications, I wanted to
> start with the simplest possibility.
> 
> The principles behind the infrastructure:
> - have small, well named, easy to understand and reuse builders
> - this builders can be chained together or embedded to each other to
> build the full resulting object (composite pattern)
> - this builders can be asynchronous, and the next builder in the
> chain has to be executed only when the current is completely done
> 
> The structure:
> - the base is an interface called Builder which has a method
> build(source, destination, rest)
> - the builder implementing this interface
>   + will get the source and destination objects
>   + copies whatever he wants from source to destination
>   + when done, executes build on the first element of the rest
>     + this may sound awkward, but this is the way how the async calls
>     can be "linearized" in a general way, not embedding anonymous
>     class into anonymous
>       class into anonymous class... as we do it today.
>     + for synchronous builders, there is a BaseSyncBuilder which
>     takes care of this boilerplate calling of next and exposes a
>     simple method
>       build(S source, D destination)
>   + to simplify the creating and running the chain of builders, there
>   is a BuilderExecutor class (can be created as sync or async)
> 
> So, a simple example - even more simple than the PoC patch :)
> 
> //create the first builder
> class FirstLetterBuilder extends BaseSyncBuilder<String,
> StringBuilder> {
>  @Override
>  protected void build(String source, StringBuilder destination) {
>      // copy the first letter to the destination
>      destination.append(source.charAt(0));
>  }
> }
> 
> //create the second builder
> class SecondLetterBuilder extends BaseSyncBuilder<String,
> StringBuilder> {
>  @Override
>  protected void build(String source, StringBuilder destination) {
>      // copy the second letter to the destination
>      destination.append(source.charAt(1));
>  }
> }
> 
> // usage
> ...
> // create the destination object
> StringBuilder res = new StringBuilder();
> 
> // configure the executor with the two builders
> BuilderExecutor<String, StringBuilder> executor = new
> BuilderExecutor<String, StringBuilder>(
>         new FirstLetterBuilder(),
>         new SecondLetterBuilder()
>         );
> 
> // execute the builder chain ("ab" is the source, res the
> destination)
> executor.build("ab", res);
> 
> // use the result
> ...
> 
> That's it. And the nice part is, that this FirstLetterBuilder and
> SecondLetterBuilder can be reused anywhere or combined with any
> other builders.
> 
> Any comments on this will be more than welcome!

great and really simplifies work and eliminate bugs resulted from copy/past code
gave +1 
Thanks
Eli
> 
> Thank you,
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mpastern at redhat.com  Sun Jan 27 07:27:54 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 27 Jan 2013 09:27:54 +0200
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <1570564188.5808831.1359037197536.JavaMail.root@redhat.com>
References: <1570564188.5808831.1359037197536.JavaMail.root@redhat.com>
Message-ID: <5104D6FA.1090005@redhat.com>

On 01/24/2013 04:19 PM, Laszlo Hornyak wrote:
> Hi,
> 
> Watchdog support in engine will add watchdog to the ovirt UI and REST API. Watchdog cards will be mainly used in HA vm's.
> 
> http://www.ovirt.org/Features/Watchdog_engine_support
> 
> Your feedback is welcome!
> 
> Thank you,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

Definitely nice feature, but i have a question for [1],
won't it cause slow responsive guests (on highly loaded hosts)
to constantly reboot?

i.e it's understood that 'reboot' is a goal of this feature,
but endless reboot of pinned-to-host guests for instance
won't do any good right?,

my point is: should watchdog 'action' have extra logic
for guest-policy like placement for instance?

[1] <watchdog model="i6300esb" action="reset"/>

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From ahadas at redhat.com  Sun Jan 27 08:19:33 2013
From: ahadas at redhat.com (Arik Hadas)
Date: Sun, 27 Jan 2013 03:19:33 -0500 (EST)
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <5101537F.9020706@redhat.com>
Message-ID: <853695569.6734728.1359274773637.JavaMail.root@redhat.com>

> Changing the name of the virtual machines, created from
>     a pool through web-admin-portal
User can now change the auto-generated name of a virtual machine
that was created from a pool through the 'edit' dialogue of the vm.


From dfediuck at redhat.com  Sun Jan 27 08:28:35 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 27 Jan 2013 03:28:35 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <5104D6FA.1090005@redhat.com>
Message-ID: <1581491581.11763957.1359275315692.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, January 27, 2013 9:27:54 AM
> Subject: Re: [Engine-devel] Watchdog support Feature
> 
> On 01/24/2013 04:19 PM, Laszlo Hornyak wrote:
> > Hi,
> > 
> > Watchdog support in engine will add watchdog to the ovirt UI and
> > REST API. Watchdog cards will be mainly used in HA vm's.
> > 
> > http://www.ovirt.org/Features/Watchdog_engine_support
> > 
> > Your feedback is welcome!
> > 
> > Thank you,
> > Laszlo
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> Definitely nice feature, but i have a question for [1],
> won't it cause slow responsive guests (on highly loaded hosts)
> to constantly reboot?
> 
> i.e it's understood that 'reboot' is a goal of this feature,
> but endless reboot of pinned-to-host guests for instance
> won't do any good right?,
> 
> my point is: should watchdog 'action' have extra logic
> for guest-policy like placement for instance?
> 
> [1] <watchdog model="i6300esb" action="reset"/>
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D

Michael, good question.
The device itself will not be added by default,
and there are a few other actions which can be used (default action is none).
So this will be in use only by someone who expects it to reboot.
Additionally the watchdog is configurable to fire according to the internal
drivers settings, so softdog may be configured to trigger the watchdog by
several indicators and not only cpu load / time.


From amureini at redhat.com  Sun Jan 27 09:27:44 2013
From: amureini at redhat.com (Allon Mureinik)
Date: Sun, 27 Jan 2013 04:27:44 -0500 (EST)
Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_unit_tests - Build
 # 3216 - Still unstable!
In-Reply-To: <263448869.4479303.1359117170498.JavaMail.root@redhat.com>
Message-ID: <374892625.4944518.1359278864520.JavaMail.root@redhat.com>

Fixed in http://gerrit.ovirt.org/#/c/11413/.

----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, January 25, 2013 2:32:50 PM
> Subject: Re: [Engine-devel] [oVirt Jenkins] ovirt_engine_unit_tests - Build # 3216 - Still unstable!
> 
> fyi,
> 
> seems like this patch introduced new unit test failure, please check,
> 
> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git&a=commit&h=207cda518399d0474154d5c3a9c363bcc43b6a72
> http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/3212/
> 
> 
> Eyal.
> Infra team.
> 
> ----- Original Message -----
> > From: "Jenkins oVirt Server" <jenkins at ovirt.org>
> > To: eedri at redhat.com, engine-patches at ovirt.org, oliel at redhat.com,
> > yzaslavs at redhat.com
> > Sent: Friday, January 25, 2013 11:49:10 AM
> > Subject: [oVirt Jenkins] ovirt_engine_unit_tests - Build # 3216 -
> > Still unstable!
> > 
> > Project: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/
> > Build: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/3216/
> > Build Number: 3216
> > Build Status:  Still unstable
> > Triggered By: Started by upstream project "ovirt_engine" build
> > number
> > 4,107, Started by upstream project "ovirt_engine" build number
> > 4,109
> > 
> > -------------------------------------
> > Changes Since Last Success:
> > -------------------------------------
> > Changes for Build #3212
> > [gerrit2] engine: consolidate VM and Poll queries
> > 
> > 
> > Changes for Build #3213
> > [gerrit2] core:unlock_entity.sh is not finding a locked ...
> > 
> > [gerrit2] core:unlock_entity.sh is not unlocking the vm...
> > 
> > [emesika] core:If no power management configured or fails...
> > 
> > 
> > Changes for Build #3214
> > 
> > Changes for Build #3215
> > [gerrit2] packaging: Starting ssh before adding host in AIO
> > 
> > [gerrit2] packaging: Updated spec to use sdk version that supports
> > ssl.
> > 
> > [gerrit2] spelling: s/mster/master/
> > 
> > 
> > Changes for Build #3216
> > 
> > 
> > 
> > -----------------
> > Failed Tests:
> > -----------------
> > 1 tests failed.
> > FAILED:
> >  org.ovirt.engine.core.bll.GetAllVmPoolsAttachedToUserQueryTest.testQueryIsAUserQuery
> > 
> > Error Message:
> > A query tested for filtered access should not be an admin query
> > 
> > Stack Trace:
> > java.lang.AssertionError: A query tested for filtered access should
> > not be an admin query
> > 	at org.junit.Assert.fail(Assert.java:93)
> > 	at org.junit.Assert.assertTrue(Assert.java:43)
> > 	at org.junit.Assert.assertFalse(Assert.java:68)
> > 	at
> > 	org.ovirt.engine.core.bll.AbstractUserQueryTest.testQueryIsAUserQuery(AbstractUserQueryTest.java:58)
> > 	at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> > 	at
> > 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > 	at java.lang.reflect.Method.invoke(Method.java:601)
> > 	at
> > 	org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> > 	at
> > 	org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> > 	at
> > 	org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> > 	at
> > 	org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> > 	at
> > 	org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> > 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> > 	at
> > 	org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> > 	at
> > 	org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> > 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> > 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> > 	at
> > 	org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> > 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> > 	at
> > 	org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> > 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> > 	at
> > 	org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> > 	at
> > 	org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> > 	at
> > 	org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> > 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > 	at
> > 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > 	at
> > 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > 	at java.lang.reflect.Method.invoke(Method.java:601)
> > 	at
> > 	org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> > 	at
> > 	org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> > 	at
> > 	org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> > 	at
> > 	org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> > 	at
> > 	org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
> > 
> > 
> >  
> > 
> > ------------------
> > Build Log:
> > ------------------
> > [...truncated 6074 lines...]
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/maven-artifact-manager/2.0.8/maven-artifact-manager-2.0.8.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/maven-artifact-manager/2.0.8/maven-artifact-manager-2.0.8.pom
> > (3 KB at 164.8 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/maven-repository-metadata/2.0.8/maven-repository-metadata-2.0.8.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/maven-repository-metadata/2.0.8/maven-repository-metadata-2.0.8.pom
> > (2 KB at 142.8 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/maven-plugin-registry/2.0.8/maven-plugin-registry-2.0.8.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/maven-plugin-registry/2.0.8/maven-plugin-registry-2.0.8.pom
> > (2 KB at 57.4 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.0/maven-common-artifact-filters-1.0.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.0/maven-common-artifact-filters-1.0.pom
> > (2 KB at 164.0 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.pom
> > (2 KB at 164.0 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting/2.0.4/maven-reporting-2.0.4.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting/2.0.4/maven-reporting-2.0.4.pom
> > (700 B at 25.3 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-core/1.0-alpha-7/doxia-core-1.0-alpha-7.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-core/1.0-alpha-7/doxia-core-1.0-alpha-7.pom
> > (2 KB at 109.7 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/oro/oro/2.0.7/oro-2.0.7.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/oro/oro/2.0.7/oro-2.0.7.pom
> > (141 B at 9.8 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-api/2.0.4/maven-reporting-api-2.0.4.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-api/2.0.4/maven-reporting-api-2.0.4.pom
> > (902 B at 80.1 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-7/doxia-site-renderer-1.0-alpha-7.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-7/doxia-site-renderer-1.0-alpha-7.pom
> > (2 KB at 127.6 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.pom
> > (8 KB at 570.5 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-7/plexus-container-default-1.0-alpha-7.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-7/plexus-container-default-1.0-alpha-7.pom
> > (2 KB at 104.9 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/plexus/plexus-containers/1.0.2/plexus-containers-1.0.2.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/plexus/plexus-containers/1.0.2/plexus-containers-1.0.2.pom
> > (471 B at 38.3 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/plexus/plexus-root/1.0.3/plexus-root-1.0.3.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/plexus/plexus-root/1.0.3/plexus-root-1.0.3.pom
> > (6 KB at 489.8 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/plexus/plexus-utils/1.0.2/plexus-utils-1.0.2.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/plexus/plexus-utils/1.0.2/plexus-utils-1.0.2.pom
> > (740 B at 60.2 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.pom
> > (168 B at 13.7 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/velocity/velocity/1.4/velocity-1.4.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/velocity/velocity/1.4/velocity-1.4.pom
> > (3 KB at 174.3 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/velocity/velocity-dep/1.4/velocity-dep-1.4.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/velocity/velocity-dep/1.4/velocity-dep-1.4.pom
> > (2 KB at 154.3 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-7/doxia-decoration-model-1.0-alpha-7.pom
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-7/doxia-decoration-model-1.0-alpha-7.pom
> > (2 KB at 99.0 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.4.6/plexus-utils-1.4.6.jar
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/shared/maven-shared-io/1.0/maven-shared-io-1.0.jar
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/shared/maven-dependency-analyzer/1.1/maven-dependency-analyzer-1.1.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.4.6/plexus-utils-1.4.6.jar
> > (200 KB at 6431.1 KB/sec)
> > Downloading: http://repo1.maven.org/maven2/asm/asm/3.0/asm-3.0.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/shared/maven-shared-io/1.0/maven-shared-io-1.0.jar
> > (33 KB at 1052.7 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.0/maven-common-artifact-filters-1.0.jar
> > Downloaded: http://repo1.maven.org/maven2/asm/asm/3.0/asm-3.0.jar
> > (42
> > KB at 2085.4 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.jar
> > Downloading:
> > http://repo1.maven.org/maven2/commons-collections/commons-collections/2.1/commons-collections-2.1.jar
> > Downloading:
> > http://repo1.maven.org/maven2/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.0/maven-common-artifact-filters-1.0.jar
> > (27 KB at 1565.7 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-core/1.0-alpha-7/doxia-core-1.0-alpha-7.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.jar
> > (14 KB at 833.5 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/oro/oro/2.0.7/oro-2.0.7.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/shared/maven-dependency-analyzer/1.1/maven-dependency-analyzer-1.1.jar
> > (27 KB at 400.2 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-7/doxia-site-renderer-1.0-alpha-7.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/oro/oro/2.0.7/oro-2.0.7.jar
> > (64 KB at 1936.1 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-core/1.0-alpha-7/doxia-core-1.0-alpha-7.jar
> > (226 KB at 6274.1 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/plexus/plexus-utils/1.0.2/plexus-utils-1.0.2.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-site-renderer/1.0-alpha-7/doxia-site-renderer-1.0-alpha-7.jar
> > (13 KB at 538.3 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
> > (38 KB at 675.0 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/velocity/velocity/1.4/velocity-1.4.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-velocity/1.1.2/plexus-velocity-1.1.2.jar
> > (8 KB at 222.3 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/velocity/velocity-dep/1.4/velocity-dep-1.4.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/plexus/plexus-utils/1.0.2/plexus-utils-1.0.2.jar
> > (157 KB at 3915.6 KB/sec)
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-7/doxia-decoration-model-1.0-alpha-7.jar
> > Downloaded:
> > http://repo1.maven.org/maven2/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar
> > (26 KB at 673.4 KB/sec)
> > Downloaded:
> > http://repo1.maven.org/maven2/commons-collections/commons-collections/2.1/commons-collections-2.1.jar
> > (162 KB at 1645.4 KB/sec)
> > Downloaded:
> > http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-7/doxia-decoration-model-1.0-alpha-7.jar
> > (38 KB at 2193.0 KB/sec)
> > Downloaded:
> > http://repo1.maven.org/maven2/velocity/velocity/1.4/velocity-1.4.jar
> > (353 KB at 4898.7 KB/sec)
> > Downloaded:
> > http://repo1.maven.org/maven2/velocity/velocity-dep/1.4/velocity-dep-1.4.jar
> > (506 KB at 10758.0 KB/sec)
> > [INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar
> > [INFO] Copying quartz-2.1.2.jar to
> > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/quartz/quartz-2.1.2.jar
> > mojoSucceeded
> > org.apache.maven.plugins:maven-dependency-plugin:2.1(copy-quartz-jar)
> > [INFO] Installing
> > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/engine.ear
> > to
> > /home/jenkins/workspace/ovirt_engine_unit_tests/.repository/org/ovirt/engine/engine-server-ear/3.2.0/engine-server-ear-3.2.0.ear
> > mojoStarted
> > org.apache.maven.plugins:maven-install-plugin:2.3.1(default-install)
> > [INFO]
> > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> > engine-server-ear ---
> > [INFO] Installing
> > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/pom.xml to
> > /home/jenkins/workspace/ovirt_engine_unit_tests/.repository/org/ovirt/engine/engine-server-ear/3.2.0/engine-server-ear-3.2.0.pom
> > mojoSucceeded
> > org.apache.maven.plugins:maven-install-plugin:2.3.1(default-install)
> > projectSucceeded org.ovirt.engine:engine-server-ear:3.2.0
> > sessionEnded
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Reactor Summary:
> > [INFO]
> > [INFO] ovirt-root ........................................ SUCCESS
> > [8.538s]
> > [INFO] oVirt Build Tools root ............................ SUCCESS
> > [0.238s]
> > [INFO] oVirt checkstyle .................................. SUCCESS
> > [6.895s]
> > [INFO] oVirt Checkstyle Checks ........................... SUCCESS
> > [2.763s]
> > [INFO] oVirt Modules - backend ........................... SUCCESS
> > [0.246s]
> > [INFO] oVirt Manager ..................................... SUCCESS
> > [0.234s]
> > [INFO] oVirt DB Scripts .................................. SUCCESS
> > [0.950s]
> > [INFO] oVirt Modules - manager ........................... SUCCESS
> > [6.026s]
> > [INFO] CSharp Compatibility .............................. SUCCESS
> > [14.711s]
> > [INFO] Encryption Libraries .............................. SUCCESS
> > [5.150s]
> > [INFO] oVirt Tools ....................................... SUCCESS
> > [0.619s]
> > [INFO] oVirt Tools Common Library ........................ SUCCESS
> > [4.614s]
> > [INFO] Common Code ....................................... SUCCESS
> > [28.455s]
> > [INFO] Common utilities .................................. SUCCESS
> > [32.168s]
> > [INFO] Data Access Layer ................................. SUCCESS
> > [30.996s]
> > [INFO] engine beans ...................................... SUCCESS
> > [0.304s]
> > [INFO] engine scheduler bean ............................. SUCCESS
> > [5.388s]
> > [INFO] Vds broker ........................................ SUCCESS
> > [14.906s]
> > [INFO] Search Backend .................................... SUCCESS
> > [8.260s]
> > [INFO] Backend Logic @Service bean ....................... SUCCESS
> > [1:16.188s]
> > [INFO] oVirt RESTful API Backend Integration ............. SUCCESS
> > [8.478s]
> > [INFO] oVirt RESTful API interface ....................... SUCCESS
> > [0.334s]
> > [INFO] oVirt Engine API Definition ....................... SUCCESS
> > [25.865s]
> > [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS
> > [0.311s]
> > [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS
> > [17.147s]
> > [INFO] oVirt RESTful API Backend Integration Type Mappers  SUCCESS
> > [51.144s]
> > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources
> >  SUCCESS [54.674s]
> > [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS
> > [2.285s]
> > [INFO] oVirt Engine Web Root ............................. SUCCESS
> > [2.731s]
> > [INFO] oVirt Configuration Tool .......................... SUCCESS
> > [3.816s]
> > [INFO] Notifier Service package .......................... SUCCESS
> > [0.171s]
> > [INFO] Notifier Service .................................. SUCCESS
> > [4.180s]
> > [INFO] Notifier Service Resources ........................ SUCCESS
> > [2.233s]
> > [INFO] oVirt Modules :: Frontend ......................... SUCCESS
> > [0.182s]
> > [INFO] oVirt Modules :: Webadmin ......................... SUCCESS
> > [0.187s]
> > [INFO] oVirt Modules - ui ................................ SUCCESS
> > [0.185s]
> > [INFO] Extensions for GWT ................................ SUCCESS
> > [4.740s]
> > [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS
> > [6.985s]
> > [INFO] Frontend for GWT UI Projects ...................... SUCCESS
> > [6.357s]
> > [INFO] UICommonWeb ....................................... SUCCESS
> > [27.230s]
> > [INFO] oVirt GWT UI common infrastructure ................ SUCCESS
> > [33.023s]
> > [INFO] WebAdmin .......................................... SUCCESS
> > [28.203s]
> > [INFO] UserPortal ........................................ SUCCESS
> > [12.630s]
> > [INFO] oVirt WARs ........................................ SUCCESS
> > [0.165s]
> > [INFO] oVirt Web Application Module ...................... SUCCESS
> > [2.619s]
> > [INFO] oVirt Server EAR .................................. SUCCESS
> > [8.673s]
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] BUILD SUCCESS
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Total time: 9:19.320s
> > [INFO] Finished at: Fri Jan 25 04:49:19 EST 2013
> > [INFO] Final Memory: 319M/676M
> > [INFO]
> > ------------------------------------------------------------------------
> > Projects to build: [MavenProject: org.ovirt.engine:root:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/pom.xml,
> > MavenProject: org.ovirt.engine:build-tools-root:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/pom.xml,
> > MavenProject: org.ovirt.engine:checkstyles:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/checkstyles/pom.xml,
> > MavenProject: org.ovirt.engine:ovirt-checkstyle-extension:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/ovirt-checkstyle-extension/pom.xml,
> > MavenProject: org.ovirt.engine.core:backend:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/pom.xml,
> > MavenProject: org.ovirt.engine.core:manager:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/pom.xml,
> > MavenProject: org.ovirt.engine.core:dbscripts:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/dbscripts/pom.xml,
> > MavenProject: org.ovirt.engine.core:manager-modules:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/pom.xml,
> > MavenProject: org.ovirt.engine.core:compat:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/pom.xml,
> > MavenProject: org.ovirt.engine.core:engineencryptutils:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/engineencryptutils/pom.xml,
> > MavenProject: org.ovirt.engine.core:manager-tools:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/pom.xml,
> > MavenProject: org.ovirt.engine.core:engine-tools-common:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-tools-common/pom.xml,
> > MavenProject: org.ovirt.engine.core:common:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/pom.xml,
> > MavenProject: org.ovirt.engine.core:utils:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/utils/pom.xml,
> > MavenProject: org.ovirt.engine.core:dal:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/dal/pom.xml,
> > MavenProject: org.ovirt.engine.core:beans:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/pom.xml,
> > MavenProject: org.ovirt.engine.core:scheduler:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/scheduler/pom.xml,
> > MavenProject: org.ovirt.engine.core:vdsbroker:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/vdsbroker/pom.xml,
> > MavenProject: org.ovirt.engine.core:searchbackend:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/pom.xml,
> > MavenProject: org.ovirt.engine.core:bll:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/bll/pom.xml,
> > MavenProject: org.ovirt.engine.api:restapi-parent:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/pom.xml,
> > MavenProject: org.ovirt.engine.api:interface:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/pom.xml,
> > MavenProject: org.ovirt.engine.api:restapi-definition:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/definition/pom.xml,
> > MavenProject: org.ovirt.engine.api:common-parent:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/pom.xml,
> > MavenProject: org.ovirt.engine.api:interface-common-jaxrs:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/jaxrs/pom.xml,
> > MavenProject: org.ovirt.engine.api:restapi-types:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/types/pom.xml,
> > MavenProject: org.ovirt.engine.api:restapi-jaxrs:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/jaxrs/pom.xml,
> > MavenProject: org.ovirt.engine.api:restapi-webapp:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/webapp/pom.xml,
> > MavenProject: org.ovirt.engine.core:root-war:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/root/pom.xml,
> > MavenProject: org.ovirt.engine.core:engine-config:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-config/pom.xml,
> > MavenProject: org.ovirt.engine.core:engine-notifier:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/pom.xml,
> > MavenProject: org.ovirt.engine.core:engine-notifier-service:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-service/pom.xml,
> > MavenProject: org.ovirt.engine.core:engine-notifier-resources:3.2.0
> > @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-resources/pom.xml,
> > MavenProject: org.ovirt.engine.ui:frontend-all:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/pom.xml,
> > MavenProject: org.ovirt.engine.ui:webadmin-all:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/pom.xml,
> > MavenProject: org.ovirt.engine.ui:webadmin-modules:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/pom.xml,
> > MavenProject: org.ovirt.engine.ui:gwt-extension:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/pom.xml,
> > MavenProject: org.ovirt.engine.ui:uicompat:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicompat/pom.xml,
> > MavenProject: org.ovirt.engine.ui:frontend:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/frontend/pom.xml,
> > MavenProject: org.ovirt.engine.ui:uicommonweb:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/pom.xml,
> > MavenProject: org.ovirt.engine.ui:gwt-common:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-common/pom.xml,
> > MavenProject: org.ovirt.engine.ui:webadmin:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/webadmin/pom.xml,
> > MavenProject: org.ovirt.engine.ui:userportal:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/userportal-gwtp/pom.xml,
> > MavenProject: org.ovirt.engine.ui:wars:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/pom.xml,
> > MavenProject: org.ovirt.engine.ui:rmw-war:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/rmw-war/pom.xml,
> > MavenProject: org.ovirt.engine:engine-server-ear:3.2.0 @
> > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/pom.xml]
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0-sources.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/root/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/root/target/root-war-3.2.0.war
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/webapp/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/webapp/target/restapi-webapp-3.2.0.war
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-tools-common/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-tools-common/target/engine-tools-common-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-tools-common/target/engine-tools-common-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/target/common-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/target/common-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/common/target/common-3.2.0-sources.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-common/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-common/target/gwt-common-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-common/target/gwt-common-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/checkstyles/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/checkstyles/target/checkstyles-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/checkstyles/target/checkstyles-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/scheduler/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/scheduler/target/scheduler-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/beans/scheduler/target/scheduler-3.2.0-client.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-resources/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-resources/target/engine-notifier-resources-3.2.0.zip
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-config/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-config/target/engine-config-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-config/target/engine-config-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/engineencryptutils/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/engineencryptutils/target/engineencryptutils-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/engineencryptutils/target/engineencryptutils-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-service/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-service/target/engine-notifier-service-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/tools/engine-notifier/engine-notifier-service/target/engine-notifier-service-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/utils/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/utils/target/utils-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/utils/target/utils-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/definition/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/definition/target/restapi-definition-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/definition/target/restapi-definition-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/types/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/types/target/restapi-types-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/types/target/restapi-types-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicompat/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicompat/target/uicompat-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/uicompat/target/uicompat-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/ovirt-checkstyle-extension/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/ovirt-checkstyle-extension/target/ovirt-checkstyle-extension-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/ovirt-checkstyle-extension/target/ovirt-checkstyle-extension-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/jaxrs/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/jaxrs/target/restapi-jaxrs-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/jaxrs/target/restapi-jaxrs-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/frontend/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/frontend/target/frontend-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/frontend/target/frontend-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/rmw-war/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/wars/rmw-war/target/rmw-war-3.2.0.war
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/dal/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/dal/target/dal-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/dal/target/dal-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/ear/target/engine.ear
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/webadmin/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/webadmin/target/webadmin-3.2.0.war
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/target/searchbackend-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/target/searchbackend-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/searchbackend/target/searchbackend-3.2.0-sources.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0-sources.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/build-tools-root/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/target/compat-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/target/compat-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/compat/target/compat-3.2.0-sources.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/jaxrs/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/jaxrs/target/interface-common-jaxrs-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/restapi/interface/common/jaxrs/target/interface-common-jaxrs-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/userportal-gwtp/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.2.0.war
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/vdsbroker/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/vdsbroker/target/vdsbroker-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/vdsbroker/target/vdsbroker-3.2.0-tests.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/bll/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/bll/target/bll-3.2.0.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/modules/bll/target/bll-3.2.0-client.jar
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/pom.xml
> > [JENKINS] Archiving disabled - not archiving
> > /home/jenkins/workspace/ovirt_engine_unit_tests/backend/manager/dbscripts/pom.xml
> > Waiting for Jenkins to finish collecting data
> > channel stopped
> > IRC notifier plugin: Sending notification to: #ovirt-jenkins
> > Email was triggered for: Unstable
> > Sending email for trigger: Unstable
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From masayag at redhat.com  Sun Jan 27 09:30:36 2013
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 27 Jan 2013 11:30:36 +0200
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <5101537F.9020706@redhat.com>
References: <365279346.10108140.1359013664441.JavaMail.root@redhat.com>
	<5101537F.9020706@redhat.com>
Message-ID: <5104F3BC.7000503@redhat.com>

On 01/24/2013 05:30 PM, Itamar Heim wrote:
> On 23/01/2013 23:47, Cheryn Tan wrote:
>> Hi all,
>>
>> I'm preparing the oVirt 3.2 release notes, starting with the features
>> listed here: http://www.ovirt.org/OVirt_3.2_release-management#Features
>>
>> Can you please go through the list, and reply to this thread if:
>> a) There are features being released for 3.2 which should be
>> documented, but are not on the list; or
>> b) Some of the planned features on this list are not being released
>> for 3.2; or
>> c) Some of the features on this list are being released for 3.2, but
>> should not be documented.
>>
>> For features which aren't on the wiki, please send a short description
>> or Bugzilla numbers of each feature.
>>
>> Please reply no later than Jan 28.
>>
>> Thank you very much for your help!
>> Cheryn
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> I think most of these made it to 3.2, i'll point fingers at others to
> give more details... (doesn't mean others weren't involved in them, just
> picked someone to give the details for release notes).
> 
> SSIA:
> Add support for Opteron G5 (Seoul)
> Add Support for Intel Haswell CPU
> windows 8/12 - add os type
> windows 8/12 - default in user portal should be rdp
>    (till we have spice support...)
> expand tree by default with list of DCs
> 
> federico:
> storage live migration
> 
> tomas:
> Configure Smartcard for VM including Portal support
> Allow e1000 to be selected as nic type for Windows VM dynamic
> 
> frantisek:
> checkbox at vm level to prevent accidental deletion
> 
> shahar:
> vm payload issues (with cd-rom)
> 
> Arik
> Changing the name of the virtual machines, created from
>    a pool through web-admin-portal
> 
> Alona:
> network as a main tab

http://wiki.ovirt.org/Feature/NetworkMainTab

> network permissions

http://wiki.ovirt.org/Feature/NetworkPermissions

> network main tab: search for networks (and api)
Achieved as part of 'network as a main tab' feature:
http://wiki.ovirt.org/Feature/NetworkMainTab#Search

UI: Since the network is a main entity, it could be filtered using the
search engine, either by its fields or joined with main entities e.g.
data-center, cluster, host, vm and template.

API: Added search capabilities to networks under
uri: api/networks?search={query}

> network main tab: show vms by logical network

Achieved as part of 'network as a main tab' feature


> hot-plug network - change networks on the fly

http://wiki.ovirt.org/Feature/NetworkLinking

> 
> Igor:
> hotplug nic hook
> 
> Muli:
> display the VM interface IP per vnic
> report ipv6 addresses from guest

For the both above:
http://wiki.ovirt.org/Feature/ReportingVnicImplementation

> 
> vojtech:
> ui plugins
> 
> Greg:
> cluster policy on hyperthreads usage
> 
> Laszlo:
> -cpu host
> 
> Ofri:
> quota - add to resource tab in power user portal
> 
> moran:
> ovirt-live
> 
> daniel erez:
> slm: move multiple disks (one by one)
> unicode enablement for OVF fields
> disks subtab/api under storage domain
> 
> Tal:
> delete disk on vm delete flag (for image vs. volume)
> 
> Liron:
> move OVF update out of reconstruct master and all other flows as an
>    independent sync process
> 
> Eli:
> inject events
> bootstrap: fetch logs to engine
> power management proxy (DC or cluster)
> multiple fencing devices
> add ilo2/ilo4 in text
> 
> Yaniv Bronhaim:
> collect hardware (bios) information
> 
> juan:
> engine-vdsm ssl session caching
> 
> michael kublin:
> auto-recovery: last host in status up
> 
> Alon Bar-Lev:
> bootstrap: install rhev-h without communication to
>    engine 443
> bootstrap: pki: use PKCS#12 format to store keys
> bootstrap: rewrite (ovirt-host-deploy)
> bootstrap: rewrite (otopi)
> 
> Yair:
> rhevm-manage-domains hardcodes the DC's address instead
>    of using DNS lookups
> 
> Yaniv Dary:
> "cloud provider"" report
> Report Daily list of people logged into Spice consoles
>    and their activity "
> add status of storage domain to dwh/reports
> DC Dashboard should display Storage Domains count
> single vm uptime - rhevm-reports should be able to
>    report uptime against virtual machines
> Storage Inventory Report - New report
> 
> michael pasternak:
> sdk - allow simultaneous connections to multiple servers
> cli - disable output redirection to ease testing efforts
> java sdk
> 
> Doron:
> tuned profile for host
> 
> doron/adam:
> not sure about status of vdsm-mom in 3.2?
> 
> 
> shireesh - what about:
> Forced removal of a host
> Configuration sync with Gluster CLI
> Import of existing gluster clusters
> 
> Thanks,
>    Itamar
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From eedri at redhat.com  Sun Jan 27 09:57:06 2013
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 27 Jan 2013 04:57:06 -0500 (EST)
Subject: [Engine-devel] [JENKINS] important change in findbugs analysis
Message-ID: <647454845.4946695.1359280626049.JavaMail.root@redhat.com>

fyi,

as part of the efforts to reduce bugs found by findbugs jenkins job, 
NORMAL priority bugs limit has been set to 15 (current count), 
this means that any NEW NORMAL bugs that will enter ovirt-engine code will fail the job,
and it's the committer responsibility to fix it.

if you're not sure about your code, you can run mvn findbugs:findbugs before merging (there's also an eclipse plugin for it).

there is on-going work on reducing NORMAL bugs, and this limit will reduce in the near future,
until it will reach '0' (similar to HIGH prirority).

thanks for the cooperation.

Eyal Edri
oVirt infra team.


From rgolan at redhat.com  Sun Jan 27 12:04:26 2013
From: rgolan at redhat.com (Roy Golan)
Date: Sun, 27 Jan 2013 14:04:26 +0200
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <5101537F.9020706@redhat.com>
References: <365279346.10108140.1359013664441.JavaMail.root@redhat.com>
	<5101537F.9020706@redhat.com>
Message-ID: <510517CA.1030903@redhat.com>

On 01/24/2013 05:30 PM, Itamar Heim wrote:
> On 23/01/2013 23:47, Cheryn Tan wrote:
>> Hi all,
>>
>> I'm preparing the oVirt 3.2 release notes, starting with the features 
>> listed here: http://www.ovirt.org/OVirt_3.2_release-management#Features
>>
>> Can you please go through the list, and reply to this thread if:
>> a) There are features being released for 3.2 which should be 
>> documented, but are not on the list; or
>> b) Some of the planned features on this list are not being released 
>> for 3.2; or
>> c) Some of the features on this list are being released for 3.2, but 
>> should not be documented.
>>
>> For features which aren't on the wiki, please send a short 
>> description or Bugzilla numbers of each feature.
>>
>> Please reply no later than Jan 28.
>>
>> Thank you very much for your help!
>> Cheryn
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
> I think most of these made it to 3.2, i'll point fingers at others to 
> give more details... (doesn't mean others weren't involved in them, 
> just picked someone to give the details for release notes).
>
> SSIA:
> Add support for Opteron G5 (Seoul)
> Add Support for Intel Haswell CPU
> windows 8/12 - add os type
"Windows 8, Windows 8-64 and Windows 2012 have been added to the OS type 
selection for a VM
  as well as configuration items for sysprep images and product keys:

SysPrepWindows8Path
SysPrepWindows8x64Path
SysPrepWindows2012x64Path
ProductKeyWindows8
ProductKeyWindows8x64
ProductKeyWindows2012x64
"
> windows 8/12 - default in user portal should be rdp
>    (till we have spice support...)
> expand tree by default with list of DCs
>
> federico:
> storage live migration
>
> tomas:
> Configure Smartcard for VM including Portal support
> Allow e1000 to be selected as nic type for Windows VM dynamic
>
> frantisek:
> checkbox at vm level to prevent accidental deletion
>
> shahar:
> vm payload issues (with cd-rom)
>
> Arik
> Changing the name of the virtual machines, created from
>    a pool through web-admin-portal
>
> Alona:
> network as a main tab
> network permissions
> network main tab: search for networks (and api)
> network main tab: show vms by logical network
> hot-plug network - change networks on the fly
>
> Igor:
> hotplug nic hook
>
> Muli:
> display the VM interface IP per vnic
> report ipv6 addresses from guest
>
> vojtech:
> ui plugins
>
> Greg:
> cluster policy on hyperthreads usage
>
> Laszlo:
> -cpu host
>
> Ofri:
> quota - add to resource tab in power user portal
>
> moran:
> ovirt-live
>
> daniel erez:
> slm: move multiple disks (one by one)
> unicode enablement for OVF fields
> disks subtab/api under storage domain
>
> Tal:
> delete disk on vm delete flag (for image vs. volume)
>
> Liron:
> move OVF update out of reconstruct master and all other flows as an
>    independent sync process
>
> Eli:
> inject events
> bootstrap: fetch logs to engine
> power management proxy (DC or cluster)
> multiple fencing devices
> add ilo2/ilo4 in text
>
> Yaniv Bronhaim:
> collect hardware (bios) information
>
> juan:
> engine-vdsm ssl session caching
>
> michael kublin:
> auto-recovery: last host in status up
>
> Alon Bar-Lev:
> bootstrap: install rhev-h without communication to
>    engine 443
> bootstrap: pki: use PKCS#12 format to store keys
> bootstrap: rewrite (ovirt-host-deploy)
> bootstrap: rewrite (otopi)
>
> Yair:
> rhevm-manage-domains hardcodes the DC's address instead
>    of using DNS lookups
>
> Yaniv Dary:
> "cloud provider"" report
> Report Daily list of people logged into Spice consoles
>    and their activity "
> add status of storage domain to dwh/reports
> DC Dashboard should display Storage Domains count
> single vm uptime - rhevm-reports should be able to
>    report uptime against virtual machines
> Storage Inventory Report - New report
>
> michael pasternak:
> sdk - allow simultaneous connections to multiple servers
> cli - disable output redirection to ease testing efforts
> java sdk
>
> Doron:
> tuned profile for host
>
> doron/adam:
> not sure about status of vdsm-mom in 3.2?
>
>
> shireesh - what about:
> Forced removal of a host
> Configuration sync with Gluster CLI
> Import of existing gluster clusters
>
> Thanks,
>    Itamar



From wei.d.chen at intel.com  Mon Jan 28 08:42:19 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Mon, 28 Jan 2013 08:42:19 +0000
Subject: [Engine-devel] Open Attestation integration with oVirt engine
 proposal, how to improve engine's performance?
Message-ID: <C5A0092C63E939488005F15F736A8112116403@SHSMSX101.ccr.corp.intel.com>

Open Attestation is a project aim to enable basic open sourced SDK with Intel TXT technology to get node's trustworthiness in a cloud usage environment. Integration Open Attestation with Ovirt will definitely provide a more secure cloud ecosystem which will give end user a choice of whether guest virtual machine need launch on a trusted host server or not. 

Initially, we want to attest the host's trustworthiness every time when every guest virtual machine launch on the host, thanks to Doron Fediuck's reminding, we just need attest the host at the first request and cache the result for subsequent requests is enough, further, we want to bring down server's response time in case of large concurrence request. To resolve/improve engine's performance, we decide to tackle this issue by caching all of node's trustworthiness while the first guest virtual machine's launching, this will take a little longer before its running. Node's trustworthiness would be stored in database or just in system memory, the value will be effective within one hour or so, of course, the period of validity could be configured, node's status need to be updated in the case of end user reboot the virtual machine and the duration exceed valid time. 

Does this acceptable and any good suggestion?

Some details can be found in this link: http://wiki.ovirt.org/Trusted_compute_pools


Best Regards,
Dave Chen




From lhornyak at redhat.com  Mon Jan 28 11:16:00 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 28 Jan 2013 06:16:00 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <165967728.6579170.1359117140365.JavaMail.root@redhat.com>
Message-ID: <416869759.6882699.1359371760138.JavaMail.root@redhat.com>

hi,

This is what I thought of:

In public clouds it is common to have pre-defined instance types e.g. amazon small/medium/large/x-large instance, and this is what customers get even if they don't like it. I guess this helps Amazon a lot to simplify the decision logic for vm scheduling and pricing.

In a private cloud, you choose the resources your application needs, therefore you can choose just as much as you need.

Of course after introducing the instance type in ovirt, you will still have control over the instance types and create any instance type you like beyond the pre-defined types you have in public cloud, but you will have two things to set: the instance type and the image, which is more administration than just working with templates, while most of the cases the templates were enough: you created both the OS image and the virtual hardware profile it is running on. For another image and another workload, I would most likely want to create another one that just fits the needs.

This is why I think keeping the template as an entity composed out of an image and a instance type would be great.

Laszlo

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Friday, January 25, 2013 1:32:20 PM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> Hi Laszlo,
> 
> it is not useful just for public clouds - it can be pretty useful for
> private as well. But to keep the previous way, it could be done this
> way:
> - on the advanced screen (after clicking "show advanced options" you
> can specify the template)
> - by default you pick on basic view the instance type (e.g. HW
> profile) and the Image (e.g. disk with some metadata such as OS
> type). But, you can select custom instance type (equivalent to
>  blank template) and no Image. In this case the template appears
> also on basic view and you can select it.
> 
> What do you think?
> 
> Tomas
> 
> ----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, January 22, 2013 7:16:32 PM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> Hi Tomas,
> 
> I like the idea in general, but for me the instance types looks like
> a feature that is typical in public clouds, while in private clouds
> it looks more like a cool extra feature for special cases. Therefore
> in my opinion it would be great to keep the old template solution as
> well to keep it simple for most users. A template could be an
> instance type and an image together. Only the description overlap,
> and that could be solved.
> 
> Thanks,
> Laszlo
> 
> ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, January 22, 2013 3:09:51 PM
> > Subject: [Engine-devel]  Instance Types Feature
> > 
> > Hi All,
> > 
> > this is the proposed new feature called instance types:
> > http://www.ovirt.org/Features/Instance_Types
> > 
> > Long story short - it should basically split the VM template into:
> > - "hardware profile" called instance types
> > - "software profile" called image
> > 
> > This should enable to do something like: Create a new "small" VM
> > and
> > attach a disk with "RHEL + Postgres" installed.
> > 
> > Any comments are more than welcome!
> > 
> > Tomas
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From fkobzik at redhat.com  Mon Jan 28 11:47:31 2013
From: fkobzik at redhat.com (Frantisek Kobzik)
Date: Mon, 28 Jan 2013 06:47:31 -0500 (EST)
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <5101537F.9020706@redhat.com>
Message-ID: <451536693.48566211.1359373651313.JavaMail.root@redhat.com>

oops, forgot to cc the others.

> checkbox at vm level to prevent accidental deletion
Simple protection from accidental VM or Template deletion. When user turns this protection on the entity (via checkbox in VM/Template dialog or using REST API), the engine does not permit its deletion.


----- Original Message -----
From: "Itamar Heim" <iheim at redhat.com>
To: "Cheryn Tan" <cheryntan at redhat.com>
Cc: engine-devel at ovirt.org, "Federico Simoncelli" <fsimonce at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>, "Roy Golan" <rgolan at redhat.com>, "Shahar Havivi" <shavivi at redhat.com>, "Frantisek Kobzik" <fkobzik at redhat.com>, "Arik Hadas" <ahadas at redhat.com>, "Alona Kaplan" <alkaplan at redhat.com>, "Igor Lvovsky" <ilvovsky at redhat.com>, "Muli Salem" <msalem at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, "Greg Padgett" <gpadgett at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>, omasad at redhat.com, "Moran Goldboim" <mgoldboi at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Tal Nisan" <tnisan at redhat.com>, "Liron Aravot" <laravot at redhat.com>, "Eli Mesika" <emesika at redhat.com>, "Yaniv Bronheim" <ybronhei at redhat.com>, "Juan Antonio Hernandez Fernandez" <jhernand at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>, "Yair Zaslavsky" <yzaslavs at redhat.com>, agl at us.ibm.com, "Shireesh Anjal" <sanjal at redhat.com>, "Yaniv Dary" <ydary at redhat.com>, "Michael Pasternak" <mpastern at redhat.com>
Sent: Thursday, January 24, 2013 4:30:07 PM
Subject: Re: [Engine-devel] 3.2 features for release notes

On 23/01/2013 23:47, Cheryn Tan wrote:
> Hi all,
>
> I'm preparing the oVirt 3.2 release notes, starting with the features listed here: http://www.ovirt.org/OVirt_3.2_release-management#Features
>
> Can you please go through the list, and reply to this thread if:
> a) There are features being released for 3.2 which should be documented, but are not on the list; or
> b) Some of the planned features on this list are not being released for 3.2; or
> c) Some of the features on this list are being released for 3.2, but should not be documented.
>
> For features which aren't on the wiki, please send a short description or Bugzilla numbers of each feature.
>
> Please reply no later than Jan 28.
>
> Thank you very much for your help!
> Cheryn
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

I think most of these made it to 3.2, i'll point fingers at others to 
give more details... (doesn't mean others weren't involved in them, just 
picked someone to give the details for release notes).

SSIA:
Add support for Opteron G5 (Seoul)
Add Support for Intel Haswell CPU
windows 8/12 - add os type
windows 8/12 - default in user portal should be rdp
    (till we have spice support...)
expand tree by default with list of DCs

federico:
storage live migration

tomas:
Configure Smartcard for VM including Portal support
Allow e1000 to be selected as nic type for Windows VM dynamic

frantisek:
checkbox at vm level to prevent accidental deletion

shahar:
vm payload issues (with cd-rom)

Arik
Changing the name of the virtual machines, created from
    a pool through web-admin-portal

Alona:
network as a main tab
network permissions
network main tab: search for networks (and api)
network main tab: show vms by logical network
hot-plug network - change networks on the fly

Igor:
hotplug nic hook

Muli:
display the VM interface IP per vnic
report ipv6 addresses from guest

vojtech:
ui plugins

Greg:
cluster policy on hyperthreads usage

Laszlo:
-cpu host

Ofri:
quota - add to resource tab in power user portal

moran:
ovirt-live

daniel erez:
slm: move multiple disks (one by one)
unicode enablement for OVF fields
disks subtab/api under storage domain

Tal:
delete disk on vm delete flag (for image vs. volume)

Liron:
move OVF update out of reconstruct master and all other flows as an
    independent sync process

Eli:
inject events
bootstrap: fetch logs to engine
power management proxy (DC or cluster)
multiple fencing devices
add ilo2/ilo4 in text

Yaniv Bronhaim:
collect hardware (bios) information

juan:
engine-vdsm ssl session caching

michael kublin:
auto-recovery: last host in status up

Alon Bar-Lev:
bootstrap: install rhev-h without communication to
    engine 443
bootstrap: pki: use PKCS#12 format to store keys
bootstrap: rewrite (ovirt-host-deploy)
bootstrap: rewrite (otopi)

Yair:
rhevm-manage-domains hardcodes the DC's address instead
    of using DNS lookups

Yaniv Dary:
"cloud provider"" report
Report Daily list of people logged into Spice consoles
    and their activity "
add status of storage domain to dwh/reports
DC Dashboard should display Storage Domains count
single vm uptime - rhevm-reports should be able to
    report uptime against virtual machines
Storage Inventory Report - New report

michael pasternak:
sdk - allow simultaneous connections to multiple servers
cli - disable output redirection to ease testing efforts
java sdk

Doron:
tuned profile for host

doron/adam:
not sure about status of vdsm-mom in 3.2?


shireesh - what about:
Forced removal of a host
Configuration sync with Gluster CLI
Import of existing gluster clusters

Thanks,
    Itamar


From gchaplik at redhat.com  Mon Jan 28 16:08:41 2013
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Mon, 28 Jan 2013 11:08:41 -0500 (EST)
Subject: [Engine-devel] [engine-devel] frontend builders proposal
In-Reply-To: <231822069.11211316.1359233937038.JavaMail.root@redhat.com>
Message-ID: <596697544.10116062.1359389321366.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Saturday, January 26, 2013 10:58:57 PM
> Subject: Re: [Engine-devel] [engine-devel] frontend builders proposal
> 
> 
> 
> ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Friday, January 25, 2013 11:55:43 AM
> > Subject: [Engine-devel] [engine-devel] frontend builders proposal
> > 
> > Hi All,
> > 
> > as many of you may know, the way how the frontend and backend
> > models
> > are built on frontend (uicommonweb project) is not really ideal.
> > Currently this logic is copy pasted over and over again to
> > different
> > places where it is needed with minor changes to fulfill the
> > specific
> > requirements. It is not only aesthetically problematic, but I
> > recall
> > tons of bugs caused by introducing a new field and forgetting to
> > add
> > it to every place it is used in GUI.
> > 
> > Now, as there will be big changes in the VM/Template models
> > (http://www.ovirt.org/Features/Instance_Types), so the way how the
> > VM, Template, Pool and also the newly created Instance Types models
> > are being built has to be touched anyhow, it is a great opportunity
> > to rethink the way how we do it.
> > 
> > I have created a simple infrastructure
> > (http://gerrit.ovirt.org/#/c/10874/) which could be used for it,
> > and
> > a PoC patch which uses this infrastructure
> > (http://gerrit.ovirt.org/#/c/11354/). Please note that the PoC is
> > not really impressive in means of removing duplications, I wanted
> > to
> > start with the simplest possibility.
> > 
> > The principles behind the infrastructure:
> > - have small, well named, easy to understand and reuse builders
> > - this builders can be chained together or embedded to each other
> > to
> > build the full resulting object (composite pattern)
> > - this builders can be asynchronous, and the next builder in the
> > chain has to be executed only when the current is completely done
> > 
> > The structure:
> > - the base is an interface called Builder which has a method
> > build(source, destination, rest)
> > - the builder implementing this interface
> >   + will get the source and destination objects
> >   + copies whatever he wants from source to destination
> >   + when done, executes build on the first element of the rest
> >     + this may sound awkward, but this is the way how the async
> >     calls
> >     can be "linearized" in a general way, not embedding anonymous
> >     class into anonymous
> >       class into anonymous class... as we do it today.
> >     + for synchronous builders, there is a BaseSyncBuilder which
> >     takes care of this boilerplate calling of next and exposes a
> >     simple method
> >       build(S source, D destination)
> >   + to simplify the creating and running the chain of builders,
> >   there
> >   is a BuilderExecutor class (can be created as sync or async)
> > 
> > So, a simple example - even more simple than the PoC patch :)
> > 
> > //create the first builder
> > class FirstLetterBuilder extends BaseSyncBuilder<String,
> > StringBuilder> {
> >  @Override
> >  protected void build(String source, StringBuilder destination) {
> >      // copy the first letter to the destination
> >      destination.append(source.charAt(0));
> >  }
> > }
> > 
> > //create the second builder
> > class SecondLetterBuilder extends BaseSyncBuilder<String,
> > StringBuilder> {
> >  @Override
> >  protected void build(String source, StringBuilder destination) {
> >      // copy the second letter to the destination
> >      destination.append(source.charAt(1));
> >  }
> > }
> > 
> > // usage
> > ...
> > // create the destination object
> > StringBuilder res = new StringBuilder();
> > 
> > // configure the executor with the two builders
> > BuilderExecutor<String, StringBuilder> executor = new
> > BuilderExecutor<String, StringBuilder>(
> >         new FirstLetterBuilder(),
> >         new SecondLetterBuilder()
> >         );
> > 
> > // execute the builder chain ("ab" is the source, res the
> > destination)
> > executor.build("ab", res);
> > 
> > // use the result
> > ...
> > 
> > That's it. And the nice part is, that this FirstLetterBuilder and
> > SecondLetterBuilder can be reused anywhere or combined with any
> > other builders.
> > 
> > Any comments on this will be more than welcome!
> 
> great and really simplifies work and eliminate bugs resulted from
> copy/past code
> gave +1
> Thanks
> Eli

Hi guys,

I agree that this refactoring can significantly help us reduce code complexity,
there is another issue that your suggestion doesn't address, 
but we may want take the opportunity to address it if we are already considering refactoring for this code:
this dialog demonstrates the greatest difference (IMHO) between server side pages to applets,
the back and forth filling the form by retrieving all elements one by one.
I would think of a concept similar to server side pages, i.e. retrieving all
data, visibility and even validations (compat?), in a single request, and let the
server have the logic.

Thanks, 
Gilad.

> > 
> > Thank you,
> > Tomas
> > _______________________________________________
> > 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 tnisan at redhat.com  Mon Jan 28 16:23:09 2013
From: tnisan at redhat.com (Tal Nisan)
Date: Mon, 28 Jan 2013 18:23:09 +0200
Subject: [Engine-devel] [engine-devel] frontend builders proposal
In-Reply-To: <231822069.11211316.1359233937038.JavaMail.root@redhat.com>
References: <231822069.11211316.1359233937038.JavaMail.root@redhat.com>
Message-ID: <5106A5ED.9030106@redhat.com>

Makes the frontend code much more readable, great job!

Tal.


On 01/26/2013 10:58 PM, Eli Mesika wrote:
>
> ----- Original Message -----
>> From: "Tomas Jelinek"<tjelinek at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Friday, January 25, 2013 11:55:43 AM
>> Subject: [Engine-devel] [engine-devel] frontend builders proposal
>>
>> Hi All,
>>
>> as many of you may know, the way how the frontend and backend models
>> are built on frontend (uicommonweb project) is not really ideal.
>> Currently this logic is copy pasted over and over again to different
>> places where it is needed with minor changes to fulfill the specific
>> requirements. It is not only aesthetically problematic, but I recall
>> tons of bugs caused by introducing a new field and forgetting to add
>> it to every place it is used in GUI.
>>
>> Now, as there will be big changes in the VM/Template models
>> (http://www.ovirt.org/Features/Instance_Types), so the way how the
>> VM, Template, Pool and also the newly created Instance Types models
>> are being built has to be touched anyhow, it is a great opportunity
>> to rethink the way how we do it.
>>
>> I have created a simple infrastructure
>> (http://gerrit.ovirt.org/#/c/10874/) which could be used for it, and
>> a PoC patch which uses this infrastructure
>> (http://gerrit.ovirt.org/#/c/11354/). Please note that the PoC is
>> not really impressive in means of removing duplications, I wanted to
>> start with the simplest possibility.
>>
>> The principles behind the infrastructure:
>> - have small, well named, easy to understand and reuse builders
>> - this builders can be chained together or embedded to each other to
>> build the full resulting object (composite pattern)
>> - this builders can be asynchronous, and the next builder in the
>> chain has to be executed only when the current is completely done
>>
>> The structure:
>> - the base is an interface called Builder which has a method
>> build(source, destination, rest)
>> - the builder implementing this interface
>>    + will get the source and destination objects
>>    + copies whatever he wants from source to destination
>>    + when done, executes build on the first element of the rest
>>      + this may sound awkward, but this is the way how the async calls
>>      can be "linearized" in a general way, not embedding anonymous
>>      class into anonymous
>>        class into anonymous class... as we do it today.
>>      + for synchronous builders, there is a BaseSyncBuilder which
>>      takes care of this boilerplate calling of next and exposes a
>>      simple method
>>        build(S source, D destination)
>>    + to simplify the creating and running the chain of builders, there
>>    is a BuilderExecutor class (can be created as sync or async)
>>
>> So, a simple example - even more simple than the PoC patch :)
>>
>> //create the first builder
>> class FirstLetterBuilder extends BaseSyncBuilder<String,
>> StringBuilder>  {
>>   @Override
>>   protected void build(String source, StringBuilder destination) {
>>       // copy the first letter to the destination
>>       destination.append(source.charAt(0));
>>   }
>> }
>>
>> //create the second builder
>> class SecondLetterBuilder extends BaseSyncBuilder<String,
>> StringBuilder>  {
>>   @Override
>>   protected void build(String source, StringBuilder destination) {
>>       // copy the second letter to the destination
>>       destination.append(source.charAt(1));
>>   }
>> }
>>
>> // usage
>> ...
>> // create the destination object
>> StringBuilder res = new StringBuilder();
>>
>> // configure the executor with the two builders
>> BuilderExecutor<String, StringBuilder>  executor = new
>> BuilderExecutor<String, StringBuilder>(
>>          new FirstLetterBuilder(),
>>          new SecondLetterBuilder()
>>          );
>>
>> // execute the builder chain ("ab" is the source, res the
>> destination)
>> executor.build("ab", res);
>>
>> // use the result
>> ...
>>
>> That's it. And the nice part is, that this FirstLetterBuilder and
>> SecondLetterBuilder can be reused anywhere or combined with any
>> other builders.
>>
>> Any comments on this will be more than welcome!
> great and really simplifies work and eliminate bugs resulted from copy/past code
> gave +1
> Thanks
> Eli
>> Thank you,
>> Tomas
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From yzaslavs at redhat.com  Mon Jan 28 16:57:35 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 28 Jan 2013 11:57:35 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <1556079335.4805444.1358860191899.JavaMail.root@redhat.com>
Message-ID: <53715767.16686219.1359392255705.JavaMail.root@redhat.com>

Hi,
Why are the flavors predefined, and not configured, or let's say that we provide predefined instance types, and let a way to provide custom instance types

Yair


----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, January 22, 2013 3:09:51 PM
> Subject: [Engine-devel]  Instance Types Feature
> 
> Hi All,
> 
> this is the proposed new feature called instance types:
> http://www.ovirt.org/Features/Instance_Types
> 
> Long story short - it should basically split the VM template into:
> - "hardware profile" called instance types
> - "software profile" called image
> 
> This should enable to do something like: Create a new "small" VM and
> attach a disk with "RHEL + Postgres" installed.
> 
> Any comments are more than welcome!
> 
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From michal.skrivanek at redhat.com  Mon Jan 28 17:06:43 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Mon, 28 Jan 2013 18:06:43 +0100
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <53715767.16686219.1359392255705.JavaMail.root@redhat.com>
References: <53715767.16686219.1359392255705.JavaMail.root@redhat.com>
Message-ID: <1B52AE18-67E3-4B93-B002-4A9D1D4803FE@redhat.com>


On Jan 28, 2013, at 17:57 , Yair Zaslavsky <yzaslavs at redhat.com> wrote:

> Hi,
> Why are the flavors predefined, and not configured, or let's say that we provide predefined instance types, and let a way to provide custom instance types
Our plan was to provide couple of predefined types and let user create own if needed. Custom means an extra type where you can specify anything when creating a VM (or use a template).
A change to one of the instance type's parameter(say, mem size) will change the type to Custom while creating a VM. Otherwise the VM will be tied to its instance type and update to the instance type will be global and reflected in all relevant VMs.

Thanks,
michal

> 
> Yair
> 
> 
> ----- Original Message -----
>> From: "Tomas Jelinek" <tjelinek at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, January 22, 2013 3:09:51 PM
>> Subject: [Engine-devel]  Instance Types Feature
>> 
>> Hi All,
>> 
>> this is the proposed new feature called instance types:
>> http://www.ovirt.org/Features/Instance_Types
>> 
>> Long story short - it should basically split the VM template into:
>> - "hardware profile" called instance types
>> - "software profile" called image
>> 
>> This should enable to do something like: Create a new "small" VM and
>> attach a disk with "RHEL + Postgres" installed.
>> 
>> Any comments are more than welcome!
>> 
>> Tomas
>> _______________________________________________
>> 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 dallan at redhat.com  Mon Jan 28 17:23:25 2013
From: dallan at redhat.com (Dave Allan)
Date: Mon, 28 Jan 2013 12:23:25 -0500
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <5102B413.4050100@redhat.com>
References: <1570564188.5808831.1359037197536.JavaMail.root@redhat.com>
	<5102B413.4050100@redhat.com>
Message-ID: <20130128172325.GE1770@redhat.com>

On Fri, Jan 25, 2013 at 08:34:27AM -0800, Itamar Heim wrote:
> On 24/01/2013 06:19, Laszlo Hornyak wrote:
> >Hi,
> >
> >Watchdog support in engine will add watchdog to the ovirt UI and REST API. Watchdog cards will be mainly used in HA vm's.
> >
> >http://www.ovirt.org/Features/Watchdog_engine_support
> >
> >Your feedback is welcome!
> >
> >Thank you,
> >Laszlo
> >_______________________________________________
> >Engine-devel mailing list
> >Engine-devel at ovirt.org
> >http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> looks like a nice, simple, addition.
> dave, anyone more intimate with the watchdog worth giving another look?

I had a look at the ovirt feature page and asked some libvirt folks as
well, and it all looks good to me except that the libvirt
documentation says that an event when watchdog fires will be added in
the future.  That event has been added.  The watchdog should work
pretty much identically to the physical world: configure the virtual
watchdog card in the guest hardware description and install the
watchdog daemon in the guest.

Dave


From mgoldboi at redhat.com  Mon Jan 28 23:30:40 2013
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Tue, 29 Jan 2013 01:30:40 +0200
Subject: [Engine-devel] oVirt 3.2 test-day
Message-ID: <51070A20.7060400@redhat.com>

we were supposed to have test day tomorrow, but we decided to push it to 
Thursday (Jan 31) to have ovirt-node and proper infra for test day (Mike 
should announce it's officially soon).
I have refreshed http://www.ovirt.org/Testing/OvirtTestDay, but there is 
action from your part as well:

-go over the scenarios (regressions), see if those relevant, add more if 
needed remove if not.
-add basic tests for your new 3.2 features.
-assign a contributor to be actively present on helping users on his area
-make commitment and participate the test day

I would like to review this document by Wednesday on users meeting, 
please make sure your part is updated by than.

Thanks,
Moran.


From navinp1281 at gmail.com  Tue Jan 29 08:27:48 2013
From: navinp1281 at gmail.com (navin p)
Date: Tue, 29 Jan 2013 13:57:48 +0530
Subject: [Engine-devel] Java process increasing resident memory
Message-ID: <CAKVd3pX+PYi5WZccz01uudFEU3K_Y=xshOfJtaisHHE3cqXbww@mail.gmail.com>

Hi,
  I wrote this sample code and the resident memory of the process is
increasing gradually over time. What could be the reason ? I don't see any
obvious leaks in my program. Could it be that the API is not
freeing/deleting memory ?

Regards,
Navin



package ovcollector;



import java.util.*;
import java.io.*;
import java.lang.management.ManagementFactory;

import org.apache.http.client.*;
import org.apache.http.params.*;
import org.ovirt.engine.sdk.Api;
import org.apache.http.pool.*;
import org.ovirt.engine.sdk.decorators.Host;
import org.ovirt.engine.sdk.decorators.HostStatistic;
import org.ovirt.engine.sdk.decorators.StorageDomain;
import org.ovirt.engine.sdk.decorators.VM;
import org.ovirt.engine.sdk.decorators.VMDisk;
import org.ovirt.engine.sdk.decorators.VMDiskStatistic;
import org.ovirt.engine.sdk.decorators.VMStatistic;
import org.ovirt.engine.sdk.decorators.VMs;
import org.ovirt.engine.sdk.entities.CPU;
import org.ovirt.engine.sdk.entities.Value;
import org.ovirt.engine.sdk.exceptions.ServerException;
import org.ovirt.engine.sdk.exceptions.UnsecuredConnectionAttemptError;
import org.ovirt.engine.*;

import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JTable;
import java.awt.Dimension;
import java.awt.GridLayout;
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;


public class collectHosts extends JPanel {

/**
 * @param args
 */
 public static String[] columnNames = {"Host Name",
            "Host uuid",
            "Cpu Cores", "Cpu Sockets",
            "Memory.total",
            "Memory.used",
            "Memory.free",

 "Memory.shared","Memory.buffers","Memory.cached","swap.total","swap.free","swap.used","swap.cached","ksm.cpu.current",

 "cpu.current.user","cpu.current.system","cpu.current.idle","cpu.load.avg.5m"
            };

public static Object[][] data =
{
{"blankvmname", "blankuuid", new Double(0),new Double(0),new Double(0),new
Double(0),new Double(0),new Double(0),new Double(0), new Double(0),
new Double(0),new Double(0),new Double(0),new Double(0),new Double(0),new
Double(0),new Double(0),new Double(0),new Double(0)},
{"blankvmname", "blankuuid", new Double(0),new Double(0),new Double(0),new
Double(0),new Double(0),new Double(0),new Double(0), new Double(0),
new Double(0),new Double(0),new Double(0),new Double(0),new Double(0),new
Double(0),new Double(0),new Double(0),new Double(0)}
 };
  public collectHosts() {
        super(new GridLayout(1,0));



        final JTable table = new JTable(data, columnNames);
        table.setPreferredScrollableViewportSize(new Dimension(500, 70));
        table.setFillsViewportHeight(true);


        //Create the scroll pane and add the table to it.
        JScrollPane scrollPane = new JScrollPane(table);

        //Add the scroll pane to this panel.
        add(scrollPane);
    }


  /**
     * Create the GUI and show it.  For thread safety,
     * this method should be invoked from the
     * event-dispatching thread.
     */
    private static void createAndShowGUI() {
        //Create and set up the window.
        JFrame frame = new JFrame("Hosts");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

        //Create and set up the content pane.
        collectHosts newContentPane = new collectHosts();
        newContentPane.setOpaque(true); //content panes must be opaque
        frame.setContentPane(newContentPane);

        //Display the window.
        frame.pack();
        frame.setVisible(true);
    }

 private static final String URL = "http://somehost:80/api";
public static void main(String[] args) throws
ClientProtocolException,ServerException,
UnsecuredConnectionAttemptError,IOException {
// TODO Auto-generated method stub
System.out.println("Hosts");

while (true)
{
Api  api = new Api(URL,"SOMEUSERNAME","SOMEPASSWORD");
System.out.println(ManagementFactory.getRuntimeMXBean().getName()) ;
 List<Host>  hlist = api.getHosts().list();
Integer i=0,j=0;
for(Host obj: hlist)
{
j=0;
System.out.println(obj.getName()+ ":" + obj.getId() +":"+
obj.getMemory()+":" + obj.getCpu().getTopology().getCores() +":"+
obj.getCpu().getTopology().getSockets());
 data[i][j++]=obj.getName();
data[i][j++]=obj.getId();
data[i][j++]=obj.getCpu().getTopology().getCores();
data[i][j++]=obj.getCpu().getTopology().getSockets();
 List<HostStatistic> lhs=obj.getStatistics().list();
for(HostStatistic obj1: lhs)
{
System.out.println(obj1.getName());
List<Value> vll=obj1.getValues().getValues();
for(Value vl:vll)
{
System.out.println(vl.getDatum());
data[i][j++]=vl.getDatum();
}
}
i++;
}
 try {
Thread.sleep(10000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
 /*
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
            createAndShowGUI();
        }
});
 List<StorageDomain> list_SD=api.getStorageDomains().list();
Integer i=0;
for(StorageDomain obj: list_SD)
{
System.out.println(obj.getName()+ " | " + obj.getUsed() + " | " +
obj.getAvailable() + " | " + obj.getType());
}
*/
 }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130129/41ed98f9/attachment.html>

From mpastern at redhat.com  Tue Jan 29 09:12:57 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 29 Jan 2013 11:12:57 +0200
Subject: [Engine-devel] Java process increasing resident memory
In-Reply-To: <CAKVd3pX+PYi5WZccz01uudFEU3K_Y=xshOfJtaisHHE3cqXbww@mail.gmail.com>
References: <CAKVd3pX+PYi5WZccz01uudFEU3K_Y=xshOfJtaisHHE3cqXbww@mail.gmail.com>
Message-ID: <51079299.4020903@redhat.com>


Hi Navin,

On 01/29/2013 10:27 AM, navin p wrote:
> while (true)
> {
> Api  api = new Api(URL,"SOMEUSERNAME","SOMEPASSWORD");

i'd suggest you moving SDK proxy initiation out of this (endless) loop.

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mkublin at redhat.com  Tue Jan 29 10:01:33 2013
From: mkublin at redhat.com (Michael Kublin)
Date: Tue, 29 Jan 2013 05:01:33 -0500 (EST)
Subject: [Engine-devel] Improving of exist memory lock infrastructure in
	ovirt-engine
Message-ID: <1052642467.10456127.1359453693714.JavaMail.root@redhat.com>

The following link http://www.ovirt.org/Features/DetailedLockMechanism contains description and design of in memory lock infrastructure.
The design is describing already existing infrastructure with additional changes that should be done in order to improve it.
The idea is to allow using of in memory locks with commands that can create asynchronous tasks.

Regards Michael


From lspevak at redhat.com  Tue Jan 29 10:42:35 2013
From: lspevak at redhat.com (Libor Spevak)
Date: Tue, 29 Jan 2013 11:42:35 +0100
Subject: [Engine-devel] Time for Spring?
Message-ID: <5107A79B.4070708@redhat.com>

Hi,

it is rather cold in Europe, but can I ask, what's the current opinion 
or plans about "full" integration of Spring Framework into oVirt engine 
(Backend)?

This is a commonly accepted integration framework among Java programmers 
and industry standard, which
solves many pains from small to large projects. And can lead to a better 
understanding of the program.

There are several Spring dependencies inside oVirt project, but mostly 
for LDAP and database communication (JDBC template).

Still missing (sorry, looks like marketing, but..):

- dependency injection
- aspect-oriented programming (AOP)
- enterprise integration patterns

Is something true? :-)

1. We tried, but it is too large and overcomplicated, it can be solved 
better way for the project purpose
2. We tried, but we think, we need just e.g. JDBC, LDAP layer covered now
3. We would like to integrate with e.g. Hibernate soon, EJB, remoting, 
unit tests, integration tests, ... , probably we will need it soon
4. We understand and need dependency injection, but there are other 
light DI containers (Pico, Guice, JBoss Seam).
etc.

Still, I think there is strong potential, probably not clear today. We 
cannot avoid Guice on frontend side because of GWTP, but the backend 
lacks something.
Or not?

Thanks.

Regards,
Libor



From eedri at redhat.com  Tue Jan 29 11:15:08 2013
From: eedri at redhat.com (Eyal Edri)
Date: Tue, 29 Jan 2013 06:15:08 -0500 (EST)
Subject: [Engine-devel] May I apply for a user account on
	jenkins.ovirt.org to run VDSM	functional tests?
In-Reply-To: <5107A35B.8090607@linux.vnet.ibm.com>
Message-ID: <1447350941.5954088.1359458108776.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Zhou Zheng Sheng" <zhshzhou at linux.vnet.ibm.com>
> To: infra at ovirt.org
> Cc: "ShaoHe Feng" <shaohef at linux.vnet.ibm.com>
> Sent: Tuesday, January 29, 2013 12:24:27 PM
> Subject: May I apply for a user account on jenkins.ovirt.org to run VDSM	functional tests?
> 
> Hi all,
> 
> I notice there is no VDSM functional tests running in oVirt Jenkins.
> Currently in VDSM we have some XML-RPC functional test cases for
> iSCSI,
> localfs and glusterfs storage as well as creating and destroying VMs
> on
> those storage. Functional tests through JSON-RPC are under review. I
> also submit a patch to Gerrit for running the tests easily
> (http://gerrit.ovirt.org/#/c/11238/). More test cases will be added
> to
> improve test coverage and reduce the chance of regression.
> 
> Some bugs that can not be covered by unit test can be caught by
> functional tests. I think it would be helpful to run these functional
> tests continuously. We can also configure the Gerrit trigger in
> Jenkins
> to run functional tests when someone verifies the patch or when it
> gets
> approved but not merged. This may be helpful to the maintainer.
> 
> I've setup a Jenkins job for VDSM functional tests in my lab server.
> You
> can refer to the job configuration of my current setup
> (https://github.com/edwardbadboy/vdsm-jenkins/blob/master/config.xml).
> After my patch in Gerrit is accepted, the job configuration will be
> simpler and the hacks can be removed. May I apply a user account for
> creating job in the oVirt Jenkins?
> 

Hi Zhou,
Basically there shouldn't be any problem with that.
we have an option for giving a 'power-user' permissions for certain users on oVirt misc projects 
to add and and configure jobs for thier project. 

it requires knowledge in jenkins, which it seems that you have and recognition from the 
team/other developers from the relevant project (in this case, VDSM) that you are an active member of the project. 
(just a formality essentially)

I've added engine-devel list to this thread so anyone from vdsm team can vote +1 for adding you as a power user for jenkins.

once we'll receive a few +1 and not objections i'll create a user for you and send you the details.

you'll be able to:

1. create new jobs
2. update jobs configurations
3. run jobs.. 


> --
> Thanks and best regards!
> 
> Zhou Zheng Sheng / ???
> E-mail: zhshzhou at linux.vnet.ibm.com
> Telephone: 86-10-82454397
> 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From dfediuck at redhat.com  Tue Jan 29 13:06:44 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 29 Jan 2013 08:06:44 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <20130128172325.GE1770@redhat.com>
Message-ID: <394616269.12971388.1359464804332.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dave Allan" <dallan at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, January 28, 2013 7:23:25 PM
> Subject: Re: [Engine-devel] Watchdog support Feature
> 
> On Fri, Jan 25, 2013 at 08:34:27AM -0800, Itamar Heim wrote:
> > On 24/01/2013 06:19, Laszlo Hornyak wrote:
> > >Hi,
> > >
> > >Watchdog support in engine will add watchdog to the ovirt UI and
> > >REST API. Watchdog cards will be mainly used in HA vm's.
> > >
> > >http://www.ovirt.org/Features/Watchdog_engine_support
> > >
> > >Your feedback is welcome!
> > >
> > >Thank you,
> > >Laszlo
> > >_______________________________________________
> > >Engine-devel mailing list
> > >Engine-devel at ovirt.org
> > >http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > 
> > looks like a nice, simple, addition.
> > dave, anyone more intimate with the watchdog worth giving another
> > look?
> 
> I had a look at the ovirt feature page and asked some libvirt folks
> as
> well, and it all looks good to me except that the libvirt
> documentation says that an event when watchdog fires will be added in
> the future.  That event has been added.  The watchdog should work
> pretty much identically to the physical world: configure the virtual
> watchdog card in the guest hardware description and install the
> watchdog daemon in the guest.
> 
> Dave

Thanks Dave.
Do you happen do know why the shutdown action is not recommended?


From navinp1281 at gmail.com  Tue Jan 29 13:09:59 2013
From: navinp1281 at gmail.com (navin p)
Date: Tue, 29 Jan 2013 18:39:59 +0530
Subject: [Engine-devel] Java process increasing resident memory
In-Reply-To: <51079299.4020903@redhat.com>
References: <CAKVd3pX+PYi5WZccz01uudFEU3K_Y=xshOfJtaisHHE3cqXbww@mail.gmail.com>
	<51079299.4020903@redhat.com>
Message-ID: <CAKVd3pUFSmZeZQFn=TPAubJvpw94DTE9PL3iXHgR9QfsnZjT7Q@mail.gmail.com>

Hi Michael,

On Tue, Jan 29, 2013 at 2:42 PM, Michael Pasternak <mpastern at redhat.com>wrote:

>
> Hi Navin,
>
> On 01/29/2013 10:27 AM, navin p wrote:
> > while (true)
> > {
> > Api  api = new Api(URL,"SOMEUSERNAME","SOMEPASSWORD");
>
> i'd suggest you moving SDK proxy initiation out of this (endless) loop.
>
> I tried that but it didn't help. The Resident memory was increasing in the
top -p output

Regards,
Navin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130129/1ae5ce5b/attachment.html>

From dallan at redhat.com  Tue Jan 29 13:42:42 2013
From: dallan at redhat.com (Dave Allan)
Date: Tue, 29 Jan 2013 08:42:42 -0500
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <394616269.12971388.1359464804332.JavaMail.root@redhat.com>
References: <20130128172325.GE1770@redhat.com>
	<394616269.12971388.1359464804332.JavaMail.root@redhat.com>
Message-ID: <20130129134242.GA2005@redhat.com>

On Tue, Jan 29, 2013 at 08:06:44AM -0500, Doron Fediuck wrote:
> 
> 
> ----- Original Message -----
> > From: "Dave Allan" <dallan at redhat.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Monday, January 28, 2013 7:23:25 PM
> > Subject: Re: [Engine-devel] Watchdog support Feature
> > 
> > On Fri, Jan 25, 2013 at 08:34:27AM -0800, Itamar Heim wrote:
> > > On 24/01/2013 06:19, Laszlo Hornyak wrote:
> > > >Hi,
> > > >
> > > >Watchdog support in engine will add watchdog to the ovirt UI and
> > > >REST API. Watchdog cards will be mainly used in HA vm's.
> > > >
> > > >http://www.ovirt.org/Features/Watchdog_engine_support
> > > >
> > > >Your feedback is welcome!
> > > >
> > > >Thank you,
> > > >Laszlo
> > > >_______________________________________________
> > > >Engine-devel mailing list
> > > >Engine-devel at ovirt.org
> > > >http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > 
> > > looks like a nice, simple, addition.
> > > dave, anyone more intimate with the watchdog worth giving another
> > > look?
> > 
> > I had a look at the ovirt feature page and asked some libvirt folks
> > as
> > well, and it all looks good to me except that the libvirt
> > documentation says that an event when watchdog fires will be added in
> > the future.  That event has been added.  The watchdog should work
> > pretty much identically to the physical world: configure the virtual
> > watchdog card in the guest hardware description and install the
> > watchdog daemon in the guest.
> > 
> > Dave
> 
> Thanks Dave.
> Do you happen do know why the shutdown action is not recommended?

Yes--it requires guest cooperation which it's unlikely to get if the
guest has gotten into a state where the watchdog fires.

Dave


From ovedo at redhat.com  Tue Jan 29 13:54:13 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Tue, 29 Jan 2013 08:54:13 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <1556079335.4805444.1358860191899.JavaMail.root@redhat.com>
Message-ID: <1290421199.15072642.1359467653790.JavaMail.root@redhat.com>

Some questions:
1. Why do we need a new set of permissions for "Create Instance" and "Instance Owner"? Aren't the VmCreator role and the UserVmManager role enough in these use-cases?
2. iiuc, the internal implementation of instance types and images will be done using templates. However, I guess we plan to expose instance types and images as REST resources, right?

Thank you,
Oved

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, January 22, 2013 3:09:51 PM
> Subject: [Engine-devel]  Instance Types Feature
> 
> Hi All,
> 
> this is the proposed new feature called instance types:
> http://www.ovirt.org/Features/Instance_Types
> 
> Long story short - it should basically split the VM template into:
> - "hardware profile" called instance types
> - "software profile" called image
> 
> This should enable to do something like: Create a new "small" VM and
> attach a disk with "RHEL + Postgres" installed.
> 
> Any comments are more than welcome!
> 
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lvernia at redhat.com  Tue Jan 29 14:08:23 2013
From: lvernia at redhat.com (Lior Vernia)
Date: Tue, 29 Jan 2013 16:08:23 +0200
Subject: [Engine-devel] oVirt 3.2 test-day
In-Reply-To: <51070A20.7060400@redhat.com>
References: <51070A20.7060400@redhat.com>
Message-ID: <5107D7D7.2060203@redhat.com>

I'll be participating and testing the network scenarios (added to wiki).

On 29/01/13 01:30, Moran Goldboim wrote:
> we were supposed to have test day tomorrow, but we decided to push it to
> Thursday (Jan 31) to have ovirt-node and proper infra for test day (Mike
> should announce it's officially soon).
> I have refreshed http://www.ovirt.org/Testing/OvirtTestDay, but there is
> action from your part as well:
> 
> -go over the scenarios (regressions), see if those relevant, add more if
> needed remove if not.
> -add basic tests for your new 3.2 features.
> -assign a contributor to be actively present on helping users on his area
> -make commitment and participate the test day
> 
> I would like to review this document by Wednesday on users meeting,
> please make sure your part is updated by than.
> 
> Thanks,
> Moran.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From lhornyak at redhat.com  Tue Jan 29 14:18:53 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 29 Jan 2013 09:18:53 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <20130129134242.GA2005@redhat.com>
Message-ID: <836007139.7337524.1359469133234.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dave Allan" <dallan at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 29, 2013 2:42:42 PM
> Subject: Re: [Engine-devel] Watchdog support Feature
> 
> On Tue, Jan 29, 2013 at 08:06:44AM -0500, Doron Fediuck wrote:
> > 
> > 
> > ----- Original Message -----
> > > From: "Dave Allan" <dallan at redhat.com>
> > > To: "Itamar Heim" <iheim at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Monday, January 28, 2013 7:23:25 PM
> > > Subject: Re: [Engine-devel] Watchdog support Feature
> > > 
> > > On Fri, Jan 25, 2013 at 08:34:27AM -0800, Itamar Heim wrote:
> > > > On 24/01/2013 06:19, Laszlo Hornyak wrote:
> > > > >Hi,
> > > > >
> > > > >Watchdog support in engine will add watchdog to the ovirt UI
> > > > >and
> > > > >REST API. Watchdog cards will be mainly used in HA vm's.
> > > > >
> > > > >http://www.ovirt.org/Features/Watchdog_engine_support
> > > > >
> > > > >Your feedback is welcome!
> > > > >
> > > > >Thank you,
> > > > >Laszlo
> > > > >_______________________________________________
> > > > >Engine-devel mailing list
> > > > >Engine-devel at ovirt.org
> > > > >http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > >
> > > > 
> > > > looks like a nice, simple, addition.
> > > > dave, anyone more intimate with the watchdog worth giving
> > > > another
> > > > look?
> > > 
> > > I had a look at the ovirt feature page and asked some libvirt
> > > folks
> > > as
> > > well, and it all looks good to me except that the libvirt
> > > documentation says that an event when watchdog fires will be
> > > added in
> > > the future.  That event has been added.  The watchdog should work
> > > pretty much identically to the physical world: configure the
> > > virtual
> > > watchdog card in the guest hardware description and install the
> > > watchdog daemon in the guest.
> > > 
> > > Dave
> > 
> > Thanks Dave.
> > Do you happen do know why the shutdown action is not recommended?
> 
> Yes--it requires guest cooperation which it's unlikely to get if the
> guest has gotten into a state where the watchdog fires.
> 
> Dave

Yep, the guest kernel should handle an ACPI signal. I don't know in what circumstances would that work, but vdsm does not support it either, so that decision is already made.

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


From mpastern at redhat.com  Tue Jan 29 14:41:22 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 29 Jan 2013 16:41:22 +0200
Subject: [Engine-devel] Java process increasing resident memory
In-Reply-To: <CAKVd3pUFSmZeZQFn=TPAubJvpw94DTE9PL3iXHgR9QfsnZjT7Q@mail.gmail.com>
References: <CAKVd3pX+PYi5WZccz01uudFEU3K_Y=xshOfJtaisHHE3cqXbww@mail.gmail.com>	<51079299.4020903@redhat.com>
	<CAKVd3pUFSmZeZQFn=TPAubJvpw94DTE9PL3iXHgR9QfsnZjT7Q@mail.gmail.com>
Message-ID: <5107DF92.40408@redhat.com>


Navin,

It's quite hard to see from your piece of code what exactly causing this,
also i can't reproduce this on my environment running very same sdk code,

can you please run your app with some profiling tool attached and send me
the output?

On 01/29/2013 03:09 PM, navin p wrote:
> 
> Hi Michael,
> 
> On Tue, Jan 29, 2013 at 2:42 PM, Michael Pasternak <mpastern at redhat.com <mailto:mpastern at redhat.com>> wrote:
> 
> 
>     Hi Navin,
> 
>     On 01/29/2013 10:27 AM, navin p wrote:
>     > while (true)
>     > {
>     > Api  api = new Api(URL,"SOMEUSERNAME","SOMEPASSWORD");
> 
>     i'd suggest you moving SDK proxy initiation out of this (endless) loop.
> 
> I tried that but it didn't help. The Resident memory was increasing in the top -p output
> 
> Regards,
> Navin 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From alonbl at redhat.com  Tue Jan 29 14:53:36 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 29 Jan 2013 09:53:36 -0500 (EST)
Subject: [Engine-devel] unit tests failing
Message-ID: <196439113.4815985.1359471216380.JavaMail.root@redhat.com>

Don't know what change exactly caused this:

Tests in error: 
  canDoActionInvalidVmStatus(org.ovirt.engine.core.bll.MoveDisksCommandTest)
  moveDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
  liveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
  liveMigrateDiskBasedOnTemplate(org.ovirt.engine.core.bll.MoveDisksCommandTest)
  moveDiskAndLiveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)


From fsimonce at redhat.com  Tue Jan 29 15:05:10 2013
From: fsimonce at redhat.com (Federico Simoncelli)
Date: Tue, 29 Jan 2013 10:05:10 -0500 (EST)
Subject: [Engine-devel] unit tests failing
In-Reply-To: <196439113.4815985.1359471216380.JavaMail.root@redhat.com>
Message-ID: <1800298234.7821816.1359471910827.JavaMail.root@redhat.com>

I'll need to fix those tests, sorry.
Working on it right now.

-- 
Federico

----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, "Federico Simoncelli" <fsimonce at redhat.com>, "Ofri Masad"
> <omasad at redhat.com>
> Sent: Tuesday, January 29, 2013 3:53:36 PM
> Subject: unit tests failing
> 
> Don't know what change exactly caused this:
> 
> Tests in error:
>   canDoActionInvalidVmStatus(org.ovirt.engine.core.bll.MoveDisksCommandTest)
>   moveDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
>   liveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
>   liveMigrateDiskBasedOnTemplate(org.ovirt.engine.core.bll.MoveDisksCommandTest)
>   moveDiskAndLiveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> 


From lhornyak at redhat.com  Tue Jan 29 15:13:20 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 29 Jan 2013 10:13:20 -0500 (EST)
Subject: [Engine-devel] unit tests failing
In-Reply-To: <1800298234.7821816.1359471910827.JavaMail.root@redhat.com>
Message-ID: <1909795085.7372620.1359472400134.JavaMail.root@redhat.com>

Probably it is not yours, I removed ff64900b7ae1b2d92e40bb290c61354d846d7d30 and still failing.

----- Original Message -----
> From: "Federico Simoncelli" <fsimonce at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 29, 2013 4:05:10 PM
> Subject: Re: [Engine-devel] unit tests failing
> 
> I'll need to fix those tests, sorry.
> Working on it right now.
> 
> --
> Federico
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>, "Federico Simoncelli"
> > <fsimonce at redhat.com>, "Ofri Masad"
> > <omasad at redhat.com>
> > Sent: Tuesday, January 29, 2013 3:53:36 PM
> > Subject: unit tests failing
> > 
> > Don't know what change exactly caused this:
> > 
> > Tests in error:
> >   canDoActionInvalidVmStatus(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> >   moveDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> >   liveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> >   liveMigrateDiskBasedOnTemplate(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> >   moveDiskAndLiveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From jhernand at redhat.com  Tue Jan 29 15:26:08 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 29 Jan 2013 16:26:08 +0100
Subject: [Engine-devel] Change in the RPM release
Message-ID: <5107EA10.2070104@redhat.com>

Hello all,

I have just merged a patch (see [1]) into the master branch that changes 
how the release number of RPMs is created by default. Now it will be 
like this:

   0.1.$(date +%Y%m%d%H%M%S)

This may impact you if you are building your own RPMs, but only if you 
are not explicitly forcing the release number with something like this:

   make rpm RPM_RELEASE_VERSION=whatever

[1] http://gerrit.ovirt.org/9704

Regards,
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 ewoud+ovirt at kohlvanwijngaarden.nl  Tue Jan 29 15:36:35 2013
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Tue, 29 Jan 2013 16:36:35 +0100
Subject: [Engine-devel] unit tests failing
In-Reply-To: <1909795085.7372620.1359472400134.JavaMail.root@redhat.com>
References: <1800298234.7821816.1359471910827.JavaMail.root@redhat.com>
	<1909795085.7372620.1359472400134.JavaMail.root@redhat.com>
Message-ID: <20130129153635.GS18889@bogey.xentower.nl>

May I recommend git bisect? See http://lwn.net/Articles/317154/ or
http://clock.co.uk/tech-blogs/git-bisect-simple-examples-and-automation
as well.

First you find a known BAD, for example master. Then you find a known
GOOD (for example 100 commits ago in master: master~100). Then we can
use a script to determine if it's good. I'm assuming mvn test will be
sufficient, but maybe you can refine this to only test for a specific
unit test.

git bisect start BAD GOOD
git bisect run mvn test

Now it will do a binary search in your history trying to find the commit
that broke mvn test.

On Tue, Jan 29, 2013 at 10:13:20AM -0500, Laszlo Hornyak wrote:
> Probably it is not yours, I removed ff64900b7ae1b2d92e40bb290c61354d846d7d30 and still failing.
> 
> ----- Original Message -----
> > From: "Federico Simoncelli" <fsimonce at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, January 29, 2013 4:05:10 PM
> > Subject: Re: [Engine-devel] unit tests failing
> > 
> > I'll need to fix those tests, sorry.
> > Working on it right now.
> > 
> > --
> > Federico
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>, "Federico Simoncelli"
> > > <fsimonce at redhat.com>, "Ofri Masad"
> > > <omasad at redhat.com>
> > > Sent: Tuesday, January 29, 2013 3:53:36 PM
> > > Subject: unit tests failing
> > > 
> > > Don't know what change exactly caused this:
> > > 
> > > Tests in error:
> > >   canDoActionInvalidVmStatus(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> > >   moveDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> > >   liveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> > >   liveMigrateDiskBasedOnTemplate(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> > >   moveDiskAndLiveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> > > 
> > _______________________________________________
> > 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 Jan 29 15:39:49 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 29 Jan 2013 10:39:49 -0500 (EST)
Subject: [Engine-devel] unit tests failing
In-Reply-To: <20130129153635.GS18889@bogey.xentower.nl>
Message-ID: <1683077720.4827221.1359473989431.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt at kohlvanwijngaarden.nl>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 29, 2013 5:36:35 PM
> Subject: Re: [Engine-devel] unit tests failing
> 
> May I recommend git bisect? See http://lwn.net/Articles/317154/ or
> http://clock.co.uk/tech-blogs/git-bisect-simple-examples-and-automation
> as well.

This is way too time consuming from unrelated party that needs to progress with his own tasks.

> 
> First you find a known BAD, for example master. Then you find a known
> GOOD (for example 100 commits ago in master: master~100). Then we can
> use a script to determine if it's good. I'm assuming mvn test will be
> sufficient, but maybe you can refine this to only test for a specific
> unit test.
> 
> git bisect start BAD GOOD
> git bisect run mvn test
> 
> Now it will do a binary search in your history trying to find the
> commit
> that broke mvn test.
> 
> On Tue, Jan 29, 2013 at 10:13:20AM -0500, Laszlo Hornyak wrote:
> > Probably it is not yours, I removed
> > ff64900b7ae1b2d92e40bb290c61354d846d7d30 and still failing.
> > 
> > ----- Original Message -----
> > > From: "Federico Simoncelli" <fsimonce at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, January 29, 2013 4:05:10 PM
> > > Subject: Re: [Engine-devel] unit tests failing
> > > 
> > > I'll need to fix those tests, sorry.
> > > Working on it right now.
> > > 
> > > --
> > > Federico
> > > 
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>, "Federico
> > > > Simoncelli"
> > > > <fsimonce at redhat.com>, "Ofri Masad"
> > > > <omasad at redhat.com>
> > > > Sent: Tuesday, January 29, 2013 3:53:36 PM
> > > > Subject: unit tests failing
> > > > 
> > > > Don't know what change exactly caused this:
> > > > 
> > > > Tests in error:
> > > >   canDoActionInvalidVmStatus(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> > > >   moveDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> > > >   liveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> > > >   liveMigrateDiskBasedOnTemplate(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> > > >   moveDiskAndLiveMigrateDisk(org.ovirt.engine.core.bll.MoveDisksCommandTest)
> > > > 
> > > _______________________________________________
> > > 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 jhernand at redhat.com  Tue Jan 29 15:44:33 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 29 Jan 2013 16:44:33 +0100
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <50FD000E.6050900@redhat.com>
References: <931532731.7675833.1358756922734.JavaMail.root@redhat.com>
	<50FD000E.6050900@redhat.com>
Message-ID: <5107EE61.3070806@redhat.com>

On 01/21/2013 09:45 AM, Michael Pasternak wrote:
> On 01/21/2013 10:28 AM, Omer Frenkel wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
>>> Sent: Monday, January 21, 2013 8:27:36 AM
>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>> To: "Juan Hernandez" <jhernand at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Sunday, January 20, 2013 3:24:58 PM
>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>
>>>> On 01/17/2013 01:04 PM, Juan Hernandez wrote:
>>>>> Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT
>>>>> in
>>>>> the master branch:
>>>>
>>>> +1
>>> I agree, and this is not the only place where should start marking
>>
>> and cluster compatibility version..
>
> all above is true, but Juan meant preparing MVN infra for the next
> development iteration, while you're talking about engine internals,
> maybe we should file BZs on that (as next version tasks) or should we
> define new process of preparing for the next version that will include both?

As I don't see hard opposition to this change I will merge it tomorrow. 
Please raise your hand iif you think it shouldn't be merged.

http://gerrit.ovirt.org/11143

-- 
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 fsimonce at redhat.com  Tue Jan 29 15:45:43 2013
From: fsimonce at redhat.com (Federico Simoncelli)
Date: Tue, 29 Jan 2013 10:45:43 -0500 (EST)
Subject: [Engine-devel] unit tests failing
In-Reply-To: <20130129153635.GS18889@bogey.xentower.nl>
Message-ID: <1523101890.7840669.1359474343328.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt at kohlvanwijngaarden.nl>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "Federico Simoncelli" <fsimonce at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 29, 2013 4:36:35 PM
> Subject: Re: [Engine-devel] unit tests failing
> 
> May I recommend git bisect? See http://lwn.net/Articles/317154/ or
> http://clock.co.uk/tech-blogs/git-bisect-simple-examples-and-automation
> as well.
> 
> First you find a known BAD, for example master. Then you find a known
> GOOD (for example 100 commits ago in master: master~100). Then we can
> use a script to determine if it's good. I'm assuming mvn test will be
> sufficient, but maybe you can refine this to only test for a specific
> unit test.
> 
> git bisect start BAD GOOD
> git bisect run mvn test
> 
> Now it will do a binary search in your history trying to find the
> commit
> that broke mvn test.

It's ff64900b7ae1b2d92e40bb290c61354d846d7d30 
I'm working on it as we speak.

-- 
Federico


From alonbl at redhat.com  Tue Jan 29 15:52:29 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 29 Jan 2013 10:52:29 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <5107EE61.3070806@redhat.com>
Message-ID: <1093916508.4830741.1359474749799.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, January 29, 2013 5:44:33 PM
> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> On 01/21/2013 09:45 AM, Michael Pasternak wrote:
> > On 01/21/2013 10:28 AM, Omer Frenkel wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> >>> To: "Michael Pasternak" <mpastern at redhat.com>
> >>> Cc: "Juan Hernandez" <jhernand at redhat.com>,
> >>> engine-devel at ovirt.org
> >>> Sent: Monday, January 21, 2013 8:27:36 AM
> >>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>>> To: "Juan Hernandez" <jhernand at redhat.com>
> >>>> Cc: engine-devel at ovirt.org
> >>>> Sent: Sunday, January 20, 2013 3:24:58 PM
> >>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>>
> >>>> On 01/17/2013 01:04 PM, Juan Hernandez wrote:
> >>>>> Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT
> >>>>> in
> >>>>> the master branch:
> >>>>
> >>>> +1
> >>> I agree, and this is not the only place where should start
> >>> marking
> >>
> >> and cluster compatibility version..
> >
> > all above is true, but Juan meant preparing MVN infra for the next
> > development iteration, while you're talking about engine internals,
> > maybe we should file BZs on that (as next version tasks) or should
> > we
> > define new process of preparing for the next version that will
> > include both?
> 
> As I don't see hard opposition to this change I will merge it
> tomorrow.
> Please raise your hand iif you think it shouldn't be merged.
> 
> http://gerrit.ovirt.org/11143

For the poms, why didn't you use a variable that is inherited? But Java is not my domain.

Tarball should be ovirt-engine-3.3.0_master.tar.gz
RPM release should be ovirt-engine-3.3.0-0.0.master

This will enable us to release milestones, such as beta1, beta2, rc1, rc2 and finally release without suffix.

Regards,
Alon


From mpastern at redhat.com  Tue Jan 29 16:20:17 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 29 Jan 2013 18:20:17 +0200
Subject: [Engine-devel] unit tests failing
In-Reply-To: <20130129153635.GS18889@bogey.xentower.nl>
References: <1800298234.7821816.1359471910827.JavaMail.root@redhat.com>	<1909795085.7372620.1359472400134.JavaMail.root@redhat.com>
	<20130129153635.GS18889@bogey.xentower.nl>
Message-ID: <5107F6C1.6050905@redhat.com>


Hey Ewoud,

+1 for bisect,

what's up Ewoud?, this email reminds me good old rhevm-api days.

On 01/29/2013 05:36 PM, Ewoud Kohl van Wijngaarden wrote:
> May I recommend git bisect? See http://lwn.net/Articles/317154/ or
> http://clock.co.uk/tech-blogs/git-bisect-simple-examples-and-automation
> as well.
> 
> First you find a known BAD, for example master. Then you find a known
> GOOD (for example 100 commits ago in master: master~100). Then we can
> use a script to determine if it's good. I'm assuming mvn test will be
> sufficient, but maybe you can refine this to only test for a specific
> unit test.
> 
> git bisect start BAD GOOD
> git bisect run mvn test
> 
> Now it will do a binary search in your history trying to find the commit
> that broke mvn test.


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From shaohef at linux.vnet.ibm.com  Tue Jan 29 16:23:15 2013
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Wed, 30 Jan 2013 00:23:15 +0800
Subject: [Engine-devel] May I apply for a user account on
 jenkins.ovirt.org to run VDSM functional tests?
In-Reply-To: <1447350941.5954088.1359458108776.JavaMail.root@redhat.com>
References: <1447350941.5954088.1359458108776.JavaMail.root@redhat.com>
Message-ID: <5107F773.5000107@linux.vnet.ibm.com>

yes. zhengsheng has setup a Jenkins job for VDSM functional tests in our 
lab server.
he is doing some works related to Jenkins.


On 01/29/2013 07:15 PM, Eyal Edri wrote:
>
> ----- Original Message -----
>> From: "Zhou Zheng Sheng" <zhshzhou at linux.vnet.ibm.com>
>> To: infra at ovirt.org
>> Cc: "ShaoHe Feng" <shaohef at linux.vnet.ibm.com>
>> Sent: Tuesday, January 29, 2013 12:24:27 PM
>> Subject: May I apply for a user account on jenkins.ovirt.org to run VDSM	functional tests?
>>
>> Hi all,
>>
>> I notice there is no VDSM functional tests running in oVirt Jenkins.
>> Currently in VDSM we have some XML-RPC functional test cases for
>> iSCSI,
>> localfs and glusterfs storage as well as creating and destroying VMs
>> on
>> those storage. Functional tests through JSON-RPC are under review. I
>> also submit a patch to Gerrit for running the tests easily
>> (http://gerrit.ovirt.org/#/c/11238/). More test cases will be added
>> to
>> improve test coverage and reduce the chance of regression.
>>
>> Some bugs that can not be covered by unit test can be caught by
>> functional tests. I think it would be helpful to run these functional
>> tests continuously. We can also configure the Gerrit trigger in
>> Jenkins
>> to run functional tests when someone verifies the patch or when it
>> gets
>> approved but not merged. This may be helpful to the maintainer.
>>
>> I've setup a Jenkins job for VDSM functional tests in my lab server.
>> You
>> can refer to the job configuration of my current setup
>> (https://github.com/edwardbadboy/vdsm-jenkins/blob/master/config.xml).
>> After my patch in Gerrit is accepted, the job configuration will be
>> simpler and the hacks can be removed. May I apply a user account for
>> creating job in the oVirt Jenkins?
>>
> Hi Zhou,
> Basically there shouldn't be any problem with that.
> we have an option for giving a 'power-user' permissions for certain users on oVirt misc projects
> to add and and configure jobs for thier project.
>
> it requires knowledge in jenkins, which it seems that you have and recognition from the
> team/other developers from the relevant project (in this case, VDSM) that you are an active member of the project.
> (just a formality essentially)
>
> I've added engine-devel list to this thread so anyone from vdsm team can vote +1 for adding you as a power user for jenkins.
>
> once we'll receive a few +1 and not objections i'll create a user for you and send you the details.
>
> you'll be able to:
>
> 1. create new jobs
> 2. update jobs configurations
> 3. run jobs..
>
>
>> --
>> Thanks and best regards!
>>
>> Zhou Zheng Sheng / ???
>> E-mail: zhshzhou at linux.vnet.ibm.com
>> Telephone: 86-10-82454397
>>
>> _______________________________________________
>> Infra mailing list
>> Infra at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>


-- 
Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center

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

From jhernand at redhat.com  Tue Jan 29 16:41:13 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 29 Jan 2013 17:41:13 +0100
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <1093916508.4830741.1359474749799.JavaMail.root@redhat.com>
References: <1093916508.4830741.1359474749799.JavaMail.root@redhat.com>
Message-ID: <5107FBA9.9040603@redhat.com>

On 01/29/2013 04:52 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Tuesday, January 29, 2013 5:44:33 PM
>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>
>> On 01/21/2013 09:45 AM, Michael Pasternak wrote:
>>> On 01/21/2013 10:28 AM, Omer Frenkel wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>,
>>>>> engine-devel at ovirt.org
>>>>> Sent: Monday, January 21, 2013 8:27:36 AM
>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>> To: "Juan Hernandez" <jhernand at redhat.com>
>>>>>> Cc: engine-devel at ovirt.org
>>>>>> Sent: Sunday, January 20, 2013 3:24:58 PM
>>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>>>
>>>>>> On 01/17/2013 01:04 PM, Juan Hernandez wrote:
>>>>>>> Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT
>>>>>>> in
>>>>>>> the master branch:
>>>>>>
>>>>>> +1
>>>>> I agree, and this is not the only place where should start
>>>>> marking
>>>>
>>>> and cluster compatibility version..
>>>
>>> all above is true, but Juan meant preparing MVN infra for the next
>>> development iteration, while you're talking about engine internals,
>>> maybe we should file BZs on that (as next version tasks) or should
>>> we
>>> define new process of preparing for the next version that will
>>> include both?
>>
>> As I don't see hard opposition to this change I will merge it
>> tomorrow.
>> Please raise your hand iif you think it shouldn't be merged.
>>
>> http://gerrit.ovirt.org/11143
>
> For the poms, why didn't you use a variable that is inherited? But Java is not my domain.

Maven doesn't support use of variables in any of the coordinates of the 
artifacts or of their parents. If you use variables, specially if you 
use them in the "version" of the parent project and the variable is 
inherited from the parent project, there is no way to determine which 
version of the parent project should be used.

>
> Tarball should be ovirt-engine-3.3.0_master.tar.gz
> RPM release should be ovirt-engine-3.3.0-0.0.master
>
> This will enable us to release milestones, such as beta1, beta2, rc1, rc2 and finally release without suffix.
>

-- 
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 lhornyak at redhat.com  Tue Jan 29 16:57:51 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 29 Jan 2013 11:57:51 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <5107FBA9.9040603@redhat.com>
Message-ID: <999421747.7410182.1359478671424.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, January 29, 2013 5:41:13 PM
> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> On 01/29/2013 04:52 PM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Juan Hernandez" <jhernand at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Tuesday, January 29, 2013 5:44:33 PM
> >> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>
> >> On 01/21/2013 09:45 AM, Michael Pasternak wrote:
> >>> On 01/21/2013 10:28 AM, Omer Frenkel wrote:
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> >>>>> To: "Michael Pasternak" <mpastern at redhat.com>
> >>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>,
> >>>>> engine-devel at ovirt.org
> >>>>> Sent: Monday, January 21, 2013 8:27:36 AM
> >>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>>>
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>>>>> To: "Juan Hernandez" <jhernand at redhat.com>
> >>>>>> Cc: engine-devel at ovirt.org
> >>>>>> Sent: Sunday, January 20, 2013 3:24:58 PM
> >>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>>>>
> >>>>>> On 01/17/2013 01:04 PM, Juan Hernandez wrote:
> >>>>>>> Once 3.2.0 is released I think we should move to
> >>>>>>> 3.3.0-SNAPSHOT
> >>>>>>> in
> >>>>>>> the master branch:
> >>>>>>
> >>>>>> +1
> >>>>> I agree, and this is not the only place where should start
> >>>>> marking
> >>>>
> >>>> and cluster compatibility version..
> >>>
> >>> all above is true, but Juan meant preparing MVN infra for the
> >>> next
> >>> development iteration, while you're talking about engine
> >>> internals,
> >>> maybe we should file BZs on that (as next version tasks) or
> >>> should
> >>> we
> >>> define new process of preparing for the next version that will
> >>> include both?
> >>
> >> As I don't see hard opposition to this change I will merge it
> >> tomorrow.
> >> Please raise your hand iif you think it shouldn't be merged.
> >>
> >> http://gerrit.ovirt.org/11143
> >
> > For the poms, why didn't you use a variable that is inherited? But
> > Java is not my domain.
> 
> Maven doesn't support use of variables in any of the coordinates of
> the
> artifacts or of their parents. If you use variables, specially if you
> use them in the "version" of the parent project and the variable is
> inherited from the parent project, there is no way to determine which
> version of the parent project should be used.

That's correct, but you can set the version numbers of the ovirt artifacts to ${parent.version}. But let's do it in a next patch, we already spent enough time on this :) Merge!

> 
> >
> > Tarball should be ovirt-engine-3.3.0_master.tar.gz
> > RPM release should be ovirt-engine-3.3.0-0.0.master
> >
> > This will enable us to release milestones, such as beta1, beta2,
> > rc1, rc2 and finally release without suffix.
> >
> 
> --
> 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.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alonbl at redhat.com  Tue Jan 29 16:58:26 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 29 Jan 2013 11:58:26 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <999421747.7410182.1359478671424.JavaMail.root@redhat.com>
Message-ID: <1725687213.4847277.1359478706903.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Juan Hernandez" <jhernand at redhat.com>
> Cc: engine-devel at ovirt.org, "Alon Bar-Lev" <alonbl at redhat.com>
> Sent: Tuesday, January 29, 2013 6:57:51 PM
> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> 
> 
> ----- Original Message -----
> > From: "Juan Hernandez" <jhernand at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, January 29, 2013 5:41:13 PM
> > Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> > 
> > On 01/29/2013 04:52 PM, Alon Bar-Lev wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Juan Hernandez" <jhernand at redhat.com>
> > >> Cc: engine-devel at ovirt.org
> > >> Sent: Tuesday, January 29, 2013 5:44:33 PM
> > >> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> > >>
> > >> On 01/21/2013 09:45 AM, Michael Pasternak wrote:
> > >>> On 01/21/2013 10:28 AM, Omer Frenkel wrote:
> > >>>>
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > >>>>> To: "Michael Pasternak" <mpastern at redhat.com>
> > >>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > >>>>> engine-devel at ovirt.org
> > >>>>> Sent: Monday, January 21, 2013 8:27:36 AM
> > >>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
> > >>>>>> To: "Juan Hernandez" <jhernand at redhat.com>
> > >>>>>> Cc: engine-devel at ovirt.org
> > >>>>>> Sent: Sunday, January 20, 2013 3:24:58 PM
> > >>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> > >>>>>>
> > >>>>>> On 01/17/2013 01:04 PM, Juan Hernandez wrote:
> > >>>>>>> Once 3.2.0 is released I think we should move to
> > >>>>>>> 3.3.0-SNAPSHOT
> > >>>>>>> in
> > >>>>>>> the master branch:
> > >>>>>>
> > >>>>>> +1
> > >>>>> I agree, and this is not the only place where should start
> > >>>>> marking
> > >>>>
> > >>>> and cluster compatibility version..
> > >>>
> > >>> all above is true, but Juan meant preparing MVN infra for the
> > >>> next
> > >>> development iteration, while you're talking about engine
> > >>> internals,
> > >>> maybe we should file BZs on that (as next version tasks) or
> > >>> should
> > >>> we
> > >>> define new process of preparing for the next version that will
> > >>> include both?
> > >>
> > >> As I don't see hard opposition to this change I will merge it
> > >> tomorrow.
> > >> Please raise your hand iif you think it shouldn't be merged.
> > >>
> > >> http://gerrit.ovirt.org/11143
> > >
> > > For the poms, why didn't you use a variable that is inherited?
> > > But
> > > Java is not my domain.
> > 
> > Maven doesn't support use of variables in any of the coordinates of
> > the
> > artifacts or of their parents. If you use variables, specially if
> > you
> > use them in the "version" of the parent project and the variable is
> > inherited from the parent project, there is no way to determine
> > which
> > version of the parent project should be used.
> 
> That's correct, but you can set the version numbers of the ovirt
> artifacts to ${parent.version}. But let's do it in a next patch, we
> already spent enough time on this :) Merge!

It this is correct, there is no point in merge and fix.
Fix and merge.

> 
> > 
> > >
> > > Tarball should be ovirt-engine-3.3.0_master.tar.gz
> > > RPM release should be ovirt-engine-3.3.0-0.0.master
> > >
> > > This will enable us to release milestones, such as beta1, beta2,
> > > rc1, rc2 and finally release without suffix.
> > >
> > 
> > --
> > 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.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From gpadgett at redhat.com  Tue Jan 29 17:00:36 2013
From: gpadgett at redhat.com (Greg Padgett)
Date: Tue, 29 Jan 2013 12:00:36 -0500
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <5101537F.9020706@redhat.com>
References: <365279346.10108140.1359013664441.JavaMail.root@redhat.com>
	<5101537F.9020706@redhat.com>
Message-ID: <51080034.100@redhat.com>

On 01/24/2013 10:30 AM, Itamar Heim wrote:
> On 23/01/2013 23:47, Cheryn Tan wrote:
>> Hi all,
>>
>> I'm preparing the oVirt 3.2 release notes, starting with the features
>> listed here: http://www.ovirt.org/OVirt_3.2_release-management#Features
>>
>> Can you please go through the list, and reply to this thread if:
>> a) There are features being released for 3.2 which should be documented,
>> but are not on the list; or
>> b) Some of the planned features on this list are not being released for
>> 3.2; or
>> c) Some of the features on this list are being released for 3.2, but
>> should not be documented.
>>
>> For features which aren't on the wiki, please send a short description
>> or Bugzilla numbers of each feature.
>>
>> Please reply no later than Jan 28.
>>
>> Thank you very much for your help!
>> Cheryn
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
> I think most of these made it to 3.2, i'll point fingers at others to give
> more details... (doesn't mean others weren't involved in them, just picked
> someone to give the details for release notes).
>
> SSIA:
> Add support for Opteron G5 (Seoul)
> Add Support for Intel Haswell CPU
> windows 8/12 - add os type
> windows 8/12 - default in user portal should be rdp
>     (till we have spice support...)
> expand tree by default with list of DCs
>
> federico:
> storage live migration
>
> tomas:
> Configure Smartcard for VM including Portal support
> Allow e1000 to be selected as nic type for Windows VM dynamic
>
> frantisek:
> checkbox at vm level to prevent accidental deletion
>
> shahar:
> vm payload issues (with cd-rom)
>
> Arik
> Changing the name of the virtual machines, created from
>     a pool through web-admin-portal
>
> Alona:
> network as a main tab
> network permissions
> network main tab: search for networks (and api)
> network main tab: show vms by logical network
> hot-plug network - change networks on the fly
>
> Igor:
> hotplug nic hook
>
> Muli:
> display the VM interface IP per vnic
> report ipv6 addresses from guest
>
> vojtech:
> ui plugins
>
> Greg:
> cluster policy on hyperthreads usage

http://www.ovirt.org/Features/cpu_thread_handling

Clusters can now be configured to treat host cpu threads as cores for the 
purpose of vm resource allocation, migration, etc.

>
> Laszlo:
> -cpu host
>
> Ofri:
> quota - add to resource tab in power user portal
>
> moran:
> ovirt-live
>
> daniel erez:
> slm: move multiple disks (one by one)
> unicode enablement for OVF fields
> disks subtab/api under storage domain
>
> Tal:
> delete disk on vm delete flag (for image vs. volume)
>
> Liron:
> move OVF update out of reconstruct master and all other flows as an
>     independent sync process
>
> Eli:
> inject events
> bootstrap: fetch logs to engine
> power management proxy (DC or cluster)
> multiple fencing devices
> add ilo2/ilo4 in text
>
> Yaniv Bronhaim:
> collect hardware (bios) information
>
> juan:
> engine-vdsm ssl session caching
>
> michael kublin:
> auto-recovery: last host in status up
>
> Alon Bar-Lev:
> bootstrap: install rhev-h without communication to
>     engine 443
> bootstrap: pki: use PKCS#12 format to store keys
> bootstrap: rewrite (ovirt-host-deploy)
> bootstrap: rewrite (otopi)
>
> Yair:
> rhevm-manage-domains hardcodes the DC's address instead
>     of using DNS lookups
>
> Yaniv Dary:
> "cloud provider"" report
> Report Daily list of people logged into Spice consoles
>     and their activity "
> add status of storage domain to dwh/reports
> DC Dashboard should display Storage Domains count
> single vm uptime - rhevm-reports should be able to
>     report uptime against virtual machines
> Storage Inventory Report - New report
>
> michael pasternak:
> sdk - allow simultaneous connections to multiple servers
> cli - disable output redirection to ease testing efforts
> java sdk
>
> Doron:
> tuned profile for host
>
> doron/adam:
> not sure about status of vdsm-mom in 3.2?
>
>
> shireesh - what about:
> Forced removal of a host
> Configuration sync with Gluster CLI
> Import of existing gluster clusters
>
> Thanks,
>     Itamar



From yzaslavs at redhat.com  Tue Jan 29 17:15:51 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 29 Jan 2013 12:15:51 -0500 (EST)
Subject: [Engine-devel] Improving of exist memory lock infrastructure
	in	ovirt-engine
In-Reply-To: <1052642467.10456127.1359453693714.JavaMail.root@redhat.com>
Message-ID: <1307204228.17616506.1359479751709.JavaMail.root@redhat.com>

Hi,
I fixed some minor typos + have some comments on things need to be clarified.
My comments are based on the sections + numbers inside the sections

Detailed Description

3.  I think you should add:
However, this behavior can be controlled as explained later on and a lock may be released after the end of "endAction".


User-work-flows

2. "If needed additional treatment the appropriate command will override getReadLocks() and getWriteLocks() methods of CommandBase <BR>"


Don't you mean here the exclusive and shared locks?


Failures -
4. In case task is found at DB, but not in SPM - will we want to clean it immediately at the first detection this issue occurs? (We talked about it today, and we think we should do that, giving other 
people a chance to comment)



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 29, 2013 12:01:33 PM
> Subject: [Engine-devel] Improving of exist memory lock infrastructure in	ovirt-engine
> 
> The following link
> http://www.ovirt.org/Features/DetailedLockMechanism contains
> description and design of in memory lock infrastructure.
> The design is describing already existing infrastructure with
> additional changes that should be done in order to improve it.
> The idea is to allow using of in memory locks with commands that can
> create asynchronous tasks.
> 
> Regards Michael
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From jhernand at redhat.com  Tue Jan 29 17:25:21 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 29 Jan 2013 18:25:21 +0100
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <1725687213.4847277.1359478706903.JavaMail.root@redhat.com>
References: <1725687213.4847277.1359478706903.JavaMail.root@redhat.com>
Message-ID: <51080601.8030005@redhat.com>

On 01/29/2013 05:58 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Laszlo Hornyak" <lhornyak at redhat.com>
>> To: "Juan Hernandez" <jhernand at redhat.com>
>> Cc: engine-devel at ovirt.org, "Alon Bar-Lev" <alonbl at redhat.com>
>> Sent: Tuesday, January 29, 2013 6:57:51 PM
>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>
>>
>>
>> ----- Original Message -----
>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Tuesday, January 29, 2013 5:41:13 PM
>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>
>>> On 01/29/2013 04:52 PM, Alon Bar-Lev wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>> Cc: engine-devel at ovirt.org
>>>>> Sent: Tuesday, January 29, 2013 5:44:33 PM
>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>>
>>>>> On 01/21/2013 09:45 AM, Michael Pasternak wrote:
>>>>>> On 01/21/2013 10:28 AM, Omer Frenkel wrote:
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>>>>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>,
>>>>>>>> engine-devel at ovirt.org
>>>>>>>> Sent: Monday, January 21, 2013 8:27:36 AM
>>>>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>>>> To: "Juan Hernandez" <jhernand at redhat.com>
>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>> Sent: Sunday, January 20, 2013 3:24:58 PM
>>>>>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>>>>>>
>>>>>>>>> On 01/17/2013 01:04 PM, Juan Hernandez wrote:
>>>>>>>>>> Once 3.2.0 is released I think we should move to
>>>>>>>>>> 3.3.0-SNAPSHOT
>>>>>>>>>> in
>>>>>>>>>> the master branch:
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>> I agree, and this is not the only place where should start
>>>>>>>> marking
>>>>>>>
>>>>>>> and cluster compatibility version..
>>>>>>
>>>>>> all above is true, but Juan meant preparing MVN infra for the
>>>>>> next
>>>>>> development iteration, while you're talking about engine
>>>>>> internals,
>>>>>> maybe we should file BZs on that (as next version tasks) or
>>>>>> should
>>>>>> we
>>>>>> define new process of preparing for the next version that will
>>>>>> include both?
>>>>>
>>>>> As I don't see hard opposition to this change I will merge it
>>>>> tomorrow.
>>>>> Please raise your hand iif you think it shouldn't be merged.
>>>>>
>>>>> http://gerrit.ovirt.org/11143
>>>>
>>>> For the poms, why didn't you use a variable that is inherited?
>>>> But
>>>> Java is not my domain.
>>>
>>> Maven doesn't support use of variables in any of the coordinates of
>>> the
>>> artifacts or of their parents. If you use variables, specially if
>>> you
>>> use them in the "version" of the parent project and the variable is
>>> inherited from the parent project, there is no way to determine
>>> which
>>> version of the parent project should be used.
>>
>> That's correct, but you can set the version numbers of the ovirt
>> artifacts to ${parent.version}. But let's do it in a next patch, we
>> already spent enough time on this :) Merge!
>
> It this is correct, there is no point in merge and fix.
> Fix and merge.

"${parent.version}" is the default value for "version" when there is a 
parent, and we don't override it in any of our projects.

>
>>
>>>
>>>>
>>>> Tarball should be ovirt-engine-3.3.0_master.tar.gz
>>>> RPM release should be ovirt-engine-3.3.0-0.0.master
>>>>
>>>> This will enable us to release milestones, such as beta1, beta2,
>>>> rc1, rc2 and finally release without suffix.
>>>>
>>>


-- 
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 fsimonce at redhat.com  Tue Jan 29 17:51:42 2013
From: fsimonce at redhat.com (Federico Simoncelli)
Date: Tue, 29 Jan 2013 12:51:42 -0500 (EST)
Subject: [Engine-devel] unit tests failing
In-Reply-To: <1523101890.7840669.1359474343328.JavaMail.root@redhat.com>
Message-ID: <476482674.7889493.1359481902835.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Federico Simoncelli" <fsimonce at redhat.com>
> To: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt at kohlvanwijngaarden.nl>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 29, 2013 4:45:43 PM
> Subject: Re: [Engine-devel] unit tests failing
> 
> ----- Original Message -----
> > From: "Ewoud Kohl van Wijngaarden"
> > <ewoud+ovirt at kohlvanwijngaarden.nl>
> > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > Cc: "Federico Simoncelli" <fsimonce at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Tuesday, January 29, 2013 4:36:35 PM
> > Subject: Re: [Engine-devel] unit tests failing
> > 
> > May I recommend git bisect? See http://lwn.net/Articles/317154/ or
> > http://clock.co.uk/tech-blogs/git-bisect-simple-examples-and-automation
> > as well.
> > 
> > First you find a known BAD, for example master. Then you find a
> > known
> > GOOD (for example 100 commits ago in master: master~100). Then we
> > can
> > use a script to determine if it's good. I'm assuming mvn test will
> > be
> > sufficient, but maybe you can refine this to only test for a
> > specific
> > unit test.
> > 
> > git bisect start BAD GOOD
> > git bisect run mvn test
> > 
> > Now it will do a binary search in your history trying to find the
> > commit
> > that broke mvn test.
> 
> It's ff64900b7ae1b2d92e40bb290c61354d846d7d30
> I'm working on it as we speak.

This is a quick fix:

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

I'm sure there's a lot to improve, please review it so we can push it
as fast as we can. Thanks.
-- 
Federico


From dfediuck at redhat.com  Tue Jan 29 22:50:04 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 29 Jan 2013 17:50:04 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <836007139.7337524.1359469133234.JavaMail.root@redhat.com>
Message-ID: <1154784739.13287784.1359499804318.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Dave Allan" <dallan at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, January 29, 2013 4:18:53 PM
> Subject: Re: [Engine-devel] Watchdog support Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Dave Allan" <dallan at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, January 29, 2013 2:42:42 PM
> > Subject: Re: [Engine-devel] Watchdog support Feature
> > 
> > On Tue, Jan 29, 2013 at 08:06:44AM -0500, Doron Fediuck wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Dave Allan" <dallan at redhat.com>
> > > > To: "Itamar Heim" <iheim at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Monday, January 28, 2013 7:23:25 PM
> > > > Subject: Re: [Engine-devel] Watchdog support Feature
> > > > 
> > > > On Fri, Jan 25, 2013 at 08:34:27AM -0800, Itamar Heim wrote:
> > > > > On 24/01/2013 06:19, Laszlo Hornyak wrote:
> > > > > >Hi,
> > > > > >
> > > > > >Watchdog support in engine will add watchdog to the ovirt UI
> > > > > >and
> > > > > >REST API. Watchdog cards will be mainly used in HA vm's.
> > > > > >
> > > > > >http://www.ovirt.org/Features/Watchdog_engine_support
> > > > > >
> > > > > >Your feedback is welcome!
> > > > > >
> > > > > >Thank you,
> > > > > >Laszlo
> > > > > >_______________________________________________
> > > > > >Engine-devel mailing list
> > > > > >Engine-devel at ovirt.org
> > > > > >http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > >
> > > > > 
> > > > > looks like a nice, simple, addition.
> > > > > dave, anyone more intimate with the watchdog worth giving
> > > > > another
> > > > > look?
> > > > 
> > > > I had a look at the ovirt feature page and asked some libvirt
> > > > folks
> > > > as
> > > > well, and it all looks good to me except that the libvirt
> > > > documentation says that an event when watchdog fires will be
> > > > added in
> > > > the future.  That event has been added.  The watchdog should
> > > > work
> > > > pretty much identically to the physical world: configure the
> > > > virtual
> > > > watchdog card in the guest hardware description and install the
> > > > watchdog daemon in the guest.
> > > > 
> > > > Dave
> > > 
> > > Thanks Dave.
> > > Do you happen do know why the shutdown action is not recommended?
> > 
> > Yes--it requires guest cooperation which it's unlikely to get if
> > the
> > guest has gotten into a state where the watchdog fires.
> > 
> > Dave
> 
> Yep, the guest kernel should handle an ACPI signal. I don't know in
> what circumstances would that work, but vdsm does not support it
> either, so that decision is already made.
> 

Makes sense, thanks.


From cheryntan at redhat.com  Wed Jan 30 04:42:28 2013
From: cheryntan at redhat.com (Cheryn Tan)
Date: Tue, 29 Jan 2013 23:42:28 -0500 (EST)
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <5101537F.9020706@redhat.com>
Message-ID: <715259299.12526857.1359520948228.JavaMail.root@redhat.com>

Thank you everyone who responded to my request for release notes, and thank you Itamar for sending me the list of SMEs for each feature.

I've sent questions to the relevant people about features I need more clarification on, but otherwise a draft of the 3.2 release notes can be found here:
http://www.ovirt.org/OVirt_3.2_release_notes

Your help in reviewing the release notes is greatly appreciated. Feel free to edit the wiki directly or email corrections to me. 

Thank you!
Cheryn






From iheim at redhat.com  Wed Jan 30 07:06:22 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 30 Jan 2013 09:06:22 +0200
Subject: [Engine-devel] 3.2 features for release notes
In-Reply-To: <715259299.12526857.1359520948228.JavaMail.root@redhat.com>
References: <715259299.12526857.1359520948228.JavaMail.root@redhat.com>
Message-ID: <5108C66E.6040001@redhat.com>

On 30/01/2013 06:42, Cheryn Tan wrote:
> Thank you everyone who responded to my request for release notes, and thank you Itamar for sending me the list of SMEs for each feature.
>
> I've sent questions to the relevant people about features I need more clarification on, but otherwise a draft of the 3.2 release notes can be found here:
> http://www.ovirt.org/OVirt_3.2_release_notes
>
> Your help in reviewing the release notes is greatly appreciated. Feel free to edit the wiki directly or email corrections to me.
>
> Thank you!
> Cheryn
>
>
>
>

looks great - thanks!


From tjelinek at redhat.com  Wed Jan 30 07:30:26 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Wed, 30 Jan 2013 02:30:26 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <416869759.6882699.1359371760138.JavaMail.root@redhat.com>
Message-ID: <307192824.8202927.1359531026222.JavaMail.root@redhat.com>

> Of course after introducing the instance type in ovirt, you will still have control over the instance types and create any instance type you like beyond the pre-defined types you have in public cloud, but you 
> will have two things to set: the instance type and the image, which is more administration...
You will still have the templates - you will be able to choose a template which defines both. But it will be "hidden" in advanced part of the dialog. 
You are right, the simple way is pretty much inspired by public clouds, because they do great job in making the things easy. You basically just say you want a small machine and attach a rhel image to it. 
Other advantage of separating the HW and SW configuration is that you can just change the HW profile (instance type) on which you are running, or, if the instance type changes, it gets reflected in all machines using this instance type. 

> This is why I think keeping the template as an entity composed out of an image and a instance type would be great.
yep, it seems we will keep it :) It just will be hidden in the advanced options (e.g. one more click). Sounds reasonable?

----- Original Message -----
From: "Laszlo Hornyak" <lhornyak at redhat.com>
To: "Tomas Jelinek" <tjelinek at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Monday, January 28, 2013 12:16:00 PM
Subject: Re: [Engine-devel]  Instance Types Feature

hi,

This is what I thought of:

In public clouds it is common to have pre-defined instance types e.g. amazon small/medium/large/x-large instance, and this is what customers get even if they don't like it. I guess this helps Amazon a lot to simplify the decision logic for vm scheduling and pricing.

In a private cloud, you choose the resources your application needs, therefore you can choose just as much as you need.

Of course after introducing the instance type in ovirt, you will still have control over the instance types and create any instance type you like beyond the pre-defined types you have in public cloud, but you will have two things to set: the instance type and the image, which is more administration than just working with templates, while most of the cases the templates were enough: you created both the OS image and the virtual hardware profile it is running on. For another image and another workload, I would most likely want to create another one that just fits the needs.

This is why I think keeping the template as an entity composed out of an image and a instance type would be great.

Laszlo

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Friday, January 25, 2013 1:32:20 PM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> Hi Laszlo,
> 
> it is not useful just for public clouds - it can be pretty useful for
> private as well. But to keep the previous way, it could be done this
> way:
> - on the advanced screen (after clicking "show advanced options" you
> can specify the template)
> - by default you pick on basic view the instance type (e.g. HW
> profile) and the Image (e.g. disk with some metadata such as OS
> type). But, you can select custom instance type (equivalent to
>  blank template) and no Image. In this case the template appears
> also on basic view and you can select it.
> 
> What do you think?
> 
> Tomas
> 
> ----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, January 22, 2013 7:16:32 PM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> Hi Tomas,
> 
> I like the idea in general, but for me the instance types looks like
> a feature that is typical in public clouds, while in private clouds
> it looks more like a cool extra feature for special cases. Therefore
> in my opinion it would be great to keep the old template solution as
> well to keep it simple for most users. A template could be an
> instance type and an image together. Only the description overlap,
> and that could be solved.
> 
> Thanks,
> Laszlo
> 
> ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, January 22, 2013 3:09:51 PM
> > Subject: [Engine-devel]  Instance Types Feature
> > 
> > Hi All,
> > 
> > this is the proposed new feature called instance types:
> > http://www.ovirt.org/Features/Instance_Types
> > 
> > Long story short - it should basically split the VM template into:
> > - "hardware profile" called instance types
> > - "software profile" called image
> > 
> > This should enable to do something like: Create a new "small" VM
> > and
> > attach a disk with "RHEL + Postgres" installed.
> > 
> > Any comments are more than welcome!
> > 
> > Tomas
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From tjelinek at redhat.com  Wed Jan 30 07:40:39 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Wed, 30 Jan 2013 02:40:39 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <1290421199.15072642.1359467653790.JavaMail.root@redhat.com>
Message-ID: <448981727.8206649.1359531639039.JavaMail.root@redhat.com>

> 1. Why do we need a new set of permissions for "Create Instance" and "Instance Owner"? Aren't the VmCreator role and the UserVmManager role enough in these use-cases?
ccing Andrew, he might know best

> 2. iiuc, the internal implementation of instance types and images will be done using templates. 
correct
> However, I guess we plan to expose instance types and images as REST resources, right?
yes, however the REST will be discussed more deeply once there will be an agreement on FE and BE.

Tomas

----- Original Message -----
From: "Oved Ourfalli" <ovedo at redhat.com>
To: "Tomas Jelinek" <tjelinek at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Tuesday, January 29, 2013 2:54:13 PM
Subject: Re: [Engine-devel]  Instance Types Feature

Some questions:
1. Why do we need a new set of permissions for "Create Instance" and "Instance Owner"? Aren't the VmCreator role and the UserVmManager role enough in these use-cases?
2. iiuc, the internal implementation of instance types and images will be done using templates. However, I guess we plan to expose instance types and images as REST resources, right?

Thank you,
Oved

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, January 22, 2013 3:09:51 PM
> Subject: [Engine-devel]  Instance Types Feature
> 
> Hi All,
> 
> this is the proposed new feature called instance types:
> http://www.ovirt.org/Features/Instance_Types
> 
> Long story short - it should basically split the VM template into:
> - "hardware profile" called instance types
> - "software profile" called image
> 
> This should enable to do something like: Create a new "small" VM and
> attach a disk with "RHEL + Postgres" installed.
> 
> Any comments are more than welcome!
> 
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lhornyak at redhat.com  Wed Jan 30 08:44:18 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 30 Jan 2013 03:44:18 -0500 (EST)
Subject: [Engine-devel] oVirt 3.2 test-day
In-Reply-To: <51070A20.7060400@redhat.com>
Message-ID: <268806924.7622116.1359535458763.JavaMail.root@redhat.com>

Hi,

I will participate and help users with SLA-related questions.


----- Original Message -----
> From: "Moran Goldboim" <mgoldboi at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, January 29, 2013 12:30:40 AM
> Subject: [Engine-devel] oVirt 3.2 test-day
> 
> we were supposed to have test day tomorrow, but we decided to push it
> to
> Thursday (Jan 31) to have ovirt-node and proper infra for test day
> (Mike
> should announce it's officially soon).
> I have refreshed http://www.ovirt.org/Testing/OvirtTestDay, but there
> is
> action from your part as well:
> 
> -go over the scenarios (regressions), see if those relevant, add more
> if
> needed remove if not.
> -add basic tests for your new 3.2 features.
> -assign a contributor to be actively present on helping users on his
> area
> -make commitment and participate the test day
> 
> I would like to review this document by Wednesday on users meeting,
> please make sure your part is updated by than.
> 
> Thanks,
> Moran.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From tjelinek at redhat.com  Wed Jan 30 09:11:41 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Wed, 30 Jan 2013 04:11:41 -0500 (EST)
Subject: [Engine-devel] [engine-devel] frontend builders proposal
In-Reply-To: <596697544.10116062.1359389321366.JavaMail.root@redhat.com>
Message-ID: <1255676477.8233003.1359537101249.JavaMail.root@redhat.com>


> this dialog demonstrates the greatest difference (IMHO) between server side pages to applets,
> the back and forth filling the form by retrieving all elements one by one.
> I would think of a concept similar to server side pages, i.e. retrieving all
> data, visibility and even validations (compat?), in a single request, and let the
> server have the logic.
Not sure if I have understood you correctly - do you mean moving the frontend logic (e.g. visibility of fields according to some selection) and also the frontend models
to the server? I would say it is better to have this on FE. 

However having the validations common between FE and BE would be great. We could prepare a different patch for this.


----- Original Message -----
From: "Gilad Chaplik" <gchaplik at redhat.com>
To: "Tomas Jelinek" <tjelinek at redhat.com>
Cc: engine-devel at ovirt.org, "Eli Mesika" <emesika at redhat.com>
Sent: Monday, January 28, 2013 5:08:41 PM
Subject: Re: [Engine-devel] [engine-devel] frontend builders proposal

----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Saturday, January 26, 2013 10:58:57 PM
> Subject: Re: [Engine-devel] [engine-devel] frontend builders proposal
> 
> 
> 
> ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Friday, January 25, 2013 11:55:43 AM
> > Subject: [Engine-devel] [engine-devel] frontend builders proposal
> > 
> > Hi All,
> > 
> > as many of you may know, the way how the frontend and backend
> > models
> > are built on frontend (uicommonweb project) is not really ideal.
> > Currently this logic is copy pasted over and over again to
> > different
> > places where it is needed with minor changes to fulfill the
> > specific
> > requirements. It is not only aesthetically problematic, but I
> > recall
> > tons of bugs caused by introducing a new field and forgetting to
> > add
> > it to every place it is used in GUI.
> > 
> > Now, as there will be big changes in the VM/Template models
> > (http://www.ovirt.org/Features/Instance_Types), so the way how the
> > VM, Template, Pool and also the newly created Instance Types models
> > are being built has to be touched anyhow, it is a great opportunity
> > to rethink the way how we do it.
> > 
> > I have created a simple infrastructure
> > (http://gerrit.ovirt.org/#/c/10874/) which could be used for it,
> > and
> > a PoC patch which uses this infrastructure
> > (http://gerrit.ovirt.org/#/c/11354/). Please note that the PoC is
> > not really impressive in means of removing duplications, I wanted
> > to
> > start with the simplest possibility.
> > 
> > The principles behind the infrastructure:
> > - have small, well named, easy to understand and reuse builders
> > - this builders can be chained together or embedded to each other
> > to
> > build the full resulting object (composite pattern)
> > - this builders can be asynchronous, and the next builder in the
> > chain has to be executed only when the current is completely done
> > 
> > The structure:
> > - the base is an interface called Builder which has a method
> > build(source, destination, rest)
> > - the builder implementing this interface
> >   + will get the source and destination objects
> >   + copies whatever he wants from source to destination
> >   + when done, executes build on the first element of the rest
> >     + this may sound awkward, but this is the way how the async
> >     calls
> >     can be "linearized" in a general way, not embedding anonymous
> >     class into anonymous
> >       class into anonymous class... as we do it today.
> >     + for synchronous builders, there is a BaseSyncBuilder which
> >     takes care of this boilerplate calling of next and exposes a
> >     simple method
> >       build(S source, D destination)
> >   + to simplify the creating and running the chain of builders,
> >   there
> >   is a BuilderExecutor class (can be created as sync or async)
> > 
> > So, a simple example - even more simple than the PoC patch :)
> > 
> > //create the first builder
> > class FirstLetterBuilder extends BaseSyncBuilder<String,
> > StringBuilder> {
> >  @Override
> >  protected void build(String source, StringBuilder destination) {
> >      // copy the first letter to the destination
> >      destination.append(source.charAt(0));
> >  }
> > }
> > 
> > //create the second builder
> > class SecondLetterBuilder extends BaseSyncBuilder<String,
> > StringBuilder> {
> >  @Override
> >  protected void build(String source, StringBuilder destination) {
> >      // copy the second letter to the destination
> >      destination.append(source.charAt(1));
> >  }
> > }
> > 
> > // usage
> > ...
> > // create the destination object
> > StringBuilder res = new StringBuilder();
> > 
> > // configure the executor with the two builders
> > BuilderExecutor<String, StringBuilder> executor = new
> > BuilderExecutor<String, StringBuilder>(
> >         new FirstLetterBuilder(),
> >         new SecondLetterBuilder()
> >         );
> > 
> > // execute the builder chain ("ab" is the source, res the
> > destination)
> > executor.build("ab", res);
> > 
> > // use the result
> > ...
> > 
> > That's it. And the nice part is, that this FirstLetterBuilder and
> > SecondLetterBuilder can be reused anywhere or combined with any
> > other builders.
> > 
> > Any comments on this will be more than welcome!
> 
> great and really simplifies work and eliminate bugs resulted from
> copy/past code
> gave +1
> Thanks
> Eli

Hi guys,

I agree that this refactoring can significantly help us reduce code complexity,
there is another issue that your suggestion doesn't address, 
but we may want take the opportunity to address it if we are already considering refactoring for this code:
this dialog demonstrates the greatest difference (IMHO) between server side pages to applets,
the back and forth filling the form by retrieving all elements one by one.
I would think of a concept similar to server side pages, i.e. retrieving all
data, visibility and even validations (compat?), in a single request, and let the
server have the logic.

Thanks, 
Gilad.

> > 
> > Thank you,
> > Tomas
> > _______________________________________________
> > 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 Jan 30 09:22:08 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Wed, 30 Jan 2013 04:22:08 -0500 (EST)
Subject: [Engine-devel] [engine-devel] frontend builders proposal
In-Reply-To: <5106AAEF.2060402@redhat.com>
Message-ID: <257310070.8237732.1359537728460.JavaMail.root@redhat.com>

Hi Tal,

> I was wondering, for entity such as VM, isn't it better to make a 
> builder for the entity as a whole? Unless you know of a specific parts 
> that are used in smaller units?
well, when you create a new VM or a Template, in both cases you need to build the VM entity from UnitVmModel. 
But, not all the fields which are taken from the UnitVmModel in case of creating the new VM are used also for new Template. 
So, in this case both can use CommonUnitToVmBuilder and QuotaUnitToVmBuilder, but the creating of the VM uses also others (e.g. UsbPolicyUntiToVmBuilder etc)

The situation will be even more complex when the Instance Types and the Images will be introduced which all will be basically VM and UnitVmModel subsets. 
So, they will be able to use some of the common builders but not all and will have some custom.

Tomas

----- Original Message -----
From: "Tal Nisan" <tnisan at redhat.com>
To: "Tomas Jelinek" <tjelinek at redhat.com>
Sent: Monday, January 28, 2013 5:44:31 PM
Subject: Re: [Engine-devel] [engine-devel] frontend builders proposal

Hi Tomas,
I was wondering, for entity such as VM, isn't it better to make a 
builder for the entity as a whole? Unless you know of a specific parts 
that are used in smaller units?

Tal.


On 01/25/2013 11:55 AM, Tomas Jelinek wrote:
> Hi All,
>
> as many of you may know, the way how the frontend and backend models are built on frontend (uicommonweb project) is not really ideal. Currently this logic is copy pasted over and over again to different places where it is needed with minor changes to fulfill the specific requirements. It is not only aesthetically problematic, but I recall tons of bugs caused by introducing a new field and forgetting to add it to every place it is used in GUI.
>
> Now, as there will be big changes in the VM/Template models (http://www.ovirt.org/Features/Instance_Types), so the way how the VM, Template, Pool and also the newly created Instance Types models are being built has to be touched anyhow, it is a great opportunity to rethink the way how we do it.
>
> I have created a simple infrastructure (http://gerrit.ovirt.org/#/c/10874/) which could be used for it, and a PoC patch which uses this infrastructure (http://gerrit.ovirt.org/#/c/11354/). Please note that the PoC is not really impressive in means of removing duplications, I wanted to start with the simplest possibility.
>
> The principles behind the infrastructure:
> - have small, well named, easy to understand and reuse builders
> - this builders can be chained together or embedded to each other to build the full resulting object (composite pattern)
> - this builders can be asynchronous, and the next builder in the chain has to be executed only when the current is completely done
>
> The structure:
> - the base is an interface called Builder which has a method build(source, destination, rest)
> - the builder implementing this interface
>    + will get the source and destination objects
>    + copies whatever he wants from source to destination
>    + when done, executes build on the first element of the rest
>      + this may sound awkward, but this is the way how the async calls can be "linearized" in a general way, not embedding anonymous class into anonymous
>        class into anonymous class... as we do it today.
>      + for synchronous builders, there is a BaseSyncBuilder which takes care of this boilerplate calling of next and exposes a simple method
>        build(S source, D destination)
>    + to simplify the creating and running the chain of builders, there is a BuilderExecutor class (can be created as sync or async)
>
> So, a simple example - even more simple than the PoC patch :)
>
> //create the first builder
> class FirstLetterBuilder extends BaseSyncBuilder<String, StringBuilder>  {
>   @Override
>   protected void build(String source, StringBuilder destination) {
>       // copy the first letter to the destination
>       destination.append(source.charAt(0));
>   }
> }
>
> //create the second builder
> class SecondLetterBuilder extends BaseSyncBuilder<String, StringBuilder>  {
>   @Override
>   protected void build(String source, StringBuilder destination) {
>       // copy the second letter to the destination
>       destination.append(source.charAt(1));
>   }
> }
>
> // usage
> ...
> // create the destination object
> StringBuilder res = new StringBuilder();
>
> // configure the executor with the two builders
> BuilderExecutor<String, StringBuilder>  executor = new BuilderExecutor<String, StringBuilder>(
>          new FirstLetterBuilder(),
>          new SecondLetterBuilder()
>          );
>
> // execute the builder chain ("ab" is the source, res the destination)
> executor.build("ab", res);
>
> // use the result
> ...
>
> That's it. And the nice part is, that this FirstLetterBuilder and SecondLetterBuilder can be reused anywhere or combined with any other builders.
>
> Any comments on this will be more than welcome!
>
> Thank you,
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From lhornyak at redhat.com  Wed Jan 30 10:24:52 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 30 Jan 2013 05:24:52 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <307192824.8202927.1359531026222.JavaMail.root@redhat.com>
Message-ID: <433283827.7637357.1359541492533.JavaMail.root@redhat.com>

A hidden feature is a not existing feature :)

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 30, 2013 8:30:26 AM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> > Of course after introducing the instance type in ovirt, you will
> > still have control over the instance types and create any instance
> > type you like beyond the pre-defined types you have in public
> > cloud, but you
> > will have two things to set: the instance type and the image, which
> > is more administration...
> You will still have the templates - you will be able to choose a
> template which defines both. But it will be "hidden" in advanced
> part of the dialog.
> You are right, the simple way is pretty much inspired by public
> clouds, because they do great job in making the things easy. You
> basically just say you want a small machine and attach a rhel image
> to it.
> Other advantage of separating the HW and SW configuration is that you
> can just change the HW profile (instance type) on which you are
> running, or, if the instance type changes, it gets reflected in all
> machines using this instance type.
> 
> > This is why I think keeping the template as an entity composed out
> > of an image and a instance type would be great.
> yep, it seems we will keep it :) It just will be hidden in the
> advanced options (e.g. one more click). Sounds reasonable?
> 
> ----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, January 28, 2013 12:16:00 PM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> hi,
> 
> This is what I thought of:
> 
> In public clouds it is common to have pre-defined instance types e.g.
> amazon small/medium/large/x-large instance, and this is what
> customers get even if they don't like it. I guess this helps Amazon
> a lot to simplify the decision logic for vm scheduling and pricing.
> 
> In a private cloud, you choose the resources your application needs,
> therefore you can choose just as much as you need.
> 
> Of course after introducing the instance type in ovirt, you will
> still have control over the instance types and create any instance
> type you like beyond the pre-defined types you have in public cloud,
> but you will have two things to set: the instance type and the
> image, which is more administration than just working with
> templates, while most of the cases the templates were enough: you
> created both the OS image and the virtual hardware profile it is
> running on. For another image and another workload, I would most
> likely want to create another one that just fits the needs.
> 
> This is why I think keeping the template as an entity composed out of
> an image and a instance type would be great.
> 
> Laszlo
> 
> ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Friday, January 25, 2013 1:32:20 PM
> > Subject: Re: [Engine-devel]  Instance Types Feature
> > 
> > Hi Laszlo,
> > 
> > it is not useful just for public clouds - it can be pretty useful
> > for
> > private as well. But to keep the previous way, it could be done
> > this
> > way:
> > - on the advanced screen (after clicking "show advanced options"
> > you
> > can specify the template)
> > - by default you pick on basic view the instance type (e.g. HW
> > profile) and the Image (e.g. disk with some metadata such as OS
> > type). But, you can select custom instance type (equivalent to
> >  blank template) and no Image. In this case the template appears
> > also on basic view and you can select it.
> > 
> > What do you think?
> > 
> > Tomas
> > 
> > ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, January 22, 2013 7:16:32 PM
> > Subject: Re: [Engine-devel]  Instance Types Feature
> > 
> > Hi Tomas,
> > 
> > I like the idea in general, but for me the instance types looks
> > like
> > a feature that is typical in public clouds, while in private clouds
> > it looks more like a cool extra feature for special cases.
> > Therefore
> > in my opinion it would be great to keep the old template solution
> > as
> > well to keep it simple for most users. A template could be an
> > instance type and an image together. Only the description overlap,
> > and that could be solved.
> > 
> > Thanks,
> > Laszlo
> > 
> > ----- Original Message -----
> > > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Tuesday, January 22, 2013 3:09:51 PM
> > > Subject: [Engine-devel]  Instance Types Feature
> > > 
> > > Hi All,
> > > 
> > > this is the proposed new feature called instance types:
> > > http://www.ovirt.org/Features/Instance_Types
> > > 
> > > Long story short - it should basically split the VM template
> > > into:
> > > - "hardware profile" called instance types
> > > - "software profile" called image
> > > 
> > > This should enable to do something like: Create a new "small" VM
> > > and
> > > attach a disk with "RHEL + Postgres" installed.
> > > 
> > > Any comments are more than welcome!
> > > 
> > > Tomas
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 


From gchaplik at redhat.com  Wed Jan 30 10:42:22 2013
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Wed, 30 Jan 2013 05:42:22 -0500 (EST)
Subject: [Engine-devel] [engine-devel] frontend builders proposal
In-Reply-To: <1255676477.8233003.1359537101249.JavaMail.root@redhat.com>
Message-ID: <1967413296.11103652.1359542542413.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 30, 2013 11:11:41 AM
> Subject: Re: [Engine-devel] [engine-devel] frontend builders proposal
> 
[adding missing part from the thread]

> I agree that this refactoring can significantly help us reduce code
> complexity,
> there is another issue that your suggestion doesn't address,
> but we may want take the opportunity to address it if we are already
> considering refactoring for this code:

> > this dialog demonstrates the greatest difference (IMHO) between
> > server side pages to applets,
> > the back and forth filling the form by retrieving all elements one
> > by one.
> > I would think of a concept similar to server side pages, i.e.
> > retrieving all
> > data, visibility and even validations (compat?), in a single
> > request, and let the
> > server have the logic.
> Not sure if I have understood you correctly - do you mean moving the
> frontend logic (e.g. visibility of fields according to some
> selection) and also the frontend models
> to the server? I would say it is better to have this on FE.

IMHO, we should uiqeury (or something similar) or uiplugin (or striving towards it), that get the entire dialog data (with /without ui).
I'm not sure what is the benefit with your refactoring, can you elaborate on that?

but let see what others think.

> 
> However having the validations common between FE and BE would be
> great. We could prepare a different patch for this.

I think that common validations are nice to have, and it is least of our problems.

> 
> 
> ----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org, "Eli Mesika" <emesika at redhat.com>
> Sent: Monday, January 28, 2013 5:08:41 PM
> Subject: Re: [Engine-devel] [engine-devel] frontend builders proposal
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Saturday, January 26, 2013 10:58:57 PM
> > Subject: Re: [Engine-devel] [engine-devel] frontend builders
> > proposal
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Friday, January 25, 2013 11:55:43 AM
> > > Subject: [Engine-devel] [engine-devel] frontend builders proposal
> > > 
> > > Hi All,
> > > 
> > > as many of you may know, the way how the frontend and backend
> > > models
> > > are built on frontend (uicommonweb project) is not really ideal.
> > > Currently this logic is copy pasted over and over again to
> > > different
> > > places where it is needed with minor changes to fulfill the
> > > specific
> > > requirements. It is not only aesthetically problematic, but I
> > > recall
> > > tons of bugs caused by introducing a new field and forgetting to
> > > add
> > > it to every place it is used in GUI.
> > > 
> > > Now, as there will be big changes in the VM/Template models
> > > (http://www.ovirt.org/Features/Instance_Types), so the way how
> > > the
> > > VM, Template, Pool and also the newly created Instance Types
> > > models
> > > are being built has to be touched anyhow, it is a great
> > > opportunity
> > > to rethink the way how we do it.
> > > 
> > > I have created a simple infrastructure
> > > (http://gerrit.ovirt.org/#/c/10874/) which could be used for it,
> > > and
> > > a PoC patch which uses this infrastructure
> > > (http://gerrit.ovirt.org/#/c/11354/). Please note that the PoC is
> > > not really impressive in means of removing duplications, I wanted
> > > to
> > > start with the simplest possibility.
> > > 
> > > The principles behind the infrastructure:
> > > - have small, well named, easy to understand and reuse builders
> > > - this builders can be chained together or embedded to each other
> > > to
> > > build the full resulting object (composite pattern)
> > > - this builders can be asynchronous, and the next builder in the
> > > chain has to be executed only when the current is completely done
> > > 
> > > The structure:
> > > - the base is an interface called Builder which has a method
> > > build(source, destination, rest)
> > > - the builder implementing this interface
> > >   + will get the source and destination objects
> > >   + copies whatever he wants from source to destination
> > >   + when done, executes build on the first element of the rest
> > >     + this may sound awkward, but this is the way how the async
> > >     calls
> > >     can be "linearized" in a general way, not embedding anonymous
> > >     class into anonymous
> > >       class into anonymous class... as we do it today.
> > >     + for synchronous builders, there is a BaseSyncBuilder which
> > >     takes care of this boilerplate calling of next and exposes a
> > >     simple method
> > >       build(S source, D destination)
> > >   + to simplify the creating and running the chain of builders,
> > >   there
> > >   is a BuilderExecutor class (can be created as sync or async)
> > > 
> > > So, a simple example - even more simple than the PoC patch :)
> > > 
> > > //create the first builder
> > > class FirstLetterBuilder extends BaseSyncBuilder<String,
> > > StringBuilder> {
> > >  @Override
> > >  protected void build(String source, StringBuilder destination) {
> > >      // copy the first letter to the destination
> > >      destination.append(source.charAt(0));
> > >  }
> > > }
> > > 
> > > //create the second builder
> > > class SecondLetterBuilder extends BaseSyncBuilder<String,
> > > StringBuilder> {
> > >  @Override
> > >  protected void build(String source, StringBuilder destination) {
> > >      // copy the second letter to the destination
> > >      destination.append(source.charAt(1));
> > >  }
> > > }
> > > 
> > > // usage
> > > ...
> > > // create the destination object
> > > StringBuilder res = new StringBuilder();
> > > 
> > > // configure the executor with the two builders
> > > BuilderExecutor<String, StringBuilder> executor = new
> > > BuilderExecutor<String, StringBuilder>(
> > >         new FirstLetterBuilder(),
> > >         new SecondLetterBuilder()
> > >         );
> > > 
> > > // execute the builder chain ("ab" is the source, res the
> > > destination)
> > > executor.build("ab", res);
> > > 
> > > // use the result
> > > ...
> > > 
> > > That's it. And the nice part is, that this FirstLetterBuilder and
> > > SecondLetterBuilder can be reused anywhere or combined with any
> > > other builders.
> > > 
> > > Any comments on this will be more than welcome!
> > 
> > great and really simplifies work and eliminate bugs resulted from
> > copy/past code
> > gave +1
> > Thanks
> > Eli
> 
> Hi guys,
> 
> I agree that this refactoring can significantly help us reduce code
> complexity,
> there is another issue that your suggestion doesn't address,
> but we may want take the opportunity to address it if we are already
> considering refactoring for this code:
> this dialog demonstrates the greatest difference (IMHO) between
> server side pages to applets,
> the back and forth filling the form by retrieving all elements one by
> one.
> I would think of a concept similar to server side pages, i.e.
> retrieving all
> data, visibility and even validations (compat?), in a single request,
> and let the
> server have the logic.
> 
> Thanks,
> Gilad.
> 
> > > 
> > > Thank you,
> > > Tomas
> > > _______________________________________________
> > > 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  Wed Jan 30 11:06:08 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 30 Jan 2013 13:06:08 +0200
Subject: [Engine-devel] ovirt-engine-sdk-java 1.0.0.3-1 released
Message-ID: <5108FEA0.1030001@redhat.com>

- added persistent authentication support
- added support for the methods overloads based on url/headers params
- added delete methods overloads with body as parameters holder
- to host added [display.address] property for overriding display address
- user can specify own ticket now in vm.ticket() via [action.ticket.value]

More details can be found at [1].

[1] http://www.ovirt.org/Java-sdk-changelog

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From tjelinek at redhat.com  Wed Jan 30 14:12:28 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Wed, 30 Jan 2013 09:12:28 -0500 (EST)
Subject: [Engine-devel] [engine-devel] frontend builders proposal
In-Reply-To: <1967413296.11103652.1359542542413.JavaMail.root@redhat.com>
Message-ID: <1238610658.8328480.1359555148038.JavaMail.root@redhat.com>



----- Original Message -----
From: "Gilad Chaplik" <gchaplik at redhat.com>
To: "Tomas Jelinek" <tjelinek at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Wednesday, January 30, 2013 11:42:22 AM
Subject: Re: [Engine-devel] [engine-devel] frontend builders proposal

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 30, 2013 11:11:41 AM
> Subject: Re: [Engine-devel] [engine-devel] frontend builders proposal
> 
[adding missing part from the thread]

> I agree that this refactoring can significantly help us reduce code
> complexity,
> there is another issue that your suggestion doesn't address,
> but we may want take the opportunity to address it if we are already
> considering refactoring for this code:

> > > this dialog demonstrates the greatest difference (IMHO) between
> > > server side pages to applets,
> > > the back and forth filling the form by retrieving all elements one
> > > by one.
> > > I would think of a concept similar to server side pages, i.e.
> > > retrieving all
> > > data, visibility and even validations (compat?), in a single
> > > request, and let the
> > > server have the logic.
> > Not sure if I have understood you correctly - do you mean moving the
> > frontend logic (e.g. visibility of fields according to some
> > selection) and also the frontend models
> > to the server? I would say it is better to have this on FE.
> IMHO, we should uiqeury (or something similar) or uiplugin (or striving towards it), that get the entire dialog data (with /without ui).
> I'm not sure what is the benefit with your refactoring, can you elaborate on that?
The plan is to decouple the FE from the BE more in the future by changing the current API to call the REST. My patch is actually a step
to this direction because we will not be able to use the backend models anymore and will need to use DTOs. If we will have the building logic centralized,
it will be much more simple to refactor them to use the new DTOs. Any coupling with the server (like getting the dialog data instead of business data) is 
a step from the moving to generic REST API, and since this is a long term plan, I would be very careful.

> but let see what others think.

> > 
> > However having the validations common between FE and BE would be
> > great. We could prepare a different patch for this.

> I think that common validations are nice to have, and it is least of our problems.
agree

> 
> 
> ----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org, "Eli Mesika" <emesika at redhat.com>
> Sent: Monday, January 28, 2013 5:08:41 PM
> Subject: Re: [Engine-devel] [engine-devel] frontend builders proposal
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Saturday, January 26, 2013 10:58:57 PM
> > Subject: Re: [Engine-devel] [engine-devel] frontend builders
> > proposal
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Friday, January 25, 2013 11:55:43 AM
> > > Subject: [Engine-devel] [engine-devel] frontend builders proposal
> > > 
> > > Hi All,
> > > 
> > > as many of you may know, the way how the frontend and backend
> > > models
> > > are built on frontend (uicommonweb project) is not really ideal.
> > > Currently this logic is copy pasted over and over again to
> > > different
> > > places where it is needed with minor changes to fulfill the
> > > specific
> > > requirements. It is not only aesthetically problematic, but I
> > > recall
> > > tons of bugs caused by introducing a new field and forgetting to
> > > add
> > > it to every place it is used in GUI.
> > > 
> > > Now, as there will be big changes in the VM/Template models
> > > (http://www.ovirt.org/Features/Instance_Types), so the way how
> > > the
> > > VM, Template, Pool and also the newly created Instance Types
> > > models
> > > are being built has to be touched anyhow, it is a great
> > > opportunity
> > > to rethink the way how we do it.
> > > 
> > > I have created a simple infrastructure
> > > (http://gerrit.ovirt.org/#/c/10874/) which could be used for it,
> > > and
> > > a PoC patch which uses this infrastructure
> > > (http://gerrit.ovirt.org/#/c/11354/). Please note that the PoC is
> > > not really impressive in means of removing duplications, I wanted
> > > to
> > > start with the simplest possibility.
> > > 
> > > The principles behind the infrastructure:
> > > - have small, well named, easy to understand and reuse builders
> > > - this builders can be chained together or embedded to each other
> > > to
> > > build the full resulting object (composite pattern)
> > > - this builders can be asynchronous, and the next builder in the
> > > chain has to be executed only when the current is completely done
> > > 
> > > The structure:
> > > - the base is an interface called Builder which has a method
> > > build(source, destination, rest)
> > > - the builder implementing this interface
> > >   + will get the source and destination objects
> > >   + copies whatever he wants from source to destination
> > >   + when done, executes build on the first element of the rest
> > >     + this may sound awkward, but this is the way how the async
> > >     calls
> > >     can be "linearized" in a general way, not embedding anonymous
> > >     class into anonymous
> > >       class into anonymous class... as we do it today.
> > >     + for synchronous builders, there is a BaseSyncBuilder which
> > >     takes care of this boilerplate calling of next and exposes a
> > >     simple method
> > >       build(S source, D destination)
> > >   + to simplify the creating and running the chain of builders,
> > >   there
> > >   is a BuilderExecutor class (can be created as sync or async)
> > > 
> > > So, a simple example - even more simple than the PoC patch :)
> > > 
> > > //create the first builder
> > > class FirstLetterBuilder extends BaseSyncBuilder<String,
> > > StringBuilder> {
> > >  @Override
> > >  protected void build(String source, StringBuilder destination) {
> > >      // copy the first letter to the destination
> > >      destination.append(source.charAt(0));
> > >  }
> > > }
> > > 
> > > //create the second builder
> > > class SecondLetterBuilder extends BaseSyncBuilder<String,
> > > StringBuilder> {
> > >  @Override
> > >  protected void build(String source, StringBuilder destination) {
> > >      // copy the second letter to the destination
> > >      destination.append(source.charAt(1));
> > >  }
> > > }
> > > 
> > > // usage
> > > ...
> > > // create the destination object
> > > StringBuilder res = new StringBuilder();
> > > 
> > > // configure the executor with the two builders
> > > BuilderExecutor<String, StringBuilder> executor = new
> > > BuilderExecutor<String, StringBuilder>(
> > >         new FirstLetterBuilder(),
> > >         new SecondLetterBuilder()
> > >         );
> > > 
> > > // execute the builder chain ("ab" is the source, res the
> > > destination)
> > > executor.build("ab", res);
> > > 
> > > // use the result
> > > ...
> > > 
> > > That's it. And the nice part is, that this FirstLetterBuilder and
> > > SecondLetterBuilder can be reused anywhere or combined with any
> > > other builders.
> > > 
> > > Any comments on this will be more than welcome!
> > 
> > great and really simplifies work and eliminate bugs resulted from
> > copy/past code
> > gave +1
> > Thanks
> > Eli
> 
> Hi guys,
> 
> I agree that this refactoring can significantly help us reduce code
> complexity,
> there is another issue that your suggestion doesn't address,
> but we may want take the opportunity to address it if we are already
> considering refactoring for this code:
> this dialog demonstrates the greatest difference (IMHO) between
> server side pages to applets,
> the back and forth filling the form by retrieving all elements one by
> one.
> I would think of a concept similar to server side pages, i.e.
> retrieving all
> data, visibility and even validations (compat?), in a single request,
> and let the
> server have the logic.
> 
> Thanks,
> Gilad.
> 
> > > 
> > > Thank you,
> > > Tomas
> > > _______________________________________________
> > > 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 Jan 30 14:26:42 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Wed, 30 Jan 2013 09:26:42 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <433283827.7637357.1359541492533.JavaMail.root@redhat.com>
Message-ID: <1626736553.8334443.1359556002148.JavaMail.root@redhat.com>

> A hidden feature is a not existing feature :)
Well, the "hide" was not a correct term :) 

But where would you put it? I see the following options:
1: To the basic screen (but a bit confusing as there will be instance type and image and this dialog should be as simple as possible)
2: To the advanced screen (let's not call it hide but make it an advanced option:) )
3: Do not add it at all (worst case)

I suppose that add it to simple screen and put the Instance type and Image to the advanced one is not really an option as the main point of
this feature is to actually introduce the instance types as a more convenient way of configuring the VM's HW decoupled from SW.

What do you think? Do you see any other ways? I would say that the second possibility is not bad...

Thank you,
Tomas

----- Original Message -----
From: "Laszlo Hornyak" <lhornyak at redhat.com>
To: "Tomas Jelinek" <tjelinek at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Wednesday, January 30, 2013 11:24:52 AM
Subject: Re: [Engine-devel]  Instance Types Feature

A hidden feature is a not existing feature :)

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 30, 2013 8:30:26 AM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> > Of course after introducing the instance type in ovirt, you will
> > still have control over the instance types and create any instance
> > type you like beyond the pre-defined types you have in public
> > cloud, but you
> > will have two things to set: the instance type and the image, which
> > is more administration...
> You will still have the templates - you will be able to choose a
> template which defines both. But it will be "hidden" in advanced
> part of the dialog.
> You are right, the simple way is pretty much inspired by public
> clouds, because they do great job in making the things easy. You
> basically just say you want a small machine and attach a rhel image
> to it.
> Other advantage of separating the HW and SW configuration is that you
> can just change the HW profile (instance type) on which you are
> running, or, if the instance type changes, it gets reflected in all
> machines using this instance type.
> 
> > This is why I think keeping the template as an entity composed out
> > of an image and a instance type would be great.
> yep, it seems we will keep it :) It just will be hidden in the
> advanced options (e.g. one more click). Sounds reasonable?
> 
> ----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, January 28, 2013 12:16:00 PM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> hi,
> 
> This is what I thought of:
> 
> In public clouds it is common to have pre-defined instance types e.g.
> amazon small/medium/large/x-large instance, and this is what
> customers get even if they don't like it. I guess this helps Amazon
> a lot to simplify the decision logic for vm scheduling and pricing.
> 
> In a private cloud, you choose the resources your application needs,
> therefore you can choose just as much as you need.
> 
> Of course after introducing the instance type in ovirt, you will
> still have control over the instance types and create any instance
> type you like beyond the pre-defined types you have in public cloud,
> but you will have two things to set: the instance type and the
> image, which is more administration than just working with
> templates, while most of the cases the templates were enough: you
> created both the OS image and the virtual hardware profile it is
> running on. For another image and another workload, I would most
> likely want to create another one that just fits the needs.
> 
> This is why I think keeping the template as an entity composed out of
> an image and a instance type would be great.
> 
> Laszlo
> 
> ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Friday, January 25, 2013 1:32:20 PM
> > Subject: Re: [Engine-devel]  Instance Types Feature
> > 
> > Hi Laszlo,
> > 
> > it is not useful just for public clouds - it can be pretty useful
> > for
> > private as well. But to keep the previous way, it could be done
> > this
> > way:
> > - on the advanced screen (after clicking "show advanced options"
> > you
> > can specify the template)
> > - by default you pick on basic view the instance type (e.g. HW
> > profile) and the Image (e.g. disk with some metadata such as OS
> > type). But, you can select custom instance type (equivalent to
> >  blank template) and no Image. In this case the template appears
> > also on basic view and you can select it.
> > 
> > What do you think?
> > 
> > Tomas
> > 
> > ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, January 22, 2013 7:16:32 PM
> > Subject: Re: [Engine-devel]  Instance Types Feature
> > 
> > Hi Tomas,
> > 
> > I like the idea in general, but for me the instance types looks
> > like
> > a feature that is typical in public clouds, while in private clouds
> > it looks more like a cool extra feature for special cases.
> > Therefore
> > in my opinion it would be great to keep the old template solution
> > as
> > well to keep it simple for most users. A template could be an
> > instance type and an image together. Only the description overlap,
> > and that could be solved.
> > 
> > Thanks,
> > Laszlo
> > 
> > ----- Original Message -----
> > > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Tuesday, January 22, 2013 3:09:51 PM
> > > Subject: [Engine-devel]  Instance Types Feature
> > > 
> > > Hi All,
> > > 
> > > this is the proposed new feature called instance types:
> > > http://www.ovirt.org/Features/Instance_Types
> > > 
> > > Long story short - it should basically split the VM template
> > > into:
> > > - "hardware profile" called instance types
> > > - "software profile" called image
> > > 
> > > This should enable to do something like: Create a new "small" VM
> > > and
> > > attach a disk with "RHEL + Postgres" installed.
> > > 
> > > Any comments are more than welcome!
> > > 
> > > Tomas
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 


From jhernand at redhat.com  Wed Jan 30 15:26:25 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 30 Jan 2013 16:26:25 +0100
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <51080601.8030005@redhat.com>
References: <1725687213.4847277.1359478706903.JavaMail.root@redhat.com>
	<51080601.8030005@redhat.com>
Message-ID: <51093BA1.7060005@redhat.com>

Note that this change has just been merged. Let me know if you find any 
issue.

-- 
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 Jan 30 15:31:17 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 30 Jan 2013 10:31:17 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <51093BA1.7060005@redhat.com>
Message-ID: <989866851.5112110.1359559877990.JavaMail.root@redhat.com>


Hi,

You merge this with the rpm version to 3.3.0 which is totally invalid.
3.3.0 is a *RELEASE*.
I really don't care what maven approach is, but please do not create issues with product release cycle.

Alon

----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 30, 2013 5:26:25 PM
> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> Note that this change has just been merged. Let me know if you find
> any
> issue.
> 
> --
> 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.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From jhernand at redhat.com  Wed Jan 30 15:38:33 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 30 Jan 2013 16:38:33 +0100
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <989866851.5112110.1359559877990.JavaMail.root@redhat.com>
References: <989866851.5112110.1359559877990.JavaMail.root@redhat.com>
Message-ID: <51093E79.7000200@redhat.com>

On 01/30/2013 04:31 PM, Alon Bar-Lev wrote:
>
> Hi,
>
> You merge this with the rpm version to 3.3.0 which is totally invalid.
> 3.3.0 is a *RELEASE*.
> I really don't care what maven approach is, but please do not create issues with product release cycle.
>
> Alon

That is not true. After this patch the default RPM version is 
3.3.0-0.1.$(date +%Y%m%d%H%M%S).

>
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, January 30, 2013 5:26:25 PM
>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>
>> Note that this change has just been merged. Let me know if you find
>> any
>> issue.
>>
>> --
>> 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.
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


-- 
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 mpastern at redhat.com  Wed Jan 30 15:48:46 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 30 Jan 2013 17:48:46 +0200
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <989866851.5112110.1359559877990.JavaMail.root@redhat.com>
References: <989866851.5112110.1359559877990.JavaMail.root@redhat.com>
Message-ID: <510940DE.9020809@redhat.com>

On 01/30/2013 05:31 PM, Alon Bar-Lev wrote:
> 
> Hi,
> 
> You merge this with the rpm version to 3.3.0 which is totally invalid.
> 3.3.0 is a *RELEASE*.
> I really don't care what maven approach is, but please do not create issues with product release cycle.

There should be no issues with "product release cycle", carrying next development iteration
with [VERSION+1]-SNAPSHOT is a standard, this way people know that they working against yet
not officially released version.

release should drop -SNAPSHOT prefix and at the end of release procedure, bump version and
add -SNAPSHOT back.

> 
> Alon
> 
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, January 30, 2013 5:26:25 PM
>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>
>> Note that this change has just been merged. Let me know if you find
>> any
>> issue.
>>
>> --
>> 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.
>> _______________________________________________
>> 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 alonbl at redhat.com  Wed Jan 30 16:13:38 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 30 Jan 2013 11:13:38 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <51093E79.7000200@redhat.com>
Message-ID: <474143045.5123403.1359562418076.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 30, 2013 5:38:33 PM
> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> On 01/30/2013 04:31 PM, Alon Bar-Lev wrote:
> >
> > Hi,
> >
> > You merge this with the rpm version to 3.3.0 which is totally
> > invalid.
> > 3.3.0 is a *RELEASE*.
> > I really don't care what maven approach is, but please do not
> > create issues with product release cycle.
> >
> > Alon
> 
> That is not true. After this patch the default RPM version is
> 3.3.0-0.1.$(date +%Y%m%d%H%M%S).

3.3.0 is a release.

0.1.* is the BUILD.

And make dist produces ovirt-engine-3.3.0.tar.gz which is a release.

You are confusing between upstream and downstream, we will have to fix this before we support more distributions. 

> 
> >
> > ----- Original Message -----
> >> From: "Juan Hernandez" <jhernand at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Wednesday, January 30, 2013 5:26:25 PM
> >> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>
> >> Note that this change has just been merged. Let me know if you
> >> find
> >> any
> >> issue.
> >>
> >> --
> >> 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.
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 
> --
> 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  Wed Jan 30 16:30:55 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 30 Jan 2013 17:30:55 +0100
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <474143045.5123403.1359562418076.JavaMail.root@redhat.com>
References: <474143045.5123403.1359562418076.JavaMail.root@redhat.com>
Message-ID: <51094ABF.1080704@redhat.com>

On 01/30/2013 05:13 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, January 30, 2013 5:38:33 PM
>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>
>> On 01/30/2013 04:31 PM, Alon Bar-Lev wrote:
>>>
>>> Hi,
>>>
>>> You merge this with the rpm version to 3.3.0 which is totally
>>> invalid.
>>> 3.3.0 is a *RELEASE*.
>>> I really don't care what maven approach is, but please do not
>>> create issues with product release cycle.
>>>
>>> Alon
>>
>> That is not true. After this patch the default RPM version is
>> 3.3.0-0.1.$(date +%Y%m%d%H%M%S).
>
> 3.3.0 is a release.
>
> 0.1.* is the BUILD.

In RPM terms 3.3.0 is the "version", and "0.1.*" is the "release", see here:

[1] http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html

> And make dist produces ovirt-engine-3.3.0.tar.gz which is a release.

ovirt-engine-3.3.0.tar.gz is not a release, it is just the name of a tar 
file generated by the makefile. The release is the act of the release 
managers, on behalf of the community, announcing and publishing some 
artifacts, maybe including a tarball generated with the makefile, maybe 
one generated manually, as they see fit.

> You are confusing between upstream and downstream, we will have to fix this before we support more distributions.

I may be confused, of course, but I don't see the connection between the 
name of the tarball generated by the makefile and supporting more 
distributions, looks to me like the least important thing in these regards.

>
>>
>>>
>>> ----- Original Message -----
>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Wednesday, January 30, 2013 5:26:25 PM
>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>
>>>> Note that this change has just been merged. Let me know if you
>>>> find
>>>> any
>>>> issue.

-- 
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 Jan 30 16:33:02 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 30 Jan 2013 11:33:02 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <51094ABF.1080704@redhat.com>
Message-ID: <2045775646.5128350.1359563582546.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 30, 2013 6:30:55 PM
> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> On 01/30/2013 05:13 PM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Juan Hernandez" <jhernand at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Wednesday, January 30, 2013 5:38:33 PM
> >> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>
> >> On 01/30/2013 04:31 PM, Alon Bar-Lev wrote:
> >>>
> >>> Hi,
> >>>
> >>> You merge this with the rpm version to 3.3.0 which is totally
> >>> invalid.
> >>> 3.3.0 is a *RELEASE*.
> >>> I really don't care what maven approach is, but please do not
> >>> create issues with product release cycle.
> >>>
> >>> Alon
> >>
> >> That is not true. After this patch the default RPM version is
> >> 3.3.0-0.1.$(date +%Y%m%d%H%M%S).
> >
> > 3.3.0 is a release.
> >
> > 0.1.* is the BUILD.
> 
> In RPM terms 3.3.0 is the "version", and "0.1.*" is the "release",
> see here:
> 
> [1] http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html
> 
> > And make dist produces ovirt-engine-3.3.0.tar.gz which is a
> > release.
> 
> ovirt-engine-3.3.0.tar.gz is not a release, it is just the name of a
> tar
> file generated by the makefile. The release is the act of the release
> managers, on behalf of the community, announcing and publishing some
> artifacts, maybe including a tarball generated with the makefile,
> maybe
> one generated manually, as they see fit.

This where you are wrong, the name of the source tarball is very important in open source, as this is what open source project actually releases.

We will discuss this offline.

> 
> > You are confusing between upstream and downstream, we will have to
> > fix this before we support more distributions.
> 
> I may be confused, of course, but I don't see the connection between
> the
> name of the tarball generated by the makefile and supporting more
> distributions, looks to me like the least important thing in these
> regards.
> 
> >
> >>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>> Cc: engine-devel at ovirt.org
> >>>> Sent: Wednesday, January 30, 2013 5:26:25 PM
> >>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>>
> >>>> Note that this change has just been merged. Let me know if you
> >>>> find
> >>>> any
> >>>> issue.
> 
> --
> 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  Wed Jan 30 16:49:10 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 30 Jan 2013 17:49:10 +0100
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <2045775646.5128350.1359563582546.JavaMail.root@redhat.com>
References: <2045775646.5128350.1359563582546.JavaMail.root@redhat.com>
Message-ID: <51094F06.4080707@redhat.com>

On 01/30/2013 05:33 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, January 30, 2013 6:30:55 PM
>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>
>> On 01/30/2013 05:13 PM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Wednesday, January 30, 2013 5:38:33 PM
>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>
>>>> On 01/30/2013 04:31 PM, Alon Bar-Lev wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> You merge this with the rpm version to 3.3.0 which is totally
>>>>> invalid.
>>>>> 3.3.0 is a *RELEASE*.
>>>>> I really don't care what maven approach is, but please do not
>>>>> create issues with product release cycle.
>>>>>
>>>>> Alon
>>>>
>>>> That is not true. After this patch the default RPM version is
>>>> 3.3.0-0.1.$(date +%Y%m%d%H%M%S).
>>>
>>> 3.3.0 is a release.
>>>
>>> 0.1.* is the BUILD.
>>
>> In RPM terms 3.3.0 is the "version", and "0.1.*" is the "release",
>> see here:
>>
>> [1] http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html
>>
>>> And make dist produces ovirt-engine-3.3.0.tar.gz which is a
>>> release.
>>
>> ovirt-engine-3.3.0.tar.gz is not a release, it is just the name of a
>> tar
>> file generated by the makefile. The release is the act of the release
>> managers, on behalf of the community, announcing and publishing some
>> artifacts, maybe including a tarball generated with the makefile,
>> maybe
>> one generated manually, as they see fit.
>
> This where you are wrong, the name of the source tarball is very important in open source, as this is what open source project actually releases.

The name of the tarball that is published as part of the release is 
important, that I agree, maybe not "very" important, but important 
anyhow. But what you are saying is that if the name of the file 
generated by default by the Makefile is not exactly the same as the 
tarball that will be published as part of the release then it is 
"totally invalid". That is going too far, in my opinion.

>
> We will discuss this offline.
>
>>
>>> You are confusing between upstream and downstream, we will have to
>>> fix this before we support more distributions.
>>
>> I may be confused, of course, but I don't see the connection between
>> the
>> name of the tarball generated by the makefile and supporting more
>> distributions, looks to me like the least important thing in these
>> regards.
>>
>>>
>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>>> Cc: engine-devel at ovirt.org
>>>>>> Sent: Wednesday, January 30, 2013 5:26:25 PM
>>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>>>
>>>>>> Note that this change has just been merged. Let me know if you
>>>>>> find
>>>>>> any
>>>>>> issue.
>>
>> --
>> 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.
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


-- 
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 Jan 30 16:58:35 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 30 Jan 2013 11:58:35 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <51094F06.4080707@redhat.com>
Message-ID: <1006277839.5134258.1359565115532.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 30, 2013 6:49:10 PM
> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> On 01/30/2013 05:33 PM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Juan Hernandez" <jhernand at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Wednesday, January 30, 2013 6:30:55 PM
> >> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>
> >> On 01/30/2013 05:13 PM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>> Cc: engine-devel at ovirt.org
> >>>> Sent: Wednesday, January 30, 2013 5:38:33 PM
> >>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>>
> >>>> On 01/30/2013 04:31 PM, Alon Bar-Lev wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> You merge this with the rpm version to 3.3.0 which is totally
> >>>>> invalid.
> >>>>> 3.3.0 is a *RELEASE*.
> >>>>> I really don't care what maven approach is, but please do not
> >>>>> create issues with product release cycle.
> >>>>>
> >>>>> Alon
> >>>>
> >>>> That is not true. After this patch the default RPM version is
> >>>> 3.3.0-0.1.$(date +%Y%m%d%H%M%S).
> >>>
> >>> 3.3.0 is a release.
> >>>
> >>> 0.1.* is the BUILD.
> >>
> >> In RPM terms 3.3.0 is the "version", and "0.1.*" is the "release",
> >> see here:
> >>
> >> [1] http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html
> >>
> >>> And make dist produces ovirt-engine-3.3.0.tar.gz which is a
> >>> release.
> >>
> >> ovirt-engine-3.3.0.tar.gz is not a release, it is just the name of
> >> a
> >> tar
> >> file generated by the makefile. The release is the act of the
> >> release
> >> managers, on behalf of the community, announcing and publishing
> >> some
> >> artifacts, maybe including a tarball generated with the makefile,
> >> maybe
> >> one generated manually, as they see fit.
> >
> > This where you are wrong, the name of the source tarball is very
> > important in open source, as this is what open source project
> > actually releases.
> 
> The name of the tarball that is published as part of the release is
> important, that I agree, maybe not "very" important, but important
> anyhow. But what you are saying is that if the name of the file
> generated by default by the Makefile is not exactly the same as the
> tarball that will be published as part of the release then it is
> "totally invalid". That is going too far, in my opinion.

It is important as the version not only appear at the tarball but within resources such as script --version or Help->About.

It is also important as people generate their own builds from tags, and expect to get proper version of tarball and content within.

This is not new, this is common to most of the open source world, oVirt is the exception in this case.

Why do we want to be an exception?

> 
> >
> > We will discuss this offline.
> >
> >>
> >>> You are confusing between upstream and downstream, we will have
> >>> to
> >>> fix this before we support more distributions.
> >>
> >> I may be confused, of course, but I don't see the connection
> >> between
> >> the
> >> name of the tarball generated by the makefile and supporting more
> >> distributions, looks to me like the least important thing in these
> >> regards.
> >>
> >>>
> >>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>>>> Cc: engine-devel at ovirt.org
> >>>>>> Sent: Wednesday, January 30, 2013 5:26:25 PM
> >>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>>>>
> >>>>>> Note that this change has just been merged. Let me know if you
> >>>>>> find
> >>>>>> any
> >>>>>> issue.
> >>
> >> --
> >> 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.
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> --
> 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  Wed Jan 30 17:17:11 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 30 Jan 2013 18:17:11 +0100
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <1006277839.5134258.1359565115532.JavaMail.root@redhat.com>
References: <1006277839.5134258.1359565115532.JavaMail.root@redhat.com>
Message-ID: <51095597.9050302@redhat.com>

On 01/30/2013 05:58 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, January 30, 2013 6:49:10 PM
>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>
>> On 01/30/2013 05:33 PM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Wednesday, January 30, 2013 6:30:55 PM
>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>
>>>> On 01/30/2013 05:13 PM, Alon Bar-Lev wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>> Cc: engine-devel at ovirt.org
>>>>>> Sent: Wednesday, January 30, 2013 5:38:33 PM
>>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>>>
>>>>>> On 01/30/2013 04:31 PM, Alon Bar-Lev wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> You merge this with the rpm version to 3.3.0 which is totally
>>>>>>> invalid.
>>>>>>> 3.3.0 is a *RELEASE*.
>>>>>>> I really don't care what maven approach is, but please do not
>>>>>>> create issues with product release cycle.
>>>>>>>
>>>>>>> Alon
>>>>>>
>>>>>> That is not true. After this patch the default RPM version is
>>>>>> 3.3.0-0.1.$(date +%Y%m%d%H%M%S).
>>>>>
>>>>> 3.3.0 is a release.
>>>>>
>>>>> 0.1.* is the BUILD.
>>>>
>>>> In RPM terms 3.3.0 is the "version", and "0.1.*" is the "release",
>>>> see here:
>>>>
>>>> [1] http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html
>>>>
>>>>> And make dist produces ovirt-engine-3.3.0.tar.gz which is a
>>>>> release.
>>>>
>>>> ovirt-engine-3.3.0.tar.gz is not a release, it is just the name of
>>>> a
>>>> tar
>>>> file generated by the makefile. The release is the act of the
>>>> release
>>>> managers, on behalf of the community, announcing and publishing
>>>> some
>>>> artifacts, maybe including a tarball generated with the makefile,
>>>> maybe
>>>> one generated manually, as they see fit.
>>>
>>> This where you are wrong, the name of the source tarball is very
>>> important in open source, as this is what open source project
>>> actually releases.
>>
>> The name of the tarball that is published as part of the release is
>> important, that I agree, maybe not "very" important, but important
>> anyhow. But what you are saying is that if the name of the file
>> generated by default by the Makefile is not exactly the same as the
>> tarball that will be published as part of the release then it is
>> "totally invalid". That is going too far, in my opinion.
>
> It is important as the version not only appear at the tarball but within resources such as script --version or Help->About.
>
> It is also important as people generate their own builds from tags, and expect to get proper version of tarball and content within.
>
> This is not new, this is common to most of the open source world, oVirt is the exception in this case.

All of those are nice goals. None of them has been made impossible by 
this patch, only that we are using a cleaner maven versioning schema, 
which is also a nice goal.

>
> Why do we want to be an exception?
>
>>
>>>
>>> We will discuss this offline.
>>>
>>>>
>>>>> You are confusing between upstream and downstream, we will have
>>>>> to
>>>>> fix this before we support more distributions.
>>>>
>>>> I may be confused, of course, but I don't see the connection
>>>> between
>>>> the
>>>> name of the tarball generated by the makefile and supporting more
>>>> distributions, looks to me like the least important thing in these
>>>> regards.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>> Sent: Wednesday, January 30, 2013 5:26:25 PM
>>>>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>>>>>
>>>>>>>> Note that this change has just been merged. Let me know if you
>>>>>>>> find
>>>>>>>> any
>>>>>>>> issue.
>>>>
>>>> --
>>>> 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.
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>>
>> --
>> 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.
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


-- 
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 Jan 30 17:22:56 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 30 Jan 2013 12:22:56 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <51095597.9050302@redhat.com>
Message-ID: <252485858.5140104.1359566576496.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 30, 2013 7:17:11 PM
> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> On 01/30/2013 05:58 PM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Juan Hernandez" <jhernand at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Wednesday, January 30, 2013 6:49:10 PM
> >> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>
> >> On 01/30/2013 05:33 PM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>> Cc: engine-devel at ovirt.org
> >>>> Sent: Wednesday, January 30, 2013 6:30:55 PM
> >>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>>
> >>>> On 01/30/2013 05:13 PM, Alon Bar-Lev wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>> Cc: engine-devel at ovirt.org
> >>>>>> Sent: Wednesday, January 30, 2013 5:38:33 PM
> >>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>>>>
> >>>>>> On 01/30/2013 04:31 PM, Alon Bar-Lev wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> You merge this with the rpm version to 3.3.0 which is totally
> >>>>>>> invalid.
> >>>>>>> 3.3.0 is a *RELEASE*.
> >>>>>>> I really don't care what maven approach is, but please do not
> >>>>>>> create issues with product release cycle.
> >>>>>>>
> >>>>>>> Alon
> >>>>>>
> >>>>>> That is not true. After this patch the default RPM version is
> >>>>>> 3.3.0-0.1.$(date +%Y%m%d%H%M%S).
> >>>>>
> >>>>> 3.3.0 is a release.
> >>>>>
> >>>>> 0.1.* is the BUILD.
> >>>>
> >>>> In RPM terms 3.3.0 is the "version", and "0.1.*" is the
> >>>> "release",
> >>>> see here:
> >>>>
> >>>> [1] http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html
> >>>>
> >>>>> And make dist produces ovirt-engine-3.3.0.tar.gz which is a
> >>>>> release.
> >>>>
> >>>> ovirt-engine-3.3.0.tar.gz is not a release, it is just the name
> >>>> of
> >>>> a
> >>>> tar
> >>>> file generated by the makefile. The release is the act of the
> >>>> release
> >>>> managers, on behalf of the community, announcing and publishing
> >>>> some
> >>>> artifacts, maybe including a tarball generated with the
> >>>> makefile,
> >>>> maybe
> >>>> one generated manually, as they see fit.
> >>>
> >>> This where you are wrong, the name of the source tarball is very
> >>> important in open source, as this is what open source project
> >>> actually releases.
> >>
> >> The name of the tarball that is published as part of the release
> >> is
> >> important, that I agree, maybe not "very" important, but important
> >> anyhow. But what you are saying is that if the name of the file
> >> generated by default by the Makefile is not exactly the same as
> >> the
> >> tarball that will be published as part of the release then it is
> >> "totally invalid". That is going too far, in my opinion.
> >
> > It is important as the version not only appear at the tarball but
> > within resources such as script --version or Help->About.
> >
> > It is also important as people generate their own builds from tags,
> > and expect to get proper version of tarball and content within.
> >
> > This is not new, this is common to most of the open source world,
> > oVirt is the exception in this case.
> 
> All of those are nice goals. None of them has been made impossible by
> this patch, only that we are using a cleaner maven versioning schema,
> which is also a nice goal.
>

The maven version is not exposed to the outside world, for all I know it can be 0.0.0 for all past and future versions.
Creating a relation between the maven version and the packaging version and not vise versa was what I discussed before you applied this patch, and you are CC on the discussions regarding that.
I would have preferred we set proper versioning scheme for 3.3.0 for the entire package.
Of course we can fix everything, remove the published snapshots, and start over, I would have liked to avoid that.
 
> >
> > Why do we want to be an exception?
> >
> >>
> >>>
> >>> We will discuss this offline.
> >>>
> >>>>
> >>>>> You are confusing between upstream and downstream, we will have
> >>>>> to
> >>>>> fix this before we support more distributions.
> >>>>
> >>>> I may be confused, of course, but I don't see the connection
> >>>> between
> >>>> the
> >>>> name of the tarball generated by the makefile and supporting
> >>>> more
> >>>> distributions, looks to me like the least important thing in
> >>>> these
> >>>> regards.
> >>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>>>>>> Cc: engine-devel at ovirt.org
> >>>>>>>> Sent: Wednesday, January 30, 2013 5:26:25 PM
> >>>>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>>>>>>
> >>>>>>>> Note that this change has just been merged. Let me know if
> >>>>>>>> you
> >>>>>>>> find
> >>>>>>>> any
> >>>>>>>> issue.
> >>>>
> >>>> --
> >>>> 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.
> >>>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>
> >>
> >> --
> >> 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.
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> --
> 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 lhornyak at redhat.com  Wed Jan 30 17:43:34 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 30 Jan 2013 12:43:34 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <252485858.5140104.1359566576496.JavaMail.root@redhat.com>
Message-ID: <724188235.7796886.1359567814825.JavaMail.root@redhat.com>

Hi Alon,

> 
> The maven version is not exposed to the outside world, for all I know
> it can be 0.0.0 for all past and future versions.

Not that I want to join the flamewar :) but the maven version should be exposed to the outside world when we publish maven artifacts. I think the best candidate is the rest-api client, but also (in the future) backend plugin projects. I do not think java developers will want to resolve those artifacts from RPM packages... on Mac os X for example.

0.0.0 will not be OK for all the versions, because it will not be refreshed after its first succesful download. I think you know this, since you created and published into the ovirt maven repo at sonatype for otopi.

> Creating a relation between the maven version and the packaging
> version and not vise versa was what I discussed before you applied
> this patch, and you are CC on the discussions regarding that.
> I would have preferred we set proper versioning scheme for 3.3.0 for
> the entire package.
> Of course we can fix everything, remove the published snapshots, and
> start over, I would have liked to avoid that.
>  

Why don't you just send a patch that fixes the linux packaging issue?

Than you,
Laszlo


From jhernand at redhat.com  Wed Jan 30 17:44:42 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 30 Jan 2013 18:44:42 +0100
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <252485858.5140104.1359566576496.JavaMail.root@redhat.com>
References: <252485858.5140104.1359566576496.JavaMail.root@redhat.com>
Message-ID: <51095C0A.8030807@redhat.com>

On 01/30/2013 06:22 PM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Juan Hernandez" <jhernand at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, January 30, 2013 7:17:11 PM
>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>
>> On 01/30/2013 05:58 PM, Alon Bar-Lev wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Wednesday, January 30, 2013 6:49:10 PM
>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>
>>>> On 01/30/2013 05:33 PM, Alon Bar-Lev wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>> Cc: engine-devel at ovirt.org
>>>>>> Sent: Wednesday, January 30, 2013 6:30:55 PM
>>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>>>
>>>>>> On 01/30/2013 05:13 PM, Alon Bar-Lev wrote:
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>> Sent: Wednesday, January 30, 2013 5:38:33 PM
>>>>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>>>>>
>>>>>>>> On 01/30/2013 04:31 PM, Alon Bar-Lev wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> You merge this with the rpm version to 3.3.0 which is totally
>>>>>>>>> invalid.
>>>>>>>>> 3.3.0 is a *RELEASE*.
>>>>>>>>> I really don't care what maven approach is, but please do not
>>>>>>>>> create issues with product release cycle.
>>>>>>>>>
>>>>>>>>> Alon
>>>>>>>>
>>>>>>>> That is not true. After this patch the default RPM version is
>>>>>>>> 3.3.0-0.1.$(date +%Y%m%d%H%M%S).
>>>>>>>
>>>>>>> 3.3.0 is a release.
>>>>>>>
>>>>>>> 0.1.* is the BUILD.
>>>>>>
>>>>>> In RPM terms 3.3.0 is the "version", and "0.1.*" is the
>>>>>> "release",
>>>>>> see here:
>>>>>>
>>>>>> [1] http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html
>>>>>>
>>>>>>> And make dist produces ovirt-engine-3.3.0.tar.gz which is a
>>>>>>> release.
>>>>>>
>>>>>> ovirt-engine-3.3.0.tar.gz is not a release, it is just the name
>>>>>> of
>>>>>> a
>>>>>> tar
>>>>>> file generated by the makefile. The release is the act of the
>>>>>> release
>>>>>> managers, on behalf of the community, announcing and publishing
>>>>>> some
>>>>>> artifacts, maybe including a tarball generated with the
>>>>>> makefile,
>>>>>> maybe
>>>>>> one generated manually, as they see fit.
>>>>>
>>>>> This where you are wrong, the name of the source tarball is very
>>>>> important in open source, as this is what open source project
>>>>> actually releases.
>>>>
>>>> The name of the tarball that is published as part of the release
>>>> is
>>>> important, that I agree, maybe not "very" important, but important
>>>> anyhow. But what you are saying is that if the name of the file
>>>> generated by default by the Makefile is not exactly the same as
>>>> the
>>>> tarball that will be published as part of the release then it is
>>>> "totally invalid". That is going too far, in my opinion.
>>>
>>> It is important as the version not only appear at the tarball but
>>> within resources such as script --version or Help->About.
>>>
>>> It is also important as people generate their own builds from tags,
>>> and expect to get proper version of tarball and content within.
>>>
>>> This is not new, this is common to most of the open source world,
>>> oVirt is the exception in this case.
>>
>> All of those are nice goals. None of them has been made impossible by
>> this patch, only that we are using a cleaner maven versioning schema,
>> which is also a nice goal.
>>
>
> The maven version is not exposed to the outside world, for all I know it can be 0.0.0 for all past and future versions.

The maven version is exposed to the outside world, not much today, only 
that the POM files are published in every installation done in Fedora. 
And it will be much more exposed in the future, when other people starts 
to develop components based in our (yet to be created) plugin 
infrastructure. So it can't be 0.0.0 for all versions.

> Creating a relation between the maven version and the packaging version and not vise versa was what I discussed before you applied this patch, and you are CC on the discussions regarding that.

This patch didn't create any relation between maven and packaging 
version, it was already there, and I think is reasonable to have it (to 
the extent that packaging systems allow). So if a decision is made to 
release 3.3.0-beta2, for example, the corresponding branch should have a 
patch to change the maven version to 3.3.0-beta2, and the packaging 
version to 3.3.0-beta2 as well.

> I would have preferred we set proper versioning scheme for 3.3.0 for the entire package.
> Of course we can fix everything, remove the published snapshots, and start over, I would have liked to avoid that.
>

What do you mean by "published snapshots"? As far as I know we don't 
publish maven artifacts to any public repository at the moment. Or do 
you mean nightly builds?

>>>
>>> Why do we want to be an exception?
>>>
>>>>
>>>>>
>>>>> We will discuss this offline.
>>>>>
>>>>>>
>>>>>>> You are confusing between upstream and downstream, we will have
>>>>>>> to
>>>>>>> fix this before we support more distributions.
>>>>>>
>>>>>> I may be confused, of course, but I don't see the connection
>>>>>> between
>>>>>> the
>>>>>> name of the tarball generated by the makefile and supporting
>>>>>> more
>>>>>> distributions, looks to me like the least important thing in
>>>>>> these
>>>>>> regards.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>>>> Sent: Wednesday, January 30, 2013 5:26:25 PM
>>>>>>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
>>>>>>>>>>
>>>>>>>>>> Note that this change has just been merged. Let me know if
>>>>>>>>>> you
>>>>>>>>>> find
>>>>>>>>>> any
>>>>>>>>>> issue.


-- 
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 Jan 30 17:54:53 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Wed, 30 Jan 2013 12:54:53 -0500 (EST)
Subject: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
In-Reply-To: <51095C0A.8030807@redhat.com>
Message-ID: <1905678209.5154384.1359568493593.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 30, 2013 7:44:42 PM
> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> 
> On 01/30/2013 06:22 PM, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Juan Hernandez" <jhernand at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Wednesday, January 30, 2013 7:17:11 PM
> >> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>
> >> On 01/30/2013 05:58 PM, Alon Bar-Lev wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>> Cc: engine-devel at ovirt.org
> >>>> Sent: Wednesday, January 30, 2013 6:49:10 PM
> >>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>>
> >>>> On 01/30/2013 05:33 PM, Alon Bar-Lev wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>> Cc: engine-devel at ovirt.org
> >>>>>> Sent: Wednesday, January 30, 2013 6:30:55 PM
> >>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>>>>
> >>>>>> On 01/30/2013 05:13 PM, Alon Bar-Lev wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>>>>> Cc: engine-devel at ovirt.org
> >>>>>>>> Sent: Wednesday, January 30, 2013 5:38:33 PM
> >>>>>>>> Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
> >>>>>>>>
> >>>>>>>> On 01/30/2013 04:31 PM, Alon Bar-Lev wrote:
> >>>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> You merge this with the rpm version to 3.3.0 which is
> >>>>>>>>> totally
> >>>>>>>>> invalid.
> >>>>>>>>> 3.3.0 is a *RELEASE*.
> >>>>>>>>> I really don't care what maven approach is, but please do
> >>>>>>>>> not
> >>>>>>>>> create issues with product release cycle.
> >>>>>>>>>
> >>>>>>>>> Alon
> >>>>>>>>
> >>>>>>>> That is not true. After this patch the default RPM version
> >>>>>>>> is
> >>>>>>>> 3.3.0-0.1.$(date +%Y%m%d%H%M%S).
> >>>>>>>
> >>>>>>> 3.3.0 is a release.
> >>>>>>>
> >>>>>>> 0.1.* is the BUILD.
> >>>>>>
> >>>>>> In RPM terms 3.3.0 is the "version", and "0.1.*" is the
> >>>>>> "release",
> >>>>>> see here:
> >>>>>>
> >>>>>> [1] http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html
> >>>>>>
> >>>>>>> And make dist produces ovirt-engine-3.3.0.tar.gz which is a
> >>>>>>> release.
> >>>>>>
> >>>>>> ovirt-engine-3.3.0.tar.gz is not a release, it is just the
> >>>>>> name
> >>>>>> of
> >>>>>> a
> >>>>>> tar
> >>>>>> file generated by the makefile. The release is the act of the
> >>>>>> release
> >>>>>> managers, on behalf of the community, announcing and
> >>>>>> publishing
> >>>>>> some
> >>>>>> artifacts, maybe including a tarball generated with the
> >>>>>> makefile,
> >>>>>> maybe
> >>>>>> one generated manually, as they see fit.
> >>>>>
> >>>>> This where you are wrong, the name of the source tarball is
> >>>>> very
> >>>>> important in open source, as this is what open source project
> >>>>> actually releases.
> >>>>
> >>>> The name of the tarball that is published as part of the release
> >>>> is
> >>>> important, that I agree, maybe not "very" important, but
> >>>> important
> >>>> anyhow. But what you are saying is that if the name of the file
> >>>> generated by default by the Makefile is not exactly the same as
> >>>> the
> >>>> tarball that will be published as part of the release then it is
> >>>> "totally invalid". That is going too far, in my opinion.
> >>>
> >>> It is important as the version not only appear at the tarball but
> >>> within resources such as script --version or Help->About.
> >>>
> >>> It is also important as people generate their own builds from
> >>> tags,
> >>> and expect to get proper version of tarball and content within.
> >>>
> >>> This is not new, this is common to most of the open source world,
> >>> oVirt is the exception in this case.
> >>
> >> All of those are nice goals. None of them has been made impossible
> >> by
> >> this patch, only that we are using a cleaner maven versioning
> >> schema,
> >> which is also a nice goal.
> >>
> >
> > The maven version is not exposed to the outside world, for all I
> > know it can be 0.0.0 for all past and future versions.
> 
> The maven version is exposed to the outside world, not much today,
> only
> that the POM files are published in every installation done in
> Fedora.
> And it will be much more exposed in the future, when other people
> starts
> to develop components based in our (yet to be created) plugin
> infrastructure. So it can't be 0.0.0 for all versions.

When we make public API, we stabilize an interface and publish versioned artifacts.

Please notice that the version will not be the product version but the interface version.
For example engine-api-1.0.0 will be available at ovirt-engine-3.2.0, ovirt-engine-3.3.0 and ovirt-engine-4.0.0, as what the developer cares about is the interface version and not the product version.
 
We do not have any consumer right now, so maven version is not important, nor the snapshot attribute used now.
So as far as I understand the maven version is "also a nice goal" but does not has any actual effect.

> 
> > Creating a relation between the maven version and the packaging
> > version and not vise versa was what I discussed before you applied
> > this patch, and you are CC on the discussions regarding that.
> 
> This patch didn't create any relation between maven and packaging
> version, it was already there, and I think is reasonable to have it
> (to
> the extent that packaging systems allow). So if a decision is made to
> release 3.3.0-beta2, for example, the corresponding branch should
> have a
> patch to change the maven version to 3.3.0-beta2, and the packaging
> version to 3.3.0-beta2 as well.

I will create such a patch, after we complete the discussion.

> 
> > I would have preferred we set proper versioning scheme for 3.3.0
> > for the entire package.
> > Of course we can fix everything, remove the published snapshots,
> > and start over, I would have liked to avoid that.
> >
> 
> What do you mean by "published snapshots"? As far as I know we don't
> publish maven artifacts to any public repository at the moment. Or do
> you mean nightly builds?

Yes.
Again, I don't care about maven, as long as not use by any other component it is meaningless.

> 
> >>>
> >>> Why do we want to be an exception?
> >>>
> >>>>
> >>>>>
> >>>>> We will discuss this offline.
> >>>>>
> >>>>>>
> >>>>>>> You are confusing between upstream and downstream, we will
> >>>>>>> have
> >>>>>>> to
> >>>>>>> fix this before we support more distributions.
> >>>>>>
> >>>>>> I may be confused, of course, but I don't see the connection
> >>>>>> between
> >>>>>> the
> >>>>>> name of the tarball generated by the makefile and supporting
> >>>>>> more
> >>>>>> distributions, looks to me like the least important thing in
> >>>>>> these
> >>>>>> regards.
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
> >>>>>>>>>> Cc: engine-devel at ovirt.org
> >>>>>>>>>> Sent: Wednesday, January 30, 2013 5:26:25 PM
> >>>>>>>>>> Subject: Re: [Engine-devel] Time to move to
> >>>>>>>>>> 3.3.0-SNAPSHOT?
> >>>>>>>>>>
> >>>>>>>>>> Note that this change has just been merged. Let me know if
> >>>>>>>>>> you
> >>>>>>>>>> find
> >>>>>>>>>> any
> >>>>>>>>>> issue.
> 
> 
> --
> 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 masayag at redhat.com  Wed Jan 30 22:50:13 2013
From: masayag at redhat.com (Moti Asayag)
Date: Thu, 31 Jan 2013 00:50:13 +0200
Subject: [Engine-devel] Java process increasing resident memory
In-Reply-To: <CAKVd3pX+PYi5WZccz01uudFEU3K_Y=xshOfJtaisHHE3cqXbww@mail.gmail.com>
References: <CAKVd3pX+PYi5WZccz01uudFEU3K_Y=xshOfJtaisHHE3cqXbww@mail.gmail.com>
Message-ID: <5109A3A5.3080309@redhat.com>

On 01/29/2013 10:27 AM, navin p wrote:
> Hi,
>   I wrote this sample code and the resident memory of the process is
> increasing gradually over time. What could be the reason ? I don't see
> any obvious leaks in my program. Could it be that the API is not
> freeing/deleting memory ?

By monitoring the program, it seems that the failure is due to constant
threads creation by invoking the "new API()" call:

Exception in thread "main" java.lang.OutOfMemoryError: unable to create
new native thread
        at java.lang.Thread.start0(Native Method)
        at java.lang.Thread.start(Thread.java:691)
        at
org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.createPoolingClientConnectionManager(ConnectionsPoolBuilder.java:182)
        at
org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.createDefaultHttpClient(ConnectionsPoolBuilder.java:160)
        at
org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.build(ConnectionsPoolBuilder.java:234)
        at org.ovirt.engine.sdk.Api.<init>(Api.java:82)
        at collectHosts.main(collectHosts.java:102)


By pulling the API instantiation outside of the loop, problem solved,
since only a single thread is created to monitor the idle/expired
connections.


Michael, wouldn't you suggest adding some sort of API.shutdown() method
in order to release resources used by it including the connection
monitor and any other live connections if exists?

> 
> Regards,
> Navin
> 
> 
> 
> package ovcollector;
> 
> 
> 
> import java.util.*;
> import java.io.*;
> import java.lang.management.ManagementFactory;
> 
> import org.apache.http.client.*;
> import org.apache.http.params.*;
> import org.ovirt.engine.sdk.Api;
> import org.apache.http.pool.*;
> import org.ovirt.engine.sdk.decorators.Host;
> import org.ovirt.engine.sdk.decorators.HostStatistic;
> import org.ovirt.engine.sdk.decorators.StorageDomain;
> import org.ovirt.engine.sdk.decorators.VM;
> import org.ovirt.engine.sdk.decorators.VMDisk;
> import org.ovirt.engine.sdk.decorators.VMDiskStatistic;
> import org.ovirt.engine.sdk.decorators.VMStatistic;
> import org.ovirt.engine.sdk.decorators.VMs;
> import org.ovirt.engine.sdk.entities.CPU;
> import org.ovirt.engine.sdk.entities.Value;
> import org.ovirt.engine.sdk.exceptions.ServerException;
> import org.ovirt.engine.sdk.exceptions.UnsecuredConnectionAttemptError;
> import org.ovirt.engine.*;
> 
> import javax.swing.JFrame;
> import javax.swing.JPanel;
> import javax.swing.JScrollPane;
> import javax.swing.JTable;
> import java.awt.Dimension;
> import java.awt.GridLayout;
> import java.awt.event.MouseAdapter;
> import java.awt.event.MouseEvent;
> 
> 
> public class collectHosts extends JPanel {
> 
> /**
> * @param args
> */
> public static String[] columnNames = {"Host Name",
>            "Host uuid",
>            "Cpu Cores", "Cpu Sockets",
>            "Memory.total",
>            "Memory.used",
>            "Memory.free",
>          
>  "Memory.shared","Memory.buffers","Memory.cached","swap.total","swap.free","swap.used","swap.cached","ksm.cpu.current",
>          
>  "cpu.current.user","cpu.current.system","cpu.current.idle","cpu.load.avg.5m"
>            };
> 
> public static Object[][] data = 
> {
> {"blankvmname", "blankuuid", new Double(0),new Double(0),new
> Double(0),new Double(0),new Double(0),new Double(0),new Double(0), new
> Double(0),
> new Double(0),new Double(0),new Double(0),new Double(0),new
> Double(0),new Double(0),new Double(0),new Double(0),new Double(0)},
> {"blankvmname", "blankuuid", new Double(0),new Double(0),new
> Double(0),new Double(0),new Double(0),new Double(0),new Double(0), new
> Double(0),
> new Double(0),new Double(0),new Double(0),new Double(0),new
> Double(0),new Double(0),new Double(0),new Double(0),new Double(0)}
> };
> public collectHosts() {
>        super(new GridLayout(1,0));
>  
>        
>  
>        final JTable table = new JTable(data, columnNames);
>        table.setPreferredScrollableViewportSize(new Dimension(500, 70));
>        table.setFillsViewportHeight(true);
>  
>  
>        //Create the scroll pane and add the table to it.
>        JScrollPane scrollPane = new JScrollPane(table);
>  
>        //Add the scroll pane to this panel.
>        add(scrollPane);
>    }
>  
> 
>  /**
>     * Create the GUI and show it.  For thread safety,
>     * this method should be invoked from the
>     * event-dispatching thread.
>     */
>    private static void createAndShowGUI() {
>        //Create and set up the window.
>        JFrame frame = new JFrame("Hosts");
>        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>  
>        //Create and set up the content pane.
>        collectHosts newContentPane = new collectHosts();
>        newContentPane.setOpaque(true); //content panes must be opaque
>        frame.setContentPane(newContentPane);
>  
>        //Display the window.
>        frame.pack();
>        frame.setVisible(true);
>    }
> 
> private static final String URL = "http://somehost:80/api";
> public static void main(String[] args) throws
> ClientProtocolException,ServerException,
> UnsecuredConnectionAttemptError,IOException {
> // TODO Auto-generated method stub
> System.out.println("Hosts");
> 
> while (true)
> {
> Api  api = new Api(URL,"SOMEUSERNAME","SOMEPASSWORD");
> System.out.println(ManagementFactory.getRuntimeMXBean().getName()) ;
> List<Host>  hlist = api.getHosts().list();
> Integer i=0,j=0;
> for(Host obj: hlist)
> {
> j=0;
> System.out.println(obj.getName()+ ":" + obj.getId() +":"+
> obj.getMemory()+":" + obj.getCpu().getTopology().getCores() +":"+
> obj.getCpu().getTopology().getSockets());
> data[i][j++]=obj.getName();
> data[i][j++]=obj.getId();
> data[i][j++]=obj.getCpu().getTopology().getCores();
> data[i][j++]=obj.getCpu().getTopology().getSockets();
> List<HostStatistic> lhs=obj.getStatistics().list();
> for(HostStatistic obj1: lhs)
> {
> System.out.println(obj1.getName());
> List<Value> vll=obj1.getValues().getValues();
> for(Value vl:vll)
> {
> System.out.println(vl.getDatum());
> data[i][j++]=vl.getDatum();
> }
> }
> i++;
> }
> try {
> Thread.sleep(10000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> /*
> javax.swing.SwingUtilities.invokeLater(new Runnable() {
> public void run() {
>            createAndShowGUI();
>        }
> });
> List<StorageDomain> list_SD=api.getStorageDomains().list();
> Integer i=0;
> for(StorageDomain obj: list_SD)
> {
> System.out.println(obj.getName()+ " | " + obj.getUsed() + " | " +
> obj.getAvailable() + " | " + obj.getType());
> }
> */
> }
> }
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From amureini at redhat.com  Thu Jan 31 08:21:57 2013
From: amureini at redhat.com (Allon Mureinik)
Date: Thu, 31 Jan 2013 03:21:57 -0500 (EST)
Subject: [Engine-devel] jpa annotations
In-Reply-To: <50F41CBA.6070104@redhat.com>
Message-ID: <614208891.7134635.1359620517121.JavaMail.root@redhat.com>

Following the general agreement on #2, and no voices to the contrary, here it goes:
http://gerrit.ovirt.org/#/c/11590/

----- Original Message -----
> From: "Tal Nisan" <tnisan at redhat.com>
> To: "Allon Mureinik" <amureini at redhat.com>
> Cc: "Mike Kolesnik" <mkolesni at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, January 14, 2013 4:56:58 PM
> Subject: Re: [Engine-devel] jpa annotations
> 
> +2 for #2, seems like most of the work done is adding the
> annotations,
> most of which are not relevant anyway so if we want to get back
> someday
> to the Hibernate effort we will have to check each one individually
> anyway, better do it from scratch.
> 
> 
> 
> On 01/14/2013 03:36 PM, Allon Mureinik wrote:
> >
> > ----- Original Message -----
> >> From: "Mike Kolesnik"<mkolesni at redhat.com>
> >> To: "engine-devel"<engine-devel at ovirt.org>
> >> Cc: "Itamar Heim"<iheim at redhat.com>, "Allon
> >> Mureinik"<amureini at redhat.com>
> >> Sent: Sunday, January 13, 2013 3:16:01 PM
> >> Subject: Re: [Engine-devel] jpa annotations
> >>
> >> ----- Original Message -----
> >>>
> >>> ----- 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: Tuesday, December 18, 2012 11:52:39 PM
> >>>> Subject: Re: [Engine-devel] jpa annotations
> >>>>
> >>>> On 12/18/2012 03:55 PM, Laszlo Hornyak wrote:
> >>>>> Hi,
> >>>>>
> >>>>> We have JPA annotations on the backend entity beans, but they
> >>>>> have
> >>>>> never been actually used as far as I know and now that I looked
> >>>>> into VmTemplate for example we do not even have a vm_template
> >>>>> table anymore, while VmTemplate still refers to it.
> >>>>> Any plans with the JPA?
> >>>>>
> >>>> I'm assuming they are from the work on moving to hibernate
> >>>> started
> >>>> a
> >>>> long time ago, and question is are we going to finish it anytime
> >>>> soon.
> >> Yes it was done a couple of year ago but never made it past a
> >> "POC"
> >> state.
> >>
> >>> It's not a case of finishing it, it's a case of redoing it.
> >>> These annotations are not being maintainted anymore, and a large
> >>> percent of them are now irrelevant.
> >> Indeed, they are mostly getting in the way and interfering with
> >> understanding the code..
> >>
> >> As I see it there are 3 options:
> >>   1. Do nothing and just live with them.
> >>   2. Remove them completely and all hibernate related work.
> >>   3. Write DAOs that work with hibernate and start using them.
> >>
> >> For me #1 is not that great since currently it's just garbage that
> >> sits there unmaintained..
> >> I would like to see #3 happen but I think that it's easier to do
> >> #2
> >> first, and then each DAO can be treated separately (there's
> >> already
> >> the infrastructure for that in place).
> >>
> >> I know it might seem wasteful to do #2 instead of #3 but:
> >>   * We don't have anyone to pick up #3 and work on it to get it to
> >>   a
> >>   good state.
> >>   * The hibernate work that's been done is really cross product,
> >>   but I
> >>   don't see why we wouldn't do it in an iterative way instead of
> >>   forcing all DAOs to switch in one fell swoop..
> >>   * The work that has been done, is not that much that we would
> >>   "cry"
> >>   over deleting it..
> > #1 is just bad, as I think we can all agree.
> > As Edmund Burke (probably did not) say - "All that is necessary for
> > the triumph of evil is that good men do nothing."
> >
> > re #2 and #3 - considering the state that these annotation are
> > currently in, #3 probably includes removing more than 50% of the
> > current annotations, so...
> > +2 on doing #2.
> >
> >
> >> Your thoughts?
> >>
> >> Regards,
> >> Mike
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From cc272309126 at gmail.com  Thu Jan 31 05:47:27 2013
From: cc272309126 at gmail.com (=?GB2312?B?s8KzrA==?=)
Date: Thu, 31 Jan 2013 13:47:27 +0800
Subject: [Engine-devel] when import ovirt-engine to eclipse,
	it cann't find the .project file.
Message-ID: <CAKZDL5PUuu4qxuQHxqLGjqd_AWuGyrV86BXh2xxT70st5ANPoA@mail.gmail.com>

Hi all,

 I am trying to set up an eclipse development environment for
ovirt-engine and am running into a stubborn problem with missing
classes.  I have followed the directions for importing the Maven
projects as written here:
http://ovirt.org/wiki/Building_Ovirt_Engine/IDE,but there is no
'.project' file,when I git clone from the gerrit.I should have a
complete ovirt-engine source repository (I cloned the ovirt-engine git
repo).  Has anyone seen this problem before?  Can you offer any
suggestions to help me resolve it?  Thanks!

chenchao.

thanks


From kmayilsa at redhat.com  Thu Jan 31 08:35:14 2013
From: kmayilsa at redhat.com (Kanagaraj Mayilsamy)
Date: Thu, 31 Jan 2013 03:35:14 -0500 (EST)
Subject: [Engine-devel] when import ovirt-engine to eclipse,
 it cann't find the .project file.
In-Reply-To: <CAKZDL5PUuu4qxuQHxqLGjqd_AWuGyrV86BXh2xxT70st5ANPoA@mail.gmail.com>
Message-ID: <155794487.11025815.1359621314232.JavaMail.root@redhat.com>

Hi,

Comments inline.

----- Original Message -----
> From: "??" <cc272309126 at gmail.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, January 31, 2013 11:17:27 AM
> Subject: [Engine-devel] when import ovirt-engine to eclipse,	it cann't find the .project file.
> 
> Hi all,
> 
>  I am trying to set up an eclipse development environment for
> ovirt-engine and am running into a stubborn problem with missing
> classes.  I have followed the directions for importing the Maven
> projects as written here:
> http://ovirt.org/wiki/Building_Ovirt_Engine/IDE,but there is no
> '.project' file,when I git clone from the gerrit.I should have a
> complete ovirt-engine source repository (I cloned the ovirt-engine
> git

we are  not maintaining .project file in the git repository. Eclispe will automatically create .project files when you import the projects through maven.

For class not found issues, did you look into the section "Change project settings to Resolve compilation errors" in http://www.ovirt.org/Building_Ovirt_Engine/IDE ?

If you follow the steps in that section, you will not see any missing classes error.

Thanks,
Kanagaraj

> repo).  Has anyone seen this problem before?  Can you offer any
> suggestions to help me resolve it?  Thanks!
> 
> chenchao.
> 
> thanks
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From tjelinek at redhat.com  Thu Jan 31 08:37:45 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Thu, 31 Jan 2013 03:37:45 -0500 (EST)
Subject: [Engine-devel] when import ovirt-engine to eclipse,
 it cann't find the .project file.
In-Reply-To: <CAKZDL5PUuu4qxuQHxqLGjqd_AWuGyrV86BXh2xxT70st5ANPoA@mail.gmail.com>
Message-ID: <831625103.8673305.1359621465663.JavaMail.root@redhat.com>

Hi Chenchao,

there should be no .project file in the repository (please have a look at the ".gitignore" file in the root of the project).
The .project is generated by eclipse when you import your project, not stored in repo.

Have you tried to import the projects as "existing maven projects"?

An another way to generate the eclipse specific files should be to run the "mvn eclipse:clean eclipse:eclipse"
from the root of the project.

hope it helps,
Tomas

----- Original Message -----
From: "??" <cc272309126 at gmail.com>
To: engine-devel at ovirt.org
Sent: Thursday, January 31, 2013 6:47:27 AM
Subject: [Engine-devel] when import ovirt-engine to eclipse,	it cann't find the .project file.

Hi all,

 I am trying to set up an eclipse development environment for
ovirt-engine and am running into a stubborn problem with missing
classes.  I have followed the directions for importing the Maven
projects as written here:
http://ovirt.org/wiki/Building_Ovirt_Engine/IDE,but there is no
'.project' file,when I git clone from the gerrit.I should have a
complete ovirt-engine source repository (I cloned the ovirt-engine git
repo).  Has anyone seen this problem before?  Can you offer any
suggestions to help me resolve it?  Thanks!

chenchao.

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


From msalem at redhat.com  Thu Jan 31 09:51:58 2013
From: msalem at redhat.com (Muli Salem)
Date: Thu, 31 Jan 2013 04:51:58 -0500 (EST)
Subject: [Engine-devel] oVirt 3.2 test-day
In-Reply-To: <268806924.7622116.1359535458763.JavaMail.root@redhat.com>
Message-ID: <313155590.8721689.1359625918859.JavaMail.root@redhat.com>

Hi all,

I will be testing the new Network main tab.

Cheers,
Muli

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Moran Goldboim" <mgoldboi at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, 30 January, 2013 10:44:18 AM
> Subject: Re: [Engine-devel] oVirt 3.2 test-day
> 
> Hi,
> 
> I will participate and help users with SLA-related questions.
> 
> 
> ----- Original Message -----
> > From: "Moran Goldboim" <mgoldboi at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, January 29, 2013 12:30:40 AM
> > Subject: [Engine-devel] oVirt 3.2 test-day
> > 
> > we were supposed to have test day tomorrow, but we decided to push
> > it
> > to
> > Thursday (Jan 31) to have ovirt-node and proper infra for test day
> > (Mike
> > should announce it's officially soon).
> > I have refreshed http://www.ovirt.org/Testing/OvirtTestDay, but
> > there
> > is
> > action from your part as well:
> > 
> > -go over the scenarios (regressions), see if those relevant, add
> > more
> > if
> > needed remove if not.
> > -add basic tests for your new 3.2 features.
> > -assign a contributor to be actively present on helping users on
> > his
> > area
> > -make commitment and participate the test day
> > 
> > I would like to review this document by Wednesday on users meeting,
> > please make sure your part is updated by than.
> > 
> > Thanks,
> > Moran.
> > _______________________________________________
> > 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  Thu Jan 31 15:13:51 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Thu, 31 Jan 2013 10:13:51 -0500 (EST)
Subject: [Engine-devel] oVirt 3.2 test-day
In-Reply-To: <51070A20.7060400@redhat.com>
Message-ID: <1282045099.11845010.1359645231364.JavaMail.root@redhat.com>

Hi All,

I tested some basic network functionality and discovered the following bugs (updated in the wiki):
Bug 906289 - [oVirt-webadmin] [network] Non-VM networks shown as VM networks on cluster attachment dialog
Bug 906291 - [oVirt-webadmin] [network] Non-VM networks not being detached from cluster
Bug 906313 - [oVirt-webadmin] [setupNetworks] "No valid Operation for <network_name> and Unassigned Logical Networks panel"
Bug 906383 - [vdsm] [setupNetworks] Error while attaching non-VM network to interface on Fedora 18
Bug 906393 - [oVirt] [network] Audit log message for unmanaged network
Bug 906394 - [oVirt-webadmin] [network] Loading animation in network main tab 'hosts' and 'vms' subtab is stuck on first view of the sub tab

Regards,
Mike

----- Original Message -----
> we were supposed to have test day tomorrow, but we decided to push it
> to
> Thursday (Jan 31) to have ovirt-node and proper infra for test day
> (Mike
> should announce it's officially soon).
> I have refreshed http://www.ovirt.org/Testing/OvirtTestDay, but there
> is
> action from your part as well:
> 
> -go over the scenarios (regressions), see if those relevant, add more
> if
> needed remove if not.
> -add basic tests for your new 3.2 features.
> -assign a contributor to be actively present on helping users on his
> area
> -make commitment and participate the test day
> 
> I would like to review this document by Wednesday on users meeting,
> please make sure your part is updated by than.
> 
> Thanks,
> Moran.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From msalem at redhat.com  Thu Jan 31 16:05:40 2013
From: msalem at redhat.com (Muli Salem)
Date: Thu, 31 Jan 2013 11:05:40 -0500 (EST)
Subject: [Engine-devel] oVirt 3.2 test-day
In-Reply-To: <1282045099.11845010.1359645231364.JavaMail.root@redhat.com>
Message-ID: <2683350.52.1359648270960.JavaMail.msalem@dhcp-1-23.tlv.redhat.com>

Hey,

I ran some tests on the Network Main Tab, summary attached (and bugs are updated in the wiki).

Muli

----- Original Message -----
From: "Mike Kolesnik" <mkolesni at redhat.com>
To: engine-devel at ovirt.org
Sent: Thursday, 31 January, 2013 5:13:51 PM
Subject: Re: [Engine-devel] oVirt 3.2 test-day

Hi All,

I tested some basic network functionality and discovered the following bugs (updated in the wiki):
Bug 906289 - [oVirt-webadmin] [network] Non-VM networks shown as VM networks on cluster attachment dialog
Bug 906291 - [oVirt-webadmin] [network] Non-VM networks not being detached from cluster
Bug 906313 - [oVirt-webadmin] [setupNetworks] "No valid Operation for <network_name> and Unassigned Logical Networks panel"
Bug 906383 - [vdsm] [setupNetworks] Error while attaching non-VM network to interface on Fedora 18
Bug 906393 - [oVirt] [network] Audit log message for unmanaged network
Bug 906394 - [oVirt-webadmin] [network] Loading animation in network main tab 'hosts' and 'vms' subtab is stuck on first view of the sub tab

Regards,
Mike

----- Original Message -----
> we were supposed to have test day tomorrow, but we decided to push it
> to
> Thursday (Jan 31) to have ovirt-node and proper infra for test day
> (Mike
> should announce it's officially soon).
> I have refreshed http://www.ovirt.org/Testing/OvirtTestDay, but there
> is
> action from your part as well:
> 
> -go over the scenarios (regressions), see if those relevant, add more
> if
> needed remove if not.
> -add basic tests for your new 3.2 features.
> -assign a contributor to be actively present on helping users on his
> area
> -make commitment and participate the test day
> 
> I would like to review this document by Wednesday on users meeting,
> please make sure your part is updated by than.
> 
> Thanks,
> Moran.
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: NetworkMainTabTests
Type: application/octet-stream
Size: 1539 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130131/80e8a7d9/attachment.obj>

From lvernia at redhat.com  Thu Jan 31 15:31:11 2013
From: lvernia at redhat.com (Lior Vernia)
Date: Thu, 31 Jan 2013 17:31:11 +0200
Subject: [Engine-devel] oVirt 3.2 test-day
In-Reply-To: <51070A20.7060400@redhat.com>
References: <51070A20.7060400@redhat.com>
Message-ID: <510A8E3F.20900@redhat.com>

Hello everybody,

Found two bugs that aren't related specifically to the version release:
* https://bugzilla.redhat.com/show_bug.cgi?id=906359
* https://bugzilla.redhat.com/show_bug.cgi?id=906378

Lior.

On 29/01/13 01:30, Moran Goldboim wrote:
> we were supposed to have test day tomorrow, but we decided to push it to
> Thursday (Jan 31) to have ovirt-node and proper infra for test day (Mike
> should announce it's officially soon).
> I have refreshed http://www.ovirt.org/Testing/OvirtTestDay, but there is
> action from your part as well:
> 
> -go over the scenarios (regressions), see if those relevant, add more if
> needed remove if not.
> -add basic tests for your new 3.2 features.
> -assign a contributor to be actively present on helping users on his area
> -make commitment and participate the test day
> 
> I would like to review this document by Wednesday on users meeting,
> please make sure your part is updated by than.
> 
> Thanks,
> Moran.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From alkaplan at redhat.com  Thu Jan 31 16:28:23 2013
From: alkaplan at redhat.com (Alona Kaplan)
Date: Thu, 31 Jan 2013 11:28:23 -0500 (EST)
Subject: [Engine-devel] oVirt 3.2 test-day
In-Reply-To: <51070A20.7060400@redhat.com>
Message-ID: <89328651.53145741.1359649703470.JavaMail.root@redhat.com>

Hi all,

I ran some tests on the Network Linking.

Found 2 bugs-
https://bugzilla.redhat.com/906434
https://bugzilla.redhat.com/906440

Alona.

----- Original Message -----
> From: "Moran Goldboim" <mgoldboi at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, January 29, 2013 1:30:40 AM
> Subject: [Engine-devel] oVirt 3.2 test-day
> 
> we were supposed to have test day tomorrow, but we decided to push it
> to
> Thursday (Jan 31) to have ovirt-node and proper infra for test day
> (Mike
> should announce it's officially soon).
> I have refreshed http://www.ovirt.org/Testing/OvirtTestDay, but there
> is
> action from your part as well:
> 
> -go over the scenarios (regressions), see if those relevant, add more
> if
> needed remove if not.
> -add basic tests for your new 3.2 features.
> -assign a contributor to be actively present on helping users on his
> area
> -make commitment and participate the test day
> 
> I would like to review this document by Wednesday on users meeting,
> please make sure your part is updated by than.
> 
> Thanks,
> Moran.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From asegurap at redhat.com  Thu Jan 31 16:45:14 2013
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Thu, 31 Jan 2013 11:45:14 -0500 (EST)
Subject: [Engine-devel] oVirt 3.2 test-day
In-Reply-To: <89328651.53145741.1359649703470.JavaMail.root@redhat.com>
Message-ID: <2084952444.5415703.1359650714229.JavaMail.root@redhat.com>

Hi,

I was reminded of Alona of a bug I uncovered sometime ago on libvirt side
that affects Network linking. I submitted patches to master and ovirt-3.2

http://gerrit.ovirt.org/#/c/11599/
http://gerrit.ovirt.org/#/c/11600/

(It's more on the vdsm side though :P )

----- Original Message -----
> From: "Alona Kaplan" <alkaplan at redhat.com>
> To: "Moran Goldboim" <mgoldboi at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, January 31, 2013 5:28:23 PM
> Subject: Re: [Engine-devel] oVirt 3.2 test-day
> 
> Hi all,
> 
> I ran some tests on the Network Linking.
> 
> Found 2 bugs-
> https://bugzilla.redhat.com/906434
> https://bugzilla.redhat.com/906440
> 
> Alona.
> 
> ----- Original Message -----
> > From: "Moran Goldboim" <mgoldboi at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, January 29, 2013 1:30:40 AM
> > Subject: [Engine-devel] oVirt 3.2 test-day
> > 
> > we were supposed to have test day tomorrow, but we decided to push
> > it
> > to
> > Thursday (Jan 31) to have ovirt-node and proper infra for test day
> > (Mike
> > should announce it's officially soon).
> > I have refreshed http://www.ovirt.org/Testing/OvirtTestDay, but
> > there
> > is
> > action from your part as well:
> > 
> > -go over the scenarios (regressions), see if those relevant, add
> > more
> > if
> > needed remove if not.
> > -add basic tests for your new 3.2 features.
> > -assign a contributor to be actively present on helping users on
> > his
> > area
> > -make commitment and participate the test day
> > 
> > I would like to review this document by Wednesday on users meeting,
> > please make sure your part is updated by than.
> > 
> > Thanks,
> > Moran.
> > _______________________________________________
> > 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
>