Epic Goal

• Enable users to install a host as day2 using agent based installer

Why is this important?

• Enable easy day2 installation without requiring additional knowledge from the user
• Unified experience for day1 and day2 installation for the agent based installer
• Unified experience for day1 and day2 installation for appliance workflow
• Eliminate the requirement of installing MCE that have high requirements (requires 4 cores and 16GB RAM for a multi-node cluster, and if the infrastructure operator is included then it will require storage as well)
• Eliminate the requirement of nodes having a BMC available to expand bare metal clusters (see docs).
• Simplify adding compute nodes based on the the UPI method or other method implemented in the field such as WKLD-433 or other automations that try to solve this problem

Scenarios

1. User installed day1 cluster with agent based install and want to add workers or replace failed nodes, currently alternative is to install MCE or, if connected, use SAAS.

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.

Dependencies (internal and external)

1. N/A

Previous Work (Optional):

ABI is using assisted installer + kube-api or any other client that communicate with the service, all the building blocks related to day2 installation exist in those components 

Assisted installer can create installed cluster and use it to perform day2 operations

A doc that explains how it's done with kube-api 

Parameters that are required from the user:

• Cluster name,Domain name - used to get the url that will be used to pull ignition
• Kubeconfig to day1 cluster 
• Openshift version
• Network configuration

Actions required from the user

• Post reboot the user will need to manually approve the node on the day1 cluster

Implementation suggestion:

To keep similar flow between day1 and day2 i suggest to run the service on each node that user is trying to add, it will create the cluster definition and start the installation, after first reboot it will pull the ignition from the day1 cluster

Open questions::

1. How should ABI detect an existing day1 cluster? Yes
2.  Using a provided kubeconfig file? Yes 
3. If so, should it be added to the config-image API (i.e. included in the ISO) - question to the agent team
4. Should we add a new command for day2 in agent-installer-client? E.g. question to the agent team 
5. So this command would import the existing day1 cluster and add the day2 node. It means that every day2 node should run an assisted-service first Yes, those instances are not depending on each other