----- Original Message ----- > From: "Livnat Peer" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "Juan Hernandez" <[email protected]>, [email protected], "Doron > Fediuck" <[email protected]> > 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" <[email protected]> > >> To: "Doron Fediuck" <[email protected]> > >> Cc: "Juan Hernandez" <[email protected]>, [email protected] > >> 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" <[email protected]> > >>>> To: "Roy Golan" <[email protected]> > >>>> Cc: [email protected] > >>>> 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 > >> [email protected] > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
