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

Bug #2809

storeconfigs: with mysql impossible to have resource title differing in case

Added by Brice Figureau over 4 years ago. Updated about 3 years ago.

Status:Needs DecisionStart date:11/12/2009
Priority:LowDue date:
Assignee:Brice Figureau% Done:

0%

Category:Rails
Target version:-
Affected Puppet version:0.25.1 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

With the following resource:

file {
  "/etc/sv/m44-test/env/MEMOIR44_HOME": content => "content";
  "/etc/sv/m44-test/env/memoir44_HOME": ensure => absent;
}

I get:

Mysql::Error: Duplicate entry '/etc/sv/m44-test/env/MEMOIR44_HOME-File-116' for key 2: INSERT INTO `resources` (`exported`, `title`, `line`, `updated_at`, `restype`, `source_file_id`, `host_id`) VALUES(0, '/etc/sv/m44-test/env/MEMOIR44_HOME', 103, '2009-11-12 17:00:08', 'File', 85, 116)

The problem is that a VARCHAR field in MySQL does a lookup in a case-insensitive way, so both titles are the same for the MySQL server. I think the correct fix would be to use a BINARY VARCHAR in the schema.

History

#1 Updated by Brice Figureau over 4 years ago

Brice Figureau wrote:

I think the correct fix would be to use a BINARY VARCHAR in the schema.

And I also think a severe error in storeconfigs (ie a catalog caching operation) should not abort the whole compilation. And more generally a fatal error in a cache operation should not halt the backing find operation. But still the error should be transmitted to the client (people tend to look more at the client side of the thing than at the master).

#2 Updated by James Turnbull over 4 years ago

  • Status changed from Unreviewed to Accepted

#3 Updated by Luke Kanies over 4 years ago

Seems like the right fix.

But on the question of both not failing when the cache fails, but also propagating the error… How would we do that? Somehow collect all non-fatal failures that happened during compilation and add them to the catalog?

It’s a great idea, but seems pretty darn complicated.

#4 Updated by Jesse Wolfe over 4 years ago

  • Status changed from Accepted to Needs More Information
  • Assignee set to Brice Figureau
  • Target version deleted (0.25.2)

I can’t reproduce this on 0.25.x, we don’t seem to have a uniqueness constraint on that table at all right now. Do you think it’s possible that your database schema is in a different state that what I’ve got?

#5 Updated by Brice Figureau over 4 years ago

Jesse Wolfe wrote:

I can’t reproduce this on 0.25.x, we don’t seem to have a uniqueness constraint on that table at all right now. Do you think it’s possible that your database schema is in a different state that what I’ve got?

You’re right, I’m running with a stricter schema (and with more indices too) than the one defined in puppet (which I once wanted to push upstream, but never really finished), and I totally forgot about it. Feel free to reject the bug then.

Anyway, this still would be an issue for instance with the following manifest:

 @@file {
   "/tmp/A": content => "A";
   "/tmp/a": content => "a";
 }
 File <<| title == "/tmp/a" |>>

This would certainly load the “/tmp/A” resource and not the one we want it to load. The result is not deterministic. The problem is the same with tag names.

#6 Updated by Markus Roberts over 4 years ago

  • Status changed from Needs More Information to Needs Decision

#7 Updated by Markus Roberts over 4 years ago

  • Target version set to 0.25.3

#8 Updated by Markus Roberts over 4 years ago

  • Target version changed from 0.25.3 to 0.25.4

#9 Updated by James Turnbull over 4 years ago

  • Target version changed from 0.25.4 to 0.25.5

#10 Updated by James Turnbull about 4 years ago

  • Target version changed from 0.25.5 to 49

#11 Updated by James Turnbull over 3 years ago

  • Target version deleted (49)

#12 Updated by James Turnbull about 3 years ago

Brice – should I close this?

Also available in: Atom PDF