Re: [foreman-dev] Building a Rails 5.1 SCL

[Eric D Helms]

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] Building a Rails 5.1 SCL

[Ewoud Kohl van Wijngaarden]

+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 
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.

Re: [foreman-dev] Building a Rails 5.1 SCL

[Eric D Helms]

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 
> 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?
>>
>> --
>> Daniel Lobato Garcia
>>
>> @dLobatog
>> blog.daniellobato.me
>> daniellobato.me
>>
>> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
>> Keybase: https://keybase.io/elobato
>>
>> --
>> 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
>



-- 
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] Building a Rails 5.1 SCL

[Eric D Helms]

On Thu, Nov 2, 2017 at 6:24 AM, Daniel Lobato Garcia 
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?
>
> --
> Daniel Lobato Garcia
>
> @dLobatog
> blog.daniellobato.me
> daniellobato.me
>
> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
> Keybase: https://keybase.io/elobato
>
> --
> 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] Building a Rails 5.1 SCL

[Eric D Helms]

On Thu, Nov 2, 2017 at 8:02 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Wed, Nov 01, 2017 at 02:00:29PM -0400, Eric D Helms wrote:
>
>> In a previous thread [1], we discussed building an SCL vs. vendorizing
>> gems
>> and the general consensus was to build an SCL. This thread is to outline a
>> starting plan for how to build and maintain a Rails 5.1 SCL. I invite and
>> appreciate comments towards this design.
>>
>> I'll begin by laying out some overall goals for the effort, a general
>> proposal of information and finally a breakdown of the why for each of the
>> proposal items to better explain my thinking.
>>
>>
>> Goals
>>
>> * Stand alone Rails 5.1 SCL and repository
>> * Owned and maintained by the Foreman community
>> * Easy to update and maintain
>> * Strive for automation and package tooling to reduce maintenance cost
>>
>>
>> Proposal
>>
>> Build location: Copr
>> SCL Name: tfm-ror51
>> Git repository: theforeman/tfm-ror51-packaging
>> Hosted: yum.theforeman.org/rails/tfm-ror51
>> RPM Signing: signed by unique Foreman owned GPG key
>> Tooling Repo: create package tooling repository separate from
>> tfm-ror51-packaging repo
>> Tooling Technology: Ansible
>>
>>
>> Breakdown
>>
>> Build Location
>>
>> There has been discussion around moving our RPM builds to Copr and off of
>> Koji. This will require shifting our configuration and setup, testing and
>> working out kinks in Copr workflow. Building this Rails SCL provides us an
>> opportunity to use Copr from the start, get familiar with it and workout
>> tooling to interact with and manage a repository there. Therefore, I am
>> proposing to start with Copr from the get go and avoid Koji.
>>
>
> +1
>
> SCL Name
>>
>> Given the Foreman community will own the SCL, and our SCL namespace is
>> 'tfm' I am suggesting we follow convention by naming it tfm-ror51.
>> Previous
>> Rails SCLs, were named similarly: rh-ror41, rh-ror42, sclo-ror42.
>>
>
> +1 though we could look at creating a CentOS SIG to do it under the sclo
> flag. IMHO this can be parallel to the development or even after the fact.
>
> Git Repository
>>
>> I am proposing we don't put this into foreman-packaging given the
>> lifecycle
>> of the SCL will not follow that of Foreman. Further, with the goal to
>> create a stand-alone Rails SCL repository this should have its own
>> lifecycle.
>>
>
> +1
>
> Hosted
>>
>> We could point at the direct Copr repository, and reduce our bandwidth.
>> However, since we own this Rails SCL I believe we should host it as such
>> officially. Further, this would allow us to do some pre-flight testing by
>> building a repository in Copr, running a test of either the SCL itself
>> and/or Foreman against the SCL updates before promoting.
>>
>
> +1
>
> This would be similar to how we now have koji: as a staging ground, we
> test against this and promote if it's stable with the added benefit that
> it's easier to consume.
>
> RPM Signing
>>
>> I am recommending here that we sign the SCL RPMs with a new GPG key
>> generated just for signing the SCL packages.
>>
>
> COPR signs repos by default with its own GPG key. Do you want a separate
> GPG key when we host it on yum.theforeman.org?
>
> Tooling
>>
>> With an eye towards foreman-packaging changes, I am proposing we create a
>> separate git repository for all package tooling. The goal here would to
>> build out new tooling to allow easier maintenance of the packaging and
>> repository.  This will allow the tooling to evolve independently of either
>> packaging repository.  Further, when applying this tooling to
>> foreman-packaging later, the tooling would not have to be duplicated
>> across
>> branches.
>>
>
> +1
>
> Tooling Technology
>>
>> I am proposing a centralization on Ansible as the tooling technology for a
>> number of reasons. First, I feel that it has a low barrier to entry while
>> providing a mix of high and low level interfaces. Secondly, Ansible allows
>> orchestrating and building out more complex and directed tasks. Third, a
>> team of us has some built out Ansible tooling that has been working well
>> for us in another area that would be easy to port for packaging
>> management.
>> I personally think bash is complex to understand for complex actions and
>> is
>> too simple for building up a set of cohesive tooling.
>>
>
> For me this depends. If an ansible playbook is just a list of commands
> then IMHO it doesn't add much value over a shell script. If you use higher
> level tools (modules?) then there's a great benefit in both readability and
> maintainability. I could see us developing a copr module so we can use
> copr_build and such.


I might have to lay out more of what I am thinking, but based on some other
work there is a chunk of neat and powerful stuff that be done by using
Ansible + inventories with packages. Plus, as you said, modules give the
ability to create some higher level abstractions. I also stand by that
Ansible syntax is easier for new 

Re: Re: [foreman-dev] Building a Rails 5.1 SCL

[Daniel Lobato Garcia]

On 11/02, Ewoud Kohl van Wijngaarden wrote:
> On Thu, Nov 02, 2017 at 11:24:26AM +0100, Daniel Lobato Garcia wrote:
> > 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).
>
> My expectation is that vendorizing RPMs would cost a similar time as
> building the SCL. Given separate packaging has a lot of benefits over
> bundling[1].
>
> Thinking about this, we currently don't check the licenses of bundled npm
> modules in our existing packaging. It's possible we currently ship something
> we're not legally allowed to ship but we simply don't know.o

Problem is - it's pretty much impossible to make npm work with the rpm model.
Dependencies are different between libraries such that this is common:

A depends on C > 1.5
B depends on C = 1.0
Foreman depends on A and B

If we don't bundle, there's no way to tell RPM to install C >= 1.5 and C = 1.0
at the same time (as far as I know).

About the legality problem - I think we should start creating some script that
parses all the dependencies we have and their licenses and make a summary, then
detect any possible conflicts...

>
> With regards to EL8 I think you're hinting at the modularization effort
> that's currently in Fedora. For those unaware: it's aimed to be a much
> better version of SCLs. Better integrated in the system but also allow
> easily producing containers. At the moment there's still little
> documentation and we'll likely support EL7 for a while so at this point I'm
> not planning much. What we do want to do is move from our own Koji instance
> to COPR. That should be prepared for modularization. Developing the SCL in
> COPR can be seen as a first step in this process.
>
> [1]: 
> https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries#Why_Bundled_Libraries_are_a_problem
>
> > Parallel to this effort, do you think it’s worth moving forward with the
> > vendorization of npm so that gems can follow suit?
>
> Personally I'd say gems shouldn't follow suit unless maintaining the SCL
> proves too much work. In fact, the only reason I currently accept npm
> vendorization is that we currently can't keep up with the changes. If we can
> develop sufficient tooling I'd actually like to roll back npm vendorization
> too when we can provide the same developer flexibility.

As I said above - npm vendorization (at the level we do now with bundled-npm
packages) isn't possible to roll back, at least to my knowledge

>
> --
> 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.

--
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato

-- 
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: PGP signature

Re: [foreman-dev] Building a Rails 5.1 SCL

[Lukas Zapletal]

Big +1 to all of that.

I think COPR provides some own GPG keys and IIRC you can't override
those. It is possible to download packages from COPR and sign them
again with a custom key of course. That's perhaps your plan I guess.
Custom signatures is on COPR development TODO I think.

