Description of problem: Cloudforms SmartState Analysis produces an error when an OpenStack instance is booted from a Cinder volume. The reported error is: "Unable to mount filesystem. Reason:[Image: EvmSnapshot (00cc8ca8-a06e-4fd0-a278-c77678bc9e76) is empty]" Version-Release number of selected component (if applicable): 5.5.3.4.20160407153134_b3e2a83 How reproducible: 1. Create an OpenStack instance booted from a Cinder volume a. Log-in to Horizon b. Select an appropriate project c. Select "Volumes" d. Select "Create a Volume" e. Under "Volume Source" f. Under "Use image as a source" select an appropriate image g. Select "Instances" h. Select "Launch Instance" i. Under "Instance boot source" select "Boot from volume" j. Under "Volume" select the volume created in (c)-(f) 2. Log-in to the Cloudforms appliance, and select the instance created in (1) (perform a "Refresh Relationships and Power States" for the provider if required to discover the instance) 3. Select "Configuration" -> "Perform SmartState Analysis" for the instance Actual results: Cloudforms is unable to analyse the instance, and reports an error: "Unable to mount filesystem. Reason:[Image: EvmSnapshot (00cc8ca8-a06e-4fd0-a278-c77678bc9e76) is empty]" Expected results: Cloudforms performs the SmartState Analysis and reports back results as it would for an OpenStack instance booted from ephemeral disk
Moving to RHOS 12 for assessment with Cloudforms org.
Right now the proposal on the table is to attempt a work around from the cloud forms side because there is not a practical path to alter the OpenStack APIs anytime soon to allow the existing code flow to work. >>>> Option 2- Accessing persistent volumes data: A workaround has been proposed in the meeting to resolve this situation and it involves altering the Cloud Forms code path for the instance introspection. <<<< So at the moment, there are no OSP changes planned and need to decide if we keep this clone of this clone of original CF bug - #b1341867
This bugzilla has been removed from the release and needs to be reviewed and Triaged for another Target Release.
Closing this CLONE of the original issue. The original issue is not a bug with the existing API calls to OSP, but instead requires a different code flow to get the same information if we want to use existing APIs and current OSP releases. There is a proposal for a new API to simplify that flow, but that will be tracked as a new RFE BZ if accepted. For now Here's a basic summary of the proposed CF changes that would be needed to address the issue and the issue should continue to be tracked in: https://bugzilla.redhat.com/1341867 Proposed code flow in CF for use with existing API calls: ---------------------------------------------------------- A workaround has been proposed to resolve this situation and it involves altering the code path for the instance introspection. The code flow for the instance introspection would end up like this: * Request instance snapshot to Nova * Is created glance image a full image? * Yes --> proceed to download to appliance * No, it's just metadata: * Request Cinder to create a volume from the snapshot ID in the metadata * Request Cinder to upload this new volume to a Glance image * Proceed to download this new image to appliance * Delete new artifacts (new image and temporary volume) * Delete glance image from the instance snapshot Concerns were expressed about the performance implications of these additional steps, since they were already experiencing some issues with the current flow from time to time. Truth is that for most backends this new flow will not be more likely to timeout than the previous flow, because there'll be just one data upload to Glance in both cases. For ephemeral volumes the process is: * Nova creates a snapshot of the volume locally --> Fast * Creates a Glance image --> Fast * Uploads data to Glance --> Slow * Delete glance image --> Fast For persistent volumes the process is: * Nova requests Cinder to create a snapshot of the volume --> Fast * Creates a Glance image and stores metadata--> Fast * CF creates volume from Snapshot in Cinder --> Fast in most backends * CF request Cinder to uploads volume to Glance image --> Slow * Delete glance images --> Fast * Delete Cinder volume --> Probably slow (data clear) So, as can be seen the only additional slow operation will be clearing a cinder volume, and that could be left to the last step, and that artifact is unlikely to get "lost" even if the operation timeouts because a volume listing will show that it is "deleting" and there will be no doubt that the volume is no longer needed.