Re: [Gluster-devel] [Gluster-infra] ACTION REQUESTED: Migrate your glusterfs patches from Gerrit to GitHub

2020-10-07 Thread Sunil Kumar Heggodu Gopala Acharya
Regards,

Sunil kumar Acharya



On Wed, Oct 7, 2020 at 4:54 PM Kaleb Keithley  wrote:

>
>
> On Wed, Oct 7, 2020 at 5:46 AM Deepshikha Khandelwal 
> wrote:
>
>>
>> - The "regression" tests would be triggered by a comment "/run
>> regression" from anyone in the gluster-maintainers[4] github group. To run
>> full regression, maintainers need to comment "/run full regression"
>>
>> [4] https://github.com/orgs/gluster/teams/gluster-maintainers
>>
>
> There are a lot of people in that group that haven't been involved with
> Gluster for a long time.
>
Also there are new contributors, time to update!

>
> Maybe some of them should be "retired."
>
> --
>
> Kaleb
> ___
>
> 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
>
>
___

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] Improvements to Gluster upstream documentation

2019-01-28 Thread Sunil Kumar Heggodu Gopala Acharya
Hi,

As part of our continuous effort to improve Gluster upstream documentation
, we are proposing a change to the
documentation theme that we are currently using through the glusterdocs
pull request 454 .

Preview of the changes proposed can be viewed through this temporary website
. Request you to review and
share the comments/concerns/feedback.

Regards,

Sunil kumar AcharYa
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Glusterd2 - Some anticipated changes to glusterfs source

2017-08-02 Thread Sunil Kumar Heggodu Gopala Acharya
Regards,

Sunil kumar Acharya

Senior Software Engineer

Red Hat



T: +91-8067935170 


TRIED. TESTED. TRUSTED. 


On Thu, Aug 3, 2017 at 2:14 AM, Niels de Vos  wrote:

> On Wed, Aug 02, 2017 at 05:03:35PM +0530, Prashanth Pai wrote:
> > Hi all,
> >
> > The ongoing work on glusterd2 necessitates following non-breaking and
> > non-exhaustive list of changes to glusterfs source code:
> >
> > Port management
> > - Remove hard-coding of glusterd's port as 24007 in clients and
> elsewhere.
> >   Glusterd2 can be configured to listen to clients on any port (still
> > defaults to
> >   24007 though)
> > - Let the bricks and daemons choose any available port and if needed
> report
> >   the port used to glusterd during the "sign in" process. Prasanna has a
> > patch
> >   to do this.
> > - Glusterd <--> brick (or any other local daemon) communication should
> >   always happen over Unix Domain Socket. Currently glusterd and brick
> >   process communicates over UDS and also port 24007. This will allow us
> >   to set better authentication and rules for port 24007 as it shall only
> be
> > used
> >   by clients.
>
> I prefer this last point to be configurable.

+1


> At least for debugging we
> should be able to capture network traces and display the communication
> in Wireshark. Defaulting to UNIX Domain Sockets is fine though.
>
>
> > Changes to xlator options
> > - Xlator authors do not have to modify glusterd2 code to expose new
> xlator
> >   options. IOW, glusterd2 will not contain the "glusterd_volopt_map"
> table.
> >   Most of its fields will be moved to the xlator itself. Glusterd2 can
> load
> >   xlator's shared object and read it's volume_options table. This also
> means
> >   xlators have to adhere to some naming conventions for options.
> > - Add following additional fields (names are indicative) to
> volume_option_t:
> > - Tag: This is to enable users to list only options having a certain
> > tag.
> >  IOW, it allows us to filter "volume set help" like output.
> >  Example of tags: debug, perf, network etc.
> > - Opversion: The minimum (or a range) op-version required by the
> xlator.
> > - Configurable: A bool to indicate whether this option is
> > user-configurable.
> >   This may also be clubbed with DOC/NO_DOC
> > functionality.
>
> This is something I have been thinking about to do as well. libgfapi
> users would like to list all the valid options before mounting (and
> receiving the .vol file) is done. Similar to how many mount options are
> set over FUSE, the options should be available through libgfapi.
> Hardcoding the options is just wrong, inspecting the available xlators
> (.so files) seems to make more sense. Each option would have to describe
> if it can be client-side so that we can apply some resonable filters by
> default.
>
> A GitHub Issue with this feature request is at
> https://github.com/gluster/glusterfs/issues/263. I appreciate additional
> comments and ideas about it :-)
>
>
> > - Xlators like AFR, changelog require non-static information such as
> brick
> > path
> >   to be present in it's options in the volfile. Currently, xlator authors
> > have
> >   to modify glusterd code to get it.
> >   This can rather be indicated by the xlator itself using
> > templates/placehoders.
> >   For example, "changelog-dir" can be set in xlator's option as as
> >   <>/.glusterfs/changelogs and then glusterd2 will ensure to
> > replace
> >   <> with actual path during volfile generation.
>
> I suggest to stick with whatever is a common syntax for other
> configuration files that uses placeholders. Maybe just {variable} or
> $VARIABLE, the <> looks a bit awkward.
>
>
> > We'd like to hear your thoughts, suggestions and comments to these
> proposed
> > changes.
>
> Thanks for sharing!
> Niels
> ___
> 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] geo-rep regression because of node-uuid change

