[WIP] Clear cache of MiqProductFeature to store MiqUserRole

[lpichler]

Method rbac_compact_features called here is using cashe of feaures
(MiqProductFeature#feature_cache)

It needs to be cleared out when newly added tenant product features
are added.
even when it is cleared after tenant creation.

This is working locally in development mode and I am not sure why it is happening in product mode.
Anyway this PR is fixing this bug.

cc @gtanzillo @skateman

Reproducer:

Links

https://bugzilla.redhat.com/show_bug.cgi?id=1468795

@miq-bot add_label bug, blocker

[miq-bot]

Checked commit lpichler@f0a608c with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
1 file checked, 0 offenses detected
Everything looks fine. 👍

[Fryguy]

This feels weird here...IIRC, the purpose of the cache was because features are static. If they are not (thinking about that new dynamic set of features), then I would expect clearing of the cache to be in the model itself, not in the UI.

[lpichler]

@Fryguy then are not static now, and clearing is done on model level but it is not working in production mode. Do you have any idea how it could be possible ?

[gtanzillo]

Is it possible that the code that clears the cache in the model is not being executed in the same process as the UI? Since the clear is tied to a callback. It may be problematic in general when there's more than 1 UI worker

[skateman]

@gtanzillo yup, models are isolated from the controllers. I don't think you have access to the session from models without explicitly passing it, but I can dig into this if you want a precise answer.

[lpichler]

@skateman I want a precise answer :)

[skateman]

Okay, I checked the object_ids and they're all good so the issue is not there. I noticed that the tenant creation is done in the API, but I'm using rails s so it uses the same process for handling the requests.

I added some debugger breakpoints in the area and determined, that after cleaning the cache in the API request, it truly becomes empty. However, when the next UI request gets fired, the cache has the items as nothing happened.

I was thinking that it has something to do with the session, but I'm not sure how the session is implemented in the API.

# API
pry(#<OpsController>)> session
=> #<ActionDispatch::Request::Session:0x7f7efb4cf410 not yet loaded>
pry(#<OpsController>)> session.object_id
=> 70091679365640

# UI
pry(#<OpsController>)> session
=> #<ActionDispatch::Request::Session:0x00007f7ef82cd408 ...>
pry(#<OpsController>)> session.object_id
=> 70091653147140

The object_ids should be probably different, but in the API the object is not yet loaded. I don't know what it means, but it might be helpful to someone else. So the thing I determined is that if you clean the cache from the API, it doesn't reflects the changes in the UI...

PS: I almost depleted the pool of available Men in Black character names during the testing.

[lpichler]

thanks! and we found other solution #5108