#musicbrainz-devel

Gentlecat, when you're back, it's changed

and yeah, it's redirecting rather than 200ing looks like,

ianmcorvidae: thanks

not sure why it's redirecting though, I changed it to 200 as you suggested

and it does the same with code before that change

hm. guess that suggests it's not finding the internal thing properly

header looks correct

X-Accel-Redirect: /internal/replication/replication-50010.tar.bz2

okay, changed it and I think it's working now

changed it to location ^~ /internal/replication

oh, right

because before it didn't match the whole URI

since it was *~ ^/internal/replication rather than something like *~ ^/internal/replication/.*

but using ^~ is better anyway

huh, good to know

yeah; the musicbrainz one matches the entire thing, since it includes some (.*?) and (.*) stuff to pull parameters out

without ^~ would probably also work but that results in it not searching regular expressions which hey, may as well

alright, works great now

didn't even know something like that was possible, that's kind of cool

Gentlecat: I'll have a look at the those PRs in a bit -- those look like awesome improvements!

ok, great

ruaok: new table creation happened at /some time/ over night

it's done, so who cares how long it took

would've been good to know how long to learn for the next time we do this.

yeah

although, after discussion with dima we need to restrict that table even more

so I'm going to join to a table

the table is now the largest subset we have to evaluate, but we also have a smaller subset to evaluate

then come schema change day, when we're all done, we can remove that.

like this one http://www.animatedgif.net/underconstruction/an...

LOL. yes. :)

ok, will add something

Gentlecat: another thing you could start on... the deployment of the new site onto sakura.

just mirror the setup that we have fo CB -- for uwsgi and directories and all that.

for now we can tunnel to the new site. once we're happy enough, we can flip the switch and make the new site live.

UmkaDK: ping

Hey! :)

hey.

so, I trust you know about the upcoming metabrainz site, right?

and changes to the replication feed and all that?

Sure! :) Thanks ruaok!!

ruaok: should I do that https://github.com/metabrainz/metabrainz.org/pu...

so, I'm working to heed Sara's request (and who wouldn't right?) so that you guys can test the site beforehand.

my question to you UmkaDK, is this: If we make the site available under a different domain name that you would have to add a /etc/hosts entry to, would that allow you to test the new setup?

*for

Hmm… give me a sec to process that and I'll get back to you :)

however, we should break up the list of files into subdirectories.

yeah, that one is fine.

ok.

oauth on meb! thanks Gentlecat!

works great.

any chance we could set up jenkins integration for it?

for metabrainz?

yes

let's -- but we may need to ask bitmap to do that.

ok, off to UPF. back in a bit

maybe acousticbrainz too

ruaok: Milled it over in my head and now have a couple of questions for you… First of all, what site are we talking about? Is it the one that manages the replication keys, the one that stores the replication packets, or are we talking about the one that hosts ALL of the MB endpoints (as the first commit in that ticket seem to imply)?

If it's the site that requires a one off access to generate a replication key, which we then use in the rest of the app, then sure. I can update my local environment, add a new record into /etc/host/, fetch the replication key and update our local version of the codebase, and then propagate the change to the test server.

However, I highly doubt it if the operations team would allow us to update /etc/hosts on the test server. So if it's a change that requires an addition of the new hosts record in order for MB to function all together, then it become a lot more problematic.

And if it's a change to all of the APIs then … [\me shudders] … all the clients would have to be updated, we would not be able to fail over on your master during our upgrade (I don't even want to think of what else might popup).

ruaok: they are not in one directory, btw

internal directory structure is the same

same as before, so we have all of them scattered in 3 directories?

the hourly one is the one that sucks. :(

correct

if we could break them up that would be better, but I guess we don't have to do that right this second.

since we're now serving them and not providing direct access this is something we can improve on later.

if you have any ideas on how to improve that, feel free to sure

so, lets leave it

ok

yeah, not hard. but too many things to do now.

also, you might want to check chat logs :)

k, thanks.

UmkaDK: to clarify... the change I am talking about is the new metabrainz.org site.

which you can see at metabrainz.mbsandbox.org

that site serves two functions: allow customers to log in, setup their account and then generate an access token.

that access token must then be installed into their musicbrainz-server setup for the replication to continue working.

once we put the new test site live, we will be putting the replication packets there as well as where they are now.

after the schema change release, we will stop putting them to the FTP server and they will only be available via the new site.

with me so far?

So far so good :)

good.

so, the new site isn't quite ready for the whole world to come look at it. our existing customers, sure.

so, we'd like to make the site available under something like test.metabrainz.org

and on schema change day, that same site would move to metabrainz.org

that is what we would *love* to do.

question is, can you and your team deal with this?

So in order to test the new replication packets before the new site is released as metabrainz.org we'd need to get the access token from metabrainz.mbsandbox.org and update the replication script to pull packets from test.metabrainz.org (for example). Right?

almost.

you would never interaction wtih metabrainz.mbsandbox.org.

only test.musicbrainz.org

Ok, so why would have to edit /etc/hosts??

but yes. then on change day, you'd need to change that URL to remove the "test."

UmkaDK: well, you have a choice.

edit the URL in your configs or edit he /etc/hosts.

+t

either will have the same effect in the end.

Ohh!! LOL! I see what you are talking about…

As far as I know there should be no blockers in doing it the way you described

ok, can you please confirm that?

and if so, then I will send an "official" email to Sara

k

ruaok: I hereby officially confirm! :)

fabu. thanks.

and thanks for being awesome to work with, btw. I wish more of our customers would hang out here. :)

no problems! :) Thanks for giving me a shout about it!

I love being able to work with other geeks, without suits inbetween.

LOL! :)

Yee, certainly makes the job easier!

though, I haven't interacted with a BBC suite in a while. I loves me some njh and sara_sgm. :)

:D

ok, going to attempt to cut the site over to the new gateway.

hold on to your hats!

ruaok: https://github.com/metabrainz/metabrainz.org/pu... good enough?

hang on a bit

that is lovely.

especially since the cut-ver seemed to work!!!

*over

Mineo: ping

Gentlecat: how do you log into rika?

pong

can you log into rika, please?

and let me know if you can get in.

I just logged in