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