Switch to Argo CD

[gilesknap]

Intro

This is a complete departure from the current tool so I'm thinking that we fork this and come up with a new name. We will want to support the old 'ec' for a short time while the transition of existing beamlines is yet to happen. Argo CD will not be deployed to beamline clusters until the cloud team has the time to do so.

Suggestions:

• repo is ec-argocd
• entrypoint is acd
• @coretl @GDYendell I know you like discussing names for things. How do the above sit with you?

This is where we are headed for managing IOCs and services:

• local deployments will be handled by compose with no custom tool required
• cluster deployments will be handled by Argo CD and this new tool will simplify interactions and provide a similar interface to the original 'ec' that worked via helm and kubectl

Specification

This tool will have as its backend argocd CLI only. It will also require no configuration via environment.sh instead you will login in to an argo cd instance and interact with that.

Goals are to support

• ps (-a will show apps whose global.enabled is false. Also consider global.removed)
• monitor
• restart
• start
• stop
• deploy (set the version we are tracking - not create a new app which will be done via a PR into blxxi-apps)
• attach
• exec
• logs
• log-history

Its a little annoying that we don't get instances which used to list all the tags that were relevant to a given service - but I guess that is better handled by looking at the repo itself, thus giving real meaning to the tags.

Command Implementation

All examples are for bl45p for app and bl45p-ea-dcam-02 for service.

NOTE: where we use enabled we could instead use not removed this would remove the child app but keep its entry in the services list of the root app so that it can be un-removed later. This is preferable for feedback in the argocd UI but looses argo rollback history. Given that we are using this tool to do the rollback that is probably not an issue.

• acd login <instance>
  • instance defaults to argocd
  • argocd login argocd.diamond.ac.uk --grpc-web --sso
  • uses sso so will usually succeed without any user intervention
• acd ps <app> (and also monitor)
  • app defaults to the beamline blxxi name for beamline clusters
  • argocd app list --app-namespace bl45p -o yaml
• acd stop <app>/<service>
  • argocd app set bl45p/bl45p -p services.bl45p-ea-dcam-02.enabled=false
• acd start <app>/<service>
  • argocd app set bl45p/bl45p -p services.bl45p-ea-dcam-02.enabled=true
• acd restart <app>/<service>
  • NOTE: this is setting the enabled on the child app so it will stop it but then the root app will re-sync and restart it
  • argocd app set bl45p/bl45p-ea-dcam-02 -p global.enabled=false
• acd logs <app>/<service>
  • argocd app logs bl45p/bl45p-ea-dcam-02
• acd log-history <app>/<service>
  • just starts a browser as before - TODO we need some global config somewhere to say what the URL is for centralised logging
• acd deploy <app>/<service> <version or tracking branch>
  • NOTE: One downside of the argocd CLI only approach is we cannot verify that the branch or tag really exists. You will just get a spinning Status on the service's argocd UI if you pick a non-existent tag.
  • argocd app set bl45p/bl45p -p services.bl45p-ea-dcam-02.targetRevision=my_feature_branch
• exec
• attach
  • exec and attach break the 'argocd CLI only` rule so maybe we should drop these and defer to using kubectl directly. Its not like it is hard to work out the pod name now we are using statefulsets.

[gilesknap]

Also note that all of the above interactions are near instantaneous, because they talk direct to ArgoCD, so no refreshing or waiting for polling required.

[marcelldls]

If we dont do configuration via environment.sh - how do you propose to set/switch the context that is the beamline? Something like acd set-context bl01t and store in .config? This could have auto-complete or an acd list-context command?

[marcelldls]

For acd deploy verification: Shall we get the repo from argo and use that to filter existing git refs?

[marcelldls]

As discussed: Lets defer attach/exec to kubectl

[marcelldls]

How shall we proceed with ec? If we keep only the kubectl and helm commands, it becomes less complex. There is surely some use for those not using argo?

[gilesknap]

As per our conversation today.

I approve:

• dropping the local backend in favour of docker compose
• adding a argocd backend as per the above
• keeping the helm/kubectl backend for those users that don't want ArgoCD
  • some minor changes required:
    • to support the beamline_values.yaml
    • to just use --update-dependency now we don't have nested dependencies.
    • anything else that has changed in the beamline repo or ioc-instance chart?

[gilesknap]

@marcelldls is this one completed now?

[GDYendell]

What PR(s) resolved this issue?

[marcelldls]

What PR(s) resolved this issue?

#160