Date   

Re: Soliciting feedback on a UX change for route services

Mike Youngstrom
 

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like services.
Binding a service to a route is as good away as any to start users thinking
that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that may
not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.

I'm not a fan of the proposed create-route/update-route cli syntax. Would
it be possible to bind more than one route service to a route with that
syntax? I'd prefer something like bind-route-service/unbind-route service
commands.

I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would prefer
use of a user-provided service to keep the relationships consistent, the
parameters generic (not specific to USPIs), and limit the number of ways to
accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these tweaks
discussed here change the fundamental routing behavior we're proposing.
That is, that a route service url is associated with the route, and not the
app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Soliciting feedback on a UX change for route services

Shannon Coen
 

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like example.com?
this cli pattern above does not really allow for that right? perhaps it's
better to have a similar syntax to the existing route commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would prefer
use of a user-provided service to keep the relationships consistent, the
parameters generic (not specific to USPIs), and limit the number of ways to
accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these tweaks
discussed here change the fundamental routing behavior we're proposing.
That is, that a route service url is associated with the route, and not the
app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


cf-release v212 is now available

Dieu Cao <dcao@...>
 

Apologies for the delayed release notes. Currently travelling in the UK.
So sunny!

-----

The cf-release v212 was released on June 22nd, 2015

- IMPORTANT: Database migrations have been moved into their own job.
Previously part of cloud_controller_ng details
<https://www.pivotaltracker.com/story/show/92724718>
- IMPORTANT: Loggregator vms have been renamed Doppler details
<https://www.pivotaltracker.com/story/show/89420698>. Note: with
zero-downtime requires a two-phase deploy:
1. Add instances of each doppler job to match the number of instances
of the corresponding loggregator job and deploy.
2. Remove all instances of loggregator and deploy.
- IMPORTANT: default template stemcells have been updated from lucid to
trusty details <https://www.pivotaltracker.com/story/show/95647916>

Buildpacks

- cloudfoundry/cf-release #701
<https://github.com/cloudfoundry/cf-release/pull/701> Upgrade NodeJs
buildpack to v1.3.4 details
<https://www.pivotaltracker.com/story/show/96491602>
- cloudfoundry/cf-release #697
<https://github.com/cloudfoundry/cf-release/pull/697> Upgrade PHP
buildpack to v3.2.2 details
<https://www.pivotaltracker.com/story/show/96125988>
- cloudfoundry/cf-release #699
<https://github.com/cloudfoundry/cf-release/pull/699> Upgrade Staticfile
buildpack to v1.1.0 details
<https://www.pivotaltracker.com/story/show/96330780>
- cloudfoundry/cf-release #702
<https://github.com/cloudfoundry/cf-release/pull/702> Upgrade Python
buildpack to v1.3.5 details
<https://www.pivotaltracker.com/story/show/96496744>

Runtime

- Allow for more than one attribute to be updated in a service instance
update call. If anything fails, roll back all changes. details
<https://www.pivotaltracker.com/n/projects/969486/stories/95209044>
- Warden more gracefully handles "Disconnected" timeouts during staging
details
<https://www.pivotaltracker.com/n/projects/966314/stories/95632950>
- Fixed a bug where newrelic filled logs with bogus error: ERROR :
URI::InvalidURIError: bad URI details
<https://www.pivotaltracker.com/story/show/95284888>
- [Experimental] User can scale v3 applications process memory details
<https://www.pivotaltracker.com/story/show/92367324>
- Address cve USN-2624-1 <http://www.ubuntu.com/usn/usn-2624-1/> details
<https://www.pivotaltracker.com/story/show/96304108>
1. Upgraded installed packages
- Service catalog now reports plans with the duplicate name details
<https://www.pivotaltracker.com/story/show/96240038>
- [Experimental] User can scale v3 process disk details
<https://www.pivotaltracker.com/story/show/92367410>
- Service catalog now reports duplicate plan ids details
<https://www.pivotaltracker.com/n/projects/1211680/stories/96728362>
- Fixed bug where Cloud Controller would become stuck waiting for NFS
details <https://www.pivotaltracker.com/story/show/94152506>
- Fixed bug where apps could request negative disk details
<https://www.pivotaltracker.com/story/show/96771020>
- Added doppler_logging_endpoint to /v2/info details
<https://www.pivotaltracker.com/story/show/93047998>
- Applications can be scaled to 0 instances details
<https://www.pivotaltracker.com/story/show/94063170>
- Space manager and auditor should see 404 error when deleting service
keys details
<https://www.pivotaltracker.com/n/projects/1211680/stories/96753978>
- Gorouter - Added "Cache-Control" and "Expires" headers to prevent
caching of heartbeat responses. details
<https://www.pivotaltracker.com/n/projects/1358110/stories/96503820>
- Fixed a bug where buildpack caches were not being deleted details
<https://www.pivotaltracker.com/story/show/95652208>
- Removed Experimental tag from context path routing details
<https://www.pivotaltracker.com/story/show/>

UAA

- Bumped UAA to version 3.2.1 details
<https://github.com/cloudfoundry/uaa/releases/tag/2.3.1>

Routing Api

- [Experimental] Now co-located on the Cloud Controller details
<https://www.pivotaltracker.com/story/show/91732492>

Loggregator

- No major changes besides the rename to doppler mentioned above

Manifest and Job Spec Changes

- properties.doppler.enabled details
<https://www.pivotaltracker.com/n/projects/966314/stories/93047998>
- properties.doppler.use_ssl details
<https://www.pivotaltracker.com/n/projects/966314/stories/93047998>
- properties.doppler.port details
<https://www.pivotaltracker.com/n/projects/966314/stories/93047998>
- properties.collector.memory_threshold details
<https://www.pivotaltracker.com/story/show/95479064>
- properties.uaa.newrelic.environment can be used to configure the old
newrelic configuration of uaa.newrelic.common.license_key details
<https://github.com/cloudfoundry/cf-release/pull/703>
- properties.uaa.database.case_insensitive can be set to *true* when
using case sensitivity with queries/filters because your DB is case
sensitive.
- [Experimental] routing api properties
- properties.routing-api.consul_ttl
- properties.routing-api.lock_retry_interval
- properties.routing-api.metrics_reporting_ttl
- properties.routing-api.statsd_endpoint
- properties.routing-api.debug_address
- properties.routing-api.max_concurrent_etcd_requests
- properties.routing-api.statsd_client_flush_interval
- [Experimental]
- properties.routing-api.enabled changed to
properties.router.enable_routing_api
- properties.acceptance_tests.oauth_password cats credentials used to
create, list and update routes details
<https://www.pivotaltracker.com/story/show/93734082>
- properties.acceptance_tests.system_domain cats system domain for
your CF releasedetails
<https://www.pivotaltracker.com/story/show/93734082>

Used Configuration

- BOSH Version: 152
- Stemcell Version: 2989
- CC Api Version: 2.29.0

Commit summary
<http://htmlpreview.github.io/?https://github.com/cloudfoundry-community/cf-docs-contrib/blob/master/release_notes/cf-212-whats-in-the-deploy.html>
Compatible Diego Version

- final release 0.1304.0 commit
<https://github.com/cloudfoundry-incubator/diego-release/commit/6e2004e611047da34520652cf021ffad1baed068>


https://github.com/cloudfoundry/cf-release/releases/tag/v212


Re: CfSummit slides

Guillaume Berche
 

Thanks for the update to [1], this really helps to have access to slides
speakers shared.

Regards,

Guillaume.

[1] http://www.cfsummit.com/program/slides


On Wed, Jun 17, 2015 at 12:24 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

no worries, thanks for your help Craig

Guillaume.

On Wed, Jun 17, 2015 at 12:44 AM, C. Craig Ross <ccr(a)linuxfoundation.org>
wrote:

Hi Guillaume,

Regrettably there was some confusion and some speakers submitted them
slides via the CFP system instead of emailing them. The former is the
normal behavior for the majority of our events but the CF Summit slides
needed to be uploaded separately by our events team.

We will get your slides and the others up on the site in the next 24hrs.
Our apologies for the trouble and thanks for bringing this to our attention.

Cheers,

C.

On Tue, Jun 16, 2015 at 6:12 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thank Angela for your response. I wonder whether the CFP system is
properly listing speaker submitted slides, as for example my two sessions
indeed have their slides attached to their associated proposal [1-4], and
they don't yet appear into [5].

Are there some other speakers on the cf-dev list that had their slides
posted on the cfp system and don't yet see them published onto [5] ?

Thanks,

Guillaume.

[1]
http://events.linuxfoundation.org/sites/events/files/slides/orange_case_study_0.pdf
[2] http://events.linuxfoundation.org/cfp/proposals/5249/4719
[3]
http://events.linuxfoundation.org/sites/events/files/slides/adapting_cf_to_org_reqs.pdf
[4] http://events.linuxfoundation.org/cfp/proposals/5249/4721
[5] http://www.cfsummit.com/program/slides

