One inline question, probably for my own edification. Thanks!
Diff comments:
> diff --git a/cloudinit/net/sysconfig.py b/cloudinit/net/sysconfig.py
> index e381596..44a2f11 100644
> --- a/cloudinit/net/sysconfig.py
> +++ b/cloudinit/net/sysconfig.py
> @@ -708,6 +708,12 @@ class Renderer(renderer
I'm happy with the way it is here... we got rid of all 'import yaml' from
cloudinit.util at least.
and down to a signle place that 'yaml.load' is called.
--
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/374679
Your team cloud-init Commiters is requested to review the propo
Review: Approve continuous-integration
PASSED: Continuous integration, rev:e69df5dce264f9f329dd0630aad3954b32999153
https://jenkins.ubuntu.com/server/job/cloud-init-ci/1234/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu
Review: Needs Fixing continuous-integration
FAILED: Continuous integration, rev:e69df5dce264f9f329dd0630aad3954b32999153
https://jenkins.ubuntu.com/server/job/cloud-init-ci/1233/
Executed test runs:
FAILED: Checkout
Click here to trigger a rebuild:
https://jenkins.ubuntu.com/server/job/cloud
OK. I just wanted to make sure that I wasn't missing something on the dump
path.
For relocating; there are quite a few yaml users inside util.py so we'd still
need to import
safeyaml into util; so module load wise, we're still pulling it in on any
import of util. additionally, moving the load
Review: Approve continuous-integration
PASSED: Continuous integration, rev:e7c84bfdc42bc533a8f737ecd6b9557b466e1ebd
https://jenkins.ubuntu.com/server/job/cloud-init-ci/1232/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu
not a real advantage other than getting closer to getting all yaml
usage into a single place.
On Thu, Oct 24, 2019 at 12:56 PM Ryan Harper wrote:
>
> Is there an advantage to moving dumps into safeyaml? I didn't think dump had
> any concerns. Could we just have replaced the yaml.load() calls w
just in better use of modules... putting yaml things into their own module
rather than having them all in util.
I'm willing to move load_yaml also if you'd like. which would mean util would
have no yaml code in it.
--
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/374679
Is there an advantage to moving dumps into safeyaml? I didn't think dump had
any concerns. Could we just have replaced the yaml.load() calls with
util.load_yaml() ?
--
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/374679
Your team cloud-init Commiters is requested to rev
Scott Moser has proposed merging
~smoser/cloud-init:fix/1849640-adjust-yaml-usage into cloud-init:master.
Commit message:
Fix usages of yaml, and move yaml_dump to safeyaml.dumps.
Here we replace uses of the pyyaml module directly with functions
provided by cloudinit.safeyaml. Also, change/move
Review: Approve continuous-integration
PASSED: Continuous integration, rev:46310972f0ce5513b93d1c3c813cf6ef0b62f2f4
https://jenkins.ubuntu.com/server/job/cloud-init-ci/1229/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu
Note: retrying 12 times on average might be overkill here - but we rather be
pessimistic and add a lot of buffer.
--
https://code.launchpad.net/~tribaal/cloud-init/+git/cloud-init/+merge/374643
Your team cloud-init Commiters is requested to review the proposed merge of
~tribaal/cloud-init:fix/ex
Chris Glass has proposed merging
~tribaal/cloud-init:fix/exoscale-datasource-wait-timeout into cloud-init:master.
Requested reviews:
cloud-init Commiters (cloud-init-dev)
For more details, see:
https://code.launchpad.net/~tribaal/cloud-init/+git/cloud-init/+merge/374643
This change sets the u
13 matches
Mail list logo