LZ

On Wed, Nov 1, 2017 at 7:00 PM, Eric D Helms  wrote:
> In a previous thread [1], we discussed building an SCL vs. vendorizing gems
> and the general consensus was to build an SCL. This thread is to outline a
> starting plan for how to build and maintain a Rails 5.1 SCL. I invite and
> appreciate comments towards this design.
>
> I'll begin by laying out some overall goals for the effort, a general
> proposal of information and finally a breakdown of the why for each of the
> proposal items to better explain my thinking.
>
>
> Goals
>
>  * Stand alone Rails 5.1 SCL and repository
>  * Owned and maintained by the Foreman community
>  * Easy to update and maintain
>  * Strive for automation and package tooling to reduce maintenance cost
>
>
> Proposal
>
> Build location: Copr
> SCL Name: tfm-ror51
> Git repository: theforeman/tfm-ror51-packaging
> Hosted: yum.theforeman.org/rails/tfm-ror51
> RPM Signing: signed by unique Foreman owned GPG key
> Tooling Repo: create package tooling repository separate from
> tfm-ror51-packaging repo
> Tooling Technology: Ansible
>
>
> Breakdown
>
> Build Location
>
> There has been discussion around moving our RPM builds to Copr and off of
> Koji. This will require shifting our configuration and setup, testing and
> working out kinks in Copr workflow. Building this Rails SCL provides us an
> opportunity to use Copr from the start, get familiar with it and workout
> tooling to interact with and manage a repository there. Therefore, I am
> proposing to start with Copr from the get go and avoid Koji.
>
> SCL Name
>
> Given the Foreman community will own the SCL, and our SCL namespace is 'tfm'
> I am suggesting we follow convention by naming it tfm-ror51. Previous Rails
> SCLs, were named similarly: rh-ror41, rh-ror42, sclo-ror42.
>
> Git Repository
>
> I am proposing we don't put this into foreman-packaging given the lifecycle
> of the SCL will not follow that of Foreman. Further, with the goal to create
> a stand-alone Rails SCL repository this should have its own lifecycle.
>
> Hosted
>
> We could point at the direct Copr repository, and reduce our bandwidth.
> However, since we own this Rails SCL I believe we should host it as such
> officially. Further, this would allow us to do some pre-flight testing by
> building a repository in Copr, running a test of either the SCL itself
> and/or Foreman against the SCL updates before promoting.
>
> RPM Signing
>
> I am recommending here that we sign the SCL RPMs with a new GPG key
> generated just for signing the SCL packages.
>
> Tooling
>
> With an eye towards foreman-packaging changes, I am proposing we create a
> separate git repository for all package tooling. The goal here would to
> build out new tooling to allow easier maintenance of the packaging and
> repository.  This will allow the tooling to evolve independently of either
> packaging repository.  Further, when applying this tooling to
> foreman-packaging later, the tooling would not have to be duplicated across
> branches.
>
> Tooling Technology
>
> I am proposing a centralization on Ansible as the tooling technology for a
> number of reasons. First, I feel that it has a low barrier to entry while
> providing a mix of high and low level interfaces. Secondly, Ansible allows
> orchestrating and building out more complex and directed tasks. Third, a
> team of us has some built out Ansible tooling that has been working well for
> us in another area that would be easy to port for packaging management. I
> personally think bash is complex to understand for complex actions and is
> too simple for building up a set of cohesive tooling.
>
> --
> 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.



-- 
Later,
  Lukas @lzap Zapletal

-- 
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

[Ewoud Kohl van Wijngaarden]

On Thu, Nov 02, 2017 at 11:24:26AM +0100, Daniel Lobato Garcia wrote:

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).


My expectation is that vendorizing RPMs would cost a similar time as 
building the SCL. Given separate packaging has a lot of benefits over 
bundling[1].


Thinking about this, we currently don't check the licenses of bundled 
npm modules in our existing packaging. It's possible we currently ship 
something we're not legally allowed to ship but we simply don't know.o


