incubator-tashi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Stroucken <mxs+apa...@cmu.edu>
Subject Re: Making a release
Date Tue, 24 Jan 2012 17:48:53 GMT
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.

Mime
View raw message