[05:20] <keshava> $JUJU_HOME/bin/juju bootstrap -v --debug --upload-tools would return 2014-02-13 00:35:41 ERROR juju.cmd supercommand.go:294 failed to enable bootstrap storage: failed to create storage dir: exit status 255 (Permission denied (publickey,password).)
[05:21] <keshava> anyone knows reasons/solution for this ?
[05:24] <keshava> ERROR juju.cmd supercommand.go:294 failed to enable bootstrap storage: failed to create storage dir: exit status 255 (Permission denied (publickey,password).) - how to workaround this?
[05:29] <bradm> keshava: sounsd like you're using the wrong public key?
[06:42] <stub> Can anyone point me to a charm which streams data (in my case, a log file) to another service? netcat would work but doesn't have the security I'd want.
[06:42] <sarnold> stub: there are rsyslog charms
[06:43] <sarnold> stub: http://manage.jujucharms.com/charms/precise/rsyslog
[06:44] <stub> Ta.
[06:44]  * stub wonders about serializing his logs and using syslog as the transport
[09:03] <vila> marcoceppi: hi there, I'm trying to understand what https://pypi.python.org/pypi/amulet/1.2.1 is lp:amulet where there is no 1.2.1 tag, can you help ?
[10:12] <stub> Gah, I've got logging backwards
[10:13] <stub> My charm needs to 'require' syslog in order to emit log messages to a receiver that 'provides' syslog
[10:15] <stub> I think the rsyslog charm was written from the POV of syslog being a service, when I'm thinking of it as a protocol
[10:17] <stub> But I guess that way makes sense if we start running hooks in a better defined order, provider side hooks first
[11:30] <marcoceppi> vila: amulet is mirrored on launchpad, but hosted on github
[11:30] <marcoceppi> vila: https://github.com/marcoceppi/amulet/releases
[11:40] <vila> marcoceppi: but https://github.com/marcoceppi/amulet.git/ doesn't have the 1.2.1 tag either ... what am I doing wrong >-/
[11:40] <marcoceppi> vila: it's there, hard refresh?
[11:43] <vila> marcoceppi: that made it, glitch since yesterday evening I suppose... Anyway,
[11:43] <vila> marcoceppi: thsnks
[11:43] <marcoceppi> vila: np
[11:43] <vila> hehe, thanks (damn fingers)
[11:46] <vila> marcoceppi: I'm also trying to find where I can get an ubuntu packaged version for that, I'm using ppa:juju/devel but amulet is not there (and I need support for precise, saucy, trusty, /me sighs, life is complicated sometimes... ;)
[11:46] <marcoceppi> vila: tools are in juju:ppa/stable :)
[11:46] <marcoceppi> and it's built for precise, saucy and trusty
[11:46] <vila> \o/
[11:47] <vila> marcoceppi: can I mix ppa/stable with juju 1.17.2 ?
[11:47] <marcoceppi> vila: yes, so if you have devel ppa, you'll always get the lastest juju as juju 1.17.2 > 1.16.6
[11:48] <marcoceppi> but when the next stable release comes out, 1.18.0 it'll get installed over 1.17.2
[11:48] <marcoceppi> since we do devel and stable releases differently
[11:48] <marcoceppi> evens are stable, odds are devel
[11:48] <vila> marcoceppi: cool, thanks for the tip about juju/stable, I could find it on lp from lp:amulet :-/
[11:48] <marcoceppi> as such, having both ppa won't break anything
[11:48] <marcoceppi> vila: I'll update the project page, thanks for the feedback!
[11:48] <vila> marcoceppi: oh, ok, good to know (I hope I will remember that odd/even in this context...)
[12:00] <cargill> when joining the db-admin relation with postgres, the user does not get the right to create new databases?
[12:05] <marcoceppi> cargill: uh, the user /should/
[12:06] <cargill> when I do "SELECT rolcreatedb from pg_roles where rolname like 'db_admin%';", all are flase
[12:06] <cargill> *false
[12:07] <marcoceppi> cargill: give me a few mins to spin up the latest postgres charm and check
[12:08] <cargill> sure, mine says 'cs:precise/postgresql-61'
[12:08] <cargill> just in case it matters
[12:09] <marcoceppi> cargill: that appears to be the latest
[12:14] <cargill> ok, that's interesting, it might be the pg_hba.conf interaction with the local environment again, as trying to create it in psql works now
[12:16] <cargill> and he does have rolsuper, that should give the user right to do anything?
[12:23] <marcoceppi> cargill: yeah, db-admin gives you superuser permissions
[12:23] <marcoceppi> so you should be able to romp around and create a database, etc
[12:24] <cargill> marcoceppi: thanks, and sorry for the false alarm, it was caused by postgresql restoring my changes to pg_hba.conf after a while
[12:27] <cargill> if doing deployment from local: and I've fixed bugs in the charm, how do I get them to be picked up? do I have to update revision? just removing the service and redeploying it again still uses the old version and there is nothing in .juju/charmcache
[12:58] <marcoceppi> cargill: yeah, from local, run juju deploy -u --repository... local:...
[12:59] <marcoceppi> the -u will update the cache
[13:34] <rick_h_> marcoceppi: doc your way with working dual local lxc environments
[13:34] <marcoceppi> rick_h_: \o/
[13:35] <rick_h_> now that I've got this I want cross env relations :P
[13:38] <cargill> marcoceppi: so the proper way is changing the revision, thanks
[13:40] <marcoceppi> rick_h_: dont' we all :)
[14:44] <cargill> when generating default passwords, is there a way to communicate them to the user?
[15:00] <marcoceppi> cargill: no, we strongly recommend you not auto-generate passwords and have users set it via config.yaml
[15:01] <marcoceppi> cargill: you can juju-log it, or place it in a file on the server and tell the user to ssh + cat that file though, again not recommended
[15:01] <cargill> but what if they do not set it?
[15:02] <marcoceppi> cargill: you can have the config-changed hook exit 1, to alert the user of an error, or have it exit 0 while it waits for the user to change/set the password
[15:25] <jcastro_> marcoceppi, so at the sprint people were making fun of me because I had to keep blowing away .jenv files
[15:25] <jcastro_> http://joshstrobl.blogspot.com/2014/02/developing-ubuntu-juju-charm.html
[15:25] <jcastro_> I feel vindicated knowing I wasn't the only one with broken local provider
[15:26] <JoshStrobl> Thanks jcastro_, I'll go ahead and sign up in the juju mailing list and take part in the discussion!
[15:26] <marcoceppi> JoshStrobl: its not local either
[15:26] <marcoceppi> err jcastro_^
[15:26] <jcastro_> we should name this script thumper.sh: http://pastebin.com/UMeZdH0Y
[15:26] <marcoceppi> jcastro_: ha!
[15:26] <jcastro_> JoshStrobl, this is sweet feedback dude
[15:27] <marcoceppi> jcastro_: HOLY CRAP DUDE
[15:27] <lazyPower_> niceeee
[15:27] <JoshStrobl> jcastro_: Just figured I'd share my experience writing a charm =)
[15:27] <marcoceppi> jcastro_: please don't recommend that script
[15:27] <marcoceppi> jcastro_: great way to loose your entire environments.yaml
[15:27] <lazyPower_> its pretty destructive without any kind of warning
[15:27] <JoshStrobl> But yea, it was a bit of a pain setting up the environment, destroying it, etc.
[15:27] <JoshStrobl> marcoceppi and lazyPower_ that is the point
[15:28] <lazyPower> JoshStrobl: oh i'm aware of that, but some people just run scripts blindly
[15:28] <marcoceppi> JoshStrobl: some of us have more than one environment in environments.yaml :)
[15:28] <lazyPower> ^
[15:28] <JoshStrobl> I did it because whenever my charm failed to be installed properly and I went to kill the service, it would just put the state as "dying" the entire time, I couldn't kill it without destroying the environment.
[15:28] <jcastro_> my point was mostly "we suck at cleanup so badly someone had to write a script."
[15:28] <marcoceppi> jcastro_: yeah, I agree
[15:28] <jcastro_> lazyPower, actually, weren't you writing a "nuke it from orbit" plugin?
[15:28]  * marcoceppi makes a cleanup plugin
[15:28] <lazyPower> jcastro_: i dubbed it "The Atom Bomb"
[15:29] <timrc> Are there best practices for accessing private bzr branches from LP from a service node?  The most obvious strategy seems to be to create a bot user and copy around a private ssh key but that thought alone I suspect makes kittens cry
[15:29] <JoshStrobl> I couldn't even use destroy-machine because the charm was stuck as dying.
[15:29] <lazyPower> and yeah - Its still in my slack task listing
[15:29] <marcoceppi> JoshStrobl: there's a force flag for that
[15:29] <marcoceppi> JoshStrobl: juju terminate-machine --force #
[15:30] <JoshStrobl> marcoceppi: I'd trying that out, but thanks to you being so helpful (bad marcoceppi, bad!), my charm works.
[15:30] <JoshStrobl> So I'll need to intentionally break the charm to test if that works :P
[15:30] <JoshStrobl> marcoceppi and jcastro_ I'll update my blog with the update you provided, provide some warnings about the script, and join the juju mailing list. My fiancee and I are going to a dance however, so I'll be afk!
[15:31] <JoshStrobl> *with the update, as in the quickstart stuff.
[15:34] <marcoceppi> JoshStrobl[afk]: enjoy!
[15:39] <marcoceppi> jcastro_: here's pretty much all you need for a clean up: https://gist.github.com/marcoceppi/8977344
[15:40] <lazyPower> marcoceppi: not sure about recent revisions of juju as i haven't had any issues, but with 1.17.0 i had to nuke ~/.juju/$env in the case of local as well. just removing the .jenv wasn't enough.
[15:41] <marcoceppi> lazyPower: OHH, yeah, good point
[15:41] <marcoceppi> lazyPower: https://gist.github.com/marcoceppi/8977344
[15:41] <lazyPower> marcoceppi: and then there's the case where it wasn't destorying the lxc containers...
[15:41] <marcoceppi> lazyPower: well, that's been fixed in 1.17
[15:41] <lazyPower> you've basically just written the nuke plugin once you've done that. parse the env name out of the lxc-ls --fancy and bam.
[15:41] <lazyPower> yeah, i agree, its no longer really required.
[15:42] <lazyPower> someone was dilligent in getting that patched, and i send them all the <3 in the world for that.
[15:42] <marcoceppi> lazyPower: probably thumper, at least that's who I always blame the lxc stuff on ;)
[15:53] <marcoceppi> So, I'm about to make a juju-plugin plugin which downloads...plugins
[15:53] <marcoceppi> much like npm, but for juju, because that seems the sanest way to package plugins
[15:55] <lazyPower> +1
[15:56] <lazyPower> Are you going to be hosting the API that powers this?
[15:56] <lazyPower> or just parse launchpad data?
[15:56] <marcoceppi> lazyPower: free for all
[15:57] <marcoceppi> lazyPower: so you can host it on github, gist, lp, where ever
[15:57] <marcoceppi> lazyPower: hosted
[15:57] <lazyPower> brilliant
[15:57] <marcoceppi> open source, etc
[15:58] <marcoceppi> just going to have the plugin create a $JUJU_HOME/plugins directory, and have it added to the users path
[16:11] <jcastro_> marcoceppi, do you know if we still support firing off a specific AMI for the AWS provider?
[16:11] <jcastro_> we used to iirc.
[16:12] <marcoceppi> jcastro_: I don't think we've supported that since the goland rewrite, let me check the source doe
[16:12] <marcoceppi> code*
[16:21] <marcoceppi> jcastro_: so you /could/ if you created simplestream data and overwrote the canonical stream data
[16:21] <marcoceppi> then you could have it use another AMI
[16:21] <mbruzek> marcoceppi, Are the machine logs for hp cloud stored on my local machine?
[16:21] <marcoceppi> mbruzek: no, they're in the bootstrap node
[16:22] <marcoceppi> mbruzek: the only reason machine logs are stored on your machine is if you're using the local provider because your laptop/desktop becomes the bootstrap node
[16:22] <mbruzek> OK
[16:23] <mbruzek> all-machines.log?
[16:24] <tomixxx4> hi, when i try to deploy a service on a machine with "juju deploy mysql --to lxc:0" it says "container creation template for juju-machine-0-lxc-0 failed"
[16:24] <mbruzek> in /var/log/juju/ ?
[16:24] <tomixxx4> the output, of "juju status" in detail is: http://pastebin.ubuntu.com/6926247
[16:25] <jcastro_> marcoceppi, excellent
[16:26] <marcoceppi> jcastro_: haven't tested that, but it shoudl work
[16:26] <marcoceppi> tomixxx4: which provider?
[16:26] <jcastro_> ok so not impossible
[16:26] <marcoceppi> mbruzek: machine-# is where the machine logs are
[16:27] <marcoceppi> tomixxx4: nvm, I see you're on maas
[16:27] <tomixxx4> marcoceppi: what do you mean "which provider" please have a look at the output of "juju status":  http://pastebin.ubuntu.com/6926247
[16:27] <marcoceppi> tomixxx4: does this machine have outside network accecss?
[16:28] <marcoceppi> machine being cloud1.master
[16:28] <tomixxx4> marcoceppi: yes
[16:28] <marcoceppi> tomixxx4: well, the error states "failed to get https://cloud-images.ubuntu.com/query/precise/server/released-dl.current.txt"
[16:29] <tomixxx4> marcoceppi: that should be fixed with help from #maas because the nodes were able to resolve all packages while booting after i executed a bash script to do some NAT
[16:29] <marcoceppi> tomixxx4: so, ssh in to that machine and try to wget that URL
[16:29] <tomixxx4> so i should enter this command on the bootstrap node?
[16:29] <marcoceppi> tomixxx4: yup
[16:30] <tomixxx4> or any other url?
[16:30] <marcoceppi> tomixxx4: that cloud-images url
[16:32] <tomixxx4> it answers with "password:"
[16:32] <marcoceppi> tomixxx4: that's...what?
[16:33] <tomixxx4> i have to type this command on the console of the juju bootstrap node, right?
[16:33] <tomixxx4> so, i typed this command in and the response of the console is "Password: "
[16:33] <marcoceppi> tomixxx4: so, you should just be able to type juju ssh 0 from wherever you ran juju bootstrap
[16:33] <marcoceppi> that should SSH you into the node
[16:33] <marcoceppi> then you should just type `wget  https://cloud-images.ubuntu.com/query/precise/server/released-dl.current.txt`
[16:33] <tomixxx4> aha
[16:33] <tomixxx4> ok
[16:35] <tomixxx4> because i have the physcial node beside me, so i typed this command with node's keyboard ;)
[16:37] <marcoceppi> tomixxx4: right, and maas removes the passwords, so you can't just log in
[16:37] <tomixxx4> ok, i have tried ssh now it prints "thomas@cloud1.master's password: " on maas-server console
[16:37] <marcoceppi> tomixxx4: did you add your ssh key to maas?
[16:37] <tomixxx4> yes
[16:38] <tomixxx4> so i have to add sth to "ssh cloud1.master" ?
[16:38] <marcoceppi> tomixxx4: well `juju ssh 0` should try to ssh ubuntu@cloud1.master
[16:38] <marcoceppi> not sure why it says thomas@cloud1.master
[16:38] <tomixxx4> it says master because i use DNS resolving
[16:38] <tomixxx4> provided by maas server
[16:39] <marcoceppi> tomixxx4: not sure why it says thomas instead of ubuntu
[16:39] <tomixxx4> OK
[16:39] <marcoceppi> it should be using the ubuntu user to ssh you in when you run `juju ssh 0`, could you run `juju ssh --show-log --debug 0` ?
[16:39] <marcoceppi> and paste the output
[16:39] <tomixxx4> kk
[16:40] <tomixxx4> k, i tried "juju ssh 0" it says "permission denied (publickey, password)
[16:40] <marcoceppi> tomixxx4: yeah, so it doesn't have your ssh keys on there
[16:41] <tomixxx4> i have followed the installation guide... i have created an ssh key
[16:41] <tomixxx4> andd added with "+ add ssh key" to preferences of root
[16:41] <marcoceppi> tomixxx4: can you run `ssh -vvv ubuntu@cloud1.master` and pastebin the output
[16:42] <marcoceppi> tomixxx4: and the ssh key is on the machine you're running the juju command from, correct?
[16:42] <tomixxx4> yes, its on the maas-server-node
[16:42] <marcoceppi> tomixxx4: cool, so you're running these commands from the maas-master
[16:43] <tomixxx4> yes
[16:43] <tomixxx4> output: http://pastebin.ubuntu.com/6926349
[16:44] <tomixxx4> oh
[16:44] <tomixxx4> this id_rsa.pub... is this the ssh key which should come into maas-dashboard?
[16:45] <tomixxx4> because i have another ssh key created some time ago, and its file name is different and its location too...
[16:45] <marcoceppi> tomixxx4: so, yeah, the ssh id_rsa.pub file that's on this machine in the thomas user should be the one in the dashboard
[16:46] <tomixxx4> ok, s***
[16:46] <marcoceppi> add it, juju destroy-environment maas, rebootstrap, then try to deploy --to lxc:0 again
[16:46] <marcoceppi> tomixxx4: if it fails, again, then do the ssh and check to make sure you can get that url
[16:46] <tomixxx4> ok
[16:46] <marcoceppi> tomixxx4: no worries man! you would have hit this issue sooner or later ;)
[16:48] <tomixxx4> iam such an idiot, if this is the cause of the issue, i have wasted lots of hours. xP
[16:48] <tomixxx4> but Thank You so far !!!
[16:51] <marcoceppi> tomixxx4: np, feel free to ping me when you get going again. I don't think that's why the lxc container failed, but it's hard to troubleshoot if you can't get to the node
[16:51] <tomixxx4> marcoceppi: ok ty
[17:16] <tomixxx4> marcoceppi: hmm, i have changed that ssh, destroyed juju and rebootstrapped but there is still sth wrong: http://pastebin.ubuntu.com/6926519
[17:45] <tomixxx4> ok, last try for today, i have deleted all keys in .ssh and created a new one with the command "ssh-keygen -t rsa", rebootstraping now...
[18:07] <tomixxx4> marcoceppi: ok, i could login now to the node and i tried wget but i get "failed: no route ho host"
[18:07] <marcoceppi> tomixxx4: ah, I know this issue!
[18:07] <marcoceppi> tomixxx4: you need to configure your DNS server to foward requests
[18:07] <marcoceppi> quick fix, on the maas-master
[18:08] <marcoceppi> tomixxx4: open /etc/bind/named.conf.options on maas-master
[18:08] <tomixxx4> kk!
[18:08] <marcoceppi> and add the following bit
[18:09] <marcoceppi> http://paste.ubuntu.com/6926815/
[18:09] <marcoceppi> tomixxx4: you should see it commented out currently
[18:09] <marcoceppi> just uncomment and set the dns server to something, lik 8.8.8.8
[18:09] <tomixxx4> marcoceppi: no its not uncommented, its 143.205.140.21
[18:09] <tomixxx4> i told u from a bashscript to NAT right?
[18:09] <tomixxx4> i guess the NAT script has caused to set this IP as DNS
[18:09] <marcoceppi> tomixxx4: you're using the micro-cluster scripts?
[18:10] <tomixxx4> gimme a sec plz
[18:10] <tomixxx4> i have executed this script on maas-server: http://pastebin.ubuntu.com/6926827/
[18:11] <tomixxx4> there is a line: dnsserver="143.205.140.21"
[18:12] <marcoceppi> tomixxx4: yeah, that's from the micro-cluster scripts
[18:12] <marcoceppi> tomixxx4: can you actually dig @ that address?
[18:12] <marcoceppi> tomixxx4: ie, `dig @143.205.140.21 google.com` from the maas-master
[18:13] <tomixxx4> yes, i guess, "query time: 1022 msec"
[18:13] <tomixxx4> 1 server found
[18:14] <tomixxx4> but a question: is the dns-server of the node not simply the maas-dns-server?
[18:14] <tomixxx4> so 10.0.0.9 ?
[18:14] <tomixxx4> because i have set "manage dhcp + dns"
[18:14] <tomixxx4> instead of 143.205.140.21, which is dns-server from the maas-server
[18:15] <marcoceppi> tomixxx4: right, so basically the nodes will use your maas-master as DNS, but that DNS server needs to forward requests that it dosn't know about to an outside DNS server
[18:15] <marcoceppi> otherwise you'll get no route to host
[18:16] <tomixxx4> hmm ok , what does this mean? do i have to edit resolvconf on ssh node and add 10.0.0.9 (maas-server) as dns-nameserver=
[18:16] <tomixxx4> ?
[18:18] <tomixxx4> aaaahhh 10.0.0.9 is already written in resolv.conf of the node
[18:19] <tomixxx4> hmm
[18:20] <tomixxx4> this is, what my "interfaces" file on the maas-server looks like: http://pastebin.ubuntu.com/6926866
[18:20] <tomixxx4> dns-nameservers: 10.0.0.9 seems wrong, not?
[18:20] <tomixxx4> (eth0 connects the server to the nodes, eth1 connects the server to the i-net)
[18:21] <marcoceppi> tomixxx4: yeah, that dns-server should be the outward facing dns-server
[18:21] <marcoceppi> dns-nameserver*
[18:22] <tomixxx4> kk
[18:22] <marcoceppi> tomixxx4: then you'll have to restart networking
[18:22] <tomixxx4> k
[18:25] <tomixxx4> hmm still no route to host
[18:41] <tomixxx4> whe i start bootstrapping, i have to manually power on the node which is allocated in maas
[18:41] <tomixxx4> so, when i power off the node, and power on it again, does juju still work on that node?
[18:41] <tomixxx4> (i have also rebooted maas-server in meantime xP)
[18:42] <marcoceppi> tomixxx4: it should, unless the node has been set to stopped in maas
[18:42] <tomixxx4> kk
[18:43] <tomixxx4> but now, i see on the nodes console "cloud1 login:" but it seems it is not finishing...
[18:43] <tomixxx4> u know what i mean?
[18:43] <tomixxx4> normally, after this line, the node goes on and at the end it prints "cloud init" or sth like that
[18:43] <marcoceppi> tomixxx4: is this after a bootstrap or just a powercycle post bootstrap?
[18:44] <tomixxx4> just powerxycle
[18:44] <marcoceppi> tomixxx4: that's noraml
[18:44] <tomixxx4> ok, but when i hit "juju status" i get no answer in maas-server...
[18:44] <tomixxx4> it seems to stuck some way
[18:44] <tomixxx4> i cant even login too
[18:44] <marcoceppi> tomixxx4: so, you see cloudinit the first time because it's provisioning juju and installing a bunch of stuff, however, it's already done that so it just boots up and runs
[18:45] <marcoceppi> tomixxx4: can you ssh ubuntu@cloud1.master ?
[18:45]  * JoshStrobl thinks he may have been a bit overkill in the length of his response on the Juju mailing list :S
[18:45] <tomixxx4> no it says "could not resolve hostname cloud1.master: Name or service not known"
[18:45]  * marcoceppi goes to review the overkill
[18:46] <marcoceppi> tomixxx4: so, can you run ssh -vvv ubuntu@cloud1.master and pastebin the output?
[18:46] <tomixxx4> "interfaces" on master: http://pastebin.ubuntu.com/6927005
[18:46] <tomixxx4> maybe i have to add "master" in search line?
[18:47] <tomixxx4> ah...
[18:47] <marcoceppi> JoshStrobl: fantastic feedback!
[18:48] <JoshStrobl> Thanks
[18:48] <marcoceppi> thank you!
[18:50] <tomixxx4> it should spelled "dns-search" and "dns-nameservers" and not "search" and "nameserver" ... xP
[18:50] <JoshStrobl> marcoceppi: In case you didn't get the notice on G+, I went ahead and updated the blog post to suggest your script as well. I described mine as an atom bomb to a problem that can be solved with a screwdriver :P
[18:51] <marcoceppi> JoshStrobl: cool, I'm taking a few mins to work on making installing plugins for juju a lot easier too, as well as addressing some of the documentation concerns you brought up
[18:51] <marcoceppi> Unfortuantely our copywriter is out, so things like quickstart which are relatively new haven't been documented yet
[18:52] <JoshStrobl> marcoceppi: That's understandable. Better to know now then never I suppose! :P
[18:56] <tomixxx4> marcoceppi: http://pastebin.ubuntu.com/6927050
[18:57] <marcoceppi> tomixxx4: what does dig cloud1.master present?
[18:57] <tomixxx4> marcoceppi: http://pastebin.ubuntu.com/6927064
[18:59] <marcoceppi> tomixxx4: what does /etc/resolve.conf look like on maas-master?
[19:00] <tomixxx4> marcoceppi: http://pastebin.ubuntu.com/6927078 and "interfaces": http://pastebin.ubuntu.com/6927082
[19:01] <marcoceppi> tomixxx4: move 10.0.0.9 to the first line
[19:01] <marcoceppi> also, which DNS server is the one you actually use?
[19:01] <marcoceppi> 140.21 or 176.16 ?
[19:02] <tomixxx4> dont know
[19:02] <marcoceppi> whichever it is, that's the one that needs to be in /etc/bind/named.local.options
[19:02] <marcoceppi> as it'll be the one that forwards requests, I'm guessing 143.205.140.21 considering the output of dig
[19:04] <tomixxx4> ok its 143.205.140.21 , i did "dig www.google.com | grep SERVER"
[19:04] <tomixxx4> can i simply edit resolv.conf?
[19:05] <marcoceppi> tomixxx4: you can, but it'll eventually get re-generated
[19:05] <tomixxx4> re-generated, but only after reboot?
[19:06] <marcoceppi> tomixxx4: and other certain times
[19:06] <tomixxx4> oh ok...
[19:06] <marcoceppi> tomixxx4: the best way is to edit /etc/resolvconf/...
[19:06] <marcoceppi> uh, I forget the file name, one second
[19:06] <tomixxx4> head?
[19:06] <marcoceppi> tomixxx4: yeah, /etc/resolvconf/resolv.conf.d/head
[19:07] <marcoceppi> that's a good one to start with
[19:09] <tomixxx4> and then reboot :-)
[19:11] <tomixxx4> yep
[19:11] <tomixxx4> working
[19:12] <tomixxx4> can login again :-)
[19:12] <tomixxx4> but no route to host :(
[19:15] <marcoceppi> tomixxx4: yeah, so you'll need to update the forwarders rule in the /etc/bind/named.local.optoins to the right dns server
[19:15] <marcoceppi> restart bind, then try again
[19:16] <tomixxx4> good point, but the ip is already correct
[19:16] <tomixxx4> 143.205.140.21
[19:16] <marcoceppi> well, something's messed up along the line there
[19:17] <tomixxx4> u meand named.conf.options?
[19:17] <marcoceppi> tomixxx4: for the sake of, something or another, from maas-master run `dig @8.8.8.8 google.com`
[19:17] <tomixxx4> btw, i have to run the bash script again it seems, because nat table iptables is empty ^^
[19:18] <tomixxx4> i always have to run it, if i reboot the maas-server tbh
[19:18] <tomixxx4> has sth to do with my old server version i guess
[19:19] <tomixxx4> when i execute this bash script, do i have to reboot, restart network service or sth like that?
[19:19] <marcoceppi> tomixxx4: nope, it should do all that for you
[19:19] <tomixxx4> kk
[19:19] <marcoceppi> tomixxx4: so, dig @8.8.8.8 google.com; did that work?
[19:20] <tomixxx4> "dig @8.8.8.8 google.com" > connection timed out; no servers could be reached
[19:20] <marcoceppi> darn, okay
[19:21] <tomixxx4> ?
[19:21] <marcoceppi> tomixxx4: well I was going to say you could just use another DNS server, but you can't because of your network location
[19:22] <tomixxx4> but i can connect to i-net on my maas-server
[19:23] <marcoceppi> tomixxx4: right, but some networks block exterior nameserver lookups
[19:23] <marcoceppi> which is happening in your case
[19:23] <tomixxx4> interesting: when i try "ping 143.205.140.21" on my node, it says "destination host unreachable"
[19:23] <marcoceppi> tomixxx4: it might not be listening to pings
[19:24] <tomixxx4> but "ping 10.0.0.9" works
[19:24] <tomixxx4> and "ping 143.205.140.21" works also from maas-server
[19:24] <marcoceppi> tomixxx4: right, because your bind instance isn't configured to not respond to pings
[19:24] <marcoceppi> OH, on your node
[19:25] <tomixxx4> yes, on the maas-server, i can ping 143.205.140.21 and 10.0.0.9
[19:25] <tomixxx4> from the juju-bootstrap-node, i can only ping 10.0.0.9
[19:25] <tomixxx4> so it seems there is some NAT problem?
[19:27] <tomixxx4> in the bash-script, eth0 and eth1 are not confused or sth like that? iam not that familiar with iptables-statements
[19:27] <tomixxx4> eth0 = connects the server to the nodes via switch, eth1 = connects the server with internet
[19:32] <marcoceppi> tomixxx4: oh, maybe that's what's up
[19:32] <marcoceppi> the script assumes something else
[19:33] <tomixxx4> kk
[19:40] <tomixxx4> so, i guess i need other NAT- and forwarding statements?
[19:41] <marcoceppi> tomixxx4: one sec, link the script you're using again?
[19:42] <tomixxx4> marcoceppi: kk, link is: http://pastebin.ubuntu.com/69227311
[19:43] <tomixxx4> marcoceppi: sorry, wrong address.... correct: http://pastebin.ubuntu.com/6927311
[19:44] <marcoceppi> tomixxx4: you should uncomment sysctl --system
[19:44] <marcoceppi> also, you should install iptables-persist
[19:44] <marcoceppi> and write the rules to it, so they survite restarts
[19:46] <marcoceppi> so, install iptables-persist, then run the nat script, then run `iptables-save > /etc/iptables/rules.v4`
[19:47] <tomixxx4> marcoceppi: but sysctl --system does not work with my ubuntu server edition
[19:47] <marcoceppi> tomixxx4: what...version are you running?
[19:48] <tomixxx4> ubuntu server 12.04.3 LTS
[19:53] <thumper> rick_h_: if I have an environment running, with a gui installed, will 'juju quickstart' just log me in to it?
[19:54] <rick_h_> thumper: yes
[19:54] <thumper> ok
[19:54] <rick_h_> thumper: it's a much faster way thank finding your admin secret
[19:54] <rick_h_> thank/than
[19:54] <thumper> true that
[19:55] <marcoceppi> can we just make juju quickstart juju deploy?
[19:55] <marcoceppi> err boostrap
[19:55] <rick_h_> not a fan, in this case it's not bootstrapping. It's using the existing env
[19:55] <rick_h_> and it's used for: juju quickstart bundle:xxxx
[19:56] <rick_h_> which can reuse an env, that's not 'bootstrap' really.
[19:56] <marcoceppi> rick_h_: it will bootstrap if the env doesn't exist already
[19:56] <marcoceppi> atleast, I'm pretty sure it will
[19:58] <tomixxx4> marcoceppi: so, the content of the bash script is ok?
[20:00] <marcoceppi> tomixxx4: seems about right
[20:02] <tomixxx4> marcoceppi: but dns resolving works
[20:02] <tomixxx4> marcoceppi: see the output of the wget command: http://pastebin.ubuntu.com/6927432
[20:19] <tomixxx4> marcoceppi: so, do u have any other idea what the reason for the problem could be ? :(
[20:43] <tomixxx4> marcoceppi: ok, i have to go now. but i will be here next week, maybe there is a chance to get things work on another day ;)
[20:44] <marcoceppi> tomixxx4: cheers, sorry we couldnt' get this figured out today!
[20:46] <tomixxx4> marcoceppi: np! thank you for all your help and hints so far ;-) All these things helped me to get stepwise closer to openstack!
[20:46] <tomixxx4> gn8
[20:53] <marcoceppi> jcastro: https://github.com/juju/plugins
[20:53] <jcastro> I saw, I am subbed to the juju org
[20:53] <jcastro> <3
[20:54] <marcoceppi> I'll add more as I clean up plugins
[20:54] <marcoceppi> jcastro: could you test my install instructions when you get a chance?
[20:55] <marcoceppi> lazyPower: you probably wrote a few plugins too ^^
[20:55] <jcastro> sure
[20:56] <jcastro> marcoceppi, git is in `git` now, not `git-core`
[20:56] <lazyPower> jcastro: so git is no longer a metapackage?
[20:58] <jcastro> no it's a package package
[20:58] <jcastro> but it's git, not git-core
[20:58] <jcastro> marcoceppi, the rest of the instructions work
[20:58] <marcoceppi> jcastro: cool, thanks
[20:58] <marcoceppi> docs updated
[20:59] <jcastro> marcoceppi, http://paste.ubuntu.com/6927700/
[20:59] <jcastro> something is wrong with the backup one I think?
[20:59] <marcoceppi> jcastro: backup isn't a plugin in the plugin repo
[20:59] <jcastro> marcoceppi, also it's Verify not Veify
[20:59] <marcoceppi> jcastro: that's something in your path
[20:59] <jcastro> oh!
[21:00] <lazyPower> marcoceppi: the only juju plugin i wrote you replaced with clean
[21:00] <lazyPower> +1 on instructions working
[21:00] <jcastro> marcoceppi, all you need is an "updating" section and you should be good
[21:00] <marcoceppi> jcastro: something I just realized, it'd be nice if in () after the description juju showed you the path to the plugin
[21:00] <jcastro> just cd'ing in there and git pull should do it right?
[21:00] <marcoceppi> jcastro: ah, good catch
[21:00] <marcoceppi> jcastro: ack
[21:00] <jcastro> o/
[21:01] <marcoceppi> thumper: you up?
[21:01] <thumper> marcoceppi: yeah man
[21:01] <thumper> pfft
[21:01] <thumper> been up for hours
[21:01] <marcoceppi> thumper: hey, how hard would it be to display the path of a plugin in the juju help plugins output?
[21:02] <marcoceppi> like `PLUGIN      --description output    PATH`
[21:02] <jcastro> man, I really want the docs on github
[21:02] <thumper> you mean where we found th eplugin?
[21:02] <jcastro> but I don't want to go down that rabbit hole
[21:02] <marcoceppi> jcastro: oh, you mean with like markdown ;)
[21:02] <thumper> jcastro: do it :-)
[21:02] <marcoceppi> +1 from me ;)
[21:02] <jcastro> marcoceppi, yeah, then you could inline edit docs ON THE FLY
[21:02] <thumper> jcastro: ask for forgiveness
[21:02] <marcoceppi> thumper: yeah, where the plugin is located
[21:03] <jcastro> thumper, yeah but we build the docs out of bzr, so like, we'd need to update cron jobs etc.
[21:03] <marcoceppi> like /usr/bin or is it ~/.juju-plugins, etc
[21:03] <thumper> marcoceppi: pretty easy
[21:03] <jcastro> hmmmm
[21:03] <marcoceppi> thumper: cool, I'll file a bug for it then try to hack it myself for the next 10 mins, then leave it to the experts
[21:03] <jcastro> hey rick_h_, how did you import the gui history into github and so on?
[21:03] <thumper> marcoceppi: heh, ok
[21:04] <thumper> rick_h_: also, re: github, do you squash the commits when merging?
[21:05] <jcastro> https://github.com/kfish/git-bzr
[21:05] <jcastro> seems useful
[21:05] <marcoceppi> jcastro: there's like a million git-bzr plugins out there
[21:05] <jcastro> yeah I just want to know which one works
[21:06] <marcoceppi> they all kind of suck, are you talking about just moving the docs branch to github?
[21:06] <marcoceppi> I can do a one time export -> import to github
[21:06] <marcoceppi> #thingstodowhennickisaway
[21:07] <jcastro> yeah
[21:08] <marcoceppi> was that yeah do that, or...?
[21:08] <marcoceppi> I mean, we should make sure no other merges exist against the docs branch, then once we move it we'll need to basically not accept merges to the docs branch anymore on lp
[21:09] <marcoceppi> then setup lp to import from gh so that we don't break auto-doc generation
[21:10] <jcastro> I was thinking of filing to make the auto-doc scripts update to pull from gh instead
[21:12] <jcastro> marcoceppi, I don't see any active MPs for docs.
[21:13] <marcoceppi> jcastro: we could do that too, file to use gh, not sure how much IS will like that, but I can do an initial import to gh
[21:13] <jcastro> -core is moving to github
[21:13] <jcastro> let's go all in!
[21:13] <marcoceppi> jcastro: cool, will set up in a few seconds
[21:16] <rick_h_> thumper: notes, scripts, and docs in here: https://bazaar.launchpad.net/~rharding/juju-gui-lander/trunk/files
[21:16] <rick_h_> thumper: hazmat says that to squash commits from bzr over to the new git repo it's a one line change to bzr-fastimport
[21:16] <marcoceppi> jcastro: https://github.com/juju/docs
[21:17] <jcastro> marcoceppi, nice, I'll send the mail to nick
[21:17] <rick_h_> thumper: yes, we squash when marging currently. https://github.com/juju/juju-gui/blob/develop/HACKING.rst#typical-github-workflow is what we're doing atm with some warts
[21:17] <lazyPower> marcoceppi: can i get an invite to the juju group?
[21:18] <marcoceppi> I don't think I'm an admin?
[21:18] <rick_h_> lazyPower: github username?
[21:18] <lazyPower> rick_h_: chuckbutler
[21:19] <marcoceppi> I do have the power
[21:19] <rick_h_> lazyPower: added as charmer like marco/jcastro
[21:19] <lazyPower> ty rick_h_
[21:19] <rick_h_> hmm, and did owners as well. looks like everyone is an owner
[21:19] <marcoceppi> lazyPower: we should make sure that we don't ever push master, but use merge proposals instead
[21:19] <marcoceppi> psa
[21:20] <lazyPower> marcoceppi: i'll follow the fork-repository pattern.
[21:20] <marcoceppi> lazyPower: <3
[21:20] <lazyPower> :)
[21:20] <rick_h_> marcoceppi: lazyPower yea, we make everyone fork off of juju owned repo into their own space and use pull requests
[21:20] <marcoceppi> I guess it's about time I moved amulet from my namespace
[21:21] <hatch> there might be a better way to do the merging so we don't need people to rebase before merging into the develop branch....but untested
[21:21] <hatch> pr's accepted.....right rick_h_ ? :)
[21:21] <rick_h_> hatch: yea, hopefully I can hack at it some this weekend.
[21:21] <hatch> oh that would be awesome
[21:21] <rick_h_> hatch: well I missed the no rebasing bit
[21:22] <hatch> there is git merge --squash
[21:22] <rick_h_> some of those ways just always end up as one commit which I'm not a fan of
[21:22] <hatch> and git merge --squash --ff
[21:22]  * marcoceppi stops pushing master to plugins now
[21:22] <rick_h_> hatch: oh hmm, well we just use the github api for the merge bit
[21:23] <rick_h_> hatch: so I don't have a way to tell it how to do it like that. I guess we could have the script try to do it and then close the pull request as a follow up step
[21:23] <rick_h_> I want to see how we get into these merge conflict issues. I don't run into them but seems everyone else does so I must be missing something in my workflow.
[21:23] <hatch> I don't....it only happens when you merge develop into your current workflow then modify it and another branch lands
[21:24] <hatch> it's pretty rare
[21:24] <hatch> but the conflicts make sense
[21:24] <rick_h_> I think the trick is to fix the way we merge develop in mid-branch
[21:24] <rick_h_> just git merge develop isn't good. I think a git rebase develop will work
[21:24] <rick_h_> but need to setup branches in the right state and try it out this weekend
[21:30] <marcoceppi> rick_h_: so is juju-core on gh or should I be using bzr still?
[21:31] <rick_h_> marcoceppi: I'm not up on what core is up to. They're moving at some point but don't know timing/state of that.
[21:31] <rick_h_> marcoceppi: I'm assuming since thumper asked for info they're still working on it
[21:31] <marcoceppi> makes sense, ta
[21:31] <thumper> marcoceppi: core moving soon
[21:31] <thumper> FSVO soon
[21:32] <rick_h_> hah
[21:33] <marcoceppi> jcastro: are you going to announce plugins to the list or should I?
[21:33] <jcastro> I can if you'd like!
[21:33] <jcastro> I am at your service
[21:34] <marcoceppi> jcastro: you're more...wordsmity than I, I can't seem to get veify right ;)
[21:34] <jcastro> on it
[21:34] <marcoceppi> ta!
[21:39] <jcastro> marcoceppi, is juju clean the only one we have right now?
[21:40] <marcoceppi> it's the only one I've put in there, I'm trolling through my gists to find others
[21:40] <jcastro> ack
[21:40] <marcoceppi> I've created a ton of them, but they're pretty hyper specific
[21:41] <jcastro> wouldn't hurt to have them in there
[21:41] <jcastro> if anything as examples
[21:42] <hatch> jcastro quickstart is a plugin..no?
[21:42] <jcastro> hatch, yessir it is!
[21:42] <hatch> or is that leveled up too much? :)
[21:43] <jcastro> though tbh I think it should just be reimplemented in core
[21:43] <jcastro> that should just be the way to use juju IMO
[21:44] <marcoceppi> hatch: well, is juju-quickstart just a single file? IMO plugins should graduate to packages, like deployer charm-tools and quickstart
[21:44] <marcoceppi> but a ton of them, like juju-clean, address gaps in juju released versions
[21:45] <hatch> marcoceppi no it's quite a bit of work :)
[21:45] <marcoceppi> or one off simplifications, like juju-setall
[21:45] <marcoceppi> which just runs juju set key=val on all services wether it exists or not as a valid config
[21:45] <hatch> https://code.launchpad.net/~juju-gui/juju-quickstart/trunk
[21:47] <hatch> it seems like there should be a juju-plugins org and then each plugin has it's own repo
[21:47] <hatch> else you have to pull down everything to patch one plugin
[21:47] <hatch> but I mean, unless there are quite a few it's probably not a problem :)
[21:47] <marcoceppi> hatch: that was my plan, but jorge was like "start small"
[21:48] <hatch> I hate to say it.....but he is probably right ;)
[21:48] <marcoceppi> yeah, I registered jujuplugins.com but unless get a cascade of plugins I think this will suffice
[21:51] <hatch> yup yup
[22:10]  * marcoceppi shames jcastro for cowboying on the docs branch
[22:15] <dannf> he shalt be punished by eating only beans from a can and dark coffee for a week!
[22:20] <thomi> Hi - I wonder who I should talk to about issues I'm having in juju-quickstart? Specifically: https://bugs.launchpad.net/juju-quickstart/+bug/1280005
[22:20] <_mup_> Bug #1280005: juju-quickstart cannot bootstrap local environemtn with sudo <juju-quickstart:New> <https://launchpad.net/bugs/1280005>
[22:45] <marcoceppi> thomi: as of 1.17.2 you no longer need sudo to bootstrap (it'll instead prompt for password) so when 1.18.0 is released that bug won't be relevant anymore
[22:45] <thomi> marcoceppi: in the mean time, what can I do?
[22:45] <marcoceppi> thomi: run sudo juju quickstart ?
[22:45]  * thomi tries
[22:48] <rick_h_> thomi: howdy, yea for now I cheat and bootstrap with juju and then run quickstart to get the Gui and bundles deployed
[22:48] <thomi> rick_h_: ok, I'll try that
[22:48] <rick_h_> thomi: we're in between releases. Right now it checks if the version is < 1.18 and if so it throws the message
[22:48] <rick_h_> thomi: once 1.18 hits it'll 'just work' and it's a pain point during the dev 1.17 cycle
[22:48] <thomi> rick_h_: perhaps on trusty it shouldn't install the PPA?
[22:49] <thomi> rick_h_:  any idea when the 1.18 release is happening?
[22:49] <rick_h_> thomi: I think the aim is within 2wk?
[22:49] <thomi> awesome, thanks
[22:49] <rick_h_> thomi: no promises, but soon so should get over this bump
[22:49] <thomi> :)
[22:57] <JoshStrobl> @marcoceppi - I don't think individual repositories are necessarily for juju plugins. I've contibuted to DefinitelyTyped (a repository of definitions and tests for Typescript stuff - https://github.com/borisyankov/DefinitelyTyped) and having each "definition" (in the case of Juju plugins it'd be a folder for each plugin) works out pretty well.
[22:57] <marcoceppi> JoshStrobl: well, this is one repository, that has a file per plugin
[22:57] <marcoceppi> same concept
[22:58] <marcoceppi> JoshStrobl: I'm about to add more, I just put the one in there, but others are welcome
[22:58] <thomi> rick_h_: probably a dumb question, but 'juju generate-config' does not set 'admin-secret' in the local environemnt config stanza, which then causes other things to fail. Any ideas what I'm missing?
[22:58] <JoshStrobl> marcoceppi: Essentially, although you could easily divide each plugin into it's own folder and accompany each plugin with it's own Markdown page that'd be similar to man pages so people could easily understand (in a human readable fashion) the plugin's use-case, flags/ args, etc.
[22:58] <marcoceppi> JoshStrobl: since plugins work by path, we'd have to add /each/ folder to path, which is tedious
[22:59] <JoshStrobl> true
[22:59] <marcoceppi> JoshStrobl: yeah, that's why I enforce all plugins accepting a --help flag
[22:59] <marcoceppi> since juju will automatically run the -help flag if you do `juju help <plugin>`
[23:00] <marcoceppi> much like the other juju help topics
[23:00] <rick_h_> thomi: I think they changed that it's in the jenv file now. The gui mentions it when you install it and load it now
[23:00] <JoshStrobl> marcoceppi: Awesome.
[23:00] <rick_h_> thomi: so check the .juju/environments/xxxx.jenv
[23:01] <thomi> rick_h_: yes, I see it there, but after doing a manual bootstrap, 'juju-quickstart -e local' complains about it being missing from the environments.yaml file - should I copy it over, or is there a better way?
[23:01] <rick_h_> thomi: if you juju quickstart it should find it and load the gui and auto log you in
[23:02] <rick_h_> thomi: juju-quickstart --version
[23:02] <thomi> juju-quickstart 1.0.0
[23:03] <rick_h_> hmm, can you file a bug then that lists the error you get from quickstart with it complaining. Note that you generated the config via generate-config
[23:03] <rick_h_> thomi: ^
[23:03] <thomi> rick_h_: sure thing
[23:03] <rick_h_> thomi: for the moment yes, you can copy it over
[23:03] <marcoceppi> lazyPower: you around?
[23:03] <rick_h_> thomi: but I thought it should *just work* in either location
[23:04] <marcoceppi> lazyPower: could you review and merge this plz https://github.com/juju/plugins/pull/2
[23:09] <thomi> rick_h_: https://bugs.launchpad.net/juju-quickstart/+bug/1280019
[23:09] <_mup_> Bug #1280019: juju-quickstart does not find admin-secret <juju-quickstart:New> <https://launchpad.net/bugs/1280019>
[23:10] <rick_h_> thomi: thanks, will put this on the radar to check into
[23:11] <rick_h_> thomi: I'm wondering if this is another case where "juju < 1.18 look in environments.yaml" and otherwise look in .jenc
[23:11] <rick_h_> .jenv
[23:11] <thomi> sounds like it
[23:12] <rick_h_> thomi: I'll verify tomorrow and update the bug.