[01:24] blackboxsw: on its up [01:24] thanks smoser for checking back in [02:10] blackboxsw: if you're bored [02:10] https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/343575 [02:10] always bored [02:10] looking now [02:10] just pushed some changes to qa-scripts and was going to hit review queue now [02:13] smoser: yeah I had just made the arbitrary decision that people probably wouldn't duplicate their specific commands. [02:13] I'm +1 on the concept. looking over the changes and will land it if I don't have objections [02:19] blackboxsw: real world... i would not be surprised to see [02:19] apt-get update [02:19] apt-get install package1 [02:19] apt-add-repository [02:19] apt-get update [02:19] apt-get update [02:19] :) [02:19] yeah [02:20] or even just [02:20] apt-get update [02:20] echo sometimes that fails [02:20] apt-get update [02:20] :) [02:34] btw generally I'm kindof excited that schema warnings showed up somewhere in our consumers. [02:35] even it if resulted in a bug in the schema being too strict. That's the kindof problem I'd like to have (albeit infrequently). Too strict vs too premissive. [02:35] Bug #1764264 [02:35] bug 1764264 in cloud-init "bionic cloud-init 18.2 WARNING Juju's 'runcmd' stanza" [Medium,In progress] https://launchpad.net/bugs/1764264 [19:04] Is there any way to tell cloud-init to reconfigure networking on every boot? [19:06] mgerdts: hrm; I don't think so; not without clearing the instance-id [19:10] I ask because as we transition from kvm to bhyve we have been planning to use cloud-init for network configuration on all platforms. Previously, those that didn't use cloud-init would rely on a dhcp server that is built-in to qemu. This means that network config would get refreshed on every reboot (at least). [19:11] This puts a bit of a wrinkle in the plan to rely solely on cloud-init. [19:11] Is this something that would be hard to make into a tunable, presumably able to be overridden by user-data? [19:12] * blackboxsw looks too. hrm. [19:14] apply_network_config: [19:14] 645 if (self.datasource is not NULL_DATA_SOURCE and [19:14] 646 not self.is_new_instance()): [19:16] yes [19:17] mgerdts: I think we would need some way to ask the ds if it wanted to do that [19:17] we already ask is_new_instance; we could add some other check [19:18] I'll code something up and shop it around for feedback. [19:18] sure [19:22] mgerdts: I don't think we have a user-data level way to toggle that; is it something the users could set such that the instance metadata would show that value? that would avoid having to create a user-data namespace for this setting; but leave control over whether network config is apply every boot or per-instance as something controllable but not seen outside of the SmartOS datasource [19:24] yea, was coming to the same conclusion. We currently surface network: config: disabled in /etc/cloud/cloud.cfg or /etc/cloud/cloud.cfg.d files [19:24] It could be created as a property in customer_metadata, which would make it a peer to user-data or put it into the sdc: namespace. I need to discuss internally how we should handle this. [19:24] and we check that in cloudinit/net/__init__.py:is_disabled_cfg(). ... would something like that be an option for setting 'autorenew' or 'update-per-boot'? [19:25] blackboxsw: but user-data can't update system config [19:26] That brings up another question I fielded recently. I was asked if my cloud-init work would make it so that networking could automatically reconfigure without taking a reboot. [19:26] so, I think it would better be a metadata value that the Datasource can reason able, but requires cloud support to allow users to toggle the setting [19:26] rharper: right I'm wondering if system config update is an option (i.e. we surface a system_config knob that can be twiddled) [19:26] mgerdts: we want to get there, I shared with you that doc that discussed a cloud-init refresh-metadata and cloud-init update-config --mode=network [19:27] https://hackmd.io/M1Tae41PQBC7a9qMsurTJw [19:27] mgerdts: but a non-reboot would look like that [19:27] oh, nice [19:27] there are some challenges w.r.t live update of networking; some things are easy, some things can leave you without connectivity if they fail [19:28] but generally things like, adding a ip, adding a new interface, etc applying new config to unconfigured interfaces; that's doable without anything fancy [19:28] having to bounce the primary interface is more troublesome [19:28] there may be running services or other things [19:31] I think the question I had was more specifically about routes. Like you say, monkeying with live interfaces can be problematic. By default, we have anti-spoofing enabled which further complicates live changes. Right now, an IP change that takes effect on a reboot doesn't have any complicated synchronization issues between host and guest. [19:31] If you are going to break all of your network connections, taking a reboot may not be that bad. [19:31] right [19:31] but incremental changes like adding a route is easy to do, hard to say it won't have an impact [19:32] the rub comes with the OS level networking service [19:32] "what could go wrong?" :) [19:32] for 16.04, ifupdown requires a bounce, 18.04 with networkd, it's possible to "append" new config; though networkd is fickle enough that it woudl need some testing to ensure it behave sanely [19:33] if we didn't rely on the OS, but had cloud-init do it itself, then it's more likely we could pick out the "new" config and apply just that (via iproute2 ) [19:33] though, generally we'd prefer to push that sort of functionality into the OS level network tool; there are other users who may want to incrementally apply config outside of clouds [20:35] hi. i'm experiencing strange network timeout problems running cloud-init on centos 7 on azure [20:35] if i disable cloud-init from running, the network becomes responsive again [20:43] it's maybe some kind of race between azure linux vm agent and cloud-init [20:44] i've used Provisioning.UseCloudInit=y in /etc/waagent.conf [20:55] akik: not sure, not seeing that on ubuntu azure. you could try pulling our latest cloud-init 18.2 from https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/ [20:56] I just published the 18.2 release there 10 days ago [20:57] blackboxsw: 18.2? i have cloud-init-0.7.9-9.el7.centos.6.x86_64 <- probably really old? [20:59] it's installed from centos updates repo [21:00] yeah it is a bit old, but not as old as the version numbers might imply. We switched cloud-init versioning scheme late in 2017. to YY.##. The distros/cloud images don't update as frequently as we release upstream cloud-init. https://lists.launchpad.net/cloud-init/msg00106.html [21:00] that message on our mailing list has the details of that versioning switch... looks like we made the move to year-based versioning September 2017 due to agreement at last year's cloud-init summit [21:01] i'd like to use stable instead of testing [21:02] as there are no instructions there. is it just installing one rpm package? [21:02] +1 akik, we will only update el-testing when cloud-init upstream releases a tested release. (like 18.1 18.2 18.3) [21:02] the cadence of those releases is about ~3 months [21:03] for those that live on the edge (and want to cope with occasional failures) we have a daily copr repo here https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/ [21:03] oh ok so i download that "repo download" ? [21:03] akik: yeah it is just cloud-init [21:04] thanks so much [21:05] i'll try that el-testing first [21:05] for sure, it'd give you an idea at least if it's something that's been fixed by more recent code [21:07] i already made a support ticket to azure because i couldn't figure it out [21:08] No package python-jsonschema available. [21:10] ah maybe i don't have epel [21:11] yep, need epel :0 [21:22] seems to have worked [21:22] i got this though "DataSourceAzure.py[WARNING]: Error communicating with Azure fabric; You may experience.connectivity issues." but some seconds later it ran the user-data i had supplied [21:24] thank you very much