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

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

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

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

Regards,
Alon