#metabrainz

But what do I know :p

zas, they will all have things like that, at least they aren't hiding it

zas: all but the downloading platform might get us.

but we still have OSUOSL for the US downloads

ruaok: well, we have to make things clear from start with OVH, because they are used to promise a lot, and often reality is a bit under ;)

reosarevok: when research money gets handed out, everyone in the vicinity holds out their hands and wants money. everything gets really expensive really fast.

zas: yeah, having a higher guarantees might be good then. that will get us what we need.

we should also keep google cloud hosting in mind.

I thin jira could live there.

probably other things. since we have a budget for that stuff.

at the current $45/month rate it is going to take us a long time to use our $10k donation from google. :)

Perhaps we could move discourse to it too

ruaok: they will all promise the earth, I think on the budget side of things (hetzner, online.net, ovh) your experiences are going to be similar with all of them

likely yes.

KodeStar: true, though i think OVH proposes superior technical solutions atm

I just want to avoid the hidden charges that hetnzer seem fond of.

Is this like the Ryanair of hosting?

the vrack alone is a big deal.

reosarevok: starting to look that way.

Exactly.

one server is VERY cheap.

two servers (I want a seat) much more expensive.

if you want to have luggage or go to the loo, eeek!

Easyjet business model ;)

it's been a long long time since I had a hetzner server, so I can't really talk about them, just that every time I look at them they don't seem that appealing, I have had servers with ovh(SYS) for 5-6 years, and online.net for 2-3years

not really, easyjet doesn't do stupid shit like that.

their fees are all printed on the tin.

At 4pm it is time to go back to the airport distillery.

I'm really glad we're having this conversation and I appreciate your input KodeStar

ovh definitely have the more interesting technical solutions at the moment

lol

does CI need to be with the rest or can it go to Google cloud?

I dunno. bitmap ^^

That said, i think it should be possible.

ruaok: i wonder about IP load balancing provided by some NewHost candidates, perhaps this is something we could use to improve scalability of our system, the thing bothering me is the current gateway setup, where all traffic goes through one machine. If we have possibility to load balance IPs we could split traffic over more gateway machines (we already have

HA, it would need to be adjusted a bit to have more machines). I'm not sure how yet, but getting rid of this single point of failure would be great

worth investigating.

OVH allows to load balance per "region", and together with vRack it could be a way to have servers near users

zas, thats always been my issue with load balancing, the fact everything goes through a single machine

whereas with ovh's ip load balancing it doesn't

Hmmm, "The Load Balancing IP will soon be compatible with the vRack." written in small at the end of page

Soon(TM)?

i've only set it up with vps's at the moment zas

and haven't actually used it, was going to test running our 300million requests a month from vp's with a load balancing ip

*vps's

but haven't got round to it, been busy trying to build the new site

does it need vrack support? Surely you can still target the individual machines within the vrack?

question for them though

zas / ruaok, have you considered using proxmox and virtualising some of you infrastructure, you will probably get more efficient use of the servers

I don't kown anything about proxmox yet

But we are using Xen (in fact, not much, because it is getting old)

lxc are a lot more efficient than xen though

you can also create xen containers with proxmox though

iirc

I have 7 lxc containers on my SYS(OVH) server, it has 64GB of RAM, and the API server (receiving 200 - 400 requests a second at peak times), this quassel instance I'm talking from now, api images downloads, the new dev site, the new dev database and the site forums all run off it without any skipping a beat

although I should qualify that, while it runs smoothly I want to move the images off it onto a cheap small dedicated server as it causes unnecessary iowait

what os do you use on the servers?

I prefer small dedicated servers of virutal ones, mostly because hardware failures have much less impact.

Ubuntu 14.04 for now

zas, that is true of course, but you could always have backups, you can also have proxmox clusters, so you can move vms between nodes with no downtime(never tried this myself though)

it uses debian (8 iirc) for the host os, most of my vm's are debian, but I have ubunto 16.04 on the dev vm because of the performance increases php7 provides

chrisskye: we've received 3 payments from customers to the new account so far. very good.

and as predicted the $50k send from our CA account is still nowhere to be seen. it should've arrived today.

it makes me a little twitchy that our net worth is $50k less than it was at the beginning of the week. It isn't in any of our accounts and just sorta in limbo.

yay thpain!

KodeStar: do you have any appreciation for the latency between vrack nodes? compared to a regular switch?

no, I don't have an vrack machines at the moment

*any

that would be my only concern.

app servers need speedy connections to postgres.

if the servers are in the same dc I would imagine latency would be low

might be worth asking them if you could test a couple of servers

is latency more important than speed ruaok?

because the other opion might be something like: https://www.online.net/en/dedicated-server/dedi...

which has 100mbps RPN included in the price

upgrading it to 1gbps costs an extra 35 euro a month

is the only issue with that one

but honestly, I would imagine the ovh vrack would be as low latency as most regular switches

The Cisco ASR 9000 devices serve as a bridge for the vRack. They are at the gateway to each datacentre and linked to each other in order to route the data without passing through the public network. The Nexus 6000s and Nexus 2000s act as network gateways to interconnect your different servers.

the latency better be low between nodes in the same data center. :)

I am more concerned about latency than speed.

the speed is almost certainly going to exceed our needs for the next 2-3 years. I think.

but if there is a 1ms increased latency between nodes, that adds 2ms for each round trip to our DB server.

and devs get kinda pissy when WS requests take more than 50ms

well according to that link

Roubaix => Beauharnois: 40 ms

Gravelines => Strasbourg: 9 ms

40 ms france to canada is pretty good

Oh, btw/ftr/psa: I'm about to leave to perform at another festival thingy tomorrow. I'll back sometime Sunday, hopefully not too late. Got mobile and laptop with me, so I'll be reachable in case of emergency.

ruaok: gindulge yourself

groan.

ruaok: why not reuse the same sign up system?

that is what I was suggesting as one of the possibilities.

it would need more caching because number of requests between the two is vastly different.

not only for getting the replication packets from meb.org

BTW, I think we should distribute all of our data dumps there

including CB, mbspotify, whatever else

I think a common download place makes sense, yes. that would play well into chrisskye's comments from yesterday.

I think it makes sense to have a central place for people to get data

but it would be against our charter to require an access key for everything.

we can choose what requires a key and what doesn't

I don't see why we need it for everything

yeah.

so given the plans that zas and I are making, we'll need to have this code working for the move to the EU

CB dumps aren't updated hourly, for example

though you are saying that MB WS needs to work with that, but I'm not yet sure how that would work reliably and fast

you have to allow for some sloppiness in that.

given the context of the window i was discussing earlier, you could choose to lookup and check the key once per window.

meaning that we could to X requests before checking it again.

that would likely still be a quite a lot.

we could check the validity of a key every n minutes

and then store the "currently" good keys in redis.

so, if you revoke a key, you will still provide service for n minutes.

which is fine, as long as n isn't stupidly long.

and even then they offending key could be removed from redis menually.

meh. weeksio is officially out for gsoc.

that seals it. time to head to the bar.