[01:19] mgagne, thank you. [01:19] prettier at http://paste.ubuntu.com/20390677/ [01:37] mgagne, it'd be nice if you could open a bug. [01:37] have a test case showing failure based on your json. [01:37] thank you. [01:37] here is test case http://paste.ubuntu.com/20392738/ [01:37] rharper, ^ . if you're sitting there doing nothing. [01:37] i suspect this is related to not using 'id' as name [01:37] i go now. [01:38] good night. [06:46] smoser: thx for confirming [06:47] (lock_passwd: False) === shardy is now known as shardy_mtg === shardy_mtg is now known as shardy [15:40] smoser, is there a good time to do a hangout today? or would Monday work better? [15:42] powersj, today is fine with me. what works for you? [15:43] anytime in the next hour, or after 1pm mountain [15:50] powersj, 5m ok ? [15:51] sure [16:00] powersj, https://hangouts.google.com/hangouts/_/canonical.com/hangout-smoser [16:13] powersj, so [16:13] https://gist.github.com/smoser/f112518132f2849443f8edfcf292c8ec [16:13] is some stuff i just had when i was doing some testing [16:13] it builds and hacks in the cloud-init into the container [16:21] powersj, http://download.cirros-cloud.net/daily/20150923/README-lxd.txt shows how youc anlaunch lxc with user-data [16:22] lxc launch xenial x2 --config=user.user-data=$(cat user-data)" [16:22] you can also use --config=user.data=- < foo [16:39] smoser: so I fixed the name attribute issue. Now it's getting a bit worst. [16:40] smoser: eth0 and eth1 are configured and enslaved to bond0 while eno1 and eno2 exist and should be used. === rtheis_ is now known as rtheis [17:00] hm... what did you change ? [17:03] http://paste.ubuntu.com/ [17:03] damn [17:03] should post first [17:03] http://paste.ubuntu.com/20475020/ [17:04] now I'm trying to up the bond and slaves aren't configured even if bond-master is configured properly. I see that slave interfaces have bond configuration too (bond-mode, bond-miimoo, etc.) [17:06] last time, I had to enslave manually even if I followed https://help.ubuntu.com/community/UbuntuBonding [17:07] will continue to debug and make sure it's not something on my side [17:20] also, auto bond0 is missing from generated config [17:20] that's why network failed to start [17:20] same for slaves interfaces [17:22] to summarize: cloud-init creates and tries to enslave eth0/eth1 while eno1 and eno2 exist (and are stil configured by cloud-init?), auto stanza is missing from bond0 and slave interfaces [18:07] Arg, brpm does a recursive rm of ~/rpmbuild. Bad build script! Bad! [18:56] larsks, wow. that is bad. [18:56] shame on harlowja_at_home [18:57] mgagne, i suspect that you didnt update the json completely. [18:58] update the json? [18:59] I'm not sure what you are referring to [18:59] so http://paste.ubuntu.com/20475020/ [19:00] i think you meant you updated the openstack to build and include 'name' [19:00] no [19:00] but could you post the complete json there ? [19:00] it is not part of the spec, not part of my implementation nor the upstream one [19:00] I posted it already yesterday [19:00] let me check [19:00] http://paste.openstack.org/show/539268/ [19:00] well what did you mean by http://paste.ubuntu.com/20475020/ [19:01] looks like 'name' is optional in links http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/helpers/openstack.py#L547 but later is mandatory: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/net/network_state.py#L284 [19:01] so I forced name to exist by using the id instead so I don't have to refactor network_state.py [19:04] right. but i suspect your force didnt' do it right. [19:04] so i wanted to see that 'forced' json with 'name' [19:04] don't change a thing, I will put the id anyway [19:05] and name isn't part of the spec so I won't add something that shouldn't exist in the first place [19:07] I think there is a wrong assumption here: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/net/network_state.py#L319 [19:07] or something needs to be translate before it comes here [19:08] bond_interfaces contains the link_id [19:09] and I think later it can't find the actual interface in the parsed interfaces [19:09] maybe because physical aren't renamed to eth0/eth1 properly earlier or something like that. [19:14] will try that render tool and see that happens [19:14] what* [19:18] mgagne, is 'id' going to be sane ? [19:18] should i i use it? [19:19] well, the question is: why bother with a name? [19:19] versus veth234234 that id gest for link veth [19:19] can't it be bond + auto_increment? [19:19] well, eys of course. [19:19] then default to that if name isn't provided. [19:20] but as stated, name will never be provided unless someone provide a change in the spec [19:20] but if the user provides networking information and says "this is what i want the bond link to be called". then its better to have it called that then creating one myself. [19:20] so we are adding dead code [19:20] I think we already talked about that [19:22] ok so I managed to make that render tool work [19:22] same behavior [19:23] http://paste.ubuntu.com/20492837/ [19:23] smoser: ok, I updated the JSON to the actual physical interface names (not the link ids) are in bond_links. it now works [19:24] so I think cloud-init doesn't translate the bond_links (link id) to physical name [19:25] smoser: with oeth1, you should see that 4 physical interfaces are configured. [19:25] http://paste.ubuntu.com/20493003/ [19:25] yea, that's exactly the problem [19:25] and auto stanza is missing [19:25] so network is never started properly [19:27] well, i'm not sure that is it [19:27] di dyou open a bug ? [19:27] not yet [19:28] will opennow [19:32] how can I link to a specific line of a specific review in LP/bazaar? [19:32] revision* [19:35] mgagne, i dont know. [19:35] ok, will link to latest for now [19:37] smoser: these are the changes I'm working on for moving to github: https://github.com/larsks/cloud-init/compare/feature/move-to-git [19:37] I haven't tackled the build scripts yet. [19:38] movign to git [19:38] not git hub [19:38] right? [19:38] Oh yeah? See, I though we were going to use the existing cloud-init/cloud-init repository on github. [19:38] No? [19:39] Just git on launchpad? That is also fine. I will just need to fix hacking.rst really; nothing else cares about where things are hosted. [19:43] here we go: https://bugs.launchpad.net/cloud-init/+bug/1605749 [20:03] smoser: well, I've updated the docs and put my changes on launchpad @ https://git.launchpad.net/~larsks/cloud-init/?h=feature/move-to-git... [20:04] larsks, ok. thank you. [20:04] ...but of course I can't propose them for merging against a bzr repository, and it doesn't look like LP allows diffing between arbitrary revisions. [20:10] larsks, thanks. [20:10] i can figure out how to diff two trees [20:10] I figured :) [20:11] * smoser googles :) [20:11] If you move the existing cloud-init repository into git, we could make this the first merge request... [20:12] yeah [20:38] larsks, still there ? [20:38] so your master is straight import ? [20:39] I think so. Does it look like not? [20:39] * larsks checks. Seems to be. [20:40] The last change in my master is "mcollective: add tests, cleanups and bug fix when no config in /etc." [20:40] just was checking. [20:41] how did you do export / import ? [20:43] Using git-bzr-remote... [20:44] Well, that's mostly just import. bzr->git. If I had to go the other way, I would probably just using 'bzr branch', and then generate and apply a patch or something. [20:45] no you're good. [20:45] harlowja_at_home, had done somethign and had to mess aroudn with some tags... [20:45] trying to find that [20:46] I've just updated the git.launchpad.net/~larsks/cloud-init with all the tags, in case those are useful. [20:48] he had done this [20:48] https://gist.github.com/harlowja/8bfe7e9a19214379684f [20:48] ok. let me see. [20:50] I'm not sure what's going on after line 30 with with the rebasing or with any of the tag deleting, but the basic bzr fast-export --plain | git fast-import looks fine. [20:51] Personally, I just ran 'git clone bzr::lp:cloud-init', and then pushed it wherever... [20:52] oh. [20:52] wow. git just has that. i didn't know that. [20:53] so if i do that, mine will differ on shas right ? [20:53] That should be substantially the same as the fast-export | import. [20:53] Actually, I think you should end up with the same shas. [20:54] yeah, i do [20:54] ok. i'm going to push this imported branch [20:54] larsks, thank you for your patience [20:54] fyi, Also 'git push --tags' [20:55] yeah. and i will first delete the ubuntu- tags [20:57] https://git.launchpad.net/~cloud-init-dev/cloud-init/ [20:57] \o/ [20:59] and updated https://code.launchpad.net/cloud-init [20:59] larsks, so you can submit yours as an MP now [21:01] Proposed. [21:03] larsks, link ? [21:03] Oh, sorry, I thought you'd get a notification of some sort. https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/300953 [21:03] well, i might ave. [21:04] now we see if CI continues to work... [21:04] powersj, whoops :) [21:04] I'm glad you did this to cloud-init first [21:05] larsks, thanks. i'm just about EOD also... so [21:05] Me too. [21:05] Gotta go perform child transportation, in fact. [21:05] harlowja_at_home, ^ larsks got done in like 3 days what you've been trying to do for like 2 years! [21:06] * smoser notes that what was actually accomplished was getting smoser to stop being lazy [21:06] thank you both. [21:06] Well, keeping in mind also that the build scripts are currently broken :) [21:07] Have to take off. See y'all on Monday.... [21:33] A bunch of CI jobs may launch in 3-4 mins. harlowja_at_home apparently wasn't allowed to launch ci jobs [21:33] I've added the cloud-init-bugcontrol and cloud-init-dev groups to the allowed users [23:02] smoser, So the branch name changed from lp:cloud-init to cloud-init:master (see last entry) if you look here: https://code.launchpad.net/cloud-init/+activereviews [23:03] The trigger job ain't happy with me just switching to the new name, so still investigating.