Description of problem: When user says 'n' to question 'Should the above be added to the store [Y/n]?' during creating/updating a feature following problems were observed: 1.) ccs asks if it should use a default value for all parameters even those which are not exist 2.) ccs print all invalid parameters, but it's not possible to tell when one parameter ends and second begins Example: name: Feature params: "Strange parameter ,.?": "Parameter 1": "Par2" "Par3" "Par4" ... # ccs -a -f Feature Adding feature "Feature" The store does not know about the following items: Parameter Par2 Par3 Par4 Parameter 1 Strange parameter ,.? Should the above be added to the store [Y/n]? n Use the default value for parameter "Par2" in feature "Feature"? [Y/n] Use the default value for parameter "Par3" in feature "Feature"? [Y/n] Use the default value for parameter "Par4" in feature "Feature"? [Y/n] Use the default value for parameter "Parameter 1" in feature "Feature"? [Y/n] Use the default value for parameter "Strange parameter ,.?" in feature "Feature"? [Y/n] The following errors were reported updating "Feature": 134218753: Invalid parameters supplied to feature Feature: Par3Par4Parameter 1Strange parameter ,.?Par2 Version-Release number of selected component (if applicable): condor-wallaby-tools-4.0-6 How reproducible: 100%
ccs will not ask to use default values for unknown parameters that are not added to the store. In addition to that, all unknown entries that are not added to the store (params, features, etc) will not be sent to the fail in a known failure case. Instead, ccs will remove the entries from the changes to be committed to the store. This means that if a change includes known and unknown entries, and the unknown are not added to the store, that the known entries will still be committed but the unknown will be thrown away. fixed on BZ701966-ccs-prompting
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: C: The condor_configure_store tool will prompt for configured items that are not in the store and ask the user whether to add them. C: If the user selects no and the configuration contained unknown parameters, condor_configure_store would still prompt if those invalid parameters should use default values. F: Removed unknown parameters from the list of parameters to ask for default values if they are not added to the store. R: condor_configure_store will not prompt for default values if unknown parameters are not added to the store.
Tested on: $CondorVersion: 7.6.3 Jul 13 2011 BuildID: RH-7.6.3-0.2.el5 $ $CondorPlatform: I686-RedHat_5.7 $ $CondorVersion: 7.6.3 Jul 13 2011 BuildID: RH-7.6.3-0.2.el5 $ $CondorPlatform: X86_64-RedHat_5.7 $ $CondorVersion: 7.6.3 Jul 13 2011 BuildID: RH-7.6.3-0.2.el6 $ $CondorPlatform: I686-RedHat_6.1 $ $CondorVersion: 7.6.3 Jul 13 2011 BuildID: RH-7.6.3-0.2.el6 $ $CondorPlatform: X86_64-RedHat_6.1 $ name: Feature params: par1: par2: # ccs -a -p par1 -f Feature Adding parameter "par1" Adding feature "Feature" The store does not know about the following items: Parameter par2 Should the above be added to the store [Y/n]? n Exception received when communicating with the configuration store This could be because of a communcation issue, or because the configuration store was taking too long to complete a task # ccs -l -f Feature Feature "Feature": Feature ID: 45 Name: Feature Included Parameters: Included Features: Conflicts: Dependencies: According to Comment 2 adding a Feature with known and unknown attributes should not end with exception. Attribute par1 should be part of Feature. >>> ASSIGNED
What version of packages are you using and what did you do in the editor? I performed the above command and added par2 to Feature and got: condor_configure_store -a -p par1 -f Feature Adding parameter "par1" Adding feature "Feature" The store does not know about the following items: Parameter par2 Should the above be added to the store [Y/n]? n Removing invalid changes from "Feature" Editor: --- !Parameter name: par1 type: string default: '' description: '' conflicts: [] depends: [] level: 0 must_change: false restart: false --- !Feature name: Feature params: par2: string conflicts: [] depends: [] includes: []
(In reply to comment #5) I am using this packages versions: condor-wallaby-base-db-1.14-1 python-wallabyclient-4.1-2 wallaby-utils-0.10.5-6 condor-wallaby-tools-4.1-2 condor-wallaby-client-4.1-2 ruby-wallaby-0.10.5-6 wallaby-0.10.5-6 As for 'Feature' the intention was to set both par1 and par2 as part of the feature, so the setting was: params: par1: par2:
Fixed on master. Updated FiV
Tested with: condor-wallaby-client-4.1-4 condor-wallaby-base-db-1.14-1 python-wallabyclient-4.1-4 wallaby-utils-0.10.5-6 condor-wallaby-tools-4.1-4 ruby-wallaby-0.10.5-6 wallaby-0.10.5-6 Tested on: RHEL5 x86_64, i386 - passed RHEL6 x86_64, i686 - passed >>> VERIFIED
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,4 +1 @@ -C: The condor_configure_store tool will prompt for configured items that are not in the store and ask the user whether to add them. +The condor_configure_store tool prompts the user whether the configured items that are not in the store are to be added to the store. Previously, if the user declined, the tool still prompted the user about whether these parameters should use their default values. With this update, the tool does no longer prompt the user for the default values when an unknown parameter is not added to the store.-C: If the user selects no and the configuration contained unknown parameters, condor_configure_store would still prompt if those invalid parameters should use default values. -F: Removed unknown parameters from the list of parameters to ask for default values if they are not added to the store. -R: condor_configure_store will not prompt for default values if unknown parameters are not added to the store.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-1249.html