[Engine-devel] Engine local configuration

Tue Jan 1 08:00:11 UTC 2013

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.

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