On 2/1/19 4:06 AM, Mikolaj Izdebski wrote:
...snip...
>> Separate Koji + Koschei deployed in Fedora infrastructure
cloud;
>
> Turns out we are going to be retiring our cloud, so no, this is not a
> place to put it. :)
Cloud doesn't necessarily mean OpenStack. There are other options. For
example, a baremetal, out-of-warranty virthost in an isolated network
would work - better that OpenStack.
Well, I was responsing to "Fedora Infrastructure cloud" which completely
does mean openstack. ;) But yes, as I mentioned we can come up with
other options if it's desired.
...snip...
Koji builders can be added and removed dynamically very easily.
Adding
a builder in public cloud is as easy as spawning some VM, installing
koji-builder, putting config file in place and starting kojid - of
course automated using Ansible. Removing a builder only requires
terminating the VM, nothing more. Adding a builder that is installed
on your laptop is as easy as booting up the VM containing in, that's
it.
Sure, except they exist in the database by that name forever.
>> Possibility to have some builders running outsides of
Fedora
>> infrastructure - contributed by proposal owners
>
> I'd be carefull of this, as it can cause a lot of issues, but of course
> up to you as you are doing the work. :)
The idea was to have just a few builders (eg. 3) running constantly.
If someone wants to do massive amounts of builds (and have them
complete quickly) then they can plug in their own hardware or
instances in public cloud that they would pay for, which would be
added to a separate Koji channel. Then their builds would use their
builders. Builders have very low requirements - in particular they
don't need public IP, can be behind firewall/NAT and only need to talk
to hub over https. Even someone's personal laptop could be used as a
builder.
Sure, note there would be some setup here for you... adding channel,
keytabs or certs for builders, etc.
>> Koji builds can be done from SCM (src.fp.o, pagure.io,
github, …) or
>> from SRPM upload
>
> Ah, so it would not have it's own git/pagure?
No. Builds would be allowed from any configured SCM - it could be from
forks on
src.fedoraproject.org, from repositories on pagure.io,
repositories on other git hosting services. It's up to people using
the system to choose the workflow that suits them best. They could
even build from SRPM uploads.
>> It is not official build system of Fedora which is not helping with Problem
>> №2: Testing of new rpm/koji/mock features/configuration
>>
<
https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...
>
> Note that if you also are testing new things you could break packagers
> that are trying to do other work...
Testing new features would be done in separate tags. So no, others
would not be affected.
I'm not sure how you could test a new koji hub or rpm on the hub with
tags, but sure, you could test some things by having different builders.
>> By building only on a single, fast architecture.
>
> This may well bite you when you merge back to koji and build for all
> arches.
I don't see this as a problem.Most of the packages that we are
planning to build in MBI (Java/Rust/Go) are noarch anyway.
ok. Unless some other folks start using it.
> Overall sounds very nice... we will have to work out details if
everyone
> is on board with it. Do note that it's going to be a lot of work for you
> all... :)
Actually there's not that much work. Most of the work is already done.
great.
I've developed and I'm running MBI setup myself in AWS, using
my
personal account. Others liked this workflow and asked whether they
could use it. I kindly refused as I can't pay for all that myself.
Then we come up with a proposal to have this hosted by Fedora.
Sure, makes sense.
Thanks for the answers!
kevin