Date   
Which OpenStack version is supported by Cloud Foundry?

R M
 

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.


Reminder about our CoC and a change to the slack configuration

Chip Childers
 

All,

Over the weekend, there were several reports of inappropriate content being shared within the CF community's slack team in various channels. These messages have been removed and the accounts that posted them have been disabled.

We'd like to take this opportunity to remind everyone that we take breaches of our code of conduct very seriously. Our code of conduct can be found here: https://www.cloudfoundry.org/code-of-conduct/ 

While these occurrences were likely caused by people outside of our community taking advantage of the fact that our slack instance is open to everyone, it's important for community members to help ensure that we have a welcoming and inclusive environment.

If you see any inappropriate content posted to slack or have any code of conduct concerns, we ask that you reach out to the CFF via conduct@...We also ask that those that have administrative access to the slack team help with policing when / if they see something. If you do have administrative access and see inappropriate content, please help by (1) deleting the messages, (2) capturing a screenshot of the offending content and (3) notifying the CFF staff at conduct@....

Also note: due to reports of similar activity in other community slack teams having included tagging @channel and @here in postings of inappropriate content, we have disabled the use of those for non-admin users. This is to reduce the impact of any bad actor's actions.

Please reach out to me directly (cchilders@...) or the conduct@ email address if you have any questions or concerns.

Chip Childers, CTO
Cloud Foundry Foundation

Re: Moving BPM out of Incubation

Christopher Brown
 

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: Moving BPM out of Incubation

Marco Voelz
 

Dear Christopher,

 

Thanks for the proposal! Sorry for not following up on this sooner. A question which currently comes to my mind given the proposed transition to an 'active' project is: How active is BPM nowadays? What does the current BPM team look like and how much time do the team members spend on BPM?

 

I'll reach out to the individual PMC members and get their vote on the issue in the next week.

 

Thanks and warm regards

Marco

 

From: <cf-bosh@...> on behalf of Christopher Brown <cbrown@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Thursday, 17. January 2019 at 20:32
To: "Discussions about the Cloud Foundry BOSH project." <cf-bosh@...>
Cc: aram price <aprice@...>, James Myers <jmyers@...>
Subject: [cf-bosh] Moving BPM out of Incubation

 

Hi everyone,

 

We'd like to propose moving the BPM project from the incubator into general availability during the next BOSH PMC meeting. 

 

bpm-release version 1.0 was released in November last year and is being used by many releases to provide a consistent and isolated sandbox environment for BOSH jobs.

 

What do you think?

 

Thanks,

Christopher

Re: Unconference in Philadelphia - Talks Please!

Dr Nic Williams
 

Hurray for the Unconference!

Nic

 


From: cf-bosh@... on behalf of Daniel Jones <daniel.jones@...>
Sent: Thursday, January 24, 2019 10:11 am
To: Discussions about Cloud Foundry projects and the system overall.; Discussions about the Cloud Foundry BOSH project.
Subject: [cf-bosh] Unconference in Philadelphia - Talks Please!
 
Hi lovely CF peeps,

We're seeking short talk proposals for the CF Summit NA 2019 Unconference. If you've got something cool, off-the-wall, or maybe that didn't quite fit the main conference criteria, then please make a proposal! 

We want to have a couple of scheduled talks so that potential attendees have some certainty about what knowledge will be imparted upon them. Other than that, we'll be allowing plenty of time for open space discussions (more than in Basel!).

In Basel last year a whopping 20% of all summit attendees came to the Unconference, so it's a great opportunity to engage your peers in conversation and learn from each other. Whilst SAP are already sponsors, we're looking for more - so if you want a way to reach a large portion of the summit audience directly, please get in touch.

We're also bringing the Cloud Foundry Pub Quiz to North America for the first time - expect beer, rubbish jokes, obscure trivia, and lively debates about whether the questions make sense!



Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists

Unconference in Philadelphia - Talks Please!

Daniel Jones
 

Hi lovely CF peeps,

We're seeking short talk proposals for the CF Summit NA 2019 Unconference. If you've got something cool, off-the-wall, or maybe that didn't quite fit the main conference criteria, then please make a proposal! 

We want to have a couple of scheduled talks so that potential attendees have some certainty about what knowledge will be imparted upon them. Other than that, we'll be allowing plenty of time for open space discussions (more than in Basel!).

