Re: [Gluster-devel] GlusterD2 - 4.0.0rc1 (warning: we have a blocker for GD2)

2018-03-04 Thread Kaushal M 
On Sat, Mar 3, 2018 at 12:34 AM, Shyam Ranganathan  wrote:
> On 03/02/2018 04:24 AM, Kaushal M wrote:
>> I was able to create libglusterfsd, with just the pmap_signout nad
>> autoscale functions.
>> Turned out to be easy enough to do in the end.
>> I've pushed a patch for review [1] on master.
>
> Thanks!
>
>>
>> I've also opened new bugs to track the fixes for master[2] and
>> release-4.0[3]. They have been made blockers to the glusterfs-4.0.0
>> tracker bug [4].
>>
>> Shyam,
>> To backport the fix from master to release-4.0, also requires
>> backporting one more change [5].
>> Would you be okay with backporting that as well, in a single patch?
>
> I am *not* in favor of taking patch [5], it is a feature change, and so
> late (considering the current build stability as well, if you are
> following other threads).
>
> Is there a way for your patch to land without the dependency?
>

The autoscale function had the dependency. But it is trivial to update
the patch to move the function, even without the dependency.
Later backports from master will be slightly harder though.

>>
>> [1]: https://review.gluster.org/19657
>> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1550895
>> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1550894
>> [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1539842
>> [5]: https://review.gluster.org/19337
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] GlusterD2 - 4.0.0rc1 (warning: we have a blocker for GD2)

2018-03-04 Thread Kaushal M 
On Sat, Mar 3, 2018 at 4:25 AM, Kaleb S. KEITHLEY  wrote:
> On 03/02/2018 04:24 AM, Kaushal M wrote:
>> [snip]
>> I was able to create libglusterfsd, with just the pmap_signout nad
>> autoscale functions.
>> Turned out to be easy enough to do in the end.
>> I've pushed a patch for review [1] on master.
>>
>> I've also opened new bugs to track the fixes for master[2] and
>> release-4.0[3]. They have been made blockers to the glusterfs-4.0.0
>> tracker bug [4].
>
> I really don't like creating this libglusterfsd.so with just two
> functions to get around this. It feels like a quick-and-dirty hack.
> (There's never time to do it right, but there's always time to do it
> over. Except there isn't.)
>
> I've posted a change at https://review.gluster.org/19664 that moves
> those two functions to libgfrpc.so. It works on my f28/rawhide box and
> the various centos and fedora smoke test boxes. No tricky linker flags,
> or anything else, required. Regression is running now.
>
> (And truth be told I'd like to also move glusterfs_mgmt_pmap_signin()
> into libgfrpc.so too. Just for (foolish) consistency/symmetry.)

Moving a specific RPC client implementation into RPC lib doesn't seem
so right to me.
But otherwise, this change is okay with me.

>
>>
>> Shyam,
>> To backport the fix from master to release-4.0, also requires
>> backporting one more change [5].
>> Would you be okay with backporting that as well, in a single patch?
>>
>> [1]: https://review.gluster.org/19657
>> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1550895
>> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1550894
>> [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1539842
>> [5]: https://review.gluster.org/19337
>>

>
>>
>>>
>>> --
>>>
>>> Kaleb
 ___
 Gluster-devel mailing list
 Gluster-devel@gluster.org
 http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>
>>>
>>>
>>>
>>> --
>>> Milind
>>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] GlusterD2 - 4.0.0rc1 (warning: we have a blocker for GD2)

2018-03-02 Thread Kaleb S. KEITHLEY 
On 03/02/2018 04:24 AM, Kaushal M wrote:
> [snip]
> I was able to create libglusterfsd, with just the pmap_signout nad
> autoscale functions.
> Turned out to be easy enough to do in the end.
> I've pushed a patch for review [1] on master.
> 
> I've also opened new bugs to track the fixes for master[2] and
> release-4.0[3]. They have been made blockers to the glusterfs-4.0.0
> tracker bug [4].

I really don't like creating this libglusterfsd.so with just two
functions to get around this. It feels like a quick-and-dirty hack.
(There's never time to do it right, but there's always time to do it
over. Except there isn't.)

I've posted a change at https://review.gluster.org/19664 that moves
those two functions to libgfrpc.so. It works on my f28/rawhide box and
the various centos and fedora smoke test boxes. No tricky linker flags,
or anything else, required. Regression is running now.

(And truth be told I'd like to also move glusterfs_mgmt_pmap_signin()
into libgfrpc.so too. Just for (foolish) consistency/symmetry.)

> 
> Shyam,
> To backport the fix from master to release-4.0, also requires
> backporting one more change [5].
> Would you be okay with backporting that as well, in a single patch?
> 
> [1]: https://review.gluster.org/19657
> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1550895
> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1550894
> [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1539842
> [5]: https://review.gluster.org/19337
> 
>>>

>
>>
>> --
>>
>> Kaleb
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>>
>>
>>
>> --
>> Milind
>>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
> 

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] GlusterD2 - 4.0.0rc1 (warning: we have a blocker for GD2)

2018-03-02 Thread Shyam Ranganathan 
On 03/02/2018 04:24 AM, Kaushal M wrote:
> I was able to create libglusterfsd, with just the pmap_signout nad
> autoscale functions.
> Turned out to be easy enough to do in the end.
> I've pushed a patch for review [1] on master.

Thanks!

> 
> I've also opened new bugs to track the fixes for master[2] and
> release-4.0[3]. They have been made blockers to the glusterfs-4.0.0
> tracker bug [4].
> 
> Shyam,
> To backport the fix from master to release-4.0, also requires
> backporting one more change [5].
> Would you be okay with backporting that as well, in a single patch?

I am *not* in favor of taking patch [5], it is a feature change, and so
late (considering the current build stability as well, if you are
following other threads).

Is there a way for your patch to land without the dependency?

> 
> [1]: https://review.gluster.org/19657
> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1550895
> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1550894
> [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1539842
> [5]: https://review.gluster.org/19337
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] GlusterD2 - 4.0.0rc1 (warning: we have a blocker for GD2)

2018-03-02 Thread Kaushal M 
On Thu, Mar 1, 2018 at 6:22 PM, Milind Changire  wrote:
> Maybe: gcc -Wl,--start-group foo.o bar.o -Wl,--end-group
>
> quote from man ld:
> It is best to use it only when there are unavoidable circular references
> between two or more archives.
>
>
> On Thu, Mar 1, 2018 at 6:18 PM, Kaushal M  wrote:
>>
>> On Thu, Mar 1, 2018 at 6:14 PM, Kaushal M  wrote:
>> > On Thu, Mar 1, 2018 at 12:52 PM, Kaushal M  wrote:
>> >> On Wed, Feb 28, 2018 at 9:50 PM, Kaleb S. KEITHLEY
>> >>  wrote:
>> >>> On 02/28/2018 10:49 AM, Kaushal M wrote:
>>  We have a GlusterD2-4.0.0rc1 release.
>> 
>>  Aravinda, Prashanth and the rest of the GD2 developers have been
>>  working hard on getting more stuff merged into GD2 before the 4.0
>>  release.
>> 
>>  At the same time I have been working on getting GD2 packaged for
>>  Fedora.
>>  I've been able to get all the required dependencies updated and have
>>  submitted to the package maintainer for merging.
>>  I'm now waiting on the maintainer to accept those updates. Once the
>>  updates have been accepted, the GD2 spec can get accepted [2].
>>  I expect this to take at least another week on the whole.
>> 
>>  In the meantime, I've been building all the updated dependencies and
>>  glusterd2-v4.0.0rc1, on the GD2 copr [3].
>> 
>>  I tried to test out the GD2 package with the GlusterFS v4.0.0rc1
>>  release from [4]. And this is where I hit the blocker.
>> 
>>  GD2 does not start with the packaged glusterfs-v4.0.0rc1 bits. I've
>>  opened an issue on the GD2 issue tracker for it [5].
>>  In short, GD2 fails to read options from xlators, as dlopen fails
>>  with
>>  a missing symbol error.
>> 
>>  ```
>>  FATA[2018-02-28 15:02:53.345686] Failed to load xlator options
>> 
>>  error="dlopen(/usr/lib64/glusterfs/4.0.0rc1/xlator/protocol/server.so)
>>  failed; dlerror =
>>  /usr/lib64/glusterfs/4.0.0rc1/xlator/protocol/server.so: undefined
>>  symbol: glusterfs_mgmt_pmap_signout" source="[main.go:79:main.main]"
>> >>>
>> >>>
>> >>> see https://review.gluster.org/#/c/19225/
>> >>>
>> >>>
>> >>> glusterfs_mgmt_pmap_signout() is in glusterfsd. When glusterfsd
>> >>> dlopens
>> >>> server.so the run-time linker can resolve the symbol — for now.
>> >>>
>> >>> Tighter run-time linker semantics coming in, e.g. Fedora 28, means
>> >>> this
>> >>> will stop working in the near future even when RTLD_LAZY is passed as
>> >>> a
>> >>> flag. (As I understand the proposed changes.)
>> >>>
>> >>> It should still work, e.g., on Fedora 27 and el7 though.
>> >>>
>> >>> glusterfs_mgmt_pmap_signout() (and glusterfs_autoscale_threads())
>> >>> really
>> >>> need to be moved to libglusterfs. ASAP. Doing that will resolve this
>> >>> issue.
>> >>
>> >> Thanks for the pointer Kaleb!
>> >>
>> >> But, I'm testing on Fedora 27, where this shouldn't theoretically
>> >> happen.
>> >> So then, why am I hitting this. Is it something to do with the way the
>> >> packages are built?
>> >> Or is there some runtime ld configuration that has been set up.
>> >>
>> >> In any case, we should push and get the offending functions moved into
>> >> libglusterfs.
>> >> That should solve the problem for us.
>> >
>> > I took a shot at this, and it's not as easy simple as it appeared.
>> > I ended up in a recursive linking situation with libglusterfs,
>> > libgfxdr and libgfrpc.
>> > Looks like the solution is to create a libglusterfsd.
>>
>> I see two ways to do this.
>> 1. Make a library out of the whole glusterfsd.
>> Rename `main` to `init`
>> And then create a simple executable which loads this library and calls
>> `init`.
>>
>> Or,
>> 2. Create a very small library with just the pmap_signout and
>> autoscale functions. And use that instead.
>>
>> If anyone else has a better idea about how to do this please let me know.

I was able to create libglusterfsd, with just the pmap_signout nad
autoscale functions.
Turned out to be easy enough to do in the end.
I've pushed a patch for review [1] on master.

I've also opened new bugs to track the fixes for master[2] and
release-4.0[3]. They have been made blockers to the glusterfs-4.0.0
tracker bug [4].

Shyam,
To backport the fix from master to release-4.0, also requires
backporting one more change [5].
Would you be okay with backporting that as well, in a single patch?

[1]: https://review.gluster.org/19657
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1550895
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=1550894
[4]: https://bugzilla.redhat.com/show_bug.cgi?id=1539842
[5]: https://review.gluster.org/19337

>>
>> >
>> >>
>> >>>
>> >>> --
>> >>>
>> >>> Kaleb
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>
>
> --
> Milind
>

Re: [Gluster-devel] GlusterD2 - 4.0.0rc1 (warning: we have a blocker for GD2)

2018-03-01 Thread Kaushal M 
On Thu, Mar 1, 2018 at 6:14 PM, Kaushal M  wrote:
> On Thu, Mar 1, 2018 at 12:52 PM, Kaushal M  wrote:
>> On Wed, Feb 28, 2018 at 9:50 PM, Kaleb S. KEITHLEY  
>> wrote:
>>> On 02/28/2018 10:49 AM, Kaushal M wrote:
 We have a GlusterD2-4.0.0rc1 release.

 Aravinda, Prashanth and the rest of the GD2 developers have been
 working hard on getting more stuff merged into GD2 before the 4.0
 release.

 At the same time I have been working on getting GD2 packaged for Fedora.
 I've been able to get all the required dependencies updated and have
 submitted to the package maintainer for merging.
 I'm now waiting on the maintainer to accept those updates. Once the
 updates have been accepted, the GD2 spec can get accepted [2].
 I expect this to take at least another week on the whole.

 In the meantime, I've been building all the updated dependencies and
 glusterd2-v4.0.0rc1, on the GD2 copr [3].

 I tried to test out the GD2 package with the GlusterFS v4.0.0rc1
 release from [4]. And this is where I hit the blocker.

 GD2 does not start with the packaged glusterfs-v4.0.0rc1 bits. I've
 opened an issue on the GD2 issue tracker for it [5].
 In short, GD2 fails to read options from xlators, as dlopen fails with
 a missing symbol error.

 ```
 FATA[2018-02-28 15:02:53.345686] Failed to load xlator options
 
 error="dlopen(/usr/lib64/glusterfs/4.0.0rc1/xlator/protocol/server.so)
 failed; dlerror =
 /usr/lib64/glusterfs/4.0.0rc1/xlator/protocol/server.so: undefined
 symbol: glusterfs_mgmt_pmap_signout" source="[main.go:79:main.main]"
>>>
>>>
>>> see https://review.gluster.org/#/c/19225/
>>>
>>>
>>> glusterfs_mgmt_pmap_signout() is in glusterfsd. When glusterfsd dlopens
>>> server.so the run-time linker can resolve the symbol — for now.
>>>
>>> Tighter run-time linker semantics coming in, e.g. Fedora 28, means this
>>> will stop working in the near future even when RTLD_LAZY is passed as a
>>> flag. (As I understand the proposed changes.)
>>>
>>> It should still work, e.g., on Fedora 27 and el7 though.
>>>
>>> glusterfs_mgmt_pmap_signout() (and glusterfs_autoscale_threads()) really
>>> need to be moved to libglusterfs. ASAP. Doing that will resolve this issue.
>>
>> Thanks for the pointer Kaleb!
>>
>> But, I'm testing on Fedora 27, where this shouldn't theoretically happen.
>> So then, why am I hitting this. Is it something to do with the way the
>> packages are built?
>> Or is there some runtime ld configuration that has been set up.
>>
>> In any case, we should push and get the offending functions moved into
>> libglusterfs.
>> That should solve the problem for us.
>
> I took a shot at this, and it's not as easy simple as it appeared.
> I ended up in a recursive linking situation with libglusterfs,
> libgfxdr and libgfrpc.
> Looks like the solution is to create a libglusterfsd.

I see two ways to do this.
1. Make a library out of the whole glusterfsd.
Rename `main` to `init`
And then create a simple executable which loads this library and calls `init`.

Or,
2. Create a very small library with just the pmap_signout and
autoscale functions. And use that instead.

If anyone else has a better idea about how to do this please let me know.

>
>>
>>>
>>> --
>>>
>>> Kaleb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] GlusterD2 - 4.0.0rc1 (warning: we have a blocker for GD2)

2018-03-01 Thread Kaushal M 
On Thu, Mar 1, 2018 at 12:52 PM, Kaushal M  wrote:
> On Wed, Feb 28, 2018 at 9:50 PM, Kaleb S. KEITHLEY  
> wrote:
>> On 02/28/2018 10:49 AM, Kaushal M wrote:
>>> We have a GlusterD2-4.0.0rc1 release.
>>>
>>> Aravinda, Prashanth and the rest of the GD2 developers have been
>>> working hard on getting more stuff merged into GD2 before the 4.0
>>> release.
>>>
>>> At the same time I have been working on getting GD2 packaged for Fedora.
>>> I've been able to get all the required dependencies updated and have
>>> submitted to the package maintainer for merging.
>>> I'm now waiting on the maintainer to accept those updates. Once the
>>> updates have been accepted, the GD2 spec can get accepted [2].
>>> I expect this to take at least another week on the whole.
>>>
>>> In the meantime, I've been building all the updated dependencies and
>>> glusterd2-v4.0.0rc1, on the GD2 copr [3].
>>>
>>> I tried to test out the GD2 package with the GlusterFS v4.0.0rc1
>>> release from [4]. And this is where I hit the blocker.
>>>
>>> GD2 does not start with the packaged glusterfs-v4.0.0rc1 bits. I've
>>> opened an issue on the GD2 issue tracker for it [5].
>>> In short, GD2 fails to read options from xlators, as dlopen fails with
>>> a missing symbol error.
>>>
>>> ```
>>> FATA[2018-02-28 15:02:53.345686] Failed to load xlator options
>>> 
>>> error="dlopen(/usr/lib64/glusterfs/4.0.0rc1/xlator/protocol/server.so)
>>> failed; dlerror =
>>> /usr/lib64/glusterfs/4.0.0rc1/xlator/protocol/server.so: undefined
>>> symbol: glusterfs_mgmt_pmap_signout" source="[main.go:79:main.main]"
>>
>>
>> see https://review.gluster.org/#/c/19225/
>>
>>
>> glusterfs_mgmt_pmap_signout() is in glusterfsd. When glusterfsd dlopens
>> server.so the run-time linker can resolve the symbol — for now.
>>
>> Tighter run-time linker semantics coming in, e.g. Fedora 28, means this
>> will stop working in the near future even when RTLD_LAZY is passed as a
>> flag. (As I understand the proposed changes.)
>>
>> It should still work, e.g., on Fedora 27 and el7 though.
>>
>> glusterfs_mgmt_pmap_signout() (and glusterfs_autoscale_threads()) really
>> need to be moved to libglusterfs. ASAP. Doing that will resolve this issue.
>
> Thanks for the pointer Kaleb!
>
> But, I'm testing on Fedora 27, where this shouldn't theoretically happen.
> So then, why am I hitting this. Is it something to do with the way the
> packages are built?
> Or is there some runtime ld configuration that has been set up.
>
> In any case, we should push and get the offending functions moved into
> libglusterfs.
> That should solve the problem for us.

I took a shot at this, and it's not as easy simple as it appeared.
I ended up in a recursive linking situation with libglusterfs,
libgfxdr and libgfrpc.
Looks like the solution is to create a libglusterfsd.

>
>>
>> --
>>
>> Kaleb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] GlusterD2 - 4.0.0rc1 (warning: we have a blocker for GD2)

2018-02-28 Thread Kaushal M 
On Wed, Feb 28, 2018 at 9:50 PM, Kaleb S. KEITHLEY  wrote:
> On 02/28/2018 10:49 AM, Kaushal M wrote:
>> We have a GlusterD2-4.0.0rc1 release.
>>
>> Aravinda, Prashanth and the rest of the GD2 developers have been
>> working hard on getting more stuff merged into GD2 before the 4.0
>> release.
>>
>> At the same time I have been working on getting GD2 packaged for Fedora.
>> I've been able to get all the required dependencies updated and have
>> submitted to the package maintainer for merging.
>> I'm now waiting on the maintainer to accept those updates. Once the
>> updates have been accepted, the GD2 spec can get accepted [2].
>> I expect this to take at least another week on the whole.
>>
>> In the meantime, I've been building all the updated dependencies and
>> glusterd2-v4.0.0rc1, on the GD2 copr [3].
>>
>> I tried to test out the GD2 package with the GlusterFS v4.0.0rc1
>> release from [4]. And this is where I hit the blocker.
>>
>> GD2 does not start with the packaged glusterfs-v4.0.0rc1 bits. I've
>> opened an issue on the GD2 issue tracker for it [5].
>> In short, GD2 fails to read options from xlators, as dlopen fails with
>> a missing symbol error.
>>
>> ```
>> FATA[2018-02-28 15:02:53.345686] Failed to load xlator options
>> 
>> error="dlopen(/usr/lib64/glusterfs/4.0.0rc1/xlator/protocol/server.so)
>> failed; dlerror =
>> /usr/lib64/glusterfs/4.0.0rc1/xlator/protocol/server.so: undefined
>> symbol: glusterfs_mgmt_pmap_signout" source="[main.go:79:main.main]"
>
>
> see https://review.gluster.org/#/c/19225/
>
>
> glusterfs_mgmt_pmap_signout() is in glusterfsd. When glusterfsd dlopens
> server.so the run-time linker can resolve the symbol — for now.
>
> Tighter run-time linker semantics coming in, e.g. Fedora 28, means this
> will stop working in the near future even when RTLD_LAZY is passed as a
> flag. (As I understand the proposed changes.)
>
> It should still work, e.g., on Fedora 27 and el7 though.
>
> glusterfs_mgmt_pmap_signout() (and glusterfs_autoscale_threads()) really
> need to be moved to libglusterfs. ASAP. Doing that will resolve this issue.

Thanks for the pointer Kaleb!

But, I'm testing on Fedora 27, where this shouldn't theoretically happen.
So then, why am I hitting this. Is it something to do with the way the
packages are built?
Or is there some runtime ld configuration that has been set up.

In any case, we should push and get the offending functions moved into
libglusterfs.
That should solve the problem for us.

>
> --
>
> Kaleb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] GlusterD2 - 4.0.0rc1 (warning: we have a blocker for GD2)

