Re: [Xen-devel] [ANNOUNCE] Project Raisin

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 1 Apr 2015, George Dunlap wrote:
> On Tue, Mar 31, 2015 at 11:16 AM, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > Hi all,
> >
> > A few weeks ago I started hacking on a new project, consisting in a set
> > of bash scripts to build xen-unstable and a few other useful elements.
> > It is still in very early stages.
> >
> > The name of the new project is "Raisin", from Raise Xen, pun intended
> > ;-)
> > It is a bit like DevStack[1] for Xen: its purpose is to simply and
> > quickly retrieve and build Xen and any other related components from
> > source, such as Libvirt and Grub2. Optionally it can install and
> > configure the system for you. In the future it could also build and
> > configure stub domains and driver domains. Another important goal of the
> > project is to effectively act as a working guideline on how to setup a
> > Xen system, so it is important that the code is easy to read and
> > understand. See the README for more information.
> >
> > With the introduction of Raisin, keeping xen-unstable lightweight, clean
> > and well suited for distro packages is going to be easier because we
> > won't have to make compromises with the ease of installation from
> > source. Raisin is going to take care of setting up a full Xen
> > development environment from scratch. As an example, going forward we
> > can move the QEMU build from xen-unstable to Raisin, and integrate
> > Raisin in OSSTest.
> >
> > I would like Raisin to work on as many distros as possible. At the
> > moment Raisin builds have been tested on Debian and Fedora.
> > Installations and system configurations have been tested only on Debian.
> >
> > I would very much appreciate if anybody with expertise on Fedora, CentOS
> > and other distros could help add proper support for them.
> >
> >
> > The code is available here:
> >
> > git://xenbits.xen.org/people/sstabellini/raisin.git
> > http://xenbits.xen.org/gitweb/?p=people/sstabellini/raisin.git
> 
> Hey Stefano!  Looks like a pretty useful package overall.
> 
> Some initial feedback:
> 
> Automatically installing packages via sudo without asking scares me.

I understand your concerns, however using sudo is the norm nowadays in
similar projects. DevStack, after which this project is modelled, does
that for example. Not the Docker is a great model but Docker also does
that.

You can still avoid this behaviour by passing -n to raise.sh. We should
probably clarify that you can (should?) avoid sudo entirely by passing -n.


> I think "raise" should take commands.  The main way package
> prerequisites should be installed, I think, is for raise to give a
> list of packages to the user, and the user to "sudo $PACKAGEMANAGER
> install $LIST" themselves.

Giving commands to raise could be a good UI improvement, but I disagree
on the package installation. In any case there is a way around that,
using the -n option. Maybe we could consider making that the default.


> e.g.:
> ---
> $ ./raise check_build_dependencies
> Packages required for build:
> build-essential libtool autoconf autopoint [...]
> 
> Optional packages for additional functionality:
> [blah]
> ---
> 
> or (for example)
> 
> $ sudo yum install -y $(./raise check_build_dependencies -min -all)
> 
> Then the normal way of doing things should be:
> * Edit config file
> * ./raise check_build_dependencies
> * [Install]
> * ./raise build
> * sudo ./raise install
> 
> Other functionality it might be nice to have:
> * "build-srcpkg", which will make source rpms/debs
> * "build-pkg", which would make installable packages; perhaps with
> "install-pkg" which would automatically install them all for you
> * "build [component]" -- if you only want to build a single component
> (or set of them)
> 
> What do you think?

At the moment the user can specify what to build using the config file.
I guess that being able to do it via command line too could be a nice
addition. build-srcpkg would be nice to have. I already introduced an
implicit build-pkg while install-pkg is basically raise.sh -i. So what
you are proposing is mostly a UI change, rather than a change in
functionality.

So far the idea has been that most users will just want to run raise.sh,
without any arguments or parameters, and everything will be set and
ready when the script completes.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel