ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sid Wagle" <swa...@hortonworks.com>
Subject Re: Review Request 40374: Refactor delete configs on delete service action
Date Tue, 17 Nov 2015 18:21:37 GMT


> On Nov. 17, 2015, 11:42 a.m., Sebastian Toader wrote:
> > Ship It!
> 
> Sebastian Toader wrote:
>     Can you perform the same manual test but this time with the cluster deployed with
Blueprint?

Blueprints dont call deletes, os I though Upgrade / Downgrade might be more relevant, I will
perform the test with a new build, need to get this in to run dome perf tests.


- Sid


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


On Nov. 17, 2015, 6:10 p.m., Sid Wagle wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/40374/
> -----------------------------------------------------------
> 
> (Updated Nov. 17, 2015, 6:10 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Myroslav Papirkovskyy,
Sumit Mohanty, and Sebastian Toader.
> 
> 
> Bugs: AMBARI-13894
>     https://issues.apache.org/jira/browse/AMBARI-13894
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> Today, when you delete Service, the code deletes ServiceConfig entries associated with
the Service. This in turn deletes ClusterConfig entities due to a Cascade.REMOVE on the many
to many relationship.
> Stack allows a multiple services to be dependent on the same config while today ServiceConfig
and ClusterConfig are not used that way as UI only shows one kind of config on a single page.

> If this changes in future then the ManyToMany relationship with CASCADE delete may create
problem. Also, there is no API way to restrict this.
> 
> Changes:
> - Remove Casacade.REMOVE from the ServiceConfigEntity -> ClusterConfigEntity
> - Move @Transactional remove inside the Write lock boundaries()
> - Modified deleteService to remove Config history and not ClusterConfigs
> 
> 
> Diffs
> -----
> 
>   ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ClusterConfigMappingEntity.java
5e18014 
>   ambari-server/src/main/java/org/apache/ambari/server/orm/entities/ServiceConfigEntity.java
f5bdbf9 
>   ambari-server/src/main/java/org/apache/ambari/server/state/ServiceImpl.java 74f9e02

>   ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
36e4a01 
>   ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterTest.java
edd6267 
> 
> Diff: https://reviews.apache.org/r/40374/diff/
> 
> 
> Testing
> -------
> 
> Added a new unit test for deleteService changes.
> 
> Manually verified Add Service -> Change configs -> Delete Service -> Re-add
service, Verify Service Config points to default configs.
> 
> 
> Thanks,
> 
> Sid Wagle
> 
>


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