On 12/13/2012 12:42 PM, Roy Golan wrote:

...

Hi,

I get the following error when trying to connect to webadmin:

2012-12-13 11:57:06,689 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/webadmin].[WebAdminDynamicHosting]] (http--0.0.0.0-8700-1) Servlet.service() for servlet WebAdminDynamicHosting threw exception: java.lang.IllegalArgumentException: The property "ENGINE_USR" doesn't have a value.

It caused by the PluginDataManager instantiation which requires several variables to be defined.

In order to by pass those errors do: 1. create a file /usr/share/ovirt-engine/conf/engine.conf.defaults 2. Add the following properties to the file: ENGINE_USR=username ENGINE_ETC=/etc/ovirt-engine 3. restart Jboss

On 12/13/2012 12:25 PM, Moti Asayag wrote: thanks its working. I think we need to add that to "setup" target of the ear so a developer could get up & running http://gerrit.ovirt.org/#/c/10026/

...

Regards, Moti _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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

Hi guys, as Moti mentioned, this issue is related to UI plugins patches that have been merged recently. However, the root cause of this issue is LocalConfig class (machine-specific Engine configuration) throwing exception in following cases: - cannot load default properties (ENGINE_DEFAULTS property if defined, otherwise /usr/share/ovirt-engine/conf/engine.conf.defaults) - cannot load custom properties (ENGINE_VARS property if defined, otherwise /etc/sysconfig/ovirt-engine) - requesting missing property value (LocalConfig.getProperty method) (Note that UI plugins use two Engine properties: ENGINE_USR and ENGINE_ETC.) As Juan suggests in his comment in http://gerrit.ovirt.org/#/c/10026/, we could include this in "building Engine" wiki. For example: - have ENGINE_DEFAULTS property point to OVIRT_HOME/backend/manager/conf/engine.conf.defaults (alternatively, users can copy this file to /usr/share/ovirt-engine/conf) - create custom Engine config file, e.g. ~/myengine.conf, and have ENGINE_VARS property point to this file Vojtech ----- Original Message ----- From: "Daniel Erez" <derez@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, December 13, 2012 11:49:13 AM Subject: Re: [Engine-devel] Error on starting webadmin ----- Original Message -----

From: "Moti Asayag" <masayag@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, December 13, 2012 12:25:07 PM Subject: [Engine-devel] Error on starting webadmin

Hi,

I get the following error when trying to connect to webadmin:

2012-12-13 11:57:06,689 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/webadmin].[WebAdminDynamicHosting]] (http--0.0.0.0-8700-1) Servlet.service() for servlet WebAdminDynamicHosting threw exception: java.lang.IllegalArgumentException: The property "ENGINE_USR" doesn't have a value.

It caused by the PluginDataManager instantiation which requires several variables to be defined.

In order to by pass those errors do: 1. create a file /usr/share/ovirt-engine/conf/engine.conf.defaults 2. Add the following properties to the file: ENGINE_USR=username ENGINE_ETC=/etc/ovirt-engine 3. restart Jboss

You can use the 'engine.conf.defaults' that resides at 'backend/manager/conf'.

Regards, Moti _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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

Hi,

I've updated http://www.ovirt.org/Building_Engine_Draft - added section "Engine local configuration" (feel free to edit or modify as necessary)

On 12/13/2012 04:32 PM, Vojtech Szocs wrote: this is making the contribution process more complex. lets think of a lighter way to get a developing setup.

Vojtech

----- Original Message ----- From: "Vojtech Szocs" <vszocs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, December 13, 2012 2:49:39 PM Subject: Re: [Engine-devel] Error on starting webadmin

Hi guys,

as Moti mentioned, this issue is related to UI plugins patches that have been merged recently.

However, the root cause of this issue is LocalConfig class (machine-specific Engine configuration) throwing exception in following cases: - cannot load default properties (ENGINE_DEFAULTS property if defined, otherwise /usr/share/ovirt-engine/conf/engine.conf.defaults) - cannot load custom properties (ENGINE_VARS property if defined, otherwise /etc/sysconfig/ovirt-engine) - requesting missing property value (LocalConfig.getProperty method)

(Note that UI plugins use two Engine properties: ENGINE_USR and ENGINE_ETC.)

As Juan suggests in his comment in http://gerrit.ovirt.org/#/c/10026/, we could include this in "building Engine" wiki. For example: - have ENGINE_DEFAULTS property point to OVIRT_HOME/backend/manager/conf/engine.conf.defaults (alternatively, users can copy this file to /usr/share/ovirt-engine/conf) - create custom Engine config file, e.g. ~/myengine.conf, and have ENGINE_VARS property point to this file

Vojtech

----- Original Message ----- From: "Daniel Erez" <derez@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, December 13, 2012 11:49:13 AM Subject: Re: [Engine-devel] Error on starting webadmin

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

...

From: "Moti Asayag" <masayag@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, December 13, 2012 12:25:07 PM Subject: [Engine-devel] Error on starting webadmin

Hi,

I get the following error when trying to connect to webadmin:

2012-12-13 11:57:06,689 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/webadmin].[WebAdminDynamicHosting]] (http--0.0.0.0-8700-1) Servlet.service() for servlet WebAdminDynamicHosting threw exception: java.lang.IllegalArgumentException: The property "ENGINE_USR" doesn't have a value.

It caused by the PluginDataManager instantiation which requires several variables to be defined.

In order to by pass those errors do: 1. create a file /usr/share/ovirt-engine/conf/engine.conf.defaults 2. Add the following properties to the file: ENGINE_USR=username ENGINE_ETC=/etc/ovirt-engine 3. restart Jboss You can use the 'engine.conf.defaults' that resides at 'backend/manager/conf'.

...

Regards, Moti _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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

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

----- Original Message ----- From: "Roy Golan" <rgolan@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, December 13, 2012 3:36:40 PM Subject: Re: [Engine-devel] Error on starting webadmin

...

Hi,

I've updated http://www.ovirt.org/Building_Engine_Draft - added section "Engine local configuration" (feel free to edit or modify as necessary)

On 12/13/2012 04:32 PM, Vojtech Szocs wrote: this is making the contribution process more complex. lets think of a lighter way to get a developing setup.

...

Vojtech

----- Original Message ----- From: "Vojtech Szocs" <vszocs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, December 13, 2012 2:49:39 PM Subject: Re: [Engine-devel] Error on starting webadmin

Hi guys,

as Moti mentioned, this issue is related to UI plugins patches that have been merged recently.

However, the root cause of this issue is LocalConfig class (machine-specific Engine configuration) throwing exception in following cases: - cannot load default properties (ENGINE_DEFAULTS property if defined, otherwise /usr/share/ovirt-engine/conf/engine.conf.defaults) - cannot load custom properties (ENGINE_VARS property if defined, otherwise /etc/sysconfig/ovirt-engine) - requesting missing property value (LocalConfig.getProperty method)

(Note that UI plugins use two Engine properties: ENGINE_USR and ENGINE_ETC.)

As Juan suggests in his comment in http://gerrit.ovirt.org/#/c/10026/, we could include this in "building Engine" wiki. For example: - have ENGINE_DEFAULTS property point to OVIRT_HOME/backend/manager/conf/engine.conf.defaults (alternatively, users can copy this file to /usr/share/ovirt-engine/conf) - create custom Engine config file, e.g. ~/myengine.conf, and have ENGINE_VARS property point to this file

Vojtech

----- Original Message ----- From: "Daniel Erez" <derez@redhat.com> To: "Moti Asayag" <masayag@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, December 13, 2012 11:49:13 AM Subject: Re: [Engine-devel] Error on starting webadmin

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

...

From: "Moti Asayag" <masayag@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, December 13, 2012 12:25:07 PM Subject: [Engine-devel] Error on starting webadmin

Hi,

I get the following error when trying to connect to webadmin:

2012-12-13 11:57:06,689 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/webadmin].[WebAdminDynamicHosting]] (http--0.0.0.0-8700-1) Servlet.service() for servlet WebAdminDynamicHosting threw exception: java.lang.IllegalArgumentException: The property "ENGINE_USR" doesn't have a value.

It caused by the PluginDataManager instantiation which requires several variables to be defined.

In order to by pass those errors do: 1. create a file /usr/share/ovirt-engine/conf/engine.conf.defaults 2. Add the following properties to the file: ENGINE_USR=username ENGINE_ETC=/etc/ovirt-engine 3. restart Jboss You can use the 'engine.conf.defaults' that resides at 'backend/manager/conf'.

...

Regards, Moti _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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

---

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

On 12/14/2012 01:25 PM, Juan Hernandez wrote:
> 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.
till certain point. that's why we have an installation script for 
production and "make install" for a developer
- alternatively, if(!) its easy and smooth we can run the engine-setup 
with an answer file  or just a "dev" flag than we can call it from the 
-Psetup profile and
make a unified process

>   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.
+1 and this is where the dev setup should end.
>   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.
again agree but only if its simple (minimum steps, don't have to follow 
a long and detailed wiki) and fast.
>   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.
>
>>>
>>> ----- Original Message -----
>>> From: "Roy Golan" <rgolan@redhat.com>
>>> To: engine-devel@ovirt.org
>>> Sent: Thursday, December 13, 2012 3:36:40 PM
>>> Subject: Re: [Engine-devel] Error on starting webadmin
>>>
>>> On 12/13/2012 04:32 PM, Vojtech Szocs wrote:
>>>> Hi,
>>>>
>>>> I've updated http://www.ovirt.org/Building_Engine_Draft - added section "Engine local configuration" (feel free to edit or modify as necessary)
>>> this is making the contribution process more complex. lets think of a
>>> lighter way to get a developing setup.
>>>
>>>> Vojtech
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Vojtech Szocs" <vszocs@redhat.com>
>>>> To: engine-devel@ovirt.org
>>>> Sent: Thursday, December 13, 2012 2:49:39 PM
>>>> Subject: Re: [Engine-devel] Error on starting webadmin
>>>>
>>>> Hi guys,
>>>>
>>>> as Moti mentioned, this issue is related to UI plugins patches that have been merged recently.
>>>>
>>>> However, the root cause of this issue is LocalConfig class (machine-specific Engine configuration) throwing exception in following cases:
>>>> - cannot load default properties (ENGINE_DEFAULTS property if defined, otherwise /usr/share/ovirt-engine/conf/engine.conf.defaults)
>>>> - cannot load custom properties (ENGINE_VARS property if defined, otherwise /etc/sysconfig/ovirt-engine)
>>>> - requesting missing property value (LocalConfig.getProperty method)
>>>>
>>>> (Note that UI plugins use two Engine properties: ENGINE_USR and ENGINE_ETC.)
>>>>
>>>> As Juan suggests in his comment in http://gerrit.ovirt.org/#/c/10026/, we could include this in "building Engine" wiki. For example:
>>>> - have ENGINE_DEFAULTS property point to OVIRT_HOME/backend/manager/conf/engine.conf.defaults (alternatively, users can copy this file to /usr/share/ovirt-engine/conf)
>>>> - create custom Engine config file, e.g. ~/myengine.conf, and have ENGINE_VARS property point to this file
>>>>
>>>> Vojtech
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Daniel Erez" <derez@redhat.com>
>>>> To: "Moti Asayag" <masayag@redhat.com>
>>>> Cc: engine-devel@ovirt.org
>>>> Sent: Thursday, December 13, 2012 11:49:13 AM
>>>> Subject: Re: [Engine-devel] Error on starting webadmin
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Moti Asayag" <masayag@redhat.com>
>>>>> To: engine-devel@ovirt.org
>>>>> Sent: Thursday, December 13, 2012 12:25:07 PM
>>>>> Subject: [Engine-devel] Error on starting webadmin
>>>>>
>>>>> Hi,
>>>>>
>>>>> I get the following error when trying to connect to webadmin:
>>>>>
>>>>> 2012-12-13 11:57:06,689 ERROR
>>>>> [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/webadmin].[WebAdminDynamicHosting]]
>>>>> (http--0.0.0.0-8700-1) Servlet.service() for servlet
>>>>> WebAdminDynamicHosting threw exception:
>>>>> java.lang.IllegalArgumentException: The property "ENGINE_USR"
>>>>> doesn't have a value.
>>>>>
>>>>> It caused by the PluginDataManager instantiation which requires
>>>>> several variables to be defined.
>>>>>
>>>>> In order to by pass those errors do:
>>>>> 1. create a file /usr/share/ovirt-engine/conf/engine.conf.defaults
>>>>> 2. Add the following properties to the file:
>>>>> ENGINE_USR=username
>>>>> ENGINE_ETC=/etc/ovirt-engine
>>>>> 3. restart Jboss
>>>> You can use the 'engine.conf.defaults' that resides at 'backend/manager/conf'.
>>>>
>>>>> Regards,
>>>>> Moti

