----- 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.