[Puppet Users] Re: Patterns for building configs using hashes & arrays
I like this approach too :) I am just wondering how you build the hash or
array up since variables are immutable and cannot be reassigned. For
example, I want to do the below however I can't.
define duplicity::job(
$directories= [],
$gpg_key_id = undef,
$print_stats= false,
$flags = [],
$options= {},
$env_vars = {},
$target_url = undef,
$full_if_older_than = '7D',
$remove_older_than = false,
$hour = '1',
$minute = '0',
$pre_commands = [],
$post_commands = [],
$shell = '/bin/bash'
) {
if $gpg_key_id == undef {
$flags += ['--no-encryption']
}
else {
$options['--encrypt-id'] = $gpg_key_id
}
if ! $print_stats {
$flags += ['--no-print-statistics']
}
}
On Monday, May 26, 2014 2:31:55 AM UTC-4, William Leese wrote:
>
> I've always found that when creating modules I'd focus on creating class
> parameters out of the most important configuration options of whatever I'm
> managing. After that I'd add a similar approach as yours for "everything
> else". This is a good approach because your module becomes usable for all
> the use cases you're not applying but other people might want.
>
> Nothing is more frustrating than finding a great module, but not being
> able to use it straight away because it is missing that vital configuration
> parameter!
>
> So in this light, I'd say your approach is good. It might be better if you
> single out the most commonly used parameters and expose them directly just
> for clarity, but it might not always provide usability/readability benefits.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/9bc25e71-4fb3-4223-8b93-d27c141cc6fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Patterns for building configs using hashes & arrays
I am new to puppet and decided to really get my feet wet by writing a duplicity module (https://github.com/JCotton1123/puppet-duplicity.git). I am struggling to deal with the fact that variables are immutable and cannot be reassigned (within the same scope). This has become a real issue while trying to dynamically build hashes and arrays that reflect the options and flags that are passed to duplicity. I opted for this approach b/c it makes composition easier and it results in a very clean template definition. For example, ``` <%- @_flags.each do |flag| -%> <%= flag -%> \ <%- end -%> <%- @_options.each do |key,val| -%> <%= key -%> <%= val -%> \ <%- end -%> ``` As opposed to checking for the existence of a dozen different variables and outputting their values if they have a "good" value. How do others work around this issue? I am looking at this the wrong way? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fcca193a-8ceb-4dd3-a7bc-c653c38a7734%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Craig Dunn's Roles/Profiles/Components & Conflicts
>
> But that's just it: you don't *want* to assign data based (strictly) on
> profile. Or if you do, then understand that it is inherently inconsistent
> with composable profiles. Since the node characteristic that determines
> the combination of profiles in use is its role, it is on that basis that
> you want to assign data. Indeed, that's what you already said with respect
> to apache::keepalive. Note that with hiera, that doesn't mean you must
> avoid assigning data based on profile; it just means you must (also) be
> able to assign data based on role, with the role-based data having higher
> priority.
I understand this better now however the problem we were really struggling
with was how to assign variables based on role or profile. Ie, how do you
incorporate the the role or profile into the hierarchy so a variable only
applies to nodes that have a particular role or profile. Your first
suggestion is good although thats not how we're currently assigning classes.
On Wednesday, May 21, 2014 10:03:33 AM UTC-4, jcbollinger wrote:
>
>
>
> On Tuesday, May 20, 2014 12:54:15 PM UTC-5, Jesse Cotton wrote:
>>
>>
>> Understood. However without creating a custom fact, I am not aware of a
>> way to say 'apache::keepalive = 1' only applies when a node has the profile
>> 'profile::apache_phpfpm'.
>>
>>
>
> There is no good way to say that to Puppet. It reflects a non-idiomatic
> thought process. Moreover, it's unlikely to be what you really want to say
> -- you might in the future want other nodes to have keepalive enabled,
> too. You should instead consider how to assign apache::keepalive: 1 to
> exactly those nodes that get profile::apache_phpfpm.
>
> There are at least two ways you could approach that problem:
>
>1. If you are using hiera to assign roles and/or profiles to nodes
>then it should be entirely straightforward to override apache::keepalive
> at
>the same hierarchy level where you assign profile::apache_phpfpm.
>2. You can perform a resource parameter override in
>profile::apache_phpfpm.
>
> If it is viable, the former is preferable to the latter. A resource
> parameter override is a bit messy because it relies on implementation
> details of module 'apache'. (It does not work to override class
> parameters; you must instead override one or more parameters of a bona fide
> resource, which can be of either defined or native type.)
>
>
>
>>
>> And the foregoing is based on using only the built-in YAML back end.
>>> Hiera supports pluggable back ends, usable together or separately. A
>>> custom back end can employ whatever lookup or computation you want to serve
>>> whichever data you choose.
>>>
>>>
>> We're really trying to avoid this.
>>
>
>
> I don't blame you. A custom back-end should certainly be a last resort.
> As you keep that alternative in reserve, however, don't forget that such a
> custom component does not necessarily need to replace the YAML back-end;
> hiera can use two (or more) at the same time.
>
>
>
>>
>>>> class profile::drupal (
>>>> $apache_listen = ['80'],
>>>> $apache_name_virtual_hosts = ['*:80'],
>>>> $apache_modules = ['fastcgi'],
>>>> $apache_fastcgi_servers = {
>>>> 'www' => {
>>>> host => '127.0.0.1:9000',
>>>> faux_path => '/var/www/php.fcgi',
>>>> alias => '/php.fcgi',
>>>> file_type => 'application/x-httpd-php'
>>>> }
>>>> },
>>>> $phpfpm_pools = {
>>>> 'www' => {
>>>> listen => '127.0.0.1:9000',
>>>> user => 'apache',
>>>> pm_max_requests => 500,
>>>> catch_workers_output => 'no',
>>>> php_admin_value => {},
>>>> php_value => {}
>>>> }
>>>> },
>>>> $php_modules = [],
>>>> $firewall_rules = {},
>>>> $backup_jobs = {},
>>>> $cron_jobs = {}
>>>> ) {
>>>>
>>>> include ::apache
>>>> ::apache::listen { $apache_listen: }
>>>> ::apache::namevirtualhost { $apache_name_virtual_hosts: }
>>>> ::apache::mod { $apache_modules: }
>>>> create_resources(::apache::fastcgi::server, $apache_fastcgi_servers)
>>>>
>>>>
[Puppet Users] Re: Craig Dunn's Roles/Profiles/Components & Conflicts
>
>
>>> We're aware of most of this and agree with most of this. However when
>> you always call include, you lose the ability to say a particular hiera
>> variable is attached to the profile. For example
>>
>> If you define:
>>
>> class profile::apache_phpfpm {
>> include ::apache
>> }
>>
>> with the following in hiera:
>>
>> apache::keepalive = 1
>>
>> keepalive = 1 applies anywhere apache is included
>>
>> vs
>>
>> class profile::apache_phpfpm (
>> $keepalive = 1
>> ) {
>> class { ::apache:
>> keepalive => $keepalive
>> }
>> }
>>
>> profile::apache_phpfpm::keepalive = 1
>>
>> So with the later you can build a somewhat self-contained profile. With
>> the former you have to set variables "globally" or on a node.
>>
>
>
> That is what your data hierarchy is for. Hiera does not limit you to only
> global and per-node data. You can define as many hierarchy levels as you
> need, each grouping your nodes in its own way (though it usually makes the
> most sense for the groups at each level to be subsets of the groups at the
> next lower level).
>
>
Understood. However without creating a custom fact, I am not aware of a way
to say 'apache::keepalive = 1' only applies when a node has the profile
'profile::apache_phpfpm'.
And the foregoing is based on using only the built-in YAML back end. Hiera
> supports pluggable back ends, usable together or separately. A custom back
> end can employ whatever lookup or computation you want to serve whichever
> data you choose.
>
>
We're really trying to avoid this.
>
>
>>
>>
>>
>>> It is thus possible to find and/or write composable classes and modules
>>> for managing the components you want. As David Schmitt observes,
>>> composability is not automatic, but I don't see why your particular case of
>>> an apache-based PHP app server with firewall rules and a specific
>>> collection of PHP and apache modules should present any special problem.
>>>
>>> Thus, the answer to your question is "neither." You build a drupal
>>> profile, and a wordpress profile, etc., and you use them all together.
>>>
>>>
>> So below is an example for Drupal. It could literally be cloned for
>> Wordpress and Joomla. Unfortunately, b/c of the class declarations, it is
>> not composable.
>>
>> class profile::drupal (
>> $apache_listen = ['80'],
>> $apache_name_virtual_hosts = ['*:80'],
>> $apache_modules = ['fastcgi'],
>> $apache_fastcgi_servers = {
>> 'www' => {
>> host => '127.0.0.1:9000',
>> faux_path => '/var/www/php.fcgi',
>> alias => '/php.fcgi',
>> file_type => 'application/x-httpd-php'
>> }
>> },
>> $phpfpm_pools = {
>> 'www' => {
>> listen => '127.0.0.1:9000',
>> user => 'apache',
>> pm_max_requests => 500,
>> catch_workers_output => 'no',
>> php_admin_value => {},
>> php_value => {}
>> }
>> },
>> $php_modules = [],
>> $firewall_rules = {},
>> $backup_jobs = {},
>> $cron_jobs = {}
>> ) {
>>
>> include ::apache
>> ::apache::listen { $apache_listen: }
>> ::apache::namevirtualhost { $apache_name_virtual_hosts: }
>> ::apache::mod { $apache_modules: }
>> create_resources(::apache::fastcgi::server, $apache_fastcgi_servers)
>>
>> include ::php::fpm::daemon
>> create_resources(::php::fpm::conf, $phpfpm_pools)
>> ::php::module { $php_modules: } ~> Service['php-fpm']
>>
>> # So the apache user is created before
>> # php-fpm starts
>> Class['::apache'] -> Class['::php::fpm::daemon']
>>
>> create_resources(firewall, $firewall_rules)
>> create_resources(::duplicity::job, $backup_jobs)
>> create_resources(::cron::job, $cron_jobs)
>> }
>>
>>
>
>
> Either you're missing something or I am. I see nothing in that class that
> would inherently preclude it being composed. In particular, the two class
> declarations it contains both use 'include', not the resource-like class
> declaration syntax. If there is a barrier to composition it would be
> related to composition with another class that declares some of the same
> resources. That problem has a solution, however: factor out the
> multiply-declared resources into their own class or classes, which the
> then-composable classes declare instead of declaring the resources directly.
>
>
Duplicate declaration: Apache::Listen[80] is already declared in file ...
Yes, the class could be broken into separate classes but this only exacerbates
the issue of assigning variables based on the profile.
How are others constructing their hierarchies when using the Role & Profile
pattern? Are you assigning variables based on a nodes role or profiles? If
so, how? Custom facts, parameterized classes as we've done in the example
above?
> John
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discus
[Puppet Users] Re: Craig Dunn's Roles/Profiles/Components & Conflicts
Perhaps I am overlooking something. How would you construct the hierarchy
so you could set apache::keepalive for this profile?
class profile::apache_phpfpm {
include ::apache
}
You could do global variables, but you couldn't one set the hierarchy to
> the profile level? Thus you isolate variables in preference to the
> profile, rather than a global mismash. Stick with parametrization for now
> if this works, refactor later after getting it working, as you'll have a
> functional base state.
>
>
We're aware of most of this and agree with most of this. However when you
>> always call include, you lose the ability to say a particular hiera
>> variable is attached to the profile. For example
>>
>> If you define:
>>
>> class profile::apache_phpfpm {
>> include ::apache
>> }
>>
>> with the following in hiera:
>>
>> apache::keepalive = 1
>>
>> keepalive = 1 applies anywhere apache is included
>>
>> vs
>>
>> class profile::apache_phpfpm (
>> $keepalive = 1
>> ) {
>> class { ::apache:
>> keepalive => $keepalive
>> }
>> }
>>
>> profile::apache_phpfpm::keepalive = 1
>>
>>
> I am not sure about this... Personally, I get scared of having too many
> sub-classes beyond install.pp, config.pp, service.pp, etc. It might make
> those files verbose, but then it is easier to contain and debug.
> Afterwards, parts into separate pieces, if this helps.
>
> Is cron a separate class? Personally, I put my bottom level modules into
> their product role, which may require cron functionality. I avoid crafting
> classes based on their functionality, as this would be the same as having a
> class called package that accepts an array packages to be installed. It
> gets hard to identify what is involved in installing a product or
> scheduling cleanup tasks for the same product; the code to implement a
> particular product gets scattered across many files, rather than
> self-contained in one module.
>
>
I am not sure I understand what you're suggesting here. The point of the
create_resources calls at the very bottom is so we can attach backup jobs,
cron jobs, firewall rules to the profile. You seem to be suggesting we
should assign these at the role level. Is that correct? I see valid reasons
for doing it either way but experience may dictate one is better then the
other.
Yes, apache, php, cron, duplicity, and firewall are all separate classes.
> So below is an example for Drupal. It could literally be cloned for
>> Wordpress and Joomla. Unfortunately, b/c of the class declarations, it is
>> not composable.
>>
>> class profile::drupal (
>> $apache_listen = ['80'],
>> $apache_name_virtual_hosts = ['*:80'],
>> $apache_modules = ['fastcgi'],
>> $apache_fastcgi_servers = {
>> 'www' => {
>> host => '127.0.0.1:9000',
>> faux_path => '/var/www/php.fcgi',
>> alias => '/php.fcgi',
>> file_type => 'application/x-httpd-php'
>> }
>> },
>> $phpfpm_pools = {
>> 'www' => {
>> listen => '127.0.0.1:9000',
>> user => 'apache',
>> pm_max_requests => 500,
>> catch_workers_output => 'no',
>> php_admin_value => {},
>> php_value => {}
>> }
>> },
>> $php_modules = [],
>> $firewall_rules = {},
>> $backup_jobs = {},
>> $cron_jobs = {}
>> ) {
>>
>> include ::apache
>> ::apache::listen { $apache_listen: }
>> ::apache::namevirtualhost { $apache_name_virtual_hosts: }
>> ::apache::mod { $apache_modules: }
>> create_resources(::apache::fastcgi::server, $apache_fastcgi_servers)
>>
>> include ::php::fpm::daemon
>> create_resources(::php::fpm::conf, $phpfpm_pools)
>> ::php::module { $php_modules: } ~> Service['php-fpm']
>>
>> # So the apache user is created before
>> # php-fpm starts
>> Class['::apache'] -> Class['::php::fpm::daemon']
>>
>> create_resources(firewall, $firewall_rules)
>> create_resources(::duplicity::job, $backup_jobs)
>> create_resources(::cron::job, $cron_jobs)
>> }
>>
>>
>>>
>>> John
>>>
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/d499acf3-d7d7-401f-8692-4d9c44b02e6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Craig Dunn's Roles/Profiles/Components & Conflicts
On Monday, May 19, 2014 10:18:11 AM UTC-4, jcbollinger wrote:
>
>
>
> On Friday, May 16, 2014 10:55:35 AM UTC-5, Jesse Cotton wrote:
>>
>> I work with Matt and am filling in for him since I posed this question to
>> him originally.
>>
>> Our confusion really lies around how you layout profiles for a
>> multi-function box. For example, suppose you have a role, "CMS App Server"
>> that will host various CMS like Wordpress, Drupal, and others. They are all
>> built on top of the same technologies, Apache, PHP, and MySQL. I don't
>> believe you can build a separate profile for each CMS b/c they will
>> conflict (at least within Puppet). Each will require a certain set of php
>> modules and settings, apache modules and settings, etc. So do you build a
>> single profile like profile::wordpress_drupal_cms3_cm4 or do you build a
>> profile::apachefpm profile? The later seems more logical to me however you
>> lose the ability to define profile specific hiera variables b/c
>> profile::apachefpm is generic.
>>
>>
>
> You can declare the same class multiple times, provided that you use the
> 'include' function or its cousins to do so. That is a tremendously useful
> technique for managing configurations where multiple facilities share
> requirements on some of the same core resources. Using 'include' instead
> of resource-like class declarations means you must feed data to your
> classes via hiera instead of via your manifests, but separating your data
> from your manifests is good practice anyway. That's what Christopher Wood
> was pointing you toward, and it is good advice.
>
>
We're aware of most of this and agree with most of this. However when you
always call include, you lose the ability to say a particular hiera
variable is attached to the profile. For example
If you define:
class profile::apache_phpfpm {
include ::apache
}
with the following in hiera:
apache::keepalive = 1
keepalive = 1 applies anywhere apache is included
vs
class profile::apache_phpfpm (
$keepalive = 1
) {
class { ::apache:
keepalive => $keepalive
}
}
profile::apache_phpfpm::keepalive = 1
So with the later you can build a somewhat self-contained profile. With the
former you have to set variables "globally" or on a node.
> It is thus possible to find and/or write composable classes and modules
> for managing the components you want. As David Schmitt observes,
> composability is not automatic, but I don't see why your particular case of
> an apache-based PHP app server with firewall rules and a specific
> collection of PHP and apache modules should present any special problem.
>
> Thus, the answer to your question is "neither." You build a drupal
> profile, and a wordpress profile, etc., and you use them all together.
>
>
So below is an example for Drupal. It could literally be cloned for
Wordpress and Joomla. Unfortunately, b/c of the class declarations, it is
not composable.
class profile::drupal (
$apache_listen = ['80'],
$apache_name_virtual_hosts = ['*:80'],
$apache_modules = ['fastcgi'],
$apache_fastcgi_servers = {
'www' => {
host => '127.0.0.1:9000',
faux_path => '/var/www/php.fcgi',
alias => '/php.fcgi',
file_type => 'application/x-httpd-php'
}
},
$phpfpm_pools = {
'www' => {
listen => '127.0.0.1:9000',
user => 'apache',
pm_max_requests => 500,
catch_workers_output => 'no',
php_admin_value => {},
php_value => {}
}
},
$php_modules = [],
$firewall_rules = {},
$backup_jobs = {},
$cron_jobs = {}
) {
include ::apache
::apache::listen { $apache_listen: }
::apache::namevirtualhost { $apache_name_virtual_hosts: }
::apache::mod { $apache_modules: }
create_resources(::apache::fastcgi::server, $apache_fastcgi_servers)
include ::php::fpm::daemon
create_resources(::php::fpm::conf, $phpfpm_pools)
::php::module { $php_modules: } ~> Service['php-fpm']
# So the apache user is created before
# php-fpm starts
Class['::apache'] -> Class['::php::fpm::daemon']
create_resources(firewall, $firewall_rules)
create_resources(::duplicity::job, $backup_jobs)
create_resources(::cron::job, $cron_jobs)
}
>
> John
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/6a4218c6-fb00-4434-aa56-56de3fb33eff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Craig Dunn's Roles/Profiles/Components & Conflicts
Yes it is feasible :) So really the server is just a PHP app server. What
makes it useable for all of the CMSs is that the correct set of apache and
php modules are installed, and it has the correct firewall rules, cron jobs
and backup jobs configured. With this in mind, my inclination is to build a
cms_app_server profile but that seems more like a role then a profile.
On Friday, May 16, 2014 3:08:00 PM UTC-4, Joaquin Menchaca wrote:
>
> Hello: This might be a dumb question, but can you build a system manually
> with the various CMSes? Are there a cross-set of technologies (Apache,
> PHP, MySQL) that will work on all CMSes in your organization? I would
> think in terms in how you would build these systems manually w/o puppet in
> some organized way, then see how this can fit into puppet. If you can
> build some reference platform that can host some or all of these, then you
> have your basic profile for that wonder-web-box system.
>
> Complexity might come in when you start separating, such as putting php in
> it's own module and apache in another, then sequencing them in profile.
> You can use augues to scissor in php specific configurations (or
> alternatively creative erb ruby code to other configurations). This is
> what I do for a nginx + php-fm configuration.
>
> class profile::webserver { class { "nginx": } -> class { "php": } }
>
>
> On Friday, May 16, 2014 8:55:35 AM UTC-7, Jesse Cotton wrote:
>>
>> I work with Matt and am filling in for him since I posed this question to
>> him originally.
>>
>> Our confusion really lies around how you layout profiles for a
>> multi-function box. For example, suppose you have a role, "CMS App Server"
>> that will host various CMS like Wordpress, Drupal, and others. They are all
>> built on top of the same technologies, Apache, PHP, and MySQL. I don't
>> believe you can build a separate profile for each CMS b/c they will
>> conflict (at least within Puppet). Each will require a certain set of php
>> modules and settings, apache modules and settings, etc. So do you build a
>> single profile like profile::wordpress_drupal_cms3_cm4 or do you build a
>> profile::apachefpm profile? The later seems more logical to me however you
>> lose the ability to define profile specific hiera variables b/c
>> profile::apachefpm is generic.
>>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/be9a1775-2d62-49f2-8b25-ae072729c059%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Craig Dunn's Roles/Profiles/Components & Conflicts
I work with Matt and am filling in for him since I posed this question to him originally. Our confusion really lies around how you layout profiles for a multi-function box. For example, suppose you have a role, "CMS App Server" that will host various CMS like Wordpress, Drupal, and others. They are all built on top of the same technologies, Apache, PHP, and MySQL. I don't believe you can build a separate profile for each CMS b/c they will conflict (at least within Puppet). Each will require a certain set of php modules and settings, apache modules and settings, etc. So do you build a single profile like profile::wordpress_drupal_cms3_cm4 or do you build a profile::apachefpm profile? The later seems more logical to me however you lose the ability to define profile specific hiera variables b/c profile::apachefpm is generic. On Thursday, May 15, 2014 1:22:02 AM UTC-4, mjus...@gmail.com wrote: > > Hi all, > > We use the roles/profiles/components model originally suggested by Craig > Dunn fairly heavily. In our case: > > >- The role is a business name, like "Application X App Server" >- The profile is the technical name, like "Base Components" or >"Webserver" >- The components are either wrapper classes around modules or modules >themselves, like "PHP" or "Apache". > > For the most part, this works well. We can have, for example: > > >- MyFace Application Server > - Base Components > - SSSD > - Sudo > - NTP > - PHP Webserver > - PHP > - Apache > - PHP-FPM > - Memcache > > However, we're running into trouble how to handle the situation where you're > running a box with multiple functions... for example, WordPress and Drupal. > In that case, how do you handle configuration conflicts? On the surface, > it seems like we would create a more generic profile like "PHP Webserver" > (like I did in the above example). If I do this, however, I lose the > ability to define profile specific variables such as firewall rules, cron > jobs, etc. > > Any thoughts on this? > > Best, > > Matt > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/457a1f16-7d8f-4bad-9d93-1f666127fb89%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
