[Engine-devel] Engine local configuration

Tue Jan 1 08:30:29 UTC 2013

----- 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
> Sent: Tuesday, January 1, 2013 10:15:37 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 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

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.