Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
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
Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
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
Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
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
Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
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 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
Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
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: 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' I am giving +1 to librarian here. 1. 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
Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
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
Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
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
Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
Hi, just wanted to mention another tool to work with 'Puppetfile' - r10k: https://github.com/puppetlabs/r10k/blob/master/doc/puppetfile.mkd Regards, Alex On Wed, Jun 24, 2015 at 11:04 PM, Paul Belanger pabelan...@redhat.com wrote: On 06/23/2015 01:51 PM, Alex Schultz 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. I'd suggest looking at librarian-puppet-simple over librarian-puppet. I found the dependency management terrible with librarian-puppet. The more complex your puppet dependencies became, the longer the tooling took to run. Mine you this was a few years ago. PB __ 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
Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
Aleksandr Didenko wrote: just wanted to mention another tool to work with 'Puppetfile' - r10k: I am a big fan of r10k - it is what we use internally @ Puppet and we encourage our users to do the same. https://github.com/puppetlabs/r10k Regards, Richard SysOps Engineer @ Puppet Labs __ 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
Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
On 06/23/2015 01:51 PM, Alex Schultz 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. I'd suggest looking at librarian-puppet-simple over librarian-puppet. I found the dependency management terrible with librarian-puppet. The more complex your puppet dependencies became, the longer the tooling took to run. Mine you this was a few years ago. PB __ 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
Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules
On 06/23/2015 01:51 PM, Alex Schultz 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. FWIW - Over in Infra we also have a giant pile of external modules we use. We looked at and chose not to use librarian because of complexity and also fragility. Instead, we wrote a simple script and a simple manifest file: http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules.env http://git.openstack.org/cgit/openstack-infra/system-config/tree/install_modules.sh Feel free to make use of that if it's helpful. __ 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
