well i would say when it comes to maintainance stopping one container will not affect as much services if they are splitted
2017-05-29 14901, 2017
ruaok
iliekcomputers finished production side of things, but got stuck with the dev side of things.
2017-05-29 14911, 2017
jesus2099 has quit
2017-05-29 14916, 2017
zas
ok, so it is a problem with that
2017-05-29 14926, 2017
ruaok
since it is unrealistic to have subdomains for dev work
2017-05-29 14942, 2017
zas
if you feel it is too complex on this side, i guess not much choice left ;)
2017-05-29 14931, 2017
ruaok
complexity now on our side is better than a production nightmare.
2017-05-29 14910, 2017
zas
well, it means we'll need to add more complex stuff on gateways, but ok
2017-05-29 14922, 2017
ruaok
doesn't MB already do this?
2017-05-29 14932, 2017
ruaok
since everything there runs on on domain, no?
2017-05-29 14940, 2017
alastairp
hmm, sorry to interrupt here
2017-05-29 14947, 2017
alastairp
perhaps we decided to not do different things
2017-05-29 14948, 2017
zas
yes it does, and it isn't very clean, according to current nginx config ;)
2017-05-29 14906, 2017
ruaok
I envisioned using mm.musicbrainz.org for this, but was never used and became a point of contention.
2017-05-29 14909, 2017
alastairp
was our decision to not have separate flask apps
2017-05-29 14916, 2017
alastairp
or to not have a separate domain for the api?
2017-05-29 14941, 2017
ruaok
I want neither, but not if it is going to sabotage production.
2017-05-29 14946, 2017
alastairp
right
2017-05-29 14955, 2017
alastairp
I agree we don't need separate flask apps
2017-05-29 14922, 2017
alastairp
I'm ambivalent about the domain, but I recall it caused this much discussion when we decided to do it in the first place
2017-05-29 14936, 2017
alastairp
I'm happy to rely on your past experience with it not working out
2017-05-29 14945, 2017
ruaok
lets turn this around: zas: ideally from your perspective what should we do?
2017-05-29 14958, 2017
ruaok
there is a decent change that LB will get a lot of traffic before long.
2017-05-29 14945, 2017
zas
according to mb ws vs website stuff, about stats/configuration/upgrades/general maintenance i think it is preferrable to split apps (because they are different by nature)
2017-05-29 14908, 2017
ruaok
please elaborate on "split".
2017-05-29 14909, 2017
zas
also it makes it easier to control access or move to api frontends like kong
2017-05-29 14914, 2017
ruaok
containers, flask apps, domains?
2017-05-29 14939, 2017
zas
i think a domain + its backends
2017-05-29 14904, 2017
alastairp
however it is technically possible to redirect a url -> different backends?
2017-05-29 14929, 2017
ruaok
zas: can you please be more explicit? specifically tell us how many domains, flask apps and containers you'd ideally like to see.
2017-05-29 14926, 2017
zas
one domain for website, one domain for api, website = as much containers needed in the backend, api = as much containers needed in the backend
2017-05-29 14928, 2017
ruaok
so you don't care if the containers in the backend are actually different between web and WS?
2017-05-29 14931, 2017
zas
basically what we have for mb, apart the subdomain (which is a mess if you ask me, requiring much more complex nginx config, for nothing), and requires common certs
2017-05-29 14943, 2017
ruaok
we could just use one image for both and create instances as needed.
2017-05-29 14958, 2017
zas
ruaok: you can point 2 domains to the same container, if the container is able to manage it
2017-05-29 14920, 2017
ruaok
its all one codebase and it would be more work to create separate images.
2017-05-29 14921, 2017
zas
or you may use the same image with a different config
2017-05-29 14949, 2017
zas
or you can use a common base image and 2 child images
2017-05-29 14905, 2017
ruaok
same image is easiest.
2017-05-29 14923, 2017
ruaok
ok, what I am understanding, and I think alastairp, is already there:
2017-05-29 14923, 2017
zas
same image -> multiple containers then ?
2017-05-29 14930, 2017
alastairp
yes, I think we would always be running with the same image, even if we had kept iliekcomputers' PR
and we run multiple instances of that container, and point 2 domains to as many instances as are required for each domain (frontend or api)
2017-05-29 14903, 2017
ruaok
2. have 1 image for both, whether or not we have 1 or 2 instances is docker-server-config tweak
2017-05-29 14925, 2017
ruaok
3. If we need to grow, we can have more containers and easily split traffic based on domain.
2017-05-29 14933, 2017
zas
yup^^
2017-05-29 14936, 2017
alastairp
I am in agreement with 1. and 2. and 3. <- trying to be super explicit here
2017-05-29 14904, 2017
ruaok
ok, I see us not using more than 1 image at start, but that doesn't really matter.
2017-05-29 14923, 2017
alastairp
just to be super picky (and for now I don't care): it's technically possible for someone to submit listens to lb.org, or browse the website on api.lb.org
2017-05-29 14929, 2017
alastairp
unless we filter at the nginx level
2017-05-29 14930, 2017
ruaok
then we need to figure out how to deal with the sub-domain in the dev env.
2017-05-29 14905, 2017
ruaok
alastairp: we should disallow this and filter that case. otherwise when we make the switch internally some clients will break.
