+1 for every suggestion! Which would you like to start with? I'd be interested in helping with forklift being used in jenkins for running bats tests. Later I hope with installers merge.
-- Marek On středa 2. srpna 2017 14:33:44 CEST Ewoud Kohl van Wijngaarden 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.
