We're moving some content from Zope 2.6 to 2.6.2, and I'm wondering what the best way to do this would be. In the fantasy world that is my mind, I think I'd be looking for a way to safely lock the ZODB in the 2.6 instance, so we can migrate to 2.6.2 while still serving (unchangeable) content from 2.6. Does such a concept exist? --- Edward J. Pollard University of Lethbridge Web Development
Sure, you can lock the one ZODB, but depending on your apps, you will get a lot of errors (all of my apps write to the ZODB). I have outlined what I do here: http://www.zopezone.com/faq/1063992383 Jake -- http://www.ZopeZone.com Edward Pollard said:
We're moving some content from Zope 2.6 to 2.6.2, and I'm wondering what the best way to do this would be.
In the fantasy world that is my mind, I think I'd be looking for a way to safely lock the ZODB in the 2.6 instance, so we can migrate to 2.6.2 while still serving (unchangeable) content from 2.6.
Does such a concept exist?
--- Edward J. Pollard University of Lethbridge Web Development
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Mon, Oct 20, 2003 at 11:28:51AM -0600, Edward Pollard wrote:
We're moving some content from Zope 2.6 to 2.6.2, and I'm wondering what the best way to do this would be.
usually just copy the Data.fs into the new instance and away you go...
In the fantasy world that is my mind, I think I'd be looking for a way to safely lock the ZODB in the 2.6 instance, so we can migrate to 2.6.2 while still serving (unchangeable) content from 2.6.
Does such a concept exist?
Not that I know of, but maybe something like this would work: - make the Zope 2.6.2 instance the only publically accessible instance, even though it has no content yet. - set up the old 2.6.0 instance in read-only mode (there are docs on how to do this), and run it on a port that is not accessible to the outside world. - serve stuff from 2.6.2 if found, else from 2.6.0 A pure-Zope approach might be to do this: modify standard_error_message on the 2.6.2 instance to do (pseudocode): if the error is NotFound: make an http request with the same headers to the 2.6.0 instance (you will need an ExternalMethod to do that) if 404: re-raise the NotFound error else: return the result of the request from 2.6.0 An alternative, probably higher-performance, approach is to use an Apache rewrite rule that tries to get stuff from 2.6.2, and rewrites the request to 2.6.0 only if the response is 404. This might require a cgi script, not sure. I don't know how to do this off the top of my head, but some quick googling turns up some likely-looking documentation. All of the above should work if you're just serving content, but if people in the outside world can add or modify zope objects, you'd need to be sure that it actually works. I suspect this will be tricky. E.g. what do you do when object foo exists on 2.6.0 and wants to be modified? You have to be sure that it gets copied to 2.6.2 first. There are other potential complications. e.g. catalog searches. - Once all that's done, use export/import or ZSyncer to gradually move things to the Zope 2.6.2 instance. Seems like a lot of work, I'll just keep copying my storage when I upgrade :-) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's UGLY-DISTRACTION NURSE! (random hero from isometric.spaceninja.com)
We're moving some content from Zope 2.6 to 2.6.2, and I'm wondering what the best way to do this would be.
In the fantasy world that is my mind, I think I'd be looking for a way to safely lock the ZODB in the 2.6 instance, so we can migrate to 2.6.2 while still serving (unchangeable) content from 2.6.
If you have an INSTANCE_HOME setup, you can install the new version alongside the old, turn off the old version, change the INSTANCE_HOME variable (I actually change a symbolic link under Linux) and turn the new one on within whatever time it takes to restart your site. It you have a ZEO setup, this can be done even faster, possibly instantaneously: you could have both new and old running off the same ZODB but on different ports, and when you wanted to cut over, make your proxy/cache/firewall-port-forwarder point to the new port. If you're actually talking separate instance (and not just upgrading an instance) then you could remove all permissions for changing content from whatever roles your usual users have until you've moved everything you need to move. But there is no safe low-level way to make the ZODB read-only. --jcc -- "My point and period will be throughly wrought, Or well or ill, as this day's battle's fought."
participants (4)
-
Edward Pollard -
J. Cameron Cooper -
Jake (aka BZ) -
Paul Winkler