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