Date   

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


Re: Using swift as a blobstore in cloud foundry with keystone v3

Marco Voelz
 

Hi Dies, Nick,

I can confirm that a swift blobstore works with domains different than 'default'. Here is our configuration on an OpenStack Liberty

fog_connection: &fog_connection
provider: OpenStack
openstack_auth_url: https://<keystone-url>:5000/v3/auth/tokens<https://cluster-4.eu-de-1.cloud.sap:5000/v3/auth/tokens>
openstack_username: <username>
openstack_api_key: <password>
openstack_project_name: <openstack project>
openstack_domain_name: MY_CUSTOM_DOMAIN
# register tem url key with swift:
# swift post -m "Temp-URL-Key:tempurlkey"
openstack_temp_url_key: tempurlkey

Warm regards
Marco

On 01/04/16 14:55, "Koper, Dies" <diesk(a)fast.au.fujitsu.com<mailto:diesk(a)fast.au.fujitsu.com>> wrote:

Hi Nick,

Can you try with a domain other than “default”?
We initially found that with the BOSH CPI, Keystone V3 worked for the “default” domain, but not for any other domain.
Note that the point of using Keystone V3 is to have different domains.

Also, we can connect to swift using the temp urls with the openstack cli fine.

Cheers,
Dies Koper


From: Nicholas Calugar [mailto:ncalugar(a)pivotal.io]
Sent: Thursday, March 31, 2016 11:18 AM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Re: Re: Re: Using swift as a blobstore in cloud foundry with keystone v3

Before confirming the new version of fog fixed this, I tried to reproduce the error using CF v233. Instead of reproducing the error, it actually worked.

V2 CONFIG:
provider: 'OpenStack'
openstack_tenant: 'admin'
openstack_username: 'admin'
openstack_api_key: '*************'
openstack_auth_url: 'https://my-openstack:5000/v2.0/tokens'
openstack_temp_url_key: 'b3968d0207b54ece87cccc06515a89d4'
connection_options:
ssl_verify_peer: false

V3 CONFIG:
provider: 'OpenStack'
openstack_tenant: 'admin'
openstack_project_name: 'admin'
openstack_domain_name: 'default'
openstack_username: 'admin'
openstack_api_key: '**************'
openstack_auth_url: 'https://my-openstack:5000/v3/auth/tokens'
openstack_temp_url_key: 'b3968d0207b54ece87cccc06515a89d4'
connection_options:
ssl_verify_peer: false

I would recommend using the openstack / swift cli to ensure you can correctly generate temp urls. The DEAs / CELLs use the tempurl feature to download objects from the blobstore and I think that is the error you are running into. Once you can get it to work via CLI, translate the correct variables into the fog_configuration for Cloud Foundry.


Thanks,

Nick

On Mon, Mar 21, 2016 at 10:21 AM Nicholas Calugar <ncalugar(a)pivotal.io<mailto:ncalugar(a)pivotal.io>> wrote:
We have a story in flight: https://www.pivotaltracker.com/story/show/115793253

If upgrading fog doesn't work, we'll happily take a PR that resolves this.

On Thu, Mar 17, 2016 at 5:33 PM Gwenn Etourneau <getourneau(a)pivotal.io<mailto:getourneau(a)pivotal.io>> wrote:
This can be nice ! As Bosh support V3 it can be nice that the CC do the same.
To be able to fully use v3.



On Thu, Mar 17, 2016 at 6:30 PM, Voelz, Marco <marco.voelz(a)sap.com<mailto:marco.voelz(a)sap.com>> wrote:
Dear Nicholas,

if desired, we can also do a PR for allowing the CC to connect to Swift using Keystone v3. A couple of months ago we did the same thing in the OpenStack CPI. We also have some test envs available where we can validate the change. What do you think?

Warm regards
Marco

On 16/03/16 18:13, "Nicholas Calugar" <ncalugar(a)pivotal.io<mailto:ncalugar(a)pivotal.io>> wrote:

Hi Muhammad,

Unfortunately, we don't have an environment using keystone v3. We are passing the configuration to fog as-is. There are several fixes that have been made in later releases of fog, for example:

https://github.com/fog/fog/pull/3806

I'll get a story prioritized to upgrade fog to v1.37.0

Thanks,

Nick

On Sun, Mar 13, 2016 at 11:58 PM Altaf, Muhammad <Muhammada(a)fast.au.fujitsu.com<mailto:Muhammada(a)fast.au.fujitsu.com>> wrote:
Hi All,
I am trying to configure cloud foundry to use swift on OpenStack. I have followed the instructions at https://docs.cloudfoundry.org/deploying/openstack/using_swift_blobstore.html
When used keystone v2, I am able to start my apps on DEA which is good. However when using keystone V3, I am not able to start my apps. The error I am getting is:

“FAILED
Server error, status code: 400, error code: 170001, message: Staging error: failed to stage application:
Error downloading: HTTP status: 401”

Tried to debug by adding some ‘puts’ statements in openstack/core.rb file and it looks like tokens are being generated successfully so there is no problem with the authentication. The generated response to auth request shows that the user has “ResellerAdmin” role as well.

When I look into runner_z1/0 /var/vcap/data/dea_next/tmp/ app-package-download.tgz2016*, I find error saying: “401 Unauthorized: Temp URL invalid xxxxx”

/var/vcap/sys/log/dea_next/dea_next.log shows some download URLs, and if I curl those URLs, I get exact same error message. Below are the fog_connection settings in cloud foundry manifest:

fog_connection: &fog_connection
provider: 'OpenStack'
openstack_username: 'cf-admin2'
openstack_tenant: 'cf2'
openstack_project_name: 'cf2'
openstack_api_key: 'passw0rd'
openstack_auth_url: 'http://<OPENSTACK_IP>:5000/v3/auth/tokens'
openstack_domain_name: 'cf_domain'
openstack_user_domain_name: 'cf_domain'
openstack_temp_url_key: 'b3968d0207b54ece87cccc06515a89d4'


Account has a valid temp_url_key configured. Please see below:
curl -v -X GET http://SWIFT_IP:SWIFT_PORT/v2/Auth_b34a51e551ec4796a461168c886c734f -H "X-Auth-Token: TOKEN"
* Hostname was NOT found in DNS cache
* Trying SWIFT_IP...
* Connected to SWIFT_IP (SWIFT_IP) port SWIFT_PORT (#0)
GET /v2/Auth_b34a51e551ec4796a461168c886c734f HTTP/1.1
User-Agent: curl/7.35.0
Host: SWIFT_IP:SWIFT_PORT
Accept: */*
X-Auth-Token: TOKEN
< HTTP/1.1 204 No Content
< Content-Length: 0
< X-Account-Object-Count: 0
< X-Timestamp: 1457918518.21777
< X-Account-Meta-Temp-Url-Key: b3968d0207b54ece87cccc06515a89d4
< X-Account-Bytes-Used: 0
< X-Account-Container-Count: 0
< Content-Type: text/plain; charset=utf-8
< Accept-Ranges: bytes
< X-Trans-Id: txfc362c27bdda4355a942a-0056e65d93
< Date: Mon, 14 Mar 2016 06:43:31 GMT
<
* Connection #0 to host SWIFT_IP left intact

Also, I can see that the containers are created on swift, so obviously it is able to authenticate.
$ openstack container list
+---------------+
| Name |
+---------------+
| cc-buildpacks |
| cc-droplets |
| cc-packages |
| cc-resources |
+---------------+

I would appreciate if someone can help me fixing this issue.

Regards,
Muhammad Altaf
Software Development Engineer

Fujitsu Australia Software Technology Pty Ltd
14 Rodborough Road, Frenchs Forest NSW 2086, Australia
T +61 2 9452 9067<tel:%2B61%202%209452%209067>F +61 2 9975 2899<tel:%2B61%202%209975%202899>
Muhammada(a)fast.au.fujitsu.com<mailto:Muhammada(a)fast.au.fujitsu.com>
fastware.com.au<http://fastware.com.au>

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<tel:%2B%2061%202%209452%209000> 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<mailto:unsubscribe(a)fast.au.fujitsu.com>



--
Nicholas Calugar
CAPI Product Manager
Pivotal Software, Inc.


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

Tom Sherrod <tom.sherrod@...>
 

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: cf v231: Issue with new webdav blobstore job

Rich Wohlstadter
 

Excellent. Thanks for your investigation on this.

-Rich

4981 - 5000 of 9422