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

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

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