[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Moving osbs/atomic-reactor under projectatomic org on Github

On 07/07/2015 02:12 PM, Tomas Tomecek wrote:
Quoting Lalatendu Mohanty (2015-07-06 14:36:11)
On 07/03/2015 05:58 PM, Bohuslav Kabrda wrote:
Hi all,
on behalf of development team of OSBS (OpenShift Build Service), I'd like to propose moving three of our projects under projectatomic org on Github:


To describe the projects a bit:
- atomic-reactor is a Python library with command line interface for building docker images. For a complete set of features, see [1]
- osbs-client is a Python module and command line client for OpenShift Build Service.
- ansible-osbs is an ansible playbook to deploy OpenShift with atomic-reactor ready to build images.

To describe the whole system more: Builds are submitted through osbs-client by users/other tools. osbs-client communicates with OpenShift. OpenShift has an image with atomic-reactor installed inside, which is used to build requested images.

Hope this makes sense and thanks for considering. Questions are welcome!

I have couple of questions/concerns. But these should not stop moving
the projects under projectatomic.

1.  Why the name is "atomic-reactor"? I could not find the correlation
atomic and atomic-reactor. IMO atomic-reactor should produce atomic images.
Ah, I can see the confusion. The original proposal was just "reactor". It should
have reflected that atoms (containers/images) are being processed inside the
reactor. Unfortunately, there are multiple projects named reactor [3] [4] so we
added the atomic prefix.

2. As of now we have overload of atomic name as prefix to many projects
e.g. atomicapp , atomicapp-builder [1], atomic command and atomic
host.   So we are already having difficulty explaining the difference
between those. So if we can avoid the atomic as the prefix unless it is
really required, it would be good.
I sort of agree here. On the other hand, if they have "atomic" in their name,
you know that they are related to linux containers, Atomic Host, etc.

I still think we are overloading the atomic name. The idea of atomic host is to create a platform for running containers. So if the project has nothing to do with the platform then I think we should not use the atomic prefix.

I am seeing people already getting confused between atomic command and atomic host. And I find it difficult explaining that atomic command is just an command line and it has no correlation with atomic operation [1]. I find atomicapp name is fine because those apps should be running on atomic hosts (ideally) even if they can be run on non-atomic hosts.

IMHO we should not use atomic prefix unless it is really justifiable.

3.  What is the correlation between atomic-reactor and atomic-builder [1] ?
atomic builder uses atomic reactor (we are in a process of renaming reactor from
its former name, dock) [5] [6]

atomic builder doesn't require CLI of atomic reactor, it is importing reactor
from python's sitelib (your $PATH won't be bloated)

4. Does sti [2] uses atomic-reactor? is there any relation between these
They try to solve a similar issue: assemble images

  * reactor has a set of pre-build and post-build plugins (see it as `docker
    build` with hooks)

  * source-to-image, on the other hand, is a tool for assembling images by
    injecting source code into a docker image

Right now the two projects don't interact.
[1] https://github.com/bkabrda/atomicapp-builder/
[2] https://github.com/openshift/source-to-image


[3] https://pypi.python.org/pypi/reactor
[4] https://github.com/reactor/reactor
[5] https://github.com/bkabrda/atomicapp-builder/blob/master/atomicapp-builder.spec#L34
[6] https://github.com/bkabrda/atomicapp-builder/blob/master/atomicapp_builder/builder.py#L32

Tomáš Tomeček
Software Engineer
Developer Experience

[1] https://en.wikipedia.org/wiki/Linearizability


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]