Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make provider "official" and move it to github.com/argoproj #323

Closed
mkilchhofer opened this issue Aug 3, 2023 · 7 comments
Closed

Make provider "official" and move it to github.com/argoproj #323

mkilchhofer opened this issue Aug 3, 2023 · 7 comments

Comments

@mkilchhofer
Copy link
Collaborator

mkilchhofer commented Aug 3, 2023

Description

I (and we at @swisspost) really like this provider. I thought it would be super nice, if this one would become part of github.com/argoproj.

Would you be interested in the move/dontation of this great provider to the CNCF?

References

I already asked the Argoproj community inside CNCF Slack:

image

https://cloud-native.slack.com/archives/C020XM04CUW/p1691069958275329

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment
@mkilchhofer mkilchhofer added the enhancement New feature or request label Aug 3, 2023
@onematchfox onematchfox removed the enhancement New feature or request label Aug 4, 2023
@oboukili
Copy link
Collaborator

oboukili commented Aug 4, 2023

Hi @mkilchhofer, thanks for raising this. To be completely honest, I have no experience with donating OSS projects, therefore could you help us understand the following:

You mentioned it would be nice for the project to be integrated to Argoproj, can you elaborate on that? What's in it for the users (you), the maintainers of this provider (mostly @onematchfox these days), the administrators of this project, Argoproj?

Naively, I would think it would help with the following:

  • increase visibility (but there's no real alternative currently on the TF registry at least, and there's already quite good usage adoption metrics, as seen from the weekly download hits on the registry)
  • help find contributors (so far, we're not in a situation where we desperately looking for contributors, though more is always nice)
  • (probably) cover user compliance needs as Argoproj may want to add this project within their umbrella security compliance audit effort.

On the other hand, I see the risk of the maintainers/administrators losing their technical decision privileges.

There's also probably other things related to the licensing (MPLv2 is a requirement for the Terraform Registry), but I'm no lawyer.

Thanks for your insights.

@mkilchhofer
Copy link
Collaborator Author

mkilchhofer commented Aug 4, 2023

Hi @oboukili thanks for the fast answer.

You already pointed out the most important topics for why I ask for this. One additional point would be that there exists large organizations who prefers using providers which are eigher

  • HashiCorp "official"
  • from HashiCorp partners
  • from a large community

To speak for us at @swisspost there was some effort needed (in the team and org. unit) to use a TF provider which is hosted in a personal GitHub account.

On the other hand, I see the risk of the maintainers/administrators losing their technical decision privileges.

I think that isn't an issue here. I am a maintainer of the community driven helm repo for Argo helm charts (https://github.com/argoproj/argo-helm). We have our own admin privs over the repo and we appreciate every new contributor who wants to join us without asking the whole Argoproj team (we are on the CNCF slack all the time ^^).

Are you sure that only MPLv2 is allowed on the TF registry? I also follow the folks from the other GitOps eco system: fluxcd. Their provider is also licensed under github.com/fluxcd/terraform-provider-flux > LICENSE.

Ah and since @onematchfox is the most active maintainer these days, we could ask for his opinion about my idea?

@onematchfox
Copy link
Collaborator

Hi all,

Sorry for the slow(er) response... Summer holidays around these parts.

Overall, I would view "becoming part of argoproj" positively.

From a benefits standpoint, I'll add that:

  • I think that having closer ties and increased collaboration between this project and the main ArgoCD project will make life easier when changes are made to the ArgoCD API that may affect this project and/or when we need to submit changes to the ArgoCD API to further the goals of this project. That being said, being part of argoproj is not required for that to happen. I am acquainted with Mike and some of the other ArgoCD maintainers from the conference circuit, and I'm sure Mike will attest that I have actively tried to ensure closer ties between this project and ArgoCD (regardless of it being hosted in a personal account).
  • I also see a benefit in becoming part of a GitHub org as we will gain access to additional features (e.g. RBAC) that are not available to personal projects.

From a purely selfish/personal standpoint, my only real concern is whether this move would introduce additional overhead/requirements on me. I have been fortunate enough to have been able to donate a lot of time to this project in the first half of this year, but that time has sadly come to an end, and my availability going forward will be more limited. I can't, for example, commit to attending maintainer/contributor meetings in NA time zones on a regular basis, nor can I commit to monitoring Slack on a regular basis (I pop in and out as and when I can already). @mkilchhofer, given that you already maintain a project under the argoproj org, can you elaborate on what (if any) requirements there are to be a maintainer of such a project?

@mkilchhofer
Copy link
Collaborator Author

From a purely selfish/personal standpoint, my only real concern is whether this move would introduce additional overhead/requirements on me.

@mkilchhofer, given that you already maintain a project under the argoproj org, can you elaborate on what (if any) requirements there are to be a maintainer of such a project?

We don't have special requirements today, no.
Maybe also following some best-practices like having a:

@mkilchhofer
Copy link
Collaborator Author

mkilchhofer commented Aug 22, 2023

Oh maybe we should wait for the outcome about the re-licensing issue over there anyways:

And some further reading:

❓ We need to decide what do to with the Flux Terraform Provider, if CNCF doesn't add the Terraform Plugin SDK (MPL licensed) to the exceptions list we may be forced to stop offering an official Terraform Provider for Flux.

Source: @stefanprodan from the flux ecosystem -> cncf/foundation#617 (comment)

xref:

@mkilchhofer
Copy link
Collaborator Author

Nice, MPL-2.0 is now allowed by CNCF

On March 21, 2024, the Governing Board approved an exception to allow CNCF projects to use these dependencies under MPL-2.0, so long as they are used in unmodified form by linking to the dependency at build time.

Source: cncf/foundation#619 (comment)

Fyi @crenshaw-dev, @oboukili , @blakepettersson, @the-technat

@mkilchhofer
Copy link
Collaborator Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants