Neat! Do you have an example of it being used in a playbook?
I'm open to including these in core if you are interested.
Big fan of Rabbit.
+1 for this in core, we use it both for our Django stuff (with celery) and our OpenStack stuff.
Offhand, since you mentioned celery,
what's the state of the art in python scheduling that does *NOT* require Django?
Do you want to do cron-style task scheduling?
I'm pretty sure you can install and use celery without django.
Lorin
Do you want to do cron-style task scheduling?
Yes, but also "here's a job now, I want you to be in a queue and run
when there's an available slot".
I'm pretty sure you can install and use celery without django.
That sounds ideal.
Django is not bad, I just end up not using/needing large parts of it.
> Do you want to do cron-style task scheduling?
Yes, but also "here's a job now, I want you to be in a queue and run
when there's an available slot".>
> I'm pretty sure you can install and use celery without django.That sounds ideal.
I'm a fan of celery, but if you want a lower-level interface for your
message queue system, I suggest you take a look at kombu.
I'm a fan of celery, but if you want a lower-level interface for your
message queue system, I suggest you take a look at kombu.
Wow, nice. Perhaps not so much scheduling related, but this is
immediately relevant to my interests with providing an upgraded
fireball.
I thing it would be great to see these in core. I wasn’t sure how specific the core modules should be but I guess Rabbit is not that obscure. I plan on creating a few more modules, specifically for vhost, policy, and cluster. I will submit a pull request and create a sample playbook that uses these modules.
I thing it would be great to see these in core. I wasn't sure how specific
the core modules should be but I guess Rabbit is not that obscure. I plan
on creating a few more modules, specifically for vhost, policy, and cluster.
I will submit a pull request and create a sample playbook that uses these
modules.
I'm increasingly going to the view that we should be rather 'batteries
included' as we can be (except for obscure stuff), as modules are a
great way to collaborate
and share.
So yeah, more power++.
We should hold back when things are clearly things that are playbook
stuff (setting up a config file) but in many cases when they deal with
commands -- especially rabbit, which NEEDS
commands to be configured, this belongs in a module for sure.
(I once almost wrote a config-file-to-rabbit-config--and-back program
at one point many years ago)