Bug 1486765

Summary: [RFE][L-8] Ability to schedule date for automate tasks to be executed on
Product: Red Hat CloudForms Management Engine Reporter: myoder
Component: APIAssignee: drew uhlmann <duhlmann>
Status: CLOSED ERRATA QA Contact: Parthvi Vala <pvala>
Severity: high Docs Contact: Red Hat CloudForms Documentation <cloudforms-docs>
Priority: high    
Version: 5.7.0CC: asoni, dmetzger, duhlmann, greartes, gtanzill, jhardy, lavenel, mfeifer, mkanoor, nchugh, obarenbo, sbulage, simaishi, tfitzger
Target Milestone: GAKeywords: FutureFeature, Reopened
Target Release: 5.11.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 5.11.0.16 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-12-12 13:33:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: Feature
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: CFME Core Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1511957    

Comment 4 Neha Chugh 2019-02-14 05:51:36 UTC
Hello Loic,

I am re-opening this RFE as when executing the automation tasks via API, there is no schedule option has been observed as we have in the Provisioning Requests.

In the provisioning request[1], we can provide schedule_type and schedule_time information in the "vm_field" parameter as an option but we require similar scheduling options when we send automation request via API.

Below are the details that we used while sending the automation request via API as well as through automate workspace:

~~~
require 'rest-client'
require 'json'
require 'uri'
api_uri = "https://<serverid>/api"
url = URI.encode(api_uri + '/auth')
rest_return = RestClient::Request.execute(
           method: :get,
           url: url,
           :user => "admin",
           :password => "smartvm",
           :headers => {:accept => :json},
           verify_ssl: false)
auth_token = JSON.parse(rest_return)['auth_token']
puts auth_token

url = URI.encode(api_uri + '/automation_requests')
puts url
post_params = {
   :version => 1.1,
   :uri_parts => {
   :namespace => 'testNS',
   :class => 'Methods',
   :instance => 'hello'
},
:parameters: {
 "
:requester => {
   :auto_approve => true
}
}.to_json
rest_value = RestClient::Request.execute(
             method: :post,
             url: url,
             :payload => post_params,
             :headers => {:accept => :json, 'x-auth-token' => auth_token},
             verify_ssl: false)
puts rest_value
result = JSON.parse(rest_value)
puts result
request_id = result['results'][0]['id']
puts request_id
           
~~~

And through automate workspace as below:

~~~
options = {}
options[:namespace] = 'testNS'"
options[:class_name] = 'Methods'
options[:instance_name] = 'hello'
approve = true

$evm.execute('create_automation_request', options, 'admin', approve)

~~~

In both the scenarios, these are the attributes that are supported with Automation Request which doesn't include scheduling option i.e.

=> #<MiqAeServiceAutomationRequest:0x53e6ebc @object=#<AutomationRequest id: 1000000000009, description: "Automation Task", approval_state: "approved", type: "AutomationRequest", created_on: "2019-02-13 09:33:08", updated_on: "2019-02-13 09:33:09", fulfilled_on: nil, requester_id: 1000000000001, requester_name: "Administrator", request_type: "automation", request_state: "pending", message: "Automation Request - Request Created", status: "Ok", options: {:namespace=>"testNS", :class_name=>"Methods", :instance_name=>"hello"}, userid: "admin", source_id: nil, source_type: nil, destination_id: nil, destination_type: nil, tenant_id: 1000000000001, service_order_id: nil, process: true, cancelation_status: nil>, @virtual_columns=["href_slug", "reason", "region_description", "region_number", "request_type_display", "resource_type", "stamped_on", "state", "v_allowed_tags", "v_approved_by", "v_approved_by_email", "v_workflow_class"], @associations=["approvers", "automation_tasks", "destination", "miq_request", "miq_request_tasks", "requester", "resource", "source", "tenant"]>


We offered few of the workarounds to the customer such as using cron jobs or send the schedule time via dialog and compared the current time with schedule time and accordingly execute the automation task but none of the workarounds feasible to the customer.

The reason for re-opening the RFE is to have sophisticated way to schedule the automation tasks as we have it for provision requests[1] via API.


[1].https://access.redhat.com/solutions/3908611


Regards,
Neha Chugh

Comment 5 Loic Avenel 2019-02-14 11:27:42 UTC
I am trying to understand precisely the requirement. It is possible today via UI to set a scheduling for an Automate Task. Here you want to be able to set a Schedule Task via RestAPI?

Comment 6 Neha Chugh 2019-02-14 11:57:33 UTC
Yes Loic, that is the requirement. Customer is aware about scheduling the Automate task via UI but he want to do it through REST API.

We can schedule provisioning request[1] via API in similar fashion it should schedule the automate task through Rest API.

[1]. https://access.redhat.com/solutions/3908611

Regards,
Neha Chugh

Comment 16 drew uhlmann 2019-05-02 20:17:14 UTC
The start of this is here: https://github.com/ManageIQ/manageiq-api/pull/583

Comment 17 drew uhlmann 2019-05-07 12:23:48 UTC
And some here: https://github.com/ManageIQ/manageiq/pull/18741

Comment 19 drew uhlmann 2019-07-17 13:17:43 UTC
Hey Parthvi. Try this: 

You don't need this: '"schedule_type": "schedule",' since it'll pick up that you've got the param of schedule_time (see https://github.com/ManageIQ/manageiq/pull/18741/files#diff-e3295c427cec18ad642950055ae49a3bR29). However, your unit for the time is wrong, it should be a count of days from now till the request processes on the queue, so change 12:35 to ten or something.

Comment 21 drew uhlmann 2019-07-19 21:15:28 UTC
https://github.com/ManageIQ/manageiq/pull/18997

Comment 22 Parthvi Vala 2019-07-25 09:21:19 UTC
FIXED. Verified on 5.11.0.16.20190724210259_2b4aa51.

Comment 25 errata-xmlrpc 2019-12-12 13:33:21 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:4199