Upcoming Rails 4 branch merge

Development
#1

Hey,

if I read the lines correctly, we will be merging Rails 4 soon. I'd
appreciate a short demo about relevant changes in Rails 4 and what is
changing in our codebase. The patch(es) are huge, this would be very
useful for most of us.

Thanks!

··· -- Later, Lukas #lzap Zapletal
#2

"close" is a relative term.
The Katello team have made quite a bit of progress on their side, so we're
getting closer to a moment that we can afford to think of a merge (business
wise)

The current PR is huge, I assume that's what Dominic refers to when he
called it a mess. What Daniel is doing to move compatible code from that
branch to develop is bringing the scope of this PR down quite a bit, but
it's still gigantic. Merging it would be tough, and frankly, I don't see a
way out of it, as the sheer scale of the changes required for moving from
3.2 to 4.1 is too large to grasp.
My mistake on this was that I just dove right in, instead of trying to do
the work Daniel now took upon himself, but I'm not sure that it would have
been possible, realistically, to do those changes in a compatible manner…

If we're already at it, I suggest two things:

  1. let's move that branch to theforeman org (currently rails4 is on my
    repository, which annoys a lot of folks)
  2. continuing to move compatible code to develop is great, let's also
    "greenlight" code from the rails4 branch to an "approved rails4" branch or
    something, i.e. have a branch with ready-to-merge stuff. we need to get
    this PR dismantled and approved…
#3

Updating on rails 4's status:

  1. Katello team is currently working on making tests green - only 300
    more failures left - yay!
  2. Foreman team:
    • Daniel is working on moving rails 3 compatible code from the rails4
      branch to foreman's develop branch.
    • Tom is scheduled to merge develop into rails4 on Sunday, so Monday
      everyone can work on an up-to-date code

We finally have a realistic goal date - we aim to get Foreman and Katello's
rails 4 versions merged right after Foreman's 1.10 stable is branched, so
1.11 will be developed with rails 4, and we'll have enough time to sort out
the quirks which are bound to happen.
In order to do that, we will remove as much code from the rails 4 branch,
that means, among other things, the removal of the strong parameters, and
usage of the rails 3 style protected attributes.

There was a suggestion that we create a rails4 branch on theforeman account
and send it PRs with code which is incompatible with rails 3 (the
compatible code should enter develop). This means that the rails4 branch on
theforeman wouldn't work at first, but it will contain only code which
passed code review. I'd like to hear your opinion on that.

The optimist in me is jumping in joy and screaming "the end is near" :slight_smile:

Comments, questions or concerns?

#4

Seems unlikely to me, but I've no idea what's going on with it either.
There's a PR open (which is a mess) from Tom Caspy, there have been some
PRs taking bits out of it from Daniel, but I can't tell what the status is.

There was a thread started on this very list about how to merge it
("Rails 4 migration - discussion"), but I don't believe the conclusions
were implemented.

It would be useful to see information somewhere (this list, Redmine, the
wiki, or the PR) about the status.

··· On 17/09/15 11:58, Lukas Zapletal wrote: > if I read the lines correctly, we will be merging Rails 4 soon.

–
Dominic Cleal
dominic@cleal.org

#5

another update - I've opened a new PR

  • https://github.com/theforeman/foreman/pull/2749
    this is just a reordering of the work I've done on the rails4 branch, and
    removal of strong parameters to give way to protected_attributes
    This branch should be in a better shape to get merged.

Currently, tests are still failing (550ish on my machine), but most of them
are just from some lack of attr_accessible or attr_protected in models,
which should be fairly easy to fix.

#6

Status update - almost there!

Where are we

I've been trying to understand the whole Rails 4 set of changes
originally written by Tom by trying to upgrade develop myself and
falling into the same issues. I've applied most of his fixes.

At this point, the diff between non-compatible Rails 4 changes and
develop + compatible changes is around 270 lines. Without
protected_attributes, ".friendly" calls, it's around 150 lines, so I
hope it's manageable to review in theforeman/foreman.

Tests fully pass, however, I have to figure out why unit tests only pass
when I run 'rake test', and functional tests only pass when I run 'rake
test:functionals'.

What's missing

Most changes are retrocompatible with Rails 3, and I've been sending PRs
to develop to include them. There are a few that are still open, the
sooner they can get in, the better:

There are a few other changes that can go in but haven't been submitted
as PRs, I just have to figure out how to make these changes compatible.

Some of the changes Rails 4 will introduce and affect our codebase the
most are:

Aside from these drawbacks, tests run a heck of a lot faster, and in
general response time is noticeably faster. There are many changes we
can benefit from, read the release notes for more info:



What now?

The roadmap I expect to follow is:

  • Get as many compatible changes in develop as possible. They can
    safely go in 1.10.
  • As soon as 1.10 is released (literally on the same day we should be
    ready), get in Rails 4 breaking changes, using protected_attributes,
    if Katello is ready (I reckon it should be)
  • I'll work on getting plugins Rails 4 compatible, both before and
    after the change, as I expect not all of them will be compatible and
    we might break Jenkins tests in some plugins for a couple of days.
    This is avoidable but I don't think is so terrible as long as
    Foreman and Katello remain green. In any case it'd be a short period
    if any, until plugins are able to run with Jenkins.
  • Since protected_attributes is too open, we don't want to
    ship 1.11 with that, and we should only consider it a temporary
    measure to allow us to develop 1.11 in Rails 4.
  • https://github.com/theforeman/foreman/pull/2509 should be
    worked on, and we should ship 1.11 with strong_params, mostly
    populated from the Apipie docs.

What should you do if you're a plugin maintainer

Please run your plugin tests against


and check for failures. Ping me on #theforeman-dev and I'll be glad to
help you fixing issues or even fixing them myself.

··· On 09/21, Tom Caspy wrote: > another update - I've opened a new PR > - https://github.com/theforeman/foreman/pull/2749 > this is just a reordering of the work I've done on the rails4 branch, and > removal of strong parameters to give way to protected_attributes > This branch should be in a better shape to get merged. > > Currently, tests are still failing (550ish on my machine), but most of them > are just from some lack of attr_accessible or attr_protected in models, > which should be fairly easy to fix. > > -- > 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+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.

–
Daniel Lobato Garcia

@eLobatoss


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

#7

Quick update if you want to check out the diff of develop/non-compatible
Rails changes. It's updated to the last change we've made to the rails4
branch.

Barring protected_attributes and .friendly changes, the diff is fairly
minimal as you can see. Hope it helps you understand the changes.

··· On 10/02, Daniel Lobato Garcia wrote: > Status update - almost there! > > ### Where are we > > I've been trying to understand the whole Rails 4 set of changes > originally written by Tom by trying to upgrade develop myself and > falling into the same issues. I've applied most of his fixes. > https://github.com/eLobato/foreman/commits/rails4_from_scratch > > At this point, the diff between non-compatible Rails 4 changes and > develop + compatible changes is around 270 lines. Without > protected_attributes, ".friendly" calls, it's around 150 lines, so I > hope it's manageable to review in theforeman/foreman. > https://github.com/eLobato/foreman/pull/11 > > Tests fully pass, however, I have to figure out why unit tests only pass > when I run 'rake test', and functional tests only pass when I run 'rake > test:functionals'. > > ### What's missing > > Most changes are retrocompatible with Rails 3, and I've been sending PRs > to develop to include them. There are a few that are still open, the > sooner they can get in, the better: > > - https://github.com/theforeman/foreman/pull/2768 > - https://github.com/theforeman/foreman/pull/2763 > - https://github.com/theforeman/foreman/pull/2757 > - https://github.com/theforeman/foreman/pull/2754 > > There are a few other changes that can go in but haven't been submitted > as PRs, I just have to figure out how to make these changes compatible. > > Some of the changes Rails 4 will introduce and affect our codebase the > most are: > - Friendly ID 5.0 > - protected_attributes / strong_params (details below, consider > protected_attributes a provisional measure to help us get in Rails 4 > quickly) > - minitest:runner is deprecated, we need to figure out other way of > running plugin tests > - hash_for_model is deprecated, but we brought it in > https://github.com/eLobato/foreman/pull/11/files#diff-78dbfad830e0697757a21fd7672ce618R1 > > Aside from these drawbacks, tests run a heck of a lot faster, and in > general response time is noticeably faster. There are many changes we > can benefit from, read the release notes for more info: > http://edgeguides.rubyonrails.org/4_0_release_notes.html > http://edgeguides.rubyonrails.org/4_1_release_notes.html > http://edgeguides.rubyonrails.org/4_2_release_notes.html > > > ### What now? > > The roadmap I expect to follow is: > - Get as many compatible changes in develop as possible. They can > safely go in 1.10. > - As soon as 1.10 is released (literally on the same day we should be > ready), get in Rails 4 breaking changes, using protected_attributes, > if Katello is ready (I reckon it should be) > - I'll work on getting plugins Rails 4 compatible, both before and > after the change, as I expect not all of them will be compatible and > we might break Jenkins tests in some plugins for a couple of days. > This is avoidable but I don't think is so terrible as long as > Foreman and Katello remain green. In any case it'd be a short period > if any, until plugins are able to run with Jenkins. > - Since protected_attributes is too open, we don't want to > ship 1.11 with that, and we should only consider it a temporary > measure to allow us to develop 1.11 in Rails 4. > - https://github.com/theforeman/foreman/pull/2509 should be > worked on, and we should ship 1.11 with strong_params, mostly > populated from the Apipie docs. > > ### What should you do if you're a plugin maintainer > > Please run your plugin tests against > https://github.com/eLobato/foreman/tree/rails4_from_scratch > and check for failures. Ping me on #theforeman-dev and I'll be glad to > help you fixing issues or even fixing them myself. > > On 09/21, Tom Caspy wrote: > > another update - I've opened a new PR > > - https://github.com/theforeman/foreman/pull/2749 > > this is just a reordering of the work I've done on the rails4 branch, and > > removal of strong parameters to give way to protected_attributes > > This branch should be in a better shape to get merged. > > > > Currently, tests are still failing (550ish on my machine), but most of them > > are just from some lack of attr_accessible or attr_protected in models, > > which should be fairly easy to fix. > > > > -- > > 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+unsubscribe@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > -- > Daniel Lobato Garcia > > @eLobatoss > blog.daniellobato.me > daniellobato.me > > GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 > Keybase: https://keybase.io/elobato

–
Daniel Lobato Garcia

@eLobatoss
blog.daniellobato.me
daniellobato.me

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

#8

Code updates -

We're trying to get more backward compatible changes in develop. Please
try to run your plugin tests against
https://github.com/eLobato/foreman/tree/rails4_from_scratch to get a
feel of how it's working.

Packaging -

Soon we're starting to work with packaging, Dominic more or less has a
plan we could follow:

Start rebuilding tfm against rh-ror41
(https://www.softwarecollections.org/en/scls/rhscl/rh-ror41/) and
change scl_ruby by scl_ror.

Update spec files to use scl_prefix_ror or scl_prefix_ruby, depending
on whether the package belongs to the ruby scl or the ror scl.

Rebuild all dependencies and the foreman SRPM on top and add/update
packages due to Gemfile changes.

I'll start when I can as this week I don't have much time to work on it
and next week I'm at a CentOS dojo talking about Foreman. Volunteers? :slight_smile:

··· On 10/07, Daniel Lobato Garcia wrote: > Quick update if you want to check out the diff of develop/non-compatible > Rails changes. It's updated to the last change we've made to the rails4 > branch. > > - https://github.com/eLobato/foreman/pull/11/files > > Barring protected_attributes and .friendly changes, the diff is fairly > minimal as you can see. Hope it helps you understand the changes. > > > On 10/02, Daniel Lobato Garcia wrote: > > Status update - almost there! > > > > ### Where are we > > > > I've been trying to understand the whole Rails 4 set of changes > > originally written by Tom by trying to upgrade develop myself and > > falling into the same issues. I've applied most of his fixes. > > https://github.com/eLobato/foreman/commits/rails4_from_scratch > > > > At this point, the diff between non-compatible Rails 4 changes and > > develop + compatible changes is around 270 lines. Without > > protected_attributes, ".friendly" calls, it's around 150 lines, so I > > hope it's manageable to review in theforeman/foreman. > > https://github.com/eLobato/foreman/pull/11 > > > > Tests fully pass, however, I have to figure out why unit tests only pass > > when I run 'rake test', and functional tests only pass when I run 'rake > > test:functionals'. > > > > ### What's missing > > > > Most changes are retrocompatible with Rails 3, and I've been sending PRs > > to develop to include them. There are a few that are still open, the > > sooner they can get in, the better: > > > > - https://github.com/theforeman/foreman/pull/2768 > > - https://github.com/theforeman/foreman/pull/2763 > > - https://github.com/theforeman/foreman/pull/2757 > > - https://github.com/theforeman/foreman/pull/2754 > > > > There are a few other changes that can go in but haven't been submitted > > as PRs, I just have to figure out how to make these changes compatible. > > > > Some of the changes Rails 4 will introduce and affect our codebase the > > most are: > > - Friendly ID 5.0 > > - protected_attributes / strong_params (details below, consider > > protected_attributes a provisional measure to help us get in Rails 4 > > quickly) > > - minitest:runner is deprecated, we need to figure out other way of > > running plugin tests > > - hash_for_model is deprecated, but we brought it in > > https://github.com/eLobato/foreman/pull/11/files#diff-78dbfad830e0697757a21fd7672ce618R1 > > > > Aside from these drawbacks, tests run a heck of a lot faster, and in > > general response time is noticeably faster. There are many changes we > > can benefit from, read the release notes for more info: > > http://edgeguides.rubyonrails.org/4_0_release_notes.html > > http://edgeguides.rubyonrails.org/4_1_release_notes.html > > http://edgeguides.rubyonrails.org/4_2_release_notes.html > > > > > > ### What now? > > > > The roadmap I expect to follow is: > > - Get as many compatible changes in develop as possible. They can > > safely go in 1.10. > > - As soon as 1.10 is released (literally on the same day we should be > > ready), get in Rails 4 breaking changes, using protected_attributes, > > if Katello is ready (I reckon it should be) > > - I'll work on getting plugins Rails 4 compatible, both before and > > after the change, as I expect not all of them will be compatible and > > we might break Jenkins tests in some plugins for a couple of days. > > This is avoidable but I don't think is so terrible as long as > > Foreman and Katello remain green. In any case it'd be a short period > > if any, until plugins are able to run with Jenkins. > > - Since protected_attributes is too open, we don't want to > > ship 1.11 with that, and we should only consider it a temporary > > measure to allow us to develop 1.11 in Rails 4. > > - https://github.com/theforeman/foreman/pull/2509 should be > > worked on, and we should ship 1.11 with strong_params, mostly > > populated from the Apipie docs. > > > > ### What should you do if you're a plugin maintainer > > > > Please run your plugin tests against > > https://github.com/eLobato/foreman/tree/rails4_from_scratch > > and check for failures. Ping me on #theforeman-dev and I'll be glad to > > help you fixing issues or even fixing them myself. > > > > On 09/21, Tom Caspy wrote: > > > another update - I've opened a new PR > > > - https://github.com/theforeman/foreman/pull/2749 > > > this is just a reordering of the work I've done on the rails4 branch, and > > > removal of strong parameters to give way to protected_attributes > > > This branch should be in a better shape to get merged. > > > > > > Currently, tests are still failing (550ish on my machine), but most of them > > > are just from some lack of attr_accessible or attr_protected in models, > > > which should be fairly easy to fix. > > > > > > -- > > > 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+unsubscribe@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > Daniel Lobato Garcia > > > > @eLobatoss > > blog.daniellobato.me > > daniellobato.me > > > > GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 > > Keybase: https://keybase.io/elobato > > > > -- > Daniel Lobato Garcia > > @eLobatoss > blog.daniellobato.me > daniellobato.me > > GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 > Keybase: https://keybase.io/elobato

–
Daniel Lobato Garcia

@eLobatoss
blog.daniellobato.me
daniellobato.me

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

#9

> Code updates -
>
> We're trying to get more backward compatible changes in develop. Please
> try to run your plugin tests against
> https://github.com/eLobato/foreman/tree/rails4_from_scratch to get a
> feel of how it's working.

Is there a job to use to do this in jenkins? All the plugin jobs only
ask for a foreman branch, not a foreman repo to use.

··· On Wed, Oct 14, 2015 at 12:05:16PM +0200, Daniel Lobato Garcia wrote:

Packaging -

Soon we’re starting to work with packaging, Dominic more or less has a
plan we could follow:

Start rebuilding tfm against rh-ror41
(https://www.softwarecollections.org/en/scls/rhscl/rh-ror41/) and
change scl_ruby by scl_ror.

Update spec files to use scl_prefix_ror or scl_prefix_ruby, depending
on whether the package belongs to the ruby scl or the ror scl.

Rebuild all dependencies and the foreman SRPM on top and add/update
packages due to Gemfile changes.

I’ll start when I can as this week I don’t have much time to work on it
and next week I’m at a CentOS dojo talking about Foreman. Volunteers? :slight_smile:

On 10/07, Daniel Lobato Garcia wrote:

Quick update if you want to check out the diff of develop/non-compatible
Rails changes. It’s updated to the last change we’ve made to the rails4
branch.

Barring protected_attributes and .friendly changes, the diff is fairly
minimal as you can see. Hope it helps you understand the changes.

On 10/02, Daniel Lobato Garcia wrote:

Status update - almost there!

Where are we

I’ve been trying to understand the whole Rails 4 set of changes
originally written by Tom by trying to upgrade develop myself and
falling into the same issues. I’ve applied most of his fixes.
https://github.com/eLobato/foreman/commits/rails4_from_scratch

At this point, the diff between non-compatible Rails 4 changes and
develop + compatible changes is around 270 lines. Without
protected_attributes, “.friendly” calls, it’s around 150 lines, so I
hope it’s manageable to review in theforeman/foreman.
https://github.com/eLobato/foreman/pull/11

Tests fully pass, however, I have to figure out why unit tests only pass
when I run ‘rake test’, and functional tests only pass when I run ‘rake
test:functionals’.

What’s missing

Most changes are retrocompatible with Rails 3, and I’ve been sending PRs
to develop to include them. There are a few that are still open, the
sooner they can get in, the better:

There are a few other changes that can go in but haven’t been submitted
as PRs, I just have to figure out how to make these changes compatible.

Some of the changes Rails 4 will introduce and affect our codebase the
most are:

Aside from these drawbacks, tests run a heck of a lot faster, and in
general response time is noticeably faster. There are many changes we
can benefit from, read the release notes for more info:
http://edgeguides.rubyonrails.org/4_0_release_notes.html
http://edgeguides.rubyonrails.org/4_1_release_notes.html
http://edgeguides.rubyonrails.org/4_2_release_notes.html

What now?

The roadmap I expect to follow is:

  • Get as many compatible changes in develop as possible. They can
    safely go in 1.10.
  • As soon as 1.10 is released (literally on the same day we should be
    ready), get in Rails 4 breaking changes, using protected_attributes,
    if Katello is ready (I reckon it should be)
  • I’ll work on getting plugins Rails 4 compatible, both before and
    after the change, as I expect not all of them will be compatible and
    we might break Jenkins tests in some plugins for a couple of days.
    This is avoidable but I don’t think is so terrible as long as
    Foreman and Katello remain green. In any case it’d be a short period
    if any, until plugins are able to run with Jenkins.
  • Since protected_attributes is too open, we don’t want to
    ship 1.11 with that, and we should only consider it a temporary
    measure to allow us to develop 1.11 in Rails 4.
  • https://github.com/theforeman/foreman/pull/2509 should be
    worked on, and we should ship 1.11 with strong_params, mostly
    populated from the Apipie docs.

What should you do if you’re a plugin maintainer

Please run your plugin tests against
https://github.com/eLobato/foreman/tree/rails4_from_scratch
and check for failures. Ping me on #theforeman-dev and I’ll be glad to
help you fixing issues or even fixing them myself.

On 09/21, Tom Caspy wrote:

another update - I’ve opened a new PR

  • https://github.com/theforeman/foreman/pull/2749
    this is just a reordering of the work I’ve done on the rails4 branch, and
    removal of strong parameters to give way to protected_attributes
    This branch should be in a better shape to get merged.

Currently, tests are still failing (550ish on my machine), but most of them
are just from some lack of attr_accessible or attr_protected in models,
which should be fairly easy to fix.

–
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Daniel Lobato Garcia

@eLobatoss
blog.daniellobato.me
daniellobato.me

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

–
Daniel Lobato Garcia

@eLobatoss
blog.daniellobato.me
daniellobato.me

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

–
Daniel Lobato Garcia

@eLobatoss
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get&search=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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,

Stephen Benjamin
Red Hat Engineering

#10

> Code updates -
>
> We're trying to get more backward compatible changes in develop.
> Please try to run your plugin tests against
> https://github.com/eLobato/foreman/tree/rails4_from_scratch to get
> a feel of how it's working.
>
> Packaging -
>
> Soon we're starting to work with packaging, Dominic more or less
> has a plan we could follow:

This is specifically RPM packaging. No change should be required
for our Debian packages, since they work identically to a source
installation with Bundler.

> Start rebuilding tfm against rh-ror41
> (https://www.softwarecollections.org/en/scls/rhscl/rh-ror41/) and
> change scl_ruby by scl_ror.
>
> Update spec files to use scl_prefix_ror or scl_prefix_ruby,
> depending on whether the package belongs to the ruby scl or the ror
> scl.

There's also a script in the tfm/ directory in rpm/develop which I
used for the tfm SCL conversion. It can probably be modified to
update spec files in this case.

Lots of conditionals will also change, since the packages are
significantly different, e.g. now the core Ruby packages will provide
ruby(release) instead of ruby(abi).

> Rebuild all dependencies and the foreman SRPM on top and
> add/update packages due to Gemfile changes.

https://gist.github.com/domcleal/9b8f1fadd95188d0df23 is a rebuild
order list, derived from mockchain --recurse. Roughly the same ought
to work still.

> I'll start when I can as this week I don't have much time to work
> on it and next week I'm at a CentOS dojo talking about Foreman.
> Volunteers? :slight_smile:

I'll of course review any PRs to foreman-packaging, else if there
isn't one then I'll try and find some time from the middle/end of next
week to take a look at the subject.

Dominic Cleal
dominic@cleal.org

··· On 14/10/15 12:05, Daniel Lobato Garcia wrote:
#11

I've added a foreman_repo parameter to:

http://ci.theforeman.org/job/test_plugin_matrix/
http://ci.theforeman.org/job/test_plugin_pull_request/

Hopefully that'll do the trick for you. Let me know if not.

Dominic Cleal
dominic@cleal.org

··· On 14/10/15 15:56, Stephen Benjamin wrote: > On Wed, Oct 14, 2015 at 12:05:16PM +0200, Daniel Lobato Garcia > wrote: >>> Code updates - >>> >>> We're trying to get more backward compatible changes in >>> develop. Please try to run your plugin tests against >>> https://github.com/eLobato/foreman/tree/rails4_from_scratch to >>> get a feel of how it's working. > Is there a job to use to do this in jenkins? All the plugin jobs > only ask for a foreman branch, not a foreman repo to use.
#12

Dominic,

This change to foreman-tasks allows it to work with rails4.

https://github.com/cpeters/foreman-tasks/blob/29e32256fffe1228112c952ab04a4bb9faaf20a4/lib/foreman_tasks/engine.rb#L60-L64

-Chris

··· On Wednesday, October 14, 2015 at 12:23:12 PM UTC-4, stephen wrote: > > On Wed, Oct 14, 2015 at 04:09:23PM +0200, Dominic Cleal wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 14/10/15 15:56, Stephen Benjamin wrote: > > > On Wed, Oct 14, 2015 at 12:05:16PM +0200, Daniel Lobato Garcia > > > wrote: > > >>> Code updates - > > >>> > > >>> We're trying to get more backward compatible changes in > > >>> develop. Please try to run your plugin tests against > > >>> https://github.com/eLobato/foreman/tree/rails4_from_scratch to > > >>> get a feel of how it's working. > > > Is there a job to use to do this in jenkins? All the plugin jobs > > > only ask for a foreman branch, not a foreman repo to use. > > > > I've added a foreman_repo parameter to: > > > > http://ci.theforeman.org/job/test_plugin_matrix/ > > http://ci.theforeman.org/job/test_plugin_pull_request/ > > > > Hopefully that'll do the trick for you. Let me know if not. > > Yup, thanks, it looks like it might have worked if my plugin didn't > explode at initialization. > > Is there any plugin that's passing against the rails4 branch that I can > look at? > > This: > > initializer 'foreman_salt.load_app_instance_data' do |app| > app.config.paths['db/migrate'] += > ForemanSalt::Engine.paths['db/migrate'].existent > end > > fails with: > > 16:16:56 NoMethodError: undefined method `+' for > # > > > > > - -- > > Dominic Cleal > > dom...@cleal.org > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2 > > > > iEYEARECAAYFAlYeYhEACgkQfH0ybywrcsyDRQCgzh+sLmxmfrpxY9EXquxwCpMf > > Fh4An1B4VhJ4r1JL4u8bBt+iHGUJXVex > > =agP5 > > -----END PGP SIGNATURE----- > > > > -- > > 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...@googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > > -- > Best Regards, > > Stephen Benjamin > Red Hat Engineering >
#13

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >>> Code updates -
> >>>
> >>> We're trying to get more backward compatible changes in
> >>> develop. Please try to run your plugin tests against
> >>> https://github.com/eLobato/foreman/tree/rails4_from_scratch to
> >>> get a feel of how it's working.
> > Is there a job to use to do this in jenkins? All the plugin jobs
> > only ask for a foreman branch, not a foreman repo to use.
>
> I've added a foreman_repo parameter to:
>
> http://ci.theforeman.org/job/test_plugin_matrix/
> http://ci.theforeman.org/job/test_plugin_pull_request/
>
> Hopefully that'll do the trick for you. Let me know if not.

Yup, thanks, it looks like it might have worked if my plugin didn't
explode at initialization.

Is there any plugin that's passing against the rails4 branch that I can
look at?

This:

initializer 'foreman_salt.load_app_instance_data' do |app|
  app.config.paths['db/migrate'] += ForemanSalt::Engine.paths['db/migrate'].existent
end

fails with:

16:16:56 NoMethodError: undefined method `+' for #<Rails::Paths::Path:0x000000044c7a08>

··· On Wed, Oct 14, 2015 at 04:09:23PM +0200, Dominic Cleal wrote: > On 14/10/15 15:56, Stephen Benjamin wrote: > > On Wed, Oct 14, 2015 at 12:05:16PM +0200, Daniel Lobato Garcia > > wrote:

Dominic Cleal
dominic@cleal.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlYeYhEACgkQfH0ybywrcsyDRQCgzh+sLmxmfrpxY9EXquxwCpMf
Fh4An1B4VhJ4r1JL4u8bBt+iHGUJXVex
=agP5
-----END PGP SIGNATURE-----

–
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,

Stephen Benjamin
Red Hat Engineering

#14

> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > >>> Code updates -
> > >>>
> > >>> We're trying to get more backward compatible changes in
> > >>> develop. Please try to run your plugin tests against
> > >>> https://github.com/eLobato/foreman/tree/rails4_from_scratch to
> > >>> get a feel of how it's working.
> > > Is there a job to use to do this in jenkins? All the plugin jobs
> > > only ask for a foreman branch, not a foreman repo to use.
> >
> > I've added a foreman_repo parameter to:
> >
> > http://ci.theforeman.org/job/test_plugin_matrix/
> > http://ci.theforeman.org/job/test_plugin_pull_request/
> >
> > Hopefully that'll do the trick for you. Let me know if not.
>
> Yup, thanks, it looks like it might have worked if my plugin didn't
> explode at initialization.
>
> Is there any plugin that's passing against the rails4 branch that I can
> look at?
>
> This:
>
> initializer 'foreman_salt.load_app_instance_data' do |app|
> app.config.paths['db/migrate'] += ForemanSalt::Engine.paths['db/migrate'].existent
> end
>
> fails with:
>
> 16:16:56 NoMethodError: undefined method `+' for #<Rails::Paths::Path:0x000000044c7a08>

Got an answer on IRC. In case anyone else needs it:
https://github.com/cpeters/foreman-tasks/blob/29e32256fffe1228112c952ab04a4bb9faaf20a4/lib/foreman_tasks/engine.rb#L60-L64

··· On Wed, Oct 14, 2015 at 12:23:09PM -0400, Stephen Benjamin wrote: > On Wed, Oct 14, 2015 at 04:09:23PM +0200, Dominic Cleal wrote: > > On 14/10/15 15:56, Stephen Benjamin wrote: > > > On Wed, Oct 14, 2015 at 12:05:16PM +0200, Daniel Lobato Garcia > > > wrote:

Dominic Cleal
dominic@cleal.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlYeYhEACgkQfH0ybywrcsyDRQCgzh+sLmxmfrpxY9EXquxwCpMf
Fh4An1B4VhJ4r1JL4u8bBt+iHGUJXVex
=agP5
-----END PGP SIGNATURE-----

–
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,

Stephen Benjamin
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,

Stephen Benjamin
Red Hat Engineering

#15

>> Start rebuilding tfm against rh-ror41
>> (https://www.softwarecollections.org/en/scls/rhscl/rh-ror41/) and
>> change scl_ruby by scl_ror.

I did this quite easily, link and branch in
Feature #7228: Rebuild packages under ror41/ruby22 SCLs - Packaging - Foreman.

>> Update spec files to use scl_prefix_ror or scl_prefix_ruby,
>> depending on whether the package belongs to the ruby scl or the
>> ror scl.
>
> There's also a script in the tfm/ directory in rpm/develop which I
> used for the tfm SCL conversion. It can probably be modified to
> update spec files in this case.
>
> Lots of conditionals will also change, since the packages are
> significantly different, e.g. now the core Ruby packages will
> provide ruby(release) instead of ruby(abi).

I'm hoping the standardisation of spec files will mean there aren't
too many permutations, but I'll work on this next.

Dominic Cleal
dominic@cleal.org

··· On 14/10/15 11:19, Dominic Cleal wrote: > On 14/10/15 12:05, Daniel Lobato Garcia wrote:
#16

Now opened as a pull request and with an EL7 test repo (for the brave):
https://github.com/theforeman/foreman-packaging/pull/877

I've reached the point where I can build and run Foreman successfully
from RPMs, with only a few hacks.

There are some bugs reported against the Foreman PR that affect
building of many plugins, but once fixed then I should be able to
proceed with those too - when plugins themselves have any necessary
Rails 4 compatibility fixes released.

Dominic Cleal
dominic@cleal.org

··· On 28/10/15 14:59, Dominic Cleal wrote: > On 14/10/15 11:19, Dominic Cleal wrote: >> On 14/10/15 12:05, Daniel Lobato Garcia wrote: >>> Start rebuilding tfm against rh-ror41 >>> (https://www.softwarecollections.org/en/scls/rhscl/rh-ror41/) >>> and change scl_ruby by scl_ror. > > I did this quite easily, link and branch in > http://projects.theforeman.org/issues/7228#note-7.
#17

> Now opened as a pull request and with an EL7 test repo (for the
> brave): https://github.com/theforeman/foreman-packaging/pull/877

EL6 repo added and non-SCL builds are running at the moment.

> I've reached the point where I can build and run Foreman
> successfully from RPMs, with only a few hacks.
>
> There are some bugs reported against the Foreman PR that affect
> building of many plugins

Just asset compilation now:
https://github.com/theforeman/foreman/pull/2870#issuecomment-153691278.

> but once fixed then I should be able to proceed with those too -
> when plugins themselves have any necessary Rails 4 compatibility
> fixes released.

The "Test failures on Ruby 2.2" ticket at
Bug #12219: Test failures on Ruby 2.2 - Foreman must be fixed too so that
2.2 can be added to our test matrix and we can package safely against
that version.

Dominic Cleal
dominic@cleal.org

··· On 04/11/15 14:42, Dominic Cleal wrote:
#18

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> Now opened as a pull request and with an EL7 test repo (for the
>> brave): https://github.com/theforeman/foreman-packaging/pull/877
>
> EL6 repo added and non-SCL builds are running at the moment.
>
>> I've reached the point where I can build and run Foreman
>> successfully from RPMs, with only a few hacks.
>>
>> There are some bugs reported against the Foreman PR that affect
>> building of many plugins
>
> Just asset compilation now:
> https://github.com/theforeman/foreman/pull/2870#issuecomment-153691278.
>
>> but once fixed then I should be able to proceed with those too -
>> when plugins themselves have any necessary Rails 4 compatibility
>> fixes released.
>
> The "Test failures on Ruby 2.2" ticket at
> Bug #12219: Test failures on Ruby 2.2 - Foreman must be fixed too so that
> 2.2 can be added to our test matrix and we can package safely against
> that version.
>

I’ll pick it up. Two failures around skipped tests are easy to deal
with; will see what the hostname failure is about.
-d

··· On Wed, Nov 11, 2015 at 12:10 PM, Dominic Cleal wrote: > On 04/11/15 14:42, Dominic Cleal wrote:

Dominic Cleal
dominic@cleal.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlZDMDoACgkQfH0ybywrcsxmmACgvIPm3EWoyGV6wuwNibh2KOZu
qwAAoId/9yF5dou7Hv6Zs+aYnND9AtEB
=hMSm
-----END PGP SIGNATURE-----

–
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#19

Thanks Dmitri. The failure on PostgreSQL loading the library version is
also rather concerning, but it seemed very consistent. I haven't tried
to reproduce it locally yet, so shout if you struggle to do so.

··· On 11/11/15 12:19, Dmitri Dolguikh wrote: > On Wed, Nov 11, 2015 at 12:10 PM, Dominic Cleal wrote: >> > The "Test failures on Ruby 2.2" ticket at >> > http://projects.theforeman.org/issues/12219 must be fixed too so that >> > 2.2 can be added to our test matrix and we can package safely against >> > that version. >> > > I’ll pick it up. Two failures around skipped tests are easy to deal > with; will see what the hostname failure is about.

–
Dominic Cleal
dominic@cleal.org

#20

I can't reproduce that bug anymore, on the Rails 4 branch tests on postgres
& Ruby 2.2 seem to pass just like the rest.

··· On 11/11, Dominic Cleal wrote: > On 11/11/15 12:19, Dmitri Dolguikh wrote: > > On Wed, Nov 11, 2015 at 12:10 PM, Dominic Cleal wrote: > >> > The "Test failures on Ruby 2.2" ticket at > >> > http://projects.theforeman.org/issues/12219 must be fixed too so that > >> > 2.2 can be added to our test matrix and we can package safely against > >> > that version. > >> > > > I’ll pick it up. Two failures around skipped tests are easy to deal > > with; will see what the hostname failure is about. > > Thanks Dmitri. The failure on PostgreSQL loading the library version is > also rather concerning, but it seemed very consistent. I haven't tried > to reproduce it locally yet, so shout if you struggle to do so.

Last thursday we had a call with Katello developers working on Rails 4
as well and it seems like all major projects should be ready. The PR in
core https://github.com/theforeman/foreman/pull/2870 passes w/o the
memory issues it used to have, and Katello seems to be consistently
green as well.

We proposed Tuesday Dec 15th as the merge day, the reason being that
right now it can be merged, and delaying it more means delaying other
big features coming in such as facets or Patternfly.

Not to mention maintaining the rails4 branch and all projects passing
tests in sync is a burden on some developers that we can get rid of
quickly after merging.

Third, the sooner we get this in, the more testing it will get before
1.11. I will move my local ‘production’ foreman to nightly to iron out
possible common bugs :slight_smile:

Does that sound good, is there anything anyone would like to do before
merging, etc? If not, let’s not merge any major changes on Monday and
let’s tackle this on Tuesday asap. Is there anyone that can merge Rails
4 on Katello in any European timezone?

–
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

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