Make the storage backend configurable in the stack

[tlotze]

The container stack as defined by docker-compose.yml and the devops swarm configuration uses a RelStorage and a PostgreSQL database without asking. It may be desirable to use ZEO instead, or even just a local FileStorage with a single backend process for small projects. There should be a cookiecutter configuration option for this.

[davisagli]

Cookieplone's main goal is to provide an easy on-ramp for newcomers to Plone. I'm worried that adding more choices for how to do things works against that goal. If we need to add more options to support "advanced" users, I would really like to make sure they are in a separate set of questions that is only asked if the user indicates they want advanced options. But, I don't think cookiecutter gives us that much flexibility in how the prompts are asked.

[stevepiercy]

But, I don't think cookiecutter gives us that much flexibility in how the prompts are asked.

Not yet. cookiecutter/cookiecutter#1645

It was requested back in 2017. cookiecutter/cookiecutter#1021

[tlotze]

Cookieplone's main goal is to provide an easy on-ramp for newcomers to Plone. I'm worried that adding more choices for how to do things works against that goal.

In general, I agree with the sentiment. But...

If we need to add more options to support "advanced" users,

to a newcomer, I consider the choice of storage much more easy to expect, understand and answer than, for example, the questions about versions (in particular about pre-release versions), or even the number of different names that are asked (all of the slug and package names).

I would really like to make sure they are in a separate set of questions that is only asked if the user indicates they want advanced options.

It would also help to group all the devops-related questions and ask first whether to create any devops stuff at all.

[yurj]

We could mark the Relstorage option as "best practice" and have it the default. This is enough for newcomers, and leave the choice open for developers.

[tlotze]

RelStorage is the default as it is, so the proposed change doesn't alter the default choice of storage.

[davisagli]

to a newcomer, I consider the choice of storage much more easy to expect, understand and answer than, for example, the questions about versions (in particular about pre-release versions), or even the number of different names that are asked (all of the slug and package names).

I have colleagues who started with Plone recently and don't even know that these different storage options exist, because they are using the defaults. What I'd like to avoid is forcing them to learn about them (or give them the impression that they need to learn about them) before they need to.

I suggest we do the following:

1. Finish reviewing Configurable storage #152 and add the option. Make sure the text makes it clear that it's only used for the deployment stack, and label Relstorage as "(recommended)"
2. Separately, investigate options for organizing the cookiecutter prompts better. Maybe this means adding a way to do grouping and conditional prompts in cookiecutter, maybe it means switching from cookiecutter to custom code for collecting the options, maybe it means creating a separate starter template which uses the same files but asks fewer questions.

[tlotze]

1. Finish reviewing [Configurable storage #152](https://github.com/plone/cookieplone-templates/pull/152) and add the option. Make sure the text makes it clear that it's only used for the deployment stack, and label Relstorage as "(recommended)"

I added a commit that I hope does both of these.

2. Separately, investigate options for organizing the cookiecutter prompts better. Maybe this means adding a way to do grouping and conditional prompts in cookiecutter, maybe it means switching from cookiecutter to custom code for collecting the options, maybe it means creating a separate starter template which uses the same files but asks fewer questions.

I'll look into the cookiecutter issues and PR referenced by @stevepiercy in #151 (comment) .