search

openaddresses / machine

Scripts for running OpenAddresses on a complete data set and publishing the results.
http://results.openaddresses.io/
ISC License
97 stars 36 forks source link

Publish latest docker tag for images on Docker Hub #642

Closed jalessio closed 7 years ago

jalessio commented 7 years ago

This is in response to #641

And my editor deleted a bunch of whitespace in the install.md.

From an ✈️ :)

migurski commented 7 years ago

I avoided latest previously because I thought there might be some unintentional clobbering with multiple versions. What do you think about switching to a major version image name with this change, e.g. openaddr/machine6:latest? It keeps the ambiguity at bay while still allowing us to use this convention?

jalessio commented 7 years ago

I'm confused by your concerns around clobbering versions. Are you concerned that versions would be lost / not maintained on Docker Hub for backward compatibility? Or that users would inadvertently clobber their own versions? Or something else?

For the proposal to use a tag like openaddr/machine6:latest I think the counter-example are the numerous projects which maintain multiple versions of Docker images in a single namespace. Look at 'python' on Docker Hub, for example. It has tags for versions 2.7 through 3.6 where latest tracks the newest release on whatever version (which today is 3.6.x, but probably used to be 3.5.x). As you know, 2.7 through 3.6 covers a huge range of Python features/compatibility.

Somewhat related, I found the tag 6.x to be confusing when I found it. I actually assume that was a placeholder and I was supposed to figure out what version number to replace the x with. Took me a few minutes before I realized that 6.x was the actual tag. Using the python project again as an example, they would just maintain the 6 tag for that.

migurski commented 7 years ago

In AWS, we have a configuration for each major version which references openaddr/machine:5.x, openaddr/machine:6.x, and so on. I don’t want those to reference full major/minor/patch versions because the updates to launch configurations would be a pain on each release. Major version upgrades often involve a short period of overlap while I bring up new versions, check that they work, and then spin down old ones. If I need to back up or slow down an upgrade, using :latest is going to be weird. This has happened a couple times.

It sounds like the suggestion here should be: publish openaddr/machine:latest for the benefit of users, but stick with major version tags for the deployed configurations. Also, borrow Python’s tag conventions and switch to e.g. openaddr/machine:6 instead of the confusing 6.x.

trescube commented 7 years ago

I like the idea of publishing openaddr/machine:latest for use by people (like me) who can follow instructions to a T but can't easily get outside of the box for ops-related things. As a person who barely comprehends those sorts of things, the instructions should be consistent between steps 1 and 3. That is, step 1 says to pull openaddr/machine:6.x but that's not copied into step 3 where latest is assumed (I think) so I had to specify openaddr/machine:6.x when running docker.

This minor snag aside, I'm very happy with how easy it is to run individual sources locally using docker!

migurski commented 7 years ago

I remembered another reason I avoided :latest until now: with potential releases for old versions interleaved with newer ones the tag might accidentally end up referring to a backport release. It’s not really guaranteed to be newer, for example during the week of April 20. This isn’t impossible to workaround, just a reason I had for not messing with latest when it didn’t seem necessary.