Yes, we think that with the initial scope of work for the v3 cc api that
we'll have the primitives to be able to orchestrate a rolling deploy. In
v3, we've already separated out the staging step so that a new package can
be uploaded and staged without affecting the running app.

-Dieu

On Mon, Jul 6, 2015 at 9:00 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

At one point Diego was slated to look at support for rolling
restart/restage. Is that still being considered in Diego's roadmap? Also,
if there are CC API changes involved it would be nice to keep those in mind
as the V3 API evolves.

Mike

On Mon, Jul 6, 2015 at 1:09 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Peter,

Actually `cf restage` does cause down time. It will stop existing
instances, stage the new app bits with the buildpack, and start new
instances.
It's possible that your app may start quickly enough that you aren't
seeing down time.
It's recommended, that for now, you should use a blue-green deployment
strategy to ensure there is no down time to your users.
If you just need your app to pick up environment variables that aren't
required during staging, you could also just restart your app instead of
restaging with each change.

-Dieu

On Fri, Jul 3, 2015 at 9:17 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hello,

We use some user-provided services to provide some configurations to
our apps.
Sometime we need to update the configurations but without downtime.
So we update these configs using cf update-user-provided-service
command and then we have to restage bound apps.
I have noticed that cf restage causes no downtime as it first starts
the new instances and only then stops the old ones.
This is ok for us, but I could not find any documentation of this
behaviour. Can we rely on this to stay like that in the future or would it
be better to use blue-green deployment (more manual work)?

Best regards,
Petar

_______________________________________________
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

_______________________________________________
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

At one point Diego was slated to look at support for rolling
restart/restage. Is that still being considered in Diego's roadmap? Also,
if there are CC API changes involved it would be nice to keep those in mind
as the V3 API evolves.

Mike

On Mon, Jul 6, 2015 at 1:09 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Peter,

Actually `cf restage` does cause down time. It will stop existing
instances, stage the new app bits with the buildpack, and start new
instances.
It's possible that your app may start quickly enough that you aren't
seeing down time.
It's recommended, that for now, you should use a blue-green deployment
strategy to ensure there is no down time to your users.
If you just need your app to pick up environment variables that aren't
required during staging, you could also just restart your app instead of
restaging with each change.

-Dieu

On Fri, Jul 3, 2015 at 9:17 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hello,

We use some user-provided services to provide some configurations to our
apps.
Sometime we need to update the configurations but without downtime.
So we update these configs using cf update-user-provided-service command
and then we have to restage bound apps.
I have noticed that cf restage causes no downtime as it first starts the
new instances and only then stops the old ones.
This is ok for us, but I could not find any documentation of this
behaviour. Can we rely on this to stay like that in the future or would it
be better to use blue-green deployment (more manual work)?

Best regards,
Petar

_______________________________________________
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

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

Hi Peter,

Actually `cf restage` does cause down time. It will stop existing
instances, stage the new app bits with the buildpack, and start new
instances.
It's possible that your app may start quickly enough that you aren't
seeing down time.
It's recommended, that for now, you should use a blue-green deployment
strategy to ensure there is no down time to your users.
If you just need your app to pick up environment variables that aren't
required during staging, you could also just restart your app instead of
restaging with each change.

-Dieu

On Fri, Jul 3, 2015 at 9:17 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hello,

We use some user-provided services to provide some configurations to our
apps.
Sometime we need to update the configurations but without downtime.
So we update these configs using cf update-user-provided-service command
and then we have to restage bound apps.
I have noticed that cf restage causes no downtime as it first starts the
new instances and only then stops the old ones.
This is ok for us, but I could not find any documentation of this
behaviour. Can we rely on this to stay like that in the future or would it
be better to use blue-green deployment (more manual work)?

Best regards,
Petar

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

We use some user-provided services to provide some configurations to our
apps.
Sometime we need to update the configurations but without downtime.
So we update these configs using cf update-user-provided-service command
and then we have to restage bound apps.
I have noticed that cf restage causes no downtime as it first starts the
new instances and only then stops the old ones.
This is ok for us, but I could not find any documentation of this
behaviour. Can we rely on this to stay like that in the future or would it
be better to use blue-green deployment (more manual work)?

Best regards,
Petar

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

hi

does anyone faced the same issue ?

it seems to be quite important

thx



---------- Forwarded message ----------
From: Gianluca Volpe <gvolpe1968(a)gmail.com>
Date: 2015-06-23 12:30 GMT+02:00
Subject: Loggregator Runtime error: invalid memory address or nil pointer
dereference
To: cf-dev(a)lists.cloudfoundry.org


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


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

github.com/cloudfoundry/loggregatorlib/server/handlers.(*httpHandler).ServeHTTP(0xc209a61e30,
0x7f5171a3b288, 0xc20abf5ae0, 0xc20b12bad0)

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

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

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

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

github.com/cloudfoundry/loggregatorlib/server/handlers.(*httpHandler).ServeHTTP(0xc20bf2d820,
0x7f5171a3b288, 0xc20d33a000, 0xc20c8c9c70)

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

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

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

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


thx
GV


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

hi Erik

did you have the chance to open the chore on this case?

if yes, are there any news about?

thx for your help

Gianluca

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

From a security stand point, if you can ssh into a container, it means you
have write access to the application in CloudFoundry. Thus you can already
push new bits/change the application in question. All of the "papertrail"
functionality around pushing/changing applications exists for SSH as well
(we record events, output log lines, make it visible to users that action
was taken on the application), and thus concerned operators would be able
to determine if someone modifying the application in question.

I have to agree with Matt on this one. I feel that the recycling of
containers is a very anti-developer default. When you approach Cloud
Foundry from the perspective of running production applications the recycle
policy makes complete sense. However, I feel that this misses out on one of
the massive benefits/use cases of Cloud Foundry, what it offers to the
development process.

From a security stand point, if you can ssh into a container, it means you
have write access to the application in CloudFoundry. Thus you can already
push new bits/change the application in question. All of the "papertrail"
functionality around pushing/changing applications exists for SSH as well
(we record events, output log lines, make it visible to users that action
was taken on the application), and thus concerned operators would be able
to determine if someone modifying the application in question.

Therefore I'm lost on how this is truly the most secure default. If we are
really going by the idea that all defaults should be the most secure, ssh
should be disabled by default.

As a developer, I can see many times in which I would want to be able to
ssh into my container and change my application as part of a
troubleshooting process. Using BOSH as an example, CF Devs constantly ssh
into VMs and change the processes running on them in order to facilitate
development. BOSH does not reap the VM and redeploy a new instance when you
have closed the SSH session. Once again this is largely due to the fact
that if you have SSH access, you can already perform the necessary actions
to change the application through different means.

Another huge hindrance to development, is that the recycling policy is
controlled by administrators. It is not something that normal users can
control, even though we allow the granularity of enabling/disabling SSH
completely to the end user. This seems counterintuitive.

I feel that a better solution would be to provide the user with some
knowledge of which instances may be tainted, and then allowing them to opt
into a policy which will reap tainted containers. This provides users with
clear insight that their application instance may be a snowflake (and that
they may want to take action), while also allowing normal behavior with
regards to SSH access to containers.

To summarize, by enabling the recycling policy by default we not only
produce extremely unusual behavior / workflows for developers, we are also
minimizing the developer-friendliness of CF in general. This mixed with the
fact that as a user I cannot even control this policy, leads me to believe
that as a default recycling should be turned off as it provides the most
cohesive and friendly user experience.

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

after executing a command, concluding an interactive session, or

copying a file into an instance, that instance will be restarted.

How does it monitor the behavior? Is there a list of commands
whitelisted? I am curious because I am trying to find out what the
whitelist contain. Also is it at the end of the bosh ssh APP_NAME session?
What if two users are there simultaneously?

Thanks.

On Mon, Jun 29, 2015 at 5:49 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

I think with the CLI we could add clarifying messaging when using ssh
what the current policy around recycling is.
Eric, what do you think about calling it the "recycling" policy, enabled
by default? =D

-Dieu


On Sat, Jun 27, 2015 at 3:42 AM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

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

_______________________________________________
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

_______________________________________________
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