On Tue, Apr 30, 2019 at 9:27 AM Sebastian Wagner
<sebastian.wagner(a)suse.com> wrote:
Hi Alfredo,
Am 30.04.19 um 15:00 schrieb Alfredo Deza:
> On Tue, Apr 30, 2019 at 8:52 AM Sebastian Wagner
> <sebastian.wagner(a)suse.com> wrote:
>>
>> All,
>>
>> I've been working on exercising some Rook orchestrator commands in an
>> automated fashion (like deploying Ceph services). The concept itself
>> works pretty well and now I'd like to integrate this into Sepia.
>>
>> A part of this endeavor was to set up an empty Kubernetes cluster using
>> local VMs and Terraform. As Sepia already runs a k8s cluster, it might
>> make sense to just use this existing cluster, instead of creating a new
>> cluster for every test run. One downside of re-using existing clusters
>> is: Only one Test run can access a given cluster at a time and thus
>> eliminating some possible parallelism.
>>
>> There is another bummer: As far as I know, we're not building Ceph
>> container images for Ceph PRs and
https://hub.docker.com/r/ceph/ceph
>> only contains stable Nautilus images. Testing Ceph images automatically
>> after they're released to the public isn't going to fly.
>>
>> Are there any plans to build Ceph container images in Shaman or from
>> within Jenkins Jobs?
>
> This has been discussed in the past
> , but it is a tremendous effort
> which has many moving pieces.
Indeed, it is.
On the other hand, if we want to make container first-class citizens, is
not building them really a viable option?
I agree with you here, we should be building containers, regardless of
how many repositories we produce a day
> One of them is where to store the
> container images - I don't think it is OK to push
> to
hub.docker.com since we build about 400 repositories per day.
Actually this would be a perfect use case for a private registry.
I agree again here. Would love to see if it there was a
community-based effort for a registry so we could push images. As it
stands right now, our very small team can't possibly
take on running/maintaining another service, much less provide for the
tremendous amount of infrastructure needed.
Out of my head, I could think of two alternatives that don't require any
new services:
1. Maybe Docker hub could build a nightly image from latest master
This wouldn't give us tests for PRs, though.
2. Or alternatively, Jenkins could build images locally without pushing
them anywhere. (I'm not a big fan of this, as it would require a
temporary private container registry while executing the test.)