ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alejandro Fernandez" <afernan...@hortonworks.com>
Subject Re: Review Request 33655: Full Delete of Host : Fix UpgradeCatalogs to handle host-related changes in 1.6.1, 1.7.0, and 2.0.0 after refactoring Entity models
Date Thu, 30 Apr 2015 19:30:20 GMT


> On April 30, 2015, 7:22 p.m., Jonathan Hurley wrote:
> > It's still hard to believe we need to move away from entities, but I guess we're
handcuffed with our upgrade framework here. I still dislike this whole raw SQL approach. There's
no way to run pre-upgrade code that creates the associations the entities need? I mean, in
this case, it's changing host name to ID in a bunch of tables; once that's done won't all
of the entities just work? 
> > 
> > What if you did the necessary association work before any of the DML updates. Thoughts?

Eventually I want to find an elegant and simple solution for this. For the purposes of getting
it to work, I'm ok with using raw SQL.


- Alejandro


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33655/#review82183
-----------------------------------------------------------


On April 29, 2015, 10:24 p.m., Alejandro Fernandez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33655/
> -----------------------------------------------------------
> 
> (Updated April 29, 2015, 10:24 p.m.)
> 
> 
> Review request for Ambari, Dmitro Lisnichenko, Jonathan Hurley, Sumit Mohanty, and Sid
Wagle.
> 
> 
> Bugs: AMBARI-10170
>     https://issues.apache.org/jira/browse/AMBARI-10170
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> The older upgrade catalogs cannot use any of Entity models that are related to the hosts
table because the host_name is no longer present (instead the host_id).
> For this reason, I changed the UpgradeCatalogs to use raw SQL.
> 
> 
> Diffs
> -----
> 
>   ambari-server/src/main/java/org/apache/ambari/server/orm/DBAccessor.java 2b01c72 
>   ambari-server/src/main/java/org/apache/ambari/server/orm/DBAccessorImpl.java 29cf755

>   ambari-server/src/main/java/org/apache/ambari/server/upgrade/AbstractUpgradeCatalog.java
940be93 
>   ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog161.java
ac8bb52 
>   ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog170.java
23ffad0 
>   ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog200.java
4117a1c 
>   ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog200Test.java
804aa60 
> 
> Diff: https://reviews.apache.org/r/33655/diff/
> 
> 
> Testing
> -------
> 
> Created VMs with each of the following Ambari versions and tested these upgrade paths.
>                            2.0.0 -> 2.1.0 (has known issues due to XML properties)
>                   1.7.0 -> 2.0.0 -> 2.1.0 (has known issues due to the stacks table,
this removed Nagios service, which was tested in UpgradeCatalog200)
>          1.6.1 -> 1.7.0 -> 2.0.0 -> 2.1.0 (has known issues due to the stacks
table, this updated the host_role_command table, which was tested in UpgradeCatalog170)
> 1.6.0 -> 1.6.1 -> 1.7.0 -> 2.0.0 -> 2.1.0
> 
> To get these work, I had to comment out certain functions that are known to fail today.
> 
> I ran local unit tests on ambari-server/src/test/java/org/apache/ambari/server/upgrade
and they passed.
> 
> 
> Thanks,
> 
> Alejandro Fernandez
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message