Jobs triggered from rules should use their default config

[kofalt]

Right now, jobs that are launched via a rule end up with an empty config. Before the job is stored in the database, we should ensure it has the proper config - in this case, copying over the default config.

Probably a dependency of #922.

Additional details added by @nagem:

Gear documents stored in mongo will have a config field (possibly empty). An example:

"config" : {
            "multiple" : {
                "exclusiveMaximum" : true,
                "description" : "Any two-digit multiple of ten.",
                "default" : 20,
                "multipleOf" : 10,
                "maximum" : 100,
                "type" : "number"
            },
            "string" : {
                "default" : "Example",
                "type" : "string",
                "description" : "Any string."
            },
            "number" : {
                "default" : 3.5,
                "type" : "number",
                "description" : "Any number."
            },
            "phone" : {
                "default" : "555-5555",
                "pattern" : "^[0-9]{3}-[0-9]{4}$",
                "type" : "string",
                "description" : "Any local phone number, no country or area code."
            },
            "boolean" : {
                "default" : true,
                "type" : "boolean",
                "description" : "Any boolean."
            },
            "integer" : {
                "default" : 7,
                "type" : "integer",
                "description" : "Any integer."
            },
            "string2" : {
                "default" : "Example 2",
                "minLength" : 2,
                "type" : "string",
                "description" : "Any string from 2 to 15 characters long.",
                "maxLength" : 15
            }
        }

Before a job is persisted to the database (in Job.save()), if config is None (or an empty dictionary*), create a config map using the default key listed for each key in the gear's config. If there is no default, do not add the config key.

[ryansanford]

@nagem What is the effort and risk to accomplish this? Something Ambrus or David could pick up?

[nagem]

Effort level is minimal, definitely something they could pick up. I'll assign it to them and add a bit more description.

[nagem]

@kofalt Should there be a way to create a job with intentionally blank config? Note the asterisk above. We could decide that empty dictionaries specifically mean no defaults should be applied.

[kofalt]

I don't think job.Save() should be modified; it would have been better to put that in a comment. We want less business logic in the persistent "layer", not more. I would be open to the idea of that function throwing an exception, but I don't think it would be a improvement to the current codebase.

Applying defaults requires the gear document, and jobs cannot (import cycle) & should not reference gear concepts to keep the graph clean. Since gears are not an object (yet 😔), the best way to do this is likely a method in the gears namespace. Probably this signature:

def set_gear_default_config_on_job(gear_id, job_object)

Debatable if gear_id or gear_map is more appropriate; for this instance you may as well choose whichever type the concept is likely to be in the common invocation paths. When / if we switch over to objects we could transparently inflate.

After applying the defaults, the job should be validated. Easy to do, but adding it to this function makes sure we apply it uniformly. I think this is not called by job-add, at the moment...

This new function should be invoked by job-add via rules, and by job-add via endpoint.

Thoughts?

[nagem]

I view assigning default config if there is none as a convenience rather than a business decision. Is there any situation where we wouldn't assign a config if the gear requests it and has defaults available? Would we call the above method in every instance where a job is created? I'm not sure how I feel about that solution either.

[kofalt]

I lost a well-written reply due to laptops, but I want object modification to be explicit rather than implicit. Otherwise we have spooky action at a distance, which is bad. To answer your question: probably no, and probably yes.