On Wed, Jun 20, 2018 at 8:44 AM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > > > 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. > I think in this case, parallel installable packages would actually make sense here. If the old system needs to be around for a data migration (and it can't do it automatically upon start of the OpenShift cluster services), then parallel installable packages need to be made so that users can do the transition while still being able to access the old version's data. > 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. Sure, with this I agree too. I just wish people wouldn't cop out on handling upgrades, though... -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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/2BSTLN4NRUPQCG4TDQFFJQ3W6URJU64F/
