Re: [Gluster-devel] Should glusterfs-3.10 become the new default with its first release?

2017-02-17 Thread Niels de Vos
On Fri, Feb 17, 2017 at 12:33:54PM -0500, Shyam wrote:
> On 02/17/2017 12:01 PM, Niels de Vos wrote:
> > I've been preparing the GlusterFS 3.10 released for the CentOS Storage
> > SIG, and that means I need to craete a new centos-release-gluster310
> > package. This is the package that users install when they want to enable
> > the YUM repository from the SIG.
> > 
> > Users are recommended to execute the following commands:
> > 
> >   # yum install centos-release-gluster
> 
> When users *chose* the above, what did they actually choose to do? Stay at
> the latest LTM for Gluster?
> 
> What I mean is, when a user chooses explicitly to do "yum install
> centos-release-gluster38", the choice is clear, they want to be on 3.8 till
> they choose to add the repo for 3.10 or other.
> 
> So, in the former case, when they chose to add centos-release-gluster, what
> was the choice made? To stay at the latest LTM, then we should modify it,
> else we should not.

When users install centos-release-gluster, they should get the release
we suggest for new deployments. If users specifically install
centos-release-gluster38, they will get the 3.8 bits and we will not
force them to upgrade (yet?).

I do not think we should automatically initiate upgrades for users that
have 3.8 once 3.10 it available. This is not something we test a lot and
surely not with all possible 3.8.x and 3.10.y combinations. We cant say
for sure that users regulary install the minor updates.

> At a later date when we choose to modify it to say 3.10.x (x>0), what is the
> decision based on? How do we communicate that to the users?

Once 3.10 is available on the CentOS mirrors, I'll send an email to
their announce list. With that message, we can explain in detail how
things are expected to work and what versions users can choose. If 3.10
is not the default yet, I can send a 2nd email when it changed.

The emails look a bit like this, it follows some kind of format that
needs review and approval by the CentOS team:
  https://lists.centos.org/pipermail/centos-announce/2017-January/022250.html


> >   # yum install glusterfs-server
> > 
> > Now, the current default for centos-release-gluster is that GlusterFS
> > 3.8.x is made available. Users can install centos-release-gluster39
> > explicitly, but it is not an update that will replace the 3.8 version.
> > 
> > Should the centos-release-gluster package (well, it is privided by
> > others) install the 3.8 YUM repository for a while until 3.10.1 is
> > released (or such)? Or, shall I make 3.10 the new default?
> 
> I think I understand your thought process here, which I presume is to gain a
> level of stability in 3.10 (if it is not the case out of the door), before
> unleashing it on unsuspecting users.

Yes, that. It is about how confident we are that the release is not
broken for common use-cases. The Storage SIG sees a lot of oVirt and
similar environments, and there will be newly installed clients+servers
with old existing servers. Possibly also old clients and new servers.

> For me it depends on what centos-release-gluster means, and defining the
> criteria for updating the same, which then becomes easier to repeat.

The package centos-release-gluster is virtual, it is provided by the
real packages centos-release-gluster38 and centos-release-gluster310. We
can only tune it to install a certain version at the time the package is
installed, after installation the version is more or less fixed.

HTH,
Niels


> > I aim to not replace the existing 3.8 deployments, they can stay on 3.8
> > for an other ~6 months:
> >   https://www.gluster.org/community/release-schedule/
> > 
> > Thanks,
> > Niels
> > 
> > 
> > 
> > ___
> > Gluster-devel mailing list
> > Gluster-devel@gluster.org
> > http://lists.gluster.org/mailman/listinfo/gluster-devel
> > 


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

Re: [Gluster-devel] Should glusterfs-3.10 become the new default with its first release?

2017-02-17 Thread Joe Julian

On 02/17/17 09:33, Shyam wrote:

On 02/17/2017 12:01 PM, Niels de Vos wrote:

I've been preparing the GlusterFS 3.10 released for the CentOS Storage
SIG, and that means I need to craete a new centos-release-gluster310
package. This is the package that users install when they want to enable
the YUM repository from the SIG.

Users are recommended to execute the following commands:

  # yum install centos-release-gluster


When users *chose* the above, what did they actually choose to do? 
Stay at the latest LTM for Gluster?


What I mean is, when a user chooses explicitly to do "yum install 
centos-release-gluster38", the choice is clear, they want to be on 3.8 
till they choose to add the repo for 3.10 or other.


So, in the former case, when they chose to add centos-release-gluster, 
what was the choice made? To stay at the latest LTM, then we should 
modify it, else we should not.


centos-release-gluster should be the most long-term stable release 
possible. Bugs should be fixed, security issues as well, obviously. No 
new features. No API changes, imho.


If a systems engineer wants to test or deploy a specific version, they 
should have to take on that responsibility manually.




At a later date when we choose to modify it to say 3.10.x (x>0), what 
is the decision based on? How do we communicate that to the users?



  # yum install glusterfs-server

Now, the current default for centos-release-gluster is that GlusterFS
3.8.x is made available. Users can install centos-release-gluster39
explicitly, but it is not an update that will replace the 3.8 version.

Should the centos-release-gluster package (well, it is privided by
others) install the 3.8 YUM repository for a while until 3.10.1 is
released (or such)? Or, shall I make 3.10 the new default?


I think I understand your thought process here, which I presume is to 
gain a level of stability in 3.10 (if it is not the case out of the 
door), before unleashing it on unsuspecting users.


For me it depends on what centos-release-gluster means, and defining 
the criteria for updating the same, which then becomes easier to repeat.




I aim to not replace the existing 3.8 deployments, they can stay on 3.8
for an other ~6 months:
  https://www.gluster.org/community/release-schedule/

Thanks,
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


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


Re: [Gluster-devel] Should glusterfs-3.10 become the new default with its first release?

2017-02-17 Thread Shyam

On 02/17/2017 12:01 PM, Niels de Vos wrote:

I've been preparing the GlusterFS 3.10 released for the CentOS Storage
SIG, and that means I need to craete a new centos-release-gluster310
package. This is the package that users install when they want to enable
the YUM repository from the SIG.

Users are recommended to execute the following commands:

  # yum install centos-release-gluster


When users *chose* the above, what did they actually choose to do? Stay 
at the latest LTM for Gluster?


What I mean is, when a user chooses explicitly to do "yum install 
centos-release-gluster38", the choice is clear, they want to be on 3.8 
till they choose to add the repo for 3.10 or other.


So, in the former case, when they chose to add centos-release-gluster, 
what was the choice made? To stay at the latest LTM, then we should 
modify it, else we should not.


At a later date when we choose to modify it to say 3.10.x (x>0), what is 
the decision based on? How do we communicate that to the users?



  # yum install glusterfs-server

Now, the current default for centos-release-gluster is that GlusterFS
3.8.x is made available. Users can install centos-release-gluster39
explicitly, but it is not an update that will replace the 3.8 version.

Should the centos-release-gluster package (well, it is privided by
others) install the 3.8 YUM repository for a while until 3.10.1 is
released (or such)? Or, shall I make 3.10 the new default?


I think I understand your thought process here, which I presume is to 
gain a level of stability in 3.10 (if it is not the case out of the 
door), before unleashing it on unsuspecting users.


For me it depends on what centos-release-gluster means, and defining the 
criteria for updating the same, which then becomes easier to repeat.




I aim to not replace the existing 3.8 deployments, they can stay on 3.8
for an other ~6 months:
  https://www.gluster.org/community/release-schedule/

Thanks,
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


[Gluster-devel] Should glusterfs-3.10 become the new default with its first release?

2017-02-17 Thread Niels de Vos
I've been preparing the GlusterFS 3.10 released for the CentOS Storage
SIG, and that means I need to craete a new centos-release-gluster310
package. This is the package that users install when they want to enable
the YUM repository from the SIG.

Users are recommended to execute the following commands:

  # yum install centos-release-gluster
  # yum install glusterfs-server

Now, the current default for centos-release-gluster is that GlusterFS
3.8.x is made available. Users can install centos-release-gluster39
explicitly, but it is not an update that will replace the 3.8 version.

Should the centos-release-gluster package (well, it is privided by
others) install the 3.8 YUM repository for a while until 3.10.1 is
released (or such)? Or, shall I make 3.10 the new default?

I aim to not replace the existing 3.8 deployments, they can stay on 3.8
for an other ~6 months:
  https://www.gluster.org/community/release-schedule/

Thanks,
Niels


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