hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allen Wittenauer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-1822) Editlog opcodes overlap between 20 security and later releases
Date Tue, 12 Apr 2011 01:51:06 GMT

    [ https://issues.apache.org/jira/browse/HDFS-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018672#comment-13018672

Allen Wittenauer commented on HDFS-1822:

bq. Why a tarball suddenly becomes so important? I am surprised. Do you count 0.22 or 0.23?
The tarballs are not out there yet.

Why are you surprised by this?  Of course an official Apache tarball is important. How do
you think users install Apache releases?  

No, 0.20.4, 0.21.1, 0.22 and 0.23 aren't real releases (yet?) either.  Until a batch of code
goes through the Apache release process, they aren't Apache branded distributions.

bq. Once a release is out, we are not allow to make incompatible changes but changing opcodes
is fine as long as the layout version is updated and it is backward compatible. As mentioned
earlier, opcode is not necessarily unique across different layout versions.

Have we ever declared that anywhere? What happens if FBBDoAH has a custom opscode that is
different than Apache's?  Would we accept a patch to parse it just like this patch proposes?

In reality, doesn't this ultimately mean that we should not be performing upgrades if an editslog
exists? In other words, the previous editslog should be fully digested before the next release
is put in place.  (This is also a great practice anyway, so reinforcing that would be good.)
 This seems like a much more acceptable idea rather than opening the door for every random
fork compatibility patch.

bq. "if a patch is only fixing a private distribution but not Apache Hadoop trunk/branches"

But there is nothing wrong with trunk.  In fact, these opcodes were released in 0.21.  Shouldn't
this patch be against the unreleased branch to bring it in line with trunk?  Or do we think
that unreleased branches have more importance than trunk?

> Editlog opcodes overlap between 20 security and later releases
> --------------------------------------------------------------
>                 Key: HDFS-1822
>                 URL: https://issues.apache.org/jira/browse/HDFS-1822
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: name-node
>    Affects Versions: 0.21.0, 0.22.0, 0.23.0
>            Reporter: Suresh Srinivas
>            Assignee: Suresh Srinivas
>            Priority: Blocker
>             Fix For: 0.22.0, 0.23.0
>         Attachments: HDFS-1822.patch
> Same opcode are used for different operations between 0.20.security, 0.22 and 0.23. This
results in failure to load editlogs on later release, especially during upgrades.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message