@ehelms, thank you so much for sharing this work! On Wed, Oct 24, 2018 at 10:11 PM Eric Helms <ehe...@redhat.com> wrote:
> If this is better off as an issue in Redmine, please let me know but I was > honestly not sure where to raise this kind of issue so mailing list it is > to start. > This is a great place to start > > Background > > While playing around with the ansible-pulp3 repository I found myself > wanting to run the scenarios to ensure that I had a basic grasp of the > install flow and to ensure that any changes I made did not break existing > scenarios. I found myself having to copy Vagrantfile's around for each > scenario, including adding new ones based on other OSes (e.g. CentOS) until > things got messy. > I agree with this problem statement. > > General Proposal > > Based on my experience, I am proposing to split the "installer" portion > (e.g. all of the core Ansible) from the provisioning pieces (e.g. Vagrant) > across two separate git repositories. > > Potential Solution for Proposal > > The above is a general proposal. What follows is a potential solution that > I built out and used locally to get myself up to speed running and testing > for multiple scenarios and OSes. In the Foreman community we built > ourselves a simple little tool called Forklift that allows configuring > Vagrant through yaml, and building custom boxes built based on previous box > definitions. This has worked quite well for both creating production, test > and development environments for many years. Given my experience I popped > out a "Pulplift" using Forklift as a library to provide boxes for Fedora > 27, 28 and CentOS 7 for source and sandbox installations. You can find the > repo at [1] with some starting notes about what the repository can do in > the README. > Pulplift looks like it offers a lot of value and it can be generically combined w/ the installer so that is great. If we adopted it would the Vagrant items be removed from the Ansible installer repo altogether? I think that would be a good thing. I'm going to try to get through the backlog of Ansible installer PRs before I ask you for any more PRs :) Thank you again for those! Anyone else please also try Pulplift and give feedback here. > Whether Pulplift is adopted or not, I think there is a benefit to > splitting per the general proposal. Further, this split will allow the > installer bits to remain Ansible focused and the Vagrant bits to be seen as > testing, and evaluation code. > +1 here > Thanks for consideration, > Eric > > [1] https://github.com/ehelms/pulplift > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
