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.
- Architecture vs. Deployment
- Does deployment drive architecture - if so, how, why?
- 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
- See also item "Unified data model" from Mustang
- 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"
- Possibly captured in Guiding Principles?
- Relationship of architecture to M&O layer cake – and does it matter and why
- Should we document a layer cake diagram to help put RackHD into context?
- AuthN/AuthZ - RBAC - Security
- Guiding Principles?
- InBand vs. Out-of-band
- No OOB access to hardware
- Self-surgery
- Redfish Host Interface (HI)
- 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
- Guiding Principles?
- High availability - hardware, infrastructure, federated views
- Guiding Principles?
- Scaleability
- Guiding Principles?
- Upgradeability
- Guiding Principles?
- Inter-service communication
- Types of semantics required (message, RPC, etc.)
- Keeping secrets secret - data encryption - at rest & in-flight (See service management below)
- External vs. Internal APIs
- Guiding Principles?
- iRSD - Intel Rack Scale Design
- Hardware view vs. Infrastructure view - Federated View of both
- Project Voyager and how it relates to RackHD
- 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
- Swordfish being looked at more closely by Byron and Joe - more to come
- ------- Topics from Brian Parry ----
- Neighborhood manager
- Consul
- See Service managemenet below
- Service isolation / decomposition
- Workflow engine optimizations
- Usability improvements
- DHCP, PXE discovery – Lots of problems with this posted to Slack. Is there anything we can change to make this easier and more reliable?
- 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
- Presentation mapping of external facing APIs to data model (i.e. Redfish, RackHD API, future presentation APIs)
- 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
- Guiding Principles?
- Finer-grained services/service autonomy
- Guiding Principles?
- WFEaaS - (Workflow Engine As A Service)
- General purpose WFE
- OS install w/o RackHD discovery/catalog
- Exploitation of the Mustang "microservice" concept - building higher level hardware and infrastructure abstractions and functionality for RackHD
- 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)
- Service registry
- Service discovery
- Service health / load balancing
- Shared secrets
- FaaS (FPGA as a Service)
- FPGAs, SmartNICs, SoCs, GPUs, etc. – all examples of compute resources with certain characteristics
- Ability to orchestrate services onto these platforms
- Exposing such services to applications running in bare metal, container and virtual machine environments
- Redfish schema advances
- Composibility at all levels (server, networking, storage)
- Inclusive of virtual machines
- Composibility at all levels (server, networking, storage)