[02:37] <halcyon> lazyPower: hye! are u available?
[02:37] <halcyon> lazyPower: I did follow this tutorial but I failed to restart my networking service
[02:39] <halcyon> lazyPower: then I reboot, and affect to show my juju status
[03:45] <halcyon> hye, does anyone can help me , what should I do if my juju status mentioned agent-state-info : container failed to start?
[03:50] <halcyon>  hye, does anyone can help me , what should I do if my juju status mentioned agent-state-info : container failed to start? I'm install juju using lxc in local provider
[04:15] <lazyPower> halcyon: this is more than likely related to reconfiguring your LXC bridge according to that post. As i mentioned - its tricky
[04:15] <lazyPower> and failure is difficult to debug when that happens
[04:15] <lazyPower> halcyon: how much linux networking do you know?
[04:16] <lazyPower> or rather, how confident are you in the event of catastrophic failure that you could reconfigure it into a working condition :)
[04:18] <halcyon> lazyPower: just a beginner :)
[04:19] <halcyon> lazyPower:  could u advice me on what should I do?
[05:48] <lazyPower> halcyon: Revert back to the LXCBR0 bridge, and revert the networking + subnet back to the 10.0.3.0/24 cidr
[05:49] <lazyPower> halcyon: i'm coming in and out of sleep - so if you're around in EST morning hours i can help. but for now i gotta get some sleep. have a good evening o/
[08:33] <Muntaner> good morning o/
[08:35] <Muntaner> I'm having problem with my first charm
[08:37] <Muntaner> 1 - when I do a juju-log in the bash code of the charm, where can I actually find those logs?
[08:37] <Muntaner> because I have a "hook failed: install" but can't figure why
[08:41] <Muntaner> maybe I'm not using well the "set -e" thing...
[08:42] <dimitern> Muntaner, in the unit log
[08:43] <dimitern> Muntaner, e.g. if you have unit wordpress/2 on machine 4, juju ssh 4, sudo less /var/log/juju/unit-wordpress-2.log
[08:43] <Muntaner> dimitern, figured it
[08:43] <Muntaner> seems like I had an error caused by a "mysql restart", and I didn't have mysql on that machine
[08:43] <Muntaner> (dumb errors :) )
[08:44] <dimitern> Muntaner, yeah - hooks need to be idempotent - calling them multiple times shouldn't be a problem
[08:46] <Muntaner> dimitern, nice! it works :)
[08:46] <Muntaner> now, I need to connect the mysql charm to my charm
[08:46] <Muntaner> can you tell me how to do that? no ideas, right now
[08:48] <dimitern> Muntaner, you'll need to specify in your charm metadata that you require a db relation like wordpress does for example
[08:48] <dimitern> Muntaner, then you can add-relation yourcharm mysql
[08:49] <dimitern> Muntaner, and ofc the relevant relation hooks need to be in place (db-relation-changed, etc.)
[08:54] <Muntaner> dimitern, maybe I'm getting it to work :D
[08:54] <dimitern> Muntaner, cool :)
[08:54] <Muntaner> dimitern, I need to tell to my charm the IP of the mysql charm... can I do that?
[08:57] <dimitern> Muntaner, check out https://jujucharms.com/docs/authors-charm-interfaces
[08:58] <dimitern> Muntaner, and this https://jujucharms.com/docs/interface-mysql
[08:58] <Muntaner> dimitern, ty!
[09:12] <Mmike> Hello, guys. I have a working juju environment, inside OpenStack. I have my bootstrap node and various other nodes with services happily running. I just managed to destroy my ~/.juju directory, along with the .jenv file that's tied to my environment.
[09:13] <Mmike> Is there a way to extract those info, somehow, from the bootstrap node?
[09:22] <Muntaner> dimitern, seems like I'm having problems in running the "db-relation-x" hooks
[09:23] <Muntaner> logs aren't helping me
[09:28] <dimitern> dimitern, sorry I'm in a meeting perhaps lazyPower or some of the charmers can help you?
[09:31] <Muntaner> dimitern, no problem!
[10:07] <Muntaner> dimitern, my charm 0.1 is ready
[10:08] <dimitern> Muntaner, awesome! does it work with mysql?
[10:08] <Muntaner> dimitern, yep!
[10:08] <Muntaner> prestashop 0.1 ready ;D
[10:09] <Muntaner> I should implement other hooks now
[10:09] <dimitern> Muntaner, sweet!
[10:11] <Muntaner> dimitern, how can I provide to the guy that deploys via juju-gui or CLI some informations about the default log-in, the default link to reach to see the web service, etc. ?
[10:12] <dimitern> Muntaner, I guess in the readme file for the charm
[10:24] <Muntaner> dimitern, can't access to readmes via the gui - seems like it loads forever, strange
[10:27] <dimitern> frankban, hey, perhaps you can help ^^
[10:30] <frankban> Muntaner: so you are not able to see the readme files from the GUI? for all the charms?
[10:30] <Muntaner> yep frankban, first time that this happens
[10:30] <Muntaner> I see "Loading..." and the spinning forever
[10:31] <frankban> Muntaner: ok I am trying to dupe
[10:32] <Muntaner> frankban, tell me if you need anything (logs, background)
[10:32] <frankban> Muntaner: sure thank you
[10:33] <Muntaner> frankban, I am logged in the same juju-gui endpoint with two laptops, if this may help
[10:33] <Muntaner> same thing happens with only 1 guy logged, just tried
[10:35] <bloodearnest> on 1.20.14, on openstack provider, is there a way for me to get hold of the private ip address of a unit that has been assigned a floating ip?
[10:35] <bloodearnest> juju status just shows the public ip, not private
[10:38] <Muntaner> frankban, another little issue: I can see the icon of my charm in the canvas, but on the left side I see its default icon
[10:39] <frankban> Muntaner: I just deployed the GUI on a ocal env using quickstart, and when I click charms on the left I can see their readme, configuration, etc without problems
[10:40] <Muntaner> frankban, maybe I caused this error someway
[10:40] <frankban> Muntaner: could you please file a bug describing the steps to dupe the error?
[10:43] <Muntaner> frankban, I just created my personal charm, changed his icon,  deployed it via CLI
[10:45] <frankban> Muntaner: deployed as a local charm?
[10:45] <Muntaner> frankban, I have an OpenStack private installation, all-in-one. The charm is a prestashop deployer - deployed it via CLI in the same LAN of the OpenStack server
[10:46] <frankban> Muntaner: what command did you use to deploy the charm?
[10:46] <Muntaner> frankban, juju deploy --repository=/home/mike/charms local:trusty/prestashop --debug
[10:47] <frankban> Muntaner: ok so this is a local charm deployment
[10:47] <frankban> Muntaner: how do you use the GUI to try to read the readme?
[10:49] <Muntaner> frankban, I click on the charm on the canvas, then I click on the link on the left tab (for example: cs:trusty/mysql-22), and then it opens a tab that loads forever
[10:49] <Muntaner> if you need screenshots, can up them
[10:50] <frankban> Muntaner: no thanks, now trying to dupe what you described
[10:55] <frankban> Muntaner: ok I deployed a local charm and now I see the readme error
[10:56] <Muntaner> great frankban!
[10:57] <frankban> Muntaner: oh... after refreshing the GUI, I can now see the readme of the local charm, could you try it?
[10:59] <Muntaner> frankban, F5ed a couple of times - no changes
[11:00] <frankban> Muntaner: any JS console errors?
[11:01] <frankban> Muntaner: oh I think I know why, I guess your charm is not in the charm stor eyet, correct?
[11:01] <Muntaner> no frankban, it justs exists in my laptop folder
[11:02] <frankban> Muntaner: ok
[11:16] <Muntaner> frankban, btw I can't read the readme of any charm (juju-gui, mysql)
[11:16] <frankban> Muntaner: even after refreshing?
[11:16] <Muntaner> frankban, yes
[11:17] <frankban> Muntaner: could you please try to refresh removing the URL path? so just the home of the GUI
[11:19] <frankban> Muntaner: anyway, I filed https://bugs.launchpad.net/juju-gui/+bug/1427162 , please feel free to add there any additional information you have. and thanks for reporting this issue!
[11:19] <mup> Bug #1427162: Local charms icon and readme <juju-gui:Triaged> <https://launchpad.net/bugs/1427162>
[11:54] <jamespage> gnuoy, can you do me a quick review of https://code.launchpad.net/~james-page/charm-helpers/bug-1413862/+merge/251426
[11:55] <gnuoy> sure
[11:57] <gnuoy> jamespage, approved
[11:57] <jamespage> gnuoy, ta
[14:25] <jcastro> hey guys
[14:25] <jcastro> http://askubuntu.com/questions/590715/how-can-i-find-power-pc-specific-charms
[14:25] <jcastro> we don't have this do we?
[15:25] <hazmat> jcastro: nope.. tags might help for the short term
[15:28] <rick_h_> jcastro: yea, there was talk of adding a metadata.yaml entry for that but nothing was firmed up and planned that I'm aware of.
[15:29] <jcastro> rick_h_, I was thinking though, if we see which charms fail on ppc64le we could have a general idea?
[15:31] <rick_h_> jcastro: maybe, I need to catch up on where/how good charm testing is to be a good indicator of something like this
[15:36] <jcastro> rick_h_, want me to answer it to that effect?
[15:37] <jcastro> hey tvansteenburgh ^^^
[15:39] <tvansteenburgh> jcastro: we're not testing on ppc64le yet
[15:39] <tvansteenburgh> not in CI anyway
[15:39] <jcastro> ack
[15:49] <jcastro> http://askubuntu.com/questions/590715/how-can-i-find-power-pc-specific-charms/591878#591878
[15:49] <jcastro> How's this guys?
[15:50] <jcastro> mbruzek, looks like that guy's jruby fixes for ppc64le are in upstream now
[15:50] <mbruzek> jcastro that is great
[15:52] <Muntaner> hey guys
[15:52] <Muntaner> just a quick question
[15:52] <Muntaner> how can I get in a juju hook
[15:52] <Muntaner> for example, install or db-relation joined
[15:52] <jcastro> what do you mean by in a juju hook
[15:52] <mbruzek> "get in"?
[15:52] <Muntaner> the floating IP assigned to the VM that is running this charm?
[15:52] <Muntaner> sorry, bad english ^^"
[15:53] <jcastro> https://jujucharms.com/docs/authors-hook-debug
[15:53] <jcastro> ok so this shows you how to go into a unit and debug a hook
[15:53] <jcastro> I assume your install hook failed and you want to see why?
[15:53] <mbruzek> Muntaner: the public-address and private-address is always available to a hook, likewise those values are available on relation hooks for the other charms.
[15:54] <Muntaner> no jcastro, I am running a command line installation into the install hook. I need to specify the local ip of the VM as a parameter of the installation
[15:55] <jcastro> oh yes, then what mbruzek said, let me find the doc snippet for those
[15:55] <mbruzek> Muntaner: if you want the private address for the system you are installing use 'unit-get private-address'
[15:56] <mbruzek> Muntaner: https://jujucharms.com/docs/authors-hook-environment
[15:57] <Muntaner> mbruzek, thanks, lemme try
[15:57] <mbruzek> Muntaner: if you need the address of a related charm, say in the db-relation-changed hook, use `relation-get private-address`
[15:58] <jcastro> evilnickveitch, hey since we're ditching the charm feature rating bits, can I go ahead and snip out that page and submit a PR?
[15:58] <evilnickveitch> jcastro, if we are doing that then sure
[16:00] <jcastro> ok confirmed we are, working it now
[16:13] <Muntaner> mbruzek, echos tell me that it's working, thanks :)
[16:13] <mbruzek> Muntaner: you are most welcome
[16:20] <Muntaner> mbruzek,
[16:20] <Muntaner> now I'm having a very strange issue
[16:23] <Muntaner> seems like the commands relation-get database return nothing
[16:23] <Muntaner> and they always worked
[16:24] <mbruzek> Muntaner:  Yes I have run into that before.  Sometimes the hook is fired before all the data is available.  Many database relation hooks exit 0 (silently) until the database'
[16:24] <mbruzek> key is in the relation-get
[16:25] <mbruzek> Muntaner: which is the reason all hooks must be idempotent they could be called several times.  An operation like building a database takes a little bit of time, so it is possible to have the relation fired before it is done.
[16:26] <Muntaner> mbruzek, the strange thing is that if I put the unit-get etc I have the problem
[16:26] <Muntaner> if I comment it, the problem isn't present anymore
[16:29] <mbruzek> Muntaner: Check out the following code I wrote: https://api.jujucharms.com/v4/precise/openmrs-1/archive/hooks/database-relation-changed
[16:29] <mbruzek> I followed the database-relation-changed pattern.  Get all the database values and in `relation-get database` did not return anything `exit 0` because the relation could be called several times.
[16:31] <Muntaner> mbruzek, sorry, I can't get it
[16:31] <Muntaner> I'm not understanding the "problem", if there is one :(
[16:38] <Muntaner> mbruzek, sooo... how can I be sure that all the values aren't empty?
[16:39] <mbruzek> Muntaner: check them all?
[16:40] <mbruzek> The code checks the "database" variable because that is the last one to be set.  If that one is available the others should be too.
[16:44] <Muntaner> mbruzek, if I do an exit 0... do the hook "finish" ?
[16:45] <mbruzek> If you exit 0 it stops there without an error
[16:45] <mbruzek> If you exit 1 Juju reads that return code as an error.
[16:45] <mbruzek> Muntaner: The hook will be called again when database is set
[16:46] <Muntaner> mbruzek, it seems like my hook did an exit 0
[16:46] <Muntaner> and in fact, his execution stopped in half
[16:48] <Muntaner> mbruzek, it does not seem to be called again... so my charm is in an "half deployed" status
[16:50] <mbruzek> Muntaner: What are you writing the charm in?  Use juju-log or echo or print() to debug this.  If the charm is half deployed I would think you need to exit earlier if you don't have the data  you need.  Only do the configuration when you have all the data
[16:51] <Muntaner> mbruzek, it's simple linux shell bash
[16:52] <mbruzek> always use set -ex for bash scripts so you can see the individual commands running.
[16:53] <Muntaner> mbruzek, already using it
[16:53] <mbruzek> Muntaner: then you should be able to figure out why the charm is half configured.
[16:54] <Muntaner> yes mbruzek, I know where I call the exit 0 because one variable is empty
[16:54] <Muntaner> but I can't figure how should I implement a workaround for this
[16:54] <mbruzek> Muntaner: exit 0 early if you don't have all the information, when you have all the data continue to set up the whole configuration.
[16:55] <Muntaner> mbruzek, I get lost at the "when you have all the data" part
[16:55] <mbruzek> All the database variables, and the private address, what ever your charm needs
[16:56] <Muntaner> yer mbruzek but I can't understand how can I check "when" I have them, since the hook exited
[16:56] <mbruzek> Muntaner: the hook will be called again when you get more information
[16:57] <Muntaner> mbruzek, btw, I'm not launching mysql and mycharm simultaneously: mysql is started since a long time
[16:57] <Muntaner> it's the same situation?
[16:57] <Muntaner> (I mean the mysql charm from the store)
[17:01] <mbruzek> Muntaner: Yes this is a common patter to connect to a database charm.  You can launch them simultaneously, the db-relation-changed hook can be called multiple times until you get all the database variables
[17:04] <Muntaner> mbruzek, maybe I got it. my relation-changed is empty, actually I'm only writing in the relation-joined
[17:04] <mbruzek> Muntaner: well there is your problem.
[17:30] <Muntaner> mbruzek, now I echo some dumb stuff in the relation-changed and seems to work
[17:38] <Muntaner> bye guys, see you tomorrow :)
[17:38] <Muntaner> mbruzek, thanks for the tips
[17:38] <mbruzek> Muntaner: you are welcome
[17:38] <mbruzek> Muntaner: glad you got it working.
[19:22] <mbruzek> Hey marcoceppi. If I wanted to rsync files between charms how would I set up creds?
[19:22] <marcoceppi> mbruzek: is this a peer relation or a service relation?
[19:22] <marcoceppi> suddenly wget doesn't seem so horrible ;)
[19:22] <mbruzek> marcoceppi: yes, that is the hook that I would use.
[19:23] <marcoceppi> peer?
[19:23] <mbruzek> no this would be a service relation
[19:23] <marcoceppi> icky, you'd have to have some kind of key exchange on the interface
[19:23] <marcoceppi> which isn't worth it anymore imo
[19:23] <marcoceppi> I thought this was a peer relation
[19:23] <mbruzek> How does peer relation make it better?
[19:24] <marcoceppi> mbruzek: the interface is virtually irrelevant, you can add any keys you want because it's an implicit relation between the units in the service/charm and not to other charms
[19:25] <mbruzek> I see.
[19:26] <mbruzek> marcoceppi: do you know of any charms that transfer *anything* via rsync ?
[19:27] <marcoceppi> i know they exist, not off the top of my head, but they're almost always peer relations
[19:27] <mbruzek> This would be more of a master/minion relation
[19:28] <mbruzek> Over the banana interface
[19:28] <lazyPower> mbruzek: i thought we refactored that to the starfruit interface
[19:28] <marcoceppi> so this is an interface you're creating?
[19:28] <mbruzek> marcoceppi: yes
[19:28] <mbruzek> marcoceppi: I have complete control
[19:28] <marcoceppi> mbruzek: then make the public key of that machine published on the interface
[19:29] <marcoceppi> public-key=`cat ~/.ssh/id_rsa.pub`
[19:29] <marcoceppi> and have all the units that get that add that public key to their authorized-keys file
[19:29] <marcoceppi> then you can rsync to all the units
[19:30] <whit> http
[19:50] <marcoceppi> or, http
[20:32] <jcastro> whit, link me up!
[20:33] <whit> for jujubox?
[20:33] <whit> jcastro, one sec
[20:33] <whit> jcastro, https://registry.hub.docker.com/u/whitmo/jujubox/
[20:34] <whit> jcastro, if you use docker 1.5.0 you can build and run charmbox, the second docker file
[20:35] <whit> jcastro, jujubox is only good for deploying, you need charmbox if you are doing any serious reviewing
[20:35] <jcastro> ack
[20:35] <jcastro> hey so, right off the bat
[20:36] <jcastro> in the "Once it's up" section in your docs
[20:36] <jcastro> put quickstart first, because you can't status without bootstrapping
[20:37] <jcastro> whit, also ran into this: http://pastebin.ubuntu.com/10506159/
[20:37] <jcastro> whit, ah I see, perhaps mention up front that the local provider won't work
[20:41] <jcastro> whit, have you posted this to the list? I don't see it there
[20:42] <whit> yeah that's mentioned in the "future" section but we should put it more prominently
[20:42] <whit> jcastro, it's only been mentioned as an aside wrt review queue
[20:43] <whit> jcastro, if you mount your $JUJU_HOME, status will work if you have an env bs'ed, but yeah will fix that for the barecase
[20:43] <jcastro> nod
[20:44] <jcastro> I was thinking more for the from-scratch case.
[20:44] <whit> jcastro, exactly
[20:44] <whit> jcastro, hypothetically it should run anywhere docker does
[20:45] <whit> jcastro, which is a nice story for folks who are  not on ubuntu but want to try juju
[20:48] <jcastro> whit, man this is fast
[20:48] <jcastro> much faster than the vagrant box, heh
[20:48] <whit> jcastro, yup
[21:48] <mbruzek> Juju peeps. My LXC environment seems to be corrupted. agent-state-info: 'failed to retrieve the template to clone: error executing "lxc-create":
[21:49] <mbruzek> Does anyone know how to fix something like that?  I tried cleaning out the LXC images, but no go
[21:50] <mbruzek> $ sudo lxc-destroy -n mbruzek-local-machine-2
[21:50] <mbruzek> lxc_container: lxccontainer.c: container_destroy: 2041 Error destroying rootfs for mbruzek-local-machine-2
[21:50] <mbruzek> help?
[21:50] <rick_h_> mbruzek: thumper is your local provider guy :)
[21:51] <waigani> mbruzek: what does `sudo  lxc-ls --fancy` show?
[21:54] <mbruzek> waigani: pastebin.ubuntu.com/10506962/
[21:55] <mbruzek> waigani: I tried to destroy the stopped containers but I can not.
[21:56] <mbruzek> waigani 1.21.3-vivid-amd64 if that makes any difference
[21:56] <waigani> mbruzek: have you tried with -f
[21:56] <mbruzek> yes
[21:56] <waigani> had to ask :)
[21:58] <mbruzek> $ sudo lxc-destroy -f -n mbruzek-local-machine-3
[21:58] <mbruzek> lxc_container: lxccontainer.c: container_destroy: 2041 Error destroying rootfs for mbruzek-local-machine-3
[21:58] <mbruzek> Destroying mbruzek-local-machine-3 failed
[21:58] <waigani> mbruzek: lxc-info -n mbruzek-local-machine-3
[21:59] <mbruzek> Name:           mbruzek-local-machine-3
[21:59] <mbruzek> State:          STOPPED
[22:00] <mbruzek> waigani http://pastebin.ubuntu.com/10507040/
[22:08] <mbruzek> https://bugs.launchpad.net/juju-core/+bug/1307215
[22:08] <mup> Bug #1307215: destroy-environment fails to clear lxc containers <destroy-environment> <local-provider> <lxc> <ubuntu-engineering> <juju-core:Invalid> <lxc (Ubuntu):Fix Released> <https://launchpad.net/bugs/1307215>
[22:09] <mbruzek> I used the work around deleting /var/lib/lxc/<image-dir>
[22:11] <waigani> mbruzek: sorry interrupted, I was just about to send you that link. Beat me to it.
[22:17] <mbruzek> Thanks for your help waigani
[22:18] <waigani> mbruzek: np
[22:33] <whit> hey cory_fu finally got back to your review comments.
[22:33] <whit> corey_fu not sure I understand the .git inclusion one
[22:37] <cory_fu> whit: Yeah, I replied to your comment on that one.
[22:37] <whit> cory_fu, ah thanks
[22:38] <cory_fu> whit: Regarding the gh: prefix, I assume that the .git suffix check means that Amulet (and thus deployer) support git repo http URLs, right?  So, I was thinking amulet could just convert gh: prefix URLs to https: URLs to GitHub.  I do also think deployer should add the gh: prefix as well, though
[23:02] <whit> cory_fu, yeah I think both amulet and deployer would need to support it, but it should be an easy add
[23:02] <whit> cory_fu, of course, removing the duplication would mean that would just be a fix in deployer
[23:02] <whit> cory_fu, add the support for sniffing the .git control dir
[23:03] <cory_fu> whit: I still don't understand, though.  If Amulet pre-processes gh:user/foo into https://github.com/user/foo.git, why would deployer need to support it?
[23:04] <whit> cory_fu, because it's not really useful for to create bundle files solely for testing
[23:04] <cory_fu> Agreed
[23:04] <whit> cory_fu, ie... you could use gh aliases for just simple test stuff, but your bundle files would still have to use the other
[23:04] <cory_fu> True
[23:05] <whit> cory_fu, so there is value supporting it in amulet, but it's less socially wierd if they both support it
[23:05] <cory_fu> I thought you meant it wouldn't work w/o deployer support.  I agree that it's not useful w/o deployer support, though
[23:05] <whit> cory_fu, but really amulet shouldn't be worrying about concerns deployer or jujuclient should handle
[23:06] <cory_fu> Indeed
[23:06] <whit> but these technologies are organically grown based on need, so some pruning is to be expected
[23:11] <lazyPower> > "Less socially weird"
[23:11] <lazyPower> i like this analysis of our tooling
[23:15]  * marcoceppi welcomes all contributions that make amulet more or less socially weird