The "owner" argument for flux bootstrap gitlab (probably others too) does not make sense if URL includes groups/subgroups

[aleksandaratanasov]

The research institute I am working for has its own GitLab instance. My team has its own group and inside we have subgroups and what not. The repository I would like to use has the following URL (placeholders used due to privacy):

https://gitlab.example.com/institute/department/research-group/cloud-computing/administration/k8s-playground.git

As you can see the structure is nested:

• institute - the name of the institute
• department - the name of the department with focus on specific research area(s)
• research-group - the name of the team with focus on specific research area(s)
• cloud-computing - a sub-group of the my team's group I have created (I am the owner) to put everything related to cloud in it
• administration - a sub-group of the cloud-computing group for admin tasks (e.g. GitOps for managing the infrastructure)
• k8s-playground - the actual project that will be used by flux to sync the Kubernetes (in my case an Ubuntu 22.04 Server with microk8s; for setting up flux to work with microk8s see here )

I am quite new to GitOps and Kubernetes in general but I do believe that flux is rather confusing when it comes to anything that is not in the form of

https://gitlab.example.com/USER/REPOSITORY.git

The URL I have used at the beginning needs to be split into chunks that, given the name of the argument --owner, is anything but helpful. It took me half an hour trying to figure out what's going on:

flux bootstrap gitlab --hostname=https://gitlab.example.com --repository=k8s-playground --branch=main --path=./clusters/playground/ --token-auth --owner=institute/department/research-group/cloud-computing/administration

Notice the absence of trailing/leading /, which is an extra thing the user needs to consider not to mention the absence of .git suffix. I do realize that internally a lot of concatenation is going on and this is how I managed to figure out what to put where.

However in the end --owner=institute/department/research-group/cloud-computing/administration is not really the owner but rather a nested structure.

I would suggest to rename the owner to something like url-path or similar. Best would be remove that completely and just go with the full URL for the --repository argument since most people are familiar with that anyway. I would further suggest to remove the requirement to discard the .git suffix and remove --hostname:

flux bootstrap gitlab --repository=https://gitlab.example.com/institute/department/research-group/cloud-computing/administration/k8s-playground.git --branch=main --path=./clusters/playground/ --token-auth

In the end hostname can be extracted inside flux itself (plenty of regexes out there for doing that).

[simonfelding]

fully agree. it's really hard to figure out whats going on when the variable names are so blatantly incorrect and the output from the CLI is misleading too.

[nagyv]

I opened an issue in the GitLab issue tracker to get GitLab involved in improving the UX. I recommend to continue the discussion there, and finally create an RFC here.

[nagyv]

@simonfelding @aleksandaratanasov @razvanphp @elehcim We discussed at GitLab the flux bootstrap gitlab command arguments / UX, and came up with the following proposal. I'd like to ask for your feedback about it:

We recommend two GitLab specific flags:

• Gitlab hostname: --hostname
  • example: https://gitlab.example.com
  • could be provided in the GITLAB_HOST environment variable as well
• Project path (group(s) + project): --project-path
  • example: gitlab-org/gitlab
  • the last part is always the project

Together with implementing the above changes, we recommend to:

• drop the --personal flag
• change --private to –-visibility: public | internal | private
• when running from a gitlab project checkout directory, the --hostname and --project-path should default to those of the current repo

Together with the above we discussed that --path and -–project-path might be confusing. Still, we recommend going forward with both flags as there is a description with usage, and both names are typical across GitLab.

Please, let me know what you think!

[elehcim]

I think it's a great proposal. Thanks

[simonfelding]

It's good but it would be even greater if it supported using a pre-existing repo (all it should do is set up the token).

Sent from Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: Michele Mastropietro @.> Sent: Sunday, June 23, 2024 11:45:04 AM To: fluxcd/flux2 @.> Cc: simonfelding @.>; Mention @.> Subject: Re: [fluxcd/flux2] The "owner" argument for flux bootstrap gitlab (probably others too) does not make sense if URL includes groups/subgroups (Issue #3817)

I think it's a great proposal. Thanks

— Reply to this email directly, view it on GitHubhttps://github.com/fluxcd/flux2/issues/3817#issuecomment-2184922288, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKYOW73VGWDOVGPOMEUUNS3ZI2KKBAVCNFSM6AAAAAAXDVSY5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBUHEZDEMRYHA. You are receiving this because you were mentioned.Message ID: @.***>

[nagyv]

It's good but it would be even greater if it supported using a pre-existing repo (all it should do is set up the token).

@simonfelding Did you meant that when running from a gitlab project checkout directory, the --hostname and --project-path should default to those of the current repo? I like this idea! Thanks!

[simonfelding]

Wow that would be really cool and easy! I actually meant the use case where you have a project repo already and you want Flux to sync with it. The bootstrap command only works with setting up a new project (that doesn't already exist).

If it's not entirely clear, the only way to use it right now is to have it create a new project. I want to use it with a project that already has everything, it just needs the token set up by the bootstrap command. Does that make sense?

Sent from Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: Viktor Nagy @.> Sent: Monday, June 24, 2024 9:20:55 PM To: fluxcd/flux2 @.> Cc: simonfelding @.>; Mention @.> Subject: Re: [fluxcd/flux2] The "owner" argument for flux bootstrap gitlab (probably others too) does not make sense if URL includes groups/subgroups (Issue #3817)

It's good but it would be even greater if it supported using a pre-existing repo (all it should do is set up the token).

@simonfeldinghttps://github.com/simonfelding Did you meant that when running from a gitlab project checkout directory, the --hostname and --project-path should default to those of the current repo? I like this idea! Thanks!

— Reply to this email directly, view it on GitHubhttps://github.com/fluxcd/flux2/issues/3817#issuecomment-2187247363, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKYOW75BQGQKAK6P62A2UA3ZJBWRPAVCNFSM6AAAAAAXDVSY5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBXGI2DOMZWGM. You are receiving this because you were mentioned.Message ID: @.***>

[stefanprodan]

The bootstrap command only works with setting up a new project (that doesn't already exist).

Never heard this before from GitLab users, Flux bootstrap should detect if a repo exists and uses it. How did you come to this conclusion?

[makkes]

The bootstrap command only works with setting up a new project (that doesn't already exist).

This is wrong! The bootstrap gitlab command works just fine with a pre-existing project. I just did exactly that.

[simonfelding]

Oh! My bad then. I had an issue with it but I don't have the time to try to recreate the issue.

On Tue, Jun 25, 2024 at 3:20 PM Max Jonas Werner @.***> wrote:

The bootstrap command only works with setting up a new project (that doesn't already exist).

This is wrong! The bootstrap gitlab command works just fine with a pre-existing project. I just did exactly that.

— Reply to this email directly, view it on GitHub https://github.com/fluxcd/flux2/issues/3817#issuecomment-2188949131, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKYOW7ZWADCCBSROOXRF5JLZJFVDLAVCNFSM6AAAAAAXDVSY5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBYHE2DSMJTGE . You are receiving this because you were mentioned.Message ID: @.***>