error after upgrading from 2.7.14-2puppetlabs1 to 2.7.17-1puppetlabs1

45 views
Skip to first unread message

Erik Anderson

unread,
Jun 27, 2012, 5:24:44 PM6/27/12
to puppet...@googlegroups.com
Hello all -

For the last few weeks I've been running puppet 2.7.14-2 from the
puppetlabs apt repo. This is on Ubuntu 12.04 LTS, x64. Things have
been going great, no issues (at least none related to puppet
itself...).

I upgraded to 2.7.17-1 this morning, again from the official
puppetlabs apt repository, and after doing this, started getting the
following syntax error during puppet agent runs:

err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not parse for environment production: Syntax error at
'-'; expected '}' at
/etc/puppet/manifests/classes/server-classes.pp:36 on node
host.example.com

Initially, I thought that I had pushed a bad config, so I reverted to
a previous known-good commit from my puppet git repo, but saw the same
error. I then down-graded back to 2.7.14-2 and the problem went away.
I looked through the puppet change logs, and didn't see anything that
looked like it should have caused this.

Here are the contents of the file referred to in the error message:

https://gist.github.com/3006908

Do you have any ideas what could be causing this?

Thank you,
Erik

llo...@oreillyauto.com

unread,
Jun 27, 2012, 6:36:29 PM6/27/12
to puppet...@googlegroups.com
Comments inline


On Wednesday, June 27, 2012 4:24:44 PM UTC-5, Erik Anderson wrote:
Hello all -

For the last few weeks I've been running puppet 2.7.14-2 from the
puppetlabs apt repo. This is on Ubuntu 12.04 LTS, x64. Things have
been going great, no issues (at least none related to puppet
itself...).

I upgraded to 2.7.17-1 this morning, again from the official
puppetlabs apt repository, and after doing this, started getting the
following syntax error during puppet agent runs:

err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not parse for environment production: Syntax error at
'-'; expected '}' at
/etc/puppet/manifests/classes/server-classes.pp:36 on node
host.example.com


Dashes '-' are not allowed in variable and class names.

We were faced with this recently.

We wound up rolling back and then refactoring all  our code, using puppet-lint as a guide and to help find all the potential issues.

The dashes have been semi-supoported for a short while, and depreciated for most of 2.7.x

I had originally thought that 3.X would be the change where it went from warning to error, but it looks like they pushed this out with 2.7.17 for whatever reason.


Jeff McCune

unread,
Jun 27, 2012, 8:00:36 PM6/27/12
to puppet...@googlegroups.com
On Wed, Jun 27, 2012 at 3:36 PM, llo...@oreillyauto.com
<llo...@oreillyauto.com> wrote:
> The dashes have been semi-supoported for a short while, and depreciated for
> most of 2.7.x

Dashes in variable names started working again in 2.7.3. According to
Daniel Pittman, they shouldn't have started working again. We looked
at the documented behavior and decided to change Puppet to match the
documentation. This change went into the 2.7.x branch and was
released in 2.7.17.

This is what happened and why it happened.

Now... Forcing our users to refactor all of their manifests is
something I'm not so keen on. Particularly in a minor release.

Do you think we should continue allowing hyphens in variables in 2.7
and only "fix" this to error out in 3.0?

> I had originally thought that 3.X would be the change where it went from
> warning to error, but it looks like they pushed this out with 2.7.17 for
> whatever reason.

It was never a deprecation warning as far as I can tell. 2.6.16
errors out, as does 2.6.7 and 2.6.12. 2.7.0 and 2.7.1 did error out.
2.7.3 didn't error out for whatever reason and this was the point we
accidentally regressed to allowing hyphens in variable names. This
allowance remained all the way through 2.7.14. In 2.7.16 we "fixed"
it again to error out with hyphens in variable names. This remained
in 2.7.17.

So, I think the story is... Don't use hyphens in variable names (and
class names). We accidentally allowed them from 2.7.3 through 2.7.14
but we've gone back to it being an error.

-Jeff

Erik Anderson

unread,
Jun 27, 2012, 8:38:36 PM6/27/12
to puppet...@googlegroups.com
On Wed, Jun 27, 2012 at 5:36 PM, llo...@oreillyauto.com
<llo...@oreillyauto.com> wrote:
> Dashes '-' are not allowed in variable and class names.
>
> We were faced with this recently.
>
> We wound up rolling back and then refactoring all  our code, using
> puppet-lint as a guide and to help find all the potential issues.
>
> The dashes have been semi-supoported for a short while, and depreciated for
> most of 2.7.x
>
> I had originally thought that 3.X would be the change where it went from
> warning to error, but it looks like they pushed this out with 2.7.17 for
> whatever reason.

Ahh, excellent. Thanks for the heads up.

It's odd that this change happened in a minor version upgrade, but at
least I know now that I'm not going crazy.

Luckily I'm very early on in our puppet deployment, so re-factoring
variable names won't be all that big of a deal.

-Erik

Erik Anderson

unread,
Jun 27, 2012, 8:40:09 PM6/27/12
to puppet...@googlegroups.com
On Wed, Jun 27, 2012 at 7:00 PM, Jeff McCune <je...@puppetlabs.com> wrote:
> So, I think the story is...  Don't use hyphens in variable names (and
> class names).  We accidentally allowed them from 2.7.3 through 2.7.14
> but we've gone back to it being an error.

Understood, Jeff. Thanks for the clarification.

-Erik

Erik Dalén

unread,
Jun 28, 2012, 4:42:43 AM6/28/12
to puppet...@googlegroups.com
On 28 June 2012 02:00, Jeff McCune <je...@puppetlabs.com> wrote:
> On Wed, Jun 27, 2012 at 3:36 PM, llo...@oreillyauto.com
>> I had originally thought that 3.X would be the change where it went from
>> warning to error, but it looks like they pushed this out with 2.7.17 for
>> whatever reason.
>
> It was never a deprecation warning as far as I can tell.  2.6.16
> errors out, as does 2.6.7 and 2.6.12.  2.7.0 and 2.7.1 did error out.
> 2.7.3 didn't error out for whatever reason and this was the point we
> accidentally regressed to allowing hyphens in variable names.  This
> allowance remained all the way through 2.7.14.  In 2.7.16 we "fixed"
> it again to error out with hyphens in variable names.  This remained
> in 2.7.17.
>
> So, I think the story is...  Don't use hyphens in variable names (and
> class names).  We accidentally allowed them from 2.7.3 through 2.7.14
> but we've gone back to it being an error.
>

But it is only dashes in variables that produce errors in 2.7.16+, right?
I know they are deprecated in class names as well, but they have
worked in them for the most part since 0.24.x releases at least AFAIK.
Ofc if they aren't allowed in variable names you shouldn't be able to
refer to variables in classes with dashes, like $class-name::variable.

We unfortunately still have some classes with dashes in the names but
no variables, so I want to know if it is safe to upgrade to 2.7.17?

--
Erik Dalén

R.I.Pienaar

unread,
Jun 28, 2012, 4:48:22 AM6/28/12
to puppet...@googlegroups.com
It does unfortunately still allow - in class names, I think the fix for
this was half baked as you couldn't access variables in those classes
from outside of the class

docs says:

"Class names, module names, and the names of defined and custom resource
types should be restricted to lowercase alphanumeric characters and
underscores, and should begin with a lowercase letter; that is, they
should match the expression [a-z][a-z0-9_]*. Although some names that
violate these restrictions currently work, using them is not
recommended."

Steph Gosling

unread,
Jun 28, 2012, 5:08:33 AM6/28/12
to puppet...@googlegroups.com, Erik Dalén
Hi,

On Thu, 28 Jun 2012 10:42:43 +0200
Erik Dalén <erik.gus...@gmail.com> wrote:

> We unfortunately still have some classes with dashes in the names but
> no variables, so I want to know if it is safe to upgrade to 2.7.17?

For us at least classes like this still work with .17. I should say
though that these are all very simple classes (describing packages
typically), most aren't even parameterized.

Cheers,

Steph

--
Steph Gosling <st...@chuci.org>
Reply all
Reply to author
Forward
0 new messages