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-gXc0ILDDHPyAcAca2GGGlENavfgPwGGgqJ_Y/edit#heading=h.iodoq4xw80c2> >> >> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
