[Engine-devel] Engine local configuration

Tue Jan 1 10:50:30 UTC 2013

----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Juan Hernandez" <jhernand at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, January 1, 2013 12:41:27 PM
> Subject: Re: [Engine-devel] Engine local configuration
> 
> 
> ----- Original Message -----
> > From: "Juan Hernandez" <jhernand at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, January 1, 2013 12:17:33 PM
> > Subject: Re: [Engine-devel] Engine local configuration
> > 
> > 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.
> > 
> 
> Alon & Juan,
> as a one-time setup which can auto-generate /local/ configuration
> based on target=`pwd`, this is something which makes sense, assuming
> engine-config and other utils will work. Otherwise this is
> meaningless.
This of course should be the goal. One can argue whether we should do it in one phase, or start with a basic patch, adding support of the different utilities in subsequent patches.
(I guess that doing that in subsequent patches will allow solving this issue today, improving it gradually to support all the different utilities).

> Additionally I'd expect engine developers to be able to perform
> mvn clean install -Pdep after the one-time setup and be able to
> work as they used to.
> 

That makes sense. But in addition we should have the ability to run setup again / upgrade, to allow testing changes in utilities, installer, etc, as these are components that aren't deployed in Jboss.

> Additionally and just as important;
> 
> - Such a discussion should be the base, and not postmortem of this
>   feature. It should lead to a design followed by implementation
>   and not the other way around.
> 
> - The patch that created the current state shouldn't have been merged
>   in the first place. It should have been taken into a feature
>   branch,
>   where other dependent patches will reside such as the one Juan just
>   mentioned (10539). So such an important feature can be properly
>   evaluated
>   and then merged as a complete feature.
> 
> Juan, is there a design we can read somewhere? The patch commit
> message
> is a good start, but as Alon suggested it may be lacking systemd
> handling,
> etc. So it would be nice to have all this written somewhere, once you
> return from your vacation. Additionally, as already mentioned,
> current
> hybrid state is not very inviting both for new and exiting
> contributers.
> Will it be possible to wither revert the existing or add an initial
> 'make xxx' to auto-generate whatever needed for existing code to
> work?
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 