RFC: MOM OS-level integration
by agl@us.ibm.com
After discussing MOM / VDSM integration at length, two different strategies have
emerged. I will call them Plan A and Plan B:
Plan A: MOM integration at the OS/Packaging level
Plan B: MOM integration as a new VDSM thread
This RFC is about Plan A. I will start another thread to discuss Plan B once I
have properly prototyped the idea in code.
Integration VDSM and MOM at the OS level is by far the simpler and least
intrusive option. As you can see from the included patch, the changes to vdsm
are very limited. In this model, VDSM interacts with MOM in the same way as it
uses libvirt. Upon installation, VDSM installs its own MOM configuration file
and restarts the MOM daemon (which continues to exist as an independent
system-level daemon). Once restarted, MOM will load its policy from the VDSM
configuration directory.
Pros:
- Simple and unobtrusive to either MOM or VDSM
- Clean API with no duplication or layering
- Maintain flexibility to tighten integration in the future
Cons:
- Momd runs as root (like supervdsm)
- If MOM will consume VDSM APIs, it must use the slower xmlrpc interface
Based on my experience while working on Plan A and Plan B, I feel that this
approach is the best way to start. Once MOM and VSDM are commingled on the node,
we can begin the interesting work of providing the actual dynamic policy to
manage the system.
Sample code for Plan A follows:
commit 4464c07849cfd921d0e3446961c5b6471dd360d9
Author: Adam Litke <agl(a)us.ibm.com>
Date: Mon Nov 28 08:46:22 2011 -0600
Integrate with MOM at the system/packaging level
diff --git a/vdsm.spec.in b/vdsm.spec.in
index cf12428..14588c6 100644
--- a/vdsm.spec.in
+++ b/vdsm.spec.in
@@ -151,6 +151,13 @@ rm -rf %{buildroot}
/usr/sbin/saslpasswd2 -p -a libvirt vdsm@rhevh < \
/etc/pki/vdsm/keys/libvirt_password
+# install the mom config file and restart momd
+if [ -f %{_sysconfdir}/momd.conf ]; then
+ mv -n %{_sysconfdir}/momd.conf %{_sysconfdir}/momd.conf.vdsmsave
+fi
+cp %{_sysconfdir}/%{vdsm_name}/momd.conf %{_sysconfdir}/momd.conf
+/sbin/service momd condrestart > /dev/null 2>&1
+
%preun
if [ "$1" -eq 0 ]
then
@@ -176,6 +183,12 @@ _EOF
/usr/sbin/saslpasswd2 -p -a libvirt -d vdsm@rhevh
+ # Restore old MOM configuration
+ if [ -f %{_sysconfdir}/momd.conf.vdsmsave ]; then
+ mv %{_sysconfdir}/momd.conf.vdsmsave %{_sysconfdir}/momd.conf
+ /sbin/service momd condrestart > /dev/null 2>&1
+ fi
+
%if 0%{?rhel}
if /sbin/initctl status libvirtd >/dev/null 2>/dev/null ; then
/sbin/initctl stop libvirtd >/dev/null 2>/dev/null
@@ -246,6 +259,8 @@ fi
%config(noreplace) %{_sysconfdir}/%{vdsm_name}/logger.conf
%config(noreplace) %{_sysconfdir}/logrotate.d/vdsm
%config(noreplace) %{_sysconfdir}/rwtab.d/vdsm
+%{_sysconfdir}/%{vdsm_name}/mom.policy
+%{_sysconfdir}/%{vdsm_name}/momd.conf
%{_sysconfdir}/sudoers.d/50_vdsm
%{_sysconfdir}/cron.hourly/vdsm-logrotate
%{_sysconfdir}/cron.d/vdsm-libvirt-logrotate
diff --git a/vdsm/Makefile.am b/vdsm/Makefile.am
index 7da9cad..a96a323 100644
--- a/vdsm/Makefile.am
+++ b/vdsm/Makefile.am
@@ -83,7 +83,9 @@ EXTRA_DIST = \
vdsm-restore-net-config.in \
vdsm.rwtab \
vdsm-sosplugin.py.in \
- vdsm-store-net-config.in
+ vdsm-store-net-config.in \
+ mom.policy \
+ momd.conf
# Reference:
# http://www.gnu.org/software/automake/manual/html_node/Scripts.html
@@ -115,7 +117,7 @@ install-data-hook:
install-data-local: install-data-init install-data-logger \
install-data-rwtab install-data-logrotate \
install-data-sudoers install-data-sosplugin \
- install-data-libvirtpass
+ install-data-libvirtpass install-data-mom
$(MKDIR_P) $(DESTDIR)$(vdsmtsdir)/keys
$(MKDIR_P) $(DESTDIR)$(vdsmtsdir)/certs
$(MKDIR_P) $(DESTDIR)$(vdsmlogdir)
@@ -128,7 +130,7 @@ install-data-local: install-data-init install-data-logger \
uninstall-local: uninstall-data-init uninstall-data-logger \
uninstall-data-rwtab uninstall-data-logrotate \
uninstall-data-sudoers uninstall-data-sosplugin \
- uninstall-data-libvirtpass
+ uninstall-data-libvirtpass uninstall-data-mom
install-data-init:
$(MKDIR_P) $(DESTDIR)$(sysconfdir)/rc.d/init.d
@@ -191,3 +193,13 @@ install-data-sosplugin:
uninstall-data-sosplugin:
$(RM) $(DESTDIR)$(pythondir)/sos/plugins/vdsm.py
+
+install-data-mom:
+ $(INSTALL_DATA) mom.policy \
+ $(DESTDIR)$(vdsmconfdir)/mom.policy
+ $(INSTALL_DATA) momd.conf \
+ $(DESTDIR)$(vdsmconfdir)/momd.conf
+
+uninstall-data-mom:
+ $(RM) $(DESTDIR)$(vdsmconfdir)/mom.policy
+ $(RM) $(DESTDIR)$(vdsmconfdir)/momd.conf
diff --git a/vdsm/mom.policy b/vdsm/mom.policy
new file mode 100644
index 0000000..cb31526
--- /dev/null
+++ b/vdsm/mom.policy
@@ -0,0 +1,155 @@
+### KSM ########################################################################
+
+### Constants
+# The number of pages to add when increasing pages_to_scan
+(defvar ksm_pages_boost 300)
+
+# The number of pages to subtract when decreasing pages_to_scan
+(defvar ksm_pages_decay -50)
+
+# The min and max number of pages to scan per cycle when ksm is activated
+(defvar ksm_npages_min 64)
+(defvar ksm_npages_max 1250)
+
+# The number of ms to sleep between ksmd scans for a 16GB system. Systems with
+# more memory will sleep less, while smaller systems will sleep more.
+(defvar ksm_sleep_ms_baseline 10)
+
+# A virtualization host tends to use most of its memory for running guests but
+# a certain amount is reserved for the host OS, non virtualization-related work,
+# and as a failsafe. When free memory (including memory used for caches) drops
+# below this parcentage of total memory, the host is deemed under pressure. and
+# KSM will be started to try and free up some memory.
+(defvar ksm_free_percent 0.20)
+
+### Helper functions
+(def change_npages (delta)
+{
+ (defvar newval (+ Host.ksm_pages_to_scan delta))
+ (if (> newval ksm_npages_max) (set newval ksm_npages_max) 1)
+ (if (< newval ksm_npages_min) (set newval ksm_npages_min) 0)
+ (Host.Control "ksm_pages_to_scan" newval)
+})
+
+### Main Script
+# Methodology: Since running KSM does incur some overhead, try to run it only
+# when necessary. If the amount of committed KSM shareable memory is high or if
+# free memory is low, enable KSM to try to increase free memory. Large memory
+# machines should scan more often than small ones. Likewise, machines under
+# memory pressure should scan more aggressively then more idle machines.
+
+(defvar ksm_pressure_threshold (* Host.mem_available ksm_free_percent))
+(defvar ksm_committed Host.ksm_shareable)
+
+(if (and (< (+ ksm_pressure_threshold ksm_committed) Host.mem_available)
+ (> (Host.StatAvg "mem_free") ksm_pressure_threshold))
+ (Host.Control "ksm_run" 0)
+ { # else
+ (Host.Control "ksm_run" 1)
+ (Host.Control "ksm_sleep_millisecs"
+ (/ (* ksm_sleep_ms_baseline 16777216) Host.mem_available))
+ (if (< (Host.StatAvg "mem_free") ksm_pressure_threshold)
+ (change_npages ksm_pages_boost)
+ (change_npages ksm_pages_decay))
+ }
+)
+### Auto-Balloon ###############################################################
+
+### Constants
+# If the percentage of host free memory drops below this value
+# then we will consider the host to be under memory pressure
+(defvar pressure_threshold 0.20)
+
+# If pressure threshold drops below this level, then the pressure
+# is critical and more aggressive ballooning will be employed.
+(defvar pressure_critical 0.05)
+
+# This is the minimum percentage of free memory that an unconstrained
+# guest would like to maintain
+(defvar min_guest_free_percent 0.20)
+
+# Don't change a guest's memory by more than this percent of total memory
+(defvar max_balloon_change_percent 0.05)
+
+# Only ballooning operations that change the balloon by this percentage
+# of current guest memory should be undertaken to avoid overhead
+(defvar min_balloon_change_percent 0.0025)
+
+### Helper functions
+# Check if the proposed new balloon value is a large-enough
+# change to justify a balloon operation. This prevents us from
+# introducing overhead through lots of small ballooning operations
+(def change_big_enough (guest new_val)
+{
+ (if (> (abs (- new_val guest.libvirt_curmem))
+ (* min_balloon_change_percent guest.libvirt_curmem))
+ 1 0)
+})
+
+(def shrink_guest (guest)
+{
+ # Determine the degree of host memory pressure
+ (if (<= host_free_percent pressure_critical)
+ # Pressure is critical:
+ # Force guest to swap by making free memory negative
+ (defvar guest_free_percent (+ -0.05 host_free_percent))
+ # Normal pressure situation
+ # Scale the guest free memory back according to host pressure
+ (defvar guest_free_percent (* min_guest_free_percent
+ (/ host_free_percent pressure_threshold))))
+
+ # Given current conditions, determine the ideal guest memory size
+ (defvar guest_used_mem (- (guest.StatAvg "libvirt_curmem")
+ (guest.StatAvg "mem_unused")))
+ (defvar balloon_min (+ guest_used_mem
+ (* guest_free_percent guest.libvirt_maxmem)))
+ # But do not change it too fast
+ (defvar balloon_size (* guest.libvirt_curmem
+ (- 1 max_balloon_change_percent)))
+ (if (< balloon_size balloon_min)
+ (set balloon_size balloon_min)
+ 0)
+ # Set the new target for the BalloonController. Only set it if the
+ # value makes sense and is a large enough change to be worth it.
+ (if (and (<= balloon_size guest.libvirt_maxmem)
+ (change_big_enough guest balloon_size))
+ (guest.Control "balloon_target" balloon_size)
+ 0)
+})
+
+(def grow_guest (guest)
+{
+ # There is only work to do if the guest is ballooned
+ (if (< guest.libvirt_curmem guest.libvirt_maxmem) {
+ # Minimally, increase so the guest has its desired free memory
+ (defvar guest_used_mem (- (guest.StatAvg "libvirt_curmem")
+ (guest.StatAvg "mem_unused")))
+ (defvar balloon_min (+ guest_used_mem (* min_guest_free_percent
+ guest.libvirt_maxmem)))
+ # Otherwise, increase according to the max balloon change
+ (defvar balloon_size (* guest.libvirt_curmem
+ (+ 1 max_balloon_change_percent)))
+
+ # Determine the new target for the BalloonController. Only set
+ # if the value is a large enough for the change to be worth it.
+ (if (> balloon_size guest.libvirt_maxmem)
+ (set balloon_size guest.libvirt_maxmem) 0)
+ (if (< balloon_size balloon_min)
+ (set balloon_size balloon_min) 0)
+ (if (change_big_enough guest balloon_size)
+ (guest.Control "balloon_target" balloon_size) 0)
+ } 0)
+})
+
+### Main script
+# Methodology: The goal is to shrink all guests fairly and by an amount
+# scaled to the level of host memory pressure. If the host is under
+# severe pressure, scale back more aggressively. We don't yet handle
+# symptoms of over-ballooning guests or try to balloon idle guests more
+# aggressively. When the host is not under memory pressure, slowly
+# deflate the balloons.
+
+(defvar host_free_percent (/ (Host.StatAvg "mem_free") Host.mem_available))
+(if (< host_free_percent pressure_threshold)
+ (with Guests guest (shrink_guest guest))
+ (with Guests guest (grow_guest guest)))
diff --git a/vdsm/momd.conf b/vdsm/momd.conf
new file mode 100644
index 0000000..4d09f44
--- /dev/null
+++ b/vdsm/momd.conf
@@ -0,0 +1,83 @@
+### DO NOT REMOVE THIS COMMENT -- MOM Configuration for VDSM ###
+
+[main]
+# The wake up frequency of the main daemon (in seconds)
+main-loop-interval: 5
+
+# The data collection interval for host statistics (in seconds)
+host-monitor-interval: 5
+
+# The data collection interval for guest statistics (in seconds)
+guest-monitor-interval: 5
+
+# The wake up frequency of the guest manager (in seconds). The guest manager
+# sets up monitoring and control for newly-created guests and cleans up after
+# deleted guests.
+guest-manager-interval: 5
+
+# The wake up frequency of the policy engine (in seconds). During each
+# interval the policy engine evaluates the policy and passes the results
+# to each enabled controller plugin.
+policy-engine-interval: 10
+
+# A comma-separated list of Controller plugins to enable
+controllers: Balloon, KSM
+
+# Sets the maximum number of statistic samples to keep for the purpose of
+# calculating moving averages.
+sample-history-length: 10
+
+# The URI to use when connecting to this host's libvirt interface. If this is
+# left blank then the system default URI is used.
+libvirt-hypervisor-uri: qemu:///system
+
+# Set this to an existing, writable directory to enable plotting. For each
+# invocation of the program a subdirectory momplot-NNN will be created where NNN
+# is a sequence number. Within that directory, tab-delimited data files will be
+# created and updated with all data generated by the configured Collectors.
+plot-dir:
+
+# Activate the RPC server on the designated port (-1 to disable). RPC is
+# disabled by default until authentication is added to the protocol.
+rpc-port: -1
+
+# At startup, load a policy from the given file. If empty, no policy is loaded
+policy: /etc/vdsm/mom.policy
+
+[logging]
+# Set the destination for program log messages. This can be either 'stdio' or
+# a filename. When the log goes to a file, log rotation will be done
+# automatically.
+log: /var/log/momd.log
+
+# Set the logging verbosity level. The following levels are supported:
+# 5 or debug: Debugging messages
+# 4 or info: Detailed messages concerning normal program operation
+# 3 or warn: Warning messages (program operation may be impacted)
+# 2 or error: Errors that severely impact program operation
+# 1 or critical: Emergency conditions
+# This option can be specified by number or name.
+verbosity: info
+
+## The following two variables are used only when logging is directed to a file.
+# Set the maximum size of a log file (in bytes) before it is rotated.
+max-bytes: 2097152
+# Set the maximum number of rotated logs to retain.
+backup-count: 5
+
+[host]
+# A comma-separated list of Collector plugins to use for Host data collection.
+collectors: HostMemory, HostKSM
+
+[guest]
+# A comma-separated list of Collector plugins to use for Guest data collection.
+collectors: GuestQemuProc, GuestLibvirt
+
+# Collector-specific configuration for GuestQemuAgent
+[Collector: GuestQemuAgent]
+# Set the base path where the host-side sockets for guest communication can be
+# found. The GuestQemuAgent Collector will try to open files with the following
+# names:
+# <socket_path>/va-<guest-name>-virtio.sock - for virtio serial
+# <socket_path>/va-<guest-name>-isa.sock - for isa serial
+socket_path: /var/lib/libvirt/qemu
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
12 years, 6 months
Proposed next-generation vdsm API
by agl@us.ibm.com
Recently we've had some very productive discussions concerning the VDSM API. I
want to attempt to refocus the discussion around an emerging proposal and see if
we can agree on a sensible path forward.
Based on the discussion, I have identified the following requirements that
a new API for vdsm should have:
1.) Single API that can be consumed by ovirt-engine and ISVs
- We don't want to maintain multiple parallel APIs
- To develop a vendor ecosystem, we must have a robust external API to
vdsm
2.) Full vdsm capabilities are exposed without requiring ovirt-engine
- ovirt components should be modular and independently useful
- Some deployments might want to manage nodes without ovirt-engine
3.) Standardized protocol with low overhead
- Required for widespread adoption
4.) Support for asynchronous tasks and events
- Needed by ovirt-engine and other consumers
Based on these requirements, the following proposal has started to emerge:
Create a REST API that will provide all of the functionality that is currently
available via the xmlrpc interface (with the goal of deprecating xmlrpc once it
becomes mature enough). To support advanced clustering features that
ovirt-engine is planning, we'll write an QMF broker that can proxy the REST API
onto a message bus. ovirt-engine will interact with vdsm exclusively over this
bus but the REST API will be the principle API and the entry point for ISV apps.
A REST API provides a light-weight and standard way to access all of the vdsm
functionality.
The REST API will handle events by exposing a new 'events' collection at the api
root. REST users will use some sort of polling to collect these events. The
details of this interface are being worked on. Several ways for minimizing the
impact of polling have been discussed. The QMF broker can expose a
publish/subscribe model for events as appropriate.
Is this model an acceptable way to improve the vdsm API? I would like to hear
the opinions of ovirt-engine developers, vdsm developers, and other
stakeholders. Thanks for providing feedback on this proposal!
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
12 years, 6 months
Announcing a proof of concept REST API for VDSM
by agl@us.ibm.com
https://github.com/aglitke/vdsm-rest/
Today I am releasing a proof of concept implementation of a REST API for vdsm.
You can find the code on github. My goal is to eventually replace the current
xmlrpc interface with a REST API. Once completed, ovirt-engine could switch to
this new API. The major advantages to making this change are: 1) VDSM will gain
a structured API that conceptually, structurally, and functionally aligns with
the ovirt-engine REST API, 2) this new API can be made public, thus providing an
entry point for direct virtualization management at the node level.
Status:
-------
The REST API currently lives outside of VDSM in its own tree. It maps the
current vdsm python bindings into a resource hierarchy and exposes it using
CherryPy. The existing vdsm API is not fully implemented yet in the REST API.
I made the decision to release now in order to gauge interest and gain some
feedback. There are three main issues that I would like to get some comments
on:
The storage API is undergoing some major changes but this API still uses the old
API. I will make the necessary changes in tandem. Once finished, I think this
code could be run from a thread inside vdsm (similar to the way xmlrpc is done
today).
To support a standalone VDSM use case, the current code makes use of a storage
mechanism to persist virtual machine definitions. At present, this is
implemented as a SQLite database that stores blobs. We also use this DB to
store information about configured storage pools (since disconnected storage
pools are not known to vdsm). This system does not make sense for a vdsm that
is connected to ovirt-engine. In that case, storage pools and virtual machines
are managed by the management server and "pushed" to vdsm. To accomodate both
use cases we will need to support a configuration option that determines if
local storage of objects is to be used. By default this will be disabled and
only active VM and storage pool resources will be represented by the API.
ovirt-engine wants to subscribe to asynchronous events. REST APIs do not
typically support async events and instead rely on polling of resources. I am
investigating what options are available for supporting async events via REST.
Getting started:
----------------
Please check out the source and https://github.com/aglitke/vdsm-rest/wiki/HOWTO
for quick start instructions. You will need to install a back-level version of
vdsm and apply a small patch. Of course this is temporary.
I look forward to your comments!
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
12 years, 6 months
need help for building vdsm on fedora16
by Jenna Johnson
build vdsm rpm on fedora16,32bit
./autobuild.sh
make rpm
encounted error:
Architecture is not included: i386
./configure --target=i686-->useless:(
change makefile adding target i686 still useless:(
my question is:
1.should I configure with something for this error?
2.Do I need to install libvirt,qemu or other staffs to make vdsm work?
12 years, 6 months
MOM integration questions
by agl@us.ibm.com
Hi guys,
I've got MOM up and running as a vdsm thread but I've hit two small problems.
I'll bounce them around on the list to see if people have some ideas.
1.) Libvirt SASL authentication
I was able to easily modify MOM to connect to libvirt by hardcoding the vdsm
credentials. Obviously this is not an acceptable long-term solution. What is
the best way to share the vdsm libvirt password with MOM in a way that does not
compromise security? Whatever method we choose should not involve vdsm-specific
changes to MOM. For starters I think I will just place the username and
password in the mom.conf file. We could make this file readable only by the
vdsm user. Thoughts?
2.) Permissions
The first error I noticed was MOM failing to adjust KSM via sysfs:
2011-11-22 10:13:48,313 - mom.Controllers.KSM - WARNING - KSM: Failed to write
/sys/kernel/mm/ksm/run: Permission denied
MOM is used to running as root so that it can adjust these settings. I would
prefer not to complicate the MOM architecture by having a separate process that
receives instructions from the main MOM thread and then applies the requested
changes as root.
Another solution would be to allow MOM to run as a completely separate daemon
(as it has been originally doing). In this scenario, vdsm would reconfigure MOM
by replacing the default configuration file and policy. vdsm could then
interact with the running momd via the existing xmlrpc interface.
Thoughts on these issues?
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
12 years, 6 months
Recommended network setup for network-based storage (NFS, iSCSI)
by ykaul@redhat.com
As we are getting some newer gear, I was wondering what is a better
setup for network-based storage in our lab (all our hosts will have >1
interface, and our storages - either 4x1Gb or some with 10Gb).
NFS:
Am I correct to assume that NFS, from a single host, will not benefit
much from bonding, when connected to a single storage domain (= a single
mount). Isn't it using a single TCP connection? (which btw implies we
might get better perf. with multiple mounts?).
iSCSI:
Am I better off configuring multipathing rather than bonding for iSCSI,
for the same reason? Configure two IPs on two interfaces on the host,
same on the storage? (which btw hints at why iSCSI from the QEMU level
is an interesting feature).
Should I 'cheat' and configure multiple IPs on the bonded interfaces on
the storage side?
For both I'm sure jumbo frames would be nice, and we will be using it
partially in our labs.
TIA,
Y.
12 years, 6 months
converging around a single guest agent
by bazulay@redhat.com
Hi,
One of the breakout sessions during the ovirt workshop [1] was about the guest
tools, and focused mainly on the ovirt-guest-agent [2].
One of the issues discussed there, was the various existing guest agents out
there, and the need to converge the efforts to a single agent that will serve
all.
while 4 agents were mentioned (Matahari, vdagent, qemu-ga & ovirt-guest-agent)
during that discussion, we narrowed it down to 2 candidates:
qemu-ga (aka virt-agent):
-------------------------
- Qemu specific - it was aimed for specific qemu needs (mainly quiesce guest
I/O)
- Communicates directly with qemu (not implemented yet)
- Supports ?
- So far linux only
- written in C
Ovirt-guest-agent:
------------------
- Has been around for a long time (~5 years) - considered stable
- Started as rhevm specific but evolved a lot since then
- Currently the only fully functional guest agent available for ovirt
- Written in python
- Some VDI related sub components are written in C & C++
- Supports a well defined list of message types / protocol [3]
- Supports the folowing guest OSs
Linux: RHEL5, RHEL6 F15, F16(soon)
Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)
The need to converge is obvious, and now that ovirt-guest-agent is opensourced
under the ovirt stack, and since it already produces value for enterprise
installations, and is cross platform, I offer to join hands around ovirt-
guest-agent and formalize a single code base that will serve us all.
git @ git://gerrit.ovirt.org/ovirt-guest-agent
Thoughts ?
Thanks
Barak Azulay
[1] http://www.ovirt.org/news-and-events/workshop
[2] http://www.ovirt.org/wiki/File:Ovirt-guest-agent.odp
[3] http://www.ovirt.org/wiki/Ovirt_guest_agent
12 years, 6 months
Re: [Users] ovirt-node on Gentoo
by abaron@redhat.com
----- Original Message -----
> On Mon, Nov 21, 2011 at 12:58:29PM +0200, Doron Fediuck wrote:
> > Hi Guys,
> > Well, it looks like we've hit our first distro-diversion.
> >
> > First of all, let's define the issues, and then see how we solve
> > each one;
> >
> > 1. Dimitrije is referring to vdsm's init script (including
> > vdsm-reg).
> >
> > 2. What Jared is referring to is relevant to:
> > - Host installation process (AKA bootstrapping and registration)
> > - vdsm operations on host networking
> >
> > I agree it will be better if we solve each issue using the same
> > code for all distro's. Having said that, we need to see if it's
> > an achievable task.
> >
> > Taking Dimitrije's issue as an example, we hit the first
> > conflict; Gentoo is using OpenRC by default (and has some BSD-style
> > leftovers), while RedHat and Fedora are using their SysV-style
> > implementation, which confirms to LSB. Also, some Fedora services
> > are moving to systemd implementation. Obviously these
> > implementations
> > are not trivial to bridge. So where Fedora's script will have
> > "Required-Start:"
> > Gentoo will use a depend() function (see vixie-cron as a sample).
> > So unless we find a magical bridge for init standards, we'll have
> > to have several init scripts, and each distro will use it's own
> > script. We can try and generalize it, to make sure distor's
> > with similar implementations use the same script.
> >
> > As for Jared's networking issues, I believe there's more room
> > here to make the relevant code more flexible, by testing the needed
> > files, and using what we find. Thus, we'll have all in the same
> > codebase. You can start by taking a look at vdsm/netinfo.py in
> > vdsm's git.
>
> And, as mentioned by Daniel Berrange, Vdsm should probably be changed
> to
> be using netcf to configure host networking. I'm not sure if Gentoo
> has
> netcf back-end, though.
Actually we're thinking about NetworkManager, not netcf.
>
> I'm sure that there are plenty of other Fedoraisms lurking in Vdsm.
> We
> would have to take them down one by one.
>
> Dan.
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
12 years, 7 months
Today's bi-weekly Sync Call
by Dan Kenigsberg
Hi Folks,
Please propose items for today's agenda.
Had I reviewed Adam's RESTful API, I would have listed it myself.
Unfortunately this is not yet the case :-(
Dan.
12 years, 7 months