[00:42] <hazmat> adam_g, hmm
[00:43] <hazmat> it looks like the apiclient barfs and then the worker restarts it
[00:43] <hazmat> rogpeppe any insight on https://launchpad.net/bugs/1219116
[00:43] <_mup_> Bug #1219116: juju-deployer fails against juju-core: dial tcp 127.0.0.1:17070: connection refused <juju-core:New> <https://launchpad.net/bugs/1219116>
[00:44] <hazmat> adam_g, the issue looks like its internal to juju-core
[00:44] <adam_g> hazmat, yeah..
[00:48] <adam_g> i retry
[00:48] <adam_g> er
[00:48] <adam_g> i have it retrying on failure, looks like when api goes down its down for a while
[05:42] <clong> Hi Juju people
[05:44] <clong> I have a question about MAAS & Juju on ubuntu 13.0.4 vs 12.0.4. Which version of Ubuntu does it actually install on with the least amount of issues?
[05:46] <sarnold> clong: I'd expect 12.04 LTS to have better success, as it is more commonly used in deployments.
[05:50] <clong> Yeh I think I might try that today.
[05:51] <clong> I've got 31 nodes on my 13.0.4 MAAS server. I'll delete a few off that and try setting up a 12.0.4 server I think.
[05:52] <clong> sarnold have you ever set up maas and juju?
[05:53] <sarnold> clong: I've never done maas before
[05:53] <sarnold> clong: one of the downsides of 13.04 is that there are probably fewer juju charms available
[05:55] <clong> sarnold, thats correct for the juju nodes rolled out as 13.0.4 but the server doesn't discriminate if you're rolling out 12.0.4 from a 13.0.4 server
[05:56] <sarnold> clong: oh cool :)
[05:57] <sarnold> I guess that's only to be expected, but I haven't tried myself.
[05:58] <clong> well time to experiment again today I spose :)
[05:59] <sarnold> cool :)
[10:48] <clong> Hi all. I'm new to this chan and just back into irc after a 15 year break. Hi
[10:48] <clong> I'm currently commissioning a 32 node blade with maas and juju and having a few issues that I'm slowly working through and bit by bit I'm progressing.
[10:48] <clong> I'm hoping that there might be a few on here who had already successfully deployed a similar solution that would be able to help answer questions with facts and not just opinions.
[10:53] <lifeless> clong: they may, but you'll have to ask a question first :)
[11:55] <clong> what is the difference maas vs local juju environment
[12:08] <marcoceppi> clong: so MaaS is metal as a service. In the case of Juju, you're using MaaS as your cloud provider, deploying on either bare metal or vMAAS (virtualized servers, kvm, xen, etc, driven by maas)
[12:08] <marcoceppi> local provider will create a "cloud" environment on your machine (if it's Ubuntu) using LXC
[12:09] <marcoceppi> clong: local is designed to be a way to test charms without having to pay for a cloud service, it works reasonably well but without a lot of extra fidiling it's really limited, accessiblitywise, to your host machine
[12:09] <marcoceppi> clong: welcome back to irc o/
[12:10] <marcoceppi> clong: typically the room is "busier" during US business hours/business days. So if you don't get your question answered feel free to post it on http://askubuntu.com using the "juju" tag or mail the list at juju@lists.ubuntu.com
[12:11] <clong> so I could install juju-gui in the local env but it would not allow me to deploy charms to my maas nodes?
[12:12] <marcoceppi> clong: right, the juju-gui only interacts with the currently deployed env. So if you deploy juju-gui to local juju environment, you can then deploy and manage services (in addition to the cli) using juju gui for _that_ local environment. If you juju deploy juju-gui to your MaaS environment, you can use that instance of the juju-gui to drive your maas environment
[12:12] <clong> I'm more likely on irc during my evening/night/early morning australia time (US day time) researching than I am otherwise :)
[12:12] <marcoceppi> clong: only interacts with your current environment, at this time*
[12:14] <clong> I thought so. So that's where I'm stuck.. I seem to be able to get the local env bootstrap working and deploying within the local env but my maas bootstrap is not completing correctly.
[12:14] <marcoceppi> clong: maas and juju still has a few friction points, I'd be happy to help where I can. First, what version of juju are you using?
[12:16] <marcoceppi> clong: either `juju version` or `juju --version`
[12:16] <clong> When I juju bootstrap -e maas, my node is "deployed" and installs a new instance of linux. that node reboots on completion of install and seems to run the juju bootstrap script but the it fails to connect to server.
[12:17] <clong> juju version 1.13.2-raring-amd64 and maas version 1.4.5
[12:17] <marcoceppi> clong: Okay, cool, so when you run juju status -e maas you don't get a response?
[12:18] <clong> it takes a while to get an errored response
[12:19] <marcoceppi> clong: can you run the rest of your commands going forward with the `-v` and `--debug` flags? This should give us enough information to potentially diagnose issues, so run juju status again with those flags and paste the results to paste.ubuntu.com
[12:20] <clong> I'll bootstrap my maas env now and post the responses if you like
[12:20] <marcoceppi> clong: yeah, use the above flags as well ^ that'd be great
[12:20] <clong> it's bare metal rather than vm so it'll be a little while. I'm running on a 32 node HP blade
[12:21] <marcoceppi> clong: no problem, I should be around most of the day, and I'm sure others will be around too
[12:22] <clong> would you like me to post all of the debug info or just the erros?
[12:23] <marcoceppi> clong: might as well just post it all, makes it easier to follow the output
[12:24] <marcoceppi> clong: as far as networking goes, when the bootstrap node comes up, are you able to access it directly from your host machine your'e running the juju commands from? Either via ping or ssh?
[12:24] <clong> yes. I can ssh into it from standard cli but not 'juju ssh'
[12:25] <marcoceppi> clong: right, gotchya.
[12:25] <marcoceppi> If you can't get juju status back without an error then most other juju commands will fail as they all do lookups against the bootstrap node first
[12:26] <clong> yep that's what I see
[12:26] <clong> here's my env for maas from the environment.yaml
[12:27] <clong>   maas:
[12:27] <clong>     type: maas
[12:27] <clong>     # Change this to where your MAAS server lives.  It must specify the base path.
[12:27] <clong>     maas-server: 'http://10.200.0.100/MAAS/'
[12:27] <clong>  maas-oauth: '[big long string]'
[12:27] <clong> admin-secret: 'nothing'
[12:27] <clong>     default-series: precise
[12:27] <clong>     #default-series: raring
[12:27] <clong>     authorized-keys-path: ~/.ssh/authorized_keys # or any file you want.
[12:27] <clong>     #authorized-keys-path: ~/.ssh/id_rsa.pub
[12:28] <clong> I'm not sure about the authorized-keys-path: , I've tried both of the above
[12:29] <marcoceppi> clong: if you can ssh directly to the node then the authorized-keys-path is set correctly
[12:30] <marcoceppi> clong: you can typically, at least for most other providers, omit it and it'll just used your id_rsa.pub file
[12:30] <clong> as I thougtht
[12:30]  * marcoceppi recommends a pastebin going forward, as the output for most of these commands will be more than one or two lines long, http://paste.ubuntu.com
[12:31] <clong> how does paste bin work?
[12:31] <marcoceppi> clong: you just copy and paste output in to it and it gives you back a link
[12:32] <clong> ah cool.
[12:32] <marcoceppi> there's also a command on ubuntu called `pastebinit` that you can install from the achives. So you can do things like `juju status -e maas -v --debug | pastebinit` or if you wanted to watch the output, `juju status -e maas -v --debug | tee status-output; cat status-output | pastebinit`
[12:33] <marcoceppi> if you're lazy like me and don't want to use  your mouse to copy and paste :)
[12:33] <clong> ok then... here's the initial bootstrap debug info: http://paste.ubuntu.com/6047680/
[12:34] <clong> cool. I'm a 9mnth linux vet so I'm loving the tips for lazy fingers
[12:35] <marcoceppi> clong: cool, looks sane so far. It's defaulting to 1.12.0 (latest stable release of juju-core) despite you using 1.13.2; there's a way to get the lastest tools but for the purposes of this initial bootstraping, 1.12.0 and 1.13.2 play together just fine
[12:36] <marcoceppi> davecheney: How did we get bootstrap to use the lastest tools and not just the lastest stable tools?
[12:36] <clong> ok. I've added all of the ppa's for stable, dev etc that's probably why the wierdness
[12:37] <marcoceppi> clong: so actually, this  whole tool fetching process is something outside the realm of ppas. There's a client tools (the ones in the ppa) then there are the server tools which are kept in a public bucket numbered by releases. The tools on the server are installed independantly from the client tools
[12:38] <marcoceppi> clong: in older releases of juju (juju < 1.0) all the tools were installed by ppas and packages, so if you had a long running deployment and deployed a new service, if there was a newer version of juju then that node would get it but none of the others would get the update. So it lead to some funkiness. This way the tools are cached on a per environment basis and can be upgraded all at once using a juju command
[12:41] <clong> sounds like a much better way to go. Almost googlesque but all good to me :)
[12:42] <clong> so are you one of the dev's too?
[12:44] <marcoceppi> clong: no, I'm not a dev working on the juju tool itself per se, I'm a charmer. Creating charms, reviewing submitted charms, building tools to make charming easier, etc
[12:44] <clong> I'm looking to start writing some charms for entermedia media asset manager (open-edit) once I get the env working
[12:44] <marcoceppi> clong: awesome, I'm a lot more helpful when it comes to charming :)
[12:46] <clong> that's cool.  I'm sort of a jack of all trades. I was an animator turned Windows sysadmin turned manager turned back to sysadmin/devops now but in linux land :)
[12:47] <marcoceppi> clong: very cool
[12:47] <clong> ahhh looks like the node is restarting to init the juju stuff
[12:48] <marcoceppi> clong: awesome, once it comes back up you can actually watch what it's doing by logging in to the node and tailing a file. So in order to set itself up juju uses cloud-init to drive the configuration of the machine
[12:48] <clong> unfortunately I can't copy and paste from the ilo window
[12:48] <marcoceppi> clong: so there's a file, I think it's in /var/log/cloud-init* which covers what's going on
[12:48] <marcoceppi> clong: that's fine, just for your reference, if you wanted to see where the process was
[12:50] <clong> is that on the node or the maas box. I can't see it on the maas server tho
[12:50] <marcoceppi> clong: it's going to be ont he bootstrap node that just rebooted
[12:52] <marcoceppi> clong: also, it's not a requirement, just spouting out information
[12:55] <clong> ok.. ^Croot@ce-maas:~/.juju# juju -v status --debug
[12:55] <clong> 2013-08-31 12:54:11 DEBUG juju.provider.maas environprovider.go:27 opening environment "maas".
[12:55] <clong> 2013-08-31 12:54:11 DEBUG juju state.go:158 waiting for DNS name(s) of state server instances [/MAAS/api/1.0/nodes/node-2a415564-05aa-11e3-9f95-0017a4770000/]
[12:55] <clong> 2013-08-31 12:54:11 INFO juju.state open.go:68 opening state; mongo addresses: ["cloud05b.cuttingedge.com.au:37017"]; entity ""
[12:55] <marcoceppi> clong: from your machine, can you resolve an IP address for cloud05b.cuttingedge.com.au ?
[12:56] <clong> I think the dns isn't doing it's thing properly cos I can't ping
[12:56] <clong> ping cloud05b.cuttingedge.com.au
[12:56] <clong> ping: unknown host cloud05b.cuttingedge.com.au
[12:56] <marcoceppi> clong: that's the problem!
[12:56] <marcoceppi> clong: Okay, so, maas has it's own DHCP and dns server
[12:56] <clong> it was working before I did the latest upgrade
[12:56] <clong> yep I know. I installed it all
[12:57] <marcoceppi> clong: you might be able to fudge your system settings to include the MAAS dns server in your lookups
[12:57] <marcoceppi> which would allow you to query the IP addresses for it
[12:57] <clong> so I wonder why it's not working
[12:57] <marcoceppi> clong: try to dig @10.200.0.100 cloud05b.cuttingedge.com.au
[12:57] <marcoceppi> clong: try to `dig @10.200.0.100 cloud05b.cuttingedge.com.au`
[12:57] <marcoceppi> do you get an IP?
[12:58] <clong> lxcbr0 is up. I think that might be overiding it
[12:58] <marcoceppi> clong: local provider usually runs on 10.0.3.0 ip span, but it's possible
[13:00] <clong> yeh. i'd previously setup a range starting @ 10.200.1.1 and it was working nicely till i install lxc
[13:00] <marcoceppi> clong: gotchya, is the local provider still bootstraped? Did the above dig command work?
[13:00] <clong> I destroyed the local environment too which I would have thought would have killed lxc
[13:01] <clong> sry I missed the dig command.. yep it worked. I've found the address now
[13:02] <marcoceppi> clong: you can get around this by editing /etc/resolv.conf on your local machine and adding nameserver 10.200.0.100 to the top of the file
[13:02] <marcoceppi> that should add the maas server as a lookup
[13:02] <clong> it's given cloud05b the cname 10-200-1-12.cuttingedge.com.au
[13:03] <clong> that is the only entry in my resolv.conf
[13:03] <clong> wierd
[13:03] <marcoceppi> hum, interesting
[13:04] <marcoceppi> it sounds like you've got juju setup correctly, since you're able to boostrap and get a machine running, it's just a matter of working out the DNS resolution
[13:04] <marcoceppi> Most people don't use a domain for their maas server, it's typically something.local or something.ext so they can properly route their local traffic for that TLD to the maas server
[13:04] <marcoceppi> afaik
[13:05] <clong> I'm using our fqdn
[13:06] <marcoceppi> clong: right, this is the part where I start to get hazy on what to do next
[13:06] <marcoceppi> I've not had to resolve this specific issue, but the problem you're seeing is juju has the MAAS domain for it's record, and it cant' resolve that to an actual machine
[13:07] <clong> it's for some reason using hypenated ip's as the hostname in the dhcp/dns. The  hostname of the prepared node is correct funilly enough when I'm logged into it
[13:08] <marcoceppi> clong: so if  you do a dig for 10-200-1-12.cuttingedge.com.au you should see it resolves to 10.200.1.12 and the hostname of the node is either going to be 10-200-1-12 or cloud05b, I forget which one maas uses
[13:09] <clong> I'm wondering ifit's got something to do with the dhcp or dns preprepping hostnames. I noticed in on of the conf files the other week that this seemed to be the case
[13:10] <marcoceppi> clong: I was going to say you might get some help in #maas, but I think it's the same thing. They're mostly US timezones and work days
[13:10] <clong> heres the dig: http://pastebin.ubuntu.com/6047772/
[13:11] <marcoceppi> clong: and if you do a dig without the @10.200.0.100 ?
[13:13] <clong> it's trying to resolve it from the dns server that I specified the maas server to use
[13:13] <clong> http://pastebin.ubuntu.com/6047778/
[13:14] <clong> therefore getting nothing back
[13:15] <marcoceppi> clong: are you on the maas master right now?
[13:15] <clong> yep
[13:16] <marcoceppi> clong: hum, I wonder if that's why it's acting weird. You don't technically need to run juju from the maas master, if you were under that impression
[13:17] <clong> I want to so I'm not burning my nodes. I've got to build a pretty decent render farm out of it
[13:17] <clong> every node counts in render land
[13:18] <marcoceppi> clong: I meant you can run it from a desktop, if you're using an ubuntu desktop, or a VM on a desktop. It's not restricted to the environment directly
[13:19] <clong> oh ok. I think I get what you mean. In this instance it's just more convenient having it consolidated with the maas server
[13:20] <marcoceppi> clong: regardless, I'm at a loss for how to get this dns to resolve properly
[13:20] <marcoceppi> clong: right, so in the future you can just copy your environments.yaml and ssh keys to another machine and you should just be able to run juju status and get it to work, as an FYI
[13:22] <clong> I'm just looking at the dhcp and dns stuff at the moment. To see if I can see how to resolf that stuff. It makes sense that if I can't see cloud05b from the maas cli and juju is looking for the hostname rather than the ip address that by fixing that issue it should fix the juju issue.
[13:22] <clong> thats cool to know
[13:22] <marcoceppi> clong: right, otherwise you've got juju and maas all set up from what I can tell
[13:23] <clong> yep.. I've definately advanced alot in that last 2 days.. Finding the info on launch pad was a good thing and getting on here too.
[13:28] <marcoceppi> clong: oh, I had a better idea
[13:29] <marcoceppi> clong: actually, nevermind
[13:29] <marcoceppi> s/better/different
[13:29] <clong> maas-dns uses bind9 doesn't it>
[13:29] <marcoceppi> clong: pretty sure, yes
[13:30] <clong> whats your s/better/different idea?
[13:31] <marcoceppi> clong: I was going to say you can just add cloud05b...com.au to your /etc/hosts and map the IP manually, that will get you the juju commands working, but you won't be able to juju ssh to any other nodes as you'll need to add their information directly
[13:32] <clong> /etc/bind/maas/zone.cuttingedge.com.au has the whole ip range in there formated as 10-200-1-36 IN A 10.200.1.36
[13:32] <clong> etc
[13:34] <clong> I wonder if I deleted those that maas would re-enter them based on the node names specified in the maas gui
[13:35] <marcoceppi> clong: right, since you're using another DNS server to manage cuttingedge.com.au, I wonder if you created a subdomain for maas directly, (say, cloud.cuttingedige.com.au) and had that DNS server 10.110.1.10 delegate NS to 10.200.0.100 if that would fix the loop. You'd need to re-configure maas to use <machine>.cloud...com.au but it might be a way to fix this DNS lookup issue
[13:36] <clong> or at least I could change the 10.200.1.12 to be cloud05b in this instance and set the dhcp lease to never expire for each node as they come up
[13:37] <marcoceppi> clong: that's another way, you'd have to edit the dhcp stuff, but it's a possibility. negronjl was telling me about how dhcp leases should expire with MaaS setups, but I can't remember why he was suggesting that
[13:39] <clong> probably on the vm side where the mac addresses would be dynamic but bare metal should be fine
[13:40] <marcoceppi> clong: there was something else about it, he does a lot of Juju + MAAS to deploy OpenStack, so it might have been specific to that
[13:41] <clong> which is what I want to do so I should probably listen to that advise
[13:42] <marcoceppi> clong: heh, I know it's a weekend, but we've got a few people around here who have done the MAAS + Juju for OpenStack deployment, they're just probably out enjoying the weekend :) It's something that's been on my todo list for a while just haven't found the time to sit down and set up maas
[13:42] <clong> Hmm how so set up my windows dns to delegate ns to 10.200.0.100 .... I haven't done that in a very very long time.. need to crack open prof google
[13:43] <clong> I always like to throw myself into the deepend
[13:43] <marcoceppi> Sink or swim! :)
[13:45] <clong> I'd never configured a hp blade before a week ago either.. that was fun, then getting ipmi to work with maas, that was even more fun.. Then juju and now back to the dns stuff. Today is the first time I've felt I've had to ask for help. I appreciate it
[13:46] <clong> Yeh, I think I do have to setup this subdomain. God I hate windows dns
[13:47] <marcoceppi> clong: fwiw, you seem to have gotten maas and juju cobbled together pretty well, so kudos to that (since I know our official maas + juju docs are a bit lacking)
[13:50] <clong> yeh, they're a few generations old. I think that's probably where I could contribute a little. I'm always writing up install notes in our internal wiki
[13:50] <clong> I'm a history hack and slasher :)
[13:51] <marcoceppi> clong: we just had a document sprint, so any feedback you have from your experience with maas + juju would be greatly appreciated!
[13:51] <clong> which group should I join to contribute to that in future?
[13:52] <clong> I'm a launchpad member already
[13:53] <marcoceppi> clong: The docs are in the bazaar branch lp:juju-core/docs; you don't need to join a group to contribute, but if you're interested in charming, ~charm-contributors is a group you could join
[13:54] <clong> cool. I'll definetly do that
[13:54] <marcoceppi> clong: I'd also join the juju mailing list, lots of conversations happen around there when irc is a quiet
[13:55] <marcoceppi> https://lists.ubuntu.com/mailman/listinfo/juju
[13:55] <clong> now I've just got to change my maas dns to be authoritative and change it to cloud.cuttingedge.com.au  so that my windows dns resolves it
[13:56] <clong> time to destory my bootstrapped env methinks
[14:00] <clong> well I've joined the  ~charm-contributors group just now
[14:01] <clong> hopefully tonight I'll get this dns issue sorted then everything else will flow on from that
[14:02] <marcoceppi> clong: I, personally, like to think charming is the real fun part. Though I may be a bit biased. We've got quite a bit of docs on how to deploy Openstack with Juju so that process should be pretty smooth
[14:02] <clong> this is where i work btw: www.cuttingedge.com.au
[14:03] <clong> I'm all for getting into the charming since we're using puppet at work at the moment
[14:05] <marcoceppi> clong: while we don't have any good examples of puppet, you can probably use quite a few of your puppet scripts to drive any charms you create. We have an example of a charm using chef scripts to help drive configuration, just not one with puppet that I know of yet
[14:05] <marcoceppi> So there at least won't be too much duplicated/lost effort when you start getting in to charms
[14:06] <clong> I'm going to be using chef too with openstack, or do the charms sort of make chef and puppet redundant?
[14:07] <marcoceppi> clong: so the whole point of the charms is to describe, in whatever language you like, how to setup a service. So most of what you get with configuration management tools is handled by charms. Charms just also expose the additional service orchestration layer that you don't nessisarily get with chef and puppet. As a result, since charms can be written in any lanuage you want, if you want to use chef or puppet scripts to drive the
[14:07] <marcoceppi> configuration of a service and just link them with the orchestration bits that juju provides, you can do so
[14:08] <marcoceppi> charms are designed to be super flexible
[14:08] <marcoceppi> how to setup a service, and how that service talks to other services (eg charms)*
[14:09] <marcoceppi> The whole chef and puppet in charms is a bit more advanced, and might not make it in to your first few cuts of charms, but it's definitely an available option
[14:10] <clong> yep, I see I have alot to learn :) I'm on the bottom rung of the ladder :)
[14:10] <marcoceppi> The important takeaway, really, is charms do whatever you want them to
[14:11] <clong> cool. Could be good for some of our production packages such as houdini, maya, vray etc
[14:13] <clong> hey is this you? http://www.youtube.com/watch?v=OCnBy1I-IZs
[14:14] <marcoceppi> clong: heh, yeah, that's an older video of me
[14:14] <clong> yep, you are way way more advanced than I. I'm an old dog learning new tricks
[14:15] <clong> this is me: http://www.linkedin.com/profile/view?id=49733998
[14:19] <marcoceppi> clong: sweet
[14:21] <clong> Yep. I think that getting my head into juju and charms and cloud is the best thing I could be doing right now. I can see that we'll be using them alot more in our business.
[14:21] <marcoceppi> clong: awesome, we'll we're happy to help when we can!
[14:24] <clong> Thanks marco... I'm going to attempt to fix this dns setup now. I'll let you know how I go.
[14:24] <marcoceppi> clong: cool, good luck!
[14:25] <clong> thanks
[14:51] <marcoceppi> evilnick: https://code.launchpad.net/~marcoceppi/juju-core/lang-yaml-pretty-print-fixes-for-nick-lessthan-3/+merge/183327
[14:54] <jcastro> clong: man that sounds awesome!
[20:24] <jackweirdy> Hey all - I'm planning on entering an LDAP charm for the championships, and I'm finding most of what I'm doing is templating stuff. Can't find anything in the docs about this - is there a "Right Place (TM)" to store config file templates? or should I just make a top level directory in the charm for them?
[20:33] <marcoceppi> jackweirdy: top level directory, just call it templates or something aptly :)
[20:33] <jackweirdy> cool, thanks :)
[23:28] <clong> hi guy's. I was wondering if anyone could tell me if I, in a maas+juju setup, can use the juju machine 0 as anything other than the bootstrap machine ie. can i " juju deploy --to 0 juju-gui" without any detrimental consequences?