2017-06-20 Thread Sunil Kumar Heggodu Gopala Acharya
EC also sends all zeros if the node is down.

Regards,

Sunil kumar Acharya

Senior Software Engineer

Red Hat



T: +91-8067935170 


TRIED. TESTED. TRUSTED. 
On Tue, Jun 20, 2017 at 4:27 PM, Karthik Subrahmanya 
wrote:

>
>
> On Tue, Jun 20, 2017 at 4:12 PM, Aravinda  wrote:
>
>> I think following format can be easily adopted by all components
>>
>> UUIDs of a subvolume are seperated by space and subvolumes are separated
>> by comma
>>
>> For example, node1 and node2 are replica with U1 and U2 UUIDs
>> respectively and
>> node3 and node4 are replica with U3 and U4 UUIDs respectively
>>
>> node-uuid can return "U1 U2,U3 U4"
>>
>> Geo-rep can split by "," and then split by space and take first UUID
>> DHT can split the value by space or comma and get unique UUIDs list
>>
>> Another question is about the behavior when a node is down, existing
>> node-uuid xattr will not return that UUID if a node is down.
>
> After the change [1], if a node is down we send all zeros as the uuid for
> that node, in the list of node uuids.
>
> [1] https://review.gluster.org/#/c/17084/
>
> Regards,
> Karthik
>
>> What is the behavior with the proposed xattr?
>>
>> Let me know your thoughts.
>>
>> regards
>> Aravinda VK
>>
>>
>> On 06/20/2017 03:06 PM, Aravinda wrote:
>>
>>> Hi Xavi,
>>>
>>> On 06/20/2017 02:51 PM, Xavier Hernandez wrote:
>>>
 Hi Aravinda,

 On 20/06/17 11:05, Pranith Kumar Karampuri wrote:

> Adding more people to get a consensus about this.
>
> On Tue, Jun 20, 2017 at 1:49 PM, Aravinda  > wrote:
>
>
> regards
> Aravinda VK
>
>
> On 06/20/2017 01:26 PM, Xavier Hernandez wrote:
>
> Hi Pranith,
>
> adding gluster-devel, Kotresh and Aravinda,
>
> On 20/06/17 09:45, Pranith Kumar Karampuri wrote:
>
>
>
> On Tue, Jun 20, 2017 at 1:12 PM, Xavier Hernandez
> 
>  >> wrote:
>
> On 20/06/17 09:31, Pranith Kumar Karampuri wrote:
>
> The way geo-replication works is:
> On each machine, it does getxattr of node-uuid and
> check if its
> own uuid
> is present in the list. If it is present then it
> will consider
> it active
> otherwise it will be considered passive. With this
> change we are
> giving
> all uuids instead of first-up subvolume. So all
> machines think
> they are
> ACTIVE which is bad apparently. So that is the
> reason. Even I
> felt bad
> that we are doing this change.
>
>
> And what about changing the content of node-uuid to
> include some
> sort of hierarchy ?
>
> for example:
>
> a single brick:
>
> NODE()
>
> AFR/EC:
>
> AFR[2](NODE(), NODE())
> EC[3,1](NODE(), NODE(), NODE())
>
> DHT:
>
> DHT[2](AFR[2](NODE(), NODE()),
> AFR[2](NODE(),
> NODE()))
>
> This gives a lot of information that can be used to
> take the
> appropriate decisions.
>
>
> I guess that is not backward compatible. Shall I CC
> gluster-devel and
> Kotresh/Aravinda?
>
>
> Is the change we did backward compatible ? if we only require
> the first field to be a GUID to support backward compatibility,
> we can use something like this:
>
> No. But the necessary change can be made to Geo-rep code as well if
> format is changed, Since all these are built/shipped together.
>
> Geo-rep uses node-id as follows,
>
> list = listxattr(node-uuid)
> active_node_uuids = list.split(SPACE)
> active_node_flag = True if self.node_id exists in active_node_uuids
> else False
>

 How was this case solved ?

 suppose we have three servers and 2 bricks in each server. A replicated
 volume is created using the following command:

 gluster volume create test replica 2 server1:/brick1 server2:/brick1
 server2:/brick2 

