Add secrets-store-csi-driver project

[aramase]

• secrets-store-csi-driver was recently moved to kubernetes-sigs
• onboarding the project, so we can start publishing the images to gcr.io

[aramase]

/assign @dims

[aramase]

/cc @ritazh

[thockin]

So we finally get to have the granularity discussion. :)

On its face this seems fine and consistent with precedent, but...

Should we force grouping? E.g. should sig- get a quota on stagings? Or something?

Or should we nest "directories" in GCR? E.g. instead of k8s.gcr.io/csi-foobar and k8s.gcr.io/csi-quuxzorb, should we encourage k8s.gcr.io/csi/{foobar,quuxzorb}?

@detiber re capi - would you prefer to have some form of nesting in the output? Would you prefer to have distinct stagings or a smaller, more onmibus set?

@listx

[listx]

So we finally get to have the granularity discussion. :)

On its face this seems fine and consistent with precedent, but...

Should we force grouping? E.g. should sig- get a quota on stagings? Or something?

Or should we nest "directories" in GCR? E.g. instead of k8s.gcr.io/csi-foobar and k8s.gcr.io/csi-quuxzorb, should we encourage k8s.gcr.io/csi/{foobar,quuxzorb}?

+1 for nesting, seems like the right paradigm, at least from a technical standpoint

[thockin]

The main argument against nesting is that we didn't already do it for capi ):)

…

On Fri, Mar 13, 2020 at 4:42 PM Linus Arver ***@***.***> wrote: So we finally get to have the granularity discussion. :) On its face this seems fine and consistent with precedent, but... Should we force grouping? E.g. should sig- get a quota on stagings? Or something? Or should we nest "directories" in GCR? E.g. instead of k8s.gcr.io/csi-foobar and k8s.gcr.io/csi-quuxzorb, should we encourage k8s.gcr.io/csi/{foobar,quuxzorb} <http://k8s.gcr.io/csi/%7Bfoobar,quuxzorb%7D>? +1 for nesting, seems like the right paradigm, at least from a technical standpoint — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#658 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKWAVFWARIEQGD6HOMB4LDRHLAGPANCNFSM4LGTELMA> .

[detiber]

I've added an agenda item to the next Cluster API meeting to discuss the topic of nesting staging repos.

[thockin]

Note that there are 2 questions and they are orthogonal. 1) Should we merge smaller-scoped staging projects (probably no, IMO) 2) Should we "nest" related prod GCR directories? On #2 specifically, the nesting would be in the FINAL, public, prod container image name.

…

On Mon, Mar 16, 2020 at 8:13 AM Jason DeTiberus ***@***.***> wrote: I've added an agenda item to the next Cluster API meeting to discuss the topic of nesting staging repos. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub, or unsubscribe.

[aramase]

@thockin Updated the PR based on the comments, PTAL!

[aramase]

@dims @thockin PTAL when you get a chance!

[ncdc]

@thockin re capi, I'd be ok with all the sig-sponsored cluster api images going into a single bucket, with distinct paths. e.g. we currently have k8s-staging-cluster-api/cluster-api-controller and k8s-staging-cluster-api-aws/cluster-api-aws-controller (just to name 2). I'm fine moving everything under a cluster-api bucket (core cluster api + all sig-sponsored providers), if that works for everyone else.

Also xref #671, which is requesting a staging bucket for the digitalocean capi provider.

cc @timothysc @vincepri @CecileRobertMichon @yastij @randomvariable and I'm sure there are others I'm leaving off

[listx]

If we do end up reorganizing some of the final prod image paths, we should not delete the old (existing) promoter manifests because they will serve as a historical record. (I.e., let's not be forced to do this again).

[vincepri]

I'm +1 to organize all CAPI projects under the CAPI staging project. In terms of timeline, where are we looking to do this change?

[detiber]

If we do organize under a single staging bucket for cluster-api, building on what @ncdc mentioned, I think it should be organized something like this:

cluster-api/ <- hosts all images that are built from cluster-api project directly
cluster-api/<provider-type>/<provider-name> <- hosts images related to that provider

This would allow for separation of ownership/access for sig-sponsored sub-projects that might have separate ownership on individual repos.

Should we rally around a doc/issue for hashing a concrete proposal, including transition plan and maintaining the historical record (as well as maintaining backward compat)?

[dims]

/hold

looks like lots of discussions here

[spiffxp]

@detiber

Should we rally around a doc/issue for hashing a concrete proposal, including transition plan and maintaining the historical record (as well as maintaining backward compat)?

Yes. I just opened #696 let's take the discussion over there.

/assign @thockin @dims
I question whether we should continue to block this PR. It's unclear to me how quickly we're going to sort this out, and we're going to have to migrate things anyway. What do you think?

[aramase]

@dims @thockin Can we unblock this PR as per @spiffxp comment?

[dims]

/hold cancel

[thockin]

Thanks!

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aramase, thockin

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [thockin]
• groups/OWNERS [thockin]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[thockin]

This is activated

[aramase]

Thank you @thockin!