[01:24] <smoser> blackboxsw: on its up
[01:24] <blackboxsw> thanks smoser for checking back in
[02:10] <smoser> blackboxsw: if you're bored
[02:10] <smoser>  https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/343575
[02:10] <blackboxsw> always bored
[02:10] <blackboxsw> looking now
[02:10] <blackboxsw> just pushed some changes to qa-scripts and was going to hit review queue now
[02:13] <blackboxsw> smoser: yeah I had just made the arbitrary decision that people probably wouldn't duplicate their specific commands.
[02:13] <blackboxsw> I'm +1 on the concept. looking over the changes and will land it if I don't have objections
[02:19] <smoser> blackboxsw: real world... i would not be surprised to see
[02:19] <smoser>  apt-get update
[02:19] <smoser>  apt-get install package1
[02:19] <smoser>  apt-add-repository
[02:19] <smoser>  apt-get update
[02:19] <blackboxsw> apt-get update
[02:19] <blackboxsw> :)
[02:19] <blackboxsw> yeah
[02:20] <smoser> or even just
[02:20] <smoser>  apt-get update
[02:20] <smoser>  echo sometimes that fails
[02:20] <smoser>  apt-get update
[02:20] <smoser> :)
[02:34] <blackboxsw> btw generally I'm kindof excited that schema warnings showed up somewhere in our consumers.
[02:35] <blackboxsw> 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] <blackboxsw> Bug #1764264
[02:35] <ubot5`> 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] <mgerdts> Is there any way to tell cloud-init to reconfigure networking on every boot?
[19:06] <rharper> mgerdts: hrm; I don't think so; not without clearing the instance-id
[19:10] <mgerdts> 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] <mgerdts> This puts a bit of a wrinkle in the plan to rely solely on cloud-init.
[19:11] <mgerdts> 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] <mgerdts> apply_network_config:
[19:14] <mgerdts> 645         if (self.datasource is not NULL_DATA_SOURCE and
[19:14] <mgerdts> 646                 not self.is_new_instance()):
[19:16] <rharper> yes
[19:17] <rharper> mgerdts: I think we would need some way to ask the ds if it wanted to do that
[19:17] <rharper> we already ask is_new_instance; we could add some other check
[19:18] <mgerdts> I'll code something up and shop it around for feedback.
[19:18] <rharper> sure
[19:22] <rharper> 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] <blackboxsw> 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] <mgerdts> 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] <blackboxsw> 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] <rharper> blackboxsw: but user-data can't update system config
[19:26] <mgerdts> 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] <rharper> 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] <blackboxsw> 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] <rharper> 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] <rharper> https://hackmd.io/M1Tae41PQBC7a9qMsurTJw
[19:27] <rharper> mgerdts: but a non-reboot would look like that
[19:27] <mgerdts> oh, nice
[19:27] <rharper> 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] <rharper> 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] <rharper> having to bounce the primary interface is more troublesome
[19:28] <rharper> there may be running services or other things
[19:31] <mgerdts> 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] <mgerdts> If you are going to break all of your network connections, taking a reboot may not be that bad.
[19:31] <rharper> right
[19:31] <rharper> but incremental changes like adding a route is easy to do, hard to say it won't have an impact
[19:32] <rharper> the rub comes with the OS level  networking service
[19:32] <mgerdts> "what could go wrong?"  :)
[19:32] <rharper> 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] <rharper> 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] <rharper> 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] <akik> hi. i'm experiencing strange network timeout problems running cloud-init on centos 7 on azure
[20:35] <akik> if i disable cloud-init from running, the network becomes responsive again
[20:43] <akik> it's maybe some kind of race between azure linux vm agent and cloud-init
[20:44] <akik> i've used Provisioning.UseCloudInit=y in /etc/waagent.conf
[20:55] <blackboxsw> 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] <blackboxsw> I just published the  18.2 release there 10 days ago
[20:57] <akik> blackboxsw: 18.2? i have cloud-init-0.7.9-9.el7.centos.6.x86_64 <- probably really old?
[20:59] <akik> it's installed from centos updates repo
[21:00] <blackboxsw> 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] <blackboxsw> 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] <akik> i'd like to use stable instead of testing
[21:02] <akik> as there are no instructions there. is it just installing one rpm package?
[21:02] <blackboxsw> +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] <blackboxsw> the cadence of those releases is about ~3 months
[21:03] <blackboxsw> 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] <akik> oh ok so i download that "repo download" ?
[21:03] <blackboxsw> akik: yeah it is just cloud-init
[21:04] <akik> thanks so much
[21:05] <akik> i'll try that el-testing first
[21:05] <blackboxsw> for sure, it'd give you an idea at least if it's something that's been fixed by more recent code
[21:07] <akik> i already made a support ticket to azure because i couldn't figure it out
[21:08] <akik> No package python-jsonschema available.
[21:10] <akik> ah maybe i don't have epel
[21:11] <blackboxsw> yep, need epel :0
[21:22] <akik> seems to have worked
[21:22] <akik> 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] <akik> thank you very much