Make persistent containers

[pkoczan]

I've removed the --rm flag from docker run commands in the script, so that you can make a persistent cluster that then can be started via docker start at a later stage. If you could put a sleep 300 between scaling on "create", then you'd not need to --scale 1 on action=create, and cluster nodes would start up gradually. it will still work, but you need to docker stop/start nodes >1 so they sync up with the cluster properly.

[clouless]

Hi, I actually do not want it to be persistent, since it should only be for testing during plugin development. So see it like atlas-run-standalone, which is also not persistent.

Currently I am happy with the way it works. But you can feel free to fork an modify everything to your needs. This is now part of my release strategy, so I will not change it in the way it works,
because that would potentially break my pre-release testing for my plugin releases.

[pkoczan]

Makes complete sense - the persistent containers are for a different use-case. I would like to modify and add this option to your script, as well as a parameter for a new target version - perform a zero downtime upgrade.

I honestly admire the work you have done, so I would certainly base the above on your script and images - if you allow it of course. If you do, what do you think would be the best way to fork the two? Do you think that making it modular somehow would be possible, so that future features on either path would be available for either use-case?

[clouless]

Ok, sorry I was rather busy the last days due to the pre-release/release phase of one of my plugins.

Since forking only the management script will not be enough. And relying on my docker-images is also not a good idea, since I want to freely be able to change their structure, even though I am always trying to maintain a stable API - I suggest you to propose a pull request, with your new features and I will see if I can include it into my script and from then on maintain it in future versions.

I think it would be best if you could add another parameter, so that you can do:

manage-jira-cluster-7.3.3.sh --action create --scale 1 --storage persistent --run false

And maybe then something like, (maybe you can come up with something better)

manage-jira-cluster-7.3.3.sh --action update --run start

 

And think of the following Corner Cases/Acceptance Criteria:

• idempotence: If you remove --rm what happens, when you do --action destroy and create a new cluster? Are then all named docker images really removed?
• clarity: Please provide some documentation on what your parameters are doing, and what the aim of your feature is like With the parameter XYZ you can make your cluster storage persistent. .....
• holism: When doing a persistent version, make sure
  • (1) database is persistent
  • (2) jira-shared-home is persistent

I personally see a lot of side effects that could happen when cluster is persistent, so please try to think of that and provide proper documentation on what could happen.
For example, I had a lot of problems deleting a docker-volume that is being used by a dangling container. I could not figure out how to find out which container used which volume via docker commands. But maybe you will be able to do it 😄

So I am waiting for your PR