On Wed, Jan 4, 2017 at 4:29 AM, Ivan Necas <ine...@redhat.com> wrote:
> Hello friends, > > You've might noticed we started using foreman-tasks inside the > foreman-core since [1] was merged. Unfortunately, we hit issues in the > packaging phase and the proposed workarounds were not accepted ([2] > [3]). > > Based on various discussions, as well as on the fact that > foreman-tasks is already part of infrastructure for pretty wide amount > of plugins (Katello, Remote Execution, Chef, Salt, Ansible, Docker…), > it seems moving foreman-tasks code-base into the core as part of the > Foreman is where people want to get us moving. > +1 given that foreman-tasks has proven itself to be a corner stone of tooling for many plugins including core now. > > Therefore, let me start proposing the plan for moving this subject forward. > > The plan would be: > > 1. get the the foreman-tasks-core, that is part of the tasks code > being use both in foreman server and smart-proxy code into separate > repository > 2. get the foreman-tasks on the same set of rubocop rules the foreman > code uses > 3. fill unit test gaps > 4. open PR to foreman with the foreman-tasks functionality > 5. open PR to get the hammer-cli-foreman-tasks inside hammer-cli-foreman > > The target version for this would be foreman 1.15. > Beyond the version being targeted, do you have a time line for this? The sooner the better for many reasons. > > In the mean time, I would like to kindly ask for trying to > find an acceptable workaround in [2] and [3] until this is done. > I commented (sorry for not jumping in sooner). > > Also, since this will be pretty large change already, I would like to > avoid radical changes done as part of the PR: as already said, > foreman-tasks has already quite significant user base though various > plugins that we need to support and I would rather prefer keeping > those as additional issues to track and address based on priorities, > as well as going though proper deprecation cycle if we need to > deprecate something. > +1 -- nightly is stagnating a bit for various plugins and core, unsticking that even with a temporary work around would be great. I'd even be OK with foreman-tasks going into the core repository as is as an engine in a sub-directory. Similar to [1]. I realize this may not be ideal long term, but it has the benefits of being able to migrate the code quicker, and sooner. The code would now live in core as is (thus in theory less prone to potential breakages) and could then be migrated out into some more official code layout that developers desire. [1] https://github.com/Katello/katello/tree/master/engines/bastion_katello > > Opinions, comments, questions, concerns (and remember, :+1: is also a > valid response:) > > [1] - https://github.com/theforeman/foreman/pull/3670 > [2] - https://github.com/theforeman/foreman-packaging/pull/1436 > [3] - https://github.com/theforeman/foreman-packaging/pull/1437 > > -- Ivan > > -- > 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. > -- 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 foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
