Date   

Re: [ANN] cf-plugin update-cli (update cloudfoundry/cli to the latest version)

taichi nakashima
 

Deis,

I have created a proposal to support such a feature in the CLI itself.
Great ! I can contribute that :)

--
Taichi Nakashima

2016年3月26日(土) 14:28 taichi nakashima <nsd22843(a)gmail.com>:

Padma

This is cool and yes it works on windows !
Thank you for testing.

However, it helps to get an acknowledgement if the update was
successful or not. It ends abruptly and need to run ‘cf –v’ to know the
status.

Added message after successfully update :)

--
Taichi Nakashima

2016年3月26日(土) 10:59 Koper, Dies <diesk(a)fast.au.fujitsu.com>:

Hi Taichi,

Nice plug-in!

I have created a proposal to support such a feature in the CLI itself.
I received some internal feedback from security people who had concerns
that publishing digitally signed checksums would hopefully address.
I hope to engage security people next month and sort that out before I
share my proposal on this list.

Thanks for sharing!

Regards,
Dies Koper
Cloud Foundry CLI PM

-----Original Message-----
From: TAICHI NAKASHIMA [mailto:nsd22843(a)gmail.com]
Sent: Thursday, March 24, 2016 12:05 PM
To: cf-dev(a)lists.cloudfoundry.org
Subject: [cf-dev] [ANN] cf-plugin update-cli (update cloudfoundry/cli to
the latest version)

Hi,

I've written new plugin to update cloudfoundry/cli to the latest version.

https://github.com/tcnksm/cf-plugin-update-cli
(You can download it from my own plugin repo,
https://t-plugins.au-syd.mybluemix.net/ui/ )

I think it should be implemented in cf/cli itself. But before that time,
it will help you.
And It would be great if cf cli team provides SHASUM for each release
binary on release page so that it can check it after downloading).

--
Taichi Nakashima


Re: [ANN] cf-plugin update-cli (update cloudfoundry/cli to the latest version)

taichi nakashima
 

Padma

This is cool and yes it works on windows !
Thank you for testing.

However, it helps to get an acknowledgement if the update was successful
or not. It ends abruptly and need to run ‘cf –v’ to know the status.

Added message after successfully update :)

--
Taichi Nakashima

2016年3月26日(土) 10:59 Koper, Dies <diesk(a)fast.au.fujitsu.com>:

Hi Taichi,

Nice plug-in!

I have created a proposal to support such a feature in the CLI itself.
I received some internal feedback from security people who had concerns
that publishing digitally signed checksums would hopefully address.
I hope to engage security people next month and sort that out before I
share my proposal on this list.

Thanks for sharing!

Regards,
Dies Koper
Cloud Foundry CLI PM

-----Original Message-----
From: TAICHI NAKASHIMA [mailto:nsd22843(a)gmail.com]
Sent: Thursday, March 24, 2016 12:05 PM
To: cf-dev(a)lists.cloudfoundry.org
Subject: [cf-dev] [ANN] cf-plugin update-cli (update cloudfoundry/cli to
the latest version)

Hi,

I've written new plugin to update cloudfoundry/cli to the latest version.

https://github.com/tcnksm/cf-plugin-update-cli
(You can download it from my own plugin repo,
https://t-plugins.au-syd.mybluemix.net/ui/ )

I think it should be implemented in cf/cli itself. But before that time,
it will help you.
And It would be great if cf cli team provides SHASUM for each release
binary on release page so that it can check it after downloading).

--
Taichi Nakashima


Re: [ANN] cf-plugin update-cli (update cloudfoundry/cli to the latest version)

Koper, Dies <diesk@...>
 

Hi Taichi,

Nice plug-in!

I have created a proposal to support such a feature in the CLI itself.
I received some internal feedback from security people who had concerns that publishing digitally signed checksums would hopefully address.
I hope to engage security people next month and sort that out before I share my proposal on this list.

Thanks for sharing!

Regards,
Dies Koper
Cloud Foundry CLI PM

-----Original Message-----
From: TAICHI NAKASHIMA [mailto:nsd22843(a)gmail.com]
Sent: Thursday, March 24, 2016 12:05 PM
To: cf-dev(a)lists.cloudfoundry.org
Subject: [cf-dev] [ANN] cf-plugin update-cli (update cloudfoundry/cli to the latest version)

