should we allow users to override gcloud / flags configuration within 'train_cloudml()'? about cloudml HOT 6 CLOSED

Yes, the flags parameter in particular is trivially supported by just forwarding it's value to training_run (which also supports a flags parameter in just this fashion).

In terms of gcloud I hadn't thought about it but it does seem like some might have use for this (although it would certainly be defensible to just start with the config file and add a gcloud parameter as needed/requested.

from cloudml.

Sounds good. FWIW there is a bit of extra work to be done on the deployment side -- since the flags will be defined on the user's computer but need to be applied and set on the deployment machine, we'd have to serialize those flags, transfer them as part of the bundle, then re-read and use them in the ensuing call to training_run(). (All the infrastructure for this is thankfully in place already; just wanted to double check that this was in line with the tfruns philosophy)

from cloudml.

from cloudml.

We decided we will have 3 arguments like this:

flags = "flags.yml"
cloudml_config = "cloudml.yml"
gcloud_config = "gcloud.yml"

Then users can pass lists as an alternative to any of those file values.

from cloudml.

The gcloud config file will support forwarding all gcloud wide config flags

from cloudml.

Duplicate of #5

from cloudml.