GitLab Incubation Engineering, 23 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IncEng MLOps Update - 2022-06-23

Description

New data from ServicePing, Consolidation of Jupyter Notebook Diffs, Current Challenges

All Updates: https://gitlab.com/gitlab-org/incubation-engineering/mlops/meta/-/issues/16

A

Hello, everyone and welcome to another update for incubation engineering. Mlaps uh today is june 23rd and we're gonna start talking about usage.

A

um We added service bing data now and which means we will be able to start collecting data from self-managed customers that opt-in for this it would we added in 15.0, so it will take a while until users actually update their installations, uh but it's nice to see that from the data at gitlab.com, uh it matches the data that we had before that we were querying and we see that a lot more users are doing the the the com.

A

The comments, the notes on mrs rather than commits, which is not what we were uh receiving as feedback from self-managed customers, which we're using the commit. So it's gonna be really interesting to see how this data evolves once start once we start receiving data from the from the self-managed ones, but yeah that's pretty good, and we also see uh the on the june uh data that well, it's not complete the last bar over there.

A

The second graph, but growth, like the number of of notes, has not slowed down so, which means that this was not a novelty effect. It was not that we added and then people start just got interested we used once and then ever again, no people keep using this feature, which is pretty cool.

A

Moving on on to consolidation, we currently have a lot of mrs in progress to consolidate this feature and move on to the next uh challenge.

A

One is that we move the library, uh the underlying library that computes uh the dev into gitlab code base itself. uh We did that to make it easier for maintainers later to find the code code review and so on so forth. um We created initially on the thought that it could be used by different parties, but the reality is that it's not gonna be used for by different parties. This is a very uh specialized piece of code and it's better off within gitlab codebase.

A

We did some small improvements to the ux as well, and we are fixing some general bugs across the across the board, and but we do have two quite non-trivial issues that we want to work on before we move on to the to to the next one and which are the file size, one of the biggest complaints or pain points that users uh reach me out to talk about is that they cannot see the bad improved diffs, because notebook diffs are too large.

A

Now we have currently a cap of 500 kilobytes on the patch size and uh since notebook diffs include images, they easily easily explode uh this uh this this limitation.

A

So I'm trying to work away to disable this limit or to increase the cap for diffs, uh specifically for notebooks, because it is a use case that it's a valid one users expect this to happen. It is large. Two books are almost like a directory, so it's not that it it's the same as having seven files and some or a merge request, they're still loaded with th. There are seven files just that here, the seven files are like bundled into one.

A

So this is the thing I'm focusing on right now, getting this uh the file size uh to work or having a large the file size for notebooks and the second one is performance.

A

A lot of the code base that we wrote is in ruby, which, for that use case or parsing large files, it's quite slow, causing timeouts, uh and we want to improve that. We have a good lead of using of moving this code into more offloading distribution to see we have a working uh prototype already and we are benchmarking. The results what's next ml flow when likely starting in july.

A

I want to get done the at least the file size so that we can get more users to use uh notebook divs but yeah. So we we need you to to go with that and that's what I had with today uh see you next time.