Date   

announcement: online cf CLI command reference guide

Koper, Dies <diesk@...>
 

Dear cf CLI users,

I have been working with the PubTools team to produce an online cf CLI command reference guide, and am happy to now announce it's ready:


* http://docs.cloudfoundry.org/cf-cli/cf-help.html is a new page in the CLI docs listing the output of `cf help`, with hyperlinks to the help pages for each subcommand

* http://cli.cloudfoundry.org/en-US/cf hosts the index page and pages for the subcommands that the above page links to, with a language selector for each of the CLI's supported locales.

The pages are generated from cf CLI help output and will be updated with each cf CLI release.

Some of the benefits of this online reference guide is that we can more easily point users with questions to the appropriate command help, e.g.
http://cli.cloudfoundry.org/en-US/cf/push.html

and the reader can then easily change to their preferred locale, e.g.
http://cli.cloudfoundry.org/ja-JP/cf/push.html

Also, I'd like to work with the Docs team and other PMs to see where we want to update existing CF documentation to point to this reference guide to reduce duplication in, and maintenance of articles that describe commands that expose CF features.

Please let us know what you think!

Regards,
Dies Koper
Cloud Foundry CLI PM


Re: App running even after delete. Pointers on finding it and debugging?

Amit Kumar Gupta
 

Ok, I would use veritas to look at the Diego BBS, and confirm that it still
thinks the app is there. You can also go onto the router and query its
HTTP endpoint to confirm that the route you're seeing is also still there:
https://github.com/cloudfoundry/gorouter#instrumentation. Lastly I would
connect to the CCDB and confirm that the app and route are *not* there.
This will reduce the problem to figuring out why Diego isn't being updated
to know that the non-existing app is no longer desired.

On Mon, Apr 4, 2016 at 3:47 PM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:

The route still exists. I was reluctant to delete it and have the "app"
still running. I wanted some way to track it down, not that it has helped,
other than let me know it is still running.

Pushed the app, with a different name/host, with no problems and it runs
as it should.

On Mon, Apr 4, 2016 at 6:17 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Tom,

So you're saying that none of the org/spaces shows the app or the route,
but the app continues to run and be routeable?

I could imagine this happen if some CC Bridge components are not able to
talk to either CC or Diego BBS, leaving the data in the Diego BBS stale.
In the case of stale info, Diego may not know that the LRP is no longer
desired, and it will do the safe thing of keeping it around, and emitting
its route to the gorouter, which just does what it's told (it doesn't check
whether CC knows about the route or not).

Are you able to push new apps or delete other apps with the Diego backend?

Amit

On Fri, Apr 1, 2016 at 1:00 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

JT,

Thanks for responding.

This is a test runtime and small. I checked all orgs and spaces. No
routes matching the app.

Found the route information and the result:

{

"total_results": 0,

"total_pages": 1,

"prev_url": null,

"next_url": null,

"resources": []

}

To learn what the output may look like, I check existing routes with
apps and without. The output appears to be the same as if the app has been
deleted.

Even now, the app url still returns a page from the app, even though it
is deleted.

Thanks,

Tom

On Fri, Apr 1, 2016 at 1:52 PM, JT Archie <jarchie(a)pivotal.io> wrote:

Tom,

Are you sure the route isn't bound to another application in another
org/space?

When you do `cf routes` it only show routes for the current space. You
can hit specific API endpoints though to get all the apps for a route.

For example, `cf
curl /v2/routes/89fc2a5e-3a9b-4a88-a360-e405cdbd6f87/apps` will show all
the apps for a particular route. Obviously replacing the route ID with the
correct ID. To find that, I recommend going through `CF_TRACE=true cf
routes` and grabbing the ID.

Let see if you can hunt it down that way.

Kind Regards,

JT

On Fri, Apr 1, 2016 at 8:51 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

cf 230, diego 0.1450.0, etcd 27, garden-linux 0.330.0
Default to diego true.

Developer deployed a java application. Deleted the application: cf
delete <app> No errors.
The app still responds. The only thing left is the route.
I've not encountered this before. Delete has been delete and even if
route remains, 404 Not Found: Requested route ('<hostname.domain>') does
not exist. is returned.

Pointers on tracking this down appreciated.

Tom


Re: App running even after delete. Pointers on finding it and debugging?

Sabha
 

Did you try running directly "cf curl /v2/routes"? this would provide a
real big output of all routes across all orgs/spaces with route guid &
paths and your problematic route would definitely be listed there.

Once you get the route id, just do "cf curl /v2/routes/<route-guid> -X
DELETE". That should clean it up.

-Sabha

On Mon, Apr 4, 2016 at 3:47 PM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:

The route still exists. I was reluctant to delete it and have the "app"
still running. I wanted some way to track it down, not that it has helped,
other than let me know it is still running.

Pushed the app, with a different name/host, with no problems and it runs
as it should.

On Mon, Apr 4, 2016 at 6:17 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Tom,

So you're saying that none of the org/spaces shows the app or the route,
but the app continues to run and be routeable?

I could imagine this happen if some CC Bridge components are not able to
talk to either CC or Diego BBS, leaving the data in the Diego BBS stale.
In the case of stale info, Diego may not know that the LRP is no longer
desired, and it will do the safe thing of keeping it around, and emitting
its route to the gorouter, which just does what it's told (it doesn't check
whether CC knows about the route or not).

Are you able to push new apps or delete other apps with the Diego backend?

Amit

On Fri, Apr 1, 2016 at 1:00 PM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

JT,

Thanks for responding.

This is a test runtime and small. I checked all orgs and spaces. No
routes matching the app.

Found the route information and the result:

{

"total_results": 0,

"total_pages": 1,

"prev_url": null,

"next_url": null,

"resources": []

}

To learn what the output may look like, I check existing routes with
apps and without. The output appears to be the same as if the app has been
deleted.

Even now, the app url still returns a page from the app, even though it
is deleted.

Thanks,

Tom

On Fri, Apr 1, 2016 at 1:52 PM, JT Archie <jarchie(a)pivotal.io> wrote:

Tom,

Are you sure the route isn't bound to another application in another
org/space?

When you do `cf routes` it only show routes for the current space. You
can hit specific API endpoints though to get all the apps for a route.

For example, `cf
curl /v2/routes/89fc2a5e-3a9b-4a88-a360-e405cdbd6f87/apps` will show all
the apps for a particular route. Obviously replacing the route ID with the
correct ID. To find that, I recommend going through `CF_TRACE=true cf
routes` and grabbing the ID.

Let see if you can hunt it down that way.

Kind Regards,

JT

On Fri, Apr 1, 2016 at 8:51 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

cf 230, diego 0.1450.0, etcd 27, garden-linux 0.330.0
Default to diego true.

Developer deployed a java application. Deleted the application: cf
delete <app> No errors.
The app still responds. The only thing left is the route.
I've not encountered this before. Delete has been delete and even if
route remains, 404 Not Found: Requested route ('<hostname.domain>') does
not exist. is returned.

Pointers on tracking this down appreciated.

Tom
--
Sabha Parameswaran
Platform Engineering, Cloud Foundry
Pivotal, Inc.
m: +1 (415) 244-5554


Re: App running even after delete. Pointers on finding it and debugging?

Tom Sherrod <tom.sherrod@...>
 

The route still exists. I was reluctant to delete it and have the "app"
still running. I wanted some way to track it down, not that it has helped,
other than let me know it is still running.

Pushed the app, with a different name/host, with no problems and it runs as
it should.

On Mon, Apr 4, 2016 at 6:17 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Tom,

So you're saying that none of the org/spaces shows the app or the route,
but the app continues to run and be routeable?

I could imagine this happen if some CC Bridge components are not able to
talk to either CC or Diego BBS, leaving the data in the Diego BBS stale.
In the case of stale info, Diego may not know that the LRP is no longer
desired, and it will do the safe thing of keeping it around, and emitting
its route to the gorouter, which just does what it's told (it doesn't check
whether CC knows about the route or not).

Are you able to push new apps or delete other apps with the Diego backend?

Amit

On Fri, Apr 1, 2016 at 1:00 PM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:

JT,

Thanks for responding.

This is a test runtime and small. I checked all orgs and spaces. No
routes matching the app.

