[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

[Kaleb S. KEITHLEY]

On 08/01/2017 01:05 PM, Stephen John Smoogen wrote:


I will bring this up at the meeting tomorrow, but I believe that the 
plan would be something like the following:


1. "Update" the current package with README.deprecated explaining why 
the package is being removed from the repository and what a user needs 
to do to get newer versions. A /usr/share/docs/ceph/upstream-ceph.repo 
may also be useful. [Putting in a Summary that the package is deprecated 
may also be useful.]



Update the package with a README.deprecated?

IOW add a README.deprecated file in dist-git, add it to the %doc in 
ceph.spec, and build+update version 0.80.7 (the current epel7 version) 
of the package.


If that's the case, consider this as the announcement that this is going 
to happen shortly.




2. Announce on epel-devel and epel-announce this is going to happen.
2. push the update out to users.
3. orphan the package in EPEL
4. remove it after a month after the update went to stable.

We also need to look at coming up with tools and a process to better 
look at packages we have in the repository so we don't make both the 
maintainer (aka Kaleb) and the users lifes miserable.


Does the above sound reasonable ?


--
Stephen J Smoogen.



___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

[Stephen John Smoogen]

packages can be blocked from being forked in EPEL. I don't remember if that
is koji or some other higher end tool.

On 3 August 2017 at 18:09, Ken Dreyer  wrote:

> On Tue, Aug 1, 2017 at 11:05 AM, Stephen John Smoogen 
> wrote:
> >
> > Does the above sound reasonable ?
> >
>
> Sounds great.
>
> It leads me to ask a question I've been wondering about for a while
> w.r.t retiring Ceph from EPEL 7: How can we keep other random
> contributors from re-introducing Ceph to EPEL? Anyone in the packagers
> FAS group could do it without checking around, right?
>
> - Ken
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

[Ken Dreyer]

On Tue, Aug 1, 2017 at 11:05 AM, Stephen John Smoogen  wrote:
>
> Does the above sound reasonable ?
>

Sounds great.

It leads me to ask a question I've been wondering about for a while
w.r.t retiring Ceph from EPEL 7: How can we keep other random
contributors from re-introducing Ceph to EPEL? Anyone in the packagers
FAS group could do it without checking around, right?

- Ken
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

[Kevin Fenzi]

On 08/01/2017 10:05 AM, Stephen John Smoogen wrote:
> On 1 August 2017 at 12:32, Jeffrey Ollie  wrote:
> 
>> Building 12.1.1 for EPEL7 would be VERY bad IMNSHO.  0.80.7 _is_ seriously
>> out of date, but:
>>
>> 1) You can't upgrade directly from 0.80.7 to 12.1.1 without upgrading to
>> at least 0.94.X and then 10.2.X first, and there are probably other
>> intermediate steps as well (you'd have to dig through the release notes to
>> be sure).
>>
>> http://docs.ceph.com/docs/master/release-notes/#upgrading-from-pre-jewel-
>> releases-like-hammer
>> http://docs.ceph.com/docs/master/release-notes/#
>> upgrading-from-infernalis-or-hammer
>> http://docs.ceph.com/docs/master/release-notes/#id598
>> http://docs.ceph.com/docs/master/release-notes/#upgrading-from-firefly
>>
>> Upgrading a Ceph installation is a non-trivial affair. Depending on the
>> versions involved and the amount of data in your system it can take days
>> for even a small installation. There are also a number of prerequisites
>> that need to be checked before upgrading like the underlying filesystem
>> used, file ownership, config settings etc.
>>
>> 2) I suspect that most people that are running Ceph on a CentOS/RHEL
>> system have switched to using the repos provided by Ceph at
>> download.ceph.com. The primary advantage of the upstream Ceph repos is
>> that you can pin your system to a specific release train. I personally am
>> using Jewel currently, but Ceph maintains repos for many different release
>> trains.
>>
>> I'm sure that I wouldn't be the only person that would be incredibly
>> annoyed if a "yum upgrade" upgraded Ceph to Luminous before I was ready.
>> For one thing, 12.1.1 is considered a release candidate by Ceph. I'm not
>> upgrading my Ceph cluster until at least 12.2.0 (which is going to be the
>> stable release) and likely will wait until 12.2.1. I'm also going to wait
>> until I'm good and ready. Since major operations can take days (literally),
>> I'm not going to do the upgrade just before I leave town for the weekend
>> for example.
>>
>> Using the upstream Ceph repos means that I can switch from Jewel to
>> Luminous when I'm ready and still get upgrades for the kernel etc. without
>> a lot of bother.
>>
>> 3) Personally I think that the Ceph packages should just be deprecated
>> from the EPEL repo. Without the ability to provide packages for multiple
>> release trains theres no sane way to allow the end user to stay on a
>> specific release train until they are ready to upgrade, rather than when
>> the package manager decides to upgrade.
>>
>>
> I will bring this up at the meeting tomorrow, but I believe that the plan
> would be something like the following:
> 
> 1. "Update" the current package with README.deprecated explaining why the
> package is being removed from the repository and what a user needs to do to
> get newer versions. A /usr/share/docs/ceph/upstream-ceph.repo may also be
> useful. [Putting in a Summary that the package is deprecated may also be
> useful.]
> 2. Announce on epel-devel and epel-announce this is going to happen.
> 2. push the update out to users.
> 3. orphan the package in EPEL
> 4. remove it after a month after the update went to stable.
> 
> We also need to look at coming up with tools and a process to better look
> at packages we have in the repository so we don't make both the maintainer
> (aka Kaleb) and the users lifes miserable.
> 
> Does the above sound reasonable ?

Yep. Agreed on all points.

kevin




signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

[Jim Perrin]

On 08/01/2017 10:05 AM, Stephen John Smoogen wrote:

> I will bring this up at the meeting tomorrow, but I believe that the
> plan would be something like the following:
> 
> 1. "Update" the current package with README.deprecated explaining why
> the package is being removed from the repository and what a user needs
> to do to get newer versions. A /usr/share/docs/ceph/upstream-ceph.repo
> may also be useful. [Putting in a Summary that the package is deprecated
> may also be useful.]
> 2. Announce on epel-devel and epel-announce this is going to happen.
> 2. push the update out to users.
> 3. orphan the package in EPEL
> 4. remove it after a month after the update went to stable. 
> 
> We also need to look at coming up with tools and a process to better
> look at packages we have in the repository so we don't make both the
> maintainer (aka Kaleb) and the users lifes miserable. 
> 
> Does the above sound reasonable ?
> 


I think that's the best course of action.

+1 here.




-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

[Stephen John Smoogen]

On 3 August 2017 at 15:00, Kaleb S. KEITHLEY  wrote:

> On 08/01/2017 01:05 PM, Stephen John Smoogen wrote:
>
>>
>>
>> On 1 August 2017 at 12:32, Jeffrey Ollie  j...@ocjtech.us>> wrote:
>>
>> Building 12.1.1 for EPEL7 would be VERY bad IMNSHO.  0.80.7 _is_
>> seriously out of date, but:
>>
>> [snip]
>>
>>
>> I will bring this up at the meeting tomorrow, but I believe that the plan
>> would be something like the following:
>>
>
>
>
> And what was the decision?
>
>
>
The meeting did not have quorum. I am asking the steering committee members
to reply to this email to +1/-1 it here.


>


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

[Kaleb S. KEITHLEY]

On 08/01/2017 01:05 PM, Stephen John Smoogen wrote:



On 1 August 2017 at 12:32, Jeffrey Ollie > wrote:


Building 12.1.1 for EPEL7 would be VERY bad IMNSHO.  0.80.7 _is_
seriously out of date, but:

[snip]


I will bring this up at the meeting tomorrow, but I believe that the 
plan would be something like the following:




And what was the decision?





1. "Update" the current package with README.deprecated explaining why 
the package is being removed from the repository and what a user needs 
to do to get newer versions. A /usr/share/docs/ceph/upstream-ceph.repo 
may also be useful. [Putting in a Summary that the package is deprecated 
may also be useful.]

2. Announce on epel-devel and epel-announce this is going to happen.
2. push the update out to users.
3. orphan the package in EPEL
4. remove it after a month after the update went to stable.

We also need to look at coming up with tools and a process to better 
look at packages we have in the repository so we don't make both the 
maintainer (aka Kaleb) and the users lifes miserable.


Does the above sound reasonable ?


--
Stephen J Smoogen.



___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

[Kaleb S. KEITHLEY]

On 08/01/2017 01:05 PM, Stephen John Smoogen wrote:


I will bring this up at the meeting tomorrow, but I believe that the 
plan would be something like the following:


1. "Update" the current package with README.deprecated explaining why 
the package is being removed from the repository and what a user needs 
to do to get newer versions. A /usr/share/docs/ceph/upstream-ceph.repo 
may also be useful. [Putting in a Summary that the package is deprecated 
may also be useful.]

2. Announce on epel-devel and epel-announce this is going to happen.
2. push the update out to users.
3. orphan the package in EPEL
4. remove it after a month after the update went to stable.

We also need to look at coming up with tools and a process to better 
look at packages we have in the repository so we don't make both the 
maintainer (aka Kaleb) and the users lifes miserable.


Does the above sound reasonable ?



Yes. That would be wonderful IMO.

--

Kaleb
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

[Stephen John Smoogen]

On 1 August 2017 at 12:32, Jeffrey Ollie  wrote:

> Building 12.1.1 for EPEL7 would be VERY bad IMNSHO.  0.80.7 _is_ seriously
> out of date, but:
>
> 1) You can't upgrade directly from 0.80.7 to 12.1.1 without upgrading to
> at least 0.94.X and then 10.2.X first, and there are probably other
> intermediate steps as well (you'd have to dig through the release notes to
> be sure).
>
> http://docs.ceph.com/docs/master/release-notes/#upgrading-from-pre-jewel-
> releases-like-hammer
> http://docs.ceph.com/docs/master/release-notes/#
> upgrading-from-infernalis-or-hammer
> http://docs.ceph.com/docs/master/release-notes/#id598
> http://docs.ceph.com/docs/master/release-notes/#upgrading-from-firefly
>
> Upgrading a Ceph installation is a non-trivial affair. Depending on the
> versions involved and the amount of data in your system it can take days
> for even a small installation. There are also a number of prerequisites
> that need to be checked before upgrading like the underlying filesystem
> used, file ownership, config settings etc.
>
> 2) I suspect that most people that are running Ceph on a CentOS/RHEL
> system have switched to using the repos provided by Ceph at
> download.ceph.com. The primary advantage of the upstream Ceph repos is
> that you can pin your system to a specific release train. I personally am
> using Jewel currently, but Ceph maintains repos for many different release
> trains.
>
> I'm sure that I wouldn't be the only person that would be incredibly
> annoyed if a "yum upgrade" upgraded Ceph to Luminous before I was ready.
> For one thing, 12.1.1 is considered a release candidate by Ceph. I'm not
> upgrading my Ceph cluster until at least 12.2.0 (which is going to be the
> stable release) and likely will wait until 12.2.1. I'm also going to wait
> until I'm good and ready. Since major operations can take days (literally),
> I'm not going to do the upgrade just before I leave town for the weekend
> for example.
>
> Using the upstream Ceph repos means that I can switch from Jewel to
> Luminous when I'm ready and still get upgrades for the kernel etc. without
> a lot of bother.
>
> 3) Personally I think that the Ceph packages should just be deprecated
> from the EPEL repo. Without the ability to provide packages for multiple
> release trains theres no sane way to allow the end user to stay on a
> specific release train until they are ready to upgrade, rather than when
> the package manager decides to upgrade.
>
>
I will bring this up at the meeting tomorrow, but I believe that the plan
would be something like the following:

1. "Update" the current package with README.deprecated explaining why the
package is being removed from the repository and what a user needs to do to
get newer versions. A /usr/share/docs/ceph/upstream-ceph.repo may also be
useful. [Putting in a Summary that the package is deprecated may also be
useful.]
2. Announce on epel-devel and epel-announce this is going to happen.
2. push the update out to users.
3. orphan the package in EPEL
4. remove it after a month after the update went to stable.

We also need to look at coming up with tools and a process to better look
at packages we have in the repository so we don't make both the maintainer
(aka Kaleb) and the users lifes miserable.

Does the above sound reasonable ?


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

[Jeffrey Ollie]

Building 12.1.1 for EPEL7 would be VERY bad IMNSHO.  0.80.7 _is_ seriously
out of date, but:

1) You can't upgrade directly from 0.80.7 to 12.1.1 without upgrading to at
least 0.94.X and then 10.2.X first, and there are probably other
intermediate steps as well (you'd have to dig through the release notes to
be sure).

http://docs.ceph.com/docs/master/release-notes/#upgrading-from-pre-jewel-releases-like-hammer
http://docs.ceph.com/docs/master/release-notes/#upgrading-from-infernalis-or-hammer
http://docs.ceph.com/docs/master/release-notes/#id598
http://docs.ceph.com/docs/master/release-notes/#upgrading-from-firefly

Upgrading a Ceph installation is a non-trivial affair. Depending on the
versions involved and the amount of data in your system it can take days
for even a small installation. There are also a number of prerequisites
that need to be checked before upgrading like the underlying filesystem
used, file ownership, config settings etc.

2) I suspect that most people that are running Ceph on a CentOS/RHEL system
have switched to using the repos provided by Ceph at download.ceph.com. The
primary advantage of the upstream Ceph repos is that you can pin your
system to a specific release train. I personally am using Jewel currently,
but Ceph maintains repos for many different release trains.

I'm sure that I wouldn't be the only person that would be incredibly
annoyed if a "yum upgrade" upgraded Ceph to Luminous before I was ready.
For one thing, 12.1.1 is considered a release candidate by Ceph. I'm not
upgrading my Ceph cluster until at least 12.2.0 (which is going to be the
stable release) and likely will wait until 12.2.1. I'm also going to wait
until I'm good and ready. Since major operations can take days (literally),
I'm not going to do the upgrade just before I leave town for the weekend
for example.

Using the upstream Ceph repos means that I can switch from Jewel to
Luminous when I'm ready and still get upgrades for the kernel etc. without
a lot of bother.

3) Personally I think that the Ceph packages should just be deprecated from
the EPEL repo. Without the ability to provide packages for multiple release
trains theres no sane way to allow the end user to stay on a specific
release train until they are ready to upgrade, rather than when the package
manager decides to upgrade.

On Tue, Aug 1, 2017 at 10:09 AM, Kaleb S. KEITHLEY 
wrote:

>
> The last version of Ceph that was built in epel7 was 0.80.7, back in
> December, 2016.
>
> That's pretty seriously out of date.
>
> Is anyone going to have any heartache if I build 12.1.1 for epel7?
>
> --
>
> Kaleb
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>



-- 
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org