(SERVER-338) Ensure netstat is available for service management

[jeffmccune]

Without this patch the puppet server service fails to start at the service
management framework layer. The failure is caused by the service unit
attempting to use netstat to check for listening ports and netstat not being
available.

This patch addresses the problem by expressing a dependency on net-tools, which
contains netstat so that netstat is always available after package installation
and before service management.

Pre-testing

Verified by building the packages from this local topic branch as per
documentation at
https://confluence.puppetlabs.com/display/ENG/How+To+build+Puppet+Server+from+a+local+topic+branch
and running the acceptance tests. The netstat command is successfully
installed and the service starts. Huzzah.

[haus]

@jeffmccune I think this dependency should be expressed in ezbake itself (for example: https://github.com/puppetlabs/ezbake/blob/master/resources/puppetlabs/lein-ezbake/template/foss/ext/redhat/ezbake.spec.erb#L56). Adding it here is sufficient for puppet-server, but pe-console-services and other ezbake projects probaby want the dependency as well.

[jeffmccune]

Cleanup: cleaning up after successful run
Handing 'bxxcjlc7v51pfe5.delivery.puppetlabs.net' back to pooling API for VM destruction
Spent 0.01 seconds cleaning up
Beaker completed successfully, thanks.

[jeffmccune]

What branches of ezbake should it be made to? There are stable, puppetserver/stable and master AFAIK right now.

[jeffmccune]

Decision in planning meeting is to submit this change as a pull request based on the master branch only of ezbake. The reason being, stable and puppetserver/stable will go away as soon as we go gold on the next PE release.

[jeffmccune]

@haus I understand the desire to reduce duplication where different projects are sharing the same resources, however, we're increasing duplication as a result of the confusion that ensues.

For example, we're already expressing the dependency on java-1.7.0-openjdk here, in the project definition. That dependency is duplicated in the redhat spec file. It's also duplicated in the debian spec file. It's also duplicated again in ezbake for PE and FOSS.

As a general principle, am I incorrect in my understanding that dependencies of a project should be expressed by the project itself as we're seeing them expressed in the project.clj file in puppet-server? This is a general principle because we know that it reduces friction between projects, puppet-server updating a dependency should not surprise and impact puppetdb, and it will not if each of the two projects are in control of their dependencies.

[jeffmccune]

@haus Another way of looking at this is that this pull-request is unnecessary, and the only necessary pull request would be to update ezbake, since the dependency lies there and not with each of the projects. What do you think?

If that's the case, then we probably shouldn't be expressing the dependency on Java here, in the project, either, since that's already expressed in ezbake.

[haus]

@jeffmccune yes. i think having java here is needless duplication

[jeffmccune]

Closing since it's really ezbake and the service scripts that depend on netstat and those dependencies are expressed in the ezbake templates rather than the project definition.

[haus]

@jeffmccune I think that if puppet-server has a need that other ezbake projects don't have, then including that dependency in project.clj would make sense, but if it is a shared dependency it belongs in ezbake.

[jeffmccune]

@jeffmccune I think that if puppet-server has a need that other ezbake projects don't have, then including that dependency in project.clj would make sense, but if it is a shared dependency it belongs in ezbake.

I'm mostly with you, but there's a nuance I'd like to call out. Two projects may end up having the same dependency, but they should still be isolated from each other (so they could vary, if needed) if it's the project (application layer) that depends on something versus the service framework (system layer? ezbake layer?) that depends on something.

A bit complicated and nuanced, but do you see what I'm driving at?

[haus]

@jeffmccune yea, that makes sense to me