p4 won't do anything more than the bare minimum "keep it running" to r10k unless someone flashes a really full wallet at them.

does g10k do atomic deployment?

Not sure, but could we add it in?

it honestly would not be hard to get really close to atomic with current r/g10k. Just deploy to a temp directory and then move in place.

I see. I guess I had a blind spot to this issue, until now.

Always hoping to learn and improve.

it would be very little work to add it to either too

basedir

comes from

/etc/puppetlabs/r10k/r10k.yaml

so would have to do some shenanigans to supply a

mktemp

based directory and then do a switcheroo. Hopefully, I'm thinking about it the right way.

For one of my Linux servers, I'm getting a "Warning: Failed to automatically renew certificate: 403 forbidden". Based on the configuration files, the puppet agent should not be trying to get a new certificate on its own. I have never tripped over this issue before. (I'm running openvox-agent 8.28.1) Could someone have accidentally set the renew setting on the command line? And if so, where would it be stored? Querying the agent/main/user settings shows everything is as it should be. (We do cert renewal through a cron job and have for over a decade.)

@Bob Negri check the auto_renewal configuration parameters. If you just want to disable it and use what you've already built, that's turning off

allow_auto_renewal

Thanks. Just odd that this is the only server I've encountered that is doing this. Of course we did shorten the cert life recently.

then do a switcheroo

Please provide feedback on this attempt, if someone gets a chance.

Perforce has no reason to add atomic deployments to

r10k

-- because that is a tent-pole feature of PE Code Manager.

I'll try out my attempt for a suitable period of time, and then I will say yes, when Tim asks me for a blog post.

Atomic should just be a matter of updating a symlink. The compiler will de-reference that at the beginning of compilation and use the referenced location for the duration. Moving directories might not work, because the path stays the same.

@Corporate Gadfly foxxx0 in #C07RCJYU147 has a script to make r10k deployments atomic

@Corporate Gadfly was your environment cache enabled?

@bastelfreak

environment_timeout

is not set in

server

section of

puppet.conf

, so that means caching is disabled.

So three things need to happen, from cursory reading: • Run

r10k

as puppet user • set

environment_timout = unlimited

in

puppet.conf

• purge cache in

r10k

post run

Cache delete example.

Moving directories is nice as long as both are on the same filesystem.. which is not always true

So symlinks should work better. Also I see no reason to not fork r10k

@Corporate Gadfly environment_timeout goes into environment.conf, not puppet.conf

I don't think swapping directories works because the path is the same before and after. That could result in any in-flight catalog compilations seeing a mix of environment content from two different deployes. Updating a symlink target is atomic, and the target paths are different, so in-flight compiles don't get a mix of content.

We do have a fork but it looks unmaintained? github.com/voxpupuli/r10k github.com/voxpupuli/plumbing/issues/330 @Corporate Gadfly you might want to try codavox, it uses the symlink approach like code-manager does and I could use more eyeballs on it, github.com/miharp/codavox I also have a wip tutorial when one puppetserver is no longer enough, mikeharp.com/openvox-scaling-guide/scaling/codavox.html

I would have opened an issue for this and other org level docs that are out of date but the repo does not have issues enabled, so starting with contributing github.com/OpenVoxProject/.github/pull/18

@bastelfreak

@Corporate Gadfly environment_timeout goes into environment.conf, not puppet.conf

I am confused with this conflicting info. docs.openvoxproject.org/openvox/8.x/configuration.html#…

environment.conf

is for per-environment settings.

Both are valid.

environment_timeout

is a global puppet.conf setting (that's why it's on the configuration reference), and environment.conf is one of the few places allowed to override it per environment. The docs recommend setting it globally in puppet.conf unless you have a reason to vary it: docs.openvoxproject.org/openvox/8.x/config_file_environment.html#…

also, watch out for github.com/OpenVoxProject/openvox/pull/717 if your checking with the cli

Ahhh it's valid in both files