Conversation
design-proposals/co-without-capi.md
Outdated
|
|
||
| ### Rough Idea #1 | ||
|
|
||
| Implement a new agent, installed by `node_agent`. The agent will be responsible for: |
There was a problem hiding this comment.
We already have a node_agent in EMF today
There was a problem hiding this comment.
We have well defined process in the "edge node" teams for creating a single node cluster during the OS provisioning task as part of the cloud-init we use to customize the OS already, we may just want to focus on that to reduce implication that we would "upgrade" outside of the OS provisioning as well.
There was a problem hiding this comment.
@soniabha-intc what I meant was that the existing node-agent would install the new-cluster-agent (needs a better name).
| Implement a new agent, installed by `node_agent`. The agent will be responsible for: | ||
|
|
||
| - Installing K3s if it is not already installed | ||
| - Reporting cluster status and kubeconfig back to a central CO database |
There was a problem hiding this comment.
Perhaps the existing agent can be extended to detect presence of a Kubernetes cluster and to report that status back? It isn't clear how "app orch" communication gets established, if we can just insert an additional agent that then talks to the k8s API when present.
There was a problem hiding this comment.
I've updated idea #2 to be the "extend existing agent and existing databases" idea. I've also added the option to explore alternative 3rd party application management components, such as portainer.
Description
Starting a new ADR for the PoC of bringing up clusters without using CAPI.
Checklist: