Feature Request P2
Status Update
No update yet.
Comments
pr...@google.com
th...@gmail.com
Hello,
Thank you for reaching out to us!
This issue seems to be outside of the scope of Issue Tracker. This Issue Tracker is a forum for end users to report bugs and request features on Google Cloud products. Please go through
I recommend you to
For now, I'm going to close this thread which will no longer be monitored. In case you want to report a new issue, please do not hesitate to create a new Issue Tracker describing your issue.
Thank you!
th...@gmail.com
Please do this, Google! It would improve user experience and acceptance of App Engine Apps dramatically! It can't be very hard to implement it, so it seems to be a quick win for everybody. Many thanks in advance!
bt...@brandonthomson.com
> When deploying new code to the default running app version
You can avoid this today by making sure to always deploy to a new app version. We have a deploy script that increments a monotonic counter and uses the counter value as the version. The script automatically adjusts the default version after verifying that the new version is warmed up and working correctly.
This technique provides a more-or-less seamless transition during updates. It could be integrated into google's appcfg, to avoid the need for folks to write their own custom script.
> When Google moves app serving from one data center to another
Yeah, this causes a mess for us too, although it's hard to tell whether it's caused by lack of warmup on our instances or just general latency associated with the transition. Do you have any hard data on that?
You can avoid this today by making sure to always deploy to a new app version. We have a deploy script that increments a monotonic counter and uses the counter value as the version. The script automatically adjusts the default version after verifying that the new version is warmed up and working correctly.
This technique provides a more-or-less seamless transition during updates. It could be integrated into google's appcfg, to avoid the need for folks to write their own custom script.
> When Google moves app serving from one data center to another
Yeah, this causes a mess for us too, although it's hard to tell whether it's caused by lack of warmup on our instances or just general latency associated with the transition. Do you have any hard data on that?
lh...@gmail.com
> You can avoid this today by making sure to always deploy to a new app version.
Yeah, we do this using a timestamp... but it doesn't completely prevent users from seeing loading requests. For the benefit of others, here's our deployment script (we'll see how badly google code mangles this):
{{{
<target name="deploy-prod" depends="thetargetthatbuildsyourapp">
<property name="appid" value="yourappid" />
<tstamp>
<format property="vnum" pattern="yyyy-MM-dd-HHmm"/>
</tstamp>
<echo message="Deploying to version: ${vnum}" />
<appcfg action="update" war="${staging.dir}">
<options>
<arg value="--application=${appid}" />
<arg value="--version=${vnum}" />
</options>
</appcfg>
<get src="http://${vnum}.${appid}.appspot.com/ping " dest="${build.dir}/warmup-garbage" verbose="true" />
</target>
<target name="deploy-prod-switch" depends="deploy-prod">
<appcfg action="set_default_version" war="${staging.dir}">
<options>
<arg value="--application=${appid}" />
<arg value="--version=${vnum}" />
</options>
</appcfg>
</target>
}}}
Note you still have to delete old versions by hand or else you'll hit the max # of versions.
Yeah, we do this using a timestamp... but it doesn't completely prevent users from seeing loading requests. For the benefit of others, here's our deployment script (we'll see how badly google code mangles this):
{{{
<target name="deploy-prod" depends="thetargetthatbuildsyourapp">
<property name="appid" value="yourappid" />
<tstamp>
<format property="vnum" pattern="yyyy-MM-dd-HHmm"/>
</tstamp>
<echo message="Deploying to version: ${vnum}" />
<appcfg action="update" war="${staging.dir}">
<options>
<arg value="--application=${appid}" />
<arg value="--version=${vnum}" />
</options>
</appcfg>
<get src="http://${vnum}.${appid}.
</target>
<target name="deploy-prod-switch" depends="deploy-prod">
<appcfg action="set_default_version" war="${staging.dir}">
<options>
<arg value="--application=${appid}" />
<arg value="--version=${vnum}" />
</options>
</appcfg>
</target>
}}}
Note you still have to delete old versions by hand or else you'll hit the max # of versions.
Description
* When deploying new code to the default running app version
* When Google moves app serving from one data center to another
In either case, this is experienced as a 20+ second outage by all end-users (depending on how long loading requests take). One plausible solution: Use warmup requests to get the new instances ready before tearing down the old instances.