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 ?
Created attachment 1135228 [details] after reoving the puppet-module from products, its still listed under content-view -> puppet-module tab
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.
(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.
Upstream bug component is Content Management
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?
What is the behavior of "use latest" for RPMs when the RPM is removed from the product? I would wish the same behavior.
(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.
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.
bug for behavior in #27 https://bugzilla.redhat.com/show_bug.cgi?id=1317976
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.
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.
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
*** Bug 1306616 has been marked as a duplicate of this bug. ***