Hi,

I've written new plugin to update cloudfoundry/cli to the latest version.

https://github.com/tcnksm/cf-plugin-update-cli
(You can download it from my own plugin repo, https://t-plugins.au-syd.mybluemix.net/ui/ )

I think it should be implemented in cf/cli itself. But before that time, it will help you.
And It would be great if cf cli team provides SHASUM for each release binary on release page so that it can check it after downloading).

--
Taichi Nakashima


UX proposal App manifests improvements for Routes, open for review

Koper, Dies <diesk@...>
 

Hi,

I'd like to introduce a set of new attributes to app manifests to support the specification of HTTP routes with paths, TCP routes and application ports.
I am also exploring a new way of specifying routes (proposal B).

Please take a look and leave your feedback in the doc or here on the list.

https://docs.google.com/document/d/17c1FwsuK_YCjQhH_7CebQkjrot4sfIsbAMQ0Cwcvv0M/edit?usp=sharing

Cheers,
Dies Koper
Cloud Foundry CLI PM


Re: CC BUILDPACK_SET App Usage Events

Nicholas Calugar
 

We are adding STAGING_STARTED and STAGING_STOPPED app usage events:
https://www.pivotaltracker.com/story/show/111168816

We've also blocked staging an app's package if the app has a package that
is staging: https://www.pivotaltracker.com/story/show/111166772


On Thu, Mar 24, 2016 at 6:59 PM Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

Can you explain how staging tasks will be recorded? We have already seen a
number of custom buildpacks that use the 15 minutes of staging time in
interesting ways that consume significant resources. This is mitigated
today by the fact that the staging only occurs when the app transitions
from stopped to started so only the staging instance can execute; during
that period the desired state of the application is `started` so it's
billable time.

While I'm happy we won't be stopping apps when a new version is pushed, I
do think providers need a way to track the additional resource consumption
of staging to avoid misuse and abuse - especially given staging tasks are
typically executed with memory and disk limits that exceed those associated
with an app instance.

Thanks.

On Thu, Mar 24, 2016 at 5:20 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi Matthew,

Thanks for the response. When we start an app in V3, we will always know
the buildpack because we are starting the app's current droplet. The
droplet was staged with a particular buildpack, so we can record the
buildpack in the STARTED app usage event.

As promised, a couple follow up questions:

If we record the buildpack_guid in the STARTED event, can we omit the
BUILDPACK_SET event in V3?

Currently, a V3 app must be stopped to change the current droplet. We
have an upcoming story [1] to enable changing the droplet on a running
application. Would we want to add something like a DROPLET_CHANGED app
usage event to indicate a running app is now using a different buildpack?


Thanks,

-Nick

Nicholas Calugar
CAPI Product Manager
Pivotal Software, Inc.

[1] https://www.pivotaltracker.com/story/show/111166678

On Wed, Mar 23, 2016 at 7:34 PM Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

The buildpack set event was implemented to enable usage based billing
for buildpack applications where the rates differed by the buildpack used
to stage the application.

When staging an application in /v2, if a buildpack is not specified, we
don't know which buildpack will stage the application until after the
detect phase of staging has occurred. That means at the time the usage
event was captured for the transition to start, the buildpack was
unavailable.

The buildpack set event makes that information available to billing
systems after staging completes.

On Tue, Mar 22, 2016 at 8:03 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF-Dev,

We are continuing work on the Cloud Controller V3 API and had a
question about a particular App Usage Event we write as part of V2, the
BUILDPACK_SET event. The test[1] around this indicates that we write the
app usage event when staging completes and the app is still started. In V2,
apps, packages, and droplets are very tightly coupled, so writing this
event here makes sense.

In V3, apps, packages, and droplets are first class resources and we
don't stage apps, we stage packages to create droplets. Furthermore,
staging with a particular buildpack does not affect the app until the
droplet is assigned to the app as the current droplet and the current
droplet can be changed to any valid droplet for the app. Staging completion
and the app being started no longer seem to correlate to the buildpack
being "set".

With the above differences, we are hoping to understand the use-case
around the BUILDPACK_SET event so we can correctly preserve the desired
behavior for V3. I'll likely have follow up questions, but the first thing
I'd like to know is what BUILDPACK_SET indicates to downstream billing
engines.

