Date   

Re: Eirini in 2019 CFAR certification requirements

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

 


 

--

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

 


Re: Eirini in 2019 CFAR certification requirements

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.

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:


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 
 



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


Re: What are the new components of DEIGO? #cf

borntorule73@...
 

I am not spamming, just trying to seek help. This is a help forum if I am not wrong!


Re: What are the new components of DEIGO? #cf

Surendhar
 

Are you in an Interview or Certification Exam 😂? Please don't spam this.


On Sat, Nov 17, 2018 at 12:04 PM <borntorule73@...> wrote:
In comparison to DEA what are the new components of DEIGO?
1. Converger
2. CC Bridge
3. Metrics server
4. Auctioneer
5. CELL


What are the new components of DEIGO? #cf

borntorule73@...
 

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


What are the ports supported by Cloudfoundry? #cf

borntorule73@...
 

What ports are supported by cloudfoundry from amongst these - 80, 4443, 43, 443 and 8080


Is it true that only one application can run/scale in a space? #cf

borntorule73@...
 

Is it true that only one application can run/scale in a space?


What is the URL of an application in Cloudofundry? #cf

borntorule73@...
 

Is it -

1. Subdomain.domain
2. Domain.subdomain
3. Subdomain
4. Domain
5. None


Can same application be deployed to multiple spaces? #cf

borntorule73@...
 
Edited

Can someone suggest if a same application be deployed to multiple spaces?
If yes, can it be done using same URL or different Unique URL?


What is the topmost administrative unit in Cloudfoundry? #cf

borntorule73@...
 

1. Space
2. Quota
3. Organization
4. None


What is the deployment blueprint of an application #cf

borntorule73@...
 

Can someone please suggest what is the deployment blueprint of an application?

1. Manifest
2. Buildpack
3. Services
4. Routes
5. None


Re: Eirini in 2019 CFAR certification requirements

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:


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 
 



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


Eirini in 2019 CFAR certification requirements

Troy Topnik
 

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


FINAL REMINDER : CF CAB call for November is next Wednesday November 14 @ 8a PST

Michael Maximilien
 

FYI...

dr.max
ibm ☁ 
silicon valley, ca



dr.max
ibm ☁ 
silicon valley, ca


On Nov 8, 2018, at 10:25 AM, Michael Maximilien <maxim@...> wrote:

Hi, all,

Quick reminder that the CAB call for November is next week Wednesday November 14th @ 8a PST.

We will have our regular PMCs highlights and two talks. One confirmed, so if you have one to give or to nominate then contact me directly ASAP.

The confirmed talk is a really good one. Saw it during Basel Summit. Don’t want to miss it:

1. Performance of a VM vs Containerized Cloud Foundry by Jeff Hobbs and Vlad Iovanov of SUSE [Vlad presenting]

2. TBD — send me nominations if you have

All other info in agenda here [0].

Zoom soon. Best,



routing-release 0.183.0

Shubha Anjur Tupil
 

We cut routing-release 0.183.0 today morning. 

Release highlights: 
  • Operator can specify HTTP headers to be added by Gorouter to responses details
  • Operator can specify HTTP headers to be removed by Gorouter from the responses details
  • We have updated locket to the latest commit details
  • Fixed an issue introduced with the move to BPM for TCP Router on accumulating TCP-Router HAProxy instances details
  • With the move to BPM, operators should use the syslog release for access log streaming. enable_access_log_streaming is no longer supported in the Gorouter details
  • Gorouter stdout logs includes vcap_request_id so operators can correlate the stdout logs with access logs for easier debugging of issues details
  • Route registrar now supports registration of TCP routes details
  • When an application instance crashes while processing a request Gorouter now returns an error and takes the backend out of the pool temporarily, without retrying another backend details
  • We have updated from Cflinux2 to Cflinuxfs3 details
  • We are still evaluating the issue we are having with performance reports and have not been able to get a root cause details
Regards, 
Routing team


For mobile application which is the best API for login (for getting acess token)? #cf

shilpa kulkarni
 

Hello,

I am using cloud foundry UAA APIs. For web application I am using Authorization code grant API. 
For mobile application which grant type(implicit, password, authorization code or client credentials) is best to use? 
For mobile application which is the best API for login (for getting access token)? 

Thanks & Regards,
Shilpa Kulkarni


Please vote: Summit NA 2019 Track Co-chairs

Swarna Podila
 

Hi Everyone,
Thank you very much for the overwhelming responses and nominating such stellar group of individuals to be track co-chairs for Cloud Foundry Summit North America 2019 to be held in Philadelphia from April 2-4, 2019.

Please take a look at the list of nominations for each track and cast your vote today:
https://www.surveymonkey.com/r/CFFNA2019cochairs

Please vote for the person that you feel would represent our community's interest, for each of the tracks listed below.  We will share the list of co-chairs with the community once voting is complete.
 
Voting closes on Tuesday, November 13, 11:59pm PST.

Thank you,
Swarna.


Re: [CAUTION] Re: [cf-dev] BOSH PMC refactoring part 2 – moving CPIs out of incubation

Marco Voelz
 

Dear friends of BOSH,

 

As announced below: The four week grace period is over and we have removed cloudfoundry-incubator releases for the 5 CPIs below. They have been promoted out of the incubator to active projects.

 

If you want to continue to use them, just remove the "-incubator" from the name: see e.g. https://bosh.io/releases/github.com/cloudfoundry/bosh-openstack-cpi-release?all=1

 

Warm regards

Marco

 

 

From: <cf-dev@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Tuesday, 2. October 2018 at 17:04
To: "cf-dev@..." <cf-dev@...>, "cf-bosh@..." <cf-bosh@...>
Subject: [CAUTION] Re: [cf-dev] BOSH PMC refactoring part 2 – moving CPIs out of incubation

 

Der friends of BOSH,

 

We have moved the below CPIs from the cloudfoundry-incubator to the cloudfoundry github organization. The new releases will soon arrive on bosh.io after adapting its configuration [1].

 

For now, bosh.io/releases will still contain both, the releases for cloudfoundry-incubator as well as the releases in cloudfoundry. After a grace period of four weeks, ending November 1st, we will remove the cloudfoundry-incubator based releases from the bosh.io/releases listing for those CPIs [2]. Until then, please adapt any references to bosh.io/releases for the 5 CPIs below.

 

Reach out to me directly or reply to this mail if you have any comments or this grace period won't work for you.

 

Warm regards

Marco

 

[1] https://github.com/bosh-io/releases/pull/58

[2] https://github.com/bosh-io/releases/pull/59

 

From: <cf-dev@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Thursday, 23. August 2018 at 11:17
To: "cf-bosh@..." <cf-bosh@...>
Cc: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Subject: [CAUTION] [cf-dev] BOSH PMC refactoring part 2 – moving CPIs out of incubation

 

Dear friends of BOSH,

 

The BOSH project management committee (PMC) proposes to promote the most mature and widely used CPIs from incubation to full project status. Specifically, we want to promote these CPIs

  • AWS CPI [1]
  • OpenStack CPI [2]
  • VSphere CPI [3]
  • Google CPI [4]
  • Azure CPI [5]

 

Promoting the projects has some impact on their users, depending on how you consume the CPIs

  • We will move the repositories from the cloudfoundry-incubator to the cloudfoundry organization in github. Github takes care of redirecting from the old repository location to the new one, so all links and references to the old repositories should still work. 
  • References on bosh.io currently include the github organization name [6]. In the past, there have been issues with people consuming outdated releases from bosh.io after they had been renamed or moved – we might need a similar mechanism of redirecting that github provides to avoid that.

 

Please reach out to by replying to this mail or contacting me personally if you have questions, concerns, or comments.

 

Warm regards

Marco

 

PS: cross-posted on cf-developers for greater reach and potential experiences about previous promotions from incubator to full project.

 

 


CF CAB call for November is next Wednesday November 14 @ 8a PST

Michael Maximilien
 

Hi, all,

Quick reminder that the CAB call for November is next week Wednesday November 14th @ 8a PST.

We will have our regular PMCs highlights and two talks. One confirmed, so if you have one to give or to nominate then contact me directly ASAP.

The confirmed talk is a really good one. Saw it during Basel Summit. Don’t want to miss it:

1. Performance of a VM vs Containerized Cloud Foundry by Jeff Hobbs and Vlad Iovanov of SUSE [Vlad presenting]

2. TBD — send me nominations if you have

All other info in agenda here [0].

Zoom soon. Best,



Re: bosh upload stemcell

Yitao Jiang
 

OpenStack networking is quite complicated,  paste your networking topology and security groups may help for diagnostics.

On Sat, Nov 3, 2018 at 3:17 PM Russell Blue via Lists.Cloudfoundry.Org <bluerussell20=yahoo.com@...> wrote:
Hi

I create bosh on openstack (Pike). I can ssh and login on bosh-env. But I cant upload stemcell on bosh. It get error timeout.
Please help me.

Best regards,





--

Regards,

Yi Tao