settingsLogin | Registersettings

[openstack-dev] [ironic] automatic migration from classic drivers to hardware types?

0 votes

Hi folks!

This was raised several times, now I want to bring it to the wider audience.
We're planning [1] to deprecate classic drivers in Queens and remove them in
Rocky. It was pointed at the Forum that we'd better provide an automatic migration.

I'd like to hear your opinion on the options:

(1) Migration as part of 'ironic-dbsync upgrade'

Pros:
* nothing new to do for the operators

Cons:
* upgrade will fail completely, if for some nodes the matching hardware types
and/or interfaces are not enabled in ironic.conf

(2) A separate script for migration

Pros:
* can be done in advance (even while still on Pike)
* a failure won't fail the whole upgrade
* will rely on drivers enabled in actually running conductors, not on ironic.conf

Cons:
* a new upgrade action before Rocky
* won't be available in packaging
* unclear how to update nodes that are in some process (e.g. cleaning), will
probably have to be run several times

(3) Migration as part of 'ironic-dbsync onlinedatamigration'

Pros:
* nothing new to do for the operators, similar to (1)
* probably a more natural place to do this than (1)
* can rely on drivers enabled in actually running conductors, not on ironic.conf

Cons:
* data migration will fail, if for some nodes the matching hardware types and/or
interfaces are not enabled in ironic.conf

(4) Do nothing, let operators handle the migration.

The most reasonable option for me seems (3), then (4). What do you think?

Dmitry

[1]
http://specs.openstack.org/openstack/ironic-specs/specs/approved/classic-drivers-future.html


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Nov 14, 2017 in openstack-dev by Dmitry_Tantsur (18,080 points)   2 3 4

1 Response

0 votes

On Tue, Nov 14, 2017 at 8:10 AM, Dmitry Tantsur dtantsur@redhat.com wrote:
Hi folks!

This was raised several times, now I want to bring it to the wider audience.
We're planning [1] to deprecate classic drivers in Queens and remove them in
Rocky. It was pointed at the Forum that we'd better provide an automatic
migration.

I'd like to hear your opinion on the options:

(1) Migration as part of 'ironic-dbsync upgrade'

Pros:
* nothing new to do for the operators

Cons:
* upgrade will fail completely, if for some nodes the matching hardware
types and/or interfaces are not enabled in ironic.conf

(2) A separate script for migration

Pros:
* can be done in advance (even while still on Pike)
* a failure won't fail the whole upgrade
* will rely on drivers enabled in actually running conductors, not on
ironic.conf

Cons:
* a new upgrade action before Rocky
* won't be available in packaging
* unclear how to update nodes that are in some process (e.g. cleaning), will
probably have to be run several times

(3) Migration as part of 'ironic-dbsync onlinedatamigration'

Pros:
* nothing new to do for the operators, similar to (1)
* probably a more natural place to do this than (1)
* can rely on drivers enabled in actually running conductors, not on
ironic.conf

Cons:
* data migration will fail, if for some nodes the matching hardware types
and/or interfaces are not enabled in ironic.conf

Rather than fail in various ways, why not do like what nova has with a
pre-upgrade status check[0] and then just handle it in ironic-dbsync
upgrade? This would allow operators to check prior to running the
upgrade to understand what might need to be changed. Additionally the
upgrade command itself could leverage the status check to fail nicely.

(4) Do nothing, let operators handle the migration.

Please no.

The most reasonable option for me seems (3), then (4). What do you think?

So this was chatted about in relation to some environment tooling we
have where we currently have where older 'pxe_ipmitool' defined and
this will need to switch to be 'ipmi'[1]. The issue with the hard
cutover on this one is any tooling which may have been written that
currently works with multiple openstack releases to generate the
required json for ironic will now have to take that into account. I
know in our case we'll be needing to support newton for longer so
making the tooling openstack aware around this is just further
tech-debt that we'll be creating. Is there a better solution that
could be done either in ironic client or in the API to gracefully
handle this transition for a longer period of time? I think this may
be one of those decisions that has a far reaching impact on
deployers/operators due changes they will have to make to support
multiple versions or as they upgrade between versions and they aren't
fully aware of yet as many may not be on Ocata. This change seems
like it has a high UX impact and IMHO should be done very carefully.

Thanks,
-Alex

[0] https://docs.openstack.org/nova/pike/cli/nova-status.html
[1] http://eavesdrop.openstack.org/irclogs/%23tripleo/%23tripleo.2017-11-14.log.html#t2017-11-14T15:36:45

Dmitry

[1]
http://specs.openstack.org/openstack/ironic-specs/specs/approved/classic-drivers-future.html


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 14, 2017 by aschultz_at_redhat.c (5,800 points)   2 2 2
...