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 <sgolovat...@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 <ikalnit...@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 >> <sgolovat...@mirantis.com> wrote: >> > Hi, >> > >> > >> > On Thu, Jul 16, 2015 at 9:01 AM, Aleksandr Didenko >> > <adide...@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 <aschu...@mirantis.com> >> >> wrote: >> >>> >> >>> Done. Sorry about that. >> >>> >> >>> -Alex >> >>> >> >>> On Fri, Jul 10, 2015 at 9:22 AM, Simon Pasquier >> >>> <spasqu...@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 >> >>>> <bdobre...@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-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 >> >>> >> >> >> >> >> >> >> >> __________________________________________________________________________ >> >> 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 >> > >> >> __________________________________________________________________________ >> 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 > __________________________________________________________________________ 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