clean-up helm area (rucio tar balls)

[dmwm]

clean-up helm area (rucio tar balls)

[ericvaandering]

Why? This is how helm publishes things. But I can try to figure out how Rucio does this by putting those things into a separate branch from master/main.

[vkuznet]

I don't know how helm handles things, but for cmsweb folder (under helm) we don't have tar balls. Moreover, you have multiple versions of tarballs which I think some of them are obsolete. I suggest that if you do require store tarballs put them under rucio folder(s) to clean up the area. I also see that there is (a possible) redundancy in directory structure, since you do have untarred areas along with tarballs, e.g.

rucio-consistency
rucio-consistency-0.1.0.tgz
rucio-cron-jobs
rucio-cron-jobs-0.1.0.tgz
rucio-cron-jobs-0.2.0.tgz
rucio-loadtest
rucio-statsd-exporter
rucio-statsd-exporter-0.1.0.tgz
rucio-statsd-exporter-1.0.0.tgz
rucio-statsd-exporter-1.0.1.tgz
rucio-traces
rucio-traces-0.1.0.tgz

and if I list one particular rucio area I see that it context represents a tar ball one.

[ericvaandering]

Right, that's all as it should be for helm to use the GH repository as a helm repo. It uses the tarballs in that case and, of course, each is a release.

[vkuznet]

that's fine then, but I still confused why help need both a tar ball and the actual area. I think one is enough to make another. And, versions can be part of git tag. Anyway, I trust you in this, but as we move to helm too (Muhammad's student is working and pushing stuff to heml/cmsweb area) I don't see tar balls over there. If you think that everything is fine I can close the ticket.

[ericvaandering]

You can use helm two different ways. You can use it by checking out the repository and keeping it up to date with git pull and so forth. Then you tell helm to use a directory as the source of the charts. The other way is more like an RPM server where you use just a URL and helm will check for updates to your package (or you can specify a release to use). For things under my control, I use a mix. I use the local GH repo as a I develop and the repo mode when things stabilize. For 3rd party stuff (e.g. prometheus) I, of course, use the repo mode. The tarballs are made by the helm package command. If they figure out a better way to do this with a separate branch, I’m happy to adapt. Hope that helps. Cheers, Eric

…

On Aug 2, 2021, at 8:39 AM, Valentin Kuznetsov ***@***.***> wrote: that's fine then, but I still confused why help need both a tar ball and the actual area. I think one is enough to make another. And, versions can be part of git tag. Anyway, I trust you in this, but as we move to helm too (Muhammad's student is working and pushing stuff to heml/cmsweb area) I don't see tar balls over there. If you think that everything is fine I can close the ticket. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dmwm_CMSKubernetes_issues_703-23issuecomment-2D891036065&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=EHaoB-POFWGrYFvPXoj1bQ&m=CM3vKEJESNdvvumrfH1pgkHvB3GQ_SZ9223TITZRDR8&s=6HtlpSw76X3Bb81qSZvSANM0_sVRUA4QL-qhR9Sma-8&e=>, or unsubscribe <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAMYJLTM7RZ6FZS65TI4C3LT22NZ3ANCNFSM5BMUSD7Q&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=EHaoB-POFWGrYFvPXoj1bQ&m=CM3vKEJESNdvvumrfH1pgkHvB3GQ_SZ9223TITZRDR8&s=-RBDprVdDyH9t_yMPF3Cai7hobh_8C5K0O404wekVrg&e=>.

[vkuznet]

ok, then I'll close the ticket.

[ericvaandering]

Installing this GH action looks like the way to go: https://github.com/helm/chart-releaser-action Then the tarballs are relegated to a branch of the repository called gh-pages and appear on http://dmwm.github.io/CMSKubernetes

Any objections to my installing it?

[vkuznet]

@ericvaandering feel free to do it. I'm in favor of GH Actions.

[muhammadimranfarooqi]

Hi,

Or another option we can think about official repo for helm https://artifacthub.io/?

[ericvaandering]

Since our helm charts are just really for internal use, I'd rather not "pollute" such a namespace with our stuff.