On 2013-15-08 6:20, Dustin J. Mitchell wrote:
This is regarding ticket 5517. Briefly, that ticket identifies a corner
case of parameterized classes and inheritance that behaves unexpectedly
with no warnings or error messages. The ticket has evolved from "please
fix" to "please warn or treat as an error" to "parameterized classes
were never a good idea anyway, let's kill them".
Pardon me while I vent a little.
Puppet has a long history of introducing new features that reference
some conceptual underpinning, then uncovering major flaws and failures
to completely implement the conceptual model, deciding they don't work
at all, and deprecating them. To name just a few: inheritance,
parameterized classes, stored configurations, global variables (or
depending on who you ask, variables in general), Ruby DSL, ENCs,
extlookup, Hiera 1. Some of these technologies died within months of
being introduced!
This is incredibly abusive to Puppet's users, who must either constantly
rewrite their manifests to suit the latest hotness before it gets cold,
or not upgrade to versions of puppet that no longer support features
they use.
Now, I know software development is hard, and that the core Puppet
development team pushes pretty relentlessly forward, and that a lot of
development comes from community members submitting patches with subtle
bugs or model mismatches that get past review and QA. Nobody's
perfect. I know that semantic versioning helps users to make
compatibility predictions based on version numbers. I know that the new
parser - and a lot of Henrik's other work - builds a base for real,
formally defined behaviors that can be supported long-term. I know that
ARMs are meant to open a space for careful thought and discussion of new
features and their implications for the future. Basically, I'm venting,
but I realize that improvement is already occurring and I'm grateful for it.
What I've been missing is an explicit conversation about what I see to
be a substantial problem, and the ways we can all help fix it. I'll
give a start to the latter:
1. We should all read ARMs early and critically. I've certainly failed
on this count.
2. We should resist the urge to admit defeat on (mis)features already
implemented, and look for creative ways to fix their warts.
3. When we do admit defeat, surrender completely and spend a *lot* of
effort making sure the new way is the right way - the cost to users is
huge, so make it count.
Totally agree with your summation.
Looping back to #5517, IMHO
it's not time to give up on parameterized classes, so let's fix the wart.
Unless it was clear earlier; I have nothing against parameterized
classes per se - it is just that there are cases where "include" vs.
"resource like" instantiation of the class clashes. There are options:
a) (now) Silently ignore problem
b) Report problem as an error
c) Deprecate the "resource like" instantiation in favor of data-bindings
d) Something else... but what?
I am contemplating a "dependency graph" approach - but not sure it will
work because it is most likely self referential. (i.e. who is using
which named object (class, variable, etc) where) and letting that
determine the order of evaluation. Not sure this approach can be made to
work.
Regards
- henrik
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
