-
Notifications
You must be signed in to change notification settings - Fork 900
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removed provider_foreman explorer and added new non-explorer style screens under Configuration main tab. #19949
Conversation
We're going to need a data migration for the user roles and the shortcuts if the identifier is changing. |
77622f1
to
813b6ab
Compare
e4d4496
to
1d3d35e
Compare
Since old screens are removed and new screens are added in UI, these are no longer renaming of existing features. |
f6ef583
to
0e201d3
Compare
@h-kataria travis issue seems relevant (loading the features YAML fails) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Jason's concern is for any existing users that have permissions to old identifiers, those need to be migrated to use the new permissions, right? |
I'm a little confused by the seeding vs migrations, let's say I have this migration: def up
old_feature = MiqProductFeature.find_by(:identifier => 'provider_foreman_explorer').id
new_features = MiqProductFeature.where(:identifier => %w[configuration_manager_show_list configuration_profile_show_list configured_system_show_list]).pluck(:id)
old_assignments = MiqRolesFeature.where(:miq_product_feature_id => old_feature)
old_assignments.each do |a|
new_features.each do |f_id|
MiqRolesFeature.create(:miq_product_feature_id => f_id, :miq_user_role_id => a.user_role_id)
end
end
old_assignments.delete_all
end I am replacing all foreman_explorers with the 3 new features in all user roles. However, when the db:seed runs through, the |
Easiest thing is to just rename the existing feature in the migration as long as the features' parents are still the same and nothing else changes. Otherwise you will need to create the new features in the migration as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found some problems while writing the migration, also I'd like to propose the name ems_configuration
if that's possible.
Testing ManageIQ/manageiq-ui-classic#6782, ManageIQ/manageiq#19949 and ManageIQ/manageiq-schema/ManageIQ#464
Added cross-repo tests ManageIQ/manageiq-cross_repo-tests#113 |
app/models/configured_system.rb
Outdated
@@ -46,6 +46,8 @@ class ConfiguredSystem < ApplicationRecord | |||
scope :with_manager, ->(manager_id) { where(:manager_id => manager_id) } | |||
scope :with_configuration_profile_id, ->(profile_id) { where(:configuration_profile_id => profile_id) } | |||
scope :without_configuration_profile_id, -> { where(:configuration_profile_id => nil) } | |||
scope :not_ansible, -> { where.not(:type => ["ManageIQ::Providers::EmbeddedAnsible::AutomationManager::ConfiguredSystem", | |||
"ManageIQ::Providers::AnsibleTower::AutomationManager::ConfiguredSystem"]) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ewww
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should really be something describing "not from automation managers", but not calling out ansible. Or perhaps in the positive, "under configuration managers only"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm tempted to actually make this a blocker...we really can't be adding references to plugins in core. @agrare Is there a way to express this without resorting to type checks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we excluding AutomationManager::ConfiguredSystem
s ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we can check if the ext_management_system is a ConfigurationManager
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Fryguy you might know a cleaner way of checking the type but something like this would do the trick:
scope :configuration_manager, -> { where(:manager => ManageIQ::Providers::ConfigurationManager.all) }
>> ConfiguredSystem.configuration_manager
ConfiguredSystem Load (0.8ms) SELECT "configured_systems".* FROM "configured_systems" WHERE "configured_systems"."manager_id" IN (SELECT "ext_management_systems"."id" FROM "ext_management_systems" WHERE "ext_management_systems"."type" IN ('ManageIQ::Providers::ConfigurationManager', 'ManageIQ::Providers::Foreman::ConfigurationManager')) LIMIT $1 [["LIMIT", 11]]
ConfiguredSystem Inst Including Associations (0.1ms - 1rows)
=> #<ActiveRecord::Relation [#<ConfiguredSystem id: 1, type: nil, hostname: nil, direct_operating_system_flavor_id: nil, configuration_profile_id: nil, manager_id: 7, manager_ref: nil, created_at: "2020-04-23 16:29:11", updated_at: "2020-04-23 16:29:11", last_checkin: nil, build_state: nil, configuration_location_id: nil, configuration_organization_id: nil, ipaddress: nil, mac_address: nil, ipmi_present: nil, puppet_status: nil, direct_customization_script_ptable_id: nil, direct_customization_script_medium_id: nil, operating_system_flavor_id: nil, customization_script_medium_id: nil, customization_script_ptable_id: nil, inventory_root_group_id: nil, virtual_instance_ref: nil, counterpart_type: nil, counterpart_id: nil>]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we excluding AutomationManager::ConfiguredSystems ?
Technically the configured_systems records include records from both ConfigurationManagers as well as AutomationManagers. When viewing the list from the Configuration -> Configured Systems we need to exclude them.
Now that I've written that out, that is EXACTLY what we do with Cloud instances/templates vs Infra vms/templates, so whatever we do there is exactly what we should do here. @h-kataria How do we do that differentiation for Cloud/Infra vms?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
scope :configuration_manager, -> { where(:manager => ManageIQ::Providers::ConfigurationManager.all) }`
Minor, but I think I'd change that slightly to
scope :under_configuration_managers, -> { where(:manager => ManageIQ::Providers::ConfigurationManager.all) }`
Otherwise, :configuration_manager
appears like a has_one relationship and would return a configuration_manager, but it doesn't
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When viewing the list from the Configuration -> Configured Systems we need to exclude them.
That makes much more sense, we want to group them not exclude some
Minor, but I think I'd changed that slightly to
Oh yeah wasn't suggesting a name haha
Added named_scope to get Configuration Manager specific Configured System records. Ansible Configured systems are being displayed on Automation Manager explorer
924044c
to
21d8260
Compare
locale/en.yml
Outdated
@@ -781,9 +781,11 @@ en: | |||
ManageIQ::Providers::AnsibleTower::AutomationManager::ConfigurationScript: Job Template (Ansible Tower) | |||
ManageIQ::Providers::AnsibleTower::AutomationManager::ConfigurationWorkflow: Workflow Template (Ansible Tower) | |||
ManageIQ::Providers::AnsibleTower::AutomationManager::Playbook: Playbook (Ansible Tower) | |||
ManageIQ::Providers::CloudAutomationManager::ConfigurationManager: Configuration Manager (Cloud Automation Manager) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@h-kataria This PR looks good to me once we remove the dictionary entries. |
These entries are no longer needed after merge of ManageIQ#20100
Checked commits h-kataria/manageiq@1a2ae17~...25bee8a with ruby 2.5.7, rubocop 0.69.0, haml-lint 0.28.0, and yamllint |
@h-kataria Backporting to jansa conflicts on |
Renamed provider_foreman specific features, links etc to configuration_manager Jansa specific PR for backport of ManageIQ#19949
Removed provider_foreman explorer and added new non-explorer style screens under Configuration main tab. (cherry picked from commit 431bbe3)
Jansa backport details:
|
These permissions where changed here: ManageIQ/manageiq#19949 and as such, the Ansible playbook results would not be displayed. Changing to use "service_view" permission since the manageiq-ui-classic uses "service" (level above), and this is only displaying the view, so this should be the only permission required.
Removed provider_foreman explorer and added new non-explorer style screens under Configuration main tab.
Follow up PR for ManageIQ/manageiq-ui-classic#6730
before
after