Hi everyone,
I did a second install of Tashi inside a new system. I addressed some
problems with the tree, for example commenting the accounting
configuration to retain awareness of it, but to avoid having it enabled
as a default if someone decides to use the distributed configuration
directly.
The whole install went rather fast, not a bad setup at all. The branch
chosen was stroucki-accounting; a test update was also done at IRP
successfully using this branch. I think this branch should be made the
release candidate.
This pass was a naive install, to see how someone doing obvious steps
without a lot of background knowledge would fare. The results:-
1)
A successful install will have prerequisites. These run from low to
medium complexity, probably have no generally accepted defaults, and as
such I propose we declare them as out of scope for the installation of
Tashi itself. Where appropriate, we should give helpful hints though. My
list:-
a) RPyC-3.1.0 is a prerequisite. The software is easily obtained and
installed.
b) A hypervisor is a prerequisite. Qemu is more tested, Xen less so.
Tutorials I write will use Qemu for now.
c) OS images are prerequisites. They need to be prepared before deployment.
d) A host's hostname should be set (but need not match DNS).
e) Networking must be engineered beforehand. Tashi will call a script
based on network ID; the user should provide that script to connect the
hosts virtual interface to the appropriate host network. The host OS
must be set up to route if appropriate.
2)
The default qemuBin configuration points to what appears to be a locally
compiled version. This should be set to /usr/bin/kvm. Can someone
confirm that /usr/bin/kvm is also the proper name on Ubuntu?
3)
The NM no longer has use for the infoFile parameter, so it should be
removed.
4)
I think it's annoying to have to hack up Python data structures to
initialize the CM. I think the default should be to use sqlite; it's
easier to work with, most people have some familarity with SQL and all
daemons could be left running in the background.
5)
Default log output is to the console; not necessarily bad, but I would
guess even naive users expect logs in /var/log by default. Any preferences?
6)
Users must change Vfs/prefix to point to somewhere (large) where Tashi
can read and write stuff. OS images must be located under ./images.
Suspend and resume images must be located under ./suspend.
7)
The DhcpDns hook needs configured before it would be usable. I propose
it be unhooked from the scheduler. VMs may be found by scanning the
network the VM is attached to, probing the next available IP addresses,
or by attaching to the VM's console. Or does someone know of a sure way
to register a name / mac address pairing with a home router?
8)
When installing in a place like /usr/local/tashi, running the Tashi
programs requires being in that directory and calling the programs like
bin/tashi-client.py. This permits the default config to be read, since
./etc is a search path. I would argue that no relative paths should be
read by default and ./etc should be changed to /usr/local/tashi/etc. A
better thing would be to have the install location configurable.
9)
The programs all end with ".py". Yes, they are python scripts, but users
probably don't care and it may trigger negative associations of scripts.
I propose that executables in the bin/ directory be stripped of their
suffix.
10)
We have documentation on the web, but Apache standards call for textual
documentation to be included in the distribution. That needs to be
provided. Richard, do you have any documentation on setting up Zoni?
I'll do a "script"ed install again today and will report.
Greetings,
Michael.
