Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Peter McGowan
@pemcg
but service_vars would be the preferred way
zigaSRC
@zigaSRC
Ok, then thank you for the info so far! Will try it out and if I encounter any problems I'll report back :)
Peter McGowan
@pemcg
:thumbsup:
Halász Dávid
@skateman
who can merge this for us? we are requiring a newer version of node and it was not updated in the guides
Joe Rafaniello
@jrafanie
@himdel beat me to it. :thumbsup:
Martin Hradil
@himdel
heheh :)
Kavita4
@Kavita4

We are facing an issue with tracking the status of the retire vm action using CloudForms api.This 'request_retire' action on vm instance internally creates a service request to retire vm, However there is no reference of the request Id returned by the post API call. We are not able to trace the status of the retire vm action.
POST api call to trigger retire vm action using CloudForms api

curl -X POST \
  https://{cf-host}/api/vms/{vmId} \
  -d ' {
     "action": "request_retire"
    }'

Response

 {
   "body": {
       "success": true,
      "message": "VM id:171 name:'UATAnsible1' request retire",
        "task_id": "7277",
       "task_href": "https://{cf-host}/api/tasks/7277",
       "href": "https://{cf-host}/api/vms/171"
   },
  "statusCode": 200
 }

Status check using the task_id returned in the response gives status as success, even before the service request completes execution.
Currently there is no way to get the reference of the service request that gets generated internally to track the status of this service request that gets generated.
cc: @aniruddhanavare @prkurade

1 reply
zigaSRC
@zigaSRC
Hej, again :)
Is anyone aware of a solution for emailing in jansa-1? Emailing just doesn't seem to work. More info in: http://talk.manageiq.org/t/no-email-notifications-since-jansa-upgrade/5147/3
Aniruddha Navare
@aniruddhanavare
Hello.. Does anybody knows how to get request ID for delete / retire VM from CloudForms ? It's same what @Kavita4 aske earlier
Halász Dávid
@skateman
there is, the task_id
d-m-u
@d-m-u
the task_id won’t tell you about the status of the retirement request though. we queue vm retirement with that call, which is why the api doesn’t (and can’t) return information about the retire request.
Oleg Barenboim
@chessbyte
FYI - we will be making the Kasparov branch in the next few days and working on building the Kasparov Beta release
Jason Frey
@Fryguy
:tada:
sonalkakode
@sonalkakode

I had a few queries related to metric rollups apis.I found different apis for metric rollup of resources
1.) Metric Rollup api - /api/metric_rollups
Issue with following parameters
end_date - Even if end_date is provided , i get data for timestamp above the end_date.
resource_ids - Always returns empty result for any vm ids provided( Tried the same api using vm id(/api/vms/<vm_id>?attributes=metric_rollups) and could see metrics for the vm )
resource_type - Other than VmOrTemplate, Service which other resources are supported ?
2.) Metric Rollup for specific collection(resource) - /api/collection/<id>/metric_rollups
Issue with following parameters :
end_date - Even if end_date is provided , i get data for timestamp above the end_date.
Works for VMS and Services only - which other resources are supported ?
3.) Metric rollup using attributes - /api/collection?attributes=metric_rollups
This attribute gives data for the following but there is no filtered using capture_interval / start_date/ end_date etc.

    - Hosts
    - Datastores
    - VMS
    - Clusters

Can I get some help understanding this ? @Fryguy
cc :@aniruddhanavare @prkurade

d-m-u
@d-m-u
anyone who's running cross repo tests, the manageiq-cross_repo-tests repo got updated recently and since that's a bit unusual i thought i may as well inform folk here that it might be helpful to update that repo locally
sonalkakode
@sonalkakode
thank you @Fryguy , will check this and get back in case of any concerns
Peter McGowan
@pemcg
@Fryguy That’s an interesting read, especially "However, the first collection begins 5 minutes after the CFME Server is started, and every 10 minutes after that.”. I thought the collectors will start dequeuing messages as soon as the coordinator has enqueued them? The coordinator wakes up every 3 minutes.
Jason Frey
@Fryguy
that doc might be old, honestly
Peter McGowan
@pemcg
:thumbsup:
Jason Frey
@Fryguy
@kbrock made a bunch of changes to that flow kind of recently...he might know better now
Adam Grare
@agrare
@pemcg the collectors will start to dequeue immediately, but the perf_capture_timer schedule job has a 5 minute initial delay
Peter McGowan
@pemcg
Aah, ok, thanks
Peter McGowan
@pemcg
I did a presentation a couple of years ago on C&U data collector worker numbers based on some scale testing I was doing - slide copies here: http://talk.manageiq.org/t/estimating-the-required-number-of-c-u-data-collector-workers/5047
Keenan Brock
@kbrock
I'm waiting for @agrare to rewrite that and throw the old implementation away
thesystemninjaneer
@thesystemninjaneer
In Jansa-1 release I have added one Container provider and one VM provider. Is it possible to create a policy condition that checks cpu load of a VM and launch containers when over a set high amount for a defined period of seconds? just read through the policy documentation and seems possible but struggling to implement in the gui. Saw "Cpu Usage Rate Average High Over Time Period" in VM control policies under Control -> Explorer -> Policies but didnt see how to create the appropriate action for the Container provider.
Peter McGowan
@pemcg
@thesystemninjaneer it might be easiest to get your alert to "Send a Management Event” which starts an automation workflow. From Automate (Ruby or Ansible) you could perform your custom container actions
thesystemninjaneer
@thesystemninjaneer
thanks @pemcg i'll take a look.
Nick LaMuro
@NickLaMuro

Public Service Annoucement: ManageIQ master is most likely busted due to this change being merged recently:

ManageIQ/manageiq-providers-google#161

Pushing a PR for it shortly

ManageIQ/manageiq#20721

cc @Fryguy @d-m-u

d-m-u
@d-m-u
pretty sure you were one PR too late :laughing: ManageIQ/manageiq#20720
Nick LaMuro
@NickLaMuro
welp, clearly I didn't rebase properly recently enough to catch that... IGNORE ME!!!
bah... looks like I fetched upstream, but didn't rebase it in... good job self...
sonalkakode
@sonalkakode
Hello, So I hit this "api /api/metric_rollups?expand=resources&resource_type=VmOrTemplate&capture_interval=daily&start_date='2020-10-19'&end_date='2020-10-20'&sort_by=timestamp&sort_order=desc" but I get response with timestamp of 21st oct and 22nd oct as well , even though my end_date is 2020-10-20.
enddate
1 reply
sonalkakode
@sonalkakode
endDate.png
Keenan Brock
@kbrock
anyone have tricks on fixing:
Bundler could not find compatible versions for gem "rubocop":
  In Gemfile:
    rubocop (~> 0.72.0)

    manageiq-style was resolved to 1.1.0, which depends on
      rubocop (~> 0.82.0)
Jason Frey
@Fryguy
bundle update rubocop?
Keenan Brock
@kbrock
bundle update from vmware, manageiq - seem to get the same
Jason Frey
@Fryguy
wait why do you have 0.72.0
rebase?
Keenan Brock
@kbrock
yea - I'll have to track down the project / gemfile. thanks
Jason Frey
@Fryguy
or maybe you have rubocop in your bundler.d files?
Keenan Brock
@kbrock
sweet - thanks @Fryguy found it pegged in my dev
yea
Jason Frey
@Fryguy
:+1:
Keenan Brock
@kbrock
just found it after you said the version
Jason Frey
@Fryguy
yeah you can drop that now