Re: [Cloud-init-dev] [Merge] ~goneri/cloud-init:freebsd_nocloud into cloud-init:master
it might be useful to have some test cases that cover the linux way using blkid and having a case that covers the FreeBSD way so future addition/changes to the data source don't break things up again without noticing. apart from that - looking at the code diff without really testing it - the change looks reasonable to me. -- https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/365630 Your team cloud-init commiters is requested to review the proposed merge of ~goneri/cloud-init:freebsd_nocloud into cloud-init:master. ___ Mailing list: https://launchpad.net/~cloud-init-dev Post to : cloud-init-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~cloud-init-dev More help : https://help.launchpad.net/ListHelp
Re: [Cloud-init-dev] [Merge] ~goneri/cloud-init:build-on-freebsd into cloud-init:master
i wonder if tools/build-on-freebsd could not be dropped completely as there is an official freshport in the meanwhile: https://www.freshports.org/net/cloud-init/ the port is version 18.3 and includes just some FreeBSD specific patches out of which i know some are 100% obsolete in the meanwhile. see https://svnweb.freebsd.org/ports/head/net/cloud-init/files/ instead of having this script i would rather have a closer work together with the port maintainer to get these FreeBSD patches upstream if still needed. or is there any good reason to still keep and maintain this build-on-freebsd script? if so i think we should make the script python2 and python3 compatible until we can drop python2 sometime in 2020. just my 2 cents ;-) -- https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/366333 Your team cloud-init commiters is requested to review the proposed merge of ~goneri/cloud-init:build-on-freebsd into cloud-init:master. ___ Mailing list: https://launchpad.net/~cloud-init-dev Post to : cloud-init-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~cloud-init-dev More help : https://help.launchpad.net/ListHelp
Re: [Cloud-init-dev] [Merge] ~liaoishere/cloud-init:sysconfig-bond-options into cloud-init:master
Thanks for looking at extending these options. Could you look at the existing unittests for sysconfig bond rendering in tests/unittests/test_net.py and extend that with some of the additional values. -- https://code.launchpad.net/~liaoishere/cloud-init/+git/cloud-init/+merge/366377 Your team cloud-init commiters is requested to review the proposed merge of ~liaoishere/cloud-init:sysconfig-bond-options into cloud-init:master. ___ Mailing list: https://launchpad.net/~cloud-init-dev Post to : cloud-init-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~cloud-init-dev More help : https://help.launchpad.net/ListHelp
Re: [Cloud-init-dev] [Merge] ~goneri/cloud-init:build-on-freebsd into cloud-init:master
I use the following script to prepare my FreeBSD images, my freebsd branch comes with all the patches from my different branches: https://github.com/virt-lightning/freebsd-cloud-images Python3 is on my TODO list, with a lower priority. If you open a bug, you can affect it to me. -- https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/366333 Your team cloud-init commiters is requested to review the proposed merge of ~goneri/cloud-init:build-on-freebsd into cloud-init:master. ___ Mailing list: https://launchpad.net/~cloud-init-dev Post to : cloud-init-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~cloud-init-dev More help : https://help.launchpad.net/ListHelp
Re: [Cloud-init-dev] [Merge] ~goneri/cloud-init:build-on-freebsd into cloud-init:master
This looks like a reasonable set of changes to me; is there any good way for me to test it? (Perhaps in a container/public cloud?) Also, do we need to open a bug for converting this script to Python 3 in preparation for dropping Python 2 support from cloud-init[0]? [0] https://lists.launchpad.net/cloud-init/msg00170.html -- https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/366333 Your team cloud-init commiters is requested to review the proposed merge of ~goneri/cloud-init:build-on-freebsd into cloud-init:master. ___ Mailing list: https://launchpad.net/~cloud-init-dev Post to : cloud-init-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~cloud-init-dev More help : https://help.launchpad.net/ListHelp
Re: [Cloud-init-dev] [Merge] ~rjschwei/cloud-init:triggerudev into cloud-init:master
Diff comments:
> diff --git a/cloudinit/net/sysconfig.py b/cloudinit/net/sysconfig.py
> index 0998392..5f6f2d8 100644
> --- a/cloudinit/net/sysconfig.py
> +++ b/cloudinit/net/sysconfig.py
> @@ -696,6 +696,14 @@ class Renderer(renderer.Renderer):
> if nm_conf_content:
> util.write_file(nm_conf_path, nm_conf_content, file_mode)
> if self.netrules_path:
> +# When many interfaces are present it can happen that we get here
> +# before they are all setup. Settle if that is the case.
> +for iface in network_state.iter_interfaces(
> +renderer.filter_by_physical):
> +path = net.sys_dev_path(str(iface))
> +if not os.path.exists(path):
> +util.udevadm_settle(path, 5)
> +break
Yes, a new event could block a second settle; I guess we would like some
confirmation that post-settle, the set of interfaces we were looking for are
now present, no?
# list of ifaces not yet present
missing = [iface for iface in
network_state.iter_interfaces(renderer.filter_by_physcal)
if not os.path.exists(net.sys_dev_path(str(iface))]
if len(missing):
util.udevadm_settle(timeout=5)
if any([iface for iface in missing if not
os.path.exists(net.sys_dev_path(str(iface))]):
log.warning('Some interfaces not yet present, possible badness')
And how hard should we try to wait for all physical interfaces?
> netrules_content = self._render_persistent_net(network_state)
> netrules_path = util.target_path(target, self.netrules_path)
> util.write_file(netrules_path, netrules_content, file_mode)
--
https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/363571
Your team cloud-init commiters is requested to review the proposed merge of
~rjschwei/cloud-init:triggerudev into cloud-init:master.
___
Mailing list: https://launchpad.net/~cloud-init-dev
Post to : cloud-init-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~cloud-init-dev
More help : https://help.launchpad.net/ListHelp
Re: [Cloud-init-dev] [Merge] ~rjschwei/cloud-init:triggerudev into cloud-init:master
Diff comments: > diff --git a/cloudinit/net/sysconfig.py b/cloudinit/net/sysconfig.py > index 0998392..5f6f2d8 100644 > --- a/cloudinit/net/sysconfig.py > +++ b/cloudinit/net/sysconfig.py > @@ -696,6 +696,14 @@ class Renderer(renderer.Renderer): > if nm_conf_content: > util.write_file(nm_conf_path, nm_conf_content, file_mode) > if self.netrules_path: > +# When many interfaces are present it can happen that we get here > +# before they are all setup. Settle if that is the case. > +for iface in network_state.iter_interfaces( > +renderer.filter_by_physical): > +path = net.sys_dev_path(str(iface)) > +if not os.path.exists(path): > +util.udevadm_settle(path, 5) > +break It is my understanding that "settle" will block until all pending udev events are processed. If we go though the process again in my mind that kind of implies that yet another device was attached after the first settle. In that use case we'd never get out of this loop as there can always be another device. > netrules_content = self._render_persistent_net(network_state) > netrules_path = util.target_path(target, self.netrules_path) > util.write_file(netrules_path, netrules_content, file_mode) -- https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/363571 Your team cloud-init commiters is requested to review the proposed merge of ~rjschwei/cloud-init:triggerudev into cloud-init:master. ___ Mailing list: https://launchpad.net/~cloud-init-dev Post to : cloud-init-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~cloud-init-dev More help : https://help.launchpad.net/ListHelp
[Cloud-init-dev] [Merge] ~liaoishere/cloud-init:sysconfig-bond-options into cloud-init:master
Liao Penghui has proposed merging ~liaoishere/cloud-init:sysconfig-bond-options
into cloud-init:master.
Commit message:
Support more bonding options for sysconfig system.
Currently, only a few bonding parameters can be configured on
sysconfig systems. This patch aims to support more parameters
documented on the docs site.
Requested reviews:
cloud-init commiters (cloud-init-dev)
For more details, see:
https://code.launchpad.net/~liaoishere/cloud-init/+git/cloud-init/+merge/366377
--
Your team cloud-init commiters is requested to review the proposed merge of
~liaoishere/cloud-init:sysconfig-bond-options into cloud-init:master.
diff --git a/cloudinit/net/sysconfig.py b/cloudinit/net/sysconfig.py
index a47da0a..be5dede 100644
--- a/cloudinit/net/sysconfig.py
+++ b/cloudinit/net/sysconfig.py
@@ -284,6 +284,18 @@ class Renderer(renderer.Renderer):
('bond_mode', "mode=%s"),
('bond_xmit_hash_policy', "xmit_hash_policy=%s"),
('bond_miimon', "miimon=%s"),
+('bond_min_links', "min_links=%s"),
+('bond_arp_interval', "arp_interval=%s"),
+('bond_arp_ip_target', "arp_ip_target=%s"),
+('bond_arp_validate', "arp_validate=%s"),
+('bond_ad_select', "ad_select=%s"),
+('bond_num_grat_arp', "num_grat_arp=%s"),
+('bond_downdelay', "downdelay=%s"),
+('bond_updelay', "updelay=%s"),
+('bond_lacp_rate', "lacp_rate=%s"),
+('bond_fail_over_mac', "fail_over_mac=%s"),
+('bond_primary', "primary=%s"),
+('bond_primary_reselect', "primary_reselect=%s"),
])
bridge_opts_keys = tuple([
___
Mailing list: https://launchpad.net/~cloud-init-dev
Post to : cloud-init-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~cloud-init-dev
More help : https://help.launchpad.net/ListHelp
