Service Catalogue Brain Storming Notes/Thoughts/Jottings

As I'll be away for the planning meeting on the 16th to discuss the service catalogue. I thought I'd jot down my thoughts here.

Feel free to add, etc

Neil's thoughts

I would prefer, and are more likely to keep up to date, service catalogue information if I could do it in the machine profile, either (or both) the actual machine's profile or some included header.

Now whether this means a new (or re-purposed) component, or just some hack so that it all lives in a giant comment (which itself may be parsed by something else) I suspect I don't mind. I guess it may depend on what we agree we need to capture about a service and whether doing that in LCFG speak is practical.

I'm sure the LCFG police won't like it, but just throwing it out there, the giant comment thing I was talking about could be we do something like in "infweb-server.h"

/*
  <begin service-cat>
  @Name: Inf Web
  @Description: The Informatics Web Server.
  @Details: Runs apache, zope, plone
  @Requires: cosign, x509
  @Host: LCFG:profile.node
  <end service-cat>
*/
That's very much off the top of my head, language/markup not at all thought through. I think we agree having some automated way to discover which machine is currently the "Informatics Web Server" would be good. That last "LCFG:profile.node" is suppose to represent some way of linking out to the value of that resource. Of course what happens if more than one profile includes infweb-server.h ? Perhaps wafer's profile could have some markup that says something like:
/* <begin service-cat>
    @I-am: Inf Web
   <end service-cat> */
Which ties @I-Am with @Name.

I'm not convinced this is the way to go, but if doing something similar in an LCFG component's resources is not practical, what other option is there? Though this assumes people agree that storing this info with the profile is the way forward.

Neil

gdutton adds...

I think Neil has said most of what I need to on this. With the best will in the world a catalogue will never get past 'incomplete' unless it's part of the "living" configuration. Even if compelled in some way to keep a set of static pages up-to-date, it'll still lag behind, and will duplicate effort in commissioning / moving services.

Thanks to our configuration management, our service headers necessarily define the services and their requirements, and the machine profiles describe the deployment of those services completely. So with this, we're only a few human-readable, machine-parseable fields away from "proper" documentation. anything else will be second-best, because it won't have the advantage of being tied to the live usage of the system.

As regards technical detail I'd lean towards a non-proprietary format (say, yaml) rather than a custom @tag format, but I am not worried about the format details so long as it's very simple, easy to edit and process, and entirely automatic. It hasn't explicitly mentioned so I assume we're talking about a system where each profile would be parsed first by the usual LCFG CPP mechanism, then by a new, simple script which would convert the catalogue entries into HTML for public display.

There are a few points I disagree with in Neil's initial proposal, though. Mainly these concern the idea of reinventing document inheritance, instances, requirements, etc. We have a mechanism for this already, namely CPP, and using it ties the actual topology of the system to the documented state. So I propose the only purpose of the new fields is to provide information we don't already have: the human-readable bits.

Rather than @Requires: cosign we have #include <dice/options/apacheconf-cosign.h> (are there any requirements which could not be captured by the headers?). Rather than @I-am: Inf Web we simply have #include <dice/options/infweb.h> For services such as www.inf, where there can only be one, then it's understandable that you might want to prevent tests from being displayed in the catalogue, but this should be done with a standard mechanism (.e.g. #define SERVICE_CATALOGUE_INHIBIT with appropriate header guards) in the machine profile. Another option would be not to inhibit its inclusion altogether, but just mark it as disabled (perhaps with a human-readable comment in the machine profile). That's not to say that, heaven forbid a server have manual initialisation steps, we shouldn't document them: we could add to the automatic requirements definition any of our own, e.g. @requires: manual keytab [link to documentation], which would be appended to all the other provides specified by the service headers.

The point is that adding new machines and services should be effortless, and their maintenance automatic. This is not a nagios-style scenario where the processing and configuration perhaps adds more complexity than it saves; I propose we utilise the mechanism we already rely on for the complicated bit: for the structure I imagine, the rest could (theoretically) be done by a few lines of awk...

Alison's bit

Following on from Ian's comments about the need to clarify what it is we're trying to achieve, perhaps the ITIL definition might help:

A service catalogue, as defined in Information Technology Infrastructure Library Service Design, is an exhaustive list of IT services that an organization provides or offers to its employees or customers. The catalogue is the only part of the Service Portfolio that is published to customers and is used to support the sale and/or delivery of IT services. Each service within the catalogue typically includes:

  • A description of the service
  • A categorization or service type
  • Any supporting or underpinning services
  • Timeframes or service level agreement for fulfilling the service
  • Who is entitled to request/view the service
  • Costs (if any)
  • How to request the service and how its delivery is fulfilled
  • Escalation points and key contacts
  • Hours of service availability

-- NeilBrown - 11 Oct 2013 -- GrahamDutton - 14 Oct 2013

Topic revision: r4 - 11 Dec 2013 - 09:12:10 - RogerBurroughes
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies