You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I intended to use job names to differentiate between jobs, using a unique identifier for a type of job as well as a timestamp. However, HEAppE is currently very opinionated about the characters it allows for job names. They are restricted to the RegEx a-zA-Z0-9_\-\ \. (see this line in AbstractValidator ). So e.g. ISO date strings cannot be used for timestamps and the identifiers I was planning to use where incompatible either.
I tried to work around that by base32 encoding the identifier and using unix timestamps, however, that leads to some rather long worker names, which in turn leads to a BadRequest response (without any details on the reason), if this length exceeds 50 characters (I guess from here].
There appears to be no real reason for these restrictions. Slurm handles any of the special characters I threw at it fine as a job name. Also the restriction to 50 characters seems rather limiting. Would you consider relaxing both of these limitations (but if I had to choose, I would ask for more than 50 characters at this point)? Otherwise the job names become somewhat useless to me, as I will be probably be forced into implementing a lookup database to keep track of jobs separately.
Also some helpful description for the cause of the BadRequest response that is returned when the job name exceeds 50 characters would be nice.
The text was updated successfully, but these errors were encountered:
I intended to use job names to differentiate between jobs, using a unique identifier for a type of job as well as a timestamp. However, HEAppE is currently very opinionated about the characters it allows for job names. They are restricted to the RegEx
a-zA-Z0-9_\-\ \.
(see this line in AbstractValidator ). So e.g. ISO date strings cannot be used for timestamps and the identifiers I was planning to use where incompatible either.I tried to work around that by base32 encoding the identifier and using unix timestamps, however, that leads to some rather long worker names, which in turn leads to a BadRequest response (without any details on the reason), if this length exceeds 50 characters (I guess from here].
There appears to be no real reason for these restrictions. Slurm handles any of the special characters I threw at it fine as a job name. Also the restriction to 50 characters seems rather limiting. Would you consider relaxing both of these limitations (but if I had to choose, I would ask for more than 50 characters at this point)? Otherwise the job names become somewhat useless to me, as I will be probably be forced into implementing a lookup database to keep track of jobs separately.
Also some helpful description for the cause of the BadRequest response that is returned when the job name exceeds 50 characters would be nice.
The text was updated successfully, but these errors were encountered: