"Peter O'Gorman" writes:
> Hi,
>
> I find the docs a little confusing with regards to how a packager
> should name a service or instance.
Sorry about that. We should get in some specific examples in this area.
> If we packager, for example, postfix, which provides smtp service,
> then the docs seem to suggest that the service name should be
> 'network/smtp', and then we should have an instance, named, for
> example 'postfix2210', possible including a stock symbol in the
> instance name. Am I right so far?
>
> My problem with the documentation comes when packaging services that
> are not already on the system, lets take mysql as an example. I have
> seen two manifests for mysql on the web, one used by blastwave, the
> other on the bigadmin site. One names the service network/mysql, the
> other says application/mysql. It is possible that our customers also
> use blastwave or some other packaging systems, we do not want to
> overwrite their entries in the database, but still we want to make
> sense. We're inclined to go with application/mysql and define an
> instance with or stock symbol in the name, our package will not
> overwrite any other package and it is possible that a number of mysql
> be installed on the system at any one time.
While that's an appealing approach, it won't do what you want due to
the following bug (which I just filed, so it may be a day or so before
you can see it on bugs.opensolaris.org).
6517953 multiple manifests delivering the same service/instance can
stomp all over each other
If someone else defines properties on the service, then you come along
with a new instance, the properties they defined on the service will be
deleted and their instances will break. :(
The biggest benefit to using the same service name as another software
distributor is if you expect software from another distributor to have
its dependencies satisfied by your service without knowing the name of
your service explicitly. That's probably not the case here, so...
I recommend going with something like application/TWW/mysql:default.
You'll have the benefit that if you're the only mysql service on the
system "svcadm enable mysql" will work great. And, you won't fall
afoul of 6517953.
For the alias' sake, I know this all sounds vaguely similar to the DNS
discussions we were having a little while ago. I've filed a new bug
to try to capture the issues. Again, just filed, so may take a day or
two to appear through opensolaris.
6517956 share config among instances when multiple vendors are
delivering the same service
liane
--
Liane Praza, Solaris Kernel Development
liane.praza at sun.com - http://blogs.sun.com/lianep