Thanks,

-Nick

Nicholas Calugar
CAPI Product Manager
Pivotal Software, Inc.

[1]
https://github.com/cloudfoundry/cloud_controller_ng/blob/45b311f18d8ad1184dcb647081b19eca6f1eaf83/spec/unit/models/runtime/app_spec.rb#L1345-L1369


--
Matthew Sykes
matthew.sykes(a)gmail.com

--
Matthew Sykes
matthew.sykes(a)gmail.com


Re: CC BUILDPACK_SET App Usage Events

Dieu Cao <dcao@...>
 

We'll be introducing new usage events for staging [1] to handle that
scenario.
I ran the changes by the CF Abacus team a month or so ago and they did not
raise any objections.

-Dieu

[1] https://www.pivotaltracker.com/story/show/111168816


On Thu, Mar 24, 2016 at 6:50 PM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

Can you explain how staging tasks will be recorded? We have already seen a
number of custom buildpacks that use the 15 minutes of staging time in
interesting ways that consume significant resources. This is mitigated
today by the fact that the staging only occurs when the app transitions
from stopped to started so only the staging instance can execute; during
that period the desired state of the application is `started` so it's
billable time.

While I'm happy we won't be stopping apps when a new version is pushed, I
do think providers need a way to track the additional resource consumption
of staging to avoid misuse and abuse - especially given staging tasks are
typically executed with memory and disk limits that exceed those associated
with an app instance.

Thanks.

On Thu, Mar 24, 2016 at 5:20 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi Matthew,

Thanks for the response. When we start an app in V3, we will always know
the buildpack because we are starting the app's current droplet. The
droplet was staged with a particular buildpack, so we can record the
buildpack in the STARTED app usage event.

As promised, a couple follow up questions:

If we record the buildpack_guid in the STARTED event, can we omit the
BUILDPACK_SET event in V3?

Currently, a V3 app must be stopped to change the current droplet. We
have an upcoming story [1] to enable changing the droplet on a running
application. Would we want to add something like a DROPLET_CHANGED app
usage event to indicate a running app is now using a different buildpack?


Thanks,

-Nick

Nicholas Calugar
CAPI Product Manager
Pivotal Software, Inc.

[1] https://www.pivotaltracker.com/story/show/111166678

On Wed, Mar 23, 2016 at 7:34 PM Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

The buildpack set event was implemented to enable usage based billing
for buildpack applications where the rates differed by the buildpack used
to stage the application.

When staging an application in /v2, if a buildpack is not specified, we
don't know which buildpack will stage the application until after the
detect phase of staging has occurred. That means at the time the usage
event was captured for the transition to start, the buildpack was
unavailable.

The buildpack set event makes that information available to billing
systems after staging completes.

On Tue, Mar 22, 2016 at 8:03 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF-Dev,

We are continuing work on the Cloud Controller V3 API and had a
question about a particular App Usage Event we write as part of V2, the
BUILDPACK_SET event. The test[1] around this indicates that we write the
app usage event when staging completes and the app is still started. In V2,
apps, packages, and droplets are very tightly coupled, so writing this
event here makes sense.

In V3, apps, packages, and droplets are first class resources and we
don't stage apps, we stage packages to create droplets. Furthermore,
staging with a particular buildpack does not affect the app until the
droplet is assigned to the app as the current droplet and the current
droplet can be changed to any valid droplet for the app. Staging completion
and the app being started no longer seem to correlate to the buildpack
being "set".

With the above differences, we are hoping to understand the use-case
around the BUILDPACK_SET event so we can correctly preserve the desired
behavior for V3. I'll likely have follow up questions, but the first thing
I'd like to know is what BUILDPACK_SET indicates to downstream billing
engines.

Thanks,

-Nick

Nicholas Calugar
CAPI Product Manager
Pivotal Software, Inc.

[1]
https://github.com/cloudfoundry/cloud_controller_ng/blob/45b311f18d8ad1184dcb647081b19eca6f1eaf83/spec/unit/models/runtime/app_spec.rb#L1345-L1369


--
Matthew Sykes
matthew.sykes(a)gmail.com

--
Matthew Sykes
matthew.sykes(a)gmail.com


Re: PHP buildpack looking for composer.json file recursively leads to detecting ASP.Net projects as PHP projects

Daniel Mikusa
 

OK. Sorry, I was thinking about code in a different spot. I would agree
that recursively searching is probably unnecessary.

This has probably not come up before because I don't think most users rely
on the detect behavior. If you set `-b` with `cf push` and pick a specific
build pack you can workaround this behavior.

Dan

On Fri, Mar 25, 2016 at 4:58 PM, Daniel E Grim <degrim(a)us.ibm.com> wrote:

This issue is with the latest PHP build pack code at
https://github.com/cloudfoundry/php-buildpack/blob/master/scripts/detect.py#L26
.

-Dan

----- Forwarded by Daniel E Grim/Raleigh/IBM on 03/25/2016 04:54 PM -----

From: Daniel Mikusa <dmikusa(a)pivotal.io>
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Date: 03/25/2016 04:52 PM
Subject: [cf-dev] Re: PHP buildpack looking for composer.json file
recursively leads to detecting ASP.Net projects as PHP projects
------------------------------



What version of the PHP build pack are you using? I know this has come up
before and I thought the build pack was changed to look in specific
locations.

Dan

On Fri, Mar 25, 2016 at 3:55 PM, Daniel E Grim <*degrim(a)us.ibm.com*
<degrim(a)us.ibm.com>> wrote:

Hi all,

The PHP buildpack is currently looking recursively for a composer.json
file within the project as part of it's detect script. This is causing an
issue for users trying to push an ASP.Net project which contains bower
packages that have a composer.json file within their directory structure
because their project gets detected by the PHP buildpack. Does anyone know
if there is a need for the PHP buildpack to search for this file
recursively, or would detecting it in the project root be enough? If the
file could be detected only in the project root, that would stop the PHP
buildpack from detecting ASP.Net projects because those composer.json files
are never in the main folder of the project but in the wwwroot/scripts/lib
folder instead.

Thanks,
Dan




Re: PHP buildpack looking for composer.json file recursively leads to detecting ASP.Net projects as PHP projects

Daniel E Grim <degrim@...>
 

This issue is with the latest PHP build pack code at
https://github.com/cloudfoundry/php-buildpack/blob/master/scripts/detect.py#L26
.

-Dan

----- Forwarded by Daniel E Grim/Raleigh/IBM on 03/25/2016 04:54 PM -----

From: Daniel Mikusa <dmikusa(a)pivotal.io>
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: 03/25/2016 04:52 PM
Subject: [cf-dev] Re: PHP buildpack looking for composer.json file
recursively leads to detecting ASP.Net projects as PHP projects



What version of the PHP build pack are you using?  I know this has come up
before and I thought the build pack was changed to look in specific
locations.

Dan

On Fri, Mar 25, 2016 at 3:55 PM, Daniel E Grim <degrim(a)us.ibm.com> wrote:
Hi all,

The PHP buildpack is currently looking recursively for a composer.json
file within the project as part of it's detect script. This is causing an
issue for users trying to push an ASP.Net project which contains bower
packages that have a composer.json file within their directory structure
because their project gets detected by the PHP buildpack. Does anyone
know if there is a need for the PHP buildpack to search for this file
recursively, or would detecting it in the project root be enough? If the
file could be detected only in the project root, that would stop the PHP
buildpack from detecting ASP.Net projects because those composer.json
files are never in the main folder of the project but in the
wwwroot/scripts/lib folder instead.

Thanks,
Dan


Re: PHP buildpack looking for composer.json file recursively leads to detecting ASP.Net projects as PHP projects

Daniel Mikusa
 

What version of the PHP build pack are you using? I know this has come up
before and I thought the build pack was changed to look in specific
locations.

Dan

On Fri, Mar 25, 2016 at 3:55 PM, Daniel E Grim <degrim(a)us.ibm.com> wrote:

Hi all,

The PHP buildpack is currently looking recursively for a composer.json
file within the project as part of it's detect script. This is causing an
issue for users trying to push an ASP.Net project which contains bower
packages that have a composer.json file within their directory structure
because their project gets detected by the PHP buildpack. Does anyone know
if there is a need for the PHP buildpack to search for this file
recursively, or would detecting it in the project root be enough? If the
file could be detected only in the project root, that would stop the PHP
buildpack from detecting ASP.Net projects because those composer.json files
are never in the main folder of the project but in the wwwroot/scripts/lib
folder instead.

