Open bkabrda opened 9 years ago
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 :) @bkabrda Very nice, I like it..and I think I don't have any objections to accept it as you proposed it.
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?
build_config:
stable:
tag: $appversion
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 images
section - or the other way around - generate Nulecule
from the information about the binary images (which would be very cool)
Q5: Can we somehow infer the mapping from images
to params:image
? So that user does not have to specify the image name and tag twice? Is that useful or is it just a complication of the spec? (I guess once we have tooling in place developer shouldn't touch Nulecule file directly too often..)
[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.
Q5: Can we somehow infer the mapping from images to params:image? So that user does not have to specify the image name and tag twice? Is that useful or is it just a complication of the spec? (I guess once we have tooling in place developer shouldn't touch Nulecule file directly too often..)
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:
images:
- name: spam/spam
IOW, this would express that user wants to use image spam/spam
and it should be obtained by standard means for given image_type
. (This would effectively make source
optional, which is the only technical change to my original proposal.)
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 :)) I'd like to hear if you guys have some ideas on how the extensions to Nulecule should be handled. Does this seem ok? Do we want to create some kind of list of Nulecule extensions so that people know where to look if they're missing something in the spec? (Should new bug be opened for creating some sort of extension guidelines that would answer these questions?)
@goern is our specification guru so he might weigh in here and comment on a textual representation.
@tradej can help with json schema
Tomáš, would it be possible to somehow validate extensions to the spec like this one? Any ideas?
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
latest
config, but all its dependencies instable
config... I'm a bit torn here, another opinion would be appreciated!CC @arrfab @vpavlin @kbsingh
[1] https://github.com/bkabrda/atomicapp-builder/ [2] https://github.com/kbsingh/cccp-index/