Here's a gist of the output I get and the command I run:
https://gist.github.com/MrEnzyme/7ebd45c9c34151a52050

On Fri, Jun 26, 2015 at 10:58 PM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

It should work since our acceptance tests validate this on every build we
cut [1]. Are you running the operation as someone with a cc admin scope?

If you want to create a gist with the log (with secrets redacted) from
running `cf` with CF_TRACE=true, we could certainly take a look.

[1]:
https://github.com/cloudfoundry/cf-acceptance-tests/blob/cdced815f585ef4661b2182799d1d6a7119489b0/apps/app_stack_test.go#L36-L104

On Fri, Jun 26, 2015 at 2:36 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

I'm having an issue where I can't upload any buildpack to cloudfoundry;
it says "The buildpack upload is invalid: a filename must be specified" and
the cf_trace confirms it's sending a null value for filename. The thing is,
I have specified a file name every time and get this error. I've used a few
different CLI versions and uploaded different buildpacks as both zip
files/directories, and nothing works. Is this a bug in the CLI/cloud
controller, or am I doing something wrong?

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

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

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

once you get to this line where you make the app started [1], then the
next step is that the cloud controller should be sending a NATS message
targeted at a particular DEA selected to run the app.

so you could monitor:
* NATS to see if you see the CC sending the NATS message
* the DEA logs to see if it receives the message
* the DEA to logs see if it is able to react to the message once it
receives it

we have had issues in the past where NATS issues on client/server
communication were addressed with restarting clients and servers, but it's
been quite awhile. letting us know which cf-release you are using could
help.

[1]
https://gist.github.com/yeukhon/666fa1936ef3473c6de6#file-gistfile1-txt-L534

On Mon, Jun 29, 2015 at 7:20 AM, John Wong <gokoproject(a)gmail.com> wrote:

Hi.

We are running on an extremely old version of CF (we are in the process
of building one based on the latest), so I know there is very little the
community may be able to help.

But regardless... let me give it a try.


In my debug session, I tried to deploy a hello world app, and deployment
stopped with "STARTED" and eventually timeout.

The full log:
https://gist.githubusercontent.com/yeukhon/666fa1936ef3473c6de6/raw/1f662b86e806ab1fff230f5558f4942d9785c584/gistfile1.txt


I can easily reproduce this when I did two concurrent push. Sometimes
they go through, sometimes they don't.

We have looked at every log in CF and we don't have any lead. I did bosh
restart JOB hoping it was caused by a slow process, but that did not help.
I found ntp was not installed on some of the components (we installed ntp
on all of the DEAs), and i found clock was not synced so I synced the
clocked, and still no help.

Any idea where I should look at? I thought about our EC2 instance health
but all of them seem to be healthy. I am considering relaunching (bosh
recreate) one component at a time.

The one thing I did notice is I am constantly deploying to a couple DEAs.
I will look into them but I am not sure...


Any ideas will be appreciated. Thanks.

John

_______________________________________________
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

Hi.

We are running on an extremely old version of CF (we are in the process of
building one based on the latest), so I know there is very little the
community may be able to help.

But regardless... let me give it a try.


In my debug session, I tried to deploy a hello world app, and deployment
stopped with "STARTED" and eventually timeout.

The full log:
https://gist.githubusercontent.com/yeukhon/666fa1936ef3473c6de6/raw/1f662b86e806ab1fff230f5558f4942d9785c584/gistfile1.txt


I can easily reproduce this when I did two concurrent push. Sometimes they
go through, sometimes they don't.

We have looked at every log in CF and we don't have any lead. I did bosh
restart JOB hoping it was caused by a slow process, but that did not help.
I found ntp was not installed on some of the components (we installed ntp
on all of the DEAs), and i found clock was not synced so I synced the
clocked, and still no help.

Any idea where I should look at? I thought about our EC2 instance health
but all of them seem to be healthy. I am considering relaunching (bosh
recreate) one component at a time.

The one thing I did notice is I am constantly deploying to a couple DEAs.
I will look into them but I am not sure...


Any ideas will be appreciated. Thanks.

John

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

Hi,

We're going to use diego in production. Could you please give the date of
the first formal release?

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

Hi Mike,

I think I understand your use case.
Currently route services are specced out such that they must, at minimum,
function like a proxy.
I think you're proposing that a route service could be a service that is
not a proxy.
I think what would be needed is a way to specify things, like https only
for example, as a route service, such that a router, like the gorouter, or
tcp router, could interpret that attribute on the route and apply that
behavior.
That sound right?

