I use VM`s to install Pulp. I would like to keep using them for testing purposes.
I think that moving vagrant files to another repo as Pulplift is a good alternative. Besides that, being able to install from source or PyPI using the installer will avoid problems for testing as well. The installer could be used in our Travis-CI environment, for instance. On Mon, Oct 29, 2018 at 5:18 PM Brian Bouterse <bbout...@redhat.com> wrote: > @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 >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
