From jkaluza at redhat.com Thu Oct 1 06:59:54 2015 From: jkaluza at redhat.com (=?UTF-8?Q?Jan_Kalu=c5=bea?=) Date: Thu, 1 Oct 2015 08:59:54 +0200 Subject: [scl.org] Recommendations for enabling scl for httpd In-Reply-To: References: Message-ID: <560CD9EA.7060105@redhat.com> On 09/29/2015 10:55 PM, Davis, Daniel (NIH/NLM) [C] wrote: > What is the best practice for enabling rh-python34 during the process of > starting Apache httpd as a service? You can add it into /opt/rh/httpd24/service-environment file and httpd24 should automatically enable that service when started using systemd or initscript. Regards, Jan Kaluza > Would it be good to add the following to /etc/sysconfi/httpd: > > if [-f /opt/rh/rh-python34/enable ]; then > > . /opt/rh/rh-python34/enable > > fi > > Thanks, > > Dan Davis, Systems/Applications Architect (Contractor), > > Office of Computer and Communications Systems, > > National Library of Medicine, NIH > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From daniel.davis at nih.gov Thu Oct 1 13:56:40 2015 From: daniel.davis at nih.gov (Davis, Daniel (NIH/NLM) [C]) Date: Thu, 1 Oct 2015 13:56:40 +0000 Subject: [scl.org] Recommendations for enabling scl for httpd In-Reply-To: <560CD9EA.7060105@redhat.com> References: <560CD9EA.7060105@redhat.com> Message-ID: Thanks Jan, We've decided not to run httpd24 because we a choice to build mod_wsgi for standard httpd, or to build mod_auth_cas, mod_jk, and some others for httpd24. EPEL contains the build of mod_auth_cas, and we already have mod_jk. So, basically, the ecosystem for standard httpd is better. We also think that system admins and some dev ops folks will look first in /etc/httpd/conf/httpd.conf for the configuration, and so it is a minor advantage to stick what has been standard in the RedHat world. I'll keep the service environment file in mind as we move forward into softwarecollections gains more module support. Here in security focused government, we like software collections more than Docker, on the whole. Docker is cool, but Nessus can theoretically scan softwarecollections better. Regards, Dan -----Original Message----- From: sclorg-bounces at redhat.com [mailto:sclorg-bounces at redhat.com] On Behalf Of Jan Kalu?a Sent: Thursday, October 01, 2015 3:00 AM To: sclorg at redhat.com Subject: Re: [scl.org] Recommendations for enabling scl for httpd On 09/29/2015 10:55 PM, Davis, Daniel (NIH/NLM) [C] wrote: > What is the best practice for enabling rh-python34 during the process > of starting Apache httpd as a service? You can add it into /opt/rh/httpd24/service-environment file and httpd24 should automatically enable that service when started using systemd or initscript. Regards, Jan Kaluza > Would it be good to add the following to /etc/sysconfi/httpd: > > if [-f /opt/rh/rh-python34/enable ]; then > > . /opt/rh/rh-python34/enable > > fi > > Thanks, > > Dan Davis, Systems/Applications Architect (Contractor), > > Office of Computer and Communications Systems, > > National Library of Medicine, NIH > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > _______________________________________________ SCLorg mailing list SCLorg at redhat.com https://www.redhat.com/mailman/listinfo/sclorg From hhorak at redhat.com Fri Oct 2 10:16:55 2015 From: hhorak at redhat.com (Honza Horak) Date: Fri, 2 Oct 2015 12:16:55 +0200 Subject: [scl.org] Image naming for centos-based images Message-ID: <560E5997.7050203@redhat.com> This is a follow-up for the meeting we had yesterday and which there are minutes from at: https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-October/000946.html One thing that we couldn't solve without any OpenShift representative was naming scheme for the centos images, that are based on SCL packages. Those were originally called (mysql chosen as example): openshift/mysql-55-rhel7 openshift/mysql-55-centos7 the new versions are located under rhscl (RH internal registry) and centos (docker hub) namespaces (variant A): rhscl/mariadb-100-rhel7 centos/mariadb-100-centos7 What we were thinking about yesterday was this scheme (variant B): rhscl/mariadb-100-rhel7 centos/mariadb:10.0 Reasoning for shorter/simpler naming (variant B): * we want to hide the fact that image is using SCL, so there is no need to distinguish between SCL and non-SCL images * there doesn't seem to be a reason to have more variants of one component in the image (if there will be in the future, the name itself should be different) * image name should be simple for users * it is a benefit to use the same scheme as on docker hub * distribution version underneath is usually irrelevant (except some specific cases, like some base libraries; anyway it won't be good enough reason to provide two variants of images just for the sake of different libraries underneath), so the -centos7 suffix is not necessary However, after talking to Ben from OpenShift there are actually some arguments for using distro version and also version in the name (variant A): * Ben claimed the distribution underneath is actually important, because of kernel. Once there is centos8-based image, it might or might not run on centos7 machine. Whether this happens in reality or not, we should at least have a backdoor how to fix it. * version in the image name instead of just tag is handy for the cases where we want to work with :latest tag (used quite a lot in docker world, default behaviour) * no version in the image name also means that if users don't use tags, they will upgrade to newer version once new version is out (which e.g. in case of mysql 5.6 to 5.7 upgrade can cause troubles). * since RH internal naming is not expected to be changed, the new suggested variant will be more confusing for users, since they won't understand that rhscl/mysql-56-rhel7 is the same image as centos/mysql:5.6. * Ben also mentioned users haven't had problems with image naming so far Since there is no ideal solution, we may consider also some compromise, like: centos/mysql-56 ..and have tags for the distribution (centos7) same as centos base image has, which would be a solution for the case distribution would matter once in the future. The general rule for the image name in the centos would be: use for cases where version of the image doesn't care use - for cases where version of the image matters, where it is expected that users will require a specific version of the image and upgrading to a newer version must be always under their control. What do you think? Honza From hhorak at redhat.com Fri Oct 2 12:10:28 2015 From: hhorak at redhat.com (Honza Horak) Date: Fri, 2 Oct 2015 14:10:28 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <560E5997.7050203@redhat.com> References: <560E5997.7050203@redhat.com> Message-ID: <560E7434.5070603@redhat.com> Tomasi, do you happen to see any potential troubles with Variant B bellow, once OSBS is used in centos? like whether something like centos/mariadb:10.0 or centos/mariadb:centos7 wouldn't be problem? Honza On 10/02/2015 12:16 PM, Honza Horak wrote: > This is a follow-up for the meeting we had yesterday and which there are > minutes from at: > https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-October/000946.html > > > One thing that we couldn't solve without any OpenShift representative > was naming scheme for the centos images, that are based on SCL packages. > Those were originally called (mysql chosen as example): > openshift/mysql-55-rhel7 > openshift/mysql-55-centos7 > > the new versions are located under rhscl (RH internal registry) and > centos (docker hub) namespaces (variant A): > rhscl/mariadb-100-rhel7 > centos/mariadb-100-centos7 > > What we were thinking about yesterday was this scheme (variant B): > rhscl/mariadb-100-rhel7 > centos/mariadb:10.0 From mfojtik at redhat.com Fri Oct 2 11:54:36 2015 From: mfojtik at redhat.com (Michal Fojtik) Date: Fri, 2 Oct 2015 13:54:36 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <560E5997.7050203@redhat.com> References: <560E5997.7050203@redhat.com> Message-ID: On Fri, Oct 2, 2015 at 12:16 PM, Honza Horak wrote: > This is a follow-up for the meeting we had yesterday and which there are > minutes from at: > > https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-October/000946.html > > One thing that we couldn't solve without any OpenShift representative was > naming scheme for the centos images, that are based on SCL packages. Those > were originally called (mysql chosen as example): > openshift/mysql-55-rhel7 > openshift/mysql-55-centos7 > > the new versions are located under rhscl (RH internal registry) and centos > (docker hub) namespaces (variant A): > rhscl/mariadb-100-rhel7 > centos/mariadb-100-centos7 > Any reason to have "mariadb-100" and not "mariadb-10" ? Are you planning to release mariadb-101 collection? > > What we were thinking about yesterday was this scheme (variant B): > rhscl/mariadb-100-rhel7 > centos/mariadb:10.0 > > Reasoning for shorter/simpler naming (variant B): > * we want to hide the fact that image is using SCL, so there is no need to > distinguish between SCL and non-SCL images > * there doesn't seem to be a reason to have more variants of one component > in the image (if there will be in the future, the name itself should be > different) > * image name should be simple for users > * it is a benefit to use the same scheme as on docker hub > * distribution version underneath is usually irrelevant (except some > specific cases, like some base libraries; anyway it won't be good enough > reason to provide two variants of images just for the sake of different > libraries underneath), so the -centos7 suffix is not necessary > > However, after talking to Ben from OpenShift there are actually some > arguments for using distro version and also version in the name (variant A): > * Ben claimed the distribution underneath is actually important, because > of kernel. Once there is centos8-based image, it might or might not run on > centos7 machine. Whether this happens in reality or not, we should at least > have a backdoor how to fix it. > * version in the image name instead of just tag is handy for the cases > where we want to work with :latest tag (used quite a lot in docker world, > default behaviour) > * no version in the image name also means that if users don't use tags, > they will upgrade to newer version once new version is out (which e.g. in > case of mysql 5.6 to 5.7 upgrade can cause troubles). > * since RH internal naming is not expected to be changed, the new > suggested variant will be more confusing for users, since they won't > understand that rhscl/mysql-56-rhel7 is the same image as centos/mysql:5.6. > * Ben also mentioned users haven't had problems with image naming so far > > Since there is no ideal solution, we may consider also some compromise, > like: > centos/mysql-56 > > ..and have tags for the distribution (centos7) same as centos base image > has, which would be a solution for the case distribution would matter once > in the future. > > The general rule for the image name in the centos would be: > use for cases where version of the image doesn't care > use - for cases where version of the image > matters, where it is expected that users will require a specific version of > the image and upgrading to a newer version must be always under their > control. > > What do you think? > > Honza > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Fri Oct 2 12:12:05 2015 From: hhorak at redhat.com (Honza Horak) Date: Fri, 2 Oct 2015 14:12:05 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: References: <560E5997.7050203@redhat.com> Message-ID: <560E7495.2030500@redhat.com> On 10/02/2015 01:54 PM, Michal Fojtik wrote: > the new versions are located under rhscl (RH internal registry) and > centos (docker hub) namespaces (variant A): > rhscl/mariadb-100-rhel7 > centos/mariadb-100-centos7 > > > Any reason to have "mariadb-100" and not "mariadb-10" ? Are you planning > to release mariadb-101 collection? > Yes, this is deliberate. MariaDB 10.0 and 10.1 are two major versions, generally incompatible the same as 5.6 and 5.7 will be in case of mysql. Honza From ttomecek at redhat.com Fri Oct 2 12:20:35 2015 From: ttomecek at redhat.com (Tomas Tomecek) Date: Fri, 02 Oct 2015 14:20:35 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <560E7434.5070603@redhat.com> References: <560E5997.7050203@redhat.com> <560E7434.5070603@redhat.com> Message-ID: <20151002122034.2968.86336@oat> Quoting Honza Horak (2015-10-02 14:10:28) > Tomasi, do you happen to see any potential troubles with Variant B > bellow, once OSBS is used in centos? like whether something like > centos/mariadb:10.0 or centos/mariadb:centos7 wouldn't be problem? > > Honza I can't see any troubles. If docker/openshift accepts the name, we're fine. Does the name conform to naming policy? https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md > On 10/02/2015 12:16 PM, Honza Horak wrote: > > This is a follow-up for the meeting we had yesterday and which there are > > minutes from at: > > https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-October/000946.html > > > > > > One thing that we couldn't solve without any OpenShift representative > > was naming scheme for the centos images, that are based on SCL packages. > > Those were originally called (mysql chosen as example): > > openshift/mysql-55-rhel7 > > openshift/mysql-55-centos7 > > > > the new versions are located under rhscl (RH internal registry) and > > centos (docker hub) namespaces (variant A): > > rhscl/mariadb-100-rhel7 > > centos/mariadb-100-centos7 > > > > What we were thinking about yesterday was this scheme (variant B): > > rhscl/mariadb-100-rhel7 > > centos/mariadb:10.0 From hhorak at redhat.com Fri Oct 2 12:24:47 2015 From: hhorak at redhat.com (Honza Horak) Date: Fri, 2 Oct 2015 14:24:47 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <20151002122034.2968.86336@oat> References: <560E5997.7050203@redhat.com> <560E7434.5070603@redhat.com> <20151002122034.2968.86336@oat> Message-ID: <560E778F.4020204@redhat.com> On 10/02/2015 02:20 PM, Tomas Tomecek wrote: > Quoting Honza Horak (2015-10-02 14:10:28) >> Tomasi, do you happen to see any potential troubles with Variant B >> bellow, once OSBS is used in centos? like whether something like >> centos/mariadb:10.0 or centos/mariadb:centos7 wouldn't be problem? >> >> Honza > > I can't see any troubles. > > If docker/openshift accepts the name, we're fine. > > Does the name conform to naming policy? > > https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md Variant A would be much closer to what is there, but there will be differences, because namespace is different and it's nonsense to use -rhel7 suffix for centos images. Honza >> On 10/02/2015 12:16 PM, Honza Horak wrote: >>> This is a follow-up for the meeting we had yesterday and which there are >>> minutes from at: >>> https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-October/000946.html >>> >>> >>> One thing that we couldn't solve without any OpenShift representative >>> was naming scheme for the centos images, that are based on SCL packages. >>> Those were originally called (mysql chosen as example): >>> openshift/mysql-55-rhel7 >>> openshift/mysql-55-centos7 >>> >>> the new versions are located under rhscl (RH internal registry) and >>> centos (docker hub) namespaces (variant A): >>> rhscl/mariadb-100-rhel7 >>> centos/mariadb-100-centos7 >>> >>> What we were thinking about yesterday was this scheme (variant B): >>> rhscl/mariadb-100-rhel7 >>> centos/mariadb:10.0 From hhorak at redhat.com Tue Oct 6 11:59:58 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 6 Oct 2015 13:59:58 +0200 Subject: [scl.org] SRPMs to import to dist-git In-Reply-To: <55F26D6B.1060901@redhat.com> References: <55F26D6B.1060901@redhat.com> Message-ID: <5613B7BE.2000400@redhat.com> I have new lists of SRPMs for importing to dist-git. Karanbir, can you re-try the import, please? https://hhorak.fedorapeople.org/sclo/sclo6-import-v5.csv https://hhorak.fedorapeople.org/sclo/sclo7-import-v5.csv These lists include multiple SRPMs per component, so we can have valid history. The links are in order from lowest nvr to highest nvr, which should always correspond with how we built the packages in cbs.c.o. Honza On 09/11/2015 07:58 AM, Honza Horak wrote: > Karanbir, these are two CSV files with input for SCLo dist-git: > https://hhorak.fedorapeople.org/sclo/sclo6-import-v4.csv > https://hhorak.fedorapeople.org/sclo/sclo7-import-v4.csv > > With that you should be able to mass-import SRPMs to the dist-git somehow.. > > There are these columns: > * status (whether package is built in cbs or not yet) > * collection name > * package name with prefix > * component name (this should be used as repository name) > * branch according > https://wiki.centos.org/BrianStinson/GitBranchesandKojiTags > * link to srpm (either to CBS if exists, otherwise uploaded to my fedora > space) > > Let me know if you need anything more.. > > Thanks, > Honza From hhorak at redhat.com Tue Oct 6 20:08:29 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 6 Oct 2015 22:08:29 +0200 Subject: [scl.org] SRPMs to import to dist-git In-Reply-To: <5613B7BE.2000400@redhat.com> References: <55F26D6B.1060901@redhat.com> <5613B7BE.2000400@redhat.com> Message-ID: <56142A3D.1030001@redhat.com> Hopefully final list, this includes fixed nodejs packages: https://hhorak.fedorapeople.org/sclo/sclo6-import-v6.csv https://hhorak.fedorapeople.org/sclo/sclo7-import-v6.csv Honza On 10/06/2015 01:59 PM, Honza Horak wrote: > I have new lists of SRPMs for importing to dist-git. Karanbir, can you > re-try the import, please? > > https://hhorak.fedorapeople.org/sclo/sclo6-import-v5.csv > https://hhorak.fedorapeople.org/sclo/sclo7-import-v5.csv > > These lists include multiple SRPMs per component, so we can have valid > history. The links are in order from lowest nvr to highest nvr, which > should always correspond with how we built the packages in cbs.c.o. > > Honza > > On 09/11/2015 07:58 AM, Honza Horak wrote: >> Karanbir, these are two CSV files with input for SCLo dist-git: >> https://hhorak.fedorapeople.org/sclo/sclo6-import-v4.csv >> https://hhorak.fedorapeople.org/sclo/sclo7-import-v4.csv >> >> With that you should be able to mass-import SRPMs to the dist-git >> somehow.. >> >> There are these columns: >> * status (whether package is built in cbs or not yet) >> * collection name >> * package name with prefix >> * component name (this should be used as repository name) >> * branch according >> https://wiki.centos.org/BrianStinson/GitBranchesandKojiTags >> * link to srpm (either to CBS if exists, otherwise uploaded to my fedora >> space) >> >> Let me know if you need anything more.. >> >> Thanks, >> Honza From praiskup at redhat.com Tue Oct 6 08:20:38 2015 From: praiskup at redhat.com (Pavel Raiskup) Date: Tue, 06 Oct 2015 10:20:38 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <560E5997.7050203@redhat.com> References: <560E5997.7050203@redhat.com> Message-ID: <1796852.ykjqeie5b3@nb.usersys.redhat.com> On Friday 02 of October 2015 12:16:55 Honza Horak wrote: > This is a follow-up for the meeting we had yesterday and which there are > minutes from at: > https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-October/000946.html > > One thing that we couldn't solve without any OpenShift representative > was naming scheme for the centos images, that are based on SCL packages. > Those were originally called (mysql chosen as example): > openshift/mysql-55-rhel7 > openshift/mysql-55-centos7 > > the new versions are located under rhscl (RH internal registry) and > centos (docker hub) namespaces (variant A): > rhscl/mariadb-100-rhel7 > centos/mariadb-100-centos7 > > What we were thinking about yesterday was this scheme (variant B): > rhscl/mariadb-100-rhel7 > centos/mariadb:10.0 +1 for DISTRO/MAJORCOMPONENT:TAG for now. > Reasoning for shorter/simpler naming (variant B): > * we want to hide the fact that image is using SCL, so there is no need > to distinguish between SCL and non-SCL images I'm not sure about this. Yes, I don't care about "technology" used underneath (SCL), but from the user POV, I would expect 'DISTRO/COMPONENT:MAJORVERSION' image *will* be supported as long as the DISTRO/COMPONENT package. Having there 'centos/mysql-scl:MAJORVER-DISTVER' would much clearer say that the image will be supported for shorter period. If we shipped non-SCL package, as a corporate database-container user -> I would personally prefer a non-SCL package over SCL one because I would have guarantees that the image will work probably 10+ years without any data migration or API breakage (thats what the CentOS policy is about, or?). Thats why I would like to have 'centos/mysql:..' reserved for non-SCL image. The reason why we plan to ship only SCL images for now is that those images are more or less designed for/needed by OpenShift -- and that environment prefers features over long-time support (SCL over non-SCL). > * there doesn't seem to be a reason to have more variants of one > component in the image (if there will be in the future, the name itself > should be different) > * image name should be simple for users > * it is a benefit to use the same scheme as on docker hub > * distribution version underneath is usually irrelevant (except some > specific cases, like some base libraries; anyway it won't be good enough > reason to provide two variants of images just for the sake of different > libraries underneath), so the -centos7 suffix is not necessary Similarly, we'll support CentOS 7 much longer than CentOS 6 from now. If we were able transparently migrate e.g. from 'centos/mysql:X.Y-el6' to 'centos/mysql:X.Y-el7', it wouldn't be a problem and we could omit the distro flag. As long as this long-time support is important for CentOS users in general (and their decision why to choose CentOS image), it is to some extent important to have the info about distro in the "image name" (== repository + tag). > However, after talking to Ben from OpenShift there are actually some > arguments for using distro version and also version in the name (variant A): > * Ben claimed the distribution underneath is actually important, because > of kernel. Once there is centos8-based image, it might or might not run > on centos7 machine. Whether this happens in reality or not, we should at > least have a backdoor how to fix it. > * version in the image name instead of just tag is handy for the cases > where we want to work with :latest tag (used quite a lot in docker > world, default behaviour) > * no version in the image name also means that if users don't use tags, > they will upgrade to newer version once new version is out (which e.g. > in case of mysql 5.6 to 5.7 upgrade can cause troubles). This is _very_ important argument, could we suggest to not use :latest, but rather explicit tag? > * since RH internal naming is not expected to be changed, the new > suggested variant will be more confusing for users, since they won't > understand that rhscl/mysql-56-rhel7 is the same image as centos/mysql:5.6. > * Ben also mentioned users haven't had problems with image naming so far > > Since there is no ideal solution, we may consider also some compromise, > like: > centos/mysql-56 > > ..and have tags for the distribution (centos7) same as centos base image > has, which would be a solution for the case distribution would matter > once in the future. This compromise sounds better to me..: The '-56' suffix could play the role of '-scl' I mentioned above (and clearly say that the mysql component in this image is somehow specific, SCL/OpenShift/.../supported shortly). Docker v2 API [1] seems to implement mutiple "path components" -- so we could later migrate to different schema like "centos/6/mysql:latest".. But taking this into account, the TAG should be IMHO considered as _important_ part of "image name" anyway (while "image name" should at least clearly say non-(SCL), distro version and component-major-version). [1] http://docs.docker.com/registry/spec/api/ Thanks, Pavel > The general rule for the image name in the centos would be: > use for cases where version of the image doesn't care > use - for cases where version of the image > matters, where it is expected that users will require a specific version > of the image and upgrading to a newer version must be always under their > control. > > What do you think? > > Honza > _______________________________________________ > env-and-stacks mailing list > env-and-stacks at lists.fedoraproject.org > https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks From hhorak at redhat.com Wed Oct 7 09:04:52 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 7 Oct 2015 11:04:52 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <560E5997.7050203@redhat.com> References: <560E5997.7050203@redhat.com> Message-ID: <5614E034.8060309@redhat.com> Thank you all for the input. I'm trying to summarize the pros of both variants in-line, because we need to move forward.. On 10/02/2015 12:16 PM, Honza Horak wrote: > variant A: > centos/mariadb-100-centos7 * consistent with what is already standardized in RH [1] * prevents potential issues when platform underneath matters (not clear now whether it is a real issue or not) * is explicit about the version (which is usually important for users, might be important for "support period" specification) * has already been used for now * proofed to be working for OpenShift (users seem to be fine with it) > variant B: > centos/mariadb:10.0 * less complicated * no redundancy * it is similar to what docker hub uses for official images now Well, there is no clear answer here. Since we need to focus on what problems it causes to users, from my PoV, the Variant A brings a bit more, even if it is more complicated and includes redundancy (but it is one-time effort for user to understand the naming and hopefully it is still self-explanatory). Considering also that some images like centos/mariadb-100-centos7 are already available on docker hub, I'm proposing to stay with this variant (A) now. As mentioned in this thread [2], there is a new API spec being prepared [3], which will be a chance to change naming scheme to something less redundant, if the current way proofs to be problematic. I'd like also to propose creating centos variant of naming guidelines [1], which should prevent similar discussion in the future. I see centos being mentioned in the RH guidelines as well, most probably for being consistent, so adding Daniel to CC (who originally wrote the guidelines). [1] https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md [2] https://www.redhat.com/archives/sclorg/2015-October/msg00010.html [3] http://docs.docker.com/registry/spec/api/ Honza From kbsingh at redhat.com Wed Oct 7 09:40:37 2015 From: kbsingh at redhat.com (Karanbir Singh) Date: Wed, 7 Oct 2015 10:40:37 +0100 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <5614E034.8060309@redhat.com> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> Message-ID: <5614E895.7090704@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/10/15 10:04, Honza Horak wrote: > Thank you all for the input. I'm trying to summarize the pros of > both variants in-line, because we need to move forward.. > > On 10/02/2015 12:16 PM, Honza Horak wrote: >> variant A: centos/mariadb-100-centos7 > > * consistent with what is already standardized in RH [1] * prevents > potential issues when platform underneath matters (not clear now > whether it is a real issue or not) * is explicit about the version > (which is usually important for users, might be important for > "support period" specification) * has already been used for now * > proofed to be working for OpenShift (users seem to be fine with > it) > >> variant B: centos/mariadb:10.0 > > * less complicated * no redundancy * it is similar to what docker > hub uses for official images now adding a few more bits here for B : * pretty much the standard way for the entire docker ecosystem to work on right now ( that redhat is largely absent from ) * provides scope for future expansion as we abstract away from delivery mechanics to focus on payload * allows for distro decompose and co-exist in a 'as default' manner ( admittedly arguable! ) A relatively sane proof for this model is looking at how many people run a 'yum install mariadb' V/s 'yum install mariadb-5.5.44-1.el7_1.x86_64' when they want a mariadb install; having a centos/mariadb and using tag space to extend the multiple version availability, allows us to extend the same user expectation. > > Well, there is no clear answer here. Since we need to focus on > what problems it causes to users, from my PoV, the Variant A brings > a bit more, even if it is more complicated and includes redundancy > (but it is one-time effort for user to understand the naming and > hopefully it is still self-explanatory). > > Considering also that some images like centos/mariadb-100-centos7 > are already available on docker hub, I'm proposing to stay with > this variant (A) now. > > As mentioned in this thread [2], there is a new API spec being > prepared [3], which will be a chance to change naming scheme to > something less redundant, if the current way proofs to be > problematic. [1] isnt complete so its clearly a work in progress, how about we just work on getting that complete now and address the whole piece together ? or is the SCL portion left as TBA allowing the scl space to do something completely different ? Secondly, if you consider the inertia against looking at a change now largely driven by we-already-have-something, what are the chances that this is going to go away when the api-spec comes up ( and we have even more water under the bridge ? ). > > I'd like also to propose creating centos variant of naming > guidelines [1], which should prevent similar discussion in the > future. I see centos being mentioned in the RH guidelines as well, > most probably for being consistent, so adding Daniel to CC (who > originally wrote the guidelines). > > [1] > https://github.com/projectatomic/ContainerApplicationGenericLabels/blo b/master/vendor/redhat/names.md > > [2] > https://www.redhat.com/archives/sclorg/2015-October/msg00010.html > [3] http://docs.docker.com/registry/spec/api/ > > Honza regards, - -- Karanbir Singh, The CentOS Project, London, UK RH Ext. 8274455 | DID: 0044 207 009 4455 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWFOiVAAoJEI3Oi2Mx7xbtXHkH/R5V/OgH0BB4u0BT7b8ub3YT sd1AfgXRSXGVDilTTs55l6HfZjFKvkN3r+tvIA6yLS/04IvoZeZkHaFS7txP1sN9 cNJU3a26yEbKJUbsFVkesIfl4mWeds9S/JTIJ9srd6QSRBGW5WfYGtXeV4pdcmDU ifUVbrxLKYuxlG8gKjve6JUPu07JLCkr74a/T7jmSS6ptp5eVH9Yfs5tJKmu0Tiv bBG0c92Pwo3wIpJVNDaBd2DzDKjaxxbUv6wvWKlxi5yuVxmFUcEPOblXqFmfBYja 4FUYp/w5tgJ/GYb4514f83bNYQv+cWvmi8CXR6XSqY+o+9p/oCut/qn54SjgL5o= =5694 -----END PGP SIGNATURE----- From hhorak at redhat.com Thu Oct 8 09:43:53 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 8 Oct 2015 11:43:53 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <5614E895.7090704@redhat.com> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> Message-ID: <56163AD9.6000200@redhat.com> On 10/07/2015 11:40 AM, Karanbir Singh wrote: >>> variant B: centos/mariadb:10.0 >> >> * less complicated * no redundancy * it is similar to what docker >> hub uses for official images now > > adding a few more bits here for B : > > * pretty much the standard way for the entire docker ecosystem to work > on right now ( that redhat is largely absent from ) Fair point. Anyway, what a sane user actually does IMO is not `docker pull mariadb`, but rather `docker pull mariadb:5.5`. And since `docker search centos/mariadb` doesn't show available versions, how can user know which versions are available? there is only centos/mariadb in the output. So, user can only guess what versions are available or can find it somewhere else.. in the case there would be the version in the image name, it would be listed in the search output, which seems like a benefit for user to me. Btw. did you know that there has been already centos/mariadb available on docker hub? > * provides scope for future expansion as we abstract away from > delivery mechanics to focus on payload I still don't consider this to be related to delivery mechanism. > * allows for distro decompose and co-exist in a 'as default' manner ( > admittedly arguable! ) > > A relatively sane proof for this model is looking at how many people > run a 'yum install mariadb' V/s 'yum install > mariadb-5.5.44-1.el7_1.x86_64' when they want a mariadb install; > having a centos/mariadb and using tag space to extend the multiple > version availability, allows us to extend the same user expectation. Sure, nobody runs 'yum install mariadb-5.5.44-1.el7_1.x86_64' and just uses `mariadb`, but we must realize that users always install RPMs for the correct platform (nobody configures yum to install el6 packages on el7) and we also provide only one version of the mariadb in the system, so users are sure what version they get. Once there are more versions (as SCLs or if we find any other format), users will install particular version -- `yum install mariadb55`, because they care (in most cases). Docker is new in this sense because you have all versions build on various kernels on one heap. This is not something we have experience with in RPM world. >> As mentioned in this thread [2], there is a new API spec being >> prepared [3], which will be a chance to change naming scheme to >> something less redundant, if the current way proofs to be >> problematic. > > [1] isnt complete so its clearly a work in progress, how about we just > work on getting that complete now and address the whole piece together > ? or is the SCL portion left as TBA allowing the scl space to do > something completely different ? The SCL part is there already, but covers only RH registry. I wish we could sync on one schema over Fedora/RHEL/CentOS as well, but I don't see a compromise here, that would be fine for all. Or maybe missing willingness to accept some compromise, I don't know. > Secondly, if you consider the inertia against looking at a change now > largely driven by we-already-have-something, what are the chances that > this is going to go away when the api-spec comes up ( and we have even > more water under the bridge ? ). IMO the chance would be big enough if we'll be convinced the current way is not good enough for users. If we'll see the current way is fine for them and doesn't make any troubles, then why changing it.. Honza From mail-lists at karan.org Sat Oct 10 22:29:41 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Sat, 10 Oct 2015 23:29:41 +0100 Subject: [scl.org] validating scls being built Message-ID: <56199155.80901@karan.org> firstly, apologies for the cross post. I've setup an example to illustrate some very simple things we can do to validate a collection. In this case the vagrant collection. https://github.com/kbsingh/validate-vagrant-scl has the test script. It does 2 things: 1) makes sure all the rpms we expect to have in the repo are there. 2) it will install the collection, run a centos/7 vagrant box, and run the centos functional test suite inside the box. if this passes, we can assert that vagrant installed ok, was able to run a libvirt backed box properly, and was able to provide typical expected functionality. There maybe 100s more features of the collection we are not testing here, but that might not be needed if a simple baseline is established. And this test can be run, from triggers in ci.centos.org, watching the 3 repos we care about for the vagrant collection ( ruby22 / ror41 and vagrant itself ). thoughts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From sghosh at redhat.com Sun Oct 11 02:21:51 2015 From: sghosh at redhat.com (Subhendu Ghosh) Date: Sat, 10 Oct 2015 22:21:51 -0400 (EDT) Subject: [scl.org] validating scls being built Message-ID: <6876dc82-8294-4d60-8c4b-b93a98f404dd@redhat.com> It would also be useful if the repo definitions did not use ReleaseVersion to allow use by CentOS and other distroa. Sent from Nine From: Karanbir Singh Sent: Oct 10, 2015 6:29 PM To: centos-devel at centos.org; sclorg at redhat.com Subject: [scl.org] validating scls being built firstly, apologies for the cross post. I've setup an example to illustrate some very simple things we can do to validate a collection. In this case the vagrant collection. https://github.com/kbsingh/validate-vagrant-scl has the test script. It does 2 things: 1) makes sure all the rpms we expect to have in the repo are there. 2) it will install the collection, run a centos/7 vagrant box, and run the centos functional test suite inside the box. if this passes, we can assert that vagrant installed ok, was able to run a libvirt backed box properly, and was able to provide typical expected functionality. There maybe 100s more features of the collection we are not testing here, but that might not be needed if a simple baseline is established. And this test can be run, from triggers in ci.centos.org, watching the 3 repos we care about for the vagrant collection ( ruby22 / ror41 and vagrant itself ). thoughts ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ SCLorg mailing list SCLorg at redhat.com https://www.redhat.com/mailman/listinfo/sclorg -------------- next part -------------- An HTML attachment was scrubbed... URL: From bparees at redhat.com Fri Oct 9 19:41:15 2015 From: bparees at redhat.com (Ben Parees) Date: Fri, 9 Oct 2015 21:41:15 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <56163AD9.6000200@redhat.com> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> Message-ID: Karanbir and I talked briefly today, and i'd like to just lay out a couple things from an openshift perspective: 1) we encourage the use of both rhel and centos images (rhel for support, centos to try), so we really want the images to have the same names (other than the namespace/org) because it makes for a much more consistent transition, better support experience, etc. So i do not like any approach that results in one naming convention for centos images and another for the "rhscl" images. 2) we're shipping OSE3.1 nov 19th and things need to be locked down earlier than that. Since this will be the first release shipping these new SCL images, we have some freedom to change the names now. But once that happens it's going to be much more painful to change them. So if things are changing, we need a decision asap. 3) I suggested that maybe we could use aliases to solve some of this... you can still provide a "mariadb" docker alias for the seamless "i don't care what i get" experience, but still maintain multiple streams of versions/etc by backing that alias with a more specifically named pull spec, like the names we use today. 4) i'm mostly willing to concede dropping the rhel7/centos7 suffice from the names now that we have separate namespaces for the repositories...but keeping the version number in the name still seems important to avoid the issues with users not being able to pull "latest" or not understand what they have pulled. I'm also adding Dan McPherson and Clayton Coleman to this thread as they are the lead architects for OpenShift and should also weigh in on any image naming decisions we're making. On Thu, Oct 8, 2015 at 11:43 AM, Honza Horak wrote: > On 10/07/2015 11:40 AM, Karanbir Singh wrote: > >> variant B: centos/mariadb:10.0 >>>> >>> >>> * less complicated * no redundancy * it is similar to what docker >>> hub uses for official images now >>> >> >> adding a few more bits here for B : >> >> * pretty much the standard way for the entire docker ecosystem to work >> on right now ( that redhat is largely absent from ) >> > > Fair point. Anyway, what a sane user actually does IMO is not `docker pull > mariadb`, but rather `docker pull mariadb:5.5`. And since `docker search > centos/mariadb` doesn't show available versions, how can user know which > versions are available? there is only centos/mariadb in the output. > > So, user can only guess what versions are available or can find it > somewhere else.. in the case there would be the version in the image name, > it would be listed in the search output, which seems like a benefit for > user to me. > > Btw. did you know that there has been already centos/mariadb available on > docker hub? > > * provides scope for future expansion as we abstract away from >> delivery mechanics to focus on payload >> > > I still don't consider this to be related to delivery mechanism. > > * allows for distro decompose and co-exist in a 'as default' manner ( >> admittedly arguable! ) >> >> A relatively sane proof for this model is looking at how many people >> run a 'yum install mariadb' V/s 'yum install >> mariadb-5.5.44-1.el7_1.x86_64' when they want a mariadb install; >> having a centos/mariadb and using tag space to extend the multiple >> version availability, allows us to extend the same user expectation. >> > > Sure, nobody runs 'yum install mariadb-5.5.44-1.el7_1.x86_64' and just > uses `mariadb`, but we must realize that users always install RPMs for the > correct platform (nobody configures yum to install el6 packages on el7) and > we also provide only one version of the mariadb in the system, so users are > sure what version they get. Once there are more versions (as SCLs or if we > find any other format), users will install particular version -- `yum > install mariadb55`, because they care (in most cases). > > Docker is new in this sense because you have all versions build on various > kernels on one heap. This is not something we have experience with in RPM > world. > > As mentioned in this thread [2], there is a new API spec being >>> prepared [3], which will be a chance to change naming scheme to >>> something less redundant, if the current way proofs to be >>> problematic. >>> >> >> [1] isnt complete so its clearly a work in progress, how about we just >> work on getting that complete now and address the whole piece together >> ? or is the SCL portion left as TBA allowing the scl space to do >> something completely different ? >> > > The SCL part is there already, but covers only RH registry. I wish we > could sync on one schema over Fedora/RHEL/CentOS as well, but I don't see a > compromise here, that would be fine for all. Or maybe missing willingness > to accept some compromise, I don't know. > > Secondly, if you consider the inertia against looking at a change now >> largely driven by we-already-have-something, what are the chances that >> this is going to go away when the api-spec comes up ( and we have even >> more water under the bridge ? ). >> > > IMO the chance would be big enough if we'll be convinced the current way > is not good enough for users. If we'll see the current way is fine for them > and doesn't make any troubles, then why changing it.. > > Honza > -- Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbsingh at centos.org Mon Oct 12 11:54:24 2015 From: kbsingh at centos.org (Karanbir Singh) Date: Mon, 12 Oct 2015 12:54:24 +0100 Subject: [scl.org] validating scls being built In-Reply-To: <6876dc82-8294-4d60-8c4b-b93a98f404dd@redhat.com> References: <6876dc82-8294-4d60-8c4b-b93a98f404dd@redhat.com> Message-ID: <561B9F70.40209@centos.org> On 11/10/15 03:21, Subhendu Ghosh wrote: > It would also be useful if the repo definitions did not use > ReleaseVersion to allow use by CentOS and other distroa. let me see if we can parametrise those from the jenkins side of things - should be possible, and we can default to something that works here for the scl/cbs process. regards, > > Sent from Nine > > *From:* Karanbir Singh > *Sent:* Oct 10, 2015 6:29 PM > *To:* centos-devel at centos.org; sclorg at redhat.com > *Subject:* [scl.org] validating scls being built > > firstly, apologies for the cross post. > > I've setup an example to illustrate some very simple things we can do to > validate a collection. In this case the vagrant collection. > > https://github.com/kbsingh/validate-vagrant-scl has the test script. > > It does 2 things: > 1) makes sure all the rpms we expect to have in the repo are there. > 2) it will install the collection, run a centos/7 vagrant box, and run > the centos functional test suite inside the box. if this passes, we can > assert that vagrant installed ok, was able to run a libvirt backed box > properly, and was able to provide typical expected functionality. > > There maybe 100s more features of the collection we are not testing > here, but that might not be needed if a simple baseline is established. > And this test can be run, from triggers in ci.centos.org, watching the 3 > repos we care about for the vagrant collection ( ruby22 / ror41 and > vagrant itself ). > > thoughts ? > > > -- > Karanbir Singh > +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh > GnuPG Key : http://www.karan.org/publickey.asc > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Mon Oct 12 12:55:26 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 12 Oct 2015 14:55:26 +0200 Subject: [scl.org] validating scls being built In-Reply-To: <56199155.80901@karan.org> References: <56199155.80901@karan.org> Message-ID: <561BADBE.4020306@redhat.com> On 10/11/2015 12:29 AM, Karanbir Singh wrote: > firstly, apologies for the cross post. > > I've setup an example to illustrate some very simple things we can do to > validate a collection. In this case the vagrant collection. > > https://github.com/kbsingh/validate-vagrant-scl has the test script. > > It does 2 things: > 1) makes sure all the rpms we expect to have in the repo are there. > 2) it will install the collection, run a centos/7 vagrant box, and run > the centos functional test suite inside the box. if this passes, we can > assert that vagrant installed ok, was able to run a libvirt backed box > properly, and was able to provide typical expected functionality. > > There maybe 100s more features of the collection we are not testing > here, but that might not be needed if a simple baseline is established. > And this test can be run, from triggers in ci.centos.org, watching the 3 > repos we care about for the vagrant collection ( ruby22 / ror41 and > vagrant itself ). > > thoughts ? Thanks, it seems fine to me for the beginning. Matej (cc'd) is also working on some basic sanity tests for collections, not sure how far he is and whether it would do the same (maybe a bit), but last time we checked the status it seemed he will have something pushed into [1] this week. I've also added list of packages that we expect will be available for the rest of the collections [2]. It has slightly different format than yours, but a good thing is that we can share it with what we keep internally for a similar purpose.. [1] https://github.com/sclorg/sclo-ci-tests/ [2] https://github.com/sclorg/sclo-ci-tests/tree/master/PackageLists Honza From mail-lists at karan.org Mon Oct 12 15:30:48 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 12 Oct 2015 16:30:48 +0100 Subject: [scl.org] validating scls being built In-Reply-To: <561BADBE.4020306@redhat.com> References: <56199155.80901@karan.org> <561BADBE.4020306@redhat.com> Message-ID: <561BD228.9030406@karan.org> On 12/10/15 13:55, Honza Horak wrote: > Thanks, it seems fine to me for the beginning. Matej (cc'd) is also > working on some basic sanity tests for collections, not sure how far he > is and whether it would do the same (maybe a bit), but last time we > checked the status it seemed he will have something pushed into [1] this > week. sounds good, I dont see anything there at the moment. let me know when there is something there and we can workout how best to plumb things in. > > I've also added list of packages that we expect will be available for > the rest of the collections [2]. It has slightly different format than > yours, but a good thing is that we can share it with what we keep > internally for a similar purpose.. > > [1] https://github.com/sclorg/sclo-ci-tests/ > [2] https://github.com/sclorg/sclo-ci-tests/tree/master/PackageLists what is the difference between all and main lists ? and you really want to add arch atleast over there, secondly - how are you comparing this with available packages in a remote repo ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Tue Oct 13 07:44:30 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 13 Oct 2015 09:44:30 +0200 Subject: [scl.org] validating scls being built In-Reply-To: <561BD228.9030406@karan.org> References: <56199155.80901@karan.org> <561BADBE.4020306@redhat.com> <561BD228.9030406@karan.org> Message-ID: <561CB65E.70702@redhat.com> On 10/12/2015 05:30 PM, Karanbir Singh wrote: > On 12/10/15 13:55, Honza Horak wrote: >> Thanks, it seems fine to me for the beginning. Matej (cc'd) is also >> working on some basic sanity tests for collections, not sure how far he >> is and whether it would do the same (maybe a bit), but last time we >> checked the status it seemed he will have something pushed into [1] this >> week. > > sounds good, I dont see anything there at the moment. > > let me know when there is something there and we can workout how best to > plumb things in. Sure, we talked with Matej that the tests should be able to be run separately for every collection, so plumbing in should be easy. Karanbir, do you already have some idea what should be the format of output? (if it is important for the ci) The only hard requirement I expect is that the script must end with non-zero exit-code, right? >> >> I've also added list of packages that we expect will be available for >> the rest of the collections [2]. It has slightly different format than >> yours, but a good thing is that we can share it with what we keep >> internally for a similar purpose.. >> >> [1] https://github.com/sclorg/sclo-ci-tests/ >> [2] https://github.com/sclorg/sclo-ci-tests/tree/master/PackageLists > > > what is the difference between all and main lists ? `all` is list of all packages that must be available in repository `main` is list of packages that we expect will be installed when user runs `yum install ` (not all packages are installed in this case obviously) The main set might be checked later, we can ignore it for this time. > and you really want > to add arch atleast over there, The only reason I see is to check whether only correct arches are in the repo, but it doesn't have to be in this list (packages change arches from/to noarch sometimes), we can just check the packages generally in the repo whether it includes only expected arches this way: repoquery --disablerepo=\* --enablerepo=sclo7-sclo-vagrant1-sclo-candidate --qf '%{ARCH} %{NVR}' -a|grep -v -e '^noarch ' -e 'x86_64 ' > secondly - how are you comparing this > with available packages in a remote repo ? I'd use something like that: repoquery --disablerepo=\* --enablerepo=sclo7-sclo-vagrant1-sclo-candidate --qf '%{NAME}' -a | sort >a cat sclo-ci-tests/PackageLists/sclo-vagrant1/all | sort >b diff -up a b which is very similar to your check, just using `sort` to be sure we don't get false negative on just different order.. Honza From hhorak at redhat.com Wed Oct 14 23:06:49 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 15 Oct 2015 01:06:49 +0200 Subject: [scl.org] collections sclo-vagrant1, rh-ror41 and rh-ruby22 ready Message-ID: <561EE009.4030703@redhat.com> Here is a couple of things I've promised to do on today's SCLo meeting. First, I've verified that sclo-vagrant1 collection works fine and imho it includes everything it should, so let's ship it! The packages from all three collections sclo-vagrant1, rh-ruby22 and rh-ror41 are also tagged into -release already (el7 only, since sclo-vagrant1 is not built for el6). Test that checks the package lists for all collections is available here: https://github.com/sclorg/sclo-ci-tests/tree/master/validate-pkg-list There is also the rest of what original Karanbir's script for validating sclo-vagrant1 did, available at: https://github.com/sclorg/sclo-ci-tests/tree/master/validate-install but the structure of this might change a bit after we'll include the other tests that Matej is working on.. Anyway, there is run.sh in the root of the repository, which may be used to run all the tests, so something like that should work generally for every collection: #> git clone https://github.com/sclorg/sclo-ci-tests.git #> cd sclo-ci-tests #> ./run.sh sclo-vagrant1 7 Let me know if there is anything else needed from my side (except the release announcement I still need to figure out), for the initial release.. Honza From jstribny at redhat.com Thu Oct 15 07:44:48 2015 From: jstribny at redhat.com (Josef Stribny) Date: Thu, 15 Oct 2015 09:44:48 +0200 Subject: [scl.org] collections sclo-vagrant1, rh-ror41 and rh-ruby22 ready In-Reply-To: <561EE009.4030703@redhat.com> References: <561EE009.4030703@redhat.com> Message-ID: <1444895088.6652.5@smtp.corp.redhat.com> Hi, On Thu, Oct 15, 2015 at 1:06 AM, Honza Horak wrote: > Here is a couple of things I've promised to do on today's SCLo > meeting. > > First, I've verified that sclo-vagrant1 collection works fine and > imho it includes everything it should, so let's ship it! Great ;). > > > The packages from all three collections sclo-vagrant1, rh-ruby22 and > rh-ror41 are also tagged into -release already (el7 only, since > sclo-vagrant1 is not built for el6). > > Test that checks the package lists for all collections is available > here: > > https://github.com/sclorg/sclo-ci-tests/tree/master/validate-pkg-list > > There is also the rest of what original Karanbir's script for > validating sclo-vagrant1 did, available at: > https://github.com/sclorg/sclo-ci-tests/tree/master/validate-install > but the structure of this might change a bit after we'll include the > other tests that Matej is working on.. > > Anyway, there is run.sh in the root of the repository, which may be > used to run all the tests, so something like that should work > generally for every collection: > #> git clone https://github.com/sclorg/sclo-ci-tests.git > #> cd sclo-ci-tests > #> ./run.sh sclo-vagrant1 7 > > Let me know if there is anything else needed from my side (except the > release announcement I still need to figure out), for the initial > release.. I assume my part is done as well, but if I need to do something in order to push it out, just let me know. Josef -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Thu Oct 15 09:28:12 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 15 Oct 2015 10:28:12 +0100 Subject: [scl.org] collections sclo-vagrant1, rh-ror41 and rh-ruby22 ready In-Reply-To: <1444895088.6652.5@smtp.corp.redhat.com> References: <561EE009.4030703@redhat.com> <1444895088.6652.5@smtp.corp.redhat.com> Message-ID: <561F71AC.50206@karan.org> On 15/10/15 08:44, Josef Stribny wrote: > Hi, > > On Thu, Oct 15, 2015 at 1:06 AM, Honza Horak wrote: >> Here is a couple of things I've promised to do on today's SCLo >> meeting. First, I've verified that sclo-vagrant1 collection works fine >> and imho it includes everything it should, so let's ship it! > > Great ;). woo! > >> The packages from all three collections sclo-vagrant1, rh-ruby22 and >> rh-ror41 are also tagged into -release already (el7 only, since >> sclo-vagrant1 is not built for el6). Test that checks the package >> lists for all collections is available here: >> https://github.com/sclorg/sclo-ci-tests/tree/master/validate-pkg-list >> There is also the rest of what original Karanbir's script for >> validating sclo-vagrant1 did, available at: >> https://github.com/sclorg/sclo-ci-tests/tree/master/validate-install >> but the structure of this might change a bit after we'll include the >> other tests that Matej is working on.. Anyway, there is run.sh in the >> root of the repository, which may be used to run all the tests, so >> something like that should work generally for every collection: #> git >> clone https://github.com/sclorg/sclo-ci-tests.git #> cd sclo-ci-tests >> #> ./run.sh sclo-vagrant1 7 Let me know if there is anything else >> needed from my side (except the release announcement I still need to >> figure out), for the initial release.. > > I assume my part is done as well, but if I need to do something in order > to push it out, just let me know. it would be great to have a SCL's section on wiki.centos.org along with some getting started content ( maybe something generic for all the scl's - even if the content is short and has a url leading to a softwarecollections.org page for more info ). and then it would be great to have a single page for the major collections, like vagrant. a quickstart gives us something to url and send announcement traffic to, and has typically proven to be a good engagement point even down the road. Finally, I've written a test that stress's a box in libvirt and another test that does the same for vbox, do we want to have more testing ? should we be testing things other than 'the box comes up, i can login' etc finally, I am hoping there is an update cadence in place. Someone is going to be doing updates for these collections right ? regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From jstribny at redhat.com Thu Oct 15 11:24:05 2015 From: jstribny at redhat.com (Josef Stribny) Date: Thu, 15 Oct 2015 13:24:05 +0200 Subject: [scl.org] collections sclo-vagrant1, rh-ror41 and rh-ruby22 ready In-Reply-To: <561F71AC.50206@karan.org> References: <561EE009.4030703@redhat.com> <1444895088.6652.5@smtp.corp.redhat.com> <561F71AC.50206@karan.org> Message-ID: <1444908245.27709.0@smtp.corp.redhat.com> > it would be great to have a SCL's section on wiki.centos.org along > with > some getting started content ( maybe something generic for all the > scl's > - even if the content is short and has a url leading to a > softwarecollections.org page for more info ). and then it would be > great > to have a single page for the major collections, like vagrant. a > quickstart gives us something to url and send announcement traffic to, > and has typically proven to be a good engagement point even down the > road. I can prepare something for Ruby/Vagrant although I am not familiar with contributions to the CentOS wiki. > > > Finally, I've written a test that stress's a box in libvirt and > another > test that does the same for vbox, do we want to have more testing ? > should we be testing things other than 'the box comes up, i can > login' etc > > finally, I am hoping there is an update cadence in place. Someone is > going to be doing updates for these collections right ? Do you miss something there now? I plan to do updates for Vagrant scl, but not sure if that often as for Fedora. But surely fixes especially connected with Fedora/RHEL/CentOS guests should be added (some are missing now). Best Regards Josef -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Mon Oct 19 09:28:04 2015 From: mail-lists at karan.org (Karanbir Singh) Date: Mon, 19 Oct 2015 10:28:04 +0100 Subject: [scl.org] golang Message-ID: <5624B7A4.2040501@karan.org> hi, is there a golang SCL anywhere ? - Kb -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Mon Oct 19 16:35:49 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 19 Oct 2015 18:35:49 +0200 Subject: [scl.org] golang In-Reply-To: <5624B7A4.2040501@karan.org> References: <5624B7A4.2040501@karan.org> Message-ID: <56251BE5.2020803@redhat.com> Not anything I'd be aware of. Is there anybody who would start working on it in part of SCLo with technical (SCL) help from our side? Honza On 10/19/2015 11:28 AM, Karanbir Singh wrote: > hi, > > is there a golang SCL anywhere ? > > - Kb > From kbsingh at redhat.com Tue Oct 20 12:15:32 2015 From: kbsingh at redhat.com (Karanbir Singh) Date: Tue, 20 Oct 2015 13:15:32 +0100 Subject: [scl.org] Image naming for centos-based images In-Reply-To: References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> Message-ID: <56263064.4020305@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, just a quick ping back - does anyone have thoughts around this ? We are getting ready to start pushing SCL's from centos.org and that will likely map back to the docker containers and getting the pipeline for those into ci.centos.org. The 19th Nov isnt far either, Regards, On 09/10/15 20:41, Ben Parees wrote: > Karanbir and I talked briefly today, and i'd like to just lay out > a couple things from an openshift perspective: > > 1) we encourage the use of both rhel and centos images (rhel for > support, centos to try), so we really want the images to have the > same names (other than the namespace/org) because it makes for a > much more consistent transition, better support experience, etc. > So i do not like any approach that results in one naming convention > for centos images and another for the "rhscl" images. > > 2) we're shipping OSE3.1 nov 19th and things need to be locked > down earlier than that. Since this will be the first release > shipping these new SCL images, we have some freedom to change the > names now. But once that happens it's going to be much more > painful to change them. So if things are changing, we need a > decision asap. > > 3) I suggested that maybe we could use aliases to solve some of > this... you can still provide a "mariadb" docker alias for the > seamless "i don't care what i get" experience, but still maintain > multiple streams of versions/etc by backing that alias with a more > specifically named pull spec, like the names we use today. > > 4) i'm mostly willing to concede dropping the rhel7/centos7 suffice > from the names now that we have separate namespaces for the > repositories...but keeping the version number in the name still > seems important to avoid the issues with users not being able to > pull "latest" or not understand what they have pulled. > > I'm also adding Dan McPherson and Clayton Coleman to this thread as > they are the lead architects for OpenShift and should also weigh in > on any image naming decisions we're making. > > > > On Thu, Oct 8, 2015 at 11:43 AM, Honza Horak > wrote: > > On 10/07/2015 11:40 AM, Karanbir Singh wrote: > > variant B: centos/mariadb:10.0 > > > * less complicated * no redundancy * it is similar to what docker > hub uses for official images now > > > adding a few more bits here for B : > > * pretty much the standard way for the entire docker ecosystem to > work on right now ( that redhat is largely absent from ) > > > Fair point. Anyway, what a sane user actually does IMO is not > `docker pull mariadb`, but rather `docker pull mariadb:5.5`. And > since `docker search centos/mariadb` doesn't show available > versions, how can user know which versions are available? there is > only centos/mariadb in the output. > > So, user can only guess what versions are available or can find it > somewhere else.. in the case there would be the version in the > image name, it would be listed in the search output, which seems > like a benefit for user to me. > > Btw. did you know that there has been already centos/mariadb > available on docker hub? > > * provides scope for future expansion as we abstract away from > delivery mechanics to focus on payload > > > I still don't consider this to be related to delivery mechanism. > > * allows for distro decompose and co-exist in a 'as default' manner > ( admittedly arguable! ) > > A relatively sane proof for this model is looking at how many > people run a 'yum install mariadb' V/s 'yum install > mariadb-5.5.44-1.el7_1.x86_64' when they want a mariadb install; > having a centos/mariadb and using tag space to extend the multiple > version availability, allows us to extend the same user > expectation. > > > Sure, nobody runs 'yum install mariadb-5.5.44-1.el7_1.x86_64' and > just uses `mariadb`, but we must realize that users always install > RPMs for the correct platform (nobody configures yum to install > el6 packages on el7) and we also provide only one version of the > mariadb in the system, so users are sure what version they get. > Once there are more versions (as SCLs or if we find any other > format), users will install particular version -- `yum install > mariadb55`, because they care (in most cases). > > Docker is new in this sense because you have all versions build on > various kernels on one heap. This is not something we have > experience with in RPM world. > > As mentioned in this thread [2], there is a new API spec being > prepared [3], which will be a chance to change naming scheme to > something less redundant, if the current way proofs to be > problematic. > > > [1] isnt complete so its clearly a work in progress, how about we > just work on getting that complete now and address the whole piece > together ? or is the SCL portion left as TBA allowing the scl space > to do something completely different ? > > > The SCL part is there already, but covers only RH registry. I wish > we could sync on one schema over Fedora/RHEL/CentOS as well, but I > don't see a compromise here, that would be fine for all. Or maybe > missing willingness to accept some compromise, I don't know. > > Secondly, if you consider the inertia against looking at a change > now largely driven by we-already-have-something, what are the > chances that this is going to go away when the api-spec comes up ( > and we have even more water under the bridge ? ). > > > IMO the chance would be big enough if we'll be convinced the > current way is not good enough for users. If we'll see the current > way is fine for them and doesn't make any troubles, then why > changing it.. > > Honza > > > > > -- Ben Parees | OpenShift > - -- Karanbir Singh, The CentOS Project, London, UK RH Ext. 8274455 | DID: 0044 207 009 4455 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWJjBjAAoJEI3Oi2Mx7xbtC0cIAJTxE4rFvXZxuRRgCnbnfEA4 mN9lb7fAhYNvsCSk6SO+V2HZmS/zDFJ64Vqb6mm2w9U3kt/5JQ0fjSXY3GM/jGgB H00T/vxlt7fIMqZ1TTV6bTut/hSa7dYd/kko+VTGKQaPe6UtBmZH8X2iGWgw/E10 AYu0IHOW7Dd9pfE1MYHnVHdPsru+//raCO5bdjH+gEYhL7d9mhtp5RMOkyQ+y2BN c7yvtujyh7LzPuqmXJrnxYtZVQu0RI99J5el5zCBzfE9rBtY2qoYGS4KJnC9y02C Nhtt+Ixt+W41GsbgwGKZqLsAG1ogcUoMQghiyyPVEv00X+d3xPp0659Knsbz08Y= =31Dn -----END PGP SIGNATURE----- From hhorak at redhat.com Tue Oct 20 21:29:53 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 20 Oct 2015 23:29:53 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> Message-ID: <5626B251.5060001@redhat.com> I'm wondering whether the silence means nobody has any objections or whether everything was already said.. Anyway, there is still the risk of using names without rhel7 and centos7 suffix like `centos/mariadb-100` or `rhscl/mariadb-100`, that user won't be sure what is the OS version in the container -- that is considered relevant in more parts of https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md. That ^ is also the view I'm more leaned towards, simply because I agree with the points in the document above and because I don't think platform version makes any harm in the name. On the other hand, the Docker world works without platform version or even component version in the name, so it shouldn't be that bad in the end. So, technically we're able to change the names for RHSCL images now after they are available as Beta, but I'm not sure whether it is still possible from PM PoV -- Brian, would it be possible to change names of the images from e.g. `rhscl/mariadb-100-rhel7` to `rhscl/mariadb-100` at this point? Honza On 10/09/2015 09:41 PM, Ben Parees wrote: > Karanbir and I talked briefly today, and i'd like to just lay out a > couple things from an openshift perspective: > > 1) we encourage the use of both rhel and centos images (rhel for > support, centos to try), so we really want the images to have the same > names (other than the namespace/org) because it makes for a much more > consistent transition, better support experience, etc. So i do not like > any approach that results in one naming convention for centos images and > another for the "rhscl" images. > > 2) we're shipping OSE3.1 nov 19th and things need to be locked down > earlier than that. Since this will be the first release shipping these > new SCL images, we have some freedom to change the names now. But once > that happens it's going to be much more painful to change them. So if > things are changing, we need a decision asap. > > 3) I suggested that maybe we could use aliases to solve some of this... > you can still provide a "mariadb" docker alias for the seamless "i don't > care what i get" experience, but still maintain multiple streams of > versions/etc by backing that alias with a more specifically named pull > spec, like the names we use today. > > 4) i'm mostly willing to concede dropping the rhel7/centos7 suffice from > the names now that we have separate namespaces for the > repositories...but keeping the version number in the name still seems > important to avoid the issues with users not being able to pull "latest" > or not understand what they have pulled. > > I'm also adding Dan McPherson and Clayton Coleman to this thread as they > are the lead architects for OpenShift and should also weigh in on any > image naming decisions we're making. > > > > On Thu, Oct 8, 2015 at 11:43 AM, Honza Horak > wrote: > > On 10/07/2015 11:40 AM, Karanbir Singh wrote: > > variant B: centos/mariadb:10.0 > > > * less complicated * no redundancy * it is similar to what > docker > hub uses for official images now > > > adding a few more bits here for B : > > * pretty much the standard way for the entire docker ecosystem > to work > on right now ( that redhat is largely absent from ) > > > Fair point. Anyway, what a sane user actually does IMO is not > `docker pull mariadb`, but rather `docker pull mariadb:5.5`. And > since `docker search centos/mariadb` doesn't show available > versions, how can user know which versions are available? there is > only centos/mariadb in the output. > > So, user can only guess what versions are available or can find it > somewhere else.. in the case there would be the version in the image > name, it would be listed in the search output, which seems like a > benefit for user to me. > > Btw. did you know that there has been already centos/mariadb > available on docker hub? > > * provides scope for future expansion as we abstract away from > delivery mechanics to focus on payload > > > I still don't consider this to be related to delivery mechanism. > > * allows for distro decompose and co-exist in a 'as default' > manner ( > admittedly arguable! ) > > A relatively sane proof for this model is looking at how many people > run a 'yum install mariadb' V/s 'yum install > mariadb-5.5.44-1.el7_1.x86_64' when they want a mariadb install; > having a centos/mariadb and using tag space to extend the multiple > version availability, allows us to extend the same user expectation. > > > Sure, nobody runs 'yum install mariadb-5.5.44-1.el7_1.x86_64' and > just uses `mariadb`, but we must realize that users always install > RPMs for the correct platform (nobody configures yum to install el6 > packages on el7) and we also provide only one version of the mariadb > in the system, so users are sure what version they get. Once there > are more versions (as SCLs or if we find any other format), users > will install particular version -- `yum install mariadb55`, because > they care (in most cases). > > Docker is new in this sense because you have all versions build on > various kernels on one heap. This is not something we have > experience with in RPM world. > > As mentioned in this thread [2], there is a new API spec being > prepared [3], which will be a chance to change naming scheme to > something less redundant, if the current way proofs to be > problematic. > > > [1] isnt complete so its clearly a work in progress, how about > we just > work on getting that complete now and address the whole piece > together > ? or is the SCL portion left as TBA allowing the scl space to do > something completely different ? > > > The SCL part is there already, but covers only RH registry. I wish > we could sync on one schema over Fedora/RHEL/CentOS as well, but I > don't see a compromise here, that would be fine for all. Or maybe > missing willingness to accept some compromise, I don't know. > > Secondly, if you consider the inertia against looking at a > change now > largely driven by we-already-have-something, what are the > chances that > this is going to go away when the api-spec comes up ( and we > have even > more water under the bridge ? ). > > > IMO the chance would be big enough if we'll be convinced the current > way is not good enough for users. If we'll see the current way is > fine for them and doesn't make any troubles, then why changing it.. > > Honza > > > > > -- > Ben Parees | OpenShift > From hhorak at redhat.com Wed Oct 21 06:14:07 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 21 Oct 2015 08:14:07 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <5626B251.5060001@redhat.com> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> Message-ID: <56272D2F.1090206@redhat.com> On 10/20/2015 11:29 PM, Honza Horak wrote: > Anyway, there is still the risk of using names without rhel7 and centos7 > suffix like `centos/mariadb-100` or `rhscl/mariadb-100`, that user won't > be sure what is the OS version in the container -- that is considered > relevant in more parts of > https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md. > > That ^ is also the view I'm more leaned towards, simply because I agree > with the points in the document above and because I don't think platform > version makes any harm in the name. Thinking about a typical example where platform matters -- let's say a developer wants to speed-up a ruby application, so he implements a part of it as a binary extension (written in C and using a library from the base OS). The developer builds the app locally, so the rubygem links to the particular system library (libfoo.so.2). Once our images would move from rhel7 to rhel8, his application wouldn't work any more, because we have libfoo.so.3 in rhel8. Honza From hhorak at redhat.com Wed Oct 21 06:29:34 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 21 Oct 2015 08:29:34 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <5626B251.5060001@redhat.com> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> Message-ID: <562730CE.7020303@redhat.com> On 10/20/2015 11:29 PM, Honza Horak wrote: > 3) I suggested that maybe we could use aliases to solve some of this... > you can still provide a "mariadb" docker alias for the seamless "i don't > care what i get" experience, but still maintain multiple streams of > versions/etc by backing that alias with a more specifically named pull > spec, like the names we use today. I like it, it is quite easy to create such an alias when building images maunally (`docker tag centos/mariadb-100-centos centos/mariadb`), but I'm worried about how to do it within OSBS -- the aliases would have to be practically layered images with different 'name' LABEL, which implies different hash. Those layered images would inherit all other metadata, so it will work for users, but would be tough to keep the layered image updated as soon as the original one updates. So, a better solution would be to do it properly in RCM, because we use something like this already for base images -- there are both rhel7.1 and rhel7 images (which currently is a bit troublesome because the latest build is tagged as rhel7, not the latest name). But if we fix this and allow this approach to be used generally, that would be great and should solve all of this. Honza From jperrin at centos.org Wed Oct 21 12:23:44 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 21 Oct 2015 07:23:44 -0500 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <56272D2F.1090206@redhat.com> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> Message-ID: <562783D0.5090206@centos.org> On 10/21/2015 01:14 AM, Honza Horak wrote: > On 10/20/2015 11:29 PM, Honza Horak wrote: >> Anyway, there is still the risk of using names without rhel7 and centos7 >> suffix like `centos/mariadb-100` or `rhscl/mariadb-100`, that user won't >> be sure what is the OS version in the container -- that is considered >> relevant in more parts of >> https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md. >> >> >> That ^ is also the view I'm more leaned towards, simply because I agree >> with the points in the document above and because I don't think platform >> version makes any harm in the name. > > Thinking about a typical example where platform matters -- let's say a > developer wants to speed-up a ruby application, so he implements a part > of it as a binary extension (written in C and using a library from the > base OS). > > The developer builds the app locally, so the rubygem links to the > particular system library (libfoo.so.2). Once our images would move from > rhel7 to rhel8, his application wouldn't work any more, because we have > libfoo.so.3 in rhel8. This level of breakage happens outside containers even in the minor point release updates. This was shown quite recently with the ImageMagick update in 6.7 [1]. To me this isn't a good enough justification (on the community side) to duplicate names. None of the fedora containers specify OS version, nor to the CentOS containers. For RHEL support and RH's own container registry it's fine and the occasional edge case makes sense there. From the community perspective, we should align with where the entire ecosystem as a whole is going. Right now we're lagging in usage, and doing things very differently from what the ecosystem expects is only going to further isolate us. In the world of containers, the application is the visible component, not the OS. It's a shift away from what we've been doing for the last decade, but it's happening. 1. https://lists.fedoraproject.org/pipermail/epel-devel/2015-July/011419.html -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From briang at redhat.com Wed Oct 21 20:22:41 2015 From: briang at redhat.com (Brian Gollaher) Date: Wed, 21 Oct 2015 16:22:41 -0400 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <562783D0.5090206@centos.org> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> Message-ID: <5627F411.9090006@redhat.com> On 10/21/2015 08:23 AM, Jim Perrin wrote: > > On 10/21/2015 01:14 AM, Honza Horak wrote: >> On 10/20/2015 11:29 PM, Honza Horak wrote: >>> Anyway, there is still the risk of using names without rhel7 and centos7 >>> suffix like `centos/mariadb-100` or `rhscl/mariadb-100`, that user won't >>> be sure what is the OS version in the container -- that is considered >>> relevant in more parts of >>> https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md. >>> >>> >>> That ^ is also the view I'm more leaned towards, simply because I agree >>> with the points in the document above and because I don't think platform >>> version makes any harm in the name. >> Thinking about a typical example where platform matters -- let's say a >> developer wants to speed-up a ruby application, so he implements a part >> of it as a binary extension (written in C and using a library from the >> base OS). >> >> The developer builds the app locally, so the rubygem links to the >> particular system library (libfoo.so.2). Once our images would move from >> rhel7 to rhel8, his application wouldn't work any more, because we have >> libfoo.so.3 in rhel8. > > This level of breakage happens outside containers even in the minor > point release updates. This was shown quite recently with the > ImageMagick update in 6.7 [1]. To me this isn't a good enough > justification (on the community side) to duplicate names. None of the > fedora containers specify OS version, nor to the CentOS containers. > > > For RHEL support and RH's own container registry it's fine and the > occasional edge case makes sense there. From the community perspective, > we should align with where the entire ecosystem as a whole is going. > > Right now we're lagging in usage, and doing things very differently from > what the ecosystem expects is only going to further isolate us. > > > In the world of containers, the application is the visible component, > not the OS. It's a shift away from what we've been doing for the last > decade, but it's happening. Yes but our business is selling a secure, stable OS with long term support so keeping the -rhel7 helps customers understand where they can confidently use the container. > > > > 1. > https://lists.fedoraproject.org/pipermail/epel-devel/2015-July/011419.html > -- Brian Gollaher Red Hat Platform Product Management Phone: 978 392-3173 Cell: 508 740-6549 briang at redhat.com From jperrin at centos.org Wed Oct 21 20:59:11 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 21 Oct 2015 15:59:11 -0500 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <5627F411.9090006@redhat.com> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> Message-ID: <5627FC9F.4070400@centos.org> On 10/21/2015 03:22 PM, Brian Gollaher wrote: > On 10/21/2015 08:23 AM, Jim Perrin wrote: >> >> On 10/21/2015 01:14 AM, Honza Horak wrote: >>> On 10/20/2015 11:29 PM, Honza Horak wrote: >>>> Anyway, there is still the risk of using names without rhel7 and >>>> centos7 >>>> suffix like `centos/mariadb-100` or `rhscl/mariadb-100`, that user >>>> won't >>>> be sure what is the OS version in the container -- that is considered >>>> relevant in more parts of >>>> https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md. >>>> >>>> >>>> >>>> That ^ is also the view I'm more leaned towards, simply because I agree >>>> with the points in the document above and because I don't think >>>> platform >>>> version makes any harm in the name. >>> Thinking about a typical example where platform matters -- let's say a >>> developer wants to speed-up a ruby application, so he implements a part >>> of it as a binary extension (written in C and using a library from the >>> base OS). >>> >>> The developer builds the app locally, so the rubygem links to the >>> particular system library (libfoo.so.2). Once our images would move from >>> rhel7 to rhel8, his application wouldn't work any more, because we have >>> libfoo.so.3 in rhel8. >> >> This level of breakage happens outside containers even in the minor >> point release updates. This was shown quite recently with the >> ImageMagick update in 6.7 [1]. To me this isn't a good enough >> justification (on the community side) to duplicate names. None of the >> fedora containers specify OS version, nor to the CentOS containers. >> >> >> For RHEL support and RH's own container registry it's fine and the >> occasional edge case makes sense there. From the community perspective, >> we should align with where the entire ecosystem as a whole is going. >> >> Right now we're lagging in usage, and doing things very differently from >> what the ecosystem expects is only going to further isolate us. >> >> >> In the world of containers, the application is the visible component, >> not the OS. It's a shift away from what we've been doing for the last >> decade, but it's happening. > Yes but our business is selling a secure, stable OS with long term > support so keeping the -rhel7 helps customers understand where they can > confidently use the container. No, we're talking about something larger here. Fedora and CentOS don't sell anything. This is where community and RH business interests diverge. If RH wants to add to the naming schema within their own registry, that's entirely fine and understandable. I don't see a need to drive a business mandate into the community space, especially when the larger container community is moving in the opposite direction. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From kbsingh at redhat.com Wed Oct 21 21:00:55 2015 From: kbsingh at redhat.com (Karanbir Singh) Date: Wed, 21 Oct 2015 22:00:55 +0100 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <5627FC9F.4070400@centos.org> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> Message-ID: <5627FD07.3060802@redhat.com> On 21/10/15 21:59, Jim Perrin wrote: > > > On 10/21/2015 03:22 PM, Brian Gollaher wrote: >> On 10/21/2015 08:23 AM, Jim Perrin wrote: >>> >>> On 10/21/2015 01:14 AM, Honza Horak wrote: >>>> On 10/20/2015 11:29 PM, Honza Horak wrote: >>>>> Anyway, there is still the risk of using names without rhel7 and >>>>> centos7 >>>>> suffix like `centos/mariadb-100` or `rhscl/mariadb-100`, that user >>>>> won't >>>>> be sure what is the OS version in the container -- that is considered >>>>> relevant in more parts of >>>>> https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md. >>>>> >>>>> >>>>> >>>>> That ^ is also the view I'm more leaned towards, simply because I agree >>>>> with the points in the document above and because I don't think >>>>> platform >>>>> version makes any harm in the name. >>>> Thinking about a typical example where platform matters -- let's say a >>>> developer wants to speed-up a ruby application, so he implements a part >>>> of it as a binary extension (written in C and using a library from the >>>> base OS). >>>> >>>> The developer builds the app locally, so the rubygem links to the >>>> particular system library (libfoo.so.2). Once our images would move from >>>> rhel7 to rhel8, his application wouldn't work any more, because we have >>>> libfoo.so.3 in rhel8. >>> >>> This level of breakage happens outside containers even in the minor >>> point release updates. This was shown quite recently with the >>> ImageMagick update in 6.7 [1]. To me this isn't a good enough >>> justification (on the community side) to duplicate names. None of the >>> fedora containers specify OS version, nor to the CentOS containers. >>> >>> >>> For RHEL support and RH's own container registry it's fine and the >>> occasional edge case makes sense there. From the community perspective, >>> we should align with where the entire ecosystem as a whole is going. >>> >>> Right now we're lagging in usage, and doing things very differently from >>> what the ecosystem expects is only going to further isolate us. >>> >>> >>> In the world of containers, the application is the visible component, >>> not the OS. It's a shift away from what we've been doing for the last >>> decade, but it's happening. >> Yes but our business is selling a secure, stable OS with long term >> support so keeping the -rhel7 helps customers understand where they can >> confidently use the container. > > > No, we're talking about something larger here. Fedora and CentOS don't > sell anything. This is where community and RH business interests > diverge. If RH wants to add to the naming schema within their own > registry, that's entirely fine and understandable. I don't see a need to > drive a business mandate into the community space, especially when the > larger container community is moving in the opposite direction. also, isnt rhel7 content already delivered via a layered private repository anyway ? I sincerely hope were not asking customers to rely on a bit in the name to build trust ( anyone can push an image called -rhel7 ). -- Karanbir Singh, The CentOS Project, London, UK RH Ext. 8274455 | DID: 0044 207 009 4455 From briang at redhat.com Wed Oct 21 21:10:37 2015 From: briang at redhat.com (Brian Gollaher) Date: Wed, 21 Oct 2015 17:10:37 -0400 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <5627FD07.3060802@redhat.com> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> Message-ID: <5627FF4D.5050603@redhat.com> On 10/21/2015 05:00 PM, Karanbir Singh wrote: > On 21/10/15 21:59, Jim Perrin wrote: >> >> On 10/21/2015 03:22 PM, Brian Gollaher wrote: >>> On 10/21/2015 08:23 AM, Jim Perrin wrote: >>>> On 10/21/2015 01:14 AM, Honza Horak wrote: >>>>> On 10/20/2015 11:29 PM, Honza Horak wrote: >>>>>> Anyway, there is still the risk of using names without rhel7 and >>>>>> centos7 >>>>>> suffix like `centos/mariadb-100` or `rhscl/mariadb-100`, that user >>>>>> won't >>>>>> be sure what is the OS version in the container -- that is considered >>>>>> relevant in more parts of >>>>>> https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md. >>>>>> >>>>>> >>>>>> >>>>>> That ^ is also the view I'm more leaned towards, simply because I agree >>>>>> with the points in the document above and because I don't think >>>>>> platform >>>>>> version makes any harm in the name. >>>>> Thinking about a typical example where platform matters -- let's say a >>>>> developer wants to speed-up a ruby application, so he implements a part >>>>> of it as a binary extension (written in C and using a library from the >>>>> base OS). >>>>> >>>>> The developer builds the app locally, so the rubygem links to the >>>>> particular system library (libfoo.so.2). Once our images would move from >>>>> rhel7 to rhel8, his application wouldn't work any more, because we have >>>>> libfoo.so.3 in rhel8. >>>> This level of breakage happens outside containers even in the minor >>>> point release updates. This was shown quite recently with the >>>> ImageMagick update in 6.7 [1]. To me this isn't a good enough >>>> justification (on the community side) to duplicate names. None of the >>>> fedora containers specify OS version, nor to the CentOS containers. >>>> >>>> >>>> For RHEL support and RH's own container registry it's fine and the >>>> occasional edge case makes sense there. From the community perspective, >>>> we should align with where the entire ecosystem as a whole is going. >>>> >>>> Right now we're lagging in usage, and doing things very differently from >>>> what the ecosystem expects is only going to further isolate us. >>>> >>>> >>>> In the world of containers, the application is the visible component, >>>> not the OS. It's a shift away from what we've been doing for the last >>>> decade, but it's happening. >>> Yes but our business is selling a secure, stable OS with long term >>> support so keeping the -rhel7 helps customers understand where they can >>> confidently use the container. >> >> No, we're talking about something larger here. Fedora and CentOS don't >> sell anything. This is where community and RH business interests >> diverge. If RH wants to add to the naming schema within their own >> registry, that's entirely fine and understandable. I don't see a need to >> drive a business mandate into the community space, especially when the >> larger container community is moving in the opposite direction. > also, isnt rhel7 content already delivered via a layered private > repository anyway ? Yes it is. > > I sincerely hope were not asking customers to rely on a bit in the name > to build trust ( anyone can push an image called -rhel7 ). My assumption was that container names would be consistent. Where we have images built on rhel7 base that run on rhel7 and rhel8 hosts (or centos7 and centos8 hosts), how do identify that the image is built with rhel7 base? > -- Brian Gollaher Red Hat Platform Product Management Phone: 978 392-3173 Cell: 508 740-6549 briang at redhat.com From daniel.davis at nih.gov Wed Oct 21 21:28:40 2015 From: daniel.davis at nih.gov (Davis, Daniel (NIH/NLM) [C]) Date: Wed, 21 Oct 2015 21:28:40 +0000 Subject: [scl.org] More recent nodejs Message-ID: What are the plans, if any, to update nodejs? Is this something you guys could accept help with? Dan Davis, Systems/Applications Architect (Contractor), Office of Computer and Communications Systems, National Library of Medicine, NIH -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperrin at centos.org Wed Oct 21 21:39:28 2015 From: jperrin at centos.org (Jim Perrin) Date: Wed, 21 Oct 2015 16:39:28 -0500 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <5627FF4D.5050603@redhat.com> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> Message-ID: <56280610.3080803@centos.org> On 10/21/2015 04:10 PM, Brian Gollaher wrote: > My assumption was that container names would be consistent. Where we > have images built on rhel7 base that run on rhel7 and rhel8 hosts (or > centos7 and centos8 hosts), how do identify that the image is built with > rhel7 base? We're trying to make them consistent at least in the community space, without making them needlessly complex or redundant. To your question, I would posit that in the community space, it doesn't matter. The container users simply aren't interested in whether they're based on fedora 21 or fedora 22. The users are after the application, not the OS. The OS itself is largely invisible in the container ecosystem except as a host or base container. >From the community space, neither fedora nor centos currently create duplicate containers distinguished by distro version, nor has either party expressed interest in doing so during these discussions. In the business case for RH, this could easily be accomplished by namespacing per release, registry.access.redhat.com:rhel7/foo, with a link to the rhel/foo-rhel7 if the BU requires it. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From hhorak at redhat.com Thu Oct 22 05:39:34 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 22 Oct 2015 07:39:34 +0200 Subject: [scl.org] SCLo el6 packages have wrong upgrade path Message-ID: <56287696.50904@redhat.com> So far I've just roughly looked at whether el6 SCL packages available at http://mirror.centos.org/centos/6/SCL/x86_64/ properly update to packages built in CBS, as we touched it yesterday. Long story short, there are packages with higher NVR than what we have in CBS now. There are basically two options here -- we may rebuild the problematic packages and bump release in CBS or we can document how to properly update using `yum distro-sync`. Anybody has a strong opinion about one of them? From my PoV, bumping&rebuilding should avoid more issues on users' side, because we can't be sure what happens if packages are combined (some from CBS and some from older repo) and depending on manual step won't work in 100% cases. Honza From hhorak at redhat.com Thu Oct 22 06:26:16 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 22 Oct 2015 08:26:16 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <56280610.3080803@centos.org> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> Message-ID: <56288188.8010202@redhat.com> On 10/21/2015 11:39 PM, Jim Perrin wrote: > On 10/21/2015 04:10 PM, Brian Gollaher wrote: > > > >> My assumption was that container names would be consistent. Where we >> have images built on rhel7 base that run on rhel7 and rhel8 hosts (or >> centos7 and centos8 hosts), how do identify that the image is built with >> rhel7 base? > > > We're trying to make them consistent at least in the community space, > without making them needlessly complex or redundant. To your question, I > would posit that in the community space, it doesn't matter. The > container users simply aren't interested in whether they're based on > fedora 21 or fedora 22. The users are after the application, not the OS. > The OS itself is largely invisible in the container ecosystem except as > a host or base container. I don't see a problem in Fedora, since changes between latest and latest-1 are quite small, so porting of application is easy, if needed. > From the community space, neither fedora nor centos currently create > duplicate containers distinguished by distro version, nor has either > party expressed interest in doing so during these discussions. > > > In the business case for RH, this could easily be accomplished by > namespacing per release, registry.access.redhat.com:rhel7/foo, with a > link to the rhel/foo-rhel7 if the BU requires it. Well, giving second thoughts to the Ben's idea of having an alias (in community variants), it seems like the way out of this, since we're really stalled here. How it could work: * `docker pull centos/ruby-22-centos7` for those who care about stability in centos-based images the same as in rhel-based images. * `docker pull centos/ruby-22` for those who do not care about platform * and possibly even `docker pull centos/ruby` for those who do not care about version either (again, we'd use this only for centos images) Since we're not limited to OSBS in centos, it can be done the way all those images having the same ID, so no matter what name the user uses, it always is the same image. The only thing we need to take care of is to run something like this after every image build: ``` docker tag centos/ruby-22-centos7 centos/ruby-22 docker push centos/ruby-22 docker tag centos/ruby-22-centos7 centos/ruby docker push centos/ruby ``` Honza From jstribny at redhat.com Thu Oct 22 09:41:35 2015 From: jstribny at redhat.com (Josef Stribny) Date: Thu, 22 Oct 2015 11:41:35 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <56280610.3080803@centos.org> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> Message-ID: <1445506895.23388.0@smtp.corp.redhat.com> > > > We're trying to make them consistent at least in the community space, > without making them needlessly complex or redundant. To your > question, I > would posit that in the community space, it doesn't matter. The > container users simply aren't interested in whether they're based on > fedora 21 or fedora 22. The users are after the application, not the > OS. > The OS itself is largely invisible in the container ecosystem except > as > a host or base container. > > I agree people are after an application, but I actually don't like not knowing the underlying system and I even think that CentOS has a good reputation and can draw attention to these images... Josef -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfojtik at redhat.com Thu Oct 22 10:13:43 2015 From: mfojtik at redhat.com (Michal Fojtik) Date: Thu, 22 Oct 2015 12:13:43 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <1445506895.23388.0@smtp.corp.redhat.com> References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> Message-ID: I think one of the main reason (AFAIK) we used "-rhel7" and "-centos7" suffixed for the images was that we simply used one repository ("openshift/") and we needed to have a way to distinguish between rhel7 and centos7 images. Now, when we are pushing the images to "centos/" namespace on DockerHub, this is not longer required I think, because "centos/ruby-22-centos7" sounds just weird :-) Similar to the RHEL7 images that we will ship via registry.access.redhat.com where we push only RHEL7 based images, we can relax the suffix. Are there any other concerns or reasons why keeping the suffixes is bad other than it "looks weird" and it is "redundant" ? -- Michal On Thu, Oct 22, 2015 at 11:41 AM, Josef Stribny wrote: > > We're trying to make them consistent at least in the community space, > without making them needlessly complex or redundant. To your question, I > would posit that in the community space, it doesn't matter. The container > users simply aren't interested in whether they're based on fedora 21 or > fedora 22. The users are after the application, not the OS. The OS itself > is largely invisible in the container ecosystem except as a host or base > container. > > > > I agree people are after an application, but I actually don't like not > knowing the underlying system and > I even think that CentOS has a good reputation and can draw attention to > these images... > > Josef > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstribny at redhat.com Thu Oct 22 10:15:11 2015 From: jstribny at redhat.com (Josef Stribny) Date: Thu, 22 Oct 2015 12:15:11 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> Message-ID: <1445508911.23388.2@smtp.corp.redhat.com> On Thu, Oct 22, 2015 at 12:13 PM, Michal Fojtik wrote: > I think one of the main reason (AFAIK) we used "-rhel7" and > "-centos7" suffixed for the images > was that we simply used one repository ("openshift/") and we needed > to have a way to distinguish > between rhel7 and centos7 images. > > Now, when we are pushing the images to "centos/" namespace on > DockerHub, this is not longer required > I think, because "centos/ruby-22-centos7" sounds just weird :-) Oh, right, in that case I am +1. Josef -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppisar at redhat.com Thu Oct 22 10:27:47 2015 From: ppisar at redhat.com (Petr Pisar) Date: Thu, 22 Oct 2015 12:27:47 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: References: <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> Message-ID: <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> On Thu, Oct 22, 2015 at 12:13:43PM +0200, Michal Fojtik wrote: > I think one of the main reason (AFAIK) we used "-rhel7" and "-centos7" > suffixed for the images > was that we simply used one repository ("openshift/") and we needed to have > a way to distinguish > between rhel7 and centos7 images. > > Now, when we are pushing the images to "centos/" namespace on DockerHub, > this is not longer required > I think, because "centos/ruby-22-centos7" sounds just weird :-) > What will happen once centos8 is released? Do you think then executing centos8 image on centos7 or vice versa will be supported? -- Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From mfojtik at redhat.com Thu Oct 22 10:31:42 2015 From: mfojtik at redhat.com (Michal Fojtik) Date: Thu, 22 Oct 2015 12:31:42 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> References: <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> Message-ID: That is good question :-) On Thu, Oct 22, 2015 at 12:27 PM, Petr Pisar wrote: > On Thu, Oct 22, 2015 at 12:13:43PM +0200, Michal Fojtik wrote: > > I think one of the main reason (AFAIK) we used "-rhel7" and "-centos7" > > suffixed for the images > > was that we simply used one repository ("openshift/") and we needed to > have > > a way to distinguish > > between rhel7 and centos7 images. > > > > Now, when we are pushing the images to "centos/" namespace on DockerHub, > > this is not longer required > > I think, because "centos/ruby-22-centos7" sounds just weird :-) > > > What will happen once centos8 is released? Do you think then executing > centos8 image on centos7 or vice versa will be supported? > > -- Petr > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbsingh at redhat.com Thu Oct 22 10:52:32 2015 From: kbsingh at redhat.com (Karanbir Singh) Date: Thu, 22 Oct 2015 11:52:32 +0100 Subject: [scl.org] SCLo el6 packages have wrong upgrade path In-Reply-To: <56287696.50904@redhat.com> References: <56287696.50904@redhat.com> Message-ID: <5628BFF0.3010200@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/10/15 06:39, Honza Horak wrote: > So far I've just roughly looked at whether el6 SCL packages > available at http://mirror.centos.org/centos/6/SCL/x86_64/ properly > update to packages built in CBS, as we touched it yesterday. Long > story short, there are packages with higher NVR than what we have > in CBS now. > > There are basically two options here -- we may rebuild the > problematic packages and bump release in CBS or we can document how > to properly update using `yum distro-sync`. > > Anybody has a strong opinion about one of them? > > From my PoV, bumping&rebuilding should avoid more issues on users' > side, because we can't be sure what happens if packages are > combined (some from CBS and some from older repo) and depending on > manual step won't work in 100% cases. > > Honza do we know why the versions are newer ? is the corrosponding code also newer ? - -- Karanbir Singh, The CentOS Project, London, UK RH Ext. 8274455 | DID: 0044 207 009 4455 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWKL/wAAoJEI3Oi2Mx7xbtq84H/2XSWBrrCTg7CExHk6Sgfg+O FQuNKwhr7RPyZS94ZsHppNR208aRuX50eITW7fiExZAOtNSyUZyyjbQu0KXBID9E hvBWWryYIfrLvGf0hU+f++dbWJo8Dk9Zse8oeaP+4Si6L3GZkIvZOl7UntBZgls4 bAubyEv2tkthR1BKmiLrjI1rnIBF7Sw04wv0n3eMKUfEvDfVghnjbKuvROOmrfl7 X04je+wJE1V1mBbX9ZhG2gF1ubF+lOLFE9N0ok5JGAfXXd7CVUTpts+SirpjQFL+ tk1dg8m3jxQpmucmMGONGZa3exvoEj/gQ3hdiANa1y2PMprvAR8cs0jfRmW9yoQ= =irb7 -----END PGP SIGNATURE----- From hhorak at redhat.com Thu Oct 22 10:56:38 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 22 Oct 2015 12:56:38 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: References: <560E5997.7050203@redhat.com> <5614E034.8060309@redhat.com> <5614E895.7090704@redhat.com> <56163AD9.6000200@redhat.com> <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> Message-ID: <5628C0E6.7080207@redhat.com> On 10/22/2015 12:13 PM, Michal Fojtik wrote: > I think one of the main reason (AFAIK) we used "-rhel7" and "-centos7" > suffixed for the images > was that we simply used one repository ("openshift/") and we needed to > have a way to distinguish > between rhel7 and centos7 images. > > Now, when we are pushing the images to "centos/" namespace on DockerHub, > this is not longer required > I think, because "centos/ruby-22-centos7" sounds just weird :-) > > Similar to the RHEL7 images that we will ship via > registry.access.redhat.com where we > push only RHEL7 based > images, we can relax the suffix. Well, the discussion is not about whether removing centos/rhel alone, which really is redundant -- it's mainly about the version piece, which doesn't make sense without the rhel/centos part. >> We're trying to make them consistent at least in the community >> space, without making them needlessly complex or redundant. To >> your question, I would posit that in the community space, it >> doesn't matter. The container users simply aren't interested in >> whether they're based on fedora 21 or fedora 22. The users are >> after the application, not the OS. The OS itself is largely >> invisible in the container ecosystem except as a host or base >> container. Totally agree if we really speak about application. But is ruby base image an application? It is rather a tool to create applications on top of it, where the rest of the system matters. Honza From hhorak at redhat.com Thu Oct 22 10:58:59 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 22 Oct 2015 12:58:59 +0200 Subject: [scl.org] SCLo el6 packages have wrong upgrade path In-Reply-To: <5628BFF0.3010200@redhat.com> References: <56287696.50904@redhat.com> <5628BFF0.3010200@redhat.com> Message-ID: <5628C173.2020504@redhat.com> On 10/22/2015 12:52 PM, Karanbir Singh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 22/10/15 06:39, Honza Horak wrote: >> So far I've just roughly looked at whether el6 SCL packages >> available at http://mirror.centos.org/centos/6/SCL/x86_64/ properly >> update to packages built in CBS, as we touched it yesterday. Long >> story short, there are packages with higher NVR than what we have >> in CBS now. >> >> There are basically two options here -- we may rebuild the >> problematic packages and bump release in CBS or we can document how >> to properly update using `yum distro-sync`. >> >> Anybody has a strong opinion about one of them? >> >> From my PoV, bumping&rebuilding should avoid more issues on users' >> side, because we can't be sure what happens if packages are >> combined (some from CBS and some from older repo) and depending on >> manual step won't work in 100% cases. >> >> Honza > > do we know why the versions are newer ? is the corrosponding code also > newer ? I didn't check many packages, but the difference was only in release, so I expect there were issues during build and release was bumped because of that. But we should check whether the content is really the same. Not done so far. Honza > - -- > Karanbir Singh, The CentOS Project, London, UK > RH Ext. 8274455 | DID: 0044 207 009 4455 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQEcBAEBAgAGBQJWKL/wAAoJEI3Oi2Mx7xbtq84H/2XSWBrrCTg7CExHk6Sgfg+O > FQuNKwhr7RPyZS94ZsHppNR208aRuX50eITW7fiExZAOtNSyUZyyjbQu0KXBID9E > hvBWWryYIfrLvGf0hU+f++dbWJo8Dk9Zse8oeaP+4Si6L3GZkIvZOl7UntBZgls4 > bAubyEv2tkthR1BKmiLrjI1rnIBF7Sw04wv0n3eMKUfEvDfVghnjbKuvROOmrfl7 > X04je+wJE1V1mBbX9ZhG2gF1ubF+lOLFE9N0ok5JGAfXXd7CVUTpts+SirpjQFL+ > tk1dg8m3jxQpmucmMGONGZa3exvoEj/gQ3hdiANa1y2PMprvAR8cs0jfRmW9yoQ= > =irb7 > -----END PGP SIGNATURE----- > From hhorak at redhat.com Thu Oct 22 11:03:27 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 22 Oct 2015 13:03:27 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: References: <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> Message-ID: <5628C27F.7080800@redhat.com> I expect we want the centos-based images be run everywhere, not only centos, but on Fedora, Debian or even Windows if possible. Honza On 10/22/2015 12:31 PM, Michal Fojtik wrote: > That is good question :-) > > On Thu, Oct 22, 2015 at 12:27 PM, Petr Pisar > wrote: > > On Thu, Oct 22, 2015 at 12:13:43PM +0200, Michal Fojtik wrote: > > I think one of the main reason (AFAIK) we used "-rhel7" and "-centos7" > > suffixed for the images > > was that we simply used one repository ("openshift/") and we needed to have > > a way to distinguish > > between rhel7 and centos7 images. > > > > Now, when we are pushing the images to "centos/" namespace on DockerHub, > > this is not longer required > > I think, because "centos/ruby-22-centos7" sounds just weird :-) > > > What will happen once centos8 is released? Do you think then executing > centos8 image on centos7 or vice versa will be supported? > > -- Petr > > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From mfojtik at redhat.com Thu Oct 22 11:10:06 2015 From: mfojtik at redhat.com (Michal Fojtik) Date: Thu, 22 Oct 2015 13:10:06 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <5628C27F.7080800@redhat.com> References: <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> <5628C27F.7080800@redhat.com> Message-ID: I think the question here is really how we will tag the ruby/python/etc images then. Now we deal just with centos7, so we can have centos/ruby-20 (or centos/ruby even). How when centos8 will be out, centos/ruby-20 will be based on centos8? What will happen to centos7 images? How users will know what base those images have? ;-) On Thu, Oct 22, 2015 at 1:03 PM, Honza Horak wrote: > I expect we want the centos-based images be run everywhere, not only > centos, but on Fedora, Debian or even Windows if possible. > > Honza > > On 10/22/2015 12:31 PM, Michal Fojtik wrote: > >> That is good question :-) >> >> On Thu, Oct 22, 2015 at 12:27 PM, Petr Pisar > > wrote: >> >> On Thu, Oct 22, 2015 at 12:13:43PM +0200, Michal Fojtik wrote: >> > I think one of the main reason (AFAIK) we used "-rhel7" and >> "-centos7" >> > suffixed for the images >> > was that we simply used one repository ("openshift/") and we needed >> to have >> > a way to distinguish >> > between rhel7 and centos7 images. >> > >> > Now, when we are pushing the images to "centos/" namespace on >> DockerHub, >> > this is not longer required >> > I think, because "centos/ruby-22-centos7" sounds just weird :-) >> > >> What will happen once centos8 is released? Do you think then executing >> centos8 image on centos7 or vice versa will be supported? >> >> -- Petr >> >> >> >> >> _______________________________________________ >> SCLorg mailing list >> SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppisar at redhat.com Thu Oct 22 11:19:08 2015 From: ppisar at redhat.com (Petr Pisar) Date: Thu, 22 Oct 2015 13:19:08 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <5628C27F.7080800@redhat.com> References: <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> <5628C27F.7080800@redhat.com> Message-ID: <20151022111908.GD2153@dhcp-0-146.brq.redhat.com> On Thu, Oct 22, 2015 at 01:03:27PM +0200, Honza Horak wrote: > I expect we want the centos-based images be run everywhere, not only centos, > but on Fedora, Debian or even Windows if possible. > Impossible. Docker image is archived file system without kernel. The archived executables depend on kernel ABI. -- Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From jperrin at centos.org Thu Oct 22 12:25:35 2015 From: jperrin at centos.org (Jim Perrin) Date: Thu, 22 Oct 2015 07:25:35 -0500 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> References: <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> Message-ID: <5628D5BF.5080900@centos.org> On 10/22/2015 05:27 AM, Petr Pisar wrote: > On Thu, Oct 22, 2015 at 12:13:43PM +0200, Michal Fojtik wrote: >> I think one of the main reason (AFAIK) we used "-rhel7" and "-centos7" >> suffixed for the images >> was that we simply used one repository ("openshift/") and we needed to have >> a way to distinguish >> between rhel7 and centos7 images. >> >> Now, when we are pushing the images to "centos/" namespace on DockerHub, >> this is not longer required >> I think, because "centos/ruby-22-centos7" sounds just weird :-) >> > What will happen once centos8 is released? Do you think then executing > centos8 image on centos7 or vice versa will be supported? Bearing in mind that the community definition of 'supported' is much less stringent (e.g, best effort by whoever chooses to answer) than for paying customers, yes. We currently have docker on CentOS 6 via EPEL where users run centos 7 images. We have CentOS 6 and even CentOS 5 base containers. Users are running these on Ubuntu, Debian and MacOS already with varying levels of support and success. That said, for layered containers I don't plan to maintain duplicates where the only differentiation is the OS. If ruby20 is based on C6 but ruby22 is based on C7, I'm okay with that. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jperrin at centos.org Thu Oct 22 12:30:36 2015 From: jperrin at centos.org (Jim Perrin) Date: Thu, 22 Oct 2015 07:30:36 -0500 Subject: [scl.org] Image naming for centos-based images In-Reply-To: References: <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> <5628C27F.7080800@redhat.com> Message-ID: <5628D6EC.8030409@centos.org> On 10/22/2015 06:10 AM, Michal Fojtik wrote: > I think the question here is really how we will tag the ruby/python/etc > images then. > Now we deal just with centos7, so we can have centos/ruby-20 (or > centos/ruby even). > How when centos8 will be out, centos/ruby-20 will be based on centos8? What > will happen > to centos7 images? How users will know what base those images have? ;-) > Via the documentation for the image and the Dockerfile used to create it, which should be linked. For example -> https://hub.docker.com/r/gitlab/gitlab-ce/ Users wanting to run gitlab in a container get it from here. It doesn't advertise what the base is, but anyone curious can simply click the 'Dockerfile' tab on the page to see. > On Thu, Oct 22, 2015 at 1:03 PM, Honza Horak wrote: > >> I expect we want the centos-based images be run everywhere, not only >> centos, but on Fedora, Debian or even Windows if possible. >> >> Honza >> >> On 10/22/2015 12:31 PM, Michal Fojtik wrote: >> >>> That is good question :-) >>> >>> On Thu, Oct 22, 2015 at 12:27 PM, Petr Pisar >> > wrote: >>> >>> On Thu, Oct 22, 2015 at 12:13:43PM +0200, Michal Fojtik wrote: >>> > I think one of the main reason (AFAIK) we used "-rhel7" and >>> "-centos7" >>> > suffixed for the images >>> > was that we simply used one repository ("openshift/") and we needed >>> to have >>> > a way to distinguish >>> > between rhel7 and centos7 images. >>> > >>> > Now, when we are pushing the images to "centos/" namespace on >>> DockerHub, >>> > this is not longer required >>> > I think, because "centos/ruby-22-centos7" sounds just weird :-) >>> > >>> What will happen once centos8 is released? Do you think then executing >>> centos8 image on centos7 or vice versa will be supported? >>> >>> -- Petr >>> >>> >>> >>> >>> _______________________________________________ >>> SCLorg mailing list >>> SCLorg at redhat.com >>> https://www.redhat.com/mailman/listinfo/sclorg >>> >>> > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From jperrin at centos.org Thu Oct 22 12:34:50 2015 From: jperrin at centos.org (Jim Perrin) Date: Thu, 22 Oct 2015 07:34:50 -0500 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <20151022111908.GD2153@dhcp-0-146.brq.redhat.com> References: <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> <5628C27F.7080800@redhat.com> <20151022111908.GD2153@dhcp-0-146.brq.redhat.com> Message-ID: <5628D7EA.20409@centos.org> On 10/22/2015 06:19 AM, Petr Pisar wrote: > On Thu, Oct 22, 2015 at 01:03:27PM +0200, Honza Horak wrote: >> I expect we want the centos-based images be run everywhere, not only centos, >> but on Fedora, Debian or even Windows if possible. >> > Impossible. Docker image is archived file system without kernel. The archived > executables depend on kernel ABI. It's not impossible. It's already happening for developers running kitematic/boot2docker on MacOS or for ubuntu users. It may not be supportable from a business perspective, but it's certainly happening at the community level. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 From ppisar at redhat.com Thu Oct 22 13:08:07 2015 From: ppisar at redhat.com (Petr Pisar) Date: Thu, 22 Oct 2015 15:08:07 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <5628D7EA.20409@centos.org> References: <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> <5628C27F.7080800@redhat.com> <20151022111908.GD2153@dhcp-0-146.brq.redhat.com> <5628D7EA.20409@centos.org> Message-ID: <20151022130807.GE2153@dhcp-0-146.brq.redhat.com> On Thu, Oct 22, 2015 at 07:34:50AM -0500, Jim Perrin wrote: > On 10/22/2015 06:19 AM, Petr Pisar wrote: > > On Thu, Oct 22, 2015 at 01:03:27PM +0200, Honza Horak wrote: > >> I expect we want the centos-based images be run everywhere, not only > >> centos, but on Fedora, Debian or even Windows if possible. > >> > > Impossible. Docker image is archived file system without kernel. The > > archived executables depend on kernel ABI. > > It's not impossible. It's already happening for developers running > kitematic/boot2docker on MacOS From : boot2docker is a lightweight Linux distribution. So they run the image on the Linux, not Mac OS X. > or for ubuntu users. Until the executable will require a feature that differs on the two distributions. And crashing on ENOSYS is still the better variant. -- Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From ncoghlan at redhat.com Thu Oct 22 16:08:30 2015 From: ncoghlan at redhat.com (Nick Coghlan) Date: Thu, 22 Oct 2015 18:08:30 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: <20151022111908.GD2153@dhcp-0-146.brq.redhat.com> References: <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> <5628C27F.7080800@redhat.com> <20151022111908.GD2153@dhcp-0-146.brq.redhat.com> Message-ID: On Thu, Oct 22, 2015 at 1:19 PM, Petr Pisar wrote: > On Thu, Oct 22, 2015 at 01:03:27PM +0200, Honza Horak wrote: > > I expect we want the centos-based images be run everywhere, not only > centos, > > but on Fedora, Debian or even Windows if possible. > > > Impossible. Docker image is archived file system without kernel. The > archived > executables depend on kernel ABI. > Folks running highly optimised C/C++/FORTRAN applications may care about the exact kernel version, but that's not your typical containerised application. When language runtimes are written to be portable across Windows, Linux and Mac OS X, the differences between Linux kernel versions generally vanish into the noise, so if a Java/Python/Ruby/Node.js container crashes because you ran it on a different kernel, that's an extreme edge case. Even when there *are* ABI compatibility issues, if an app is designed to be failure tolerant, bugs in the *app itself* are still far more likely to be the culprit for a server 500 error than a kernel ABI incompatibility - web services are expected to be crashy bugfests, which is why we still mainly use them for cases where relatively high failure rates (regardless of cause) are an acceptable outcome. Honza's suggestion of making the three levels of tagging (ruby, ruby-22, ruby-22-centos7) available makes sense to me, as that puts the control in the hands of the end user - when "centos/ruby-22" switches to "centos/ruby-22-centos8", folks will be able to see the userland has changed, even though it will likely still work with a centos7 kernel. Cheers, Nick. -- Nick Coghlan Fedora Environments & Stacks Red Hat Developer Experience, Brisbane Software Development Workflow Designer & Process Architect -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Thu Oct 22 16:31:09 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 22 Oct 2015 18:31:09 +0200 Subject: [scl.org] Image naming for centos-based images In-Reply-To: References: <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> <5628C27F.7080800@redhat.com> Message-ID: <56290F4D.80009@redhat.com> On 10/22/2015 01:10 PM, Michal Fojtik wrote: > I think the question here is really how we will tag the ruby/python/etc > images then. > Now we deal just with centos7, so we can have centos/ruby-20 (or > centos/ruby even). > How when centos8 will be out, centos/ruby-20 will be based on centos8? > What will happen > to centos7 images? How users will know what base those images have? ;-) Thank you for rephrasing, that's basically my point all the time. We just need to be able to distinguish it somehow, even if it is crucial only for part of the users and others will ignore it. Honza > On Thu, Oct 22, 2015 at 1:03 PM, Honza Horak > wrote: > > I expect we want the centos-based images be run everywhere, not only > centos, but on Fedora, Debian or even Windows if possible. > > Honza > > On 10/22/2015 12:31 PM, Michal Fojtik wrote: > > That is good question :-) > > On Thu, Oct 22, 2015 at 12:27 PM, Petr Pisar > >> wrote: > > On Thu, Oct 22, 2015 at 12:13:43PM +0200, Michal Fojtik wrote: > > I think one of the main reason (AFAIK) we used "-rhel7" > and "-centos7" > > suffixed for the images > > was that we simply used one repository ("openshift/") and > we needed to have > > a way to distinguish > > between rhel7 and centos7 images. > > > > Now, when we are pushing the images to "centos/" > namespace on DockerHub, > > this is not longer required > > I think, because "centos/ruby-22-centos7" sounds just > weird :-) > > > What will happen once centos8 is released? Do you think > then executing > centos8 image on centos7 or vice versa will be supported? > > -- Petr > > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > > From bparees at redhat.com Mon Oct 26 23:02:22 2015 From: bparees at redhat.com (Ben Parees) Date: Mon, 26 Oct 2015 19:02:22 -0400 Subject: [scl.org] Image naming for centos-based images In-Reply-To: References: <5626B251.5060001@redhat.com> <56272D2F.1090206@redhat.com> <562783D0.5090206@centos.org> <5627F411.9090006@redhat.com> <5627FC9F.4070400@centos.org> <5627FD07.3060802@redhat.com> <5627FF4D.5050603@redhat.com> <56280610.3080803@centos.org> <1445506895.23388.0@smtp.corp.redhat.com> <20151022102747.GB2153@dhcp-0-146.brq.redhat.com> <5628C27F.7080800@redhat.com> <56290F4D.80009@redhat.com> Message-ID: Based on what I've seen on this thread so far, I think there's a general consensus that: 1) the long form names are useful in certain situations 2) the short form also have value and as such, we should simply use the alias approach so we can advertise and reference the images in the most appropriate way for the context/requirements of different scenarios. Therefore I'm proceeding with updating the openshift v3 release to assume the long form names will be available: https://github.com/openshift/origin/pull/5409 On Sat, Oct 24, 2015 at 9:12 PM, Daniel Riek wrote: > FWITW, I agree with Michal and Honza here. > > There were 2 primary reasons to include the Platformdifferentiator: > * As stated in the policy [1], the primary purpose was to allow builders > of layered images to understand what underlying platform they would be > using and give them explicit control. > * In addition we wanted to ensure that the RHEL name show-up in searches > (one of the reasons why this is a cert requirement). > > [1] > https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md > > Daniel > > On Friday, October 23, 2015, Honza Horak wrote: > >> On 10/22/2015 01:10 PM, Michal Fojtik wrote: >> >>> I think the question here is really how we will tag the ruby/python/etc >>> images then. >>> Now we deal just with centos7, so we can have centos/ruby-20 (or >>> centos/ruby even). >>> How when centos8 will be out, centos/ruby-20 will be based on centos8? >>> What will happen >>> to centos7 images? How users will know what base those images have? ;-) >>> >> >> Thank you for rephrasing, that's basically my point all the time. We just >> need to be able to distinguish it somehow, even if it is crucial only for >> part of the users and others will ignore it. >> >> Honza >> >> On Thu, Oct 22, 2015 at 1:03 PM, Honza Horak >> > wrote: >>> >>> I expect we want the centos-based images be run everywhere, not only >>> centos, but on Fedora, Debian or even Windows if possible. >>> >>> Honza >>> >>> On 10/22/2015 12:31 PM, Michal Fojtik wrote: >>> >>> That is good question :-) >>> >>> On Thu, Oct 22, 2015 at 12:27 PM, Petr Pisar >> >>> >> wrote: >>> >>> On Thu, Oct 22, 2015 at 12:13:43PM +0200, Michal Fojtik >>> wrote: >>> > I think one of the main reason (AFAIK) we used "-rhel7" >>> and "-centos7" >>> > suffixed for the images >>> > was that we simply used one repository ("openshift/") and >>> we needed to have >>> > a way to distinguish >>> > between rhel7 and centos7 images. >>> > >>> > Now, when we are pushing the images to "centos/" >>> namespace on DockerHub, >>> > this is not longer required >>> > I think, because "centos/ruby-22-centos7" sounds just >>> weird :-) >>> > >>> What will happen once centos8 is released? Do you think >>> then executing >>> centos8 image on centos7 or vice versa will be supported? >>> >>> -- Petr >>> >>> >>> >>> >>> _______________________________________________ >>> SCLorg mailing list >>> SCLorg at redhat.com >>> https://www.redhat.com/mailman/listinfo/sclorg >>> >>> >>> > > -- > Daniel Riek > * Sr. Director Systems Design & Engineering > * Red Hat Inc, Tel. +1-617-863-6776 > > -- Ben Parees | OpenShift -------------- next part -------------- An HTML attachment was scrubbed... URL: From seitz at bsd-unix.net Tue Oct 27 19:49:48 2015 From: seitz at bsd-unix.net (Bryan Seitz) Date: Tue, 27 Oct 2015 15:49:48 -0400 Subject: [scl.org] Python SCL Message-ID: <562FD55C.2080108@bsd-unix.net> Hi folks, Would it be possible to bump the Python 3.4.2 SCL to 3.4.3 ? Seems like a lot of bug fixes in that change. TIA, From Jaroslaw.Polok at cern.ch Thu Oct 29 14:51:23 2015 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Thu, 29 Oct 2015 15:51:23 +0100 Subject: [scl.org] scl's release ? Message-ID: <5632326B.6070905@cern.ch> Hi all, Apologies if the question has been asked before ... but I could not find the answer: When are SCLo collections going to be released ? I see that most packages are already built on cbs.centos.org .. since few weeks ?) looking at the list archives I see there are upgrade path problems for (some?) collections on 6, but what about 7 ? Thanks Jarek __ ------------------------------------------------------- _ Jaroslaw_Polok __________________ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _ From Jaroslaw.Polok at cern.ch Thu Oct 29 15:07:48 2015 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Thu, 29 Oct 2015 16:07:48 +0100 Subject: [scl.org] bug reporting for slcs ? Message-ID: <56323644.8000702@cern.ch> Hi, Where bugs for SCLo collections are to be reported ? bugs.centos.org does not seem to have SCLo project defined ? We have just seen a (minor) bug in rh-ruby22 collection (wrong shebang paths in some tools) My understanding is that that collection is a rebuilt of upstream RH one: in that case the bug is to be reported to CentOS/SCLo or to RH directly ? Thanks Jarek __ ------------------------------------------------------- _ Jaroslaw_Polok __________________ CERN - IT/OIS/WLS _ _ http://cern.ch/~jpolok ________ tel_+41_22_767_1834 _ ______________________________________+41_75_411_9487 _