Re: F29 Self Contained Change: Origin 3.10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Jun 20, 2018 at 8:21 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Wed, Jun 20, 2018 at 8:07 AM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
>
>
>
> On Wed, Jun 20, 2018 at 8:02 AM Jan Kurik <jkurik@xxxxxxxxxx> wrote:
>>
>> = Proposed Self Contained Change: Origin 3.10 =
>> https://fedoraproject.org/wiki/Changes/origin3.10
>>
>>
>> Owner(s):
>>   * Jakub Čajka <jcajka at redhat dot com>
>>
>>
>> Rebase of the Openshift Origin package to the latest upstream version,
>> along with introduction of necessary infrastructure container images.
>>
>>
>> == Detailed description ==
>> Rebase of the Origin package to the latest upstream release. To note
>> upgrade path from previous version (3.9) will not be covered by this
>> change(dnf update origin, will most certainly be unable to cleanly
>> update Origin cluster), any one interested in helping out with the
>> supportable update path please reach out to the change owner or any
>> origin maintainer. Upstream provided update ansible playbooks are
>> located at https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/openshift-cluster/upgrades
>
>
> This sounds like a perfect use-case for a module. If `dnf update` cannot be made safe on its own, then it might be best if it wasn't attempted as part of the system upgrade, but was instead made into a module stream that users could switch to at their convenience.

You're making a huge assumption there. These days, I can generally
assume it's a matter of not wanting to try in the first place. And
modules don't improve the UX at all for this. The fact that no one has
attempted to make this a safe upgrade process is irrespective of
whether it's a normal RPM usable by all package managers or a module
that's usable only by DNF.

The assumption that I'm making is that users won't necessarily want to remain stuck on an older platform (such as an EOL Fedora) because the upgrade would break their cluster. Modules provide an opportunity to at least provide a stream of their current version and a stream of the newer version so that they can update the platform without breaking their cluster.

Of course, I may have been reading the original comment differently than intended; it sounded like "upgrading with these packages installed may break your cluster". If instead it was "after upgrading these packages, you must run these ansible playbooks to update your cluster", that's a slightly different story. But I'd want to know for sure that a simple `dnf update` wouldn't break things. 
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/MPSA5QHNYA2OJEEGKILAPIUQKEZS2LPU/

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux