anchor.diff:  
   Similar to labels -- we can specify environment variables that should be present in the container after running the image. We provide `envs` section for this.
   
  -As you can see we have two subsections: `information` and `configuration`. The `information` section is useful to provide environment variables that are meant to be read-only, only providing information. On the other hand the `configuration` section contains environment variables that can (and probably should) be set by the user.
  +As you can see we have two subsections: `information` and `configuration`. The `information` section is useful to provide environment variables that are meant to be read-only and only providing some information. On the other hand the `configuration` section contains environment variables that can (and probably should) be set by the user.
   
   For the `information` envs we just provide `name` and `value`, `description` is optional. For `configuration`, instead of `value`, there is an `example` key which contains an example value. Please note that `description` for configuration envs is required and should be explain what is the variables used for as well as showing the default value (if any).
   
   NOTE: The reason to differentiate between `configuration` and `information` environment variables is that we can use the `image.yaml` as a source to *generate documentation*.
  -
   
   ```yaml
   envs:
  
positive.code: 
  ## Ports
  
  This section is used to mark which ports should be exposed in the container.
  
  ```yaml
  ports:
      - value: 8443
      - value: 8778
  ```
  
  ## Command and entrypoint
  
  You can specify the entrypoint or command that should be used by the container with the `cmd` and `entrypoint`.
  
  NOTE: Both `entrypoint` and `cmd` keys use the exec (array) form of providing its value which is preferred in Docker.
  
  ```yaml
  entrypoint:
  
negative.code:     - hostname
  ```
  
  ## Sources
  
  It will rarely happen that your image won't require external artifacts. In most cases you will want to add files into the image and use them in the image building process. Sources section is meant exactly for this. Dogen will fetch any artifacts specified in this section and addtiionally check their correctness by comptuting specific hash of the downloaded file and comparing it with the desired value.
  
  ```yaml
  sources:
      - url: https://github.com/rhuss/jolokia/releases/download/v1.3.6/jolokia-1.3.6-bin.tar.gz
        md5: 75e5b5ba0b804cd9def9f20a70af649f
  ```
  
  NOTE: Supported hash algorithms are: md5, sha1 and sha256.
  
  ## Scripts
  
  Scipts are the *most important* section in the descriptor file. Scripts are responsible for actually building the image -- all modifications are done in scripts, we do not execute any commands in with `RUN` instrutions directly. A script can be written in any language, as long as its interpreter will be available inside of the image. It is common that scripts are written in Bash.
  
  Scripts are divided into "packages". A package is a set of scripts (but can be only one!) that are together solving a particular problem. For example consider installing a jolokia JAR file into an image. You need to copy the jar file, change the owner and probably modify (or add) some configuration files. Now, it could happen that you need to install jolokia in multiple images - in this case you can share a single package with many images byt just adding it in the scripts section!
  
  For each package you can specify the user that should be used to execute it (`root` by default).
  
  ```yaml
  scripts:
      - package: dynamic-resources
        exec: install.sh
      - package: s2i-common
        exec: install.sh
      - package: java-alternatives
        exec: run.sh
      - package: os-eap7-openshift
        exec: prepare.sh
      - package: os-eap-s2i
        exec: prepare.sh
      - package: os-java-jolokia
        exec: install_as_root
      - package: jolokia
        exec: configure.sh
        user: 185
  ```
  
  ## TBD Volumes
  ## TBD Dogen
  