Bug 1668020 - Inactive datastore is used to provision a vm with VMware provider
Summary: Inactive datastore is used to provision a vm with VMware provider
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.9.2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: GA
: 5.11.0
Assignee: drew uhlmann
QA Contact: Kedar Kulkarni
Red Hat CloudForms Documentation
URL:
Whiteboard:
Depends On:
Blocks: 1669582 1669583
TreeView+ depends on / blocked
 
Reported: 2019-01-21 17:36 UTC by Imaan
Modified: 2022-03-13 16:49 UTC (History)
11 users (show)

Fixed In Version: 5.11.0.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1669582 1669583 (view as bug list)
Environment:
Last Closed: 2019-12-13 15:09:41 UTC
Category: Bug
Cloudforms Team: VMware
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Imaan 2019-01-21 17:36:47 UTC
Description of problem:

In compute -> infrastructure, there is an "inactive" datastore and CFME tries to provision VM in it hence failing with the following error:

~~~

Status [Error Creating VM] Message [[MiqException::MiqProvisionError]: Destination placement_ds_name not provided] "}

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

Cfme- 5.9.2 (Red Hat CloudForms)

Steps to Reproduce:

1. Login to CloudForms operational portal
2. Navigate to Compute -> Infrastructure -> Datastores 
3. Selected in-active datastore
4. Click on Configuration > Remove Datastore from inventory
5. Provision the VM.

Actual results:

VM provisioning is failing with a mentioned error.

Expected results:

CFME should not try to provision VMs in in-active datastores of VMware provider

Comment 3 Greg McCullough 2019-01-21 18:21:38 UTC
This is how the product is designed to work when selecting a specific datastore.  If you want dynamic behavior you will want to either select Auto-placement or you can modify the default placement logic in automate so it adjusts the storage if the target storage is no longer available.

I would expect that this ticket should ultimately be closed as not a bug.

Comment 4 Tina Fitzgerald 2019-01-21 19:47:25 UTC
Hi Imaan,

Can you ask the customer to clarify how the datastore is inactive? 

For example, is it in maintenance mode, or is the managed entity status "grey" or "red"?

Thanks,
Tina

Comment 13 Tina Fitzgerald 2019-01-22 20:03:05 UTC
Hi Neha,

Since it's likely that there will need to be code changes to capture the additional datastore information, 
we've identified 2 possible workarounds for the customer to use in the meantime:

1. Make API calls to VMware during the placement Automate method to determine if the datastore is valid for provisioning.
2. Use the "Best Fit with Scope" placement logic which requires manual tagging of data-stores to avoid Inactive resources.

Could you work with them to implement one of the workarounds?

Thanks,
Tina

Comment 15 Adam Grare 2019-01-23 14:09:31 UTC
Interesting so I was expecting the "inactive" datastore would have had an overallStatus that was red like the last datastore.  I'll need to investigate what inactive in the UI translates to in the API.

Comment 19 Tina Fitzgerald 2019-01-23 16:00:05 UTC
Hi Neha,

I was thinking about the customer using the best_fit_with_scope method, explained here;
https://access.redhat.com/webassets/avalon/d/Mastering_CloudForms_Automation_Red_Hat/Mastering_CloudForms_Automation_Red_Hat.pdf

Thanks,
Tina

Comment 22 Adam Grare 2019-01-24 15:45:34 UTC
https://github.com/ManageIQ/manageiq/pull/18391

Comment 25 Adam Grare 2019-01-29 13:34:22 UTC
Back end has been updated to expose a host.writable_accessible_storages association which filters out inaccessible storages.  Assigning to the automate team to update the automate methods.

Comment 26 Greg McCullough 2019-01-29 14:23:54 UTC
Tina - Let's discuss.  I'm thinking we have a couple of options on how to resolve this upstream.  

