Ok, guys, I have done some digging into fuelclient and corresponding nailgun code and discovered some features of deployment settings processing for cli.
So only solution I may propose to you guys is using separate network configuration for env via cli. Workflow is similar to that with deployment data:
1) download default network configuration:
fuel --env {env_id} network --download [--dir {path}]
2) change needed settings in downloaded yaml file
3) upload changed configuration
fuel --env {env_id} network --upload [--dir {path}]
Few notations for this approach: it does make db data updated, so after deployment you get new values via corresponding requests; second - it doesn't work if you already have uploaded deployment configuration for whole env via cli, in such case network data will be taken from uploaded conf but not saved into db so afterwards you will get stale data for your requests; and third - AFAIU, not all data are updated (only section networks is using now) so keep that in mind.
Ok, guys, I have done some digging into fuelclient and corresponding nailgun code and discovered some features of deployment settings processing for cli.
So only solution I may propose to you guys is using separate network configuration for env via cli. Workflow is similar to that with deployment data:
1) download default network configuration:
fuel --env {env_id} network --download [--dir {path}]
2) change needed settings in downloaded yaml file
3) upload changed configuration
fuel --env {env_id} network --upload [--dir {path}]
Few notations for this approach: it does make db data updated, so after deployment you get new values via corresponding requests; second - it doesn't work if you already have uploaded deployment configuration for whole env via cli, in such case network data will be taken from uploaded conf but not saved into db so afterwards you will get stale data for your requests; and third - AFAIU, not all data are updated (only section networks is using now) so keep that in mind.