Add Argo CD and Helm configuration for UOP and FAP Results Letter topology resources#330
Add Argo CD and Helm configuration for UOP and FAP Results Letter topology resources#330Bhaswati1148 wants to merge 25 commits into
Conversation
…-uop-specific-rabbitmq-definitions
…-uop-specific-rabbitmq-definitions
…-uop-specific-rabbitmq-definitions
…-uop-specific-rabbitmq-definitions
…-uop-specific-rabbitmq-definitions
…uster operator instance
| - values.yaml | ||
| # Kustomize config for ingress | ||
| - path: components/shared/message-broker/overlays/dev | ||
| repoURL: 'https://github.com/isisbusapps/gitops' |
| valueFiles: | ||
| - values.yaml | ||
| # Kustomize config for ingress | ||
| - path: components/shared/message-broker/overlays/dev |
There was a problem hiding this comment.
why are we adding Kustomize files , we already have helm chart
There was a problem hiding this comment.
The kustomize files are for including the HTTPRoute configuration of the rabbitmq cluster operator instance.
The HTTPRoute is configured in dev and can be accessed using https://devkubernetes.developers.facilities.rl.ac.uk/rmq/#/queues
There was a problem hiding this comment.
Instead of kustomize can you use helm ?
whats happening here is that half of the implementation is in helm and other half in kustomize
There was a problem hiding this comment.
Why is this file needed ?
There was a problem hiding this comment.
R&A team needs to access the management UI to check the queues and exchanges. I mentioned about this in one of our meetings with your team.
The HTTPRoute is required to expose the RabbitMQ Management UI through the Gateway API.
The HTTPRoute configuration is applied using kustomize, so it has been added to argocd configuration files. This has noting to do with rabbitmq cluster operator instance which is deployed using helm values.
@Sahil-STFC
There was a problem hiding this comment.
we have exposed Publisher using HTTPRoute and Helm , I think you can do the same thing for the exchange?
rabbitmq cluster operator and message broker both are deployed using helm.
There was a problem hiding this comment.
I could find this HTTPRoute and kustomize configuration for Publisher, is this the one you are referring above ?
I don't find helm being used to expose publisher, unless I am looking at wrong place.
@Sahil-STFC
There was a problem hiding this comment.
Sorry my bad, Publisher is kustomize and HTTPRoutes, I don't remember why its that way, we might have to change it in the future.
As of now I think if you'll put HTTPRoute in template folder it should work the same way kustomize does. Besides I don't see why we'd want to override the base file for different env, but if we need to we can just use values file .
HTTPRoutes is essentially just another K8 manifest file that can get its values from value-<env>.yaml.
Also while you are at it , you might want to remove the hardcoded values and make it more template driven ?
There was a problem hiding this comment.
Message broker is deployed via helm , why are we adding Kustomize files ?
There was a problem hiding this comment.
Kustomize files are for deploying HTTPRoute gateway configuration for accessing rabbitmq management UI
There was a problem hiding this comment.
you'll need 2 values files - 1 for dev and second one for prod
| @@ -0,0 +1,24 @@ | |||
| apiVersion: v2 | |||
| name: user-exchange-topology-chart | |||
There was a problem hiding this comment.
Chart name should be different
| vhost: {{ $.Values.uop_exchange_vhost}} | ||
| rabbitmqClusterReference: | ||
| name: {{ $.Values.rmq_cluster_name }} | ||
| deletionPolicy: retain |
There was a problem hiding this comment.
You might wanna check this. This ensures your queue never gets deleted, even if you have removed it from the values.yaml file.
If that's what's intended then that's fine
There was a problem hiding this comment.
My intention was to preserve the current behaviour. With the existing deployment of Bitnami helm charts, queues are imported via definitions.json, and removing them from the definitions does not automatically delete them from RabbitMQ. Using deletionPolicy: retain keeps that behaviour during the migration.
There was a problem hiding this comment.
Suggestion : If you have only 1 policy then its best to hard code the value, it will be easier for you to maintain
There was a problem hiding this comment.
I'd like to keep this as a Helm template for consistency with other topology objects
| @@ -0,0 +1,24 @@ | |||
| apiVersion: v2 | |||
| name: user-exchange-topology-chart | |||
…-uop-specific-rabbitmq-definitions
…nge to location argocd/uex/<environment>
| type: ReplacePrefixMatch | ||
| replacePrefixMatch: "" | ||
| backendRef: | ||
| name: rmq-message-broker |
| @@ -0,0 +1,17 @@ | |||
| httpRoute: | |||
| name: rmq-message-broker | |||
There was a problem hiding this comment.
Don't need this, this can be referenced from RMQ- message-broker values.yaml.
| @@ -0,0 +1,17 @@ | |||
| httpRoute: | |||
| name: rmq-message-broker | |||
| namespace: apps | |||
Closes https://github.com/isisbusapps/docker-orchestration/issues/857
This PR adds the Argo CD configuration and Helm chart changes required to deploy the UOP and FAP Results Letter RabbitMQ topology resources. The changes include Helm values, chart configuration, and templates for managing the topology resources.
This PR also adds
httpRoutefor the rabbitmq cluster operator instance.