1. Add the new method to automate service model and update the automate methods that call it.
2. Redirect the existing writable_storages method exposed to automate to call writable_accessible_storages.  This would avoid having to update automate methods to use the new method.  From automate I'm not sure a user would need to distinguish between writable_storages and writable_accessible_storages.
3. A bigger change would be to implement eligible_storages in the best_fit methods.

Comment 28 CFME Bot 2019-02-13 10:40:14 UTC
New commit detected on ManageIQ/manageiq-schema/master:

https://github.com/ManageIQ/manageiq-schema/commit/547d4af71ad5c00527a32625ff6b18339ac9917e
commit 547d4af71ad5c00527a32625ff6b18339ac9917e
Author:     Adam Grare <agrare>
AuthorDate: Wed Jan 23 16:06:24 2019 -0500
Commit:     Adam Grare <agrare>
CommitDate: Wed Jan 23 16:06:24 2019 -0500

    Add Accessible to HostStorages

    Add a property to the host storage mount information about if a
    particular datastore is accessible to the given host or not.

    If a datastore is inaccessible for some reason (e.g. the NFS server is
    down) then even though read_only may be false the datastore still cannot
    be accessed.

    VMware tracks this property in the HostMountInfo (where read_only is
    already pulled from) in a boolean field called "accessible" [0].

    This can be used to ignore offline datastore for the purposes of
    provisioning as well as alerting the user of issues on their datastores

    [0] https://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vim.host.MountInfo.html

    https://bugzilla.redhat.com/show_bug.cgi?id=1668020

 db/migrate/20190123210452_add_accessible_to_host_storages.rb | 5 +
 1 file changed, 5 insertions(+)

Comment 29 CFME Bot 2019-02-14 09:57:01 UTC
New commit detected on ManageIQ/manageiq-providers-vmware/master:

https://github.com/ManageIQ/manageiq-providers-vmware/commit/01f506a5b62e31900b0e6f8d6483a64f82f6ec15
commit 01f506a5b62e31900b0e6f8d6483a64f82f6ec15
Author:     Adam Grare <agrare>
AuthorDate: Wed Jan 23 16:28:01 2019 -0500
Commit:     Adam Grare <agrare>
CommitDate: Wed Jan 23 16:28:01 2019 -0500

    Parse if a datastore is accessible from a host

    Parse if a datastore is able to be accessed from a host into the
    host_storage record.

    https://bugzilla.redhat.com/show_bug.cgi?id=1668020

 app/models/manageiq/providers/vmware/infra_manager/inventory/parser/datastore.rb | 9 +-
 app/models/manageiq/providers/vmware/infra_manager/refresh_parser.rb | 11 +-
 spec/models/manageiq/providers/vmware/infra_manager/refresher_spec.rb | 7 +
 spec/tools/vim_data/miq_vim_inventory/dataStoresByMor.yml | 280 +
 4 files changed, 299 insertions(+), 8 deletions(-)

Comment 30 CFME Bot 2019-02-15 10:29:09 UTC
New commit detected on ManageIQ/manageiq/master:

https://github.com/ManageIQ/manageiq/commit/afddd9479639d504bd157260e7377359b9c75bd7
commit afddd9479639d504bd157260e7377359b9c75bd7
Author:     Adam Grare <agrare>
AuthorDate: Thu Jan 24 10:23:12 2019 -0500
Commit:     Adam Grare <agrare>
CommitDate: Thu Jan 24 10:23:12 2019 -0500

    Add method for restricting to accessible storages

    Use the host_storage.accessible property to filter storages that cannot
    be accessed by the provider due to be disconnected or otherwise
    inaccessible.

    https://bugzilla.redhat.com/show_bug.cgi?id=1668020

 app/models/host.rb | 2 +
 app/models/host_storage.rb | 12 +
 app/models/miq_request_workflow.rb | 2 +-
 app/models/vm_or_template/operations/configuration.rb | 2 +-
 4 files changed, 16 insertions(+), 2 deletions(-)

Comment 31 Kedar Kulkarni 2019-04-26 20:05:09 UTC
Verified on 5.11.0.1


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