/sig auth
/sig network
/sig storage

/assign @youngnick

Would folks be willing to retitle this KEP? Although the change we want to bring about is a move of API group, the desired state is that there is a ReferenceGrant API available for multiple consumers and with review by SIG Architecture.

I'd like to capture that desired outcome, which will become visible to end users (eg: in release notes, other release-related comms), in the KEP title.

That seems reasonable to me, something like "Create in-tree ReferenceGrant resource for allowing cross-namespace references"? ("in-tree" is doing a lot of heavy lifting there.)

That's also changing the intent. I originally thought this KEP was about updating the existing CRD to be one that SIG Auth would own.

Let's be clear on which we want, so that our end users are also not confused!

Hello @robscott 👋, v1.27 Enhancements team here.

Just checking in as we approach enhancements freeze on 18:00 PDT Thursday 9th February 2023.

This enhancement is targeting for stage alpha for 1.27 (please correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP readme using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable for latest-milestone: 1.27
• KEP readme has a updated detailed test plan section filled out
• KEP readme has up to date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements.

For this KEP, we would need to update the following:

• Update to the latest KEP template. Specifically, there is an additional question in the Scalability section of the PRR.
• Update kep.yaml to reflect current stage information. This assumes that the description in the issue that states that the v1.27 is for beta is correct, and that the kep.yaml information that v1.27 is for alpha is not - if the opposite is true then no change would be needed in the file.
• Fix formatting in the Graduation Criteria section.

The status of this enhancement is marked as at risk. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

@fsmunoz I don't believe this has had a PRR review.

Yes, it is merged right now as provisional, so the PRR tooling doesn't kick in - Rob & I discussed this. Before it moves to implementable it needs PRR. @robscott this needs to move to implementable ASAP if you want to make the release!

@johnbelamaric filed a PR earlier that would make that change, but still needs some more reviews + approvals: #3832

@johnbelamaric thank you, I was going from the content of the KEP PRR section. Until it's marked as implementable though it's not going to be tracked.

As much as I'd love to get this in to the 1.27 cycle, I think everyone that could review/approve is pretty underwater this cycle and we likely need some rounds of review + revision on this KEP still. In light of that, we should probably formally punt this to the 1.28 cycle.

@robscott I'm marking this as Deferred, should this change in the next hours place comment and we'll try to review it. Thanks!

Some quick updates on this KEP.

1. We've met at the previous 2 KubeCons with some sig-auth leads to discuss a path forward, resulting in this updated proposal
2. I've translated that proposal into a rough proof of concept here: https://github.com/robscott/referencegrant-poc

Hello @robscott @deads2k @youngnick 👋, Enhancements team here.

Just checking in as we approach enhancements freeze on [02:00 UTC Friday 9th February 2024 / 18:00 PDT Thursday 8th February 2024](https://everytimezone.com/s/1ade3dca):.

This enhancement is targeting for stage alpha for v1.30 (correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP readme using the [latest template](https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template) has been merged into the k/enhancements repo.
• KEP status is marked as implementable for latest-milestone: 1.30. KEPs targeting stable will need to be marked as implemented after code PRs are merged and the feature gates are removed.
• KEP readme has up-to-date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements. (For more information on the PRR process, check [here](https://github.com/kubernetes/community/blob/master/sig-architecture/production-readiness.md#submitting-a-kep-for-production-readiness-approval)).

For this KEP, we would just need to update the following:

• The latest-milestone and stage should be updated to 1.30 in the kep.yaml file.
• The production readiness review should be completed and updated with the information for the targeting stage alpha.

The status of this enhancement is marked as at risk for enhancement freeze. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

Per the slack thread conversation, I am moving this KEP out of the v1.30 release.

/milestone clear

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

What can we do to move this forward? I'd be very pleased to see an out-of-tree alpha CRD that is neutral in respect of use case.

If I work on that, is that contribution useful?