Red Hat Bugzilla – Bug 1458817
[RFE] Prioritize attribute order in puppet classes limited to 255 chars
Last modified: 2018-02-21 07:39:59 EST
Description of problem: Prioritize attribute order feature for puppet class override does not allow more than 255 characters. Version-Release number of selected component (if applicable): 6.2.9 How reproducible: Always Steps to Reproduce: 1. Go to Sat Webui, "Configure" --> "Classes" --> *Select a class* 2. Go to "Smart Class Parameter" --> *Select a class and click on override* 3. Enter/paste more than 255 chars in the "Order" field and try to save it Actual results: Errors out with "is too long (maximum is 255 characters)" Expected results: Should get accepted Additional info: Customer is trying for 604 chars
This is: # select key,path from lookup_keys where key='max_luns'; key | path ----------+----------------------------------- max_luns | gsd-all-00-ob_n_dhporacle30\r + | gsd-all-00-ob_p_dhporacle30\r + | gsd-all-00-ob_n_dhporacle\r + | gsd-all-00-ob_p_dhporacle\r + | gsd-all-00-ob_n_dhporacledvsz\r + | gsd-all-00-ob_n_dhporacledvsz30\r+ | gsd-all-00-ob_p_dhporacledvsz\r + | gsd-all-00-ob_p_dhporacledvsz30 (1 row) And # \d lookup_keys; Table "public.lookup_keys" Column | Type | Modifiers --------------------+-----------------------------+---------------------------------------------------------- id | integer | not null default nextval('lookup_keys_id_seq'::regclass) key | character varying(255) | created_at | timestamp without time zone | updated_at | timestamp without time zone | puppetclass_id | integer | default_value | text | path | character varying(255) | description | text | validator_type | character varying(255) | validator_rule | character varying(255) | key_type | character varying(255) | override | boolean | default false required | boolean | default false merge_overrides | boolean | not null default false avoid_duplicates | boolean | not null default false use_puppet_default | boolean | type | character varying(255) | merge_default | boolean | not null default false hidden_value | boolean | default false Indexes: "lookup_keys_pkey" PRIMARY KEY, btree (id) "index_lookup_keys_on_key" btree (key) "index_lookup_keys_on_path" btree (path) "index_lookup_keys_on_puppetclass_id" btree (puppetclass_id) "index_lookup_keys_on_type" btree (type) Foreign-key constraints: "lookup_keys_puppetclass_id_fk" FOREIGN KEY (puppetclass_id) REFERENCES puppetclasses(id) Referenced by: TABLE "environment_classes" CONSTRAINT "environment_classes_lookup_key_id_fk" FOREIGN KEY (puppetclass_lookup_key_id) REFERENCES lookup_keys(id) TABLE "lookup_values" CONSTRAINT "lookup_values_lookup_key_id_fk" FOREIGN KEY (lookup_key_id) REFERENCES lookup_keys(id)
Created redmine issue http://projects.theforeman.org/issues/19934 from this bug
This is really an RFE, the field 'Order' is only meant to contain the types of matchers, not the values of the matchers themselves. fqdn hostgroup os domain Instead I believe you want to input hostgroup labels directly and have Satellite automatically understand you want to match hostgroups params in a certain order. We can trivially remove the limit but it won't help with the goal you have, as the field isn't meant for that, hence why I'm changing it to RFE (it makes sense though)
Upstream bug assigned to tbrisker@redhat.com
(In reply to Daniel Lobato Garcia from comment #6) > This is really an RFE, the field 'Order' is only meant to contain the types > of matchers, not the values of the matchers themselves. > > fqdn > hostgroup > os > domain > > Instead I believe you want to input hostgroup labels directly and have > Satellite automatically understand you want to match hostgroups params in a > certain order. > > We can trivially remove the limit but it won't help with the goal you have, > as the field isn't meant for that, hence why I'm changing it to RFE (it > makes sense though) Hey Daniel, no that is not the case. Our use case is *simply* that this field is not large enough to contain all the types we need to add. Our environment is global. As the matchers are simplistic (key = value) we simply have a fact that returns a key for each AD group a server is a member of and set the value to true. # dzdo facter -p | grep gsd gsd-all-00-ob_n_dhporacledvsz => true gsd-all-00-ob_n_dhporacledvsz30 => true This has certain advantages over checking if the value is in an array in that we can be deterministic with priority (i.e if a server is in multiple AD groups) Our matchers then are: if gsd-all-00-ob_n_dhporacledvsz = true then <value> if gsd-all-00-ob_n_dhporacledvsz30 = true then <value> Hope this clarifies. In our lab we have updated the length of the path column to 1024 chars. We need a support commitment before we can do the same to production though.
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/19934 has been resolved.
Verified on latest 6.3 snap for both smart class parameters and smart variables Used proposed list in comment1 multiplied by 2 (around 600 characters) and everything saved successfully
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0336