| smoser | blackboxsw: on its up | 01:24 |
|---|---|---|
| blackboxsw | thanks smoser for checking back in | 01:24 |
| 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:10 |
| 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:13 |
| 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:19 |
| 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:20 |
| blackboxsw | btw generally I'm kindof excited that schema warnings showed up somewhere in our consumers. | 02:34 |
| 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 | 02:35 |
| mgerdts | Is there any way to tell cloud-init to reconfigure networking on every boot? | 19:04 |
| rharper | mgerdts: hrm; I don't think so; not without clearing the instance-id | 19:06 |
| 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:10 |
| 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:11 |
| * blackboxsw looks too. hrm. | 19:12 | |
| 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:14 |
| rharper | yes | 19:16 |
| 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:17 |
| mgerdts | I'll code something up and shop it around for feedback. | 19:18 |
| rharper | sure | 19:18 |
| 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:22 |
| 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:24 |
| rharper | blackboxsw: but user-data can't update system config | 19:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:31 |
| 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:32 |
| 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 | 19:33 |
| 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:35 |
| akik | it's maybe some kind of race between azure linux vm agent and cloud-init | 20:43 |
| akik | i've used Provisioning.UseCloudInit=y in /etc/waagent.conf | 20:44 |
| 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:55 |
| blackboxsw | I just published the 18.2 release there 10 days ago | 20:56 |
| akik | blackboxsw: 18.2? i have cloud-init-0.7.9-9.el7.centos.6.x86_64 <- probably really old? | 20:57 |
| akik | it's installed from centos updates repo | 20:59 |
| 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:00 |
| akik | i'd like to use stable instead of testing | 21:01 |
| 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:02 |
| 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:03 |
| akik | thanks so much | 21:04 |
| 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:05 |
| akik | i already made a support ticket to azure because i couldn't figure it out | 21:07 |
| akik | No package python-jsonschema available. | 21:08 |
| akik | ah maybe i don't have epel | 21:10 |
| blackboxsw | yep, need epel :0 | 21:11 |
| 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:22 |
| akik | thank you very much | 21:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!