Open alexlovelltroy opened 5 months ago
I think it'd be nice to have an input wrapper as well, so the students can write in a standard data format (I'm a yaml enjoyer), and run something against it to create their resources.
It'd also replicate how other microservice architectures do their resource ingestion (ie kubectl apply -f yourcoolpodshere.yaml
) .
as a fellow yaml enjoyer, I was thrilled to see that Apple has open sourced PKL which is even awesomer.
With the current API spec, adding nodes is a bit cumbersome for our students to navigate.
Our microservices optimize for adding/removing nodes on the fly through a continuous discovery system based on Redfish. The appearance of a new Redfish Endpoint in SMD triggers a discovery process that follows the Redfish tree of whatever device is connected. That applies as easily to a chilled water system as it does to a compute node. This flexibility is great when operating a large heterogeneous system, but confusing at the point where students need to bootstrap a small cluster and operate it for a short lifetime.
With so many concepts to teach, I don't think it's reasonable to include this extended and flexible system. Our students will want to be able to add nodes directly to the system and query the system in one place to understand the compute node makeup of the system.
I am proposing the creation of a thin node orchestration API that presents a Node-centric view of the world to students and converts their intent to smd/bss commands on the backend. This go microservice will support filtered CRUD operations on a Node schema that looks like this:
Through these three structures, I believe we can capture the needs of a node-centric student and convert those into upstream api calls.
What am I missing? Should we proceed?