Proposal for a single rucio chart with complete reproducible deployment of rucio

[volodymyrss]

Related to #228

We decided to split this PR into multiple smaller PRs. This PR will be just a reordering of charts.

Original comment below.

The principle agreed with @bari12 on Rucio-Dirac workshop, but not the technical details of the chart implementation.

In CTAO we made a chart of our Bulk Data Management System (BDMS) including as subcharts rucio charts, optional dependencies charts, and adding jobs for bootstrap and configure. See a talk.

This would require several changes ported to upstream rucio chart:

• put existing rucio-server, rucio-demons, etc charts to be subcharts of rucio chart.
• add bootstrap and configure jobs
• add certificate generation/issuer/manager subchart with options:
  • self-signed CA
  • admin-provider certificates
  • letsencrypt (where possible)
  • IAM x509 certificates (RCAuth-based)
• appropriate documentation

Please let me know if this set of changes makes sense!
The PR is started as a draft, just starting to move.

[maany]

Hey @volodymyrss, I am not able to access the link to the talk ( probably due to access restrictions). Could you please highlight what are the global variables you'd use that are accessible to all the sub-charts?

[volodymyrss]

Hey @volodymyrss, I am not able to access the link to the talk ( probably due to access restrictions).

Hi @maany , thanks for having a look on this draft proposal! Please see updated link, it should work.

Could you please highlight what are the global variables you'd use that are accessible to all the sub-charts?

For example, database configuration and rucio version.

Please have a look here of our integrated chart we use : https://gitlab.cta-observatory.org/cta-computing/dpps/bdms/bdms/-/tree/main/chart (this one with test values)

[lobis]

We will merge this branch into 228-unified-rucio-helm-charts in order to test.

[lobis]

@volodymyrss please can you rebase / fix conflicts and I will merge this branch into the 228-unified-rucio-helm-charts branch to start the big PR.

[volodymyrss]

Hi @lobis ! How is it going? We were wondering what are your plans on this PR and in general on the unified self-contained rucio chart? Should we try to contribute more?

edit: one thing which continues to be a bit inconvenient for us, is the way DB credentials are passed. It would be much better for us if there was an option to use an existing secret. In fact, this change is itself quite small, much smaller than the entire unified rucio chart proposal. Maybe we could contribute this one small change separately? What do you think?

[lobis]

Hi @lobis ! How is it going? We were wondering what are your plans on this PR and in general on the unified self-contained rucio chart? Should we try to contribute more?

edit: one thing which continues to be a bit inconvenient for us, is the way DB credentials are passed. It would be much better for us if there was an option to use an existing secret. In fact, this change is itself quite small, much smaller than the entire unified rucio chart proposal. Maybe we could contribute this one small change separately? What do you think?

We ended up creating a de-factor unified charts here: https://gitlab.cern.ch/rucio-it/rucio-k8s which are opinionated and tailored to our needs, but I still think a more unified chart should be available upstream.

I also agree the way db credentials are passed is a bit annoying and only works because people use flux.

I bypass this by using environment variables (rucio looks for db credentials on env variables too), so endedup not contributing this change, but it would be welcome.

I did a very similar change here: https://github.com/rucio/helm-charts/pull/245/files in case you find it useful.

[volodymyrss]

We ended up creating a de-factor unified charts here: https://gitlab.cern.ch/rucio-it/rucio-k8s which are opinionated and tailored to our needs,

Thanks, looks interesting! Essentially it's like we have own.

but I still think a more unified chart should be available upstream.

So do you plan to make one, or would you accept a contribution?

I bypass this by using environment variables (rucio looks for db credentials on env variables too), so endedup not contributing this change,

Oh nice, we'll use that too for now.

but it would be welcome.

Should we propose a PR? Or start with with an issue?

[volodymyrss]

We ended up creating a de-factor unified charts here: https://gitlab.cern.ch/rucio-it/rucio-k8s which are opinionated and tailored to our needs,

Thanks, looks interesting! Essentially it's like we have own.

Oh, it's private outside CERN, not all my colleagues can see it, is there are reason? Am I allowed to share the code?

[bari12]

I would still think this would be a good change upstream. The difficulty is that it breaks people who already deploy the current charts, so any change needs to be very well prepared, and very well documented, aiming at a specific major release.

[volodymyrss]

I would still think this would be a good change upstream. The difficulty is that it breaks people who already deploy the current charts, so any change needs to be very well prepared, and very well documented, aiming at a specific major release.

Do you mean the PR title change (single chart) or using secrets for DB credentials?

If we keep existing charts as they are (rucio-server, rucio-deamons), and only add another high-level chart including these as subcharts, maybe the change will not break too much?

It would break if we change directory locations in this repo, and people use github as the source for their deployments. But if they use https://rucio.github.io/helm-charts as the doc recommends, nothing will change for them.

For the DB credentials as kubernetes secret, we can make it so that it's not breaking (keeping current behavior as default).

[bari12]

I think most people will use the recommended way via releases on https://rucio.github.io/helm-charts - I think if they use it otherwise, it's their fault and we can't be blamed.

If we can do both changes in a backwards compatible way, even better :-)