RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1680293 - [machines] React to external Storage Pool changes
Summary: [machines] React to external Storage Pool changes
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: cockpit-appstream
Version: 8.0
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: 8.1
Assignee: Martin Pitt
QA Contact: YunmingYang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-23 17:25 UTC by Siddhant Rao
Modified: 2020-11-14 06:38 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 20:41:39 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3935821 0 None None None 2019-02-23 18:45:10 UTC
Red Hat Product Errata RHBA-2019:3325 0 None None None 2019-11-05 20:41:48 UTC

Description Siddhant Rao 2019-02-23 17:25:07 UTC
Description of problem:

Add Refresh Button to check changes in Storage Pool
When making any changes in the storage pool , these changes are not reflected in the cockpit GUI 

Version-Release number of selected component (if applicable):
cockpit-185-2.el8.x86_64
cockpit-machines-184.1-1.el8.noarch

How reproducible:
100%

Steps to Reproduce:
1) Make a manual change in storage pool, for example create a qcow2 image manually in the storage pool.


Actual results:
Change is not reflected in the cockpit UI.

Expected results:
Change should be seen in the cockpit UI.

Additional info:
I tried logging in and logging out of cockpit GUI . That did not work as well
The change should be triggered automatically, but if it cannot, then perhaps a refresh button would be good.

Comment 1 Katerina Koukiou 2019-03-22 14:21:16 UTC
@Siddhant When you manually add a volume in a pool libvirt is not aware of it.
Verify yourself: If you execute virsh vol-list $MY_POOL you will not see your new volume there. You can make it visible by virsh pool-refresh $POOL_NAME.

This is essentially what we are doing when user is deleting volumes from cockpit UI. Same, once we 'll implement the feature to add a storage volume to an existing pool, we will refresh the pool after adding the volumes.

Regarding the refresh button I think it is not good idea to get implemented. Once the functionality to add volumes from cockpit UI is in, there will not be need for explicit refresh, it will be called internally.
For the time being, since you are already on terminal to add the new image, you can probably just do the refresh there as well, instead of clicking a button from UI.

Let me know if you agree.

Comment 2 Siddhant Rao 2019-03-28 19:15:01 UTC
@Katerina,

I have no issue's with what you ask , I just thought It would be a good feature to include if some sort of manual intervention if required , say for example if the volume , say a multipath device goes missing , then will libvirt understand that the volume is missing suddenly and remove it's entry from the UI?. or will it still show until you run virsh pool-refresh $POOL_NAME.

Just asking for curiosity.

Also it would be much more user friendly since a lot of end users may not know the command "virsh pool-refresh $POOL_NAME". However it's not a tough find.

If adding / removing is going to trigger the refresh , then well I have no problem with not implementing it, However will it handle such cases as mentioned above where due to some unforeseen reasons , the volume is not present?.

Comment 3 Katerina Koukiou 2019-03-29 09:49:20 UTC
@Siddhant no, if a volume will get removed manually, or anyhow except from within the cockpit UI, the UI will not update, simply because libvirt does not offer events for Storage Volumes.
So, let's leave this feature request open. Thanks!

Comment 4 Martin Pitt 2019-06-04 05:54:55 UTC
Adjusting the title to be more appropriate. This is blocked by missing libvirt API by now.

Indeed we won't add "Refresh" buttons to Cockpit. If needed, just use the general browser Reload button/key.

Comment 5 Katerina Koukiou 2019-07-18 13:11:14 UTC
Fixed by:

commit 026dd4f08e7d130aa6b9d2df0669c8aa1bf39b6c
Author: Katerina Koukiou <kkoukiou>
Date:   Thu Jul 11 11:22:44 2019 +0200

    machines: when fetching storage pools refresh them first if they are active

$ git describe 026dd4
198-67-g026dd4f08

Now, plain reload of the browser page will refresh pool data.

Comment 6 Martin Pitt 2019-07-18 13:22:08 UTC
Yunming, can you please QA ack? I'd like to backport that fix into RHEL 8.1.

Comment 8 YunmingYang 2019-08-06 11:09:31 UTC
Test Versions:
cockpit-machines-197.1-1.el8.noarch
libvirt-dbus-1.2.0-2.module+el8.1.0+2983+b2ae9c0a.x86_64


Test Steps:
1. Login cockpit
2. Prepare a storage pool, then check the storage pool and the volumes in this pool through UI
3. Create a disk manually, just like ‘qemu-img create -f qcow2 {vol-bane}.qcow2 1G’
4. Check the volumes in the storage pool through UI
5. Refresh the page, re-check the volumes in the storage pool through UI

Test Results:
1. After step4, the volume which is created manually is not shown on the UI.
2. After step5, the volume which is created manually is shown on the UI.

According to the results, move the status to VERIFIED.

Comment 10 errata-xmlrpc 2019-11-05 20:41:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3325


Note You need to log in before you can comment on or make changes to this bug.