Bug 1271000 - Deleting a deployed puppet module from a Product breaks Content View.
Deleting a deployed puppet module from a Product breaks Content View.
Status: CLOSED ERRATA
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Content Management (Show other bugs)
6.1.2
All Linux
medium Severity high (vote)
: 6.1.8
: --
Assigned To: Chris Duryee
Sachin Ghai
http://projects.theforeman.org/issues...
: Triaged
: 1306616 (view as bug list)
Depends On:
Blocks: 1317978
  Show dependency treegraph
 
Reported: 2015-10-12 17:19 EDT by Deepannagaraj Nagarathinam
Modified: 2017-02-23 14:22 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1317978 (view as bug list)
Environment:
Last Closed: 2016-03-22 11:44:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
after reoving the puppet-module from products, its still listed under content-view -> puppet-module tab (52.16 KB, image/png)
2016-03-11 08:17 EST, Sachin Ghai
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2206521 None None None 2016-03-22 12:15 EDT

  None (edit)
Comment 18 Sachin Ghai 2016-03-11 08:15:54 EST
Verified with Satellite 6.1.8

I performed following steps to reproduce the issue:

1) created a product
2) created puppet type repo without URL
3) uploaded a motd puppet module
4) created a CV
5) added puppet module along with other rhel repo
6) selected the latest version
7) published the CV
8) Now removed the puppet modules from product -> puppet repo

Puppet module was deleted successfully, however a exception raised in production.log:

