Jira (MCO-161) Investigate possible loss of parity between standard Puppet Labs packaging and "mco plugin package"

[Tomas Doran (JIRA)]

Title: Message Title

Tomas Doran commented on an issue   Re: Investigate possible loss of parity between standard Puppet Labs packaging and "mco plugin package" Just to add my $0.02, one of the primary reasons I've been able to sell people on packaging our internal mcollective agents 'properly' (i.e. in separate git repositories, and with Jenkins jobs to run tests and build .debs and .rpms) is that the packaging is uniform. Before the advent of 'mco plugin package' (and data plugins), I tended to just ship a .ddl and .rb file inlined inside my puppet code, and to many people that seems like the 'best' (read as easiest) method of shipping internally developed agents. Obviously (to me) versioning everything as 'latest' is a pretty crappy solution, and having real packages I can promote between environments is a major win. However, to people who don't see these advantages as sharply as me, the winning argument can IME be, uniformity. "We package mcollective agents like this because it's exactly the same as how all mcollective agents get packaged, that's just how it's done" is a winning argument to more traditional 'sysadmin' type people, as they can easily see (and have lots of experience in) the value of homogeneity. Whereas arguments about how we should run tests and build artifacts in Jenkins; coming from a developer world view which is more continuous delivery/continuous integration-centric, whilst being a better argument (IMO) don't have as much weight, as the 'traditional sysadmin' will claim to "just write scripts", and they are unlikely to appreciate the value of unit testing. The best way to get people do the right thing is to make doing the right thing be the easiest thing to do. "Just run mco plugin package, you get a package just like the official agents" is a great example of the right thing to do also being the easiest thing to do! I'd dearly like to see the capabilities of 'mco plugin package' be enhanced as necessary to be more flexible so that everyone can "just run mco plugin package", and I feel that moving away from that for puppetlabs packages, whilst not technically very much worse, is socially sending absolutely the wrong signals.. On a side note, it would be wonderful if mco plugin generate got expanded to at least generate a 'does it compile' test, as I have actually had "but mco plugin generate doesn't generate tests?" offered as an explanation for why at least a smoke test isn't a basic necessity.. Add Comment   MCollective / MCO-161 Investigate possible loss of parity between standard Puppet Labs packaging and "mco plugin package" User feedback has brought up the fact that if plugin packaging moves to the standard Puppet Labs packaging methods "mco plugin package" becomes devalued. We need to have the discussion here if we should review moving forward with standardising packaging or move back to using "mco plugin package". This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.