Subcollectives indeed work fine. So far I have things running on a single host and the setup was much easier than doing something similar with activemq several years ago. Everything I could think to try works the same.
Next to fully puppetize the setup and persuade the security department to open another port for nats (oh dear). Mild nitpick: there doesn't seem to be a client config file option for cert and key. I know there are environment variable options but enough people will forget to set those on every login (environment with no persistent .bash_profile or similar, yes indeed). My workaround will be to provide a short puppet manifest to reshape their client config since any shuffling errors will be obvious when mailed back. It would definitely be easier to have people copy activemq cert params into choria cert params. On Thu, Sep 29, 2016 at 06:14:16PM +0100, R.I.Pienaar wrote: > > > ----- Original Message ----- > > From: "Christopher Wood" <[email protected]> > > To: "mcollective-users" <[email protected]> > > Sent: Thursday, 29 September, 2016 18:52:32 > > Subject: [mcollective-users] translate activemq subcollectives to nats.io > > > I am (finally*) digging into nats as a broker. > > > > I think I need help figuring out how to translate an activemq > > authorizationMap > > specifying all the collectives into a set of nats.io routes. Are > > subcollectives > > specified in the broker config still a thing with nats? The idea is to > > preserve > > the same set of subcollectives for group convenience. > > > > Details: > > > > For instance, here's the default "mcollective" collective in activemq: > > > > <authorizationMap> > > <authorizationEntries> > > <authorizationEntry topic="mcollective.>" write="mcollective" > > read="mcollective" > > admin="mcollective" /> > > <authorizationEntry queue="mcollective.>" write="mcollective" > > read="mcollective" > > admin="mcollective" /> > > </authorizationEntries> > > </authorizationMap> > > > > Going by the example (https://github.com/ripienaar/puppet-nats) it doesn't > > look > > like there's a similar construct in nats. So maybe not a thing? > > Not really, the module there does not do any authorization rules - but > requires > CA signed certs to connect. It does though support sub collectives just > configure > them in mcollective via the module > > NATS very recently got some new Authorization rules features which might be > handy but > I think they're still a bit short on feature so for now I didnt integrate them > > > (*Why now? Two days ago one of the activemq daemons here helped up achieve > > our > > monthly clustering failure by crashing, and the clustering stayed dead even > > when monit brought the daemon up, again. I'm feeling the glimmer of a > > scintilla > > of irritation here.) > > definitely keen to hear how it goes :) > > -- > > --- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
