Date   

Announcement: BOSH for Windows

Steven Benario
 

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)

taichi nakashima
 

Thanks,

Not yet tested on window

I don't have one so hope someone try


On 2016年3月24日(木) at 19:40 Lomov Alexander <alexander.lomov(a)altoros.com>
wrote:

Nice idea for cf cli plugin! Will certainly use it.

I also fell on thought to make PR to install specific version of cf cli.

Quick question: is tested on Windows?

On Mar 24, 2016, at 4:26 AM, Dr Nic Williams <drnicwilliams(a)gmail.com>
wrote:

Nice demo gif on the readme. Looks v handy!


On 24 Mar 2016, 11:05 AM +1000, TAICHI NAKASHIMA <nsd22843(a)gmail.com>,
wrote:
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)

Alexander Lomov <alexander.lomov@...>
 

Nice idea for cf cli plugin! Will certainly use it.

I also fell on thought to make PR to install specific version of cf cli.

Quick question: is tested on Windows?

On Mar 24, 2016, at 4:26 AM, Dr Nic Williams <drnicwilliams(a)gmail.com> wrote:

Nice demo gif on the readme. Looks v handy!


On 24 Mar 2016, 11:05 AM +1000, TAICHI NAKASHIMA <nsd22843(a)gmail.com>, wrote:
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: Proposal to Change CATs Ownership

Michael Fraenkel <michael.fraenkel@...>
 

All the teams have to deal with a workflow and bumping. I don't believe
there is a team that doesn't have to also deploy CF with Diego (except
mine) and run CATs.

The issue I believe you are highlighting is something different. CAPI
needs a CAPI acceptance for its new features which have no CLI
counterpart. In the past CATs contained that. I think now that CATs now
includes DATs and RATs and xATs, its not part of one team. If CAPI needs
a place to test out new functions using cf curl, that can either live in
CATs or it goes some where else. CATs should be what an end user will
attempt which is hopefully not driving CF via 'cf curl'.

Having CATs live under any one release is a problem for any other team
that uses it and provides code. Any changes are gated by someone merging
a commit and making it through a pipeline that includes other changes
that maybe should not be consumed by others since its not part of the
"release" because we will get additional components from the CAPI
release that may not be ready.

- Michael

On 3/23/16 2:43 PM, Utako Ueda wrote:
We had a series of meetings to figure out a good path for CATs that
ranged from multiple teams to smaller groups. We met most recently to
address concerns that include the following:

• Workflow and Release Bumping Issues: CATs relies on calls to
specific versions of CC API to run successfully. The CAPI CI currently
bumps cloud_controller_ng within capi-release, and on a successful run
of CATs (which lives on cf-release develop), capi-release then gets
bumped in cf-release develop. This leads to a "chicken and egg"
scenario, in that when changes are made to both CATs and CC, both
cf-release and capi pipelines are broken until a manual fix is made.
• In a world where cf-release no longer exists, how do we ensure CATs
uses the correct versions of the CF CLI and CC API?

tl;dr: Though not all of the CATs test the CC API explicitly, they all
make use of the CC API and therefore make CC a choke point. Having
CATs as a separate release may be a good idea, but doesn't necessarily
address the strong coupling issues.

We'd like to know if there are specific cases in which this will be
detrimental to other projects' workflows before moving forward.


On Wed, Mar 23, 2016 at 4:08 AM, Michael Fraenkel
<michael.fraenkel(a)gmail.com <mailto:michael.fraenkel(a)gmail.com>> wrote:

Can you explain why CATs should live under CAPI?

CATs now represents acceptance test for all of the Cloud Foundry
function driven mainly via the CLI.

Tieing this to any one release seems a bit artificial.
CATs is about testing the aggregation of all the various releases
not just CAPI.

I am more surprised that it wasn't suggested to be its own release
which dictated the versions for all releases that had passed.

- Michael


On 3/22/16 3:05 AM, Utako Ueda wrote:
Hi all,

The CAPI team would like to take ownership of the CF acceptance
tests <https://github.com/cloudfoundry/cf-acceptance-tests/> and
include them as part of CAPI release
<http://github.com/cloudfoundry/capi-release>.

This solves several pain points we've experienced over the last
few months, mainly due to the strong coupling between CATs and
the Cloud Controller API.

Our plan is to submodule the CATs repo in to CAPI release, and
bump CATs on a successful run through the CAPI ci pipeline. At
this point, CAPI release will be bumped in cf-release develop,
which other teams will consume for their own testing purposes.

We hope to make these changes in the near future as we wrap up
our release extraction from cf-release. We'd like to know if any
teams have any concerns about this before we proceed, so do let
us know as soon as possible so we can address them.

Thanks,
Utako, CF CAPI Team


Re: Upcoming extraction of cflinuxfs2 rootfs release from diego-release

Benjamin Gandon
 

Hi Eric,

Facing the pace of cflinuxfs2 updates, I've done and successfully deployed such a BOSH release. It also ships with example manifests. I'll share it with you this afternoon.

I've been using a "cheap" local blobstore but it would be interesting that you publish the blobs on a public bucket.

/Benjamin

Le 18 mars 2016 à 00:01, Eric Malm <emalm(a)pivotal.io> a écrit :

Dear CF Community,

Over the next few weeks, the Diego and Buildpacks teams will be working together to extract a new BOSH release for the cflinuxfs2 rootfs/stack out of the Diego BOSH release. The Buildpacks team has been doing an amazing job of publishing new rootfs images in response to CVEs, and this separation will make it easier for all Diego deployment operators to update to those latest rootfs images without having to update their other releases. We've already taken advantage of the same kind of separation between Garden-Linux and Diego when addressing some recent Garden CVEs, and we're looking forward to having that flexibility with the rootfs image as well.

Once completed, the release extraction will mean a couple of minor changes for Diego deployment operators:

- You'll have one more release to upload alongside the Diego, Garden-Linux, and etcd BOSH releases to deploy your Diego cluster. The Diego release tarball itself will be much smaller, as it will no longer include the rootfs image that accounts for about 70% of its current size.
- If you use the spiff-based manifest-generation script in the diego-release repo to produce your manifest, that's all you'll have to do! If you're hand-rolling your manifests, you will have one or two BOSH properties to add or move, and an entry to change in the list of job templates on the Diego Cell VMs.

We'll call out these changes explicitly in the Diego release notes on GitHub when the time comes.

Just as we do with the Garden-Linux and etcd releases today, the Diego team will also attach a recent final cflinuxfs2-rootfs release tarball to each final Diego release we publish on GitHub, so it will be easy for consumers to get a validated set of default 'batteries' to plug into Diego. We'll also work with the CF Release Integration team to make sure that when the most recent rootfs image passes tests against Diego in their integration environments, its release version is recorded in the Diego/CF compatibility record, at https://github.com/cloudfoundry-incubator/diego-cf-compatibility/blob/master/compatibility-v2.csv.

If you would like to track our progress, please follow the 'cflinuxfs2-release-extraction' epic in the Diego tracker (https://www.pivotaltracker.com/epic/show/2395419) and the 'bosh-release' label in the Buildpacks tracker (https://www.pivotaltracker.com/n/projects/1042066/search?q=label%3A%22bosh-release%22).

Thanks,
Eric Malm, CF Runtime Diego PM


Re: Adding previous_instances and previous_memory fields to cf_event

Dieu Cao <dcao@...>
 

Hi Hristo,

I think a PR to add them would be fine, but I would defer to Nick Calugar,
who's taking over as PM of CAPI, to make that call.

-Dieu

On Wed, Mar 23, 2016 at 2:12 PM, Hristo Iliev <hsiliev(a)gmail.com> wrote:

Hi again,

Would you consider a PR that adds previous memory & instances to the app
usage events? Does this two additional fields make a sense?

Regards,
Hristo Iliev


Re: CC BUILDPACK_SET App Usage Events

Matthew Sykes <matthew.sykes@...>
 

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


Re: Warden Name Space

Matthew Sykes <matthew.sykes@...>
 

Warden does not create a bind mount to the network namespace. If you want
to find the namespace, locate the pid of the wshd associated with the
container and use /proc/${pid}/ns/net as the namespace.

`ip netns` only references bind mounts in /var/run/netns; I don't know of
any container systems that actually use that default location.

On Wed, Mar 23, 2016 at 4:27 PM, ravi malhotra <ravi.malhotra(a)bnymellon.com>
wrote:

Why do I not see linux name spaces for my warden instances?

root(a)874c4cea-19ed-41c7-abd2-09eb5851d54d:/var/vcap/data/warden/depot# ip
netns list <-- note that the output was blank
root(a)874c4cea-19ed-41c7-abd2-09eb5851d54d:/var/vcap/data/warden/depot# ls
19b0ug03pal 19b0ug03pba tmp <-- however, there are two containers up and
running


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


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

Dr Nic Williams <drnicwilliams@...>
 

Nice demo gif on the readme. Looks v handy!

On 24 Mar 2016, 11:05 AM +1000, TAICHI NAKASHIMA<nsd22843(a)gmail.com>, wrote:
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: Issue with stacks related to removal of libmariadb

Mike Dalessio
 

Thanks for asking this question!

Deleting blobs from the Buildpack cache would mean users could avoid having
to delete their app, which may be an improvement over the process outlined
by Danny previously. However, in that case applications would still need to
be restaged in order to link extensions against libmariadbclient.so.18.

-m

On Wed, Mar 23, 2016 at 8:51 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Danny/John,

Would deleting all the blobs in the Buildpack cache help to mitigate the
issue?


http://apidocs.cloudfoundry.org/233/blobstores/delete_all_blobs_in_the_buildpack_cache_blobstore.html

-Dieu
CF Runtime PMC Lead


On Wednesday, March 23, 2016, John Shahid <jshahid(a)pivotal.io> wrote:

Hi,

We (the buildpack team) just found out that stacks version 1.47 had an
incomplete fix for applications linked against libmysqlclient.so. The new
version 1.48 will contain a complete fix for the issue.

Sorry for the inconvenience.


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

taichi nakashima
 

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: Issue with stacks related to removal of libmariadb

Dieu Cao <dcao@...>
 

Danny/John,

Would deleting all the blobs in the Buildpack cache help to mitigate the
issue?

http://apidocs.cloudfoundry.org/233/blobstores/delete_all_blobs_in_the_buildpack_cache_blobstore.html

-Dieu
CF Runtime PMC Lead

On Wednesday, March 23, 2016, John Shahid <jshahid(a)pivotal.io> wrote:

Hi,

We (the buildpack team) just found out that stacks version 1.47 had an
incomplete fix for applications linked against libmysqlclient.so. The new
version 1.48 will contain a complete fix for the issue.

Sorry for the inconvenience.


Re: Incubation request: App Auto-Scaling service

Dr Nic Williams <drnicwilliams@...>
 

Nice work everyone!

On 24 Mar 2016, 2:51 AM +1000, Shannon Coen<scoen(a)pivotal.io>, wrote:
The Services PMC accepts App-Autoscaling into incubation.

Thank you to IBM for the contribution, and to Fujitsu and SAP for the commitment to assist in its maintenance and enhancement.

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.




On Mon, Mar 21, 2016 at 2:30 PM, Christopher B Ferris<chrisfer(a)us.ibm.com(mailto:chrisfer(a)us.ibm.com)>wrote:
awesome!

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email:chrisfer(a)us.ibm.com(mailto:chrisfer(a)us.ibm.com)
twitter: @christo4ferris
blog:https://developer.ibm.com/opentech/author/chrisfer/
phone:+1 508 667 0402(tel:+1%20508%20667%200402)

On Mar 21, 2016, at 5:28 PM, Voelz, Marco<marco.voelz(a)sap.com(mailto:marco.voelz(a)sap.com)>wrote:

Thanks Dies for driving this proposal. We're looking forward to contributing with two of our engineers in full-time!

Warm regards
Marco

On 21/03/16 21:54, "Koper, Dies"<diesk(a)fast.au.fujitsu.com(mailto:diesk(a)fast.au.fujitsu.com)>wrote:


Hi Shannon,





Our App Auto-Scaling proposal has received overwhelming support from the community, and we have received and addressed various feedback.





Now, Fujitsu and IBM would like to put the proposal forward to the Services PMC as an incubation project.





Project name: App Auto-Scaling


Project proposal:https://docs.google.com/document/d/1HHhj9ZK-trI_VVDR34bwOnWem83UAq5_Pjr9imRTazY/edit?usp=sharing


Proposed Project Lead: Michael Fraenkel (IBM)


Proposed Scope: Please refer to the Goals and Non-goals sections in the proposal


Development Operating Model: Distributed Committer Model


Technical Approach: Please refer to the Deliverables section in the proposal


Initial team committed: 7 engineers: 2 from Fujitsu, 2 from SAP, 3 from IBM (not including the Lead)





As functionally IBM’s recently open sourced app auto-scaling solution (seehttps://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/QRBQKDDG7PWS6EMEBWI4ARFQ3OGSSSWB) seems a good match to our proposal, the team will look at using that code.


Michael can be contacted to answer any IP concerns about this code.





Please let me know if you have any questions.





Regards,


Dies Koper


Fujitsu









From:Koper, Dies [mailto:diesk(a)fast.au.fujitsu.com]
Sent:Friday, February 19, 2016 11:53 AM
To:cf-dev(a)lists.cloudfoundry.org(mailto:cf-dev(a)lists.cloudfoundry.org)
Subject:[cf-dev] Proposal: App Auto-Scaling service







Dear community,





We have relaunched this initiative and put together a proposal for an App Auto-Scaling service, ready for your review:





https://docs.google.com/document/d/1HHhj9ZK-trI_VVDR34bwOnWem83UAq5_Pjr9imRTazY/edit?usp=sharing





The proposal includes feedback from SAP, as well as some of the suggestions you have shared with me.





The intent is to start with a MVP, really a minimal yet useful solution, that can serve as a foundation to build upon to address the various problems raised.





We welcome your feedback, as well as your participation in this exciting project!





Regards,


Dies Koper


Fujitsu





Re: Issue with stacks related to removal of libmariadb

John Shahid
 

Hi,

We (the buildpack team) just found out that stacks version 1.47 had an incomplete fix for applications linked against libmysqlclient.so. The new version 1.48 will contain a complete fix for the issue.

Sorry for the inconvenience.


Re: Adding previous_instances and previous_memory fields to cf_event

Hristo Iliev
 

Hi again,

Would you consider a PR that adds previous memory & instances to the app usage events? Does this two additional fields make a sense?

Regards,
Hristo Iliev


Warden Name Space

ravi malhotra
 

Why do I not see linux name spaces for my warden instances?

root(a)874c4cea-19ed-41c7-abd2-09eb5851d54d:/var/vcap/data/warden/depot# ip netns list <-- note that the output was blank
root(a)874c4cea-19ed-41c7-abd2-09eb5851d54d:/var/vcap/data/warden/depot# ls
19b0ug03pal 19b0ug03pba tmp <-- however, there are two containers up and running


Re: Proposal to Change CATs Ownership

Mike Youngstrom
 

I don't have any show stopping cases. But, my 2 main concerns are:

* Conceptually speaking if the CATS are for all will making them part of
capi hinder other teams from contributing to it?

* Having the CATs part of CAPI will require me to fork CAPI when I need to
fix/customize a test specific to our environment, something we frequently
need to do. Long term I'd prefer to fork a smaller more single purpose
release when these situations arise.

Mike

On Wed, Mar 23, 2016 at 12:43 PM, Utako Ueda <uueda(a)pivotal.io> wrote:

We had a series of meetings to figure out a good path for CATs that ranged
from multiple teams to smaller groups. We met most recently to address
concerns that include the following:

• Workflow and Release Bumping Issues: CATs relies on calls to specific
versions of CC API to run successfully. The CAPI CI currently bumps
cloud_controller_ng within capi-release, and on a successful run of CATs
(which lives on cf-release develop), capi-release then gets bumped in
cf-release develop. This leads to a "chicken and egg" scenario, in that
when changes are made to both CATs and CC, both cf-release and capi
pipelines are broken until a manual fix is made.
• In a world where cf-release no longer exists, how do we ensure CATs uses
the correct versions of the CF CLI and CC API?

tl;dr: Though not all of the CATs test the CC API explicitly, they all
make use of the CC API and therefore make CC a choke point. Having CATs as
a separate release may be a good idea, but doesn't necessarily address the
strong coupling issues.

We'd like to know if there are specific cases in which this will be
detrimental to other projects' workflows before moving forward.


On Wed, Mar 23, 2016 at 4:08 AM, Michael Fraenkel <
michael.fraenkel(a)gmail.com> wrote:

Can you explain why CATs should live under CAPI?
CATs now represents acceptance test for all of the Cloud Foundry function
driven mainly via the CLI.
Tieing this to any one release seems a bit artificial.
CATs is about testing the aggregation of all the various releases not
just CAPI.

I am more surprised that it wasn't suggested to be its own release which
dictated the versions for all releases that had passed.

- Michael


On 3/22/16 3:05 AM, Utako Ueda wrote:

Hi all,

The CAPI team would like to take ownership of the CF acceptance tests
<https://github.com/cloudfoundry/cf-acceptance-tests/> and include them
as part of CAPI release <http://github.com/cloudfoundry/capi-release>.

This solves several pain points we've experienced over the last few
months, mainly due to the strong coupling between CATs and the Cloud
Controller API.

Our plan is to submodule the CATs repo in to CAPI release, and bump CATs
on a successful run through the CAPI ci pipeline. At this point, CAPI
release will be bumped in cf-release develop, which other teams will
consume for their own testing purposes.

We hope to make these changes in the near future as we wrap up our
release extraction from cf-release. We'd like to know if any teams have any
concerns about this before we proceed, so do let us know as soon as
possible so we can address them.

Thanks,
Utako, CF CAPI Team



Re: Proposal to Change CATs Ownership

Utako Ueda
 

We had a series of meetings to figure out a good path for CATs that ranged
from multiple teams to smaller groups. We met most recently to address
concerns that include the following:

• Workflow and Release Bumping Issues: CATs relies on calls to specific
versions of CC API to run successfully. The CAPI CI currently bumps
cloud_controller_ng within capi-release, and on a successful run of CATs
(which lives on cf-release develop), capi-release then gets bumped in
cf-release develop. This leads to a "chicken and egg" scenario, in that
when changes are made to both CATs and CC, both cf-release and capi
pipelines are broken until a manual fix is made.
• In a world where cf-release no longer exists, how do we ensure CATs uses
the correct versions of the CF CLI and CC API?

tl;dr: Though not all of the CATs test the CC API explicitly, they all make
use of the CC API and therefore make CC a choke point. Having CATs as a
separate release may be a good idea, but doesn't necessarily address the
strong coupling issues.

We'd like to know if there are specific cases in which this will be
detrimental to other projects' workflows before moving forward.


On Wed, Mar 23, 2016 at 4:08 AM, Michael Fraenkel <
michael.fraenkel(a)gmail.com> wrote:

Can you explain why CATs should live under CAPI?
CATs now represents acceptance test for all of the Cloud Foundry function
driven mainly via the CLI.
Tieing this to any one release seems a bit artificial.
CATs is about testing the aggregation of all the various releases not just
CAPI.

I am more surprised that it wasn't suggested to be its own release which
dictated the versions for all releases that had passed.

- Michael


On 3/22/16 3:05 AM, Utako Ueda wrote:

Hi all,

The CAPI team would like to take ownership of the CF acceptance tests
<https://github.com/cloudfoundry/cf-acceptance-tests/> and include them
as part of CAPI release <http://github.com/cloudfoundry/capi-release>.

This solves several pain points we've experienced over the last few
months, mainly due to the strong coupling between CATs and the Cloud
Controller API.

Our plan is to submodule the CATs repo in to CAPI release, and bump CATs
on a successful run through the CAPI ci pipeline. At this point, CAPI
release will be bumped in cf-release develop, which other teams will
consume for their own testing purposes.

We hope to make these changes in the near future as we wrap up our release
extraction from cf-release. We'd like to know if any teams have any
concerns about this before we proceed, so do let us know as soon as
possible so we can address them.

Thanks,
Utako, CF CAPI Team



Re: Reg the upgrade from cf-205 to cf-231

Amit Kumar Gupta
 

Just a heads up, while the community is committed to helping people use CF,
people here are essentially volunteering their time and hence cannot
respond differently to urgent or blocking issues.

Also, your new issue seems fairly different from your original issue. I
would recommend starting a new thread with a clear title of the issue, it
will have a better chance of catching the eye of some of the logging
experts. I would even recommend creating a GH issue at
github.com/cloudfoundry/loggregator.

Best,
Amit

On Tue, Mar 22, 2016 at 9:27 PM, Ben R <vagcom.ben(a)gmail.com> wrote:


Can you curl that endpoint. Have you added cert and private key for uaa?

Ben

On Tue, Mar 22, 2016 at 8:29 PM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

Hi



Gentle reminder.. Sorry it’s a kind of blocking issue for us.





Regards

Nithiyasri



*From:* Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at
Cisco)
*Sent:* Tuesday, March 22, 2016 5:29 PM
*To:* 'Amit Gupta' <agupta(a)pivotal.io>
*Cc:* Gwenn Etourneau <getourneau(a)pivotal.io>; Discussions about Cloud
Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>;
Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com>
*Subject:* RE: [cf-dev] Re: Reg the upgrade from cf-205 to cf-231



Hi Amit/Gwenn



We are getting the following error while doing cf push and unable to see
the logs..



Warning: error tailing logs

Error dialing loggregator server: local error: record overflow.

Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is wss://
loggregator.testinceptionjk.cisco.com:80).

Starting app logconsumerms in org vms / space app as admin..



I googled and updated the loggegrator port from 80 to 4443. I observed a
different error and the endpoint begins with ws:. Previously it was wss:



Warning: error tailing logs

Error dialing loggregator server: unexpected EOF.

Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is ws://
loggregator.testinceptionjk.cisco.com:4443).





Properties:



logger_endpoint:

port: 4443



The spiff generated manifest has zero instances of loggregator. The same
has been used by us.



Regards

Nithiyasri





*From:* Amit Gupta [mailto:agupta(a)pivotal.io <agupta(a)pivotal.io>]
*Sent:* Tuesday, March 22, 2016 2:16 AM
*To:* Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)
<ngnanase(a)cisco.com>
*Cc:* Gwenn Etourneau <getourneau(a)pivotal.io>; Discussions about Cloud
Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>;
Jayarajan Ramapurath Kozhummal (jayark) <jayark(a)cisco.com>

*Subject:* Re: [cf-dev] Re: Reg the upgrade from cf-205 to cf-231



Awesome!



On Mon, Mar 21, 2016 at 3:12 AM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

Thank you Gwenn and Amit

The fix works.



Regards

Nitiyasri



*From:* Gwenn Etourneau [mailto:getourneau(a)pivotal.io]
*Sent:* Saturday, March 19, 2016 4:38 AM
*To:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>
*Cc:* Amit Gupta <agupta(a)pivotal.io>; Nithiyasri Gnanasekaran -X
(ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com>
*Subject:* Re: [cf-dev] Re: Reg the upgrade from cf-205 to cf-231



Hi,



What is the value of uaa.require_https in your manifest ? By default is
true, try to put to false





Thanks



On Sat, Mar 19, 2016 at 6:05 AM, Jayarajan Ramapurath Kozhummal (jayark) <
jayark(a)cisco.com> wrote:

Hi Amit,



Thanks a lot for your support as always!



Please see the detailed logs you are looking for:-





root(a)testinceptionjk:/opt/cisco/vms-installer/tenant-testinceptionjk/cf-deploy#
cf login

API endpoint: https://api.testinceptionjk.cisco.com



REQUEST: [2016-03-18T16:30:28Z]

GET /v2/info HTTP/1.1

Host: api.testinceptionjk.cisco.com

Accept: application/json

Content-Type: application/json

User-Agent: go-cli 6.12.2-24abed3 / linux







RESPONSE: [2016-03-18T16:30:28Z]

HTTP/1.1 200 OK

Content-Length: 632

Content-Type: application/json;charset=utf-8

Date: Fri, 18 Mar 2016 16:30:28 GMT

Server: nginx

X-Content-Type-Options: nosniff

X-Vcap-Request-Id: 1cffe445-b169-426f-61fe-f421654bf997

X-Vcap-Request-Id:
a4da6848-66c7-4375-6509-3688b69232a2::fbaf3999-67d2-4fd4-b35e-c02c2af15281



{"name":"","build":"","support":"http://support.cloudfoundry.com
","version":0,"description":"","authorization_endpoint":"
http://uaa.testinceptionjk.cisco.com","token_endpoint":"
http://uaa.testinceptionjk.cisco.com
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.51.0","app_ssh_endpoint":"
ssh.testinceptionjk.cisco.com:2222
","app_ssh_host_key_fingerprint":null,"app_ssh_oauth_client":"ssh-proxy","routing_endpoint":"
https://api.testinceptionjk.cisco.com/routing","logging_endpoint":"wss://
loggregator.testinceptionjk.cisco.com:80
","doppler_logging_endpoint":"wss://
doppler.testinceptionjk.cisco.com:4443"}



REQUEST: [2016-03-18T16:30:28Z]

GET /login HTTP/1.1

Host: uaa.testinceptionjk.cisco.com

Accept: application/json

Content-Type: application/json

User-Agent: go-cli 6.12.2-24abed3 / linux







REQUEST: [2016-03-18T16:30:28Z]

GET /login HTTP/0.0

Host: uaa.testinceptionjk.cisco.com

Accept: application/json

Referer: http://uaa.testinceptionjk.cisco.com/login

User-Agent: go-cli 6.12.2-24abed3 / linux







RESPONSE: [2016-03-18T16:30:28Z]

HTTP/1.1 200 OK

Content-Length: 487

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Cache-Control: no-store

Content-Language: en-US

Content-Type: application/json;charset=UTF-8

Date: Fri, 18 Mar 2016 16:30:28 GMT

Expires: 0

Pragma: no-cache

Server: Apache-Coyote/1.1

Strict-Transport-Security: max-age=31536000 ; includeSubDomains

X-Content-Type-Options: nosniff

X-Frame-Options: DENY

X-Vcap-Request-Id: 7a845595-63f4-4c97-5397-52ffca0f2f4b

X-Xss-Protection: 1; mode=block



{"app":{"version":"3.1.0"},"links":{"uaa":"
http://uaa.testinceptionjk.cisco.com","passwd":"
https://console.testinceptionjk.cisco.com/password_resets/new","login":"
http://login.testinceptionjk.cisco.com","register":"
https://console.testinceptionjk.cisco.com/register
"},"zone_name":"uaa","entityID":"login.testinceptionjk.cisco.com
","commit_id":"9b5c13d","idpDefinitions":{},"prompts":{"username":["text","Email"],"password":["password","Password"]},"timestamp":"2016-02-05T14:27:13+0000"}



Email> admin



Password>

Authenticating...



REQUEST: [2016-03-18T16:30:35Z]

POST /oauth/token HTTP/1.1

Host: uaa.testinceptionjk.cisco.com

Accept: application/json

Authorization: [PRIVATE DATA HIDDEN]

Content-Type: application/x-www-form-urlencoded

User-Agent: go-cli 6.12.2-24abed3 / linux



grant_type=password&password=[PRIVATE DATA HIDDEN]&scope=&username=admin



RESPONSE: [2016-03-18T16:30:35Z]

HTTP/1.1 400 Bad Request

Content-Length: 1086

Content-Language: en

Content-Type: text/html;charset=utf-8

Date: Fri, 18 Mar 2016 16:30:35 GMT

Server: Apache-Coyote/1.1

X-Vcap-Request-Id: fbe5f151-ae1f-48fa-673d-f002dd3ab04f



<html><head><title>Apache Tomcat/7.0.61 - Error
report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--></style>
</head><body><h1>HTTP Status 400 - {&quot;error&quot;: &quot;request must
be over https&quot;}</h1><HR size="1" noshade="noshade"><p><b>type</b>
Status report</p><p><b>message</b> <u>{&quot;error&quot;: &quot;request
must be over https&quot;}</u></p><p><b>description</b> <u>The request sent
by the client was syntactically incorrect.</u></p><HR size="1"
noshade="noshade"><h3>Apache Tomcat/7.0.61</h3></body></html>

Server error, status code: 400, error code: , message:



Password>

Authenticating...



REQUEST: [2016-03-18T16:30:42Z]

POST /oauth/token HTTP/1.1

Host: uaa.testinceptionjk.cisco.com

Accept: application/json

Authorization: [PRIVATE DATA HIDDEN]

Content-Type: application/x-www-form-urlencoded

User-Agent: go-cli 6.12.2-24abed3 / linux



grant_type=password&password=[PRIVATE DATA HIDDEN]&scope=&username=admin



RESPONSE: [2016-03-18T16:30:42Z]

HTTP/1.1 400 Bad Request

Content-Length: 1086

Content-Language: en

Content-Type: text/html;charset=utf-8

Date: Fri, 18 Mar 2016 16:30:42 GMT

Server: Apache-Coyote/1.1

X-Vcap-Request-Id: bfa611f1-46bc-42de-4b81-37e40bab8fe7



<html><head><title>Apache Tomcat/7.0.61 - Error
report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--></style>
</head><body><h1>HTTP Status 400 - {&quot;error&quot;: &quot;request must
be over https&quot;}</h1><HR size="1" noshade="noshade"><p><b>type</b>
Status report</p><p><b>message</b> <u>{&quot;error&quot;: &quot;request
must be over https&quot;}</u></p><p><b>description</b> <u>The request sent
by the client was syntactically incorrect.</u></p><HR size="1"
noshade="noshade"><h3>Apache Tomcat/7.0.61</h3></body></html>

Server error, status code: 400, error code: , message:



Password>



Thanks

Jayaraj



*From: *Amit Gupta <agupta(a)pivotal.io>
*Date: *Friday, March 18, 2016 at 11:37 AM
*To: *"Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at
Cisco)" <ngnanase(a)cisco.com>
*Cc: *"Discussions about Cloud Foundry projects and the system overall."
<cf-dev(a)lists.cloudfoundry.org>, Jayarajan Ramapurath Kozhummal <
jayark(a)cisco.com>


*Subject: *Re: Reg the upgrade from cf-205 to cf-231



Can you do:



CF_TRACE=true cf login



so we can get more info about where that 400 response code is coming from.



Best,

Amit



On Fri, Mar 18, 2016 at 5:49 AM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

Hi Amit



Bosh deployment has completed successfully. I could set the endpoint,
but I could not login to it with the credentials I have given in the
properties. Logs and properties below.



root(a)testdeploy:/deploy# cf login

API endpoint: https://api.testdeploy.cisco.com



Email> admin



Password>

Authenticating...

Server error, status code: 400, error code: , message:



Password>

Authenticating...

Server error, status code: 400, error code: , message:





PROPERTIES::



scim:

# external_groups: null

# groups: null

userids_enabled: true

users:

- admin|<%= $common_password
%>|scim.write,scim.read,openid,cloud_controller.admin,uaa.admin,password.write

- services|<%= $common_password
%>|scim.write,scim.read,openid,cloud_controller.admin

#spring_profiles: null



Regards

Nithiyasri



*From:* Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at
Cisco)
*Sent:* Friday, March 18, 2016 7:23 AM
*To:* 'Amit Gupta' <agupta(a)pivotal.io>
*Cc:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>; Jayarajan Ramapurath Kozhummal (jayark) <
jayark(a)cisco.com>
*Subject:* RE: Reg the upgrade from cf-205 to cf-231



Hi Amit



Thanks for your quick reply. Pls let me know in which Vm , should I login
to see the compilation logs..



Previously when I did the upgrade, it dint compile the individual
packages. Logs below.

Kindly let me know why is it trying to compile individual package now.




---------------------------------------------------------------------------------------

Started preparing package compilation > Finding packages to compile. Done
(00:00:00)



Started preparing dns > Binding DNS. Done (00:00:00)







Regards

Nithiyasri



*From:* Amit Gupta [mailto:agupta(a)pivotal.io <agupta(a)pivotal.io>]
*Sent:* Friday, March 18, 2016 5:36 AM
*To:* Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco)
<ngnanase(a)cisco.com>
*Cc:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>; Jayarajan Ramapurath Kozhummal (jayark) <
jayark(a)cisco.com>
*Subject:* Re: Reg the upgrade from cf-205 to cf-231



I'm not sure why it's taking >40 mins to compile some simple go
binaries. You may have network issues (compilation jobs taking a long time
to download dependencies from BOSH director blobstore, or upload compiled
resulting artifacts) or you may need more CPU on your compilation
machines. You can try to SSH into the compilation VMs while they're
running to see what they're doing over those 40 minutes.



On Thu, Mar 17, 2016 at 7:06 AM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

Hi Amit



I was able to do an upgrade of deployment from cf-205 to cf-231 multiple
times.

But now, I am getting timeout errors while compiling buildpacks once in
rootfs or in buildpack_java or in nginx..

Could you pls help us resolve this error..



Following is the one:



Done compiling packages >
buildpack_java/d65c2d20fc067c9995c18d195e0ff117ea9202c0 (00:24:23)

Done compiling packages >
rtr/2d7de4f6fc25938c21c5be87174f95583feb14b5 (00:38:22)

Failed compiling packages >
rootfs_cflinuxfs2/ac0ba35f1106af81cb735eb56360c6cc924af83a: Timed out
waiting for Server `3c04cecc-1308-4da
f-8dc5-b9c1924004c3' to be active (00:41:23)

Failed compiling packages >
nginx/bf3af6163e13887aacd230bbbc5eff90213ac6af: Timed out waiting for
Server `fbbb8647-1415-46d9-92de-d030f 4164b6b'
to be active (00:43:31)







Failed compiling packages >
cli/b61b75716312df9f4f7c81a17f3a7de456efce71: Timed out waiting for Server
`223ec673-b66d-4362-8e27-0859805 2ebe5' to be
active (00:44:49)



Error 100: Timed out waiting for Server
`3c04cecc-1308-4daf-8dc5-b9c1924004c3' to be active





Regards

Nithiyasri









Re: Proposal to Change CATs Ownership

Mike Youngstrom
 

I agree with Michael. I think the CATs and Smoke tests should be in their
own release(s).

Mike

On Wed, Mar 23, 2016 at 5:08 AM, Michael Fraenkel <
michael.fraenkel(a)gmail.com> wrote:

Can you explain why CATs should live under CAPI?
CATs now represents acceptance test for all of the Cloud Foundry function
driven mainly via the CLI.
Tieing this to any one release seems a bit artificial.
CATs is about testing the aggregation of all the various releases not just
CAPI.

I am more surprised that it wasn't suggested to be its own release which
dictated the versions for all releases that had passed.

- Michael


On 3/22/16 3:05 AM, Utako Ueda wrote:

Hi all,

The CAPI team would like to take ownership of the CF acceptance tests
<https://github.com/cloudfoundry/cf-acceptance-tests/> and include them
as part of CAPI release <http://github.com/cloudfoundry/capi-release>.

This solves several pain points we've experienced over the last few
months, mainly due to the strong coupling between CATs and the Cloud
Controller API.

Our plan is to submodule the CATs repo in to CAPI release, and bump CATs
on a successful run through the CAPI ci pipeline. At this point, CAPI
release will be bumped in cf-release develop, which other teams will
consume for their own testing purposes.

We hope to make these changes in the near future as we wrap up our release
extraction from cf-release. We'd like to know if any teams have any
concerns about this before we proceed, so do let us know as soon as
possible so we can address them.

Thanks,
Utako, CF CAPI Team


5101 - 5120 of 9426