This is a little more complicated to backport to RHEL-7 kickstart.  The work for this mentioned above builds on the F30 handler, which is not in the version of pykickstart in RHEL-7 (most recent in F22).  I am hesitant to rebase pykickstart in RHEL-7 and would prefer a direct reimplementation of this work on rhel7-branch upstream and cutting a new release from that.  That would mean that the SSL handling work should extend the RHEL7 handler in this version of Kickstart.  That does introduce a problem where the RHEL7 handler in pykickstart in RHEL8 would then lack the SSL handler work, but that's easier to fix up than to rebase pykickstart in RHEL-7.

So this needs both a candidate PR for rhel7-branch and a candidate PR for rhel8-branch that adds the SSL commands to the RHEL7 handler to maintain forward compatibility.

Is anyone opposed to this approach?

(In reply to David Cantrell from comment #3)
> This is a little more complicated to backport to RHEL-7 kickstart.  The work
> for this mentioned above builds on the F30 handler, which is not in the
> version of pykickstart in RHEL-7 (most recent in F22).  I am hesitant to
> rebase pykickstart in RHEL-7 and would prefer a direct reimplementation of
> this work on rhel7-branch upstream and cutting a new release from that. 
> That would mean that the SSL handling work should extend the RHEL7 handler
> in this version of Kickstart.  That does introduce a problem where the RHEL7
> handler in pykickstart in RHEL8 would then lack the SSL handler work, but
> that's easier to fix up than to rebase pykickstart in RHEL-7.
> 
> So this needs both a candidate PR for rhel7-branch and a candidate PR for
> rhel8-branch that adds the SSL commands to the RHEL7 handler to maintain
> forward compatibility.
> 
> Is anyone opposed to this approach?

I'm not opposed, but I wonder why you're hesitant to rebase. I assumed the reason for pykickstart handling different OS versions itself was that it could be used as-is in all kinds of OS releases. Is there a huge difference between the versions in RHEL 7 and 8?

rhel7-branch is 744 commits behind master, rhel8-branch is now 86 commits behind.  That's a lot of change for a .7 update release.

The other major problem is python2 vs. python3.  I do not recommend a rebase of pykickstart in RHEL-7 because it is a high risk of impact to both anaconda and Satellite and any other product using pykickstart.  This is why pykickstart is built to version the handlers and the project is maintained with multiple stable branches at one time.

Adding in the CDN access patches to the RHEL7 handler in pykickstart's rhel7-branch as well as adding it to the RHEL7 handler in rhel8-branch is safer low risk path to take here.

*** Bug 1664390 has been marked as a duplicate of this bug. ***

Created attachment 1557738 [details]
0001-Add-repo-and-url-command-SSL-options-1701035.patch

Patch for rhel7-branch and adds the SSL options to the repo and url commands for the RHEL7 version of kickstart parsed by pykickstart.  This patch passes the pykickstart test suite on RHEL7.

This is specific to the rhel7-branch of pykickstart.

I've pushed these patches to pykickstart's rhel7-branch to prepare for a release once acks are set on this bug (and other rhel7.7 bugs for pykickstart).  Thanks.

I also need to push and build an update for RHEL-8's pykickstart at the same time I do this.  If I don't, then the version=RHEL7 handler in pykickstart in RHEL-8 will fail to parse kickstart files generated with this new build of pykickstart on RHEL-8, which would be a regression.

Bug #1702370 needs acks and then whatever fields set that tell me what branch the change should go on.  I don't know if that is 8.0.1 or 8.1.0 or something else.  Please advise.

Bug #1702370 appears to have been acked for RHEL 8.1.0

Today I released pykickstart-1.99.66.20 off rhel7-branch which incorporates the fix for this bug.  Tests pass on RHEL-7, in Travis-CI, and via %check when building in brew.  Covscan also passes.

Enjoy.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2074