{"action":"created","comment":{"url":"https://api.github.com/repos/openshift/openshift-docs/pulls/comments/24144667","id":24144667,"diff_hunk":"@@ -5,143 +5,186 @@\n :icons:\n :experimental:\n :toc: macro\n-:toc-title: \n+:toc-title:\n \n toc::[]\n \n == Overview\n-When creating Docker images to run on OpenShift there are a number of best practices to consider in order to ensure consumers of those images have a good experience.  Since images are intended to be immutable and used as is, it is the image author's responsibility to ensure the image contains any artifacts that would typically be needed by a user of the image and that the image can be configured by the user.  Here are some general comments around things to consider.\n+When creating Docker images to run on OpenShift, there are a number of best practices to consider as an image author to ensure a good experience for consumers of those images. Because images are intended to be immutable and used as is, it is your responsibility to ensure:\n \n-== General Docker Best Practices\n-The following are some guidelines that apply to Docker image creation in general, independent of whether the images are used on OpenShift v3.\n+- the image contains any artifacts that would typically be needed by a user of the image, and\n+- the image can be configured by the user.\n \n-=== Reuse images\n-Whereever possible you should base your image on an appropriate upstream image via the `FROM` statement.  This will ensure that your image can easily pick up security fixes\n-from an upstream image when it is updated, rather than you being responsible for updating your dependencies directly.  \n+== General Docker Guidelines\n+The following are some guidelines that apply to Docker image creation in general, independent of whether the images are used on OpenShift. See the official https://docs.docker.com/articles/dockerfile_best-practices/[Docker documentation] for more comprehensive guidelines.\n \n-In addition, you should use tags in the `FROM` instruction (for example `rhel:rhel7`) will make it clear to users exactly which version of an image your image is based on.  If you use a tag other than `latest` this ensures that your image is not subjected to breaking changes that might go into the `latest` version of an upstream image.\n+*Reusing Images*\n \n-=== Tagging images\n-When tagging your own images, you should strive to maintain backwards compatibility within a tag.  For example, if you provide an image named \"foo\" and it currently includes version 1.0, you might provide a tag of \"foo:v1\".  When you update the image, as long as it continues to be compatible with the orginal image, you can continue to tag the new image \"foo:v1\" and downstream consumers of this tag will be able to get updates without being broken.  If you come out with an incompatible update, then you should switch to a new tag, e.g. \"foo:v2\".  This allows downstream consumers to move up to the new version at will, but not be inadvertently broken by the new incompatible image.\n+Wherever possible, base your image on an appropriate upstream image using the `FROM` statement. This ensures your image can easily pick up security fixes from an upstream image when it is updated, rather than you being responsible for updating your dependencies directly.\n \n-Of course any downstream consumer who chooses to use \"foo:latest\" will be taking on the risk of any incompatible changes introduced.\n+In addition, use tags in the `FROM` instruction (for example,  `rhel:rhel7`) to make it clear to users exactly which version of an image your image is based on. Using a tag other than `latest` ensures your image is not subjected to breaking changes that might go into the `latest` version of an upstream image.\n \n+*Tagging Images*\n \n-=== Do not start multiple processes\n-It is not a good idea to start multiple services (like database, sshd, …​) inside one container. Containers are lighweight and can be easily linked together for multiprocess orchestration.  OpenShift allows you to easily colocate and comanage related images by grouping them into a single pod.  This will ensure they share a network namespace and storage for communication.  It also makes updates less disruptive as each image can be updated less frequently and independently.  Having a single process also makes signal handling flows clearer as you do not need to manage routing signals to spawned processes.\n+When tagging your own images, strive to maintain backwards compatibility within a tag. For example, if you provide an image named [sysitem]#foo# and it currently includes version 1.0, you might provide a tag of _foo:v1_. When you update the image, as long as it continues to be compatible with the original image, you can continue to tag the new image _foo:v1_, and downstream consumers of this tag will be able to get updates without being broken.\n \n+If you later release an incompatible update, then you should switch to a new tag, for example _foo:v2_. This allows downstream consumers to move up to the new version at will, but not be inadvertently broken by the new incompatible image. Of course, any downstream consumer who chooses to use _foo:latest_ will be taking on the risk of any incompatible changes introduced.\n \n-=== Use exec in wrapper scripts\n-See http://www.projectatomic.io/docs/docker-image-author-guidance/, subsection _Always `exec` in Wrapper Scripts_\n+*Avoiding Multiple Processes*\n \n-Also be aware that your process runs as PID 1 when running in a Docker container.  This means that if your main process terminates, the entire container will be stopped, killing any child processes you may have launched from your PID 1 process.  Additional implications to be aware of are documented http://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/[here].  For a deep dive on PID 1 and init systems, you can read https://felipec.wordpress.com/2013/11/04/init/[this] as well.\n+Do not start multiple services, such a database and [sysitem]#sshd#, inside one container. Containers are lightweight and can be easily linked together for multiprocess orchestration. OpenShift allows you to easily collocate and comanage related images by grouping them into a single pod.\n \n+This collocation ensures they share a network namespace and storage for communication. It also makes updates less disruptive as each image can be updated less frequently and independently. Having a single process also makes signal handling flows clearer as you do not need to manage routing signals to spawned processes.\n \n-=== Clean temporary files\n-Every temporary files you create during the build process should be removed. This includes any files added with the ADD command too.  For example it is strongly recommended you run yum clean after performing yum install operations.  If you craft your `RUN` statement as follows, you an prevent the yum cache from ending up in an image layer:\n+*Using `exec` in Wrapper Scripts*\n \n-\tRUN yum -y install mypackage && yum -y install myotherpackage && yum clean all -y\n+See the \"Always `exec` in Wrapper Scripts\" section of the http://www.projectatomic.io/docs/docker-image-author-guidance[Project Atomic documentation] for more information.\n+\n+Also be aware that your process runs as PID 1 when running in a Docker container. This means that if your main process terminates, the entire container is stopped, killing any child processes you may have launched from your PID 1 process.\n+\n+See the http://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/[\"Docker and the PID 1 zombie reaping problem\"] blog article for additional implications. See the https://felipec.wordpress.com/2013/11/04/init/[\"Demystifying the init system (PID 1)\"] blog article for a deep dive on PID 1 and [sysitem]#init# systems, as well.\n+\n+\n+*Cleaning Temporary Files*\n+\n+Every temporary files you create during the build process should be removed. This includes any files added with the `ADD` command, too.  For example, it is strongly recommended you run the `yum clean` command after performing `yum install` operations.\n+\n+If you craft your `RUN` statement as follows, you can prevent the `yum` cache from ending up in an image layer:\n+\n+----\n+RUN yum -y install mypackage && yum -y install myotherpackage && yum clean all -y\n+----\n \n Be aware that if you instead write:\n-\t\t\n-\t\tRUN yum -y install mypackage\n-\t\tRUN yum -y install myotherpackage && yum clean all -y\n \n-Then the first `yum` invocation will leave extra files in that layer which cannot be removed by the later clean operation.  (The extra files will not be visible in the final image but they will be present in the underlying layers).\n+----\n+RUN yum -y install mypackage\n+RUN yum -y install myotherpackage && yum clean all -y\n+----\n+\n+Then the first `yum` invocation leaves extra files in that layer which cannot be removed by the later `yum clean` operation. The extra files are not visible in the final image, but they are present in the underlying layers.\n+\n+The current Docker build process does not allow a command run in a later later to shrink the space used by the image when something was removed in an earlier layer. However, this may change in the future. This means that if you perform an `rm` command in a later layer, the files are hidden but it does not reduce the overall size of the image that needs to be downloaded. Therefore, as with the `yum clean` example, it is best to remove files in the same command that created them, where possible, so they do not end up written to a layer.\n+\n+In addition, performing multiple commands in a single `RUN` statement reduces the number of layers in your image, which improves download and extraction time.\n+\n+*Placing Instructions in Proper Order*\n \n-Although the current Docker build process does not allow shrinking the space used by the image when we remove something from an earlier layer by a command run in a later layer, this may change in the future.   This means that if you perform an `rm` command in a later layer, you will hide the files but you will not reduce the overall size of the image that needs to be downloaded.  Therefore, as with the yum clean example, it's best to remove files in the same command that created them, where possible, so they do not end up written to a layer.  \n+Docker reads the [sysitem]#Dockerfile# and runs the instructions from top to bottom. Every successfully executed instruction creates a layer which can be reused the next time this or another image is built. It is very important to place instructions that will rarely change at the top of your [sysitem]#Dockerfile#. Doing so ensures the next builds of the same image are very fast because the cache is not invalidated by upper layer changes.\n \n-In addition, performing multiple commands in a single `RUN` statement will reduce the number of layers in your image which will improve download and extraction time.\n+For example, if you are working on a [sysitem]#Dockerfile# that contains an `ADD` command to install a file you are iterating on, and a `RUN` command to `yum install` a package, it is best to put the `ADD` command last:\n \n+----\n+FROM foo\n+RUN yum -y install mypackage && yum clean all -y\n+ADD myfile /test/myfile\n+----\n \n-=== Place instructions in proper order\n-Docker reads the Dockerfile and runs the instructions from top to bottom. Every successfully executed instruction creates a layer which can be reused next we build this (or other image). It is very important to place on top of your Dockerfile instructions that will change rarely.\n+This way each time you edit `myfile` and rerun `docker build`, the system reuses the cached layer for the `yum` command and only generates the new layer for the `ADD` operation.\n \n-This will make sure the next builds of the same image will be very fast because the cache will not be invalidated by upper layer changes.\n+If instead you wrote the [sysitem]#Dockerfile# as:\n \n-For example, if you are working on a Dockerfile that contains an `ADD` command to install a file you are iteratin on, and a `RUN` command to yum install a package, it's best to put the `ADD` command last, such as:\n+----\n+FROM foo\n+ADD myfile /test/myfile\n+RUN yum -y install mypackage && yum clean all -y\n+----\n \n-\t\tFROM foo\n-\t\tRUN yum -y install mypackage && yum clean all -y\n-\t\tADD myfile /test/myfile\n+Then each time you changed `myfile` and reran `docker build`, the `ADD` operation would invalidate the `RUN` layer cache, so the `yum` operation would need to be rerun as well.\n \n-This way each time you edit `myfile` and rerun `docker build` the system will reuse the cached layer for the yum command and only have to generate the new layer for the `ADD` operation.\n+*Using `EXPOSE` to Mark Important Ports*\n \n-If instead you wrote the Dockerfile as:\n+See the \"Always `EXPOSE` Important Ports\" section of the http://www.projectatomic.io/docs/docker-image-author-guidance[Project Atomic documentation] for more information.\n \n-\t\tFROM foo\n-\t\tADD myfile /test/myfile\n-\t\tRUN yum -y install mypackage && yum clean all -y\n+*Setting Environment Variables with `ENV`*\n \n-Then each time you changed `myfile` and reran `docker build`, the `ADD` operation would invalidate the `RUN` layer cache so the yum operation would need to be rerun as well.\n+It is good practice to set environment variables with the `ENV` instruction. One example is to set the version of your project. This makes it easy for people find the version without looking at the [sysitem]#Dockerfile#. Another example is advertising a path on the system that could be used by another process, such as `JAVA_HOME`.\n \n-=== Use EXPOSE to mark important ports\n-See http://www.projectatomic.io/docs/docker-image-author-guidance/, subsection _Always `EXPOSE` Important Ports_\n+*Avoiding Default Passwords*\n \n-=== Set environment variables with ENV\n-It’s a good idea to set environment variables with the `ENV` instruction. One example is to set version of your project. This will make it easy for people find the version without even looking at the Dockerfile.  Another example of an environment variable worth setting is when to advertise some path on the system that could be used by some process, like `JAVA_HOME`.\n+Do not set default passwords. Many people will extend the image and forget to remove or change the default password. This can lead to security issues if there is a user with a well-known password in production. Passwords should be configurable using an environment variable instead. See the link:#using-env-vars[Using Environment Variables for Configuration] topic for more information.\n \n-=== Do not set default passwords\n-It is not a good idea to set default passwords. Many people will extend the image and forget to remove or change the default password. This will lead to security issues where in production there will be a user with a well-known passwords. Passwords should be configurable via environment variable instead (See anchor:configuration[])\n+If you do choose to set a default password, ensure that an appropriate warning message is displayed when the container is started. The message should inform the user of the value of the default password and explain how to change it, such as what environment variable to set.\n \n-If you do choose to set a default password, ensure that an appropriate warning message is displayed when the container is started.  The message should inform the user of the value of the default password and explaining how to change it (e.g. what environment variable to set).\n+*Avoiding SSHD*\n \n-=== Do not start (or install) SSHD\n-Running SSHD should be avoided.  For accessing running containers you can use `docker exec` locally, or the OpenShift tooling which allows execution of arbitrary commands in running images.  Installing and running SSHD in your image opens up additional vectors for attack and requirements for security patching.\n+Do not start or install SSHD in your image. For accessing running containers, you can use the `docker exec` command locally, or the OpenShift tooling which allows execution of arbitrary commands in running images. Installing and running SSHD in your image opens up additional vectors for attack and requirements for security patching.\n \n-=== Use Volumes for Persisted Data\n-Images should expect to use a https://docs.docker.com/reference/builder/#volume[Docker volume] for persisted data.  This way the OpenShift system can mount network storage to the node where the container is running and then reattach that storage at a new node if the container moves.  By using the volume for all persisted storage needs, the content will be preserved throughout container restarts and moves.  If your image writes data to arbitrary locations within the container, there is no guarantee that content will be preserved.\n+*Using Volumes for Persisted Data*\n \n-All data which is expected to live longer than the container must be written to a volume.  With Docker 1.5 there will be a `readonly` flag for containers which can be used to strictly enforce good practices about not writing data to ephemeral storage in a container, so designing your image around that capability now will make it easier to take advantage of it later.\n+Images should expect to use a https://docs.docker.com/reference/builder/#volume[Docker volume] for persisted data. Doing so allows OpenShift to mount network storage to the node where the container is running, then reattach that storage at a new node if the container moves. By using the volume for all persisted storage needs, the content is preserved throughout container restarts and moves. If your image writes data to arbitrary locations within the container, there is no guarantee that content will be preserved.\n \n-Furthermore, by explicitly defining volumes in your Dockerfile, you make it easy for consumers of the image to understand what volumes they need to define when running your image.\n+All data which is expected to live longer than the container must be written to a volume. With Docker 1.5, there will be a `readonly` flag for containers which can be used to strictly enforce good practices about not writing data to ephemeral storage in a container. Designing your image around that capability now will make it easier to take advantage of it later.\n \n+Furthermore, explicitly defining volumes in your [sysitem]#Dockerfile# makes it easy for consumers of the image to understand what volumes they need to define when running your image.\n+\n+See the https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/volumes.md[Kubernetes documentation] for more information on how volumes are used in OpenShift.\n+\n+////\n For more information on how Volumes are used in OpenShift, see https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/volumes.md[this documentation]. (NOTE to docs team:  this link should really go to something in the openshift docs, once we have it)\n+////\n+\n+NOTE: Even with persisted volumes, each instance of your image has its own volume, and the filesystem is not shared between instances.  This means the volume cannot be used to share state in a cluster.\n+\n+== OpenShift-Specific Guidelines\n+The following are guidelines that apply when creating Docker images specifically for use on OpenShift.\n+\n+*Enabling Images for Source-To-Image (STI)*\n+\n+For images that are intended to run application code provided by a third party, such as a Ruby image designed to run Ruby code provided by a developer, you can enable your image to work with the https://github.com/openshift/source-to-image[Source-to-Image (STI)]  build tool. STI is a framework which makes it easy to write images that take application source code as an input and produce a new image that runs the assembled application as output.\n+\n+For example, this https://github.com/openshift/wildfly-8-centos[Wildfly image] defines STI scripts which run a `maven` build on a Java source repository and copy the resulting [sysitem]#war# file into the Wildfly deployments directory. The resulting image now automatically starts Wildfly with the application running.\n+\n+For more details about how to write STI scripts for your image, see the link:sti.html[STI Requirements] topic.\n+\n+[[using-services]]\n+*Using Services for Inter-image Communication*\n+\n+For cases where your image needs to communicate with a service provided by another image, such as a web front end image that needs to access a database image to store and retrieve data, your image should consume an OpenShift link:../architecture/kubernetes_model.html#service[service]. Services provide a static endpoint for access which does not change as containers are stopped, started, or moved. In addition, services provide load balancing for requests.\n \n-Keep in mind that even with persisted volumes, each instance of your image will have its own volume, the filesystem is not shared between instances.  This means the volume cannot be used to share state in a cluster.\n+////\n+For more information see https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/services.md[this documentation].  (NOTE to docs team:  this link should really go to something in the openshift docs once we have it)\n+////\n \n+*Providing Common Libraries*\n \n+For images that are intended to run application code provided by a third party, ensure that your image contains commonly used libraries for your platform. In particular, provide database drivers for common databases used with your platform. For example, provide JDBC drivers for MySQL and PostgreSQL if you are creating a Java framework image. Doing so prevents the need for common dependencies to be downloaded during application assembly time, speeding up application image builds. It will also simplify the work required by application developers to ensure all of their dependencies are met.\n \n-== OpenShift Specific Recommendations\n-=== Enable images for Source-To-Image\n-For images that are intended to run application code provided by a third party (e.g. a Ruby image designed to run Ruby coded provided by a developer), you should enable your image to work with the https://github.com/openshift/source-to-image[Source to Image] (STI) build tool.  It is a framework which makes it easy to write images that take application source code as an input, and produce a new image that will run the assembled application as output.  For example, this https://github.com/openshift/wildfly-8-centos[Wildfly] image defines STI scripts which will run a `maven` build on a java source repository and copy the resulting war file into the Wildfly deployments directory.  The resulting image will now automatically start Wildfly with the application running.\n+[[using-env-vars]]\n+*Using Environment Variables for Configuration*\n \n-For more details about how to write STI scripts for your image, see the https://github.com/openshift/source-to-image/blob/master/docs/builder_image.md[STI documentation].\n+Users of your image should be able to configure it without having to create a downstream image based on your image. This means that the runtime configuration should be handled using environment variables.\n+For a simple configuration, the running process can consume the environment variables directly. For a more complicated configuration or for runtimes which do not support this, configure the runtime by defining a template configuration file which is processed during startup. During this processing, values supplied using environment variables can be substituted into the configuration file or used to make decisions about what options to set in the configuration file.","path":"image_writers_guide/guidelines.adoc","position":209,"original_position":209,"commit_id":"7bd4f3e1ea0e129bf9dc8a16da2d631db2e4dba5","original_commit_id":"7bd4f3e1ea0e129bf9dc8a16da2d631db2e4dba5","user":{"login":"CowboysFan","id":5652976,"avatar_url":"https://avatars.githubusercontent.com/u/5652976?v=3","gravatar_id":"","url":"https://api.github.com/users/CowboysFan","html_url":"https://github.com/CowboysFan","followers_url":"https://api.github.com/users/CowboysFan/followers","following_url":"https://api.github.com/users/CowboysFan/following{/other_user}","gists_url":"https://api.github.com/users/CowboysFan/gists{/gist_id}","starred_url":"https://api.github.com/users/CowboysFan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/CowboysFan/subscriptions","organizations_url":"https://api.github.com/users/CowboysFan/orgs","repos_url":"https://api.github.com/users/CowboysFan/repos","events_url":"https://api.github.com/users/CowboysFan/events{/privacy}","received_events_url":"https://api.github.com/users/CowboysFan/received_events","type":"User","site_admin":false},"body":"[Suggestion]\r\nFor a more complicated configuration or for runtimes which do not support this, configure the runtime by defining a template configuration file which is processed during startup.\r\n\r\ns/which/that","created_at":"2015-02-05T05:55:02Z","updated_at":"2015-02-05T05:55:02Z","html_url":"https://github.com/openshift/openshift-docs/pull/126#discussion_r24144667","pull_request_url":"https://api.github.com/repos/openshift/openshift-docs/pulls/126","_links":{"self":{"href":"https://api.github.com/repos/openshift/openshift-docs/pulls/comments/24144667"},"html":{"href":"https://github.com/openshift/openshift-docs/pull/126#discussion_r24144667"},"pull_request":{"href":"https://api.github.com/repos/openshift/openshift-docs/pulls/126"}}},"pull_request":{"url":"https://api.github.com/repos/openshift/openshift-docs/pulls/126","id":28675675,"html_url":"https://github.com/openshift/openshift-docs/pull/126","diff_url":"https://github.com/openshift/openshift-docs/pull/126.diff","patch_url":"https://github.com/openshift/openshift-docs/pull/126.patch","issue_url":"https://api.github.com/repos/openshift/openshift-docs/issues/126","number":126,"state":"open","locked":false,"title":"Edits to all image_writers_guide topics.","user":{"login":"adellape","id":3442316,"avatar_url":"https://avatars.githubusercontent.com/u/3442316?v=3","gravatar_id":"","url":"https://api.github.com/users/adellape","html_url":"https://github.com/adellape","followers_url":"https://api.github.com/users/adellape/followers","following_url":"https://api.github.com/users/adellape/following{/other_user}","gists_url":"https://api.github.com/users/adellape/gists{/gist_id}","starred_url":"https://api.github.com/users/adellape/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/adellape/subscriptions","organizations_url":"https://api.github.com/users/adellape/orgs","repos_url":"https://api.github.com/users/adellape/repos","events_url":"https://api.github.com/users/adellape/events{/privacy}","received_events_url":"https://api.github.com/users/adellape/received_events","type":"User","site_admin":false},"body":"A run at edits for style/structure/formatting on the image guidelines/testing topics.\r\n\r\n@bparees @soltysh @mfojtik Looking for review as the initial authors and/or reviewers of these topics.\r\n","created_at":"2015-02-04T21:16:04Z","updated_at":"2015-02-05T05:55:02Z","closed_at":null,"merged_at":null,"merge_commit_sha":"9bf0fbea46f801f1cfb111290ef8ee424bed2032","assignee":null,"milestone":null,"commits_url":"https://api.github.com/repos/openshift/openshift-docs/pulls/126/commits","review_comments_url":"https://api.github.com/repos/openshift/openshift-docs/pulls/126/comments","review_comment_url":"https://api.github.com/repos/openshift/openshift-docs/pulls/comments/{number}","comments_url":"https://api.github.com/repos/openshift/openshift-docs/issues/126/comments","statuses_url":"https://api.github.com/repos/openshift/openshift-docs/statuses/7bd4f3e1ea0e129bf9dc8a16da2d631db2e4dba5","head":{"label":"adellape:imagewritersguide_edits","ref":"imagewritersguide_edits","sha":"7bd4f3e1ea0e129bf9dc8a16da2d631db2e4dba5","user":{"login":"adellape","id":3442316,"avatar_url":"https://avatars.githubusercontent.com/u/3442316?v=3","gravatar_id":"","url":"https://api.github.com/users/adellape","html_url":"https://github.com/adellape","followers_url":"https://api.github.com/users/adellape/followers","following_url":"https://api.github.com/users/adellape/following{/other_user}","gists_url":"https://api.github.com/users/adellape/gists{/gist_id}","starred_url":"https://api.github.com/users/adellape/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/adellape/subscriptions","organizations_url":"https://api.github.com/users/adellape/orgs","repos_url":"https://api.github.com/users/adellape/repos","events_url":"https://api.github.com/users/adellape/events{/privacy}","received_events_url":"https://api.github.com/users/adellape/received_events","type":"User","site_admin":false},"repo":{"id":29119125,"name":"openshift-docs","full_name":"adellape/openshift-docs","owner":{"login":"adellape","id":3442316,"avatar_url":"https://avatars.githubusercontent.com/u/3442316?v=3","gravatar_id":"","url":"https://api.github.com/users/adellape","html_url":"https://github.com/adellape","followers_url":"https://api.github.com/users/adellape/followers","following_url":"https://api.github.com/users/adellape/following{/other_user}","gists_url":"https://api.github.com/users/adellape/gists{/gist_id}","starred_url":"https://api.github.com/users/adellape/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/adellape/subscriptions","organizations_url":"https://api.github.com/users/adellape/orgs","repos_url":"https://api.github.com/users/adellape/repos","events_url":"https://api.github.com/users/adellape/events{/privacy}","received_events_url":"https://api.github.com/users/adellape/received_events","type":"User","site_admin":false},"private":false,"html_url":"https://github.com/adellape/openshift-docs","description":"OpenShift Documentation","fork":true,"url":"https://api.github.com/repos/adellape/openshift-docs","forks_url":"https://api.github.com/repos/adellape/openshift-docs/forks","keys_url":"https://api.github.com/repos/adellape/openshift-docs/keys{/key_id}","collaborators_url":"https://api.github.com/repos/adellape/openshift-docs/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/adellape/openshift-docs/teams","hooks_url":"https://api.github.com/repos/adellape/openshift-docs/hooks","issue_events_url":"https://api.github.com/repos/adellape/openshift-docs/issues/events{/number}","events_url":"https://api.github.com/repos/adellape/openshift-docs/events","assignees_url":"https://api.github.com/repos/adellape/openshift-docs/assignees{/user}","branches_url":"https://api.github.com/repos/adellape/openshift-docs/branches{/branch}","tags_url":"https://api.github.com/repos/adellape/openshift-docs/tags","blobs_url":"https://api.github.com/repos/adellape/openshift-docs/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/adellape/openshift-docs/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/adellape/openshift-docs/git/refs{/sha}","trees_url":"https://api.github.com/repos/adellape/openshift-docs/git/trees{/sha}","statuses_url":"https://api.github.com/repos/adellape/openshift-docs/statuses/{sha}","languages_url":"https://api.github.com/repos/adellape/openshift-docs/languages","stargazers_url":"https://api.github.com/repos/adellape/openshift-docs/stargazers","contributors_url":"https://api.github.com/repos/adellape/openshift-docs/contributors","subscribers_url":"https://api.github.com/repos/adellape/openshift-docs/subscribers","subscription_url":"https://api.github.com/repos/adellape/openshift-docs/subscription","commits_url":"https://api.github.com/repos/adellape/openshift-docs/commits{/sha}","git_commits_url":"https://api.github.com/repos/adellape/openshift-docs/git/commits{/sha}","comments_url":"https://api.github.com/repos/adellape/openshift-docs/comments{/number}","issue_comment_url":"https://api.github.com/repos/adellape/openshift-docs/issues/comments/{number}","contents_url":"https://api.github.com/repos/adellape/openshift-docs/contents/{+path}","compare_url":"https://api.github.com/repos/adellape/openshift-docs/compare/{base}...{head}","merges_url":"https://api.github.com/repos/adellape/openshift-docs/merges","archive_url":"https://api.github.com/repos/adellape/openshift-docs/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/adellape/openshift-docs/downloads","issues_url":"https://api.github.com/repos/adellape/openshift-docs/issues{/number}","pulls_url":"https://api.github.com/repos/adellape/openshift-docs/pulls{/number}","milestones_url":"https://api.github.com/repos/adellape/openshift-docs/milestones{/number}","notifications_url":"https://api.github.com/repos/adellape/openshift-docs/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/adellape/openshift-docs/labels{/name}","releases_url":"https://api.github.com/repos/adellape/openshift-docs/releases{/id}","created_at":"2015-01-12T04:47:07Z","updated_at":"2015-02-04T14:47:04Z","pushed_at":"2015-02-04T21:06:51Z","git_url":"git://github.com/adellape/openshift-docs.git","ssh_url":"git@github.com:adellape/openshift-docs.git","clone_url":"https://github.com/adellape/openshift-docs.git","svn_url":"https://github.com/adellape/openshift-docs","homepage":null,"size":871,"stargazers_count":0,"watchers_count":0,"language":"CSS","has_issues":false,"has_downloads":true,"has_wiki":true,"has_pages":false,"forks_count":0,"mirror_url":null,"open_issues_count":0,"forks":0,"open_issues":0,"watchers":0,"default_branch":"master"}},"base":{"label":"openshift:master","ref":"master","sha":"1d7b558a13efeaaca055cda7eaa39df7f483b251","user":{"login":"openshift","id":792337,"avatar_url":"https://avatars.githubusercontent.com/u/792337?v=3","gravatar_id":"","url":"https://api.github.com/users/openshift","html_url":"https://github.com/openshift","followers_url":"https://api.github.com/users/openshift/followers","following_url":"https://api.github.com/users/openshift/following{/other_user}","gists_url":"https://api.github.com/users/openshift/gists{/gist_id}","starred_url":"https://api.github.com/users/openshift/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/openshift/subscriptions","organizations_url":"https://api.github.com/users/openshift/orgs","repos_url":"https://api.github.com/users/openshift/repos","events_url":"https://api.github.com/users/openshift/events{/privacy}","received_events_url":"https://api.github.com/users/openshift/received_events","type":"Organization","site_admin":false},"repo":{"id":21740844,"name":"openshift-docs","full_name":"openshift/openshift-docs","owner":{"login":"openshift","id":792337,"avatar_url":"https://avatars.githubusercontent.com/u/792337?v=3","gravatar_id":"","url":"https://api.github.com/users/openshift","html_url":"https://github.com/openshift","followers_url":"https://api.github.com/users/openshift/followers","following_url":"https://api.github.com/users/openshift/following{/other_user}","gists_url":"https://api.github.com/users/openshift/gists{/gist_id}","starred_url":"https://api.github.com/users/openshift/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/openshift/subscriptions","organizations_url":"https://api.github.com/users/openshift/orgs","repos_url":"https://api.github.com/users/openshift/repos","events_url":"https://api.github.com/users/openshift/events{/privacy}","received_events_url":"https://api.github.com/users/openshift/received_events","type":"Organization","site_admin":false},"private":false,"html_url":"https://github.com/openshift/openshift-docs","description":"OpenShift Documentation","fork":false,"url":"https://api.github.com/repos/openshift/openshift-docs","forks_url":"https://api.github.com/repos/openshift/openshift-docs/forks","keys_url":"https://api.github.com/repos/openshift/openshift-docs/keys{/key_id}","collaborators_url":"https://api.github.com/repos/openshift/openshift-docs/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/openshift/openshift-docs/teams","hooks_url":"https://api.github.com/repos/openshift/openshift-docs/hooks","issue_events_url":"https://api.github.com/repos/openshift/openshift-docs/issues/events{/number}","events_url":"https://api.github.com/repos/openshift/openshift-docs/events","assignees_url":"https://api.github.com/repos/openshift/openshift-docs/assignees{/user}","branches_url":"https://api.github.com/repos/openshift/openshift-docs/branches{/branch}","tags_url":"https://api.github.com/repos/openshift/openshift-docs/tags","blobs_url":"https://api.github.com/repos/openshift/openshift-docs/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/openshift/openshift-docs/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/openshift/openshift-docs/git/refs{/sha}","trees_url":"https://api.github.com/repos/openshift/openshift-docs/git/trees{/sha}","statuses_url":"https://api.github.com/repos/openshift/openshift-docs/statuses/{sha}","languages_url":"https://api.github.com/repos/openshift/openshift-docs/languages","stargazers_url":"https://api.github.com/repos/openshift/openshift-docs/stargazers","contributors_url":"https://api.github.com/repos/openshift/openshift-docs/contributors","subscribers_url":"https://api.github.com/repos/openshift/openshift-docs/subscribers","subscription_url":"https://api.github.com/repos/openshift/openshift-docs/subscription","commits_url":"https://api.github.com/repos/openshift/openshift-docs/commits{/sha}","git_commits_url":"https://api.github.com/repos/openshift/openshift-docs/git/commits{/sha}","comments_url":"https://api.github.com/repos/openshift/openshift-docs/comments{/number}","issue_comment_url":"https://api.github.com/repos/openshift/openshift-docs/issues/comments/{number}","contents_url":"https://api.github.com/repos/openshift/openshift-docs/contents/{+path}","compare_url":"https://api.github.com/repos/openshift/openshift-docs/compare/{base}...{head}","merges_url":"https://api.github.com/repos/openshift/openshift-docs/merges","archive_url":"https://api.github.com/repos/openshift/openshift-docs/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/openshift/openshift-docs/downloads","issues_url":"https://api.github.com/repos/openshift/openshift-docs/issues{/number}","pulls_url":"https://api.github.com/repos/openshift/openshift-docs/pulls{/number}","milestones_url":"https://api.github.com/repos/openshift/openshift-docs/milestones{/number}","notifications_url":"https://api.github.com/repos/openshift/openshift-docs/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/openshift/openshift-docs/labels{/name}","releases_url":"https://api.github.com/repos/openshift/openshift-docs/releases{/id}","created_at":"2014-07-11T15:14:42Z","updated_at":"2015-02-05T00:13:12Z","pushed_at":"2015-02-05T00:13:12Z","git_url":"git://github.com/openshift/openshift-docs.git","ssh_url":"git@github.com:openshift/openshift-docs.git","clone_url":"https://github.com/openshift/openshift-docs.git","svn_url":"https://github.com/openshift/openshift-docs","homepage":null,"size":2169,"stargazers_count":11,"watchers_count":11,"language":"CSS","has_issues":true,"has_downloads":true,"has_wiki":true,"has_pages":false,"forks_count":45,"mirror_url":null,"open_issues_count":6,"forks":45,"open_issues":6,"watchers":11,"default_branch":"master"}},"_links":{"self":{"href":"https://api.github.com/repos/openshift/openshift-docs/pulls/126"},"html":{"href":"https://github.com/openshift/openshift-docs/pull/126"},"issue":{"href":"https://api.github.com/repos/openshift/openshift-docs/issues/126"},"comments":{"href":"https://api.github.com/repos/openshift/openshift-docs/issues/126/comments"},"review_comments":{"href":"https://api.github.com/repos/openshift/openshift-docs/pulls/126/comments"},"review_comment":{"href":"https://api.github.com/repos/openshift/openshift-docs/pulls/comments/{number}"},"commits":{"href":"https://api.github.com/repos/openshift/openshift-docs/pulls/126/commits"},"statuses":{"href":"https://api.github.com/repos/openshift/openshift-docs/statuses/7bd4f3e1ea0e129bf9dc8a16da2d631db2e4dba5"}}}}