Feature Overview (aka. Goal Summary)  

An elevator pitch (value statement) that describes the Feature in a clear, concise way.  Complete during New status.

OCPSTRAT-620 is about relocating Single Node OpenShift clusters and [TELCOSTRAT-38] is about deploying any kind of cluster as an appliance. I would like to take these two features a step further to support Industrial Edge use cases, where we would like to prepare multi-node clusters in a factory and configure them only when they are deployed in the field.

Goals (aka. expected user outcomes)

The observable functionality that the user now has as a result of receiving this feature. Complete during New status.

Unconfigured multi-node clusters with late binding and configuration offer the following benefits:

1. The appliance image can be generic and applied on many servers in a supply chain
2. An unconfigured cluster has no value to 3rd parties because it has no sensitive data
3. A reconfigurable cluster can be rerouted anywhere for better supply chain flexibility
4. The initialization and deployment of the hardware requires no OpenShift knowledge

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order to be considered complete.  Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.  Initial completion during Refinement status.

1. The unconfigured appliance based cluster has a generic node and API naming
2. The unconfigured cluster runs a reconfiguration service at boot
3. The reconfiguration service supports ISO and network configuration storage

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

 One of the premises of edge deployment is that the persons doing the installation of the device in the field will have no IT knowledge and should only do logistic: put the device in its location and plug power and network. From there, the onboarding and configuration should be automated.

In the context of Industrial Edge, we have industrial systems that are pre-assembled in factories by people who have knowledge of the industrial process, but not of the IT part of the Software Defined Factory components.

In the more complex systems, we will have a multi-node OpenShift cluster that provides onboarding and management tools (FDO, AAP, ACM, ACS, etc...) and IT/OT Gateway services (OPC-UA server, MQTT Broker, Prometheus aggregator, Kafka Streams...) depending on the workloads deployed in the system. A multi-node layout allows for high-availability and more resources for the workloads.

In the factory, the people initializing the OpenShift cluster will not have the OpenShift knowledge and should be able to simply connect the server to power and network to automatically install a baseline OpenShift appliance as defined by the IT Architects. The appliance paradigm allows deploying multi-node clusters.

In the context of a industrial systems factory, we think that deploying an unconfigured cluster allows for better flexibility and security. The system can be prepared and stay in a politically challenging country customs for quite some time. An unconfigured system will not have sensitive data that the country intelligence service may try to extract. An unconfigured system can stay disconnected for a long time with no problem.

Once the unconfigured appliance-based cluster is installed in its final location, it will go through an onboarding process to verify its integrity and its configuration will then be applied via the relocation technique. The hostnames, nodes and API IP addresses, certificates, etc... will be updated to match the role of the system.

Reconfigurable multi-node can be rerouted to another destination if needed. The configuration can be assigned from a central management system. This allows more flexibility in the supply chain to address any logistic issue.

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  Initial completion during Refinement status.

Interoperability Considerations

Which other projects and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.