Bug 1562670

Is master of libgfapi-python compatible with master of glusterfs now?

> 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.

>  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.

> 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.

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.

(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

Let's get the tests running in any case. I think it's better to have a nightly job that fails rather than nothing.

Hey Prashanth, what's the status on this one? How ready are we to get a nightly job running? It's okay to fail.

(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

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