Re: smf manifests in pkgsrc

[Filip Hajny <filip%joyent.com@localhost>]

> 15. 1. 2015 v 2:09, Paul B. Henson <henson%acm.org@localhost>:
> 
> No further thoughts on this? I'm currently working on updating the openntpd
> package to the latest version, and as part of that plan to add an smf
> manifest for it. I'd really like to make the FRMI for that
> svc:/network/ntp:pkgsrc-openntpd so it can cleanly replace the bundled
> operating system service. As I described below, it seems that could be
> easily accomplished within the existing infrastructure simply by shuffling
> around where the substitution variables are in the manifest, but I feel I am
> missing something given your warning that changing the FMRI's would be a
> complicated process requiring code rewrite.

For me, SMF instances are perfect for managing several sets of the same software (e.g. PHP/FPM pools of processes), where you can define a single set methods and then just add empty instance containers and rely on SMF variables to do the differentiation. I also understood the case where different versions of the same software were instances of a service (e.g. PostgreSQL), even though we have none such in pkgsrc. However, I’ve never liked the way Solaris used instances to bundle up possibly vastly different software. I got the basic idea, but the tooling didn’t feel right. There’s very little (if anything) that you can re-use in a SMF service if methods, properties etc. differ too much for each instance, and once you import a new instance into an existing service, it’s never the same thing anymore.

I agree it’s likely just a point of view, and maybe has to do with the fact that there never was any good documentation on SMF out there, which means that for anything non-trivial you end up reading XML DTDs. (And I’m speaking as a member of the Joyent team that has taked in a good share of experienced Sun engineers over time.)

I guess we never took the stance of someone trying to amend an existing OS software base with pkgsrc. SmartOS doesn’t ship with any of the traditional Solaris 3rd party software base (with the exception of sendmail maybe and even sendmail is network/sendmail-client with us), so it felt natural to draw a clear line between pkgsrc and the OS (we do not use /etc for pkgsrc files either).

I do understand your situation though. Maybe both modes co-existing in pkgsrc is not such a crazy idea? I do want to maintain status quo for SmartOS and not just because we have thousands of customers and users relying on this.  Maybe differentiate between SunOS flavors in smf.mk and provide a “Solaris integration style” mode there?


> 
> Thanks much.
> 
>> -----Original Message-----
>> From: Paul Henson
>> Sent: Sunday, January 11, 2015 8:37 PM
>> To: tech-pkg%NetBSD.org@localhost
>> Subject: Re: smf manifests in pkgsrc
>> 
>> On Sun, Jan 11, 2015 at 08:48:10AM +0000, Jonathan Perkin wrote:
>> 
>>> This would require a large rewrite of how SMF is handled and how
>>> variables are substituted, would break a lot of users who already
>>> depend on the current naming scheme, would require the addition of
>>> hard-coded FMRIs, and would remove the ability for users to have
>>> separate SMF prefixes (e.g. if they want to have multiple branches
>>> installed).
>> 
>> Hmm. You make this sound much more complicated than I anticipated :).
>> 
>> I will grant you transition headache if a user had a package with one
>> FMRI and an update resulted in another. OTOH, at Joyent you strongly
>> recommend against updating in favor of just reprovisioning with a new
>> dataset, so it wouldn't be an issue for your customers ;). Given such a
>> transition would only matter if FMRI's changed, I'm going to shelve that
>> problem for now to be revisited later if need be.
>> 
>> In the case of the current postfix manifest, it defines the FMRI as
>> '@SMF_PREFIX@/@SMF_NAME@', and '<create_default_instance
>> enabled="false" />',
>> which turns into svc:/pkgsrc/postfix:default on the system.
>> 
>> What if instead the FMRI was set to svc:/network/smtp, and rather than a
>> default instance, a specifically name instance was created:
>> 
>> <instance name='@SMF_PREFIX@-@SMF_NAME@' enabled='false'>
>> 
>> Unless I'm (quite possibly) missing something, that simple change would
>> result in exactly what I suggested "svc:/network/smtp:pkgsrc-postfix",
>> with zero changes to code. It would also continue to allow multiple
>> installations with separate SMF prefixes:
>> 
>> svc:/network/smtp:pkgsrc-postfix
>> svc:/network/smtp:pkgsrc2-postfix
>> svc:/network/smtp:pkgsrcblah-postfix
>> 
>> This would of course break on services which are restricted to a single
>> instance, but that's solved by simply not doing it this way for them :).
>> 
>> Yes, the FMRI svc:/network/smtp would be hardcoded. Why is that *bad*?
>> Arguably, that seems *good*. On all SMF using operating systems I know
>> of, the mail system out of the box uses svc:/network/smtp as the FMRI.
>> If you want to install postfix, why wouldn't you want everything else on
>> the system to recognize it as the mail system? There are many hardcoded
>> FMRI's in the existing postfix manifest, such as svc:/system/system-log,
>> svc:/milestone/name-services, etc; they are hardcoded because they *are*
>> the standard FMRI for the service.
>> 
>> For example, let's say I install postfix and syslog-ng out of pkgsrc,
>> with the intention of replacing the OS implementations. While syslog-ng
>> doesn't currently have an SMF manifest in pkgsrc, presumably if one were
>> added, the FMRI would be svc:/pkgsrc/syslog-ng:default.
>> 
>> So here I am, trying to run pkgsrc postfix with pkgsrc syslog-ng. You'd
>> think that would work out of the box, right? Nope, pkgsrc postfix would
>> refuse to start because its hardcoded dependency on
>> svc:/system/system-log isn't met. What then? I'd have to either use the
>> system syslog, or mangle either the pkgsrc postfix or syslog-ng
>> manifests to kludge it to work.
>> 
>> Whereas with my suggestion it would "just work" :). pkgsrc postfix would
>> recognize svc:/system/system-log:pkgsrc-syslog-ng as a valid provider of
>> the svc:/system/system-log service. And anything else that wanted a mail
>> system running would be happy with svc:/network/smtp:pkgsrc-postfix to
>> provide it...
>> 
>> Thanks...
> 
>