Hi all,

 

For SAP, as a CFF member having developers working on Eirini fulltime, it is evident that Troy’s

 

> a number of us are keen to see Kubernetes-native app scheduling in CFAR distributions as soon as possible. Ideally we would like these distributions to be certified by the CF Foundation when they are released.

 

includes SAP as well.

 

Following Simon’s reasoning, not being able to certify a distribution running Eirini would actually be an adoption blocker for us. Also, similar to IBM, it is a well-kept secret that SAP is running some of the biggest Cloud Foundry deployments world-wide (oops, now I told it…), so we’ll do our part to make sure that Eirini is scaling and capable to run production workloads.

 

I did some “internet archeology” to see how we handled the DEA à Diego switch and certification. Unfortunately, I think the old certification docs are gone from the Cloud Foundry homepage [1], but there’s archive.org, fortunately:

• https://web.archive.org/web/20160310172551/https://www.cloudfoundry.org/use/cloud-foundry-certified/certification-requirements/ (March 10, 2016) - “Certified offerings are required to use the following Cloud Foundry platform components […] DEA & Warden (OR the newer “Diego” components, OR both runtime architectures)”
• Diego was declared 1.0.0 Nov 29, 2016 and this is when the end-of-life ticker for DEAs started (attached).
• If I am not getting things wrong this means that distributions could be certified with only running Diego well before the Diego GA.

 

Thanks,

Bernd

 

[1] Feedback: For governance docs (@Chip Childers), it might be worthwhile to keep things in a public Github repo, too.

 

From: <cf-dev@...> on behalf of Simon D Moser <smoser@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Saturday, 17. November 2018 at 09:22
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] Eirini in 2019 CFAR certification requirements

 

While i agree that Eirini needs more Battle-testing and production evaluation still, i think the key is this not a certification *requirement*, but rather a *certification option*. From my point of view, IBM will have a commercial Eirini out in 2019 and we want that not to be non-certified. Up to an cf adopter whether he‘ll take the risk to pick it up or not, but if you do you should be within the certification.

 

FWIW, with SUSE SCF and IBM CFEE there will likely be at least two production adopter products in 2019, and the community cannot and does not want to make that decision dependent on PCF adoption. Other projects have been production tested on other CF offerings like IBM Bluemix in the past, so PCF is not (and should not be) the only quality gate for an open source project. 

 

Von meinem iPhone gesendet

Am 17.11.2018 um 00:39 schrieb Sascha Matzke <sascha.matzke@...>:

Hi,

 

I really don't want to spoil your enthusiasm, but I would say let's run some production workloads on Eirini first and then include it in the certification (2020 maybe?).

 

One of the things I love about the current Cloud Foundry ecosystem is that it is continuously "battle tested" on PWS and other environments (even if it's not for altruistic reasons at all, it's still a great service for the community - Kudos Pivotal!). 

 

I would like to see the same level of validation for Eirini before including it in the certification requirements. 

 

Best, 

 

Sascha

 

 

On Fri, Nov 16, 2018 at 11:47 PM Troy Topnik <troy.topnik@...> wrote:

Eirini is coming, and a number of us are keen to see Kubernetes-native app scheduling in CFAR distributions as soon as possible. Ideally we would like these distributions to be certified by the CF Foundation when they are released.

 

We recognize that Eirini is still in incubation, but it’s getting closer to feature parity with Diego every day. The Cloud Foundry acceptance tests (CATs) are almost all passing, and are expected to be fully passing by the time the certification requirements are released, but the 2019 requirements are currently being drafted.

 

So I’d like to propose including Eirini as an alternative CFAR scheduler, assuming it will be passing the relevant tests by the time of certification.

 

My suggestion is a one line change to the Application Runtime section of the certification requirements:

 

The Application Runtime portion of a certified offering must include the following components:

·         Cloud Controller: https://github.com/cloudfoundry/capi-release/

·         Router: https://github.com/cloudfoundry-incubator/routing-release/

