Bug 1384724 - [RFE] Everything created from catalog items are not necessarily "services"(e.g. Not a Virtual Machine)
Summary: [RFE] Everything created from catalog items are not necessarily "services"(e....
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Provisioning
Version: 5.6.0
Hardware: All
OS: Unspecified
high
high
Target Milestone: GA
: 5.7.5
Assignee: John Hardy
QA Contact: Shveta
URL:
Whiteboard: service
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-14 01:25 UTC by Mike Dahlgren
Modified: 2019-12-18 14:27 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-18 14:27:28 UTC
Category: ---
Cloudforms Team: CFME Core
Target Upstream Version:


Attachments (Terms of Use)
Image of service that is not a service (124.00 KB, image/png)
2016-10-14 01:25 UTC, Mike Dahlgren
no flags Details

Description Mike Dahlgren 2016-10-14 01:25:05 UTC
Created attachment 1210291 [details]
Image of service that is not a service

Description of problem:

CloudForms makes the assumption that every Catalog item ordered is a "service" and has VM information which is not necessarily the case.

For example if a user creates a service that is not a VM such as a WordPress site, database, or just runs an Ansible job. Then there needs to be an option to automatically delete the corresponding "service" once finished.   

Attached is a screen shot of running an Ansible job directly that patches any host you run it against.  No point in having a persistent "service" that shows CPU/Memory/Disk infomation that is not a VM.  


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


How reproducible:


Steps to Reproduce:
1.Connect CloudForms to Ansible
2.Create a simple Ansible job that performs a simple task on a VM
3.Run that job ten times.


Actual results:
Ten "services" are created that make no sense as they are not VM's, and have no state of their own.


Expected results:
When creating the order dialog the user is given a choice to "delete service on completion" 



Additional info:

Comment 2 Greg McCullough 2016-10-17 17:59:39 UTC
John - Please review this RFE.  I have been asked about this before and I believe it makes sense to create an option for a service template so it is not visible in the users "My Service" list after order completion.

Maybe we do not delete them, but instead create a flag so they are archived and filtered out of the main list.

Comment 3 Mike Dahlgren 2016-10-17 19:10:47 UTC
The best solution would be for CloudForms to be smart enough that if a "yum update" was performed against a server with Ansible, that job and results would be tied to the VM in question.(Similar to how Ansible Tower works).  

However in the short term just having an option to hide these non-services from the user is a much need stopgap.

Comment 5 Greg McCullough 2016-10-25 12:18:02 UTC
Mike - Also wanted to point out that the object that represents the service instance in automate supports a "remove_from_vmdb" method.  So you could implement this today if you did want to completely remove the object from the database.

Comment 6 Greg McCullough 2016-11-07 20:36:49 UTC
https://www.pivotaltracker.com/story/show/133880813


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