Page History

Description

The service catalog binds together the K8s service files for deploying the service, service descriptions for project admins to configure a service with options via a CLI/GUI, and provides interfaces to configure service repositories and to manage and maintain the per-cluster service catalog that is cached in etcd.

Design Session Notes - 16/02/16:

Resolved:

• Dev side:   Separate docker image builds from catalog/configure/deploy files
  • proposed repo names:  ndslabs/images.git, ndslabs/ccd.git
• CCD:  
  • Catalog file - Declarative
    • static service description 
    • composite dependencies for composites
    • Config options (simple)
  • Configure - 
    • Assign options and provision resources
  • Deploy - 
    • generate K8s and run

...

• Workflow and format for CCD spec files
• Detailed defn and workflow
  
  • Catalog generation from catalogs in URL
    • Simple aggregation of static data - yes?
  • Configure time - options vs resources
    • Options
      • validatable
      • May influence subordinates
        • Other options - ex. (log(yes|no)->yes)->logfile(input(name))
        • Resources - ex.  (logvol(named)->yes)->vols.map(logvol(lookup(name)))
    • Resources
      • Need lookup in system
        • volumes, etc.
        • need consistent naming/identification scheme
    • Generating K8s
      • Unknown, but could leverage other declarative->declarative transformation tools

...

Design Notes - 16/02/15:

• Goals

1. Simplicity - Easy to understand and use for cluster admins, project admins, and tool/service developers
   1. Glean as much optional information as possible from build/images/K8s manifests
      1. Volumes, ports, scalability(replication controllers), etc. - 
   2. Sensible and simple defaults, with expert override support for Project deployments
2. Automation - Set the catalog references and run - updates/changes appear without intervention
3. Extensible  - Multiple catalogs - nds, other-public and private catalogs per-cluster,  support experimental/dev ad-hoc use in shared and person dev environments
4. Independent - Not tightly bound to NDS or docker.io, does not require administrative intervention for developers
5. Trusted - support signing/verification as an option for service repos and individual services
   
   

...