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 <sba...@redhat.com> wrote: > >> On Mon, Jul 27, 2015 at 09:43:28PM (+0000), 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 >> <component>_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. '<SERVICE DEFAULT>' 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 '<SERVICE DEFAULT>' 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