Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deploy beamline services to new namespace #7

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

DiamondJoseph
Copy link
Contributor

No description provided.

@DiamondJoseph
Copy link
Contributor Author

Does this need apps.yaml namespace to change?
Ingresses for rabbitmq and blueapi are currently created in this namespace, can we just move over or do we need to request new cloud team actions?
Switching the namespace should remove all of the old applications and redeploy in new namespace, but will it do all required cleanup?

Blocked because need SealedSecret to be generated in new namespace

@DiamondJoseph DiamondJoseph marked this pull request as ready for review August 16, 2024 14:39
@gilesknap
Copy link
Member

gilesknap commented Oct 10, 2024

@DiamondJoseph this is a fun PR. We do also need to change the apps.yaml namespace because bl45p namespace app will not have permission to deploy to bl45p-beamline.

For this reason we can't have argo do the whole transfer for us. When you are ready with the sealed secret. You can:

  • go to the argocd Web UI and delete the root app
  • change apps.yaml to namespace bl45p-beamline
  • merge the changes into main
  • kubectl apply -n bl45p-beamline app apps.yaml

Out newly namespaced beamline will burst into life. Probably.

@marcelldls
Copy link
Contributor

The epics helm charts that are being used are now consistent with the other test beamlines and everything appears to be running OK. Note: I haven't touched the actual ioc configs.

@gilesknap
Copy link
Member

@marcelldls I think we should take this opportunity to update the iocs values.yaml to point at the latest versions of the generic IOCs.

This is something that I think is not super slick to do right now - do we want to make some tooling to do this? can you let me know what you think?

@marcelldls
Copy link
Contributor

@gilesknap fair enough. The services, deployment repos for bl45p is not exactly consistent with any other beamline (experimental?) so I was trying to not do more than I need to, also PRs into the deployment repo is a bit of a pain.

As for tooling - I believe you have mentioned this as a possible feature for ec in the past. I reckon up reving ghcr.io/epics-containers/xxx in any of our values.yaml seems easy/useful?

@gilesknap
Copy link
Member

Yes up revving is what I'm suggesting. We don't have a strong need to update the IOCs right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants