Older 3.x versions of Blacklight may have put a solrmarc.jar inside your app's ./config/SolrMarc. That may not be caught by your slug ignore.

This was an error, it was never meant to do that. If you have one in a BL 3.x you should be safe to remove it.

Other than that, I'm curious what's making a BL app so large!

Incidentally, you don't need a ./jetty in your local app _at all_, unless you actually want to keep a jetty Solr there. BL will optionally install one there, but it's not required.

(Does slug size include your gem dependencies? I am not familiar with heroku. Cause the BL gem itself _does_ also include a SolrMarc.jar, if that's a problem, we'd have to refactor things on the BL side to make it an optional dependency instead of baked into BL).

On 3/29/2012 12:37 PM, Chris Fitzpatrick wrote:
Hey Sean,

Jah, I did that...my .slugignore is:
tmp/*
log/*
coverage/*
spec/*
koha/*
jetty/*

That dropped it down to 30 from ~50mb, so that's good .
(koha has some scripts wrote to pull from our ILS).

I think the slug size is a really minor issue. Heroku says under 25mb
is good, but over 50mb is not so good.  Not "Good",  but not "Chaotic
Evil" . "Neutral Good".



On Thu, Mar 29, 2012 at 6:26 PM, Sean Hannan<shan...@jhu.edu>  wrote:
If you already have everything indexed in Solr elsewhere, a way to cut down
the BL slug size is to remove/ignore the SolrMarc.jar. It's pretty sizable.

-Sean


On 3/29/12 12:16 PM, "Chris Fitzpatrick"<chrisfitz...@gmail.com>  wrote:

Hi,

I've deployed Blacklight on both Heroku and Elastic BeanStalk.

Heroku is still a much better choice. The only issue I had was I
needed to make sure the sass-rails gem in installed in the :production
gem group and not just development.

  I still have an issue of getting heroku to compile all my
sass/coffeescript/etc assets on update, but it actually doesn't seem
to make much of an impact on performance. The minor issue is that it
would be nice to figure out a way to slim down BL's slug size. The
lowest I've been able to get it is about 30mb and Heroku recommends
having it be below 25mb.

I have not used Heroku's solr service (I still use EC2 for my solr
deployments).
EngineYard would also be another option.

There is also an AMI for DSpace, so deploying that to EC2 should be
pretty easy....

b,chris.



On Thu, Mar 29, 2012 at 3:55 PM, Rosalyn Metz<rosalynm...@gmail.com>  wrote:
Erik,

I haven't tried it (recently) on PaaS providers, but I have on IaaS.  The
AMIs I've created in association with start up scripts (if you're
interested in seeing those let me know, I'd have to look for them somewhere
or other) mean that the application automagically starts up on its own, all
you need to do is go to the URL.  I've used this as a back up method in the
past and I think would be a great way for people to be able to play with
the different apps before committing.

To this end, I created an AMI for Blacklight a while back:
http://www.rosalynmetz.com/ami-3c10f255/  I guarantee you it is grossly out
of date.  I also have instructions on creating an EBS backed AMI:
http://rosalynmetz.com/ideas/2011/04/14/creating-an-ebs-backed-ami/ which
is the method I used for creating the Blacklight AMI. These instructions
are also fairly old, but I still get comments on my blog now and then that
the method works.

I also played around with it on Heroku, but that was so long ago I don't
think any of the things I learned still apply (this was when Heroku was
fairly new to the scene).  Hope some of this helps.

Rosalyn



On Thu, Mar 29, 2012 at 8:34 AM, Seth van Hooland<svhoo...@ulb.ac.be>wrote:

Dear Erik,

Bram Wiercx and myself have given a talk on how to put together a package
to install CollectiveAccess on Red Hat's OpenShift:
http://www.dish2011.nl/sessions/open-source-software-platform-collectiveacce
s-as-a-service-solution
.

My students are currently happily playing around with CollectiveAccess,
which they have installed on OpenShift. My teaching assistant Max De Wilde
has developed clear guidelines on how to run the installation procedure:
http://homepages.ulb.ac.be/~svhoolan/redhat_ca_install.pdf.

It would be wonderful to aggregate these kind of installation procedure's
for other types of LIS applications...

Kind regards and looking forward to your book!

Seth van Hooland
Président du Master en Sciences et Technologies de l'Information et de la
Communication (MaSTIC)
Université Libre de Bruxelles
Av. F.D. Roosevelt, 50 CP 123  | 1050 Bruxelles
http://homepages.ulb.ac.be/~svhoolan/
http://twitter.com/#!/sethvanhooland
http://mastic.ulb.ac.be
0032 2 650 4765
Office: DC11.113

Le 29 mars 2012 à 14:10, Erik Mitchell a écrit :

Hi all,

I have been toying with the process of implementing common LIS
applications (e.g. Vufind, Dspace, Blacklight. .  .) on PaaS providers
like Heroku and Amazon Elastic Beanstalk.  I have just tried out of
the box distributions so far and have not made much progress but was
wondering if someone else had tried this or had ideas about what
issues I might run into.

Thanks,

Erik

Erik Mitchell
Assistant Professor
College of Information Studies
University of Maryland, College Park
http://ischool.umd.edu

Reply via email to