Discussion Topics - Ungroomed

Potential Topics for Discussion - Not a complete list & in no particular order - WIP

We need to triage/groom/scrub all of these to come up with a more congruent list of topics that makes sense for where we are in our discussions. For right now, this is just a brainstorm/brain dump of topics and a place to hold them until we're ready. 

  1. Architecture vs. Deployment
    1. Does deployment drive architecture - if so, how, why?
    2. Should we be documenting the different deployments that we are aware of, and then asking the community if they have others they are interested in? 
  2. Data models and how/if they relate to architecture
    1. See also item "Unified data model" from Mustang
    2. Refer to Server ISG/CTO Interlock minutes from 2/2/17
  3. Requirements that drive architecture – being careful to not turn this forum into a discussion of roadmap "features"
    1. Possibly captured in Guiding Principles?
  4. Relationship of architecture to M&O layer cake – and does it matter and why
    1. Should we document a layer cake diagram to help put RackHD into context?
  5. AuthN/AuthZ - RBAC - Security
    1. Guiding Principles?
  6. InBand vs. Out-of-band
    1. No OOB access to hardware
    2. Self-surgery
    3. Redfish Host Interface (HI)
      1. Host access to hardware management controller (i.e. iDRAC, BMC) to provide common interface for both external (OOB) and internal (in-band) management clients
  7. Greenfield vs. Brownfield - how/if it affects architecture
  8. Language bindings, languages 
    1. Guiding Principles?
  9. High availability - hardware, infrastructure, federated views
    1. Guiding Principles?
  10. Scaleability
    1. Guiding Principles?
  11. Upgradeability
    1. Guiding Principles?
  12. Inter-service communication
    1. Types of semantics required (message, RPC, etc.)
    2. Keeping secrets secret - data encryption - at rest & in-flight (See service management below)
  13. External vs. Internal APIs
    1. Guiding Principles?
  14. iRSD - Intel Rack Scale Design 
  15. Hardware view vs. Infrastructure view - Federated View of both
  16. Project Voyager and how it relates to RackHD
    1. Deep dive on architecture
  17. Notion of "providers" that can add a set of resources to a Redfish service (i.e. RackHD provides service root, a Swordfish provider adds storage resources to root) and how this might affect architecture
    1. Swordfish being looked at more closely by Byron and Joe - more to come
  18. ------- Topics from Brian Parry ----
  19. Neighborhood manager
  20. Consul
    1. See Service managemenet below
  21. Service isolation / decomposition
  22. Workflow engine optimizations
  23. Usability improvements
    1. DHCP, PXE discovery – Lots of problems with this posted to Slack.  Is there anything we can change to make this easier and more reliable?
    2. More human friendly interface for graphs / task definitions
  24. -----------------------------------------
  25. ------- Topics from Mustang ----
  26. Advanced Services – Business Logic – Perspective on where these live in the architecture - North or South of RackHD
  27. Unified data model in rackHD
    1. Presentation mapping of external facing APIs to data model (i.e. Redfish, RackHD API, future presentation APIs)
    2. Decoupling of discovery/cataloging technique with WFE requirements for data
  28. Interactive workflows in rackHD
  29. Current workflow / taskgraph design - one active graph per node
  30. -----------------------------------------
  31. Footprint reduction
    1. Guiding Principles?
  32. Finer-grained services/service autonomy
    1. Guiding Principles?
  33. WFEaaS - (Workflow Engine As A Service)
    1. General purpose WFE
    2. OS install w/o RackHD discovery/catalog
  34. Exploitation of the Mustang "microservice" concept - building higher level hardware and infrastructure abstractions and functionality for RackHD
    1. I.e .Building higher level abstractions to serve up different persona, without propogating different decoupled technologies (a.k.a. "OnServe" - James King
  35. Service Management (Hi priority – based on Consul vs. Eureka discussion and what we learn from spike stories created in Team Mustang)
    1. Service registry
    2. Service discovery
    3. Service health / load balancing
    4. Shared secrets
  36. FaaS (FPGA as a Service)
    1. FPGAs, SmartNICs, SoCs, GPUs, etc. – all examples of compute resources with certain characteristics
      1. http://files.opencompute.org/oc/public.php?service=files&t=5803e581b55e90e51669410559b91169&download&path=//SmartNIC%20OCP%202016.pdf
      2. https://www.nextplatform.com/2016/12/02/takes-build-true-fpga-service/
    2. Ability to orchestrate services onto these platforms
    3. Exposing such services to applications running in bare metal, container and virtual machine environments
  37. Redfish schema advances
    1. Composibility at all levels (server, networking, storage)
      1. Inclusive of virtual machines