$ python ./mytest.py
before deepcopy
f1 is f: True
f1 == f: True
after deepcopy
f1 is f: False
f1 == f: True
$ cat mytest.py
#!/usr/bin/python
import copy
f = {'a': {'b': {'c': {1
f1 = f
print("before deepcopy")
print("f1 is f: %s" % (f1 is f))
print("f1 == f: %s" % (f1 == f))
f = copy.de
Diff comments:
> diff --git a/cloudinit/config/cc_apt_configure.py
> b/cloudinit/config/cc_apt_configure.py
> index 42c5641..76b8d64 100644
> --- a/cloudinit/config/cc_apt_configure.py
> +++ b/cloudinit/config/cc_apt_configure.py
> @@ -476,9 +477,13 @@ def convert_v2_to_v3_apt_format(oldcfg):
>
Scott Moser has proposed merging ~smoser/cloud-init:bug/1621180 into
cloud-init:master.
Commit message:
apt config conversion: treat empty string as not provided.
Old behavior allowed a user to provide:
apt_mirror: ""
And that was the same as:
apt_mirror: null
and the same as having not sp
The proposal to merge ~smoser/cloud-init:bug/1621180 into cloud-init:master has
been updated.
Commit Message changed to:
apt config conversion: treat empty string as not provided.
Old behavior allowed a user to provide:
apt_mirror: ""
And that was the same as:
apt_mirror: null
and the sam
The proposal to merge ~bregeer-ctl/cloud-init:bugfix/centos7_resolv into
cloud-init:master has been updated.
Status: Needs review => Rejected
For more details, see:
https://code.launchpad.net/~bregeer-ctl/cloud-init/+git/cloud-init/+merge/305058
--
Your team cloud init development team is r
Review: Disapprove
I am not willing to sign the CLA as it currently stands. I have no issues with
providing my changes under the GPLv3, I do have issues signing a document that
states Canonical is allowed to re-license my changes under any license they
deem necessary. I also refuse to agree to
Re: smoser's comment:
> Some of those have per-interface dns configuration, some do not. It'd be nice
> to render this
> per-interface information when we can.
If we tell networkmanager not to manage /etc/resolv.conf, those
interface-specific nameservers are going to be effectively ignored. I
This all looks fine as far as fixing the immediate problem.
I can't help but feel that there must be a better way to cooperate with
networkmanager, because there are some situations in which it's really useful
to have nm managing dns (vpn environments in which you want certain domains to
resolv
This generally looks good.
cloud-init gets network configuration from a variety of sources (openstack
config drive in 'interfaces(5)' format, config drive in network_data.json
format, Nocloud in 'network_config' format
Some of those have per-interface dns configuration, some do not. It'd
9 matches
Mail list logo
