On Fri, May 8, 2015 at 12:50 PM, Mathieu Gagné <mga...@iweb.com> wrote:
> On 2015-05-07 4:19 PM, Emilien Macchi wrote: > > > > Proposals > > ========= > > > > #1 Creating puppet-oslo > > ... and having oslo::messaging::rabbitmq, oslo::messaging::qpid, ..., > > oslo::logging, etc. > http://git.openstack.org/cgit/stackforge/puppet-openstacklib/refs/ > > This module will be used only to configure actual Oslo libraries when we > > deploy OpenStack. To me, this solution is really consistent with how > > OpenStack works today and is scalable as soon we contribute Oslo > > configuration changes in this module. > > > > #2 Using puppet-openstacklib > > ... and having openstacklib::oslo::messaging::(...) > > A good thing is our modules already use openstacklib. > > But openstacklib does not configure OpenStack now, it creates some > > common defines & classes that are consumed in other modules. > > > > I prefer #1 due to oslo configs being specific to OpenStack versions. > > The goal of openstacklib is to (hopefully) be OpenStack version agnostic > and be used only for code common across all *our* modules. > > That's why I suggest going with solution #1, unless someone comes with a > solution to support multiple OpenStack versions in openstacklib without > the use of stable branches. > puppet-openstacklib already has stable branches: http://git.openstack.org/cgit/stackforge/puppet-openstacklib/refs/ I was not aware of any assumption that openstacklib would work for different versions of our modules. I think this would be a difficult goal to achieve. For example, the provider code in puppet-keystone is tightly coupled with the code in puppet-openstacklib. If making puppet-openstacklib version-agnostic is important (and I do think there would be value in it) then maybe we should consider ripping out the provider backend code from puppet-openstacklib and creating a puppet-openstackclient module. Colleen > > -- > Mathieu > > __________________________________________________________________________ > 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