In a new version of Pulp we’d like to improve the way kickstart trees are managed, so we are looking for your feedback on:
How do you use kickstart trees from a content management perspective right now?
e.g. just mirror them and use later for provisioning.
Do you lack any functionality and what are your use cases that drive that need?
e.g. I’d like to add some custom files and make them a part of the kickstart tree and not create pulp_distribution.xml file
Here is an example of a simple kickstart tree. There could be much more complex ones with nested RPM repositories and so on.
so my knowledge here is a bit rusty, but might still contain valid points you want to hear
Kickstart trees as published by Red Hat are a “write once” thing, so when they are published on the CDN they don’t change. So technically(!) there is no need to version them on the Katello side.
I have no idea if this holds true for other sources, call me biased
The way Katello uses Pulp2 requires us to add Kickstarts to ContentViews, because otherwise
it would not sync them over to our Content Proxies if the proxy does not carry the Library environment (which is something I personally recommend)
it would not list the kickstarts as available, synced install media
Esp the latter is confusing to users, as they don’t perceive kickstarts as a kind of content that needs to be in the CV for day2day operations.
They are unfortunate exceptions to this rule and occasionally KS trees do change when a fatal bug is found in the initramdisk. We’ve seen this in the past, so I’d rather see some mechanism for resyncing to be available. Maybe calling this “redownload” or something similar to indicate the content should not change. Or at least designing this in a way that KS tree can be easily deleted and synced again somehow.
Isn’t another reason to be able to filter out packages? I’ve heard that some customers love to filter out every possible package that should never be installed onto managed nodes.
Ability to pre-download key files (kernel/initramdisk, s390 custom files) when on-demand kickstart repository is synced for the first time.
Just for completeness: one feature we’re using from Pulp 2 is loading the info about distributions available in the kickstart (and we do OS mapping based on that), just to not miss this feature in Pulp 3
