metabarj0 / carrier Goto Github PK

Today, the appliance system of carrier lacks of reusability/composability.
It can be seen by comparing the devenv-cpp and the devenv-trinitycore appliances.
Actually, devenv_trinitycore needs all images devenv-cpp requires.
But, these images have to be respecified in the manifest file of the devenv-trinitycore appliance, thus leading to duplication and maintenance burden.
The purpose of this issue is to find a way to make an appliance 'inheritable' for another one, simplifying new specialized appliance creation and maintenance.

Today to create an image or an appliance, one must copy/paste an existing image or appliance project in a brand new directory then, modify the content of duplicated files.
The purpose of this issue is to add 2 new commands in image and appliance domains to allow one to create both interactively and programatically image and appliance projects.
For instance, carrier image create will enter the interactive image creation process whereas carrier image create [options...] will trigger the image project creation without the need of an input from the user.
Same thing for the appliance domain.

Today, the appliance system works well with the image build system, ensuring the user has almost no input to provide in order to build or start a complete appliance.
Though services' images are correctly built, they lack of an image.dist file describing their content.
Moreover, they also lack of utilities script named importPackageFrom and exportPackageTo that could allow these service images to behave just like carrier regular built images.
The purpose of this issue is to add these utilities as well as an image.dist file describing the full content of any service image of an appliance.

Currently, the devenv-cpp carrier appliance is very simple and does not involve the use of lots of carrier images.
The purpose of this issue is to make this appliance BDD ready, that is, able to sue the cucumber-cpp framework enabling behavior driven development.
This issue is related to the #6.

carrier image creation process was born at the early stage of carrier. It has been incorporated 'as-is' in the unique carrier script without thinking about performances (though it has been refactored for readability and testability purposes).
Today, while being created, an image use the overlay storage of its running container as temporary staging area.
The factorization feature opened the way to re-think existing image operations like the image creation.
After being implemented, an image being created won't use the overlay storage of its running container to build up. It should lead to a significant performance boost in image creations.

This issue is about to manage version of images.
Today, images does not provide the concept of version. The only version concept you can find is about the source files you download thanks to a variable in the manifest file.
The purpose of this issue is to implement a way to manage version of images.

• The version of an image can match the version of sources downloaded to build it
• At the end, version the image could help to update them easily
• Version could serve in dependency resolution as well as the image name
• …specification in prgress

Today, one can bootstrap its system with carrier using the following command :
carrier bootstrap run
The purpose of this issue is not to change how the bootstrap run is invoked but how it performs.
Today it is kind of heavy :

• relies on the base/archlinux docker image, that is far to be lightweight
• this image needs to be updated and various software must be installed before building any sources that is time and bandwidth consuming
• gcc (currently 7.2.0 and 7.3.0) that are the only supported versions so far must be cross-compiled to be useable with musl-libc
• an alpine image with a docker installation is needed to create the metabarj0/docker-cli image therefore, the base/archlinux image is not the only one base image the bootstrap process needs.

Once this issue will be solved, the bootstrap process should rely only on the alpine docker image :

• very lightweight image
• already based on musl-libc (though maybe not the latest version)
• won't change anything for the metabarj0/docker-cli image creation

Add a carrier image for Ruby

Today, carrier hold an image for LLVM 5.
I need LLVM 6 in order to test if the new clang can be used as a lint engine supporting compilation databases.
If it does not, at least, LLVM will be updated

This issue is directly related to #2.
As a result, new images should have their own directory in docker/share/images :

• gcc (update to 8.1+)
• make (updated to 4.2+)
  As a result, the bootstrap process should be significantly faster than today

As a user, I would like carrier to be easier to use. As a result, a contextual help system could help providing me enough information to use carrier correctly without the necessity to invoke the full and a way too much verbose help.
Here are some examples :

• carrier help gives a better overview carrier can do indicating all supported global commands, options and domains. The existing global help command is insufficient today.
• carrier image help gives a precise help on all supported commands and options associated with the image domain
• carrier appliance start help gives a precise help on all options that can be used with the start command of the appliance domain

The way metabarj0/gcc is built forces one to explicitely specify rpath and rpath-link compilation flags for each project to build.
This issue is related to the #2 and could be implicitly solved.
Consequences :

• easier image builds/project compilations
• refacto almost all carrier images because these flags are always used on images requiring build with gcc