Bug 1562670 - Run libgfapi-python tests on Gerrit against glusterfs changes
Summary: Run libgfapi-python tests on Gerrit against glusterfs changes
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: GlusterFS
Classification: Community
Component: project-infrastructure
Version: mainline
Hardware: All
OS: Unspecified
low
low
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-02 05:22 UTC by Prashanth Pai
Modified: 2020-03-12 12:52 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-12 12:52:34 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Prashanth Pai 2018-04-02 05:22:43 UTC
We can run libgfapi-python functional tests on Gerrit against all glusterfs patches. They take just about a minute or so to run and will compliment tests present at tests/basic/gfapi. They'll help catch regressions due to API changes. They have uncovered few (minor) issues in ligfapi earlier when run manually.

At present, the master of glusterfs repo isn't compatible with libgfapi-python. When that is achieved, the tests can be enabled on Jenkins.

Comment 1 Nigel Babu 2018-07-20 04:43:00 UTC
Is master of libgfapi-python compatible with master of glusterfs now?

Comment 2 Prashanth Pai 2018-07-20 04:49:11 UTC
> Is master of libgfapi-python compatible with master of glusterfs now?

Most likely, no it's not. I'll try it out and confirm though. I'm waiting for all API changes in glusterfs to finish so that I can do the corresponding changes in libgfapi-python all at once.

Comment 3 Amar Tumballi 2018-07-20 05:40:18 UTC
>  I'm waiting for all API changes in glusterfs to finish so that I can do the corresponding changes in libgfapi-python all at once.

I guess that is not an ideal thing to do. Either we have to keep the goal as every release rebase, or consumer (in this case, libgfapi-python) will mandate the version they are compatible. So, even if you run on master, it should fail, because it is not the version one needs.

There will be no chance of knowing when we will have 'all the changes' completed.

Comment 4 Prashanth Pai 2018-07-20 07:08:56 UTC
> I guess that is not an ideal thing to do. Either we have to keep the goal as every release rebase

Every release rebase would be ideal.

> There will be no chance of knowing when we will have 'all the changes' completed.

All the changes planned for a particular release. I think glusterfs release 5 has some API changes planned (that got pushed from 4.1 plan). When all those API changes are in, we can make libgfapi-python rebase to those changes.

Comment 5 Niels de Vos 2018-07-25 10:55:39 UTC
I think we might need to add a way to do feature detection through new gfapi function.

How about adding this:

int glfs_supports(glfs_t *fs, enum glfs_feature)

enum glfs_features {
    GFAPI_READLINK_HAS_FOLLOW = 1,
    GFAPI_GETXATTR_RETURNS_STAT = 2,
    ...
}

It can return 1=YES, 0=NO, -1=unknown feature. Any changes in the API can then be dynamically checked, making it possible for non-compiled languages (like Python) to handle different versions. Some features may be available only when a particular option is set in for the volume, by passing the glfs_t it would be possible to support these kind of requests as well.

Comment 6 Prashanth Pai 2018-09-04 05:10:20 UTC
(In reply to Niels de Vos from comment #5)
> I think we might need to add a way to do feature detection through new gfapi
> function.
> 
> How about adding this:
> 
> int glfs_supports(glfs_t *fs, enum glfs_feature)
> 
> enum glfs_features {
>     GFAPI_READLINK_HAS_FOLLOW = 1,
>     GFAPI_GETXATTR_RETURNS_STAT = 2,
>     ...
> }
> 
> It can return 1=YES, 0=NO, -1=unknown feature. Any changes in the API can
> then be dynamically checked, making it possible for non-compiled languages
> (like Python) to handle different versions. Some features may be available
> only when a particular option is set in for the volume, by passing the
> glfs_t it would be possible to support these kind of requests as well.

Sounds okay to me

Comment 7 Nigel Babu 2018-09-19 15:11:30 UTC
Let's get the tests running in any case. I think it's better to have a nightly job that fails rather than nothing.

Comment 8 Nigel Babu 2018-10-08 02:57:22 UTC
Hey Prashanth, what's the status on this one? How ready are we to get a nightly job running? It's okay to fail.

Comment 9 Prashanth Pai 2018-10-08 04:01:22 UTC
(In reply to Nigel Babu from comment #8)
> Hey Prashanth, what's the status on this one? How ready are we to get a
> nightly job running? It's okay to fail.

We have nightly job on Centos CI running against glusterfs nightly. That job is currently broken. I sent a patch to fix it:

https://github.com/gluster/centosci/pull/22

Comment 11 Worker Ant 2020-03-12 12:52:34 UTC
This bug is moved to https://github.com/gluster/project-infrastructure/issues/28, and will be tracked there from now on. Visit GitHub issues URL for further details


Note You need to log in before you can comment on or make changes to this bug.