On 12/31/2012 05:05 PM, Doron Fediuck wrote:

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

...

From: "Juan Hernandez" <jhernand@redhat.com> To: "Roy Golan" <rgolan@redhat.com> Cc: engine-devel@ovirt.org Sent: Friday, December 14, 2012 1:25:57 PM Subject: Re: [Engine-devel] Error on starting webadmin

On 12/13/2012 03:55 PM, Roy Golan wrote:

...

On 12/13/2012 04:49 PM, Vojtech Szocs wrote:

...

...

this is making the contribution process more complex. lets think of a lighter way to get a developing setup. I agree, I just wanted to have the local Engine configuration steps documented for reference.. If there's a better way to do it, I'm for it.

Vojtech

having LocalConfig look for "engine.conf.defaults" system property before fallback to System.getenv("ENGINE_DEFAULTS"); + concatenating -Dengine.conf.defaults=$HOME/.engine.conf.defaults to JAVA_OPTS on standalone.conf

How is the system property simpler than the environment variable?

I agree that this makes the development process a bit more complex at the moment, but I think that the way to make it simpler is not to continue adding things to standalone.conf. I think that we should move towards a development environment that is closer to the production environment, not the other way around. Ideally the developer should be able to do something like "make install" to have the engine deployed to a directory structure similar to what he have in the production environment. Then you should be able to go to the bin directory inside that structure and start the engine (and the other tools) using the same script that we use in production environments. If we achieve this goal then we have a simple development environment setup and also we have all developers testing almost the same thing that will go into the production environments. At the moment we don't have that, most times you are testing something quite different (in terms of directory structure, configuration, etc) to what will be installed in production environments. I am working in that direction.

Hi Guys, Sorry to resume this discussion, but I find the current situation unfriendly to most developers. I understand there's a need for specific configurations, but it seems to me that this has taken one step too far for most developers.

Further more, I expect to see such fundamental concepts being initially discussed here, and not settle with a technical ack, only to be a part of a thread called: "Error on starting webadmin". In this context I expect the verified flag to mean "This was discussed and verified with contributers in the relevant list".

Hi Doron, Thanks for bringing this on the list, I agree with everything you wrote and could not put it any better myself. I configured an environment from scratch yesterday and the additional step to have this config file in /etc does not feel right, not to mentioned that this is not documented in the wiki installation page. I think one of the guidelines we kept so far for setting a development environment and making it as easy as possible for new developers is that no manual step is needed on top of using the setup profile and this definitely breaks this assumption (at least with the way it is handled today).

My use case is exactly what Juan describes, but I think the resolution should be different. ie- contributers should be able to git clone and once they setup jboss & postgres they should be able to have something running.

We cannot assume /etc is a location contributers can access. Think of university students who would like to see how ovirt works using university's machines. In the past they may have had issues with JBoss, but that's already handled by profiles. So there's really no need for oVirt to ask them more than that. I know UI plugins are using this infra, but remember that the plugins are completely optional and should not block basic operation.

Some more concerns this issue raises are related to release versions; What happens when we need to support more than one jboss and/or release version?

So here are 2 options we should consider in order to allow local config without additional requirements:

1. Use defaults. System should boot and start in whichever way we decide without anything else needed. Local configuration can override these defaults if it exists, but it should simply work.

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

2. Use local JBoss profile. Have everything we need in my-standalone.conf and start running jboss with a local 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

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

From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Tuesday, January 1, 2013 9:30:20 AM Subject: Re: [Engine-devel] Engine local configuration

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

...

From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Tuesday, January 1, 2013 9:05:03 AM Subject: Re: [Engine-devel] Engine local configuration

