9:05 a.m.
----- Original Message -----
From: "Juan Hernandez" <jhernand(a)redhat.com>
To: "Roy Golan" <rgolan(a)redhat.com>
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".
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.
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