[Pulp-dev] Splitting ansible-pulp3 responsibilities

[Kersom]

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 <bbouters at redhat.com> wrote:

> @ehelms, thank you so much for sharing this work!
>
> On Wed, Oct 24, 2018 at 10:11 PM Eric Helms <ehelms at 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20181030/4d95031e/attachment.htm>