[Engine-devel] Engine local configuration

[Juan Hernandez]

On 01/01/2013 10:51 AM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Doron Fediuck" <dfediuck at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
>> Sent: Tuesday, January 1, 2013 10:30:29 AM
>> Subject: Re: [Engine-devel] Engine local configuration
>>>> All we are saying is DEVELOPMENT=1 is the default, since the code
>>>> is built differently for production, and installed accordingly.
>>>> Additionally you may have more than one devel setup, for example
>>>> for
>>>> different versions. So unless you override something (such as
>>>> keystore
>>>> pass, jboss location) mvn -Pdep should simply work, and make XXX
>>>> will
>>>> ensure whatever you need to override is done properly.
>>>>
>>>>
>>>
>>> No, you miss the point.
>>> I want to be able to have a full blown product installed for
>>> development as well.
>>> The only difference is the PREFIX and may be some other stuff I
>>> don't
>>> think of that are specific of development.
>>> I put the DEVELOPMENT=1 to focus the discussion.
>>>
>>> I should have written the following steps to be more clear:
>>> $ OEHOME=$HOME/ovirt-engine-root
>>> $ make PREFIX=$OEHOME
>>> $ make PREFIX=$OEHOME DEVELOPMENT=1 install
>>> $ cd ${OEHOME}
>>> $ . ./ovirt-engine.vars
>>> $ engine-setup
>>> <snip>
>>> $ sbin/engie-service.py start
>>>
>>> We probably need more vars on the make install, such as JBOSS_HOME,
>>> but the idea is that you have fully functional product in
>>> development mode, including PKI and support scripts.
>>>
>>> Regards,
>>> Alon
>>
>> Alon,
>> most universities today will not give you admin privileges.
>> We must be able to download the code and run it without additional
>> requirements. It is possible to run jboss with local configuration
>> (per user). So we should minimize the restrictions and not impose
>> new once. Running the installation script is nice to have, but
>> should be completely optional. Especially if you'd like to see it
>> being deployed in various distro's. So at least developers should
>> be able to git clone, compile and run. Everything else is packaging.
>>
> 
> You don't need any admin to install at PREFIX=$HOME/ovirt-engine-root
> 
> We should make sure that we can run all components within PREFIX without root.
> 
> As far as I can tell, we do not actually need root access for 99% of the implementation, one of the trivial differences is to replace systemctl start/stop with direct script execution in non-root mode.
> 
> Alon

As I mentioned on my first response to this thread I have been working
on trying to make the build system able to install the engine to a
directory chosen by the developer, and without root permissions. This is
the patch that I prepared for that, please take a look at the commit
message:

http://gerrit.ovirt.org/10539

The idea is that the developer can chose a directory and then just run
the following:

  ./make.py --build --install --devel --target /that/directory

Even the complexity of this command line can be hidden in a make target,
or made the default, so the developer will only need to run something
like this:

  make install

This will prepare an environment similar to the production environment,
with the same directory structure (except the /that/directory prefix)
where the engine can run, so to start it the developer only needs to go
to that directory and execute the same script that we use in production
environments:

  cd /that/directory/usr/bin
  ./engine-service start

This will also automatically configure the engine for remote debugging
(adding ENGINE_DEBUG_ADDRESS=0.0.0.0:8787 to the configuration) so that
the developer can connect to the engine with her/his favorite IDE and
start debugging immediately.

The make.py script also includes options to create Eclipse project files
and to configure the Eclipse workspace, which I think is very useful,
specially for new developers:

  ./make.py --eclipse-projects

That creates the .project and .classpath files for Eclipse and adds the
required variables to the workspace, so after that all what the
developer has to do to start working is open Eclipse and import the
projects.

The patch is not yet ready to merge, as there are a few missing things,
like changing the ownership of files when running as root, but I would
appreciate if you can test it.

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.