Bug 1646763

Summary:	Satellite 6.3.4 upgrade fails on step db_seed
Product:	Red Hat Satellite	Reporter:	Paul Dudley <pdudley>
Component:	Users & Roles	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Katello QA List <katello-qa-list>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.3.4	CC:	dhlavacd, inecas, mbacovsk, mhulan
Target Milestone:	Unspecified	Keywords:	Triaged, Upgrades
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-11-14 07:24:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Paul Dudley 2018-11-05 23:27:00 UTC

Description of problem:
Upgrade from 6.3.3 to 6.3.4:
===
Seeding /usr/share/foreman/db/seeds.d/03-roles.rb
rake aborted!
NoMethodError: undefined method `destroy!' for nil:NilClass
/usr/share/foreman/app/models/role.rb:205:in `map'
/usr/share/foreman/app/models/role.rb:205:in `remove_permissions!'
/usr/share/foreman/lib/seed_helper.rb:80:in `block in update_role_permissions'
/usr/share/foreman/app/models/role.rb:228:in `ignore_locking'
/usr/share/foreman/lib/seed_helper.rb:72:in `update_role_permissions'
/usr/share/foreman/lib/seed_helper.rb:53:in `create_role'
/usr/share/foreman/db/seeds.d/03-roles.rb:9:in `block (3 levels) in <top (required)>'
/usr/share/foreman/db/seeds.d/03-roles.rb:8:in `each'
/usr/share/foreman/db/seeds.d/03-roles.rb:8:in `block (2 levels) in <top (required)>'
/opt/theforeman/tfm/root/usr/share/gems/gems/audited-4.4.1/lib/audited/auditor.rb:283:in `without_auditing'
/usr/share/foreman/db/seeds.d/03-roles.rb:4:in `block in <top (required)>'
/opt/theforeman/tfm/root/usr/share/gems/gems/audited-4.4.1/lib/audited/auditor.rb:283:in `without_auditing'
/usr/share/foreman/db/seeds.d/03-roles.rb:3:in `<top (required)>'
===

How reproducible:
With customer DB, 100%

Additional info:
Current workaround is to comment out the following in 03-roles.rb:

[root@cobalt ~]# cat /usr/share/foreman/seeds.d/03-roles.rb
require (Rails.root + 'db/seeds.d/02-roles_list.rb')

#Role.without_auditing do
#  Filter.without_auditing do
#    RolesList.seeded_roles.each do |role_name, permission_names|
#      SeedHelper.create_role(role_name, permission_names, 0)
#    end
#    RolesList.default_role.each do |role_name, permission_names|
#      SeedHelper.create_role(role_name, permission_names, Role::BUILTIN_DEFAULT_ROLE)
#    end
#  end
#end


After this, the upgrade finishes without error and no known issues are seen in Satellite function (also, no known issues are seen in role function either).

Comment 2 Paul Dudley 2018-11-09 19:53:34 UTC

This issue persists after removing all custom user roles and leaving only the 24 roles available by default.

Comment 3 Paul Dudley 2018-11-14 03:26:37 UTC

This turned out to be an issue with the default_role role. The role was given a few additional filters/permissions than are added by default. Those permissions were:

----|------------------------|-------------------------|------------|-----------|--------------|--------------------------------------------------------------------
ID  | RESOURCE TYPE          | SEARCH                  | UNLIMITED? | OVERRIDE? | ROLE         | PERMISSIONS                                                        
----|------------------------|-------------------------|------------|-----------|--------------|--------------------------------------------------------------------
134 | Bookmark               | none                    | yes        | no        | Default role | view_bookmarks                                                     
135 | (Miscellaneous)        | none                    | yes        | no        | Default role | view_tasks                                                  
136 | ForemanTasks::Task     | owner.id = current_user | no         | no        | Default role | view_foreman_tasks                                                 
607 | (Miscellaneous)        | none                    | yes        | no        | Default role | access_dashboard                                                   
608 | Katello::ContentView   | none                    | yes        | no        | Default role | view_content_views                                                 
609 | Katello::GpgKey        | none                    | yes        | no        | Default role | view_gpg_keys                                                      
610 | Katello::KTEnvironment | none                    | yes        | no        | Default role | view_lifecycle_environments                                        
611 | MailNotification       | none                    | yes        | no        | Default role | view_mail_notifications                                            
612 | Organization           | none                    | yes        | no        | Default role | view_organizations                                                 
613 | Katello::Product       | none                    | yes        | no        | Default role | view_products                                                      
628 | Bookmark               | none                    | yes        | no        | Default role | view_bookmarks, create_bookmarks, edit_bookmarks, destroy_bookmarks
----|------------------------|-------------------------|------------|-----------|--------------|--------------------------------------------------------------------

The filter causing the problem was #628. My guess is that it isn't expected for this role to be able to destroy anything, so that wasn't accounted for, and the rake fails.

This failure was not able to be reproduced in 6.4 when granting the default_role extra filters that allow it to destroy things. Given that, would it make sense to close this bug as currentrelease?

Comment 4 Marek Hulan 2018-11-14 07:24:57 UTC

This is probably duplicate of BZ 1621029 that was fixed in 6.4 as Paul found out. I prefer the suggested approach and close this as current release, so closing as such. Thanks Paul for great investigation!