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
UmkaDK
Hmm… give me a sec to process that and I'll get back to you :)
ruaok
however, we should break up the list of files into subdirectories.
yeah, that one is fine.
ok.
oauth on meb! thanks Gentlecat!
works great.
Gentlecat
any chance we could set up jenkins integration for it?
ruaok
for metabrainz?
Gentlecat
yes
ruaok
let's -- but we may need to ask bitmap to do that.
ok, off to UPF. back in a bit
Gentlecat
maybe acousticbrainz too
UmkaDK
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)?
xBytez joined the channel
ruaok joined the channel
xBytez joined the channel
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 joined the channel
Gentlecat
ruaok: they are not in one directory, btw
internal directory structure is the same
ruaok
same as before, so we have all of them scattered in 3 directories?
the hourly one is the one that sucks. :(
Gentlecat
correct
ruaok
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.
Gentlecat
if you have any ideas on how to improve that, feel free to sure
ruaok
so, lets leave it
Gentlecat
ok
ruaok
yeah, not hard. but too many things to do now.
Gentlecat
also, you might want to check chat logs :)
ruaok
k, thanks.
UmkaDK: to clarify... the change I am talking about is the new metabrainz.org site.
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?
UmkaDK
So far so good :)
ruaok
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?
UmkaDK
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?