On Wed, Oct 18, 2017 at 1:46 AM, Eric D Helms <[email protected]> wrote: > Plugins do present the most complicated part of this process given they > would each potentially be requiring a few independent gems separate from the > core stack and we would not want bloat. Seems we'd need either: > > 1) a single gem stack that plugins contribute to and is renegenrated with > all them enabled > 2) a method for plugins to generate the bundle install, and pick out just > the gems they need to contribute on top of the core stack
The disadvantage of 2) comes, when there are two plugins, that both need the same dependency, that is not in the core and using both plugins can lead to version collisions (we've seen that in the deb packaging every now and then). Although, having multiple versions of gems usually is not that much of a big deal, as long as they are compatible with the plugins, it's seems a bit weird that the specific versions being used would depend on the specific plugins being installed. The disadvantage of the the single plugins gem stack is, that update of any dependency there means that the end user needs to re-download the whole bundle again. This is probably not issue for most of the dependencies, that we don't update that often (the part of the stack). But there are gems, such as Dynflow, that are more related to the code and it would be beneficial to have an ability to deliver new versions asynchronously. Thinking about it a bit more, we usually need the fast updates in nightlies, where it's probably not much of a deal for the end user, and having the gem stack rpm updated with every upstream release seems like it could work. There would be still possibility for any plugin, to bring in their own dependency, that would not be in the common stack, if needed, but the recommended would be to get into the Foreman ecosystem to get the deps into the common stack. So for now, 1) is winning for me. This might be also an entry-point for testing the plugins together. Another potential move could be tackling how the plugins are getting enable in the first place. If the bits and pieces for all the plugins would be available every time, than the act of installing a plugin would be just about enabling loading the corresponding gem (as opposed for need to installing it first). It would make it also easier to make the plugins discoverable: there is of course more work to be done for making that working, but just exploring what it might mean. It's also good to thing about how that could influence the containerization work. We could still build the containers at the end-user side, with a subset of plugins installed, but with the all-plugins bundle, we could distribute the images themselves. There would be additional requirement on the plugin developers to sync even more with the core releases, but I think it's a good thing. -- Ivan > > On Tue, Oct 17, 2017 at 6:42 PM, Dmitri Dolguikh <[email protected]> > wrote: >> >> > 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) >> >> Not sure if this has already been considered: use bundler to package the >> app. In this case all dependencies, including rails will be cached locally, >> and we could then wrap the result into an rpm. Not sure how plugins would >> fit into this though. >> >> -d >> >> On Tue, Oct 17, 2017 at 11:17 AM, Bryan Kearney <[email protected]> >> wrote: >>> >>> On 10/16/2017 04:36 AM, Michael Moll wrote: >>> > I don't really have stakes in RPMs, but I'd try to stick with option 1 >>> > and I even expect that there's some demand for Rails SCLs at least in >>> > the RHEL/CentOS world by other projects, too. >>> > >>> > Regards >>> >>> I would suggest the decision be made based on the assumption that the >>> foreman community owns all the work for options 1 and 2. I have no >>> special instights, but I would hate to assume we could package based on >>> another communities work. Assume this commuity owns it all, which way is >>> better/easier/quicker/less error prone. >>> >>> -- bk >>> >>> -- >>> 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 [email protected]. >>> 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 [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > > > > -- > Eric D. Helms > Red Hat Engineering > > -- > 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
