Bug in migration of interfaces for release >= 1.8

I have been in the process of upgrading from 1.6 to 1.10, going to 1.7 and
1.8 first. When I hit 1.7 I wrote a Rails runner script to update the
primary_interface to the correct value based on facts and then also
updating a host's interface identifiers based on facts. I saw
in db/migrate/20140910153654_move_host_nics_to_interfaces.rb that this
primary_interface attribute would get used though was not entirely sure how
to set it outside Rails scripting.

Even once I set primary_interface for a Host, the upgrade to 1.8 set the
primary interface for all systems to "eth0" even when 300 of my servers had
"eth1" set for primary_interface. This simple patch solves the problem:

class MoveHostNicsToInterfaces < ActiveRecord::Migration
@@ -26,7 +31,7 @@ class MoveHostNicsToInterfaces < ActiveRecord::Migration
nic.subnet_id = host.attributes.with_indifferent_access[:subnet_id]
nic.domain_id = host.attributes.with_indifferent_access[:domain_id]
nic.virtual = false

  •  nic.identifier = host.primary_interface || &quot;eth0&quot;
    
  •  nic.identifier = 
    

host.attributes.with_indifferent_access[:primary_interface] || "eth0"

I noticed that if I diff that migration from 1.8 against current develop
branch that there have been attr_accessible items added to the fake
classes. The attr_accessible primary_interface MAY solve this problem,
though have not tested. Would it violate the Foreman release policy to get
these patches into a 1.8.5 release? Maybe this is a discussion for
foreman-users, but it was my understanding based on docs that upgrading
from 1.6 to 1.10 required 1.6->1.7->1.8…etc which would make patches
after 1.8 to migrations introduced in 1.8 sort of broken in terms of having
a clean upgrade path by doing one release at a time.

Thanks,

  • Trey

> I noticed that if I diff that migration from 1.8 against current develop
> branch that there have been attr_accessible items added to the fake
> classes. The attr_accessible primary_interface MAY solve this problem,
> though have not tested.

I doubt that's related…

> Would it violate the Foreman release policy to
> get these patches into a 1.8.5 release?

It would, because I try to only manage one major stable release at a
time with a short overlap of two. I'm not willing to make any more
1.8.x releases now, it's been stopped for too long now (5 months). 1.9
is also closed.

> Maybe this is a discussion for
> foreman-users, but it was my understanding based on docs that upgrading
> from 1.6 to 1.10 required 1.6->1.7->1.8…etc which would make patches
> after 1.8 to migrations introduced in 1.8 sort of broken in terms of
> having a clean upgrade path by doing one release at a time.

It's just that the big jump isn't tested, so there can be bugs in DB
migrations that don't work when using a much older DB against a newer
codebase (e.g. #12669).

I'd suggest proposing the patch first for develop, then it might get
into 1.10.x if it's accepted in time and it's suitable.

··· On 09/02/16 18:36, Trey Dockendorf wrote:


Dominic Cleal
dominic@cleal.org

>
>
>
> I'd suggest proposing the patch first for develop, then it might get
> into 1.10.x if it's accepted in time and it's suitable.
>

PR submitted: https://github.com/theforeman/foreman/pull/3173

Thanks,

  • Trey