2018-02-28 Thread Kaleb S. KEITHLEY 
On 02/28/2018 10:49 AM, Kaushal M wrote:
> We have a GlusterD2-4.0.0rc1 release.
> 
> Aravinda, Prashanth and the rest of the GD2 developers have been
> working hard on getting more stuff merged into GD2 before the 4.0
> release.
> 
> At the same time I have been working on getting GD2 packaged for Fedora.
> I've been able to get all the required dependencies updated and have
> submitted to the package maintainer for merging.
> I'm now waiting on the maintainer to accept those updates. Once the
> updates have been accepted, the GD2 spec can get accepted [2].
> I expect this to take at least another week on the whole.
> 
> In the meantime, I've been building all the updated dependencies and
> glusterd2-v4.0.0rc1, on the GD2 copr [3].
> 
> I tried to test out the GD2 package with the GlusterFS v4.0.0rc1
> release from [4]. And this is where I hit the blocker.
> 
> GD2 does not start with the packaged glusterfs-v4.0.0rc1 bits. I've
> opened an issue on the GD2 issue tracker for it [5].
> In short, GD2 fails to read options from xlators, as dlopen fails with
> a missing symbol error.
> 
> ```
> FATA[2018-02-28 15:02:53.345686] Failed to load xlator options
> error="dlopen(/usr/lib64/glusterfs/4.0.0rc1/xlator/protocol/server.so)
> failed; dlerror =
> /usr/lib64/glusterfs/4.0.0rc1/xlator/protocol/server.so: undefined
> symbol: glusterfs_mgmt_pmap_signout" source="[main.go:79:main.main]"


see https://review.gluster.org/#/c/19225/


glusterfs_mgmt_pmap_signout() is in glusterfsd. When glusterfsd dlopens
server.so the run-time linker can resolve the symbol — for now.

Tighter run-time linker semantics coming in, e.g. Fedora 28, means this
will stop working in the near future even when RTLD_LAZY is passed as a
flag. (As I understand the proposed changes.)

It should still work, e.g., on Fedora 27 and el7 though.

glusterfs_mgmt_pmap_signout() (and glusterfs_autoscale_threads()) really
need to be moved to libglusterfs. ASAP. Doing that will resolve this issue.

-- 

Kaleb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel