[Engine-devel] Engine local configuration

[Alon Bar-Lev]

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

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

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

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

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

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

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

Alon