--
2016-03-11 13:50:29 [I] Processing by Katello::Api::V2::RepositoriesController#remove_content as JSON
2016-03-11 13:50:29 [I]   Parameters: {"id"=>"10", "uuids"=>["06a5a280-572a-4b0e-a21b-15bec164bfda"], "organization_id"=>"1", "api_version"=>"v2", "repository"=>{"id"=>"10"}}
2016-03-11 13:50:39 [E] undefined method `[]' for nil:NilClass (NoMethodError)
/opt/rh/ruby193/root/usr/share/gems/gems/katello-2.2.0.84/app/lib/actions/pulp/repository/distributor_publish.rb:35:in `distributor_id'
/opt/rh/ruby193/root/usr/share/gems/gems/katello-2.2.0.84/app/lib/actions/pulp/repository/distributor_publish.rb:27:in `invoke_external_task'
/opt/rh/ruby193/root/usr/share/gems/gems/dynflow-0.7.7.9/lib/dynflow/action/polling.rb:83:in `initiate_external_action'
/opt/rh/ruby193/root/usr/share/gems/gems/dynflow-0.7.7.9/lib/dynflow/action/polling.rb:18:in `run'
/opt/rh/ruby193/root/usr/share/gems/gems/dynflow-0.7.7.9/lib/dynflow/action/cancellable.rb:9:in `run'
/opt/rh/ruby193/root/usr/share/gems/gems/katello-2.2.0.84/app/lib/actions/pulp/abstract_async_task.rb:57:in `run'
--

Later, when I checked content-view --> puppet-module tab, I still found the listing of motd puppet module. Please see the screenshot.

So what is expected here ?

Can user delete the puppet-module fro products if its part of published CV ?

and shouldn't it be removed from CV if it can be removed from products ?

Please advice what is expected ?
Comment 19 Sachin Ghai 2016-03-11 08:17 EST
Created attachment 1135228 [details]
after reoving the puppet-module from products, its still listed under content-view -> puppet-module tab
Comment 20 Chris Duryee 2016-03-11 09:25:08 EST
I believe the deletion behavior itself is OK, deleting something from a product (puppet module, rpm, etc) should not remove the units from CVs.

I am looking into the stack trace now.
Comment 21 Simon Reber 2016-03-11 09:28:18 EST
(In reply to Chris Duryee from comment #20)
> I believe the deletion behavior itself is OK, deleting something from a
> product (puppet module, rpm, etc) should not remove the units from CVs.
> 
> I am looking into the stack trace now.
This bug is about when removing something from a product that is used in a Content View that it breaks the Content view.

So basically removing something within a product that is used within a Content View should simply not be possible and raise an error to the customer, telling that he first needs to remove the respective Content View before removing product.
Comment 22 Bryan Kearney 2016-03-11 10:06:11 EST
Upstream bug component is Content Management
Comment 23 Chris Duryee 2016-03-11 11:35:18 EST
Simon,

I think we are close on agreement on how this should work. Here is a scenario I tested:

add puppet repo to product
add puppet module to CV (in this case, 'ntpd' module)
publish CV version 1.0, confirm ntpd module is under /etc/puppet/environments
go back to product, click 'manage puppet modules', remove ntpd module

go to CV again, click "puppet modules" tab which shows that the puppet module is still there (page no longer creates an error)
confirm ntpd module is still there under /etc/puppet/environments

publish CV version 2.0, 'ntpd' module is no longer under /etc/puppet/environments (this is a bug, it's trying to find the latest version and failing. IMO this is an improvement over previous behavior at least, since users are no longer blocked)

promote CV version 1.0 to a new environment, puppet module is in /etc/puppet/environments and shown in published version in web UI even though we deleted it from the product (this is correct, published CVs are immutable)


*********


I think if a puppet module is deleted from a product, we should either:

 * block deletion until all 'use latest' versions are flipped to specific versions, or
 * go through and flip all 'use latest' to pin them to the last known version we have in the CV

I would vote for #1 since it would cause the least amount of surprise by the user.

I think though that if the user has selected a specific version and associated it with a CV, then that version should stay associated even after deletion from the product. The CV should  not be impacted by things that happen in the product IMO, unless the 'use latest' flag is set.

Does this seem congruent with your thoughts on this bug?
Comment 24 Tom McKay 2016-03-11 12:56:54 EST
What is the behavior of "use latest" for RPMs when the RPM is removed from the product? I would wish the same behavior.
Comment 26 Simon Reber 2016-03-15 09:43:58 EDT
(In reply to Chris Duryee from comment #23)
> Simon,
> 
> I think we are close on agreement on how this should work. Here is a
> scenario I tested:
> 
> add puppet repo to product
> add puppet module to CV (in this case, 'ntpd' module)
> publish CV version 1.0, confirm ntpd module is under /etc/puppet/environments
> go back to product, click 'manage puppet modules', remove ntpd module
> 
> go to CV again, click "puppet modules" tab which shows that the puppet
> module is still there (page no longer creates an error)
> confirm ntpd module is still there under /etc/puppet/environments
> 
> publish CV version 2.0, 'ntpd' module is no longer under
> /etc/puppet/environments (this is a bug, it's trying to find the latest
> version and failing. IMO this is an improvement over previous behavior at
> least, since users are no longer blocked)
> 
> promote CV version 1.0 to a new environment, puppet module is in
> /etc/puppet/environments and shown in published version in web UI even
> though we deleted it from the product (this is correct, published CVs are
> immutable)
I'm not sure that this is the intended functionality. I think we should not allow deleting anything out of products that is actively used within a Content View. I think your solution does somehow resolve the problem. But what, if somebody does delete a module by mistake. During the next publish and propagate we simply lose this functionality.
If we would would prevent the user from deleting the module because it's still used in a Content View we could avoid that and the user would actually need to follow a work-flow to properly remove the module before deleting it.

> *********
> 
> 
> I think if a puppet module is deleted from a product, we should either:
> 
>  * block deletion until all 'use latest' versions are flipped to specific
> versions, or
>  * go through and flip all 'use latest' to pin them to the last known
> version we have in the CV
> 
> I would vote for #1 since it would cause the least amount of surprise by the
> user.
> 
> I think though that if the user has selected a specific version and
> associated it with a CV, then that version should stay associated even after
> deletion from the product. The CV should  not be impacted by things that
> happen in the product IMO, unless the 'use latest' flag is set.
> 
> Does this seem congruent with your thoughts on this bug?
As I said, I don't think we should allow them to delete a module/product as long as it's actively used in a Content View.
Comment 27 Chris Duryee 2016-03-15 12:16:29 EDT
Sachin,

I was able to repro the stack trace with the following steps:

* create new custom product
* add a puppet repo, add one module to repo
* remove module from repo

The problem is that in Katello 2.2, puppet repos associated with products have no distributors, so when the metadata generate task runs, it fails. This is an error that should be fixed, but should not affect functionality.

In Katello 3.0, puppet repos associated with products have a distributor so this should no longer happen. If you want, I can create a new bug for this issue so we can ensure it gets addressed.
Comment 28 Chris Duryee 2016-03-15 12:26:42 EDT
bug for behavior in #27 https://bugzilla.redhat.com/show_bug.cgi?id=1317976
Comment 29 Chris Duryee 2016-03-15 12:33:55 EDT
Simon,

I created https://bugzilla.redhat.com/show_bug.cgi?id=1317978, it would be easier to have our discussion in that bz since it is set for 6.2.
Comment 30 Sachin Ghai 2016-03-15 12:50:26 EDT
After deleting the puppet-module from product, I can load the CV puppet-module details page and can see the deleted module. However an exception raised in logs as mentioned in comment18. And for that exception, another bz is filed as pointed in comment28.

So Moving this bz to verified.
Comment 32 errata-xmlrpc 2016-03-22 11:44:21 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:0475
Comment 33 Stefan Nemeth 2016-04-04 03:07:39 EDT
*** Bug 1306616 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.