Red Hat Bugzilla – Bug 1559703
Running bootstrap fails: Content view can't be blank
Last modified: 2018-08-22 16:24:56 EDT
Description of problem: Using the bootstrap script to migrate hosts from 6.3 fails with Content view can't be blank The error is from calling Foreman API to create a host entry associated with the group & org. An error occured: HTTP Error 422: Unprocessable Entity url: https://xxxx.xx.xx.xx:8443/api/v2/hosts/ code: 422 data: { "host": { "operatingsystem_id": 3, "managed": "true", "name": "mod-ops01", "ip": "192.168.18.103", "hostgroup_id": 7, "organization_id": 1, "mac": "xx:xx:xx:xx:xx:xx", "architecture_id": 1, "location_id": 3, "domain_id": 1 } } error: { "error": { "errors": { "content_facet.content_view": [ "can't be blank" ] }, "id": null, "full_messages": [ "Content view can't be blank" ] } } Version-Release number of selected component (if applicable): 6.3 How reproducible: Easy Steps to Reproduce: 1. create a new host group without specifying a content view 2. call the API for creating a new host with the newly created host group Actual results: Can't create a new host Expected results: Can create a new host with the host group that doesn't associate with a content view Additional info: It seems like a regression in 6.3 as it works in 6.2.
It seems like this regression is introduced by this commit d7d435d59c0ae9eed36edfe0a0054f7f0fe0790c index 687e166e7..2d8f12015 100644 --- a/app/models/katello/concerns/content_facet_host_extensions.rb +++ b/app/models/katello/concerns/content_facet_host_extensions.rb @@ -45,8 +45,12 @@ module Katello accepts_nested_attributes_for( :content_facet, self.nested_attributes_options[:content_facet].merge( - :reject_if => proc { |attributes| attributes['content_view_id'].blank? && attributes['lifecycle_environment_id'].blank? }) + :reject_if => :content_facet_ignore_update?) ) + + def content_facet_ignore_update?(attributes) + self.content_facet.blank? && attributes.blank? As in this case, if attributes is not blank(as some attributes are inherited from the host group) but content_view_id is blank, content_facet_ignore_update? will return false and then the validation on content_view_id is triggered which leads to the failure of creating a new host.
Another way to reproduce this. On sat 6.3 foreman-console rake irb(main):011:0> host = Host::Managed.new({"operatingsystem_id"=>3, "managed"=>"true", "name"=>"mod-ops01", "ip"=>"192.168.18.103", "hostgroup_id"=>6, "organization_id"=>1, "mac"=>"00:50:56:BF:2A:39", "architecture_id"=>1, "location_id"=>1, "domain_id"=>1}) irb(main):012:0> host.content_facet <===== On Sat 6.2, this returns nil => #<Katello::Host::ContentFacet id: nil, host_id: nil, uuid: nil, content_view_id: nil, lifecycle_environment_id: 5, kickstart_repository_id: nil, content_source_id: 1, installable_security_errata_count: 0, installable_enhancement_errata_count: 0, installable_bugfix_errata_count: 0, applicable_rpm_count: 0, upgradable_rpm_count: 0> irb(main):005:0> host = Host::Managed.new({"operatingsystem_id"=>3, "managed"=>"true", "name"=>"mod-ops01", "ip"=>"192.168.18.103", "hostgroup_id"=>6, "organization_id"=>1, "mac"=>"00:50:56:BF:2A:39", "architecture_id"=>1, "location_id"=>1, "domain_id"=>1}) irb(main):018:0> host.validate => false irb(main):019:0> host.errors.first => [:"content_facet.content_view", "can't be blank"]
(In reply to matt jia from comment #2) > Another way to reproduce this. > > On sat 6.3 > > foreman-console rake This should be foreman-rake console, :-)
(In reply to matt jia from comment #1) > It seems like this regression is introduced by this commit > d7d435d59c0ae9eed36edfe0a0054f7f0fe0790c > > index 687e166e7..2d8f12015 100644 > --- a/app/models/katello/concerns/content_facet_host_extensions.rb > +++ b/app/models/katello/concerns/content_facet_host_extensions.rb > @@ -45,8 +45,12 @@ module Katello > accepts_nested_attributes_for( > :content_facet, > self.nested_attributes_options[:content_facet].merge( > - :reject_if => proc { |attributes| > attributes['content_view_id'].blank? && > attributes['lifecycle_environment_id'].blank? }) > + :reject_if => :content_facet_ignore_update?) > ) > + > + def content_facet_ignore_update?(attributes) > + self.content_facet.blank? && attributes.blank? > > As in this case, if attributes is not blank(as some attributes are inherited > from the host group) but content_view_id is blank, > content_facet_ignore_update? will return false and then the validation on > content_view_id is triggered which leads > to the failure of creating a new host. I may get wrong here as I'm quite sure what self.nested_attributes_options does here.
Hi Matt, Do you have an internal reproducer? If so, would you be interested in trying a quick patch? I suspect that this issue may be solved by the following upstream issue http://projects.theforeman.org/issues/21670.
(In reply to Brad Buckingham from comment #6) > Hi Matt, > > Do you have an internal reproducer? If so, would you be interested in > trying a quick patch? > > I suspect that this issue may be solved by the following upstream issue > http://projects.theforeman.org/issues/21670. Hi Brad, Yeah, it should be fixed by the patch in this upstream issue.
(In reply to matt jia from comment #7) > (In reply to Brad Buckingham from comment #6) > > Hi Matt, > > > > Do you have an internal reproducer? If so, would you be interested in > > trying a quick patch? > > > > I suspect that this issue may be solved by the following upstream issue > > http://projects.theforeman.org/issues/21670. > > Hi Brad, > > Yeah, it should be fixed by the patch in this upstream issue. It turns out this patch doesn't solve this issue. I will update a patch then.
Created attachment 1412963 [details] propose a patch
(In reply to matt jia from comment #2) > Another way to reproduce this. > > On sat 6.3 > > foreman-console rake > > irb(main):011:0> host = Host::Managed.new({"operatingsystem_id"=>3, > "managed"=>"true", "name"=>"mod-ops01", "ip"=>"192.168.18.103", > "hostgroup_id"=>6, "organization_id"=>1, "mac"=>"00:50:56:BF:2A:39", > "architecture_id"=>1, "location_id"=>1, "domain_id"=>1}) > > irb(main):012:0> host.content_facet <===== On Sat 6.2, this returns nil > > => #<Katello::Host::ContentFacet id: nil, host_id: nil, uuid: nil, > content_view_id: nil, lifecycle_environment_id: 5, kickstart_repository_id: > nil, content_source_id: 1, installable_security_errata_count: 0, > installable_enhancement_errata_count: 0, installable_bugfix_errata_count: 0, > applicable_rpm_count: 0, upgradable_rpm_count: 0> > irb(main):005:0> host = Host::Managed.new({"operatingsystem_id"=>3, > "managed"=>"true", "name"=>"mod-ops01", "ip"=>"192.168.18.103", > "hostgroup_id"=>6, "organization_id"=>1, "mac"=>"00:50:56:BF:2A:39", > "architecture_id"=>1, "location_id"=>1, "domain_id"=>1}) > > irb(main):018:0> host.validate > => false > irb(main):019:0> host.errors.first > => [:"content_facet.content_view", "can't be blank"] To be clear, the host group used here does not associate with any content view.
Matt, Thanks for the feedback. I ran a similar test on my 6.3.1 environment and I had different results. On my environment, applying the patch from redmine 21670 solve the issue. Console output from my test: BEFORE PATCH [root@sat-6-3-qa-rhel7 ~]# foreman-rake console Loading production environment (Rails 4.2.6) Failed to load console gems, starting anyway irb(main):001:0> host=Host::Managed.new({"operatingsystem_id"=>2,"managed"=>"false","name"=>"testhost", "ip"=>"192.168.18.103","hostgroup_id"=>1,"organization_id"=>1, "mac"=>"00:50:56:BF:2A:39", "architecture_id"=>1,"location_id"=>1, "domain_id"=>1}) => #<Host::Managed id: nil, name: "testhost", last_compile: nil, last_report: nil, updated_at: nil, created_at: nil, root_pass: nil, architecture_id: 1, operatingsystem_id: 2, environment_id: nil, ptable_id: nil, medium_id: nil, build: false, comment: nil, disk: nil, installed_at: nil, model_id: nil, hostgroup_id: 1, owner_id: nil, owner_type: nil, enabled: true, puppet_ca_proxy_id: nil, managed: false, use_image: nil, image_file: nil, uuid: nil, compute_resource_id: nil, puppet_proxy_id: nil, certname: nil, image_id: nil, organization_id: 1, location_id: 1, type: "Host::Managed", otp: nil, realm_id: nil, compute_profile_id: nil, provision_method: nil, grub_pass: "", discovery_rule_id: nil, content_view_id: nil, lifecycle_environment_id: nil, global_status: 0, lookup_value_matcher: nil, pxe_loader: nil, openscap_proxy_id: nil> irb(main):002:0> host.validate => false irb(main):003:0> host.errors.first => [:"content_facet.content_view", "can't be blank"] irb(main):004:0> irb(main):005:0* irb(main):006:0* exit AFTER PATCH [root@sat-6-3-qa-rhel7 ~]# foreman-rake console Loading production environment (Rails 4.2.6) Failed to load console gems, starting anyway irb(main):001:0> host=Host::Managed.new({"operatingsystem_id"=>2,"managed"=>"false","name"=>"testhost", "ip"=>"192.168.18.103","hostgroup_id"=>1,"organization_id"=>1, "mac"=>"00:50:56:BF:2A:39", "architecture_id"=>1,"location_id"=>1, "domain_id"=>1}) => #<Host::Managed id: nil, name: "testhost", last_compile: nil, last_report: nil, updated_at: nil, created_at: nil, root_pass: nil, architecture_id: 1, operatingsystem_id: 2, environment_id: nil, ptable_id: nil, medium_id: nil, build: false, comment: nil, disk: nil, installed_at: nil, model_id: nil, hostgroup_id: 1, owner_id: nil, owner_type: nil, enabled: true, puppet_ca_proxy_id: nil, managed: false, use_image: nil, image_file: nil, uuid: nil, compute_resource_id: nil, puppet_proxy_id: nil, certname: nil, image_id: nil, organization_id: 1, location_id: 1, type: "Host::Managed", otp: nil, realm_id: nil, compute_profile_id: nil, provision_method: nil, grub_pass: "", discovery_rule_id: nil, content_view_id: nil, lifecycle_environment_id: nil, global_status: 0, lookup_value_matcher: nil, pxe_loader: nil, openscap_proxy_id: nil> irb(main):002:0> host.validate => true irb(main):003:0> host.errors.first => nil irb(main):004:0> Note: on my test, I basically created a hostgroup with no details (e.g. no CV...etc) and then created the host using that group.
I tested Matt's second patch on a 6.3.1 production server and it worked fine. We will produce a hotfix set of RPMs which should be available soon to resolve this issue.
(In reply to Brad Buckingham from comment #12) > > [root@sat-6-3-qa-rhel7 ~]# foreman-rake console > Loading production environment (Rails 4.2.6) > Failed to load console gems, starting anyway > irb(main):001:0> > host=Host::Managed.new({"operatingsystem_id"=>2,"managed"=>"false", > "name"=>"testhost", > "ip"=>"192.168.18.103","hostgroup_id"=>1,"organization_id"=>1, > "mac"=>"00:50:56:BF:2A:39", "architecture_id"=>1,"location_id"=>1, > "domain_id"=>1}) > => #<Host::Managed id: nil, name: "testhost", last_compile: nil, > last_report: nil, updated_at: nil, created_at: nil, root_pass: nil, > architecture_id: 1, operatingsystem_id: 2, environment_id: nil, ptable_id: > nil, medium_id: nil, build: false, comment: nil, disk: nil, installed_at: > nil, model_id: nil, hostgroup_id: 1, owner_id: nil, owner_type: nil, > enabled: true, puppet_ca_proxy_id: nil, managed: false, use_image: nil, > image_file: nil, uuid: nil, compute_resource_id: nil, puppet_proxy_id: nil, > certname: nil, image_id: nil, organization_id: 1, location_id: 1, type: > "Host::Managed", otp: nil, realm_id: nil, compute_profile_id: nil, > provision_method: nil, grub_pass: "", discovery_rule_id: nil, > content_view_id: nil, lifecycle_environment_id: nil, global_status: 0, > lookup_value_matcher: nil, pxe_loader: nil, openscap_proxy_id: nil> > irb(main):002:0> host.validate > => true > irb(main):003:0> host.errors.first > => nil > irb(main):004:0> > > > Note: on my test, I basically created a hostgroup with no details (e.g. no > CV...etc) and then created the host using that group. Hi Brad, Can you please set a life cycle environment on that group and try again? I forgot to mention that the group I used for reproducing has associated with a life cycle environment.
Created redmine issue http://projects.theforeman.org/issues/23457 from this bug
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/23457 has been resolved.
Hi Mike/Team, One of my customer is facing this issue after upgrading satellite to 6.3.2. Can i provide the same hotfix. Case no #02127577. Regards,
** Hotfix RPMs for 6.3.2 ** The attached RPMs only work on Satellite 6.3.2. Instructions for hotfix: 1) download newest RPMs from BZ attachment: tfm-rubygem-katello-3.4.5.74-2.HOTFIXRHBZ1559703.el7sat.noarch.rpm tfm-rubygem-katello_ostree-3.4.5.74-2.HOTFIXRHBZ1559703.el7sat.noarch.rpm 2) rpm -Uvh tfm-rubygem-katello-3.4.5.74-2.HOTFIXRHBZ1559703.el7sat.noarch.rpm tfm-rubygem-katello_ostree-3.4.5.74-2.HOTFIXRHBZ1559703.el7sat.noarch.rpm NOTE: Remove ostree RPM from command if not already installed. 3) katello-service restart 4) resume operations and verify hotfix is functional in your environment
Created attachment 1455088 [details] tfm-rubygem-katello-3.4.5.74-2.HOTFIXRHBZ1559703.el7sat.noarch.rpm
Created attachment 1455090 [details] tfm-rubygem-katello_ostree-3.4.5.74-2.HOTFIXRHBZ1559703.el7sat.noarch.rpm
Hi Mike, My customer has applied the hotfix for 6.3.2 and it works like a charm. Thanks,
Andrew, This failed to cherry-pick downstream, can you take a look?
Verified! @ Satellite 6.3.3 snap 2 Steps and observation: --------------------------- irb(main):001:0> host5 = Host::Managed.new({"operatingsystem_id"=>2, "managed"=>"true", "name"=>"jyejare-10", "ip"=>"192.168.100.157", "hostgroup_id"=>1, "mac":"00:50:56:bf:2a:30", "architecture_id"=>1, "location_id"=>2, "domain_id"=>1, "organization_id"=>1}) => #<Host::Managed id: nil, name: "jyejare-10", last_compile: nil, last_report: nil, updated_at: nil, created_at: nil, root_pass: nil, architecture_id: 1, operatingsystem_id: 2, environment_id: 1, ptable_id: nil, medium_id: nil, build: false, comment: nil, disk: nil, installed_at: nil, model_id: nil, hostgroup_id: 1, owner_id: nil, owner_type: nil, enabled: true, puppet_ca_proxy_id: 1, managed: true, use_image: nil, image_file: nil, uuid: nil, compute_resource_id: nil, puppet_proxy_id: 1, certname: nil, image_id: nil, organization_id: 1, location_id: 2, type: "Host::Managed", otp: nil, realm_id: nil, compute_profile_id: nil, provision_method: nil, grub_pass: "", discovery_rule_id: nil, content_view_id: nil, lifecycle_environment_id: nil, global_status: 0, lookup_value_matcher: nil, pxe_loader: nil, openscap_proxy_id: nil> irb(main):002:0> host5.validate => true irb(main):003:0> host5.errors.first => nil irb(main):004:0> host5.hostgroup => #<Hostgroup id: 1, name: "HG1", created_at: "2018-07-31 16:13:36", updated_at: "2018-07-31 16:13:36", environment_id: 1, operatingsystem_id: 2, architecture_id: 1, medium_id: nil, ptable_id: 92, root_pass: "", puppet_ca_proxy_id: 1, use_image: nil, image_file: nil, ancestry: nil, vm_defaults: nil, subnet_id: 1, domain_id: 1, puppet_proxy_id: 1, title: "HG1", realm_id: nil, compute_profile_id: nil, content_source_id: 1, grub_pass: "", content_view_id: nil, lifecycle_environment_id: 10, lookup_value_matcher: "hostgroup=HG1", kickstart_repository_id: nil, subnet6_id: nil, pxe_loader: "PXELinux BIOS", openscap_proxy_id: nil> irb(main):005:0> hg = host5.hostgroup => #<Hostgroup id: 1, name: "HG1", created_at: "2018-07-31 16:13:36", updated_at: "2018-07-31 16:13:36", environment_id: 1, operatingsystem_id: 2, architecture_id: 1, medium_id: nil, ptable_id: 92, root_pass: "", puppet_ca_proxy_id: 1, use_image: nil, image_file: nil, ancestry: nil, vm_defaults: nil, subnet_id: 1, domain_id: 1, puppet_proxy_id: 1, title: "HG1", realm_id: nil, compute_profile_id: nil, content_source_id: 1, grub_pass: "", content_view_id: nil, lifecycle_environment_id: 10, lookup_value_matcher: "hostgroup=HG1", kickstart_repository_id: nil, subnet6_id: nil, pxe_loader: "PXELinux BIOS", openscap_proxy_id: nil> irb(main):006:0> hg.content_view_id => nil Hence, its proved, The host is being created without CV. The same has been verified with manage = false and its working fine.
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-2018:2551