On Mon, Aug 24, 2015 at 06:35:00AM +0200, Niels de Vos wrote:
On Mon, Aug 24, 2015 at 09:01:52AM +0530, Lalatendu Mohanty wrote:
On 08/22/2015 10:22 PM, Niels de Vos wrote:
Hi Lala,
Today I've prepared the glusterfs-coreutils package for the Storage SIG. Everything works fine, but there is one thing I am unable to get done. Maybe I am missing certain permissions?
The new glusterfs-coreutils package would need to be added to the CBS. This fails for me:
$ koji -p centos \ add-pkg --owner storage \ storage6-gluster-common-candidate glusterfs-coreutils SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
Doing scratch-builds works fine, so I doubt that the issue really is the SSL-certificate.
Could you let me know if I am doing something wrong, or if it is expected that I can not add new packages?
Thanks, Niels
Niels,
I correct command is "koji add-pkg storage6-gluster-common-candidate glusterfs-coreutils --owner storage". I have executed this and it is added to the SIG now. Let me know you still face the issue.
Thanks, but that really does not work for me... I'd like to add userspace-rcu and glusterfs-coreutils to the storage7 channels too, but it fails exactly the same as before:
$ koji -p centos add-pkg storage7-gluster-37-candidate userspace-rcu --owner storage SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
$ koji -p centos add-pkg storage7-gluster-common-candidate glusterfs-coreutils --owner storage SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
Note that I use "-p centos" to pick the CentOS profile for Koji, the default would connect to Fedora's instance.
Hmm, I think I have a misunderstanding of how things are setup. The storage6-gluster-common-candidate does not contain any glusterfs packages, so building glusterfs-coreutils for storage6-gluster-common-* fails. I guess glusterfs-coreutils needs to be added to - storage6-gluster-36-* - storage6-gluster-37-* - storage7-gluster-36-* - storage7-gluster-37-*
Adding a little more to this. What would be the best place to document the structure of the tags that contain which packages? I would like to see something similar to this:
storage6-common-* |- base packages/dependencies like centos-storage-release | |- storage6-gluster-common-* | |- dependencies for Gluster, like userspace-rcu | | | |- storage6-gluster-35-* | | '- GlusterFS 3.5 and related packages | | | |- storage6-gluster-36-* | | '- GlusterFS 3.6 and related packages | | | |- storage6-gluster-37-* | : '- GlusterFS 3.7 and related packages | '- storage6-..openafs.. '- OpenAFS packages
Which tags would contain a centos-storage-gluster-release package? In the end, what would users install to get access to the repositories they need?
Now, glusterfs-coreutils depends on glusterfs >= 3.6, and it is possible to compile against glusterfs-3.6 but run the binaries with glusterfs-3.7. To which tag(s) this package be added? Other packages like scsi-target-utils (with Gluster support) would be an other candidate for a 'common' tag. Should these all get build for the different storage6-gluster-36/37 tags?
We also want to have storage7 for CentOS-7 and most likely a reduced set for storage5. I would prefer to keep the number of builds that need to be done as small as possible, and share as much as possible between the different releases.