Hi,
We currently have openshift origin containers being delivered through the Container Pipeline.
However, with the release of openshift origin 1.3, we have to consider how we are going to deliver containers for v1.2.1 and v1.3.
Currently, the dockerfiles basically do a yum install origin[1] and other origin packages. This could possibly result in the latest origin rpms being used even in 1.2.1 containers. We need to consider how we are going to differentiate the versions.
Even if there aren't any updates to 1.2 containers on toe repos, its still possible the containers might get rebuilt from other triggers, such as base image rebuilds and so on.
KB, Troy Dawson, thoughts? Others are welcome to chime in as well.
[1] https://github.com/openshift/origin/blob/release-1.2/images/origin/Dockerfil...
Dirk, havent you guys at RCM thought about that? Or was that just the naming schema for all the different versions of containers?
//G
On Fri, Sep 30, 2016 at 1:22 PM, Mohammed Ahmed moahmed@redhat.com wrote:
Hi,
We currently have openshift origin containers being delivered through the Container Pipeline.
However, with the release of openshift origin 1.3, we have to consider how we are going to deliver containers for v1.2.1 and v1.3.
Currently, the dockerfiles basically do a yum install origin[1] and other origin packages. This could possibly result in the latest origin rpms being used even in 1.2.1 containers. We need to consider how we are going to differentiate the versions.
Even if there aren't any updates to 1.2 containers on toe repos, its still possible the containers might get rebuilt from other triggers, such as base image rebuilds and so on.
KB, Troy Dawson, thoughts? Others are welcome to chime in as well.
[1] https://github.com/openshift/origin/blob/release-
1.2/images/origin/Dockerfile.centos7#L13
*Mohammed Zeeshan Ahmed* Associate Software Engineer, Redhat Developers Team (Devtools) http://mohammedzee1000.wordpress.com
RED HAT | DIFFERENT FOR THE SAKE OF BETTER TECHNOLOGY
Find out why every airline, telecom, commercial bank, healthcare, and financial data services company in the Fortune 500 relies on Red Hat.
Trusted | Red Hat https://www.redhat.com/en/about/trusted
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 30/09/16 12:22, Mohammed Ahmed wrote:
Even if there aren't any updates to 1.2 containers on toe repos, its still possible the containers might get rebuilt from other triggers, such as base image rebuilds and so on.
is there a precidence here ? have there been updates to a prev release ? I guess the way the Dockerfile.CentOS went into 1.2 would potentially constitute a change in pre-code, since Master/ at the time was already 1.3Alpha, but is there another example for say a bugfix or a security update ?
Another way to look at this might be - is there a LTS like model in openshift origin ?
On Mon, Oct 3, 2016 at 7:12 AM, Karanbir Singh mail-lists@karan.org wrote:
On 30/09/16 12:22, Mohammed Ahmed wrote:
Even if there aren't any updates to 1.2 containers on toe repos, its still possible the containers might get rebuilt from other triggers, such as base image rebuilds and so on.
is there a precidence here ? have there been updates to a prev release ? I guess the way the Dockerfile.CentOS went into 1.2 would potentially constitute a change in pre-code, since Master/ at the time was already 1.3Alpha, but is there another example for say a bugfix or a security update ?
Another way to look at this might be - is there a LTS like model in openshift origin ?
Nope
This brings up a very good point I hadn't even thought about. We're trying to treat a rotating product (designed to only use the latest version) in an enterprise / LTS way.
At the moment, I don't have anything else to say, as I said, I hadn't even thought about it until now.
Troy
On Mon, Oct 3, 2016 at 8:42 PM, Troy Dawson tdawson@redhat.com wrote:
On Mon, Oct 3, 2016 at 7:12 AM, Karanbir Singh mail-lists@karan.org wrote:
On 30/09/16 12:22, Mohammed Ahmed wrote:
Even if there aren't any updates to 1.2 containers on toe repos, its still possible the containers might get rebuilt from other triggers, such as base image rebuilds and so on.
is there a precidence here ? have there been updates to a prev release ? I guess the way the Dockerfile.CentOS went into 1.2 would potentially constitute a change in pre-code, since Master/ at the time was already 1.3Alpha, but is there another example for say a bugfix or a security update ?
Another way to look at this might be - is there a LTS like model in openshift origin ?
Nope
This brings up a very good point I hadn't even thought about. We're trying to treat a rotating product (designed to only use the latest version) in an enterprise / LTS way.
At the moment, I don't have anything else to say, as I said, I hadn't even thought about it until now.
Troy _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
So how do we want to proceed with this. Build only the latest containers by updating branch in container-index every time there is a release, or do we want to update the dockerfiles to use more specific rpms by version (will require maintenance of the rpms). In the case of latter we might need LTS.
On Wed, Oct 5, 2016 at 9:06 AM, Mohammed Ahmed moahmed@redhat.com wrote:
On Mon, Oct 3, 2016 at 8:42 PM, Troy Dawson tdawson@redhat.com wrote:
On Mon, Oct 3, 2016 at 7:12 AM, Karanbir Singh mail-lists@karan.org wrote:
On 30/09/16 12:22, Mohammed Ahmed wrote:
Even if there aren't any updates to 1.2 containers on toe repos, its still possible the containers might get rebuilt from other triggers, such as base image rebuilds and so on.
is there a precidence here ? have there been updates to a prev release ? I guess the way the Dockerfile.CentOS went into 1.2 would potentially constitute a change in pre-code, since Master/ at the time was already 1.3Alpha, but is there another example for say a bugfix or a security update ?
Another way to look at this might be - is there a LTS like model in openshift origin ?
Nope
This brings up a very good point I hadn't even thought about. We're trying to treat a rotating product (designed to only use the latest version) in an enterprise / LTS way.
At the moment, I don't have anything else to say, as I said, I hadn't even thought about it until now.
Troy
So how do we want to proceed with this. Build only the latest containers by updating branch in container-index every time there is a release, or do we want to update the dockerfiles to use more specific rpms by version (will require maintenance of the rpms). In the case of latter we might need LTS.
We talked about this during our Paas SIG meeting. We have decided to follow the upstream support model, which is to only support the latest release. So we will only build 1.3 images and not worry about the 1.2 images.
I have created a support page for OpenShift Origin on CentOS. https://wiki.centos.org/SpecialInterestGroup/PaaS/OpenShift-Origin-Support
On a related subject, once we get the rpm build automation in place (both in upstream origin spec/tito code, as well as the CentOS testing/build infrastructure) we do have an paas7-openshift-future tag that we can use to build and push beta's and release candidates. So, while we won't be supporting older releases, we can hopefully become a place that people can test/use the latest and greatest. (even if it's not stable)
Troy
On Thu, Oct 6, 2016 at 10:07 PM, Troy Dawson tdawson@redhat.com wrote:
On Wed, Oct 5, 2016 at 9:06 AM, Mohammed Ahmed moahmed@redhat.com wrote:
On Mon, Oct 3, 2016 at 8:42 PM, Troy Dawson tdawson@redhat.com wrote:
On Mon, Oct 3, 2016 at 7:12 AM, Karanbir Singh mail-lists@karan.org wrote:
On 30/09/16 12:22, Mohammed Ahmed wrote:
Even if there aren't any updates to 1.2 containers on toe repos, its still possible the containers might get rebuilt from other triggers, such as base image rebuilds and so on.
is there a precidence here ? have there been updates to a prev
release ?
I guess the way the Dockerfile.CentOS went into 1.2 would potentially constitute a change in pre-code, since Master/ at the time was already 1.3Alpha, but is there another example for say a bugfix or a security update ?
Another way to look at this might be - is there a LTS like model in openshift origin ?
Nope
This brings up a very good point I hadn't even thought about. We're trying to treat a rotating product (designed to only use the latest version) in an enterprise / LTS way.
At the moment, I don't have anything else to say, as I said, I hadn't even thought about it until now.
Troy
So how do we want to proceed with this. Build only the latest containers
by
updating branch in container-index every time there is a release, or do we want to update the dockerfiles to use more specific rpms by version (will require maintenance of the rpms). In the case of latter we might need LTS.
We talked about this during our Paas SIG meeting. We have decided to follow the upstream support model, which is to only support the latest release. So we will only build 1.3 images and not worry about the 1.2 images.
Sounds good.
I have created a support page for OpenShift Origin on CentOS.
https://wiki.centos.org/SpecialInterestGroup/PaaS/OpenShift-Origin-Support
On a related subject, once we get the rpm build automation in place (both in upstream origin spec/tito code, as well as the CentOS testing/build infrastructure) we do have an paas7-openshift-future tag that we can use to build and push beta's and release candidates. So, while we won't be supporting older releases, we can hopefully become a place that people can test/use the latest and greatest. (even if it's not stable)
So this should leave one last doubt. Do we tag the containers coming from
the origin repo, with only the version tag as we currently are or tag them as latest or both (version tag and latest tag).
Once the infra is in place, we should also consider how we are going the tag those containers as well.
Troy _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-
Christoph Goern -
Karanbir Singh -
Mohammed Ahmed -
Troy Dawson