This message was deleted.

we raised a ticket for that some time ago. the storage wasn't as fast as I would like it to be. we removed the exec resources

it's actually moved on

sh -c test $(find /etc/puppetlabs/code-staging -not -user pe-puppet -print | wc -l) -eq 0

... any way to either speed these finds up or make them less disruptive?

removed the code from the puppet_enterprise module. there isn't a flag 😞

oh that's awesome... maybe create a puppet module for that 😉

😄

That's a tricky one. Those `exec`s are there because code ending up not owned by

pe-puppet

causes File Sync to fail, which causes

pe-puppetserver

to shutdown and then fail to start up until it can enforce the content of the code directory (File Sync is very insistent about making a strong guarantee that an environment is not in a half-deployed state). However, due to roving gangs of sysadmins, files in the codedir have a habit of ending up with

root

ownership. That

exec

allows

puppet

to fix any of those instances --- which means they get auto-solved before a human notices Puppet Server is having a problem. Usually, if that exec times out it is a sign that some environment content needs to be pruned or the node needs more I/O throughput.

I understand the purpose of those execs and I think they should be there, but on a large codebase with a few million files, this just takes ages or fills the IO queues. I think it would be helpful if an opt-out would be possible and thats really a small patch

Again, it's tricky. In many cases, it is not helpful in the long run to enable folks to override safety interlocks so that more pressure can be applied to a system that is already under strain. You're just trading one problem for another.

yes. thats why it should be opt-out. getting a storage upgrade in an "enterprise" environment usually takes months, removing the execs it really a nobrainer compared to that. We did that roughly a year ago and and significantly lowered IO wait and speed up the agent runs

In my experience "short term" fixes always become permanent 😉

honestly if they work I am fine with that 😄

That's why the more effective solution is to prune unused content or increase the I/O bandwidth if there truly needs to be that much content deployed. Because if that

find

is producing high I/O wait, then there are many other mechanisms that are going to produce the same pressure.

we maintain a PE setup where admins do not have much experience with PE, we enabled the execs their again. in another setup this works since almost a year because people do not touch the code

@csharpsteen is there a prune job for versioned-dirs to cleanup? or you suggesting just have less environments?

file-sync has the versioned-dirs-ttl option which configures when older versions of an environmwnt are purged. I think the default is 30min

@csharpsteen I would really love to see a condition around these execs defaulting to true.