In Basel last year a whopping 20% of all summit attendees came to the Unconference, so it's a great opportunity to engage your peers in conversation and learn from each other. Whilst SAP are already sponsors, we're looking for more - so if you want a way to reach a large portion of the summit audience directly, please get in touch.

We're also bringing the Cloud Foundry Pub Quiz to North America for the first time - expect beer, rubbish jokes, obscure trivia, and lively debates about whether the questions make sense!



Regards,
Daniel 'Deejay' Jones - CTO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists

Moving BPM out of Incubation

Christopher Brown
 

Hi everyone,

We'd like to propose moving the BPM project from the incubator into general availability during the next BOSH PMC meeting. 

bpm-release version 1.0 was released in November last year and is being used by many releases to provide a consistent and isolated sandbox environment for BOSH jobs.

What do you think?

Thanks,
Christopher

Re: BOSH vision and strategy

Mike Youngstrom
 

I think this looks great.  Nice work!  +1 for IPv6 support.  Getting iIPv6 into bosh will hopefully help bubble support for that up the stack and into CF.

Mike



On Wed, Dec 19, 2018 at 6:15 AM Frédéric Desbiens <fdesbiens@...> wrote:
 

Hi BOSH community!


When Marco, Morgan and myself started in our roles in the BOSH project management committee (PMC), one of our primary objectives was to give the community more visibility into our roadmap. It took us a bit more time than expected, but we finally put together a document that explains our vision and strategy for BOSH. It is my pleasure to finally share it with you today. You can access it here: https://docs.google.com/document/d/1pa-d7aC707dK9vvZUYIu9iytYzM9oM8YK-0M4vTp1rA/edit?usp=sharing


By making this document public, we hope to start a conversation with you. We wish to make sure we are building the right features for our users. This will be impossible without your comments and suggestions. Please let us know what you think.  


Priorities evolve over time. A roadmap is never set in stone; we want to evolve ours according to your feedback. We aim to publish new versions of the document on a regular basis to let you know where we are headed.


Thank you for reading this, and for being a part of the BOSH community!


Best Regards,  


Frédéric Desbiens

Product Manager

Project Lead, BOSH Core Toronto project


BOSH vision and strategy

Frédéric Desbiens
 

 

Hi BOSH community!


When Marco, Morgan and myself started in our roles in the BOSH project management committee (PMC), one of our primary objectives was to give the community more visibility into our roadmap. It took us a bit more time than expected, but we finally put together a document that explains our vision and strategy for BOSH. It is my pleasure to finally share it with you today. You can access it here: https://docs.google.com/document/d/1pa-d7aC707dK9vvZUYIu9iytYzM9oM8YK-0M4vTp1rA/edit?usp=sharing


By making this document public, we hope to start a conversation with you. We wish to make sure we are building the right features for our users. This will be impossible without your comments and suggestions. Please let us know what you think.  


Priorities evolve over time. A roadmap is never set in stone; we want to evolve ours according to your feedback. We aim to publish new versions of the document on a regular basis to let you know where we are headed.


Thank you for reading this, and for being a part of the BOSH community!


Best Regards,  


Frédéric Desbiens

Product Manager

Project Lead, BOSH Core Toronto project


Re: [CAUTION] [cf-bosh] CF BOSH PMC: BOSH Core Europe Call for Nominations

Marco Voelz
 

Dear Friends of BOSH,

 

SAP is nominating Felix Riegger as PM for the BOSH Europe Team. Felix has been a developer in the team since 2015 and has been pairing with me for the last few weeks to guarantee a smooth transitioning.

 

Please send any other nominations directly to me or in reply to this message no later than 23:59 GMT on Thursday, December 20, 2018.

 

Warm regards

Marco

 

From: <cf-bosh@...> on behalf of Marco Voelz <marco.voelz@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Friday, 14. December 2018 at 14:31
To: "cf-bosh@..." <cf-bosh@...>, "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Subject: [CAUTION] [cf-bosh] CF BOSH PMC: BOSH Core Europe Call for Nominations

 

Dear Friends of BOSH,

 

I'm rotating into a different role within SAP, which means I'm stepping down from the BOSH Core Europe PM position.

Therefore, the BOSH Core Europe team operating out of Walldorf, Germany, has an opening for its PM. Please send nominations directly to me or in reply to this message no later than 23:59 GMT on Thursday, December 20, 2018.

 

