dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Stone <daniel@fooishbar.org>
To: Matt Turner <mattst88@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	"X.Org development" <xorg-devel@lists.x.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	wayland <wayland-devel@lists.freedesktop.org>,
	"X.Org Foundation Board" <board@foundation.x.org>,
	Xorg Members List <members@x.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	Mesa Dev <mesa-dev@lists.freedesktop.org>,
	gstreamer-devel@lists.freedesktop.org
Subject: Re: gitlab.fd.o financial situation and impact on services
Date: Fri, 28 Feb 2020 07:59:33 +0000	[thread overview]
Message-ID: <CAPj87rOhwLPGHaHvPrZ6j8zufO8VqiwNFoBGFjx95yHr3cBm3Q@mail.gmail.com> (raw)
In-Reply-To: <CAEdQ38Hr-L6rg80Gf18QNM7eK-QDK0BBU-9tChT6VxrP+T4qCw@mail.gmail.com>

Hi Matt,

On Thu, 27 Feb 2020 at 23:45, Matt Turner <mattst88@gmail.com> wrote:
> We're paying 75K USD for the bandwidth to transfer data from the
> GitLab cloud instance. i.e., for viewing the https site, for
> cloning/updating git repos, and for downloading CI artifacts/images to
> the testing machines (AFAIU).

I believe that in January, we had $2082 of network cost (almost
entirely egress; ingress is basically free) and $1750 of cloud-storage
cost (almost all of which was download). That's based on 16TB of
cloud-storage (CI artifacts, container images, file uploads, Git LFS)
egress and 17.9TB of other egress (the web service itself, repo
activity). Projecting that out gives us roughly $45k of network
activity alone, so it looks like this figure is based on a projected
increase of ~50%.

The actual compute capacity is closer to $1150/month.

> I was not aware that we were being charged for anything wrt GitLab
> hosting yet (and neither was anyone on my team at Intel that I've
> asked). This... kind of needs to be communicated.
>
> A consistent concern put forth when we were discussing switching to
> GitLab and building CI was... how do we pay for it. It felt like that
> concern was always handwaved away. I heard many times that if we
> needed more runners that we could just ask Google to spin up a few
> more. If we needed testing machines they'd be donated. No one
> mentioned that all the while we were paying for bandwidth... Perhaps
> people building the CI would make different decisions about its
> structure if they knew it was going to wipe out the bank account.

The original answer is that GitLab themselves offered to sponsor
enough credit on Google Cloud to get us started. They used GCP
themselves so they could assist us (me) in getting bootstrapped, which
was invaluable. After that, Google's open-source program office
offered to sponsor us for $30k/year, which was I believe last April.
Since then the service usage has increased roughly by a factor of 10,
so our 12-month sponsorship is no longer enough to cover 12 months.

> What percentage of the bandwidth is consumed by transferring CI
> images, etc? Wouldn't 75K USD would be enough to buy all the testing
> machines we need and host them within Google or wherever so we don't
> need to pay for huge amounts of bandwidth?

Unless the Google Cloud Platform starts offering DragonBoards, it
wouldn't reduce our bandwidth usage as the corporate network is
treated separately for egress.

Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-02-28  8:00 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27 21:27 gitlab.fd.o financial situation and impact on services Daniel Vetter
2020-02-27 23:45 ` Matt Turner
2020-02-28  7:59   ` Daniel Stone [this message]
2020-02-28 10:09     ` Jan Engelhardt
2020-02-28 11:11       ` Daniel Stone
2020-02-28 21:20     ` Matt Turner
2020-02-28  0:21 ` Luc Verhaegen
2020-02-28  0:33 ` Carsten Haitzler
2020-02-28  1:00 ` [Mesa-dev] " Tom Stellard
2020-02-28  1:08   ` Tom Stellard
2020-02-28  3:37 ` [Intel-gfx] " Dave Airlie
2020-02-28  7:44   ` Daniel Vetter
2020-02-28  8:17   ` Daniel Stone
2020-02-28  8:48     ` Dave Airlie
2020-02-28  9:26       ` Daniel Stone
2020-02-28 19:34       ` [Mesa-dev] " Eric Anholt
2020-02-28 20:30         ` Dave Airlie
2020-02-28 21:22           ` Daniel Vetter
2020-02-28 21:37             ` Nuritzi Sanchez
2020-04-04 13:55         ` Andreas Bergmeier
2020-04-05 14:07           ` Nicolas Dufresne
2020-02-28  9:28   ` Erik Faye-Lund
2020-02-28  9:40     ` Lionel Landwerlin
2020-02-28 10:06       ` Erik Faye-Lund
2020-02-28 10:43         ` Daniel Stone
2020-02-28 11:02           ` Erik Faye-Lund
2020-02-28 11:46             ` Michel Dänzer
2020-02-28 13:08               ` Lionel Landwerlin
2020-02-29 18:14           ` Timur Kristóf
2020-02-29 19:46             ` Nicolas Dufresne
2020-02-29 20:28               ` Timur Kristóf
2020-02-29 21:54                 ` Jason Ekstrand
2020-02-29 22:20                   ` Nicolas Dufresne
2020-03-01  5:46                     ` Marek Olšák
2020-04-03 14:12                       ` Michel Dänzer
2020-04-04 15:11                         ` Rob Clark
2020-04-04 17:47                           ` Nicolas Dufresne
2020-04-04 18:16                             ` Rob Clark
2020-04-04 18:41                               ` Rob Clark
2020-04-04 18:47                                 ` Rob Clark
2020-04-04 23:39                               ` Peter Hutterer
2020-04-04 23:32                           ` Peter Hutterer
2020-04-06 15:42                           ` Adam Jackson
2020-04-06 16:34                             ` Rob Clark
2020-04-06 17:04                               ` Michel Dänzer
2020-04-06 18:00                                 ` Rob Clark
2020-03-01 14:14               ` [Mesa-dev] [Intel-gfx] " Michel Dänzer
2020-03-01 14:27                 ` Nicolas Dufresne
2020-03-01 19:51                   ` Jacob Lifshay
2020-03-01 20:18                     ` [Intel-gfx] [Mesa-dev] " Jason Ekstrand
2020-03-01 20:30                       ` Bridgman, John
2020-03-01 20:49                       ` Nicolas Dufresne
2020-03-02  4:53                         ` Jason Ekstrand
2020-02-28  9:47     ` [Mesa-dev] [Intel-gfx] " Daniel Vetter
2020-02-28 10:10       ` Erik Faye-Lund
2020-02-28 10:27       ` Lucas Stach
2020-02-28 11:43     ` Michel Dänzer
2020-02-28 17:00       ` [Intel-gfx] [Mesa-dev] " Rob Clark
2020-02-29 15:58         ` Jason Ekstrand
2020-02-28 18:03   ` [Intel-gfx] " Kristian Høgsberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPj87rOhwLPGHaHvPrZ6j8zufO8VqiwNFoBGFjx95yHr3cBm3Q@mail.gmail.com \
    --to=daniel@fooishbar.org \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=board@foundation.x.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gstreamer-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mattst88@gmail.com \
    --cc=members@x.org \
    --cc=mesa-dev@lists.freedesktop.org \
    --cc=wayland-devel@lists.freedesktop.org \
    --cc=xorg-devel@lists.x.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).