Further to this, some more details on the Puppet DSL based Playbooks.

A first stab at the docs is being cut, but the intro page already show some 


Above is a playbook that interacts with PuppetDB PQL, MCollective Agents, 
Graphite and Slack and shows how you'd make reusable playbooks that can combine 
to make more complex things - like the Slack stuff here.

It also shows looping over data and error handling which the old playbook 
system could not do.

Feedback welcome

On Wed, 21 Feb 2018, at 21:34, R.I.Pienaar wrote:
> hello,
> It's been a while since I made any releases - I have been super busy 
> with the new brokers and daemons and waiting for Puppet 5.4.0 to ship.  
> I wanted to write a mail giving everyone an update on where we are and 
> what is happening.
> I am working full time on Choria related projects so there's a LOT going 
> on, I am happy to expand on any of these topics if you are interested 
> please respond and ask questions.
> So we're approaching various things falling into place and I will be 
> shipping the following:
> Releases of the existing choria related modules with some fixes and 
> dependencies for stuff mentioned below and some valuable contributions 
> received from the community
> A new 'choria' module that will slowly absorb the confusing mess from 
> the choria/mcollective and choria/mcollective_choria modules and deliver 
> a lot of what is discussed below
> A new middleware broker that replaces the NATS you have been setting up 
> for choria with one called 'choria broker'.  The above 'choria' module 
> will install this.  This will be available for RHEL 5-7, Debian 9 and 
> Ubuntu LTS. Package repos are on packagecloud.io.  This broker has a 3 
> line configuration and is compatible with the ruby choria you have now.
>    https://packagecloud.io/choria/release
> The broker mentioned above is currently aiming at a MUCH improved 
> registration story, I am building really large scale registration and 
> meta data gathering system by bridging mcollective messages into NATS 
> Streaming / Kafka / Kinesis etc
> Embeddable daemons particularly suited for things like IoT and to 
> provide custom control plans into the internals of other applications, 
> some links:
>    https://github.com/ripienaar/choriapi
>    https://github.com/ripienaar/embedded-choria-sample#readme
> A way to write playbooks in the new Puppet Plan DSL so you can build on 
> your puppet knowledge. Here are some links:
>    https://gist.github.com/ripienaar/2f0b7c8ae9c59234963718b46fce8084
>    https://gist.github.com/ripienaar/b57bcd5081e2de73d438f4e220d333df
>    https://choria.io/docs/playbooks/plans/ (outdated but conveys the idea)
> A way to use Bolt tasks as choria agents which will come as a optional 
> module to install:
>    https://youtu.be/LLyjPjZW7TE
> Kind of related and released under the choria umbrella:
> A way to replicate NATS Streaming topics between data centres and across 
> the globe, this is key to the registration stuff I mentioned above:
>    https://github.com/choria-io/stream-replicator
> A way to use NATS Streaming and optionally the above replicator to 
> federate prometheus traffic around the globe where direct intra DC 
> connections are not possible:
>    https://github.com/choria-io/prometheus-streams#readme
> I will soon start absorbing the various mcollective plugin repos and 
> they will start shipping bolt tasks, playbook integrations and default 
> action policy rules to ensure a smooth read only out of the box 
> experience (package status works out of the box, package install 
> doesn't)
> Longer term I am working on a new daemon that will replace mcollectived.  
> Right now its functional but still development level, the embeddable 
> repos above is already using this
> A lot of release automation stuff has been happening, nightly RPMs for 
> some repos are being posted already, more to follow
> Further I am exploring the following directions:
> Auto provisioning of choria instances to manage really very large scale 
> networks
> Gossip based agent comms channels for comms between nodes for large 
> scale adhoc coordination without the need for a central orchestraor to 
> create a much more independent style of management.
> -- 
> R.I.Pienaar / www.devco.net / @ripienaar

R.I.Pienaar / www.devco.net / @ripienaar


You received this message because you are subscribed to the Google Groups 
"mcollective-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mcollective-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to