Oh, I forgot to add that related to parallel installations, when conflicting modules are desired, generally containerization or virtualization is the recommended solution. However, this is from the RHEL user persona perspective. We realize that is a very different user persona from say a developer working in Fedora Rawhide.
Thank you, Terry Bowling Sr. Technical Product Manager - RHEL Systems Mgmt Red Hat, Inc. On Mon, Jun 17, 2019 at 4:04 PM Terry Bowling <tbowl...@redhat.com> wrote: > Regarding to a few of the questions about why modularity was created in > the first place (paraphrased), I can offer the following background. Note, > I was not on the team at the very beginning but have been very involved for > the last ~2 years. > > Do not consider the following to be formal answers, guidance, or laws of > nature. I'm only trying to help share some perspective. > > From the RHEL Product Management (PM) side, we observed the following > customer+market problems. Note this is not a perfect list but a rough, > paraphrased, quick brain dump: > > - Customers think we had too many repos. It is hard to find what they > need. > - optional, supplementary, extras, software collections, and more... > - Customers need more options that are fully supported to meet their > production workload requirements. > - 1. "I need as little change as possible. I will stick with the > version of DB provided with X.0 release for the next 10 years." > - 2. "I need newer versions of xyz to benefit from some features." > - 3. A few states in between 1 & 2. > - "Software Collections are helpful and provide us more choices, but > the user experience is awkward and most of the time we only install 1 > version at a time, with the exception of a few programming language > environments (multiple python, gcc, and so forth)." And it's a different > repo and a non-native software management workflow. > - RH need the distinction to provide realistic life cycles that > matched the true upstream life cycle. 5 year life cycles of DB's are a > good example, as well as the python 2 reaching its end of life. > Application Stream modules help with defining this, as well as enabling > customers to block access to versions that have reached the end of their > life cycle. > > Thus, RHEL PM asked for a method so solve these problems above. PM > objectives ideally should not dictate the technical implementation but > rather focus on addressing the customer/market problems, user experience, > supportability, and things like that. My understanding was that > package-name-versioning could have been acceptable to PM, but there were a > number of support and engineering challenges which led to the modularity > design. > > That said, some of the internal guidance was that: > > - Only select modules are parallel installable, primarily programming > languages such as python. > - while modularity could help with some traditional repository > challenges, it does not solve all, nor does it make RPM dependency problems > go away. Therefore only select things in Appstream should be modularized, > usually when collections of rpms serve a common use case, such as databases > or Identity Management. > - The RHEL distribution ensures a sane state of compatibility to > ensure a good user experience. So the analogy of conflicts with many > different repos does not magically go away. > - Disciplined distribution content management policies and > compatibility are still required as if they were different repos. > - Default stream versions defined so that if a user wants a simple > RHEL 7 like experience, they have it. They are not forced to use > modularity unless they want to or their workload dictates different > modules. > - Changing streams is a manual process, at least until modularity > matures. If a customer chooses a stream for their workload, we cannot > break that customer's workload. Though shalt do no harm. Therefore > auto-stream switching is off-limits in RHEL. At least for now until we > further understand customer demand and the risk impact as Appstream grows > to include more modules. > > That's all I can think of right now and I might have missed some things. > Again, it does NOT answer many of the questions in this thread and we know > we have future work to do. I would be happy to consult with, but not > dictate to, Fedora members on defining their own policy guidelines if > desired. > > Thank you, > Terry Bowling > Sr. Technical Product Manager - RHEL Systems Mgmt > Red Hat, Inc. > > > > On Mon, Jun 17, 2019 at 2:52 PM Neal Gompa <ngomp...@gmail.com> wrote: > >> On Mon, Jun 17, 2019 at 2:29 PM Colin Walters <walt...@verbum.org> wrote: >> > >> > On Mon, Jun 17, 2019, at 4:47 AM, Michael Schroeder wrote: >> > > On Fri, Jun 14, 2019 at 12:12:01PM -0400, Neal Gompa wrote: >> > > > I would actually really like to see rpm's multiversioning >> capabilities >> > > > extended to support this. >> > > >> > > I'd actually prefer to drop the multiversion mode for the kernel and >> > > instead add the version to the kernel package name. >> > >> > FWIW in rpm-ostree we go to some lengths to explicitly undo the libdnf >> default of multiple versions for the kernel, because the ostree side of >> things effectively multi-versions all of userspace as well. We're always >> creating a new root, so there's no concern about removing modules from the >> running kernel (any more than there is a similar concern for userspace >> components). An ostree deployment includes a (kernel+initramfs,userspace) >> as a pair; two deployments can happen to share a kernel, or not. A bit >> more info in >> > https://github.com/projectatomic/rpm-ostree/pull/1346 >> >> RPM-OSTree is functionally irrelevant in this discussion, since it has >> its own behavior patterns and eschews compatibility with the greater >> ecosystem anyway. It doesn't even support modules, so this whole >> discussion doesn't even matter for systems built on RPM-OSTree. >> >> >> -- >> 真実はいつも一つ！/ Always, there's only one truth! >> _______________________________________________ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
