Hello: I''ve been reading up on puppet after spending a while on SmartFrog. SmartFrog''s late binding and ability to encode dependencies between machines or document parallel or serial configuration steps was compelling. Java was not. :) Are there notions of these concepts in puppet that aren''t apparent from the documentation? Different ways to get to the same conclusion? Thanks, Brad
On Feb 9, 2007, at 5:53 PM, Brad Dixon wrote:> Hello: > > I''ve been reading up on puppet after spending a while on SmartFrog. > SmartFrog''s late binding and ability to encode dependencies between > machines or document parallel or serial configuration steps was > compelling. Java was not. :) > > Are there notions of these concepts in puppet that aren''t apparent > from the documentation? Different ways to get to the same conclusion?At this point, no, there are not. I guess I need to look more closely at SmartFrog; I haven''t looked at it in a while, and I don''t remember those bits. Can you give a quick run-down of how it works? -- Once...in the wilds of Afghanistan, I lost my corkscrew, and we were forced to live on nothing but food and water for days. -- W. C. Fields --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
> Can you give a quick run-down of how it works?I''d be happy to. I''m doing this not as an expert or a practitioner... just as one who has done a close reading of the docs and tried to map both puppet and SmartFrog onto my anticipated uses. Take it for what it is worth. These aren''t criticisms of puppet in any means. This is probably the best doc to look at for info on the SmartFrog component language: http://smartfrog.org/releasedocs/smartfrogdoc/sfReference.html Interesting things I liked about SmartFrog that seem unique as compared to puppet: 1) Component lifecycles ( http://smartfrog.org/releasedocs/smartfrogdoc/sfReference.html#Lifecycles ) Each component has a lifecycle (Constructed, Instantiated, Initialized, Running, Terminated) and the chlidren of a component synchronize their lifecycle with the parent. If the parent is running then so are the children. 2) Compounds ( http://smartfrog.org/releasedocs/smartfrogdoc/sfReference.html#Compounds ) "SmartFrog provides the ability to create collections of components with certain semantic guarantees." The most commonly used is that components within a compound have a shared lifecycle. Either they all transition together to each lifecycle state or the compound as a whole fails. Compounds could guarantee, for example, that the overall system not be deployed if the database tier fails to deploy. 3) Liveness: Components are checked for "liveness". Components can extend the liveness checks to do something specific to the component. 4) Lazy resolution: This is really intriguing and I would imagine quite useful. Components can communicate with each other without being concerned about the underlying methods or locations of the components. (reminds me of the "runnels" you''ve written up). This lazy resolution can be used so, for example, servers who are allocated dynamic IP''s and port numbers can be coordinated with clients that need to connect. Components are resident in a tree so that each component can be addressed with absolutely starting from ROOT or in a relative manner. There are a bunch of rules for addressing. 5) Workflow: Smartfrog has an extension that implements some basic workflow mechanisms. ( http://smartfrog.org/releasedocs/smartfrogdoc/sfWorkflow.html ) These include: parallel, sequence, timeout, during (like a timeout but doesn''t generate an error if timeout occurs), retry, try (but no error if failure occurs), and a simple delay. In summary: SmartFrog has a lot of interesting features that seem to enable it to manage configuration with dependencies spread out across machines, handle errors when the occur, communicate between components, and describe simple workflows. Handy stuff. It all seems highly biased towards deploying Java implemented services and components, however. Just being in the Java VM isolates one, to a degree, from the underlying system. A VM is also heavy weight and impossible to find on many architectures I''m interested in. Hence my interest in Puppet. Brad
On Feb 11, 2007, at 11:17 AM, Brad Dixon wrote:> > I''d be happy to. I''m doing this not as an expert or a practitioner... > just as one who has done a close reading of the docs and tried to map > both puppet and SmartFrog onto my anticipated uses. Take it for what > it is worth. These aren''t criticisms of puppet in any means. > > This is probably the best doc to look at for info on the SmartFrog > component language: > > http://smartfrog.org/releasedocs/smartfrogdoc/sfReference.html > > Interesting things I liked about SmartFrog that seem unique as > compared to puppet:Overall, from your description, it sounds like SmartFrog is at least one layer up the stack from Puppet, at least right now. Puppet is quite bottom-up, and its significant advancement is its resource abstraction layer. When I looked at SmartFrog (admittedly a long time ago), the biggest problem I had was that its modules were essentially opaque -- I had the same problem with LCFG. This means that the modules are fundamentally not very portable, either across operating systems or across organizations. Puppet starts at a much lower layer, which gives you more power to write portable modules, but it also means that Puppet has not yet caught up to SmartFrog on the stack.> 1) Component lifecycles ( > http://smartfrog.org/releasedocs/smartfrogdoc/ > sfReference.html#Lifecycles > ) > > Each component has a lifecycle (Constructed, Instantiated, > Initialized, Running, Terminated) and the chlidren of a component > synchronize their lifecycle with the parent. If the parent is running > then so are the children.Interesting. It''d be interesting to try to write a module layer that allowed Puppet''s resource abstraction layer to be used as modules within SmartFrog. That''s definitely the idea behind the low-level approach I''ve chosen.> 2) Compounds ( http://smartfrog.org/releasedocs/smartfrogdoc/ > sfReference.html#Compounds > ) > > "SmartFrog provides the ability to create collections of components > with certain semantic guarantees." The most commonly used is that > components within a compound have a shared lifecycle. Either they all > transition together to each lifecycle state or the compound as a whole > fails. Compounds could guarantee, for example, that the overall system > not be deployed if the database tier fails to deploy.Very nice, and very high level.> 3) Liveness: Components are checked for "liveness". Components can > extend the liveness checks to do something specific to the component.This kind of hook would be great.> 4) Lazy resolution: This is really intriguing and I would imagine > quite useful. Components can communicate with each other without being > concerned about the underlying methods or locations of the components. > (reminds me of the "runnels" you''ve written up). This lazy resolution > can be used so, for example, servers who are allocated dynamic IP''s > and port numbers can be coordinated with clients that need to connect. > Components are resident in a tree so that each component can be > addressed with absolutely starting from ROOT or in a relative manner. > There are a bunch of rules for addressing.Huh. I vaguely remember this.> 5) Workflow: Smartfrog has an extension that implements some basic > workflow mechanisms. ( > http://smartfrog.org/releasedocs/smartfrogdoc/sfWorkflow.html ) These > include: parallel, sequence, timeout, during (like a timeout but > doesn''t generate an error if timeout occurs), retry, try (but no error > if failure occurs), and a simple delay.Another great high-level feature.> In summary: SmartFrog has a lot of interesting features that seem to > enable it to manage configuration with dependencies spread out across > machines, handle errors when the occur, communicate between > components, and describe simple workflows.Yeah; seems like it''s a much higher-level tool than Puppet is right now, and they might actually dovetail nicely.> Handy stuff. It all seems highly biased towards deploying Java > implemented services and components, however. Just being in the Java > VM isolates one, to a degree, from the underlying system. A VM is also > heavy weight and impossible to find on many architectures I''m > interested in. Hence my interest in Puppet.Interesting. I''d be surprised to find that Ruby ran in many places that Java didn''t, so I''m not sure Puppet can be much help. It might even be fun to try to run Puppet in JRuby, thus making it even easier to integrate with SmartFrog. However, I expect it will be a while before Puppet has many of these high-level features. -- Charm is a way of getting the answer yes without asking a clear question. -- Albert Camus --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 2/12/07, Luke Kanies <luke@madstop.com> wrote:> On Feb 11, 2007, at 11:17 AM, Brad Dixon wrote: > > 3) Liveness: Components are checked for "liveness". Components can > > extend the liveness checks to do something specific to the component. > > This kind of hook would be great.Would this be some kind of monitoring thingy? A Nagios hook, so to speak? Just checking if I understand OP correctly. -- Gegroet, Tim
On Feb 12, 2007, at 4:59 PM, Tim Stoop wrote:> On 2/12/07, Luke Kanies <luke@madstop.com> wrote: >> On Feb 11, 2007, at 11:17 AM, Brad Dixon wrote: >>> 3) Liveness: Components are checked for "liveness". Components can >>> extend the liveness checks to do something specific to the >>> component. >> >> This kind of hook would be great. > > Would this be some kind of monitoring thingy? A Nagios hook, so to > speak? Just checking if I understand OP correctly.Something like that -- a builtin feedback loop with an extensible definition of whether a given component is functioning properly. -- It has recently been discovered that research causes cancer in labratory rats. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 2/12/07, Luke Kanies <luke@madstop.com> wrote:> Puppet starts at a much lower layer, which gives you more power to > write portable modules, but it also means that Puppet has not yet > caught up to SmartFrog on the stack.Ok... I''m not sure it is a competition. Maybe they are just different and should be different to serve their constituencies.> Interesting. I''d be surprised to find that Ruby ran in many places > that Java didn''t, so I''m not sure Puppet can be much help. It mightI find this in non-x86 systems quite freqently. Finding a JVM for ARM or MIPS will cost you some money. Ruby, Perl, and other interpreted languages typically port with a little elbow grease.> However, I expect it will be a while before Puppet has many of these > high-level features.Thanks for your commentary. None of this reflects poorly on Puppet but I do know more know. Thanks, Brad
On Feb 12, 2007, at 8:48 PM, Brad Dixon wrote:> On 2/12/07, Luke Kanies <luke@madstop.com> wrote: >> Puppet starts at a much lower layer, which gives you more power to >> write portable modules, but it also means that Puppet has not yet >> caught up to SmartFrog on the stack. > > Ok... I''m not sure it is a competition. Maybe they are just different > and should be different to serve their constituencies.Well, I didn''t mean "caught up" in the competition sense so much as in the bridging sense. I''m starting at a lower level of the stack, so it will naturally take me longer to fill in all of those gaps.>> Interesting. I''d be surprised to find that Ruby ran in many places >> that Java didn''t, so I''m not sure Puppet can be much help. It might > > I find this in non-x86 systems quite freqently. Finding a JVM for ARM > or MIPS will cost you some money. Ruby, Perl, and other interpreted > languages typically port with a little elbow grease.Interesting; I''d no idea.>> However, I expect it will be a while before Puppet has many of these >> high-level features. > > Thanks for your commentary. None of this reflects poorly on Puppet but > I do know more know.No problem. -- What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? --Larry Wall in <1992Aug26.184221.29627@netlabs.com> --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com