=== rangerpbzzzz is now known as rangerpb === rangerpb is now known as rangerpbzzzz [14:23] bah [14:23] how do i un-delete https://trello.com/c/BDxqarbu [14:23] or un-archive [14:24] "send to board". obvious [14:24] http://help.trello.com/article/795-archiving-and-deleting-cards [15:41] smoser: after you update the bug for #1697545, let's talk about the open MPs on #169189 [15:41] #1691489 [15:42] k === rangerpb is now known as baude === baude is now known as rangerpb [16:34] smoser: let me know when you have a new test case for http://pad.lv/1687712, then we can wrap up SRU testing [16:34] Launchpad bug 1687712 in cloud-init "cc_disk_setup: fs_setup with cmd doesn't work" [Medium,Confirmed] [16:40] powersj, still working on it. :-( [16:41] ok [17:25] powersj, updated https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1687712 [17:25] Ubuntu bug 1687712 in cloud-init "cc_disk_setup: fs_setup with cmd doesn't work" [Medium,Confirmed] [17:26] smoser: thx! I'll give it a shot shortly === shardy is now known as shardy_afk === shardy_afk is now known as shardy [19:58] smoser 'cloud-init summit ' [19:58] woa [19:58] lol [19:58] *woah [20:01] the big time [20:04] smoser: still running into issues with your updated SRU template, mount -a fails due to wrong fs type, bad option, bad superblock on /dev/sdc1 [20:04] cloud config: https://paste.ubuntu.com/24958336/ [20:04] log: https://paste.ubuntu.com/24958331/ [20:04] woops wrong cloud-config, that's without cmd one sec [20:05] this one: https://paste.ubuntu.com/24958364/ [20:10] powersj, ok. so that i guess is expected. :-( [20:11] i was testing on openstack. [20:11] config preference goes [20:11] system (files in /etc/cloud) [20:11] datasource (DataSourceAzure 'BUILTIN_CLOUD_CONFIG') [20:11] user-data [20:12] you provided via 'system', which then got trumped in the fs_setup section the fs_setup section by azure. [20:12] ah [20:12] :-( [20:12] i think that you would get he desired behavior if you did it via user-data [20:13] (openstack datasource does not have provide fs_setup config) [20:13] hmm ok I know how to first launch an instance with a config, but not afterwards. Let me look around. [20:14] well, if you launch with the config [20:14] it will fail the first time [20:14] (thats the bug) [20:14] then you can [20:14] right [20:14] rm -Rf /var/lib/cloud /var/log/cloud-init* [20:14] and reboot [20:14] and it should dtrt [20:14] after enabling proposed? [20:14] (well, after upgrading [20:14] yeah) [20:14] ok [20:15] alright I'll go that route [20:15] I forget about the preferences hierarchy [20:15] well, azure is the only datasource that does that [20:15] =( [20:16] I fought that and lost [20:20] rharper, http://paste.ubuntu.com/24958427/ [20:21] that;s just renaming [20:21] since it runs at Local as well ? [20:21] i think thats probalby why your network config was running twice. i'd have to see a log. [20:21] only runs at local [20:21] oh [20:21] I didn't think we could do that [20:21] the big difference there is line 30 [20:21] I thought we always need to run at net time when attempting to consume metadata [20:23] smoser: I had a separate class with just enough to run local but the class gets picked after local, and when net ran, it didn't have the right class, so instead I changed the Net class to have network_config, and then let it run in both local and net; the assumption was that AzureNet could *not* run at local time (ie, it's metadata it reads may not be available if networking is *not* up, which is the case for init --lo [20:23] cal) [20:25] i'll poke some more [20:26] why did i not get any errors on that. [20:26] I don't no [20:26] I didn't get errors when Net didn't do anything [20:26] so, it's possible my assumption is not correct anymore [20:26] in which case, I'm all for running to completion (consuming metadata) at local time [20:29] well this is what i commented in the MP about [20:29] smoser: some quick reading that made me cautious (agent_command requiring bouncing network, get_metadata_from_fabric, which calls into WALA shim, [20:29] at least i ghoutht i did [20:29] reading the Shim object, it appears to do a dhcp and read data out of it [20:30] that implies some level of networking; I would then expect that in local mode we can write config, and then at init net; attempt to bring networking up and read the lease file, etc. [20:31] well, net doesn't bring up networking [20:31] its already up [20:31] right [20:31] the azure datasource is a mess in that it may actually *bounce* the interface [20:32] my comments last week and an inline comment in 'get_data' [20:32] sure; for this first round, I was hoping to change as little of the DS as possible to make things work; [20:32] i think youo've changed that a bunch now. but we'll have to do something like that i think [20:33] do something like what? [20:37] 2 options [20:38] either get_data handles doing a dhcp and then appropriate tear down [20:38] or get_data just does local things and 'activate' does the remainder [20:39] the second is less invasive at the moment [20:40] smoser: rharper: dpb1: SRU verification complete. [20:40] woohoo! [20:40] someone do a 21 gun salute [20:44] smoser: vs the partial get_data I have now ? [20:46] \o. [20:49] rharper, i'm looking at f31c8a02f75fcb1aeafe665dc6b240a0ff542a05 [20:49] is that right? [20:51] git top hash ? [20:52] yes [20:52] I've pushed two commits to fix up your items of spelling and such [20:52] " the partial get_data I have now" confused me. as i think get_data is most of everything [20:52] but otherwise that's the right hash [20:52] do you want to do a hangout ? [20:52] probably should