Re: [openstack-dev] [puppet] Parameters possible default value
Hello,
Few weeks ago the patches needed for us to have a cleaner parameters default
management way of doing things have been merged [1].
After that each module have been updated so it could rely on this new
feature.
All but puppet-neutron[3] and puppet-glance[4] have their patch merged.
Following on this effort, here is the first review to try to converge to
what
we expected : https://review.openstack.org/#/c/221005/
Cinder has been picked as the Canary module, if it can make it there it can
make it everywhere :)
If you have any feedback, please provide them on the review
Thank you in advance,
[1]
https://github.com/openstack/puppet-openstacklib/commit/3b85306d042292713d0fd89fa508e0a0fbf99671
[2] https://review.openstack.org/#/c/209875/
[3] https://review.openstack.org/#/c/209894/
--
Yanis Guenane
On 08/06/2015 11:04 AM, Yanis Guenane wrote:
> Hi Andrew,
>
> Sorry for the delay in this answer
>
> On 07/30/2015 09:20 PM, Andrew Woodward wrote:
>> On Thu, Jul 30, 2015 at 3:36 AM Sebastien Badia wrote:
>>
>>> On Mon, Jul 27, 2015 at 09:43:28PM (+), Andrew Woodward wrote:
Sorry, I forgot to finish this up and send it out.
#--SNIP--
def absent_default(
$value,
$default,
$unset_when_default = true,
){
if ( $value == $default ) and $unset_when_default {
# I cant think of a way to deal with this in a define so lets pretend
# we can re-use this with multiple providers like we could if this
>>> was
# in the actual provider.
keystone_config {$name: ensure => absent,}
} else {
keystone_config {$name: value = $value,}
}
}
# Usage:
absent_default{'DEFAULT/foo': default => 'bar', value => $foo }
>>> Hi,
>>>
>>> Hum, but you want to add this definition in all our modules, or directly in
>>> openstacklib?
>>>
>> I only mocked it up in a puppet define, because its easier for me (my ruby
>> is terrible) It should be done by adding these kinds of extra providers to
>> the inifile provider override that Yanis proposed.
>>
>>
>>> In case of openstacklib, in which manner do you define the
>>> _config
>>> resource? (eg, generic def, but specialized resource).
>>>
#--SNIP--
(I threw this together and haven't tried to run it yet, so It might not
>>> run
verbatim, I will create a test project with it to show it working)
So In the long-term we should be able to add some new functionality to
>>> the
inifile provider to simply just do this for us. We can add the 'default'
and 'unset_when_default' parameter so that we can use them straight w/o a
wrapping function (but the warping function could be used too). This
>>> would
give us the defaults (I have an idea on that too that I will try to put
into the prototype) that should allow us to have something that looks
>>> quite
clean, but is highly functional
> Keystone_config{unset_when_default => true} #probably flatly enabled in
our inifile provider for the module
> keystone_config {'DEFAULT/foo': value => 'bar', default => 'bar'}
>>> I'm not sure to see the difference with the Yanis solution here¹, and not
>>> sure
>>> to see the link between the define resource and the type/provider resource.
>>>
>> This adds on to Yanis' solution so that we can authoritatively understand
>> what the default value is, and how it should be treated (instead of hoping
>> some magic word doesn't conflict)
> So I think we agree on most points here. '' value has
> been chosen based on our weekly meetings two weeks ago but it remains
> customizable (via the ensure_absent_val parameter).
>
> We need an explicit one by default so it can be set as a default value
> in all manifests.
>
> We mainly picked that value because we thought it was the less likely to
> be used as a valid value in any OpenStack related component
> configuration file.
>
> If by any chance it turns out to be a valid value for a parameter, we
> can use the temporary fix of changing ensure_absent_val for this
> specific parameter and raise the point during a meeting.
>
> I take the point to make it clear in the README that if a X_config
> resource has as a value set to '' it will ensure absent
> on the resource.
>
> Does that sound good with you ?
>
>> Seb
>>> ¹https://review.openstack.org/#/c/202574/
>>> --
>>> Sebastien Badia
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> --
Re: [openstack-dev] [puppet] Parameters possible default value
Hi Andrew,
Sorry for the delay in this answer
On 07/30/2015 09:20 PM, Andrew Woodward wrote:
> On Thu, Jul 30, 2015 at 3:36 AM Sebastien Badia wrote:
>
>> On Mon, Jul 27, 2015 at 09:43:28PM (+), Andrew Woodward wrote:
>>> Sorry, I forgot to finish this up and send it out.
>>>
>>> #--SNIP--
>>> def absent_default(
>>> $value,
>>> $default,
>>> $unset_when_default = true,
>>> ){
>>> if ( $value == $default ) and $unset_when_default {
>>> # I cant think of a way to deal with this in a define so lets pretend
>>> # we can re-use this with multiple providers like we could if this
>> was
>>> # in the actual provider.
>>>
>>> keystone_config {$name: ensure => absent,}
>>> } else {
>>> keystone_config {$name: value = $value,}
>>> }
>>> }
>>>
>>> # Usage:
>>> absent_default{'DEFAULT/foo': default => 'bar', value => $foo }
>> Hi,
>>
>> Hum, but you want to add this definition in all our modules, or directly in
>> openstacklib?
>>
> I only mocked it up in a puppet define, because its easier for me (my ruby
> is terrible) It should be done by adding these kinds of extra providers to
> the inifile provider override that Yanis proposed.
>
>
>> In case of openstacklib, in which manner do you define the
>> _config
>> resource? (eg, generic def, but specialized resource).
>>
>>> #--SNIP--
>>>
>>> (I threw this together and haven't tried to run it yet, so It might not
>> run
>>> verbatim, I will create a test project with it to show it working)
>>>
>>> So In the long-term we should be able to add some new functionality to
>> the
>>> inifile provider to simply just do this for us. We can add the 'default'
>>> and 'unset_when_default' parameter so that we can use them straight w/o a
>>> wrapping function (but the warping function could be used too). This
>> would
>>> give us the defaults (I have an idea on that too that I will try to put
>>> into the prototype) that should allow us to have something that looks
>> quite
>>> clean, but is highly functional
>>>
Keystone_config{unset_when_default => true} #probably flatly enabled in
>>> our inifile provider for the module
keystone_config {'DEFAULT/foo': value => 'bar', default => 'bar'}
>>
>> I'm not sure to see the difference with the Yanis solution here¹, and not
>> sure
>> to see the link between the define resource and the type/provider resource.
>>
> This adds on to Yanis' solution so that we can authoritatively understand
> what the default value is, and how it should be treated (instead of hoping
> some magic word doesn't conflict)
So I think we agree on most points here. '' value has
been chosen based on our weekly meetings two weeks ago but it remains
customizable (via the ensure_absent_val parameter).
We need an explicit one by default so it can be set as a default value
in all manifests.
We mainly picked that value because we thought it was the less likely to
be used as a valid value in any OpenStack related component
configuration file.
If by any chance it turns out to be a valid value for a parameter, we
can use the temporary fix of changing ensure_absent_val for this
specific parameter and raise the point during a meeting.
I take the point to make it clear in the README that if a X_config
resource has as a value set to '' it will ensure absent
on the resource.
Does that sound good with you ?
>
> Seb
>> ¹https://review.openstack.org/#/c/202574/
>> --
>> Sebastien Badia
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Yanis Guenane
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Parameters possible default value
On Thu, Jul 30, 2015 at 3:36 AM Sebastien Badia wrote:
> On Mon, Jul 27, 2015 at 09:43:28PM (+), Andrew Woodward wrote:
> > Sorry, I forgot to finish this up and send it out.
> >
> > #--SNIP--
> > def absent_default(
> > $value,
> > $default,
> > $unset_when_default = true,
> > ){
> > if ( $value == $default ) and $unset_when_default {
> > # I cant think of a way to deal with this in a define so lets pretend
> > # we can re-use this with multiple providers like we could if this
> was
> > # in the actual provider.
> >
> > keystone_config {$name: ensure => absent,}
> > } else {
> > keystone_config {$name: value = $value,}
> > }
> > }
> >
> > # Usage:
> > absent_default{'DEFAULT/foo': default => 'bar', value => $foo }
>
> Hi,
>
> Hum, but you want to add this definition in all our modules, or directly in
> openstacklib?
>
I only mocked it up in a puppet define, because its easier for me (my ruby
is terrible) It should be done by adding these kinds of extra providers to
the inifile provider override that Yanis proposed.
>
> In case of openstacklib, in which manner do you define the
> _config
> resource? (eg, generic def, but specialized resource).
>
> > #--SNIP--
> >
> > (I threw this together and haven't tried to run it yet, so It might not
> run
> > verbatim, I will create a test project with it to show it working)
> >
> > So In the long-term we should be able to add some new functionality to
> the
> > inifile provider to simply just do this for us. We can add the 'default'
> > and 'unset_when_default' parameter so that we can use them straight w/o a
> > wrapping function (but the warping function could be used too). This
> would
> > give us the defaults (I have an idea on that too that I will try to put
> > into the prototype) that should allow us to have something that looks
> quite
> > clean, but is highly functional
> >
> > > Keystone_config{unset_when_default => true} #probably flatly enabled in
> > our inifile provider for the module
> > > keystone_config {'DEFAULT/foo': value => 'bar', default => 'bar'}
>
>
> I'm not sure to see the difference with the Yanis solution here¹, and not
> sure
> to see the link between the define resource and the type/provider resource.
>
This adds on to Yanis' solution so that we can authoritatively understand
what the default value is, and how it should be treated (instead of hoping
some magic word doesn't conflict)
Seb
>
> ¹https://review.openstack.org/#/c/202574/
> --
> Sebastien Badia
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Parameters possible default value
On Mon, Jul 27, 2015 at 09:43:28PM (+), Andrew Woodward wrote:
> Sorry, I forgot to finish this up and send it out.
>
> #--SNIP--
> def absent_default(
> $value,
> $default,
> $unset_when_default = true,
> ){
> if ( $value == $default ) and $unset_when_default {
> # I cant think of a way to deal with this in a define so lets pretend
> # we can re-use this with multiple providers like we could if this was
> # in the actual provider.
>
> keystone_config {$name: ensure => absent,}
> } else {
> keystone_config {$name: value = $value,}
> }
> }
>
> # Usage:
> absent_default{'DEFAULT/foo': default => 'bar', value => $foo }
Hi,
Hum, but you want to add this definition in all our modules, or directly in
openstacklib?
In case of openstacklib, in which manner do you define the _config
resource? (eg, generic def, but specialized resource).
> #--SNIP--
>
> (I threw this together and haven't tried to run it yet, so It might not run
> verbatim, I will create a test project with it to show it working)
>
> So In the long-term we should be able to add some new functionality to the
> inifile provider to simply just do this for us. We can add the 'default'
> and 'unset_when_default' parameter so that we can use them straight w/o a
> wrapping function (but the warping function could be used too). This would
> give us the defaults (I have an idea on that too that I will try to put
> into the prototype) that should allow us to have something that looks quite
> clean, but is highly functional
>
> > Keystone_config{unset_when_default => true} #probably flatly enabled in
> our inifile provider for the module
> > keystone_config {'DEFAULT/foo': value => 'bar', default => 'bar'}
I'm not sure to see the difference with the Yanis solution here¹, and not sure
to see the link between the define resource and the type/provider resource.
Seb
¹https://review.openstack.org/#/c/202574/
--
Sebastien Badia
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Parameters possible default value
Sorry, I forgot to finish this up and send it out.
#--SNIP--
def absent_default(
$value,
$default,
$unset_when_default = true,
){
if ( $value == $default ) and $unset_when_default {
# I cant think of a way to deal with this in a define so lets pretend
# we can re-use this with multiple providers like we could if this was
# in the actual provider.
keystone_config {$name: ensure => absent,}
} else {
keystone_config {$name: value = $value,}
}
}
# Usage:
absent_default{'DEFAULT/foo': default => 'bar', value => $foo }
#--SNIP--
(I threw this together and haven't tried to run it yet, so It might not run
verbatim, I will create a test project with it to show it working)
So In the long-term we should be able to add some new functionality to the
inifile provider to simply just do this for us. We can add the 'default'
and 'unset_when_default' parameter so that we can use them straight w/o a
wrapping function (but the warping function could be used too). This would
give us the defaults (I have an idea on that too that I will try to put
into the prototype) that should allow us to have something that looks quite
clean, but is highly functional
> Keystone_config{unset_when_default => true} #probably flatly enabled in
our inifile provider for the module
> keystone_config {'DEFAULT/foo': value => 'bar', default => 'bar'}
On Mon, Jul 27, 2015 at 3:06 AM Yanis Guenane wrote:
>
>
> On 07/20/2015 10:07 AM, Martin Mágr wrote:
> > Hey Yanis
> >
> > On 07/17/2015 10:56 AM, Yanis Guenane wrote:
> >> Hello everyone,
> >>
> >>
> >> if set the value would have been set else it would default to upstream
> >> default.
> >>
> >> But Mathieu raised a fair point here[2] is that an empty string for some
> >> settings is a valid value, and hence we can't rely on
> >> it.
> >>
> >> Since the beginning we are trying to avoid the use of a magic string,
> >> but
> >> I am starting to run out of idea here.
> >>
> >> Does someone has an idea on which sane value the default could be ?
> >
> > How about '*config_default*'? Or whatever similar which says you want
> > the default value, but will potentially never be value of any parameter.
> >
> > Regards,
> > Martin
> >
> >>
> >> Thanks in advance,
> >>
> >> [1] https://review.openstack.org/#/c/202488
> >> [2] https://review.openstack.org/#/c/202574
> >> --
> >> Yanis Guenane
> >>
> >>
> __
> >>
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __
> >
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Following on the thread, and following the discussion that took place
> during last week meeting[1],
>
> The patchset[2] and the example[3] have been updated not to ensure
> absent for a nil string due to its valid usage in some cases,
> but to ensure absent when '' is specified. Based on the
> community feedback this string
> isn't used across any component.
>
> During the meeting xarses had an alternative idea, if once mocked up you
> could send a follow-up mail in this
> thread so we can grasp the idea.
>
> @Mathieu: if the new approach is ok with you, could you please review
> your -2 on that patchset
>
> Thanks in advance for your feedbacks,
>
> [1]
>
> http://eavesdrop.openstack.org/meetings/puppet/2015/puppet.2015-07-21-14.59.log.html
> [2] https://review.openstack.org/#/c/202574/
> [3] https://review.openstack.org/#/c/202513/
>
> --
> Yanis Guenane
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Parameters possible default value
On 07/20/2015 10:07 AM, Martin Mágr wrote: > Hey Yanis > > On 07/17/2015 10:56 AM, Yanis Guenane wrote: >> Hello everyone, >> >> >> if set the value would have been set else it would default to upstream >> default. >> >> But Mathieu raised a fair point here[2] is that an empty string for some >> settings is a valid value, and hence we can't rely on >> it. >> >> Since the beginning we are trying to avoid the use of a magic string, >> but >> I am starting to run out of idea here. >> >> Does someone has an idea on which sane value the default could be ? > > How about '*config_default*'? Or whatever similar which says you want > the default value, but will potentially never be value of any parameter. > > Regards, > Martin > >> >> Thanks in advance, >> >> [1] https://review.openstack.org/#/c/202488 >> [2] https://review.openstack.org/#/c/202574 >> -- >> Yanis Guenane >> >> __ >> >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __ > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Following on the thread, and following the discussion that took place during last week meeting[1], The patchset[2] and the example[3] have been updated not to ensure absent for a nil string due to its valid usage in some cases, but to ensure absent when '' is specified. Based on the community feedback this string isn't used across any component. During the meeting xarses had an alternative idea, if once mocked up you could send a follow-up mail in this thread so we can grasp the idea. @Mathieu: if the new approach is ok with you, could you please review your -2 on that patchset Thanks in advance for your feedbacks, [1] http://eavesdrop.openstack.org/meetings/puppet/2015/puppet.2015-07-21-14.59.log.html [2] https://review.openstack.org/#/c/202574/ [3] https://review.openstack.org/#/c/202513/ -- Yanis Guenane __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Parameters possible default value
Hey Yanis On 07/17/2015 10:56 AM, Yanis Guenane wrote: Hello everyone, if set the value would have been set else it would default to upstream default. But Mathieu raised a fair point here[2] is that an empty string for some settings is a valid value, and hence we can't rely on it. Since the beginning we are trying to avoid the use of a magic string, but I am starting to run out of idea here. Does someone has an idea on which sane value the default could be ? How about '*config_default*'? Or whatever similar which says you want the default value, but will potentially never be value of any parameter. Regards, Martin Thanks in advance, [1] https://review.openstack.org/#/c/202488 [2] https://review.openstack.org/#/c/202574 -- Yanis Guenane __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Parameters possible default value
Hey Yanis,
On Fri, Jul 17, 2015 at 3:56 AM, Yanis Guenane wrote:
> Hello everyone,
>
> Based on the conversation we had during last meeting I went ahead and
> created an
> ini_setting provider[1] that will act as a proxy between our provider
> and the
> upstream one, this way we don't have to fork, only overload the method
> we want.
>
> The second step towards parameter default management was to provide a
> way that
> means if 'X' is specified as the value for the provider then ensure it
> is absent.
>
> This way we could move from the following pattern :
>
> if $myvar {
> keystone_config {'DEFAULT/foo': value => $myvar,
> } else {
> keystone_config {'DEFAULT/foo': ensure => absent,
> }
>
> to a more readable one that would have been
>
> keystone_config {'DEFAULT/foo': value => $myvar, }
>
> that based on the value of $myvar would have ensure absent the parameter.
>
> In a first time the empty string seemed to have been a good idea, so we
> could
> have default all the parameters to '' (empty string) and live happily
> ever after,
> if set the value would have been set else it would default to upstream
> default.
>
> But Mathieu raised a fair point here[2] is that an empty string for some
> settings is a valid value, and hence we can't rely on
> it.
>
>
Does it make sense for undef to be the 'magic' string for this? As '' or
false may be valid settings, but undef currently is basically ignored (or
so I've been told). Would we want to use undef to indicate the removal of
an option from a configuration?
>
> Since the beginning we are trying to avoid the use of a magic string, but
> I am starting to run out of idea here.
>
> Does someone has an idea on which sane value the default could be ?
>
> Thanks in advance,
>
> [1] https://review.openstack.org/#/c/202488
> [2] https://review.openstack.org/#/c/202574
> --
> Yanis Guenane
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Thanks,
-Alex
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] Parameters possible default value
Hello everyone,
Based on the conversation we had during last meeting I went ahead and
created an
ini_setting provider[1] that will act as a proxy between our provider
and the
upstream one, this way we don't have to fork, only overload the method
we want.
The second step towards parameter default management was to provide a
way that
means if 'X' is specified as the value for the provider then ensure it
is absent.
This way we could move from the following pattern :
if $myvar {
keystone_config {'DEFAULT/foo': value => $myvar,
} else {
keystone_config {'DEFAULT/foo': ensure => absent,
}
to a more readable one that would have been
keystone_config {'DEFAULT/foo': value => $myvar, }
that based on the value of $myvar would have ensure absent the parameter.
In a first time the empty string seemed to have been a good idea, so we
could
have default all the parameters to '' (empty string) and live happily
ever after,
if set the value would have been set else it would default to upstream
default.
But Mathieu raised a fair point here[2] is that an empty string for some
settings is a valid value, and hence we can't rely on
it.
Since the beginning we are trying to avoid the use of a magic string, but
I am starting to run out of idea here.
Does someone has an idea on which sane value the default could be ?
Thanks in advance,
[1] https://review.openstack.org/#/c/202488
[2] https://review.openstack.org/#/c/202574
--
Yanis Guenane
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
