[openstack-dev] [puppet] openstacklib::db::sync proposal

Yanis Guenane yguenane at redhat.com
Mon Jun 8 06:48:16 UTC 2015

On 06/03/2015 02:32 PM, Martin Mágr wrote:
> On 06/02/2015 07:05 PM, Mathieu Gagné wrote:
>> On 2015-06-02 12:41 PM, Yanis Guenane wrote:
>>> The openstacklib::db::sync[2] is currently only a wrapper around an
>>> exec
>>> that does the actual db sync, this allow to make any modification to
>>> the
>>> exec into a single place. The main advantage IMO is that a contributor
>>> is provided with the same experience as it is not the case today across
>>> all modules.
>> The amount of possible change to an exec resource is very limited. [1] I
>> don't see a value in this change which outweighs the code churn and
>> review load needed to put it in place. Unless we have real use cases or
>> outrageously genius feature to add to it, I'm not in favor of this
>> change.
>> Furthermore, any change to the public interface of
>> openstacklib::db::sync would require changes across all our modules
>> anyway to benefit from this latest hypothetical feature. I think we are
>> starting to nitpick over as little "generic" code we could possibly find
>> to put in openstacklib.
>> [1] https://docs.puppetlabs.com/references/latest/type.html#exec
> Wearing my consistency hat I must say I like this change. On the other
> hand I agree with Mathieu that delegating single resource from several
> modules to single module is necessary in this case.
> Regards,
> Martin

Mathieu, Martin, thank you for replying.

For the wrapper around exec usefulness I understand your concerns.
On a note I was trying to follow the current use of openstacklib.

If we look at openstacklib::db::postgresql[1] or
openstackib::db::mysql[2] they are simple wrapper around
puppet resources with no extra logic, but a common resource across all

Also, to move forward on this topic I will submit to a vote one of the
three propositions during our next meeting

 1. Abandon this change
 2. Move everything to X::db::sync, but just run the exec there, no
 3. Move forward with current implementation

Thanks again for the feedbacks,


Yanis Guenane

More information about the OpenStack-dev mailing list