###### tags: `Anaconda` `RFC`

# [RFC] Use repo files in Anaconda

Author: jkonecny \<[e-mail]\>
Date: 2019-09-06

This is a request for comment for feature which we are considering to be a part of Anaconda. It doesn't mean that this feature will be implemented or when it will be implemented. The main purpose of this RFC is to give community a chance to react and help us to find the best solution for the given problem.

## Short description

Extend support for repo files in installation environment to avoid duplicating all the repo files functionality in the pykickstart [repo command](https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#repo). The [repo files](https://dnf.readthedocs.io/en/latest/conf_ref.html) is already well defined format which is used by DNF directly. The repo files supports GPG keys, custom certificates and much more than pykickstart repo command will ever support.

## Justification

Right now we have a pykickstart [repo command](https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#repo) that has a plenty of functionality. Based on the last few PRs (see below) it looks it is going to grow even more. Point of this RFC is to get responses from the Anaconda community to find out if the proposed solution is good enough to replace the existing proposals to extend the repo command.

This way we would be able to add installer ISO creators a posibility to use complete functionality of the repo files without additional extension of the current pykickstart [repo command](https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#repo).

Another benefit will be that all the new functionality implemented by DNF with support from the repo file will automatically work in the Anaconda environment.

It should be possible to solve all these issues by this proposal:

---

Use [repo ssl options](https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#sshkey) we want to deprecate:

- [1] https://github.com/weldr/lorax/pull/839

Add new gpg keys for package verification:

- [2] https://github.com/pykickstart/pykickstart/pull/32
- [3] https://pagure.io/pungi/pull-request/63
- [4] https://github.com/rhinstaller/anaconda/pull/375

Add --priority repo command:

- [5] https://github.com/pykickstart/pykickstart/pull/275

## Proposed solution

Anaconda is able to load all the repo files in a specific directory and use that as the usual installation source. The harder part is to get the repo files into stage2 image. That is where I would like to get feedback from the maintainers of [Lorax](https://github.com/weldr/lorax/), [LiveCD tools](https://github.com/livecd-tools/livecd-tools) and maybe [Pungi](https://pagure.io/pungi) for injecting the repo files into the existing image.

### Create an updates image which will be applied during the bootup

1) Create a tool which will create an updates image with all the parts in it
* repo files
* SSL certificates and GPG keys
2) Integrate this updates image to the installation media so it will be automatically applied during the boot *(ISO builders work)*
3) Anaconda will read all the repo files from a predefined folder and use them the same way as if they were loaded by repo kickstart command.

This variant will share code for all the ISO creators. It can be easily extended to read SSL certificates and GPG keys from other local path, not just what is pointed by the repo file.

## Alternatives

### Use the current approach (not recommended)

Stay with the current solution with extending the kickstart repo command. I would really prefer to avoid this because it would complicate everything about how the repos are working.

---
---

# Comments section

If you want to comment to the whole topic. Please comment below in other case feel free to comment under parts which are interesting to you.

To write a comment you can switch to Edit (`Ctrl+Alt+E`) or Both (`Ctrl+Alt+B`) mode and write under the line separator below:

> [name=your name]
> comment

---
> [name=Neal Gompa]
> I'm not sure that this would work in most use-cases for kickstarts. Netinstalls and Koji builds with livecd-creator or livemedia-creator make the assumption that the only needed input is a ks file. Moreover, in most repositories fed in to kickstarts, things like GPG public key are actually *also* available via a URL that can be passed in. I think making repo files required for these extra options is going to make it effectively unusable for the cases where Kickstarts are still actively used for.
> > [name=Jiří Konečný]
> > Thanks a lot for your insights. We will take this into account for further plans.

> [name=Pat Riehecky]
> - to be clear, is this targeted at just the behavior in anaconda or will kickstart be changing as well?
> - I'm utlizing updates.img for site local customization and would prefer not to reuse updates.img in this manner
>
> I'd prefer a solution where lorax does the injection directly into the stage2 so that folks doing private mirrors on disconnected networks can maintain the current workflow (pxelinux->vmlinuz/initrd->stage2.img). If you are looking at something more complex, you may also need to bring the folks from pulp-project in for Sat6 intetgration.
>
>> [name=Jiří Konečný]
> - to be clear, is this targeted at just the behavior in anaconda or will kickstart be changing as well?
>
>> What we are trying to solve is to avoid adding more parts to pykickstart. If there will be a real benefit then we can use kickstart command here but otherwise I don't see a point in kickstart solution.
> - I'm utlizing updates.img for site local customization and would prefer not to reuse updates.img in this manner
>
>> Updates image can be used multiple times with no drawback. It's happening even now. You have product.img and updates.img which both are working the same way. The only difference is the purpose.
>>
> I'd prefer a solution where lorax does the injection directly into the stage2 so that folks doing private mirrors on disconnected networks can maintain the current workflow (pxelinux->vmlinuz/initrd->stage2.img). If you are looking at something more complex, you may also need to bring the folks from pulp-project in for Sat6 intetgration.
>
>> That could be an interesting solution. However, this is a question on Brian and Neal if they want to use updates image or rather inject these things on one place in the installation environment. The updates image has a benefit that there could be a tool which will prepare everything for you, so you can just call this tool and use the result. Easy enough and deduplication of work.
>> What we want to achieve here is to find a solution which would satisfy all the sides and they will agree on using the same solution from now on. It would be also beneficial to have their requirements on Anaconda.
>> For example how Anaconda should react on these repo files? Should they be loaded as additional files or in a similar way how `Closest mirror` is now implemented?

> [name=Vratislav Podzimek]
What about a new `%repos` section the contents of which
would just be used as a `.repo` file? I think that would
be a simple way to overcome the limitations of the KS
syntax using commands and options (except for sections).
>
>> [name=Jiří Konečný]
>> No it would not help much. The reason is that you have to get gpg keys and certificates with the repo files in the environment. So having the section `%repos` would not really solve much here.
>>
>>> [name=Vratislav Podzimek]
>>> As discussed face to face -- maybe a generic `%file` section would be useful