On 10 September 2014 09:12, Spencer Krum <krum.spen...@gmail.com> wrote: > Yes integration would have to be opt-in. I'm sure the maintainers of those > tools would want it that way anyways. And everything would have to respect > the http_proxy variable, everyone's favorite variable in corporate settings. > > On Wed, Sep 10, 2014 at 5:58 AM, Trevor Vaughan <tvaug...@onyxpoint.com> > wrote: >> >> If anyone does tool integration PLEASE make it opt-in. >>
The simplest route would be plugins, so installation of the plugin as the opt-in. Vagrant and Geppetto support a plugin module, while librarian and r10k are Ruby so a gem and some monkey patching should suffice. G >> It's always fun trying to explain why your tools are pounding on the >> inside of a corporate firewall. >> >> Trevor >> >> On Wed, Sep 10, 2014 at 1:40 AM, Gareth Rushgrove >> <gar...@morethanseven.net> wrote: >>> >>> On 7 September 2014 15:57, Spencer Krum <krum.spen...@gmail.com> wrote: >>> > Hi Puppet-dev, >>> > >>> > I've been working, with a lot of help from some others, on a new >>> > project at >>> > http://puppet-analytics.org. It is very much in the >>> > experimental/development >>> > phase and I'm looking for feedback and help. >>> > >>> > The goal of this project is to enable module authors and users greater >>> > visibility into module use. The architecture is modeled after Debian's >>> > popularity contest, where a program on the debian system reports to a >>> > central server about package use. This means that Puppet users can >>> > submit(through a json/http endpoint) 'hey I've deployed this version of >>> > stdlib!'. After a bunch of users have been reporting for a while, >>> > module >>> > maintainers can see the trends, identify which versions of the modules >>> > are >>> > being used, etc. Similarly users can see which modules are the most >>> > popular, >>> > which versions of those modules are the most popular, etc. >>> > >>> > There is an arbitrary tagging system built in that allows users to >>> > report >>> > that the deploy is being performed by their ci infrastructure, by a >>> > developer doing testing, or by an operator pushing code to production. >>> > This >>> > allows people viewing the data to see the 'true' numbers, unpolluted by >>> > ci >>> > systems or runaway webcrawlers. >>> > >>> > Reporting can be done with curl, or with a script. Right now there is a >>> > script and example curl to report to puppet analytics at: >>> > https://github.com/nibalizer/puppet-analytics-client. I think >>> > everyone's >>> > infrastructure looks a little different, so writing a generic tool to >>> > report >>> > to PA would be pretty hard. I'd like puppet-analytics-client to become >>> > a >>> > place to put scripts and tools to hit PA. >>> > >>> > I'm interested in your thoughts an opinions. Especially around the >>> > opt-in >>> > architecture. Would you be willing to report to PA? Do you think we >>> > would >>> > ever be able to get enough people reporting that the data would be >>> > significant? All the code is open source on github >>> > (https://github.com/nibalizer/puppet-analytics). The website is hosted >>> > on >>> > digital ocean. I also have the mental model that people would report >>> > after >>> > every code change to their Puppet infrastructure, i.e. in the >>> > post-commit >>> > hook if using dynamic environments. Is this a model you agree with? Do >>> > you >>> > have a different idea? >>> > >>> > We have had a lot of conversations, on this list, and in person, around >>> > 'what are people doing with puppet?' I think a tool like this could >>> > really >>> > help us figure out which modules are being used the most often. >>> > >>> > Please note that PA is not nearly done yet. Much of the empty space I >>> > expect >>> > will be filled in with cool visualizations of the data. It is liable to >>> > break at any time, especially with actual users. One of the cool >>> > features >>> > that is currently in PR is the ability to have shields.io downloads >>> > tags >>> > come from PA and show up in the ReadMe's of our modules. >>> > >>> >>> I mentioned last night at the Portland Puppet User Group that I think >>> from a module developers point of view this is really cool. >>> >>> A couple of things I said which may be worth repeating are that rapid >>> integration with some of the dependency tools could net lots of data >>> quickly, for instance: >>> >>> * librarian-puppet >>> * r10k >>> * geppetto >>> * vagrant >>> >>> Probably some others I've forgotten. >>> >>> Gareth >>> >>> > Thanks everybody, >>> > Spencer >>> > >>> > -- >>> > Spencer Krum >>> > (619)-980-7820 >>> > >>> > -- >>> > 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+unsubscr...@googlegroups.com. >>> > To view this discussion on the web visit >>> > >>> > https://groups.google.com/d/msgid/puppet-dev/CADt6FWPoK7N6pwPj4h6_84p-6WEwtz3N6zJbuJniRkHaMi9HBA%40mail.gmail.com. >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- >>> Gareth Rushgrove >>> @garethr >>> >>> devopsweekly.com >>> morethanseven.net >>> garethrushgrove.com >>> >>> -- >>> 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+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/puppet-dev/CAFi_6yKyY03L-NMdo2qy%3DeNSZYQPWem8bJUeeoBU3_yJLfpkmQ%40mail.gmail.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 >> tvaug...@onyxpoint.com >> >> -- This account not approved for unencrypted proprietary information -- >> >> -- >> 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+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVaOZatVtyjXBPAZG-4SDwEwQ7nBNG2pj%3DXNQJ8oHm6zg%40mail.gmail.com. >> >> For more options, visit https://groups.google.com/d/optout. > > > > > -- > Spencer Krum > (619)-980-7820 > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CADt6FWN%2BuqL-CgTQUnMdJ74mOzupWok-2WWmmOeoLbaKCFMFvg%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- Gareth Rushgrove @garethr devopsweekly.com morethanseven.net garethrushgrove.com -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAFi_6yKz8eJiasCzz8%3D0Cgw_K%2B0g_G5_MmnFS1Xu5ZUf_Cnu%2Bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