Thanks,
Dan


PHP buildpack looking for composer.json file recursively leads to detecting ASP.Net projects as PHP projects

Daniel E Grim <degrim@...>
 

Hi all,

The PHP buildpack is currently looking recursively for a composer.json
file within the project as part of it's detect script. This is causing an
issue for users trying to push an ASP.Net project which contains bower
packages that have a composer.json file within their directory structure
because their project gets detected by the PHP buildpack. Does anyone know
if there is a need for the PHP buildpack to search for this file
recursively, or would detecting it in the project root be enough? If the
file could be detected only in the project root, that would stop the PHP
buildpack from detecting ASP.Net projects because those composer.json files
are never in the main folder of the project but in the wwwroot/scripts/lib
folder instead.

Thanks,
Dan


Garden / Guardian update

Will Pragnell <wpragnell@...>
 

Hi All,

Last July, we announced that we would be transitioning the Garden-Linux
backend over to use runC, an implementation of the Open Container
Initiative specification. 9 months on, and we're happy to report that we're
extremely close to shipping v1.0 of what we've decided to call Guardian
[1]. This is a new Garden backend based on runC, and it has the exact same
API as existing versions of Garden-Linux.

We believe Guardian will be feature complete (at least in terms of features
used by Cloud Foundry / Diego) within the next few weeks. Once we hit this
milestone, there is still some integration work and performance testing to
be done, but you should expect to hear from us again in the next few months
with details of a transition plan.

We're also planning to incept the next batch of work for the Garden team
next week. Normally we would wait until Guardian has shipped to do this,
but we have a rare opportunity next week as the whole team will be in the
same location for the first time in six months, and we're going to take
advantage of this to run an inception.

The next batch of work will be focused on security, with the high level
goal that Guardian should be the most secure container management solution
available for multi-tenant workloads. We'll share some notes after the
inception, but please do get in touch in the meantime if you have any
questions or thoughts.

Best,
Will - Garden PM


[1]: https://github.com/cloudfoundry-incubator/guardian-release


Re: add Diego into our monitoring system

Jim CF Campbell
 

Hi Liu Rui,


1) If we just want to have those metrics, we still have to collect all
logging data through the Loggregator system. It is a huge network overhead
for our system because our CF system is large.
You can use a metrics nozzle that only passes metrics and not logs. For
example, here is the Datadog nozzle
<https://github.com/cloudfoundry-incubator/datadog-firehose-nozzle>.



2) We will migrate to CF release 233 soon. And the /varz support for
HM9000 will be sunset. Do we have the corresponding metrics of statistics
flowing through the Loggregator system? Do we have some document for that?
<https://docs.cloudfoundry.org/loggregator/all_metrics.html>
List of CF metrics
<https://docs.cloudfoundry.org/loggregator/all_metrics.html>


--
Jim Campbell | Product Manager | Cloud Foundry | Pivotal.io | 303.618.0963


Re: Announcement: BOSH for Windows

Steven Benario
 

Hi Gwenn,

We have a work in progress on github (sample-windows-bosh-release) for a
release we have been using to test agent features during implementation.
However, this probably won't be very useful or interesting at the moment
since it has not really been designed for public consumption so much as it
has been designed as a tool for the team. Furthermore, because there is
currently no stemcell available currently, it can't be run by anyone
externally yet.

Sorry we don't have more for you yet!

-Steven


On Thu, Mar 24, 2016 at 9:11 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

That's a really good news.
Do you have any bosh-release example for windows ??

Thanks

On Fri, Mar 25, 2016 at 1:18 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

This is great!

Mike

On Thu, Mar 24, 2016 at 9:06 AM, Steven Benario <sbenario(a)pivotal.io>
wrote:

Hello everyone,

We wanted to take this opportunity to announce a new incubating project
under the BOSH umbrella.

In the fall, we launched full support for Windows and .NET applications
in Cloud Foundry with Project Greenhouse (composed of Garden-Windows [1]
and Diego-Windows [2]). Since then, we've seen a lot of interest in
bringing the magic of CF to Windows developers.

