Project

General

Profile

Actions

Bug #21172

closed

Unknown Variables in partition tables <%= @osver %>

Added by Ivan Necas over 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
TFTP
Target version:
Difficulty:
Triaged:
Yes
Fixed in Releases:
Found in Releases:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1459290

Description of problem: After provisioning a Host when Partition table template is unlocked and a kickstart specific variable @osver is used instead of @host.operatingsystem.major variable the @osver variable is not able to process causing the statements of a particular block of code.

According to the "Host configuration Guide in the 'A.3. Satellite Specific Functions and Variables - Table A.4. Kickstart Specific Variables' the table state that @osver is the same as @host.operatingsystem.major.

==================================================================
@osver The operating system major version number, same as @host.operatingsystem.major. ==================================================================

Version-Release number of selected component (if applicable): satellite-6.2.9-7

How reproducible: 100%

Steps to Reproduce:

1. Go to the "Hosts" - "Partition Tables" - select the "clone" - unlock for the specific Template.
2. Access the template by click it and add the following block of code:

<% if @host.operatingsystem.major.to_i 6 ->
modprobe -r qla2xxx
modprobe -r lpfc
partprobe
<
end -%>

3. Go back to the preview page of the partition template opened before and refresh the page. the 3 lines should be printed there.
4. Now go back to the Partition tables edition page and change the variable @host.operatingsystem to @osver.to_i

<% if @osver.to_i 6 ->
modprobe -r qla2xxx
modprobe -r lpfc
partprobe
<
end -%>

5. Go back to the preview page and refresh. Now you none of the lines were executed.
6. Change the @osver.to_i to @osver

<% if @osver 6 ->
modprobe -r qla2xxx
modprobe -r lpfc
partprobe
<
end -%>

7. Go back to the preview page and refresh. Now you none of the lines were executed.

Actual results:
The block of code defined between the <% if @osver 6 -> and < end -> and < if @osver.to_i == 6 -> and < end -%> are not being evaluated.

Expected results:
both variables @host.operatingsystem.major and @osver should be processed successful.


Related issues 4 (0 open4 closed)

Related to Foreman - Bug #1341: Unknown Variables in partition tablesClosedOhad Levy11/19/2011Actions
Related to Foreman - Bug #24931: @dynamic kickstart variable stopped working in Foreman 1.19.0DuplicateActions
Related to Foreman - Bug #25136: stack level to deep exception when rendering autoyast templateClosedTimo GoebelActions
Related to Foreman - Bug #25150: regression: @dynamic in template is always falseClosedPeter LehwessActions
Actions #1

Updated by The Foreman Bot over 6 years ago

  • Status changed from New to Ready For Testing
  • Assignee set to Ivan Necas
  • Pull request https://github.com/theforeman/foreman/pull/4883 added
Actions #2

Updated by Ivan Necas over 6 years ago

  • Related to Bug #1341: Unknown Variables in partition tables added
Actions #3

Updated by Tomer Brisker almost 6 years ago

  • Subject changed from Unknown Variables in partition tables <%= @osver %> to Unknown Variables in partition tables <%= @osver %>
  • Target version set to 1.19.0
  • Triaged set to Yes
  • Fixed in Releases 1.19.0 added
Actions #4

Updated by Ivan Necas almost 6 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions #5

Updated by Tomer Brisker over 5 years ago

  • Related to Bug #24931: @dynamic kickstart variable stopped working in Foreman 1.19.0 added
Actions #6

Updated by Timo Goebel over 5 years ago

  • Related to Bug #25136: stack level to deep exception when rendering autoyast template added
Actions #7

Updated by Timo Goebel over 5 years ago

  • Related to Bug #25150: regression: @dynamic in template is always false added
Actions

Also available in: Atom PDF