Sounds very good to me. Let's do this and find solutions for problems as we go. If bandwidth is an issue, Cloudflare CDN might be worth checking out for the packages.
Timo > On 2. Aug 2017, at 14:33, Ewoud Kohl van Wijngaarden > <ew...@kohlvanwijngaarden.nl> wrote: > > Hello all, > > As many of you know we have some overlapping work between Foreman and > Katello. This is an effort to reduce some of this. This is only focussing on > git repositories but once this is in place this should be easier. It's all > proposals and we will need to work out details. > > One might notice that much of this has been talked about before but never > reached a conclusion, which is something we tend to do a lot. Let's break the > cycle and make some decisions. > > # foreman-bats -> forklift merge > > Currently we have foreman-bats[1] and forklift[2] which both include a > vagrant config and bats tests. I'd propose we merge foreman-bats into > forklift and deprecate foreman-bats. Most of bats (if not all) should already > be there so I believe we just need to verify we can test Foreman using > Forklift. Since I added Debian we need to make Ubuntu work and verify Jenkins > can still test everything it used to. > > This should be a relative easy task for which a lot of work has already been > done. > > Tasks/Challenges I can think of: > > * Add Ubuntu to Forklift > * Get bats passing on all supported configs > * Verify foreman-bats is no longer used on CI > * Add a deprecation warning in foreman-bats' README > > # katello-packaging -> foreman-packaging > > At the moment Foreman packages are maintained in foreman-packaging[3] with an > RPM branch for every release (rpm/1.15, rpm/1.16, rpm/develop) and a the same > with deb/ for obvious reasons. On the Katello side there is > katello-packaging[4] with KATELLO-3.3, KATELLO-3.4 and master. > > There was a discussion in #1541[5] about merging katello-packaging into > foreman-packaging, but it didn't reach a conclusion. The general opinions > were in favour but there might be space and traffic constraints when actually > building the packages. > > My proposal is to revive this effort. Given the practical constraints are > related to the hosting it makes sense to me to start with just merging the > git repositories. Is it possible to do the builds from a single git > repository and end up on different servers for now? > > If that's possible, we can look at finding proper hosting and which yum > repositories we should offer. > > # katello modules -> theforeman namespace (including modulesync) > > Right now we have a foreman-installer-modulesync[6] and > katello-installer-modulesync[7] to maintain the base layout of modules. > These are all very similar and with little effort we can maintain all modules > with the same layout. > > The bigger impact is that we need to migrate all modules at least on the > github level to the theforeman github namespace. It also implies that when > you make changes to modulesync that needs to be applied to about double the > modules which can be more effort. The upside is that the overall quality will > be higher. > > If this all works well we can look at moving the katello modules to the > foreman namespace on the Puppet forge as well but I think that benefit is > smaller and will take effort on the (direct) users since the forge doesn't > support redirects. > > # katello-installer -> foreman-installer > > Currently the katello-installer[8] builds on the foreman-installer[9] with > additional modules and scenarios. Sometimes the katello build breaks on > dependencies and then the cache gets out of sync with the foreman thus > breaking on older builds as well. > > I'd like to merge this in a single installer with one set of modules and > multiple scenarios. The impact is that the installer will be bigger but the > katello-installer should be less fragile. It can also simplify packaging. > > Care will need to be taken that the needed repositories are present but there > are multiple ways of fixing this. Currently we assume the user has installed > the katello release RPM which enables the needed yum repositories but that > will not be true anymore if we ship it within foreman-installer. > > We'll also want to remove/disable the katello scenarios on Debian/Ubuntu. > > You may notice I haven't thought this through too much and it may depend on a > unified Yum repository structure but there are big usability and reliability > wins we can gain. > > [1]: https://github.com/theforeman/foreman-bats > [2]: https://github.com/theforeman/forklift > [3]: https://github.com/theforeman/foreman-packaging > [4]: https://github.com/katello/katello-packaging > [5]: https://github.com/theforeman/foreman-packaging/pull/1541 > [6]: https://github.com/theforeman/foreman-installer-modulesync > [7]: https://github.com/katello/foreman-installer-modulesync > [8]: https://github.com/katello/katello-installer > [9]: https://github.com/theforeman/foreman-installer > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