At the same time, I'd like to stay as BOSH PMC lead. A big part of my new role at SAP is concerned with defining and shaping an opinion about the future of BOSH, which should fit nicely to the PMC lead position. If you have any concerns about this, please don't hesitate to contact me.

 

If you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

 

Thanks and warm regards

Marco

 

 

CF BOSH PMC: BOSH Core Europe Call for Nominations

Marco Voelz
 

Dear Friends of BOSH,


I'm rotating into a different role within SAP, which means I'm stepping down from the BOSH Core Europe PM position.

Therefore, the BOSH Core Europe team operating out of Walldorf, Germany, has an opening for its PM. Please send nominations directly to me or in reply to this message no later than 23:59 GMT on Thursday, December 20, 2018.


At the same time, I'd like to stay as BOSH PMC lead. A big part of my new role at SAP is concerned with defining and shaping an opinion about the future of BOSH, which should fit nicely to the PMC lead position. If you have any concerns about this, please don't hesitate to contact me.


If you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks and warm regards
Marco


Re: Telemetry within BOSH

Damzog Jochen (CI/OSC1)
 

Hi Marco and Mike,

 

We have since long time a requirement that is similar. I have noted it down some time ago:

 

Subscription mechanism for events

bosh does have a notion of events, see http://bosh.io/docs/events. These events will be fired on each activity taken by the director o.a. deployments, creation and deletion of vms. These events could very well be used to trigger operations outside of bosh to either prepare or complement the action taken by the director. For example we would like to use these events to trigger creation or deletion of firewall configurations.

In order to use events to trigger external action we require to have a mechanism to subscribe for these events. There are multiple ways to achieve this. For example, the director could forward these events to a messaging system (like rabbitmq) or it could offer a mechanism to register webhooks. 

For our use case of setting up FW rules it would be useful to configure a synchronous coupling between the director action and the external action to ensure FW rules are applied before a particular vms is started. This feature, however, should remain configurable if implemented because many other use cases will probably prefer to be executed asynchronously.

 

 

Mit freundlichen Grüßen / Best regards

Jochen Damzog

Service Integration and Brokering (CI/OSC1)
Robert Bosch GmbH | Postfach 30 02 20 | 70442 Stuttgart | GERMANY
| www.bosch.com
Tel. +49 711 811-18977 | Mobil +49 173 8673114 | Fax +49 711 811 |
Jochen.Damzog@...

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar Denner,
Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Rolf Bulander, Dr. Christian Fischer,
Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller


Von: cf-bosh@... <cf-bosh@...> Im Auftrag von Marco Voelz
Gesendet: Donnerstag, 13. Dezember 2018 16:46
An: cf-bosh@...
Betreff: Re: [cf-bosh] Telemetry within BOSH

 

Dear Mike,

 

Thanks for bringing this up. More insight in what the Director could definitely be helpful for a number of things. 

 

Concerning your use-case, I hope you can help me understand a few points:

  • What is it that you're trying to achieve? My current understanding is that you're trying to run some analytics on the data you want to gather. Let's say you have all the data for your Director – how are you going to use it, specifically?
  • At which level of granularity would you imagine this data to be gathered? When I'm reading 'where the Director spends its time', I'm understanding anything between 'each single statement in the code' to 'each interaction with the IaaS/CPI'.
  • To get a better understanding of where you're coming from: Have you looked at particular libraries/tools/software for this use-case that you want to share as examples when gathering telemetry data for other services you worked with?

 

Thanks and warm regards

Marco


From: cf-bosh@... <cf-bosh@...> on behalf of Mike Lloyd <mike@...>
Sent: Thursday, December 13, 2018 1:12:41 AM
To: cf-bosh@...
Subject: [cf-bosh] Telemetry within BOSH

 

Hey folks,

 

I have an interesting use case in front of me that I’m trying to figure out how to approach both sanely as well as sustainably. I have a use case where I want highly structured telemetry data from the BOSH director for downstream analytics. My target goal of this use case is to have a comprehensive and clear perspective into where BOSH is spending it’s time. I could see any type of telemetry data being immensely useful for operators and CFF developers as it can help give insight into where improvements can be made.

 

Currently I’m exploring 3 options:

  • Dump of the Director database.
    • Pro: Anything that’s logged to the database is available, can be used with external data visualisation solutions.
    • Con: Schema relations and changes with versions make this difficult to sustain; database schema isn’t well documented; potentially lots of SQL script maintenance; only visible for what’s stored in the database.
  • Adding telemetry hooks to the Director and BOSH Agent.
    • Pro: Every action the director takes can be tracked and measured through the majority of BOSH.
    • Cons: Immense amount of initial work; finding a telemetry framework; handling telemetry output.
  • Adding telemetry hooks to the BOSH CLI.
    • Pro: Every action the CLI takes can be tracked and measured.
    • Cons: Only CLI actions can be tracked; immense amount of initial work; finding a telemetry framework; handling telemetry output.

 

Looking across the industry, telemetry is very prevalent, and it’s almost always an opt-in model, so anything I explore . Since I haven’t seen anything like this discussed in the mailing lists before, I wanted to surface my explorations to get others’ thoughts and opinions on telemetry within BOSH.

 

Respectfully,

 

Mike Lloyd

t: @mxplusc

g: @mxplusb
Professional Member, ACM

 

Re: Telemetry within BOSH

Marco Voelz
 

Dear Mike,


Thanks for bringing this up. More insight in what the Director could definitely be helpful for a number of things. 


Concerning your use-case, I hope you can help me understand a few points:

  • What is it that you're trying to achieve? My current understanding is that you're trying to run some analytics on the data you want to gather. Let's say you have all the data for your Director – how are you going to use it, specifically?
  • At which level of granularity would you imagine this data to be gathered? When I'm reading 'where the Director spends its time', I'm understanding anything between 'each single statement in the code' to 'each interaction with the IaaS/CPI'.
  • To get a better understanding of where you're coming from: Have you looked at particular libraries/tools/software for this use-case that you want to share as examples when gathering telemetry data for other services you worked with?

Thanks and warm regards
Marco


From: cf-bosh@... <cf-bosh@...> on behalf of Mike Lloyd <mike@...>
Sent: Thursday, December 13, 2018 1:12:41 AM
To: cf-bosh@...
Subject: [cf-bosh] Telemetry within BOSH
 

Hey folks,

 

I have an interesting use case in front of me that I’m trying to figure out how to approach both sanely as well as sustainably. I have a use case where I want highly structured telemetry data from the BOSH director for downstream analytics. My target goal of this use case is to have a comprehensive and clear perspective into where BOSH is spending it’s time. I could see any type of telemetry data being immensely useful for operators and CFF developers as it can help give insight into where improvements can be made.

 

Currently I’m exploring 3 options:

  • Dump of the Director database.
    • Pro: Anything that’s logged to the database is available, can be used with external data visualisation solutions.
    • Con: Schema relations and changes with versions make this difficult to sustain; database schema isn’t well documented; potentially lots of SQL script maintenance; only visible for what’s stored in the database.
  • Adding telemetry hooks to the Director and BOSH Agent.
    • Pro: Every action the director takes can be tracked and measured through the majority of BOSH.
    • Cons: Immense amount of initial work; finding a telemetry framework; handling telemetry output.
  • Adding telemetry hooks to the BOSH CLI.
    • Pro: Every action the CLI takes can be tracked and measured.
    • Cons: Only CLI actions can be tracked; immense amount of initial work; finding a telemetry framework; handling telemetry output.

 

Looking across the industry, telemetry is very prevalent, and it’s almost always an opt-in model, so anything I explore . Since I haven’t seen anything like this discussed in the mailing lists before, I wanted to surface my explorations to get others’ thoughts and opinions on telemetry within BOSH.

 

Respectfully,

 

Mike Lloyd

t: @mxplusc

g: @mxplusb
Professional Member, ACM

 

Telemetry within BOSH

Mike Lloyd
 

Hey folks,

 

I have an interesting use case in front of me that I’m trying to figure out how to approach both sanely as well as sustainably. I have a use case where I want highly structured telemetry data from the BOSH director for downstream analytics. My target goal of this use case is to have a comprehensive and clear perspective into where BOSH is spending it’s time. I could see any type of telemetry data being immensely useful for operators and CFF developers as it can help give insight into where improvements can be made.

 

Currently I’m exploring 3 options:

  • Dump of the Director database.
    • Pro: Anything that’s logged to the database is available, can be used with external data visualisation solutions.
    • Con: Schema relations and changes with versions make this difficult to sustain; database schema isn’t well documented; potentially lots of SQL script maintenance; only visible for what’s stored in the database.
  • Adding telemetry hooks to the Director and BOSH Agent.
    • Pro: Every action the director takes can be tracked and measured through the majority of BOSH.
    • Cons: Immense amount of initial work; finding a telemetry framework; handling telemetry output.
  • Adding telemetry hooks to the BOSH CLI.
    • Pro: Every action the CLI takes can be tracked and measured.
    • Cons: Only CLI actions can be tracked; immense amount of initial work; finding a telemetry framework; handling telemetry output.

 

Looking across the industry, telemetry is very prevalent, and it’s almost always an opt-in model, so anything I explore . Since I haven’t seen anything like this discussed in the mailing lists before, I wanted to surface my explorations to get others’ thoughts and opinions on telemetry within BOSH.

 

Respectfully,

 

Mike Lloyd

t: @mxplusc

g: @mxplusb
Professional Member, ACM

 

Reduce syslog redundancy in linux-stemcells

Dewald, Manuel
 

Hi all,

we observed that in the current configuration BOSH-deployed VMs consume a lot of disk space by writing redundant log files. As an example, currently syslog writes all output to /var/log/syslog and /var/log/messages. This seems to be due to the compatibility to CentOS and Ubuntu default behaviour.

To reduce the redundancy in the logs of bosh-deployed VMs, we want to change the rsyslog config file[1]. We propose the following changes:
- As default log file use /var/log/syslog on Ubuntu and /var/log/messages on CentOS
- Don't write debug, lpr.log, mail.*, user.log and news.* files.

Please review our PR[2] and let us know if you have any objections, which might be the case if you rely on the current behaviour.

[1] https://github.com/beyhan/bosh-linux-stemcell-builder/blob/master/stemcell_builder/stages/rsyslog_config/assets/rsyslog_50-default.conf
[2] https://github.com/cloudfoundry/bosh-linux-stemcell-builder/pull/75

Kind regards,
Kai & Manuel

Cloud Foundry Summit (Philadelphia): CFP Deadline

Swarna Podila
 

A friendly reminder to you all:
The deadline for submitting your speaking proposals to Cloud Foundry Summit North America 2019 is this Friday, Nov 30.  Please get your proposals in before 11.59pm US Pacific.  As we mentioned earlier, there will not be an extension to this deadline.

If you'd like to get feedback on your abstract or would like for it to be reviewed for a sanity-check, please don't hesitate to "@cfp-help" in #summit channel on CF Slack.

Get started at: https://www.cloudfoundry.org/event/nasummit2019/

--Swarna.

Using credhub 2.0.2 with bosh 268.3.0 cause variable generation errors during deployments

kansberry@...
 

We have download the latest repo from https://github.com/cloudfoundry/bosh-deployment, which uses bosh 268.3.0 in conjunction with credhub 2.0.2. However, when I am attempting to have bosh deploy concourse, it fails to generate all variables with the following error:

The request could not be completed because the credential does not exist or you do not have sufficient authorization.

Has anyone seen this issue and, more importantly, found a solution?

Thanks,
Kevin

Re: BOSH / CF - stop / start during maintenance

sinisa.zec <sinisa.zec@...>
 

Hello,

I found your message here. It is rather old message, but I was intrigued
because I am looking for the solution that you already implemented:

"We have deployed BOSH / CF on vSphere. There are two hosts (each host is
AZ) and vm's are distributed between these two hosts. microBOSH, BOSH and CF
all three are co-located in these two hosts. "

Can you please explain me how did you do this? This is what I want to do:
I have two vSphere hosts in the same network segment. I have installed BOSH
Director on one of those hosts. I would like to deploy Cloud Foundry to the
(vSphere) cloud, but I would like that instances of Cloud Foundry be
distributed between those two hosts (for instance "half" instances on one
host and "other half" on another ). Is there a way to do this via bosh
deploy?

best regards,
Sinisa




--
Sent from: http://cf-bosh.70367.x6.nabble.com/

Please vote: Summit NA Track Co-chairs

Swarna Podila
 

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

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

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

Thank you,
Swarna.

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

Marco Voelz
 

Dear friends of BOSH,

 

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

 

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

 

Warm regards

Marco

 

 

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

 

Der friends of BOSH,

 

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

 

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

 

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

 

Warm regards

Marco

 

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

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

 

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

 

Dear friends of BOSH,

 

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

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

 

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

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

 

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

 

Warm regards

Marco

 

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