[Engine-devel] Engine local configuration

[Alon Bar-Lev]

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org, "Doron Fediuck" <dfediuck at redhat.com>
> Sent: Tuesday, January 1, 2013 10:00:11 AM
> Subject: Re: [Engine-devel] Engine local configuration
> 
> On 01/01/2013 09:30 AM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- 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.
> > 
> 
> The setup profile is relevant only for development and not used in
> production. So having this file copied/handled as part of the setup
> profile has no risk in it.

The development environment should be similar to the production environment as much as we can.
Hence, running engine-setup in development environment is something I would like to see.
The maven magic is not enough to setup such environment.
However, maven magic can be used to update existing environment with new java artifacts.

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