Jamis,
Yeah deployment definitely goes bad if the timestamp is before another
more recent deployment, AND you run a migration. The migration gets
run on the most recent timestamp, not the current one being updated
and sym_linked.
As for multiple servers, it's not an issue if the deployment server is
out of sync as long as the timestamps remain in order. For instance if
it's off by five days it's fine as long as the update release
directory is the most recent timestamp on that server.
I personally had a big failure due to this.
I had a release with the timestamp of ~'1220153000', however another
developer had deployed a release to ~'1220163000'.
The deployment and symlink went fine, and the server was running off
'1220153000' code. However, the "rake db:migrate" is setup to run on
the MOST RECENT timestamped release. So in this case it ran on the
"1220163000" directory. Site crashed because the code couldn't find
several new tables.
It's a pretty unusual error, but I don't think it would be a bad idea
to standardize the timestamps to the deployment servers, even if each
one has imperfectly sync time. The issue is avoided as long as the
timestamps REMAIN IN ORDER. If something pops behind another release,
and you have a migration, it fails. Even different servers with
unsync'd time should keep the releases in order.
I agree it's a rare case, but I do think it would be a good idea to
standardize to server time. However as you suggested I have added it
to my deploy.rb for the time being.
Thanks,
Mark
On Dec 23, 12:25 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
> Mark,
>
> This sounds like a "this might possibly bite someone someday" issue.
> Have you actually been bitten by this, where a deployment goes bad
> because of an incorrect timestamp?
>
> The sad fact is, the only authoritative way to build the timestamp
> would be to query a time server on each deploy. Even production
> servers can get out of sync--ours have, on occasion. If the current
> implementation concerns you, then you're more than welcome to use the
> solution you suggested--plopping that right into your deploy.rb should
> work just fine.
>
> - Jamis
>
> On Dec 23, 2007, at 9:32 AM, Mark Percival wrote:
>
>
>
> > I came across this issue a couple days ago and found it interesting.
> > Quick rundown - I develop on a Ubuntu VM inside of my windows laptop.
> > This allows me to develop on a machine configured identically to my
> > production Ubuntu server. The problem is that sometimes the time gets
> > out of sync when I suspend the machine. So in some cases my Ubuntu
> > machine can think it's 3 days ago, especially if I suspend over the
> > weekend.
>
> > Of course as Capistrano currently uses the date on the local machine,
> > you can wind up with a release directory that's actually behind
> > another deployment from another developer.
>
> > For example -
> > The current date is midnight 12/20/2007, and my laptop thinks it's
> > 12/15/2007
> > /u/apps/sampleapp/releases/20071215000000 is where mine deployed
> > /u/apps/sampleapp/releases/20071217000000 is where another developer
> > deployed 3 days ago
>
> > The "current" directory gets symlinked to the "20071215" directory
> > with the up to date code, and if you run a migration it gets run on
> > the latest directory, which in this case is set to the "20071217"
> > directory. So now you have your mongrels running off the "20071215"
> > directory, and the database still lacking the most recent update.
>
> > Now obviously one solution is for me to sync my clock. I recognize
> > that it's ridiculous to expect capistrano to make up for my poor "time
> > management"
>
> > But I think there's a more subtle problem here. If you're working in
> > group where multiple people can deploy, you could still run into this
> > issue. For example, it's not absurd to expect a one developers clock
> > to be off my 5 minutes, and I've been in a situation where one person
> > has deployed and minutes later I fixed an issue and redeployed.
>
> > I think the best solution is to base all release directory timestamps
> > off of the server. That completely solves the issue and to be honest
> > it just make more sense to organize around one time standard, rather
> > than to expect everyone to be perfectly in sync.
>
> > I propose the following modification -
> > _cset(:release_name) { Time.parse(capture('date')).utc.strftime("%Y
> > %m
> > %d%H%M%S") }
>
> > This has solved the problem entirely for me, and now I can happily
> > update from a laptop that think it's Dec 15, 1986, as I often do
> > whilst traveling around in my DeLorean.
>
> > Of course I'm not an expert on Capistrano, so I'd appreciate any
> > thoughts on why this would be a good or bad change.
>
> > Thanks,
> > Mark Percival
> > >
>
>
> smime.p7s
> 3KDownload
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
