I'm ok with the vendorizing approach, as long as it makes the release process more effective than it is right now.
Could you expand more on how the core dependencies, plugins and plugin-dependencies work? Perhaps this is something we could align with the debian packaging as well to address some of the issues that we are facing. -- Ivan On Sat, Oct 14, 2017 at 8:24 PM, Eric D Helms <ericdhe...@gmail.com> wrote: > Note: This is specific to RPMs because as far as I know the Debian process > is different and uses gems directly. Please correct me and contribute any > information with respect to Debian that I miss. I believe the Nodejs part of > the email does apply to Debian. > > This proposal is in two parts: gems and node packages. The general issue > applies to both, the project has a need to be able to move and update > dependencies more quickly given the speed at which platforms like Rails, > React and Webpack update. > > > Node/NPM Packages > > Today, we package nearly all nodejs packages that are required to either > build the UI or runtime UI dependencies into packages. At current count, > there are 78 nodejs packages listed in Koji as RPMs. Over the past few > months, the move to React and updating UI within Foreman core and branching > into plugins has led to multiple, and at times, compounding packaging and > thus nightly breakages. One of those breakages lasted over a week with > multiple developers spending many hours tracking down the issue. The speed > at which these changes are made makes keeping up successful nightly builds > difficult. The git repository gets well ahead of the packaging which leads > to compounding issues. This has also been the cause of stable version > release delays. > > Proposal: > Deprecate nodejs packages in favor of foreman-assets or a new RPM > foreman-node-modules that contains a source tarball of node_modules/ > packaged into a simple RPM that is used as a build dependency. This tarball > would be regenerated, and the package bumped, as dependency updates are > needed. > > > Ruby Gems > > Today we package all required rubygems as RPMs and utilize a thirdparty > Software Collection (SCL) for both the Ruby (rh-ruby22) and Rails stack > (sclo-ror42). The team that manages the RHSCLs has already released Ruby 2.3 > and RUby 2.4 SCLs and will continue to do so. However, there are no plans to > release any further SCLs for the Rails stack. This means, in addition to our > own dependencies, we need to build and manage the Rails stack for the > versions we want. This adds more packaging burden on the RPM side. GIven > this, we have a few options: > > 1) Build and manage our own SCLs for every version of Rails from here on > out > 2) Vendorize Rails and thirdparty gems into a one or more base RPMs (e.g. > an RPM for rails stack and one for thirdparty dependencies) > > Option 2, to vendorize, is a deviation from our prior practices in the area > of production deployment. Thus, I am reaching out to the community to get > feedback. One interesting consideration for vendorizing is when containers > are considered and having the ability to build them using 'bundle install' > versus using RPM based installation. > > In theory vendorizing allows the community to move faster, keep up to date > with dependencies more easily and reduces the burden on RPM packaging to > keep nightly builds flowing. However, this does stray from the standard RPM > based installation benefits typically associated to it. > > > Please consider carefully, and weigh in even if it is simply to +1 or -1 a > given idea. Deployment is a large part of our project and the more voices > weighing in the better. > > Thanks, > Eriic > > -- > 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.
