Skip to content
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

Adding options field to ext_management_system #15398

Merged
merged 1 commit into from
Jul 25, 2017

Conversation

enoodle
Copy link

@enoodle enoodle commented Jun 19, 2017

This will add the serialzed column options to ExtManagementSystem.
There is also a migration for ManageIQ::Providers::Kubernetes::ContainerManager options that where saved in CustomAttributes and general settings but should be there. This takes inspiration from #13826 and #14106 but the options details will be added in a later stage in the appropriate provider modules.

RFE BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1462835

@enoodle
Copy link
Author

enoodle commented Jun 19, 2017

cc @simon3z @blomquisg

ExtManagementSystem.where(:type => "ManageIQ::Providers::Kubernetes::ContainerManager").each do |cp|
migrated_options = {}
migrated_options[:image_inspector_repository] = Settings.ems.ems_kubernetes.image_inspector_repository
migrated_options[:image_inspector_registry] = Settings.ems.ems_kubernetes.image_inspector_registry
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@enoodle we don't want to move the Settings values in the options.

:resource_type => cp.type,
:resource_id => cp.id,
:section => ManageIQ::Providers::Kubernetes::ContainerManager::Scanning::Job::ATTRIBUTE_SECTION,
:name => ManageIQ::Providers::Kubernetes::ContainerManager::Scanning::Job::PROXY_ENV_VARIABLES).each do |ca|
Copy link
Contributor

@simon3z simon3z Jun 19, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@enoodle I don't think we want to rely on the Kubernetes module dependency here for this migration. cc @blomquisg

@enoodle
Copy link
Author

enoodle commented Jun 20, 2017 via email

@simon3z
Copy link
Contributor

simon3z commented Jun 20, 2017

I am not sure I understand, if we dont migrate these kubernetes options and
not the ones from the settings, what should we migrate?

@enoodle I don't want you to prepopulate the values in the db for the Settings ones... otherwise we can't change the defaults going forward.

Read more carefully the comment about the kubernetes options, it's about the module dependency.

@simon3z
Copy link
Contributor

simon3z commented Jun 20, 2017

Current implementation adding a generic options json column to ext_management_system LGTM 👍.

Of course I am also considering the downside of this approach. The table authentications just recently added the same options json column so I assume we reached the same conclusion on the need for a more flexible field for special best-of-breed options (of course it must be used with care).

For completeness I want to mention that since most of the times (I'd say always?) these are also global settings, e.g.:

:ems:
  :ems_kubernetes:
    :miq_namespace: management-infra
    :image_inspector_registry: docker.io
    :image_inspector_repository: openshift/image-inspector

It's worth mentioning that this could be achieved also using ExtManagementSystem specific settings in the settings_changes table:

id resource_type resource_id key value
100 ExtManagementSystem 1 /ems/ems_kubernetes/image_inspector_registry mydockerregistry.io
101 ExtManagementSystem 2 /ems/ems_kubernetes/image_inspector_registry myotherdockerregistry.io

I am not sure of the implications of this second approach though.

cc @blomquisg

@enoodle enoodle force-pushed the add_options_to_ems branch 2 times, most recently from 5ce53e8 to fca068a Compare June 20, 2017 10:22
:resource_type => cp.type,
:resource_id => cp.id,
:section => ManageIQ::Providers::Kubernetes::ContainerManager::Scanning::Job::ATTRIBUTE_SECTION,
:name => ManageIQ::Providers::Kubernetes::ContainerManager::Scanning::Job::PROXY_ENV_VARIABLES
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@enoodle as mentioned before I am not sure if we can afford this dependency to the Kubernetes module. cc @blomquisg You may have to hard-code the values here.

@enoodle
Copy link
Author

enoodle commented Jun 20, 2017

I have added deletion of the old CustomAttribute's with the settings and also made sure that the migration is happening on Kubernetes and Openshift Providers.

:name => %w(no_proxy http_proxy https_proxy)
).each do |ca|
migrated_options["image_inspector_#{ca.name}".to_sym] = ca.value
ca.delete
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@enoodle isn't it risky to delete this before having it persisted in the new options? (cp.update)

@simon3z
Copy link
Contributor

simon3z commented Jun 21, 2017

@blomquisg @Fryguy can you review?

@miq-bot
Copy link
Member

miq-bot commented Jun 22, 2017

This pull request is not mergeable. Please rebase and repush.

@Fryguy
Copy link
Member

Fryguy commented Jun 22, 2017

Database migrations have now been moved to the https://github.com/ManageIQ/manageiq-schema repo. Please see http://talk.manageiq.org/t/new-split-repo-manageiq-schema/2478 for instructions on how to transfer your database migrations. If this PR contains only migrations, I will leave it open for a short time during the transition, after which I will close this if it has not been moved over.

@miq-bot
Copy link
Member

miq-bot commented Jun 25, 2017

Checked commit enoodle@ad37b0e with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
1 file checked, 0 offenses detected
Everything looks fine. 🏆

@moolitayer
Copy link

cc @Loicavenel

@Fryguy Fryguy merged commit 56f639e into ManageIQ:master Jul 25, 2017
@Fryguy Fryguy added this to the Sprint 66 Ending Aug 7, 2017 milestone Jul 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants