<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 08/29/2012 12:58 PM, Mike McCune wrote: <blockquote cite="mid:503E4A45.2030300@redhat.com" type="cite">On 08/29/2012 03:29 AM, Lukas Zapletal wrote: <blockquote type="cite">On Tue, Aug 28, 2012 at 09:13:03AM -0700, Michael McCune wrote: <blockquote type="cite">this violates our rule that: *** "All changes to content in any live environment must be through a changeset" *** </blockquote> Now THATS a good point! <blockquote type="cite">3) Allow user to delete custom repositories in the Library and then message them that in order to re-create any repositories with the same name they will need to go through and execute changesets in each of their environments to delete the repos from anywhere they promoted to. We could auto create deletion changesets for them so all the changes to the live environments would be tracked and done through our existing mechanism. If people really want it we can allow the "apply" to mass-execute the changesets in order. We would be maintaining our existing rule above but allowing for an easier mechanism to mass delete repositories </blockquote> The question is how would you create a deletion changeset when repository is already GONE? I mean, you can't really insert it there, there is nothing to apply. I don't get it. Maybe I just don't understand how delete promotions works atm. </blockquote> If you delete a custom repo from the Library right now from the GUI or CLI the repo will still exist in all the environments you have promoted to. So to delete the repos from say ... DEV/TEST/PROD after you delete from the Library you just go in, create a 'deletion' changeset in DEV/TEST/PROD and add the repos you previously deleted from the Library to the Changeset. Then you apply that changeset and the repos are now gone from that env. EG: 1) Create custom product, CP1 and environments: DEV/TEST 2) Add 2 repos, repo1, repo2 3) sync to library 4) promote CP1 to DEV, now you have repo1, repo2 in DEV 5) promote CP2 to TEST, now you have repo1, repo2 in TEST 6) Go into Custom Providers, delete repo2. Now repo2 is deleted from the Library but still exists in DEV and TEST 7) Create a Deletion Changeset in DEV, add repo2 to this changeset 8) Apply the changeset, repo2 is now gone from DEV but still exists in TEST 9) Create a Deletion Changeset in TEST, add repo2 to this changeset 10) Apply changeset, repo2 is now gone from TEST and exists nowhere This is how it works in master now today but after running through the above scenario we are still getting that JDBC error so content deletion is *not* cleaning something up correctly. Brad/myself can take a look at why deleting all the repos from Library -> end of promotion path is still leaving something in Candlepin Mike </blockquote> All, I took a brief look at the error that Mike mentioned above and it is the same one described in the bugzilla that Lukas is working on a solution for (i.e. <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=835875">https://bugzilla.redhat.com/show_bug.cgi?id=835875</a> ). (I didn't realize it was the same one until I ran through the reproducer.) What I observed was essentially what was mentioned in the bz and thread. When a user deletes a repository from Library, Katello cleans up content in candlepin's cp_product and cp_content tables; however, if the repository has been promoted to another environment (e.g. Dev), the records will remain in candlepin. This appears to be the reason the error is generated. Note, the following are the log references that perform that cleanup: Resource DELETE request: /candlepin/products/1346272223107/content/1346272248579 Resource DELETE request: /candlepin/content/1346272248579 We could possibly trigger the deletion of those records to also occur when deleting repositories from Library that were previously promoted; however, I wonder if that might cause problems when using the content that remains in the later environments (e.g. Dev, Test). For example, assume: 1. create provider/product/repo : zoo/zoo/zoo 2. sync repo: zoo 3. promote zoo product to dev & test When 1 occurs, the cp_product will get a record for 'zoo' and cp_content will get a record for 'ACME_Corporation_zoo_zoo'. There are no additional records created in these tables during 3; therefore, I wonder if this information needed for a consumer to be able to subscribe to and receive content from the dev and test environments? If so, we may want to prohibit deleting a repository from Library, if it has been promoted. This would essentially mean that Katello would need to warn the user that the content has been promoted to dev and test, the user would need to first delete it from those environments and then they may delete it from Library. thanks Brad </body> </html>