-Dieu


On Sat, Jun 27, 2015 at 2:05 PM, James Bayer <jbayer(a)pivotal.io> wrote:

i think i understand what you mean now. shannon has thought through those
concepts and relationships and the options for how to express them. i'll
let him comment on his current thinking. i got hung up on this example not
being complete and assumed you mean binding to an app:

cf bind/unbind-route-service

more explicitly, i believe you're advocating for an experience like:

cf bind-route-service ROUTE SERVICE_INSTANCE
cf unbind-route-service ROUTE SERVICE_INSTANCE

where ROUTE today is typically expressed with the compound "DOMAIN -n
HOSTNAME" rather a named alias.

On Fri, Jun 26, 2015 at 7:23 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

Let me clarify. I'm still 100% on board with binding a service to a
route. What I'm proposing with my different perspective is to decouple the
idea of a Route service being a proxy and think of a service bound to a
route as a generic way to apply enhanced functionality to a route (not
necessarily through a proxy) and make applying a proxy to a route a
standard extension to a route service similar in concept to how a service
meant to be bound to an app can be enhanced to provide a log drain.

Does that make sense?

Mike

On Fri, Jun 26, 2015 at 1:36 AM, James Bayer <jbayer(a)pivotal.io> wrote:

we explored the ux of app to service binding in detail, but it is
problematic.

apps will soon support multiple routes on different ports.
e.g. imagine an app with 3 ports:
web traffic goes to container port 8080 on web.example.com
admin traffic goes to container port 8888 on admin.example.com
jmx goes to 9000 on jmx.example.com

which of the 3 routes should the route service bound to the app be
associated with?

a route can be mapped to multiple apps, what happens when some apps
mapped to a route have a route service bound and others don't?

shannon can probably explain more of the problem areas that we
discussed, i need to get to bed :)


On Thu, Jun 25, 2015 at 11:55 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

This thread [0] on Route services has got me thinking. I'd like to
propose a slightly different perspective on the route services concept.

A typical service today, lets call them "App Services" at its most
base function exists to apply some functionality to an application.
Typically that functionality comes in the form of credentials supplied to
an application. But not always. For example, a Log Drain App Service
applies log drain functionality to an app. My organization has other
services that apply other functionality to an app not necessarily in the
form of credentials.

So, with that perspective what should a "Route Service" be? I think
at its basest form a Route Service should simply be a way to applying
functionality to a Route. (note I said nothing about proxies).

Just like a log drain app service is a type of App Service. I think a
Proxy Route Service could be viewed as a type of Route Service. Why is
this distinction important? I think it keeps the vision of a route service
more simple, pure, and less implementation specific.

I think with this perspective route services become much simpler and
more powerful. You support binding one or more route services to a route
just like today you can bind one or more app services to an app. However,
if the service identifies itself as a Proxy Route Service (just like a
service can identify itself as a log drain service) then the Cloud
Controller simply fails the bind because today we only allow one proxy
route services to be bound to a route at a time. The UX becomes simply:

cf bind/unbind-route-service

We leave the problem of ordering multiple Proxy Route Services as a
future problem. Of which I think user provided ordering is only one
possible solution. I believe other more natural and simple solutions will
present themselves over time.

Thoughts?

Mike

[0]
http://lists.cloudfoundry.org/pipermail/cf-dev/2015-June/000535.html

_______________________________________________
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

--
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

Hello,

A commit to increment the broker API version header went out by mistake.
We are currently backfilling docs for 2.5 (should be published very soon):
https://www.pivotaltracker.com/story/show/88824286

Broker API v2.5 represents support for the Arbitrary Parameters feature.
Cloud Controller may include a field called "parameters" in the provision,
update, and bind request bodies. Values for this field are only included if
provided by the CF API client (CLI, etc).

These changes are expected to be backwards compatible. A broker that does
not support the "parameters" field should ignore it.

Info that could help troubleshoot:
- what operation fails; create/update broker, provision, bind, etc?
- logs from the broker of the request and response
- logs from cloud controller of the request and response to the broker
- output of CLI with CF_TRACE=true

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 8:26 PM, James Bayer <jbayer(a)pivotal.io> wrote:

looks like the docs are only at 2.4:
http://docs.cloudfoundry.org/services/api.html

2.5 should only have been incremental changes and should be backward
compatible with other 2.x versions.

when you say it doesn't work, do you have details of an interaction that
shows the problem?

On Thu, Jun 25, 2015 at 7:45 PM, NGUYEN Hong Chau <
nguyenhongchau(a)gmail.com> wrote:

Hi all,

I'm trying to implement a service broker for cf-release v210. I
implemented my service broker in cf-release v207 based on this service
broker project
<https://github.com/cloudfoundry-community/spring-boot-cf-service-broker>.
Now cf-release v210 using api version 2.5 for broker and my code
doesn't work. I'm looking up docs for api version 2.5 but find no document
available yet. Does anyone implement a service broker for api version 2.5?
And could you explain me the modifications I must do for the new broker
version?

Thanks in advance.

--
Nguyen Hong-Chau

_______________________________________________
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

i think i understand what you mean now. shannon has thought through those
concepts and relationships and the options for how to express them. i'll
let him comment on his current thinking. i got hung up on this example not
being complete and assumed you mean binding to an app:

cf bind/unbind-route-service

more explicitly, i believe you're advocating for an experience like:

cf bind-route-service ROUTE SERVICE_INSTANCE
cf unbind-route-service ROUTE SERVICE_INSTANCE

where ROUTE today is typically expressed with the compound "DOMAIN -n
HOSTNAME" rather a named alias.

On Fri, Jun 26, 2015 at 7:23 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Let me clarify. I'm still 100% on board with binding a service to a
route. What I'm proposing with my different perspective is to decouple the
idea of a Route service being a proxy and think of a service bound to a
route as a generic way to apply enhanced functionality to a route (not
necessarily through a proxy) and make applying a proxy to a route a
standard extension to a route service similar in concept to how a service
meant to be bound to an app can be enhanced to provide a log drain.

Does that make sense?

Mike

On Fri, Jun 26, 2015 at 1:36 AM, James Bayer <jbayer(a)pivotal.io> wrote:

we explored the ux of app to service binding in detail, but it is
problematic.

apps will soon support multiple routes on different ports.
e.g. imagine an app with 3 ports:
web traffic goes to container port 8080 on web.example.com
admin traffic goes to container port 8888 on admin.example.com
jmx goes to 9000 on jmx.example.com

which of the 3 routes should the route service bound to the app be
associated with?

a route can be mapped to multiple apps, what happens when some apps
mapped to a route have a route service bound and others don't?

shannon can probably explain more of the problem areas that we
discussed, i need to get to bed :)


On Thu, Jun 25, 2015 at 11:55 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

This thread [0] on Route services has got me thinking. I'd like to
propose a slightly different perspective on the route services concept.

A typical service today, lets call them "App Services" at its most base
function exists to apply some functionality to an application. Typically
that functionality comes in the form of credentials supplied to an
application. But not always. For example, a Log Drain App Service applies
log drain functionality to an app. My organization has other services that
apply other functionality to an app not necessarily in the form of
credentials.

So, with that perspective what should a "Route Service" be? I think at
its basest form a Route Service should simply be a way to applying
functionality to a Route. (note I said nothing about proxies).

Just like a log drain app service is a type of App Service. I think a
Proxy Route Service could be viewed as a type of Route Service. Why is
this distinction important? I think it keeps the vision of a route service
more simple, pure, and less implementation specific.

I think with this perspective route services become much simpler and
more powerful. You support binding one or more route services to a route
just like today you can bind one or more app services to an app. However,
if the service identifies itself as a Proxy Route Service (just like a
service can identify itself as a log drain service) then the Cloud
Controller simply fails the bind because today we only allow one proxy
route services to be bound to a route at a time. The UX becomes simply:

cf bind/unbind-route-service

We leave the problem of ordering multiple Proxy Route Services as a
future problem. Of which I think user provided ordering is only one
possible solution. I believe other more natural and simple solutions will
present themselves over time.

Thoughts?

Mike

[0]
http://lists.cloudfoundry.org/pipermail/cf-dev/2015-June/000535.html

_______________________________________________
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

--
Thank you,

James Bayer

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

Let me clarify. I'm still 100% on board with binding a service to a
route. What I'm proposing with my different perspective is to decouple the
idea of a Route service being a proxy and think of a service bound to a
route as a generic way to apply enhanced functionality to a route (not
necessarily through a proxy) and make applying a proxy to a route a
standard extension to a route service similar in concept to how a service
meant to be bound to an app can be enhanced to provide a log drain.

Does that make sense?

Mike

On Fri, Jun 26, 2015 at 1:36 AM, James Bayer <jbayer(a)pivotal.io> wrote:

we explored the ux of app to service binding in detail, but it is
problematic.

apps will soon support multiple routes on different ports.
e.g. imagine an app with 3 ports:
web traffic goes to container port 8080 on web.example.com
admin traffic goes to container port 8888 on admin.example.com
jmx goes to 9000 on jmx.example.com

which of the 3 routes should the route service bound to the app be
associated with?

a route can be mapped to multiple apps, what happens when some apps
mapped to a route have a route service bound and others don't?

shannon can probably explain more of the problem areas that we discussed,
i need to get to bed :)


On Thu, Jun 25, 2015 at 11:55 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

This thread [0] on Route services has got me thinking. I'd like to
propose a slightly different perspective on the route services concept.

A typical service today, lets call them "App Services" at its most base
function exists to apply some functionality to an application. Typically
that functionality comes in the form of credentials supplied to an
application. But not always. For example, a Log Drain App Service applies
log drain functionality to an app. My organization has other services that
apply other functionality to an app not necessarily in the form of
credentials.

So, with that perspective what should a "Route Service" be? I think at
its basest form a Route Service should simply be a way to applying
functionality to a Route. (note I said nothing about proxies).

Just like a log drain app service is a type of App Service. I think a
Proxy Route Service could be viewed as a type of Route Service. Why is
this distinction important? I think it keeps the vision of a route service
more simple, pure, and less implementation specific.

I think with this perspective route services become much simpler and
more powerful. You support binding one or more route services to a route
just like today you can bind one or more app services to an app. However,
if the service identifies itself as a Proxy Route Service (just like a
service can identify itself as a log drain service) then the Cloud
Controller simply fails the bind because today we only allow one proxy
route services to be bound to a route at a time. The UX becomes simply:

cf bind/unbind-route-service

We leave the problem of ordering multiple Proxy Route Services as a
future problem. Of which I think user provided ordering is only one
possible solution. I believe other more natural and simple solutions will
present themselves over time.

Thoughts?

Mike

[0] http://lists.cloudfoundry.org/pipermail/cf-dev/2015-June/000535.html

_______________________________________________
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

I'm having an issue where I can't upload any buildpack to cloudfoundry; it
says "The buildpack upload is invalid: a filename must be specified" and
the cf_trace confirms it's sending a null value for filename. The thing is,
I have specified a file name every time and get this error. I've used a few
different CLI versions and uploaded different buildpacks as both zip
files/directories, and nothing works. Is this a bug in the CLI/cloud
controller, or am I doing something wrong?

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

matt,

could you elaborate a bit on what you believe ssh access to instances is
for?


b


On Thu, Jun 25, 2015 at 9:29 PM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

My concern is the default behavior.

When I first prototyped this support in February, I never expected that
merely accessing a container would cause it to be terminated. As we can see
from Jan's response, it's completely unexpected; many others have the same
reaction.

I do not believe that this behavior should be part of the default
configuration and I do believe the control needs to be at the space level.
I have have already expressed this opinion during Diego retros and at the
runtime PMC meeting.

I honestly believe that if we were talking about applying this behavior
to `bosh ssh` and `bosh scp`, few would even consider running in a 'kill on
taint mode' because of how useful it is. We should learn from that.

If this behavior becomes the default, I think our platform will be seen
as moving from opinionated to parochial. That would be unfortunate.


On Thu, Jun 25, 2015 at 6:05 PM, James Bayer <jbayer(a)pivotal.io> wrote:

you can turn the "restart tainted containers" feature off with
configuration if you are authorized to do so. then using scp to write files
into a container would be persisted for the lifetime of the container even
after the ssh session ends.

On Thu, Jun 25, 2015 at 5:50 PM, Jan Dubois <jand(a)activestate.com>
wrote:

On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io> wrote:

after executing a command, concluding an
interactive session, or copying a file into an instance, that

instance will

be restarted.

What is the purpose of being able to copy a file into an instance if
the instance is restarted as soon as the file has been received?

Cheers,
-Jan
_______________________________________________
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

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

_______________________________________________
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

you can turn the "restart tainted containers" feature off with configuration
if you are authorized to do so. then using scp to write files into a
container would be persisted for the lifetime of the container even after
the ssh session ends.

On Thu, Jun 25, 2015 at 5:50 PM, Jan Dubois <jand(a)activestate.com> wrote:

On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io> wrote:

after executing a command, concluding an
interactive session, or copying a file into an instance, that instance
will
be restarted.

What is the purpose of being able to copy a file into an instance if
the instance is restarted as soon as the file has been received?

Cheers,
-Jan
_______________________________________________
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

It feels like the right behavior, but also very unexpected. My vote would
be to enable it by default, but as Matt suggests, make clear to the user
that their actions will have unrequested consequences. Users will be trying
to use SSH with expected patterns, including the assumption of longevity.

I don't think it's a tough sell that recycling is a good idea, but that
sale still needs to be made to each user.


On Thursday, June 25, 2015, Matt Cowger <matt(a)cowger.us> wrote:

we propose to implement a restart policy for CF app instances: after

executing a command, concluding an interactive session, or copying a file
into an instance, that instance will be restarted.

I have to agree with Matt S here - having this as default behavior is
rough....having an instance restart automatically after running a command,
ending a session (what if that session end was accidental, or caused by
external network problems) or upon copying a file in (which presumably had
a reason to be used) would certainly fall into the 'unexpected' category
for someone who doesn't follow CF development closely.

I totally understand the argument about tainted containers being
snowflakes (hugely dangerous in and of itself), and I wouldn't want to see
them stick around forever either.

Some alternative thoughts:

* Upon tainting a container, add a scheduled task that recycles the
container in N hours unless some action is take (like issuing another
tainted command)
* Declaring a warning (MOTD style) on login that the following sorts of
commands will result in instant recycle upon logout
* Combined with above - automatically recycling a container after N hours
or logout unless a given file (~/dont_tase_me) exists*

I think something like the above prevents the 'magic' effects that feel
dangerous and, as Matt suggested, somewhat parochial. They also require
the instance manager to make active efforts to prevent recycling, thus
hopefully preventing some of the self-induced snowflake effect.

*reminds me of my favorite old VMS command:
FORCE_DISMOUNT_USE_WITH_EXTREME_CAUTION (yes, that was the whole command
you actually had to type).

--Matt Cowger


On Thu, Jun 25, 2015 at 10:53 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

matt,

could you elaborate a bit on what you believe ssh access to instances is
for?


b


On Thu, Jun 25, 2015 at 9:29 PM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

My concern is the default behavior.

When I first prototyped this support in February, I never expected that
merely accessing a container would cause it to be terminated. As we can see
from Jan's response, it's completely unexpected; many others have the same
reaction.

I do not believe that this behavior should be part of the default
configuration and I do believe the control needs to be at the space level.
I have have already expressed this opinion during Diego retros and at the
runtime PMC meeting.

I honestly believe that if we were talking about applying this behavior
to `bosh ssh` and `bosh scp`, few would even consider running in a 'kill on
taint mode' because of how useful it is. We should learn from that.

If this behavior becomes the default, I think our platform will be seen
as moving from opinionated to parochial. That would be unfortunate.


On Thu, Jun 25, 2015 at 6:05 PM, James Bayer <jbayer(a)pivotal.io> wrote:

you can turn the "restart tainted containers" feature off with
configuration if you are authorized to do so. then using scp to write files
into a container would be persisted for the lifetime of the container even
after the ssh session ends.

On Thu, Jun 25, 2015 at 5:50 PM, Jan Dubois <jand(a)activestate.com>
wrote:

On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io> wrote:

after executing a command, concluding an
interactive session, or copying a file into an instance, that

instance will

be restarted.

What is the purpose of being able to copy a file into an instance if
the instance is restarted as soon as the file has been received?

Cheers,
-Jan
_______________________________________________
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

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

_______________________________________________
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

--
-- Matt

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

looks like the docs are only at 2.4:
http://docs.cloudfoundry.org/services/api.html

2.5 should only have been incremental changes and should be backward
compatible with other 2.x versions.

when you say it doesn't work, do you have details of an interaction that
shows the problem?

On Thu, Jun 25, 2015 at 7:45 PM, NGUYEN Hong Chau <
nguyenhongchau(a)gmail.com> wrote:

Hi all,

I'm trying to implement a service broker for cf-release v210. I
implemented my service broker in cf-release v207 based on this service
broker project
<https://github.com/cloudfoundry-community/spring-boot-cf-service-broker>.
Now cf-release v210 using api version 2.5 for broker and my code
doesn't work. I'm looking up docs for api version 2.5 but find no document
available yet. Does anyone implement a service broker for api version 2.5?
And could you explain me the modifications I must do for the new broker
version?

Thanks in advance.

--
Nguyen Hong-Chau

_______________________________________________
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