Bug 1486765 - [RFE][L-8] Ability to schedule date for automate tasks to be executed on
Summary: [RFE][L-8] Ability to schedule date for automate tasks to be executed on
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: API
Version: 5.7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.11.0
Assignee: drew uhlmann
QA Contact: Parthvi Vala
Red Hat CloudForms Documentation
URL:
Whiteboard:
Depends On:
Blocks: 1511957
TreeView+ depends on / blocked
 
Reported: 2017-08-30 13:53 UTC by myoder
Modified: 2023-03-24 13:51 UTC (History)
14 users (show)

Fixed In Version: 5.11.0.16
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-12 13:33:21 UTC
Category: Feature
Cloudforms Team: CFME Core
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:4199 0 None None None 2019-12-12 13:33:36 UTC

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


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