-
Notifications
You must be signed in to change notification settings - Fork 357
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
Provisioning Workflows are being stored directly in session #7877
Comments
What is the recommended approach? Store the IDs in the session and look up the objects when needed? |
That would be an ideal solution but it looks more complicated than that. The code is deeply tied together and I can't tell what parts of the workflow object the UI needs in session. The only way I can think of doing it is just not store it in session and see what breaks. Then, store just what you need in session in a new object to get past that error. Rinse/repeat. There were 80 references to |
what if the setters to |
Yeah, that would work but many areas in miq_request_methods try to access fields / dialogs and refresh data on demand so I think the default is to get much of the data up front in the wf object, cache it in the object stored to session and refresh it as needed. If this is the case, I'd imagine, the getter would need to either eager load the full object on load or lazily load the wf components on demand. Both of these could have performance implications and complexity. Additionally, is it possible that we store wf objects that aren't yet persisted with an id? I'm not sure. We've done it before for authentications we need to verify before we create. Basically, I have more questions than answers. |
I think the basic problem is that the workflow is a state based object. As users change their selections, things like the allowed lists are updated, and then the UI needs to reflect that. If we throw that away, we probably need to recalculate all of the allowed lists over again. However, that may not be a bad thing. Ultimately this will go to react though, and the nice thing about react is the state is held on the page on the client side (as opposed to server side for a regular Rails page). There can be API calls then which optimize building/filtering the allowed lists. @agrare and I have discussed designing that; we should probably bump the priority on that. |
Wondering if this is related to #7144 |
Yes, good find! It looks like @agrare had large dialogs in #7144 bloating the workflow whereas we had a large number of deprecated templates for GCE bloating the workflow in ManageIQ/manageiq#21455 and it's related google provider issue: ManageIQ/manageiq-providers-google#198 Since both dialogs and templates are stored in the provisioning workflow, which is saved into session, the end result is the same, too much data and you can't save it in session. |
So that means we can close #7144? |
yeah, I closed the other. This seems like the more general issue. |
This issue has been automatically marked as stale because it has not been updated for at least 3 months. If you can still reproduce this issue on the current release or on Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation. |
The contents of
@edit
are being stored into session. Included in@edit
in the provisioning pages is the@edit[:wf]
which is an instance of a provisioning workflow object.This is used throughout the UI in these pages but most specifically throughout this file
We shouldn't be storing such large objects into session.
As an side effect, the following issues/PRs were raised because this large object stored very large lists of
allowed_templates
:ManageIQ/manageiq#21455
ManageIQ/manageiq-providers-google#198
For example, when walking the code that checks for session bloat, I found that there were thousands of openstructs for each template in the list of templates within the
wf
object:We shouldn't store the workflow object in the session at all.
The text was updated successfully, but these errors were encountered: