Puppet Dev Status -- week ending Feb 21

[Henrik Lindberg]

We gave all of the yaks a mullet, now they need a shave.

Everyone is really busy with the AIO packaging and getting all the right
bits through the testing gauntlet.

After much going back and forth on one of the details; what should the
paths be for all the components in the AIO? we decided to write this up
as a proper specification. Now there is one:
https://github.com/puppetlabs/puppet-specifications/blob/master/file_paths.md

Making the changes for these paths, the tests pipelines, and doing
everything in the right order and also fixing the problems that have
occurred is taking longer than anticipated.

Old friends come back and bite us... as an example there are circular
dependencies between hiera and puppet that makes testing interesting.
We also again experienced how difficult it is to add a dependency on an
additional gem - now experienced again with the deep_merge gem (for
merging arrays and hashes in hiera and in the the data in modules
support). We simply have a lot of ways the software gets delivered, and
in some cases it is difficult to get a gem in the right place. Thus we
ended up vendoring (i.e. including a copy) the deep_merge gem like we do
with some other gems. Long term we want to stop doing this - but for now
there were too many places to deal with, and we did not want to add
additional yaks to the line of yaks already waiting for their shave.

On the bright side, while waiting for the bits to fall into place, we
have been fixing additional puppet and hiera tickets that we thought we
would not get to in time for the release of Puppet 4.0/3.7.5 and friends.

Real soon now folks...

- henrik


--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[Erik Dalén]

Regarding the installation paths, wouldn't it make sense to move ssldir to $vardir/ssl instead to make it more in line where distros put it?
As that directory essentially needs to be writable by the puppet agent.

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/mc8ne9%245e5%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[Trevor Vaughan]

Yes please. Moving this out of $vardir/ssl will be quite irritating to teach existing users about the new product usage.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAAAzDLeOTz-bt_3jw_4mw8yY9EuMUuLknx8oHvz9RBS0bUPVVg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Jeff McCune]

On Sun, Feb 22, 2015 at 12:08 PM, Trevor Vaughan <tvau...@onyxpoint.com> wrote:

Yes please. Moving this out of $vardir/ssl will be quite irritating to teach existing users about the new product usage.

Even if we kept it in $vardir/ssl, this would mean the path is /opt/puppetlabs/puppet/cache/ssl rather than /var/lib/puppet/ssl (Please note the agent and master vardir's in the specification).  Is your concern that SSL data remain in $vardir/ssl or that they remain in /var/lib/puppet/ssl ?

-Jeff

[Trevor Vaughan]

Hmm....I suppose it might not matter as much so long as we get people used to using 'puppet config print ssldir'.

That said, the SSL directory is one of those critical items to back up on your system and the principal of least surprise would be nice here.

Honestly using /etc/pki (RHEL) or /etc/ssl (Deb) would be nice, but it's not part of the FHS so probably not a good choice.

So, in the end, I'll just use puppet config print ssldir and you can place it wherever makes sense to you.

Thanks,

Trevor

--

You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAOXx1vFymTmFpHe9Fttj%3D9dwvFwXFZNZqUyGMmPBRTzykxP0Ew%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Erik Dalén]

I've just noticed it is one of those things distros frequently change the default value for (and kind of rightly so as it is variable data, not config files). And it would be good if the PL default and distro default matched each other to avoid confusion. Not terribly important, but good to fix when changing everything around anyway.

For migration it is likely best if it remains in the same place though, will see how we will deal with that if we just config it to old location or move the files around when upgrading if the location changes.

 

-Jeff

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAOXx1vFymTmFpHe9Fttj%3D9dwvFwXFZNZqUyGMmPBRTzykxP0Ew%40mail.gmail.com.

[Trevor Vaughan]

I'm sorry, but I can't find the completely AIO doc right now with all of the paths, but are you going to try to be FHS compliant?

/opt => Install

/etc/opt => Config

/var/opt => Var

Thanks,

Trevor

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAAAzDLfMBBD6K_CybLS_ssw5mTENjvft%3DhPg8WgTY4B9dxdwvw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Eric Sorenson]

tldr: No

Spec is here: https://github.com/puppetlabs/puppet-specifications/blob/master/file_paths.md

The FHS is actively user-hostile and when we've tried to follow it, everyone ends up hating it. The current PE var area is under /var/opt and it's awful.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXK9G4OFbPz8gZOBC%2BT2chO-B-pvz%2BXjBtkiRudxsnhdg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Eric Sorenson - eric.s...@puppetlabs.com - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles

[Trevor Vaughan]

No problem.

Unfortunately, I do agree about the FHS, but occasionally customer security specs will dictate filesystem modifications and/or restrictions that might make it more difficult.

Will we be able to do a whole-hog AIO move if necessary? /opt/foo to /srv/foo or /var/foo or whatever. Symlinks will probably work as well, but it's never ideal.

rake rootdir[/srv/foo] or something to change all of the sub-components.

'No' is obviously valid, just nice to know.

Thanks,

Trevor

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/7D1EDE7E-D9C9-47C3-82CB-328A12BB1FEC%40puppetlabs.com.

For more options, visit https://groups.google.com/d/optout.

[Wil Cooley]

It does not seem like a great idea to put $vardir under /opt. /opt is only sometimes a separate file system from / and could grow much more variably. If anything, I'd rather see the some of the directories under $vardir to be moved to /var/cache/puppet, depending on whether the data is transitory or persistent. (Much of it, in fact, I would expect to be cache, but 'reports', 'bucket' and possibly 'clientbucket' stand out as non-transitory so kept in 'lib'; if ssl were not in /etc I would expect it to be in 'lib' as it is not transitory.)

I agree with the hating on '/etc/opt' and '/var/opt' too.

Also, if hiera, c?facter and mco are going to be installed in /opt/puppetlabs/puppet, why bother with the extra directory level and then have to bother symlinking into /opt/puppetlabs/bin? I'm guessing that there is an expectation that other projects/products will go alongside the 'puppet' level, but then it seems weird to put hiera c?facter and mco into 'puppet' instead of their own directories. I guess you're putting ruby into the 'puppet' directory, so that's why... Hrm

Blue. I say it should be blue!

Wil

[Trevor Vaughan]

+1 for caching stuff in /var/cache and I'd also like to vote for some self-cleaning of those directories (if not there already).

Nah, green...

Thanks,

Trevor

--

You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMmm3r43PjKyGNbvPFYRRw5aM8XtDz%2BuQFMB6GTDdCf%2BZj%3DPcg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Stahnke]

On Tue, Feb 24, 2015 at 10:31 AM, Wil Cooley <wco...@nakedape.cc> wrote:

On Mon, Feb 23, 2015 at 2:17 PM, Jeff McCune <je...@puppetlabs.com> wrote:

On Sun, Feb 22, 2015 at 12:08 PM, Trevor Vaughan <tvau...@onyxpoint.com> wrote:

Yes please. Moving this out of $vardir/ssl will be quite irritating to teach existing users about the new product usage.

Even if we kept it in $vardir/ssl, this would mean the path is /opt/puppetlabs/puppet/cache/ssl rather than /var/lib/puppet/ssl (Please note the agent and master vardir's in the specification).  Is your concern that SSL data remain in $vardir/ssl or that they remain in /var/lib/puppet/ssl ?

It does not seem like a great idea to put $vardir under /opt. /opt is only sometimes a separate file system from / and could grow much more variably. If anything, I'd rather see the some of the directories under $vardir to be moved to /var/cache/puppet, depending on whether the data is transitory or persistent. (Much of it, in fact, I would expect to be cache, but 'reports', 'bucket' and possibly 'clientbucket' stand out as non-transitory so kept in 'lib'; if ssl were not in /etc I would expect it to be in 'lib' as it is not transitory.)

/var is sometimes only a separate filesystem not as well. We plan to keep (as we have for PE) the SSL stuff in /etc/puppetlabs/puppet/ssl. Putting it in cache doesn't make a ton of sense, at least in my head a cache should be able to regenerated upon deletion. That wouldn't work well for ssl certs. 

Distros place ssl certs as configuration information in /etc- however since distros can't ever seem to agree on where that stuff should go, we're putting it with our application stack.

I agree with the hating on '/etc/opt' and '/var/opt' too.

I hate those so much. 

Also, if hiera, c?facter and mco are going to be installed in /opt/puppetlabs/puppet, why bother with the extra directory level and then have to bother symlinking into /opt/puppetlabs/bin? I'm guessing that there is an expectation that other projects/products will go alongside the 'puppet' level, but then it seems weird to put hiera c?facter and mco into 'puppet' instead of their own directories. I guess you're putting ruby into the 'puppet' directory, so that's why... Hrm

There will be other directories at the puppet level in some types of installations. You could see puppet-server being there, or puppetdb or something. More information on that to come in the future. 

 

Blue. I say it should be blue!

Wil

--

You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAMmm3r43PjKyGNbvPFYRRw5aM8XtDz%2BuQFMB6GTDdCf%2BZj%3DPcg%40mail.gmail.com.