Notes from #MetaBrainz Meeting on 2016-06-27

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…

  1. 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.
  2. 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”.
1 Like

The docker "mini " meeting made this one hard to write. Sorry about the delay! :confused: