toggle quoted message
Show quoted text
100% agree with encouraging diversity and not being king makers.
However, I also think that applies within projects, not just between projects.
I want to make sure that we adopt tools that encourage and enable a diversity of people hosting artifacts.
As a concrete example, I would be uncomfortable accepting something like npm (not that they're talking to us) because it is pretty tightly locked to a single web site for discovery.
From: Erin Boyd <eboyd@...>
Sent: Thursday, March 12, 2020 11:22 AM
To: Brendan Burns <bburns@...>
Cc: alexis richardson <alexis@...>; CNCF TOC <cncf-toc@...>
Subject: Re: [EXTERNAL] Re: [cncf-toc] Point of process
To add to your thought, Brendan...I believe we should be thorough with our technical due diligence and understand what differentiates one project from another in the same space. And the CNCF, like any other company/organization is free to choose
the best technology to address their problem space.
However, I firmly believe that our job (TOC and TOC contributors) are to enable choices and diversity within the landscape. We don't want every project that goes into the cncf to operate exactly the same. There are advantages and disadvantages
of both. It's not a one-size-fits-all.
Ensuring we aren't being King Makers should be a fundamental value we hold in making these decisions.
On Thu, Mar 12, 2020, 11:40 AM Brendan Burns <bburns@...
I'm in full agreement regarding transparency in the CNCF.
However, I think the discussion about OperatorHub has more to do with it's intersection with Helm and the Helm Hub as well as whether Operator Hub is built to enable alternate/federated hubs in the way that Helm is.
(there's lots of details on the other threads about OperatorHub)
So I don't think it is accurate to characterize the delay as being due to CNCF Hub, but rather the ToC wrangling with what makes sense around these kinds of artifact discovery mechanisms.
In the interests of not forking the discussion, if people want to discuss OperatorHub technical design let's use the other threads for that.
On Thu, Mar 12, 2020, 4:26 AM alexis richardson <alexis@...> wrote:
I believe the issue here is simple. The CNCF is an open organisation
and should not develop its own projects in secret. End of story. We
saw this happen before eg "cloud native network functions" , which
led to collective bafflement from the community, TOC and End Users.
To be clear: I am 100% supportive of the CNCF using resources and
brand to kick projects, RFCs, RFPs, and who knows what. But please do
it in the OPEN. The CNCF should not compete with its membership.
On Thu, Mar 12, 2020 at 5:37 AM Chris Wright <chrisw@...> wrote:
> On Wed, Mar 11, 2020, 7:23 PM Liz Rice <liz@...> wrote:
>> Lots to unpack here, Chris, and as it’s 11pm I may not do it full justice in this response but I did want to make a couple of quick points:
>> First come, first served project assessment has been a worry for the TOC ever since I have been involved, if not longer. Accepting a project can be beneficial for that project but might be detrimental for a competing project. So, we try to look at competing
/ alternative solutions as part of any assessment. The order in which things are submitted is not the most important factor here.
> Agree with the sentiment here. I'd put it as domain squatting or cookie licking is not healthy for the broader industry. What I find uncomfortable here is the potential added component of lack of transparency and awkward sense of conflict of interest when
it appears to come from CNCF.
> Our stated goal is not to be a king maker. One natural outcome is projects with overlapping scope.
>> I think we all would have liked CNCF Hub to be made public some time ago.
> If someone other than CNCF said in private, "hey, we have a great project that nobody uses or has seen, so you should delay your process" I would expect the response to be pretty disinterested. "Thanks for your input, happy to evaluate after you exist."
>> To be fair to Dan, there have been some other pressing concerns to deal with in this time; I still think the project could have been made public sooner, but we are where we are. The TOC was made aware of the project, and I hope you’d agree we should act
with all the information we have at our disposal. It was clear that CNCF Hub would likely have an impact on the CNCF’s overall strategy around artifact discovery and distribution (and the operator hub is clearly in that space).
> I guess I'm really struggling not to see reverse cookie licking...despite what's existed for some time (with highly relevant concerns discussed and laid to rest in an open, active SIG community), here's a new and unproven concept...seemingly from CNCF. It
does beg the question: What is CNCF's strategy for artifact discovery and distribution?
>> Considering that strategy properly and calmly is in our view extremely important. We were aware that the delay was frustrating to the OF project and tried to at least give some explanation as to why there was hold-up (hence the comment in the PR that you
> Thank you for surfacing in a PR.
> The discussion is 13days after the SIG recommendation for acceptance, and draws out a suggestion the OF comply with a new, non-existent concept.
>> Over the past few months we have been working to make the project assessment process more scalable and transparent. But IMO process should never trump doing what we believe is the right thing for the community.
> I agree that process for process sake is the negative expression of beuraucracy.
> And I applaud all the work towards scalability and transparency. The task here is onerous and even thankless. So please take this as constructive feedback.
> It's why I suggested some clarity on guidelines. Because if we all decide independently on the right thing, we are not a community.
>> Liz Rice
>> @lizrice |
lizrice.com | +44 (0) 780 126 1145
>> On 11 Mar 2020, 22:33 +0000, Chris Wright <chrisw@...>, wrote:
>> During the evaluation of the Operator Framework for acceptance into
>> the CNCF as an incubation project, I was surprised to learn that the
>> vote was being held up by a request on behalf of a project yet to be
>> submitted to the TOC and SIGs for review. You can see the comment
>> The project, CNCF Hub, was just submitted March 10th to the TOC
>> mailing list as a project intended to be used as the CNCF standard for
>> discovering and installing projects within this ecosystem. This
>> project was mentioned to the community at KubeCon San Diego, but no
>> significant community awareness until March 10th. The project is being
>> released as pre-beta helm based project. The potential appearance of a
>> fait accompli by having this conceptual prototype with a CNCF domain
>> name is one of my concerns, as it can easily give a misleading view of
>> community and CNCF support.
>> As a foundation based on open source and open governance, I can't
>> accept a process that gives a CNCF sponsored project any special path
>> in or ability to hold up another project for consideration.
>> Projects should never be reviewed according to fluid, inconsistent or
>> secretive guidelines.
>> I recommend that we clarify the guidelines to ensure all projects are
>> treated equally and fairly.