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

 

 

Seeking nominations for track co-chairs for Philly Summit

Swarna Podila
 

Dear Cloud Foundry Community,
Cloud Foundry Summits are successful, educational, and valuable to our community only because our track co-chair volunteers strive to bring as many high quality talks to Summit as they possibly can.  We thank all those folks who have helped in making Summit tracks valuable to our community.

It is now time for you to step up and nominate yourself or your peer to be a co-chair.   The deadline for nominations is Nov 6, 2018 at 11:59 PST.  I wrote a quick post to help answer any questions you may have about being a co-chair, but please feel free to reach out to me (slack or email) if there is an additional question.

Get nominating today!

--Swarna.

Re: BOSH Stemcell Support Policy

Marco Voelz
 

Dear Morgan,

 

I don't have the rights to comment in the attached document, so I guess I'll leave my comments here.

 

We should specifically mention how we're dealing with the case of switching operating systems. We're doing it now by switching from Trusty to Xenial, and we will do it again when we switch from Xenial to Bionic or 20.04 (whatever it will be called).

 

In cases like this, will ne do N and N-1 per operating system version (i.e. N and N-1 on Trusty as well as N and N-1 on Xenial) – at least for some grace period?

 

Thanks and warm regards

Marco

 

From: <cf-bosh@...> on behalf of Morgan Fine <mfine@...>
Reply-To: "cf-bosh@..." <cf-bosh@...>
Date: Friday, 28. September 2018 at 20:58
To: "cf-dev@..." <cf-dev@...>, "cf-bosh@..." <cf-bosh@...>
Subject: [cf-bosh] BOSH Stemcell Support Policy

 

Hi CF Community,

 

The BOSH team is working to formalize a policy for Linux stemcell support. Up until now, the team has not had a policy on which stemcell lines are officially supported. We'll also be working to make this information available on bosh.io

 

Please find the details in the attached document.

 

 

Best,

Morgan Fine

CF BOSH 

Re: Azure Storage?

Mike Lloyd <klloyd@...>
 

I'm on board for it so long as Morgan and Frederic are fine with it!

Respectfully,

Mike Lloyd


On Wed, Oct 3, 2018 at 5:34 AM Bin Xia via Lists.Cloudfoundry.Org <binxi=microsoft.com@...> wrote:

Hi Mike and Morgan,

 

Several months ago, we had a discussion with Dimitry to enable Azure Blob storage support for the BOSH director. The codes basically works. And several PRs to Azure CPI, stemcell and bosh-agent (bosh blob command) were also ready to submit.

https://github.com/bingosummer/bosh-azureblobcli

I think, we can restart the work to enable Azure Blob storage support for the BOSH director. What do you think?

 

Thanks

Bin

 

From: cf-bosh@... <cf-bosh@...> On Behalf Of Mike Lloyd
Sent: Wednesday, October 3, 2018 2:38 AM
To: cf-bosh@...
Subject: Re: [cf-bosh] Azure Storage?

 

I think midterm is okay - so long as it's on the roadmap and committed I can be happy. Recently there was an issue I had where the BOSH director was return HTTP 500 for every operation, after some investigation it turned out to be the local disk space was full. I was able to resolve it, but as I (and others) run BOSH on Azure, the ability to use the target cloud's blob store would be immensely useful. Otherwise it's monitoring for disk space and resizing disks or leveraging Minio/off-cloud solution. As a primarily Azure-based operator, not having parity on blob storage adds a small engineering overhead which may not necessarily exist in AWS and GCP.

 

Respectfully,

 

Mike.

 

 

On Tue, Oct 2, 2018 at 11:54 AM Morgan Fine <mfine@...> wrote:

Hey Mike,

We do have a roadmap item to enable Azure Blob Storage support for the BOSH director. That being said, it's looking like it's a midterm roadmap goal in the next few months based on our current priorities. 

Is there a specific reason you're asking? Any additional context is always useful to help with prioritization decisions later on.

Thanks,
Morgan

Re: Azure Storage?

Bin Xia
 

Hi Mike and Morgan,

 

Several months ago, we had a discussion with Dimitry to enable Azure Blob storage support for the BOSH director. The codes basically works. And several PRs to Azure CPI, stemcell and bosh-agent (bosh blob command) were also ready to submit.

https://github.com/bingosummer/bosh-azureblobcli

I think, we can restart the work to enable Azure Blob storage support for the BOSH director. What do you think?

 

Thanks

Bin

 

From: cf-bosh@... <cf-bosh@...> On Behalf Of Mike Lloyd
Sent: Wednesday, October 3, 2018 2:38 AM
To: cf-bosh@...
Subject: Re: [cf-bosh] Azure Storage?

 

I think midterm is okay - so long as it's on the roadmap and committed I can be happy. Recently there was an issue I had where the BOSH director was return HTTP 500 for every operation, after some investigation it turned out to be the local disk space was full. I was able to resolve it, but as I (and others) run BOSH on Azure, the ability to use the target cloud's blob store would be immensely useful. Otherwise it's monitoring for disk space and resizing disks or leveraging Minio/off-cloud solution. As a primarily Azure-based operator, not having parity on blob storage adds a small engineering overhead which may not necessarily exist in AWS and GCP.

 

Respectfully,

 

Mike.

 

 

On Tue, Oct 2, 2018 at 11:54 AM Morgan Fine <mfine@...> wrote:

Hey Mike,

We do have a roadmap item to enable Azure Blob Storage support for the BOSH director. That being said, it's looking like it's a midterm roadmap goal in the next few months based on our current priorities. 

Is there a specific reason you're asking? Any additional context is always useful to help with prioritization decisions later on.

Thanks,
Morgan