DSpace Docker and Cloud Deployment Goals (old)

Not sure how realistic my idea is, but in terms of very large AIP distribution – we could encourage the community to actively seed it on P2P, so it's distributed by torrent rather than having to pay for long-term hosting costs?

I don't see a direct relation between goal 2 (AIP) and Docker. I now that we would like to use the AIPs within Docker and that it makes sense for Docker to provide AIPs, but I considder this more a side effect than a goal of our docker work. At least it should not be the second goal (expecting at least some people to just quickly read the headlines).

Regarding Docker I see more goals, maybe some may be covered indirectly already, but I think they are worth to get emphasized:

• Making our own development work faster and easier
  Changing between DSpace versions is crucial for DSpace committers while testing and fixing bugs and releasing DSpace versions
• Make it easier to test DSpace for people looking for a new repository software
  With Docker we could provide complex setups that people can use easily to see all of the features DSpace offers. This is a very good option to test DSpace without the necessity to understand the complex setup and installation process.
• Enabling the Community to easily provide previews on coming DSpace versions
  For example we could publish a DSpace 7 preview, that includes example contents, the rest api and angular running in multiple containers, being started just by docker run. We can automate easily all the steps that would be necessary to create such an environment even if the deployment/installation process is not fully developed and even if we still miss a strategy to pack DSpace 7 (or any other version while working on it).
• Provide comparable setups for DSpace testathrons
  For every new version of DSpace we run a testathron. People are asked to got through a testplan provided by DCAT and/or to test their own uses cases for an upcoming version of DSpace. Dockers enables us to provide comparable environments for everyone who is taking part on such a testathron, making it easier to reproduce reported problems. Beside the uses cases, the installation and updates of DSpace has to be tested as well. This is outside of the scope or Docker, but it is only a small part of the whole testathron.

Yes, I suppose I just see a lot of those goals like "comparable setup for testathons", "easy testing for new users", "easy, stable previews" etc, as needing both a well-maintained docker / docker-compose resources, but also a decent set of AIPs to make it a more realistic user experience?

For development, agree they'd mainly be around for just testing and quite often the nature of the fix/improvement being worked on means it needs some special test conditions anyway.

So perhaps the test AIPs are a dependency of a goal like "shared testing / preview / review" experience? (of which docker is another dependency?)