Bug 703196

Summary:	Unable to set non-numeric Args for job
Product:	Red Hat Enterprise MRG	Reporter:	Jan Sarenik <jsarenik>
Component:	cumin	Assignee:	Chad Roberts <croberts>
Status:	CLOSED ERRATA	QA Contact:	Jan Sarenik <jsarenik>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	2.0	CC:	croberts, eallen, iboverma, matt, tmckay
Target Milestone:	2.0.1
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	cumin-0.1.4878-1	Doc Type:	Bug Fix
Doc Text:	Cause When attributes are edited, condor interprets string values enclosed by explicit double quote characters as strings and string values without explicit double quotes as expressions. Consequence Submitting an Args value without explicit double quotes will cause Args to be interpreted as an expression, not a string. If Args contains non-numeric characters (such as 25s) setting the attribute will fail even though cumin will report "OK". This is because the failure status is not returned to cumin from condor. Workaround When setting a non-numeric value for Args, or setting other attributes with string values, enclose the value in double quotes. This will ensure that those attribute values are interpreted as strings rather than expressions. Result Enclosing string attribute values in double quotes will allow those attributes to be set correctly.	Story Points:	---
Clone Of:	696635
Clones:	723848 (view as bug list)		Environment:
Last Closed:	2011-09-07 16:42:37 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	696635, 715956
Bug Blocks:	723848, 723887

Description Jan Sarenik 2011-05-09 15:53:01 UTC

+++ This bug was initially created as a clone of Bug #696635 +++
I am not able to supply "25m" as an argument by editing the
attributes in Cumin. Job I am trying to edit is on hold
and I am comparing what I entered on input and what I get
back after submitting the changes.

cumin-0.1.4746-1.el5

How reproducible: 100%

Steps to reproduce:
0. Submit a simple /bin/sleep job
  using following script from command line:
--------------------
getent passwd test || adduser test
echo Submitting a job
su - test -c "condor_submit << EOF
Executable     = /bin/sleep
Universe = vanilla
concurrency_limits = JASANLIMIT
args    = 20m
queue 1
EOF"
--------------------

1. Grid -> Submissions -> submission -> job -> mark it and put it on hold
... wait until the status changes to "Held"
2. Grid -> Submissions -> submission -> job -> "Edit Attributes" (on top)
3. Change "Args" to "25m"
... wait until it gets updated
4. See the Job Attributes (read-only) while still in held state

Examples:
  a) if you change "234" to "25m" there follows a never-ending "Loading..."
  b) if you change whatever there is to "234", it should work, but the result will be "234.0"

Comment 1 Chad Roberts 2011-05-18 13:53:52 UTC

Fixed in revision 4768.

Comment 2 Chad Roberts 2011-05-18 13:53:52 UTC

    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:
Cause:  Cumin was sending an unquoted value to condor for the Args value.

Consequence:  Condor would treat that value (ie:  25m) as an expression, which wouldn't make any sense.  The result was that the QMF call would succeed, but the value would never get changed in condor because the eventual evaluation of the expression would fail (but the QMF call doesn't verify that part, so cumin would never know about it)

Fix:  Cumin is now adding quotes to the Args value before making the QMF call

Result:  Editing the Args to values like 25m or any other string will now work correctly.

Comment 3 Chad Roberts 2011-05-18 15:09:15 UTC

Matt recommended a workaround of having the user add quotes to the input box, which seems to work.  As a result of that, I have tweaked my fix so that it will support the user entering either quoted or unquoted strings into the box.  

The updated fix is in revision 4769

Comment 4 Jan Sarenik 2011-06-21 15:07:17 UTC

When I am editing arguments of a job and Cumin is running
with "update-interval: 2" (meaning the page gets updated
every two seconds), I can hardly manage to press Submit
button while the text form contains the changed string.

Besides that, I still see many "Edit Ad" notifications
in the yellow box, i.e.
 Edit Ad: OK                Dismiss
 Edit Ad: OK                Dismiss
 Edit Ad: OK                Dismiss
 Edit Ad: OK                Dismiss
 Edit Ad: OK                Dismiss
 Edit Ad: OK                Dismiss
 Edit Ad: OK                Dismiss
 Edit Ad: OK                Dismiss
 Edit Ad: OK                Dismiss

Comment 5 Chad Roberts 2011-06-22 19:21:20 UTC

Maybe the right way to go here is to close the original BZ (not being able to set non-numeric args) and open 2 new BZ's.

1)  The edit attributes page should NOT use the cumin update-interval (to avoid blowing away changes before the user can hit Submit).

2)  The multitude of "Edit Ad: OK" messages seem to be coming from saving values that were not changed.  ie:  you edit the args for a job, but when you hit submit, it is getting treated like you edited all of the editable fields--hence the multiple "Edit Ad: OK" messages.  

Thoughts?

Comment 6 Jan Sarenik 2011-06-23 15:52:09 UTC

I half-agree. This bug should not be closed as it is another
important thing that should be tested when the bug 1) is solved.

1) Bug 715956

2) Bug 715973

Thanks.

Comment 7 Trevor McKay 2011-07-18 19:32:39 UTC

Additional tweak needed for this.

Requirements strings now have explicit quotes around them after editing.  This prevents them from being interpreted by condor as expressions.  For attributes that are expressions, the quotes need to be left off.

Comment 8 Trevor McKay 2011-07-20 17:31:34 UTC

Adjusted in revision 4877

Backing out the change for adding quotes to attribute values automatically and changing the Tech note to a Known Issue.

Users will have to explicitly quote Args values if they contain non-numeric characters.

Comment 9 Trevor McKay 2011-07-20 17:43:52 UTC

    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,7 +1,11 @@
-Cause:  Cumin was sending an unquoted value to condor for the Args value.
+Cause
+    When attributes are edited, condor interprets string values enclosed by explicit double quote characters as strings and string values without explicit double quotes as expressions.
 
-Consequence:  Condor would treat that value (ie:  25m) as an expression, which wouldn't make any sense.  The result was that the QMF call would succeed, but the value would never get changed in condor because the eventual evaluation of the expression would fail (but the QMF call doesn't verify that part, so cumin would never know about it)
+Consequence
+    Submitting an Args value without explicit double quotes will cause Args to be interpreted as an expression, not a string.  If Args contains non-numeric characters (such as 25s) setting the attribute will fail even though cumin will report "OK".  This is because the failure status is not returned to cumin from condor.
 
-Fix:  Cumin is now adding quotes to the Args value before making the QMF call
+Workaround
+    When setting a non-numeric value for Args, or setting other attributes with string values, enclose the value in double quotes.  This will ensure that those attribute values are interpreted as strings rather than expressions.
 
-Result:  Editing the Args to values like 25m or any other string will now work correctly.+Result
+    Enclosing string attribute values in double quotes will allow those attributes to be set correctly.

Comment 12 Jan Sarenik 2011-07-21 10:40:48 UTC

Verified in cumin-0.1.4878-1.el5

Comment 13 errata-xmlrpc 2011-09-07 16:42:37 UTC

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