Compliance: Community Extension Projects

[jbw976]

The Crossplane governance has recently been updated to define the lifecycle and policies for Community Extension Projects. All community extension projects are expected to comply with these new policies.

An example of a completed compliance self-assessment can be seen in crossplane-contrib/provider-nop#21 (comment).

This discussion can be used for general questions about the policies and process, so that all project maintainers can stay in the loop and questions can be answered efficiently across the entire ecosystem. Feel free to post here with any questions. If preferred, you can also reach out directly to the steering committee. We're here to help make the entire community successful. Thank you!

[yordis]

Is there any example repo I could follow to understand an ideal state?

Trying to figure out what needs to be done in crossplane-upjet-digitalocean registry, maybe you have a migration PR or something that could help.

[jbw976]

Great question @yordis! good to hear from you 😎 - I expect the two big things to do for projects that are in good health in terms of activity, regular releases, active maintainers, etc. will be:

• publishing to gchr.io
• ensuring the maintainer list is up to date in both the repo's OWNERS.md file and the GitHub permissions on the repo

Of course, if a repo isn't in good health then there will be more work for the maintainers to express what the gaps are and how they will remedy them.

Here's a couple PRs and github actions workflows that will be relevant to demonstrate how to start publishing to ghcr.io, since that will be a very common step to take:

• (non family providers, the common case): provider-kubernetes/publish-provider-package.yaml, provider-spotify/publish-provider-package.yaml
• (for family providers, which is uncommon): Integrate reusable workflows for provider package publishing crossplane-contrib/provider-upjet-gcp#734
• (for functions): Update Go version and enable pushing to ghcr.io in CI crossplane-contrib/function-go-templating#171

There is also an extension release guide in the Crossplane docs:

• https://docs.crossplane.io/latest/guides/extensions-release-process/

Also, note that if a project is being updated that hasn't been touched in awhile, it may be affected by GitHub sunsetting older versions of its cache service. You can read about how to solve that issue in:

• Crossplane builds failing due to GitHub Actions Cache sunset crossplane#6399

[yordis]

ensuring the maintainer list is up to date in both the repo's OWNERS.md file and the GitHub permissions on the repo

Currently https://github.com/crossplane-contrib/provider-upjet-digitalocean/blob/d5af3f33b8f43c5e737493600336118f5263d1a1/OWNERS.md?plain=1#L13-L15

@ulucinar and @sergenyalcin are part of the code owner, but I have never done it and do not know the process for removing or adding.
Both are from Upbound, which is good. Ideally, somebody outside me would have some responsibility, but in the worst case, I can not react fast enough.

[jbw976]

You are the creator and maintainer of provider-upjet-digitalocean my friend 🙌 - to accurately reflect that reality, I would say you should update the OWNERS.md file to only include yourself.

[tampakrap]

I noticed that some providers started using reusable workflows from the provider-workflows repo (example). Should other crossplane-contrib providers start using this repo for building, testing and/or publishing images, or is the warning in the readme still valid? If it is actually ready for use, should the provider-upjet-template repo also use it?

[jbw976]

Good eye @tampakrap - I think those reusable workflows that publish artifacts for providers can start being used by other projects in crossplane-contrib. I'll check with others on the team if the warning in the readme is still valid.

I'm not entirely sure if the upjet template should be updated to use those workflows actually - they may be a bit too specific right now, without a bit more work, for publishing the way crossplane-contrib repos are expected to. Other ecosystem projects, that do not donate their provider to crossplane-contrib also use this template, so there may be more work to do to make it more general if it should be included in the template. I'll check on that too.

[jeanduplessis]

@tampakrap @jbw976 We added these workflows to that repo since we maintain a couple of projects in crossplane-contrib and wanted not to duplicate everything. As Jared mentioned, the publishing workflows are good to use. We've tested them, and they are actively being used in provider-upjet-{aws,gcp,azure,azuread,kubernetes,helm} today. One thing to note is that they do MORE than the minimum publishing to ghrc.io since they dual publish to the Upbound Marketplace as well.

We have not tested/adopted the other workflows so the general warning is still valid. We intend to maintain this repo, so relying on the publishing workflow is safe for projects in crossplane-contrib.

I think I generally agree with Jared's sentiment that using these in the provider template might be a bit too coupled with expecting the provider to be in crossplane-contrib.

[jan-di]

Hi, we (crossplane-contrib/provider-openstack) have also migrated to using the provider-workflows. We have no XPKG_UPBOUND_TOKENand thus would like to disable pushing to Upbound registry. See crossplane-contrib/provider-workflows#11

[yordis]

@jbw976 @jeanduplessis should .github/workflows/publish-provider-package.yaml be added to https://github.com/crossplane/upjet-provider-template/tree/main/.github/workflows

[bobh66]

Personal opinion - since provider-template is in crossplane-contrib then I think it's reasonable for it to at least make the workflows available, maybe with a comment that explains that they should be commented-out if the user does not plan to host the provider in crossplane-contrib, or commented-out by default but at least still easy to implement should the user want to.

[jeanduplessis]

This actually points out a slight descendency between provider-template and https://github.com/crossplane/upjet-provider-template with the latter being in the crossplane org. @jbw976 is the upjet provider template in the wrong place?

[tampakrap]

what is the difference between https://github.com/crossplane/provider-template and https://github.com/crossplane/upjet-provider-template ?

[jbw976]

provider-template is the starting template for classic providers that do not use upjet or code generation, their APIs and controllers are mostly done manually and they typically directly use golang SDKs for the service/env they are targeting.

upjet-provider-template is the starting template for providers that will have their code generated by the upjet framework and use an underlying terraform provider.

[jbw976]

@jeanduplessis @bobh66 all the template repos are in the crossplane org and I think that's the right home for them: https://github.com/crossplane/?q=template&type=public&language=&sort=

[chlunde]

We no longer use BitBucket Server so https://github.com/crossplane-contrib/provider-bitbucket-server should either get new maintainers, or be archived. I've reached out on slack but have not gotten any feedback. I'm no longer able to test any changes to the provider.

Should we just go ahead and archive it, or should we also think about a well defined process for deprecating and archiving providers, like a slack announcement, "call for new maintainers", check for activity (maybe not possible with GHCR?) etc?

[jbw976]

good question @chlunde, I think it's reasonable that a maintainer team attempts to find replacement/interested maintainers to carry on a project. The steering committee will own the archival process for a repo - there will be a big sweep of that in a couple months here after all the community extension projects have responded about their compliance (or haven't responded 😂).

[jan-di]

The Maintainer list requirements mention the cncf-crossplane-maintainers@lists.cncf.io mailing list.

Should we announce changes of maintainership there or should all maintainers of the Community Extension Project join the mailinglist? For the latter case, we are not able to find the mailing list over at https://lists.cncf.io.

[jbw976]

Great question @jan-di - I want to batch those changes to the CNCF maintainer mailing list into a single request after all the dust has settled from these new policies. I suspect we'll be archiving a chunk of these projects, so we'll make one request to the CNCF to update the mailing list with just the projects that have come into compliance in a couple months or so.