On 10 September 2014 09:12, Spencer Krum <[email protected]> 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 <[email protected]>
> 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
>> <[email protected]> wrote:
>>>
>>> On 7 September 2014 15:57, Spencer Krum <[email protected]> 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 [email protected].
>>> > 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 [email protected].
>>> 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
>> [email protected]
>>
>> -- 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 [email protected].
>> 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 [email protected].
> 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 [email protected].
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.

Reply via email to