Bug #6299

fact_names being mangled, 2.6.5rc1, mysql

Added by Mark Washeim over 1 year ago. Updated 4 months ago.

Status:Needs More Information Start date:02/12/2011
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:parser
Target version:2.7.x
Affected Puppet version:2.6.5 Branch:
Keywords:
Votes: 0

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 1 year ago

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

#2
Updated by Nigel Kersten over 1 year ago

  • Status changed from Unreviewed to Needs More Information

#3
Updated by Markus Roberts over 1 year 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 about 1 year 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 about 1 year 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 about 1 year 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 4 months ago

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

2.6.x is closed. Moving to 2.7.x

Also available in: Atom PDF