Date   

[cf-dev] [CFEU2019 Registration] Contributor Code

Swarna Podila
 

I meant to share this with the bosh folks as well; apologies for the miss on my part.

Please make note of the Contributor Summit at Cloud Foundry Summit EU (Sep 10) while making travel plans to The Hague.

Please also note the Contributor code for Cloud Foundry Summit EU registration if you're a current or a past Cloud Foundry Contributor.

-- 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.


---------- Forwarded message ---------
From: Swarna Podila via Lists.Cloudfoundry.Org <spodila=cloudfoundry.org@...>
Date: Tue, May 14, 2019 at 3:45 PM
Subject: Re: [cf-dev] [CFEU2019 Registration] Contributor Code
To: CF Developers Mailing List <cf-dev@...>


Dear Cloud Foundry Contributors,
I just wanted to surface up the Contributor Code email in case you need it to register for Cloud Foundry Summit EU.  

As you are making travel plans, please also note that Contributor Summit will be hosted again as a Day Zero event on Sep 10th.  We are still finalizing the specifics (start/end times, schedule etc.) but please do plan to get The Hague in time for the Contributor Summit.

Thank you.

-- 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.


On Wed, Apr 17, 2019 at 11:18 AM Swarna Podila <spodila@...> wrote:
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.


[Operators SIG Meeting] Call for Content

Swarna Podila
 

Dear Cloud Foundry Community,
Recently, the Cloud Foundry platform operators at SAP initiated an "operators SIG meeting" to bring the operators together and share experiences, good practices, etc.

The recording of the first meeting is here.

The recurring call is scheduled for every fourth Wednesday of the month at 8AM US Pacific; so the next call is on Wednesday, May 22.  If you'd like discuss specific topics, you can either unicast me or add it to the meeting notes.

Join the discussion on Cloud Foundry slack at #cf-operators. 

-- 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.


Vote Today! CF Summit Track Co-Chairs

Swarna Podila
 

Please vote for the track co-chairs who will help shape the content at the next Cloud Foundry Summit Europe.
Deadline: May 13, 11:59PM US Pacific

-- 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.


[Important Notice] End of support for trusty stemcells

Mukesh Gadiya
 

Hi BOSH OSS Community,  

We want to let y'all know that Canonical has stopped providing security updates to Trusty ( Ubuntu 14.04) on April 30th 2019. In BOSH OSS world, this means we can not continue to provide security updates for trusty stemcell line 3586 but will continue to support and ship security patches to Xenial stemcell lines. 


Thanks,

BOSH Systems team


Re: Migrating Bosh-Acceptance-Tests to v2 manifests

Riegger, Felix
 

Hi all,

meanwhile this has been tested against OpenStack. There were only minor changes necessary. These have been integrated into the v2_manifest branch.

Kind regards,
Felix


Re: Migrating Bosh-Acceptance-Tests to v2 manifests

Belinda Liu <bliu@...>
 

Hey Jason and Mike,

Thanks for calling that out. We don't have any environments on hand to test Azure and Openstack, and have synced up with the Openstack CPI and Azure CPI team to test these changes. We don't intend to merge before we get feedback from them. 

Thanks,
Belinda

On Thu, Apr 25, 2019 at 8:06 AM Jason Stevens <Jason.Stevens@...> wrote:
Yes, I’m curious about that, too.  I would think we’d want to test on Azure before a merge.

-jps

Create clarity. Generate energy. Find solutions.

From: cf-bosh@... <cf-bosh@...> on behalf of Mike Lloyd via Lists.Cloudfoundry.Org <mike=reboot3times.org@...>
Sent: Thursday, April 25, 2019 7:25 AM
To: cf-bosh@...
Cc: Belinda Liu; Morgan Fine
Subject: Re: [cf-bosh] Migrating Bosh-Acceptance-Tests to v2 manifests
 

Charles and Belinda,

 

Is there a reason Azure and Openstack are still untested?

 

Thanks,

 

Mike.

 

From: cf-bosh@... <cf-bosh@...>On Behalf Of via Lists.Cloudfoundry.Org
Sent: Wednesday, April 24, 2019 5:46 PM
To: cf-bosh@...
Cc: Belinda Liu <bliu@...>; Morgan Fine <mfine@...>
Subject: [cf-bosh] Migrating Bosh-Acceptance-Tests to v2 manifests

 

Hi Bosh community,

 

tldr; BATs is now on v2 manifests. If you run BATs in your pipeline, please try running against the v2_manifest branchbefore it is merged into master and let us know if you have any feedback. Hopefully it should just work.

 

We are migrating BATs (https://github.com/cloudfoundry/bosh-acceptance-tests) to use v2 manifests + cloud config. Using v2 manifest to deploy on bosh has been the standard for a while, but BATs has never been updated. We hope to deprecate v1 manifests very soon and need to upgrade BATs. Much of the v1 manifest that relates to vms, networks, disks etc is now in cloud config in the v2 world.

 

Specifically, the BATs previously had deployment manifest templates for every IaaS. We have migrated the IaaS details into IaaS specific cloud configs instead, and all BATs will deploy a generic deployment manifest. These can all be found in https://github.com/cloudfoundry/bosh-acceptance-tests/tree/v2_manifest/templates with the `cloud-config-` prefix.

 

We tested vSphere, AWS, GCP, and Warden in our own pipelines, but Azure and Openstack remain untested. BATs also has an Oracle configuration which we did not touch. Additionally, BATs can be configured with a variety of different network topologies, and we only tested a few. Ideally these changes should not affect anyone, but there may be some unforeseen issues. If you are a CPI author and have feedback on these changes, please reach out to the BOSH Director team. Otherwise, these changes will be merged into master next week.

 

Thanks in advance for your feedback,

 

Charles and Belinda, BOSH Director team (SF)


Re: Migrating Bosh-Acceptance-Tests to v2 manifests

Jason Stevens
 

Yes, I’m curious about that, too.  I would think we’d want to test on Azure before a merge.

-jps

Create clarity. Generate energy. Find solutions.


From: cf-bosh@... <cf-bosh@...> on behalf of Mike Lloyd via Lists.Cloudfoundry.Org <mike=reboot3times.org@...>
Sent: Thursday, April 25, 2019 7:25 AM
To: cf-bosh@...
Cc: Belinda Liu; Morgan Fine
Subject: Re: [cf-bosh] Migrating Bosh-Acceptance-Tests to v2 manifests
 

Charles and Belinda,

 

Is there a reason Azure and Openstack are still untested?

 

Thanks,

 

Mike.

 

From: cf-bosh@... <cf-bosh@...>On Behalf Of via Lists.Cloudfoundry.Org
Sent: Wednesday, April 24, 2019 5:46 PM
To: cf-bosh@...
Cc: Belinda Liu <bliu@...>; Morgan Fine <mfine@...>
Subject: [cf-bosh] Migrating Bosh-Acceptance-Tests to v2 manifests

 

Hi Bosh community,

 

tldr; BATs is now on v2 manifests. If you run BATs in your pipeline, please try running against the v2_manifest branchbefore it is merged into master and let us know if you have any feedback. Hopefully it should just work.

 

We are migrating BATs (https://github.com/cloudfoundry/bosh-acceptance-tests) to use v2 manifests + cloud config. Using v2 manifest to deploy on bosh has been the standard for a while, but BATs has never been updated. We hope to deprecate v1 manifests very soon and need to upgrade BATs. Much of the v1 manifest that relates to vms, networks, disks etc is now in cloud config in the v2 world.

 

Specifically, the BATs previously had deployment manifest templates for every IaaS. We have migrated the IaaS details into IaaS specific cloud configs instead, and all BATs will deploy a generic deployment manifest. These can all be found in https://github.com/cloudfoundry/bosh-acceptance-tests/tree/v2_manifest/templates with the `cloud-config-` prefix.

 

We tested vSphere, AWS, GCP, and Warden in our own pipelines, but Azure and Openstack remain untested. BATs also has an Oracle configuration which we did not touch. Additionally, BATs can be configured with a variety of different network topologies, and we only tested a few. Ideally these changes should not affect anyone, but there may be some unforeseen issues. If you are a CPI author and have feedback on these changes, please reach out to the BOSH Director team. Otherwise, these changes will be merged into master next week.

 

Thanks in advance for your feedback,

 

Charles and Belinda, BOSH Director team (SF)


Re: Migrating Bosh-Acceptance-Tests to v2 manifests

Mike Lloyd <mike@...>
 

Charles and Belinda,

 

Is there a reason Azure and Openstack are still untested?

 

Thanks,

 

Mike.

 

From: cf-bosh@... <cf-bosh@...> On Behalf Of via Lists.Cloudfoundry.Org
Sent: Wednesday, April 24, 2019 5:46 PM
To: cf-bosh@...
Cc: Belinda Liu <bliu@...>; Morgan Fine <mfine@...>
Subject: [cf-bosh] Migrating Bosh-Acceptance-Tests to v2 manifests

 

Hi Bosh community,

 

tldr; BATs is now on v2 manifests. If you run BATs in your pipeline, please try running against the v2_manifest branch before it is merged into master and let us know if you have any feedback. Hopefully it should just work.

 

We are migrating BATs (https://github.com/cloudfoundry/bosh-acceptance-tests) to use v2 manifests + cloud config. Using v2 manifest to deploy on bosh has been the standard for a while, but BATs has never been updated. We hope to deprecate v1 manifests very soon and need to upgrade BATs. Much of the v1 manifest that relates to vms, networks, disks etc is now in cloud config in the v2 world.

 

Specifically, the BATs previously had deployment manifest templates for every IaaS. We have migrated the IaaS details into IaaS specific cloud configs instead, and all BATs will deploy a generic deployment manifest. These can all be found in https://github.com/cloudfoundry/bosh-acceptance-tests/tree/v2_manifest/templates with the `cloud-config-` prefix.

 

We tested vSphere, AWS, GCP, and Warden in our own pipelines, but Azure and Openstack remain untested. BATs also has an Oracle configuration which we did not touch. Additionally, BATs can be configured with a variety of different network topologies, and we only tested a few. Ideally these changes should not affect anyone, but there may be some unforeseen issues. If you are a CPI author and have feedback on these changes, please reach out to the BOSH Director team. Otherwise, these changes will be merged into master next week.

 

Thanks in advance for your feedback,

 

Charles and Belinda, BOSH Director team (SF)


Migrating Bosh-Acceptance-Tests to v2 manifests

Charles Hansen <chansen@...>
 

Hi Bosh community,

tldr; BATs is now on v2 manifests. If you run BATs in your pipeline, please try running against the v2_manifest branch before it is merged into master and let us know if you have any feedback. Hopefully it should just work.

We are migrating BATs (https://github.com/cloudfoundry/bosh-acceptance-tests) to use v2 manifests + cloud config. Using v2 manifest to deploy on bosh has been the standard for a while, but BATs has never been updated. We hope to deprecate v1 manifests very soon and need to upgrade BATs. Much of the v1 manifest that relates to vms, networks, disks etc is now in cloud config in the v2 world.

Specifically, the BATs previously had deployment manifest templates for every IaaS. We have migrated the IaaS details into IaaS specific cloud configs instead, and all BATs will deploy a generic deployment manifest. These can all be found in https://github.com/cloudfoundry/bosh-acceptance-tests/tree/v2_manifest/templates with the `cloud-config-` prefix.

We tested vSphere, AWS, GCP, and Warden in our own pipelines, but Azure and Openstack remain untested. BATs also has an Oracle configuration which we did not touch. Additionally, BATs can be configured with a variety of different network topologies, and we only tested a few. Ideally these changes should not affect anyone, but there may be some unforeseen issues. If you are a CPI author and have feedback on these changes, please reach out to the BOSH Director team. Otherwise, these changes will be merged into master next week.

Thanks in advance for your feedback,

Charles and Belinda, BOSH Director team (SF)


Re: Cloud Foundry Operators SIG

Swarna Podila
 

Kicking off in a few hours is the first cf-operators sig meeting.  Don’t forget to join: at 5AM US Eastern | 11AM CET. 

Topic: Cloud Foundry Operators SIG Meeting
Time: Apr 24, 2019 2:00 AM Pacific Time (US and Canada)

Join Zoom Meeting

One tap mobile
+16699006833,,4084184280# US (San Jose)
+19292056099,,4084184280# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 929 205 6099 US (New York)
Meeting ID: 408 418 4280
Find your local number: https://zoom.us/u/ali1NKUd8


On Thu, Apr 18, 2019 at 19:08 Swarna Podila <spodila@...> wrote:
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.
--
-- Swarna Podila
Senior Director, Community | Cloud Foundry Foundation
spodila@...
@skpodila


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

121 - 140 of 2745