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 <yguen...@redhat.com> 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 '<SERVICE DEFAULT>' 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
