Adjusting the mindset

• Increased focus on maintenance
• Lets decouple our users' duties:
  • BAU maintenance
  • Development
  • Business reporting
  • System configuration
  • (Consumer: Self-service portal)

A new mental model and structure

With support for "domains"

The hierarchy

Environment

Asset

Provider

Host

Uses

Influences

Facilitates a bottom up view for assets and hosts.

Informational

"Semantic"

"Physical"

Assets

• Service catalogue instances
• Composite service catalogue instances
• MintDeploy Enterprise Deployments
• "Hollow" templates for existing assets
  • e.g. to manage existing stuff, add a template for it which only has the custom actions you want to add

The tab hierarchy

Home, focused on BAU

Environment

Provider

Home, empty state

🏃

Environments and friends

"Assets"

• Asset/SC instance
  • Composable
• Enterprise deployment
  • Composable
    • Requires increased flexibility
• Existing asset
• (Actor)

Multiselect for comparisons and actions.

Asset card

Assets, bottom up

Providers and friends

Home >> Provider: Prod >> awsosi1

OSQuery for host info?

Env Development

Making definition updates is done offline

Download template: downloads a tarball containing a working directory:
 {{template_name}}/
       metadata.yml
       properties.yml
       actions.yml
       composition.yml
       transforms.yml
       compliance.yml
       testing.yml
       domainCfg.yml
       definition/ -- chef stuff
Equivalent of running `mintpress init`.

Adding a "shortname" is tempting...

Workflow

• Pre-commit/pre-receive hooks
• Linting
• Testing

Existing assets

• Add a shell of a template that provides available actions
• Treat like an asset
  • Might be worth visually indicating the distinction

MintDeploy

• More detail needed
• Implementation technology doesn't actually matter, i.e. doesn't need to use Chef
• Treat like an asset
  • Might be worth visually indicating the distinction

Custom transforms

• An exception case, or as part of a dev flow
• Built for power users, not so much the BAU team
• Facilitate "export" to allow integrating into the template
• Facilitate multiple types of transform
  • Adding an initial Javascript implementation is simple and powerful
  • Other options include:
    • XSLT like
    • JQ like
    • Anything else that anyone wants :-p but maybe phased releases of types (plugin-like)

Adding assets

• No need to specify a runtime
• Simple self-service role: 95% different and slimmed down self-service UI for these users

Random screens

Implementation plan

• Start UI build as interactive prototype
  • Less polished
  • Use PostgREST as a backend for hierarchical data model
    • Anticipate replacing if necessary, but just use verbatim until that's required
    • Using Row Level Security is a very tempting way to implement security...
  • Target "Home" and SC functionality
  • Anticipate becoming real codebase if well received
• Start BE updates in parallel

Console: SPA

PostgREST

Postgres

"Interactive Prototype"

Console: SPA

PostgREST

Postgres

"Interactive Prototype"

Logstash/ElasticSearch/Kibana

Console: SPA

PostgREST

Postgres

"Interactive Prototype"

Logstash/ElasticSearch/Kibana

Git/Catalogue development

Console: SPA

PostgREST-compatible backend

"Interactive Prototype"

Logstash/ElasticSearch/Kibana

Git/Catalogue development

Config Repo functionality

Console

PostgREST-compatible backend

Logstash/ElasticSearch/Kibana

Git/Catalogue development

Config Repo functionality

The Engine

Executor

Provisioning

Console

PostgREST-compatible backend

Logstash/ElasticSearch/Kibana

Git/Catalogue development

Config Repo functionality

The Engine

Runtime, with the GUI disabled

Console

PostgREST-compatible backend

Logstash/ElasticSearch/Kibana

Git/Catalogue development

Config Repo functionality

The Engine

Executor

Provisioning