·         Diego and/or Eirini: https://github.com/cloudfoundry/diego-release/  https://github.com/cloudfoundry-incubator/eirini

·         ...

 

There are likely more changes coming in this section from other projects, but this would be the diff from the 2018 certification requirements.

 

Obviously, this is a matter for discussion with the wider community and of course the PMC Council, so let’s start the discussions here on cf-dev and expose all the questions and concerns.

Cheers,

TT

--

Troy Topnik

Senior Product Manager, 

SUSE Cloud Application Platform 

troy.topnik@...

 

 

--

Through the darkness of future past
the magician longs to see
One chants out between two worlds
Fire walk with me.

 

---------- Forwarded message ----------
From: Eric Malm <emalm@...>
To: cf-dev <cf-dev@...>
Cc: 
Bcc: 
Date: Tue, 29 Nov 2016 09:53:44 -0800
Subject: [cf-dev] Cloud Foundry Diego v1.0.0 released, starting EOL schedule for DEAs

Hi, all,

I'm extremely pleased to report that the Cloud Foundry Diego team has now released version 1.0.0 of diego-release, after having successfully validated its ambitious scaling targets in a full Cloud Foundry setting. If you've been following in our public tracker at https://www.pivotaltracker.com/n/projects/1003146, or joined the Community Advisory Board discussion earlier this month, you'll have seen that the Diego team has succeeded in running 200,000 CF apps with a total of 250,000 instances on a large, Diego-backed CF deployment on GCP.

A key part of achieving this milestone has been replacing the etcd key-value store with a relational data store, and from version 1.0.0 forward Diego officially supports only MySQL and Postgres databases. Consequently, if you haven't done so already, please conduct your migration to one of these two relational stores as soon as possible. Throughout major version 1, Diego will support migrating data from existing etcd data stores to MySQL or Postgres, but not standalone etcd deployments. We also recommend that operators adopt a new set of more granular database configuration properties introduced in Diego v0.1490.0 instead of the original monolithic connection string.

As a reminder, the release of Diego v1.0.0 also officially starts the six-month end-of-life schedule for the DEAs. Please see more details in the earlier announcement at https://lists.cloudfoundry.org/archives/list/cf-dev@.../message/GMXXJTTM2Q6SIRGVXSQH4TPLHTVHKNNG/.

Finally, a tremendous thank-you to all of the past and present members of the Diego team, stretching all the way back to January 2014!

Thanks,

Eric Malm, CF Runtime Diego PM

In comparison to DEA what are the new components of DEIGO?
1. Converger
2. CC Bridge
3. Metrics server
4. Auctioneer
5. CELL

Eirini is coming, and a number of us are keen to see Kubernetes-native app scheduling in CFAR distributions as soon as possible. Ideally we would like these distributions to be certified by the CF Foundation when they are released.

We recognize that Eirini is still in incubation, but it’s getting closer to feature parity with Diego every day. The Cloud Foundry acceptance tests (CATs) are almost all passing, and are expected to be fully passing by the time the certification requirements are released, but the 2019 requirements are currently being drafted.

So I’d like to propose including Eirini as an alternative CFAR scheduler, assuming it will be passing the relevant tests by the time of certification.

My suggestion is a one line change to the Application Runtime section of the certification requirements:

The Application Runtime portion of a certified offering must include the following components:

• Cloud Controller: https://github.com/cloudfoundry/capi-release/

• Router: https://github.com/cloudfoundry-incubator/routing-release/

• Diego and/or Eirini: https://github.com/cloudfoundry/diego-release/  https://github.com/cloudfoundry-incubator/eirini

• ...

There are likely more changes coming in this section from other projects, but this would be the diff from the 2018 certification requirements.

Obviously, this is a matter for discussion with the wider community and of course the PMC Council, so let’s start the discussions here on cf-dev and expose all the questions and concerns.

Cheers,

TT

--

Troy Topnik

Senior Product Manager, 

SUSE Cloud Application Platform 

troy.topnik@...