-
Notifications
You must be signed in to change notification settings - Fork 898
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
Only use JSON-safe values in settings #17201
Comments
Merged #17168, so one down. |
@djberg96 Can you comment on what we use the dates for in the ems_azure section? If we can convert those to simple strings, that would knock out one of the potential issues here. |
Those are used by the azure-armrest library, which is ultimately part of the REST API for Azure. That string is passed along as a param with each request, and different services have different api-version strings. Occasionally Microsoft changes the underlying behavior and updates the api-version strings. Since our backend code might not be able to handle the change, we lock them down on our end. |
@djberg96 My question is more specific to the object types being stored. It sounds like the Azure API is expecting strings, so we should probably store strings in our yaml...right now Date objects are being stored (see below), which can cause issues with JSON roundtripping (e.g. when someone gets the settings via the REST API, then POSTs back to the REST API with change). [9] pry(main)> ::Settings.ems.ems_azure.api_versions.to_hash.values.map(&:class)
=> [Date, Date, Date, Date, Date, Date, Date, Date, Date, Date, Date, Date, Date, Date] |
Symbols in configuration values are problematic because Symbols do not roundtrip through JSON. Since the API now exposes Settings, it's not possible to set Symbols as values. The saver_strategy was fixed in ManageIQ/manageiq#17168 to support String values, and the next step is to remove all Symbols from the Settings. ManageIQ/manageiq#17201 https://bugzilla.redhat.com/show_bug.cgi?id=1558031
Symbols in configuration values are problematic because Symbols do not roundtrip through JSON. Since the API now exposes Settings, it's not possible to set Symbols as values. The saver_strategy was fixed in ManageIQ/manageiq#17168 to support String values, and the next step is to remove all Symbols from the Settings. ManageIQ/manageiq#17201 https://bugzilla.redhat.com/show_bug.cgi?id=1558031
Symbols in configuration values are problematic because Symbols do not roundtrip through JSON. Since the API now exposes Settings, it's not possible to set Symbols as values. The saver_strategy was fixed in ManageIQ/manageiq#17168 to support String values, and the next step is to remove all Symbols from the Settings. ManageIQ/manageiq#17201 https://bugzilla.redhat.com/show_bug.cgi?id=1558031
@Fryguy I'm fine with changing them to strings since they're just passed along as strings. |
Symbols in configuration values are problematic because Symbols do not roundtrip through JSON. Since the API now exposes Settings, it's not possible to set Symbols as values. The saver_strategy was fixed in ManageIQ/manageiq#17168 to support String values, and the next step is to remove all Symbols from the Settings. ManageIQ/manageiq#17201 https://bugzilla.redhat.com/show_bug.cgi?id=1558031
@Ladas Seems there is another possible symbol key in the saver area called |
BZ is marked POST but a few more symbols remain (UPDATED Nov 2018):
|
roundtrip through JSON. Since the API now exposes Settings, it's not possible to set Symbols as values. The saver_strategy was fixed in ManageIQ/manageiq#17168 to support String values, and the next step is to remove all Symbols from the Settings. ManageIQ/manageiq#17201 https://bugzilla.redhat.com/show_bug.cgi?id=1558031 673b088
roundtrip through JSON. Since the API now exposes Settings, it's not possible to set Symbols as values. The saver_strategy was fixed in ManageIQ/manageiq#17168 to support String values, and the next step is to remove all Symbols from the Settings. ManageIQ/manageiq#17201 https://bugzilla.redhat.com/show_bug.cgi?id=1558031
This issue has been automatically marked as stale because it has not been updated for at least 6 months. If you can still reproduce this issue on the current release or on Thank you for all your contributions! |
Symbols in configuration values are problematic because Symbols do not roundtrip through JSON. Since the API now exposes Settings, it's not possible to set Symbols as values. The saver_strategy was fixed in ManageIQ/manageiq#17168 to support String values, and the next step is to remove all Symbols from the Settings. ManageIQ/manageiq#17201 https://bugzilla.redhat.com/show_bug.cgi?id=1558031
@miq-bot remove-label stale |
Important for being able to safely modify settings through the REST API. ManageIQ#17201 https://bugzilla.redhat.com/show_bug.cgi?id=1558031
@miha-plesko @tadeboro you added the regexp support in #17295 and the specific regexp settings it in ManageIQ/manageiq-providers-nuage#119, ManageIQ/manageiq-providers-redfish#34. The problem with regexps in Settings is that ManageIQ has a RESP API for settings which represents full settings as JSON, and JSON doesn't have regexp type. Merely reading then writing settings via the API turns them into strings: Diff:
@@ -487,10 +487,10 @@
{:blacklisted_event_names=>[],
:event_handling=>
{:event_groups=>
- {:addition=>{:critical=>[/^nuage_.+_create$/]},
- :deletion=>{:critical=>[/^nuage_.+_delete$/]},
- :update=>{:critical=>[/^nuage_.+_update$/]},
- :status=>{:critical=>[/^nuage_alarm_.+$/]}}}},
+ {:addition=>{:critical=>["(?-mix:^nuage_.+_create$)"]},
+ :deletion=>{:critical=>["(?-mix:^nuage_.+_delete$)"]},
+ :update=>{:critical=>["(?-mix:^nuage_.+_update$)"]},
+ :status=>{:critical=>["(?-mix:^nuage_alarm_.+$)"]}}}},
:ems_openshift=>
{:blacklisted_event_names=>[], :event_handling=>{:event_groups=>nil}},
:ems_openstack=>
@@ -633,7 +633,8 @@
:connection_manager=>{:purge_interval=>"1.hour"}},
:ems_redfish=>
{:blacklisted_event_names=>[],
- :event_handling=>{:event_groups=>{:general=>{:critical=>[/^redfish_/]}}}},
+ :event_handling=>
+ {:event_groups=>{:general=>{:critical=>["(?-mix:^redfish_)"]}}}},
:ems_scvmm=>
{:blacklisted_event_names=>[], :event_handling=>{:event_groups=>nil}},
:ems_vmware=>
... [omitting other diffs from symbols becoming strings] ... What do you think? Could we always store regexps in string form? Or do you ability to distinguish regexp from simple string? |
Important for being able to safely modify settings through the REST API. ManageIQ#17201 https://bugzilla.redhat.com/show_bug.cgi?id=1558031
Ouch, thanks for noticing @cben . So currently we are able to distinguish between regex and plain string just directly by type to know what kind of comparison to perform, see here; it's Perhaps we could workaround it like you say, by passing also regexes as strings that we would distinguish by It should work this way, right @tadeboro ? |
Storing regular expressions in string form is something I would prefer to avoid. There are two main reasons for this:
Maybe api can perform some serialization and deserialization of regular expressions when requests are handled? |
This issue has been automatically marked as stale because it has not been updated for at least 6 months. If you can still reproduce this issue on the current release or on Thank you for all your contributions! |
Looks like we're close enough to it already, easier than alternatives?
https://bugzilla.redhat.com/show_bug.cgi?id=1558031
So:
I think we want to update each settings.yml, to use strings for these places, but keep code accepting either, in case any users modified these to another date/symbol.
Either that or:
When done,
JSON.parse(Settings.to_hash.to_json, symbolize_names: true) == Settings.to_hash
.@miq-bot assign Fryguy
The text was updated successfully, but these errors were encountered: