RFC/RFP Service sets

[Andreas Ericsson]

On 05/18/2011 05:15 PM, nap wrote:
> On Wed, May 18, 2011 at 3:44 PM, Andreas Ericsson<ae at op5.se>  wrote:
> 
>> On 05/18/2011 02:02 PM, nap wrote:
>>   [...]
>>
>> You're sort of missing the point. Consider service sets as "service
>> templates with added services", but with a much clearer syntax and a
>> less muddied explanation than what you're proposing. To be honest, I'm
>> not sure exactly what it is you ARE proposing, and neither are any of
>> my colleagues. That's a sort of point in favour of my suggestion, I'd
>> say.
>>
> The idea was to have a "service set" but with current defined elements and a
> unique property for all host description properties (so use "use" :) ).
> 
>> Or just add them as a global variable (template-style) to the service
>> sets they want to use. Perhaps you missed that part of the example I
>> posted.
>>
>> Yes it seems so.
> 
>> [...]
>>
>> I disagree. It's a shame that "use" is already taken, but perhaps we
>> can let "profiles" be a duplicate of "service_sets" in the host object.
>> I suspect that's really the only remaining point of this discussion,
>> along with the fact that "use" can't be abused (teehee) to let hosts
>> link to service templates as well.
>>
>> But do understand that the nested-compound style service sets will, in
>> fact, *be* a special kind of service template with linked-in services
>> that hosts can reference.
>>
> Yes, the only point is how we describe host in fact. I prefer got a unique
> property for all hosts "things" (how we check it, who we notify, what
> service we add in).
> 
> 
>> [..]
>>
>> But then you're forbidding host templates from having the same name
>> as service templates, which is currently allowed. Not a very senible
>> limitation, imo.
>>
> I don't think so, the link is done with the host_name propery for services
> templates (if it's a template, it will look for host template, that's the
> main idea).
> 
> 
>> [..]
>>
>> That's totally trivial. The nested-compound version is a bit easier
>> since less stashed data needs to be used, but with a sensible 2-pass
>> config parser even that could be avoided.
>>
> I always see parsing more difficult that it is so :)
> 
>>
>> [..]
>>
>> Consider this (for non-nested version); Some admin on a site where
>> they only use MySQL creates a service set named "db-services" and
>> ships it upline so others can reuse it. In order to rename it
>> (with non-nested version, ofcourse), other people who wants to use
>> it have to rename it in not only the service_set "name" parameter
>> but also in each and every service shipped with the service set.
>>
>> And please don't tell me users are sensible. We know that's not
>> always true, and the few that aren't add grief and suffering to
>> those who are. Always have and always will.
>>
> True. So the name visibility can be a problem indeed.
> 
> [..]
>>
>> Why would you want to? PING should probably be on (very nearly) all hosts,
>> while all webserver type checks should only be on all hosts that have a
>> webserver. It's true that the basic HTTP check will have to be in the set
>> for both apache and MS(whateveritsnameis) servers, but that's still a huge
>> improvement over how it works today, and once admins start sharing their
>> service sets it won't really matter, because checks for one type of server
>> will all be contained in the service set.
>>
>   Just to get again a gain the most little configuration as possible ;)
> But maybe this time it is just too much.
> 
>>
>> [..]
>>
>> Except that templates now serve two different purposes, which has *already*
>> proven to be confusing to people.
>>
> I try to explain to my colleges how to configure a new host and it's always
> hard to explain that we've got templates for some properties and some other
> one for services (was groups, now it's sets with a level less for link it's
> true). They just don't understand the host/service point, and just want to
> ear about host and "it's a Windows, so I put the windows template and I'm
> done".
> 

Well, nothing prevents you from adding service sets to templates,
which I suspect is more or less identical to what you're doing
right now, except with a linkage chain I don't understand. If
you hook up service sets with templates and we remain with the
multiple templates thing (which I personally think is horrible,
but whatever), then you can use your "use" statement to assign
service sets as well.


>>
>> [..]
>>
>> Object configuration inheritance will still work more or less the
>> same as they do today, so contacts etc will be inherited from the
>> host for the services that don't have any. That and the ability to
>> optionally customize service set parameters from their inclusion
>> in the host makes me very certain I'm doing this right.
>>
>
> Yes, if we keep the implicit inheritance for this object, will do the trick
> :)
> 
> We can have the template thing with sets, but we will need to explain admins
> the "addition inheritance" so, but maybe it's the easier way and split
> description in two properties (your solution so)?
> 

As explained in the paragraph above, you can still use host templates
to assign a bunch of service sets for each host. The only problem is
that you're forced to set the service set parameters in the template
in that case. Then again, for companies that have a large bunch of
very similar servers, that's not necessarily a bad thing.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay