[openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

Aleksandr Didenko adidenko at mirantis.com
Thu Jul 16 14:01:45 UTC 2015


Hi,

guys, what if we "simplify" things a bit? All we need is:

   1. Remove all the community modules from fuel-library.
   2. Create 'Puppetfile' with list of community modules and their versions
   that we currently use.
   3. Make sure all our customizations are proposed to the upstream modules
   (via gerrit or github pull-requests).
   4. Create a separate file with list of patches for each module we need
   to cherry-pick (we need to support gerrit reviews and github pull-requests).
   5. Update 'make iso' scripts:
      1. Make them use 'r10k' (or other tool) to download upstream modules
      based on 'Puppetfile'
      2. Iterate over list of patches for each module and cherry-pick them
      (just like we do for custom ISO build. I'm not sure if librarian provides
      such possibility)

Eventually, when all the functionality we rely on is accepted in upstream
modules, we'll get rid of file with list of patches for modules. But
meanwhile it should be much easier to manage modules and customization in
such way.

Regards,

Alex



On Fri, Jul 10, 2015 at 5:25 PM, Alex Schultz <aschultz at mirantis.com> wrote:

> Done. Sorry about that.
>
> -Alex
>
> On Fri, Jul 10, 2015 at 9:22 AM, Simon Pasquier <spasquier at mirantis.com>
> wrote:
>
>> Alex, could you enable the comments for all on your document?
>> Thanks!
>> Simon
>>
>> On Thu, Jul 9, 2015 at 11:07 AM, Bogdan Dobrelya <bdobrelia at mirantis.com>
>> wrote:
>>
>>> > Hello everyone,
>>> >
>>> > I took some time this morning to write out a document[0] that outlines
>>> > one possible ways for us to manage our upstream modules in a more
>>> > consistent fashion. I know we've had a few emails bouncing around
>>> > lately around this topic of our use of upstream modules and how can we
>>> > improve this. I thought I would throw out my idea of leveraging
>>> > librarian-puppet to manage the upstream modules within our
>>> > fuel-library repository. Ideally, all upstream modules should come
>>> > from upstream sources and be removed from the fuel-library itself.
>>> > Unfortunately because of the way our repository sits today, this is a
>>> > very large undertaking and we do not currently have a way to manage
>>> > the inclusion of the modules in an automated way. I believe this is
>>> > where librarian-puppet can come in handy and provide a way to manage
>>> > the modules. Please take a look at my document[0] and let me know if
>>> > there are any questions.
>>> >
>>> > Thanks,
>>> > -Alex
>>> >
>>> > [0]
>>> https://docs.google.com/document/d/13aK1QOujp2leuHmbGMwNeZIRDr1bFgJi88nxE642xLA/edit?usp=sharing
>>>
>>> The document is great, Alex!
>>> I'm fully support the idea to start adapting fuel-library by
>>> the suggested scheme. The "monitoring" feature of ibrarian looks not
>>> intrusive and we have no blockers to start using the librarian just
>>> immediately.
>>>
>>> --
>>> Best regards,
>>> Bogdan Dobrelya,
>>> Irc #bogdando
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150716/9b71e226/attachment.html>


More information about the OpenStack-dev mailing list