[Dspace-tech] Questions on upgrading from 1.5 to 3.1 and maintaining a live and test instance

2013-06-17 Thread Spencer Lamm 
Hello Everyone,
We are getting ready to do a long overdue upgrade from 1.5.2 to 3.1. In
light of that, I have two questions...

1) This wiki post by Mark Diggory details how to upgrade on the same box
without overwriting - essentially install the new code, diff the config
file differences, copy the db files to the new instance, and run the db
upgrades. We need to upgrade on a new server due to OS issues. Are there
any additional considerations replicating Mark's process on a new server?
https://wiki.duraspace.org/display/DSPACE/To+upgrade+without+overwriting

2) Our assetstore is on a Compellent SAN accessible via a server mount.
What I would love to do is use this upgrade as an opportunity to set up
live and development DSpace servers that are as close as possible to being
exact replicas. Is it possible to have two DSpace instances pointing to the
same assetstore? Do database changes in DSpace upgrades affect the
assetstore ?

Thanks!
Spencer

-- 
Spencer Lamm
Digital Initiatives Librarian
Swarthmore College Library
sla...@swarthmore.edu
610-328-8541
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] Questions on upgrading from 1.5 to 3.1 and maintaining a live and test instance

2013-06-18 Thread helix84 
On Mon, Jun 17, 2013 at 6:52 PM, Spencer Lamm  wrote:
> 1) This wiki post by Mark Diggory details how to upgrade on the same box
> without overwriting - essentially install the new code, diff the config file
> differences, copy the db files to the new instance, and run the db upgrades.
> We need to upgrade on a new server due to OS issues. Are there any
> additional considerations replicating Mark's process on a new server?
> https://wiki.duraspace.org/display/DSPACE/To+upgrade+without+overwriting

Hi Spencer,

using a new server when upgrading is actually a procedure I would
recommend over in-place upgrade, especially in case of a large version
jump.

I outlined the procedure here (I really need to make a wiki page for it):

http://dspace.2283337.n4.nabble.com/Migrate-1-8-to-3-0-database-td4661490.html
http://dspace.2283337.n4.nabble.com/migrate-repository-into-a-new-instances-machine-td4660930.html

Basically, make sure you read through each of the upgrading
instructions (1.5->1.6, 1.6->1.7, ...). You don't need to do all the
steps, but at the very least you have to run the database migration
scripts in the correct order. Then, in the last one (1.8->3.1) follow
the repeated steps you previously skipped.

> 2) Our assetstore is on a Compellent SAN accessible via a server mount.
> What I would love to do is use this upgrade as an opportunity to set up live
> and development DSpace servers that are as close as possible to being exact
> replicas. Is it possible to have two DSpace instances pointing to the same
> assetstore? Do database changes in DSpace upgrades affect the assetstore ?

Yes, it's possible, but I strongly recommend against it! If you did,
you could delete a file in the staging instance and it would be also
missing in the production instance assetstore, but the production
instance wouldn't know about it, because it would still have a record
that it exists in its database.

What you can do is make separate assetstores and use some
deduplication method (because most of the files will be the same) -
from primitive ones like hardlinks to advanced ones like deduplication
on ZFS - check with your SAN admin.


Regards,
~~helix84

Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] Questions on upgrading from 1.5 to 3.1 and maintaining a live and test instance

2013-06-19 Thread Spencer Lamm 
Thanks everyone! Helix84, we'll give your plan a try next week. I'll let
you know about anything we learn that would be good for your potential wiki
entry.


On Tue, Jun 18, 2013 at 4:39 AM, helix84  wrote:

> On Mon, Jun 17, 2013 at 6:52 PM, Spencer Lamm 
> wrote:
> > 1) This wiki post by Mark Diggory details how to upgrade on the same box
> > without overwriting - essentially install the new code, diff the config
> file
> > differences, copy the db files to the new instance, and run the db
> upgrades.
> > We need to upgrade on a new server due to OS issues. Are there any
> > additional considerations replicating Mark's process on a new server?
> > https://wiki.duraspace.org/display/DSPACE/To+upgrade+without+overwriting
>
> Hi Spencer,
>
> using a new server when upgrading is actually a procedure I would
> recommend over in-place upgrade, especially in case of a large version
> jump.
>
> I outlined the procedure here (I really need to make a wiki page for it):
>
>
> http://dspace.2283337.n4.nabble.com/Migrate-1-8-to-3-0-database-td4661490.html
>
> http://dspace.2283337.n4.nabble.com/migrate-repository-into-a-new-instances-machine-td4660930.html
>
> Basically, make sure you read through each of the upgrading
> instructions (1.5->1.6, 1.6->1.7, ...). You don't need to do all the
> steps, but at the very least you have to run the database migration
> scripts in the correct order. Then, in the last one (1.8->3.1) follow
> the repeated steps you previously skipped.
>
> > 2) Our assetstore is on a Compellent SAN accessible via a server mount.
> > What I would love to do is use this upgrade as an opportunity to set up
> live
> > and development DSpace servers that are as close as possible to being
> exact
> > replicas. Is it possible to have two DSpace instances pointing to the
> same
> > assetstore? Do database changes in DSpace upgrades affect the assetstore
> ?
>
> Yes, it's possible, but I strongly recommend against it! If you did,
> you could delete a file in the staging instance and it would be also
> missing in the production instance assetstore, but the production
> instance wouldn't know about it, because it would still have a record
> that it exists in its database.
>
> What you can do is make separate assetstores and use some
> deduplication method (because most of the files will be the same) -
> from primitive ones like hardlinks to advanced ones like deduplication
> on ZFS - check with your SAN admin.
>
>
> Regards,
> ~~helix84
>
> Compulsory reading: DSpace Mailing List Etiquette
> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>



-- 
Spencer Lamm
Digital Initiatives Librarian
Swarthmore College Library
sla...@swarthmore.edu
610-328-8541
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Re: [Dspace-tech] Questions on upgrading from 1.5 to 3.1 and maintaining a live and test instance

2013-06-20 Thread Alan Orth 

Hi, Spencer.

Regarding development/production instances, we maintain our code on 
github[0], with "3_x-dev" and "3_x-prod" branches.  Code modifications 
like XMLUI tweaks, input form modifications, etc are tested and pushed 
to the development branch for scrutiny by our editors and users, and 
then pushed to production every Monday (this creates a predictable 
workflow and timeline for both devs and users).  From time to time we 
manually re-install the development instance with a new snapshot of the 
database and assetstore from production.  Both of our instances live on 
the same box, but we use separate domain names and Apache httpd / Tomcat 
virtual hosting to keep the instances separate.


Hope that helps,

Alan

[0] https://github.com/ilri/DSpace/

On 06/19/2013 09:23 PM, Spencer Lamm wrote:
Thanks everyone! Helix84, we'll give your plan a try next week. I'll 
let you know about anything we learn that would be good for your 
potential wiki entry.



On Tue, Jun 18, 2013 at 4:39 AM, helix84 > wrote:


On Mon, Jun 17, 2013 at 6:52 PM, Spencer Lamm
mailto:sla...@swarthmore.edu>> wrote:
> 1) This wiki post by Mark Diggory details how to upgrade on the
same box
> without overwriting - essentially install the new code, diff the
config file
> differences, copy the db files to the new instance, and run the
db upgrades.
> We need to upgrade on a new server due to OS issues. Are there any
> additional considerations replicating Mark's process on a new
server?
>
https://wiki.duraspace.org/display/DSPACE/To+upgrade+without+overwriting

Hi Spencer,

using a new server when upgrading is actually a procedure I would
recommend over in-place upgrade, especially in case of a large version
jump.

I outlined the procedure here (I really need to make a wiki page
for it):


http://dspace.2283337.n4.nabble.com/Migrate-1-8-to-3-0-database-td4661490.html

http://dspace.2283337.n4.nabble.com/migrate-repository-into-a-new-instances-machine-td4660930.html

Basically, make sure you read through each of the upgrading
instructions (1.5->1.6, 1.6->1.7, ...). You don't need to do all the
steps, but at the very least you have to run the database migration
scripts in the correct order. Then, in the last one (1.8->3.1) follow
the repeated steps you previously skipped.

> 2) Our assetstore is on a Compellent SAN accessible via a server
mount.
> What I would love to do is use this upgrade as an opportunity to
set up live
> and development DSpace servers that are as close as possible to
being exact
> replicas. Is it possible to have two DSpace instances pointing
to the same
> assetstore? Do database changes in DSpace upgrades affect the
assetstore ?

Yes, it's possible, but I strongly recommend against it! If you did,
you could delete a file in the staging instance and it would be also
missing in the production instance assetstore, but the production
instance wouldn't know about it, because it would still have a record
that it exists in its database.

What you can do is make separate assetstores and use some
deduplication method (because most of the files will be the same) -
from primitive ones like hardlinks to advanced ones like deduplication
on ZFS - check with your SAN admin.


Regards,
~~helix84

Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette




--
Spencer Lamm
Digital Initiatives Librarian
Swarthmore College Library
sla...@swarthmore.edu 
610-328-8541




--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev


___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette


--
Alan Orth
alan.o...@gmail.com
http://alaninkenya.org
http://mjanja.co.ke
"I have always wished for my computer to be as easy to use as my telephone; my wish 
has come true because I can no longer figure out how to use my telephone." -Bjarne 
Stroustrup, inventor of C++

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette