Puppet users - Jan 2011 - can a class require an other class?

Hello

Is it possible to define a class say php-fpm that requires the class
php to be called first ?
if so what s the syntax?

Here is some background (Ubuntu distro)

To get the latest version of either  php or php-fpm I need to setup a
new repo (dotdeb), since
if one is using php-fpm there is big chance you will need php bit not
the way-around...

So since I setup the repo in php the class php-fpm can not start
before the class php
is done... make sense ? I do have a work around by adding a require in
the ''package'' resource
something like

package ( "php5-pfm" : ensure => "installed", require
=> "Update_repo[
"dotdeb-repo" ] }

where update_repo ( "dotdeb-repo" } is in the php class


make sense? comment? advice ?
-- 
-ls

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jan 6, 2:29 pm, Luc Suryo <lsu...@gmail.com>
wrote:
> Hello
>
> Is it possible to define a class say php-fpm that requires the class
> php to be called first ?
> if so what s the syntax?
>
> Here is some background (Ubuntu distro)
>
> To get the latest version of either  php or php-fpm I need to setup a
> new repo (dotdeb), since
> if one is using php-fpm there is big chance you will need php bit not
> the way-around...
>
> So since I setup the repo in php the class php-fpm can not start
> before the class php
> is done... make sense ? I do have a work around by adding a require in
> the ''package'' resource
> something like
>
> package ( "php5-pfm" : ensure => "installed",
require => "Update_repo[
> "dotdeb-repo" ] }
>
> where update_repo ( "dotdeb-repo" } is in the php class
>
> make sense? comment? advice ?
Why is it a problem to put the require on Package["php5-pfm"] as you
are already doing?  That''s where it SHOULD go.


John

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jan 6, 2011 at 12:50 PM, jcbollinger
<John.Bollinger@stjude.org>wrote:
>
>
> On Jan 6, 2:29 pm, Luc Suryo <lsu...@gmail.com> wrote:
> > Hello
> >
> > Is it possible to define a class say php-fpm that requires the class
> > php to be called first ?
> > if so what s the syntax?
> >
> > Here is some background (Ubuntu distro)
> >
> > To get the latest version of either  php or php-fpm I need to setup a
> > new repo (dotdeb), since
> > if one is using php-fpm there is big chance you will need php bit not
> > the way-around...
> >
> > So since I setup the repo in php the class php-fpm can not start
> > before the class php
> > is done... make sense ? I do have a work around by adding a require in
> > the ''package'' resource
> > something like
>
starting in 2.6.x, you can specify class level deps:

in the class definition:

class foo {
  Class[''foo'']->Class[bar'']
}

or when you declare it:

class { ''foo'':
  require => Class[''bar'']
}

> >
> > package ( "php5-pfm" : ensure => "installed",
require => "Update_repo[
> > "dotdeb-repo" ] }
> >
> > where update_repo ( "dotdeb-repo" } is in the php class
> >
> > make sense? comment? advice ?
>
> Why is it a problem to put the require on Package["php5-pfm"] as
you
> are already doing?  That''s where it SHOULD go.
>
>
> John
>
> --
> 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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> 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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jan 6, 2011 at 12:29, Luc Suryo <lsuryo@gmail.com> wrote:
> Is it possible to define a class say php-fpm that requires the class
> php to be called first?  if so what s the syntax?
Yes:  package { "foo": require => Class["bar"] }

I think Nigel just pointed out in another thread that this is, in
fact, our recommended way to do cross-module and cross-class
dependencies.  I certainly do, because it means you can change the
implementation of the PHP stuff without peturbing the php-fpm module
at all.

Regards,
    Daniel
-- 
✉ Daniel Pittman <daniel@rimspace.net>
⌨ daniel@rimspace.net (XMPP)
☎ +1 503 893 2285
♻ made with 100 percent post-consumer electrons

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- Original Message -----
> On Thu, Jan 6, 2011 at 12:29, Luc Suryo <lsuryo@gmail.com> wrote:
> 
> > Is it possible to define a class say php-fpm that requires the class
> > php to be called first? if so what s the syntax?
> 
> Yes: package { "foo": require => Class["bar"] }
> 
> I think Nigel just pointed out in another thread that this is, in
> fact, our recommended way to do cross-module and cross-class
> dependencies. I certainly do, because it means you can change the
> implementation of the PHP stuff without peturbing the php-fpm module
> at all.
I dont get it, 

if you have a number of inter dependent classes that you got somewhere,
lets say the puppet forge, you''d want that class to have its own
dependencies
and requires between classes and such.

You would then use the class syntax as above to supply parameters to configure
these classes but you would really not want to use it to set relationships
between classes.  You should not need to know that php::foo is designed to run
after php::install and php::configure, thats an implementation detail not a use
case detail.

You''re in effect saying you can only supply the relationships in one
place
since this syntax can only be used once per node. 

So if you''re recommending this as The Way then we''ll end up
with a bunch
of classes downloaded from github and such with either no relationship
or lacking the ability to pass in arguments for the class.

This syntax - and externally specified dependencies - means you cant just
look at the code and know what to expect.  You cant just look at code you
get given by teams and know the dependencies, requirements and such.

If you''re going to start using ENCs to do parametrized classes then
everyone
who wish to include a class need to know what relationships need to be set etc.

We need to retain - and recommend, document and support - the way for classes
to set relationships between classes.

In this example that you are responding to - class php::foo that requires php -
your suggestion is a bit weird.  With your suggestion anyone who ever want to
use this class need to know "when including php::foo you need to remember
to
set the requirement on foo" when in fact what you want is to include the
foo::bar
class and it should just behave in a sane way without any burden of
documentation
or everyone using it creating the dependencies tree.


-- 
R.I.Pienaar

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jan 6, 2011 at 14:19, R.I.Pienaar <rip@devco.net>
wrote:
>> On Thu, Jan 6, 2011 at 12:29, Luc Suryo <lsuryo@gmail.com> wrote:
>>
>> > Is it possible to define a class say php-fpm that requires the
class
>> > php to be called first? if so what s the syntax?
>>
>> Yes: package { "foo": require => Class["bar"] }
>>
>> I think Nigel just pointed out in another thread that this is, in
>> fact, our recommended way to do cross-module and cross-class
>> dependencies. I certainly do, because it means you can change the
>> implementation of the PHP stuff without peturbing the php-fpm module
>> at all.
>
> I dont get it,
>
> if you have a number of inter dependent classes that you got somewhere,
> lets say the puppet forge, you''d want that class to have its own
dependencies
> and requires between classes and such.
>
> You would then use the class syntax as above to supply parameters to
configure
> these classes but you would really not want to use it to set relationships
> between classes.  You should not need to know that php::foo is designed to
run
> after php::install and php::configure, thats an implementation detail not a
use
> case detail.
Well, to address that the ''include php::install'' mechanism
also
serves, but you are right that ...
> So if you''re recommending this as The Way then we''ll end
up with a bunch
> of classes downloaded from github and such with either no relationship
> or lacking the ability to pass in arguments for the class.
...it doesn''t play nicely with parameterized classes at this point in
time.

[...]
> In this example that you are responding to - class php::foo that requires
php -
> your suggestion is a bit weird.  With your suggestion anyone who ever want
to
> use this class need to know "when including php::foo you need to
remember to
> set the requirement on foo" when in fact what you want is to include
the foo::bar
> class and it should just behave in a sane way without any burden of
documentation
> or everyone using it creating the dependencies tree.
I was perhaps too terse in my response here: generally I would expect
that to happen *inside* the php::foo class, so that ''include
php::foo''
would do the right thing on the node:

    class foo { ... }
    class bar {
        include foo
        package { "whatever": require => Class["foo"] }
    }

Then ''include bar'' will just work™ for end users, including
the
appropriate cross-class dependencies and inclusions.  Which still
fails if foo is parameterized, but that is ... a rough area right now.
:)

Regards,
    Daniel
-- 
✉ Daniel Pittman <daniel@rimspace.net>
⌨ daniel@rimspace.net (XMPP)
☎ +1 503 893 2285
♻ made with 100 percent post-consumer electrons

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jan 6, 4:04 pm, Daniel Pittman <dan...@rimspace.net>
wrote:
> On Thu, Jan 6, 2011 at 12:29, Luc Suryo <lsu...@gmail.com> wrote:
> > Is it possible to define a class say php-fpm that requires the class
> > php to be called first?  if so what s the syntax?
>
> Yes:  package { "foo": require => Class["bar"] }
>
> I think Nigel just pointed out in another thread that this is, in
> fact, our recommended way to do cross-module and cross-class
> dependencies.  I certainly do, because it means you can change the
> implementation of the PHP stuff without peturbing the php-fpm module
> at all.
I''m not following that logic.  How do whole-class dependencies isolate
one class from changes to the other better than precise resource/
resource dependencies do?  Whole-class dependencies produce a whole
lot more edges in the resource-level dependency graph (n or n*m) than
do single-resource dependencies (1).  How does that not constitute
much tighter coupling with per-class dependencies?

No matter how many per-resource dependencies are declared, a Class/
Class dependency still produces a dependency graph that is a superset
of that produced by all the per-resource dependencies between those
classes'' resources.  It furthermore obscures the details of the
dependencies so that some types of maintenance -- refactoring, for
example -- are considerably more difficult.

I''m not saying that per-class dependencies are always inferior, but
one would be wise to consider carefully both their advantages and
disadvantages in any given case.  Inasmuch as they are shorthand for a
collection of per-resource dependencies, per-class depenencies are
never *necessary*.


John

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- Original Message -----
> > In this example that you are responding to - class php::foo that
> > requires php -
> > your suggestion is a bit weird. With your suggestion anyone who ever
> > want to
> > use this class need to know "when including php::foo you need to
> > remember to
> > set the requirement on foo" when in fact what you want is to
include
> > the foo::bar
> > class and it should just behave in a sane way without any burden of
> > documentation
> > or everyone using it creating the dependencies tree.
> 
> I was perhaps too terse in my response here: generally I would expect
> that to happen *inside* the php::foo class, so that ''include
php::foo''
> would do the right thing on the node:
> 
> class foo { ... }
> class bar {
> include foo
> package { "whatever": require => Class["foo"] }
> }
> 
> Then ''include bar'' will just work™ for end users,
including the
> appropriate cross-class dependencies and inclusions. Which still
> fails if foo is parameterized, but that is ... a rough area right now.

imho the right solution is a combination of the require and include keywords,
resources requiring classes used extremely sparingly and the new syntax as Dan 
pointed out.

What worries me greatly is that ''use parametrized classes'' for
everything
recommendation seems to be the default response these days from PL even to the 
point of suggesting the include and require keywords be removed and deprecated
while the alternatives are, to be frank, half baked.

It spreads confusion and frustrates users. 

At Puppet Camp in the US it was clear the impression by many were that the
Language
has gone a bit in the wrong direction use case wise and Luke suggested that a
community +
puppet labs panel will be formed to help decide how the language gets designed
rather than
it be just a bunch of features that kind of works together.  I''d very
much like to see
this happen and I believe it''s becoming pretty desperately needed :)

The DSL used to exist as a simple language that does what we do elegantly and in
a
well designed manner.  In a way that systems administrators can understand and
embrace.
A language that obvious how it behaves when looked at and the outcome and
behavior
of code is clear.  These were the reasons it is touted over using a turing
complete
programming language.

What we have today is a language with special meaning in the following symbols:

=>, <|, |>, <||, ||>, @, @@, +=, ->, =>, <-, <=,
~>, <~

I''d wager that you couldn''t find more than 20 community
members who can explain without
referencing documentation what each of these do.  And more importantly when
speaking to
the ones who know you''ll in almost all cases be told of edge cases,
strange interactions
and odd bugs in these when used alone or in combination with others.

We have unpredictable inconsistencies where a case statement is case insensitive
except
when you use regular expressions, then its case sensitive.  And many more
similar issues,
issues that have us essentially sit with small test.pp scripts and learn by
observation
how things work constantly expecting the behavior that most people might find
most
surprising would be the one that you''ll find in complex use cases. 
Worse these
inconsistancies change in new weird and interesting ways between versions.  At
this point
using a real language would be more bearable.

General usage, user friendliness and consistency should become a big priority
with how a
feature would be used and how it would interact with existing code and coding
style should
matter greatly.  

Thus I''d like to see the above mentioned language steering group to be
put together so that
the people who use the language can get real input into how it evolves.
  
-- 
R.I.Pienaar

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jan 6, 2011 at 3:14 PM, R.I.Pienaar <rip@devco.net> wrote:
>
>
> ----- Original Message -----
> > > In this example that you are responding to - class php::foo that
> > > requires php -
> > > your suggestion is a bit weird. With your suggestion anyone who
ever
> > > want to
> > > use this class need to know "when including php::foo you
need to
> > > remember to
> > > set the requirement on foo" when in fact what you want is to
include
> > > the foo::bar
> > > class and it should just behave in a sane way without any burden
of
> > > documentation
> > > or everyone using it creating the dependencies tree.
> >
> > I was perhaps too terse in my response here: generally I would expect
> > that to happen *inside* the php::foo class, so that ''include
php::foo''
> > would do the right thing on the node:
> >
> > class foo { ... }
> > class bar {
> > include foo
> > package { "whatever": require => Class["foo"] }
> > }
> >
> > Then ''include bar'' will just work™ for end users,
including the
> > appropriate cross-class dependencies and inclusions. Which still
> > fails if foo is parameterized, but that is ... a rough area right now.
>
>
> imho the right solution is a combination of the require and include
> keywords,
> resources requiring classes used extremely sparingly and the new syntax as
> Dan
> pointed out.
>
> What worries me greatly is that ''use parametrized
classes'' for everything
> recommendation

I am a HUGE fan of param classes;) I find the dynamic scoping implications
of include to be frightening and difficult to fully understand.

> seems to be the default response these days from PL even to the
> point of suggesting the include and require keywords be removed and
> deprecated
> while the alternatives are, to be frank, half baked.
>
I agree that we cannot deprecate include until we fully consider the
functionality that it provides and provide suitable work-arounds, I am also
a little concerned about backwards compatibility, I hope we never pull a
cfengine2->3

The only two that I can think of are:
   - the ability to indicate a requirement for a class (all places that
require a class can include it)
       - although the behavior this provides seems convenient, all of the
implications with dynamic scoping and the fact that only a single inclusion
path is chosen tp build the scope binding stacks based on code evaluation
order makes it hard to fully understand from code the true implications of
this
   - the ability to ensure that a scope has been evaluated so that we can
access variables

are there others?

I consider deprecating require moot, b/c we can express it as

Class[''self'']->Class[''other'']  (unless
there is something that I don''t
understand about require?)

There still could be performance issues that need to be sorted out with this
approach.

It is a little concerning that the include -> param classes move does
require some rethinking about how to model things in Puppet, after having
gone though quite a bit of this, I am sure it is all for the best.

It spreads confusion and frustrates users.
>
> At Puppet Camp in the US it was clear the impression by many were that the
> Language
> has gone a bit in the wrong direction use case wise
>
and Luke suggested that a community +
> puppet labs panel will be formed to help decide how the language gets
> designed rather than
> it be just a bunch of features that kind of works together.  I''d
very much
> like to see
> this happen and I believe it''s becoming pretty desperately needed
:)
>
> The DSL used to exist as a simple language that does what we do elegantly
> and in a
> well designed manner.  In a way that systems administrators can understand
> and embrace.
> A language that obvious how it behaves when looked at and the outcome and
> behavior
> of code is clear.  These were the reasons it is touted over using a turing
> complete
> programming language.
>
> What we have today is a language with special meaning in the following
> symbols:
>
> =>, <|, |>, <||, ||>, @, @@, +=, ->, =>, <-, <=,
~>, <
> I''d wager that you couldn''t find more than 20 community
members who can
> explain without
> referencing documentation what each of these do.

I think you could break these into:
   the ones everyone should know and advanced (<|, |>, <||, ||>, @,
@@)

>  And more importantly when speaking to
> the ones who know you''ll in almost all cases be told of edge
cases, strange
> interactions
> and odd bugs in these when used alone or in combination with others.
>
I agree that we should identify which interactions and bugs exist and get
them prioritized. Maybe we could put together a list for consensus (I have a
few that come to mind)?

>
> We have unpredictable inconsistencies where a case statement is case
> insensitive except
> when you use regular expressions, then its case sensitive.

:(, you can make regex case insensitive in puppet with (?i-mx:regex)

>  And many more similar issues,
> issues that have us essentially sit with small test.pp scripts and learn by
> observation
> how things work constantly expecting the behavior that most people might
> find most
> surprising would be the one that you''ll find in complex use cases.
Worse
> these
> inconsistancies change in new weird and interesting ways between versions.
>  At this point
> using a real language would be more bearable.
>
> General usage, user friendliness and consistency should become a big
> priority with how a
> feature would be used and how it would interact with existing code and
> coding style should
> matter greatly.
>
> Thus I''d like to see the above mentioned language steering group
to be put
> together so that
> the people who use the language can get real input into how it evolves.
>
+1
I''m in


> --
> R.I.Pienaar
>
> --
> 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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> 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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- Original Message -----
> 
> 
> imho the right solution is a combination of the require and include
> keywords,
> resources requiring classes used extremely sparingly and the new
> syntax as Dan
> pointed out.
> 
> What worries me greatly is that ''use parametrized
classes'' for
> everything
> recommendation
> 
> I am a HUGE fan of param classes;) I find the dynamic scoping
> implications of include to be frightening and difficult to fully
> understand.
Sure I do like them too, 

> seems to be the default response these days from PL even to the
> point of suggesting the include and require keywords be removed and
> deprecated
> while the alternatives are, to be frank, half baked.
> 
> 
> I agree that we cannot deprecate include until we fully consider the
> functionality that it provides and provide suitable work-arounds, I am
> also a little concerned about backwards compatibility, I hope we never
> pull a cfengine2->3
> 
> The only two that I can think of are:
> - the ability to indicate a requirement for a class (all places that
> require a class can include it)
> - although the behavior this provides seems convenient, all of the
> implications with dynamic scoping and the fact that only a single
> inclusion path is chosen tp build the scope binding stacks based on
> code evaluation order makes it hard to fully understand from code the
> true implications of this
> - the ability to ensure that a scope has been evaluated so that we can
> access variables
> 
> are there others?
> 

class apache::php {
   include apache 
   
   # do stuff
}

class apache($version="1.2.3") {
}

class{"apache::php": }

This will do what I want with apache as 1.2.3 etc simply saying i
want apache::php on the node will pull in the dependencies and just
looking at the apache::php class will tell me what will happend.

and if I want a different apache version:

class{"apache": version => "1.2.4"}
class{"apache::php": }

This lets me set a different version, without the include keyword you 
cant do this cos you use the param class syntax twice

> I consider deprecating require moot, b/c we can express it as
> 
> Class[''self'']->Class[''other'']
(unless there is something that I don''t
> understand about require?)
do we loose anything by keeping the much simpler to read and understand
version? in addition to the more powerful and advance use version?
> 
> :(, you can make regex case insensitive in puppet with (?i-mx:regex)
oh right, thats obvious.  Principal of most surprising undocumented behavior
demonstrated :)

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jan 6, 2011 at 2:19 PM, R.I.Pienaar <rip@devco.net> wrote:

We need to retain - and recommend, document and support - the way
for
> classes
> to set relationships between classes.

This is really important to me. Classes must continue to be able to set
relationships between classes.


On Thu, Jan 6, 2011 at 3:06 PM, jcbollinger <John.Bollinger@stjude.org>
 wrote:
>
> I''m not following that logic.  How do whole-class dependencies
isolate
> one class from changes to the other better than precise resource/
> resource dependencies do?  Whole-class dependencies produce a whole
> lot more edges in the resource-level dependency graph (n or n*m) than
> do single-resource dependencies (1).  How does that not constitute
> much tighter coupling with per-class dependencies?

It''s much better in terms of encapsulation.

Say you have this class:

class package::updates {
  exec { "apt-get update": }
  exec { "apt-get upgrade": }
  exec { "dpkg --configure -a": }
  # These three resources have appropriate relationships
  # defined so they occur in the right order.
}

From outside the class, you''re better off requiring the whole
"package::updates" class than any of the specific resources, as it
means the
package::updates class is free to reorganize itself, add/remove
functionality, and you don''t have to change all the references outside
this
class.

Ideally you do this as a class <-> class relationship with the
"require"
function, as it''s even more maintainable.

This really does start to matter when you have a large manifest tree with
distributed management of different modules.


On Thu, Jan 6, 2011 at 3:14 PM, R.I.Pienaar <rip@devco.net> wrote:
>
> imho the right solution is a combination of the require and include
> keywords,
> resources requiring classes used extremely sparingly and the new syntax as
> Dan
> pointed out.
>
> What worries me greatly is that ''use parametrized
classes'' for everything
> recommendation seems to be the default response these days from PL even to
> the
> point of suggesting the include and require keywords be removed and
> deprecated
> while the alternatives are, to be frank, half baked.
>
We have some serious language issues with the combination of
"include/require" being able to repeatedly operate on a class, and the
new
parameterized syntax only letting you operate on a class once.

I''m not convinced what the right answer is yet. This is why the
following
bug is still in the "Needs Design Decision" stage.

http://projects.puppetlabs.com/issues/5046

It''s possible we just made a mistake with parameterized classes as
implemented in 2.6.x. We do need to get to somewhere *consistent*, I''m
just
not quite sure what that place looks like yet.


It spreads confusion and frustrates users.
>
> At Puppet Camp in the US it was clear the impression by many were that the
> Language
> has gone a bit in the wrong direction use case wise and Luke suggested that
> a community +
> puppet labs panel will be formed to help decide how the language gets
> designed rather than
> it be just a bunch of features that kind of works together.  I''d
very much
> like to see
> this happen and I believe it''s becoming pretty desperately needed
:)
>
Yes. I want this set up before the next major version, but I''d also
like to
see us have a more general plan for some kind of Puppet oversight group with
very strong non-Puppet Labs involvement that helps work on issues like this.
I''ve had a 3 sentence draft written for the last few weeks that I
haven''t
gotten to, so it''s nice to get nudged about it :)

The DSL used to exist as a simple language that does what we do
elegantly
> and in a
> well designed manner.  In a way that systems administrators can understand
> and embrace.
> A language that obvious how it behaves when looked at and the outcome and
> behavior
> of code is clear.  These were the reasons it is touted over using a turing
> complete
> programming language.

 No arguments from me here. I like Ruby, and I still think the DSL is a
better choice for most system administration.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- Original Message -----
> On Thu, Jan 6, 2011 at 2:19 PM, R.I.Pienaar < rip@devco.net > wrote:
> 
> 
>> imho the right solution is a combination of the require and include
>> keywords,resources requiring classes used extremely sparingly and the
new
>> syntax as Danpointed out.
>> 
>> What worries me greatly is that ''use parametrized
classes'' for
>> everything
>> recommendation seems to be the default response these days from PL
>> even to the
>> point of suggesting the include and require keywords be removed and
>> deprecated
>> while the alternatives are, to be frank, half baked.
> 
> 
> 
> We have some serious language issues with the combination of
> "include/require" being able to repeatedly operate on a class,
and the
> new parameterized syntax only letting you operate on a class once.
> 
> 
> I''m not convinced what the right answer is yet. This is why the
> following bug is still in the "Needs Design Decision" stage.
> 
> 
> http://projects.puppetlabs.com/issues/5046
> 
> 
> It''s possible we just made a mistake with parameterized classes as
> implemented in 2.6.x. We do need to get to somewhere *consistent*,
I''m
> just not quite sure what that place looks like yet.
> 

Then I am doubly perplexed.  It''s not a surprise that the feature
isn''t
adequate perhaps even mistake has been made.

Being that it is not done or fixed in stone you''re almost guaranteed
that its behavior, implications, perhaps even the syntax will change in future
versions.  And not just superficially either, its far from workable.

Does it serve the users that we are recommending they use such a feature?
Do we not almost guarantee costly from a time and effort and risk basis
that using this feature will result in a very difficult migration to a future
version of puppet?

It''s loose loose, the users loose since the Lynchpin of their
production
systems - configuration management - is a ever moving target requiring heavy
refactors between versions.  The community who support the opensource users
loose because it''s ever more complex to support the number of puppet
versions
out there - they all behave differently.
> It spreads confusion and frustrates users.
I''d just state this again.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, Jan 7, 2011 at 3:26 AM, R.I.Pienaar <rip@devco.net>
wrote:
>
>
> ----- Original Message -----
>> On Thu, Jan 6, 2011 at 2:19 PM, R.I.Pienaar < rip@devco.net >
wrote:
>>
>>
>>> imho the right solution is a combination of the require and include
>>> keywords,resources requiring classes used extremely sparingly and
the new
>>> syntax as Danpointed out.
>>>
>>> What worries me greatly is that ''use parametrized
classes'' for
>>> everything
>>> recommendation seems to be the default response these days from PL
>>> even to the
>>> point of suggesting the include and require keywords be removed and
>>> deprecated
>>> while the alternatives are, to be frank, half baked.
>>
>>
>>
>> We have some serious language issues with the combination of
>> "include/require" being able to repeatedly operate on a
class, and the
>> new parameterized syntax only letting you operate on a class once.
>>
>>
>> I''m not convinced what the right answer is yet. This is why
the
>> following bug is still in the "Needs Design Decision" stage.
>>
>>
>> http://projects.puppetlabs.com/issues/5046
>>
>>
>> It''s possible we just made a mistake with parameterized
classes as
>> implemented in 2.6.x. We do need to get to somewhere *consistent*,
I''m
>> just not quite sure what that place looks like yet.
>>
>
>
> Then I am doubly perplexed.  It''s not a surprise that the feature
isn''t
> adequate perhaps even mistake has been made.
>
> Being that it is not done or fixed in stone you''re almost
guaranteed
> that its behavior, implications, perhaps even the syntax will change in
future
> versions.  And not just superficially either, its far from workable.
That''s been true of lots of new features though RI, and it
hasn''t
stopped them being useful for people, achieving actual work, and
eventually moving to a stable place without causing significant user
pain.

Environments were definitely like this and we haven''t caused
significant pain as we improved them.

> Does it serve the users that we are recommending they use such a feature?
> Do we not almost guarantee costly from a time and effort and risk basis
> that using this feature will result in a very difficult migration to a
future
> version of puppet?
Hang on. You''re making a whole bunch of logical leaps here that I
don''t believe are justified at all.

People have been clamoring for some way to pass parameters to classes
as you declare them for a long time, at least since the early days of
0.24.x and almost certainly earlier.

There''s a reason why this was merged into the code base.

Right now I think we have some issues due to the inconsistency between
include/require and the new declaration syntax, and all I said was
that I want us to get to a consistent place, and maybe we made a
misstep in our initial implementation. "our" there refers to all of us
in the community, not just Puppet Labs people. Given the number of
bugs I''ve seen you file or comment about this area, I can''t
believe
you disagree with this.

I don''t see how you jump from our current situation to the idea that
future user pain is guaranteed when we haven''t all decided how to
resolve these problems.
> It''s loose loose, the users loose since the Lynchpin of their
production
> systems - configuration management - is a ever moving target requiring
heavy
> refactors between versions.  The community who support the opensource users
> loose because it''s ever more complex to support the number of
puppet versions
> out there - they all behave differently.
That''s a logical consequence of adding features. Didn''t I
state
earlier that consistency was a primary goal though?

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, Jan 7, 2011 at 3:26 AM, R.I.Pienaar <rip@devco.net> wrote:

[snip]

> Then I am doubly perplexed.  It''s not a surprise that the feature
isn''t
> adequate perhaps even mistake has been made.
>
> Being that it is not done or fixed in stone you''re almost
guaranteed
> that its behavior, implications, perhaps even the syntax will change in
> future
> versions.  And not just superficially either, its far from workable.
>
I''ve switched to writing modules entirely using 2.6.x syntax and
parametrized classes.  While many aspects could certainly be improved,
I''ve
found them to be workable from a module author perspective.

Does it serve the users that we are recommending they use such a
feature?
>
I think the net gain is worth recommending parametrized classes.

The net gain I see is that it helps new and veteran Puppet users flatten
their nested scopes and avoid unintended side effects which arise from
variables referenced but not defined in the local scope and resource
defaults.

In the example you posted previously, what scope does class apache exist
in?  You included the class twice, once in the top scope and once inside of
class apache::php.

The class is only included once so it''s either top or inside of
apache::php.  It''s unclear reading the code what the resulting scope
and
behavior of the apache class will end up as.

Do we not almost guarantee costly from a time and effort and risk
basis
> that using this feature will result in a very difficult migration to a
> future
> version of puppet?
>
I don''t think we guarantee a difficult migration if we recommend
switching
to parametrized classes.  On the contrary, I think we all agree we _must_
address the scoping issue at some point.  I''ve previously [1]
recommended we
change the behavior of include to always add classes at top scope, but
didn''t get much positive feedback from this idea.

If we must address the scoping issue, there is a significant chance the
migration to the fix will require non-zero effort.  My educated guess is
that migrations will be far easier if the code base is already using class
parameters and you have a guarantee multiple inclusions aren''t
happening in
the puppet manifests.

[1]
http://groups.google.com/group/puppet-users/browse_thread/thread/cabf600aff9fe19b

Cheers,
-- 
Jeff McCune
http://www.puppetlabs.com/

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- Original Message -----
> 
> Does it serve the users that we are recommending they use such a
> feature?
> 
> I think the net gain is worth recommending parametrized classes.
> 
> The net gain I see is that it helps new and veteran Puppet users
> flatten their nested scopes and avoid unintended side effects which
> arise from variables referenced but not defined in the local scope and
> resource defaults.
> 
> In the example you posted previously, what scope does class apache
> exist in? You included the class twice, once in the top scope and once
> inside of class apache::php.
> 
> The class is only included once so it''s either top or inside of
> apache::php. It''s unclear reading the code what the resulting
scope
> and behavior of the apache class will end up as.
This is due to the strange design of scoping in puppet not due to the 
desire of wanting to look at code and know what it depends on.

