On Fri, 2019-10-18 at 11:39 +0300, Alexander Bokovoy wrote: > On to, 17 loka 2019, Orion Poplawski wrote: > > > > You could install the ipa-client package and enroll a system into IPA from a > > > > kickstart in RHEL 7 too.. Without modules. That's what I've deployed for the > > > > environments I support, for example. Using a module is not required there. > > > > > > That wasn't the point, though - the point was the answer the question > > > "why do we need *default* module streams?" > > > > > > The logic is this: FreeIPA maintainers wanted FreeIPA to be a module in > > > RHEL, to take advantage of the added flexibility around lifecycles and > > > version bumps (basically so each RHEL release isn't tied to one version > > > of FreeIPA forever). But if it's modularized and there's no concept of > > > 'default stream modules', this is a thing that breaks: you can't > > > install it from a kickstart. So, *given that* we wanted to modularize > > > FreeIPA in RHEL *and* we also want to still make it deployable via > > > kickstart, that creates a requirement for default stream modules or > > > something a lot like it. > > > > This doesn't seem quite true. You couldn't install it with the same kickstart > > you used for EL7, but you could use the new module command or syntax in kickstart: > > > > module --name=NAME [--stream=STREAM] > Actually, you could install client packages with the same kickstart file > as for RHEL 7, that was one of uses for default profiles. > > Server package installation from kickstart file is less of a worry > because we are running a different deployment process since switching to > domain level 1 and that implies you have to do client installation > first. > > And at the time when all this was designed, kickstart had no support for > modularized installation. It has it now, of course. Well, module installation vias kickstart has been supported since before 8.0 GA. But I guess the design decisions have taken place before that. > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
