MetaBrainz Meeting 2016-06-27
Meeting start: IRC Logs for #metabrainz | MetaBrainz Chatlogs
Agenda
- Reviews
- Old FreeDB VM at OSUOSL
- JIRA upgrade status?
- Docker-mini meeting
Reviews
@Freso
IRC Logs for #metabrainz | MetaBrainz Chatlogs
@reosarevok
IRC Logs for #metabrainz | MetaBrainz Chatlogs
@bitmap
@Gentlecat
@Rob
IRC Logs for #metabrainz | MetaBrainz Chatlogs
@chrisskye
IRC Logs for #metabrainz | MetaBrainz Chatlogs
@LordSputnik
IRC Logs for #metabrainz | MetaBrainz Chatlogs
@alastairp
IRC Logs for #metabrainz | MetaBrainz Chatlogs
@zas
IRC Logs for #metabrainz | MetaBrainz Chatlogs
@rahulr
IRC Logs for #metabrainz | MetaBrainz Chatlogs
@Quora
IRC Logs for #metabrainz | MetaBrainz Chatlogs
@armalcolite
IRC Logs for #metabrainz | MetaBrainz Chatlogs
@hellska
IRC Logs for #metabrainz | MetaBrainz Chatlogs
@kartikgupta0909
IRC Logs for #metabrainz | MetaBrainz Chatlogs
Old FreeDB VM at OSUOSL
IRC Logs for #metabrainz | MetaBrainz Chatlogs
@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.
JIRA upgrade status?
IRC Logs for #metabrainz | MetaBrainz Chatlogs
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.
Docker mini meeting
IRC Logs for #metabrainz | MetaBrainz Chatlogs
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.
next up
@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.
dev/deployment
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.
@LordSputnik asks…
- 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”.