Guillaume.


On Thu, Jun 11, 2015 at 1:42 AM, CF Events <events(a)cloudfoundry.org>
wrote:

Hello Guillaume,

On Wed, Jun 10, 2015 at 5:09 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

Thanks again to the CF Foundation for the great cf summit, and for
publishing so promptly the video recordings on youtube. The sessions
content is great to watch, and I'm sometimes lacking the high resolution
slides display, and ability to use the slides as a reference.

There is currently 12 slide decks onto [1] over the 38 sessions
presented. Is there somewhere else they can be accessed, or any way for the
foundation to publish the ones speakers have already posted on the CFP
system ?
I will double check with our content manager, but typically if slides
are missing it is because the speakers did not share the with us. If we do
still have some that have not been posted, I'll make sure that happens by
Monday.

Thank you,

Angela


Thanks in advance,

Guillaume.

[1] http://www.cfsummit.com/program/slides


--
Cloud Foundry Summit Events Team
Cloud Foundry Foundation
events(a)cloudfoundry.org

--
C. Craig Ross
Director of Creative Services & Developer Programs
The Linux Foundation
http://www.linuxfoundation.org/


loggregator tc repeating error "websocket: close 1005"

Gianluca Volpe <gvolpe1968@...>
 

thx Erik


Re: How to get files from crash apps

James Bayer
 

if you're using DEA's i believe the container stays around on the DEA for
about an hour or so by default before being removed.

assuming you're on a DEA, to investigate, you'd need to know the DEA and
the warden handle to investigate, log in to the DEA as an operator with
bosh, then go the warden depot directory, find the warden handle and
execute bin/wsh from the container handle directory.

see:
http://docs.cloudfoundry.org/running/troubleshooting/troubleshooting-apps.html#access-warden

in diego, removing containers happens right away, but diego is also going
to support ssh for active troubleshooting and could just increase the
memory and attach jvm tools for debugging purposes to troubleshoot.

good luck.

On Tue, Jun 23, 2015 at 1:12 AM, Meng, Xiangyi <xiangyi.meng(a)emc.com> wrote:

We encountered java out of memory issue in our CF env recently. We had
enabled gc log for the application by setting JAVA_TOOL_OPTIONS:
-Xloggc:gc.log. But when out of memory issue occurred, the application was
stopped and removed. We can’t get gc.log. Is there any way to keep the
gc.log after application crashes? The CF version we are using is 197. Any
advice would be appreciated.



Regards,

Maggie

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer


Re: [cf-bosh] The promise is a debt - bosh-init POST

James Bayer
 

looks interesting, would love to hear if people try this approach. thanks
for sharing!

On Tue, Jun 23, 2015 at 12:11 PM, Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote:

Guys here is the second post, this time featuring the new bosh-init CLI.
Any feedback from the community will be great, let me know your
experience!!!

Check it here: http://wp.me/p5G2dP-2z

Thanks,
Leandro.-

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh


--
Thank you,

James Bayer


Re: Soliciting feedback on a UX change for route services

James Bayer
 

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.

regarding the UX, i have tried some explicit examples with
comments/questions below:

cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?

cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future? what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that right?
perhaps it's better to have a similar syntax to the existing route commands:

cf update-route example.com -n foo -s my-audit-service

what about supplying an external URL that is not a service on the platform?
would we do that with a user provided service instance or an explicit URL
added to the route?

# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u https://audit.example.com

how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer


Re: Soliciting feedback on a UX change for route services

Benjamin Black
 

yes, this is how it should work.

On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Soliciting feedback on a UX change for route services

Shannon Coen
 

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


The promise is a debt - bosh-init POST

Leandro David Cacciagioni
 

Guys here is the second post, this time featuring the new bosh-init CLI.
Any feedback from the community will be great, let me know your
experience!!!

Check it here: http://wp.me/p5G2dP-2z

Thanks,
Leandro.-


Loggregator Runtime error: invalid memory address or nil pointer dereference

Gianluca Volpe <gvolpe1968@...>
 

The
/var/vcap/sys/log/loggregator_trafficcontroller/loggregator_trafficcontroller.stderr.log
file has frequent occurrences of this type of snippet