when you look at the apache::php class - perhaps in a emailed diff from
your SCM you know what it does, it needs apache class.  This is a valid 
wish and today with the state of param classes that relationship isnt 
going to be clear.
> 
> 
> 
> Do we not almost guarantee costly from a time and effort and risk
> basis
> that using this feature will result in a very difficult migration to a
> future
> version of puppet?
> 
> 
> I don''t think we guarantee a difficult migration if we recommend
> switching to parametrized classes. On the contrary, I think we all
> agree we _must_ address the scoping issue at some point. I''ve
> previously [1] recommended we change the behavior of include to always
> add classes at top scope, but didn''t get much positive feedback
from
> this idea.
> 
> If we must address the scoping issue, there is a significant chance
> the migration to the fix will require non-zero effort. My educated
> guess is that migrations will be far easier if the code base is
> already using class parameters and you have a guarantee multiple
> inclusions aren''t happening in the puppet manifests.
the specific php example here is bike shedding and I dont care for it, 
the overall point is there are features that are not designed in a way I 
believe has everyones needs in mind and certainly hasnt had community input. 
The language design process needs to be improved so that the result is less
inconsistent and weird.


-- 
R.I.Pienaar

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, Jan 7, 2011 at 9:10 AM, R.I.Pienaar <rip@devco.net> wrote:
> the overall point is there are features that are not designed in a way I
> believe has everyones needs in mind and certainly hasnt had community
input.
I have to admit I was absent from the community when parameterized
classes were introduced as my day job was taking all my time, but did
we really *never* send anything out about it other than the patch
submissions to puppet-dev ?

I thought I''d seen proposals seeking feedback before 2.6.0.

If this wasn''t the case, then that was a screwup.

As far as fixing the situation we''re in now though, I''ve been
pushing
people to provide feedback on:

http://projects.puppetlabs.com/issues/5046

I would love to see your proposals for improving the situation there RI.
> The language design process needs to be improved so that the result is less
> inconsistent and weird.
I agree. I think this is partly a consequence of us generally
accepting patches without having serious curation and discussion of
the consequences, and partly due to our community being largely made
up of sysadmins who are time-poor, with small scraps of time here and
there to devote to this sort of discussion.

It''s a difficult line to tread, as going too far in the other
direction means we''re rejecting too many contributions from the
community, and no-one wants to be in that situation.

So lets fix this.

What do we need?

A formalized group that takes the time to have oversight over language
changes according to general principles we''ve agreed on?

How official does this need to be? A full on committee with rotating
roles and elections etc etc ? A volunteer group whose membership is
completely ad hoc? Why aren''t we getting the right feedback on the
Dev/User lists when proposals are sent out?

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

OK hat is what I was looking for, sorry for the noise.


On Jan 6, 2:04 pm, Daniel Pittman <dan...@rimspace.net>
wrote:
> On Thu, Jan 6, 2011 at 12:29, Luc Suryo <lsu...@gmail.com> wrote:
> > Is it possible to define a class say php-fpm that requires the class
> > php to be called first?  if so what s the syntax?
>
> Yes:  package { "foo": require => Class["bar"] }
>
> I think Nigel just pointed out in another thread that this is, in
> fact, our recommended way to do cross-module and cross-class
> dependencies.  I certainly do, because it means you can change the
> implementation of the PHP stuff without peturbing the php-fpm module
> at all.
>
> Regards,
>     Daniel
> --
> ✉ Daniel Pittman <dan...@rimspace.net>
> ⌨ dan...@rimspace.net (XMPP)
> ☎ +1 503 893 2285
> ♻ made with 100 percent post-consumer electrons
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

To add, I''d like to see a formalized group too... I am slightly tired
of having several methods for declaring resources with different
syntax for roughly the same idea... Examples

node hostname{
   stuff
}

cust_def { ''namestr'':

}

On Jan 7, 9:30 am, Nigel Kersten <ni...@puppetlabs.com>
wrote:
> On Fri, Jan 7, 2011 at 9:10 AM, R.I.Pienaar <r...@devco.net> wrote:
> > the overall point is there are features that are not designed in a way
I
> > believe has everyones needs in mind and certainly hasnt had community
input.
>
> I have to admit I was absent from the community when parameterized
> classes were introduced as my day job was taking all my time, but did
> we really *never* send anything out about it other than the patch
> submissions to puppet-dev ?
>
> I thought I''d seen proposals seeking feedback before 2.6.0.
>
> If this wasn''t the case, then that was a screwup.
>
> As far as fixing the situation we''re in now though, I''ve
been pushing
> people to provide feedback on:
>
> http://projects.puppetlabs.com/issues/5046
>
> I would love to see your proposals for improving the situation there RI.
>
> > The language design process needs to be improved so that the result is
less
> > inconsistent and weird.
>
> I agree. I think this is partly a consequence of us generally
> accepting patches without having serious curation and discussion of
> the consequences, and partly due to our community being largely made
> up of sysadmins who are time-poor, with small scraps of time here and
> there to devote to this sort of discussion.
>
> It''s a difficult line to tread, as going too far in the other
> direction means we''re rejecting too many contributions from the
> community, and no-one wants to be in that situation.
>
> So lets fix this.
>
> What do we need?
>
> A formalized group that takes the time to have oversight over language
> changes according to general principles we''ve agreed on?
>
> How official does this need to be? A full on committee with rotating
> roles and elections etc etc ? A volunteer group whose membership is
> completely ad hoc? Why aren''t we getting the right feedback on the
> Dev/User lists when proposals are sent out?
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I would like to see a dedicated group for this too. I have a few
opinions on the matter of language syntax and semantics.