On 12/31/2012 05:05 PM, Doron Fediuck wrote:

...

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

...

From: "Juan Hernandez" <jhernand@redhat.com> To: "Roy Golan" <rgolan@redhat.com> Cc: engine-devel@ovirt.org Sent: Friday, December 14, 2012 1:25:57 PM Subject: Re: [Engine-devel] Error on starting webadmin

On 12/13/2012 03:55 PM, Roy Golan wrote:

...

On 12/13/2012 04:49 PM, Vojtech Szocs wrote:

...

> this is making the contribution process more complex. lets > think > of a > lighter way to get a developing setup. I agree, I just wanted to have the local Engine configuration steps documented for reference.. If there's a better way to do it, I'm for it.

Vojtech

having LocalConfig look for "engine.conf.defaults" system property before fallback to System.getenv("ENGINE_DEFAULTS"); + concatenating -Dengine.conf.defaults=$HOME/.engine.conf.defaults to JAVA_OPTS on standalone.conf

How is the system property simpler than the environment variable?

I agree that this makes the development process a bit more complex at the moment, but I think that the way to make it simpler is not to continue adding things to standalone.conf. I think that we should move towards a development environment that is closer to the production environment, not the other way around. Ideally the developer should be able to do something like "make install" to have the engine deployed to a directory structure similar to what he have in the production environment. Then you should be able to go to the bin directory inside that structure and start the engine (and the other tools) using the same script that we use in production environments. If we achieve this goal then we have a simple development environment setup and also we have all developers testing almost the same thing that will go into the production environments. At the moment we don't have that, most times you are testing something quite different (in terms of directory structure, configuration, etc) to what will be installed in production environments. I am working in that direction.

Hi Guys, Sorry to resume this discussion, but I find the current situation unfriendly to most developers. I understand there's a need for specific configurations, but it seems to me that this has taken one step too far for most developers.

Further more, I expect to see such fundamental concepts being initially discussed here, and not settle with a technical ack, only to be a part of a thread called: "Error on starting webadmin". In this context I expect the verified flag to mean "This was discussed and verified with contributers in the relevant list".

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

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

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

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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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

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

From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Livnat Peer" <lpeer@redhat.com> Sent: Tuesday, January 1, 2013 9:56:05 AM Subject: Re: [Engine-devel] Engine local configuration

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

...

From: "Doron Fediuck" <dfediuck@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Tuesday, January 1, 2013 9:30:20 AM Subject: Re: [Engine-devel] Engine local configuration

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

...

From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Tuesday, January 1, 2013 9:05:03 AM Subject: Re: [Engine-devel] Engine local configuration

On 12/31/2012 05:05 PM, Doron Fediuck wrote:

...

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

...

From: "Juan Hernandez" <jhernand@redhat.com> To: "Roy Golan" <rgolan@redhat.com> Cc: engine-devel@ovirt.org Sent: Friday, December 14, 2012 1:25:57 PM Subject: Re: [Engine-devel] Error on starting webadmin

On 12/13/2012 03:55 PM, Roy Golan wrote: > On 12/13/2012 04:49 PM, Vojtech Szocs wrote: >>> this is making the contribution process more complex. >>> lets >>> think >>> of a >>> lighter way to get a developing setup. >> I agree, I just wanted to have the local Engine >> configuration >> steps documented for reference.. If there's a better way >> to >> do >> it, I'm for it. >> >> Vojtech > > having LocalConfig look for "engine.conf.defaults" system > property > before fallback to System.getenv("ENGINE_DEFAULTS"); > + concatenating > -Dengine.conf.defaults=$HOME/.engine.conf.defaults > to JAVA_OPTS on standalone.conf

How is the system property simpler than the environment variable?

I agree that this makes the development process a bit more complex at the moment, but I think that the way to make it simpler is not to continue adding things to standalone.conf. I think that we should move towards a development environment that is closer to the production environment, not the other way around. Ideally the developer should be able to do something like "make install" to have the engine deployed to a directory structure similar to what he have in the production environment. Then you should be able to go to the bin directory inside that structure and start the engine (and the other tools) using the same script that we use in production environments. If we achieve this goal then we have a simple development environment setup and also we have all developers testing almost the same thing that will go into the production environments. At the moment we don't have that, most times you are testing something quite different (in terms of directory structure, configuration, etc) to what will be installed in production environments. I am working in that direction.

Hi Guys, Sorry to resume this discussion, but I find the current situation unfriendly to most developers. I understand there's a need for specific configurations, but it seems to me that this has taken one step too far for most developers.

Further more, I expect to see such fundamental concepts being initially discussed here, and not settle with a technical ack, only to be a part of a thread called: "Error on starting webadmin". In this context I expect the verified flag to mean "This was discussed and verified with contributers in the relevant list".

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

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

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

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.

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

From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Tuesday, January 1, 2013 10:15:37 AM Subject: Re: [Engine-devel] Engine local configuration

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

...

From: "Doron Fediuck" <dfediuck@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Livnat Peer" <lpeer@redhat.com> Sent: Tuesday, January 1, 2013 9:56:05 AM Subject: Re: [Engine-devel] Engine local configuration

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

...

From: "Doron Fediuck" <dfediuck@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Livnat Peer" <lpeer@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@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Tuesday, January 1, 2013 9:30:20 AM Subject: Re: [Engine-devel] Engine local configuration

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

...

From: "Livnat Peer" <lpeer@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Tuesday, January 1, 2013 9:05:03 AM Subject: Re: [Engine-devel] Engine local configuration

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

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

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

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

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.

On 01/01/2013 10:51 AM, Alon Bar-Lev wrote:

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

...

From: "Doron Fediuck" <dfediuck@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@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.

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

From: "Doron Fediuck" <dfediuck@redhat.com> To: "Juan Hernandez" <jhernand@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, January 1, 2013 12:41:27 PM Subject: Re: [Engine-devel] Engine local configuration

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

...

From: "Juan Hernandez" <jhernand@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: engine-devel@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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

From: "Livnat Peer" <lpeer@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Doron Fediuck" <dfediuck@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@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Tuesday, January 1, 2013 9:05:03 AM Subject: Re: [Engine-devel] Engine local configuration

On 12/31/2012 05:05 PM, Doron Fediuck wrote:

...

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

...

From: "Juan Hernandez" <jhernand@redhat.com> To: "Roy Golan" <rgolan@redhat.com> Cc: engine-devel@ovirt.org Sent: Friday, December 14, 2012 1:25:57 PM Subject: Re: [Engine-devel] Error on starting webadmin

On 12/13/2012 03:55 PM, Roy Golan wrote:

...

On 12/13/2012 04:49 PM, Vojtech Szocs wrote: >> this is making the contribution process more complex. lets >> think >> of a >> lighter way to get a developing setup. > I agree, I just wanted to have the local Engine configuration > steps documented for reference.. If there's a better way to do > it, I'm for it. > > Vojtech

having LocalConfig look for "engine.conf.defaults" system property before fallback to System.getenv("ENGINE_DEFAULTS"); + concatenating -Dengine.conf.defaults=$HOME/.engine.conf.defaults to JAVA_OPTS on standalone.conf

How is the system property simpler than the environment variable?

I agree that this makes the development process a bit more complex at the moment, but I think that the way to make it simpler is not to continue adding things to standalone.conf. I think that we should move towards a development environment that is closer to the production environment, not the other way around. Ideally the developer should be able to do something like "make install" to have the engine deployed to a directory structure similar to what he have in the production environment. Then you should be able to go to the bin directory inside that structure and start the engine (and the other tools) using the same script that we use in production environments. If we achieve this goal then we have a simple development environment setup and also we have all developers testing almost the same thing that will go into the production environments. At the moment we don't have that, most times you are testing something quite different (in terms of directory structure, configuration, etc) to what will be installed in production environments. I am working in that direction.

Hi Guys, Sorry to resume this discussion, but I find the current situation unfriendly to most developers. I understand there's a need for specific configurations, but it seems to me that this has taken one step too far for most developers.

Further more, I expect to see such fundamental concepts being initially discussed here, and not settle with a technical ack, only to be a part of a thread called: "Error on starting webadmin". In this context I expect the verified flag to mean "This was discussed and verified with contributers in the relevant list".

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

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

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

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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel