Date   

Re: SSH access to CF app instances on Diego

Matthew Sykes <matthew.sykes@...>
 

Depends on your role and where your app is in the deployment pipeline. Most
of the scenarios I envisioned were for the tail end of development where
you need to poke around to debug and figure out those last few problems.

For example, Ryan Morgan was saying that the Cloud Foundry plugin for
eclipse is going to be using the ssh support in diego to enable debug of
application instances in the context of a buildpack deployed app. This is
aligned with other requirements I've heard from people working on dev tools.

As apps reach production, I would hope that interactive ssh is disabled
entirely on the prod space leaving only scp in source mode as an option
(something the proxy can do).

Between dev and prod, there's a spectrum, but in general, I either expect
access to be enabled or disabled - not enabled with a suicidal tendency.

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

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


Re: SSH access to CF app instances on Diego

Jan Dubois <jand@...>
 

I would rather that scp would throw an error than having it copy the
file and then immediately kill the instance. I still don't understand
how that would ever be useful.

Or would having a simultaneous ssh session to the same container keep
it alive even after the scp session ended?

I have no problem with not allowing scp into app instances by default.

Cheers,
-Jan

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


Re: SSH access to CF app instances on Diego

Cornelia Davis <cdavis@...>
 

On behalf of many customers that I have spoken to, the default behavior of
disposing of any container that could be tainted is the right choice. Not
providing rope is a huge feature of the platform. If you want to be
dangerous, it should be hard to do so. And as James has explained, it is
possible.

On Fri, Jun 26, 2015 at 8:59 AM, Dan Wendorf <dwendorf(a)pivotal.io> wrote:

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


Can't create/update buildpacks, "a filename must be specified"

kyle havlovitz <kylehav@...>
 

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?


Re: Document for service broker api version 2.5

Shannon Coen
 

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


Re: Issues with offline ruby_buildpack, disconnected CF, and gems from Git

Josh Ghiloni
 

Thanks for the response Mike. I'll take a look this afternoon when I get a chance and get back to you.

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

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


________________________________
From: cf-dev-bounces(a)lists.cloudfoundry.org <cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of Mike Dalessio <mdalessio(a)pivotal.io>
Sent: Friday, June 26, 2015 10:14 AM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] Issues with offline ruby_buildpack, disconnected CF, and gems from Git

Hi Josh,

I can't reproduce what you're describing, so in order to diagnose what's going on, we'll probably need more information.

Here's what I did to attempt to reproduce, so that you can compare what you're doing:

- I'm pushing the app at https://github.com/cloudfoundry/ruby-buildpack/tree/master/cf_spec/fixtures/sinatra_web_app

- I ran `bundle package` locally, and here's what the `vendor` directory looks like:

```
vendor/
└── bundle
├── bin
│ ├── rackup
│ └── tilt
└── ruby
└── 2.2.0
├── bin
│ ├── rackup
│ └── tilt
├── build_info
├── cache
│ ├── rack-1.5.2.gem
│ ├── rack-protection-1.5.2.gem
│ ├── sinatra-1.4.4.gem
│ └── tilt-1.4.1.gem
├── doc
├── extensions
├── gems
│ ├── rack-1.5.2
│ │ ├── COPYING
│ │ ├── KNOWN-ISSUES
│ │ ├── README.rdoc
│ │ ├── Rakefile
│ │ ├── SPEC
...
│ ├── sinatra-1.4.4
│ │ ├── AUTHORS
│ │ ├── CHANGES
│ │ ├── Gemfile
│ │ ├── LICENSE
│ │ ├── README.de.md<http://README.de.md>
...
└── specifications
├── rack-1.5.2.gemspec
├── rack-protection-1.5.2.gemspec
├── sinatra-1.4.4.gemspec
└── tilt-1.4.1.gemspec

70 directories, 410 files
```

- I made sure I didn't have a `.cfignore` file, which might prevent the `vendor` subdirectory from being uploaded on `cf push`. (You can read more about this lesser-known feature here: http://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#exclude)

- I pushed the app with ruby-buildpack v1.3.0, and amongst the log output I see:

```
-------> Buildpack version 1.3.0
-----> Compiling Ruby/Rack
-----> Using Ruby version: ruby-2.0.0
-----> Installing dependencies using 1.7.12
Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
Using bundler 1.7.12
Installing tilt 1.4.1
Installing rack 1.5.2
Installing rack-protection 1.5.2
Installing sinatra 1.4.4
Your bundle is complete!
Gems in the groups development and test were not installed.
It was installed into ./vendor/bundle
Bundle completed (0.54s)
Cleaning up the bundler cache.
```

Note that the `bundle` command is displayed. This command does not require any network connectivity if all the gems are in your vendor directory. You can test this yourself by disconnecting your dev machine from the network and running it:

```
$ bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
Using bundler 1.9.4
Installing tilt 1.4.1
Installing rack 1.5.2
Installing rack-protection 1.5.2
Installing sinatra 1.4.4
Bundle complete! 1 Gemfile dependency, 5 gems now installed.
Gems in the groups development and test were not installed.
Bundled gems are installed into ./vendor/bundle.
```


So, what are we doing differently?

-mike




On Thu, Jun 25, 2015 at 11:50 AM, Josh Ghiloni <jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>> wrote:
Hi all,

I’m currently working on a project where I have my gem source in our local git enterprise server, and I need to push an app that uses it to an instance of CF (v208) that is disconnected from the internet. The app has in its Gemfile a reference to that gem like this:

```
gem 'mygem', :git => 'https://github.myco.com/common/mygem.git'
```

When I run

```
bundle install
bundle package
```

That gem never shows up in my `vendor/cache` directory. However, if I use `bundle package --all`, it shows up in my `vendor/cache` directory as `vendor/cache/mygem-0.0.1-d1c2237f1ebca`. Unfortunately, when I `cf push`, the result is the same in both cases: my ruby app fails to find the require. I’m using the ruby buildpack v1.3, for what it’s worth. Also of note, this does run locally.

Is there something I can do to git ruby to recognize that this gem exists? I’m still rather new to Ruby and don’t fully understand the intricacies.

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


Re: Issues with offline ruby_buildpack, disconnected CF, and gems from Git

Mike Dalessio
 

Hi Josh,

I can't reproduce what you're describing, so in order to diagnose what's
going on, we'll probably need more information.

Here's what I did to attempt to reproduce, so that you can compare what
you're doing:

- I'm pushing the app at
https://github.com/cloudfoundry/ruby-buildpack/tree/master/cf_spec/fixtures/sinatra_web_app

- I ran `bundle package` locally, and here's what the `vendor` directory
looks like:

```

vendor/
└── bundle
├── bin
│ ├── rackup
│ └── tilt
└── ruby
└── 2.2.0
├── bin
│ ├── rackup
│ └── tilt
├── build_info
├── cache
│ ├── rack-1.5.2.gem
│ ├── rack-protection-1.5.2.gem
│ ├── sinatra-1.4.4.gem
│ └── tilt-1.4.1.gem
├── doc
├── extensions
├── gems
│ ├── rack-1.5.2
│ │ ├── COPYING
│ │ ├── KNOWN-ISSUES
│ │ ├── README.rdoc
│ │ ├── Rakefile
│ │ ├── SPEC
...
│ ├── sinatra-1.4.4
│ │ ├── AUTHORS
│ │ ├── CHANGES
│ │ ├── Gemfile
│ │ ├── LICENSE
│ │ ├── README.de.md
...
└── specifications
├── rack-1.5.2.gemspec
├── rack-protection-1.5.2.gemspec
├── sinatra-1.4.4.gemspec
└── tilt-1.4.1.gemspec

70 directories, 410 files

```

- I made sure I didn't have a `.cfignore` file, which might prevent the
`vendor` subdirectory from being uploaded on `cf push`. (You can read more
about this lesser-known feature here:
http://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#exclude
)

- I pushed the app with ruby-buildpack v1.3.0, and amongst the log output I
see:

```

-------> Buildpack version 1.3.0
-----> Compiling Ruby/Rack
-----> Using Ruby version: ruby-2.0.0
-----> Installing dependencies using 1.7.12
Running: bundle install --without development:test --path
vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
Using bundler 1.7.12
Installing tilt 1.4.1
Installing rack 1.5.2
Installing rack-protection 1.5.2
Installing sinatra 1.4.4
Your bundle is complete!
Gems in the groups development and test were not installed.
It was installed into ./vendor/bundle
Bundle completed (0.54s)
Cleaning up the bundler cache.

```

Note that the `bundle` command is displayed. This command does not require
any network connectivity if all the gems are in your vendor directory. You
can test this yourself by disconnecting your dev machine from the network
and running it:

```

$ bundle install --without development:test --path vendor/bundle --binstubs
vendor/bundle/bin -j4 --deployment
Using bundler 1.9.4
Installing tilt 1.4.1
Installing rack 1.5.2
Installing rack-protection 1.5.2
Installing sinatra 1.4.4
Bundle complete! 1 Gemfile dependency, 5 gems now installed.
Gems in the groups development and test were not installed.
Bundled gems are installed into ./vendor/bundle.

```


So, what are we doing differently?

-mike

On Thu, Jun 25, 2015 at 11:50 AM, Josh Ghiloni <jghiloni(a)ecsteam.com> wrote:

Hi all,

I’m currently working on a project where I have my gem source in our
local git enterprise server, and I need to push an app that uses it to an
instance of CF (v208) that is disconnected from the internet. The app has
in its Gemfile a reference to that gem like this:

```
gem 'mygem', :git => 'https://github.myco.com/common/mygem.git'
```

When I run

```
bundle install
bundle package
```

That gem never shows up in my `vendor/cache` directory. However, if I
use `bundle package --all`, it shows up in my `vendor/cache` directory as
`vendor/cache/mygem-0.0.1-d1c2237f1ebca`. Unfortunately, when I `cf push`,
the result is the same in both cases: my ruby app fails to find the
require. I’m using the ruby buildpack v1.3, for what it’s worth. Also of
note, this does run locally.

Is there something I can do to git ruby to recognize that this gem
exists? I’m still rather new to Ruby and don’t fully understand the
intricacies.

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: SSH access to CF app instances on Diego

Dan Wendorf
 

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
<javascript:_e(%7B%7D,'cvml','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
<javascript:_e(%7B%7D,'cvml','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
<javascript:_e(%7B%7D,'cvml','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
<javascript:_e(%7B%7D,'cvml','jand(a)activestate.com');>> wrote:

On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io
<javascript:_e(%7B%7D,'cvml','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
<javascript:_e(%7B%7D,'cvml','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
<javascript:_e(%7B%7D,'cvml','cf-dev(a)lists.cloudfoundry.org');>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Matthew Sykes
matthew.sykes(a)gmail.com
<javascript:_e(%7B%7D,'cvml','matthew.sykes(a)gmail.com');>

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
<javascript:_e(%7B%7D,'cvml','cf-dev(a)lists.cloudfoundry.org');>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
<javascript:_e(%7B%7D,'cvml','cf-dev(a)lists.cloudfoundry.org');>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
-- Matt


Re: Feedback: A slightly different perspective on route services

Mike Youngstrom
 

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


Re: Feedback: A slightly different perspective on route services

James Bayer
 

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


Feedback: A slightly different perspective on route services

Mike Youngstrom
 

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


Re: SSH access to CF app instances on Diego

Matt Cowger
 

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


Re: SSH access to CF app instances on Diego

Aaron Huber
 

I can certainly confirm that for Intel this feature would be required for us
to use ssh/scp access at all, and maybe not even then. We've been selling
Cloud Foundry to our security folks as a huge improvement in app security
specifically because developers don't have access to the containers and they
don't need to be "system admins". Enabling this feature goes a long way
towards unwinding that and having this extra control might give us some
wiggle room to enable it. In any case, the default configuration should
always be the most secure and it can be easily configured off if desired.

I think it's been said before, but I also strongly feel that "cf files"
needs to continue to work in Diego even if ssh/scp access is disabled. If
we're not allowed to enable ssh/scp access and "cf files" goes away then
we've effectively lost all access to the containers for developers which
will be frustrating. If "cf files" is going away, then we'd need some way
to enforce that the only access allowed is read-only. Even destroying the
container after the ssh session ends may not be good enough - an argument
can easily be made that a malicious user could keep the ssh session open
after intentionally modifying the container in some way.

Aaron Huber
Intel Corporation



--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-SSH-access-to-CF-app-instances-on-Diego-tp531p549.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: SSH access to CF app instances on Diego

Benjamin Black
 

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


Re: SSH access to CF app instances on Diego

James Bayer
 

thanks for sharing your view matt. i happen to disagree. i've talked to
many more conservative enterprise operations people and they really don't
want to enable snowflakes by default.

since we plan to have both global and per-space/per-app configuration
options, administrators can make the choice for each installation if they
want to enable writable containers without tainted container recycling.
each vendor that distributes cloud foundry could have their own opinionated
default.

i'd love to hear from others in the oss community what the default should
be in cf-release. i can tell you that the vast majority of customers and
people i've spoken with feel it should be "recycle tainted containers by
default" and only able to be turned off with an exception to the rule from
an administrator.

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


--
Thank you,

James Bayer


Re: service discovery

James Bayer
 

i would encourage you to consider a circuit breaker pattern like hystrix
which will have graceful degradation if a remote endpoint is unavailable
because it has not started yet, has too many failures, is network
segmented, etc..

On Thu, Jun 25, 2015 at 9:02 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

No. My endpoints don't change. I envision having a number of 12 factor
stateless applications getting deployed using CF push (java buildpacks).
Some of these stateless apps need to talk to each other and so the need for
service discovery.


Currently we use Consul - i.e. each 12 factor app registers itself with
Consul and apps needs to re-discover another app. We feed in the Consul
end point to all the apps as an environment variable.


Using environment variables has a dependency issue that certain
applications that have not been started yet, would not be visible to
applications that have already started...but a HashMap of apps and its
route could itself serve as a repository to discover other applications as
long as the app can get access to the hash map or we persist this hash map
as a KV store in Consul.


Thanks all for your inputs.


Sumanth



------------------------------
*From:* cf-dev-bounces(a)lists.cloudfoundry.org <
cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of James Bayer <
jbayer(a)pivotal.io>
*Sent:* Thursday, June 25, 2015 11:42 PM

*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] service discovery

can you describe the architecture of your applications? do the
endpoints change often after some mircoservices have been started?

your app needs some way to look up other network endpoints it needs.
there are several ways to do this.

* use environment variables - which is provided just-in-time when the
container starts - this might be a URL for example, that routes to the CF
router that might be bound to several different apps, but all the source
app needs to know is the destination route represented by a FQDN and
optional context path

* use a service - either user a service broker or provided service that
provides information to the apps that bind to it, might be a URL and
authentication information, this information is also put in the apps env
variables

* use something like the spring cloud config service that can distribute
information to clients dynamically post container start [1]

* use something like the spring cloud eureka service from netflix oss
that can provide dynamic information to clients using netflix ribbon, also
takes in updates post container start [2] [3]

[1] https://www.youtube.com/watch?v=bJvReWt2jLc
[2] http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html
[3]
http://blog.pivotal.io/pivotal-cloud-foundry/features/deploying-microservice-architectures-with-pivotal-cloud-foundry

On Thu, Jun 25, 2015 at 7:47 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

micro-service architecture.


Yes - would like for applications to discover the URL of other
applications deployed in CF . Consul is what I use right now - was
wondering if CloudFoundry had something in this space.


Service brokers I thought are only for stateful components like a
database, Consul..can it be used for stateless components as well?



Thanks,

Sumanth


------------------------------
*From:* cf-dev-bounces(a)lists.cloudfoundry.org <
cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of John Wong <
gokoproject(a)gmail.com>
*Sent:* Thursday, June 25, 2015 10:35 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] service discovery

What's the requirement that your application need to discover other
application? Did you mean somethibg like say microservice architecture and
you want to know the url available and any metadat / property of some
service / app you depend on? One way is via service broker. You can use
also use consul and token to do ACL based resource retrieval/discovery and
I have seen this apptoach (actually today at a local tech talk).
On Thursday, June 25, 2015, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

Hi,


In CF space - the applications that get deployed in warden containers
- how do they discover other applications ? Should we pick a third party
like Consul or Eureka, or does CF provide an alternate approach.


Thanks in advance.


Thanks,

Sumanth

--
Sent from Jeff Dean's printf() mobile console

_______________________________________________
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


--
Thank you,

James Bayer


Re: SSH access to CF app instances on Diego

Matthew Sykes <matthew.sykes@...>
 

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


Re: Soliciting feedback on a UX change for route services

Guillaume Berche
 

I was about to suggest a similar UX for expressing a list of route
services, by relying on params ordering

cf update-route DOMAIN [-n HOST] (-s 'service instance' )*
cf update-route DOMAIN [-n HOST] -s caching -s https-only -s rate-limiting

Besides, If the MVP does not include support for multiple route services,
route service implementers might be able to experiment with supporting
arbitrary params as a way for users to specify fine grain options, possibly
ordered

cf create-service large-grain-route-service -p '{ "caching": true,
"ssl_only": true, "rate_limit": 3 }'

+1 for Mike's suggestions to allow for some route services to be
implemented in an upfront LB such as no router. This might address the
latency and availability concerns in the initial MVP ("route services to
forward requests back through the LB and GoRouter")

Lastly, it seems important that route services be able to output logs that
end up being associated with the app that receive the associated traffic
(e.g. cache hit or cache miss for a specific incoming request). With route
services being associated to routes (and not being bound to app instances
anymore), I'd like to re-iterate the suggestion I made in the design
document (on Feb 17) to have the gorouter include the app_id in the headers
of the signed request it sends to route service(s). This will allow for a
route service with log_emiter scope to add entries to the proper app
through loggregator/doppler. Of course, this also means that when a route
is associated to multiple apps, the load balancing decision among app is
made prior to sending traffic to route service(s). I'd imagine the app_id
could be propagated in the signed request headers when going through route
services and finally reaching the gorouter before hitting the app (as to
preserve the stateless nature of gorouter).

Guillaume.

On Fri, Jun 26, 2015 at 12:04 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

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


This is interesting. Could you flesh this out for me? What use cases do
you have in mind for associating a service instance with a route, but not
providing a forwarding address?

I would imagine you could bind a service to a route any time you want to
customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.

Here are a few examples:

* A Public facing service as an indicator that a given route should be
made public facing. (Would require a broker to orchestrate stuff outside
of CF DNS, applying DoS security profiles to the route, force ssl on the
front end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as a
proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be
implemented by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect on a
route. Again could be implemented as a proxy if you trust X-Forwarded-For
or simply change some config on a front end load balancer no new proxy
needed.

Basically a service applied to a route could trigger and manage all kinds
of functionality not necessarily implemented as proxy orchestrated by the
GoRouter.

It also occurs to me that the only time chain ordering of route services
seems to be an issue is in the case of a proxy url. So, it is unfortunate
that I'd be limited to binding only one route service when I may want to
apply all kinds of functionality to a route not implemented as a proxy
because user defined ordering isn't an issue.

That said I can see how it can be difficult for CF to provide a generic
solution to the kind of functionality applied above and that you may not
want to distract from the basic Route Services MVP to accommodate these
types of use cases. I guess I can only hope that you keep the concept of
applying non proxy functionality to a route in mind as you move through
your MVP.

Mike

_______________________________________________
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: service discovery

Sumanth Yamala
 

No. My endpoints don't change. I envision having a number of 12 factor stateless applications getting deployed using CF push (java buildpacks). Some of these stateless apps need to talk to each other and so the need for service discovery.


Currently we use Consul - i.e. each 12 factor app registers itself with Consul and apps needs to re-discover another app. We feed in the Consul end point to all the apps as an environment variable.


Using environment variables has a dependency issue that certain applications that have not been started yet, would not be visible to applications that have already started...but a HashMap of apps and its route could itself serve as a repository to discover other applications as long as the app can get access to the hash map or we persist this hash map as a KV store in Consul.


Thanks all for your inputs.


Sumanth



________________________________
From: cf-dev-bounces(a)lists.cloudfoundry.org <cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of James Bayer <jbayer(a)pivotal.io>
Sent: Thursday, June 25, 2015 11:42 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] service discovery

can you describe the architecture of your applications? do the endpoints change often after some mircoservices have been started?

your app needs some way to look up other network endpoints it needs. there are several ways to do this.

* use environment variables - which is provided just-in-time when the container starts - this might be a URL for example, that routes to the CF router that might be bound to several different apps, but all the source app needs to know is the destination route represented by a FQDN and optional context path

* use a service - either user a service broker or provided service that provides information to the apps that bind to it, might be a URL and authentication information, this information is also put in the apps env variables

* use something like the spring cloud config service that can distribute information to clients dynamically post container start [1]

* use something like the spring cloud eureka service from netflix oss that can provide dynamic information to clients using netflix ribbon, also takes in updates post container start [2] [3]

[1] https://www.youtube.com/watch?v=bJvReWt2jLc
[2] http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html
[3] http://blog.pivotal.io/pivotal-cloud-foundry/features/deploying-microservice-architectures-with-pivotal-cloud-foundry

On Thu, Jun 25, 2015 at 7:47 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:

micro-service architecture.


Yes - would like for applications to discover the URL of other applications deployed in CF . Consul is what I use right now - was wondering if CloudFoundry had something in this space.


Service brokers I thought are only for stateful components like a database, Consul..can it be used for stateless components as well?



Thanks,

Sumanth


________________________________
From: cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org> <cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org>> on behalf of John Wong <gokoproject(a)gmail.com<mailto:gokoproject(a)gmail.com>>
Sent: Thursday, June 25, 2015 10:35 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] service discovery

What's the requirement that your application need to discover other application? Did you mean somethibg like say microservice architecture and you want to know the url available and any metadat / property of some service / app you depend on? One way is via service broker. You can use also use consul and token to do ACL based resource retrieval/discovery and I have seen this apptoach (actually today at a local tech talk).
On Thursday, June 25, 2015, Sumanth Yamala <Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:

Hi,


In CF space - the applications that get deployed in warden containers - how do they discover other applications ? Should we pick a third party like Consul or Eureka, or does CF provide an alternate approach.


Thanks in advance.


Thanks,

Sumanth


--
Sent from Jeff Dean's printf() mobile console

_______________________________________________
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




--
Thank you,

James Bayer


Re: service discovery

James Bayer
 

can you describe the architecture of your applications? do the endpoints
change often after some mircoservices have been started?

your app needs some way to look up other network endpoints it needs. there
are several ways to do this.

* use environment variables - which is provided just-in-time when the
container starts - this might be a URL for example, that routes to the CF
router that might be bound to several different apps, but all the source
app needs to know is the destination route represented by a FQDN and
optional context path

* use a service - either user a service broker or provided service that
provides information to the apps that bind to it, might be a URL and
authentication information, this information is also put in the apps env
variables

* use something like the spring cloud config service that can distribute
information to clients dynamically post container start [1]

* use something like the spring cloud eureka service from netflix oss that
can provide dynamic information to clients using netflix ribbon, also takes
in updates post container start [2] [3]

[1] https://www.youtube.com/watch?v=bJvReWt2jLc
[2] http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html
[3]
http://blog.pivotal.io/pivotal-cloud-foundry/features/deploying-microservice-architectures-with-pivotal-cloud-foundry

On Thu, Jun 25, 2015 at 7:47 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

micro-service architecture.


Yes - would like for applications to discover the URL of other
applications deployed in CF . Consul is what I use right now - was
wondering if CloudFoundry had something in this space.


Service brokers I thought are only for stateful components like a
database, Consul..can it be used for stateless components as well?



Thanks,

Sumanth


------------------------------
*From:* cf-dev-bounces(a)lists.cloudfoundry.org <
cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of John Wong <
gokoproject(a)gmail.com>
*Sent:* Thursday, June 25, 2015 10:35 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] service discovery

What's the requirement that your application need to discover other
application? Did you mean somethibg like say microservice architecture and
you want to know the url available and any metadat / property of some
service / app you depend on? One way is via service broker. You can use
also use consul and token to do ACL based resource retrieval/discovery and
I have seen this apptoach (actually today at a local tech talk).
On Thursday, June 25, 2015, Sumanth Yamala <Sumanth.Yamala(a)sas.com> wrote:

Hi,


In CF space - the applications that get deployed in warden containers -
how do they discover other applications ? Should we pick a third party
like Consul or Eureka, or does CF provide an alternate approach.


Thanks in advance.


Thanks,

Sumanth

--
Sent from Jeff Dean's printf() mobile console

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


--
Thank you,

James Bayer

8821 - 8840 of 9414