[Gluster-devel] New Testing Framework For Gluster
Greetings Gluster community, Following recent discussions on the effectiveness of the current functional test framework (glusto_test), I've prepared a doc specifying why in my opinion the glusto_test needs to be abandoned and a new testing framework should be created: https://docs.google.com/document/d/1g0jb04IN0ENic3CovCGJMILLQXMhnD930QeF1bzTlh4/edit?usp=sharing In addition, I've also prepared a doc detailing a design for a new testing framework: https://docs.google.com/document/d/1D8zUSmg-00ey711gsqvS6G9i_fGN2cE0EbG4u1TOsaQ/edit?usp=sharing Please share your thoughts and views on the matter. Regards. -- *Barak Sason Rofman* Gluster Storage Development Red Hat Israel <https://www.redhat.com/> 34 Jerusalem rd. Ra'anana, 43501 bsaso...@redhat.com T: *+972-9-7692304* M: *+972-52-4326355* @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/redhat.il/> <https://red.ht/sig> --- Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://meet.google.com/cpu-eiue-hvk Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] RFE - Global Layout
Hello Nag, Thank you for looking into my proposal. I've Included the GitHub link in the doc and also modified the for commenting - so we'll have both options. I've lso and commented on the GitHub issue. Thank you for bringing it to my attention. My regards, On Thu, Aug 13, 2020 at 8:30 PM Nag Pavan Chilakam wrote: > Hello Barak, > Firstly, thanks for your effort in trying to improve glusterfs > performance, appreciate it. > Looks like you haven't given comment access to the google doc. > Anyways it is a better practice to capture comments in the git issue. I > have put a comment there. > Maybe , you can add a note in the google doc, at the beginning saying > reviewers to comment on the git issue with the git-issue link. > > regards, > nag pavan chilakam > > On Wed, Aug 12, 2020 at 12:31 PM Barak Sason Rofman > wrote: > >> Greetings everyone, >> >> I want to bring up for discussion a proposition that I personally think >> may be very beneficial to the project. >> This proposition involves modification in the DHT layer and the design >> and implementation of other distribution mechanism. >> As of today, Gluster employs a per-directory layout mechanism. A >> different approach, Global Layout, might provide substantial benefits to >> the product. >> For more details regarding this proposal, I've created the following >> GitHub issue and POC doc: >> https://github.com/gluster/glusterfs/issues/1433 >> >> https://docs.google.com/document/d/1wX8BBcenOK_GbUCGuJN8vlZIEkZ4MbvD3EFDegot-kM/edit?usp=sharing >> >> I welcome all of you to share your news on the subject. >> >> Thank you all. >> -- >> *Barak Sason Rofman* >> >> Gluster Storage Development >> >> Red Hat Israel <https://www.redhat.com/> >> >> 34 Jerusalem rd. Ra'anana, 43501 >> >> bsaso...@redhat.com T: *+972-9-7692304* >> M: *+972-52-4326355* >> @RedHat <https://twitter.com/redhat> Red Hat >> <https://www.linkedin.com/company/red-hat> Red Hat >> <https://www.facebook.com/redhat.il/> >> <https://red.ht/sig> >> _______ >> >> Community Meeting Calendar: >> >> Schedule - >> Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC >> Bridge: https://bluejeans.com/441850968 >> >> >> >> >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-devel >> >> -- *Barak Sason Rofman* Gluster Storage Development Red Hat Israel <https://www.redhat.com/> 34 Jerusalem rd. Ra'anana, 43501 bsaso...@redhat.com T: *+972-9-7692304* M: *+972-52-4326355* @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/redhat.il/> <https://red.ht/sig> ___ Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://bluejeans.com/441850968 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] RFE - Global Layout
Greetings everyone, I want to bring up for discussion a proposition that I personally think may be very beneficial to the project. This proposition involves modification in the DHT layer and the design and implementation of other distribution mechanism. As of today, Gluster employs a per-directory layout mechanism. A different approach, Global Layout, might provide substantial benefits to the product. For more details regarding this proposal, I've created the following GitHub issue and POC doc: https://github.com/gluster/glusterfs/issues/1433 https://docs.google.com/document/d/1wX8BBcenOK_GbUCGuJN8vlZIEkZ4MbvD3EFDegot-kM/edit?usp=sharing I welcome all of you to share your news on the subject. Thank you all. -- *Barak Sason Rofman* Gluster Storage Development Red Hat Israel <https://www.redhat.com/> 34 Jerusalem rd. Ra'anana, 43501 bsaso...@redhat.com T: *+972-9-7692304* M: *+972-52-4326355* @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/redhat.il/> <https://red.ht/sig> ___ Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://bluejeans.com/441850968 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Multithreaded Iterative Dir Tree Scan
Hello everyone! Following a discussion I had with @Susant Palai some time ago, we have decided to look into an option to improve the rebalance process in the DHT layer by modifying the underlying mechanism. Currently, dir-tree crawling is done recursively, by a single thread, which is likely slow and also poses the risk of stack overflow. An iterative multithreaded solution might improve performance and also stability (by eliminating the risk of stack overflow). I have prepared a POC doc on the matter, including a sample implementation of the iterative multithreaded solution. The doc can be found at: https://docs.google.com/document/d/1JCl0T9zeagOcFFpgVQF8zNyhlR54VqkNAZ7TJb42egE/edit <https://docs.google.com/document/d/1L0uHgFbrNWWxCQB6s4YcoymKrO7q0yVAbEIWWIiu_as/edit?usp=sharing>Apart from the rebalance process, maybe this approach can be useful for other use-cases where dir-tree crawl is being performed? Any comments on the concept, the design of the solution and the implementation are welcome. -- *Barak Sason Rofman* Gluster Storage Development Red Hat Israel <https://www.redhat.com/> 34 Jerusalem rd. Ra'anana, 43501 bsaso...@redhat.com T: *+972-9-7692304* M: *+972-52-4326355* <https://red.ht/sig> ___ Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://bluejeans.com/441850968 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Method types and return values handling
Hello everyone, I'd like to bring some points up for discussion: 1 - We have a great number of methods all across Gluster which (for example) are declared to be 'int' but in reality return (for example) 0 in all cases, both on the positive and the negative path. 2 - In many cases there are calls to methods that return a value, but this value is completely ignored (e.g. the method 'foo(...)' return an int, but all calls are in the form of 'foo(...)' instead of ret = 'foo(...)' ). These 2 issues adversely affects the readability/maintainability of the project and probably also affect error handling (if an error occurs in a method that always returns 0, how will the calling methods know that an error happened?). These issues are not specific to a certain component, but seem to be all across the project. I believe this needs addressing, and probably in one of the following ways: 1 - Change methods to 'void', where there is really no need for a return value. 2 - Actually handle the return value and log erros accordingly. Of course discretion is needed and in some cases we could change to void, while in other handle the return value. I'd like to hear opinions on if and how this needs to be handled. Thank you all. -- *Barak Sason Rofman* Gluster Storage Development Red Hat Israel <https://www.redhat.com/> 34 Jerusalem rd. Ra'anana, 43501 bsaso...@redhat.com T: *+972-9-7692304* M: *+972-52-4326355* <https://red.ht/sig> ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/441850968 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/441850968 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-Maintainers] Modifying gluster's logging mechanism
Greetings all and thank you for your contribution to this discussion.
Amar and Sankarshan, regarding your comments:
> * First of all, when we looked at log very early in project's life, our
> idea was based mostly on kernel logs (/var/log/messages). We decided, as a
> file-system, because it is very active with I/Os and should run for years
> together without failing, there should be NO log messages when the system
> is healthy, which should be 99%+ time.
>
> * Now, if there are no logs when everything is healthy, and most of the
> things are healthy 99% of the time, naturally the focus was not
> 'performance' of logging infra, but the correctness. This is where, the
> strict ordering through locks to preserve the timestamps of logs, and have
> it organized came by.
>
I believe this can be said about pretty much every software - nothing is
designed to break (except maybe *piñatas*?).
I am curious though - when the project had begun, there were no INFO levels
logs? These logs are logged even when everything is healthy.
In any case, we can set the history aside and focus on the present, and I
believe many components were upgraded and improved over time and it looks
like the logger was left behind, and is seems there are consequences for
this now.
That is interesting observation. For this alone, can we have an option to
> disable all logging during regression? That would fasten up things for
> normal runs immediately.
We had an idea that could have improved CI time, but because the test
module is built in such a way that each test starts gluster by itself, our
idea was not feasible as it would require modification to all the tests (we
wanted to run tests with no logging, and do log only when a test fails, on
the re-run).
Anyway, IMO, turning off logging does not help us at all handle the core
problem, and I also believe it may send a wrong message to our users ("our
logging is not good enough so we decide to get rid of it instead of
improving it").
And I fully agree with Sankarshan's comment:
> If having quicker regression runs is the objective, then perhaps we should
> not look at turning off logging to accomplish them. Instead, there ought to
> be additional aspects which can be reviewed with turning off logging being
> the last available option.
>
> Please make sure, we have minimum dependency on this project, and also the
> install steps are easy for your project. One of the reasons Gluster
> succeeded is because it is very easy to install (and uninstall), without
> much dependencies. I personally would like to keep that behavior same.
>
I did not mean for it to be a dependency for the project, I suggested that
as an alternative logging solution that would be fully integrated into
gluster.
I am in agreement with Sankarshan, who responded in another thread about
> tools like EFK/ELK stack for centralized logging. By moving to centralized
> logging, and having proper structure for logging, the initial goals we had
> wouldn't be broken, and we will have better performance even when we are
> logging in DEBUG mode.
>
I do not know enough about EFK/ELK to base an opinion, but I understand
from your comments that this is considered standard components for logging
etc'.
I'm not against this at all but I do need to investigate more before I
could share my thoughts on the technical aspects.
[Amar] This, in my opinion is a good reason to undertake this activity.
> Mainly because we should be having our logging infra similar with other
> tools, and one shouldn't be having a learning curve to understand gluster's
> logging.
[Sankarshan] The original proposal from Barak has merit for planning
> towards an alpha form to be available.
>
I'm very happy to hear this, as it gives me confidence in my actions, thank
you.
Unfortunately, I've been informed that I'm not to pursue this initiative at
the current time, as there are other, higher, priorities that requires
resources and it was decided not to dedicate them for this initiative.
I do hope that when the time is right, we could revisit this discussion and
see how we can advance on that front.
If anyone has insight he'd like to share, I'd be happy to discuss it.
Thank you all very much,
On Wed, Nov 27, 2019 at 4:33 AM Sankarshan Mukhopadhyay <
sankarshan.mukhopadh...@gmail.com> wrote:
>
>
> On Wed, Nov 27, 2019 at 7:44 AM Amar Tumballi wrote:
>
>> Hi Barak,
>>
>> My replies inline.
>>
>> On Thu, Nov 21, 2019 at 6:34 PM Barak Sason Rofman
>> wrote:
>>
>>>
>>>
> [snip]
>
>
>>
>>> Initial tests, done by *removing logging from the regression testing,
>>> shows an improvement of about 20% in run time*. This indicates we’re
>>> taking a pretty heavy performance h
Re: [Gluster-devel] [Gluster-Maintainers] Modifying gluster's logging mechanism
Thank you all for participating in this discussion. Regarding Yaniv's comments: > If you need an external tool (please not Java - let's not add another > language to the project), you might as well move to binary logging. > I believe we need to be able to do this sort using Linux command line > tools only. > My intention was not at all to perform ordering using Java. Ordering of the logs can be done easily using Python or even C (these are the tools that I know). I'd be happy to know how this can be done with just Linux CLI, please share your insight. Regarding Java - I only meant to use it as a GUI tool (Java Swift). A GUI tool that presents ordered logs in a couple of ways (e.g. a tab that shows the sorted logs for all threads, separate tabs per threads etc') may add some value. Regarding the binary logging, actually the system I proposed is already "semi binary", as it logs time-stamp as raw hex. A switch to full binary is fairly simple and I do see advantages with that proposal. This is not a fair comparison: > 1. The regression tests are running with debug log > 2. Not logging at all != replacing the logging framework - the new one > will have its own overhead as well. > 3. I believe there's a lot of code that is not real life scenarios there - > such as dumping a lot of data there (which causes a lot of calls to > inode_find() and friends - for example). > 1 - Actually I'm not sure about this. need to verify. 2 - I haven't claimed that with a new system we'd suddenly have a 20% performance increase. I have pointed out a potential problematic influence of the current mechanism that users (and developers) may be unaware of (as Strahil's comment suggests). 3 - That's the power of a community. I encourage users and developers to perform further tests on the matter, with real life scenarios, so we'd have a better understanding of the impact. Regarding Ravi's comments: > maintaining causality of messages and working > with command line text editors and tools on log files is important IMO. > Will running a tool in the form of "# logOrderer /someDireWithLogs" and having logs sorted in the way they are currently sorted will be so bad? Furthermore, The system I proposed can easily produce ordered logs if no threads are registered for a private buffer (As I mentioned, and as the project documentation mentions, if a thread doesn;t have a private buffer, he automatically falls down to "level 2" writing, which is writing to a shared buffer - basic async logging. Level 2 and 3 maintain log ordering). I think at this point we can focus the discussion at 2 points: 1 - Do we want to change the current system? The current mechanism is "synced" logging, which definitely hurts performance. Are we OK with taking that hit or do we want to improve? "Async logging" is not a new concept it certainly has it's advantages over "synced" logging. 2 - Given that the answer for question 1 is "yes", what do we require from the new logging system? I proposed a system I've been developing as a side project for the past couple of weeks and I'd appreciate looking at the proposed mechanism if comments are made specifically on it (and remember that the project is still a work in progress). Lastly, there are a lot of logging alternatives out there (e.g. Log4c) which are definitely worth consideration. Lastly I want to adress Strahil's comment: > As an end user, I think that performance improvents must be of outmost > priority and this 'async logging' approach makes sense. > Actually, you make me think If I really need such detailed logs (I'm > running an oVirt lab) , as I can benefit from logless gluster's > performance. > Obviously there are many different users with many different use cases out there and I believe we should be flexible enough to provide them with a suitable solution for their needs. I'd hate to see users turn off logging just because it hurts their performance as it would hurt our ability as developers to provide support when needed. Again, thank you for participating and looking forward for more comments and input, On Fri, Nov 22, 2019 at 12:19 PM Ravishankar N wrote: > > On 22/11/19 3:13 pm, Barak Sason Rofman wrote: > > This is actually one of the main reasons I wanted to bring this up for > > discussion - will it be fine with the community to run a dedicated > > tool to reorder the logs offline? > > I think it is a bad idea to log without ordering and later relying on an > external tool to sort it. This is definitely not something I would want > to do while doing test and development or debugging field issues. > Structured logging is definitely useful for gathering statistics and > post-processing to make reports and chart
Re: [Gluster-devel] Modifying gluster's logging mechanism
Thank you for your input Atin and Xie Changlong. Regarding log ordering - my initial thought was to do it offline using a dedicated too. Should be straight forward, as the logs have time stamp composed of seconds and microseconds, so ordering them using this value is definitely possible. This is actually one of the main reasons I wanted to bring this up for discussion - will it be fine with the community to run a dedicated tool to reorder the logs offline? Reordering the logs offline will allow us to gain the most performance improvement, as keeping the logs order online will have some cost (probably through stronger synchronization). Moreover, we can take log viewing one step further and maybe create some GUI system (JAVA based?) to view and handle logs (e.g. one window to show the combined order logs, other windows to show logs per thread etc'). Regarding the test method - my initial testing was done by removing all logging from regression. Modifying the method "skip_logging" to return 'true' in all cases seems to remove most of the logs (though not all, "to be on the safe side", really removing all logging related methods is probably even better). As regression tests use mostly single-node tests, some additional testing was needed. I've written a couple of very basic scripts to create large number of files / big files, read / write to / from them, move them around and perform some other basic functionality. I'd actually be glad to test this in some 'real world' use cases - if you have specific use cases that you use frequently, we can model them and benchmark against - this will likely offer an even more accurate benchmark. On Fri, Nov 22, 2019 at 7:27 AM Xie Changlong wrote: > > 在 2019/11/21 21:04, Barak Sason Rofman 写道: > > I see two design / implementation problems with that mechanism: > >1. > >The mutex that guards the log file is likely under constant contention. >2. > >The fact that each worker thread perform the IO by himself, thus >slowing his "real" work. > > > Initial tests, done by *removing logging from the regression testing, > shows an improvement of about 20% in run time*. This indicates we’re > taking a pretty heavy performance hit just because of the logging activity. > > Hi Barak Sason Rofman. Amazing perf improvement! Could show me the detail > test method ? > > Thanks > > -Xie > > In addition to these problems, the logging module is due for an upgrade: > >1. > >There are dozens of APIs in the logger, much of them are deprecated - >this makes it very hard for new developers to keep evolving the project. > 2. > >One of the key points for Gluster-X, presented in October at >Bangalore, is the switch to a structured logging all across gluster. > > -- *Barak Sason Rofman* Gluster Storage Development Red Hat Israel <https://www.redhat.com/> 34 Jerusalem rd. Ra'anana, 43501 bsaso...@redhat.com T: *+972-9-7692304* M: *+972-52-4326355* <https://red.ht/sig> ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/441850968 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/441850968 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Modifying gluster's logging mechanism
Hello Gluster community, My name is Barak and I’ve joined RH gluster development in August. Shortly after my arrival, I’ve identified a potential problem with gluster’s logging mechanism and I’d like to bring the matter up for discussion. The general concept of the current mechanism is that every worker thread that needs to log a message has to contend for a mutex which guards the log file, write the message and, flush the data and then release the mutex. I see two design / implementation problems with that mechanism: 1. The mutex that guards the log file is likely under constant contention. 2. The fact that each worker thread perform the IO by himself, thus slowing his "real" work. Initial tests, done by *removing logging from the regression testing, shows an improvement of about 20% in run time*. This indicates we’re taking a pretty heavy performance hit just because of the logging activity. In addition to these problems, the logging module is due for an upgrade: 1. There are dozens of APIs in the logger, much of them are deprecated - this makes it very hard for new developers to keep evolving the project. 2. One of the key points for Gluster-X, presented in October at Bangalore, is the switch to a structured logging all across gluster. Given these points, I believe we’re in a position that allows us to upgrade the logging mechanism by both switching to structured logging across the project AND replacing the logging system itself, thus “killing two birds with one stone”. Moreover, if the upgrade is successful, the new logger mechanism might be adopted by other teams in Red Hat, which lead to uniform logging activity across different products. I’d like to propose a logging utility I’ve been working on for the past few weeks. This project is still a work in progress (and still much work needs to be done in it), but I’d like to bring this matter up now so if the community will want to advance on that front, we could collaborate and shape the logger to best suit the community’s needs. An overview of the system: The logger provides several (number and size are user-defined) pre-allocated buffers which threads can 'register' to and receive a private buffer. In addition, a single, shared buffer is also pre-allocated (size is user-defined). The number of buffers and their size is modifiable at runtime (not yet implemented). Worker threads write messages in one of 3 ways that will be described next, and an internal logger threads constantly iterates the existing buffers and drains the data to the log file. As all allocations are allocated at the initialization stage, no special treatment it needed for "out of memory" cases. The following writing levels exist: 1. Level 1 - Lockless writing: Lockless writing is achieved by assigning each thread a private ring buffer. A worker threads write to that buffer and the logger thread drains that buffer into a log file. In case the private ring buffer is full and not yet drained, or in case the worker thread has not registered for a private buffer, we fall down to the following writing methods: 1. Level 2 - Shared buffer writing: The worker thread will write it's data into a buffer that's shared across all threads. This is done in a synchronized manner. In case the private ring buffer is full and not yet drained AND the shared ring buffer is full and not yet drained, or in case the worker thread has not registered for a private buffer, we fall down to the last writing method: 1. Level 3 - Direct write: This is the slowest form of writing - the worker thread directly write to the log file. The idea behind this utility is to reduce as much as possible the impact of logging on runtime. Part of this reduction comes at the cost of having to parse and reorganize the messages in the log files using a dedicated tool (yet to be implemented) as there is no guarantee on the order of logged messages. The full logger project is hosted on: https://github.com/BarakSason/Lockless_Logger For project documentation visit: https://baraksason.github.io/Lockless_Logger/ I thank you all for reading through my suggestion and I’m looking forward to your feedback, -- *Barak Sason Rofman* Gluster Storage Development Red Hat Israel <https://www.redhat.com/> 34 Jerusalem rd. Ra'anana, 43501 bsaso...@redhat.com T: *+972-9-7692304* M: *+972-52-4326355* <https://red.ht/sig> ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/441850968 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/441850968 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] How does Gluster works - Locating files after change sin cluster
Hello everyone, I'm about to post several threads with question regarding how Gluster handles different scenarios. I'm looking for answers on architecture/design/"the is the idea" level, and not specifically implementation (however, it would be nice to know where the relevant code is). In this thread I want to focus on the "adding servers/bricks" scenario. >From what I know at this point, every file that's created is given a 32-bit value based on it's name, and this hashing function is fixed and independent of any factors. Next, there is a function (a routing method), located on the client side, that *is* dependent on outside factors, such as numbers of servers (or bricks) in the system which determines on which server a particular file is located. Let's examine the following case: Assume (for simplicity's sake) that the hashing function assign values to file in 1-100 range (instead of 32-bit) and currently there are 4 servers in the cluster. In this case, files 1-25 would be located on server 1, 26-50 on server 2 and so on. Now, if a 5th server is added to the cluster, then the ranges will change: files 1-20 will be located on server 1, 21-40 on server 2 and so on. The questions regarding this scenarios are as follows: 1 - Does the servers update the clients that an additional server (or brick) has been added to the cluster? If not, how does this happen? 2 - Does the server also know which files *should* be located on them? if so, does the servers create a link file (which specifies the "real" location of the file) for the files that are supposed to be moved (e.g. files 21-25) or actually move the data right away? Maybe this works in a completely different manner? I have additional questions regarding this, but they are dependent om the answers to these question. Thank you all for your help. -- *Barak Sason Rofman* Gluster Storage Development Red Hat Israel <https://www.redhat.com/> 34 Jerusalem rd. Ra'anana, 43501 bsaso...@redhat.com T: *+972-9-7692304* M: *+972-52-4326355* <https://red.ht/sig> ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Proposal: move glusterfs development to github workflow, completely
Greetings all, As a new developer on the project, I might add a fresh look on the matter. Before I can here I was familiar with Github and unfamiliar with Gerrit. Understanding Gerrit itself wasn't too troublesome, but also not needed as I see no benefit of using that system, because as others suggested, solutions like Gerrithub exist. In general centralized workflow is always welcomed and personally I'd be happy to make the switch. +1 for me. On Mon, Aug 26, 2019 at 10:06 AM Ravishankar N wrote: > > On 24/08/19 9:26 AM, Yaniv Kaul wrote: > > I don't like mixed mode, but I also dislike Github's code review > > tools, so I'd like to remind the option of using http://gerrithub.io/ > > for code review. > > Other than that, I'm in favor of moving over. > > Y. > +1 for using gerrithub for code review when we move to github. > ___ > > Community Meeting Calendar: > > APAC Schedule - > Every 2nd and 4th Tuesday at 11:30 AM IST > Bridge: https://bluejeans.com/836554017 > > NA/EMEA Schedule - > Every 1st and 3rd Tuesday at 01:00 PM EDT > Bridge: https://bluejeans.com/486278655 > > Gluster-devel mailing list > Gluster-devel@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-devel > > -- *Barak Sason Rofman* Gluster Storage Development Red Hat Israel <https://www.redhat.com/> 34 Jerusalem rd. Ra'anana, 43501 bsaso...@redhat.com T: *+972-9-7692304* M: *+972-52-4326355* <https://red.ht/sig> ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Gluster on RHEL 8
Thank you very much! Everything is working now. I've gathered several technical difficulties such as such that I've encountered during setup. Maybe in the future, once I have better understanding of Gluster. I could update documentation and help future users :) Cheers, Barak On Tue, Jul 23, 2019 at 3:55 PM Kaleb Keithley wrote: > You still have to install rpcgen before building. The build process isn't > going to do that for you. > > > On Tue, Jul 23, 2019 at 8:16 AM Barak Sason wrote: > >> Hello again Kaleb, >> >> Thank you for the clarification - at least now I know where the rpcgen is. >> Unfortunately, the problem still persists. >> >> I'm attaching the repo file and terminal output. >> Might you have any idea what I'm doing wrong? >> >> Thank you very much for your assistance, >> >> Barak >> >> On Tue, Jul 23, 2019 at 2:40 PM Kaleb Keithley >> wrote: >> >>> rpcgen is in the CRB (codeready-builder) repo. >>> >>> >>> >>> Package ArchVersionRepository >>> Size >>> >>> >>> Installing: >>> rpcgen x86_64 1.3.1-4.el8 >>> codeready-builder-for-rhel-8-x86_64-rpms 52 k >>> >>> Transaction Summary >>> >>> >>> >>> Make sure that the codeready-builder-for-rhel-8-x86_64-rpms repo is >>> enabled (enabled = 1) in /etc/yum.repos.d/redhat.repo or or run dnf with >>> `... --enable codeready-builder-for-rhel-8-x86_64-rpms ...` >>> >>> -- >>> >>> Kaleb >>> >>> >>> On Tue, Jul 23, 2019 at 7:31 AM Barak Sason wrote: >>> >>>> Greeting Kaleb, >>>> >>>> Thank you for the clarification. >>>> >>>> Though, I did try to install rpcgen package, but without success >>>> (libtirpc-devel >>>> package is installed). >>>> I'm attaching relevant terminal output. >>>> >>>> What am I missing? >>>> >>>> Barak >>>> >>>> On Tue, Jul 23, 2019 at 2:25 PM Kaleb Keithley >>>> wrote: >>>> >>>>> >>>>> you must not use --without-libtirpc on RHEL8. >>>>> >>>>> rpcgen is in the rpcgen package on RHEL8 and Fedora 29+ >>>>> >>>>> -- >>>>> >>>>> Kaleb >>>>> >>>>> >>>>> On Tue, Jul 23, 2019 at 7:11 AM Barak Sason >>>>> wrote: >>>>> >>>>>> Greeting all, >>>>>> >>>>>> I've made a fresh installation of RHEL 8 on a VM and have been trying >>>>>> to set up Gluster on that system. >>>>>> >>>>>> Running ./autogen.sh completes OK, but running ./config results in an >>>>>> error regarding missing 'rpcgen'. >>>>>> 'libtirpc-devel package is installed. >>>>>> Running ./configure --without-libtirp results in the same error. >>>>>> I'm attaching reverent terminal output. >>>>>> I'm currently out of ideas. >>>>>> >>>>>> I appreciate any help you may offer, >>>>>> >>>>>> Barak >>>>>> ___ >>>>>> >>>>>> Community Meeting Calendar: >>>>>> >>>>>> APAC Schedule - >>>>>> Every 2nd and 4th Tuesday at 11:30 AM IST >>>>>> Bridge: https://bluejeans.com/836554017 >>>>>> >>>>>> NA/EMEA Schedule - >>>>>> Every 1st and 3rd Tuesday at 01:00 PM EDT >>>>>> Bridge: https://bluejeans.com/486278655 >>>>>> >>>>>> Gluster-devel mailing list >>>>>> Gluster-devel@gluster.org >>>>>> https://lists.gluster.org/mailman/listinfo/gluster-devel >>>>>> >>>>>> ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Gluster on RHEL 8
Hello again Kaleb, Thank you for the clarification - at least now I know where the rpcgen is. Unfortunately, the problem still persists. I'm attaching the repo file and terminal output. Might you have any idea what I'm doing wrong? Thank you very much for your assistance, Barak On Tue, Jul 23, 2019 at 2:40 PM Kaleb Keithley wrote: > rpcgen is in the CRB (codeready-builder) repo. > > > > Package ArchVersionRepository > Size > > > Installing: > rpcgen x86_64 1.3.1-4.el8codeready-builder-for-rhel-8-x86_64-rpms > 52 k > > Transaction Summary > > > > Make sure that the codeready-builder-for-rhel-8-x86_64-rpms repo is > enabled (enabled = 1) in /etc/yum.repos.d/redhat.repo or or run dnf with > `... --enable codeready-builder-for-rhel-8-x86_64-rpms ...` > > -- > > Kaleb > > > On Tue, Jul 23, 2019 at 7:31 AM Barak Sason wrote: > >> Greeting Kaleb, >> >> Thank you for the clarification. >> >> Though, I did try to install rpcgen package, but without success >> (libtirpc-devel >> package is installed). >> I'm attaching relevant terminal output. >> >> What am I missing? >> >> Barak >> >> On Tue, Jul 23, 2019 at 2:25 PM Kaleb Keithley >> wrote: >> >>> >>> you must not use --without-libtirpc on RHEL8. >>> >>> rpcgen is in the rpcgen package on RHEL8 and Fedora 29+ >>> >>> -- >>> >>> Kaleb >>> >>> >>> On Tue, Jul 23, 2019 at 7:11 AM Barak Sason wrote: >>> >>>> Greeting all, >>>> >>>> I've made a fresh installation of RHEL 8 on a VM and have been trying >>>> to set up Gluster on that system. >>>> >>>> Running ./autogen.sh completes OK, but running ./config results in an >>>> error regarding missing 'rpcgen'. >>>> 'libtirpc-devel package is installed. >>>> Running ./configure --without-libtirp results in the same error. >>>> I'm attaching reverent terminal output. >>>> I'm currently out of ideas. >>>> >>>> I appreciate any help you may offer, >>>> >>>> Barak >>>> ___ >>>> >>>> Community Meeting Calendar: >>>> >>>> APAC Schedule - >>>> Every 2nd and 4th Tuesday at 11:30 AM IST >>>> Bridge: https://bluejeans.com/836554017 >>>> >>>> NA/EMEA Schedule - >>>> Every 1st and 3rd Tuesday at 01:00 PM EDT >>>> Bridge: https://bluejeans.com/486278655 >>>> >>>> Gluster-devel mailing list >>>> Gluster-devel@gluster.org >>>> https://lists.gluster.org/mailman/listinfo/gluster-devel >>>> >>>> [root@localhost src]# subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms Repository 'codeready-builder-for-rhel-8-x86_64-rpms' is enabled for this system. [root@localhost src]# dnf upgrade Updating Subscription Management repositories. Last metadata expiration check: 0:05:06 ago on Tue 23 Jul 2019 03:06:19 PM IDT. Dependencies resolved. Nothing to do. Complete! [root@localhost src]# ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking how to create a pax tar archive... gnutar checking whether make supports nested variables... (cached) yes checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of gcc... gcc3 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that h
Re: [Gluster-devel] Gluster on RHEL 8
Greeting Kaleb, Thank you for the clarification. Though, I did try to install rpcgen package, but without success (libtirpc-devel package is installed). I'm attaching relevant terminal output. What am I missing? Barak On Tue, Jul 23, 2019 at 2:25 PM Kaleb Keithley wrote: > > you must not use --without-libtirpc on RHEL8. > > rpcgen is in the rpcgen package on RHEL8 and Fedora 29+ > > -- > > Kaleb > > > On Tue, Jul 23, 2019 at 7:11 AM Barak Sason wrote: > >> Greeting all, >> >> I've made a fresh installation of RHEL 8 on a VM and have been trying to >> set up Gluster on that system. >> >> Running ./autogen.sh completes OK, but running ./config results in an >> error regarding missing 'rpcgen'. >> 'libtirpc-devel package is installed. >> Running ./configure --without-libtirp results in the same error. >> I'm attaching reverent terminal output. >> I'm currently out of ideas. >> >> I appreciate any help you may offer, >> >> Barak >> ___ >> >> Community Meeting Calendar: >> >> APAC Schedule - >> Every 2nd and 4th Tuesday at 11:30 AM IST >> Bridge: https://bluejeans.com/836554017 >> >> NA/EMEA Schedule - >> Every 1st and 3rd Tuesday at 01:00 PM EDT >> Bridge: https://bluejeans.com/486278655 >> >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-devel >> >> [root@localhost ~]# dnf install rpcgen Updating Subscription Management repositories. Last metadata expiration check: 1:50:52 ago on Mon 22 Jul 2019 04:21:58 PM IDT. No match for argument: rpcgen Error: Unable to find a match [root@localhost ~]# yum install rpcgen Updating Subscription Management repositories. Last metadata expiration check: 1:51:00 ago on Mon 22 Jul 2019 04:21:58 PM IDT. No match for argument: rpcgen Error: Unable to find a match [root@localhost ~]# ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/836554017 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/486278655 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Gluster on RHEL 8
Hello Prasanna *,*Thank you for the quick response. I've made a mistake and attached the wring output file (I've noticed the spelling error as you've pointed out, and copied output to a new file, but attached the old by mistake). Attached now is the relevant file. I apologize for the inconvenience, Barak On Tue, Jul 23, 2019 at 2:14 PM Prasanna Kalever wrote: > On Tue, Jul 23, 2019 at 4:41 PM Barak Sason wrote: > > > > Greeting all, > > > > I've made a fresh installation of RHEL 8 on a VM and have been trying to > set up Gluster on that system. > > > > Running ./autogen.sh completes OK, but running ./config results in an > error regarding missing 'rpcgen'. > > 'libtirpc-devel package is installed. > > Running ./configure --without-libtirp results in the same error. > > I see: > [root@localhost src]# ./configure --without-libtirp > configure: WARNING: unrecognized options: --without-libtirp > > should it be '--without-libtirpc' instead of '--without-libtirp' ? > > BRs, > -- > Prasanna > > > > > > > I'm attaching reverent terminal output. > > I'm currently out of ideas. > > > > I appreciate any help you may offer, > > > > Barak > > ___ > > > > Community Meeting Calendar: > > > > APAC Schedule - > > Every 2nd and 4th Tuesday at 11:30 AM IST > > Bridge: https://bluejeans.com/836554017 > > > > NA/EMEA Schedule - > > Every 1st and 3rd Tuesday at 01:00 PM EDT > > Bridge: https://bluejeans.com/486278655 > > > > Gluster-devel mailing list > > Gluster-devel@gluster.org > > https://lists.gluster.org/mailman/listinfo/gluster-devel > > > [root@localhost src]# ./configure --without-libtirpc checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking how to create a pax tar archive... gnutar checking whether make supports nested variables... (cached) yes checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of gcc... gcc3 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for a working dd... /usr/bin/dd checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1 checking for mt... no checking if : is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DP
Re: [Gluster-devel] Assistance setting up Gluster
Hello again Sanju, Thank you very much for your input. Unfortunately, running './configure --without-libtirp' does not help and the problem still persists. I've opened a new thread on the matter under the name "Gluster on RHEL 8" for organization purposes (and also attached some output files) and would appreciate if you could offer further assistance. Thank you very much, Barak On Tue, Jul 23, 2019 at 1:14 PM Sanju Rakonde wrote: > Hello Barak, > > It's great that you could resolve the issues. I was searching about how to > resolve "rpcgen" issue, usually ./configure --without-libtirp works. I > will try to help you with your other issues. > > On Tue, Jul 23, 2019 at 3:37 PM Barak Sason wrote: > >> Hello Sanju, >> >> I greatly appreciate your assistance. >> >> The problem has been solved already - There was indeed a process running >> in the background. >> I do have another problem with setting up Gluster on RHEL 8, but as >> suggested before I'll post it in another thread. >> >> Again, Thank you very much for your help, >> >> Barak >> >> On Tue, Jul 23, 2019 at 12:19 PM Atin Mukherjee >> wrote: >> >>> Sanju - can you please help Barak? >>> >>> From a quick glance of the log it seems that this wasn’t a clean setup. >>> >>> Barak - can you please have an empty /var/lib/glusterd/ and start over >>> again? Also make sure that there’s no glusterd process already running. >>> >>> On Mon, 22 Jul 2019 at 14:40, Barak Sason wrote: >>> >>>> Greeting Yaniv, >>>> >>>> Thank you very much for your response. >>>> >>>> As you suggested, I'm installing additional VM (CentOs) on which I'll >>>> try to use the repo you suggested in order to get Gluster up and running. >>>> I'll update on progress in this matter later today, as it'll take a bit of >>>> time to get the VM ready. >>>> >>>> In addition, I'll post the RHEL problem in a separate thread, as you >>>> requested. >>>> >>>> In the meantime, let's focus on the Ubuntu problem. >>>> I'm attaching the log file from Ubuntu, corresponding to running 'sudo >>>> glusterd' command (attachment - glusterd.log). >>>> Regarding you question about running manually - I've followed the >>>> instructions specified in the INSTALL.txt file which comes with the repo >>>> and specifies the following steps for installation: >>>> 1- ./autogen.sh >>>> 2- ./configure >>>> 3- make install >>>> Please let me know if this somehow incorrect. >>>> >>>> I kindly thank you for your time and effort, >>>> >>>> Barak >>>> >>>> On Mon, Jul 22, 2019 at 8:10 AM Yaniv Kaul wrote: >>>> >>>>> >>>>> >>>>> On Mon, Jul 22, 2019 at 1:20 AM Barak Sason >>>>> wrote: >>>>> >>>>>> Hello everyone, >>>>>> >>>>>> My name is Barak and I'll soon be joining the Gluster development >>>>>> team as a part of Red Hat. >>>>>> >>>>> >>>>> Hello and welcome to the Gluster community. >>>>> >>>>>> >>>>>> As a preparation for my upcoming employment I've been trying to get >>>>>> Gluster up and running on my system, but came across some technical >>>>>> difficulties. >>>>>> I'll appreciate any assistance you may provide. >>>>>> >>>>>> I have 2 VMs on my PC - Ubuntu 18, which I used for previous >>>>>> development and RHEL 8 which I installed a fresh copy just days ago. >>>>>> >>>>> >>>>> 2 VMs is really minimal. You should use more. >>>>> >>>>>> The copy of Gluster code I'm working with is a clone of the master >>>>>> repository. >>>>>> >>>>>> On Ubuntu installation completed, but running the command 'sudo >>>>>> glusterd' does nothing. Debugging with gdb shows that the program >>>>>> terminates very early due to an error. >>>>>> At glusterfsd.c:2878 (main method) there is a call to 'daemonize' >>>>>> method. at glusterfsd.c:2568 a call to sys_read fails with errno 17. >>>>>>
[Gluster-devel] Gluster on RHEL 8
Greeting all, I've made a fresh installation of RHEL 8 on a VM and have been trying to set up Gluster on that system. Running ./autogen.sh completes OK, but running ./config results in an error regarding missing 'rpcgen'. 'libtirpc-devel package is installed. Running ./configure --without-libtirp results in the same error. I'm attaching reverent terminal output. I'm currently out of ideas. I appreciate any help you may offer, Barak [root@localhost ~]# dnf install rpcgen Updating Subscription Management repositories. Last metadata expiration check: 1:50:52 ago on Mon 22 Jul 2019 04:21:58 PM IDT. No match for argument: rpcgen Error: Unable to find a match [root@localhost ~]# yum install rpcgen Updating Subscription Management repositories. Last metadata expiration check: 1:51:00 ago on Mon 22 Jul 2019 04:21:58 PM IDT. No match for argument: rpcgen Error: Unable to find a match [root@localhost ~]# [root@localhost src]# ./configure --without-libtirp configure: WARNING: unrecognized options: --without-libtirp checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking how to create a pax tar archive... gnutar checking whether make supports nested variables... (cached) yes checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of gcc... gcc3 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for a working dd... /usr/bin/dd checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1 checking for mt... no checking if : is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for rpcgen... no configure: error: `rpcgen` not found, glusterfs needs `rpcgen` exiting.. [root@localhost src]# ___ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM
Re: [Gluster-devel] Assistance setting up Gluster
Hello Sanju,
I greatly appreciate your assistance.
The problem has been solved already - There was indeed a process running in
the background.
I do have another problem with setting up Gluster on RHEL 8, but as
suggested before I'll post it in another thread.
Again, Thank you very much for your help,
Barak
On Tue, Jul 23, 2019 at 12:19 PM Atin Mukherjee wrote:
> Sanju - can you please help Barak?
>
> From a quick glance of the log it seems that this wasn’t a clean setup.
>
> Barak - can you please have an empty /var/lib/glusterd/ and start over
> again? Also make sure that there’s no glusterd process already running.
>
> On Mon, 22 Jul 2019 at 14:40, Barak Sason wrote:
>
>> Greeting Yaniv,
>>
>> Thank you very much for your response.
>>
>> As you suggested, I'm installing additional VM (CentOs) on which I'll try
>> to use the repo you suggested in order to get Gluster up and running. I'll
>> update on progress in this matter later today, as it'll take a bit of time
>> to get the VM ready.
>>
>> In addition, I'll post the RHEL problem in a separate thread, as you
>> requested.
>>
>> In the meantime, let's focus on the Ubuntu problem.
>> I'm attaching the log file from Ubuntu, corresponding to running 'sudo
>> glusterd' command (attachment - glusterd.log).
>> Regarding you question about running manually - I've followed the
>> instructions specified in the INSTALL.txt file which comes with the repo
>> and specifies the following steps for installation:
>> 1- ./autogen.sh
>> 2- ./configure
>> 3- make install
>> Please let me know if this somehow incorrect.
>>
>> I kindly thank you for your time and effort,
>>
>> Barak
>>
>> On Mon, Jul 22, 2019 at 8:10 AM Yaniv Kaul wrote:
>>
>>>
>>>
>>> On Mon, Jul 22, 2019 at 1:20 AM Barak Sason wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> My name is Barak and I'll soon be joining the Gluster development team
>>>> as a part of Red Hat.
>>>>
>>>
>>> Hello and welcome to the Gluster community.
>>>
>>>>
>>>> As a preparation for my upcoming employment I've been trying to get
>>>> Gluster up and running on my system, but came across some technical
>>>> difficulties.
>>>> I'll appreciate any assistance you may provide.
>>>>
>>>> I have 2 VMs on my PC - Ubuntu 18, which I used for previous
>>>> development and RHEL 8 which I installed a fresh copy just days ago.
>>>>
>>>
>>> 2 VMs is really minimal. You should use more.
>>>
>>>> The copy of Gluster code I'm working with is a clone of the master
>>>> repository.
>>>>
>>>> On Ubuntu installation completed, but running the command 'sudo
>>>> glusterd' does nothing. Debugging with gdb shows that the program
>>>> terminates very early due to an error.
>>>> At glusterfsd.c:2878 (main method) there is a call to 'daemonize'
>>>> method. at glusterfsd.c:2568 a call to sys_read fails with errno 17.
>>>> I'm unsure why this happens and I was unable to solve this.
>>>> I've tried to run 'sudo glusterd -N' in order to deactivate
>>>> deamonization, but this also fails at glusterfsd.c:2712
>>>> ('glusterfs_process_volfp' method). I was unable to solve this issue too.
>>>>
>>>> On RHEL, running ./configure results in an error regarding 'rpcgen'.
>>>> Running ./configure --without-libtirp was unhelpful and results in the
>>>> same error.
>>>>
>>>
>>> I'd separate the two issues to two different email threads, as they may
>>> or may not be related.
>>> Please provide logs for each.
>>> Why are you running glusterd manually, btw?
>>>
>>> You may want to take a look at https://github.com/mykaul/vg - which is
>>> a simple way to set up Gluster on CentOS 7 VMs for testing. I have not
>>> tried it for some time - let me know how it works for you.
>>> Y.
>>>
>>>>
>>>> As of right now I'm unable to proceed so I ask for your assistance.
>>>>
>>>> Thank you all very much.
>>>> ___
>>>>
>>>> Community Meeting Calendar:
>>>>
>>>> APAC Schedule -
>>>> Every 2nd and 4th Tuesday at 11:30 AM IST
&
Re: [Gluster-devel] Assistance setting up Gluster
Greeting Yaniv,
Thank you very much for your response.
As you suggested, I'm installing additional VM (CentOs) on which I'll try
to use the repo you suggested in order to get Gluster up and running. I'll
update on progress in this matter later today, as it'll take a bit of time
to get the VM ready.
In addition, I'll post the RHEL problem in a separate thread, as you
requested.
In the meantime, let's focus on the Ubuntu problem.
I'm attaching the log file from Ubuntu, corresponding to running 'sudo
glusterd' command (attachment - glusterd.log).
Regarding you question about running manually - I've followed the
instructions specified in the INSTALL.txt file which comes with the repo
and specifies the following steps for installation:
1- ./autogen.sh
2- ./configure
3- make install
Please let me know if this somehow incorrect.
I kindly thank you for your time and effort,
Barak
On Mon, Jul 22, 2019 at 8:10 AM Yaniv Kaul wrote:
>
>
> On Mon, Jul 22, 2019 at 1:20 AM Barak Sason wrote:
>
>> Hello everyone,
>>
>> My name is Barak and I'll soon be joining the Gluster development team as
>> a part of Red Hat.
>>
>
> Hello and welcome to the Gluster community.
>
>>
>> As a preparation for my upcoming employment I've been trying to get
>> Gluster up and running on my system, but came across some technical
>> difficulties.
>> I'll appreciate any assistance you may provide.
>>
>> I have 2 VMs on my PC - Ubuntu 18, which I used for previous development
>> and RHEL 8 which I installed a fresh copy just days ago.
>>
>
> 2 VMs is really minimal. You should use more.
>
>> The copy of Gluster code I'm working with is a clone of the master
>> repository.
>>
>> On Ubuntu installation completed, but running the command 'sudo glusterd'
>> does nothing. Debugging with gdb shows that the program terminates very
>> early due to an error.
>> At glusterfsd.c:2878 (main method) there is a call to 'daemonize' method.
>> at glusterfsd.c:2568 a call to sys_read fails with errno 17.
>> I'm unsure why this happens and I was unable to solve this.
>> I've tried to run 'sudo glusterd -N' in order to deactivate
>> deamonization, but this also fails at glusterfsd.c:2712
>> ('glusterfs_process_volfp' method). I was unable to solve this issue too.
>>
>> On RHEL, running ./configure results in an error regarding 'rpcgen'.
>> Running ./configure --without-libtirp was unhelpful and results in the
>> same error.
>>
>
> I'd separate the two issues to two different email threads, as they may or
> may not be related.
> Please provide logs for each.
> Why are you running glusterd manually, btw?
>
> You may want to take a look at https://github.com/mykaul/vg - which is a
> simple way to set up Gluster on CentOS 7 VMs for testing. I have not tried
> it for some time - let me know how it works for you.
> Y.
>
>>
>> As of right now I'm unable to proceed so I ask for your assistance.
>>
>> Thank you all very much.
>> ___
>>
>> Community Meeting Calendar:
>>
>> APAC Schedule -
>> Every 2nd and 4th Tuesday at 11:30 AM IST
>> Bridge: https://bluejeans.com/836554017
>>
>> NA/EMEA Schedule -
>> Every 1st and 3rd Tuesday at 01:00 PM EDT
>> Bridge: https://bluejeans.com/486278655
>>
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>>
glusterd.log
Description: Binary data
___
Community Meeting Calendar:
APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017
NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Assistance setting up Gluster
Hello everyone,
My name is Barak and I'll soon be joining the Gluster development team as a
part of Red Hat.
As a preparation for my upcoming employment I've been trying to get Gluster
up and running on my system, but came across some technical difficulties.
I'll appreciate any assistance you may provide.
I have 2 VMs on my PC - Ubuntu 18, which I used for previous development
and RHEL 8 which I installed a fresh copy just days ago.
The copy of Gluster code I'm working with is a clone of the master
repository.
On Ubuntu installation completed, but running the command 'sudo glusterd'
does nothing. Debugging with gdb shows that the program terminates very
early due to an error.
At glusterfsd.c:2878 (main method) there is a call to 'daemonize' method.
at glusterfsd.c:2568 a call to sys_read fails with errno 17.
I'm unsure why this happens and I was unable to solve this.
I've tried to run 'sudo glusterd -N' in order to deactivate deamonization,
but this also fails at glusterfsd.c:2712 ('glusterfs_process_volfp'
method). I was unable to solve this issue too.
On RHEL, running ./configure results in an error regarding 'rpcgen'.
Running ./configure --without-libtirp was unhelpful and results in the same
error.
As of right now I'm unable to proceed so I ask for your assistance.
Thank you all very much.
___
Community Meeting Calendar:
APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017
NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
