Date   

UAA - Non-Browser Requests Code: GET /oauth/authorize, and sample login application

Yogesh Sajanikar
 

I have setup uaa service, and trying to setup a non-browser client (another server actually) to get the authorization. In fact, I am trying to adapt sample "login" application to my needs.

However, the step mentioned in documentation to login fails with "403". Here is the curl command that I am trying.

curl -v -H "Accept:application/json" http://localhost:8080/uaa/login.do -d "username=marissa&password=koala" --cookie cookies.txt --cookie-jar cookies.txt

And here is the response that I get.

* Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
POST /uaa/login.do HTTP/1.1
Host: localhost:8080
User-Agent: curl/7.43.0
Cookie: JSESSIONID=0003A0F5BC783B536970393F2F0B0AE4; X-Uaa-Csrf=RsrCTu
Accept:application/json
Content-Length: 31
Content-Type: application/x-www-form-urlencoded
* upload completely sent off: 31 out of 31 bytes
< HTTP/1.1 403 Forbidden
< Server: Apache-Coyote/1.1
< Strict-Transport-Security: max-age=31536000
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< Cache-Control: no-store
< Content-Type: application/json;charset=UTF-8
< Content-Language: en-US
< Transfer-Encoding: chunked
< Date: Thu, 04 Feb 2016 04:30:43 GMT
<
* Connection #0 to host localhost left intact
{"app":{"version":"3.0.1"},"links":{"uaa":"http://localhost:8080/uaa","passwd":"/forgot_password","login":"http://localhost:8080/uaa","register":"/create_account"},"zone_name":"uaa","entityID":"cloudfoundry-saml-login","commit_id":"4f37e9b","idpDefinitions":{},"prompts":{"username":["text","Email"],"password":["password","Password"]},"timestamp":"2016-01-26T01:13:19+0530"}

The sample application "login" does not work in a similar way!


Re: Upgrading consul-release to consul 0.6.0

Amit Kumar Gupta
 

Hi Gwenn

Thanks for your feedback, and taking the time to look through the changelog!

cf-release/consul-release have been on 0.5.2 (post BoltDB migration) since
Jun 2015:
https://github.com/cloudfoundry/cf-release/commit/1683884704c91ec1609efe3c8390c058ccc6c537.
So there should be no concerns around any migrations from LMDB.

Best,
Amit

On Wed, Feb 3, 2016 at 6:04 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

My biggest concern is the Data migration from LMDB to BoltDB, I know there
is a CLI to do that but I am concern about the migration of the DATA itself.


*" Previously, Consul would automatically detect data directories using
the old LMDB format, and convert them to the newer BoltDB format. This
automatic upgrade has been removed for Consul 0.6, and instead a safeguard
has been put in place which will prevent Consul from booting if the old
directory format is detected. "*
*AND*
* Consul should be provisioned with physical memory approximately 2X the
data set size to allow for bursty allocations and subsequent garbage
collection.*



On Thu, Feb 4, 2016 at 3:28 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hi cf-dev, cf-diego

The CF Infrastructure team which maintains consul-release (
https://github.com/cloudfoundry-incubator/consul-release) is considering
bumping from consul 0.5.2 to 0.6.0. There are many changes between those
consecutive releases, which you can read about here:

* 0.6.0:
https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#060-december-3-2015
* 0.6.1:
https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#061-january-6-2016
* 0.6.2:
https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#062-january-13-2016

We would like to explore this bump to get the change in 0.6.0 where
consul moved to a pure Go implementation, allowing us to avoid having to
set GOMAXPROCS when starting the consul server, and then some of the
security fixes in 0.6.2 for good measure.

This change would also affect clients of the consul server in
consul-release, hopefully in mainly positive ways. If you're a consumer of
consul-release as a client, I would appreciate your feedback on this
potential bump to consul in consul-release.

Thanks,
Amit, CF Infrastructure team PM


Re: Routes limitation per app

Siva Balan <mailsiva@...>
 

Thanks Filip and Shawn. I think Filip's suggestion would solve our problem.

On Wed, Feb 3, 2016 at 2:02 PM, Shawn Nielsen <sknielse(a)gmail.com> wrote:

The only known route limitation I am aware of on a CF org is the route
quota associated with the org. If you type 'cf org [ORG_NAME]' you
should see how many routes are allowed. You can also view quotas directly
using 'cf quotas'. We're running thousands of routes and haven't seen an
issue as long as the route quota is set high enough.

On Wed, Feb 3, 2016 at 11:40 AM, Filip Hanik <fhanik(a)pivotal.io> wrote:

hi Siva,
can't you just register *.uaa.test.com as a route?


https://github.com/cloudfoundry/cf-release/blob/master/templates/cf-jobs.yml#L173-L182



On Wed, Feb 3, 2016 at 10:05 AM, Siva Balan <mailsiva(a)gmail.com> wrote:

Hello,
We have an implementation of UAA using Identity zones where each zone in
UAA is represented by a unique route and this route is bound to that UAA
app in our cloudfoundry implementation. Eg:
If UAA is deployed at uaa.test.com, then the routes for the zones are
represented as:
zone1.uaa.test.com
zone2.uaa.test.com
zone3.uaa.test.com
We have a requirement to test for 10,000 identity zones which translates
to 10,000 routes bound to a single UAA app.
We would like to know if there are any known limitations to the number
of routes that can be created per org or number of routes that can be bound
to a single app.

Thanks
Siva Balan

--
http://www.twitter.com/sivabalans


Re: Upgrading consul-release to consul 0.6.0

Gwenn Etourneau
 

My biggest concern is the Data migration from LMDB to BoltDB, I know there
is a CLI to do that but I am concern about the migration of the DATA itself.


*" Previously, Consul would automatically detect data directories using the
old LMDB format, and convert them to the newer BoltDB format. This
automatic upgrade has been removed for Consul 0.6, and instead a safeguard
has been put in place which will prevent Consul from booting if the old
directory format is detected. "*
*AND*
* Consul should be provisioned with physical memory approximately 2X the
data set size to allow for bursty allocations and subsequent garbage
collection.*

On Thu, Feb 4, 2016 at 3:28 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hi cf-dev, cf-diego

The CF Infrastructure team which maintains consul-release (
https://github.com/cloudfoundry-incubator/consul-release) is considering
bumping from consul 0.5.2 to 0.6.0. There are many changes between those
consecutive releases, which you can read about here:

* 0.6.0:
https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#060-december-3-2015
* 0.6.1:
https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#061-january-6-2016
* 0.6.2:
https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#062-january-13-2016

We would like to explore this bump to get the change in 0.6.0 where consul
moved to a pure Go implementation, allowing us to avoid having to set
GOMAXPROCS when starting the consul server, and then some of the security
fixes in 0.6.2 for good measure.

This change would also affect clients of the consul server in
consul-release, hopefully in mainly positive ways. If you're a consumer of
consul-release as a client, I would appreciate your feedback on this
potential bump to consul in consul-release.

Thanks,
Amit, CF Infrastructure team PM


Re: Support for HTTP/2

Shannon Coen
 

Thank you for the additional context, Carlo. I agree the loss of support
for non-TLS requests would not only restrictive, but potentially backwards
incompatible.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Tue, Feb 2, 2016 at 9:05 PM, Carlo Alberto Ferraris <
carlo.ferraris(a)rakuten.com> wrote:

With this limitation in mind, an upstream component could still terminate
TLS, but couldn't Gorouter also?
Just as a small followup, consider that companies might have internal
regulations mandating how and where SSL termination needs to happen
(Rakuten is among them, for example...). As described in my previous mail,
there are workarounds (e.g. using a separate TLS session between LB/RP and
gorouter) but this may add further deployment complexity (and overhead).


Re: Routes limitation per app

Shawn Nielsen
 

The only known route limitation I am aware of on a CF org is the route
quota associated with the org. If you type 'cf org [ORG_NAME]' you
should see how many routes are allowed. You can also view quotas directly
using 'cf quotas'. We're running thousands of routes and haven't seen an
issue as long as the route quota is set high enough.

On Wed, Feb 3, 2016 at 11:40 AM, Filip Hanik <fhanik(a)pivotal.io> wrote:

hi Siva,
can't you just register *.uaa.test.com as a route?


https://github.com/cloudfoundry/cf-release/blob/master/templates/cf-jobs.yml#L173-L182



On Wed, Feb 3, 2016 at 10:05 AM, Siva Balan <mailsiva(a)gmail.com> wrote:

Hello,
We have an implementation of UAA using Identity zones where each zone in
UAA is represented by a unique route and this route is bound to that UAA
app in our cloudfoundry implementation. Eg:
If UAA is deployed at uaa.test.com, then the routes for the zones are
represented as:
zone1.uaa.test.com
zone2.uaa.test.com
zone3.uaa.test.com
We have a requirement to test for 10,000 identity zones which translates
to 10,000 routes bound to a single UAA app.
We would like to know if there are any known limitations to the number of
routes that can be created per org or number of routes that can be bound to
a single app.

Thanks
Siva Balan

--
http://www.twitter.com/sivabalans


Re: bits-service fog usage question

Tim Lawrence <tim.lawrence1984@...>
 

We would potentially be affected as we use Fog's Atmos provider for now. In the future we plan to implement fully s3 compatible
Object storage so no problem then but may require some backwards compatibility for a while..

Tim

Sent from my iPhone

On 3 Feb 2016, at 14:21, Tammer Saleh <tsaleh(a)pivotal.io> wrote:

I can't comment on the common use cases, and who this change would break. However, I'm very much in favor of hiding this implementation detail from our API. Letting a library's internal API leak into our product surface area is a very bad thing for us long term.

Cheers,
Tammer Saleh
Senior Director of Engineering, Pivotal CF, London
http://pivotal.io | http://tammersaleh.com | +44 7463 939332

On Wed, Feb 3, 2016 at 1:07 PM, Simon D Moser <SMOSER(a)de.ibm.com> wrote:
ps: forgot to mention that openStack Swift is of course in scope, too.

Mit freundlichen Grüßen / Kind regards

Simon Moser

Senior Technical Staff Member / IBM Master Inventor
Bluemix Application Platform Lead Architect
Dept. C727, IBM Research & Development Boeblingen

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds discuss people.
Eleanor Roosevelt



From: Simon D Moser/Germany/IBM(a)IBMDE
To: "CF Developers Mailing List" <cf-dev(a)lists.cloudfoundry.org>
Date: 03/02/2016 11:51
Subject: [cf-dev] bits-service fog usage question



Hi everybody,

we are beginning work on the Bits Service proposed here [1] for handling all kinds of blobstore related operations - a functionality that is in the cloud controller today. Cloud controller currently uses the ruby gem 'fog' [2] for interactions with the back-end blobstore.
We are thinking about removing the dependency on the ruby fog gem and would like to better understand what blobstores and configurations you, in the community, are using today. Unfortunately, the fact that this gem is used leaks out to the cc configuration [3] by taking an opaque fog hash, and therefore it could potentially be used in many ways.

We would like to get feedback on whether it would be fine if the new bits service only supported s3 compatible blobstores, externally provided nfs, and webdav (and no longer everything that fog potentially supports).
Would you be impacted by such a decision, and how?
What connection parameters/features of fog do you currently make use of?


[1] https://docs.google.com/document/d/1kIjBuJJ0ZiJRPzMJW8dtce26jhAHbK7KotY9416YMEI/edit?usp=sharing
[2] https://github.com/fog/fog
[3] https://github.com/cloudfoundry/cf-release/blob/master/jobs/cloud_controller_ng/spec#L250-L251


Mit freundlichen Grüßen / Kind regards

Simon Moser

Senior Technical Staff Member / IBM Master Inventor
Bluemix Application Platform Lead Architect
Dept. C727, IBM Research & Development Boeblingen

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds discuss people.
Eleanor Roosevelt


Re: Routes limitation per app

Filip Hanik
 

hi Siva,
can't you just register *.uaa.test.com as a route?

https://github.com/cloudfoundry/cf-release/blob/master/templates/cf-jobs.yml#L173-L182

On Wed, Feb 3, 2016 at 10:05 AM, Siva Balan <mailsiva(a)gmail.com> wrote:

Hello,
We have an implementation of UAA using Identity zones where each zone in
UAA is represented by a unique route and this route is bound to that UAA
app in our cloudfoundry implementation. Eg:
If UAA is deployed at uaa.test.com, then the routes for the zones are
represented as:
zone1.uaa.test.com
zone2.uaa.test.com
zone3.uaa.test.com
We have a requirement to test for 10,000 identity zones which translates
to 10,000 routes bound to a single UAA app.
We would like to know if there are any known limitations to the number of
routes that can be created per org or number of routes that can be bound to
a single app.

Thanks
Siva Balan

--
http://www.twitter.com/sivabalans


Requirements introduced in cf-release v229 for external PostgreSQL as CCDB

Shannon Coen
 

In support of work in progress to enable developers to specify application
ports when mapping routes, cf-release v229 introduces a database migration
for CCDB. *For deployments that use a PostgreSQL database for CCDB that is
NOT the PostreSQL job that comes with cf-release*, v229 introduces the
following requirements. These requirements are applicable for subsequent
releases. If you are using the PostgreSQL job that comes with cf-release,
or if you are using MySQL as the backing db for CC, no action is necessary.

- PostgreSQL 9.1 is required at a minimum
- For versions 9.1-9.3, operators must first install the extension
uuid-ossp [1]
- For versions 9.4 and newer, operators must first install the extension
pgcrypto [2]

Release Notes have been updated. [3]

[1] http://www.postgresql.org/docs/9.1/static/uuid-ossp.html
[2] http://www.postgresql.org/docs/9.4/static/pgcrypto.html
[3] https://github.com/cloudfoundry/cf-release/releases/tag/v229


Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Upgrading consul-release to consul 0.6.0

Amit Kumar Gupta
 

Hi cf-dev, cf-diego

The CF Infrastructure team which maintains consul-release (
https://github.com/cloudfoundry-incubator/consul-release) is considering
bumping from consul 0.5.2 to 0.6.0. There are many changes between those
consecutive releases, which you can read about here:

* 0.6.0:
https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#060-december-3-2015
* 0.6.1:
https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#061-january-6-2016
* 0.6.2:
https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#062-january-13-2016

We would like to explore this bump to get the change in 0.6.0 where consul
moved to a pure Go implementation, allowing us to avoid having to set
GOMAXPROCS when starting the consul server, and then some of the security
fixes in 0.6.2 for good measure.

This change would also affect clients of the consul server in
consul-release, hopefully in mainly positive ways. If you're a consumer of
consul-release as a client, I would appreciate your feedback on this
potential bump to consul in consul-release.

Thanks,
Amit, CF Infrastructure team PM


Re: Issue with crashing Windows apps on Diego

Aaron Huber
 

Yes, I agree that setting the specific URI to check would be necessary as
well so that developers could avoid some of the other concerns. So the ones
I can think of:

* URI / endpoint
* Expected status codes - this would probably need to be a range or an
array, or even an array of ranges :-)
* Timeout

Aaron




--
View this message in context: http://cf-dev.70369.x6.nabble.com/Issue-with-crashing-Windows-apps-on-Diego-tp3586p3662.html
Sent from the CF Dev mailing list archive at Nabble.com.


Routes limitation per app

Siva Balan <mailsiva@...>
 

Hello,
We have an implementation of UAA using Identity zones where each zone in
UAA is represented by a unique route and this route is bound to that UAA
app in our cloudfoundry implementation. Eg:
If UAA is deployed at uaa.test.com, then the routes for the zones are
represented as:
zone1.uaa.test.com
zone2.uaa.test.com
zone3.uaa.test.com
We have a requirement to test for 10,000 identity zones which translates to
10,000 routes bound to a single UAA app.
We would like to know if there are any known limitations to the number of
routes that can be created per org or number of routes that can be bound to
a single app.

Thanks
Siva Balan

--
http://www.twitter.com/sivabalans


Re: bits-service fog usage question

Tammer Saleh
 

I can't comment on the common use cases, and who this change would break.
However, I'm very much in favor of hiding this implementation detail from
our API. Letting a library's internal API leak into our product surface
area is a very bad thing for us long term
<http://tammersaleh.com/posts/mind-the-map/>.

Cheers,
Tammer Saleh
Senior Director of Engineering, Pivotal CF, London
http://pivotal.io | http://tammersaleh.com | +44 7463 939332

On Wed, Feb 3, 2016 at 1:07 PM, Simon D Moser <SMOSER(a)de.ibm.com> wrote:

ps: forgot to mention that openStack Swift is of course in scope, too.

Mit freundlichen Grüßen / Kind regards

Simon Moser

Senior Technical Staff Member / IBM Master Inventor
Bluemix Application Platform Lead Architect
Dept. C727, IBM Research & Development Boeblingen


-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Simon D Moser/Germany/IBM(a)IBMDE
To: "CF Developers Mailing List" <cf-dev(a)lists.cloudfoundry.org>
Date: 03/02/2016 11:51
Subject: [cf-dev] bits-service fog usage question
------------------------------



Hi everybody,

we are beginning work on the Bits Service proposed here [1] for handling
all kinds of blobstore related operations - a functionality that is in the
cloud controller today. Cloud controller currently uses the ruby gem 'fog'
[2] for interactions with the back-end blobstore.
We are thinking about removing the dependency on the ruby fog gem and
would like to better understand what blobstores and configurations you, in
the community, are using today. Unfortunately, the fact that this gem is
used leaks out to the cc configuration [3] by taking an opaque fog hash,
and therefore it could potentially be used in many ways.

We would like to get feedback on whether it would be fine if the new bits
service only supported s3 compatible blobstores, externally provided nfs,
and webdav (and no longer everything that fog potentially supports).
Would you be impacted by such a decision, and how?
What connection parameters/features of fog do you currently make use of?


[1]
*https://docs.google.com/document/d/1kIjBuJJ0ZiJRPzMJW8dtce26jhAHbK7KotY9416YMEI/edit?usp=sharing*
<https://docs.google.com/document/d/1kIjBuJJ0ZiJRPzMJW8dtce26jhAHbK7KotY9416YMEI/edit?usp=sharing>
[2] *https://github.com/fog/fog* <https://github.com/fog/fog>
[3]
*https://github.com/cloudfoundry/cf-release/blob/master/jobs/cloud_controller_ng/spec#L250-L251*
<https://github.com/cloudfoundry/cf-release/blob/master/jobs/cloud_controller_ng/spec#L250-L251>


Mit freundlichen Grüßen / Kind regards

Simon Moser

Senior Technical Staff Member / IBM Master Inventor
Bluemix Application Platform Lead Architect
Dept. C727, IBM Research & Development Boeblingen


-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



Re: bits-service fog usage question

Simon D Moser
 

ps: forgot to mention that openStack Swift is of course in scope, too.

Mit freundlichen Grüßen / Kind regards

Simon Moser

Senior Technical Staff Member / IBM Master Inventor
Bluemix Application Platform Lead Architect
Dept. C727, IBM Research & Development Boeblingen

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt



From: Simon D Moser/Germany/IBM(a)IBMDE
To: "CF Developers Mailing List" <cf-dev(a)lists.cloudfoundry.org>
Date: 03/02/2016 11:51
Subject: [cf-dev] bits-service fog usage question



Hi everybody,

we are beginning work on the Bits Service proposed here [1] for handling
all kinds of blobstore related operations - a functionality that is in the
cloud controller today. Cloud controller currently uses the ruby gem 'fog'
[2] for interactions with the back-end blobstore.
We are thinking about removing the dependency on the ruby fog gem and
would like to better understand what blobstores and configurations you, in
the community, are using today. Unfortunately, the fact that this gem is
used leaks out to the cc configuration [3] by taking an opaque fog hash,
and therefore it could potentially be used in many ways.

We would like to get feedback on whether it would be fine if the new bits
service only supported s3 compatible blobstores, externally provided nfs,
and webdav (and no longer everything that fog potentially supports).
Would you be impacted by such a decision, and how?
What connection parameters/features of fog do you currently make use of?


[1]
https://docs.google.com/document/d/1kIjBuJJ0ZiJRPzMJW8dtce26jhAHbK7KotY9416YMEI/edit?usp=sharing

[2] https://github.com/fog/fog
[3]
https://github.com/cloudfoundry/cf-release/blob/master/jobs/cloud_controller_ng/spec#L250-L251



Mit freundlichen Grüßen / Kind regards

Simon Moser

Senior Technical Staff Member / IBM Master Inventor
Bluemix Application Platform Lead Architect
Dept. C727, IBM Research & Development Boeblingen

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt


bits-service fog usage question

Simon D Moser
 

Hi everybody,

we are beginning work on the Bits Service proposed here [1] for handling
all kinds of blobstore related operations - a functionality that is in the
cloud controller today. Cloud controller currently uses the ruby gem 'fog'
[2] for interactions with the back-end blobstore.
We are thinking about removing the dependency on the ruby fog gem and
would like to better understand what blobstores and configurations you, in
the community, are using today. Unfortunately, the fact that this gem is
used leaks out to the cc configuration [3] by taking an opaque fog hash,
and therefore it could potentially be used in many ways.

We would like to get feedback on whether it would be fine if the new bits
service only supported s3 compatible blobstores, externally provided nfs,
and webdav (and no longer everything that fog potentially supports).
Would you be impacted by such a decision, and how?
What connection parameters/features of fog do you currently make use of?


[1]
https://docs.google.com/document/d/1kIjBuJJ0ZiJRPzMJW8dtce26jhAHbK7KotY9416YMEI/edit?usp=sharing
[2] https://github.com/fog/fog
[3]
https://github.com/cloudfoundry/cf-release/blob/master/jobs/cloud_controller_ng/spec#L250-L251


Mit freundlichen Grüßen / Kind regards

Simon Moser

Senior Technical Staff Member / IBM Master Inventor
Bluemix Application Platform Lead Architect
Dept. C727, IBM Research & Development Boeblingen

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser(a)de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294

**
Great minds discuss ideas; average minds discuss events; small minds
discuss people.
Eleanor Roosevelt


Re: Issue with crashing Windows apps on Diego

Eric Malm <emalm@...>
 

Hi, Aaron and Matt,

Thanks for the thoughtful discussion of the Windows health-check issue. I
too think for consistency that if the CF end user has specified 'port' as
the type of health-check on their app, then the platform should be checking
only TCP connectivity to the app on that port, and not any layer-7
functionality beyond that.

Some background on the HTTP vs TCP behavior in the health-check:
originally, the health-check binary used for the buildpack and docker app
lifecycles made only TCP connections to the requested port. When Lattice
made it possible to submit DesiredLRPs directly to the Diego API, we got
feedback from its users that they wanted an option to specify an HTTP-based
health-check as well. Consequently, we extended that health-check binary to
take an optional endpoint flag, and in its presence the binary would make a
GET request to the specified endpoint and check for a response with a 200
OK status code within the specified timeout (default 1s). For buildpack and
docker CF apps, though, none of that HTTP functionality has been exposed
through CC, and only the basic TCP connectivity check is available.

Matt, the native NetCheckAction from the Diego Dev Notes proposal you
mention is effectively just encoding the current behavior of that
TCP-or-HTTP health-check binary as an action that the rep could perform
itself, rather that by invoking that binary in-container. The Diego team
had conceived of it primarily as a performance optimization, particularly
when starting a lot of instances on a cell simultaneously, but
investigation revealed it to be of secondary benefit at best. The Diego
team might implement it at some point, but for now we'd prefer not to
expand the surface area of the Diego BBS API to include it. I've been
meaning to update and close out that Dev Notes issue, and will do so
shortly.

In any case, the options on that proposed NetCheckAction are just the ones
already available on the health-check binary, and, native action or not,
additional work would still be required to expose them through CC to the CF
end-user. Moreover, I don't think they're sufficient to address all the
concerns that Aaron raises in his observations about the Windows app
lifecycle's current HTTP-based check. Aaron, you mentioned timeout and
expected status code as important parameters to specify on an HTTP
health-check; are there others? I would think endpoint could be just as
useful: perhaps your app has a /health or /ping endpoint specifically
designed to return a fast response about the app itself, separate from
backing services and/or authentication checks, or perhaps it simply doesn't
handle requests to /.

Thanks,
Eric

On Tue, Feb 2, 2016 at 1:50 PM, aaron_huber <aaron.m.huber(a)intel.com> wrote:

My concern is that the HTTP check (mislabeled as "port") would still be the
default and I'd have to expect users to opt out of it per app. It's
confusing and not what users of the platform have come to expect moving
from
DEA/IF.

In general, the HTTP checks as a platform owner still make me nervous.
They
are nice in theory as long as they are opt-in for the developer, but what
happens when something goes wrong? For example, say I have an app
dependent
on a back-end resource (database, web service, etc.) that is down and as a
result my app is returning a friendly error page with a 500 response. With
an HTTP healthcheck my app is now effectively down with an ugly 404 message
from the router as all containers will fail and not correctly respawn
because they will not return a 200 to ever get healthy. Is that a better
user experience than the friendly error page? How long will Diego continue
trying to start the unhealthy containers before it gives up and then
requires developer interaction to start the app again?

To close on this, I think the new story is essential for consistency of the
overall platform and to avoid the issues above, and I would argue strongly
that it should be completed ASAP. Once the improved story is in place then
my customers could opt into an HTTP check with adequate knowledge of the
potential impacts.

Aaron



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/Issue-with-crashing-Windows-apps-on-Diego-tp3586p3647.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Wildcard routes, subdomains and failing smoke-test

Dieu Cao <dcao@...>
 

You might consider making a tiny custom 404 app and then map *.cf.bar.io
and *.foo.bar.io and any other sub domains to it so that it doesn't fall
through to your landing page app.
Would that work for you?

-Dieu
CF CAPI PM

On Wed, Feb 3, 2016 at 12:46 AM, Engelke, Johannes <info(a)johannes-engelke.de
wrote:
Hi,
we got the following problem and I would like to know, if you have an idea
how to solve it.

We setup a view domains:
- bar.io
- foo.bar.io
- cf.bar.io

Bar.io <http://bar.io> is used for all the end user related things like
the landing page, documentation, etc. foo.bar.io is used for internal
service endpoints and cf.bar.io is used for all stuff related to CF (api,
uaa, login…) and some shared things like monitoring UI etc.

I created a route *.bar.io to move all typos etc. of our customer touch
points to the central landing page. I was expecting <random>.cf.bar.io
will be still return an 404 Route not found. Now smoketests (using
cf.bar.io) are failing, because the wildcard domain is working recursive
for all subdomains and is returning the content of *.bar app. (See:
https://github.com/cloudfoundry/cf-smoke-tests/blob/master/smoke/runtime/runtime_test.go#L87-L93
)

*.bar.io -> landing-page-app
*.cf.bar.io -> landing-page-app (why?)
*.foo.bar.io -> landing-page-app (why?)

So my question, were should we fix it? Should the gorouter not be
recursive over subdomains? Should we change the smoketest? Or am I on the
wrong track and we should do something else?

Cheers
Johannes


Wildcard routes, subdomains and failing smoke-test

Engelke, Johannes <info@...>
 

Hi,
we got the following problem and I would like to know, if you have an idea how to solve it.

We setup a view domains:
- bar.io
- foo.bar.io
- cf.bar.io

Bar.io is used for all the end user related things like the landing page, documentation, etc. foo.bar.io is used for internal service endpoints and cf.bar.io is used for all stuff related to CF (api, uaa, login…) and some shared things like monitoring UI etc.

I created a route *.bar.io to move all typos etc. of our customer touch points to the central landing page. I was expecting <random>.cf.bar.io will be still return an 404 Route not found. Now smoketests (using cf.bar.io) are failing, because the wildcard domain is working recursive for all subdomains and is returning the content of *.bar app. (See: https://github.com/cloudfoundry/cf-smoke-tests/blob/master/smoke/runtime/runtime_test.go#L87-L93 <https://github.com/cloudfoundry/cf-smoke-tests/blob/master/smoke/runtime/runtime_test.go#L87-L93>)

*.bar.io -> landing-page-app
*.cf.bar.io -> landing-page-app (why?)
*.foo.bar.io -> landing-page-app (why?)

So my question, were should we fix it? Should the gorouter not be recursive over subdomains? Should we change the smoketest? Or am I on the wrong track and we should do something else?

Cheers
Johannes


Re: Support for HTTP/2

Carlo Alberto Ferraris
 

With this limitation in mind, an upstream component could still terminate
TLS, but couldn't Gorouter also?
Just as a small followup, consider that companies might have internal regulations mandating how and where SSL termination needs to happen (Rakuten is among them, for example...). As described in my previous mail, there are workarounds (e.g. using a separate TLS session between LB/RP and gorouter) but this may add further deployment complexity (and overhead).


Re: Support for HTTP/2

Carlo Alberto Ferraris
 

Shannon,
in our design we have a reverse proxy colocated with the gorouter. [1] While we can clearly reencrypt data going over loopback TCP (or Unix sockets :D) to the gorouter... it sounds a little bit overkill.

[1] https://github.com/cloudfoundry/gorouter/issues/110#issuecomment-169204139

5721 - 5740 of 9398