2015/06/16 18:16:13 http: panic serving <routerIP>:<port>: runtime error:
invalid memory address or nil pointer dereference
goroutine 1614338 [running]:
net/http.func·011()
/usr/local/go/src/pkg/net/http/server.go:1100 +0xb7
runtime.panic(0x7c1a40, 0xa4a993)
/usr/local/go/src/pkg/runtime/panic.c:248 +0x18d
github.com/cloudfoundry/loggregatorlib/server/handlers.(*httpHandler).ServeHTTP(0xc209a61e30,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12bad0)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/
github.com/cloudfoundry/loggregatorlib/server/handlers/http_handler.go:29
+0x2f5
trafficcontroller/dopplerproxy.(*Proxy).serveWithDoppler(0xc2080ac0d0,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12bad0, 0xc20aaacd6b, 0xa,
0xc20aaacd46, 0x24, 0x0, 0x12a05f200, ...)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:181
+0x152
trafficcontroller/dopplerproxy.(*Proxy).serveAppLogs(0xc2080ac0d0,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12bad0)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:170
+0x849
trafficcontroller/dopplerproxy.(*Proxy).ServeHTTP(0xc2080ac0d0,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12b930)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:86
+0x4d9
net/http.serverHandler.ServeHTTP(0xc2080046c0, 0x7f5171a3b288,
0xc20abf5ae0, 0xc20b12b930)
/usr/local/go/src/pkg/net/http/server.go:1673 +0x19f
net/http.(*conn).serve(0xc20a8c6f00)
/usr/local/go/src/pkg/net/http/server.go:1174 +0xa7e
created by net/http.(*Server).Serve
/usr/local/go/src/pkg/net/http/server.go:1721 +0x313
2015/06/22 11:28:58 http: panic serving <routerIP>:<port>: runtime error:
invalid memory address or nil pointer dereference
goroutine 2034572 [running]:
net/http.func·011()
/usr/local/go/src/pkg/net/http/server.go:1100 +0xb7
runtime.panic(0x7c1a40, 0xa4a993)
/usr/local/go/src/pkg/runtime/panic.c:248 +0x18d
github.com/cloudfoundry/loggregatorlib/server/handlers.(*httpHandler).ServeHTTP(0xc20bf2d820,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9c70)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/
github.com/cloudfoundry/loggregatorlib/server/handlers/http_handler.go:29
+0x2f5
trafficcontroller/dopplerproxy.(*Proxy).serveWithDoppler(0xc2080ac0d0,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9c70, 0xc20c96e1eb, 0xa,
0xc20c96e1c6, 0x24, 0x0, 0x12a05f200, ...)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:181
+0x152
trafficcontroller/dopplerproxy.(*Proxy).serveAppLogs(0xc2080ac0d0,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9c70)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:170
+0x849
trafficcontroller/dopplerproxy.(*Proxy).ServeHTTP(0xc2080ac0d0,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9ad0)

/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/dopplerproxy/doppler_proxy.go:86
+0x4d9
net/http.serverHandler.ServeHTTP(0xc2080046c0, 0x7f5171a3b288,
0xc20d33a000, 0xc20c8c9ad0)
/usr/local/go/src/pkg/net/http/server.go:1673 +0x19f
net/http.(*conn).serve(0xc20c9cc680)
/usr/local/go/src/pkg/net/http/server.go:1174 +0xa7e
created by net/http.(*Server).Serve
/usr/local/go/src/pkg/net/http/server.go:1721 +0x313


thx
GV


How to get files from crash apps

MaggieMeng
 

We encountered java out of memory issue in our CF env recently. We had enabled gc log for the application by setting JAVA_TOOL_OPTIONS: -Xloggc:gc.log. But when out of memory issue occurred, the application was stopped and removed. We can't get gc.log. Is there any way to keep the gc.log after application crashes? The CF version we are using is 197. Any advice would be appreciated.

Regards,
Maggie


Re: App placement in Diego

Josh Ghiloni
 

Thanks Eric. I’ll pass this info along.

Josh Ghiloni
Senior Consultant
303.932.2202 o | 303.590.5427 m | 303.565.2794 f
jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>

ECS Team
Technology Solutions Delivered
ECSTeam.com<http://ECSTeam.com>

On Jun 22, 2015, at 14:25, Eric Malm <emalm(a)pivotal.io<mailto:emalm(a)pivotal.io>> wrote:

Hi, Josh,

