[14:21] <smoser> rharper, when you get a chance, i'd liek some thoughts on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/321218
[14:21] <rharper> y
[14:21] <smoser> paulmey, sorry for not coming back to you yesterday.
[14:22] <smoser> i kind of like cloud-init's paths better than walinux-agent
[14:22] <smoser> it seems better to me to namespace these under 'cloud', then populating/polluting the top level /dev/disks/ with somewhat arbitrary things.
[14:24] <smoser> i dont think that 'cloud' is the best thing, currently you have things like 'by-name', 'by-id', 'by-partuuid'.... it doesn't seem right to just start throwing in 'azure', 'aws', 'whizbang'
[14:24]  * smoser knows that paulmey is likely still sleeping.
[14:30] <rharper> smoser: replied;  I'm hoping to have both explicit config disable as well as sanity checks in the case config is provided but system can't handle it (no apt, system_is_snappy)
[14:30] <smoser> rharper, i dont wnat to do explicit disable if i can avoid it
[14:31] <rharper> why?
[14:31] <rharper> we clearly have it in many other modules
[14:31] <smoser> i'm not opposed to adding generic module disalbe/enable functionality, but i dont want to further polute the inconsistency.
[14:31] <smoser> that you pointed out
[14:31] <smoser> of how you'd do that.
[14:31] <rharper> can we agree on what that should look like and follow up with a cleanup ?
[14:32] <rharper> module_name: disabled
[14:32] <rharper> that matches network: disabled
[14:32] <rharper> among other checks for disabled;
[14:33] <smoser> well, i'd not put 'module_name' in the top level namespace
[14:33] <rharper> $module_name
[14:33] <smoser> right. but i dont want in top level config N more entries
[14:34] <rharper> I'm not following, if someone wants to configure a config module, it requires putting the module key in ?
[14:34] <smoser> many of which might conflict with the config entry they use.
[14:34] <smoser> i think you're suggesting:
[14:34] <smoser>  apt_configure: disable
[14:34] <smoser> while 'apt' is the top level key that the apt_configure reads.
[14:35] <smoser> others will also be inconsistent in that way. there is not a 1:1 mapping of module to config entry. maybe there shoudl be but there is not.
[14:35] <smoser> i think i'd rather do a top level:
[14:35] <smoser>  modules:
[14:35] <smoser>     apt_configure: disabled
[14:35] <smoser> but that is similar to what we have in the less useful
[14:36] <smoser>   cloud_init_modules: [migrator, ubuntu-init-switch, ...]
[14:36] <rharper> yes; I understand;
[14:37] <smoser> so there is more bikeshed then i'd care to rush into this fix that i'd hope to get in today
[14:38] <rharper> right; then let's take it as-is and we can tee up discussions around that;  I think we poked at a few things we could clean up; and I'd much prefer providing a blacklist of modules that shouldn't run which saves some execution time
[16:00] <smoser> rharper, i do think that if you specifically provide apt configuration, that it should fail horrifically or warn at very least . i'd rather fail.
[16:01] <smoser> ah. i see you responded there to that affect. thanks.
[16:01] <rharper> yep
[16:02] <rharper> smoser: I'm fine without explicit config disabled for now; and we'll tee up a discussion for later w.r.t how we can disable modules in a cleaner way that now
[19:39] <smoser> rharper, would you quicklyi read https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/321218
[19:39] <smoser> and i can pull that one.
[19:57] <rharper> k
[19:58] <smoser> i think we're probably just going to have to accept failure
[19:58] <smoser>  https://bugs.launchpad.net/nova/+bug/1674946
[19:58] <smoser> and spin just turn that into a warning :-(
[19:59] <rharper> bleh, one more type