Feature #22090


API Support for easier use of Smart-Class Param Overrides

Added by Iain Walmsley over 6 years ago. Updated about 5 years ago.

Target version:
Fixed in Releases:
Found in Releases:


Similiar to #15003 around using Hammer to remove smart-class param overrides to hosts.

Currently there is a trivial API call to add an override by FQDN for a specific host - this is very useful for us;

-X POST --/api/v2/puppetclasses/:puppetclass_name/smart_class_parameters/:parameter_name/override_values -d '{"match":"fqdn=:hostname","value":":parameter_value}"}}'


--/api/v2/puppetclasses/apache::vhost/smart_class_parameters/port/override_values -d '{"match":"fqdn=myhost1","value":"4055"}}'

this is really nice and clean way of assigning values to hosts on a single basis, particularly when interfacing with external systems.

However when it comes to changing or removing this override, the calls are more elaborate, as you need to know both the specific numeric ID of the parameter, as well as the numeric ID of the override itself.


-X PUT --/api/v2/smart_class_parameters/412/override_values/1021 -d '{"override_value":{"match":"fqdn=myhost1","value":"4056"}}'
-X DELETE --/api/v2/smart_class_parameters/412/override_values/1021

This means external systems need to cache a list potentially of all override ids, parse and choose the related one.

Hence I would like to be able to edit using the same call as adding an override, or equivalent functionality for delete, eg.

-X PUT --/api/v2/puppetclasses/apache::vhost/smart_class_parameters/port/override_values -d '{"match":"fqdn=host1","value":"4057"}}'

Related issues 1 (0 open1 closed)

Related to Foreman - Bug #26232: Override Values API - request fails if the matcher attribute name has space or dot(.) character ClosedOri RabinActions
Actions #1

Updated by Iain Walmsley over 6 years ago

  • Category set to API
Actions #2

Updated by Iain Walmsley about 6 years ago

Having looked into this further the suggestion above clearly won't work. Instead, enabling friendlyid for LookupValue and allow overriding API calls to accept the match as the friendly name is a possibility? I have added a PR for this.

The match is unique per lookup key and the unit tests which use to_param automatically use the match string which appears to be working. However I wasn't sure if there was another way this should be being done or there's a reason this hasn't been implemented yet? If someone could have a look and advise me that'd be great.

Whatever the case, it would help hugely as setting individual overrides on hosts at the moment using the API is very clunky, especially when getting external systems to interface.

Actions #3

Updated by The Foreman Bot about 6 years ago

  • Status changed from New to Ready For Testing
  • Pull request added
Actions #4

Updated by Daniel Lobato Garcia over 5 years ago

  • Target version set to 1.20.0
  • Fixed in Releases 1.20.0 added
Actions #5

Updated by Iain Walmsley over 5 years ago

  • Status changed from Ready For Testing to Closed
Actions #6

Updated by Bryan Kearney over 5 years ago

  • Bugzilla link set to 1614768
Actions #7

Updated by Jitendra Yejare about 5 years ago


Just wanted to know the verification steps to verify this bug in downstream. Can you please provide the same ?

Actions #8

Updated by Ori Rabin about 5 years ago

  • Related to Bug #26232: Override Values API - request fails if the matcher attribute name has space or dot(.) character added

Also available in: Atom PDF