6:11 p.m.
On Fri, Nov 20, 2015 at 1:54 PM, Giuseppe Ragusa
<giuseppe.ragusa(a)hotmail.com> wrote:
Hi all,
I'm trying to organize my wishes/hopes for oVirt 4.0
These items derive from both solitary mumblings and community talks at the the first
Italian oVirt Meetup.
I offer to help in coding (work/family schedules permitting) but keep in mind that
I'm a sysadmin with mainly C and bash-scripting skills (but hoping to improve my
less-than-newbie Python too...)
Since I have related interests/wishes also for Engine and VDSM, I'll send a separate
message for each one.
Giuseppe,
this is a nice compilation of wishes!
Let's start from the oVirt Node:
*) oVirt Node complete convergence with Atomic Host: start from Project Atomic tools and
define an ISO-installable Atomic Host variant [1] to include gluster, qemu, libvirt, vdsm
and all the packages/configurations that an oVirt Node would need (remove unneeded parts)
That's a nice idea and we actually actively investigated to use Atomic Host.
Atomic is pretty strong on quickly building and deploying trees. It
also provides the nice features to rollback in case of accidents, and
also has a vibrant community.
But we encountered a few issues i.e. Atomic has tough requirements on
how the root filesystem must look, and how packages can touch/change
the root file-system. Besides that we were seeing issues when it comes
to support a wider range of (multipathed) storage hardware. To just
name two issues.
So for now we don't aim to build Node an the foundations of Atomic.
But we are working on an approach which is similar to Atomic and
allows us to address some long standing issues and make Node much
easier to use, maintain, and customize.
Stay tuned for news on the Node development road-map.
*) add oVirt Node ability to host containers (independent of the
above mentioned convergence with Atomic); note that Atomic Host has Docker/Kubernetes, but
libvirt already has a LXC driver [2] and the Engine could benefit from some added
smartness in managing groups of guests etc. in the vm case too; there are related wishlist
items on configuring/managing containers on the Engine and on VDSM
Actually a good point which I also had on my mind.
The main focus of Node will be to host VMs, but having basic container
support to host containers for supporting a feature is surely
something interesting.
*) add Open vSwitch direct support (not Neutron-mediated); there are
related wishlist items on configuring/managing Open vSwitch on the Engine and on VDSM
This will need work on the vdsm side before it makes sense to pull
this into Node.
*) add oVirt Node ability to fully perform as a stand-alone
hypervisor: I hear that Cockpit is coming, so why not Kimchi too? ;)
Yep, Cockpit will be part of the game on Node.
Kimchi might be problematic - not because of Node - but because of the
way how libvirtd is tuned towards vdsm.
The last time I looked the issue was that libvirtd is not consumable
by kimchi anymore, once vdsm has configured it.
And to me it looks like this does not really fit anyway right now,
because the current assumption is that Engine has the full control
over VMs - and this would be not true anymore if you could use kimchi
to administer your VMs.
- fabian