With regards to EL8 I think you're hinting at the modularization effort 
that's currently in Fedora. For those unaware: it's aimed to be a much 
better version of SCLs. Better integrated in the system but also allow 
easily producing containers. At the moment there's still little 
documentation and we'll likely support EL7 for a while so at this point 
I'm not planning much. What we do want to do is move from our own Koji 
instance to COPR. That should be prepared for modularization. Developing 
the SCL in COPR can be seen as a first step in this process.


[1]: 
https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries#Why_Bundled_Libraries_are_a_problem


Parallel to this effort, do you think it’s worth moving forward with the
vendorization of npm so that gems can follow suit?


Personally I'd say gems shouldn't follow suit unless maintaining the SCL 
proves too much work. In fact, the only reason I currently accept npm 
vendorization is that we currently can't keep up with the changes. If we 
can develop sufficient tooling I'd actually like to roll back npm 
vendorization too when we can provide the same developer flexibility.


--
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

[Daniel Lobato Garcia]

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).

Parallel to this effort, do you think it’s worth moving forward with the
vendorization of npm so that gems can follow suit?

--
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato

-- 
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: PGP signature

[foreman-dev] Building a Rails 5.1 SCL

[Eric D Helms]

In a previous thread [1], we discussed building an SCL vs. vendorizing gems
and the general consensus was to build an SCL. This thread is to outline a
starting plan for how to build and maintain a Rails 5.1 SCL. I invite and
appreciate comments towards this design.

I'll begin by laying out some overall goals for the effort, a general
proposal of information and finally a breakdown of the why for each of the
proposal items to better explain my thinking.


Goals

 * Stand alone Rails 5.1 SCL and repository
 * Owned and maintained by the Foreman community
 * Easy to update and maintain
 * Strive for automation and package tooling to reduce maintenance cost


Proposal

Build location: Copr
SCL Name: tfm-ror51
Git repository: theforeman/tfm-ror51-packaging
Hosted: yum.theforeman.org/rails/tfm-ror51
RPM Signing: signed by unique Foreman owned GPG key
Tooling Repo: create package tooling repository separate from
tfm-ror51-packaging repo
Tooling Technology: Ansible


Breakdown

Build Location

There has been discussion around moving our RPM builds to Copr and off of
Koji. This will require shifting our configuration and setup, testing and
working out kinks in Copr workflow. Building this Rails SCL provides us an
opportunity to use Copr from the start, get familiar with it and workout
tooling to interact with and manage a repository there. Therefore, I am
proposing to start with Copr from the get go and avoid Koji.

SCL Name

Given the Foreman community will own the SCL, and our SCL namespace is
'tfm' I am suggesting we follow convention by naming it tfm-ror51. Previous
Rails SCLs, were named similarly: rh-ror41, rh-ror42, sclo-ror42.

Git Repository

I am proposing we don't put this into foreman-packaging given the lifecycle
of the SCL will not follow that of Foreman. Further, with the goal to
create a stand-alone Rails SCL repository this should have its own
lifecycle.

Hosted

We could point at the direct Copr repository, and reduce our bandwidth.
However, since we own this Rails SCL I believe we should host it as such
officially. Further, this would allow us to do some pre-flight testing by
building a repository in Copr, running a test of either the SCL itself
and/or Foreman against the SCL updates before promoting.

RPM Signing

I am recommending here that we sign the SCL RPMs with a new GPG key
generated just for signing the SCL packages.

Tooling

With an eye towards foreman-packaging changes, I am proposing we create a
separate git repository for all package tooling. The goal here would to
build out new tooling to allow easier maintenance of the packaging and
repository.  This will allow the tooling to evolve independently of either
packaging repository.  Further, when applying this tooling to
foreman-packaging later, the tooling would not have to be duplicated across
branches.

Tooling Technology

I am proposing a centralization on Ansible as the tooling technology for a
number of reasons. First, I feel that it has a low barrier to entry while
providing a mix of high and low level interfaces. Secondly, Ansible allows
orchestrating and building out more complex and directed tasks. Third, a
team of us has some built out Ansible tooling that has been working well
for us in another area that would be easy to port for packaging management.
I personally think bash is complex to understand for complex actions and is
too simple for building up a set of cohesive tooling.

-- 
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.