puppet-dev@googlegroups.com
Fellow Humans! i would like solicit your expert knowledge in designing a type & provider for Apache Traffic Server's [storage.config](http://trafficserver.readthedocs.org/en/latest/reference/configuration/storage.config.en.html) The basic outline of my general idea, which i implemented with finch's Filemapper, and finch's help(!) can be found here: type: https://github.com/Brainsware/puppet-trafficserver/blob/types/lib/puppet/type/trafficserver_storage.rb provider baseclass: https://github.com/Brainsware/puppet-trafficserver/blob/types/lib/puppet/provider/trafficserver_storage.rb (literally, a class, this was finch's idea ;) provider for linux: https://github.com/Brainsware/puppet-trafficserver/blob/types/lib/puppet/provider/trafficserver_storage/udev_storage.rb (ignore it for now;) now the problem that i'm trying to solve is as follows: storage.config *drives* the configuration process: when it changes, *something* on the system changes too. this could either mean a * directory needs to be created and chowned to the correct user * udev|devfs entry needs to be made and udev needs to be reloaded the first case is easy and platform independent (i.e.: it works on all Unix platforms equally, and traffic server only runs on Unix, so it's fine ;) the second case however is more problematic as it means we need to keep two syntactically distinct files in sync. it also means that we need to verify, and possibly recreate that secondary file if *nothing* in the primary file at all has changed. now, from what i gather, a provider cannot be split on a line-by line basis, but maybe i'm wrong there. in my design above i integrated the directory case - as an if statement - into the base provider. Considering all the things i've learned about refactoring in the past three months, this strikes me now as a profoundly bad move ;) as for the second case, at least with filemapper, this is really hard to do: the udev/devfs files would have to be handled in ruby, rather than in filemapper, if i use inheritance. and so i'm stuck, and would like some advise on how to handle this properly. thank you very much in advance. -- o/~ i Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/122470397.139030.1417771731123.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] This is a trivial contribution.
Fellow Humans, Recently the puppetcla bot has been activated for most puppetlabs-modules. This has sparked a *lot* of controversies from people who just contribute the most trivial of fixes, * https://github.com/puppetlabs/puppetlabs-apache/pull/775 * https://github.com/puppetlabs/puppetlabs-java/pull/63 <<<< * https://github.com/puppetlabs/puppetlabs-postgresql/pull/448 Now, ignoring the understandable criticism that PRs should be merged faster, i think we need to have a discussion on what warrants a CLA signing. Speaking with my Apache Software Foundation hat on: we only ask people to sign a CLA who are committers - or in git terms, those with merge access. We entrust *them* to judge patches from third parties. We have done this since times immemorial. Before we had git. Before there *was* git. Before it was *this* easy to contribute a patch. It still is. Random drive-by contributions happen every day, some of them even through GitHub! At this point i'm kinda stuck for argumentation, from my perspective, and the expressed bewilderment of many contributors it seems silly we even have to bring this up at all. So long, -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/1251781699.678.1408453265551.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] stubbing our toes on a mysql test
Fellow humans, I've been working on MODULES-151, and pushed my work in progress to https://github.com/puppetlabs/puppetlabs-mysql/pull/548 this pr adds a mariadb provider to puppetlabs-mysql, boolean-confining it, based on a version-check (for >= 10.0.0-MariaDB), if so, it adds a feature for long username support. however, both me, and Hunnur have so far failed to make this sensibly testable. As you can see in the latest comments, I've tried stubbing out version_check() in the unit test for the type, and, apparently, I'm doing it wrong. Do I ignore this test in the type, and instead add it to the provider? Am I trying to attach it to the wrong object? In the wrong context? uhm.. yeah, I don't really know, so I'd really appreciate your input! -- bye i Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/1067198849.34321.1406830684081.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Module PR Triage Notes 2014-07-31
Fellow Humans, This week we triaged PRs for puppetlabs-firewal and briefly looked at puppetlabs-git and, once again, at puppetlabs-mysql (more in a next email). puppetlabs-firewall === merged: * #388 Add cbt protocol, to be able to mitigate some DDoS attacks discussed: * #387 Add missing set_mark in the ip6tables provider #387 * #394 (MODULES-450) Enable rule inversion #394 * #387 Add missing set_mark in the ip6tables provider * #348 add ipset support (closing in favour of #383) * #380 Apply firewall resources alphabetically -- this is a can of worms... closed. * #374 Fixed bug which arbitrarily limited iniface and outiface parameters -- this needs more input. * #356 RHEL has a separate services for IPv4 and IPv6 iptables -- must be made optional needs rebased: * #383 add ipset support * #381 Patch for Debian Jessie (testing) * #378 Added support for statistic module * #373 Revised Firewall Module README for review * #372 Add support for 'NOTRACK' action -- also, NOTRACK is obsolete... * #349 make extension parameter ordering easier to understand -- YES PLEASE! puppetlabs-git == merged: * #30 User Config -- also fixes #28 and #18 puppetlabs-mysql * #548 Add support for MariaDB > 10.0.0 - both Hunnur and me are admitting defeat: we have no idea how to test this properly. Like always, there's a Jira Triage every two weeks, I'm sure someone else will have taken notes for that one ;) So long, and thanks for all the <>< -- o/~ i Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/231702019.34303.1406830251452.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Module PR Triage Notes 2014-07-24
Fellow humans, This week we triaged PRs for puppetlabs-dhcp, puppetlabs-mysql, and bits of puppetlabs-rabbitmq puppetlabs-dhcp === #32 Remove deprecation warnings for templates and use of concat::setup #36 Add patches from foreman-dhcp * we have a release pending here. puppetlabs-mysql Merged: #545 Update mysqltuner.pl to version 1.3.0 #545 #517 Add Archlinux support (not officially supported) #547 Prevent ERROR 1008 in mysql_database provider (bonus! I merged this one yesterday:) closed: #474 enable removal of mysql::server::backup — closed, we won't support absent, because it's a pain #497 Ignore internal mysql databases when creating a backup (already fixed) #492 parameterize mysqld config_dir (implemented better[?] in #508) #537 Include mysql::server class (this will be fixed by decoupling mysql::db) #542 Adding CentOS rules (duplicate of #544) Needs rebase: #506 added spec test for username validation #405 run mysql_install_db if datadir is set annd mysql database is missing (I tried but gave up) #352 Add timeout parameter to increase for long time running sql imports (I tried but gave up) #440 Some mixup between usin PE and OSS and using puppet vs norm .box files. Comments: #462 Defined type for managing conf.d entries — this needs a redesign, as suggested. General: We've discussed how to close in on the mariadb support in https://tickets.puppetlabs.com/browse/MODULES-151 I'll be taking a look at this in the next couple of days. puppetlabs-rabbitmq === Actually, we didn't touch anything, because we're waiting for #192 This module still needs a https://github.com/puppetlabs/modulesync Tests = We're currently working on reducing acceptance tests. In the past we've been quite naïve in writing these. Basically we've been repeating alot of the unit tests by checking if a package is installed or a service is running. Since this is basic puppet functionality, we don't really need to cover that. The other thing that we also want to change is to simplify those tests so we only use the resources available on *all* platforms. The best example for this way forward is puppetlabs-postgresl: https://github.com/puppetlabs/puppetlabs-postgresql/tree/master/spec/acceptance We also discussed to make the Puppetlabs Modules Jenkins publicly accessible. This Jenkins server runs acceptance tests for all supported Operating Systems, how ever it only runs it on merge to master, not yet for all PRs. Baby steps ;) At least that way people can can see how tests are even run at all, and we get a better feel for a module's overal health. Next week we'll do a crawl through Jira again, so if you have any open issues, or any unopened issuese, get started: https://tickets.puppetlabs.com/browse/MODULES So long and thanks for all the <>< -- o/~ i Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/522390200.7250.1406231826197.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Speculative Syntax: Varargs & Matchers
perhaps a better way to summarize this issue is this:
define httpd::mod (
$ensure = 'enabled',
$instance = 'default',
$module = $title,
$package = undef,
) {
}
This definition of httpd::mod's interface is static.
it's a static map (Hash). If we pass any additional parameters
it'll blow up, and rightfully so.
What I wanted with this:
>
> define httpd::mod (
> $ensure = 'enabled',
> $instance = 'default',
> $module = $title,
> $package = undef,
> $* # all others
> ) {
(or whatever the syntax) was a dynamic interface. A way to
programmatically define that map.
(came up in a discussion with daff/antaflos today, so I thought
I'd like to clarify my now seemingly more clear thoughts on that ;)
~bye, o/~
-- i
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.ga...@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
--
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/8889271.75730.1404505755998.JavaMail.zimbra%40brainsware.org.
For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Mapping $system to puppet
Hi folks, last week I proposed we add a function to puppetlabs-apache which converts puppet booleans to httpd's On/Off. https://github.com/puppetlabs/puppetlabs-apache/pull/782 of course that has no straight-forward approach, because in some cases httpd will allow boolean values, as well as strings https://httpd.apache.org/docs/current/mod/core.html#acceptpathinfo https://httpd.apache.org/docs/current/mod/core.html#usecanonicalname to name only a few. My first throw of naming the function bool2httpd(), allowing it to map /on/i, /true/i, true, 1, => 'On' /off/i, /false/i, false, 0, nil, :undef => 'Off' and otherwise, simply returning whatever we got lead to the effect of having a *bad* name. Looking at it now, the solution to this seems simple: Rename the function to normalise_bool(), allow it an optional parameter (a regex?) that validates the outliers. But what about the general problem of mapping a sub-system's directives and the values they can take to puppet-friendly names, and validating their types and ranges? It seems a lot of energy is expended in our manifests, templates, or types/providers to that task. Especially when a system has a rich set of directives, this can become very cumbersome. If you have similar pains, I invite you to share your stories here. Maybe someone can think of a solution for your problem, or maybe we can even find a more general solution. So long, -- i Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/440824986.75047.1404432705369.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Module PR Triage Notes 2014-07-03
Hi folks, This week we triaged PRs for puppetlabs-apt, puppetlabs-apache, puppetlabs-vcsrepo puppetlabs-apt: * Most PRs here are in limbo because they are still failing/missing tests. * apenny merged 1.5.x * it's time for a new release here. puppetlabs-apache Merged: - Add validate and lint tasks to travis script #788 - Allow ssl_certs_dir to be unset. #787 - Add param to ctrl purging of vhost dir #786 - Update tests for strict variable testing #783 Reviewed/Commented on: - Add deflate params: types, notes #785 - function to munge booleans to httpd's On/Off #782 * this sparked a bit of a discussion, which I'll follow up in another email. - Changes $alias to $fcgi_alias to prevent Puppet complaining about using that name #781 Release: - We should make a new release, it's about time. puppetlabs-vcsrepo Merged: - (MODULES-1014) Add rspec for noop mode #189 Discussed: - This module needs a https://github.com/puppetlabs/modulesync General: most Puppetlabs modules' [Report Issues] links were still pointing to github/issues. This should be fixed now. If we're missing anything, please point us to it! (Unfortunately the forge is, as of yet, unable to crawl Jira to retrieve the issues & display them) We also did a crawl through the open tickets, closing a bunch. If you're looking for places to help, cleaning up Jira bugs, or providing patches for them is a great place to start: https://tickets.puppetlabs.com/browse/MODULES -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/1811591346.74965.1404429783113.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Speculative Syntax: Varargs & Matchers
Henry, Andy, that all sounds very promising, and exciting! I'm very much looking forward for that. -- o/~ i Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/568369049.40513.1402571681739.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Speculative Syntax: Varargs & Matchers
Hi folks,
over the last couple of days I've been dabbling with the design
for a new module for Apache httpd: we use our own package & module
currently, which allows for multi-instance configurations, but are
trying to shift towards "standard" Ubuntu 2.4 package (I created a
ppa with a current version:
https://launchpad.net/~apache-helpdesk/+archive/httpd-ppa )
I've been hitting a snag in the design, because httpd and many of
its modules are complex beasts, and I don't want to try and foresee every
single directive someone might want to use in templates / (defined) type / class
but rather have some form of matcher. Since most of the directives follow
simple patterns, I'd like to handle those, and reject everything else -
rather than handling everything explicitly as is the case now.
For a defined type, or a class, we could introduce the special variables
`$_` and `$*` (I'm not happy with those names. They are short, that's nice
but otherwise, they are too Perlesque, and not very speaking)
define httpd::mod (
$ensure = 'enabled',
$instance = 'default',
$* # all others
) {
validate_re($ensure, 'enabled|disabled')
Match {
/_enabled$/ => { validate_bool($_) }
/_path$/=> { validate_absolute_path($_) }
/s$/=> { validate_array($_) }
/_size$/=> { validate_number($_) }
default => { fail("${name} We really don't know what to make of
this directive") }
}
}
alternatively, we could match the front part:
define httpd::directory (
$ensure = 'present',
$instance = 'default',
$*
) {
# …
Match {
/(proxy|ssl|..)_/ => { httpd::mod { $1: ensure => $ensure, instance =>
$instance, $* }
}
}
This is kind of the basic idea, and it's lacking a good way to transform those
matches into actual variables we can access, but I hope you get the basic idea.
The main reason I wish this was supported syntax, is that a
$catch_all_other_settings
hash generally translates poorly through all the layers of
yaml -> ruby -> puppet dsl -> actual config. The chances for very specific
failures
are very high simply because of the amount of layers, each of which can
introduce
their own implementation leak.
Highly welcome your feedback!
-- o/~ i
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.ga...@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
--
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/306231088.39368.1402493220564.JavaMail.zimbra%40brainsware.org.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Module triage meeting
- Original Message - > Hi folks, > here's a short writeup of what we discussed. > Meta > * package needs to be a resource that can be duplicate > Trusty LTS is out (or very soon), brace yourselves. More meta talk I forgot to write down: we are very much looking forward for hooks between GitHub and Jira to have those two better connected links in commits will be referenced in Jira, but it would be extremely useful if [MODULES-\d+] tags in comments were converted on GitHub's side also. > There is an (internal) ticket for creating a Central Repo to pull general > module changes > * .gitignore > * .gitattributes > * Gemfile > * Rakefile > * CONTRIBUTING.md > NodeJS > * most tests are failing due to Travis hickup. > * no PR comes with tests :( > We've closed all the PRs, which is the best way to solve this. - ash > Passenger > * merging compilation timeout, but we'd rather ash publish his installation > through brightbox/phusion repos. > we don't like when you add gcc, make and other things as package deps. (see > meta talk ;) > "As it stands, it's a horrible module. We want to get rid of it.…" > PostgreSQL > * We are not backporting features. > * Port change looks very complete, but needs a squash, (ask back why the > inherit stuff slipped in) > * PostgreSQL tests take a *long* time, we should check if it's > necessary to uninstall/purge everything between test runs > RabbitMQ > * needs your ♥ > * Tests need fixing (because apt ;) > * Should be easy to fix > Registry > * Travis is reworking the tests right now > So long, o/~ > i > - Original Message - > > 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 blasted 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...@puppetlabs.com > > > Module Engineer > > > Join us at PuppetConf 2014 , September 23-24 in San Francisco - > > http://puppetconf.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/CAC9eg%2B%3DpTz2c3ymkQp%3D0FbExYupUKk9mMhofF4FrQWOnPaSNTQ%40mail.gmail.com > > . > > > For more options, visit https://groups.google.com/d/optout . > > -- > Igor Galić > Tel: +43 (0) 664 886 22 883 > Mail: i.ga...@brainsware.org > URL: http://brainsware.org/ > GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/1321220055.20422.1397757994168.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Module triage meeting
Hi folks, here's a short writeup of what we discussed. Meta * package needs to be a resource that can be duplicate Trusty LTS is out (or very soon), brace yourselves. There is an (internal) ticket for creating a Central Repo to pull general module changes * .gitignore * .gitattributes * Gemfile * Rakefile * CONTRIBUTING.md NodeJS * most tests are failing due to Travis hickup. * no PR comes with tests :( We've closed all the PRs, which is the best way to solve this. - ash Passenger * merging compilation timeout, but we'd rather ash publish his installation through brightbox/phusion repos. we don't like when you add gcc, make and other things as package deps. (see meta talk ;) "As it stands, it's a horrible module. We want to get rid of it.…" PostgreSQL * We are not backporting features. * Port change looks very complete, but needs a squash, (ask back why the inherit stuff slipped in) * PostgreSQL tests take a *long* time, we should check if it's necessary to uninstall/purge everything between test runs RabbitMQ * needs your ♥ * Tests need fixing (because apt ;) * Should be easy to fix Registry * Travis is reworking the tests right now So long, o/~ i - Original Message - > 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 blasted 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...@puppetlabs.com > Module Engineer > Join us at PuppetConf 2014 , September 23-24 in San Francisco - > http://puppetconf.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/CAC9eg%2B%3DpTz2c3ymkQp%3D0FbExYupUKk9mMhofF4FrQWOnPaSNTQ%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout . -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/1349541795.20401.1397757834984.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] ROADMAP/REDESIGN: Puppetlabs-mysql
> To bring this back to mysql I guess I'd see: > mysql-provider > mysql-server > mysql-server-accounts > mysql-server-backup > mysql-client Do we have a precedent for these kinds of patterns? -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/362570001.1774.1394138948628.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet-dev] [PROPOSAL] Bug Triage for Modules
Hi folks, I would like to propose a bug triage for the puppet modules team. At least for the time being, during the transition to beaker I would also like to see the QA team included in these meetings. Many of our modules are in rough shape: They are plagued with incomplete or wrong documentation and incomplete tests. I think a weekly get-together would greatly accelerate our progress or at least allow us to focus on key issues. Moreover, it would allow us to more evenly distribute the know-how about module internals and the workings of the test suites. Being from Europe, I especially want to see a more even distribution across time-zones. Currently it's heavily focused in PST. I highly welcome your input and your suggestions for a time. A good place seems to be the same as that where we currently hold puppet (hiera+facter+stdlib) bug triages: Google Hangout. So long, -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641 -- 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/1792340092.99980.1391021937288.JavaMail.zimbra%40brainsware.org. For more options, visit https://groups.google.com/groups/opt_out.
