[01:43] <wallyworld_> bigjools: https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.3tn7jebub5jn5mhuh5sf8acd70
[09:01] <rogpeppe> mornin' all
[09:09] <dimitern> morning
[09:19]  * fwereade needs to go out for a bit and catch up with some lifey things that have taken a back seat this week
[09:19] <fwereade> bbl
[09:19]  * dimitern needs to dash to the post office - back in a bit
[09:52]  * dimitern is back
[10:47] <dimitern> TheMue, standup?
[11:14]  * dimitern lunch
[12:34]  * rogpeppe1 goes for lunch
[12:35] <rogpeppe1> i may be a little longer than usual
[12:54] <mattyw> fwereade, I've updated my latest owner-tag cl - when you have a moment could you take another look? https://codereview.appspot.com/14699043/
[13:35] <rogpeppe1> back
[13:38]  * TheMue fights with f*cking headaches today. :/ at least his tailer looks nice so far.
[13:57] <rogpeppe> fwereade: you might be interested to know that that environment in the recent thread in #juju was initially bootstrapped in May...
[14:09] <hazmat> is this a known issue.. WARNING no tools available, attempting to retrieve from https://streams.canonical.com/juju  ERROR cannot find bootstrap tools: XML syntax error on line 9: element <hr> closed by </body>
[14:10] <rogpeppe> hazmat: i believe it is
[14:11] <rogpeppe> hazmat: i think the issue is that we're trying to parse something as XML that isn't actually xml
[14:11] <rogpeppe> hazmat: but i don't know much more than that
[14:11] <rogpeppe> dimitern: what version do you think we should recommend that peter waller upgrade to (agents currently on 0.13.2)?
[14:12] <hazmat> rogpeppe, thanks, found the bug report
[14:12] <rogpeppe> dimitern: i'm thinking of seeing how it goes with 1.10, but i can't remember anything about the characteristics of any version
[14:12] <rogpeppe> hazmat: which bug?
[14:12] <hazmat> bug 1254401
[14:12] <_mup_> Bug #1254401: error reading from streams.canonical.com <bootstrap> <juju-core:Triaged> <https://launchpad.net/bugs/1254401>
[14:13] <rogpeppe> hazmat: ah looks like a) there are no tools there and b) we don't react well to the error it supplies in that case
[14:14] <rogpeppe> dimitern: i guess it must be better than 1.17!
[14:16] <hazmat> rogpeppe, re the guy on list..
[14:16] <hazmat> rogpeppe, so afaics. he just needs to upgrade --version=1.14
[14:16] <hazmat> ?
[14:16] <rogpeppe> hazmat: yeah, probably.
[14:16] <hazmat> er, 1.14.?
[14:16] <rogpeppe> hazmat: i was wondering whether 0.13->1.10->1.14 might be more likely to work
[14:17] <rogpeppe> hazmat: but i'll suggest 1.14.1
[14:20] <hazmat> why do we have terminate-machine when every else is labeled destroy-* ?
[14:21] <hazmat> nm.. i guess we have an alias
[14:23] <dimitern> rogpeppe, why not the latest trunk?
[14:24] <rogpeppe> dimitern: because i'm not sure that we should upgrade all that way in one step
[14:24] <dimitern> rogpeppe, then 0.14 first, then 0.16
[14:25] <rogpeppe> dimitern: yeah
[14:25] <rogpeppe> dimitern: when he verifies that his environment has come back up, i'll suggest that
[14:25] <dimitern> rogpeppe, while checking logs, etc. to make sure all hell did not break loose
[14:25] <rogpeppe> dimitern: yeah, i've been looking at his logs
[14:25] <rogpeppe> dimitern: the environment was bootstrapped in may...
[14:25] <rogpeppe> dimitern: which is kinda cool
[14:26] <dimitern> rogpeppe, wow!
[14:26] <dimitern> rogpeppe, and still working? :)
[14:26] <rogpeppe> dimitern: well, no, that's the point :-)
[14:26] <rogpeppe> dimitern: but was until recently
[14:27] <dimitern> rogpeppe, i see
[14:55] <hazmat> rogpeppe, btw do you still test/use juju with pre-release go versions?
[14:55] <rogpeppe> hazmat: yeah
[14:56] <rogpeppe> hazmat: currently i'm using go1.2rc2
[14:57] <hazmat> dimitern, there are numerous incompatible changes along the way to trunk in terms of tool discovery that the env agents loop on due to lack of finding on in my experience.
[14:57] <hazmat> i think we changed the look up like 3 times from 0.13 to 0.16
[14:58] <hazmat> maybe just twice.
[15:02] <dimitern> hazmat, yes, true
[15:03] <dimitern> hazmat, perhaps digging through the old release notes on the mailing list might provide some clues for possible issues that might happen between upgrades
[16:40] <rogpeppe> does anyone know where the downloads for any of the non-dev releases are? i'm looking at https://launchpad.net/juju-core/+download and i only see dev release downloads apart from 1.16
[16:40] <rogpeppe> i'm looking for 1.12 or 1.14 download
[16:41] <mgz> rogpeppe: I've always just grabbed 'em from s3
[16:41] <rogpeppe> mgz: is the juju client command there too?
[16:41] <mgz> ah, good point.
[16:49] <hatch> are there any juju builds which have a working manual provider?
[16:50] <rogpeppe> hmm, dammit
[17:07] <rogpeppe> can anyone verify if the download link on this page works for them? https://launchpad.net/juju-core/+milestone/1.10.0
[17:07] <rogpeppe> (the .tag.gz file)
[17:07] <rogpeppe> tar.gz
[17:07] <rogpeppe> i just get an empty file
[17:07] <rogpeppe> this is most frustrating
[17:08] <rogpeppe> surely we can resurrect *some* earlier juju client?
[17:08] <hatch> rogpeppe checking
[17:08] <hatch> yup there is stuff in it
[17:08] <hatch> want me to re-up it somewhere?
[17:09] <hatch> rogpeppe see pm
[18:34] <rogpeppe> right, i'm done for the day.
[18:34] <rogpeppe> happy weekends all
[19:21] <hazmat> rogpeppe, the only real archive is the various forms of stream data
[19:22] <hazmat> it would be so much easier if we could bypass all the simplestream cruft, and just give it a tools tarball
[19:25] <hazmat> filed bug 1256413 wrt
[19:25] <_mup_> Bug #1256413: provide an option when upgrading or bootstraping to bypass simplestreams cruft and just use a given tarball <juju-core:New> <https://launchpad.net/bugs/1256413>
[19:28] <hazmat> did someone wipe the old s3 bucket?


[10:53] <rburton> seb128: should g2 in ubuntu do the magic dont-focus-window tricks?
[10:54] <seb128> no
[10:54] <rburton> ok
[10:54] <seb128> they are working on it, the first changes to get it are in metacity 2.8.2 but that's not working yet
[10:55] <seb128> BTW morning rburton :)
[10:55] <rburton> morning!
[10:56] <seb128> mornign
[10:56] <seb128> oups, damnit
[10:56] <seb128> I hate the laptops
[10:56] <seb128> morning teuf
[10:56] <rburton> seb128: join the gang, get an x-series thinkpad
[10:56] <rburton> all the cool people have one
[10:56] <seb128> ah ah ah
[10:57] <seb128> I don't even have a laptop in fact
[10:57] <rburton> so what are you typing on?
[10:57] <seb128> I've borrowed this one from a friend for the meeting
[10:57] <rburton> ah
[10:57] <seb128> that's not mine
[10:58] <seb128> that's an old pII 366
[10:58] <rburton> ewww
[10:58] <seb128> But warty/GNOME2.7/evo1.5 run surprisly fine on it
[10:59] <rburton> warty is surprisingly fast
[10:59] <rburton> a lot faster than rh9+garnome on the same hardware
[11:11] <rburton> Oskuro: dude, stop slagging off our weather.  british weather is fun, it keeps you on your toes :)
[11:11] <rburton> today its.... raining!
[11:11] <rburton> next day.... heat wave!


[02:36] <oerheks> "sudo apt install snapd to install Snap support in Linux Mint, it’s easy” — but you’re a little bit wrong. Mint has disabled that." ... muhahahaha
[02:37] <oerheks> silly  /etc/apt/preferences.d/nosnap.pref
[06:29] <ducasse> good morning
[07:49] <lordievader> Good morning


[11:33] <Raboo> hi
[11:33] <Raboo> i'm having troubles with cloud init, it fails with my configuration
[11:34] <Raboo> i've created a file in /etc/cloud/cloud.cfg.d with following content http://pastebin.com/c4ZP1KA2
[11:34] <Raboo> I'm using the NoCloud datasource
[11:35] <Raboo> wondering if I have syntax errors or something..
[11:37] <Odd_Bloke> Raboo: One test would be to use a yaml library to inspect the content and see if it looks how you expect.
[11:38] <Raboo> Odd_Bloke ok
[11:39] <Raboo> yaml is valid
[11:40] <Raboo> cloud-init[1521]: Can not apply stage config, no datasource found! Likely bad things to come!
[11:42] <Odd_Bloke> Raboo: Is the yaml within user-data valid?
[11:42] <Odd_Bloke> Raboo: (It looks like you have a trailing space on everything after #cloud-config; don't know if that matters.)
[11:44] <Raboo> Odd_Bloke I think pastebin did that
[11:45] <Odd_Bloke> Raboo: So locally lines 8 and 9 have the same level of indentation?
[11:45] <Odd_Bloke> Because it looks like 5 spaces and 6 spaces in the paste.
[11:45] <Raboo> everything after user-data have 6 spaces or more if it have sub-config
[11:46] <Raboo> Odd_Bloke yes
[11:46] <Odd_Bloke> Fair enough.
[11:46] <Raboo> 8-9 have same indentation
[11:46]  * Odd_Bloke is out of ideas.
[11:46] <Raboo> 6 spaces
[11:46] <Odd_Bloke> I've never had cause to use the NoCloud datasource.
[11:46] <Odd_Bloke> Sorry I couldn't be more help. :(
[11:47] <Raboo> np, thanks anyway
[11:48] <Raboo> the thing is that i just put this file in /etc/cloud/cloud.cfg.d on the raw image
[11:48] <Raboo> don't know if it will work like that
[11:48] <Raboo> is user-data: supposed to have that pipe "|"?
[11:49] <Odd_Bloke> That's yaml for "treat lines below this as a single string".
[11:50] <Odd_Bloke> So I expect so.
[11:53] <Raboo> Odd_Bloke when does it end, when indentation becomes equal?
[11:57] <Odd_Bloke> Raboo: Not exactly sure, sorry.
[11:57] <Raboo> k
[12:33] <Raboo> how can i stop cloud init from trying to rename the interface?
[12:33] <Raboo> 2017-01-19 12:32:35,562 - stages.py[WARNING]: Failed to rename devices: [unknown] Error performing rename('enp5s0f0', 'bond0') for d8:d3:85:65:82:f4, bond0: Unexpected error while running command.
[12:33] <Raboo> Command: ['ip', 'link', 'set', 'enp5s0f0', 'name', 'bond0']
[12:34] <Raboo> how can i stop it to configure any networking?
[12:34] <Raboo> should i edit /etc/cloud/cloud.cfg or can i do it from user-data?
[13:06] <ffledgling> Raboo: from what I understand, you're missing the NoCloud data source
[13:07]  * ffledgling is still reading scrollback
[13:07] <ffledgling> Raboo: you need to create an .iso and mount it on the cd drive of your VM/Machine and that needs to have two files user-data and meta-data iirc
[13:08] <ffledgling> I don't recall having to edit cloud.cfg to use the NoCloud data source
[13:10] <ffledgling> Here's a makefile that I wrote a while back that (1) fires up a fedora 22 qcow2 image with qemu-kvm (2) Generates the cloud-init files (3) creates the .iso, mounts them correctly and configures the VM using cloud-init
[13:10] <ffledgling> https://gist.github.com/ffledgling/27460a617f0e9ef93afd847b6ef3c20a
[13:11] <Raboo> ffledgling im trying to do this on bare-metal
[13:11] <Raboo> so mounting an iso kind if defeats the automation
[13:12] <ffledgling> Raboo: what's your setup look like exactly?
[13:12] <Raboo> thats why i inject the config in /etc/clod/cloud.cfg.d
[13:12] <Raboo> ffledgling and i got around the problem of no datasources
[13:12] <Raboo> i simply split it to two files
[13:12] <ffledgling> oh?
[13:13] <Raboo> i put the datasource_list: [ NoCloud ] in a own file
[13:13] <Raboo> and a separate file with the datasource: stuff
[13:13] <ffledgling> ah
[13:13] <Raboo> now i believe that it dies when trying to rename the interfaces, which I don't want it to do
[13:14] <Raboo> ffledgling i'm redeploying the node now, give me 2 minutes.
[13:14] <Raboo> i removed the network setup now, so now when the node it shouldn't have a network setup, only a udev rule that runs dhcps on all interfaces i believe
[13:15] <Raboo> ffledgling what im doing is building a way to deploy ready raw images to bare metal nodes using theforeman
[13:15] <Raboo> so boot a minor image via pxe that partitions the hdd, then curl cloudimage.img | of=/dev/sdaX
[13:16] <Raboo> mount /dev/sdaX
[13:16] <Raboo> add cloud init config to /etc/cloud/cloud.cfg.d/
[13:16] <Raboo> (previously until 2 minutes ago also added network config to /etc/network/interfaces.d/)
[13:16] <Raboo> reboot
[13:17] <Raboo> cloud image boots, and should run cloud-init
[13:17] <ffledgling> Out of curiousity, any reason you wouldn't just do this with a salt/ansible playbook that runs at startup after the node boots up?
[13:18] <Raboo> ffledgling we do that aswell, run chef
[13:18] <Raboo> but preseed sucks and is slow
[13:18] <Raboo> and we already maintain cloud-init config for our virtual nodes, so why not deploy bare-metal nodes in the same way as virtual?
[13:19] <ffledgling> Hm, haven't heard of preseed
[13:19] <Raboo> bbl, gotta go and donate some blood
[13:19] <ffledgling> Yeah, that's fair, I just hadn't heard of many people using cloud-init for bare metal
[13:19] <Raboo> ffledgling you pxe boot physical nodes and use debian bootstrap with preseed files
[13:19] <Raboo> be back in 30
[13:20] <ffledgling> (y)
[14:37] <Raboo> hmm
[14:37] <Raboo> i'm back at no datasources found.
[14:38] <Raboo> but i do run echo 'datasource_list: [ NoCloud ]' > /etc/cloud/cloud.cfg.d/98_datasources.cfg
[14:38] <Raboo> do I need to run anything after i add that config for cloud-init to apply?
[14:39] <liqw> Raboo: sorry if i'm offtopic.. this https://maas.ubuntu.com/docs/development/preseeds.html (curtin) can provision bare-metal quicky with metadata similar to cloud-init (it's a part of ubuntu maas)
[14:42] <Raboo> liqw ok, i'm trying to avoid preseed
[14:42] <Raboo> i simply want to boot an image
[14:43] <Raboo> and have cloud init get it's configuration from the local disk
[14:43] <Raboo> not some remote data source
[14:43] <Raboo> just can
[14:43] <Raboo> just can't figure out how
[14:44] <liqw> on baremetal?
[14:46] <Raboo> liqw yes
[14:47] <Raboo> everything else in in place
[14:47] <Raboo> new machine boots for the first time
[14:48] <Raboo> boots into a tiny pxe image that writes the ubuntu cloud image to disk, adds my cloud-init configs and reboots
[14:48] <Raboo> second boot, is the newly written cloud image and it runs cloud init since it's a "first boot"
[14:52] <Diranged> I'm a bit new to cloud-init.. im curious, can Cloud-init be configurd to call a final command in the event of any error code being generated by one of the runcmd sections, or any other failure?
[14:52] <Diranged> basically "look, the host didnt finish booting man… so lets call the amazon set-instance-status command and mark us as unhealthy"
[14:52] <liqw> Raboo: so no cdrom if i get it right?
[15:03] <Raboo> liqw no cdrom
[16:02] <Raboo> liqw ffledgling Odd_Bloke i found a way
[16:02] <Raboo> if i put my user-data and meta-data in /var/lib/cloud/seed/nocloud/
[16:02] <Raboo> it works.
[16:28] <smoser> http://paste.ubuntu.com/23828513/
[16:28] <smoser> for what its worth, Raboo ^ that works for me.
[16:31] <smoser> Raboo, and not shown there, but the hostname is set correctly as  'foo'
[18:53] <supernova> hello !
[19:18] <smoser> hey
[20:44] <paulmey> ola
[20:45] <paulmey> when I run make in one of the ubuntu/* branches, it complains about git describe returning a different version
[20:45] <paulmey> like this: git describe version (ubuntu/0.7.8-49-g9e904bb-0ubuntu1_16.04.4) differs from cloudinit.version (0.7.8)
[20:47] <paulmey> am I doing something wrong?
[20:49] <powersj> ah this is the whole tags not being checked in problem
[20:49] <powersj> well not problem, just have to do something and I don't remember what
[20:50] <paulmey> yeah it looks like tools/read-version doesn't expect the ubuntu/ to be in front of the tags...
[20:51] <magicalChicken> paulmey: you can just checkout from the tag you want
[20:52] <magicalChicken> something like 'git checkout 0.7.8' should handle it
[20:52] <magicalChicken> or rename the tag if you want the ubuntu/* ones
[20:52] <paulmey> I'm trying to build the xenial package
[20:52] <paulmey> (for example)
[20:52] <paulmey> so I do git checkout ubuntu/xenial
[20:52] <paulmey> and then run make
[22:35] <Raboo> smoser hmm, thanks, guess i had something wrong in my file
[23:13] <ranger81> What is the cloud-init command to read from a yml file and add users in ubuntu?
[23:13] <ranger81> In coreos - /bin/coreos-cloudinit —from-file
[23:13] <ranger81> In ubuntu cloud-init —f <filename> does not work