On Tue, Jun 26, 2012 at 4:44 PM, Florian Haas <flor...@hastexo.com> wrote: > On Mon, Jun 25, 2012 at 1:40 PM, Andrew Beekhof <and...@beekhof.net> wrote: >> I've added the concept of a 'system service' that expands to whatever >> standard the local machine supports. >> So you could say, in xml, <primitive id="Magic" class="system" type="mysql"> >> and the cluster would use 'lsb' on RHEL, 'upstart' on Ubuntu and 'systemd' >> on newer fedora releases. >> Handy if you have a mixed cluster. >> >> My question is, what to call it? >> 'system', 'service', something else? > > I think Red Hat Cluster has similar functionality named "service", so > in the interest of continuity that would be my preference.
Fair enough, thats what David went with originally, I just wanted to put it out there before it got set in stone. > One thought though: what's supposed to happen on platforms that > support several system service interfaces, such as Ubuntu which > supports both Upstart and LSB? IOW: If I define a service as > service:foobar, and there is no upstart job named foobar, but > /etc/init.d/foobar exists, would that be an OCF_ERR_INSTALLED? No. We'd use the LSB script. We check all available system type services until we find a match. If someone actually wanted the OCF_ERR_INSTALLED behaviour, 'lsb' and 'upstart' will continue to exist as possible classes. So they would use upstart:foobar instead. > >> In other news, the next pacemaker release will support systemd and both it >> and upstart will use a persistent connection to the DBus API (no more >> forking!). > > Sweet! Code is now in Clusterlabs/master if you want to take it for a spin. _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
