Hello, Not speaking as a SLES user, but interested in background how this is moving forward. Although also not a systemd developer and not actually looked at how the systemd project code is managed, 1. I think that the systemd project has split up its code as "core" with other non-core units managed as "modules." Am not certain, but believe this why "systemctl --version" returns the systemd version number (currently 195 for openSUSE 12.3, uncertain what might be for anything else) and below that the distro name (suse) and several names in capital letters (likely modules?). 1a. So, my first thought is whether there might be code upstream from Fedora as an official "module" somewhere. If so, although Fedora is leading implementation I wonder if upstream is more stable and perhaps "basic." 1b. My second thought is that when messing with systemd units, it might be advisable to have at least some minimal communication with whoever determines core and maybe module code being implemented as a whole in SUSE/openSUSE. Although I think the namespaces are pretty safe, IMO the SUSE overall decision-makers on systemd versions and updating from upstream should at least know what is being done here to avoid duplication of effort and possible conflicts. How is the current code that is being created going to be distributed, as a "module?" If not, I think it'd be a mistake to just deploy Units ad hoc to distros. 2. Am I correct that the only code being considered is to simply integrate with Quantum which is a SLES only implementation, not available to openSUSE? 3. Because I don't have visibility into what is happening in SLES (I'm deploying only on openSUSE personally), as someone who has been studying/learning systemd on 12.3, on general principles implementing compiled code Units that replace and do not just reference init scripts is good for many reasons. If the Unit simply references an init script, it can still be useful bridging to eventual replacement, allows systemctl commands (like status) to greatly enhance troubleshooting and management and presumably allows the process to run as an "equal citizen" managed in a cgroup instead of buried in a hierarchy called the "legacy" way. 4. More Units (and defined Unit services) is supposed to be good on general principles. AFAIK defining greater numbers of Units means more granularity in the code which should enhance future maintenance, updates and upgrades. Since the "parent" Unit and the child Units called by that parent are in the same cgroup, this should not increase the complexity exposed to the User and Management tools. 4a. If Fedora is that much different than SUSE, perhaps a short conversation with someone "over there" might be beneficial to know <why>, eg does someone have thoughts on some kind of management tool that would read values generated by some of these Units? Or, is it something someone decided to do just on instinct? Also, the "greater number of Fedora service units" might only mean that the Fedora you were looking at is a more advanced version (ie version number greater than 195). It might be that if you compared the same level systemd on both the Fedora and SUSE system you're working on, the number of service units would be very similar. Just some of my thoughts, Tony On Tue, Apr 23, 2013 at 11:35 AM, Andreas Jaeger <aj@suse.com> wrote:

I've started adding systemd service files to quantum (taking what Fedora has) and noticed that their setup is different from ours, especially they have many more service files than we have have init ones.

Details: https://build.opensuse.org/package/show?package=openstack-quantum&project=home%3Aa_jaeger%3AFactoryFix

Could somebody review my changes and tell me whether this is the right way forward - or tell me what to change? Feel free to enhance as well ;)

Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org

Le mardi 23 avril 2013, à 20:35 +0200, Andreas Jaeger a écrit :

I've started adding systemd service files to quantum (taking what Fedora has) and noticed that their setup is different from ours, especially they have many more service files than we have have init ones.

Details: https://build.opensuse.org/package/show?package=openstack-quantum&project=home%3Aa_jaeger%3AFactoryFix

Could somebody review my changes and tell me whether this is the right way forward - or tell me what to change? Feel free to enhance as well ;)

Better to have the systemd files upstream than to have more and more distros shipping slightly different systemd files, imho. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-cloud+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-cloud+owner@opensuse.org