Closed gilesknap closed 2 weeks ago
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.
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
?
For acd deploy
verification: Shall we get the repo from argo and use that to filter existing git refs?
As discussed: Lets defer attach/exec to kubectl
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?
As per our conversation today.
I approve:
docker compose
@marcelldls is this one completed now?
What PR(s) resolved this issue?
What PR(s) resolved this issue?
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:
ec-argocd
acd
This is where we are headed for managing IOCs and services:
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
global.enabled
is false. Also considerglobal.removed
)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 usenot
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-remove
d 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>
argocd
argocd login argocd.diamond.ac.uk --grpc-web --sso
acd ps <app>
(and also monitor)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>
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>
acd deploy <app>/<service> <version or tracking branch>
argocd app set bl45p/bl45p -p services.bl45p-ea-dcam-02.targetRevision=my_feature_branch