[Gluster-devel] Cmockery2 in GlusterFS

Lalatendu Mohanty lmohanty at redhat.com
Tue Jul 22 12:01:13 UTC 2014


On 07/22/2014 05:22 PM, Luis Pabón wrote:
> Hi Lala,
>     No problem at all, I just want to make sure that developers 
> understand the importance of the tool.  On the topic of RPMs, they 
> have a really cool section called "%check", which is currently being 
> used to run the unit tests after the glusterfs RPM is created.  
> Normally developers test only on certain systems and certain 
> architectures, but by having the "%check" section, we can guarantee a 
> level of quality when an RPM is created on an architecture or 
> operating system version which is not normally used for development.  
> This actually worked really well for cmockery2 when the RPM was first 
> introduced to Fedora.  The %check section ran the unit tests on two 
> architectures that I do not have, and both of them found issues on 
> ARM32 and s390 architectures.  Without the %check section, cmockery2 
> would have been released and not been able to have been used.  This is 
> why cmockery2 is set in the "BuildRequires" section.
>

Awesome!, now it make perfect sense to run these units tests during RPM 
building. Thanks Luis.

>
>
> On 07/22/2014 07:34 AM, Lalatendu Mohanty wrote:
>> On 07/22/2014 04:35 PM, Luis Pabón wrote:
>>> I understand that when something is new and different, it is most 
>>> likely blamed for anything wrong that happens.  I highly propose 
>>> that we do not do this, and instead work to learn more about the tool.
>>>
>>> Cmockery2 is a tool that is important as the compiler.  It provides 
>>> an extremely easy method to determine the quality of the software 
>>> after it has been constructed, and therefore it has been made to be 
>>> a requirement of the build.  Making it optional undermines its 
>>> importance, and could in turn make it useless.
>>>
>>
>> Hey Luis,
>>
>> Th intention was not to undermine or give less importance to 
>> Cmockery2. Sorry if it looked like that.
>>
>> However I was thinking from a flexibility point of view. I am 
>> assuming in future, it would be part of upstream regression test 
>> suite. So each patch will go through full unit testing by-default. So 
>> when somebody is creating RPMs from pristine sources, we should be 
>> able to do that without Cmockery2 because the tests were already ran 
>> through Jenkins/gerrit.
>>
>> The question is do we need Cmockery every-time we compile glusterfs 
>> source? if the answer is yes, then I am fine with current code.
>>
>>> Cmockery2 is available for all supported EPEL/Fedora versions.  For 
>>> any other distribution or operating system, it takes about 3 mins to 
>>> download and compile.
>>>
>>> Please let me know if you have any other questions.
>>>
>>> - Luis
>>>
>>> On 07/22/2014 02:23 AM, Lalatendu Mohanty wrote:
>>>> On 07/21/2014 10:48 PM, Harshavardhana wrote:
>>>>> Cmockery2 is a hard dependency before GlusterFS can be compiled in
>>>>> upstream master now - we could make it conditional
>>>>> and enable if necessary? since we know we do not have the cmockery2
>>>>> packages available on all systems?
>>>>
>>>> +1, we need to make it conditional and enable it if necessary.  I 
>>>> am also not sure if we have "cmockery2-devel" in el5, el6. If not 
>>>> Build will fail.
>>>>
>>>>> On Mon, Jul 21, 2014 at 10:16 AM, Luis Pabon <lpabon at redhat.com> 
>>>>> wrote:
>>>>>> Niels you are correct. Let me take a look.
>>>>>>
>>>>>> Luis
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Niels de Vos [ndevos at redhat.com]
>>>>>> Received: Monday, 21 Jul 2014, 10:41AM
>>>>>> To: Luis Pabon [lpabon at redhat.com]
>>>>>> CC: Anders Blomdell [anders.blomdell at control.lth.se];
>>>>>> gluster-devel at gluster.org
>>>>>> Subject: Re: [Gluster-devel] Cmockery2 in GlusterFS
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 21, 2014 at 04:27:18PM +0200, Anders Blomdell wrote:
>>>>>>> On 2014-07-21 16:17, Anders Blomdell wrote:
>>>>>>>> On 2014-07-20 16:01, Niels de Vos wrote:
>>>>>>>>> On Fri, Jul 18, 2014 at 02:52:18PM -0400, Luis Pabón wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>      A few months ago, the unit test framework based on 
>>>>>>>>>> cmockery2 was
>>>>>>>>>> in the repo for a little while, then removed while we 
>>>>>>>>>> improved the
>>>>>>>>>> packaging method.  Now support for cmockery2 (
>>>>>>>>>> http://review.gluster.org/#/c/7538/ ) has been merged into 
>>>>>>>>>> the repo
>>>>>>>>>> again.  This will most likely require you to install 
>>>>>>>>>> cmockery2 on
>>>>>>>>>> your development systems by doing the following:
>>>>>>>>>>
>>>>>>>>>> * Fedora/EPEL:
>>>>>>>>>> $ sudo yum -y install cmockery2-devel
>>>>>>>>>>
>>>>>>>>>> * All other systems please visit the following page:
>>>>>>>>>> https://github.com/lpabon/cmockery2/blob/master/doc/usage.md#installation 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Here is also some information about Cmockery2 and how to use it:
>>>>>>>>>>
>>>>>>>>>> * Introduction to Unit Tests in C Presentation:
>>>>>>>>>> http://slides-lpabon.rhcloud.com/feb24_glusterfs_unittest.html#/
>>>>>>>>>> * Cmockery2 Usage Guide:
>>>>>>>>>> https://github.com/lpabon/cmockery2/blob/master/doc/usage.md
>>>>>>>>>> * Using Cmockery2 with GlusterFS:
>>>>>>>>>> https://github.com/gluster/glusterfs/blob/master/doc/hacker-guide/en-US/markdown/unittest.md 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When starting out writing unit tests, I would suggest writing 
>>>>>>>>>> unit
>>>>>>>>>> tests for non-xlator interface files when you start. Once you 
>>>>>>>>>> feel
>>>>>>>>>> more comfortable writing unit tests, then move to writing 
>>>>>>>>>> them for
>>>>>>>>>> the xlators interface files.
>>>>>>>>> Awesome, many thanks! I'd like to add some unittests for the 
>>>>>>>>> RPC and
>>>>>>>>> NFS
>>>>>>>>> layer. Several functions (like ip-address/netmask matching for 
>>>>>>>>> ACLs)
>>>>>>>>> look very suitable.
>>>>>>>>>
>>>>>>>>> Did you have any particular functions in mind that you would 
>>>>>>>>> like to
>>>>>>>>> see
>>>>>>>>> unittests for? If so, maybe you can file some bugs for the 
>>>>>>>>> different
>>>>>>>>> tests so that we won't forget about it? Depending on the 
>>>>>>>>> tests, these
>>>>>>>>> bugs may get the EasyFix keyword if there is a clear 
>>>>>>>>> description and
>>>>>>>>> some pointers to examples.
>>>>>>>> Looks like parts of cmockery was forgotten in glusterfs.spec.in:
>>>>>>>>
>>>>>>>> # rpm -q -f  `which gluster`
>>>>>>>> glusterfs-cli-3.7dev-0.9.git5b8de97.fc20.x86_64
>>>>>>>> # ldd `which gluster`
>>>>>>>>       linux-vdso.so.1 =>  (0x00007ffff4dfe000)
>>>>>>>>       libglusterfs.so.0 => /lib64/libglusterfs.so.0 
>>>>>>>> (0x00007fe034cc4000)
>>>>>>>>       libreadline.so.6 => /lib64/libreadline.so.6 
>>>>>>>> (0x00007fe034a7d000)
>>>>>>>>       libncurses.so.5 => /lib64/libncurses.so.5 
>>>>>>>> (0x00007fe034856000)
>>>>>>>>       libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fe03462c000)
>>>>>>>>       libgfxdr.so.0 => /lib64/libgfxdr.so.0 (0x00007fe034414000)
>>>>>>>>       libgfrpc.so.0 => /lib64/libgfrpc.so.0 (0x00007fe0341f8000)
>>>>>>>>       libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fe033e8f000)
>>>>>>>>       libz.so.1 => /lib64/libz.so.1 (0x00007fe033c79000)
>>>>>>>>       libm.so.6 => /lib64/libm.so.6 (0x00007fe033971000)
>>>>>>>>       libdl.so.2 => /lib64/libdl.so.2 (0x00007fe03376d000)
>>>>>>>>       libcmockery.so.0 => not found
>>>>>>>>       libpthread.so.0 => /lib64/libpthread.so.0 
>>>>>>>> (0x00007fe03354f000)
>>>>>>>>       libcrypto.so.10 => /lib64/libcrypto.so.10 
>>>>>>>> (0x00007fe033168000)
>>>>>>>>       libc.so.6 => /lib64/libc.so.6 (0x00007fe032da9000)
>>>>>>>>       libcmockery.so.0 => not found
>>>>>>>>       libcmockery.so.0 => not found
>>>>>>>>       libcmockery.so.0 => not found
>>>>>>>>       liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fe032b82000)
>>>>>>>>       /lib64/ld-linux-x86-64.so.2 (0x00007fe0351f1000)
>>>>>>>>
>>>>>>>> Should I file a bug report or could someone on the fast-lane 
>>>>>>>> fix this?
>>>>>>> My bad (installation with --nodeps --force :-()
>>>>>> Actually, I was not expecting a dependency on cmockery2. My
>>>>>> understanding was that only some temporary test-applications 
>>>>>> would be
>>>>>> linked with libcmockery and not any binaries that would get 
>>>>>> packaged in
>>>>>> the RPMs.
>>>>>>
>>>>>> Luis, could you clarify that?
>>>>>>
>>>>>> Thanks,
>>>>>> Niels
>>>>>>
>>>>>> _______________________________________________
>>>>>> Gluster-devel mailing list
>>>>>> Gluster-devel at gluster.org
>>>>>> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140722/eafdff13/attachment.html>


More information about the Gluster-devel mailing list