Date   
Cloud Foundry Operators SIG

Swarna Podila
 

Hello Everyone,
It has been recently brought up that it would be useful to have a forum for Cloud Foundry operators to come together and discuss regularly.  The folks at SAP took the lead and have scheduled a call for April 24th, 11AM CET, and repeats every fourth Wednesday of the month.  The appointment is now on the Community calendar; it has the conference bridge info so you can all add it to your own calendars.

Thank you, Gowrisankar and team, for taking lead on this.

-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.

[CFEU2019 Registration] Contributor Code

Swarna Podila
 

I love some of y'all's excitement when you asked for the Contributors' Code to register for Cloud Foundry Summit EU in The Hague (Sep 11-12).

Please use CFEU19CONT to register for the EU Summit, if you are (or were) a Cloud Foundry Contributor (code, docs, bugs -- all contributions count).  See you all there!

-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.

Re: Removing Support for v1 Style Manifests

Jeanyhwh Desulme
 

Hey Morgan -

This is unfortunately a breaking change for our implementation of Bosh. We looked at fully implementing V2 some time ago but found that there was an issue in how we wanted to use it. For example our pipelines combine both a CFT and a deployment manifest. So that when we run a deployment of a given application we are passing down physical ids of native aws resources directly into the manifest itself. The following open Github issue has some more specifics in what were looking to do and what we currently have in place today.

Ideally we would love to move but only if we can override some of the deployment configuration at deploy time. 

https://github.com/cloudfoundry/bosh/issues/2094

Regards,
Jean 
Liberty Mutual

Re: Ask for CF Community Process of building light stemcell

Mukesh Gadiya
 

Hi Bing Li,

My name is Mukesh and I am the PM for BOSH Systems team in San Francisco which is responsible for Stemcells, DNS and CLI. We talked about this in pre-IPM meeting with team and your request looks similar to how IBM Softlayer builds stemcells. Below are some questions for Marco on the SoftLayer process that should help us figure answers for your question.

Marco, 
  1. Should the stemcell builder & metalink repository be in the cloudfoundry github organization?

  2. Should the foundation own the credentials for the artifacts?

  3. Should we include the artifacts on bosh.io/stemcells?

Since, IBM does this with Softlayer, we're curious what the answers to the above questions are for softlayer.

Thanks,
Mukesh

Re: [CAUTION] Re: [cf-bosh] Moving BPM out of Incubation

Marco Voelz
 

Dear Christopher,

 

I'm happy to announce that BPM has been accepted as an active project within the BOSH PMC at yesterday's PMC meeting.

You can reach out to @Chris Clark for the logistics of moving the repository and updating the list of projects in the BOSH PMC.

 

Welcome onboard!

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Thursday, 14. March 2019 at 10:10
To: "cf-bosh@..." <cf-bosh@...>, "cbrown@..." <cbrown@...>
Subject: [CAUTION] Re: [cf-bosh] Moving BPM out of Incubation

 

Thanks Christopher!

 

I haven't forgotten about your proposal, we're going to vote on it during our BOSH PMC meeting on March 21st. Sorry it took so long, we had to sort out some logistics around all of this.

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of Christopher Brown <cbrown@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Tuesday, 5. February 2019 at 01:26
To: "cf-bosh@..." <cf-bosh@...>
Subject: Re: [cf-bosh] Moving BPM out of Incubation

 

I work on it 1-2 days per week. BPM v1 is pretty much feature complete and I anticipate that most of the work from now on will be refinements.

At some point we'll start seriously considering what the next steps for v2 are. At that point I expect the time spent on it and the feature work to ramp back up again.

Thanks and all the best,
Christopher

Re: Removing Support for v1 Style Manifests

Morgan Fine
 

Hi all,

A few clarifications and questions that have come up. While the create-env flow is still using "v1 manifest" structure, that code path does not involve the BOSH director itself as create-env is done in the CLI. To that end, we are not intending to change the create-env manifest structure at this time, only the manifest structure used in `bosh deploy` commands. 

In regards to what are we intending to remove, at a high level, we are intending to remove the sections from the v1 manifest page that have migrated to v2 syntax:
  • Deployment Identification i.e. "director_uuid"
  • Networks
  • Resource Pools
  • Disk Pools
  • Compilation
  • Jobs becomes Instance Groups
Best,
Morgan

On Thu, Mar 21, 2019 at 8:10 AM Stanislav German-Evtushenko <s.germanevtushenko@...> wrote:
How to know what exactly is planned to be removed? I remember some overlaps between v1 and v2 as well as not explicitly documented features which worked.

What happens to bosh create-env manifest, will it be documented separately? As of now, it's a mix of both (v1 and v2) because it should support cloud properties.

Good time to update bosh-deployment btw.

Re: Removing Support for v1 Style Manifests

Stanislav German-Evtushenko
 

How to know what exactly is planned to be removed? I remember some overlaps between v1 and v2 as well as not explicitly documented features which worked.

What happens to bosh create-env manifest, will it be documented separately? As of now, it's a mix of both (v1 and v2) because it should support cloud properties.

Good time to update bosh-deployment btw.

Re: Removing Support for v1 Style Manifests

Corey Innis
 

+100 ... big proponent of making v1 manifests obsolete.

Cheers,
Corey

On Mon, Mar 18, 2019 at 6:29 PM Ronak Banka <ronakbanka.cse@...> wrote:
Great job BOSH team 👏🏻

On Tue, 19 Mar 2019 at 12:36 AM, Morgan Fine <mfine@...> wrote:
Friends of BOSH & CF,

In the olden days of BOSH, all IaaS configuration was done in individual deployment manifests, a la "v1 manifests". This became tedious and difficult for operators to mange. 

In order to abstract IaaS configuration, and simplify the operator workflow, BOSH added support for "v2 manifests". This introduced a concept called Cloud Config in order to consolidate IaaS configuration in a single file. The new "v2 manifests" reference IaaS concepts/objects from the Cloud Config and were more reusable across infrastructures.

Support for "v2 manifests" was added over 2 years ago. We believe this has given ample time for operators and release authors to migrate and stop relying on v1 syntax. Thus, the time has come where the BOSH team would like to simplify the code base and formally remove support for "v1 manifests". 

If you have any feedback about this change, please let us know.

For reference:
v1 manifest documentation: https://bosh.io/docs/deployment-manifest/
v2 manifest documentation: https://bosh.io/docs/manifest-v2/

Best,
Morgan Fine
CF BOSH

Re: Removing Support for v1 Style Manifests

Ronak Banka
 

Great job BOSH team 👏🏻

On Tue, 19 Mar 2019 at 12:36 AM, Morgan Fine <mfine@...> wrote:
Friends of BOSH & CF,

In the olden days of BOSH, all IaaS configuration was done in individual deployment manifests, a la "v1 manifests". This became tedious and difficult for operators to mange. 

In order to abstract IaaS configuration, and simplify the operator workflow, BOSH added support for "v2 manifests". This introduced a concept called Cloud Config in order to consolidate IaaS configuration in a single file. The new "v2 manifests" reference IaaS concepts/objects from the Cloud Config and were more reusable across infrastructures.

Support for "v2 manifests" was added over 2 years ago. We believe this has given ample time for operators and release authors to migrate and stop relying on v1 syntax. Thus, the time has come where the BOSH team would like to simplify the code base and formally remove support for "v1 manifests". 

If you have any feedback about this change, please let us know.

For reference:
v1 manifest documentation: https://bosh.io/docs/deployment-manifest/
v2 manifest documentation: https://bosh.io/docs/manifest-v2/

Best,
Morgan Fine
CF BOSH

Removing Support for v1 Style Manifests

Morgan Fine
 

Friends of BOSH & CF,

In the olden days of BOSH, all IaaS configuration was done in individual deployment manifests, a la "v1 manifests". This became tedious and difficult for operators to mange. 

In order to abstract IaaS configuration, and simplify the operator workflow, BOSH added support for "v2 manifests". This introduced a concept called Cloud Config in order to consolidate IaaS configuration in a single file. The new "v2 manifests" reference IaaS concepts/objects from the Cloud Config and were more reusable across infrastructures.

Support for "v2 manifests" was added over 2 years ago. We believe this has given ample time for operators and release authors to migrate and stop relying on v1 syntax. Thus, the time has come where the BOSH team would like to simplify the code base and formally remove support for "v1 manifests". 

If you have any feedback about this change, please let us know.

For reference:
v1 manifest documentation: https://bosh.io/docs/deployment-manifest/
v2 manifest documentation: https://bosh.io/docs/manifest-v2/

Best,
Morgan Fine
CF BOSH

Re: Moving BPM out of Incubation

Marco Voelz
 

Thanks Christopher!

 

I haven't forgotten about your proposal, we're going to vote on it during our BOSH PMC meeting on March 21st. Sorry it took so long, we had to sort out some logistics around all of this.

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of Christopher Brown <cbrown@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Tuesday, 5. February 2019 at 01:26
To: "cf-bosh@..." <cf-bosh@...>
Subject: Re: [cf-bosh] Moving BPM out of Incubation

 

I work on it 1-2 days per week. BPM v1 is pretty much feature complete and I anticipate that most of the work from now on will be refinements.

At some point we'll start seriously considering what the next steps for v2 are. At that point I expect the time spent on it and the feature work to ramp back up again.

Thanks and all the best,
Christopher

Announcement: Regular BOSH PMC meetings

Marco Voelz
 

[cross-posting lists for visibility]

 

Dear Friends of BOSH,

 

We are about to have our first BOSH PMC meeting!

 

When?

Thursday, March 21st, 8AM Pacific Time

Afterwards: Every third Thursday of the month in the same timeslot.

 

Where?

http://zoom.bosh.io

 

What is this all about?

Similarly to the existing PMC meetings, the BOSH PMC meeting is for announcements, updates, and outlook for all active projects within the BOSH PMC [1]. After a meeting, you can find the meeting minutes in pmc-notes/bosh on github [2]. If you want to see topics discussed at the meeting, we appreciate a heads-up a few days before the meeting, either via mail on cf-bosh@... or by making a pull request to the agenda document.

 

According to the Cloud Foundry Foundation's Governance documents, all companies with at least one full-time contributor on an active project get a vote to be issued by a representative. Others can join, but not vote on decisions, such as incubating new projects or promoting a project from incubation to active.

For more information on the organization within a Cloud Foundry PMC, please refer to the official Cloud Foundry Foundation Governance Documents [3].

 

Warm regards

Marco

 

[1] https://docs.google.com/a/pivotal.io/spreadsheets/d/1hg0EA3aB9wiCq8SgCU90ft4qrHvczsUjK0W_31APWxM

[2] https://github.com/cloudfoundry/pmc-notes/tree/master/Bosh

[3] https://www.cloudfoundry.org/wp-content/uploads/2015/09/CFF_Development_Governance.pdf

Two questions about BOSH CPI Certification

"李冰(张嶷) <zhangyi.lb@...>
 

Dear BOSH team.


I have another topic about BOSH CPI Certification. We aim to get Alibaba Cloud BOSH CPI passed BOSH CPI Certification (https://github.com/cloudfoundry-incubator/bosh-cpi-certification). Now we are still in development, but assume very soon we will submit a PR to include Alibaba Cloud directory into this repo, and corresponding pipeline yml file and CI tasks will be there.


Now, I have two questions regarding the integration process.

 

1)      At the beginning of certification, CI will run Terraform to build network environment. The question is about who owns the IaaS infrastructure, saying Alibaba Cloud BOSH team will own the account or CF community should own the account

 

2)      Per our understanding, a new CPI release (bosh-cpi-release) will trigger BOSH CPI Certification CI. If CI failed, what is the follow up procedures to get CPI release roll-back or be fixed?


Thank you in advance.


李冰(Bing LI)

电话:+86 13691202002

邮箱:zhangyi.lb@alibaba-inc.com


Ask for CF Community Process of building light stemcell

"李冰(张嶷) <zhangyi.lb@...>
 

Dear BOSH team,


I am seeking for helps on how to get Alibaba Cloud Light Stemcell Builder and Stemcell CIs integrated with the CF community process of building light stemcells.

 

I have the following questions and sorry for asking them in one batch, so adding #number for easy tracking.

 

1)      Do we need a Cloud Foundry active project for AliCloud light stemcell builder in GitHub CF org, like this one https://github.com/cloudfoundry/bosh-aws-light-stemcell-builder? Or can we just use AliCloud light stemcell builder in Aliyun org, like this one https://github.com/aliyun/bosh-alicloud-light-stemcell-builder/tree/dev

 

2)      There is one step in Stemcell CI pipeline to upload full stemcell to an object storage bucket. In our case, we need to upload it to an AliCloud OSS bucket. The question is that who should be the owner of this OSS bucket. Is it owned by AliCloud BOSH team or CF Community? This is about how to fetch the Access Key (AK).

 

3)      After the step of light stemcell verification in Stemcell CI pipeline, if passed, it’s about to publish this light stemcell to S3 bucket then generate a meta4 file. For this S3 bucket, is it owned by CF Community?

 

4)      Once the meta4 file is generated, what is the process to update it into bosh.io/stemcells-cpi-index (https://github.com/bosh-io/stemcells-cpi-index)?

 

5)      At the end, AliCloud will make the custom image public available, however, there is a manual process sitting behind. Is it acceptable? If not, we’d better to know any best practices to automatically make a custom image public.

 

6)      Finally, how to publish light stemcell to bosh.io? Assume someone from CF community will make it happen, right?


Thanks for your time and looking forward to your feedback.


李冰(Bing LI)

电话:+86 13691202002

邮箱:zhangyi.lb@alibaba-inc.com


Seeking Nominations: Community Awards

Swarna Podila
 

Dear Cloud Foundry Community,
It is that time of Summit again where we seek your help to nominate yourself or your peers for the Community Awards that will be presented at Cloud Foundry Summit in Philadelphia next month.

This year, the nomination categories are:
  • The Quiet Achiever
  • The Advocate
  • The Coolest User Story
More details on each of these categories can be found in this blog [1] and the nomination form can be found here [2].

Nominations close at 11:59 PM on March 14, 2019.  If you have any questions, please do not hesitate to contact me via email or slack.

Thank you,
Swarna.


-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.


Re: upload custom windows stemcell issue

Danny Berger
 

Hi,

Without seeing the full error message, you may want to start by making sure that the ephemeral disk of your director is sufficiently large enough to receive the large stemcell file (+ some overhead, and it might store an additional copy of the image on disk while it's processing).

If increasing the size of ephemeral disk doesn't help, can you please provide the full error message that you're seeing?

Danny


On Sun, Feb 17, 2019 at 10:54 AM Atil Sensalduz <atil.sensalduz@...> wrote:
Hi folks,

When I was trying upload custom windows server 2012R2 stemcell I got the error like this: image-tar: disk1.vmdk: wrote only 7680 of 10240 bytes.
My stemcell tar file size is 12 GB. I have increased client_mac_body_size in the ngnx.conf and blobstore.conf at the director. Which did I stick in the limitation?

best regards



--
Danny Berger

upload custom windows stemcell issue

Atil Sensalduz
 

Hi folks,

When I was trying upload custom windows server 2012R2 stemcell I got the error like this: image-tar: disk1.vmdk: wrote only 7680 of 10240 bytes.
My stemcell tar file size is 12 GB. I have increased client_mac_body_size in the ngnx.conf and blobstore.conf at the director. Which did I stick in the limitation?

best regards

Re: Can't renew bosh-director certificate

Jan-Henrik Christophersen
 

Turns out I didn't regenerate the "default_ca". After regenerating all of them the deployment worked. I'll leave this up hoping it will help someone else if they encounter this.

Can't renew bosh-director certificate

Jan-Henrik Christophersen
 

Hello all,

we failed to renew our director and mbus certificate before they expired and wanted to do that now by using the create-env command. I removed the "director_ssl" and "mbus_bootstrap_ssl" sections and used bosh int with the --vars-store flag to regenerate them. I've manually checked that the certificates are valid for another year.
To deploy this change, I ran the bosh create-env command but I am now running into this issue:

Command:
```
bosh create-env bosh-director/bosh.yml
    --state=xxx/state.json
    --vars-store=xxx/credentials.yml
    -o bosh-director/cpi.yml
    -v access_key_id=xxxxxxx
    -v secret_access_key=xxxxxxx
    -v director_name=bosh-director 
    -v director_instance_profile=xxx
    -v internal_cidr=10.118.132.0/24 
    -v internal_dns=10.118.128.2 
    -v internal_gw=10.118.132.1 
    -v internal_ip=10.118.132.9 
    -v subnet_id=subnet-04a2xxx
    -v region=eu-central-1 
    -v az=eu-central-1a 
    -v default_key_name=bosh
    -v default_security_groups=sg-e88axxx
    -v concourse_security_group=sg-679xxx
    -v concourse_elb=elb
    --ca-cert (interpolated ca cert) # tried with and without this parameter
    --var-file private_key=xxxxxxx.pem
```

Output:
```
Started validating
  Downloading release 'bosh'... Skipped [Found in local cache] (00:00:00)
  Validating release 'bosh'... Finished (00:00:00)
  Downloading release 'bosh-aws-cpi'... Skipped [Found in local cache] (00:00:00)
  Validating release 'bosh-aws-cpi'... Finished (00:00:00)
  Validating cpi release... Finished (00:00:00)
  Validating deployment manifest... Finished (00:00:00)
  Downloading stemcell... Skipped [Found in local cache] (00:00:00)
  Validating stemcell... Finished (00:00:00)
Finished validating (00:00:00)
 
Started installing CPI
  Compiling package 'ruby_aws_cpi/c6ba8a1e1b53b94ee9caf13d2d749c40cecfa038'... Finished (00:00:00)
  Compiling package 'bosh_aws_cpi/137cfc70652337ff1d3fca795e6d9ddd6e7e68dd'... Finished (00:00:00)
  Installing packages... Finished (00:00:01)
  Rendering job templates... Finished (00:00:00)
  Installing job 'aws_cpi'... Finished (00:00:00)
Finished installing CPI (00:00:02)
 
Starting registry... Finished (00:00:00)
Uploading stemcell 'bosh-aws-xen-hvm-ubuntu-trusty-go_agent/3421.9'... Skipped [Stemcell already uploaded] (00:00:00)
 
Started deploying
  Waiting for the agent on VM 'i-099931a2d9xxxxx'... Failed (00:00:00)
  Deleting VM 'i-099931a2d9xxxxx'... Finished (00:00:41)
  Creating VM for instance 'bosh/0' from stemcell 'ami-f7349398 light'... Finished (00:00:38)
  Waiting for the agent on VM 'i-07711bc8a06xxxxx' to be ready...
channel 2: open failed: connect failed: Connection refused
channel 2: open failed: connect failed: Connection refused
...
 Failed (00:00:34)
Failed deploying (00:02:05)
 
Stopping registry... Finished (00:00:00)
Cleaning up rendered CPI jobs... Finished (00:00:00)

Deploying:
  Creating instance 'bosh/0':
    Waiting until instance is ready:
      Post https://mbus:<redacted>@10.118.132.9:6868/agent: x509: certificate has expired or is not yet valid
```

bosh-director/bosh.yml
```
---
name: bosh
 
releases:
- name: bosh
  version: "262.3"
  url: https://s3.amazonaws.com/bosh-compiled-release-tarballs/bosh-262.3-ubuntu-trusty-3421.9-20170706-183731-831697577-20170706183736.tgz?versionId=7GmwKfufgb5JwWhJ.cwIWLnejOtm2Hu4
  sha1: 1eae3f06282417e54ebb199656458f9d6c38e2af
 
resource_pools:
- name: vms
  network: default
  env:
    bosh:
      password: '*'
      mbus:
        cert: ((mbus_bootstrap_ssl))
 
disk_pools:
- name: disks
  disk_size: 32_768
 
networks:
- name: default
  type: manual
  subnets:
  - range: ((internal_cidr))
    gateway: ((internal_gw))
    static: [((internal_ip))]
    dns: [((internal_dns))]
 
instance_groups:
- name: bosh
  instances: 1
  jobs:
  - {name: nats, release: bosh}
  - {name: postgres-9.4, release: bosh}
  - {name: blobstore, release: bosh}
  - {name: director, release: bosh}
  - {name: health_monitor, release: bosh}
  resource_pool: vms
  persistent_disk_pool: disks
  networks:
  - name: default
    static_ips: [((internal_ip))]
  properties:
    nats:
      address: 127.0.0.1
      user: nats
      password: ((nats_password))
    postgres: &db
      listen_address: 127.0.0.1
      host: 127.0.0.1
      user: postgres
      password: ((postgres_password))
      database: bosh
      adapter: postgres
    blobstore:
      address: ((internal_ip))
      port: 25250
      provider: dav
      director:
        user: director
        password: ((blobstore_director_password))
      agent:
        user: agent
        password: ((blobstore_agent_password))
    director:
      address: 127.0.0.1
      name: ((director_name))
      db: *db
      flush_arp: true
      enable_post_deploy: true
      generate_vm_passwords: true
      enable_dedicated_status_worker: true
      enable_nats_delivered_templates: true
      workers: 4
      events:
        record_events: true
      ssl:
        key: ((director_ssl.private_key))
        cert: ((director_ssl.certificate))
      user_management:
        provider: local
        local:
          users:
          - name: admin
            password: ((admin_password))
          - name: hm
            password: ((hm_password))
    hm:
      director_account:
        user: hm
        password: ((hm_password))
        ca_cert: ((director_ssl.ca))
      resurrector_enabled: true
    ntp: &ntp
    - time1.google.com
    - time2.google.com
    - time3.google.com
    - time4.google.com
    agent:
      mbus: nats://nats:((nats_password))@((internal_ip)):4222
 
cloud_provider:
  mbus: https://mbus:((mbus_bootstrap_password))@((internal_ip)):6868
  cert: ((mbus_bootstrap_ssl))
  properties:
    agent: {mbus: "https://mbus:((mbus_bootstrap_password))@0.0.0.0:6868"}
    blobstore: {provider: local, path: /var/vcap/micro_bosh/data/cache}
    ntp: *ntp
 
variables:
- name: admin_password
  type: password
- name: blobstore_director_password
  type: password
- name: blobstore_agent_password
  type: password
- name: hm_password
  type: password
- name: mbus_bootstrap_password
  type: password
- name: nats_password
  type: password
- name: postgres_password
  type: password
- name: default_ca
  type: certificate
  options:
    is_ca: true
    common_name: ca
- name: mbus_bootstrap_ssl
  type: certificate
  options:
    ca: default_ca
    common_name: ((internal_ip))
    alternative_names: [((internal_ip))]
- name: director_ssl
  type: certificate
  options:
    ca: default_ca
    common_name: ((internal_ip))
    alternative_names: [((internal_ip))]
```

Can anyone point out what I am doing wrong here? I only have limited experience with bosh and didn't have to regenerate certificates before. The person who originally deployed this is also not around.

Thanks,
Jan

Re: Which OpenStack version is supported by Cloud Foundry?

Marco Voelz
 

Hey,

 

Thanks for pointing out that the docs at per https://bosh.io/docs/init-openstack/ are outdated. We will fix that hopefully soon and link to the correct documents.

The information at  https://github.com/cloudfoundry/bosh-openstack-cpi-release#supported-openstack-versions is correct: we test against the officially supported versions of OpenStack.

 

Let me know if you have further questions.

 

Warm regards

Marco

 

 

From: <cf-bosh@...> on behalf of R M <rishi.investigate@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Friday, 8. February 2019 at 23:31
To: "cf-bosh@..." <cf-bosh@...>
Subject: [cf-bosh] Which OpenStack version is supported by Cloud Foundry?

 

Folks,

 

I am trying to determine which version of OpenStack is supported by Cloud Foundry.  As per https://bosh.io/docs/init-openstack/ it mentions Liberty/Mikata/Newton as being supported and actively tested.  Does this still hold as all of the mentioned releases are EOL?

 

As per https://github.com/cloudfoundry/bosh-openstack-cpi-release#supported-openstack-versions - it mentions upstream OpenStack policy which seems to contradict with what is listed on bosh.io.

 

Thanks for any insight you can provide.