Some parameters in job_client.create() don't work about gradient-cli HOT 8 CLOSED

Would creating /storage/config.json be a bad idea security-wise?

from gradient-cli.

hello @lefnire thanks for reporting this - we will take a look and push out change at the API, the env variables are getting passed along for jobs but not being returned as part of the object.

in the interim you can use experiments (gradient experiments create), which is a very similar interface as jobs with some additional syntax around /modelPath) - this will save and register your model in the paperspace system for easy deployment.

for security i wouldn't leave the /storage/config.json but set secrets at the project/cluster level and inject them in as experiment_env variables {db_read_creds: secret:DB_READ_CREDS)

from gradient-cli.

Thanks for the reply. The other reason I believe job_env wasn't passing is that my code cascades config.example.json -> config.json -> os.environ[x]. The 3rd was being printed as skipped in all the vars I passed. Is that we're they're accessed, as env-vars like export X=1 / os.environ['X']?

Thanks for the heads up on secrets, I'll look into that. Is there a definite security risk in /storage, like each user's /storage is publicly accessible, or is it more about good/bad practice? (Wondering if I need to do damage control now)

from gradient-cli.

if env variables get passed in correctly they get set the same way that you would with export X=1. you can read them in code as X = os.getenv('X'). you should see them on the actual job/experiment (which will be pushed out on the api side soon).

the config.json being on /storage is okay, just not a recommended practice, the persistent volume is only accessible to your workloads that are executed within your paperspace team. Might accidentally copy/move that config somewhere you didn't intend to, other people can see the config within the team (wouldn't want coworker seeing my github creds for instance), accidentally leak api key, ect).

from gradient-cli.

@lefnire re: working_dir - will update the documentation a bit to make this more clear: this is not a parameter for the WORKDIR of the container but the relative folder you want to be executing command from when you use a remote workspace (like github). shouldn't need to rebuild the container and package up your code inside every time you iterate, can instead snapshot your local directory or pull from a branch when the notebook/job/experiment/deployment executes.

from gradient-cli.

Thanks a million for the details @mkutsovsky !

from gradient-cli.

@lefnire we release a new version the gradient. This version we are using envVars instead of job_env and it should work as expected.

from gradient-cli.

y'all rock, thanks a million!

from gradient-cli.