Re: Eirini in 2019 CFAR certification requirements

Daniel Jones

Hi all,

The most important thing to ensure is that folks know what they're getting. It is in no-one's interests for a customer/user to think they're getting Cloud Foundry, and then find it doesn't offer all the advertised features - that would undermine trust in Cloud Foundry as a technology, and as a community.

If Eirini is optional in the certification and there's a clear feature matrix in the docs for each Eirini release detailing feature parity with Diego, then there is no danger of this happening.

Perhaps those not in favour of including Eirini in the certification spec could define the scope of the feature matrix, to ensure that all their concerns are highlighted.

Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists

On Sat, 17 Nov 2018 at 10:03, Krannich, Bernd <bernd.krannich@...> wrote:

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, fortunately:





[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@...>:



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. 







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:

·         Router:

·         Diego and/or 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.




Troy Topnik

Senior Product Manager, 

SUSE Cloud Application Platform 




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@...>
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, 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

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!

Eric Malm, CF Runtime Diego PM

Join to automatically receive all group messages.