@chirlu now has the FreeDB gateway running in a Google VM and wanted to know if anything was still needed from the old VM running on OSUOSL. No one mentioned anything specific and @Rob said old VM was treated as disposable, so it should be fine to just kill it.
As per @Rob, we still very much want to upgrade our JIRA instance, but we want to move to NewHost more, so @Zas (and everyone else) are all about moving our things to Docker. Once everything is dockerised, we can move to NewHost, and then we can upgrade JIRA.
This concludes the regular meeting, so only people actually involved (or interested) in the dockerisation process were asked to remain around.
pgbouncer vs. pg-pool
pool is much more complex than bouncer and has some drawbacks, and high availability stuff seems tacked on. @Bitmap says dockerization should not depend on moving to pool since we have already spent enough time getting pgbouncer to work properly in dockers, and that we may want to look at using “haproxy or something” for load balancing, with pgbouncer in front of that.
Conclusion is that @Bitmap investigates this further.
progress on MBS docker image
@Bitmap estimates that he’s “approaching half way done” for the MBS docker image.
@Rob will look at search related things. @Zas should “focus on the gateways and ancillary images, such as rsync, ftp.” @LordSputnik might be able to look at CAA. @Gentlecat was asked to “focus on CB, then MeB, then CAA if LordSputnik isn’t done with it.”
move CAA to Flask before dockerizing
@Gentlecat and @Rob talked a bit back and forth, but nothing conclusive.
Discussion about whether a prod/dev split is even necessary: it is.
Then discussion turned into how to achieve this, and Docker’s own docks recommend using separate compose files, so we’re going with that: one common which can be “extended” into a dev and a prod file.
Would it be better to keep docker files in project repositories (as it seems to be currently), or together in a metabrainz-dockerfiles repo? @Rob and @Bitmap agrees that the files should be in the project repositories.
Could we use debian rather than ubuntu as the base image, to reduce image size and have “cleaner” resulting images? @Zas says, “i think using debian as base is better yes, but for some services we can go for alpine”.