My main frustration is the matter of slightly different methods for
declaring defines, nodes and classes.

Take these four examples a node, a define and the two class include/
initialize methods.

# A node
node uniquehostname {
        #do stuff
    }

# a define
mydefine {''uniqueName'':
    #do some stuff that can be run multiple times
    param => ''val'',
}

#Comments around ''uniqueclassname'' may be used or ommited here
class {uniqueclassname:
    param => ''val'', #note comments on
''param'' would mess it up here...
lame
    }

#but comments are required here for ''module::class'' syntax,
else it
throws a syntax error
class {''module::uniqueclassname'':
    param => ''val'',
}

#and finally
include uniqueclassname


I would like to see all syntax for instantiating a class define or
node be the same... an example:

node {''unquehostname'': }

mydefine {''uniquedefinename'': }

myclass {''module::classname'': }

####
or if you prefer a more explicit syntax:


node {''unquehostname'': }

mydefine {''uniquedefinename'': }

class {''module::classname'': }

Thoughts?

Nick

On Jan 7, 9:30 am, Nigel Kersten <ni...@puppetlabs.com>
wrote:
> On Fri, Jan 7, 2011 at 9:10 AM, R.I.Pienaar <r...@devco.net> wrote:
> > the overall point is there are features that are not designed in a way
I
> > believe has everyones needs in mind and certainly hasnt had community
input.
>
> I have to admit I was absent from the community when parameterized
> classes were introduced as my day job was taking all my time, but did
> we really *never* send anything out about it other than the patch
> submissions to puppet-dev ?
>
> I thought I''d seen proposals seeking feedback before 2.6.0.
>
> If this wasn''t the case, then that was a screwup.
>
> As far as fixing the situation we''re in now though, I''ve
been pushing
> people to provide feedback on:
>
> http://projects.puppetlabs.com/issues/5046
>
> I would love to see your proposals for improving the situation there RI.
>
> > The language design process needs to be improved so that the result is
less
> > inconsistent and weird.
>
> I agree. I think this is partly a consequence of us generally
> accepting patches without having serious curation and discussion of
> the consequences, and partly due to our community being largely made
> up of sysadmins who are time-poor, with small scraps of time here and
> there to devote to this sort of discussion.
>
> It''s a difficult line to tread, as going too far in the other
> direction means we''re rejecting too many contributions from the
> community, and no-one wants to be in that situation.
>
> So lets fix this.
>
> What do we need?
>
> A formalized group that takes the time to have oversight over language
> changes according to general principles we''ve agreed on?
>
> How official does this need to be? A full on committee with rotating
> roles and elections etc etc ? A volunteer group whose membership is
> completely ad hoc? Why aren''t we getting the right feedback on the
> Dev/User lists when proposals are sent out?
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 01/07/2011 07:49 PM, dingus9 wrote:
> 
> I would like to see a dedicated group for this too. I have a few
> opinions on the matter of language syntax and semantics.
> 
> My main frustration is the matter of slightly different methods for
> declaring defines, nodes and classes.
> 
> Take these four examples a node, a define and the two class include/
> initialize methods.
> 
> # A node
> node uniquehostname {
>         #do stuff
>     }
> 
> # a define
> mydefine {''uniqueName'':
>     #do some stuff that can be run multiple times
>     param => ''val'',
> }
> 
> #Comments around ''uniqueclassname'' may be used or ommited
here
> class {uniqueclassname:
>     param => ''val'', #note comments on
''param'' would mess it up here...
> lame
>     }
> 
> #but comments are required here for ''module::class''
syntax, else it
> throws a syntax error
> class {''module::uniqueclassname'':
>     param => ''val'',
> }
> 
> #and finally
> include uniqueclassname
> 
> 
> I would like to see all syntax for instantiating a class define or
> node be the same... an example:
> 
> node {''unquehostname'': }
> 
> mydefine {''uniquedefinename'': }
> 
> myclass {''module::classname'': }
> 
> ####
> or if you prefer a more explicit syntax:
> 
> 
> node {''unquehostname'': }
> 
> mydefine {''uniquedefinename'': }
> 
> class {''module::classname'': }
> 
> Thoughts?
Nick,

you''re confusing me. You keep writing about "comments" where
(hopefully)
you mean "quotes"!

Please note that "node { }" is always a declaration. Such is
"class {
}". If I read you right, you''d like instanciation to work using
class { "name": }. But how can the parser tell that you
aren''t creating
a new class by the name of "<current_scope>::name"?

Furthermore, it would be downright confusing to be required to write
node { ''dbserver1'':
  include defaults
  include mail::server
  include mysql::server
}
Because declaring a node/class/define is conceptually different from
instanciating a class or define. Both types of block should not look alike.

I find it desirable to allow the negligience of quotes. It''s OK when I
have to quote
node "my.fqdn.server.com" and need not quote
node projecta-db1.

Quoting parameter names is a Bad Idea. But for those that like typing
absolutely unnecessary quote characters in almost each single line of
each single manifest, it may as well be allowed as far as I''m
concerned,
but it should not be a requirement.

Regards,
Felix

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.