Found the route information and the result:

{

"total_results": 0,

"total_pages": 1,

"prev_url": null,

"next_url": null,

"resources": []

}

To learn what the output may look like, I check existing routes with apps
and without. The output appears to be the same as if the app has been
deleted.

Even now, the app url still returns a page from the app, even though it
is deleted.

Thanks,

Tom

On Fri, Apr 1, 2016 at 1:52 PM, JT Archie <jarchie(a)pivotal.io> wrote:

Tom,

Are you sure the route isn't bound to another application in another
org/space?

When you do `cf routes` it only show routes for the current space. You
can hit specific API endpoints though to get all the apps for a route.

For example, `cf
curl /v2/routes/89fc2a5e-3a9b-4a88-a360-e405cdbd6f87/apps` will show all
the apps for a particular route. Obviously replacing the route ID with the
correct ID. To find that, I recommend going through `CF_TRACE=true cf
routes` and grabbing the ID.

Let see if you can hunt it down that way.

Kind Regards,

JT

On Fri, Apr 1, 2016 at 8:51 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

cf 230, diego 0.1450.0, etcd 27, garden-linux 0.330.0
Default to diego true.

Developer deployed a java application. Deleted the application: cf
delete <app> No errors.
The app still responds. The only thing left is the route.
I've not encountered this before. Delete has been delete and even if
route remains, 404 Not Found: Requested route ('<hostname.domain>') does
not exist. is returned.

Pointers on tracking this down appreciated.

Tom


cf client - Extended cli Table implementation.

Kupries, Andreas <andreas.kupries@...>
 

Hello.

At
https://github.com/andreas-kupries/cli/tree/hcf-466-cli-extended-table
is a fork of the CF client containing a rewrite of the
cf/terminal/table.go
implementation to overcome a few limitations of the existing code I came across while writing some plugins.

The list of features I added are:
- Allows multi-line cell content.
- Ability to suppress header row from output.
- General column transformation scheme for arbitrary colorization, vertical separators, and the like
Some internal changes:
- Use of go buffers over strings (less memory churn due to string immutability)
- Generates less output, trims superfluous trailing whitespace.

Is this something of interest to the CF cli team ?

Andreas Kupries
System/Software Engineer
HP Cloud

andreas.kupries(a)hpe.com
T +1 778 327 6590
Hewlett-Packard Company
1700-409 Granville St
Vancouver, BC, V6C 1T2
Canada


Re: CF Installed on Physical Node

Amit Kumar Gupta
 

Hi Raymond,

Yes, you can deploy Cloud Foundry without using the Ops Manager appliance.
However "Elastic Runtime", "Ops Manager", etc. are Pivotal products built
on top of the open source Cloud Foundry project. This mailing list is for
questions related to the open source Cloud Foundry project itself.

For information about deploy OSS Cloud Foundry, please start with
http://docs.cloudfoundry.org/deploying/index.html

For information about using and deploying Pivotal Cloud Foundry products,
you can check out http://docs.pivotal.io/pivotalcf/installing/pcf-docs.html

Best,
Amit

On Mon, Apr 4, 2016 at 2:32 PM, Raymond J Steele <raymondsteele(a)gmail.com>
wrote:

Can Cloud Foundry be installed on a physical node versus via VMware
appliance? Also, can you cluster the cloudfoundry elastic runtime, ops
manager, etc..?


Re: App running even after delete. Pointers on finding it and debugging?

Amit Kumar Gupta
 

You can also use the "veritas" tool to inspect more of what's going on with
the Diego BBS, in particular you could see if the cf apps domain is fresh.

https://github.com/pivotal-cf-experimental/veritas

On Mon, Apr 4, 2016 at 3:17 PM, Amit Gupta <agupta(a)pivotal.io> wrote:

Tom,

So you're saying that none of the org/spaces shows the app or the route,
but the app continues to run and be routeable?

I could imagine this happen if some CC Bridge components are not able to
talk to either CC or Diego BBS, leaving the data in the Diego BBS stale.
In the case of stale info, Diego may not know that the LRP is no longer
desired, and it will do the safe thing of keeping it around, and emitting
its route to the gorouter, which just does what it's told (it doesn't check
whether CC knows about the route or not).

