jupyterhub / team-compass

A repository for team interaction, syncing, and handling meeting notes across the JupyterHub ecosystem.
http://jupyterhub-team-compass.readthedocs.io
62 stars 33 forks source link

Billing for Binder showcase at NeurIPS2018 #81

Closed betatim closed 5 years ago

betatim commented 5 years ago

Can we have a quick show of opposition (if you support this show it with a 👍 reaction on this post) for using up to $2000 for the mybinder.org showcase at NIPS and charge it to the mybinder.org billing account?

Why $2000? It seems like a absolute upper limit would be $4000 based on some rough guesswork. So I took that and divided it by two because why not.

choldgraf commented 5 years ago

I'm +1 on this, though we should be careful we don't accidentally add a "0" in there somewhere :-)

cc @yuvipanda who had some thoughts yesterday on costs for fancy things like GPUs

jzf2101 commented 5 years ago

@fperez is that an number that works with you?

IMHO, I think it would be ok to set a user limit or to create a simple authenticator to keep costs down?

betatim commented 5 years ago

I'd set a maximum number of users with a friendly error message and not use auto scaling so that it takes a human to resize the size of the cluster (spend more money).

jzf2101 commented 5 years ago

Works for me. Does the $40 come from the cost of launching a binder or running a binder?

betatim commented 5 years ago

What do you mean with launching vs running a binder?

The cost comes from using the Google cloud cost estimator

Some cost estimates from the calculator (assuming the instance will be live for 72h). If per user we provide the equivalent of: n1-standard-2 (2vCPU, 7.5GB RAM), 1 NVIDIA TESLA K80 to each user/pod that will cost $40.

Having one Binder running for 72h will cost us $40 if we assign it the resources written above. If we have 200 running for 72h we will spend 200*40. With a budget of $2000 we can run 50 concurrent instances for 72h. My guess would be that at night there will be less instances running so we can peak higher than 50. As long as on average we don't go above 50.

jzf2101 commented 5 years ago

Ok so we mean running the binder. Given the fact that no one can rerun an entire experiment during the demo (it's only a few hours) maybe we should just have them there and then pause it at the end of the demo? We have a second demo at the end of the week we could open it up for again.

This would allow us to have a few more instances available.

choldgraf commented 5 years ago

@jzf2101 what's the environment going to be like for this session? Are people just milling around and occasionally stopping at our demo? Or is there a moment like "everybody now pay attention to the Binder demo"?

jzf2101 commented 5 years ago

people just milling around and occasionally stopping at our demo

This one ^

Also we're likely limited by the number of monitors.

betatim commented 5 years ago

Can we pick demo repos that complete in a few minutes? I'd even go as far as making a demo-demo repo that completes in seconds. Use that as a prop during any demos where people are actually standing there listening/watching.

Then let them leave and give them a link to a repo that takes minutes to rerun that they can try "at home" (during the conference).

I would not bother to try and get something working for this that takes anywhere close to a real amount of training time. It is a demo after all and there are lots of things competing for people's interest. IMHO people will understand that "GPUs and BinderHub, it works!" and can extrapolate to having something that runs for days (or realise that it would take some extra infrastructure to do that).

jzf2101 commented 5 years ago

Yeah I can think about runtime and figure out which ones would make the most sense.