| blargh | does cloud-init support including external files (e.g. to avoid storing ssh keys in user-data)? | 14:01 |
|---|---|---|
| smoser | blargh: yes | 14:50 |
| smoser | #include <url> | 14:50 |
| smoser | #include-once <url> | 14:50 |
| smoser | the latter form can be an expiring url it will only ever be read once. | 14:51 |
| blargh | smoser: thank you! | 14:52 |
| blackboxsw | rharper: smoser, thinking about Azure network_from_imds upgrade path. pre-upgrade deployments would have generated fallback config (with blacklisted mlx drivers). after upgrade azure could regen network on next boot and the network_config will have a delta from the original fallback_config versus config from imds_metadata. Do we want the upgraded instance to retain fallback_config? | 17:28 |
| rharper | blackboxsw: did you find that mlx interfaces are present in the metadata? I didn't think that they were | 17:29 |
| blackboxsw | basic use case (1 nic) we'd see no change in 50-cloud-init.yaml just that the file would have an updated timestamp. in 2nic instances though 50-cloud-init.yaml would contain definitions for both interfaces after upgrade | 17:30 |
| blackboxsw | rharper: nope that blacklist works fine. no mlx interfaces listed (but the cached network_metadata on the instance contains unused driver information (hv_netsvc). | 17:31 |
| blackboxsw | and mlx interfaces aren't present in metadata | 17:31 |
| rharper | right | 17:32 |
| blackboxsw | what differs is imds_metadata contains ip addrs etc which aren't present in the pickled DS config on disk. so I see a delta in that case. do we regen network in that case from known fallback config | 17:33 |
| rharper | so ignore the mlx bit; the scenario is bionic, upgrade, now a crawl of metadata could return an network_config with multiple nic configs; should running instances get this post upgrade? | 17:33 |
| blackboxsw | yeah exactly, that's a situation that could be a potential fail if they've already configured nic2 | 17:33 |
| rharper | I think yes since it's a "bug" that we don't handle dhcp on secondary nics; that's getting fixed; so on upgrade to imds rendered network config, we'd want to retain that ability | 17:33 |
| rharper | well, manual configuration override isn't something we support today AFAIK, the azure default is "dhcp" on all nics; one has to change stuff in the image to make that happen and keep it working (like turning off the hotplug hook script for eth1-9 etc) | 17:34 |
| blackboxsw | yeah that makes sense. ohh right, yeah per cpc image we were trying to support dhcp all nice | 17:42 |
| blackboxsw | ok, so the way I have things for azure is this: attempt to get imds_network_md if present, use it all and regen, if absent, use fallback non-mlx | 17:43 |
| smoser | so... its interesting. | 17:56 |
| smoser | rharper is implying that the "dhcp on all nics" that is present in official ubuntu images allows us to have more freedom with respect to taking on new behavior as long as that new behavior is similar to the old. | 17:57 |
| smoser | there are some issues with that though | 17:57 |
| smoser | a.) cloud-init and ubuntu do not make any requirements that they are running "officially provided cpc images" | 17:57 |
| smoser | so for sure people could be using cloud-init on ubuntu elsewhere and our changes in behavior could break them. | 17:58 |
| smoser | b.) users could very well have adjustted to the mechanisms that are in that image to configure networking and disabled them or learned to work with them. | 17:58 |
| smoser | since the new behavior would be different (not exactly the same) it could definitely break *those* users too | 17:58 |
| smoser | the absolute safest thing is: upgrade does not change behavior | 17:59 |
| smoser | er.... safest is: upgrade does not change behavior, and new instances of ubuntu release still behave as they always did. | 18:00 |
| smoser | second is: new instances can change behavior, upgrades do not | 18:00 |
| smoser | least "safe": upgrade or new instance get change in behavior, sorry user. | 18:01 |
| blackboxsw | in that case, the only way cloud-init can be certain it owned a fallback config generation would be to inspect ds.network_config for version:1 containing the 'params'->'driver' key present. | 18:02 |
| blackboxsw | because only then would cloud-init have owned the network configuration generated (as no users would have provided that unused params:driver key | 18:03 |
| blackboxsw | I might add a helper method DataSourceAzure._is_fallback_config we can chat about when we review the azure-cold-plug branc | 18:04 |
| blackboxsw | I might add a helper method DataSourceAzure._is_fallback_config we can chat about when we review the azure-cold-plug branch | 18:04 |
| blackboxsw | thanks | 18:04 |
| smoser | i'm not entirely opposed to saying that cloud-init takes over networking configuration on azure | 18:05 |
| smoser | i'm just saying that the arguments for "we can do that" were not sufficient | 18:06 |
| blackboxsw | no worries, just wanted to know if I should account for that behavior | 18:25 |
| blackboxsw | and I probably should. we could do what we have for openstack which would be to allow for someone to disable the network config option. | 18:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!