The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #6299

fact_names being mangled, 2.6.5rc1, mysql

Added by Mark Washeim over 3 years ago. Updated almost 2 years ago.

Status:Needs More InformationStart date:02/12/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:parser
Target version:-
Affected Puppet version:2.6.5 Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

This looks like it should be timestamp?

| 39 | --- !ruby/sym _timestamp | 2011-02-11 14:58:52 | 2011-02-11 14:58:52 |

History

#1 Updated by Nigel Kersten over 3 years ago

Mark, was this definitely not the case prior to the 2.6.5 RC series?

#2 Updated by Nigel Kersten over 3 years ago

  • Status changed from Unreviewed to Needs More Information

#3 Updated by Markus Roberts over 3 years ago

  • Status changed from Needs More Information to Rejected

This has been “_timestamp” (with an underscore) since 0.24.5 at least, and possibly far longer.

If there is some new behaviour that led you to thinking that this was in error please provide more details / context & reopen.

#4 Updated by Mark Washeim over 3 years ago

  • Status changed from Rejected to Re-opened

the attribute timestamp is not the problem. That “—– !ruby/sym _timestamp” is being stored in the column is the problem. It’s most probably caused by spurious manifest errors. But it occurs. Since I’ve been restructuring our manifests (and correcting errors) I’ve not been able to reproduce it. Still, it seems like an ‘error by design’ when a string that is not going to be parse-able is written to the db?

I’ll see if I can find the clause that could be thrown off by an error.

#5 Updated by Mark Washeim over 3 years ago

Mark Washeim wrote:

the attribute timestamp is not the problem. That “—– !ruby/sym _timestamp” is being stored in the column is the problem. It’s most probably caused by spurious manifest errors. But it occurs. Since I’ve been restructuring our manifests (and correcting errors) I’ve not been able to reproduce it. Still, it seems like an ‘error by design’ when a string that is not going to be parse-able is written to the db?

I’ll see if I can find the clause that could be thrown off by an error.

Very odd. I started searching and for the first found that the timestamp param name was gone.

mysql> select * from param_names where name like “timestamp”; Empty set (0.00 sec)

I should probably also have mentioned that I’m using foreman (no reporting, no unattended).

In any case, I’ll look a little bit further…

#6 Updated by James Turnbull over 3 years ago

  • Status changed from Re-opened to Needs More Information
  • Affected Puppet version changed from 2.6.5rc1 to 2.6.5

Any update on this Mark?

#7 Updated by Michael Stahnke almost 3 years ago

  • Target version changed from 2.6.x to 2.7.x

2.6.x is closed. Moving to 2.7.x

#8 Updated by Andrew Parker almost 2 years ago

  • Target version deleted (2.7.x)

#9 Updated by Andrew Parker almost 2 years ago

As the 2.7.x line is winding down, I am removing the target at 2.7.x from tickets in the system. The 2.7 line should only receive fixes for major problems (crashes, for instance) or security problems.

Also available in: Atom PDF