-
Notifications
You must be signed in to change notification settings - Fork 356
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
Lazy load StorageManagers upon volume creation #4549
Lazy load StorageManagers upon volume creation #4549
Conversation
@miq-bot add_label blocker |
@miha-plesko can you add a reviewer. We have an upcoming final dev complete on Sep 10 and this fix is needed. |
@JPrause I dont have enough permissions.. |
Thanks @miha-plesko it's enough if you ping them to review. |
@h-kataria @AparnaKarve @himdel @mzazrivec @skateman not sure who, but can someone please take a look at this one? It's kinda urgent. Thanks! |
@miha-plesko I verified that the reported issue has been fixed by this PR. I noticed something else while testing - With this PR - With master branch - Both Storage Manager and Availability Zone are read-only fields, so this is not a big issue. Anyway, this was something that I happened to notice, that is partially related to the subject matter of this PR, and exists in master 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.
Verified that the reported issue has been fixed.
Nice find, thanks @AparnaKarve. I'm refactoring a little more to get the issue fixed. What I'm going to do is introduce a new variable |
So... sounds like the bug is really that the controller is being used by multiple unrelated forms, isn't it? This should become 7 different controllers + a service to share common code. But.. perhaps more importantly, doesn't this break creating new cloud volumes? Since you can no longer pick a storage manager when EDIT: verified this is indeed the case, it's impossible to select a storage manager for new cloud volumes now. (And additionally, even though the field is required, it let's you save.) |
4ae7295
to
087b387
Compare
@himdel it was OK for adding new volumes because condition was in fact negated |
@@ -56,5 +56,6 @@ | |||
|
|||
:javascript | |||
ManageIQ.angular.app.value('cloudVolumeFormId', '#{@volume.id}'); | |||
ManageIQ.angular.app.value('storageManagerId', #{@volume.ext_management_system.id}); | |||
ManageIQ.angular.app.value('storageManagerId', '#{@volume.ext_management_system.id.to_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.
@AparnaKarve this is the reason why StorageManager wasn't getting selected upon volume edit (on master branch). It's because we're passing integer id from rails, but drop-down options somehow have strings. Well hidden bug, spent quite some time figuring it out :)
So the easiest solution is to convert it to string immediately here. Problem is if we would want it be integer, then we could hit overflow as MIQ ID's are huge numbers.
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.
Agreed, strings are necessary for our long ids in js :). (The to_s
is not necessary, but.. not a problem either.)
switch (cloudVolumeFormOperation) { | ||
case 'EDIT': | ||
// Fetch relevant StorageManager, just enough to populate the disabled drop-down. | ||
apiPromises.push(API.get(`/api/providers/${storageManagerId}?attributes=id,name`) |
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.
Uhh, can't do this here, sorry ;)
Anything under app/assets
needs to be ES5-only.
(so, I guess apiPromises.push(API.get('/api/providers/' + storageManagerId + '?attributes=id,name')
or sprintf)
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.
Thanks for noticing! I've changed as you suggest on both places, no other change, and pushed. Now I'm gone for the weekend :)
Verified I can now see the right manager in the new cloud volume screen. 👍 |
When creating a new volume user has to pick what StorageManager is volume supposed to be created with, hence we perform API request to fetch those. Problem is we share angular controller with other volume operations (attach, detach) that don't need this list of all managers and fetching those anyway results in permission denied error due to fine-grained permission setting. For example if we give user only permission to attach/detach volume, but not to view StorageManagers, then we must not perform the API call as it results in 403 with red popup. With this commit we refactor controller so that it now only performs the API calls that are really needed. BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1571224 Signed-off-by: Miha Pleško <[email protected]>
087b387
to
771e97f
Compare
Checked commit miha-plesko@771e97f with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
Going through the other templates, looks like only attach depends on extra data, covered by the |
Not seeing any breakage in the UI, merging 👍 |
Yeah @himdel , I was thinking about defaulting to zero API requests but then didn't dare to do it because I wasn't sure... Having this one merged I think it will be simple enough to do it should BZ arise :) |
@miha-plesko Yeah, agreed, for backporting, we better keep the existing behaviour. But if you're planning to do the split-the-controller PR, we may as well remove the extra calls there. |
@miha-plesko There are some conflicts (in |
Backported to Fine via #4600 |
Lazy load StorageManagers upon volume creation (cherry picked from commit 47c98ac) https://bugzilla.redhat.com/show_bug.cgi?id=1625249
Gaprindashvili backport details:
|
When creating a new volume user has to pick what StorageManager is volume supposed to be created with, hence we perform API request to fetch those. Problem is we share angular controller with other volume operations (attach, detach) that don't need this list of all managers and fetching those anyway results in permission denied error due to fine-grained permission setting.
For example if we give user only permission to attach/detach volume, but not to view StorageManagers:
then we must not perform the API call as it results in 403 with red popup:
With this commit we refactor controller so that it now only performs the API call "fetch storage managers" when we're creating a new volume, and not just always by default. Attaching/detaching volume therefore doesn't trigger the problematic API call anymore:
BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1571224
@miq-bot add_label bug,fine/yes,gaprindashvili/yes
@miq-bot assign @h-kataria
BZ is reported for Fine, therefore we have to reach that far.
/cc @AparnaKarve