Return-Path: <issues-return-36499-archive-asf-public=cust-asf.ponee.io@ambari.apache.org>
X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io
Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io
Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183])
	by cust-asf2.ponee.io (Postfix) with ESMTP id A18C1200BF8
	for <archive-asf-public-internal@cust-asf2.ponee.io>; Fri, 13 Jan 2017 15:36:32 +0100 (CET)
Received: by cust-asf.ponee.io (Postfix)
	id A02D6160B47; Fri, 13 Jan 2017 14:36:32 +0000 (UTC)
Delivered-To: archive-asf-public@cust-asf.ponee.io
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by cust-asf.ponee.io (Postfix) with SMTP id 1B9E8160B32
	for <archive-asf-public@cust-asf.ponee.io>; Fri, 13 Jan 2017 15:36:31 +0100 (CET)
Received: (qmail 4177 invoked by uid 500); 13 Jan 2017 14:36:28 -0000
Mailing-List: contact issues-help@ambari.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@ambari.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@ambari.apache.org>
List-Post: <mailto:issues@ambari.apache.org>
List-Id: <issues.ambari.apache.org>
Reply-To: dev@ambari.apache.org
Delivered-To: mailing list issues@ambari.apache.org
Received: (qmail 4131 invoked by uid 99); 13 Jan 2017 14:36:28 -0000
Received: from Unknown (HELO jira-lw-us.apache.org) (207.244.88.139)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jan 2017 14:36:28 +0000
Received: from jira-lw-us.apache.org (localhost [127.0.0.1])
	by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 6455E25281
	for <issues@ambari.apache.org>; Fri, 13 Jan 2017 14:36:26 +0000 (UTC)
Date: Fri, 13 Jan 2017 14:36:26 +0000 (UTC)
From: "Nate Cole (JIRA)" <jira@apache.org>
To: issues@ambari.apache.org
Message-ID: <JIRA.13034673.1484318134000.2576.1484318186408@Atlassian.JIRA>
In-Reply-To: <JIRA.13034673.1484318134000@Atlassian.JIRA>
References: <JIRA.13034673.1484318134000@Atlassian.JIRA> <JIRA.13034673.1484318134321@jira-lw-us.apache.org>
Subject: [jira] [Created] (AMBARI-19527) Downgrade executes <pre-upgrade>
 section if <pre-downgrade> is not defined
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
archived-at: Fri, 13 Jan 2017 14:36:32 -0000

Nate Cole created AMBARI-19527:
----------------------------------

             Summary: Downgrade executes <pre-upgrade> section if <pre-downgrade> is not defined
                 Key: AMBARI-19527
                 URL: https://issues.apache.org/jira/browse/AMBARI-19527
             Project: Ambari
          Issue Type: Bug
          Components: ambari-server
            Reporter: Nate Cole
            Assignee: Nate Cole
            Priority: Critical
             Fix For: 2.5.0


When creating the initial upgrade packs, an effort was made to make them as least-verbose as possible.  In that, we assumed that all tasks that occurred during an Upgrade would also occur on a Downgrade.  That assumption led to some sneaky bugs that are difficult to troubleshoot.

The real fix is to make the XSD enforce "sibling" elements, such that when PRE-UPGRADE tasks are defined, you can enforce that a PRE-DOWNGRADE element exist.  Unfortunately, the JDK (even 1.8) doesn't support that version of XSD in JAXB.

The interim solution was to use the afterUnmarshal secret sauce to validate that the elements exist.  Allow a pre-downgrade or post-downgrade element to indicate that it can reuse the (pre-post)upgrade element definitions.

Many of the changes here are in upgrade packs to add the new required elements, and the unit test that parses all upgrade packs passes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)