Hide Forgot
1. Proposed title of this feature request [RFE] Please can we have a way of incrementing image tags associated with triggered builds 3. What is the nature and description of the request? At the moment we have our builds in openshift outputting with a tag of 'latest', e.g. output: to: kind: ImageStreamTag name: 'appdelta:latest' This is ok if we are only ever interested in the lastest version of our application - and it leads to image-streams with only one tag, e.g: - tag: latest items: - created: '2016-04-15T15:42:38Z' dockerImageReference: '172.30.25.186:5000/pret-apps/appdelta@sha256:89e6928f3dfdd5c6cde817c2e8a352b75597c770c685dfa434311ba12c18bb8f' image: 'sha256:89e6928f3dfdd5c6cde817c2e8a352b75597c770c685dfa434311ba12c18bb8f' - created: '2016-04-15T15:29:20Z' dockerImageReference: '172.30.25.186:5000/pret-apps/appdelta@sha256:31491970ac28ce0e903f70309f6906b0d0794e273db58130148c8d373b74c21f' image: 'sha256:31491970ac28ce0e903f70309f6906b0d0794e273db58130148c8d373b74c21f' - This is an awkward way of tracking the different versions of the application and would be easier to manage and understand if we could create a new version tag for every new build. We don't want to have to keep on using the Openshift API to keep updating the BuildConfig object we a new version and would like to be able to two things: - 1. For builds that are triggered by an image change we would like to be able to define an output strategy where the openshift build is able to automatically increment the version tag of the output docker image, e.g. myapplication:1 exists and so the next triggered build creates myapplication:2 (and the latest tag is also automatically updated to 2). e.g. output: to: kind: ImageStreamTag name: 'appdelta' tagStrategy: increment (taking the idea further we might allow the tagStrategy to increment different positions of a multiple version number such as 1.5.3 - so that we could specify we wish for the 1, 5 or 3 to be incremented). 2. For builds that are triggered by a webhook or generic hook we would like to a) pass parameters (already a bugzilla for this) and b) set the output version based on a parameter input by the hook. This would able an external CI server such as Jenkins to choose the new version number and have this version number consistently used within openshift. The openshift deployment, replication controllers could/should be updated to use this version number rather than creating their own arbitrary numbering scheme (presently an incrementing number starting from 1). e.g. A build of myapp is triggered from a generic hook which has a parameter ?version=1.4.2 The build of myapp should output to image myapp:1.4.2 (and latest also points to 1.4.2) The deployment should be numbered 1.4.2 The replication controller and pods should be numbered 1.4.2 This work would allow openshift deployments to better tie in with artifacts elsewhere and will allow us to have more meaningful useful image streams and docker tags which have more value. People keep on saying that 'latest' is NOT a version and so I don't think that we should be outputting only 'latest' tags from our openshift builds.
2. customer SRM yes TAM strategic yes 4. Why does the customer need this? We need this because at the moment in order to integrate Openshift with our build processes we have to write code that reaches into openshift via its API to change the version of an application in both its build and deployment configs so that each new version of each application is tagged. We would like a solution where we don't have to manipulate openshift via its API to drive the functionality we want around the handling of versioning. We are using the Openshift build process to simply wrap our build artefacts in a container. Because our external CI server, bamboo, already has a notion of the version of the artefacts that it has built we would like it to be able to pass these into the openshift build process on the build trigger and have openshift propagate this version through its build process and resultant image tag and deployment configs. I have another simple use-case. I have created a simple Dockerfile build which watches an imagestream of an dockerhub image and builds on it to create a new service (i.e. I watch the glusterfs-centos image and add an application on-top of it that uses the glusterfs client provided by the dockerhub image) . I would like for each time that a new build is triggered by the remove image change, or a manual build, for it to produce a new version tag in my openshift docker repository. I still want for latest to also be tagged to the last image submitted too but I want the docker tag to be the version and not always 'latest'. I recently went to KubeCon in London and 'latest' was often derided as not being a version so it would be good for versioning to be better defined and handled within Openshift 5. How would the customer like to achieve this? We would like mechanisms in the build configs to receive a version string from an external trigger, such as a webhook, and use that version in resultant image output, labels etc. We would like a mechanism in the buildconfigs to choose to automatically increment the output image tag with that version (and we would also like it to still automatically update latest to this version too) We would like the deployconfigs to be able to watch for new versioned tags and in our image streams and update the image tags of the resultant replication controller templates (i.e. pods with the versioned tag). We would like all replications, controllers, pods and containers to be labelled with the version string that was passing into the build process OR the one which was incremented for us. With incrementing versions it would be nice to be able to choose which number to increment in multi-point version numbers, e.g. 2.4.1 (we could choose 1st/major = 3.4.1, 2nd/minor = 2.5.1 or 3rd/build/patch = 2.4.2) personally I would always choose to increment the last least significant digit and let developers choose when they manually want to tag a version to a more significant release. 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. A build triggered by generic hook with a version parameter will output an image with the same version as its tag; the deployment config will reference the new version and the resultant deployed pods will be labelled with the version as passed in on the generic webhook. A simple Dockerfile build in both triggered cases - manual build and remote image trigger will result in a new imagetag appearing in the image stream and latest also being set to the new image, e.g an example resultant imagestream from my dockerfile builder: - Name: gluster-application Created: 6 days ago Labels: template=dockerbuild Annotations: openshift.io/image.dockerRepositoryCheck=2016-04-16T02:09:12Z Docker Pull Spec: 172.30.25.186:5000/infrastructure-builders/gluster-application Tag Spec Created PullSpec Image latest <pushed> 2 days ago 172.30.25.186:5000/infrastructure-builders/gluster-recycler@sha256:08fb4d40d295b46342c18e6925cf32197d07f7f61887325ca1515f4e3c2356b1 1.0.3 <pushed> 2 days ago 172.30.25.186:5000/infrastructure-builders/gluster-recycler@sha256:08fb4d40d295b46342c18e6925cf32197d07f7f61887325ca1515f4e3c2356b1 1.0.2 <pushed> 3 days ago 172.30.25.186:5000/infrastructure-builders/gluster-recycler@sha256:d912e902991180fe4adaa92316738ee3923ebdfc1c5ad332c3ae0eb8f6bee91a 1.0.1 <pushed> 5 days ago 172.30.25.186:5000/infrastructure-builders/gluster-recycler@sha256:fd2acbeb2b971d34a97873fa58d348ac8654a52692059ca0cc876a9ef9f758e8 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? https://bugzilla.redhat.com/show_bug.cgi?id=1328568 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? No but see it as strategic 10. List any affected packages or components. Builds Deployments ImageStreams 11. Would the customer be able to assist in testing this functionality if implemented? yes
This bug has been identified as a dated (created more than 3 months ago) bug. This bug has been triaged (has a trello card linked to it), or reviewed by Engineering/PM and has been put into the product backlog, however this bug has not been slated for a currently planned release (3.9, 3.10 or 3.11), which cover our releases for the rest of the calendar year. As a result of this bugs age, state on the current roadmap and PM Score (being below 70), this bug is being Closed - Differed, as it is currently not part of the products immediate priorities. Please see: https://docs.google.com/document/d/1zdqF4rB3ea8GmVIZ7qWCVYUaQ7-EexUrQEF0MTwdDkw/edit for more details.