Issue #7226 has been updated by R.I. Pienaar. Target version set to 1.3.x
---------------------------------------- Feature #7226: Rework internal messaging to support broadcast as well as point to point comms https://projects.puppetlabs.com/issues/7226 Author: R.I. Pienaar Status: Accepted Priority: Normal Assignee: R.I. Pienaar Category: Core Target version: 1.3.x Keywords: Branch: Affected mCollective version: This is a placeholder ticket that will be the parent for lots of related tickets. The rough outline of what will be worked on in 1.3.x is all about making the messaging system both more robust and morphing it into a highbrid of p2p and broadcast messages. The initial mcollective goals was to look at ways to address groups of machines by their meta data, this necessitated a broadcast based design approach. We've solved this problem and now can look at ways to involve more traditional point to point comms in a way that compliment the broadcast paradigm present in mcollective <= 1.2.x enabling a marriage of P2P and broadcast will allow us to optimize for example: * Puppet Commander can discover nodes to manage using broadcast, schedule individual runs on nodes using P2P. * Allow making discovery pluggable - query a DB for hostnames matching any criteria you wish and then submit requests to them P2P, eliminating the current broadcast based discovery all together, this will make MC a better fit as transport for things like BPM systems. It will also extend the AAA and existing code to a more traditional use case * Allow submitting tasks for machines before they are even booted/built to optimize host provisioning * Allow submitting tasks that has to be done, managing DNS zones using a broadcast best-efforts medium isnt appropriate, should be able to send a job to the nameserver host and know it will get done even if the host is now off This will involve a number of optimizations: * Create a message object that encapsulates more meta data about requests and replies than we have today, associate requests with replies allowing middleware to better use middleware specific features * Make fewer assumptions about the structure of the middleware outside of the connector plugins - stop using *Util#make_target* * Don't rely on the structure of the request to determine what agent and collective its targeted at (#7225) * Allow servers to open a queue per server that can be used for point to point comms (#7225) * Use request response patterns to ensure that replies goes only to their requesters or to fully custom destinations (#6938) * Allow certain agents to elect that they can be used in a queued fashion as a group - enable better use of mcollective for HA service provision * Long term allow multiple connectors to be active in the same server. mcollectived should be able to take a request from middleware as well as REST on the same host. After/during this work a new ActiveMQ specific connector should be created that make use of some ActiveMQ specific optimisations, the restructuring above should make it easier to support middleware of very different internal designs than it is today - hopefully avoiding the currently inevitable marriage between MC and ActiveMQ -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
