Project

General

Profile

Actions

Feature #2334

closed

location matcher doesn't match on smart parameters

Added by David Schmitt about 11 years ago. Updated almost 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Organizations and Locations
Target version:
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

Version 1.1stable, running on Scientific Linux 6.x

I've got a parameterized class that should receive different arguments depending on the location of a node.

I've added location to the override order list and specified the new override with "location=TheLocation" and a value, but the value does not appear in the ENC output of the node, although both the class and the location appear correctly in the YAML.

Actions #1

Updated by Sam Kottler about 11 years ago

  • Category set to Organizations and Locations
  • Target version set to 1.2.0
Actions #2

Updated by Greg Sutcliffe almost 11 years ago

  • Tracker changed from Bug to Feature

Gonna set this as a Feture (more of an Enchancement) for the class-param work.

Actions #3

Updated by Joseph Magen almost 11 years ago

  • Status changed from New to Need more information

David, I replicated your scenario and the overridden value appears in the ENC output for me. Can you provide more information.

Actions #4

Updated by Joseph Magen almost 11 years ago

  • Assignee set to Joseph Magen
Actions #5

Updated by David Schmitt almost 11 years ago

I've got a host that has a class added via a hostgroup.

On the class, I add a smart variable (for testing, I assume the same matching mechanisms also apply to class params).

This is the configuration of the smart variable:

Name: loc_test
Description: test for location matching
Type: string
Default value: default
Order: fqdn hostgroup os domain location
Match: location=abc
Value: abc

Here is the output from https://foreman/hosts/testhost/externalNodes?name=testhost

--- 
  classes: 
    theclass: 
  parameters: 
    location: abc
    loc_test: default
Actions #6

Updated by Joseph Magen almost 11 years ago

  • Status changed from Need more information to Assigned

David, yes the matching mechanism is the same whether it's a smart variable (global) or smart class parameter

The smart variables appear in the yaml files under "parameters:" as in your example above.

The smart class parameters appear in the yaml files under "classes:" and then under the particular class it refers to.

I duplicated your exact example and "loc_test: abc" appears in the yaml output under parameters. I can't figure out what's wrong with your example. I'm sure that the smart variable "loc_test" was added to the class called "theclass". If so, it should work????

Actions #7

Updated by Joseph Magen almost 11 years ago

David, can this issue be closed?

Actions #8

Updated by David Schmitt almost 11 years ago

Retesting this, I found a deeper cause of my problem:

For some reason the displayed and the actual name of the location do not have the same case. At most places in the UI, the location is displayed with title case (i.e. first letter capitalized), but in the :edit, the name is entered all lower case.

I always tried matching to the lowercase version (which is also what can be seen in the YAML output and the database (taxonomies table), but actually the upcased version is matched.

Demo:

class: loctest
param: var
matcher1: location=rcv, value1: lowercase
matcher2: location=Rcv, value2: uppercase

(pruned) output:

--- 
  parameters: 
    location: rcv
  classes: 
    "bi::loctest": 
      var: uppercase
foreman=# select * from taxonomies;
 id | name |   type   |         created_at         |         updated_at         | ignore_types 
----+------+----------+----------------------------+----------------------------+--------------
  2 | rcv  | Location | 2013-01-28 12:24:14.135418 | 2013-02-11 16:26:10.407401 | --- []

This effect vanishes if the to_label function of app/models/taxonomy.rb is changed as follows:

  def to_label
    # name =~ /[A-Z]/ ? name : name.capitalize
    name
  end
Actions #9

Updated by Joseph Magen almost 11 years ago

thanks David, I will look into this further

Actions #10

Updated by Joseph Magen almost 11 years ago

David, I sent a pull request https://github.com/theforeman/foreman/pull/700 with your fix.
As a rule, I feel that changing uppercase, lowercase, etc should only be in the UI and not in business logic. The matcher should match whatever the user enters. I didn't realize that the code matches on #to_label, but apparently your test shows that it does.

Actions #11

Updated by Joseph Magen almost 11 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF