Internal hosting for Jenkins for short-term [RFC]

[Itamar Heim]

On 05/07/2012 11:18 PM, Karsten 'quaid' Wade wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/23/2012 11:33 PM, Itamar Heim wrote:
>
>>> my view is until we can resolve how to do this over publicly
>>> accessible community resources via some hosting provider, private
>>> CI is better to no CI.
>
> Itamar and I have been having some progress internally on getting
> hosts that may be able to be exposed externally so we can have shared
> community infrastructure.
>
> Based on that and the immediate need, I'd like us to start allowing
> Itamar's team to use whatever they have internally to support
> development, with these understandings:
>
> * Publish all results ASAP publicly, as per usual.

the idea is any such server will be a jenkins slave, so the results are 
part of public jenkins.

> * Move the workloads externally ASAP when we can.
> * Look for the future of how we want to handle enabling Jenkins
> servers to be used on internal networks so oVirt members can use more
> readily available internal hosts for infrastructure that doesn't
> require or benefit from an open collaboration.

actually, that's one of the things we are looking at right now - 
allowing usage of servers as slaves without community access, where the 
slaves will run the batch.
we are looking at this assuming this will be easier for most to 
contribute, rather than remote/external/accessible hosts.
we are looking at a solution with community access as well - we may need 
to mix both due to space/connectivity and other constraints.

>
> Basically, it makes sense to me that if we have a standard set of
> workloads that can be run on any instance, there is no reason anyone
> can't commit to doing that on infrastructure they run themselves. That
> is different from the actual participation components that should be
> run entirely externally. The project needs to have 100% r/w access to
> all of the online components that make up the project, but that
> doesn't have to include CI servers running a standard workload on an
> open source stack.

as stated above - we are looking at this as well.