Date   

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.


COMING SOON: V8 Release of CF CLI

dominicr@...
 

Hello all,

We are happy to announce that the CF CLI team is preparing to release v8 in the next month or so. Here are some new features that you can look forward to:
  • All services commands now utilize v3 api, enabling most commands to run asynchronously and with better performance
  • Bump to golang 1.16
  • Beta support for the Space Supporter role
  • Manifest diffs on pushing utilizing the v3 api
If you have any feedback, concerns or questions regarding the v8 release please feel free to reach out on the cli slack channel


CFF Working Groups: feedback and participants requested!

Eric Malm
 

Hi, everyone,

As we mentioned at CF Summit last week, the newly formed Technical Oversight Committee (TOC) is currently carrying out more and more of the details of the transition from the previous project-team and project management committee (PMC) structure to the working groups and community roles.

To that end, we have proposed an initial set of working groups on PR #140 on the community repo, together with how they will subsume the existing project teams and components. As a community, we now need to confirm the scope of each of these working groups, to staff them with leads and approvers, and to get them up and running with transparent development and roadmap processes. Consequently, we need a few things from the community now:
  • Please provide feedback on the overall working-group organizational structure.
  • Please provide suggestions for and feedback on the goals, scope, and technical assets for each proposed working group.
  • Please identify people in the community as candidates for approvers/leads in each working group, including yourselves if you already work in this area.
We're currently working out these details for the App Runtime Deployments working group as a pilot case, so if you care about cf-deployment, KubeCF, cf-for-k8s, or the overall community mandate to provide reference deployments of the App Runtime, now is the right time to get involved! The TOC would also like to complete this process for the complete set of working groups over the next few weeks, so if you're more focused on another area of the CF community, we need your involvement as well.

We invite everyone to join to discuss these working-group proposals at the public TOC meetings every Tuesday at 10:30 am ET, with details on the CF community calendar, and to provide feedback asynchronously on a particular proposed working group is the draft PR for its charter. Here is the full list of those charter PRs:
Please don't worry if you don't see a particular project listed here: it should be present in the PR content itself, and if it's not, the TOC wants to know about it!

Thanks,
Eric Malm, TOC member


Cloud Foundry Community Awards Nominations is now extended!

Shedrack Akintayo <sakintayo@...>
 

Hello Friends,

The Community Awards nomination form deadline is now extended until Friday, July 2nd, 11:59 PM PT, 2021.

This is to give our community members more time to nominate their peers as we strongly believe in the opinion of every community member. If you believe a particular member of the community deserves any of the awards, go ahead and nominate them.

I also wrote a post to help answer any questions you may have about any of the award categories, but please feel free to reach out if there is any additional question.

Get nominating today!

Thanks,
Shedrack.

Shedrack Akintayo | Developer Advocate


Cloud Foundry Foundation


sakintayo@...


twitter.com/coder_blvck


CFF TOC Meetings

Chip Childers <cchilders@...>
 

All,

The newly elected CFF TOC will initially be meeting weekly, on Tuesdays at 14:30 UTC (7:30 AM US Pacific Time, 4:30 PM Central European Time). 

These meetings are open to the entire community to attend, although I ask that you respect that the TOC will be setting the agenda and running the meeting.

The meetings will be recorded and posted to the foundation's youtube channel.

Chip Childers
Executive Director
Cloud Foundry Foundation


Re: Update regarding Bionic Stemcells: Version 1.10 released from Foundation owned infrastructure

Benjamin Gandon
 

Congrats Felix and SAP team, and all other CFF contributors for this great achievement!

Benjamin


Le 17 juin 2021 à 17:16, Riegger, Felix via lists.cloudfoundry.org <felix.riegger=sap.com@...> a écrit :

Dear Cloud Foundry community,
 
The migration of the Stemcell release infrastructure and pipelines from VMWare to CloudFoundry Foundation owned accounts is mostly done. With Bionic Stemcell 1.10 the first Stemcell has been created and released with the new setup.
 
This is again a huge step forward to bring the Stemcell into the hands of the communitiy. Again a big thank you to everyone involved in this journey.
 
What has changed?
 
The new Stemcells are now published in Google Cloud Storage instead of AWS S3. This change uncovered a bug in the BOSH CLI, which has been fixed in the latest version. Please update to https://github.com/cloudfoundry/bosh-cli/releases/tag/v6.4.4 to consume the latest Stemcells.
 
In the previous setup BOSH Acceptance Tests (BATS), IPv4 and IPv6 tests have been executed against a vSphere environment owned by VMWare. In the new setup these tests are executed in a GCP environment. Unfortunately, it was not possible to replicate the IPv6 tests to this environment. While we don't expect big changes in this area this implies that IPv6 might stop working at some point with newer Stemcells without us noticing. If this is important to you and you would like to contribute please reach out to discuss options.
 
Where can I access the new infrastructure?
 
The concourse is hosted on https://bosh.ci.cloudfoundry.org/ and runs on a GCP account of the CloudFoundry Foundation.
 
Where is the code?
 
The repositories for the pipeline definitions and the stemcell code itself have not changed. They can be found in https://github.com/cloudfoundry/bosh-stemcells-ci and https://github.com/cloudfoundry/bosh-linux-stemcell-builder.
 
Any assets regarding the Concourse setup live in https://github.com/cloudfoundry/bosh-community-stemcell-ci-infra.
 
Who can access the pipelines and contribute?
 
Any member of https://github.com/orgs/cloudfoundry/teams/bosh-stemcell can access and work with the pipeline as well as the relevant repositories. If you would like to become a contributor, please reach out.
 
Where can I follow?
 
 
Anything else?
 
As was announced by the CFF Security Working Group in https://www.cloudfoundry.org/blog/security-advisory-update/ CFF security advisories are now in place for Bionic Stemcells and the release of version 1.10 triggered the first advisories.
 
Kind regards,
Felix


Update regarding Bionic Stemcells: Version 1.10 released from Foundation owned infrastructure

Riegger, Felix
 

Dear Cloud Foundry community,

 

The migration of the Stemcell release infrastructure and pipelines from VMWare to CloudFoundry Foundation owned accounts is mostly done. With Bionic Stemcell 1.10 the first Stemcell has been created and released with the new setup.

 

This is again a huge step forward to bring the Stemcell into the hands of the communitiy. Again a big thank you to everyone involved in this journey.

 

What has changed?

 

The new Stemcells are now published in Google Cloud Storage instead of AWS S3. This change uncovered a bug in the BOSH CLI, which has been fixed in the latest version. Please update to https://github.com/cloudfoundry/bosh-cli/releases/tag/v6.4.4 to consume the latest Stemcells.

 

In the previous setup BOSH Acceptance Tests (BATS), IPv4 and IPv6 tests have been executed against a vSphere environment owned by VMWare. In the new setup these tests are executed in a GCP environment. Unfortunately, it was not possible to replicate the IPv6 tests to this environment. While we don't expect big changes in this area this implies that IPv6 might stop working at some point with newer Stemcells without us noticing. If this is important to you and you would like to contribute please reach out to discuss options.

 

Where can I access the new infrastructure?

 

The concourse is hosted on https://bosh.ci.cloudfoundry.org/ and runs on a GCP account of the CloudFoundry Foundation.

 

Where is the code?

 

The repositories for the pipeline definitions and the stemcell code itself have not changed. They can be found in https://github.com/cloudfoundry/bosh-stemcells-ci and https://github.com/cloudfoundry/bosh-linux-stemcell-builder.

 

Any assets regarding the Concourse setup live in https://github.com/cloudfoundry/bosh-community-stemcell-ci-infra.

 

Who can access the pipelines and contribute?

 

Any member of https://github.com/orgs/cloudfoundry/teams/bosh-stemcell can access and work with the pipeline as well as the relevant repositories. If you would like to become a contributor, please reach out.

 

Where can I follow?

 

Work can be tracked in https://github.com/orgs/cloudfoundry/projects/4.

 

Anything else?

 

As was announced by the CFF Security Working Group in https://www.cloudfoundry.org/blog/security-advisory-update/ CFF security advisories are now in place for Bionic Stemcells and the release of version 1.10 triggered the first advisories.

 

Kind regards,

Felix


The Community Awards Nomination is Now Open

Shedrack Akintayo <sakintayo@...>
 

Hello Friends, 

The Community Awards nomination form is now available!

This means that you can nominate any of your peers in the community for any of the award categories available. If you believe a particular member of the community deserves any of the awards, go ahead and nominate them.

The deadline for nominations is Friday, June 25th, 11:59 PM PT. I also wrote a post to help answer any questions you may have about any of the award categories, but please feel free to reach out if there is any additional question.


Get nominating today!

Thanks,
Shedrack.

Shedrack Akintayo | Developer Advocate


Cloud Foundry Foundation


sakintayo@...


twitter.com/coder_blvck


Re: 2021 CFF Technical Oversight Committee Election Results

Lee Porte
 

Wow! Thank you to the community.

I'm looking forwards to getting started

Cheers

L

On Thu, 17 Jun 2021 at 13:53, Chip Childers <cchilders@...> wrote:

Many thanks to everyone who took the time to register and vote in the first Cloud Foundry Foundation annual election for our newly forming Technical Oversight Committee (TOC). I also extend my deep thanks to all of the nominees who agreed to run in the election. Overall, our community’s participation in this election process was outstanding (especially given that this was our first time doing this!)


And with that preamble, I’m pleased to announce our first CFF Technical Oversight Committee will be:

* Eric Malm (VMware)

* David Stevenson (VMware)

* Jan von Loewenstein (SAP)

* Stephan Merker (SAP)

* Lee Porte (GOV.UK)


Congratulations to Eric, David, Jan, Stephan and Lee! I’m looking forward to working with you to get the TOC up and running.


For transparency, more details have been published here: https://github.com/cloudfoundry/community/blob/main/toc/elections/2021/results.md


Chip Childers
Executive Director
Cloud Foundry Foundation


--
Lee Porte
Reliability Engineer 
GOV.UK PaaS Team
‪020 3920 6036‬
07785 449292

1 - 20 of 9369