On Wed, Jul 25, 2012 at 04:34:34PM -0700, Stuart Cracraft wrote:
>    Hey, Chris: so that begs the question, do you think you have some "secret"
>    or are just
>    happier with fewer flashy gui's, more install/deployment scripts, and so
>    forth.

No actual secret. I'm happier with the command line and text configuration 
files (though a GUI absolutely has its place). I prefer interpreted (or shell) 
based installers so that I can tell what's going on, or going wrong. Of course, 
this may have as much to do with how my mind works as the amount of practice 
I've had in different computing ecosystems (because, again, $0 budget). Just 
because these things are good for me doesn't automatically mean they're good 
for other people with other talents.

>    In other words, do you think the scaling of Open Puppet is adequate to
>    scale much larger
>    without the flash?

Yes, I do.

>    Or, is there something fundamentally holding back Open Puppet from
>    handling
>    thousands, tens of thousands, or hundreds of thousands of nodes, in your
>    opinion?

But then, it's not just puppet that people are scaling. If somebody thinks that 
they're going to point 100k nodes at a single virtual machine running puppet 
and have everything work at 99.999% uptime, they're making a mistake. (The same 
mistake that we've all seen for mail, radius, dns, et cetera.) Even if that 
works, are they willing to lose a cluster's configuration management if a 
single VM goes down? So now we have multiple puppet servers. Unix-like 
directories get slow when we add hundreds of thousands of directory entries. 
Let's stop tossing our node definitions in a single directory. How do we keep 
the certificates in sync? Now we have a system to sync certs. Can our switches 
handle the load of all that network traffic? Let's make sure we have redundant 
switches in our network core. Do we really want every server to depend on one 
set of puppetmasters? Let's break things out into pods. Can't keep the pods in 
sync? Maybe centralized is the way to go. Your whole datacentre checks into the 
puppetmaster at the same time every hour? It's time to spread thousands of 
requests out over the 3600 seconds you have in each hour, or add more backend 
puppetmasters or check in less often. There's a ton more of these scaling items.

In short: scaling puppet is about more than puppet. The puppet component is 
ready to compile a catalog from your manifests and send it to the node, yes. 
Every other layer has to be ready to scale up in support of that goal.

>    Cheers,
>    Stuart
>    On Wednesday, July 25, 2012 2:52:00 PM UTC-7, Christopher Wood wrote:
> 
>      On Wed, Jul 25, 2012 at 02:20:17PM -0700, Hai Tao wrote:
>      > I see. so it is on purpose to make it not easy to use so the
>      > enterprise can be sold? :)
> 
>      There are different skill levels at different tasks in the enterprise
>      space, and it is legitimate that some organizations are better off with
>      a prefabbed installer for a configuration management system.
> 
>      I've created a puppet installation of reasonable complexity without
>      puppet enterprise, but that is possibly just me:
> 
>      $ cd files/puppet/svn/prod/trunk
>      $ ls manifests/nodes | wc -l
>      43
>      $ find modules -name "*pp" | wc -l
>      174
> 
>      That's not to say I don't salivate a bit at the thought of Puppet
>      Enterprise, but my budget of $0 doesn't help there. Or perhaps a
>      career-long $0 budget has helped, in that I'm more used to building from
>      components instead of buying the package. People who are more used to
>      buying than building may be better off with a different situation than
>      mine.
> 
>      > On Wed, Jul 25, 2012 at 2:02 PM, Christopher Wood
>      > <[1]christopher_w...@pobox.com> wrote:
>      > > Sounds like you should be talking to your managers about buying
>      Puppet Enterprise.
>      > >
>      > > On Wed, Jul 25, 2012 at 02:00:37PM -0700, Hai Tao wrote:
>      > >> Hi,
>      > >>
>      > >> I notice that many components of puppet do not scale well and are
>      not
>      > >> intended for large environment. For example, stored config and
>      > >> inventory service. In order to scale, we need to use puppetDB,
>      right?
>      > >> Another example is the webrick, and which should be replaced by a
>      > >> decent web server such as apache. All these need a lot of new
>      > >> installation of pieces of software and configurations.
>      > >>
>      > >> My question is why the designer of puppet did not consider this and
>      > >> integrate everything into a complete solution at the beginning,
>      rather
>      > >> than having us have to reconfigure everything by hand. Who will use
>      > >> puppet if he has only 50 nodes?
>      > >>
>      > >> --
>      > >> Hai Tao
>      > >>
>      > >> --
>      > >> You received this message because you are subscribed to the Google
>      Groups "Puppet Users" group.
>      > >> To post to this group, send email to
>      [2]puppet-users@googlegroups.com.
>      > >> To unsubscribe from this group, send email to
>      [3]puppet-users+unsubscr...@googlegroups.com.
>      > >> For more options, visit this group at
>      [4]http://groups.google.com/group/puppet-users?hl=en.
>      > >>
>      > >>
>      > >
>      > > --
>      > > You received this message because you are subscribed to the Google
>      Groups "Puppet Users" group.
>      > > To post to this group, send email to
>      [5]puppet-users@googlegroups.com.
>      > > To unsubscribe from this group, send email to
>      [6]puppet-users+unsubscr...@googlegroups.com.
>      > > For more options, visit this group at
>      [7]http://groups.google.com/group/puppet-users?hl=en.
>      > >
>      >
>      >
>      >
>      > --
>      > Hai Tao
>      >
>      > --
>      > You received this message because you are subscribed to the Google
>      Groups "Puppet Users" group.
>      > To post to this group, send email to [8]puppet-users@googlegroups.com.
>      > To unsubscribe from this group, send email to
>      [9]puppet-users+unsubscr...@googlegroups.com.
>      > For more options, visit this group at
>      [10]http://groups.google.com/group/puppet-users?hl=en.
>      >
>      >
> 
>    --
>    You received this message because you are subscribed to the Google Groups
>    "Puppet Users" group.
>    To view this discussion on the web visit
>    [11]https://groups.google.com/d/msg/puppet-users/-/MW0Ok3Eent8J.
>    To post to this group, send email to puppet-users@googlegroups.com.
>    To unsubscribe from this group, send email to
>    puppet-users+unsubscr...@googlegroups.com.
>    For more options, visit this group at
>    http://groups.google.com/group/puppet-users?hl=en.
> 
> References
> 
>    Visible links
>    1. mailto:christopher_w...@pobox.com
>    2. mailto:puppet-users@googlegroups.com
>    3. mailto:puppet-users%2bunsubscr...@googlegroups.com
>    4. http://groups.google.com/group/puppet-users?hl=en
>    5. mailto:puppet-users@googlegroups.com
>    6. mailto:puppet-users%2bunsubscr...@googlegroups.com
>    7. http://groups.google.com/group/puppet-users?hl=en
>    8. mailto:puppet-users@googlegroups.com
>    9. mailto:puppet-users%2bunsubscr...@googlegroups.com
>   10. http://groups.google.com/group/puppet-users?hl=en
>   11. https://groups.google.com/d/msg/puppet-users/-/MW0Ok3Eent8J

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to