Re: [atomic-devel] [Proposal] Move atomicapp Vagrant box git repo under Project Atomic

[Carl Trieloff <cctrieloff redhat com>]

On 06/19/2015 06:01 AM, Lalatendu Mohanty wrote:
> On 06/19/2015 12:47 AM, James wrote:
>> On Thu, Jun 18, 2015 at 1:18 PM, Colin Walters <walters verbum org>
>> wrote:
>>> On Thu, Jun 18, 2015, at 05:53 AM, Lalatendu Mohanty wrote:
>>>> Hi All,
>>>> [1]
>>>> https://github.com/LalatenduMohanty/centos7-container-app-vagrant-box
>>> I don't object exactly, but at some point we're really going to have
>>> to invest in
>>> de-duplicating Vagrant work.
>>>
>>> See:
>>> https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-April/msg00027.html
>>>
>>> and
>>> https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-April/msg00047.html
>>>
>>>
>>> This most closely overlaps
>>> https://github.com/projectatomic/adb-atomic-developer-bundle/
>>>
>>> The kickstart file has a lot of overlap with (but is not exactly the
>>> same as) the
>>> Vagrant boxes for Fedora 22 (both Base and Atomic), which are
>>> configured here:
>>> https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/
>>>
>>> Your kickstart configuration could probably be fairly easily written
>>> as a Vagrant
>>> provisioner on top of either the Cloud Base or Atomic - or on top of
>>> OMV.
>> I too agree with Colin. If someone wants to make a custom spin of a
>> box, my vagrant-builder tool does exactly that.
>> You can use any of the existing Fedora produced base images as a base.
>>
>> I've been down the roads to/from vagrant for many years now. It would
>> be my recommendation to build on existing work I've done, or to have
>> good reasons why not to. I'd rather throw out my work than to
>> constantly see people re-invent where it's not needed.
>>
>> Cheers,
>> James
>>
>
> Colin, James, Nick,
>
> Sorry for not communicating well about the pupose of the Vagrant box
> or boxes we are trying to create. So as a first step I have updated
> the Readme in the github [1] and copied the same below for your
> reference.  I have plans to update the readme after the our current
> discussion if required ( and you are welcome to send a PR too).
>
> (For hyperlinks to the below projects/keywords, please visit the git
> repo readme [1] )
>
> - The vagrant box should have all the tools and library required for
> developing Nulecule based atomicapps.
> --E.g. We have plan to add tools like atomicapp-builder and Nulecule
> DEV assistant. Check here for details
> - This box will be complimentary to CentOS CentOS Community Container
> Pipeline.
> -- That would help developers test the Nulecule based atomicapp
> locally on the vagrant box/boxes before sending the pull request to
> the CentOS Community Container Pipeline index
> - The base Vagrant box will contain the developer environments of the
> atomicapp providers as required e.g. OpenShift.
> -- We are working on integrating OpenShift Vagrant box for developers
> with this.
> - The idea is to create base boxes using distributions build system
> and then use solution like Oh-my-vagrant for multibox dev environment.
> -- As of now we are building the base boxes through CBS.
> - This project will inherit from
> projectatomic/adb-atomic-developer-bundle and will consolidate the
> work already done.
>
> Note: Project Atomic already provides Vagarant boxes for CentOS and
> Fedora, but we can not reuse those as we need an environment which can
> be modified by the developers.
>
> Kindly let me know your thoughts on this. Honestly I am not interested
> to redo stuff which is already done. Rather I will prefer to
> consolidate what is already done.
>
> [1] https://github.com/LalatenduMohanty/centos7-container-app-vagrant-box
>
> Thanks,
> Lala
>


What I would like to see is once we have the above merge complete as
Lala has described we will have the key tools  and envs (OpenShift)
structured into containers. This gives us the simple case, 1 image env.
Then I would like to see a OMV config (to be discussed with PupleIdea)
that pulls a meta data file we could use for both single VM and OMV
config that lists all the tools / env's we have (and gets added to as we
add options, which OMV can use to provide the same set of options but
for multi image(VM) environments.  This means we not duplicating work on
tool and env options and supporting both use cases.

i.e. once the ABRT guys have their tool in a container/nulecule, we link
that into the meta data file. This means inside the single VM env  I can
get that tool by running AtomicApp run {abrt}  & in OMV it will appear
automatically as an option in the env setup options of the tool.

Carl.