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

Lalatendu Mohanty lmohanty at redhat.com
Mon Aug 24 05:59:59 UTC 2015


On 08/24/2015 10:59 AM, Niels de Vos wrote:
> 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:

I think we can put it in 
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster.
>
>    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.
>
>



More information about the CentOS-devel mailing list