Hi,

I've added devuan-dev back as the main recipient and inlined the
top-posted reply as I saw fit.

Boian Bonev via Dng <dng@???> writes:

> Hi,
>
> On Mon, 2022-10-10 at 12:36 +1100, Ralph Ronnquist wrote:
>
>> Hi Olaf,
>>
>> On Sun, Oct 09, 2022 at 04:02:21PM +0900, Olaf Meeuwissen via Dng
>> wrote:
>>
>>> Hi,
>>>
>>> Some five years ago I started a little project on GitLab.com to
>>> build Devuan Docker images.  Images were built and pushed to the
>>> project's registry by CI/CD on a monthly schedule.  Until
>>> 2021-07-03, that is, when a change to GitLab's shared runners broke
>>> the build.
>>>
>>> The project is at https://gitlab.com/paddy-hack/devuan.
>>
>> I would guess you are aware of git.devuan.org and have your reason(s)
>> for having opted for other choices, but if not, "git.devuan.org" is
>> (also) an alternative as a publicly available software repository.
>
> That would be perfect for the scripts and files used to build the
> images.

Indeed, it is.

The reason for my project living life at GitLab.com is that when I
started it Devuan was still getting things set up (or was debating
whether to replace its GitLab instance with Gitea). By the time that
dust settled, my project was building images on auto-pilot and I never
bothered to move things elsewhere. Until now.

I had an account on Devuan's GitLab instance. I've created an account
on the Gitea instance a few days ago and have been looking around. What
I miss though is CI/CD integration. I know Devuan has a Jenkins server
and am curious how to get CI/CD going for projects.

# Not really enthousiastic about using Jenkins though. Bad experience
# trying to upgrade a Jenkins server courtesy of plugin dependency hell
# a long time ago is to blame for that.

>>> There were regular images for all of jessie, ascii, beowulf,
>>> chimaera and ceres as well as slim, builder and helper variants. 
>>> Together they gobbled up some 30GiB in disk space in my personal
>>> project space.
>>
>> Though I'm not sure it (a git store web gui) is a good place for
>> publishing releases of anything given it's page rendering
>> limitations, and perhaps you would want something different for that.

Looking at the Gitea Package Registry[1], Devuan could add that (for
some kinds of "packages", after upgrading to 1.17?) but seeing the
bandwidth limitations that Boian mentioned a bit below that might not
be advisable.

[1]: https://docs.gitea.io/en-us/packages/overview/

> I do not understand the process of building Docker images at all.

That's OK ;-) We can't all be understanding everything. Just leave it
to others who do understand the process. I think I've got a fair handle
on it.

> But it would be best for the downloadable product to be mirrored - it
> shouldn't be a problem to run the image build process on the Devuan's
> infra, but distributing them is best done via the mirror network. To
> explain the reasons - bandwidth on the infra is limited. It is enough
> for timely distribution to the mirrors, but not for direct user
> downloads, especially in case the user base grows.

I guess Boian is refering to the mirrors listed at

https://www.devuan.org/get-devuan

While that might work, that suggestion got me thinking about ways to
push container images to one or more of the BIG registries (Docker Hub,
ghcr.io and quay.io, off the top of my head) and have Devuan users
consume them from there.

>>> Now GitLab.com is making changes to their Free Tier offering, which
>>> is what I'm using, and one of those is a 5GiB storage limit on
>>> personal (and other top-level) namespaces.  This change will come
>>> into effect on or after 2022-10-19.  Nothing will be removed but
>>> one will not be able to write any new data past that cap.  That is,
>>> as soon as the limit is enforced I can no longer use my personal
>>> GitLab.com namespace.
>>>
>>> [...]

> From Olaf's post, I get that the biggest problem is the space
> requirement.

As far as my GitLab.com hosted registry, yes. Free Tier top-level
namespaces like mine only get 5GB to play in. My registries kept *all*
images that were ever built so it slowly ballooned to 30GB. I'm not
sure keeping these historic images is worth the resources, though.

>>> I could purchase additional 10GiB storage chunks at USD60/year but
>>> if I had that kind of money to burn, I think donating it to Devuan
>>> would be a much better investment.

In case it wasn't clear, that would work out to USD180/year to start
with and increase over time (unless some policy is enforced to prune
very old images and free up space).

>>> I could also apply for an Open Source Program (and re-apply every
>>> year) to try and get an Ultimate license which comes with 250GB of
>>> storage (and 500GB transfer/month).  However, I think it might be a
>>> better idea to move the images to the Devuan project and its
>>> infrastructure.
>>>
>>> That is, if they are still wanted/needed in the first place.  If
>>> so, I am willing to help with any migration and volunteer for their
>>> continued maintenance.  I guess adding daedalus and excalibur would
>>> be one of the first things to do after migrating.  A policy
>>> regarding the keeping of historic builds might also need some
>>> discussion.
>>>
>>> # Or maybe Devuan could be added to the Docker Official Images...

I have now created an, as of yet empty, project[2]. Seeing that there
have been no new images since 2021-07-03, I figured I would start from
scratch (with half an eye on what I've got on GitLab.com of course! and
another half eye on what is going on with the Official Debian image) and
look for creative solutions around storage and band-width limitations
while at the same time getting images out to at least one of the BIG
container registries.

[2]: https://git.devuan.org/paddy-hack/container-images

Oops! I guess I just got myself sucked into volunteering for Devuan ;-)

>>> Anyway, I need to do something about my GitLab.com storage
>>> consumption (and not only for the devuan images!) soonish so I've
>>> moved all the images that were on GitLab.com to a localhost
>>> registry just in case.

Good thing I did that! The GitLab.com container registry expiry policy
implementation is seriously broken[3].

[3]: https://gitlab.com/gitlab-org/gitlab/-/issues/377417

I restored the images that should have been kept from my localhost
registry and cleaned out the GitLab.com one manually.

BTW, I'm within the 5GB limit now according to GitLab.com but I still
see storage usage numbers that look fishy. Anyway, that's another story
so back to Devuan Docker container images.

>>> Only a few of these images are still available via GitLab.com, for
>>> the time being, and mostly not to break the daily dyne/devuan builds
>>> ;-)

Only the codename tagged images remain. The daily dyne/devuan image
build should be green again after I fixed up the clean up policy mess
last night (UTC+0900).

> Olaf, is there something else, that I miss?

Nope, don't think so.

> Is there something special about hosting a Docker repo?

I guess it's easiest to just point you to Docker's documentation[4] on
the subject. Personally, I only have experience setting up a localhost
instance and deploying one on Kubernetes to integrate with a self-hosted
GitLab CE instance at the office. For the latter, GitLab handles the
authentication/authorization and it uses Min.IO to provision storage (if
I remember correctly).

[4]: https://docs.docker.com/registry/deploying/

Hope this helps,
--
Olaf Meeuwissen