On 12/13/2012 12:25 PM, Moti Asayag 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 thanks its working. I think we need to add that to "setup" target of the ear so a developer could get up & running

> Regards, > Moti > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

From: "Moti Asayag" <masayag(a)redhat.com&gt; To: engine-devel(a)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

Regards, Moti _______________________________________________ Engine-devel mailing list Engine-devel(a)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)

Vojtech ----- Original Message ----- From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; To: engine-devel(a)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(a)redhat.com&gt; To: "Moti Asayag" <masayag(a)redhat.com&gt; Cc: engine-devel(a)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(a)redhat.com&gt; > To: engine-devel(a)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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

> 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

----- Original Message ----- From: "Roy Golan" <rgolan(a)redhat.com&gt; To: engine-devel(a)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(a)redhat.com&gt; > To: engine-devel(a)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(a)redhat.com&gt; > To: "Moti Asayag" <masayag(a)redhat.com&gt; > Cc: engine-devel(a)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(a)redhat.com&gt; >> To: engine-devel(a)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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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. >> >> ----- Original Message ----- >> From: "Roy Golan" <rgolan(a)redhat.com&gt; >> To: engine-devel(a)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(a)redhat.com&gt; >>> To: engine-devel(a)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(a)redhat.com&gt; >>> To: "Moti Asayag" <masayag(a)redhat.com&gt; >>> Cc: engine-devel(a)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(a)redhat.com&gt; >>>> To: engine-devel(a)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

----- Original Message ----- > From: "Juan Hernandez" <jhernand(a)redhat.com&gt; > To: "Roy Golan" <rgolan(a)redhat.com&gt; > Cc: engine-devel(a)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".

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.

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: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; To: "Livnat Peer" <lpeer(a)redhat.com&gt; Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)ovirt.org Sent: Tuesday, January 1, 2013 9:30:20 AM Subject: Re: [Engine-devel] Engine local configuration ----- Original Message ----- > From: "Livnat Peer" <lpeer(a)redhat.com&gt; > To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)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(a)redhat.com&gt; > >> To: "Roy Golan" <rgolan(a)redhat.com&gt; > >> Cc: engine-devel(a)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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)ovirt.org, "Livnat Peer" <lpeer(a)redhat.com&gt; Sent: Tuesday, January 1, 2013 9:56:05 AM Subject: Re: [Engine-devel] Engine local configuration ----- Original Message ----- > From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)ovirt.org, > "Livnat Peer" <lpeer(a)redhat.com&gt; > Sent: Tuesday, January 1, 2013 9:43:50 AM > Subject: Re: [Engine-devel] Engine local configuration > > > > ----- Original Message ----- > > From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > To: "Livnat Peer" <lpeer(a)redhat.com&gt; > > Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, > > engine-devel(a)ovirt.org > > Sent: Tuesday, January 1, 2013 9:30:20 AM > > Subject: Re: [Engine-devel] Engine local configuration > > > > > > > > ----- Original Message ----- > > > From: "Livnat Peer" <lpeer(a)redhat.com&gt; > > > To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > > > Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, > > > engine-devel(a)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(a)redhat.com&gt; > > > >> To: "Roy Golan" <rgolan(a)redhat.com&gt; > > > >> Cc: engine-devel(a)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: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)ovirt.org Sent: Tuesday, January 1, 2013 10:15:37 AM Subject: Re: [Engine-devel] Engine local configuration ----- Original Message ----- > From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)ovirt.org, > "Livnat Peer" <lpeer(a)redhat.com&gt; > Sent: Tuesday, January 1, 2013 10:08:32 AM > Subject: Re: [Engine-devel] Engine local configuration > > > > ----- Original Message ----- > > From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > > Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, > > engine-devel(a)ovirt.org, > > "Livnat Peer" <lpeer(a)redhat.com&gt; > > Sent: Tuesday, January 1, 2013 9:56:05 AM > > Subject: Re: [Engine-devel] Engine local configuration > > > > > > > > ----- Original Message ----- > > > From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > > > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > > Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, > > > engine-devel(a)ovirt.org, > > > "Livnat Peer" <lpeer(a)redhat.com&gt; > > > Sent: Tuesday, January 1, 2013 9:43:50 AM > > > Subject: Re: [Engine-devel] Engine local configuration > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > > > To: "Livnat Peer" <lpeer(a)redhat.com&gt; > > > > Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, > > > > engine-devel(a)ovirt.org > > > > Sent: Tuesday, January 1, 2013 9:30:20 AM > > > > Subject: Re: [Engine-devel] Engine local configuration > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Livnat Peer" <lpeer(a)redhat.com&gt; > > > > > To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > > > > > Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, > > > > > engine-devel(a)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(a)redhat.com&gt; > > > > > >> To: "Roy Golan" <rgolan(a)redhat.com&gt; > > > > > >> Cc: engine-devel(a)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

----- Original Message ----- > From: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)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: "Doron Fediuck" <dfediuck(a)redhat.com&gt; To: "Juan Hernandez" <jhernand(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org Sent: Tuesday, January 1, 2013 12:41:27 PM Subject: Re: [Engine-devel] Engine local configuration ----- Original Message ----- > From: "Juan Hernandez" <jhernand(a)redhat.com&gt; > To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; > Cc: engine-devel(a)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(a)redhat.com&gt; > >> To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > >> Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, > >> engine-devel(a)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? _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)ovirt.org, "Doron Fediuck" <dfediuck(a)redhat.com&gt; 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(a)redhat.com&gt; >> To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; >> Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)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(a)redhat.com&gt; >>>> To: "Roy Golan" <rgolan(a)redhat.com&gt; >>>> Cc: engine-devel(a)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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >>