Date   
Re: cf-deployment 3.0

Marco Voelz
 

Dear Josh, dear David,


Thanks David for sharing your past experiences in the RelInt team. I can sympathize with the stories you shared and understand the motivation for the planned changes better.


Now that cf-deployment 3.0 is there, let me tell you "how it went": It now means you have to switch to bosh-dns to receive security updates.


There is a number of reasons why we didn't introduce bosh-dns yet in our production system:

  • This ~200 lines of .yml just for aliasing DNS names [1], as the story making this obsolete isn't done yet [2]
  • This needs to be replicated e.g. in the ops-file to rename the network [3] which makes it even more terrible to maintain
  • There were open issues [4] that are important for larger-scale deployments. I give you that this is fixed now with dns-release 1.8.0 – but this came after you released cf-deployment 3.0
  • Parts of the above issue try a fix by introducing an experimental flag to get feedback from teams. Given this actually *is* an issue, I'd want to wait what comes out of this.
  • Other teams are still surprised from time to time by bosh-dns behavior and are looking into whether this might have implications they need to deal with [5]

Moreover, I think although everyone knew that bosh-dns was going to be a requirement at some point in time, the fact that this would be 3.0 was poorly communicated (I might have missed a mail there, but I cannot remember this. I would have raised my concerns earlier if that would have been the case).

For our production environment, we now have a few choices, all of them bring me headaches:
  • adopt bosh-dns *right now* although we don't feel good about it, 
  • try to bring back consul for a while (not even sure that's possible) and otherwise follow cf-deployment 3.0
  • backport security fixes only to a cf-deployment 2.x based production env

All of this brings me back to: As someone responsible for a cf-deployment production environment, I find it incredibly difficult having to deal with breaking changes like this on a regular basis to get security fixes. 

Warm regards
Marco




From: cf-dev@... <cf-dev@...> on behalf of Josh Collins <jcollins@...>
Sent: Wednesday, July 18, 2018 11:54:06 PM
To: cf-dev@...
Subject: Re: [cf-dev] cf-deployment 3.0
 

Thanks Geoff, Marco, Chip, Jesse, Bernd, and David for sharing your feedback and thoughts. You’ve expressed valid concerns and provided valuable context that I take to heart. I really appreciate the time and effort required for meaningful dialogue about the impacts of the proposed release cadence.


While the RelInt team's primary goal remains supporting the CF Foundation engineering teams and their ability to validate their commits in CI, your points underscore a tension we’re acutely aware of.


We’re trying to meet the needs of both the CFF Contributor and Operator and the ‘trick’ is to find a sustainable balance between the two. However, on occasions where we must prioritize one over the other we’re going to favor the CFF Contributor.  


I mentioned this earlier, but it’s worth restating that the RelInt team doesn’t have any plans provide LTS support and as Chip and Jesse pointed out that has traditionally been a value-added service provided by commercial vendors.  


In the spirit of iteration, I’d like to propose we proceed with the release cadence I originally outlined and see how it goes.


Again, thank you for providing such valuable feedback.


Cheers,


Josh Collins

_Current_ PM of CF Release Integration

Re: Deprecate route-sync from CFCR to CFAR

Guillaume Berche
 

Hi Oleksandr and Shannon,

I wonder what's the current plan for routing to CFCR workloads from CFAR ? Is there a concensus towards the proposed usage of TCP router [1] with an associated CloudFoundryRouteController component, or rather leverage K8S cloud providers ?

Which team would be working on this as I could not yet find related stories in the routing/tcp-routing/kubo pivotal trackers [2][3][4]

Thanks in advance,

Guillaume.


On Mon, Jul 16, 2018 at 12:57 PM, Oleksandr Slynko <oslynko@...> wrote:
Hi Arghya,

You have mentioned in Github that you were able to overcome this issue.

For everyone else, here is the context and a bit more information.

History
In very early CFCR days, we did not support cloud provider and basically could not give access to the applications and API outside of the cluster. We had HA Proxies to give access to workloads and API.  At that point, several early adopters told us that they would like to try exposing routes in more dynamic way a-la CFAR and possibly reuse existing routing layer. The main point was that we would like to provision multiple clusters with ease and without changed to Cloud Config.
As result we created a route-sync. 

What is does
It solves two problems:
- have stable and known URL for the API, so we can use to sign the certificate
- have a way to expose applications

How we solve it now
For API, we suggest people to wire their load balancers directly and then add the URL to the manifest. For example, check how BBL does it https://github.com/cloudfoundry/bosh-bootloader/tree/master/plan-patches/cfcr-gcp

Are we diverging further from CFAR?
Yes, CFCR team is moving further to the "vanilla" Kubernetes. But we expect other team to provide solutions for both worlds. We don't have enough deep knowledge of CFAR components and getting this knowledge will slow us down in improving Kubernetes experience. 

We are ready to help anyone to understand Kubernetes more and provide better experience with both runtimes.

Sincerely,
Oleksandr


Re: cf-acceptance-tests moving to development/master --> PR into develop please :)

Iryna Shustava
 

Hey all,

We just created develop and RC branches in the CATs repository. Please make all pull requests on develop going forward. Thanks!

Sebastian Vidrio & Iryna Shustava
CF Release Integration Team


On Fri, Jul 27, 2018 at 1:14 PM Josh Collins <jcollins@...> wrote:
Hello (again) My Cloud Foundrians,

Some changes are coming soon that are likely to impact you and I wanted to give you a heads up in advance...

RelInt has kicked off a tract of work to improve the acceptance test suite that's run by (hopefully) all component teams before they cut releases for integration to cf-deployment.

Cf-acceptance-tests a.k.a. CATs are going to get a iterative makeover.

CATs changes are likely to be released in fits and starts because of the RelInt team's distributed focus across marshalling PR's from component teams and continual fixing of broken builds as changes come into our pipelines, but please know we are focusing a portion of our attention on CATs because we care.

Making irregular, and possibly dramatic, changes to the CATs suite could have negative impacts for all of us, so before we really get into things we're making some changes:
  1. We're going to move to a develop/master split.
  2. We'll validate changes to CATs in CI (against the latest cf-deployment release).
  3. We'll apply semantic versioning practices to our releases.
We're just about to make the switch over to develop/master so I wanted to give you a heads up so you'll know to submit PR's to the develop branch soon rather than master.

************************************
We'll focus initially on making improvements aimed at:
  1. reducing false negatives (flakes)
  2. increasing the ease and efficiency of failure diagnosis
Subsequent improvement steps will be based on learnings from executing on the above and talking to CATs consumers, like you.
***********************************

I'll send another note when we've officially made the switch to develop. 'Till then, keep submitting PRs to master.

If you have any questions, concerns, or suggestions related to CATs, please don't hesitate to reach out to @jcollins or @relint-team ion the cats-users slack.

We're always interested in what you have to say.

Thanks very much!

Josh Collins
PM - Release Integration
--
Josh Collins
PM - CF R&D Release Integration

Headless browser support in nodejs-buildpack

Pietsch, Mathias (Allianz Deutschland, externer Mitarbeiter) <EXTERN.PIETSCH_MATHIAS@...>
 

Hello Cloudfoundry-Support team,

 

in our project we have the following issue:

 

we would like to generate a PDF-File with screenshots of our angular-html application. Therefore we need a buildpack with a headless browser support.

 

We already tried to generate screenshots with headless-chrome and phantomjs with the standard nodejs-buildpack. For  the headless-chrome we received an error-message that the shared library libnss3.so is missing. The phantomjs process terminated immediately.

 

Do you have a solution for us to solve our problem? This would be very helpful for finishing our project.

 

Thank in advance and best regards.

 

Mathias Pietsch

 

dienstleistend für Allianz Deutschland AG, Grafische Oberflächen für ROPO

Externer Brückenkopf: Darko Pelikan

 

Erreichbarkeit während des Projekts:

   Telefon:             +49 (0) 711 6 63 - 1537

   E-Mail:                EXTERN.PIETSCH_MATHIAS@...

 

------------------------------------------------------------------

 

Telefon: +49 (0) 711 6 63 - 1537

E-Mail: Mathias.Pietsch@...

 

PASS Consulting Group

Schwalbenrainweg 24

D-63741 Aschaffenburg

 

PASS IT-Consulting Dipl.-Inf. G. Rienecker GmbH & Co. KG, Handelsregister: Amtsgericht Aschaffenburg HRA 2921, Sitz der Gesellschaft: Aschaffenburg, Komplementärin: Rienecker Beteiligungs-GmbH, Handelsregister: Amtsgericht Aschaffenburg HRB 7619, Sitz der Gesellschaft: Aschaffenburg, Geschäftsführer: Dipl. Inf. Gerhard Rienecker

 

Add support for multiple Credhubs to CF/Diego

Matthias.Winzeler@...
 

Hi all

 

Currently, the CF ecosystem supports two deployment architectures of Credhub (https://docs.cloudfoundry.org/credhub/#deployment-architecture ):

  • Colocated with BOSH, used for the secrets of the BOSH director
  • Deployed standalone as its own deployment (“Runtime Credhub”), used for the secrets of service brokers, supported by CF for https://github.com/cloudfoundry-incubator/credhub/blob/master/docs/secure-service-credentials.md to interpolate creds.
    Currently, Diego only supports one credhub endpoint for the Runtime Credhub (which is injected via CloudController in the VCAP_PLATFORM_OPTIONS env var). It does not support multiple Credhubs.

 

However, we have two use cases that would profit if we could add support for CF/Diego so that it can interpolate credentials also from a different credhub url, which could for example be passed as part of the service binding/VCAP_SERVICES.

  • Use case 1: Service brokers running outside of CF:
    Since we use our Service brokers also for other platforms than CF (namely k8s and our IaaS offerings), the service brokers run outside of CF. Thus, they do not use CF’s Runtime Credhub but a dedicated one (since we still want to store the creds securely).
    Thus, CF can’t interpolate the credentials because it can only do this for the Runtime Credhub. If we could pass the SB’s credhub URL as part of the service binding, CF could interpolate the credentials from the 3rd party SB’s credhub.
  • Use case 2: Credhub as a Service: Some customers are asking for a dedicated Credhub instance, since Credhub currently does not offer strong multi-tenancy. So we plan to deploy dedicated Credhubs as a service (pushed as an App to CF).
    CF can also not interpolate the credentials, since it can only do this for the Runtime Credhub – and we could solve that by passing the Credhub URL as part of the service binding, as above.
    We’re aware that Credhub will eventually get stronger multi-tenancy, so Use case 2 might be solved with a shared Credhub (i.e. the Runtime Credhub). However, the need for multiple Credhubs remains with Use case 1.

 

I already reached out on the #credhub Slack (https://cloudfoundry.slack.com/archives/C3EN0BFC0/p1531942967000203) and on the Diego repo (https://github.com/cloudfoundry/diego-release/issues/401).

However, I was told to reach out on a more generic channel since this is a cross-cutting concern.

 

What do you think? Is multiple Credhub something that CF could profit in the future? If yes, we’re happy to provide a PR (see implementation suggestions in the Diego issue).

CCed Erich as the PM of Diego.

 

Best regards

Matthias

 

Matthias Winzeler

Application Cloud

https://developer.swisscom.com 

___________________________________________________________________________
Mobile  +41 79 664 96 16

matthias.winzeler@...
___________________________________________________________________________
Swisscom (Switzerland) Ltd

Write custom MFA connector/provider

Rashmi Singh <singhrasster@...>
 

Hello,
I was looking at the MFA Providers and it looks like currently only Google authenticator is supported. I need an MFA support but not Google authenticator. Is it possible to write a custom authenticator /MFA connector on UAA that we can then integrate with our TokenValidator? We have our own Authentication server that supports different types of authentication like OTP, grid based, etc and we would like to integrate UAA with that. What would be preferred is that we do the normal username/password authentication on UAA and then for the second factor, instead of using Google Authenticator, we have our custom provider/connector that we can integrate with our token validator/server for authentication. Is it possible to make changes in the UAA code and write a provider to achieve this?

Re: Write custom MFA connector/provider

Sree Tummidi
 

Hi Rashmi,

We only have support for google authenticator at this time. The best way to integrate an existing MFA to UAA is through federation like SAML/OIDC. In this case the entire auth flow is delegated to the external provider.


Thanks,
Sree Tummidi
Sr. Manager, Product Management
Pivotal Cloud Foundry


On Thu, Jul 26, 2018 at 1:44 PM, Rashmi Singh <singhrasster@...> wrote:
Hello,
I was looking at the MFA Providers and it looks like currently only Google authenticator is supported. I need an MFA support but not Google authenticator. Is it possible to write a custom authenticator /MFA connector on UAA that we can then integrate with our TokenValidator? We have our own Authentication server that supports different types of authentication like OTP, grid based, etc and we would like to integrate UAA with that. What would be preferred is that we do the normal username/password authentication on UAA and then for the second factor, instead of using Google Authenticator, we have our custom provider/connector that we can integrate with our token validator/server for authentication. Is it possible to make changes in the UAA code and write a provider to achieve this?


Re: Headless browser support in nodejs-buildpack

Franks, Geoff
 

We had to solve a similar problem ourselves. We ended up building a custom stack for this, forking cflinuxfs2, and adding the additional packages + business logic on top. There are a number of buildpacks that may have issues with stacks not named `cflinuxfs2`, but the only buildpack we needed seemed to work with the custom name, so we have a default stack, and a custom stack for the apps that neeed Chrome. If you can support multi-buildpack pushes with the v3 API, you may be able to make use of that with https://github.com/cloudfoundry/apt-buildpack which would be less long-term maintenance + support compared to forking things.

 

From: <cf-dev@...> on behalf of "Pietsch, Mathias (Allianz Deutschland, externer Mitarbeiter)" <EXTERN.PIETSCH_MATHIAS@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Monday, July 23, 2018 at 10:25 AM
To: "cf-dev@..." <cf-dev@...>
Cc: "Pfaffel, Stefan (Allianz Deutschland)" <STEFAN.PFAFFEL@...>, "Hofbauer, Eveline (Allianz Deutschland)" <EVELINE.HOFBAUER@...>
Subject: [External] [cf-dev] Headless browser support in nodejs-buildpack

 

Hello Cloudfoundry-Support team,

 

in our project we have the following issue:

 

we would like to generate a PDF-File with screenshots of our angular-html application. Therefore we need a buildpack with a headless browser support.

 

We already tried to generate screenshots with headless-chrome and phantomjs with the standard nodejs-buildpack. For  the headless-chrome we received an error-message that the shared library libnss3.so is missing. The phantomjs process terminated immediately.

 

Do you have a solution for us to solve our problem? This would be very helpful for finishing our project.

 

Thank in advance and best regards.

 

Mathias Pietsch

 

dienstleistend für Allianz Deutschland AG, Grafische Oberflächen für ROPO

Externer Brückenkopf: Darko Pelikan

 

Erreichbarkeit während des Projekts:

   Telefon:             +49 (0) 711 6 63 - 1537

   E-Mail:                EXTERN.PIETSCH_MATHIAS@...

 

------------------------------------------------------------------

 

Telefon: +49 (0) 711 6 63 - 1537

E-Mail: Mathias.Pietsch@...

 

PASS Consulting Group

Schwalbenrainweg 24

D-63741 Aschaffenburg

 

PASS IT-Consulting Dipl.-Inf. G. Rienecker GmbH & Co. KG, Handelsregister: Amtsgericht Aschaffenburg HRA 2921, Sitz der Gesellschaft: Aschaffenburg, Komplementärin: Rienecker Beteiligungs-GmbH, Handelsregister: Amtsgericht Aschaffenburg HRB 7619, Sitz der Gesellschaft: Aschaffenburg, Geschäftsführer: Dipl. Inf. Gerhard Rienecker

 

bosh and cf ssl cert update question

강경원 <kyungwon.kang@...>
 

Hello.

 

I created CERTS file with bosh-cli with var-store. By default, ssl will be expired after 1 year from generated day. Is there a best way to update ssl at bosh and cf?

 

 

Missing az_attr claim in access_token of password grant

Paul Bakare
 

Hi,

An access_token gotten from password grant doesn't contain az_attr when decoded [1]. Is this by design? Is there something I'm doing wrongly?

How do I access an access_token additional information (az_attr) when decoded?

Kindly advise.

Many thanks



--
Odeyemi 'Kayode O.
http://ng.linkedin.com/in/kayodeodeyemi. t: @charyorde

routing-release 0.180.0

Shubha Anjur Tupil
 

Hi, 

We released routing-release 0.180.0 today. 

  • Operator can see a log message that indicates the number of tries when the Gorouter fails to connect to a backend in the gorouter.log details
  • Golang has been updated to 1.10.3 for all routing components details here and here
  • Release author can now specify an IP for the route-registrar using the job spec. If a host is not found in the job spec it will default to the IP of the VM the route-registrar is running on details

Using BPM for routing components

  • We are now using BPM for gorouter details
  • We are now using BPM for routing-api details
  • We are now using BPM for route_registrar details

Fixed Issues:

  • Fixed a issue where query parameters were not sent to the application when preceded by a //anywhere in the URL. Now when the request URL includes a //, the query parameters are sent to the application by the Gorouter details
  • Fixed an issue with symlinks to enable bosh-cli v5.x to work with routing-release details
  • PID files are being deleted when the Gorouter stops details

Regards, 
Shubha

Version of UAA to upgrade to from version 4.11.0

brian.sung@...
 

Hi, we are currently using version UAA 4.11.0 and like to update to a more recent version. 

Looking at the Github repo, the latest release is 4.12.4, and I think this is what I should aim for.

But I also see 4.13.4, 4.14.0, and 4.19.2 releases.  Are these releases of feature branches under development?  Should I consider upgrading to one of these?

Regards,
Brian

Re: Version of UAA to upgrade to from version 4.11.0

Sree Tummidi
 

Please update to the latest line which is 4.19.2

Thanks,
Sree Tummidi
Sr. Manager, Product Management
Pivotal Cloud Foundry


On Tue, Aug 7, 2018 at 9:02 AM, <brian.sung@...> wrote:
Hi, we are currently using version UAA 4.11.0 and like to update to a more recent version. 

Looking at the Github repo, the latest release is 4.12.4, and I think this is what I should aim for.

But I also see 4.13.4, 4.14.0, and 4.19.2 releases.  Are these releases of feature branches under development?  Should I consider upgrading to one of these?

Regards,
Brian


Re: routing-release 0.180.0

Shubha Anjur Tupil
 

I wanted to add a note to clarify now that some routing components use bpm. 

BPM needs to be colocated on the VM for the components that are using BPM (gorouter, routeing-api and route-registrar). If you are using cf-deployment, BPM is already colocated on the bosh deployed VMs, but if you are not using cf-deployment you would have to colocate the BPM job on the component VMs for gorouter, routing-api and route-registrar.

Regards, 
Shubha

On Mon, Aug 6, 2018 at 4:08 PM, Shubha Anjur Tupil <sanjurtupil@...> wrote:
Hi, 

We released routing-release 0.180.0 today. 

  • Operator can see a log message that indicates the number of tries when the Gorouter fails to connect to a backend in the gorouter.log details
  • Golang has been updated to 1.10.3 for all routing components details here and here
  • Release author can now specify an IP for the route-registrar using the job spec. If a host is not found in the job spec it will default to the IP of the VM the route-registrar is running on details

Using BPM for routing components

  • We are now using BPM for gorouter details
  • We are now using BPM for routing-api details
  • We are now using BPM for route_registrar details

Fixed Issues:

  • Fixed a issue where query parameters were not sent to the application when preceded by a //anywhere in the URL. Now when the request URL includes a //, the query parameters are sent to the application by the Gorouter details
  • Fixed an issue with symlinks to enable bosh-cli v5.x to work with routing-release details
  • PID files are being deleted when the Gorouter stops details

Regards, 
Shubha


CAB call for August is Wednesday 08/15 @ 8a PST or 11a EST

Michael Maximilien
 

FYI..,


Please remember to book your calendar to join the Zoom call [0] Wednesday August 15th at 8a Pacific for QAs, PMC highlights, and community presentations.


If you have a presentation about an OSS project related to CF or an update on a current project then please contact me ASAP. Reply direct to me or Slack.


Zoom soon. Best,



CF CLI v6.38.0 Released Today

Abby Chau
 

Hey everyone,

The CF CLI team released cf CLI v6.38.0 today; please see release notes for full details. Highlights include: 

Changes to the `cf app app-name` Display
  • In late June, we sent out a survey (thank you to all who responded) to ask the community their opinion on changing the `cf app app-name` display.  Buoyed by your feedback, we decided to move forward with changing the `cf app` display such that it is backed by the v3 app api endpoint. Users on cc api 3.27 or higher will see the new app display.  

Multiple Buildpacks Support
  • Previously, pushing with multiple buildpacks, required you to use a combination of "v2" and "v3" commands. Now, if you are using CC API `3.25` or above, you can push with multiple buildpacks by either passing in multiple `-b` flags, or use the new `buildpacks` field in the manifest. 

Invocation Timeout Configuration
  • App devs on cc api `3.43.0` or higher can now use `v3-set-health-check` to set per invocation timeouts for http and port health checks  for individual health checks. 

Upgraded to Golang 1.10.3
  • This release bumps the CLI to use Golang `1.10.3`. 

Support for SOCKS5
  • We added SOCKS5 support for `cf v3-ssh` 

Other Enhancements
  • `v3-ssh` process type now defaults to `web` 
  • Support added for setting tags for user provided service instances 
  • Now a warning appears if you attempt to use deprecated properties and variable substitution 
  • Updated usage so now you can rename the `cf` binary use it with every command 
  • `cf events` now displays the Diego `cell_id` and `instance` guid in crash events 
  • Includes `cf service service-instance` table display improvements wherein the service instance information is now grouped separately from the binding information
  • `cf service service-instance` table display information for user provided services changed: `status` has been added to the table 
New Translations
  • New translations are included in this release. Big thanks to IBM who contributed updated translations of CLI output and help text. As the update came in mid-release and a number of message strings changed since, you may find some untranslated messages (in particular in the help pages).

Bug Fixes
  • the CLI now properly handles escaped commas in the `X-Cf-Warnings` header

Deprecations
  • the `buildpack` field in the manifest has been deprecated in favour of `buildpacks`.

Contributors:  An Yu, Sebastian Vidrio, Anande Gaitonde, Thomas Viehman, Alex Zhao, Abby Chau, Spencer Hawley, Renee Chu, Nick Guerette

Special Guests: Dies Koper (for helping us test SOCK5 support), SAPI London team (for tags support for user provided services and help updating the `cf service service-instance` table),  Dr. Max and the IBM team (for translation updates). 

Best,

Abby and the CLI team




Stratos User Survey

Richard Cox
 

Hi All!

The team here in Stratos have created a quick survey for users of, or people who would consider using, Stratos.

In case you're unfamiliar with Stratos, it's an Open Source Web-based UI (Console) for managing Cloud Foundry. For information, screen shots, deployment methods and more please pop over to https://github.com/cloudfoundry-incubator/stratos. If there are any more immediate questions please feel free to ask in our cf slack channel #stratos (https://cloudfoundry.slack.com/messages/C80EP4Y57/).

We can't promise t-shirts or Amazon vouchers for those who complete the survey, but can promise it will help shape the future of the project.

Survey Link - https://www.surveymonkey.com/r/2L8XWST

Thanks!

Richard

on behalf of the Stratos Team

Re: [cf-bosh] Incubation proposal: CF Containerization

Marco Voelz
 

Hi everyone,


Thanks for the comments, discussions and suggestions everyone! The deadline for raising major concerns before we go on with the usual incubation process ended on August 10th. I don't see any ongoing discussions that would prevent us moving forward, so I'll call for a vote within the PMC and we will then proceed.


Warm regards

Marco



From: cf-bosh@... <cf-bosh@...> on behalf of Dmitriy Kalinin <dkalinin@...>
Sent: Friday, July 13, 2018 12:02:27 AM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization
 
Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.

On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher <cschum@...> wrote:
Hi all,

We would like to propose the CF Containerization effort for incubation in the
BOSH PMC.

The full proposal can be found here:
https://docs.google.com/document/d/1_IvFf-cCR4_Hxg-L7Z_R51EKhZfBqlprrs5NgC2iO2w/edit

As a first step towards this, we are proposing the Fissile code base as a
starting point, with the goal of transforming it in the direction of the above
proposal. Fissile is a tool that allows developers to convert existing BOSH
releases to docker images and deploy them to Kubernetes. Fissile is currently
used in SUSE CAP (https://www.suse.com/products/cloud-application-platform)
and IBM Cloud Foundry Enterprise Environment (https://console.bluemix.net/
docs/cloud-foundry/
).

Fissile is fully open  source and can currently be found on GitHub at
https://github.com/SUSE/fissile

The project would follow a distributed committer model.

Project Lead: Vlad Iovanov
Initial Committers:
- Jan Dubois (SUSE)
- Mark Yen (SUSE)
- Mario Manno (SUSE)
- Enrique Encalada (IBM)
- Matthias Diester (IBM)
- Gong (Grace) Zhang (IBM)

SAP is also currently evaluating additional staffing.

We are looking forward to your questions and comments.

Best Regards,
Cornelius

--
Cornelius Schumacher <cschum@...>




REMINDER: CAB call for August is Wednesday 08/15 @ 8a PST or 11a EST + TALKS AGENDA

Michael Maximilien
 

Quick reminder for the call on Wednesday and announcing two talks:
 
1. Using Istio Pilot and Envoy for Edge Routing in Cloud Foundry [1] by Shubha Anjur Tupil of Pivotal
2. Update on Project Eirini: Kubernetes backend for Cloud Foundry [2] by Julian Friedman of IBM
 
Full agenda and Zoom details in [0]. Zoom soon. Best,
 
------
dr.max
ibm ☁ 
silicon valley, ca
maximilien.org
 
 

----- Original message -----
From: Michael Maximilien/Almaden/IBM
To: cf-dev@...
Cc:
Subject: CAB call for August is Wednesday 08/15 @ 8a PST or 11a EST
Date: Wed, Aug 8, 2018 8:04 AM
 
 

FYI..,

 

Please remember to book your calendar to join the Zoom call [0] Wednesday August 15th at 8a Pacific for QAs, PMC highlights, and community presentations.

 

If you have a presentation about an OSS project related to CF or an update on a current project then please contact me ASAP. Reply direct to me or Slack.

 

Zoom soon. Best,

 
 
 

Re: [cf-bosh] Incubation proposal: CF Containerization

Marco Voelz
 

Hi everyone,


The BOSH PMC voted unanimously in favor of incubating the CF Containerization project. Welcome to Vlad and the team!


Warm regards

Marco




From: Voelz, Marco
Sent: Monday, August 13, 2018 1:52 PM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization
 

Hi everyone,


Thanks for the comments, discussions and suggestions everyone! The deadline for raising major concerns before we go on with the usual incubation process ended on August 10th. I don't see any ongoing discussions that would prevent us moving forward, so I'll call for a vote within the PMC and we will then proceed.


Warm regards

Marco



From: cf-bosh@... <cf-bosh@...> on behalf of Dmitriy Kalinin <dkalinin@...>
Sent: Friday, July 13, 2018 12:02:27 AM
To: CF BOSH Mailing List
Cc: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-bosh] Incubation proposal: CF Containerization
 
Thank you for submitting this proposal. Let's shoot for collecting and resolving most of the comments in the next month by Aug 10th and voting at that time to incubate it in BOSH PMC.

On Tue, Jul 3, 2018 at 2:25 AM, Cornelius Schumacher <cschum@...> wrote:
Hi all,

We would like to propose the CF Containerization effort for incubation in the
BOSH PMC.

The full proposal can be found here:
https://docs.google.com/document/d/1_IvFf-cCR4_Hxg-L7Z_R51EKhZfBqlprrs5NgC2iO2w/edit

As a first step towards this, we are proposing the Fissile code base as a
starting point, with the goal of transforming it in the direction of the above
proposal. Fissile is a tool that allows developers to convert existing BOSH
releases to docker images and deploy them to Kubernetes. Fissile is currently
used in SUSE CAP (https://www.suse.com/products/cloud-application-platform)
and IBM Cloud Foundry Enterprise Environment (https://console.bluemix.net/
docs/cloud-foundry/
).

Fissile is fully open  source and can currently be found on GitHub at
https://github.com/SUSE/fissile

The project would follow a distributed committer model.

Project Lead: Vlad Iovanov
Initial Committers:
- Jan Dubois (SUSE)
- Mark Yen (SUSE)
- Mario Manno (SUSE)
- Enrique Encalada (IBM)
- Matthias Diester (IBM)
- Gong (Grace) Zhang (IBM)

SAP is also currently evaluating additional staffing.

We are looking forward to your questions and comments.

Best Regards,
Cornelius

--
Cornelius Schumacher <cschum@...>