Hi Markus, On Fri, Apr 15, 2011 at 1:24 PM, Markus Schmidberger <markus.schmidberger at="" mytum.de=""> wrote: > > ? Hi, > ? it is great to have R and BioC in the cloud! Is there any reason to provide > ? your own image from the BioC core team? > ? Check this: [1]http://www.wurlug.org/wurlug/index.php/BioNode > ? Great group, great support, ... > ? Best > ? Markus > > References > > ? 1. http://www.wurlug.org/wurlug/index.php/BioNode > _______________________________________________ > Bioconductor mailing list > Bioconductor at r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor > Thanks for your question. I'll try and answer. We want to keep our cloud support focused tightly on Bioconductor. We aim to provide a new AMI with each new Bioconductor release. Our AMI has many important Bioconductor packages already installed, both software packages (particularly focused on sequencing tasks) and annotation packages. If other groups want to integrate Bioconductor into AMIs that they release, we welcome that and will do what we can to help, but our AMI should be considered the only "officially supported" one. We may like what other groups have done, but even if we work with them, we can't completely control what they do with Bioconductor. Our goals with this AMI are not just to provide Bioconductor in the cloud, but to try and enable use cases that are 1) particularly useful in the cloud, and 2) perhaps somewhat tricky for individual users to set up, or 3) both. To this end, we make it easy to do things like: set up an MPI cluster in the cloud, to run Rgraphviz, and to make it easy to run R in a web browser using RStudio Server. I took a quick look at BioNode. Their most recent AMI is running R 2.11.1 and it doesn't appear that they have too many Bioconductor packages installed. I did not test extensively to see if the use cases I mention above are made easy with their AMI, because none of that is very important if the version of R and Bioconductor that's available is not current. Incidentally, the BioNode AMI is an S3-backed (instance store) AMI which takes several minutes to load. The Bioconductor AMI is EBS-backed which means instances will be available in a few seconds. I hope this answers your question. Dan

Dan and Markus; Interesting discussion, especially as a developer on another of the more general biological AMIs: CloudBioLinux (http://cloudbiolinux.org). > We want to keep our cloud support focused tightly on Bioconductor. We > aim to provide a new AMI with each new Bioconductor release. [...] > If other groups want to integrate Bioconductor into AMIs that they > release, we welcome that and will do what we can to help, but our AMI > should be considered the only "officially supported" one. We may like > what other groups have done, but even if we work with them, we can't > completely control what they do with Bioconductor. This all makes good sense. There is definitely a need for both specialized and generalized AMIs. On the other side, I also think there is lots of room for working collaboratively on these. The approach we've taken in CloudBioLinux is to produce an automated framework that is used to build the images: https://github.com/chapmanb/cloudbiolinux with packages and libraries specified in configuration files. For instance here is R/Bioconductor configuration file (with lots taken from your list of packages): https://github.com/chapmanb/cloudbiolinux/blob/master/config/r-libs.ya ml This framework makes it easy to keep rolling new updates to stay current, and also allows deployment to multiple types of virtual machines. For instance, the latest AMI has 2.12 since it was made just before the latest R release, but the VirtualBox image has 2.13 since we did it last Friday. On the practical side, this also handles a lot of the worries you mentioned. It's EBS backed and contains Rgraphviz and plenty more ready to go. Our hope is this could save you time with building images by automating a lot of the installation, allowing you to focus on the higher level additions that are harder to automate and make your custom AMIs so useful. >From our point of view, it would be great to have the Bioconductor team involved. This would contribute back to making the general AMI more stable and useful, in addition to it just being fun to work together. We've also been trying to convince Pjotr and the BioNode folks to collaborate; I'm planning to roll a Debian image for them. Thanks for the Bioconductor AMI. It's really great to see more people working in this area, Brad