Date   

Membership Github cloudfoundry-community

Andy Lo A Foe
 

Hi all,

I'm a co-maintainer of the cloudfoundry-community/terraform-provider-cloudfoundry project located here:


A new release was created a few weeks ago but this requires some manual action on the https://registry.terraform.io website. AFAIK one needs to be a member of the cloudfoundry-community to perform this.

Hereby requesting membership for the cloudfoundry-community. My Github handle is 'loafoe'. Can anyone help with this?

Thanks,
Andy


Foundational Infrastructure Working Group is live!

Ruben Koster (VMware)
 

Hello community,

 

This message marks the official start of the Foundational Infrastructure Working Group. Below are a few links to common resources y’all might find useful:

  • Our weekly Office hours call, where we discuss PRs which are stuck in the review process and any other business. Meeting notes are kept here.
  • The Github project board per working group area:

 

The formation of the working groups is still being actively worked on. For ideas or general feedback, feel free to drop by during the office hours call, or leave a response below.

 

Best regards,

 

Ruben Koster (VMware) & Beyhan Veli (SAP)


Live Stream on 21 Oct

Ram Iyengar
 

Dear Cloud Foundry community,

Just a reminder that the last in the series of live streams with the TOC members is happening tomorrow, 21st October 2021. It is scheduled for 9AM Pacific time/Noon Eastern. 

David Stevenson from VMware will be the guest. It would be great to have you join live on the YouTube link given below. If you have any questions about Cloud Foundry, please ask them during the live stream and we will be happy to get you the answers! 

Look forward to seeing you all there! 

Cheers,
Ram Iyengar

https://youtu.be/e3Jg412d72k


CAB Call on Oct 14th

Ram Iyengar
 

Folks,

A quick reminder about the CF CAB call - The Cloud Foundry CAB calls are a great opportunity to join an active dialogue and find out about the latest news and updates from the various Cloud Foundry projects.

As you're aware, we recently moved to a new governance model. The upcoming CAB call is the first time we're going to introduce some portions of the new Working Groups, structure, status updates, etc. It would be great to have an active participation. Airing questions during the call, feedback about ongoing efforts, and healthy debates are most welcome.

In addition to the updates about the project governance, we're also having a demo of Cloud Foundry Sidecars by Peter Wagner from datev.de.

Date: 14th Oct 2021
Time: 5PM CEST/11 AM ET/8AM PT

Note: The invite for the CAB call is always available on the Cloud Foundry Community Calendar.

Regards,
Ram


Maintainers sought for KubeCF and Project Quarks

Chris Clark
 

Hi all, 

We've got two projects that no longer have active maintainers. Are there any companies or individuals out there that would like to pick up maintenance of the KubCF project and/or Project Quarks?  

The primary repositories are: 
https://github.com/cloudfoundry-incubator/kubecf

If we don't find maintainers for these, we'll want to archive these repositories soon, as we don't want folks putting in Issues and Pull Requests that won't be responded to. 

--
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation


Re: SIG Meeting: Cloud Foundry for Kubernetes updates

Krannich, Bernd
 

Hi Andrew,

 

Thank you very much for volunteering to take over the SIG call and broadening it according to the new working group setup – highly appreciated!

 

Regards,

Bernd

 

Bernd Krannich

SAP Technology & Innovation

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

 

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

 

From: cf-dev@... <cf-dev@...> on behalf of Andrew Wittrock <awittrock@...>
Date: Tuesday, 5. October 2021 at 02:17
To: cf-dev@... <cf-dev@...>
Subject: [cf-dev] SIG Meeting: Cloud Foundry for Kubernetes updates

Hello everyone! I’m sharing some news regarding the SIG Meeting: Cloud Foundry for Kubernetes. First of all, a huge thanks to Bernd Krannich, who has been running the meetings. He expressed interest in having someone carry the torch forward, and I have volunteered to do so. Starting tomorrow, October 5, 2021, I’ll be leading the meetings in that time slot.

 

Additionally, we have some changes in format. I’d like to expand the meeting beyond a focus on the cf-for-k8s project to include all CF on Kubernetes projects. It would be great to have the people working in this space come together to ensure we can build useful products for each other. To that end, we are drafting a proposal for a new Working Group to oversee the development of the new cf-k8s API and controllers as the latest approach for a CF experience deeply integrated with Kubernetes. We envision that that group could even take over this meeting’s time slot for its periodic public discussion forum, should it be approved.

 

Please join us at one of the biweekly meetings! The floor is pretty much open, but we’ll be discussing the current nascent cf-k8s-api and cf-k8s-controllers projects as we build out a more Kubernetes-native CF experience.

 

- Andrew


SIG Meeting: Cloud Foundry for Kubernetes updates

Andrew Wittrock
 

Hello everyone! I’m sharing some news regarding the SIG Meeting: Cloud Foundry for Kubernetes. First of all, a huge thanks to Bernd Krannich, who has been running the meetings. He expressed interest in having someone carry the torch forward, and I have volunteered to do so. Starting tomorrow, October 5, 2021, I’ll be leading the meetings in that time slot.


Additionally, we have some changes in format. I’d like to expand the meeting beyond a focus on the cf-for-k8s project to include all CF on Kubernetes projects. It would be great to have the people working in this space come together to ensure we can build useful products for each other. To that end, we are drafting a proposal for a new Working Group to oversee the development of the new cf-k8s API and controllers as the latest approach for a CF experience deeply integrated with Kubernetes. We envision that that group could even take over this meeting’s time slot for its periodic public discussion forum, should it be approved.


Please join us at one of the biweekly meetings! The floor is pretty much open, but we’ll be discussing the current nascent cf-k8s-api and cf-k8s-controllers projects as we build out a more Kubernetes-native CF experience.


- Andrew


Proposal to adopt Ubuntu 22.04 as the next OS for CF #cf

David Stevenson
 

CF community -

I'm thinking a lot about the right way to get ahead of the upcoming expiration of Bionic in 2023. Unlike the Xenial=>Bionic stemcell work, this time the container rootfs and stemcell are both going to expire. Here is my proposal to skip Focal (20.04) and instead rapidly execute a transition to 22.04, starting next spring when it is available:
https://docs.google.com/document/d/1rh8Bb9Ac5k3UudtRJ3AhpCpfW0kkIKXVM-9Giyh4h_Q/edit#

Please comment on the document, or write back to this thread. If there's a lot of contention on the issue, I'll schedule a conversation where anyone can show up and discuss the right path forward.

Thank you, have a great weekend!
-David Stevenson
VMware Sr. Staff Technical Lead
CFF Technical Oversight Committee 


Live stream: The Past, Present, and Future Of Cloud Foundry Featuring Lee Porte

Ram Iyengar
 

Dear CF Community,

We have a live stream today featuring Lee Porte, the Chair of the Cloud Foundry Technical Oversight Committee. The conversation will center around updates from the work that the TOC have been putting in, what the roadmap is like for various projects, and Lee's general experience with Cloud Foundry.

You can view the stream live on YouTube or Twitter.

Should you have any questions that you would like to pose to Lee, make sure to drop them in the chat box of the live stream or tag us on Twitter.

Look forward to seeing you all there!

Cheers,
Ram Iyengar
Developer Advocate
Cloud Foundry Foundation


Live Stream 16th Sep: Eric Malm

Ram Iyengar
 

Dear Cloud Foundry community,

The Cloud Foundry Foundation is hosting a series of live streams with elected members of the Technical Oversight Committee. Tomorrow, we have Eric Malm join us for an hour-long chat. 

Date: 16th September 2021 (Thu)
Time: 10:00 am Pacific Time

You're welcome to participate in the conversation by posting your questions and comments on YouTube (live chat) or Twitter (live tweets). 

Help us spread the word! And also, see you tomorrow. 

Regards,
Ram Iyengar
Developer Advocate
Cloud Foundry Foundation


Re: Cloudfoundry deployment error on vanilla Openstack Wallaby cloud #cf

Chris L
 

I also found this issue open on the fog-openstack project…. I think this has been an issue for a bit…. Is there any way to get some traction there?  I can even take over but I would need to even reach someone who could pass the torch…

 

https://github.com/fog/fog-openstack/issues/346

 

From: cf-dev@... <cf-dev@...> on behalf of Chris L <chris@...>
Date: Friday, September 3, 2021 at 8:50 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Cloudfoundry deployment error on vanilla Openstack Wallaby cloud #cf

I was reading up on the neutron LBaaS deprecation and wondering if that is an issue here.  I thought the policy was to support the latest 3 openstack versions….  Could that be the issue? Cloudfoundry does not support Octavia and thus wouldent support anything after Queens?  I guess I could try deploying as Kubernetes…

 

From: cf-dev@... <cf-dev@...> on behalf of Conner UK, Jim via lists.cloudfoundry.org <jim.conner=fil.com@...>
Date: Friday, September 3, 2021 at 3:01 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Cloudfoundry deployment error on vanilla Openstack Wallaby cloud #cf

I don’t think the Octavia endpoints are the same as the old Neutron lbaas ones were.

 

:path          => "/v2.0/lbaas/pools"

''OpenStack API NotFound Expected(200) <=> Actual(404 Not Found)

 

The API docs for Octavia seem to indicate that the path would be /v2/lbaas (rather than /v2.0)

 

I’ve no idea how to fix the issue, but I think that explains why the error is happening.

 

Cheers,

 

Jim

 

 

From: <cf-dev@...> on behalf of Chris L <chris@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Thursday, 2 September 2021 at 14:40
To: "cf-dev@..." <cf-dev@...>
Subject: [cf-dev] Cloudfoundry deployment error on vanilla Openstack Wallaby cloud #cf

 

All,

I am receiving this error while attempting to deploy Cloudfoundry on a vanilla Openstack Wallaby cloud:

[2021-09-02T01:29:55.856730 #882] [task:40] DEBUG -- DirectorJobRunner: (0.001265s) (conn: 47027669444740) INSERT INTO "events" ("parent_id", "timestamp", "user", "action", "object_type", "object_name", "error", "task", "deployment", "instance", "context_json") VALUES (342, '2021-09-02 01:29:55.852077+0000', 'admin', 'update', 'deployment', 'cf', 'CPI error ''Bosh::Clouds::CloudError'' with message ''OpenStack API NotFound Expected(200) <=> Actual(404 Not Found)

excon.error.response

  :body          => "{\"NeutronError\": {\"type\": \"HTTPNotFound\", \"message\": \"The resource could not be found.\", \"detail\": \"\"}}"

  :cookies       => [

  ]

  :headers       => {

    "content-length"            => "103"

    "content-type"              => "application/json"

    "date"                      => "Thu, 02 Sep 2021 01:29:32 GMT"

    "strict-transport-security" => "max-age=31536000;"

    "x-openstack-request-id"    => "req-fbfa7aa1-1f13-46c6-8385-5f0fde847b08"

  }

  :host          => "openstack-external.lyonsgroup.family"

  :local_address => "10.0.1.6"

  :local_port    => 45952

  :path          => "/v2.0/lbaas/pools"

  :port          => 9696

  :reason_phrase => "Not Found"

  :remote_ip     => "174.54.141.197"

  :status        => 404

  :status_line   => "HTTP/1.1 404 Not Found\r\n"

.

Check task debug log for details.'' in ''create_vm'' CPI method (CPI request ID: ''cpi-184472'')', '40', 'cf', NULL, '{"before":{"releases":["loggregator-agent/6.3.3","metrics-discovery/3.0.6","bpm/1.1.13","bosh-dns-aliases/0.0.4","bosh-dns/1.29.0","binary-buildpack/1.0.39","capi/1.112.0","cf-networking/2.38.0","cf-smoke-tests/41.0.2","cflinuxfs3/0.251.0","credhub/2.9.0","diego/2.51.0","dotnet-core-buildpack/2.3.32","garden-runc/1.19.29","go-buildpack/1.9.34","java-buildpack/4.41","loggregator/106.6.0","nats/40","nginx-buildpack/1.1.30","r-buildpack/1.1.20","nodejs-buildpack/1.7.57","php-buildpack/4.4.44","pxc/0.37.0","python-buildpack/1.7.43","routing/0.221.0","ruby-buildpack/1.8.43","silk/2.38.0","staticfile-buildpack/1.5.24","statsd-injector/1.11.16","uaa/75.6.0","log-cache/2.11.1","cf-cli/1.32.0"],"stemcells":["bosh-openstack-kvm-ubuntu-xenial-go_agent-raw/621.125"]},"after":{"releases":["loggregator-agent/6.3.3","metrics-discovery/3.0.6","bpm/1.1.13","bosh-dns-aliases/0.0.4","bosh-dns/1.29.0","binary-buildpack/1.0.39","capi/1.112.0","cf-networking/2.38.0","cf-smoke-tests/41.0.2","cflinuxfs3/0.251.0","credhub/2.9.0","diego/2.51.0","dotnet-core-buildpack/2.3.32","garden-runc/1.19.29","go-buildpack/1.9.34","java-buildpack/4.41","loggregator/106.6.0","nats/40","nginx-buildpack/1.1.30","r-buildpack/1.1.20","nodejs-buildpack/1.7.57","php-buildpack/4.4.44","pxc/0.37.0","python-buildpack/1.7.43","routing/0.221.0","ruby-buildpack/1.8.43","silk/2.38.0","staticfile-buildpack/1.5.24","statsd-injector/1.11.16","uaa/75.6.0","log-cache/2.11.1","cf-cli/1.32.0"],"stemcells":["bosh-openstack-kvm-ubuntu-xenial-go_agent-raw/621.125"]}}') RETURNING *

I do have the Octavia project installed and a loadbalancer is created and running.  I use the terraform script here to prepare the Openstack cloud for cloudfoundry:

https://github.com/cloudfoundry-attic/bosh-openstack-environment-templates/cf-deploymnet-tf/cf.tf

This creates a loadbalancer, security groups, networks, etc.

It completes successfully and I do see the cf-lb loadbalancer created, running, in active state, and a whole lot of ports and pools that exist under it.  I then execute the BOSH deploy of cloudfoundry using this repo:

https://github.com/cloudfoundry/cf-deployment/cf-deployment.yml

My deployment line looks like this:

runuser -l stack -c  "cd /opt/stack; \
                  bbl print-env -s /opt/stack > /tmp/bbl_env.sh; \
                  chmod 700 /tmp/bbl_env.sh; \
                  source /tmp/bbl_env.sh; \
                  bosh -d cf deploy -o /tmp/cf-deployment/operations/use-external-blobstore.yml \
                  -o /tmp/cf-deployment/operations/use-swift-blobstore.yml \
                  -o /tmp/cf-deployment/operations/openstack.yml \
                  -o /tmp/cf-deployment/operations/scale-to-one-az.yml \
                  -o /tmp/cf-deployment/operations/use-compiled-releases.yml \
                  --vars-store /tmp/vars/deployment-vars.yml \
                  /tmp/cf-deployment/cf-deployment.yml \
                  -v system_domain=
$DOMAIN_NAME \
                  -v auth_url=https://
$EXTERNAL_VIP_DNS:5000/v3 \
                  -v openstack_project=cloudfoundry \
                  -v openstack_domain=default \
                  -v openstack_username=
$OPENSTACK_CLOUDFOUNDRY_USERNAME \
                  -v openstack_password=
$OPENSTACK_CLOUDFOUNDRY_PWD \
                  -v openstack_temp_url_key=
$SWIFT_KEY \
                  -v app_package_directory_key=app_package_directory \
                  -v buildpack_directory_key=buildpack_directory \
                  -v droplet_directory_key=droplet_directory \
                  -v resource_directory_key=resource_directory \
                  -n"


Is there anything anyone could see as to what would cause the error at the beginning of the post?  I can get any other logs that would help, I could grant access to the env, anything that would give anyone an idea.


The information transmitted is intended for the person or entity to which it is addressed and may contain confidential, privileged or copyrighted material. If you receive this in error, please contact the sender and delete the material from any computer. Any views or opinions expressed are those of the author and do not necessarily represent those of Fidelity International. All e-mails may be monitored. FIL Investments International (Reg. No.1448245), FIL Investment Services (UK) Limited (Reg. No. 2016555), FIL Pensions Management (Reg. No. 2015142), Financial Administration Services Limited (Reg. No. 1629709) and FIL Wealth Management Limited (Registered. No. 06121251) are authorised and regulated in the UK by the Financial Conduct Authority. FIL Life Insurance Limited (Reg No. 3406905) is authorised in the UK by the Prudential Regulation Authority and regulated in the UK by the Financial Conduct Authority and the Prudential Regulation Authority. Registered offices at Beech Gate, Millfield Lane, Lower Kingswood, Tadworth, Surrey KT20 6RP.


This email has been scanned by Inbound Shield™.

 


Re: Cloudfoundry deployment error on vanilla Openstack Wallaby cloud #cf

Chris L
 

I was reading up on the neutron LBaaS deprecation and wondering if that is an issue here.  I thought the policy was to support the latest 3 openstack versions….  Could that be the issue? Cloudfoundry does not support Octavia and thus wouldent support anything after Queens?  I guess I could try deploying as Kubernetes…

 

From: cf-dev@... <cf-dev@...> on behalf of Conner UK, Jim via lists.cloudfoundry.org <jim.conner=fil.com@...>
Date: Friday, September 3, 2021 at 3:01 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Cloudfoundry deployment error on vanilla Openstack Wallaby cloud #cf

I don’t think the Octavia endpoints are the same as the old Neutron lbaas ones were.

 

:path          => "/v2.0/lbaas/pools"

''OpenStack API NotFound Expected(200) <=> Actual(404 Not Found)

 

The API docs for Octavia seem to indicate that the path would be /v2/lbaas (rather than /v2.0)

 

I’ve no idea how to fix the issue, but I think that explains why the error is happening.

 

Cheers,

 

Jim

 

 

From: <cf-dev@...> on behalf of Chris L <chris@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Thursday, 2 September 2021 at 14:40
To: "cf-dev@..." <cf-dev@...>
Subject: [cf-dev] Cloudfoundry deployment error on vanilla Openstack Wallaby cloud #cf

 

All,

I am receiving this error while attempting to deploy Cloudfoundry on a vanilla Openstack Wallaby cloud:

[2021-09-02T01:29:55.856730 #882] [task:40] DEBUG -- DirectorJobRunner: (0.001265s) (conn: 47027669444740) INSERT INTO "events" ("parent_id", "timestamp", "user", "action", "object_type", "object_name", "error", "task", "deployment", "instance", "context_json") VALUES (342, '2021-09-02 01:29:55.852077+0000', 'admin', 'update', 'deployment', 'cf', 'CPI error ''Bosh::Clouds::CloudError'' with message ''OpenStack API NotFound Expected(200) <=> Actual(404 Not Found)

excon.error.response

  :body          => "{\"NeutronError\": {\"type\": \"HTTPNotFound\", \"message\": \"The resource could not be found.\", \"detail\": \"\"}}"

  :cookies       => [

  ]

  :headers       => {

    "content-length"            => "103"

    "content-type"              => "application/json"

    "date"                      => "Thu, 02 Sep 2021 01:29:32 GMT"

    "strict-transport-security" => "max-age=31536000;"

    "x-openstack-request-id"    => "req-fbfa7aa1-1f13-46c6-8385-5f0fde847b08"

  }

  :host          => "openstack-external.lyonsgroup.family"

  :local_address => "10.0.1.6"

  :local_port    => 45952

  :path          => "/v2.0/lbaas/pools"

  :port          => 9696

  :reason_phrase => "Not Found"

  :remote_ip     => "174.54.141.197"

  :status        => 404

  :status_line   => "HTTP/1.1 404 Not Found\r\n"

.

Check task debug log for details.'' in ''create_vm'' CPI method (CPI request ID: ''cpi-184472'')', '40', 'cf', NULL, '{"before":{"releases":["loggregator-agent/6.3.3","metrics-discovery/3.0.6","bpm/1.1.13","bosh-dns-aliases/0.0.4","bosh-dns/1.29.0","binary-buildpack/1.0.39","capi/1.112.0","cf-networking/2.38.0","cf-smoke-tests/41.0.2","cflinuxfs3/0.251.0","credhub/2.9.0","diego/2.51.0","dotnet-core-buildpack/2.3.32","garden-runc/1.19.29","go-buildpack/1.9.34","java-buildpack/4.41","loggregator/106.6.0","nats/40","nginx-buildpack/1.1.30","r-buildpack/1.1.20","nodejs-buildpack/1.7.57","php-buildpack/4.4.44","pxc/0.37.0","python-buildpack/1.7.43","routing/0.221.0","ruby-buildpack/1.8.43","silk/2.38.0","staticfile-buildpack/1.5.24","statsd-injector/1.11.16","uaa/75.6.0","log-cache/2.11.1","cf-cli/1.32.0"],"stemcells":["bosh-openstack-kvm-ubuntu-xenial-go_agent-raw/621.125"]},"after":{"releases":["loggregator-agent/6.3.3","metrics-discovery/3.0.6","bpm/1.1.13","bosh-dns-aliases/0.0.4","bosh-dns/1.29.0","binary-buildpack/1.0.39","capi/1.112.0","cf-networking/2.38.0","cf-smoke-tests/41.0.2","cflinuxfs3/0.251.0","credhub/2.9.0","diego/2.51.0","dotnet-core-buildpack/2.3.32","garden-runc/1.19.29","go-buildpack/1.9.34","java-buildpack/4.41","loggregator/106.6.0","nats/40","nginx-buildpack/1.1.30","r-buildpack/1.1.20","nodejs-buildpack/1.7.57","php-buildpack/4.4.44","pxc/0.37.0","python-buildpack/1.7.43","routing/0.221.0","ruby-buildpack/1.8.43","silk/2.38.0","staticfile-buildpack/1.5.24","statsd-injector/1.11.16","uaa/75.6.0","log-cache/2.11.1","cf-cli/1.32.0"],"stemcells":["bosh-openstack-kvm-ubuntu-xenial-go_agent-raw/621.125"]}}') RETURNING *

I do have the Octavia project installed and a loadbalancer is created and running.  I use the terraform script here to prepare the Openstack cloud for cloudfoundry:

https://github.com/cloudfoundry-attic/bosh-openstack-environment-templates/cf-deploymnet-tf/cf.tf

This creates a loadbalancer, security groups, networks, etc.

It completes successfully and I do see the cf-lb loadbalancer created, running, in active state, and a whole lot of ports and pools that exist under it.  I then execute the BOSH deploy of cloudfoundry using this repo:

https://github.com/cloudfoundry/cf-deployment/cf-deployment.yml

My deployment line looks like this:

runuser -l stack -c  "cd /opt/stack; \
                  bbl print-env -s /opt/stack > /tmp/bbl_env.sh; \
                  chmod 700 /tmp/bbl_env.sh; \
                  source /tmp/bbl_env.sh; \
                  bosh -d cf deploy -o /tmp/cf-deployment/operations/use-external-blobstore.yml \
                  -o /tmp/cf-deployment/operations/use-swift-blobstore.yml \
                  -o /tmp/cf-deployment/operations/openstack.yml \
                  -o /tmp/cf-deployment/operations/scale-to-one-az.yml \
                  -o /tmp/cf-deployment/operations/use-compiled-releases.yml \
                  --vars-store /tmp/vars/deployment-vars.yml \
                  /tmp/cf-deployment/cf-deployment.yml \
                  -v system_domain=
$DOMAIN_NAME \
                  -v auth_url=https://
$EXTERNAL_VIP_DNS:5000/v3 \
                  -v openstack_project=cloudfoundry \
                  -v openstack_domain=default \
                  -v openstack_username=
$OPENSTACK_CLOUDFOUNDRY_USERNAME \
                  -v openstack_password=
$OPENSTACK_CLOUDFOUNDRY_PWD \
                  -v openstack_temp_url_key=
$SWIFT_KEY \
                  -v app_package_directory_key=app_package_directory \
                  -v buildpack_directory_key=buildpack_directory \
                  -v droplet_directory_key=droplet_directory \
                  -v resource_directory_key=resource_directory \
                  -n"


Is there anything anyone could see as to what would cause the error at the beginning of the post?  I can get any other logs that would help, I could grant access to the env, anything that would give anyone an idea.


The information transmitted is intended for the person or entity to which it is addressed and may contain confidential, privileged or copyrighted material. If you receive this in error, please contact the sender and delete the material from any computer. Any views or opinions expressed are those of the author and do not necessarily represent those of Fidelity International. All e-mails may be monitored. FIL Investments International (Reg. No.1448245), FIL Investment Services (UK) Limited (Reg. No. 2016555), FIL Pensions Management (Reg. No. 2015142), Financial Administration Services Limited (Reg. No. 1629709) and FIL Wealth Management Limited (Registered. No. 06121251) are authorised and regulated in the UK by the Financial Conduct Authority. FIL Life Insurance Limited (Reg No. 3406905) is authorised in the UK by the Prudential Regulation Authority and regulated in the UK by the Financial Conduct Authority and the Prudential Regulation Authority. Registered offices at Beech Gate, Millfield Lane, Lower Kingswood, Tadworth, Surrey KT20 6RP.




This email has been scanned by Inbound Shield™.

 


Re: Cloudfoundry deployment error on vanilla Openstack Wallaby cloud #cf

Conner UK, Jim
 

I don’t think the Octavia endpoints are the same as the old Neutron lbaas ones were.

 

:path          => "/v2.0/lbaas/pools"

''OpenStack API NotFound Expected(200) <=> Actual(404 Not Found)

 

The API docs for Octavia seem to indicate that the path would be /v2/lbaas (rather than /v2.0)

 

I’ve no idea how to fix the issue, but I think that explains why the error is happening.

 

Cheers,

 

Jim

 

 

From: <cf-dev@...> on behalf of Chris L <chris@...>
Reply to: "cf-dev@..." <cf-dev@...>
Date: Thursday, 2 September 2021 at 14:40
To: "cf-dev@..." <cf-dev@...>
Subject: [cf-dev] Cloudfoundry deployment error on vanilla Openstack Wallaby cloud #cf

 

All,

I am receiving this error while attempting to deploy Cloudfoundry on a vanilla Openstack Wallaby cloud:

[2021-09-02T01:29:55.856730 #882] [task:40] DEBUG -- DirectorJobRunner: (0.001265s) (conn: 47027669444740) INSERT INTO "events" ("parent_id", "timestamp", "user", "action", "object_type", "object_name", "error", "task", "deployment", "instance", "context_json") VALUES (342, '2021-09-02 01:29:55.852077+0000', 'admin', 'update', 'deployment', 'cf', 'CPI error ''Bosh::Clouds::CloudError'' with message ''OpenStack API NotFound Expected(200) <=> Actual(404 Not Found)

excon.error.response

  :body          => "{\"NeutronError\": {\"type\": \"HTTPNotFound\", \"message\": \"The resource could not be found.\", \"detail\": \"\"}}"

  :cookies       => [

  ]

  :headers       => {

    "content-length"            => "103"

    "content-type"              => "application/json"

    "date"                      => "Thu, 02 Sep 2021 01:29:32 GMT"

    "strict-transport-security" => "max-age=31536000;"

    "x-openstack-request-id"    => "req-fbfa7aa1-1f13-46c6-8385-5f0fde847b08"

  }

  :host          => "openstack-external.lyonsgroup.family"

  :local_address => "10.0.1.6"

  :local_port    => 45952

  :path          => "/v2.0/lbaas/pools"

  :port          => 9696

  :reason_phrase => "Not Found"

  :remote_ip     => "174.54.141.197"

  :status        => 404

  :status_line   => "HTTP/1.1 404 Not Found\r\n"

.

Check task debug log for details.'' in ''create_vm'' CPI method (CPI request ID: ''cpi-184472'')', '40', 'cf', NULL, '{"before":{"releases":["loggregator-agent/6.3.3","metrics-discovery/3.0.6","bpm/1.1.13","bosh-dns-aliases/0.0.4","bosh-dns/1.29.0","binary-buildpack/1.0.39","capi/1.112.0","cf-networking/2.38.0","cf-smoke-tests/41.0.2","cflinuxfs3/0.251.0","credhub/2.9.0","diego/2.51.0","dotnet-core-buildpack/2.3.32","garden-runc/1.19.29","go-buildpack/1.9.34","java-buildpack/4.41","loggregator/106.6.0","nats/40","nginx-buildpack/1.1.30","r-buildpack/1.1.20","nodejs-buildpack/1.7.57","php-buildpack/4.4.44","pxc/0.37.0","python-buildpack/1.7.43","routing/0.221.0","ruby-buildpack/1.8.43","silk/2.38.0","staticfile-buildpack/1.5.24","statsd-injector/1.11.16","uaa/75.6.0","log-cache/2.11.1","cf-cli/1.32.0"],"stemcells":["bosh-openstack-kvm-ubuntu-xenial-go_agent-raw/621.125"]},"after":{"releases":["loggregator-agent/6.3.3","metrics-discovery/3.0.6","bpm/1.1.13","bosh-dns-aliases/0.0.4","bosh-dns/1.29.0","binary-buildpack/1.0.39","capi/1.112.0","cf-networking/2.38.0","cf-smoke-tests/41.0.2","cflinuxfs3/0.251.0","credhub/2.9.0","diego/2.51.0","dotnet-core-buildpack/2.3.32","garden-runc/1.19.29","go-buildpack/1.9.34","java-buildpack/4.41","loggregator/106.6.0","nats/40","nginx-buildpack/1.1.30","r-buildpack/1.1.20","nodejs-buildpack/1.7.57","php-buildpack/4.4.44","pxc/0.37.0","python-buildpack/1.7.43","routing/0.221.0","ruby-buildpack/1.8.43","silk/2.38.0","staticfile-buildpack/1.5.24","statsd-injector/1.11.16","uaa/75.6.0","log-cache/2.11.1","cf-cli/1.32.0"],"stemcells":["bosh-openstack-kvm-ubuntu-xenial-go_agent-raw/621.125"]}}') RETURNING *

I do have the Octavia project installed and a loadbalancer is created and running.  I use the terraform script here to prepare the Openstack cloud for cloudfoundry:

https://github.com/cloudfoundry-attic/bosh-openstack-environment-templates/cf-deploymnet-tf/cf.tf

This creates a loadbalancer, security groups, networks, etc.

It completes successfully and I do see the cf-lb loadbalancer created, running, in active state, and a whole lot of ports and pools that exist under it.  I then execute the BOSH deploy of cloudfoundry using this repo:

https://github.com/cloudfoundry/cf-deployment/cf-deployment.yml

My deployment line looks like this:

runuser -l stack -c  "cd /opt/stack; \
                  bbl print-env -s /opt/stack > /tmp/bbl_env.sh; \
                  chmod 700 /tmp/bbl_env.sh; \
                  source /tmp/bbl_env.sh; \
                  bosh -d cf deploy -o /tmp/cf-deployment/operations/use-external-blobstore.yml \
                  -o /tmp/cf-deployment/operations/use-swift-blobstore.yml \
                  -o /tmp/cf-deployment/operations/openstack.yml \
                  -o /tmp/cf-deployment/operations/scale-to-one-az.yml \
                  -o /tmp/cf-deployment/operations/use-compiled-releases.yml \
                  --vars-store /tmp/vars/deployment-vars.yml \
                  /tmp/cf-deployment/cf-deployment.yml \
                  -v system_domain=
$DOMAIN_NAME \
                  -v auth_url=https://
$EXTERNAL_VIP_DNS:5000/v3 \
                  -v openstack_project=cloudfoundry \
                  -v openstack_domain=default \
                  -v openstack_username=
$OPENSTACK_CLOUDFOUNDRY_USERNAME \
                  -v openstack_password=
$OPENSTACK_CLOUDFOUNDRY_PWD \
                  -v openstack_temp_url_key=
$SWIFT_KEY \
                  -v app_package_directory_key=app_package_directory \
                  -v buildpack_directory_key=buildpack_directory \
                  -v droplet_directory_key=droplet_directory \
                  -v resource_directory_key=resource_directory \
                  -n"


Is there anything anyone could see as to what would cause the error at the beginning of the post?  I can get any other logs that would help, I could grant access to the env, anything that would give anyone an idea.


The information transmitted is intended for the person or entity to which it is addressed and may contain confidential, privileged or copyrighted material. If you receive this in error, please contact the sender and delete the material from any computer. Any views or opinions expressed are those of the author and do not necessarily represent those of Fidelity International. All e-mails may be monitored. FIL Investments International (Reg. No.1448245), FIL Investment Services (UK) Limited (Reg. No. 2016555), FIL Pensions Management (Reg. No. 2015142), Financial Administration Services Limited (Reg. No. 1629709) and FIL Wealth Management Limited (Registered. No. 06121251) are authorised and regulated in the UK by the Financial Conduct Authority. FIL Life Insurance Limited (Reg No. 3406905) is authorised in the UK by the Prudential Regulation Authority and regulated in the UK by the Financial Conduct Authority and the Prudential Regulation Authority. Registered offices at Beech Gate, Millfield Lane, Lower Kingswood, Tadworth, Surrey KT20 6RP.


Cloudfoundry deployment error on vanilla Openstack Wallaby cloud #cf

Chris L
 

All,

I am receiving this error while attempting to deploy Cloudfoundry on a vanilla Openstack Wallaby cloud:

[2021-09-02T01:29:55.856730 #882] [task:40] DEBUG -- DirectorJobRunner: (0.001265s) (conn: 47027669444740) INSERT INTO "events" ("parent_id", "timestamp", "user", "action", "object_type", "object_name", "error", "task", "deployment", "instance", "context_json") VALUES (342, '2021-09-02 01:29:55.852077+0000', 'admin', 'update', 'deployment', 'cf', 'CPI error ''Bosh::Clouds::CloudError'' with message ''OpenStack API NotFound Expected(200) <=> Actual(404 Not Found)
excon.error.response
  :body          => "{\"NeutronError\": {\"type\": \"HTTPNotFound\", \"message\": \"The resource could not be found.\", \"detail\": \"\"}}"
  :cookies       => [
  ]
  :headers       => {
    "content-length"            => "103"
    "content-type"              => "application/json"
    "date"                      => "Thu, 02 Sep 2021 01:29:32 GMT"
    "strict-transport-security" => "max-age=31536000;"
    "x-openstack-request-id"    => "req-fbfa7aa1-1f13-46c6-8385-5f0fde847b08"
  }
  :host          => "openstack-external.lyonsgroup.family"
  :local_address => "10.0.1.6"
  :local_port    => 45952
  :path          => "/v2.0/lbaas/pools"
  :port          => 9696
  :reason_phrase => "Not Found"
  :remote_ip     => "174.54.141.197"
  :status        => 404
  :status_line   => "HTTP/1.1 404 Not Found\r\n"
.
Check task debug log for details.'' in ''create_vm'' CPI method (CPI request ID: ''cpi-184472'')', '40', 'cf', NULL, '{"before":{"releases":["loggregator-agent/6.3.3","metrics-discovery/3.0.6","bpm/1.1.13","bosh-dns-aliases/0.0.4","bosh-dns/1.29.0","binary-buildpack/1.0.39","capi/1.112.0","cf-networking/2.38.0","cf-smoke-tests/41.0.2","cflinuxfs3/0.251.0","credhub/2.9.0","diego/2.51.0","dotnet-core-buildpack/2.3.32","garden-runc/1.19.29","go-buildpack/1.9.34","java-buildpack/4.41","loggregator/106.6.0","nats/40","nginx-buildpack/1.1.30","r-buildpack/1.1.20","nodejs-buildpack/1.7.57","php-buildpack/4.4.44","pxc/0.37.0","python-buildpack/1.7.43","routing/0.221.0","ruby-buildpack/1.8.43","silk/2.38.0","staticfile-buildpack/1.5.24","statsd-injector/1.11.16","uaa/75.6.0","log-cache/2.11.1","cf-cli/1.32.0"],"stemcells":["bosh-openstack-kvm-ubuntu-xenial-go_agent-raw/621.125"]},"after":{"releases":["loggregator-agent/6.3.3","metrics-discovery/3.0.6","bpm/1.1.13","bosh-dns-aliases/0.0.4","bosh-dns/1.29.0","binary-buildpack/1.0.39","capi/1.112.0","cf-networking/2.38.0","cf-smoke-tests/41.0.2","cflinuxfs3/0.251.0","credhub/2.9.0","diego/2.51.0","dotnet-core-buildpack/2.3.32","garden-runc/1.19.29","go-buildpack/1.9.34","java-buildpack/4.41","loggregator/106.6.0","nats/40","nginx-buildpack/1.1.30","r-buildpack/1.1.20","nodejs-buildpack/1.7.57","php-buildpack/4.4.44","pxc/0.37.0","python-buildpack/1.7.43","routing/0.221.0","ruby-buildpack/1.8.43","silk/2.38.0","staticfile-buildpack/1.5.24","statsd-injector/1.11.16","uaa/75.6.0","log-cache/2.11.1","cf-cli/1.32.0"],"stemcells":["bosh-openstack-kvm-ubuntu-xenial-go_agent-raw/621.125"]}}') RETURNING *

I do have the Octavia project installed and a loadbalancer is created and running.  I use the terraform script here to prepare the Openstack cloud for cloudfoundry:

https://github.com/cloudfoundry-attic/bosh-openstack-environment-templates/cf-deploymnet-tf/cf.tf

This creates a loadbalancer, security groups, networks, etc.

It completes successfully and I do see the cf-lb loadbalancer created, running, in active state, and a whole lot of ports and pools that exist under it.  I then execute the BOSH deploy of cloudfoundry using this repo:

https://github.com/cloudfoundry/cf-deployment/cf-deployment.yml

My deployment line looks like this:

runuser -l stack -c  "cd /opt/stack; \
bbl print-env -s /opt/stack > /tmp/bbl_env.sh; \
chmod 700 /tmp/bbl_env.sh; \
source /tmp/bbl_env.sh; \
bosh -d cf deploy -o /tmp/cf-deployment/operations/use-external-blobstore.yml \
-o /tmp/cf-deployment/operations/use-swift-blobstore.yml \
-o /tmp/cf-deployment/operations/openstack.yml \
-o /tmp/cf-deployment/operations/scale-to-one-az.yml \
-o /tmp/cf-deployment/operations/use-compiled-releases.yml \
--vars-store /tmp/vars/deployment-vars.yml \
/tmp/cf-deployment/cf-deployment.yml \
-v system_domain=$DOMAIN_NAME \
-v auth_url=https://$EXTERNAL_VIP_DNS:5000/v3 \
-v openstack_project=cloudfoundry \
-v openstack_domain=default \
-v openstack_username=$OPENSTACK_CLOUDFOUNDRY_USERNAME \
-v openstack_password=$OPENSTACK_CLOUDFOUNDRY_PWD \
-v openstack_temp_url_key=$SWIFT_KEY \
-v app_package_directory_key=app_package_directory \
-v buildpack_directory_key=buildpack_directory \
-v droplet_directory_key=droplet_directory \
-v resource_directory_key=resource_directory \
-n"


Is there anything anyone could see as to what would cause the error at the beginning of the post?  I can get any other logs that would help, I could grant access to the env, anything that would give anyone an idea.


Re: bosh cf-deploy on openstack

Chris L
 

Did you ever get this resolved?  I am trying to deploy cloudfoundry on a vanilla openstack wallaby cloud and am getting an error that looks the same as yours.  I am using Octavia (and need to, disabling isnt an option).  I see this same on deploy of the same VM's, I get about 8/9 VM's out of 12 or so attempting to be created with the rest printing this error.


Re: CF on K8s Update

Angela Chin
 

Hi Jan,


It’s great to hear your thoughts on this topic. I definitely agree that the core of what makes CF so powerful is the simplicity for the end user.


Just to clarify, would the CLI you’re referring to remain backwards compatible with existing CLI commands or would it be new CLI commands/workflows?


In contrast, building container images on the server side and threading a call to cf push​ through a cascade of custom resources and corresponding controllers seems to contribute a lot of complexity while provided only marginally to the value. Both, for the application developers/system operators and for the CF community developing and maintaining these controllers.


I agree that having custom resources/controllers doesn’t provide additional benefit to the end user experience since it is an implementation detail. However, I would argue that this architecture does provide value to the CF community. 


Primarily, by having this layer of indirection (versus a direct CLI -> end resource architecture), we are able to have a defined interface (the CF custom resources) that allows for the introduction of alternative technologies. This allows for pluggability of different Kubernetes ecosystem projects depending on the user’s needs, which was called out as a major guiding principle in the Vision for CF on K8s.


One thing that we struggled with in CF for VMs was how tightly coupled all of the components were with one another. The architecture did not lend itself to extensibility. For example, there was an attempt to replace the gorouter with Istio-- while this ultimately failed for several reasons, the tight integration of gorouter in the rest of the system played a major role.


Another benefit that this architecture brings is the ability to support both users who require backward compatibility with existing CF workflows and users who want more cutting edge features. Depending on the organization’s requirements, different build or runtime solutions could be plugged in and used. 


If we truly want to evolve CF on Kubernetes, I believe we should be attempting to not only meet the existing requirements of CF, but look at places where we can improve the system even more. I think extensibility is a major area, which is why I believe this architecture is the right level of abstraction.


To your point on the number of resources and controllers though, we are looking into possibly consolidating the App and Process objects as well as Build and Droplet. We’ve prioritized explorations for each on our Github project.


In terms of next steps, if we want to discuss the tradeoffs of this architecture and what you proposed, I’d suggest we revisit the Vision for CF on K8s document and the goals and principles it lays out :)


- Angela



From: cf-dev@... <cf-dev@...> on behalf of Jan von L?wenstein via lists.cloudfoundry.org <jan.von.loewenstein=sap.com@...>
Sent: Thursday, August 26, 2021 11:52 PM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] CF on K8s Update
 
Hi Angela et al,

It is good to have clarity on the state of cf-for-k8s for which a decline in activity has been observable already for some time.
Additionally, freeing up resources for the broader topic of exploring further options of bringing the Cloud Foundry workflows to Kubernetes is a good decision.

I have looked at the demo and PR and would like to approach the discussion from a slightly different perspective.
What makes Cloud Foundry awesome?
Here is my code
Run it in the cloud for me
I do not care how
In my humble opinion, it is the not having to care. Not having to care how code is translated into an executable container. Not having to care how such container is executed.

Now I would argue that we can reach eighty percent of the awesomeness of not caring for container creation using Paketo buildpacks with pack​ on a developer machine and some integration into CI/CD - be it Jenkins, Concourse, Tekton, or something else.
Using pack​ works nicely for the development flow and the production flow anyhow runs in a CI/CD system.

Similarly, I would argue that taking a container and creating a Kubernetes Workload resource (Deployment or StatefulSet) with secure container defaults (runAsNonRoot and dropCapabilities: ALL to name two), the best available Kubernetes means to achieve high availability, and others will bring the largest part of value. Basically, what Eirini does.

In contrast, building container images on the server side and threading a call to cf push​ through a cascade of custom resources and corresponding controllers seems to contribute a lot of complexity while provided only marginally to the value. Both, for the application developers/system operators and for the CF community developing and maintaining these controllers.

Should we maybe focus our efforts on the creation of Kubernetes resources with good defaults for Cloud Foundry apps - doesn't even have to be a controller, but handled in a CLI - and keep the layer(s) between the CF manifest and application code on the one hand side and the Kubernetes resources and application images on the other hand side as minimal and narrow as possible?

If the answer to the question of what's left of Cloud Foundry then is "Not much in terms of code", I would consider that a good thing.

Best regards
Jan

From: cf-dev@... <cf-dev@...> on behalf of Angela Chin <angelac@...>
Sent: 23 August 2021 19:24
To: cf-dev@... <cf-dev@...>
Subject: [cf-dev] CF on K8s Update
 

Hi cf-dev,


Earlier this year, leadership from IBM, SAP, and VMware shared a new Vision for CF on K8s document and discussed it with the community. Since then, our group of engineers at VMware and SAP have been exploring what it would take to support this vision. We have been engaging in the CF on K8s SIG meetings to discuss future technical direction and spiking out a proof-of-concept to support the core cf push workflow using Kubernetes-native concepts, which you can view here


We are excited to share that we have finished the proof-of-concept and have recorded a demo video to illustrate. Additionally, we have written a high-level summary of the current architecture and have opened a PR for an initial set of CF CRDs. All of this work is being actively tracked in the CF on K8s Github project. We are looking to engage a larger swath of the community in our efforts, and would appreciate any and all contributions to this effort :) If you're interested in contributing to this effort, please join us in the new #cf-k8s-dev channel in the CF Slack!


As a result of devoting development resources to accelerate this new vision and technical architecture for CF on K8s, we have decided to pause our contributions to the cf-for-k8s project. It is now in a position where it is stable and demonstrates the promise of the CF developer experience on top of Kubernetes. We anticipate future development to consist of only a small amount of regular maintenance to keep up to date with the latest versions of some of the dependencies it incorporates, such as Istio and kpack. We recently updated to the latest version of Istio but would appreciate additional community assistance in maintaining cf-for-k8s as we focus on bootstrapping the new CF on K8s architecture and reference deployments. We expect this activity to happen in the App Runtime Deployments working group that is forming under the new CFF technical governance structure.


- Angela Chin, on behalf of the cf-for-k8s and Eirini maintainers


Re: CF on K8s Update

Jan von L?wenstein
 

Hi Angela et al,

It is good to have clarity on the state of cf-for-k8s for which a decline in activity has been observable already for some time.
Additionally, freeing up resources for the broader topic of exploring further options of bringing the Cloud Foundry workflows to Kubernetes is a good decision.

I have looked at the demo and PR and would like to approach the discussion from a slightly different perspective.
What makes Cloud Foundry awesome?
Here is my code
Run it in the cloud for me
I do not care how
In my humble opinion, it is the not having to care. Not having to care how code is translated into an executable container. Not having to care how such container is executed.

Now I would argue that we can reach eighty percent of the awesomeness of not caring for container creation using Paketo buildpacks with pack​ on a developer machine and some integration into CI/CD - be it Jenkins, Concourse, Tekton, or something else.
Using pack​ works nicely for the development flow and the production flow anyhow runs in a CI/CD system.

Similarly, I would argue that taking a container and creating a Kubernetes Workload resource (Deployment or StatefulSet) with secure container defaults (runAsNonRoot and dropCapabilities: ALL to name two), the best available Kubernetes means to achieve high availability, and others will bring the largest part of value. Basically, what Eirini does.

In contrast, building container images on the server side and threading a call to cf push​ through a cascade of custom resources and corresponding controllers seems to contribute a lot of complexity while provided only marginally to the value. Both, for the application developers/system operators and for the CF community developing and maintaining these controllers.

Should we maybe focus our efforts on the creation of Kubernetes resources with good defaults for Cloud Foundry apps - doesn't even have to be a controller, but handled in a CLI - and keep the layer(s) between the CF manifest and application code on the one hand side and the Kubernetes resources and application images on the other hand side as minimal and narrow as possible?

If the answer to the question of what's left of Cloud Foundry then is "Not much in terms of code", I would consider that a good thing.

Best regards
Jan

From: cf-dev@... <cf-dev@...> on behalf of Angela Chin <angelac@...>
Sent: 23 August 2021 19:24
To: cf-dev@... <cf-dev@...>
Subject: [cf-dev] CF on K8s Update
 

Hi cf-dev,


Earlier this year, leadership from IBM, SAP, and VMware shared a new Vision for CF on K8s document and discussed it with the community. Since then, our group of engineers at VMware and SAP have been exploring what it would take to support this vision. We have been engaging in the CF on K8s SIG meetings to discuss future technical direction and spiking out a proof-of-concept to support the core cf push workflow using Kubernetes-native concepts, which you can view here


We are excited to share that we have finished the proof-of-concept and have recorded a demo video to illustrate. Additionally, we have written a high-level summary of the current architecture and have opened a PR for an initial set of CF CRDs. All of this work is being actively tracked in the CF on K8s Github project. We are looking to engage a larger swath of the community in our efforts, and would appreciate any and all contributions to this effort :) If you're interested in contributing to this effort, please join us in the new #cf-k8s-dev channel in the CF Slack!


As a result of devoting development resources to accelerate this new vision and technical architecture for CF on K8s, we have decided to pause our contributions to the cf-for-k8s project. It is now in a position where it is stable and demonstrates the promise of the CF developer experience on top of Kubernetes. We anticipate future development to consist of only a small amount of regular maintenance to keep up to date with the latest versions of some of the dependencies it incorporates, such as Istio and kpack. We recently updated to the latest version of Istio but would appreciate additional community assistance in maintaining cf-for-k8s as we focus on bootstrapping the new CF on K8s architecture and reference deployments. We expect this activity to happen in the App Runtime Deployments working group that is forming under the new CFF technical governance structure.


- Angela Chin, on behalf of the cf-for-k8s and Eirini maintainers


cf CLI v7.3.0 is now available

Alexander Berez
 

Good Day to You All,

The cf CLI team has released  v7.3.0 of the cf CLI

Highlights: 

  • Change CLI strategy for streaming logs from log cache, delaying when messages aren't found by 250 MS to decrease excessive load on log cache
  • Add --wait to run-task
  • Two spaces indent for json
  • Add support for quotas to be given in TBs
  • Support TLS 1.3

Bug Fixes:
  • Stack being overridden on cf push
  • V7 services do not poll empty jobs
  • Cancel deployment v7 push on failure
  • dfe195d -> Special characters are not HTML encoded

