Bug 1183306 - [RFE][HC] - volumes actions should be restricted when volume is assigned as a storage domain within hyperconverged cluster
Summary: [RFE][HC] - volumes actions should be restricted when volume is assigned as a...
Keywords:
Status: CLOSED DUPLICATE of bug 1182774
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RFEs
Version: ---
Hardware: x86_64
OS: Linux
unspecified
high vote
Target Milestone: ovirt-4.0.0-alpha
: ---
Assignee: Sahina Bose
QA Contact: Pavel Stehlik
URL:
Whiteboard:
Depends On:
Blocks: Generic_Hyper_Converged_Host 1182774 1183307 Gluster-HC-2
TreeView+ depends on / blocked
 
Reported: 2015-01-18 12:55 UTC by Yaniv Lavi
Modified: 2016-03-08 15:41 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 1182774
Environment:
Last Closed: 2016-03-08 15:41:45 UTC
oVirt Team: Gluster
ylavi: ovirt-4.0.0?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?


Attachments (Terms of Use)

Description Yaniv Lavi 2015-01-18 12:55:05 UTC
+++ This bug was initially created as a clone of Bug #1182774 +++

Description of problem:
In hyperconverged, a gluster volume becomes the storage domain for vm images. However, actions on the volume (stop/remove) are not currently prevented when the volume is actually assigned and in use as a storage domain.

Once a volume has been assigned as a storage domain, it should 'own' the glusterfs volume and the workflow around these tasks should change to be oVirt orientated.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. in hyperconverged cluster, create a volume and start it
2. add the volume as a storage domain to oVirt
3. go to the volumes tab and issue a stop to confirm that a volume action does not link to actions against the associated object in oVirt

Actual results:
stop and remove are allowed underneath an active storage domain.

Expected results:
For a volume that is a storage domain (hyperconverged - or not!), I would expect the following to happen;

* Volume Stop ;
  - include on the "stop volume" modal dialog the fact that this volume is 
    assigned as a storage domain
  - once the admin confirms the stop operation, place the domain into maintenance mode for consistency in the UI
  - once in maintenance mode, the voume stop can be performed

* Volume remove (note a stop must have already been performed)
  - should prompt for confirmation pointing out that the volume is a storage domain
  - if the user confirms removal
    - destroy the associated storage domain
    - issue the vol delete to remove the volume

* Volume start;
  - start the volume 
  - check domain state, and if in maintenance mode issue an activate



Additional info:

Comment 1 Red Hat Bugzilla Rules Engine 2015-10-19 10:55:01 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 2 Sahina Bose 2016-03-08 15:41:45 UTC

*** This bug has been marked as a duplicate of bug 1182774 ***


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