One of the most common requests along those lines has been for BOSH to
support Windows cells. I'm pleased to announce that we have recently begun
adding support for Windows servers to Bosh (aka "Bosh for Windows" or
"BoshWin"). This project can be tracked at its public tracker [3], and will
be an open source contribution to the Foundation.

To date, all contributions have been committed directly to the
Bosh-Agent repo [4], under "windows" branches. If appropriate, we may
commit code to other repos in the future.

We are really excited to announce this, and would love to hear from you
if you are a potential user or contributor to Bosh-Windows!

Cheers,
Steven Benario
PM for Bosh-Windows



[1] - https://github.com/cloudfoundry/garden-windows
[2] - https://github.com/cloudfoundry/diego-windows-release
[3] - https://www.pivotaltracker.com/n/projects/1479998
[4] - https://github.com/cloudfoundry/bosh-agent


Re: Announcement: BOSH for Windows

Mike Dalessio
 

Benjamin,

Thanks for asking this question!

The BOSH Windows Agent sits above the CPI abstraction, and so you will be
able to deploy Windows VMs on any of the BOSH-supported IaaSes (pending
resolution of various questions about stemcell composition).

-m



On Fri, Mar 25, 2016 at 7:48 AM, Benjamin Gandon <benjamin(a)gandon.org>
wrote:

Very great news!

As BOSH doesn't support multiple CPIs, does this mean that people need a
separate BoshWin to manage Windows deployments, along with the normal BOSH
for classical Linux deployments?

/Benjamin

Le 24 mars 2016 à 16:06, Steven Benario <sbenario(a)pivotal.io> a écrit :

Hello everyone,

We wanted to take this opportunity to announce a new incubating project
under the BOSH umbrella.

In the fall, we launched full support for Windows and .NET applications in
Cloud Foundry with Project Greenhouse (composed of Garden-Windows [1] and
Diego-Windows [2]). Since then, we've seen a lot of interest in bringing
the magic of CF to Windows developers.

One of the most common requests along those lines has been for BOSH to
support Windows cells. I'm pleased to announce that we have recently begun
adding support for Windows servers to Bosh (aka "Bosh for Windows" or
"BoshWin"). This project can be tracked at its public tracker [3], and will
be an open source contribution to the Foundation.

To date, all contributions have been committed directly to the Bosh-Agent
repo [4], under "windows" branches. If appropriate, we may commit code to
other repos in the future.

We are really excited to announce this, and would love to hear from you if
you are a potential user or contributor to Bosh-Windows!

Cheers,
Steven Benario
PM for Bosh-Windows



[1] - https://github.com/cloudfoundry/garden-windows
[2] - https://github.com/cloudfoundry/diego-windows-release
[3] - https://www.pivotaltracker.com/n/projects/1479998
[4] - https://github.com/cloudfoundry/bosh-agent


Re: Announcement: BOSH for Windows

Benjamin Gandon
 

Very great news!

As BOSH doesn't support multiple CPIs, does this mean that people need a separate BoshWin to manage Windows deployments, along with the normal BOSH for classical Linux deployments?

/Benjamin

Le 24 mars 2016 à 16:06, Steven Benario <sbenario(a)pivotal.io> a écrit :

Hello everyone,

We wanted to take this opportunity to announce a new incubating project under the BOSH umbrella.

In the fall, we launched full support for Windows and .NET applications in Cloud Foundry with Project Greenhouse (composed of Garden-Windows [1] and Diego-Windows [2]). Since then, we've seen a lot of interest in bringing the magic of CF to Windows developers.

One of the most common requests along those lines has been for BOSH to support Windows cells. I'm pleased to announce that we have recently begun adding support for Windows servers to Bosh (aka "Bosh for Windows" or "BoshWin"). This project can be tracked at its public tracker [3], and will be an open source contribution to the Foundation.

To date, all contributions have been committed directly to the Bosh-Agent repo [4], under "windows" branches. If appropriate, we may commit code to other repos in the future.

We are really excited to announce this, and would love to hear from you if you are a potential user or contributor to Bosh-Windows!

Cheers,
Steven Benario
PM for Bosh-Windows



[1] - https://github.com/cloudfoundry/garden-windows
[2] - https://github.com/cloudfoundry/diego-windows-release
[3] - https://www.pivotaltracker.com/n/projects/1479998
[4] - https://github.com/cloudfoundry/bosh-agent


Re: [ANN] cf-plugin update-cli (update cloudfoundry/cli to the latest version)

Padmashree B
 

Hi,

This is cool and yes it works on windows !
However, it helps to get an acknowledgement if the update was successful or not. It ends abruptly and need to run 'cf -v' to know the status.

cf update-cli
Your cf version v6.15.0 is not latest (v6.16.1)
Do you want to update?: [Y/n]: Y

Start to update to v6.16.1
Downloading: 6021596/6184613

... back to prompt

Cheers,
Padma


Reg the serial property

Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM@Cisco) <ngnanase at cisco.com...>
 

Hi Amit

We are able to combine following cloud foundry jobs into one VM and deploy. The global default setting is serial:true
Curious to confirm, In this scenario, what is the order of the template jobs being created? Will it serially create the template jobs one by one from the beginning?
Here I have arranged the templates reading your answer in the below link

https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/GQR3FGZGBPPZS56ZYALBYX6WGUVTY24Y/

Thanks for your detailed answer in this link.

Templates:
- name: etcd
release: cf
- name: etcd_metrics_server
release: cf
- name: nats
release: cf
- name: nats_stream_forwarder
release: cf
- name: collector
release: cf
- name: postgres
release: cf
- name: uaa
release: cf
- name: cloud_controller_clock
release: cf
- name: consul_agent
release: cf
- name: go-buildpack
release: cf
- name: binary-buildpack
release: cf
- name: nodejs-buildpack
release: cf
- name: ruby-buildpack
release: cf
- name: php-buildpack
release: cf
- name: python-buildpack
release: cf
- name: staticfile-buildpack
release: cf
- name: cloud_controller_ng
release: cf
- name: statsd-injector
release: cf
- name: blobstore
release: cf
- name: route_registrar
release: cf
- name: metron_agent
release: cf
update: {}


regards
Nithiyasri


Re: add Diego into our monitoring system

Liu Rui
 

Thanks for all comments which are very helpful.

We are now able to get the metrics through nozzle connecting to traffic controller.

I have 2 questions:

1) If we just want to have those metrics, we still have to collect all logging data through the Loggregator system. It is a huge network overhead for our system because our CF system is very large.

2) We will migrate to CF release 233 soon. And the /varz support for HM9000 will be sunset. Do we have the corresponding metrics of statistics flowing through the Loggregator system? Do we have some document for that?


Re: add Diego into our monitoring system

Liu Rui
 

Thanks for all comments which are very helpful.

We are now able to get the metrics through nozzle connecting to traffic controller.

I have 2 questions:

1) If we just want to have those metrics, we still have to collect all logging data through the Loggregator system. It is a huge network overhead for our system because our CF system is large.

2) We will migrate to CF release 233 soon. And the /varz support for HM9000 will be sunset. Do we have the corresponding metrics of statistics flowing through the Loggregator system? Do we have some document for that?


Re: "Can't find property `[etcd.cluster]' when deploy cfv233

王小锋 <zzuwxf at gmail.com...>
 

Please ignore this thread, I just figure out the problem.

2016-03-25 13:13 GMT+08:00 王小锋 <zzuwxf(a)gmail.com>:

Hi, there

I am trying to deploy cf deployment 233, and use script to generate
deployment manifest, but failed with the following error, I am not sure
what "value" should be given to property "cluster", your help is greatly
appreciated!! thanks.

Started preparing configuration > Binding configuration. Failed: Error
filling in template `etcd_bosh_utils.sh.erb' for `etcd_z1/0' (line 33:
Can't find property `["etcd.cluster"]') (00:00:01)

*Error 100: Error filling in template `etcd_bosh_utils.sh.erb' for
`etcd_z1/0' (line 33: Can't find property `["etcd.cluster"]')*

Task 38 error

The corresponding etcd job looks like:

- instances: 1
name: etcd_z1
networks:
- name: cf1
static_ips:
- 10.10.16.20
persistent_disk: 10024
properties:
metron_agent:
zone: z1
resource_pool: medium_z1
templates:
- name: etcd
release: cf
- name: etcd_metrics_server
release: cf
- name: metron_agent
release: cf
update:
max_in_flight: 1
serial: true

5061 - 5080 of 9425