Contributors:
Reid Mitchell, Jenna Goldstrich, Alexander Berezovsky, Dominic Roberts, Juan Diego Gonzalez, Hema Ranganathan, Teal Stannard, Seth Boyles, Zach Robinson, Felisia Martini, George Blue, Sarah Weinstein, Colin Simmons and Ryker Reed


Please see the release notes for more details and links to binaries and packages.

And as always, we really would love to hear from you so please feel free to respond to this email or find us in the Cloud Foundry Slack #cli channel any time.


Thank you very much


CF on K8s Update

Angela Chin
 

Hi cf-dev,


Earlier this year, leadership from IBM, SAP, and VMware shared a new Vision for CF on K8s document and discussed it with the community. Since then, our group of engineers at VMware and SAP have been exploring what it would take to support this vision. We have been engaging in the CF on K8s SIG meetings to discuss future technical direction and spiking out a proof-of-concept to support the core cf push workflow using Kubernetes-native concepts, which you can view here


We are excited to share that we have finished the proof-of-concept and have recorded a demo video to illustrate. Additionally, we have written a high-level summary of the current architecture and have opened a PR for an initial set of CF CRDs. All of this work is being actively tracked in the CF on K8s Github project. We are looking to engage a larger swath of the community in our efforts, and would appreciate any and all contributions to this effort :) If you're interested in contributing to this effort, please join us in the new #cf-k8s-dev channel in the CF Slack!


As a result of devoting development resources to accelerate this new vision and technical architecture for CF on K8s, we have decided to pause our contributions to the cf-for-k8s project. It is now in a position where it is stable and demonstrates the promise of the CF developer experience on top of Kubernetes. We anticipate future development to consist of only a small amount of regular maintenance to keep up to date with the latest versions of some of the dependencies it incorporates, such as Istio and kpack. We recently updated to the latest version of Istio but would appreciate additional community assistance in maintaining cf-for-k8s as we focus on bootstrapping the new CF on K8s architecture and reference deployments. We expect this activity to happen in the App Runtime Deployments working group that is forming under the new CFF technical governance structure.


- Angela Chin, on behalf of the cf-for-k8s and Eirini maintainers


Bosh proposal for enhancement of rotating bosh-agent certificates/credentials

jpalermo@...
 

Hey all, we’ve got a proposal out for how to enhance the process of rotation certificates/credentials used by the bosh agent (making NATS cert rotation easier being the primary driver): https://github.com/cloudfoundry/bosh/discussions/2309

Looking for feedback. Ideally we’d like to keep the conversation around it in the github discussion so it’s more permanent and discoverable.

1 - 20 of 9377