[CentOS-devel] [Storage SIG] Adding new package glusterfs-coreutils to the CBS

[Niels de Vos]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20150824/8818be37/attachment.sig>