-
Notifications
You must be signed in to change notification settings - Fork 47
Including information on how to build all images for application #105
Comments
First thought, this issue/RFE is a excellent description of a good practice how to extend the usage of the Nulecule Spec without touching the formal spec... We have exactly want people to extend the YAML file Nulecule and put all that they need in there. |
@goern +1 :) Q1: Exactly, it's good that it's optional and we will just expect images to already exist if they are not specified Q2: Good idea. What about some mapping to the Nulecule appversion [1]? So that I don't have to duplicate the version information in my Nulecule file if the appversion is same to the version of the binary image?
Q3: Two build_configs sound good to me. You probably don't need to rebuiled older versions of images. Q4: No, it's pretty straighforward and I think it shouldn't be very hard to add support to f.e. DevAssistant to generate Q5: Can we somehow infer the mapping from [1] https://github.com/projectatomic/nulecule/blob/master/examples/helloapache/Nulecule#L7 |
Thanks for your replies. I would very much like this to be an optional part of the specification itself, since I think it's crucial to be able to enumerate list of images that the application needs to run - for build tools, CI systems etc. This not only ensures that all images can be rebuilt the right way, but also allows tools to verify that no unexpected images get used when application is run - hence improving trackability and enabling auditing etc.
Good point, we should allow people to do that. I would however propose to not do this right now, since it opens a whole new can of worms called "how do we reference one part of the file from a different part". If allowed, this should be carefully thought through and handled in a different issue. One more thing that I'd like to add to this proposal is enumerating images that user doesn't want to rebuild/doesn't know their sources etc. Something like:
IOW, this would express that user wants to use image |
Just FYI I created a repo [1] that's supposed to hold the specification of this extension (I finally had to agree that this will be an extension after an offline discussion :)) |
Background
I'm working on a tool called atomicapp-builder [1], that should be able to rebuild a whole Nulecule app based on a given Nulecule file and cccp-index [2].
Terminology
While working on atomicapp-builder, I realized that Nulecule operates with two types of images, that don't really have names in Nulecule documentation (at least I didn't find the names :)). I'll call them meta images and binary images throughout this proposal:
Problem statement
While current Nulecule specification, combined with a cccp-index, allows resolving what meta images need to be built for an application to work, there is no general way to tell what binary images need to be built and how. This is problematic for my use case, since atomicapp-builder should be able to build all images from scratch.
Proposal
I'd like to propose an addition of optional field called
images
forgraph
items. This field, if used, would provide information required to build binary images for the application. An example follows:I think the example is quite self-explanatory, so I'll just comment very briefly:
images
is a list of json objects with following properties:name
(required) - name of the image to buildsource
(required) - SCM repository URLscm_type
(optional) - type of SCM to use, defaults togit
build_configs
(optional) - a json object containing named build configurations; only 2 configs are allowed -stable
andmaster
branch
ortag
; the default isbranch: master
branch
ortag
(optional) - branch or tag to build fromimage_type
(optional) - type of containerization engine to build image for, defaults todocker
image_buildfile
(optional) - path of build file of the image inside the repo, defaults toDockerfile
Things to consider / Q&A
A: Since the field is optional, this is not a problem. Some tooling may however require providing list of all images that will be needed for the application; if an incomplete list is provided, this tooling may be unable to work with the application.
A: So that there is a builtin way to specify how to build various versions of this application, e.g. the latest development version, the latest stable version, a specific released version, etc... The tooling used for building Nulecule apps shall expose options to select one of the build configs.
A: This crossed my mind, but I'm not sure how to sanely implement this in the build tooling. The problem is that the set of images to build is unknown prior to invoking the build, so a defined set of configurations makes sense (I can't specify configs for images that I don't know will be built). OTOH the problem is, that I may want to be building my app with
latest
config, but all its dependencies instable
config... I'm a bit torn here, another opinion would be appreciated!A: I don't know, you tell me :) If someone can think of a nicer/more concise way, I'll be happy to see it!
CC @arrfab @vpavlin @kbsingh
[1] https://github.com/bkabrda/atomicapp-builder/
[2] https://github.com/kbsingh/cccp-index/
The text was updated successfully, but these errors were encountered: