Inventory / Blueprint notes

gistfile1.txt

# Overview

- Both pretty proof-of-concept

## Flight Inventory

- Original goal was to see if we can draw useful diagrams of clusters built
  with Metalware
  - basically displaying networks and connections between things, showing
    containment between different types of things (node runs on a server,
    server is in a chassis, chassis and network switches are in racks etc.)
    - ended up with (sort of) a rack diagram showing everything in the cluster,
      with network connections between these, as well as logical views showing
      the cluster groups and genders
  - these could then potentially be used in many ways:
    - as marketing/sales tool - "here's the cluster we can build you"
    - integrated with Flight Center
      - click an object to start creating a case against it in Flight Center
      - could link back and forth between things in both apps
    - integrated with Ganglia/Nagios/other monitoring tools
      - could indicate on diagram if a node is having problems

- Conclusion was that this is cool but not sure how much it will help in terms
  of the business, moved on to Blueprint


## Flight Blueprint

- Sort of the reverse: can we interactively create a cluster in a diagram, and
  then have this launched somewhere for you
  - since the hard part of this is the interactive creation, focused on this
  - for now Blueprint just builds up a config file, this can then be used in
    Cloudware to launch this cluster (or at least that was the plan, not sure
    if Stu ever got this fully going)
  - long term plan was that Blueprint would build this file up behind the
    scenes and then allow you to launch it - possibly at this point you put in
    your credit card and start paying us a premium for running this cluster for
    you
  - we would also be able to display things like the status of your cloud nodes
    back in blueprint, allow you to add/remove/shut down nodes in your already
    running cluster
  - we also planned to display network connections in this diagram, this should
    be able to be done in a similar code to Inventory, but since this would be
    a bit of work to adapt and these don't give any useful info we held off on
    that for now


# Architecture

## Flight Inventory

- Import rake task, with all the logic in `lib/import.rb`
  - configured via env vars (`IP` and `ALCES_INSECURE_PASSWORD`, i.e. sqrt)
  - connects to a machine running Metalware accessible via SSH
  - blows away any current data in database - not designed to work with
    multiple clusters at once atm
  - imports both physical and logical assets from Metalware to local database

    - physical = assets configured with `metal asset` commands - servers,
      network switches etc.
      - these commands themselves were fairly POC, were an experiment in how we
        could capture this information (which Stu/Steve etc. have at build
        time) and use it in other products without needing to repeat it, while
        also not adding a load of extra work at build time

    - logical = nodes and groups configured with `metal configure` commands
      - these are traditionally what Metalware works with, with nodes
        configured in groups as well as individually configurable, and then
        built; the asset info was traditionally only needed to be input to the
        extent that this helps build the cluster, and is otherwise stored
        elsewhere (spreadsheets etc.)

    - see `erd.pdf` in Inventory repo to see relationships between all these

    - this is all using the old way things were structured in Metalware project
      - since then we have split this into both Underware and Metalware
        projects and added various things to both (Underware now has most
        (all?) of the stuff which we used to interact with Metalware for)
      - I believe using
        [2018.3.1](https://github.com/alces-software/metalware/tree/2018.3.1)
        should still work with Inventory though

- Imported data then available in simple Rails app
  - lots of models, mostly just contain `name` field and `data` JSON field,
    which is then just displayed in client, with potentially certain other bits
    unpacked if we need additional handling
  - all data just dumped into data tag to then be passed into Elm app via flag 
    - dumped in `app/controllers/pages_controller.rb` and
      `app/views/pages/root.html.erb`

- Elm app which handles displaying data, entry in `app/javascript/Main.elm`
  - this app is handled by Rails' Webpacker
  - tiny amount of JS to initialize app, handle port communication
    - `app/javascript/root.js`
    - we use ports to:
      - send positions of things into Elm app when page layout/viewport etc.
        change, so we can redraw SVG network diagrams between correct positions
      - use FLIP animations to animate transition between different layouts of
        visualizing cluster (these are still a bit ropy though, particularly
        the transition to genders layout as that was added last and displays
        multiple instances of each node)


## Flight Blueprint

- Rails API server (has been set up but doesn't do anything yet; long term plan
  was to save and restore Blueprint configs ('blueprints') from this, but we
  decided this wasn't important for just a proof-of-concept)
  - unlike Inventory, the API and client are entirely independent (in Inventory
    the client is on a server-rendered page of Rails app) - just worked out
    simpler in each case given other initial requirements
  - in order to save 'blueprints' we would need to be able to decode these back
    from the YAML (i.e. JSON) file back into the app state, which isn't done
    yet (currently just one way)

- Can communicate with flight-sso and sign in/up in similar way to our other
  Flight apps, though nothing special happens when we do this as yet
  - long term plan was that you'd be able to save and retrieve your
    'blueprints' associated with your Flight account, with option to sign up
    and then do this if you've not already got an account

- React frontend, with most of the page handled by Elm but header/footer
  standard Reactware components