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:
https://github.com/DBuildService/atomic-reactor
https://github.com/DBuildService/osbs-client
https://github.com/DBuildService/ansible-osbs
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
two?
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
Thanks,
Lala
[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
Regards,
~~
Tomáš Tomeček
Software Engineer
Developer Experience
UTC+2 (CEST)
[1] https://en.wikipedia.org/wiki/Linearizability
Thanks,
Lala
