Re: [foreman-dev] Plugin gems with a single author - redux
On 10/11/17 15:20, Ewoud Kohl van Wijngaarden wrote: > On Fri, Nov 10, 2017 at 02:02:10PM +, Greg Sutcliffe wrote: >> To make this a more "official" policy, I've created a "Foreman" account >> on Rubygems, and the user can be added >> to any gem we keep on our namespace. This should minimize any issues >> when transferring gems to new owners. > > For what it's worth: it'd be good if this was rubyg...@theforeman.org, > even if it's still stored on gmail. That way you can easily change it as > long as you own the domain. Agreed. Ohad is away (he controls the DNS domain), and I wanted to get it done while I was thinking about it. I'll get that alias sorted when he's back. -- 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. signature.asc Description: OpenPGP digital signature
[foreman-dev] Help wanted with SaltStack/Foreman
So, I am looking for some help integrating SaltStack with The Foreman/Katello. I think I might have bitten off more than I can chew. So far, I can: * Install Katello/The Foreman with SaltStack - https://github.com/jdshewey/slik-installer * Add GPG Keys * I have a module/python functions for doing several other tasks, but could use help adding them to my formula - https://github.com/jdshewey/salt-formula-katello In the future, I plan to: * Use Foreman Hooks to trigger reactor functions to force using Salt to configure the SaltStack - https://github.com/jdshewey/salt-formula-katello/issues/2 - https://github.com/jdshewey/salt-formula-katello/issues/2 * See about replacing the foreman install with a Salt equivelent (it seems silly to have to install a competing configuration management system) - https://github.com/jdshewey/slik/issues * Eventually, I would like to see FreeIPA more closely integrated into The Foreman - https://github.com/jdshewey/slik/milestones If you find any of this interesting, I would welcome your contributions or just feedback (and bug reports) Thanks, James -- 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.
[foreman-dev] Help with Foreman/StalStack integration wanted
So, I am looking for some help integrating SaltStack with The Foreman/Katello. I think I might have bitten off more than I can chew. So far, I can: * Install Katello/The Foreman with SaltStack - https://github.com/jdshewey/slik-installer * Add GPG Keys * I have a module/python functions for doing several other tasks, but could use help adding them to my formula - https://github.com/jdshewey/salt-formula-katello In the future, I plan to: * Use Foreman Hooks to trigger reactor functions to force using Salt to configure the SaltStack - https://github.com/jdshewey/salt-formula-katello/issues/2 - https://github.com/jdshewey/salt-formula-katello/issues/2 * See about replacing the foreman install with a Salt equivelent (it seems silly to have to install a competing configuration management system) - https://github.com/jdshewey/slik/issues * Eventually, I would like to see FreeIPA more closely integrated into The Foreman - https://github.com/jdshewey/slik/milestones If you find any of this interesting, I would welcome your contributions or just feedback (and bug reports) Thanks, James -- 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.
Re: [foreman-dev] Building a Rails 5.1 SCL
Based on the feedback, I have started the repository for this effort [1] and opened an initial PR [2] that adds tooling and an initial set of packages in order to ensure that tooling works. My goal is to get the initial package and tooling reviewed and committed before moving on to other packages. This should allow developer collaboration creating packages, and ensure from the start we have everything setup. Thus, I invite all developers and especially those on the packaging team to review. My next goal, before that PR is merged, is to add PR testing so that from the start we have the infrastructure to support changes and new pckages. Eric [1] https://github.com/theforeman/tfm-ror51-packaging [2] https://github.com/theforeman/tfm-ror51-packaging/pull/1 On Tue, Nov 7, 2017 at 12:03 PM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: > +1 for 2.4. I believe currently it's beta in SCLo but I assume that it'll > be GA by the time we finish it and the RH-SCL version is already GA. > > > On Tue, Nov 07, 2017 at 11:59:43AM -0500, Eric D Helms wrote: > >> One thing I didn't include as part of this discussion was a discussion of >> the version of Ruby to use. Currently a Ruby 2.4 and Ruby 2.3 SCL exists >> from the RHSCL team within CentOS. I propose we use Ruby 2.4 given that it >> is latest and greatest. This is important, since the Rails SCL will have >> to >> depend on a Ruby SCL version. >> >> Eric >> >> On Fri, Nov 3, 2017 at 9:23 AM, Eric D Helms >> wrote: >> >> >>> >>> On Thu, Nov 2, 2017 at 6:24 AM, Daniel Lobato Garcia < >>> elobat...@gmail.com> >>> wrote: >>> >>> I agree with all of that, definitely something to do in a different repository. Just one question, my understanding is that you prefer to do this (SCL) because we are uncertain of the time/effort required for vendoring the gems/npm packages. Given that long-term we would have to keep up building SCLs (which if I’m not wrong are going to be less used from EL8 onward) and maintaining packages (which consumes a great deal of our time). >>> To be fair, I judged this based on what the community prefers not just my >>> personal preference per the other thread. I do tend to still think NPM >>> should be vendorized given how it does not provide runtime dependencies >>> and >>> only build time as well as the complex nature of how it handles packages >>> and dependencies (and sheer scale of packages). >>> >>> Eric >>> >>> >>> Parallel to this effort, do you think it’s worth moving forward with the vendorization of npm so that gems can follow suit? >>> > -- > 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.
Re: [foreman-dev] Plugin gems with a single author - redux
On Fri, Nov 10, 2017 at 02:02:10PM +, Greg Sutcliffe wrote: To make this a more "official" policy, I've created a "Foreman" account on Rubygems, and the user can be added to any gem we keep on our namespace. This should minimize any issues when transferring gems to new owners. For what it's worth: it'd be good if this was rubyg...@theforeman.org, even if it's still stored on gmail. That way you can easily change it as long as you own the domain. -- 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.
[foreman-dev] Re: Plugin gems with a single author - redux
On 10/11/17 14:02, Greg Sutcliffe wrote: > To make this a more "official" policy, I've created a "Foreman" account > on Rubygems, and the user can be added > to any gem we keep on our namespace. This should minimize any issues > when transferring gems to new owners. That user is now added to every gem I have access to. Feel free to do the same with your own ;) Greg -- 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.
Re: [foreman-dev] Plugin gems with a single author - redux
On 10/11/17 14:23, Ewoud Kohl van Wijngaarden wrote: > > I like this. What are the opinions on deploying gems through Travis like > voxpupuli does? > > https://docs.travis-ci.com/user/deployment/rubygems/ > > tl;dr: on tags it can deploy the gem to rubygems. It standardizes the > deploy process and you're sure that any gem has a tag and vice versa. I was about to suggest *exactly* this. Add the gems to a bot, let the bot handle pushing new versions. Can be automated from the Git so we don't even need any other authors on a gem (provided the access to the bot account is properly shared for yanking etc). Thoughts everyone? -- 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.
Re: [foreman-dev] Plugin gems with a single author - redux
On Fri, Nov 10, 2017 at 02:02:10PM +, Greg Sutcliffe wrote: A few months ago we added a policy that required 2 gem authors per plugin. We did, however struggle to actually get two authors on some plugins. To make this a more "official" policy, I've created a "Foreman" account on Rubygems, and the user can be added to any gem we keep on our namespace. This should minimize any issues when transferring gems to new owners. The account has a recovery email of my RedHat address, which means it can be recovered even if I get hit by a bus (because my superiors can open it). I will also revive the discussion about sharing infra passwords with appropriate security ;) Unless anyone has any strong objections, I'll send a PR for review to make adding this owner an official policy for our gems. I like this. What are the opinions on deploying gems through Travis like voxpupuli does? https://docs.travis-ci.com/user/deployment/rubygems/ tl;dr: on tags it can deploy the gem to rubygems. It standardizes the deploy process and you're sure that any gem has a tag and vice versa. -- 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.
[foreman-dev] Plugin gems with a single author - redux
Hi all, A few months ago we added a policy that required 2 gem authors per plugin. We did, however struggle to actually get two authors on some plugins. To make this a more "official" policy, I've created a "Foreman" account on Rubygems, and the user can be added to any gem we keep on our namespace. This should minimize any issues when transferring gems to new owners. The account has a recovery email of my RedHat address, which means it can be recovered even if I get hit by a bus (because my superiors can open it). I will also revive the discussion about sharing infra passwords with appropriate security ;) Unless anyone has any strong objections, I'll send a PR for review to make adding this owner an official policy for our gems. Greg -- 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.
