Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150717/3accfae3/attachment.html>