Are you able to push new apps or delete other apps with the Diego backend?

Amit

On Fri, Apr 1, 2016 at 1:00 PM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:

JT,

Thanks for responding.

This is a test runtime and small. I checked all orgs and spaces. No
routes matching the app.

Found the route information and the result:

{

"total_results": 0,

"total_pages": 1,

"prev_url": null,

"next_url": null,

"resources": []

}

To learn what the output may look like, I check existing routes with apps
and without. The output appears to be the same as if the app has been
deleted.

Even now, the app url still returns a page from the app, even though it
is deleted.

Thanks,

Tom

On Fri, Apr 1, 2016 at 1:52 PM, JT Archie <jarchie(a)pivotal.io> wrote:

Tom,

Are you sure the route isn't bound to another application in another
org/space?

When you do `cf routes` it only show routes for the current space. You
can hit specific API endpoints though to get all the apps for a route.

For example, `cf
curl /v2/routes/89fc2a5e-3a9b-4a88-a360-e405cdbd6f87/apps` will show all
the apps for a particular route. Obviously replacing the route ID with the
correct ID. To find that, I recommend going through `CF_TRACE=true cf
routes` and grabbing the ID.

Let see if you can hunt it down that way.

Kind Regards,

JT

On Fri, Apr 1, 2016 at 8:51 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

cf 230, diego 0.1450.0, etcd 27, garden-linux 0.330.0
Default to diego true.

Developer deployed a java application. Deleted the application: cf
delete <app> No errors.
The app still responds. The only thing left is the route.
I've not encountered this before. Delete has been delete and even if
route remains, 404 Not Found: Requested route ('<hostname.domain>') does
not exist. is returned.

Pointers on tracking this down appreciated.

Tom


Re: App running even after delete. Pointers on finding it and debugging?

Amit Kumar Gupta
 

Tom,

So you're saying that none of the org/spaces shows the app or the route,
but the app continues to run and be routeable?

I could imagine this happen if some CC Bridge components are not able to
talk to either CC or Diego BBS, leaving the data in the Diego BBS stale.
In the case of stale info, Diego may not know that the LRP is no longer
desired, and it will do the safe thing of keeping it around, and emitting
its route to the gorouter, which just does what it's told (it doesn't check
whether CC knows about the route or not).

Are you able to push new apps or delete other apps with the Diego backend?

Amit

On Fri, Apr 1, 2016 at 1:00 PM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:

JT,

Thanks for responding.

This is a test runtime and small. I checked all orgs and spaces. No routes
matching the app.

Found the route information and the result:

{

"total_results": 0,

"total_pages": 1,

"prev_url": null,

"next_url": null,

"resources": []

}

To learn what the output may look like, I check existing routes with apps
and without. The output appears to be the same as if the app has been
deleted.

Even now, the app url still returns a page from the app, even though it is
deleted.

Thanks,

Tom

On Fri, Apr 1, 2016 at 1:52 PM, JT Archie <jarchie(a)pivotal.io> wrote:

Tom,

Are you sure the route isn't bound to another application in another
org/space?

When you do `cf routes` it only show routes for the current space. You
can hit specific API endpoints though to get all the apps for a route.

For example, `cf
curl /v2/routes/89fc2a5e-3a9b-4a88-a360-e405cdbd6f87/apps` will show all
the apps for a particular route. Obviously replacing the route ID with the
correct ID. To find that, I recommend going through `CF_TRACE=true cf
routes` and grabbing the ID.

Let see if you can hunt it down that way.

Kind Regards,

JT

On Fri, Apr 1, 2016 at 8:51 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

cf 230, diego 0.1450.0, etcd 27, garden-linux 0.330.0
Default to diego true.

Developer deployed a java application. Deleted the application: cf
delete <app> No errors.
The app still responds. The only thing left is the route.
I've not encountered this before. Delete has been delete and even if
route remains, 404 Not Found: Requested route ('<hostname.domain>') does
not exist. is returned.

Pointers on tracking this down appreciated.

Tom


CF Installed on Physical Node

Raymond J Steele
 

