[01:11] <harlowja> https://github.com/harlowja/cloud-init/tree/0.7.x-fixed should be the repo we need resynced...
[01:11] <harlowja> with all the missing 0.7.x stuffs
[01:12] <harlowja> * https://github.com/stackforge/cloud-init/compare/0.7.x...harlowja:0.7.x-fixed
[11:11] <Odd_Bloke> smoser: It does look like update_hostname is doing the right thing.
[11:12] <Odd_Bloke> smoser: I think I was hitting the cloud-init/walinuxagent race before.
[13:30] <smoser> Odd_Bloke, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1444086 seems kind of serious.
[13:30] <smoser> is someone looking at that ? 
[13:41] <Odd_Bloke> smoser: I believe utlemming has been.
[14:45] <utlemming> smoser: yeah, I
[14:46] <utlemming> smoser: er, I'm looking at that
[15:37] <yaronr_> hi guys
[15:37] <yaronr_> trying to add a yum_repos in cloud-init. installation fails because repo returns 403
[15:37] <yaronr_> interestingly, installation of packages that come from other repos fail as well
[15:39] <ndonegan> It's going to be the server serving the repos that's returning 403
[15:41] <ndonegan> So most likely you're pointing at the wrong directories for the repos, or there's some user or ip restriction on the repos.
[15:59] <smoser> or, if the repos are on S3, then 404 are returned as 403
[15:59] <smoser> (S3 does do that. ie, they tell you "you can't see that file", rather than 'that file doesnt exist')
[15:59] <smoser> yaronr_, ^
[16:00] <yaronr_> hmm
[16:00] <yaronr_> baseurl: http://repos.mesosphere.io/el/7/noarch/RPMS/mesosphere-el-repo-7-1.noarch.rpm
[16:01] <yaronr_> works on my browser..
[17:51] <zer0c00l> howdy
[17:52] <smoser> hi.
[17:54] <kwaping> howdy
[17:54] <harlowja> kwaping hey, so i'm working with openstack-infra to get https://github.com/harlowja/cloud-init/tree/0.7.x-fixed pushed in to stackforge
[17:55] <kwaping> cool
[17:55] <harlowja> and nm, https://github.com/stackforge/cloud-init/tree/0.7.x is up to date now
[17:55] <harlowja> lol
[17:55] <harlowja> sooo ya, thats done :-P
[17:55] <kwaping> wooo
[17:55] <kwaping> new source of truth?
[17:56] <kwaping> so is the 0.7.x branch considered stable, and master is bleeding-edge?
[17:56] <harlowja> sure
[17:56] <harlowja> seems about right
[17:56] <kwaping> ha
[17:57] <kwaping> yeah, I like that scheme - was thinking about other options but that works for me
[17:58] <harlowja> ya, doesn't need to be perfect
[17:59] <kwaping> no, it needs to be perfect
[17:59] <kwaping> jk
[18:00] <harlowja> lol
[20:31] <vila> hi there !
[20:34] <vila> with a fresh vivid-server image and cloud-init 0.7.7 I end up with no ssh keys generated and suspicious messages in the console: https://pastebin.canonical.com/129649/
[20:39] <vila> does that ring a bell ? 
[20:49] <larsks> vila: that pastebin apparently requires on to log in to view?
[20:50] <vila> ha right, sorry, bad habbit
[20:51] <vila> http://paste.ubuntu.com/10828856/
[20:59] <larsks> It looks like there is no sshd-keygen service on vivid, at least.  
[20:59] <larsks> It looks like key generation happens as part of the openssh-server postinst script...which is a terrible idea, but there it is.
[21:18] <vila> larsks: you mean sshd-keygen exists somewhere else ?
[21:18] <vila> larsks: and openssh-server may need to be fixed for vivid ?
[21:23] <larsks> vila: so, I'm not super familiar with the ubuntu openssh packages. *I* would fix this by having the sshd systemd service unit run a key-generation script prior to starting sshd.
[21:23] <larsks> Someone more familiar with the ubuntu side of things can probably provide a better answer. 
[21:23] <vila> ack, thanks
[21:39] <vila> smoser, utlemming : any idea ?