can a class require an other class?
Luc Suryo
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
jcbollinger
are already doing? That's where it SHOULD go.
John
Daniel Pittman
> 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
R.I.Pienaar
----- Original Message -----
> 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 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
Dan Bode
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']
}
>Why is it a problem to put the require on Package["php5-pfm"] as you
> package ( "php5-pfm" : ensure => "installed", require => "Update_repo[
> "dotdeb-repo" ] }
>
> where update_repo ( "dotdeb-repo" } is in the php class
>
> make sense? comment? advice ?
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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Daniel Pittman
>> 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 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.
:)
jcbollinger
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.
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
R.I.Pienaar
----- 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
Dan Bode
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
R.I.Pienaar
----- 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 :)
Nigel Kersten
We need to retain - and recommend, document and support - the way for classes
to set relationships between classes.
On Thu, Jan 6, 2011 at 3:06 PM, jcbollinger <John.Bo...@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?
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.
R.I.Pienaar
----- Original Message -----
> On Thu, Jan 6, 2011 at 2:19 PM, R.I.Pienaar < r...@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.
Nigel Kersten
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?
Jeff McCune
[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/
R.I.Pienaar
----- 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
Nigel Kersten
> 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?
Luc Suryo
dingus9
of having several methods for declaring resources with different
syntax for roughly the same idea... Examples
node hostname{
stuff
}
cust_def { 'namestr':
dingus9
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
Felix Frank
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