Currently, the default kickstart snippets are written such that any unknown distro names are handled as if they were Red Hat Enterprise Linux 6. We've dealt with Fedora by mentioning it explicitly in the templates when necessary.
That's worked OK up until now, but there's likely to be a CentOS 7 beta some time in the next few months, and the handling of that and other Red Hat Enterprise Linux 7 derivatives means that this isn't going to work any more, since we can't hardcode special case handling of every possible derivative.
The simplest resolution I have been able to come up with is the following:
1. Add a "base_distro" context variable in the kickstart rendering. By default, this is the same as "distro". 2. Update the kickstart snippets to use base_distro rather than distro 3. Add an optional "base_distro" field to our distro records. If that is set, base_distro in the template rendering context is to that rather than yo the same thing as distro.
It's too late to get that into 0.16, but we could do it for 0.17.
Does anyone see a simpler way to resolve the problem? If not, I'll create an RFE for this and allocate it to 0.17.
Cheers, Nick.
On 02/27/2014 01:48 PM, Nick Coghlan wrote:
Currently, the default kickstart snippets are written such that any unknown distro names are handled as if they were Red Hat Enterprise Linux 6. We've dealt with Fedora by mentioning it explicitly in the templates when necessary.
That's worked OK up until now, but there's likely to be a CentOS 7 beta some time in the next few months, and the handling of that and other Red Hat Enterprise Linux 7 derivatives means that this isn't going to work any more, since we can't hardcode special case handling of every possible derivative.
The simplest resolution I have been able to come up with is the following:
- Add a "base_distro" context variable in the kickstart rendering. By
default, this is the same as "distro". 2. Update the kickstart snippets to use base_distro rather than distro 3. Add an optional "base_distro" field to our distro records. If that is set, base_distro in the template rendering context is to that rather than yo the same thing as distro.
It's too late to get that into 0.16, but we could do it for 0.17.
Does anyone see a simpler way to resolve the problem? If not, I'll create an RFE for this and allocate it to 0.17.
It occurs to me that this approach would need another tweak: allowing Distro entries to be created directly, since you would still want to be able to say that CentOS7 (for example) was derived from RedHatEnterpriseLinux7, even if you didn't have an RHEL 7 trees loaded into your Beaker instance. I'm open to other ways to tackle the problem that would avoid needing to do that, though.
Cheers, Nick.
Excerpts from Nick Coghlan's message of 2014-02-27 13:53:23 +1000:
On 02/27/2014 01:48 PM, Nick Coghlan wrote:
The simplest resolution I have been able to come up with is the following:
- Add a "base_distro" context variable in the kickstart rendering. By
default, this is the same as "distro". 2. Update the kickstart snippets to use base_distro rather than distro 3. Add an optional "base_distro" field to our distro records. If that is set, base_distro in the template rendering context is to that rather than yo the same thing as distro.
It occurs to me that this approach would need another tweak: allowing Distro entries to be created directly, since you would still want to be able to say that CentOS7 (for example) was derived from RedHatEnterpriseLinux7, even if you didn't have an RHEL 7 trees loaded into your Beaker instance. I'm open to other ways to tackle the problem that would avoid needing to do that, though.
Everywhere you say "distro" you mean "OS major" (a.k.a. "distro family").
But yes, that seems like a viable solution although as you noted it will require some UI work.
I assume we would want to use the "base OS major" when checking excluded families and install options as well -- that will make things easier for system owners. Instead of updating their exclusions and install options for RedHatEnterpriseLinux7 and every single derivative that comes along, they would only need to do it once.
On 02/27/2014 02:01 PM, Dan Callaghan wrote:
Excerpts from Nick Coghlan's message of 2014-02-27 13:53:23 +1000:
On 02/27/2014 01:48 PM, Nick Coghlan wrote:
The simplest resolution I have been able to come up with is the following:
- Add a "base_distro" context variable in the kickstart rendering. By
default, this is the same as "distro". 2. Update the kickstart snippets to use base_distro rather than distro 3. Add an optional "base_distro" field to our distro records. If that is set, base_distro in the template rendering context is to that rather than yo the same thing as distro.
It occurs to me that this approach would need another tweak: allowing Distro entries to be created directly, since you would still want to be able to say that CentOS7 (for example) was derived from RedHatEnterpriseLinux7, even if you didn't have an RHEL 7 trees loaded into your Beaker instance. I'm open to other ways to tackle the problem that would avoid needing to do that, though.
Everywhere you say "distro" you mean "OS major" (a.k.a. "distro family").
Sort of - the template conditions in some cases currently look like: "distro is osmajor('RedHatEnterpriseLinux7')".
However, you're right that "base_osmajor" might be a more accurate name for the new template variable, and we could set it directly to the text string rather than exposing the rich object directly.
For example, the following conditionals (from default_rhts_compat):
{% if distro.osversion.osmajor.osmajor.startswith('Fedora') %} {% set releasever = distro.osversion.osmajor.osmajor[6:] %} {% if releasever|int >= 15 or releasever == 'rawhide' %} {% set default_rhts_compat = False %} {% endif %} {% else %} {% if distro is osmajor('RedHatEnterpriseLinux7') %} {% set default_rhts_compat = False %} {% endif %} {% endif %}
would become:
{% if base_osmajor.startswith('Fedora') %} {% set releasever = base_osmajor[6:] %} {% if releasever|int >= 15 or releasever == 'rawhide' %} {% set default_rhts_compat = False %} {% endif %} {% else %} {% if base_osmajor == 'RedHatEnterpriseLinux7' %} {% set default_rhts_compat = False %} {% endif %} {% endif %}
But yes, that seems like a viable solution although as you noted it will require some UI work.
I assume we would want to use the "base OS major" when checking excluded families and install options as well -- that will make things easier for system owners. Instead of updating their exclusions and install options for RedHatEnterpriseLinux7 and every single derivative that comes along, they would only need to do it once.
Ah, that's a good point - I'll include that in the RFE.
How about when checking for template snippets? I'm inclined to say not - if instance admins want that behaviour, they can use symlinks to get the same effect.
Cheers, Nick.
Excerpts from Nick Coghlan's message of 2014-02-27 14:29:23 +1000:
Sort of - the template conditions in some cases currently look like: "distro is osmajor('RedHatEnterpriseLinux7')".
Yes that is a Jinja filter, shorthand for: distro.osversion.osmajor.osmajor == 'RedHatEnterpriseLinux7'
The important thing is that we are talking about (at the database level) a new relationship from OSMajor to OSMajor.
How we expose it in the templates is less important, although I would be inclined to expose the actual OSMajor instance (rather than its name) just for consistency. In fact we needn't expose it as a new variable at all, it would be reachable from the distro variable just as the ordinary OSMajor currently is.
So instead of distro.osversion.osmajor it becomes distro.osversion.osmajor.base_osmajor. We could even encapsulate that in the existing 'osmajor' Jinja filter so that the current template conditions that use "distro is osmajor()" remain unchanged. This way users don't have to update their custom snippets to obey base_osmajor.
Or if that is too magical it could be a separate Jinja filter, based_on_osmajor: distro is based_on_osmajor('RedHatEnterpriseLinux7')
The startswith case you quoted should probably be extracted to a Jinja filter as well, analogous to the osmajor() filter. Maybe: distro is osmajor('Fedora', match_prefix=True) although I can't remember if Jinja filters can accept named args....
On 02/27/2014 02:51 PM, Dan Callaghan wrote:
Excerpts from Nick Coghlan's message of 2014-02-27 14:29:23 +1000:
Sort of - the template conditions in some cases currently look like: "distro is osmajor('RedHatEnterpriseLinux7')".
Yes that is a Jinja filter, shorthand for: distro.osversion.osmajor.osmajor == 'RedHatEnterpriseLinux7'
The important thing is that we are talking about (at the database level) a new relationship from OSMajor to OSMajor.
How we expose it in the templates is less important, although I would be inclined to expose the actual OSMajor instance (rather than its name) just for consistency. In fact we needn't expose it as a new variable at all, it would be reachable from the distro variable just as the ordinary OSMajor currently is.
So instead of distro.osversion.osmajor it becomes distro.osversion.osmajor.base_osmajor. We could even encapsulate that in the existing 'osmajor' Jinja filter so that the current template conditions that use "distro is osmajor()" remain unchanged. This way users don't have to update their custom snippets to obey base_osmajor.
Or if that is too magical it could be a separate Jinja filter, based_on_osmajor: distro is based_on_osmajor('RedHatEnterpriseLinux7')
It couldn't be "is" due to the 1->many relationship involved, but yeah, a custom filter makes sense.
RFE filed at https://bugzilla.redhat.com/show_bug.cgi?id=1070597
Cheers, Nick.
On 02/26/2014 11:01 PM, Dan Callaghan wrote:
Excerpts from Nick Coghlan's message of 2014-02-27 13:53:23 +1000:
On 02/27/2014 01:48 PM, Nick Coghlan wrote:
The simplest resolution I have been able to come up with is the following:
- Add a "base_distro" context variable in the kickstart rendering. By
default, this is the same as "distro". 2. Update the kickstart snippets to use base_distro rather than distro 3. Add an optional "base_distro" field to our distro records. If that is set, base_distro in the template rendering context is to that rather than yo the same thing as distro.
It occurs to me that this approach would need another tweak: allowing Distro entries to be created directly, since you would still want to be able to say that CentOS7 (for example) was derived from RedHatEnterpriseLinux7, even if you didn't have an RHEL 7 trees loaded into your Beaker instance. I'm open to other ways to tackle the problem that would avoid needing to do that, though.
Everywhere you say "distro" you mean "OS major" (a.k.a. "distro family").
But yes, that seems like a viable solution although as you noted it will require some UI work.
I assume we would want to use the "base OS major" when checking excluded families and install options as well -- that will make things easier for system owners. Instead of updating their exclusions and install options for RedHatEnterpriseLinux7 and every single derivative that comes along, they would only need to do it once.
Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Hey Guys,
I've already run into this on the huntsville instance of beaker. I submitted a custom kickstart for RHSA-2.0-20140225.0 and anaconda complained that I was missing %end sections in my kickstart.
What time frame are you guys thinking for making the above changes? Should I create a patch that updates these snippets to handle OSMajor RedHatServerforARMDevelopmentPreview2? I'm been told that will stay consistent for the length of the preview.
Thanks
On 03/01/2014 06:40 AM, Bill Peck wrote:
What time frame are you guys thinking for making the above changes? Should I create a patch that updates these snippets to handle OSMajor RedHatServerforARMDevelopmentPreview2? I'm been told that will stay consistent for the length of the preview.
The proper fix will likely be in 0.17, which is currently looking like it will be in early May(ish). So if you wanted to special case a custom distro in the default templates for 0.16, we could do that as an interim fix.
Cheers, Nick.
beaker-devel@lists.fedorahosted.org
-
Bill Peck -
Dan Callaghan -
Nick Coghlan