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