Re: [Engine-devel] Engine local configuration

From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)ovirt.org, "Doron Fediuck" <dfediuck(a)redhat.com&gt; 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(a)redhat.com&gt; >> To: "Doron Fediuck" <dfediuck(a)redhat.com&gt; >> Cc: "Juan Hernandez" <jhernand(a)redhat.com&gt;, engine-devel(a)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(a)redhat.com&gt; >>>> To: "Roy Golan" <rgolan(a)redhat.com&gt; >>>> Cc: engine-devel(a)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.

>> >>> 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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >>