The target is the 5G, but it's vast! We encourage you to contribute with tools, software bricks... it is very wide.
The Atom concept is analogous to the bricks or software modules that we can integrate to create molecules or matter. We also think that it's cool.
For the moment, it is considered that the lifetime is a "commit on the master branch". Every time you commit to the master, a build and delivery is sent to the AtomStore/AtomDocs, so a new version. This will also encourage contributors to use branches other than the master to avoid this (if not desired)
Yes but not only. Plug'in is the research PF to experiment 5G. So there is the goal to show the 5G, the innovations proposed by Orange and its partners, with of course an important place to the administration and piloting of 5G, since it is a new & key component of 5G , All the more important for the operator.
Both. Plug'in provides tools to present Atoms (i.e. software bricks relevant to 5G), automatic publication of Atoms and their documentation to facilitate the work of researchers, and thus, the work of assumbling Atoms for illustration purpose.
Plug’in welcome such contributions as they are fully connected to 5G promises. There are already analytic bricks that have been contributed in the AtomStore.
No, Plug'in does not host running atom instance
The work of Orange Partners is very product oriented. The Plug'in platform is intended for experimentation and research projects. The work carried out in the Plug'in platform can then pass to the production phase through anticipation, the Techno Center, etc.
OpenShift is a container-based software (uses Docker and Kubernetes) that allows DevOps to create microservices. Plug'in is more than a container platform, at least, that's our goal. Plug'in is about creating new ways to interact, to share and create together. Plug'in is bare metal, IaaS and PaaS (may be) capable and focuses at most at changing the way research is done, by bringing researchers/developers together in the Sandbox, and AtomStore in particular.
Plug'in chooses IaaS and bare metal, to fulfill the needs of a 5G Telco, a PaaS may be considered in the future.
In ODN, the integration involves relatively stable bricks, unitarily ready for deployment, whose end-to-end compatibility and performance must be tested with the underlying infrastructure. Plug'in's goal is to prevent researchers from making 5G silo developments, but on the contrary to have visibility on the bricks already developed, and to be able to reuse them or even complete them; To highlight the relevance of an innovation, it is often necessary to demonstrate it in a more complete 5G chain. Hence the possibility of integrating bricks (more or less mature) on Plug'in.
Plug'in is a support for innovation, so the innovations will be pushed then or in parallel in opensource or in normalization. Plug'in uses bricks originating from the opensource, brought by partners, developed in-house or in collaboration.
Several research teams from Orange (and elsewhere) started using OAI because it was the only available opensource solution. Although OAI does not implement 5G, because of its modularity, 5G functionnalities may be added in the future. As a corollary, a weak point of OAI is the management of the modifications of OAI which could be greatly improved.
Plug'in PlayGround is the place to test and experiment innovation bricks (Atoms). Plug'in offers the way to accelerate the adoption of bricks. What we want to avoid is: “I have heard of a software brick, but I don’t know how to use it, I sent a mail to the author but he is offline”. Instead, we propose this on-demand self-service innovation development environment. With the PlayGround I can deploy for test such or such Atom.
If it's about opening to non-members of the project, it is already the case, ex. the gitlab that is used is that of the forge. If it's about opening up on the Internet, issues about patents, external collaborations... can arise.
Yes, in the medium term.
Yes, Plug'in reuses some tools from the Devops Store, and completes them with specific developments.
The Jenkins used by Plug'in is that of FaaS (please visit devops-store here for more info).
Exact. It takes LDAP ids, so it's actually personal. But we give recommendations and also recipes. We also encourage people that are confortable with FaaS to share with the community.
Often yes. The idea here is that people offer their versions in the store in the tools category (for example). Then we hope that people will not re-create, but re-use instead. The sandbox will be an accelerator of development from scratch by automating the maximum of things.
Plug'in does not have that guarantee. It is up to the community of Plug'in, users and contributors to offer this guarantee.
Yes, we are working on it.
Currently we work on it, the Juju model inspired us and we want to do something similar.
Yes, OpenAPI for api, so swagger will be everywhere :)
For now it is simply markdown (or rst) with some basic structure (for more details, see here). If you think of a particular structure or structure that you have seen or liked, it is really welcome :)
Plug'in is using Gitlab and favors its usage to store the developed bricks. In complement to gitlab, Plug'in has developed AtomStore and AtomDocs which enable to visualize all innovation software bricks at a single place. It avoids having to check all Gitlab projects, one by one. With many open source communities such as Docker, Python, Go, OpenStack, similar approach is followed.
1-2 hours for the first time, please have a look at the testimony of one of the contributors.
API REST is preferred, but we are open to others. Please, tell us.
First, we started with Jenkins as it is very complete, and was considered as THE reference by many. Plug'in goal is to facilitate developers' life, hence whenever pertinent we keep existing choices, especially when available as Orange Forge aaS. In addition, we proposed GitLab CI for those who prefer it.