1. cncf-toc@lists.cncf.io
  2. Messages
   Date   
Re: CNCF Storage SIG - Mission/Purpose/Ownership?

Quinton Hoole <quinton@...>
 

Hi Saad

Speaking personally, it would be great to have you as a TL on the CNCF Storage SIG. 

Regarding your other questions around SIG scope, have you read this yet?


That spells out in broad strokes what the responsibilities of CNCF SIGs are in general.  What I have undertaken to do is write up a draft charter of what exactly this means for the CNCF Storage SIG.  We can then review and  finalize this draft with the TOC.  It would be great to have your input.

Q



On Wed, Apr 10, 2019 at 1:38 PM Saad Ali <saadali@...> wrote:
Hi CNCF Storage WG,

Following up on the CNCF Storage WG meeting this morning: I'm considering throwing my hat in to the ring as a possible TL for the proposed CNCF Storage SIG. I'm currently Co-chair/TL of SIG Storage.

That said, I'd first like to understand what this new CNCF SIG will own?

The Kubernetes Storage SIG, for example, has clear ownership of the Kubernetes volume sub-system. This, CNCF storage workgroup, so far has produced whitepapers on the storage landscape, surveyed users, and hosted presentations from 3rd party storage projects. While all valuable, these are short term tasks.

My goal here is to make sure we act intentionally with a clear mission and purpose. A group without something to own will, at best, waste time, and, at worst, cause unnecessary conflict. To that end, I want to make sure the SIG has an obvious, long-term ownership of something concrete.

Thoughts? What do we think will be the long term sustainability strategy for this new SIG? What will it own?

Thanks,

Saad Ali



--
Quinton Hoole
quinton@...
CNCF Storage SIG - Mission/Purpose/Ownership?

Saad Ali <saadali@...>
 

Hi CNCF Storage WG,

Following up on the CNCF Storage WG meeting this morning: I'm considering throwing my hat in to the ring as a possible TL for the proposed CNCF Storage SIG. I'm currently Co-chair/TL of SIG Storage.

That said, I'd first like to understand what this new CNCF SIG will own?

The Kubernetes Storage SIG, for example, has clear ownership of the Kubernetes volume sub-system. This, CNCF storage workgroup, so far has produced whitepapers on the storage landscape, surveyed users, and hosted presentations from 3rd party storage projects. While all valuable, these are short term tasks.

My goal here is to make sure we act intentionally with a clear mission and purpose. A group without something to own will, at best, waste time, and, at worst, cause unnecessary conflict. To that end, I want to make sure the SIG has an obvious, long-term ownership of something concrete.

Thoughts? What do we think will be the long term sustainability strategy for this new SIG? What will it own?

Thanks,

Saad Ali
Re: CNCF Storage SIG - Mission/Purpose/Ownership?

Alex Chircop
 

Hi Saad,

 

Thanks for throwing your hat into the ring ! :-)

 

(apologies for the long email, but the info will hopefully benefit the rest of the mailing list too)

 

The CNCF SIGs are being setup to help the TOC as the CNCF continues to scale with the growing list of projects and members.

All the detail for the proposal/formation of the CNCF SIGs is available here: https://github.com/cncf/toc/blob/master/sigs/cncf-sigs.md

 

In summary, the general objectives are:

  • Strengthen the project ecosystem to meet the needs of end users and project contributors.
  • Identify gaps in the CNCF project portfolio. Find and attract projects to fill these gaps.
  • Educate and inform users with unbiased, effective, and practically useful information.
  • Focus attention & resources on helping foster project maturity, systematically across CNCF projects.
  • Clarify relationship between projects, CNCF project staff, and community volunteers.
  • Engage more communities and create an on-ramp to effective TOC contribution & recognition.
  • Reduce some project workload on TOC while retaining executive control & tonal integrity with this elected body.
  • Avoid creating a platform for politics between vendors.

 

and the specific responsibilities of the SIG include:

 

Project Handling:

  • Understand and document a high level roadmap of projects within this space, including CNCF and non-CNCF projects. Identify gaps in project landscape.
  • For projects that fall within the CNCF, perform health checks.
  • Perform discovery of and outreach to candidate projects
  • Help candidate projects prepare for presentation to the TOC
  • Every CNCF project will be assigned to one suitable SIG by the TOC.

End User Education (Outbound Communication)

  • Provide up-to-date, high quality, unbiased and easy-to-consume material to help end users to understand and effectively adopt cloud-native technologies and practises within the SIG’s area, for example:
    • White papers, presentations, videos, or other forms of training clarifying terminology, comparisons of different approaches, available projects or products, common or recommended practises, trends, illustrative successes and failures, etc.
    • As far as possible, information should be based on research and fact gathering, rather than pure marketing or speculation.

End User Input Gathering (Inbound Communication)

  • Gather useful end user input and feedback regarding expectations, pain points, primary use cases etc.
  • Compile this into easily consumable reports and/or presentations to assist projects with feature design, prioritization, UX etc.

Community Enablement

  • SIGs are open organizations with meetings, meeting agendas and notes, mailing lists, and other communications in the open
  • The mailing list, SIG meeting calendar, and other communication documents of the SIG will be openly published and maintained

As Trusted Expert Advisors to the TOC

  • Perform technical due diligence on new and graduating projects, and advise TOC on findings.
  • Be involved with, or periodically check in with projects in their area, and advise TOC on health, status and proposed actions (if any) as necessary or on request.

See Example Responsibilities of a CNCF SIG.

 

The first set of SIGs as per the proposal and the TOC members who will act as liaison with the SIG are:

(from: https://docs.google.com/presentation/d/1BUmTO5PFt7NZ9jVMMR3r1W7k8NANltNNJJqFCZdbS0I/edit#slide=id.g4e24cc378e_1_39)

  • Matt: Traffic (networking, service discovery, load balancing, service mesh, RPC, pubsub, etc)
    • Envoy, Linkerd, NATS, gRPC, CoreDNS, CNI
  • Jeff: Observability (monitoring, logging, tracing, profiling, etc.)
    • Prometheus, OpenTracing, Fluentd, Jaeger, Cortex, OpenMetrics,
  • Liz + Joe: Security/Governance (auth, authorization, auditing, policy enforcement, compliance, GDPR, cost management, etc)
    • SPIFFE, SPIRE, Open Policy Agent, Notary, TUF,  Falco,
  • Michelle + Alexis: App Dev, Ops & Testing (PaaS, Serverless, Operators, CI/CD,  Conformance, Chaos Eng, Scalability and Reliability measurement etc.)
    • Helm, CloudEvents, Telepresence, Buildpacks, (CNCF CI)
  • Brendan + Brian: Core and Applied Architectures (orchestration, scheduling, container runtimes, sandboxing technologies, packaging and distribution, specialized architectures thereof (e.g. Edge, IoT, Big Data, AI/ML, etc).
    • Kubernetes, containerd, rkt, Harbor, Dragonfly, Virtual Kubelet
  • Xiang: Storage (Block and File Stores, Databases, Key-Value stores etc)
    • TiKV, etcd, Vitess, Rook

 

Hope this helps,

 

Kind Regards,

Alex

 

 

 

 

From: Saad Ali <saadali@...>
Date: Wednesday, 10 April 2019 at 21:38
To: Quinton Hoole <quinton@...>, cncf-wg-storage <cncf-wg-storage@...>, "cncf-toc@..." <cncf-toc@...>, Alex Chircop <alex.chircop@...>
Subject: CNCF Storage SIG - Mission/Purpose/Ownership?

 

Hi CNCF Storage WG,

 

Following up on the CNCF Storage WG meeting this morning: I'm considering throwing my hat in to the ring as a possible TL for the proposed CNCF Storage SIG. I'm currently Co-chair/TL of SIG Storage.

 

That said, I'd first like to understand what this new CNCF SIG will own?

 

The Kubernetes Storage SIG, for example, has clear ownership of the Kubernetes volume sub-system. This, CNCF storage workgroup, so far has produced whitepapers on the storage landscape, surveyed users, and hosted presentations from 3rd party storage projects. While all valuable, these are short term tasks.

 

My goal here is to make sure we act intentionally with a clear mission and purpose. A group without something to own will, at best, waste time, and, at worst, cause unnecessary conflict. To that end, I want to make sure the SIG has an obvious, long-term ownership of something concrete.

 

Thoughts? What do we think will be the long term sustainability strategy for this new SIG? What will it own?

 

Thanks,

 

Saad Ali

 
Re: RFC: Strimzi

alexis richardson
 

David

Thanks. I would prioritise open governance over reducing your
committers, but up to you.

Re quotas. Any multi-tenant system that holds data for any length of
time faces the question of how available resources may be allocated to
tenants. Typically a quota system is used. If your users are single
tenant, then you don't need this.

a

On Wed, Apr 10, 2019 at 8:19 AM <dingham@...> wrote:

Hi,

Thank you for your comments and the opportunity to present Strimzi to the TOC yesterday.


We are keen to work towards neutral open governance of the project and think that the link to the Cortex governance is a good starting point. Until now the project has prioritised ease of administration over more formal processes for PR review and merging, but now is a good time to start adopting a more formal model. We will therefore start by reducing the number of our own committers and explore expanding the pool of non-Red Hat committers on the project (this might however take some more time). We’ll keep you informed on our progress.


During the call it was clear that other people were also interested in the idea of having a standalone Zookeeper deployment - without Apache Kafka. In order to make a start on some initial design work for this it would be great to get more input from those people about how they think this would be used. For example, if they had other Zookeeper-dependent projects in mind it would be great to know about them.


Can you elaborate on the idea around quotas? We think the idea here would be a messaging-agnostic custom resource/API expressing a quota for authenticated message senders to (abstract) message destinations, but we’re not sure we understood you correctly.


Finally, if we addressed these points are there other TOC members who would be willing to sponsor the project or do others have further issues they would like to discuss?

Best regards,
Dave.
Re: RFC: Strimzi

David Ingham
 

Hi,

Thank you for your comments and the opportunity to present Strimzi to the TOC yesterday.


We are keen to work towards neutral open governance of the project and think that the link to the Cortex governance is a good starting point. Until now the project has prioritised ease of administration over more formal processes for PR review and merging, but now is a good time to start adopting a more formal model. We will therefore start by reducing the number of our own committers and explore expanding the pool of non-Red Hat committers on the project (this might however take some more time). We’ll keep you informed on our progress.


During the call it was clear that other people were also interested in the idea of having a standalone Zookeeper deployment - without Apache Kafka. In order to make a start on some initial design work for this it would be great to get more input from those people about how they think this would be used. For example, if they had other Zookeeper-dependent projects in mind it would be great to know about them.


Can you elaborate on the idea around quotas? We think the idea here would be a messaging-agnostic custom resource/API expressing a quota for authenticated message senders to (abstract) message destinations, but we’re not sure we understood you correctly.


Finally, if we addressed these points are there other TOC members who would be willing to sponsor the project or do others have further issues they would like to discuss?

Best regards,
Dave.
Re: RFC: Keycloak project presentation

Stian Thorgersen <sthorger@...>
 

Keycloak does indeed have built-in support for MFA, but it is currently limited to one-time passwords (HOTP or TOTP). It is possible to extend Keycloak to add additional custom MFA mechanisms and we have community users that use SMS, hardware tokens, etc. with Keycloak.

That being said we are aware of limitations here which will be addressed in the near future. The limitations are mainly lack of additional built-in types (SMS, email, backup, etc.) as well as support for users to have choice between multiple mechanisms.

Until recently we have not actually seen much demand to go beyond one-time password support, but with WebAuthn becoming an official web standard there is now a lot of demand for it. It is a high priority to the Keycloak team to deliver improvements in this area as well as WebAuthn support and we are aiming to have this available in the next few months. We also have several community contributors working on this together with us, one group is working on a WebAuthn library for Java (https://github.com/webauthn4j/webauthn4j) and corresponding authenticator for Keycloak (https://github.com/webauthn4j/keycloak-webauthn-authenticator - this will be added directly to Keycloak in the future), another group is working on addition to authentication flows to allow for choices of MFA mechanisms.

In summary our plans are:

* Add support for admins to be able to manage what MFA mechanisms should be available
* Add support for users to configure multiple mechanisms through account console and selecting a default. During login users will be prompted for the default, but have choice to use an alternative
* Add support for WebAuthn to be used as a 2FA mechanisms in addition to password, and also a primary authentication mechanism for passwordless experience

More details can be found in our design brief for WebAuthn here https://github.com/keycloak/keycloak-community/blob/master/design/web-authn-two-factor.md. The brief on application initiated actions is also relevant (https://github.com/keycloak/keycloak-community/blob/master/design/application-initiated-actions.md). There will be two more related design briefs coming soon, one on passwordless experience for WebAuthn and another on extensions we are making to authentication flows (a contributor from the community is currently working on a proposal for this).

I hope this clears your concerns around MFA, if not I'm happy to discuss it further.


On Tue, 9 Apr 2019 at 19:56, Christopher LILJENSTOLPE <cdl@...> wrote:
Greetings,

Sorry I could not make the call today, but I did want to raise some concerns I have had over Keycloak.  One is the fact that, at heart, it is still a login/password system.  There is some ability to add MFA, but right now it is not really part of the standard mechanics, as far as I can see, and certainly does not allow multiple MFA capabilities - which is rapidly becoming a requirement and 'expected' behavior of an auth system.  I know there are issues open to look at this, but it seems as if there is no consensus within the keycloak community as to how to address those capabilities/requirements.

Without a clear path to enable more modern authentication practices, I'm pretty sure I wouldn't be able to support (I'm non-binding) adoption.

Christopher


On Tue, Apr 9, 2019 at 8:47 AM Chris Aniszczyk <caniszczyk@...> wrote:
The Keycloak project presented today:
https://github.com/cncf/toc/pull/176

The TOC, especially Joe had some questions on how Keycloak was
deployed on Wildfly (vs the RHT enterprise version of that). This
project is also fairly high up the stack compared to what we normally
accept in CNCF imho. We also didn't have a full roster of TOC members
so I'd like to ensure we have a wide set of eyes on this topic.

Jeff was also interested in being one of the sponsors for the sandbox
potentially.

Anyways, wanted to move the discussion to the mailing list.

--
Chris Aniszczyk (@cra) | +1-512-961-6719





-- 
Christopher LILJENSTOLPE
Co-Founder & CTO, Solutions
Tigera
cdl@... | @liljenstolpe | @liljenstolpe
Follow us: Blog  | Twitter | LinkedIn

Zero Trust Network Security & Continuous Compliance for Modern Applications

Re: RFC: Keycloak project presentation

Stian Thorgersen <sthorger@...>
 

As this may come up I wanted to clarify the relationship between Keycloak and RH-SSO. Keycloak is the community project and is freely available for anyone to use. RH-SSO is built directly from Keycloak source and each RH-SSO version is based on a specific Keycloak version (https://www.keycloak.org/support.html). There are no feature add-ons or any code that is not open source, everything is done in the open. Other than branding, the only difference between Keycloak and RH-SSO is that for productised builds Red Hat builds all dependencies from source internally, while for community projects we use available public releases of dependencies (from Maven Central mostly).


On Tue, 9 Apr 2019 at 17:47, Chris Aniszczyk <caniszczyk@...> wrote:
The Keycloak project presented today:
https://github.com/cncf/toc/pull/176

The TOC, especially Joe had some questions on how Keycloak was
deployed on Wildfly (vs the RHT enterprise version of that). This
project is also fairly high up the stack compared to what we normally
accept in CNCF imho. We also didn't have a full roster of TOC members
so I'd like to ensure we have a wide set of eyes on this topic.

Jeff was also interested in being one of the sponsors for the sandbox
potentially.

Anyways, wanted to move the discussion to the mailing list.

--
Chris Aniszczyk (@cra) | +1-512-961-6719
Re: RFC: Keycloak project presentation

sthorger@...
 

Actually, domain-mode is not relevant. Domain-mode is a feature of WildFly that allows creating and managing a group of servers, but this is not relevant in Kubernetes since it already has this capability. The relevant section of the documentation is https://www.keycloak.org/docs/latest/server_installation/index.html#_standalone-ha-mode as well as the documentation for the container image https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md.

For HA and scalability Keycloak relies on the embedded Infinispan server, which in turn relies on JGroups. Infinispan (https://infinispan.org/) is a distributed in-memory key/value data store, and JGroups (http://www.jgroups.org/) is a toolkit for reliable messaging. JGroups supports both UDP and TCP for transport and has a range of discovery protocols it supports for different environments.

Keycloak uses Infinispan for two purposes. Firstly, it is used as an invalidation cache which allows us to heavily cache data from the database. Secondly, it is used as a distributed cache for sessions. By default sessions are distributed to the nodes in the cluster and each session is stored in one node, but it is easy to enable replication of sessions where more than one node holds a replica.

We have plenty of large companies using both Keycloak as well as customers of Red Hat using RH-SSO (Red Hat's supported build of Keycloak, I will send a separate mail further explaining the difference here) that are deploying it in HA within a single site and we have quite a few that are deploying it to multiple-sites as well. Red Hat itself relies on RH-SSO as both are internal IdP and our external IdP (https://developers.redhat.com/blog/2019/02/14/red-hat-sso-high-availability-hybrid-cloud/). We also have several community users and customers that are deploying Keycloak with millions of users.

During one of the keynotes (https://www.redhat.com/fr/about/videos/summit-2018-keynote-emerging-technology-and-innovation-chris-wright) at last years Red Hat Summit we demonstrated RH-SSO running not just multi-site, but multi-cloud. We had RH-SSO available in AWS, Azure and a private cloud, with load balanced between the 3 clouds and also showed fail-over during the keynote. 

I hope this answers the concerns around HA and scalability, but I'm happy to follow-up if there are still some questions around this.

On Tue, 9 Apr 2019 at 19:39, Quinton Hoole <quinton.hoole@...> wrote:
Thanks for the presentation.  Very informative.

The questions I (and Joe) had around HA and scalability are at least partially answered in the installation documentation:

https://www.keycloak.org/docs/latest/server_installation/index.html#_domain-mode

If there is any more detailed information available on the HA and scalability design, and what's happening under the hood in that area, that would be useful.

Q

________________________________________
From: cncf-toc@... [cncf-toc@...] on behalf of boleslaw.dawidowicz@... [boleslaw.dawidowicz@...]
Sent: Tuesday, April 09, 2019 8:55 AM
To: Chris Aniszczyk
Cc: CNCF TOC
Subject: Re: [cncf-toc] RFC: Keycloak project presentation

There is nothing RHT enterprise specific and it is backed fully by
proven upstream technologies with active communities.

Regarding clustering and concerns expressed in the chat there is a way
to configure clustering on Kubernetes. We have people in the commnity
running deployments like that. Same for cross site replication.

If there is need to address more specific questions or perform a a
deeper dive we would be happy to do so.

Would like to thank for the opportunity to present the project to the
TOC today.

On Tue, Apr 9, 2019 at 5:47 PM Chris Aniszczyk
<caniszczyk@...> wrote:
>
> The Keycloak project presented today:
> https://github.com/cncf/toc/pull/176
>
> The TOC, especially Joe had some questions on how Keycloak was
> deployed on Wildfly (vs the RHT enterprise version of that). This
> project is also fairly high up the stack compared to what we normally
> accept in CNCF imho. We also didn't have a full roster of TOC members
> so I'd like to ensure we have a wide set of eyes on this topic.
>
> Jeff was also interested in being one of the sponsors for the sandbox
> potentially.
>
> Anyways, wanted to move the discussion to the mailing list.
>
> --
> Chris Aniszczyk (@cra) | +1-512-961-6719
>
>
>
Re: RFC: Keycloak project presentation

Christopher LILJENSTOLPE <cdl@...>
 

Greetings,

Sorry I could not make the call today, but I did want to raise some concerns I have had over Keycloak.  One is the fact that, at heart, it is still a login/password system.  There is some ability to add MFA, but right now it is not really part of the standard mechanics, as far as I can see, and certainly does not allow multiple MFA capabilities - which is rapidly becoming a requirement and 'expected' behavior of an auth system.  I know there are issues open to look at this, but it seems as if there is no consensus within the keycloak community as to how to address those capabilities/requirements.

Without a clear path to enable more modern authentication practices, I'm pretty sure I wouldn't be able to support (I'm non-binding) adoption.

Christopher


On Tue, Apr 9, 2019 at 8:47 AM Chris Aniszczyk <caniszczyk@...> wrote:
The Keycloak project presented today:
https://github.com/cncf/toc/pull/176

The TOC, especially Joe had some questions on how Keycloak was
deployed on Wildfly (vs the RHT enterprise version of that). This
project is also fairly high up the stack compared to what we normally
accept in CNCF imho. We also didn't have a full roster of TOC members
so I'd like to ensure we have a wide set of eyes on this topic.

Jeff was also interested in being one of the sponsors for the sandbox
potentially.

Anyways, wanted to move the discussion to the mailing list.

--
Chris Aniszczyk (@cra) | +1-512-961-6719





-- 
Christopher LILJENSTOLPE
Co-Founder & CTO, Solutions
Tigera
cdl@... | @liljenstolpe | @liljenstolpe
Follow us: Blog  | Twitter | LinkedIn

Zero Trust Network Security & Continuous Compliance for Modern Applications

Re: RFC: Keycloak project presentation

Quinton Hoole
 

Thanks for the presentation. Very informative.

The questions I (and Joe) had around HA and scalability are at least partially answered in the installation documentation:

https://www.keycloak.org/docs/latest/server_installation/index.html#_domain-mode

If there is any more detailed information available on the HA and scalability design, and what's happening under the hood in that area, that would be useful.

Q

________________________________________
From: cncf-toc@... [cncf-toc@...] on behalf of boleslaw.dawidowicz@... [boleslaw.dawidowicz@...]
Sent: Tuesday, April 09, 2019 8:55 AM
To: Chris Aniszczyk
Cc: CNCF TOC
Subject: Re: [cncf-toc] RFC: Keycloak project presentation

There is nothing RHT enterprise specific and it is backed fully by
proven upstream technologies with active communities.

Regarding clustering and concerns expressed in the chat there is a way
to configure clustering on Kubernetes. We have people in the commnity
running deployments like that. Same for cross site replication.

If there is need to address more specific questions or perform a a
deeper dive we would be happy to do so.

Would like to thank for the opportunity to present the project to the
TOC today.

On Tue, Apr 9, 2019 at 5:47 PM Chris Aniszczyk
<caniszczyk@...> wrote:

The Keycloak project presented today:
https://github.com/cncf/toc/pull/176

The TOC, especially Joe had some questions on how Keycloak was
deployed on Wildfly (vs the RHT enterprise version of that). This
project is also fairly high up the stack compared to what we normally
accept in CNCF imho. We also didn't have a full roster of TOC members
so I'd like to ensure we have a wide set of eyes on this topic.

Jeff was also interested in being one of the sponsors for the sandbox
potentially.

Anyways, wanted to move the discussion to the mailing list.

--
Chris Aniszczyk (@cra) | +1-512-961-6719
Re: RFC: Strimzi

alexis richardson
 

I am a potential sponsor.

for me to buy in: I'd like to see a neutral gov & roadmap plus plans
from david on achieving unambiguous neutrality, plus thoughts on what
would be useful as a 'spun out' tool, eg ZK, Quotas, ..

example of lean governance that works for one project
https://github.com/cortexproject/cortex/blob/master/GOVERNANCE.md


On Tue, Apr 9, 2019 at 9:00 AM Chris Aniszczyk
<caniszczyk@...> wrote:

Hey all, we heard from the Strimzi project today:
https://github.com/cncf/toc/issues/138

There were questions about if the ZK aspects of the operator could be
pulled out as its own project. There were also other questions around
other kafka operators in the ecosystem.

Anyways, the Strimzi project is looking for TOC sponsors for the sandbox.

--
Chris Aniszczyk (@cra) | +1-512-961-6719
RFC: Strimzi

Chris Aniszczyk
 

Hey all, we heard from the Strimzi project today:
https://github.com/cncf/toc/issues/138

There were questions about if the ZK aspects of the operator could be
pulled out as its own project. There were also other questions around
other kafka operators in the ecosystem.

Anyways, the Strimzi project is looking for TOC sponsors for the sandbox.

--
Chris Aniszczyk (@cra) | +1-512-961-6719
Re: RFC: Keycloak project presentation

boleslaw.dawidowicz@gmail.com
 

There is nothing RHT enterprise specific and it is backed fully by
proven upstream technologies with active communities.

Regarding clustering and concerns expressed in the chat there is a way
to configure clustering on Kubernetes. We have people in the commnity
running deployments like that. Same for cross site replication.

If there is need to address more specific questions or perform a a
deeper dive we would be happy to do so.

Would like to thank for the opportunity to present the project to the
TOC today.

On Tue, Apr 9, 2019 at 5:47 PM Chris Aniszczyk
<caniszczyk@...> wrote:

The Keycloak project presented today:
https://github.com/cncf/toc/pull/176

The TOC, especially Joe had some questions on how Keycloak was
deployed on Wildfly (vs the RHT enterprise version of that). This
project is also fairly high up the stack compared to what we normally
accept in CNCF imho. We also didn't have a full roster of TOC members
so I'd like to ensure we have a wide set of eyes on this topic.

Jeff was also interested in being one of the sponsors for the sandbox
potentially.

Anyways, wanted to move the discussion to the mailing list.

--
Chris Aniszczyk (@cra) | +1-512-961-6719
RFC: Keycloak project presentation

Chris Aniszczyk
 

The Keycloak project presented today:
https://github.com/cncf/toc/pull/176

The TOC, especially Joe had some questions on how Keycloak was
deployed on Wildfly (vs the RHT enterprise version of that). This
project is also fairly high up the stack compared to what we normally
accept in CNCF imho. We also didn't have a full roster of TOC members
so I'd like to ensure we have a wide set of eyes on this topic.

Jeff was also interested in being one of the sponsors for the sandbox
potentially.

Anyways, wanted to move the discussion to the mailing list.

--
Chris Aniszczyk (@cra) | +1-512-961-6719
Re: thought leadership

Vineet Gupta
 

Hello All,

I would like to second Erin’s idea for CNCF role in telco softwares, they are majorly driven towards NFV base deployments . Since I am coming from telco security companies a large transformation is happening in telcos to move towards what’s been done in Airship project and some other proprietary softwares in NFV space . As carriers we are looking to have a technical direction from CNCF which collaborated with what has been done in OPNFV space so far and how cloud native projects can be well integrated in OPNFV stack seamlessly . 

Almost all the efforts in telcos this year is  directed towards building up products which conforms to the security and edge deployment focused. So it would be great to have some CNCF landscape project to directly integrate with MANO and NFVI in plugins and extension point to integrate.

Not sure if there would be anything in KubeCon  Barcelona for the same but I would appreciate thoughts and guidance here from members.

Thanks much


On Sat 23 Mar 2019 at 19:45, Sarah Allen <sarah@...> wrote:

The CNCF is being looked to as a thought leader, and as I read the mission statement it seems to clearly evoke a strong leadership role “fostering and sustaining an ecosystem.”  I like Liz’s framing of the CNCF thought leadership roles as “curating, not inventing.”


To address the specific questions on security, I want to highlight some of the work of the SAFE WG, which provides a foundation for the kind of resources that I believe will be useful to executives who are making decisions about cloud native technologies and would like to understand security implications.


Published resources based on initial vision and charter:


Other in-progress resources:


We recently prioritized the security white paper, now that it is a bit more clear the audience and purpose of that resource.  We appreciate that the CNCF and the Linux Foundation is supporting this effort and look forward to collaborating with Jessica Wilkerson, Linux Foundation Cybersecurity Research Director on that effort.  


Thank you,

Sarah Allen

SAFE WG, co-chair


p.s. I completely agree on the need for more guidance on compliance (HIPAA, GDPR have come up a lot in discussions, and my hope is that the current work on shared terminology and categorization the existing technologies and common approaches for enforcement, verification, auditing, explainability, etc. will serve as a solid foundational for additional resources.)




On Fri, Mar 22, 2019 at 12:17 PM Doug Davis <dug@...> wrote:

Yup. I kind of like what we did in the Serverless WG. We produced a whitepaper and landscape doc to help people understand what serverless is all about, what's going on in the community, what's out there for people to use (OSS vs proprietary), etc... There was a little bit of opinion mixed in, but I think it was based on experience and the general direction we were seeing the community go. Or it was more like talking about design patterns that were emerging, and when they might be appropriate. It definitely was not playing "king maker" or telling people to use one product over another.

More about education than anything else so they can make an informed decision.


thanks
-Doug
_______________________________________________________
STSM | IBM Open Source, Cloud Architecture & Technology
(919) 254-6905 | IBM 444-6905 | dug@...
The more I'm around some people, the more I like my dog

"Matt Farina" ---03/22/2019 02:10:22 PM---When I was writing the SIG Responsibilities I added a bullet under the end user education section th

From: "Matt Farina" <matt@...>
To: CNCF TOC <cncf-toc@...>
Date: 03/22/2019 02:10 PM
Subject: Re: [cncf-toc] thought leadership
Sent by: cncf-toc@...




When I was writing the SIG Responsibilities I added a bullet under the end user education section that reads:
      White papers, presentations, videos, or other forms of training clarifying terminology, comparisons of different approaches, available projects or products, common or recommended practises, trends, illustrative successes and failures, etc.

I don’t know if I would call this “thought leadership” in the typical sense. The idea was to consolidate and clearly communicate what is going on. To share how people are solving their problems and what it does for them.

When it comes to being opinionated on how people should do things, I tend to be a bit reserved there. Different people have different needs and there is no one size fits all. And, a lot of the talk is from infrastructure folks who have different practices, goals, and cultures from the app devs running the applications. Then there is the difference between highly regulated businesses and many of the startups trying things out. There are many dimensions to differences which makes it hard to give too many recommendations on how people should do things.

--
Matt Farina
mattfarina.com
Agenda for 4/9/2019 TOC Meeting

Chris Aniszczyk
 

Hey all, we are meeting tomorrow, focused on community presentations
to catch up on the CNCF community presentation backlog:

https://docs.google.com/presentation/d/1bijEpuwaaa6jR1D5PAjyW731-j6Xc1TFHJuUh_FwwK8/edit#slide=id.g25ca91f87f_0_0
https://docs.google.com/document/d/1jpoKT12jf2jTf-2EJSAl4iTdA7Aoj_uiI19qIaECNFc/edit#

We will be hearing from the NSM, Keycloak and Strimzi communities.

--
Chris Aniszczyk (@cra) | +1-512-961-6719
[RESULT] CRI-O project proposal (incubation)

Chris Aniszczyk
 

Re: [VOTE] fluentd moving to graduation

Gilbert Song
 

+1 (non-binding)

On Fri, Mar 29, 2019 at 9:35 AM Chris Aniszczyk <caniszczyk@...> wrote:
fluentd has requested to move to the graduation maturity level:
https://github.com/cncf/toc/pull/69

Brian Grant from the TOC has performed due diligence and called the vote:
https://lists.cncf.io/g/cncf-toc/message/3089
https://all.devstats.cncf.io/d/54/project-health?orgId=1&var-repogroup_name=Fluentd

Please vote (+1/0/-1) by replying to this thread; the full proposal
located here: https://github.com/cncf/toc/pull/69

Remember that the TOC has binding votes only, but we do appreciate
non-binding votes from the community as a sign of support!

--
Chris Aniszczyk (@cra) | +1-512-961-6719
Re: [VOTE] fluentd moving to graduation

Brewer, Jeff
 

+1 binding

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Michelle Noorali via Lists.Cncf.Io
Sent: Thursday, April 4, 2019 5:39 PM
To: Chris Aniszczyk <caniszczyk@...>; CNCF TOC <cncf-toc@...>; mrausch@...
Cc: cncf-toc@...
Subject: Re: [cncf-toc] [VOTE] fluentd moving to graduation

 

This email is from an external sender.

 

+1 binding

From: cncf-toc@... <cncf-toc@...> on behalf of Rausch, Matt via Lists.Cncf.Io <mrausch=nipr.com@...>
Sent: Tuesday, April 2, 2019 4:07 PM
To: Chris Aniszczyk; CNCF TOC
Cc: cncf-toc@...
Subject: Re: [cncf-toc] [VOTE] fluentd moving to graduation

 

+1 (non-binding)

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Yash Thakkar
Sent: Tuesday, April 2, 2019 1:52 PM
To: Chris Aniszczyk <caniszczyk@...>; CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] fluentd moving to graduation

 

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

+1 (non-binding)

 

On Tue 2 Apr, 2019, 10:52 PM Chiradeep Vittal, <chiradeep.vittal@...> wrote:

+1 (nb)

On 3/29/19, 9:35 AM, "cncf-toc@... on behalf of Chris Aniszczyk" <cncf-toc@... on behalf of caniszczyk@...> wrote:

    fluentd has requested to move to the graduation maturity level:
    https://github.com/cncf/toc/pull/69

    Brian Grant from the TOC has performed due diligence and called the vote:
    https://lists.cncf.io/g/cncf-toc/message/3089
    https://all.devstats.cncf.io/d/54/project-health?orgId=1&var-repogroup_name=Fluentd

    Please vote (+1/0/-1) by replying to this thread; the full proposal
    located here: https://github.com/cncf/toc/pull/69

    Remember that the TOC has binding votes only, but we do appreciate
    non-binding votes from the community as a sign of support!

    --
    Chris Aniszczyk (@cra) | +1-512-961-6719






----------------------------------------- CONFIDENTIALITY NOTICE This message and any attachments are from the NIPR and are intended only for the addressee. Information contained herein is confidential, and may be privileged or exempt from disclosure pursuant to applicable federal or state law. This message is not intended as a waiver of the confidential, privileged or exempted status of the information transmitted. Unauthorized forwarding, printing, copying, distribution or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error.

Re: [VOTE] fluentd moving to graduation

Michelle Noorali
 

+1 binding
From: cncf-toc@... <cncf-toc@...> on behalf of Rausch, Matt via Lists.Cncf.Io <mrausch=nipr.com@...>
Sent: Tuesday, April 2, 2019 4:07 PM
To: Chris Aniszczyk; CNCF TOC
Cc: cncf-toc@...
Subject: Re: [cncf-toc] [VOTE] fluentd moving to graduation
 

+1 (non-binding)

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Yash Thakkar
Sent: Tuesday, April 2, 2019 1:52 PM
To: Chris Aniszczyk <caniszczyk@...>; CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] fluentd moving to graduation

 

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

+1 (non-binding)

 

On Tue 2 Apr, 2019, 10:52 PM Chiradeep Vittal, <chiradeep.vittal@...> wrote:

+1 (nb)

On 3/29/19, 9:35 AM, "cncf-toc@... on behalf of Chris Aniszczyk" <cncf-toc@... on behalf of caniszczyk@...> wrote:

    fluentd has requested to move to the graduation maturity level:
    https://github.com/cncf/toc/pull/69

    Brian Grant from the TOC has performed due diligence and called the vote:
    https://lists.cncf.io/g/cncf-toc/message/3089
    https://all.devstats.cncf.io/d/54/project-health?orgId=1&var-repogroup_name=Fluentd

    Please vote (+1/0/-1) by replying to this thread; the full proposal
    located here: https://github.com/cncf/toc/pull/69

    Remember that the TOC has binding votes only, but we do appreciate
    non-binding votes from the community as a sign of support!

    --
    Chris Aniszczyk (@cra) | +1-512-961-6719







----------------------------------------- CONFIDENTIALITY NOTICE This message and any attachments are from the NIPR and are intended only for the addressee. Information contained herein is confidential, and may be privileged or exempt from disclosure pursuant to applicable federal or state law. This message is not intended as a waiver of the confidential, privileged or exempted status of the information transmitted. Unauthorized forwarding, printing, copying, distribution or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error.

4641 - 4660 of 7803