Eirini in 2019 CFAR certification requirements
|
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:
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@...
|
|
|
|
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:
--
Through the darkness of future past the magician longs to see One chants out between two worlds Fire walk with me. |
|
|
|
Simon D Moser
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.
toggle quoted message
Show quoted text
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.
|
|
|
|
Krannich, Bernd
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:
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@...>
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.
|
|
|
|
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. Regards, Daniel 'Deejay' Jones - CTO +44 (0)79 8000 9153 On Sat, 17 Nov 2018 at 10:03, Krannich, Bernd <bernd.krannich@...> wrote:
|
|
|
|
Chip Childers <cchilders@...>
On Sat, Nov 17, 2018 at 5:03 AM Krannich, Bernd <bernd.krannich@...> wrote:
This is an accurate statement.
Ack - will work on that. :) |
|
|
|
Matt Cholick
The eirini repository's current README (https://github.com/cloudfoundry-incubator/eirini#y-tho-y) states: "Partly a fun experiment, partly a proof of concept" That phrasing doesn't read as a component I would want to run in production (or in a certified distribution). That section doesn't really dive into strong detail as to "why" the project important either. I think fleshing that section out more would be valuable. -Matt On Mon, Nov 19, 2018 at 8:13 AM Chip Childers <cchilders@...> wrote:
|
|
|
|
Julz Friedman
> That phrasing doesn't read as a component I would want to run in production (or in a certified distribution).
toggle quoted message
Show quoted text
Oops! You’re quite right Matt, this is still the README from my original spike many months ago, before we even officially started the project — we’ll be sure to update that asap :-). In the mean time, fwiw, there’s a (very) long and detailed proposal document, from when we originally approved Eirini as an incubator project, with much much more detail about the reasoning available here: https://docs.google.com/document/d/1qs6UQQDWMkfOpY19XqS3CfvI00jCns876TjplJ6E95s/edit?ouid=109489329491803931461&usp=docs_home&ths=true Thanks! On Mon, 26 Nov 2018 at 18:37, Matt Cholick <cholick@...> wrote:
|
|
|
|
Eric Malm <emalm@...>
Hi, all, Thanks for raising the topic of whether to include Eirini as an option in the 2019 CFAR certification requirements. Although the Eirini team has made tremendous progress over the past 6 months or so, it seems premature for the CFF to commit to including Eirini as a certified option for 2019. The team is close to passing a minimal set of CF Acceptance Tests, with the latest update in the #eirini-dev channel (https://cloudfoundry.slack.com/archives/C8RU3BZ26/p1543575973001900) reporting 66 passing, 1 failing, and 155 skipped tests, but according to https://github.com/cloudfoundry-incubator/eirini-ci/blob/master/pipelines/ci/cats-conf.yml that set of CATs does not yet even include all of the default suites in the CATs config (as per https://github.com/cloudfoundry/cf-acceptance-tests#test-configuration). In either case, those particular suites of CATs do not validate functionality such as application security groups, CF SSH, and app tasks that platform operators can enable or should configure, even if some CFAR environments may happen to disable them for their app developers. In addition to parity of feature functionality, I'm concerned that we would be granting certification to CFAR distributions that have not yet demonstrated a reasonable level of parity with current expectations of operational reliability and scale. For comparison, at the start of 2016, Diego had already been running the entirety of PWS for three months and had committed to backwards compatibility of its APIs and BOSH properties, and Pivotal had shipped PCF with it as the default container backend. I'm not aware of an Eirini-backed CFAR having the same level of practical operational validation at scale. I understand that the community members that are most committed to Eirini are concerned about missing all of 2019 for certification, so I'd like to propose the following course of action. Although the CFAR certifications have been on an annual cadence, the "Updates" section in the provider requirements (https://www.cloudfoundry.org/provider-requirements/) seem to me to state that the CFF has the authority to update them at any time. This annual cadence for certification seems intended primarily to give vendors enough lead time to react to proposed breaking changes in the certification, such as the removal of the DEAs and the transition from cf-release to cf-deployment in terms of integration expectations. Adding Eirini as a certification option once it is sufficiently robust in both feature parity and operational maturity would be an additive change, however, and therefore one that would not require advance notice or review lest it render existing distributions incompatible. Should Eirini achieve that parity during the 2019 calendar, that amendment could be released in, say, a "2019.1" certification revision during that year, in advance of the expected certification requirements for 2020. Thanks again, Eric On Mon, Nov 26, 2018 at 10:53 AM Julz Friedman <julz.friedman@...> wrote: > That phrasing doesn't read as a component I would want to run in production (or in a certified distribution). |
|
|
|
That sounds reasonable. I was going to add some "pending feature parity and passing CATs" language in the proposed change, but ammeding the requirements with a mid-term update would probably satisfy our needs without introducing conditional clauses.
Thanks for the feedback. TT |
|
|
|
Simon D Moser
+1. Our main intent certainly was to avoid
certification FUD in case we accomplish a "mature" Eirini in
the first half or 2019. To me ammeding the requirements with a mid-term
update does address this, so I'm fine with that.
Mit freundlichen Grüßen / Kind regards Simon Moser Senior Technical Staff Member / IBM Master Inventor Bluemix Application Platform Lead Architect Dept. C727, IBM Research & Development Boeblingen ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Schoenaicher Str. 220 71032 Boeblingen Phone: +49-7031-16-4304 Fax: +49-7031-16-4890 E-Mail: smoser@... ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 ******* ITIL has led people to think in siloes ("go fix change management"). Project Management has led people to think in finite units of work instead of streams of product. Both are fundamental dysfunctions of the framework model, not failures of execution. ⁃ Rob England From: "Troy Topnik" <troy.topnik@...> To: cf-dev@... Date: 04/12/2018 21:12 Subject: Re: [cf-dev] Eirini in 2019 CFAR certification requirements Sent by: cf-dev@... That sounds reasonable. I was going to add some "pending feature parity and passing CATs" language in the proposed change, but ammeding the requirements with a mid-term update would probably satisfy our needs without introducing conditional clauses. Thanks for the feedback. TT |
|
|
|
Chip Childers <cchilders@...>
Seems that discussion has died down on this.... At this point, it appears that consensus is around not adding Erini yet and reassessing when the project is further along. We can certainly make changes later in the year. The PMC Council has final say around any changes to the technical requirements, but any CFF member can propose the change. I'll look for interested parties to re-propose Erini inclusion when folks feel it's appropriate. On Wed, Dec 5, 2018 at 8:27 AM Simon D Moser <smoser@...> wrote: +1. Our main intent certainly was to avoid certification FUD in case we accomplish a "mature" Eirini in the first half or 2019. To me ammeding the requirements with a mid-term update does address this, so I'm fine with that. |
|
|
> Ack - will work on that. :) Chip, any progress on making governance and certification documents available to the community onto github ? Thanks in advance, Guillaume. On Tue, Dec 11, 2018 at 5:30 PM Chip Childers <cchilders@...> wrote:
|
|
|