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.

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?
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
Requirements that drive architecture – being careful to not turn this forum into a discussion of roadmap "features"
1. Possibly captured in Guiding Principles?
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?
AuthN/AuthZ - RBAC - Security
1. Guiding Principles?
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
Greenfield vs. Brownfield - how/if it affects architecture
Language bindings, languages
1. Guiding Principles?
High availability - hardware, infrastructure, federated views
1. Guiding Principles?
Scaleability
1. Guiding Principles?
Upgradeability
1. Guiding Principles?
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)
External vs. Internal APIs
1. Guiding Principles?
iRSD - Intel Rack Scale Design
Hardware view vs. Infrastructure view - Federated View of both
Project Voyager and how it relates to RackHD
1. Deep dive on architecture
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
------- Topics from Brian Parry ----
Neighborhood manager
Consul
1. See Service managemenet below
Service isolation / decomposition
Workflow engine optimizations
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
-----------------------------------------
------- Topics from Mustang ----
Advanced Services – Business Logic – Perspective on where these live in the architecture - North or South of RackHD
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
Interactive workflows in rackHD
Current workflow / taskgraph design - one active graph per node
-----------------------------------------
Footprint reduction
1. Guiding Principles?
Finer-grained services/service autonomy
1. Guiding Principles?
WFEaaS - (Workflow Engine As A Service)
1. General purpose WFE
2. OS install w/o RackHD discovery/catalog
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
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
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
Redfish schema advances
1. Composibility at all levels (server, networking, storage)
  1. Inclusive of virtual machines