You're probably remembering some discussion about the 'placement pools' or 'placement constraints' feature. We haven't implemented any of that functionality yet in Diego, but we do have a series of stories in the Diego tracker (https://www.pivotaltracker.com/n/projects/1003146) with the '+placement-constraints' label that represents the currently planned work on that track. As we complete the necessary work to get Diego to be ready for production use, we do expect it to be among the first of the new features we start work on.

Thanks,
Eric, CF Runtime Diego PM


On Thu, Jun 18, 2015 at 9:04 AM, Josh Ghiloni <jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>> wrote:
Hi All,

One of the features of Diego I heard about a while ago, when I first heard about Diego, was the ability to restrict an application’s placement to certain availability zones / cells / etc. I’ve been looking around for documentation on this — specifically, if it’s in Diego already and if not, a roadmap, but I’m coming up short. Can anyone here point me to some documentation on this feature? Our client is quite interested in it. Thanks!

Josh Ghiloni
Senior Consultant
303.932.2202<tel:303.932.2202> o | 303.590.5427<tel:303.590.5427> m | 303.565.2794<tel:303.565.2794> f
jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>

ECS Team
Technology Solutions Delivered
ECSTeam.com<http://ecsteam.com/>






_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: App placement in Diego

Eric Malm <emalm@...>
 

Hi, Josh,

You're probably remembering some discussion about the 'placement pools' or
'placement constraints' feature. We haven't implemented any of that
functionality yet in Diego, but we do have a series of stories in the Diego
tracker (https://www.pivotaltracker.com/n/projects/1003146) with the
'+placement-constraints' label that represents the currently planned work
on that track. As we complete the necessary work to get Diego to be ready
for production use, we do expect it to be among the first of the new
features we start work on.

Thanks,
Eric, CF Runtime Diego PM

On Thu, Jun 18, 2015 at 9:04 AM, Josh Ghiloni <jghiloni(a)ecsteam.com> wrote:

Hi All,

One of the features of Diego I heard about a while ago, when I first
heard about Diego, was the ability to restrict an application’s placement
to certain availability zones / cells / etc. I’ve been looking around for
documentation on this — specifically, if it’s in Diego already and if not,
a roadmap, but I’m coming up short. Can anyone here point me to some
documentation on this feature? Our client is quite interested in it. Thanks!

Josh Ghiloni
Senior Consultant
303.932.2202 o | 303.590.5427 m | 303.565.2794 f
jghiloni(a)ecsteam.com

ECS Team
Technology Solutions Delivered
ECSTeam.com






_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: loggregator tc repeating error "websocket: close 1005"

Erik Jasiak <ejasiak@...>
 

Hi Gianluca,

First: using the categories you described, this message is more of a
warning than an error - there should be no impact to your installation.

That said, it still shouldn't be happening. We will investigate further
why we are not providing a status before websocket closing. I'm creating a
chore to investigate further, and any additional info you could provide
would be great.

Thanks,
Erik

On Mon, Jun 22, 2015 at 8:07 AM, Gianluca Volpe <gvolpe1968(a)gmail.com>
wrote:

hi all

I'm having a long list of errors in loggregator_tc stdout log file, saying
:

{"timestamp":1433153574.809743166,"process_id":13854,"source":"loggregator
trafficcontroller","log_level":"error","message":"WebsocketListener.Start:
Error connecting to ws://
198.11.228.56:8081/apps/71725662-41b5-4b1f-a37f-da28b47ece75/stream:
websocket: close 1005
","data":null,"file":"/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/listener/websocket_listen
er.go","line":73,"method":"trafficcontroller/listener.(*websocketListener).listenWithTimeout"}



found the source code responsible for the message:


https://github.com/gorilla/websocket/blob/master/conn.go
called from

https://github.com/cloudfoundry/loggregator/blob/develop/src/trafficcontroller/listener/websocket_listener.go



understood that 1005 is an error reporting to a connection being closed
missing the status information (as of RFC 6455, section 11.7)


// Close codes defined in RFC 6455, section 11.7.
const (
CloseNormalClosure = 1000
CloseGoingAway = 1001
CloseProtocolError = 1002
CloseUnsupportedData = 1003
CloseNoStatusReceived = 1005
CloseAbnormalClosure = 1006
CloseInvalidFramePayloadData = 1007
ClosePolicyViolation = 1008
CloseMessageTooBig = 1009
CloseMandatoryExtension = 1010
CloseInternalServerErr = 1011
CloseTLSHandshake = 1015
)


Each time a log is requested, this error is repeated for many of the
dopplers behind the traffic_controller (but rarely also for all of those),
and I'm still not able to understand if this should be a blocking error or
a sort of warning (I'm not receiving complaints from the users) due to
firehose connection method, but I need to know what is happening and how to
prevent any problem.

thx
GV


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Is the Collector already deprecated?

Erik Jasiak <ejasiak@...>
 

Hi MinhND,

The collector is not deprecated yet - where are you seeing this
property configured?

I found the minimal example AWS yml in release 210, where we have it
set to one I believe [1].

Thanks,
Erik

[1]
https://github.com/cloudfoundry/cf-release/blob/v210/example_manifests/minimal-aws.yml#L241-L250

On Sun, Jun 21, 2015 at 8:44 PM, Nguyen Dang Minh <nguyendangminh(a)gmail.com>
wrote:

Hi guys,

I've just upgraded to the CF 210 and see that the Collector is removed
(instance = 0). Is the Collector officially deprecated? I don't see any
notice in the CF release note.

If it is true, how could I get the DEA metrics now? It seems that the DEA
doesn't send metrics to Doppler at all.

Best regards,
MinhND

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Service Broker API - updating instances

Mike Heath
 

Shannon,

The polling API in the the Asynchronous Operations documentation suffers
from the same problem. Perhaps the .../last_operation request could include
a service_id query parameter?

Thanks,

-Mike

On Thu, Jun 11, 2015 at 5:33 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hello Mike,

Quite reasonable. I'll put a story in the backlog.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 11, 2015 at 2:15 PM, Mike Heath <elcapo(a)gmail.com> wrote:

One of the really nice features of the V2 Service Broker API is the
ability to broker multiple services from a single process. Each service
provides its unique id in the broker catalog. The Cloud Controller then
includes that unique id with requests to the broker making it easy for the
broker to route the request to the correct service.

The problem I'm currently having is that the API added in version 2.4 for
updating a service instances does not include the service's unique id [1].
It only provides the service instance's id and the new plan id. This makes
it very difficult to route the update request to the correct service
provider within a process brokering multiple services as it would require
querying each service provider to determine if it brokered the provided
instance.

I would like to propose adding a service_id field to the update request,
the same as every other request in the service broker API. I believe that
the main issue with this is that it implies that an instance's service
provider could be changed by the broker. I think proper documentation would
alleviate that issue though.

Thoughts?

-Mike

1 -
http://docs.cloudfoundry.org/services/api.html#updating_service_instance

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


loggregator tc repeating error "websocket: close 1005"

Gianluca Volpe <gvolpe1968@...>
 

hi all

I'm having a long list of errors in loggregator_tc stdout log file, saying :

{"timestamp":1433153574.809743166,"process_id":13854,"source":"loggregator
trafficcontroller","log_level":"error","message":"WebsocketListener.Start:
Error connecting to ws://
198.11.228.56:8081/apps/71725662-41b5-4b1f-a37f-da28b47ece75/stream:
websocket: close 1005
","data":null,"file":"/var/vcap/data/compile/loggregator_trafficcontroller/loggregator/src/trafficcontroller/listener/websocket_listen
er.go","line":73,"method":"trafficcontroller/listener.(*websocketListener).listenWithTimeout"}



found the source code responsible for the message:


https://github.com/gorilla/websocket/blob/master/conn.go
called from
https://github.com/cloudfoundry/loggregator/blob/develop/src/trafficcontroller/listener/websocket_listener.go



understood that 1005 is an error reporting to a connection being closed
missing the status information (as of RFC 6455, section 11.7)


// Close codes defined in RFC 6455, section 11.7.
const (
CloseNormalClosure = 1000
CloseGoingAway = 1001
CloseProtocolError = 1002
CloseUnsupportedData = 1003
CloseNoStatusReceived = 1005
CloseAbnormalClosure = 1006
CloseInvalidFramePayloadData = 1007
ClosePolicyViolation = 1008
CloseMessageTooBig = 1009
CloseMandatoryExtension = 1010
CloseInternalServerErr = 1011
CloseTLSHandshake = 1015
)


Each time a log is requested, this error is repeated for many of the
dopplers behind the traffic_controller (but rarely also for all of those),
and I'm still not able to understand if this should be a blocking error or
a sort of warning (I'm not receiving complaints from the users) due to
firehose connection method, but I need to know what is happening and how to
prevent any problem.

thx
GV


Is the Collector already deprecated?

Nguyen Dang Minh
 

Hi guys,

I've just upgraded to the CF 210 and see that the Collector is removed
(instance = 0). Is the Collector officially deprecated? I don't see any
notice in the CF release note.

If it is true, how could I get the DEA metrics now? It seems that the DEA
doesn't send metrics to Doppler at all.

Best regards,
MinhND

8881 - 8900 of 9425