g 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/1d38a4dd-596e-4338-b0d5-f6117f3a6052%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/1d38a4dd-596e
. At the very least all these language
proposals and suggestions and syntax changes should come with "real
production code" examples that show how you solve it today and how this
proposed change leads to a more elegant situation for actual puppet users
because right now it seems to be ha
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%2BFoXEmCqKWGZ92jzApa_qP4RKk7zdodUL6OgxiPMU5tc4SQ%40mail.gmail.com
>
.
His background, like mine, is mostly UNIX systems administration. He’s
responsible for the huge refactoring of the apache module a while back, and
is all over the popular puppetlabs modules we hope you’re all using.
Ashley Penney
This one is me. I’m “ashp” on IRC and hopefully I know many of
the first pass through all modules so we're back to
'A', starting with activemq.
Bring your opinions and PRs for other modules not in that list if you want
to jump the queue!
--
Ashley Penney
ashley.pen...@puppetlabs.com
Module Engineer
*Join us at PuppetConf 2014**, September
I'm running late today so I'll spare you the ramblings. We'll be carrying
on doing PRs like every week at
https://plus.google.com/hangouts/_/7acpiq9k91sjml589gf1bbgq7g?hl=en in 5
minutes from when I hit send.
See you there!
--
Ashley Penney
ashley.pen...@puppetlabs.com
Module
through a whole bunch more PRs, and we'll be doing the
same thing again. We'll be jumping in around nodejs this week and working
our way through the list.
Bring your opinions and PRs for other modules not in that list if you want
to jump the queue!
--
Ashley Penney
ashley.pen...@puppe
s not in that list if you want
to jump the queue!
--
Ashley Penney
ashley.pen...@puppetlabs.com
Module Engineer
*Join us at PuppetConf 2014**, September 23-24 in San Francisco
- http://puppetconf.com <http://puppetconf.com/>*
--
You received this message because you are subscribe
or Squeeze - merged
#280 Fix pin comments
- merged
postgres - https://github.com/puppetlabs/puppetlabs-postgresql/pulls
#297- quoting fix
--
Ashley Penney
ashley.pen...@puppetlabs.com
Module Engineer
*Join us at PuppetConf 2014**, September 23-24 in San Francisco
- http://puppetconf.com &l
Hi,
It's soon time for our weekly modules triage/meeting. We'll be meeting at
1700 UTC (I learnt my lesson on timezones) at the regular link:
http://links.puppetlabs.com/modules_hangout.
(The link won't point anywhere active until shortly before the meeting)
Last week we triaged up to the concat
modules not in that list if you want
to jump the queue!
--
Ashley Penney
ashley.pen...@puppetlabs.com
Module Engineer
*Join us at PuppetConf 2014**, September 23-24 in San Francisco
- http://puppetconf.com <http://puppetconf.com/>*
--
You received this message because you are subscribe
and we're getting tons of strangers joining and leaving. I can't really
moderate it so you're possibly exposed to any kind of craziness. We'll try
to find a better solution going forward but for now, be warned, we're
trapped with whoever swings by.
--
Ashley Penney
n on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CAAAzDLdbmjX9tMjQm%3D02%2Bcc-JDG4tp%3Dy%2BB5GfvdmMrsU8gmWcw%40mail.gmail.com<https://groups.google.com/d/msgid/puppet-dev/CAAAzDLdbmjX9tMjQm%3D02%2Bcc-JDG4tp%3Dy%2BB5GfvdmMrsU8gmWcw%40mail.gmail.com?utm_medium=email&utm_sour
Hi,
As some of you will know we've been copying the platform team and doing a
weekly triage/meeting amongst the community to discuss current open PRs,
requests, code in progress, and simply trying to close PRs on some of the
popular modules.
We originally picked 0900 (PST) on Tuesdays to run this
> "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/e58569e96ca0273607ed3081caab15fa%
surprisingly
often).
I have a lot more words written down but that's basically the two things I
suspect we need to address out of the gate. Anyway, let me know what you
people think puppetlabs-mysql needs.
--
Ashley Penney
ashley.pen...@puppetlabs.com
Module Engineer
*Join us at PuppetCo
focus for now and almost all the PRs you'll see generated from us
will be towards testing code.
--
Ashley Penney
ashley.pen...@puppetlabs.com
Module Engineer
*Join us at PuppetConf 2014, September 23-24 in San Francisco*
--
You received this message because you are subscribed to the Google
s on.
The link will be http://links.puppetlabs.com/modules_hangout assuming I've
managed to get the hangout to be public. We start in 15 minutes from the
sending of this email, at 0900 PST.
--
Ashley Penney
ashley.pen...@puppetlabs.com
Module Engineer
*Join us at PuppetConf 2014, Septemb
ache::passenger code in favor of more generic,
reusable code.
604: (apenney) Merge post README changes.
603: (apenney) Same, docs waiting.
546: (apenney) Closed this, based on facter 1.7 having this support in, we
didn't want to merge 1.6 changes.
Look forward to seeing everyone next Tuesday
On Wed, Feb 5, 2014 at 2:20 PM, Felix Frank wrote:
>
>
> This resembles my feeling quite accurately. I've butted heads with
> parsedfile quite a bit as well, and it can make you sad.
>
> Can you elaborate on the possible compatibility concerns? I don't have a
> clear idea in what way those could l
Having just spent the last day solid reading parsedfile, writing notes, and
following it down the rabbithole I can't find myself arguing against this.
I am planning to at least experiment with trying to a/ document this
heavily b/ clean it up and make it easier and more usable because everyone
hat
On Wed, Jan 22, 2014 at 1:15 PM, Henrik Lindberg <
henrik.lindb...@cloudsmith.com> wrote:
> Recent Pull Requests to puppetlabs-stdlib has raised issues w.r.t how we
> should handle stdlib going forward. We have also had a discussion about
> types and providers in core and if they should be moved o
On Fri, Jan 10, 2014 at 12:55 PM, Dustin J. Mitchell wrote:
> On Fri, Jan 10, 2014 at 12:45 PM, Andy Parker wrote:
> > Tier-1 types: user, service, file, group, package, host, cron, exec,
> stage,
> > tidy
> > Tier-1 providers: dpkg, apt, gem, msi, rpm, windows, yum, useradd,
> > windows_adsi, gr
eam Puppet but it's still in
a PR. It should make developing providers (it didn't have one before)
significantly easier for the community.
We're still just a team of 3, so I'm afraid this is all we were able to get
done, but we'll continue working on bringing you
and shout at ashp (or hunter) if you want anything module related
or just want to throw us your worst "I can't figure out how to.." problems.
Thanks,
--
Ashley Penney
ashley.pen...@puppetlabs.com
Module Engineer
*Join us at PuppetConf 2014, September 23-24 in San Francisco*
-
B! If I had a catalog that ended with a reboot and there was an issue I
would be very surprised (and probably upset) if my machine rebooted. It
may be in a state that won't boot cleanly due to the failing half run
catalog.
On Mon, Sep 16, 2013 at 2:52 PM, Rob Reynolds wrote:
> We are discussi
I'd also like to suggest you take a look at some of the other puppetlabs-*
modules for how we test types/providers. We don't exactly do a -fantastic-
job of it. (I'm sure the real core developers would cry to read the tests)
but generally speaking it's a reasonable place to crib from as you get u
On Mon, Sep 2, 2013 at 1:07 PM, Dustin J. Mitchell wrote:
> On Mon, Sep 2, 2013 at 12:40 PM, Henrik Lindberg
> wrote:
> > How would you ensure this? The fact that it seems to work? Do you have
> > perfect test coverage? (The parser checks all code paths, not just the
> ones
> > that are executed
efore I start writing some beginner
provider/types documentation for the module team. MySQL has proven to be
an absolute nightmare to write these types for so I'm full of pain points
to touch on to make sure the rest of you have an easier time in the future.
--
Ashley Penney
ashley.pen...@pupp
On Wed, Aug 28, 2013 at 12:05 PM, Ryan Coleman wrote:
>
> For simplicity sake, why not keep the language version expression at the
> module level and not allow one class in a module to use R3 and a second
> class to use R6. This strikes me as complex without much benefit. The
> module level shoul
On Mon, Aug 26, 2013 at 5:04 PM, markus wrote:
>
>
> > > I think the system needs to change to eager loading of manifests
> > > (not applying them all, but at least loading them all).
>
> Eager loading all manifests (e.g. by a directory search) could change
> the semantics in unexpected ways, and
So uh, as you can see from the subject there's been a little bit of a gap
between the last email and this one. I got super sick and forgot to put it
together, so you have my apologies if you were paying attention!
Over the last two weeks we've continued to focus on the backlog of PRs as
well as w
My apologizes to all the readers for not getting this out on Friday. It
was 100F in my basement and it felt like I was melting, I completely forgot
in my rush to escape the house and survive until today.
Three weeks into working on modules and we're making steady progress.
Things have slowed dow
On Sat, Jul 13, 2013 at 6:16 AM, Alessandro Franceschi wrote:
> I insist on the question since I've not had answers previously:
> Any hope the redesign of the PuppetLabs modules will consider the
> suggested standards discussed here:
> https://github.com/stdmod/puppet-modules/blob/master/Paramete
On Fri, Jul 12, 2013 at 10:10 PM, James Turnbull wrote:
>
> If it was a huge change shouldn't it be semantically versioned and up'ed
> to 1.x.x?
>
Hopefully hunner will reply directly himself rather than me putting words
in his mouth, but I believe our intent was that the first 1.0.0 would have
a
Hello!
Now that we're two weeks in it's time for another update on what's been
going on in the module team. We focused on puppetlabs-ntp and
puppetlabs-firewall as our two primary modules, but also merged in fixes to
passenger, rabbitmq, mysql, apt, and apache.
As a result of this work we've rel
Hello!
Now that Puppetlabs has a module team we thought we should start trying to
keep the community informed as to what we're doing and why on earth we're
doing it. I wanted to put together a short update (I'm aiming to do these
every friday) as to where we stand.
This was our first week workin
On Tue, Jul 2, 2013 at 12:47 AM, Simon Marechal wrote:
>
> I don't think these tools cover the basic testing needs, at least not
> mine. I only knew about the first, which is mainly useful to write
> standalone module specific tests, and is pretty slow. The second seems to
> require a puppet maste
On Thu, Jun 27, 2013 at 10:43 AM, Henrik Lindberg <
henrik.lindb...@cloudsmith.com> wrote:
>
>> Then you will probably like the proposal in ARM-8 that allows mapping
> the parameters of one type onto another. This was added to support exactly
> the case you describe; i.e. binding the parameters f
On Wed, Jun 26, 2013 at 6:57 AM, Erik Dalén wrote:
>
> A big +1 from me for having the feature. I've needed it a couple of times,
> and the easiest workaround when not having it is simply data duplication,
> which is really bad.
> In some cases I've worked around that data duplication using more c
On Fri, May 17, 2013 at 4:08 PM, Daniel Pittman wrote:
> I think the best solution would be to change the `template` function
> to select the first entry, rather than concatenate, and allow users to
> manually concatenate multiple `template` calls if they wanted it.
>
> I understand the attraction
On Thu, Apr 4, 2013 at 5:15 PM, Andy Parker wrote:
>
> Interested to hear about that reboot plan you mentioned in the other mail
>> as I guess this might be connected :)
>>
>>
> Are you asking about the support for rebooting? I don't think that is
> connected to this :)
>
I suspect he was thinki
On Thu, Oct 18, 2012 at 1:33 PM, Luke Kanies wrote:
> I agree with all of this. We've done a great job of building a
> self-sustaining user community, but we clearly have not delivered that on the
> development side.
>
> There are outside contributors with commit access, but not many, and AFAI
On Wed, Oct 17, 2012 at 10:14 PM, Miguel Di Ciurcio Filho
wrote:
> b) Make Puppet a real community project, where the "Puppet Community
> Project" (maybe a different name) is the upstream of Puppet Enterprise
> or other PuppetLabs projects. Like Citrix did to Xen and CloudStack,
> Red Hat does wi
On Tue, Jul 31, 2012 at 7:42 PM, Andy Parker wrote:
> Would that make it easier for you? The change on our end would be that
> github pull requests would just be a staging area for code and we often
> wouldn't use it for merging (which is not a big loss).
I think that might be a positive change
Hi everyone,
I've been looking at the facter code that handles networking facts in
2.x and trying to refactor it to be more useful in various
circumstances. I've ran into issues with ipv4/ipv6 as well what to
represent and when and thought I'd see what others in the community
think. Part of this
On Sat, Jul 28, 2012 at 5:04 PM, Ken Dreyer wrote:
> I recently opened my first pull request [1], against master. After
> re-reading CONTRIBUTORS.md I see that Puppet prefers to merge bug
> fixes into the earliest branch first (eg 2.6.x or 2.7.x), rather than
> master first. I thought this might b
You need a Puppetlabs amsterdam office, the only sensible solution. ;)
On Tue, Jul 24, 2012 at 5:17 PM, Andrew Parker wrote:
> Yeah, that would be a problem. :( I'm open for suggestions as to what we
> could do. I think a problem is that even 8 in the morning for us is still 4
> in the afternoo
I love the idea of that, so I just wanted to publically +1 it. I
think that would be a cool idea. Having specific time set aside
probably benefits everyone equally and it would be easy to hijack
#puppet-dev during that timeframe to discuss things. :)
On Tue, Jul 24, 2012 at 12:31 PM, Andrew Park
Personally I find lurking on #puppet and bugging an appropriate person
to be about your best bet. Puppetlabs should hire a "Director of Pull
Requests" to manage all the queues for their various repos. :)
On Mon, Jul 16, 2012 at 12:29 PM, Erik Dalén
wrote:
> Hi, I have some pull requests against
ice wrote:
> Thanks, that's helpful too. Out of curiosity, are you using modules for
> the msyql/pg stuff that you've copied above? Or is it something that you
> built up from scratch? If it's from scratch, can you provide some insight
> as to what was lacking fro
e only relevant for specific providers, and to some
> degree it feels to me like that lessens the luster of the unified type,
> because you might still end up with the same problem that you're describing
> where if you need to migrate from one provider to another, you may still be
> f
I would vote in favor of a single module with multiple providers. As
Puppet grows up and becomes more powerful I think this model is going to
become more common anyway - once you move beyond basic modules you start
relying on more and more functions and "real code". The pool of people who
are lik
My only question is: Does this really need Ruby 1.9? As a Redhat user I
firmly live years in the past, lumbered with ancient versions of everything
we use in our toolchain. The module appears to only support Ubuntu in the
first place but it doesn't look easily portable with the references to Rub
You guys are the best, quite the quick turn around! I'll be applying this
to our largest puppetmaster tomorrow and running a series of tests so I can
give you some feedback.
On Thu, May 10, 2012 at 2:44 PM, Nick Lewis wrote:
> On Thursday, May 10, 2012 at 10:30 AM, Ashley Penney wrote
On Thu, May 10, 2012 at 1:42 AM, Jeff Weiss wrote:
>
> Fourth, Peter, Émile, and Trevor (or anyone else experiencing the
> problem), would you be willing to be pre-release testers of improvements?
> Our ops team is seeing the problem too, but that's only a single real-world
> data point. We need
It's interesting this problem has come up because all of a sudden I'm
plagued
by incredibly slow config retrieval:
Changes:
Total: 2
Events:
Success: 2
Total: 2
Resources:
Changed: 2
Out of sync: 2
Total: 390
Skipped: 6
Time:
I've noticed that nobody else has replied to this but as one of the more
vocal people in the
original discussion I'd like to state that I love the idea of a vendor and
site module path and
think this is an ideal way to move these things out of the core. This
proposal is much less
scary than the pr
I think in this context he's talking about the ec2 API being the
'node', so to speak like how with the network-device you write to
devices that are not running puppet (switches, for example). The
actual EC2 instances would still run Puppet as normal. Maybe I
misunderstood what was being said but
I definitely want (and need) global require's, Being able to set a
bunch of Package{ require=> }'s in site.pp would be immensely helpful
for local configuration, and would allow me to generalise my modules
even more by keeping all my 'local oddities' in a couple of global
requires.
On Mon, Dec 15
I'm just posting in support of this because I'm tired of adding this in
manually and every single script provided by the system has included these!
On Wed, Jul 16, 2008 at 5:47 PM, Peter Meier <[EMAIL PROTECTED]> wrote:
>
> Hi
>
> > as far I see there have been a regression while refactoring the
I wanted to start a discussion on environments, based on the results of some
stuff me and Volcane have been trying. I spoke to lak about the default
puppet behaviour, and why I think it should be changed. I want to solicit
some opinions on if other people would agree with this.
The problem is th
I don't have a pointer, answer or RTFM, I just wanted to thank you for
tackling this one and I hope you get the answers you need. It was right on
the bottom of my 'todo' list, but realistically I'm never reaching that part
of the list! This is really useful feature.
Thanks,
On Fri, Jun 6, 2008 a
63 matches
Mail list logo
