Problems getting latest lagotto running.

[Ruth Ivimey-Cook]

Folks,

Has anyone else tried to get the 3.6.3 lagotto server running?  I have been having problems both with Chef and with the server itself:

The startup issues are described at the end of this mail, but I am having problems once the server is running: despite loading articles, and those articles being in the MySQL table and actions/events happening in the background, the frontpanel (with the 'stats' boxes including the version number) only shows accurate info for #users, version number and #workers and couchdb size. For Articles, Events and so on, it shows '0'.  Any ideas what is going wrong?

[ If I go to the articles page, I do see articles (though I can only see the first page... there are no 'next page' button/s). ]

The installation issues:

- database.yml:  database: alm_<%= Rails.env %>

         should be database: lagotto_<%= Rails.env %>

- node.json:

     "recipe[apt]"

   needed before

     "recipe[lagotto]"

   or the use of "apt-get install" is likely to fail because apt-get update hasn't happened recently enough.

- node.json: new VM hostname is not actually set on the host. Possibly fixed by:

     "recipe[hostname]"

   again, before

     "recipe[lagotto]"

  and with appropriate changes to the Cheffile, though I'm not sure yet.

- Instructions (git clone... vagrant up...) need to say that the Vagrantfile needs to be modified for use with AWS (and probably other providers). For AWS the following is what I changed to:

    aws.access_key_id = ENV['AWS_KEY_ID']

    aws.secret_access_key = ENV['AWS_SECRET_KEY']

    aws.keypair_name = ENV['AWS_KEYPAIR_NAME']

    override.ssh.private_key_path = ENV['AWS_KEY_PATH']

- Instructions also need to indicate the need to change settings.yml, config.json, development.rb, production.rb et al to suit the need.

[Martin Fenner]

Ruth,

thanks for the feedback regarding missing/misleading information in the installation instructions, I will update them accordingly. The instructions should also make clear that what you are seeing is normal behavior: many pages in the admin panel show cached content, in particular the status page. The admin cache is automatically updated once an hour via background jobs, or you can update the cache manually (with running delayed_job workers) with

RAILS_ENV=production bundle exec rake cache:update

The total number of articles is also cached, and the paginator depends on that number. All this caching is necessary, as MySQL isn’t so good with counting if you have large numbers of database rows. This is obviously more of a concern with millions of articles, but on a production system the caching should run transparently.

Let me know how that works, and feel free to upen a Github issue.

Best,

Martin

--
You received this message because you are subscribed to the Google Groups "PLOS API Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to plos-api-develo...@googlegroups.com<mailto:plos-api-develo...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

[Ruth Ivimey-Cook]

Thanks Martin, that does help.

In between posting the mail and now, I ran a deploy via capistrano, which resolved the problems... I noticed the cache:update at that point. Previously I had thought that the config that Vagrant left me with would have been enough -- and it was, nearly, but the crontab was not installed, and the cache not updated.

In referring to the instructions, I was thinking of those on the homepage: the installation.md file is a lot clearer.

It may be useful to either do an automatic (cap production deploy) from the Vagrant run, or to echo some text telling the user 'now set deploy/production.rb and run cap production deploy'.

Ruth