[Engine-devel] Engine local configuration

Tue Jan 1 07:43:50 UTC 2013

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

> > 
> > > 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 at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 