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

Igor Kalnitsky ikalnitsky at mirantis.com
Sat Jul 18 10:04:33 UTC 2015


Sergii,

It's not about tests, it's about how we want to retrieve upstream
packages. Directly from Git? Or package them and add deps to our
fuel-library package?

Thanks,
Igor

On Sat, Jul 18, 2015 at 1:14 AM, Sergii Golovatiuk
<sgolovatiuk at mirantis.com> wrote:
> Igor,
>
> There shouldn't be any holywars as we are going to add our tests to Puppet
> manifests projects. We'll be able to resolve fast enough. In case of
> problems we can stick librarian to particular commit in upstream repo.
>
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Fri, Jul 17, 2015 at 8:19 AM, Igor Kalnitsky <ikalnitsky at mirantis.com>
> wrote:
>>
>> Hello guys,
>>
>> > Update 'make iso' scripts:
>> >   * Make them use 'r10k' (or other tool) to download upstream modules
>> > based on 'Puppetfile'
>>
>> I foreseen holywars with our Build team. AFAIK they are deeply
>> concerned about Internet access during ISO build process. Hence,
>> they'll propose to package upstream puppet manifests, and that can
>> complicate our experience to work with upstream flexibly.
>>
>> Thanks,
>> Igor
>>
>> On Thu, Jul 16, 2015 at 11:55 PM, Sergii Golovatiuk
>> <sgolovatiuk at mirantis.com> wrote:
>> > Hi,
>> >
>> >
>> > On Thu, Jul 16, 2015 at 9:01 AM, Aleksandr Didenko
>> > <adidenko at mirantis.com>
>>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> guys, what if we "simplify" things a bit? All we need is:
>> >>
>> >> Remove all the community modules from fuel-library.
>> >> Create 'Puppetfile' with list of community modules and their versions
>> >> that
>> >> we currently use.
>> >> Make sure all our customizations are proposed to the upstream modules
>> >> (via
>> >> gerrit or github pull-requests).
>> >> 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).
>> >> Update 'make iso' scripts:
>> >>
>> >> Make them use 'r10k' (or other tool) to download upstream modules based
>> >> on
>> >> 'Puppetfile'
>> >
>> > I am giving +1 to librarian here.
>> >>
>> >> 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)
>> >
>> >
>> > Puppetlabs is in transition of moving all modules to openstack. We may
>> > use
>> > pull-requests here just specifying repository. However, I am thinking
>> > about
>> > hacking librarian to add cherry-pick option.
>> >
>> >>
>> >> 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
>> >>>
>> >>
>> >>
>> >>
>> >> __________________________________________________________________________
>> >> 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
>> >
>>
>> __________________________________________________________________________
>> 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
>



More information about the OpenStack-dev mailing list