Re: [Gluster-devel] Please test Gerrit 2.12.2

2016-05-30 Thread Nigel Babu 
Hello,

A reminder: I'm hoping to get this done tomorrow morning at 0230 GMT[1].
I'll have a backup ready in case something goes wrong. I've tested this
process on review.nigelb.me and it's gone reasonably smoothly.

[1]:
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Maintenance=20160601T08=176=1

On Mon, May 30, 2016 at 7:26 PM, Nigel Babu  wrote:

> Hello,
>
> I've now upgraded Gerrit on http://review.nigelb.me to 2.12.2. Please
> spend a few minutes testing that everything works as you expect it to. If I
> don't hear anything negative by tomorrow, I'd like to schedule an upgrade
> this week.
>
> --
> nigelb
>



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

Re: [Gluster-devel] dht mkdir preop check, afr and (non-)readable afr subvols

2016-05-30 Thread Raghavendra Gowdappa 
+gluster-devel, +Xavi

Hi all,

The context is [1], where bricks do pre-operation checks before doing a fop and 
proceed with fop only if pre-op check is successful.

@Xavi,

We need your inputs on behavior of EC subvolumes as well.

[1] http://review.gluster.org/13885

regards,
Raghavendra

- Original Message -
> From: "Pranith Kumar Karampuri" 
> To: "Raghavendra Gowdappa" 
> Cc: "team-quine-afr" , "rhs-zteam" 
> 
> Sent: Tuesday, May 31, 2016 10:22:49 AM
> Subject: Re: dht mkdir preop check, afr and (non-)readable afr subvols
> 
> I think you should start a discussion on gluster-devel so that Xavi gets a
> chance to respond on the mails as well.
> 
> On Tue, May 31, 2016 at 10:21 AM, Raghavendra Gowdappa 
> wrote:
> 
> > Also note that we've plans to extend this pre-op check to all dentry
> > operations which also depend parent layout. So, the discussion need to
> > cover all dentry operations like:
> >
> > 1. create
> > 2. mkdir
> > 3. rmdir
> > 4. mknod
> > 5. symlink
> > 6. unlink
> > 7. rename
> >
> > We also plan to have similar checks in lock codepath for directories too
> > (planning to use hashed-subvolume as lock-subvolume for directories). So,
> > more fops :)
> > 8. lk (posix locks)
> > 9. inodelk
> > 10. entrylk
> >
> > regards,
> > Raghavendra
> >
> > - Original Message -
> > > From: "Raghavendra Gowdappa" 
> > > To: "team-quine-afr" 
> > > Cc: "rhs-zteam" 
> > > Sent: Tuesday, May 31, 2016 10:15:04 AM
> > > Subject: dht mkdir preop check, afr and (non-)readable afr subvols
> > >
> > > Hi all,
> > >
> > > I have some queries related to the behavior of afr_mkdir with respect to
> > > readable subvols.
> > >
> > > 1. While winding mkdir to subvols does afr check whether the subvolume is
> > > good/readable? Or does it wind to all subvols irrespective of whether a
> > > subvol is good/bad? In the latter case, what if
> > >a. mkdir succeeds on non-readable subvolume
> > >b. fails on readable subvolume
> > >
> > >   What is the result reported to higher layers in the above scenario? If
> > >   mkdir is failed, is it cleaned up on non-readable subvolume where it
> > >   failed?
> > >
> > > I am interested in this case as dht-preop check relies on layout xattrs
> > and I
> > > assume layout xattrs in particular (and all xattrs in general) are
> > > guaranteed to be correct only on a readable subvolume of afr. So, in
> > essence
> > > we shouldn't be winding down mkdir on non-readable subvols as whatever
> > the
> > > decision brick makes as part of pre-op check is inherently flawed.
> > >
> > > regards,
> > > Raghavendra
> --
> Pranith
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Gluster Community Newsletter, May 2016

2016-05-30 Thread Amye Scavarda 
Pranith,
Thanks for the heads up!
Resolved, try it again.

http://goo.gl/forms/8GhHIdjUBoX6YoE93

On Fri, May 27, 2016 at 9:45 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

> Hey Amye,
> The form doesn't seem to allow editing "Your Role within Gluster" and
> "Why should you attend?" Could you let us know how to fill these fields?
>
> Pranith
>
> On Sat, May 28, 2016 at 12:45 AM, Amye Scavarda  wrote:
>
>> Important happenings for Gluster this month:
>> We're closing in on a 3.8 release, with release candidate 2 released on
>> May 24th. (
>> http://www.gluster.org/pipermail/gluster-devel/2016-May/049642.html)
>> Our 3.8 roadmap of features is available at:
>> https://www.gluster.org/community/roadmap/3.8/
>> Our current timeline is to have a release in June, so update your release
>> notes!
>>
>> Gluster Developers Summit:
>> October 6, 7 directly following LinuxCon Berlin
>> https://www.gluster.org/events/summit2016/
>>
>> This is an invite-only event, but you can apply for an invitation.
>> Deadline for application is July 31, 2016.
>> Apply for an invitation:
>> http://goo.gl/forms/JOEzoimW9qVV4jdz1
>>
>>
>> Gluster.org events page:
>> Instead of having just a publicpad, we now have an area on the website
>> where oyu can add upcoming talks, meetups and other events.
>> https://www.gluster.org/events/
>> -- To contribute an event, submit a pull request to the glusterweb github
>> account.
>> See something that should be moved over from the publicpad? Feel free to
>> contribute!
>>
>> Change in presentation tracking:
>> We have a new slideshare account to share Gluster-related presentations
>> with.
>> Find everything that was previously in the documentation site over at the
>> new slideshare account.
>> http://www.slideshare.net/GlusterCommunity/
>>
>> Top 5 contributors:
>> Kaleb S. Keithley, Prasanna Kumar Kalever, Pranith Kumar K, Niels de Vos,
>> Krutika Dhananjay
>>
>> Upcoming CFPs:
>> LinuxCon Europe: (
>> http://events.linuxfoundation.org/events/linuxcon-europe/program/cfp)
>>  June 17
>>
>> --
>> Amye Scavarda | a...@redhat.com | Gluster Community Lead
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Pranith
>



-- 
Amye Scavarda | a...@redhat.com | Gluster Community Lead
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Please test Gerrit 2.12.2

2016-05-30 Thread Nigel Babu 
Hello,

I've now upgraded Gerrit on http://review.nigelb.me to 2.12.2. Please spend
a few minutes testing that everything works as you expect it to. If I don't
hear anything negative by tomorrow, I'd like to schedule an upgrade this
week.

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

Re: [Gluster-devel] [Gluster-Maintainers] Release Management Process change - proposal

2016-05-30 Thread Vijay Bellur 
On Sun, May 29, 2016 at 10:19 PM, Sankarshan Mukhopadhyay
 wrote:
> On Mon, May 30, 2016 at 7:07 AM, Vijay Bellur  wrote:
>> Since we do not have any objections to this proposal, let us do the
>> following for 3.7.12:
>>
>> 1. Treat June 1st as the cut-off for patch acceptance in release-3.7.
>> 2. I will tag 3.7.12rc1 on June 2nd.
>> 3. All maintainers to ack content and stability of components by June 9th.
>> 4. Release 3.7.12 around June 9th after we have all acks in place.
>
> Would 3 days be sufficient to get the content for the website and a
> bit of PR written up?
>

Should be ample time for a minor release.

Regards,
Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Understanding build.jenkins.org

2016-05-30 Thread Niels de Vos 
On Mon, May 30, 2016 at 04:13:52PM +0530, Nigel Babu wrote:
> Hi Niels,
> 
> Thank you. This gives me a much clearer picture than what I had with simply
> exploring the Jenkins web UI and the server. I still have a few more
> questions:
> 
> What is /opt/qa. Where is that code coming from?

I think this should contain the scripts from
https://github.com/gluster/glusterfs-patch-acceptance-tests . Is that
directory not a git repository? If so, just check with 'git remote -v'.

> I'm guessing that a lot of this isn't written down. So I'm going to make an
> effort to document the current state as is in the Ops-Guide section of the
> documentation.

Some of this is in the docs, but I do not know in what detail.
Explaining more about it is surely good!

Thanks,
Niels


> 
> On Mon, May 30, 2016 at 1:36 PM, Niels de Vos  wrote:
> 
> > On Mon, May 30, 2016 at 10:21:27AM +0530, Nigel Babu wrote:
> > > Hello folks,
> > >
> > > I'm trying to get a sense of how our Jenkins instance. In particular, I'm
> > > trying to understand the following:
> > >
> > > 1. How jobs are created. Is this version controlled or automated in any
> > > manner?
> >
> > The jobs are created in the Jenkins webui, and later exported with the
> > Jenkins CLI (https://build.gluster.org/cli). The resulting XML files are
> > stored here:
> >
> > https://github.com/gluster/glusterfs-patch-acceptance-tests/tree/master/jenkins/jobs
> >
> > > 2. How are the machines created? Do we have a standardized image?
> >
> > No idea, Micheal Scherer should know. I guess Manu setup the NetBSD
> > systems, not sure who takes care of the FreeBSD ones.
> >
> > > 3. Where is the code (the repository) for the tests that are run?
> >
> > Most of the tests have their scripts in the patch-acceptance-test
> > repository:
> >   https://github.com/gluster/glusterfs-patch-acceptance-tests
> >
> > The regression tests themselves are contained in the glusterfs
> > repository. We expect that all changes to the sources come with a
> > test-case.
> >
> > > 4. What is the process for going from updating the code for a test to
> > > updating the job on Jenkins? Is this automated and/or documented?
> >
> > Not sure. The number of people that modify the Jenkins jobs is very
> > small. All of them are aware (or should be!) that a modification
> > requires updating the XML files in the git repo.
> >
> > > 5. How many of the jobs are critical?
> >
> > All of the regular running ones?
> >
> > > 6. What is the process for creating new jobs/new types of tests?
> >
> > That is hardly ever needed, and more of an exception. If someone needs a
> > new job on build.gluster.org one of the people with an account can
> > create it.
> >
> > > Bonus Question: Is there any friction that you'd like to see us reduce?
> >
> > One of the things we're doing for this is to move more time consuming
> > and multi-host tests to ci.centos.org. Currently the regression tests
> > are still running on our own instance, but the CentOS CI has much more
> > and much faster hardware (no VMs). There is the long-term plan to move
> > at least a bunch of the heavy testing to their Jenkins instance.
> >
> > Also scheduled jobs (distaf tests, tests for integration with other
> > projects, nightly builds, ) are supposed to get added to the CentOS
> > CI, and not our build.gluster.org environment:
> >   https://ci.centos.org/view/Gluster/
> >
> > Thanks,
> > Niels
> >
> 
> 
> 
> -- 
> nigelb


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Understanding build.jenkins.org

2016-05-30 Thread Nigel Babu 
Hi Niels,

Thank you. This gives me a much clearer picture than what I had with simply
exploring the Jenkins web UI and the server. I still have a few more
questions:

What is /opt/qa. Where is that code coming from?

I'm guessing that a lot of this isn't written down. So I'm going to make an
effort to document the current state as is in the Ops-Guide section of the
documentation.

On Mon, May 30, 2016 at 1:36 PM, Niels de Vos  wrote:

> On Mon, May 30, 2016 at 10:21:27AM +0530, Nigel Babu wrote:
> > Hello folks,
> >
> > I'm trying to get a sense of how our Jenkins instance. In particular, I'm
> > trying to understand the following:
> >
> > 1. How jobs are created. Is this version controlled or automated in any
> > manner?
>
> The jobs are created in the Jenkins webui, and later exported with the
> Jenkins CLI (https://build.gluster.org/cli). The resulting XML files are
> stored here:
>
> https://github.com/gluster/glusterfs-patch-acceptance-tests/tree/master/jenkins/jobs
>
> > 2. How are the machines created? Do we have a standardized image?
>
> No idea, Micheal Scherer should know. I guess Manu setup the NetBSD
> systems, not sure who takes care of the FreeBSD ones.
>
> > 3. Where is the code (the repository) for the tests that are run?
>
> Most of the tests have their scripts in the patch-acceptance-test
> repository:
>   https://github.com/gluster/glusterfs-patch-acceptance-tests
>
> The regression tests themselves are contained in the glusterfs
> repository. We expect that all changes to the sources come with a
> test-case.
>
> > 4. What is the process for going from updating the code for a test to
> > updating the job on Jenkins? Is this automated and/or documented?
>
> Not sure. The number of people that modify the Jenkins jobs is very
> small. All of them are aware (or should be!) that a modification
> requires updating the XML files in the git repo.
>
> > 5. How many of the jobs are critical?
>
> All of the regular running ones?
>
> > 6. What is the process for creating new jobs/new types of tests?
>
> That is hardly ever needed, and more of an exception. If someone needs a
> new job on build.gluster.org one of the people with an account can
> create it.
>
> > Bonus Question: Is there any friction that you'd like to see us reduce?
>
> One of the things we're doing for this is to move more time consuming
> and multi-host tests to ci.centos.org. Currently the regression tests
> are still running on our own instance, but the CentOS CI has much more
> and much faster hardware (no VMs). There is the long-term plan to move
> at least a bunch of the heavy testing to their Jenkins instance.
>
> Also scheduled jobs (distaf tests, tests for integration with other
> projects, nightly builds, ) are supposed to get added to the CentOS
> CI, and not our build.gluster.org environment:
>   https://ci.centos.org/view/Gluster/
>
> Thanks,
> Niels
>



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

[Gluster-devel] review request

2016-05-30 Thread Susant Palai 
Hi,
  Requesting reviews for http://review.gluster.org/#/c/14251 and 
http://review.gluster.org/#/c/14252.

Thanks,
Susant~
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Understanding build.jenkins.org

2016-05-30 Thread Niels de Vos 
On Mon, May 30, 2016 at 10:21:27AM +0530, Nigel Babu wrote:
> Hello folks,
> 
> I'm trying to get a sense of how our Jenkins instance. In particular, I'm
> trying to understand the following:
> 
> 1. How jobs are created. Is this version controlled or automated in any
> manner?

The jobs are created in the Jenkins webui, and later exported with the
Jenkins CLI (https://build.gluster.org/cli). The resulting XML files are
stored here:
  
https://github.com/gluster/glusterfs-patch-acceptance-tests/tree/master/jenkins/jobs

> 2. How are the machines created? Do we have a standardized image?

No idea, Micheal Scherer should know. I guess Manu setup the NetBSD
systems, not sure who takes care of the FreeBSD ones.

> 3. Where is the code (the repository) for the tests that are run?

Most of the tests have their scripts in the patch-acceptance-test
repository:
  https://github.com/gluster/glusterfs-patch-acceptance-tests

The regression tests themselves are contained in the glusterfs
repository. We expect that all changes to the sources come with a
test-case.

> 4. What is the process for going from updating the code for a test to
> updating the job on Jenkins? Is this automated and/or documented?

Not sure. The number of people that modify the Jenkins jobs is very
small. All of them are aware (or should be!) that a modification
requires updating the XML files in the git repo.

> 5. How many of the jobs are critical?

All of the regular running ones?

> 6. What is the process for creating new jobs/new types of tests?

That is hardly ever needed, and more of an exception. If someone needs a
new job on build.gluster.org one of the people with an account can
create it.

> Bonus Question: Is there any friction that you'd like to see us reduce?

One of the things we're doing for this is to move more time consuming
and multi-host tests to ci.centos.org. Currently the regression tests
are still running on our own instance, but the CentOS CI has much more
and much faster hardware (no VMs). There is the long-term plan to move
at least a bunch of the heavy testing to their Jenkins instance.

Also scheduled jobs (distaf tests, tests for integration with other
projects, nightly builds, ) are supposed to get added to the CentOS
CI, and not our build.gluster.org environment:
  https://ci.centos.org/view/Gluster/

Thanks,
Niels


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Idea: Alternate Release process

2016-05-30 Thread Oleksandr Natalenko 

30.05.2016 05:08, Sankarshan Mukhopadhyay написав:

It would perhaps be worthwhile to extend this release timeline/cadence
discussion into (a) End-of-Life definition and invocation (b) whether
a 'long term support' (assuming that is what LTS is) is of essentially
any value to users of GlusterFS.

(b) especially can be (and perhaps should be) addressed by predictable
and tested upgrade paths to ensure that users are able to get to newer
releases without much hassles.


I believe 3.7 should be LTS with EOL in 1 year at least because it is 
the last branch released before changes to release process were 
committed.

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