Backwards incompatible change: PowerDNS (2.9.x to 3.1.x)

[James Findley]

Hi,

 I noticed that pdns was recently (October) updated to 3.1 from 2.9. As
http://doc.powerdns.com/changelog.html#changelog-auth-3-1 and
http://doc.powerdns.com/upgrades.html#from2.9to3.0 notes this is a major upgrade that
requires schema updates to the database, will cause powerdns to fail to start for some
configs, may change the answers returned and may negatively affect performance.

 This probably should not have been done at all, and definitely not without some mention
of these issues in the RPM changelog and ideally a postscript to fix configs, DB schema,
etc.

 We are fortunate that we rigourously test every new EPEL update before we update any live
servers - but if there are going to be major changes like this in EPEL, some way of
warning people that use the repository would be useful as there are many people out there
who trust EPEL not to break their systems.


 Thanks,

 James

[Lars Kellogg-Stedman]

On Mon, Nov 26, 2012 at 01:52:16PM +0100, James Findley wrote:
>     This probably should not have been done at all, and definitely not
> without
>     some mention of these issues in the RPM changelog and ideally a postscript
>     to fix configs, DB schema, etc. 
I would vote exclusively for the "should not have been done at all"
sentiment, since in general it can be difficult to completely automate
the process of upgrading between major versions of anything.

I was recently bitten by exactly the same issue with the OpenStack
Essex -> Folsom upgrade.  And in fact we also got bitten earlier this
year by the Cobbler upgrade that replaced the mod_python based
configuration with one based on mod_wsgi.

There was some recent discussion about performing another major
version upgrade to Puppet (by moving the "puppet" package in EPEL from
2.x to 3.x).  I hope *that* never happens.

I would really rather see this sort of thing relegated to a separate
"epel-exciting" repository (or, you know, "Fedora").

-- 
Lars Kellogg-Stedman <lars(a)seas.harvard.edu&gt;  |
Senior Technologist                           | http://ac.seas.harvard.edu/
Academic Computing                            | http://code.seas.harvard.edu/
Harvard School of Engineering                 |
  and Applied Sciences                        |

[Ken Dreyer]

On Mon, Nov 26, 2012 at 8:43 AM, Lars Kellogg-Stedman
<lars(a)seas.harvard.edu&gt; wrote:
>  There was some recent discussion about performing another major
>  version upgrade to Puppet (by moving the "puppet" package in EPEL from
>  2.x to 3.x).  I hope *that* never happens. 
EPEL 6 will be around until November 2020. The upstream Puppet project
will not maintain the 2.6.x branch for another seven years. Eventually
we will have to upgrade.

- Ken

[Toshio Kuratomi]

On Nov 26, 2012 7:52 AM, "Ken Dreyer" <ktdreyer(a)ktdreyer.com&gt; wrote:
>  On Mon, Nov 26, 2012 at 8:43 AM, Lars Kellogg-Stedman
>  <lars(a)seas.harvard.edu&gt; wrote:
>  > There was some recent discussion about performing another major
>  > version upgrade to Puppet (by moving the "puppet" package in EPEL from
>  > 2.x to 3.x).  I hope *that* never happens.
>
>  EPEL 6 will be around until November 2020. The upstream Puppet project
>  will not maintain the 2.6.x branch for another seven years. Eventually
>  we will have to upgrade. 
Just to add a historical note: this was a point of contention during the
founding of EPEL as well.  Some argued that maintainers should be required
to backport fixes to the packages just like in RHEL.  Others argued that
you could't require that sort of commitment from unpaid maintainers so the
more Fedora style of upgrading to get fixes was appropriate.

The very first epel thread:
http://www.redhat.com/archives/epel-devel-list/2007-February/thread.html#...

Continued:
http://www.redhat.com/archives/epel-devel-list/2007-March/msg00001.html
http://www.redhat.com/archives/epel-devel-list/2007-March/msg00000.html

[Morten Stevens]

On 26.11.2012 13:52, James Findley wrote:
>  I noticed that pdns was recently (October) updated to 3.1 from 2.9.
>    As http://doc.powerdns.com/changelog.html#changelog-auth-3-1
>  and http://doc.powerdns.com/upgrades.html#from2.9to3.0 notes this is a
>  major upgrade that requires schema updates to the database, will cause
>  powerdns to fail to start for some configs, may change the answers
>  returned and may negatively affect performance. 
Hi,

The database schema from pdns 2.9.22 is still compatible with pdns 3.x.

Please see:
http://doc.powerdns.com/upgrades.html#from2.9to3.0

>  Can 3.x versions read the 2.9 pre-DNSSEC database schema? 
>  Yes, as long as the relevant '-dnssec' setting is not
> enabled. These 
>  settings are typically called 'gmysql-dnssec', 'gpgsql-dnssec', 
>  'gsqlite3-dnssec'. If this setting IS enabled, 3.x expects the new 
>  schema to be in place. 
>  PowerDNS Authoritative Server 3.0 comes with DNSSEC support, but this
>
>  has required big changes to database schemas. Each backend lists the 
>  changes required. To facilitate a smooth upgrade, the old, non-DNSSEC 
>  schema is used by default. 
There will be no issue with the old 2.9.22 non-DNSSEC database schema 
with 3.x, because pdns 3.x uses by default the old non-DNSSEC database 
schema. You'll need big database changes only for DNSSEC. Since the old 
version (2.9.22) doesn't support DNSSEC this shouldn't be a problem.

Furthermore, the configuration from 2.9.22 in /etc/pdns/pdns.conf is 
also fully compatible with pdns 3.x.

On 26.11.2012 16:51, Ken Dreyer wrote:
>  EPEL 6 will be around until November 2020. 
That's exactly the point, also for PowerDNS. The upstream project will 
not maintain the old 2.9.x branch until 2020. For security reasons, I 
think it is necessary to upgrade to the 3.x branch. (to make sure that 
we get security related patches for PowerDNS) Furthermore, many bugs 
have been fixed since 2.9.22 and pdns 3.x supports DNSSEC.

>  This probably should not have been done at all, and definitely not
>  without some mention of these issues in the RPM changelog and ideally a
>  postscript to fix configs, DB schema, etc. 
You don't need to fix the database schema or the configuration file, 
because pdns 3.x uses by default the old non-DNSSEC database schema and 
the pdns.conf file is still compatible.

Thank you for your understanding.

Best regards,

Morten