[Gluster-devel] FALLOCATE support on EC Volumes

2017-05-26 Thread Sunil Kumar Heggodu Gopala Acharya
Hi,

Support for FALLOCATE file operation on EC volumes has been added on
master. The same is also available on 3.11.

Details:
*
Patch:https://review.gluster.org/15200
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1448293

GitHub issue: https://github.com/gluster/glusterfs/issues/219

Regards,

Sunil kumar Acharya

Senior Software Engineer

Red Hat



T: +91-8067935170 


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

[Gluster-devel] Minutes from Gluster Bug Triage meeting today

2017-04-11 Thread Sunil Kumar Heggodu Gopala Acharya
Hi,

Thanks all who joined!

Next week at the same time (Tuesday 12:00 UTC) we will have an other bug
triage meeting to catch the bugs that were not handled by developers and
maintainers yet. We'll stay repeating this meeting as safety net so that
bugs get the initial attention and developers can immediately start
working on the issues that were reported.

Bug triaging (in general, no need to only do it during the meeting) is
intended to help developers, in the hope that developers can focus on
writing bug fixes instead of spending much of their valued time
troubleshooting incorrectly/incompletely reported bugs.

More details about bug triaging can be found here:
http://gluster.readthedocs.io/en/latest/Contributors-Guide/Bug-Triage/

Meeting minutes below.

Meeting summary
---
* agenda:https://github.com/gluster/glusterfs/wiki/Bug-Triage-Meeting
  (skumar, 12:00:26)
* Roll call  (skumar, 12:00:34)

* Next week’s meeting host  (skumar, 12:02:18)
  * ACTION: kkeithley will host next week's meeting  (skumar, 12:02:58)

* ndevos need to decide on how to provide/use debug builds  (skumar,
  12:03:05)
  * ACTION: removing it from agenda  (skumar, 12:07:51)

* jiffin  needs to send the changes to check-bugs.py also  (skumar,
  12:08:12)
  * ACTION: jiffin  needs to send the changes to check-bugs.py also
(skumar, 12:09:15)

* bug triage  (skumar, 12:09:22)
  * LINK:
https://gluster.readthedocs.io/en/latest/Contributors-Guide/Bug-Triage/
<<-- process  (skumar, 12:09:29)
  * LINK: http://bit.ly/gluster-bugs-to-triage <<-- tool  (skumar,
12:09:37)

* open floor  (skumar, 12:15:05)

Meeting ended at 12:17:42 UTC.




Action Items

* kkeithley will host next week's meeting
* removing it from agenda
* jiffin  needs to send the changes to check-bugs.py also




Action Items, by person
---
* kkeithley
  * kkeithley will host next week's meeting
* **UNASSIGNED**
  * removing it from agenda
  * jiffin  needs to send the changes to check-bugs.py also




People Present (lines said)
---
* skumar (26)
* kkeithley (11)
* ndevos (5)
* zodbot (4)
* rafi (1)
* amarts (1)


Regards,

Sunil kumar Acharya

Senior Software Engineer

Red Hat



T: +91-8067935170 


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

[Gluster-devel] [Gluster-users] REMINDER: Gluster Community Bug Triage meeting at 12:00 UTC (today)

2017-04-11 Thread Sunil Kumar Heggodu Gopala Acharya
Hi,

This meeting is scheduled for anyone who is interested in learning more
about or assisting with the Bug Triage.

Meeting details:
- location: #gluster-meeting on Freenode IRC
(https://webchat.freenode.net/?channels=gluster-meeting  )
- date: every Tuesday
- time: 12:00 UTC
  (in your terminal, run: date -d "12:00 UTC")
- Agenda:https://github.com/gluster/glusterfs/wiki/Bug-Triage-Meeting

Currently the following items are listed:

* Roll Call
* Status of last weeks action items
* Group Triage
 - http://bit.ly/gluster-bugs-to-triage
* Open Floor

The last two topics have space for additions. If you have a suitable bug or
topic to discuss, please add it to the agenda.

Appreciate your participation.

Regards,

Sunil kumar Acharya

Senior Software Engineer

Red Hat



T: +91-8067935170 


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