not easy to install and set up Invirt

[Greg Price]

There's no reasonable way right now for someone to set up an Invirt cluster without getting help from the Invirt developers.
The process is something like

 - install Hardy on a fresh physical machine
 - add "deb http://xvm.mit.edu/invirt stable main" to the sources.list
 - install invirt-host-master
 - run invirt-install to make some system/management VMs (which? we know, but haven't documented)
 - compose an /etc/invirt/master.yaml
 - boot up each sysvm, add master.yaml, install its respective metapackage (or metapackages, for master)
 - hope everything works, figure out what broke, fix it

Much of this could be made simpler.

[Greg Price (gregprice)]

In an email thread I wrote:

"""
I think we want it to be something like
 - make an /etc/invirt/master.yaml config file based on an example
 - from an apt repo that we run, install invirt-host-master on one or
   more hosts, together with an empty equivs package invirt-manual-config
   that provides invirt-config
 - run some as-yet-unwritten script to make an autoinstaller and sysvms;
   invirt-install does the heavy lifting

but aside from the three pieces in that sketch that don't exist, there
are likely many other steps that a sysadmin would have to do to get
Invirt running as things stand.
"""

[Evan Broder (broder)]

This is probably one of our higher priority bugs, since we already have other groups interested in using Invirt

[Evan Broder (broder)]

As part of this ticket, we should figure out what the development environment looks like going forward. This is going to be relevant for us, even, independent of HCS or other groups using Invirt, since we'll hopefully have two live cluster soon.

We should figure out things like

  - Are we the only people who are going to be running an apt repository? A svn repository? This puts more burden on us in terms of keeping our software up to date, but that might be acceptable if not preferable. On the other hand, I find it a little presumptuous to think that we're the only people who will want to roll packages and so forth.
  - If nobody else is running and apt repository, then invirt-dev is purely an internal package. That's actually kind of cool, because it substantially simplifies the process of setting up a new master VM, since you don't have to screw around with the sbuild config.
  - Even within our own infrastructure, do we let the dev cluster commit to the svn repository? How is the dev apt repository connected to the prod apt repository? We need to find something that allows non-prod maintainers to upload packages for testing on dev. This might be an excellent opportunity to make use of the unstable and stable components we created in the apt repository.

These are the issues that spring to mind, but there are probably more. Just things to think about.

[Greg Price (gregprice)]

Good questions.

svn: The dev cluster won't have filesystem-level access to the svn
repo like prod does, but we can commit from there through the https
URI like we do from our own machines. Maybe that's not the question
you had in mind.

apt, dev vs prod: I'm happy with either unstable/stable or two apt
repos from the usage side. How does uploading work without local file
access? If we can let system:xvm upload to unstable from xvm-dev
while only system:xvm-root can upload to stable and only from xvm,
then that sounds like a good plan. If not then let's have a dev and a
prod repo.

apt for other people: Yeah, I think the real trouble with expecting
nobody else to have an apt repo is that other people will definitely
want local changes. At least some other people will, in particular
our first few outside users. Probably we want to
 - support local apt repos, for a completely independent installation
 - run a no-really-stable apt repo on invirt.mit.edu or somesuch for
   users that just want to run the software. Those users can skip
   sbuild, for instance. Not sure how we want to do the release
   engineering for this; fortunately we don't need it much for our
   first outside users.

Sound reasonable?

Greg

On Sun, Dec 07, 2008 at 01:44:27AM -0000, Evan Broder wrote:
> As part of this ticket, we should figure out what the development
> environment looks like going forward. This is going to be relevant for
> us, even, independent of HCS or other groups using Invirt, since we'll
> hopefully have two live cluster soon.
>
> We should figure out things like
>
> - Are we the only people who are going to be running an apt repository? A svn repository? This puts more burden on us in terms of keeping our software up to date, but that might be acceptable if not preferable. On the other hand, I find it a little presumptuous to think that we're the only people who will want to roll packages and so forth.
> - If nobody else is running and apt repository, then invirt-dev is purely an internal package. That's actually kind of cool, because it substantially simplifies the process of setting up a new master VM, since you don't have to screw around with the sbuild config.
> - Even within our own infrastructure, do we let the dev cluster commit to the svn repository? How is the dev apt repository connected to the prod apt repository? We need to find something that allows non-prod maintainers to upload packages for testing on dev. This might be an excellent opportunity to make use of the unstable and stable components we created in the apt repository.
>
> These are the issues that spring to mind, but there are probably more.
> Just things to think about.
>
> --
> not easy to install and set up Invirt
> https://bugs.launchpad.net/bugs/305673
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Invirt Project: Confirmed
>
> Bug description:
> There's no reasonable way right now for someone to set up an Invirt cluster without getting help from the Invirt developers.
> The process is something like
>
> - install Hardy on a fresh physical machine
> - add "deb http://xvm.mit.edu/invirt stable ...