Can Cloud Foundry be installed on a physical node versus via VMware appliance? Also, can you cluster the cloudfoundry elastic runtime, ops manager, etc..?


Re: Adding previous_instances and previous_memory fields to cf_event

KRuelY <kevinyudhiswara@...>
 

Thank you for the effort and merging the pull request.



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Adding-previous-instances-and-previous-memory-fields-to-cf-event-tp4100p4431.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Adding previous_instances and previous_memory fields to cf_event

Hristo Iliev
 

Hi,

Seems this was merged 4 days ago.

Thanks a lot,
Hristo Iliev

On 4 Apr 2016 15:49, "Hristo Iliev" <hsiliev(a)gmail.com> wrote:

Hey,

Any news about this PR? We tried to minimize the change and make it easer
for review.

Regards,
Hristo Iliev

2016-03-29 14:50 GMT+03:00 Hristo Iliev <hsiliev(a)gmail.com>:

Hi again,

We created https://github.com/cloudfoundry/cloud_controller_ng/pull/569

Can you please take a look and comment on possible problems and missed
use-cases?

Regards,
Hristo Iliev

2016-03-24 18:06 GMT+02:00 Hristo Iliev <hsiliev(a)gmail.com>:

Hi Nick,

Adding previous state sounds good. Will add it in the PR as well.

Thanks,
Hristo Iliev

2016-03-24 17:29 GMT+02:00 Nicholas Calugar <ncalugar(a)pivotal.io>:

Hi Hristo,

I'm fine with a PR to add these two fields. Would it make sense to add
previous state as well?

Thanks,

Nick

On Thu, Mar 24, 2016 at 12:59 AM Dieu Cao <dcao(a)pivotal.io> wrote:

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


Spotting performance regressions

Michal Tekel
 

Hi,

I wanted to check if you know about a good way to spot performance regressions on CF and if anyone is doing it (at least partially) already. We are mainly interested in discovering user-facing degradation. That is, app operations (deploy, scale, delete, manage routes) and routing layer operations (latency per request, total throughput, SSL termination capacity) - esp. in connection with (heavier) routing services usage.

We did a brief investigation about the best way to automate this kind of regression testing, but didn't find any complete solution. We had a look at [CF PATs](1) tool and made a [container](2) it can be run from. But that only gives us metrics on app operations and no way of spotting regressions or automating the tests.

We were wondering if perhaps someone already does any kind of performance measurements as a part of their CF build/deploy pipelines/process and what their experience with tracking the results is...

[1] https://github.com/cloudfoundry-incubator/pat
[2] https://hub.docker.com/r/keymon/governmentpaas-cf-pats/


Re: Adding previous_instances and previous_memory fields to cf_event

Hristo Iliev
 

Hey,

Any news about this PR? We tried to minimize the change and make it easer
for review.

Regards,
Hristo Iliev

2016-03-29 14:50 GMT+03:00 Hristo Iliev <hsiliev(a)gmail.com>:

Hi again,

We created https://github.com/cloudfoundry/cloud_controller_ng/pull/569

Can you please take a look and comment on possible problems and missed
use-cases?

Regards,
Hristo Iliev

2016-03-24 18:06 GMT+02:00 Hristo Iliev <hsiliev(a)gmail.com>:

Hi Nick,

Adding previous state sounds good. Will add it in the PR as well.

Thanks,
Hristo Iliev

2016-03-24 17:29 GMT+02:00 Nicholas Calugar <ncalugar(a)pivotal.io>:

Hi Hristo,

I'm fine with a PR to add these two fields. Would it make sense to add
previous state as well?

Thanks,

Nick

On Thu, Mar 24, 2016 at 12:59 AM Dieu Cao <dcao(a)pivotal.io> wrote:

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: Failed to deploy diego 0.1452.0 on openstack: database_z2/0 is not running after update

Yunata, Ricky <rickyy@...>
 

Hi Adrian,

Thanks so much, I'll give it a try

Ricky Yunata

Please consider the environment before printing this email

-----Original Message-----
From: Adrian Zankich [mailto:azankich(a)pivotal.io]
Sent: Saturday, 2 April 2016 3:57 AM
To: cf-dev(a)lists.cloudfoundry.org
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Re: Re: Failed to deploy diego 0.1452.0 on openstack: database_z2/0 is not running after update

Hi Ricky,

We deconstructed the certs you provided in your manifest and think that you may have missed a step when you generated your peer ssl cert. Your peer cert is missing the DNS wildcard entry '*.etcd.service.cf.internal`, it will show up like this if you deconstruct your cert

X509v3 Subject Alternative Name:
DNS:*.etcd.service.cf.internal, DNS:etcd.service.cf.internal

If you regenerate your peer ssl cert with:

$ certstrap --depot-path peer request-cert --common-name "etcd.service.cf.internal" --domain "*.etcd.service.cf.internal,etcd.service.cf.internal"

It is detailed in https://github.com/cloudfoundry-incubator/diego-release#generating-tls-certificates step #8.

That should fix the ssl error you're experiencing.

- Adrian
Disclaimer

The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof.


Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.


If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe(a)fast.au.fujitsu.com


Re: cf create-buildpack fails in v233 with error 403 Forbidden

Wayne Ha <wayne.h.ha@...>
 

I also found this:

root(a)fe34f4b9-37f1-4c6e-ba86-17f667ef4fa9:/var/vcap/sys/log# cat ./blobstore/internal_error.log
2016/04/02 02:26:00 [error] 404#0: *1953 access forbidden by rule, client: <bosh directory ip>, server: blobstore.service.cf.internal, request: "PUT /admin/bosh-lite.com-cc-buildpacks/76/9f/769f3795-0076-4080-a8ee-b17bfc5f7a37_02401f2d6e33f084cfe932e130056d6f18cb53eb HTTP/1.1", host: "blobstore.service.cf.internal"

Some permission problem?


cf create-buildpack fails in v233 with error 403 Forbidden

Wayne Ha <wayne.h.ha@...>
 

Hi,

I just deployed CF 233 using bosh-lite-v233.yml. After deployment, I tried create-buildpack and it failed:

cf create-buildpack noop-buildpack ./buildpack_noop-buildpack_v01.zip 1
Creating buildpack noop-buildpack...
OK
Uploading buildpack noop-buildpack...
FAILED
Server error, status code: 500, error code: 10001, message: An unknown error occurred.

I found the following in cloud_controller_ng/cloud_controller_ng.log:

{"timestamp":1459559430.5717704
,"message":"Request failed: 500: {\"code\"=>10001
, \"description\"=>\"Could not create object
, 403/<html>\\r\\n<head><title>403 Forbidden</title></head>\\r\\n<body bgcolor=\\\"white\\\">\\r\\n<center><h1>403 Forbidden</h1></center>\\r\\n<hr><center>nginx</center>\\r\\n</body>\\r\\n</html>\\r\\n\"
, \"error_code\"=>\"CF-BlobstoreError\"
, \"backtrace\"=>[\"/var/vcap/data/packages/cloud_controller_ng/0f8b96021b770958c5e092c2c985a4aeb7977f80.1-fede99189ea8fff7b54ba05780db0c0e67b213d0/cloud_controller_ng/lib/cloud_controller/blobstore/webdav/dav_client.rb:82:in `block (2 levels) in cp_to_blobstore'\"
etc...
, \"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/2.2.0/gems/eventmachine-1.0.9.1/lib/eventmachine.rb:1067:in `block in spawn_threadpool'\"]}"
,"log_level":"error"
,"source":"cc.api"
,"data":{"request_guid":"029f33f9-30be-4c52-4993-8aad9b2c3889::8839c078-b9c5-4c68-a0f3-db4f45ff0340"}
,"thread_id":69990030933680
,"fiber_id":69990027455520
,"process_id":2661
,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/sinatra/vcap.rb"
,"lineno":53
,"method":"block in registered"}

Please let me know what I can do to fix this problem.

Thanks,


PSA: router.enable_routing_api removed

Mark St.Godard
 

We have recently added a property 'routing_api.enabled' which indicates if
the routing-api is also deployed.

Gorouter has a property 'router.enable_routing_api' which would determine
if gorouter should also fetch routes from the routing-api.

CC is using the new generic 'routing_api.enabled'. So to avoid duplication
we removed 'router.enable_routing_api' and now gorouter references the
newer 'routing_api.enabled' property.

Therefore if anyone was explicitly overriding 'router.enable_routing_api' ,
you will no longer have to do this once you get the change.

For more info:
https://www.pivotaltracker.com/story/show/115965445

https://github.com/cloudfoundry/cf-release/commit/dcc9bd69ca7f9a0e2615035999764ff1d976f7ff

Cheers

Mark (and Leo)


Re: App running even after delete. Pointers on finding it and debugging?

Tom Sherrod <tom.sherrod@...>
 

JT,

Thanks for responding.

This is a test runtime and small. I checked all orgs and spaces. No routes
matching the app.

Found the route information and the result:

{

"total_results": 0,

"total_pages": 1,

"prev_url": null,

"next_url": null,

"resources": []

}

To learn what the output may look like, I check existing routes with apps
and without. The output appears to be the same as if the app has been
deleted.

Even now, the app url still returns a page from the app, even though it is
deleted.

Thanks,

Tom

On Fri, Apr 1, 2016 at 1:52 PM, JT Archie <jarchie(a)pivotal.io> wrote:

Tom,

Are you sure the route isn't bound to another application in another
org/space?

When you do `cf routes` it only show routes for the current space. You can
hit specific API endpoints though to get all the apps for a route.

For example, `cf
curl /v2/routes/89fc2a5e-3a9b-4a88-a360-e405cdbd6f87/apps` will show all
the apps for a particular route. Obviously replacing the route ID with the
correct ID. To find that, I recommend going through `CF_TRACE=true cf
routes` and grabbing the ID.

Let see if you can hunt it down that way.

Kind Regards,

JT

On Fri, Apr 1, 2016 at 8:51 AM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:

cf 230, diego 0.1450.0, etcd 27, garden-linux 0.330.0
Default to diego true.

Developer deployed a java application. Deleted the application: cf delete
<app> No errors.
The app still responds. The only thing left is the route.
I've not encountered this before. Delete has been delete and even if
route remains, 404 Not Found: Requested route ('<hostname.domain>') does
not exist. is returned.

Pointers on tracking this down appreciated.

Tom


Re: App running even after delete. Pointers on finding it and debugging?

JT Archie <jarchie@...>
 

Tom,

Are you sure the route isn't bound to another application in another
org/space?

When you do `cf routes` it only show routes for the current space. You can
hit specific API endpoints though to get all the apps for a route.

For example, `cf curl /v2/routes/89fc2a5e-3a9b-4a88-a360-e405cdbd6f87/apps`
will show all the apps for a particular route. Obviously replacing the
route ID with the correct ID. To find that, I recommend going through
`CF_TRACE=true cf routes` and grabbing the ID.

Let see if you can hunt it down that way.

Kind Regards,

JT

On Fri, Apr 1, 2016 at 8:51 AM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:

cf 230, diego 0.1450.0, etcd 27, garden-linux 0.330.0
Default to diego true.

Developer deployed a java application. Deleted the application: cf delete
<app> No errors.
The app still responds. The only thing left is the route.
I've not encountered this before. Delete has been delete and even if route
remains, 404 Not Found: Requested route ('<hostname.domain>') does not
exist. is returned.

Pointers on tracking this down appreciated.

Tom


Re: Failed to deploy diego 0.1452.0 on openstack: database_z2/0 is not running after update

Adrian Zankich
 

Hi Ricky,

We deconstructed the certs you provided in your manifest and think that you may have missed a step when you generated your peer ssl cert. Your peer cert is missing the DNS wildcard entry '*.etcd.service.cf.internal`, it will show up like this if you deconstruct your cert

X509v3 Subject Alternative Name:
DNS:*.etcd.service.cf.internal, DNS:etcd.service.cf.internal

If you regenerate your peer ssl cert with:

$ certstrap --depot-path peer request-cert --common-name "etcd.service.cf.internal" --domain "*.etcd.service.cf.internal,etcd.service.cf.internal"

It is detailed in https://github.com/cloudfoundry-incubator/diego-release#generating-tls-certificates step #8.

That should fix the ssl error you're experiencing.

- Adrian

4981 - 5000 of 9425