Oh this is amazing news really good to hear about your performance metrics,

did you deploy this using just the settings my module installs?

Can you tell me a bit about your memory and CPU usage in this case?

----- Original Message -----
> From: "Christopher Wood" <christopher_w...@pobox.com>
> To: "mcollective-users" <mcollective-users@googlegroups.com>
> Sent: Tuesday, 18 October, 2016 14:49:51
> Subject: Re: [mcollective-users] translate activemq subcollectives to nats.io

> Good news, today we migrated our mcollective installation from ActiveMQ to 
> NATS.
> There are the usual handful of straggler hosts but various departments have
> tickets. I will switch my client back to activemq and check on the leftovers 
> in
> a few days (clustered activemq brokers still running precisely for this
> reason).
> 
> It turned out that the security department was quite accomodating about adding
> $HOME/.puppetlabs to the "keep" list. They send frequent auditing queries
> around and are getting faster, more consistent replies so they're happier now.
> ("All good for me too, after switching to it, I see speed improvements and
> better reliability.") I see the same thing, queries where I would have had to
> extend the timeout with ActiveMQ are handled within my client's configured
> "--dt 5 -t 5" with NATS.
> 
> Finally, I will be able to turn off a few hosts. We're now handling 1900
> mcollective servers on a single unclustered NATS daemon where before we needed
> four clustered ActiveMQ daemons (I agree that my own ActiveMQ skill was a
> likely factor here). The NATS daemon is using less cpu and ram than any single
> ActiveMQ daemon was.
> 
> Now let's see how NATS handles its first DDOS or inter-datacenter connection
> downtime! Will follow up if I notice anything bad.
> 
> On Thu, Oct 06, 2016 at 08:02:37PM +0100, R.I.Pienaar wrote:
>> 
>> 
>> ----- Original Message -----
>> > From: "Christopher Wood" <christopher_w...@pobox.com>
>> > To: "mcollective-users" <mcollective-users@googlegroups.com>
>> > Sent: Thursday, 6 October, 2016 20:29:16
>> > Subject: Re: [mcollective-users] translate activemq subcollectives to 
>> > nats.io
>> 
>> > On Thu, Oct 06, 2016 at 08:43:54AM +0100, R.I.Pienaar wrote:
>> >> 
>> >> 
>> >> ----- Original Message -----
>> >> > From: "Christopher Wood" <christopher_w...@pobox.com>
>> >> > To: "mcollective-users" <mcollective-users@googlegroups.com>
>> >> > Sent: Wednesday, 5 October, 2016 22:19:50
>> >> > Subject: Re: [mcollective-users] translate activemq subcollectives to 
>> >> > nats.io
>> >> 
>> >> > 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).
>> >> 
>> >> Did you use the module the wiki recommend? It's simple but does what you 
>> >> want
>> >> including
>> >> clustering
>> >> 
>> >> > 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.
>> >> 
>> >> why do you wish to change these paths? It defaults to the same ones 
>> >> puppet use
>> >> for a reason - you should not need to make any client configuration at 
>> >> all, just
>> >> put the certs in the puppet location - which 'mco choria request_cert' 
>> >> does for
>> >> you
>> > 
>> > If I were setting things up from scratch in regular home directories the 
>> > choria
>> > technique would be suitable, but I'm not.
>> > 
>> > I have the usual corporate things going on:
>> > 
>> > 1) The new cert location is not in "$HOME/.mcollective.d". It took a great 
>> > deal
>> > of protracted discussion with the security department to permit 
>> > .mcollective
>> > and .mcollective.d (certs and things) to persist overnight in users' home
>> > directories. Most every other file under $HOME on the authorized mco client
>> > hosts get removed nightly. I will be re-opening that discussion.
>> 
>> OK, well adding configurable overrides for these would not be hard, I dont 
>> mind
>> adding more flags, feel free to open a issue in the choria github
>> 
>> > 2) Everybody has their own (working) certs and configs from the current
>> > production install. It was like pulling teeth the first time to get people 
>> > set
>> > up despite the detailed instructions; what is straightforward and obvious 
>> > to me
>> > is not so obvious to others. That includes running a cert management 
>> > command
>> > based on my experience here.
>> 
>> reusing those would be hard right? There were never a CA involved in making
>> those
>> the new stuff does CA validation
>> 
>> > NB: This is of course a policy issue not an mcollective issue, I myself 
>> > wouldn't
>> > go and add this functionality based on the description of the issues. 
>> > Policies
>> > have results and working around them in a corporate environment rarely ends
>> > well.
>> 
>> no its fair enough, this stuff matters and mcollective is one of few in this
>> space
>> with solid AAA story because I want it to appeal to exactly this kind of 
>> user,
>> so
>> if overrides will help I will add them
>> 
>> --
>> 
>> ---
>> 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.
> 
> --
> 
> ---
> 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.

-- 

--- 
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