On 06/26/2014 07:19 PM, Karanbir Singh wrote:
> On 06/26/2014 02:13 PM, Fabian Arrotin wrote:
>> On 26/06/14 14:56, Thomas Oulevey wrote:
>>> Hi All,
>>> The initial idea is to configure Koji and make it available to the
>>> community.
>>> Thanks to Karanbir/Fabian we already got the hardware and
>>> installation is on going.
>>> But first, we would like to ask for feedback:
>>> 1/ PKI setup, a proposal: - koji-web use a certificate signed by an
>>> external CA (and obviously trusted) - the rest of the koji
>>> architecture (hub and kojid) will use a self-signed CA that we'll
>>> use to also generate other certs. The proposal is to gpg encrypt
>>> the CA within a non-public GIT repo. Talking with Fabian, he
>>> already use this method for other infrastructure project. - the
>>> clients (at the beginning git.c.o) will use self-signed CA.
>>> This need to be discussed in the light of future integration of
>>> different user facing tools (koji, git, etc...) and if we want to
>>> provide koji client accesses, as Fedora project does.
>> Well, I'll (obviously) agree with what we discussed previously. But
>> just keep in mind that normally we'll not have a bunch of clients cert
>> to generate, because the normal flow will go like this (if i'm not
>> wrong) :
>> SIGs -> git commit & push -> git.c.o -> hooks -> koji
>> So in that case, all builds will be triggered by Git, and so we don't
>> have to generate client certs for people submitting build jobs in the
>> queue .
> I agree, but users should still be able to run scratch builds and get
> their logs and status / tags etc - so we will need some mechanism for
> those bits to happen, I assumed this would be via the koji clients
> rather than a web interface?
+1, we need a way to do scratch builds for SIGs.
>> That's also worth noting than when we say "community" that doesn't
>> mean that we open buildservice to the wide world (no OBS here :-) ),
>> just that SIGs will build packages on that Koji setup (in a automated way)
>>
>>
>>> 2/ Hostnames to use: - After a round on #centos-devel,
>>> cbs.centos.org was the best we can come up with. Comments ? - For
>>> the builders machine, we should decide on a decent naming as this
>>> info appears in RPM metadata. i.e : builder01.cbs.centos.org,
>>> builder02.cbs.centos.org, etc... Do we want to deal with different
>>> "architecture family" within the name (e.g ARM) ? i.e :
>>> x86-builder01.cbs.centos.org, arm-builder01.cbs.centos.org
>>> Your comments are very welcome!
>>> cheers,
>> I'm fine with the $arch in the fqdn (for logging purposes) so let's say :
>> builder01-x86.cbs.centos.org ? (or the reverse, as you proposed :
>> $arch-builder${num}.cbs.centos.org
> why not drop the word 'builder' completely, x8664-0.cbs.c.o etc
>