management.path_prefix is not respected by messaging-topology-operator

[ktzsolt]

Describe the bug

Declaring a user with the topology operator fails to declare with the error "Error 404 (Object Not Found): Not Found" when the management.path_prefix is set to some value (that is needed to expose the UI with reverse proxy, ingress etc) in the RabbitmqCluster spec at .spec.rabbitmq.additionalConfig

As a workaround using connection secret was offered in #287 but this needs a user/password credential that is already present in the cluster thus creating a "chicken or egg" problem when one wants to set up a cluster in fully declarative way using gitops (argocd)

To Reproduce

Steps to reproduce the behavior:
1, set management.path_prefix RabbitmqCluster spec at .spec.rabbitmq.additionalConfig to some value
2, create user as shown in example
3, check logs of messaging-topology-operator pod in rabbitmq-system

Expected behavior
As @blackjid suggested #287 (comment) The topology operator should look into the cluster reference resource to see if there is a path_prefix config, and use it to define the api calls. Maybe the Cluster resource could have a specific key in the spec to add a management path prefix, so it would be easier for the topology operator to find the information.

Version and environment information

• Messaging Topology Operator: 1.6.0
• RabbitMQ: 3.9.13
• RabbitMQ Cluster Operator: 1.12.1
• Kubernetes: 1.19.10
• Cloud provider or hardware configuration: onprem

[ChunyiLyu]

Hi @ktzsolt, when you create a RabbitmqCluster via Cluster Operator, a default user is created. You can get the default user credentials by following our doc Admin credentials for a RabbitmqCluster. You can use this admin user in the connectionSecret. Please let me know how it goes.

[ktzsolt]

Hi @ChunyiLyu, the default user secret would be good for connection secret only if it had inherited the management.path_prefix from the .spec.rabbitmq.additionalConfig field.

Creating a new secret and use it as the connection secret manually with cred values acquired with kubectl (https://www.rabbitmq.com/kubernetes/operator/using-operator.html#creds ) is not the gitops way, it needs manual/administrator work or running kubectl scripts in the cicd pipeline that I want to avoid.

[pattersongp]

I'm also experiencing this issue and agree with @ktzsolt that the suggested work around from @ChunyiLyu is not a viable solution. Using the operator shouldn't require you to get user credentials for a management user using kubectl, but should be a well known value when the User is created.

The topology operator could use the path_prefix, a solution mentioned in #287.

[blackjid]

As a workaround, I created my own image with from the topology operator with the path prefix hard coded to the value I needed. I havent had the time to try to make it generic, but I don't really know if I'll be able to do it..

…

On Tue, Jul 19, 2022, 11:06 AM Graham Patterson ***@***.***> wrote: I'm also experiencing this issue and agree with @ktzsolt <https://github.com/ktzsolt> that the suggested work around from @ChunyiLyu <https://github.com/ChunyiLyu> is not a viable solution. Using the operator shouldn't require you to get user credentials for a management user using kubectl, but should be a well known value when the User is created. The topology operator could use the path_prefix, a solution mentioned in #287 <#287>. — Reply to this email directly, view it on GitHub <#421 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABXVRJ4IHXZB43SBKZEEFDVU3AA7ANCNFSM53U6KI6Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[blackjid]

As I mentioned in previous comments, I see two potential implementations:

1. The topology operator could get the 'additional_config' property from the cluster resource, parse it, and find the path_prefix setting. I believe this is rather complex because we need to add logic to understand the additional config syntax.
2. The topology operator gets the path_prefix setting directly from the cluster resource. This is easier on the topology operator side, but the rabbit cluster operator and its crds require changes.

What do you think is the best approach? Perhaps there is another approach that I haven't considered.

[blackjid]

May be the easier and straight forward, candidate of mvp, is just add a path_prefix property to the rabbitmqClusterReference property on the topology crds.

[blackjid]

That PR implements the option 1. As this code has almost everything needed to get the path_prefix from the cluster object.

In the rabbitmq docs, says that additional_config can be ini or sysctl-like syntax...
I found a small go library to parse ini syntax. I guess it should support both, so I still have to work on the sysctl syntax.

The specs are working for the ini syntax. Still need some cleanup

[ChunyiLyu]

New release with the feature implemented by @blackjid just cut 😀 See: https://github.com/rabbitmq/messaging-topology-operator/releases/tag/v1.8.0

[ktzsolt]

Excellent, thank you all!