[Ovirt-devel] A few things (rather long actually)

[Daniel P. Berrange]

On Fri, Feb 15, 2008 at 06:26:26AM -0500, Daniel Veillard wrote:
>  + related to it, it's really good to have a glossary, use only the 
>    same terms though the documentation for the same pieces of the
>    infrastructure. Ideally this should match libvirt terminology
>    (Node/Hypervisor/Domain), in the graphic I made:
>     - Console Node: for the physical machine running the WUI appliance

That's a reasonable choice, or possibly 'Admin node'.

>     - Cluster Nodes: for the physical barebone machines used to run
>       the user domains

The choice of the word 'cluster' is not good - the managed nodes can
be standalone, or they can be clustered. I prefer 'Managed nodes'.

>     - WUI appliance: the domain running the services needed for ovirt
>       provisionning, authentication and management
>     - managed domains: for the domains the user actually want to run and
>       control
>    those terms are my pick, I find
>     'oVirt host(s)' and 'oVirt management host' too similar to the point
>     they are confusing and not matching libvirt own terminology, sorry :-)

We can add a glossary of terms to the documentation area of the website,
or even better put it in the wiki so anyone can add entries for things
they think need explaining.

>  + it's hard to see the requirement for installing my current list so
>    far is:
>    - one 64bits machine with an existing OS and KVM support to run the
>      WUI appliance domain, 2-3 GB available in the root user directory
>      (Xen based fully virt may work also with tweaking)
>    - at least one node for the cluster, a bare machine, able to 
>      PXE boot (ideally otherwise booting from a CD or USB key) 
>      64bits with hardware virtualization support
>    - at least one network connecting the machines and DNS and DHCP
>      for that network are under the user control (this may be relaxed
>      in the future)
>    General feedback is that this is a very contraining set, which may put
>    many 'would be' testers off, it's really better to put those upfront
>    nothing is worse from their viewpoint than spending time for nothing,
>    on the other hand being explicit may get some of them in an helping mood
>    since we generally want to remove/ease a lot of those requirements.

I've expanded the detail in the FAQ to give much more info about the
requirements for deployment - can you take a look at it on the website
now. I think it covers the points you raise here.

>   - Building the appliance from a kickstart is actually hard to set up,
>     do not suggest it as a way to avoid the time of the download
>       "Booting and provisioning a host or a VM with a kickstart is left
>       as an exercise for the reader."
>     is condescending, actually very hard, get rid of the section, assume
>     user will follow the standard track (download + using KVM), but document
>     separately the process for rebuilding the appliance, and changes needed
>     to run it as a Xen fully-virt domain (I assume only the xml and way to
>     launch the applicance need changes)

I'd like to get to a place where building an either the wui appliance,
or the managed host appliance consists of nothing more than invoking the
Fedora livecd-creator tool. There is some work going on to make the
livecd-creator more general purpose, so I think this is doable in the
the Fedora 9 timescale.


Just a reminder to anyone with suggestions - the wiki is available for any
adhoc content you think will be useful to others...

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|