[00:01] <lazypower> bolthole : well huzzah for random workingness :)
[00:04] <lazypower> bolthole: sorry about the quickstart papercut though :/
[08:41] <apuimedo> jamespage: https://code.launchpad.net/~celebdor/charms/trusty/nova-cloud-controller/liberty/+merge/283709
[08:42] <apuimedo> did you have a chance to look at the merge proposal?
[08:44] <apuimedo> jamespage: I take it that were waiting for after the release to merge them since the branch is probably frozen (don't know if you do that or you make a frozen separate branch)
[08:44] <jamespage> apuimedo, not yet
[08:44] <jamespage> apuimedo, your tomorrows train work :-)
[08:44] <jamespage> so long as things are looking and testing ok I'd hope to land later this week once we unfreeze
[08:45] <apuimedo> you are going to Brussels by train?
[08:45] <apuimedo> I finally decided for plane
[08:45] <jamespage> apuimedo, btw we have plans to move all charm development upstream under openstack - I'm assuming that you might be supportive of that move?
[08:45] <jamespage> apuimedo, eurostar is to easy :-)
[08:45] <apuimedo> jamespage: supportive is not enough. I'm enthusiastic about it
[08:45] <jamespage> apuimedo, planes are ok but I have to transfer Norwich -> Amsterdam -> Brussels
[08:46] <apuimedo> you'll probably have a downstream release branch though, right?
[08:46] <jamespage> apuimedo, I'm hoping to sprint on the last remaining technical blockers thurs/friday so can move forwards
[08:46] <jamespage> apuimedo, nope - all git/gerrit
[08:46] <apuimedo> jamespage: that makes me happy
[08:46] <jamespage> well have some sort of branch strategy for consolidated charm release points
[08:47] <jamespage> apuimedo, charm store is moving away from the bzr based injestion to a direct publish model so that helps...
[08:47] <apuimedo> although having a downstream internal canonical clone for hotfixes makes a lot of sense
[08:47] <jamespage> apuimedo, I'd rather do it all upstream
[08:47] <apuimedo> jamespage: so would I. I'm just speaking in practical terms
[08:47] <jamespage> apuimedo, we're just moving everything we do now in launchpad/bzr to gerrit/git
[08:48] <apuimedo> that is the best news I heard for a while jamespage
[09:34] <D4RKS1D3> Hi, goodmorning
[09:34] <D4RKS1D3> jamespage, to whom sal I connected the juju-info interface required by openvswitch-odl?,  p.s: Could you share with me a juju-status, it would be very appreciated to enable me to explore this information, thanks a lot in advanced.
[09:41] <jamespage> D4RKS1D3, just relate it to nova-compute and neutron-gateway
[09:44] <D4RKS1D3> Thanks jamespage
[11:57] <jamespage> gnuoy, beisner: not sure that neutron-openvswitch got a charm-helpers sync
[11:57]  * jamespage checks
[12:00] <jamespage> beisner, gnuoy: https://code.launchpad.net/~james-page/charms/trusty/neutron-openvswitch/16.01-resync/+merge/283933
[12:57] <marcoceppi> lazypower aisrael
[13:48] <lazypower> marcoceppi
[14:36] <beisner> jamespage, yeah i've been finding onesy-twosey sync misses unfortunately
[14:38] <lazypower> tvansteenburgh: o/ heyo - have you ever seen an issue like this bubble up when attempting ot test a bundle w/ bundletester? http://paste.ubuntu.com/14672009/
[14:38] <tvansteenburgh> lazypower: no
[14:40] <tvansteenburgh> lazypower: pondering...
[14:40] <lazypower> I got this stack trace from anton, a nexenta charmer
[14:40]  * lazypower is trying to reproduce
[14:41] <mbruzek> I have a partner getting an error bootstrapping, "ERROR failed to bootstrap environment: cannot start bootstrap instance: No default VPC for this user (VPCIdNotSpecified". I have never seen this before.  Has anyone in #juju seen this problem?
[14:41] <lazypower> mbruzek: i'm thinking thi sis an account permissions issue
[14:42] <lazypower> but i'm not 100% positive ont hat
[14:42] <mbruzek> lazypower: OK I will ask
[14:42] <lazypower> mbruzek: and i'm referring to the AWS API Credentials being provided to juju
[14:42] <mbruzek> yes I figured that.
[14:43] <lazypower> right on :) I haven't had my coffee this morning, and if this week is anything like last week, i'm already speaking jibberish
[14:43] <mbruzek> lazypower: I had not thought of that, so I thank you for responding.  I will send them an email
[14:43] <tvansteenburgh> it could also be that the aws user is old enough that it predates vpc, and actually doesn't have a default vpc defined - that happened to me once upon a time
[14:45] <mbruzek> thanks tvansteenburgh!  All good things to check.
[14:46] <tvansteenburgh> lazypower: are the nexenta charms in lp?
[14:46] <lazypower> tvansteenburgh they are, 1 sec and i can get you a link
[14:47] <lazypower> tvansteenburgh https://bugs.launchpad.net/charms/+bug/1515717
[14:47] <mup> Bug #1515717: Nexenta Edge Charms to deploy edge cluster <Juju Charms Collection:In Progress by nexenta-systems> <https://launchpad.net/bugs/1515717>
[14:47] <tvansteenburgh> lazypower: ta
[14:57] <lazypower> urulama: are we in the middle of a deploy?
[14:58] <lazypower> urulama: looks like our docs are 404'ing all the way down the url tree
[14:58] <urulama> lazypower: no, no deploy on production going on ...
[14:58] <urulama> lazypower: will look into it
[14:58] <lazypower> i take that back, /stable/ is whats 404'ing
[14:58] <lazypower> looks like /devel/ is still functional
[14:59] <lazypower> and i spoke too soon
[14:59] <urulama> :-/
[14:59] <urulama> weird behaviour!
[14:59]  * lazypower nods
[14:59] <lazypower> Want me to file a bug urulama?
[15:00] <urulama> i'll put a task directly, thanks
[15:00] <lazypower> np, thanks for taking a look
[15:02] <urulama> lazypower: i suspect that was an exact moment when docs got rebuilt ...
[15:02] <tvansteenburgh> lazypower: i couldn't repro using the charm from lp, but, the first thing i would try is to ask him to reinstall bundletester in a venv
[15:02] <lazypower> ok, i've got you cc'd on these emails. incoming update
[16:04] <marcoceppi> cory_fu: I've got a use case for helpers.any_states
[16:04] <marcoceppi> cory_fu: I'd like to add a @hook_any do you think that would work?
[16:05] <marcoceppi> cory_fu: this is what I'm doing currently: http://paste.ubuntu.com/14672561/
[16:11] <cory_fu> marcoceppi: Sorry, meeting.  @hook_any?
[16:11] <cory_fu> Do you mean @when_any?
[16:12] <marcoceppi> @when_any, yes
[16:17] <cory_fu> marcoceppi: Ok, sorry, meeting is done.
[16:18] <cory_fu> Ok, I'm fine with a @when_any in theory, but the issue is that, for states set by relations, you are in a position where a given relation instance might or might not be available, so how do you match up relation instances to handler args?
[16:18] <marcoceppi> cory_fu: are relations keynamed invoked? or just passed as args?
[16:19] <cory_fu> And, more importantly, if a state is not set, you have no way of knowing if it would have been a relation state, so no way to know if it *would* have an instance if it were set vs if it's a non-relation state in which case it would not have a value regardless
[16:20] <marcoceppi> maybe this isn't the best approach
[16:20] <cory_fu> marcoceppi: They are only passed  by position, because you can name the args whatever you want
[16:20] <cory_fu> In the handler
[16:20] <cory_fu> marcoceppi: Really, passing args into the handler is not ideal, because there's already confusion about which states should expect args and which shouldn't.
[16:22] <marcoceppi> cory_fu: yeah, I might need to rethink this a bit
[16:22] <cory_fu> It's definitely a problem, though.  I've run into cases where having @when_any would make the code quite a bit cleaner
[16:23] <cory_fu> marcoceppi: You can always work around it by having multiple handlers, each with their own explicit conditions
[16:23] <cory_fu> But that can make the list of handlers quite cluttered
[16:24] <cory_fu> marcoceppi: For your specific example, it looks like all of those states that you're checking with any_states are really just a way of detecting whether or not you're in an action.  Could you generalize that to a single "in-action" state?
[16:26] <marcoceppi> cory_fu: possibly, but it's only a subset of actions
[16:26] <cory_fu> marcoceppi: Also, if we had https://github.com/juju-solutions/charms.reactive/issues/11 then you could just handle that with an @action decorator with some sort of pattern or wildcard
[16:26] <marcoceppi> cory_fu: sure, but I'm still in a position that I have to mix @action and @when_not
[16:26] <cory_fu> True
[16:26] <marcoceppi> does any_states support wildcard?
[16:26] <cory_fu> Not currently, no
[16:27] <marcoceppi> cory_fu: interesting
[16:27] <cory_fu> marcoceppi: How are those states getting set?  Could the code that sets those states also set a common "action-requires-configured" state?
[16:28] <marcoceppi> cory_fu: :) https://github.com/juju-solutions/vpe-router/tree/master/actions
[16:28] <marcoceppi> cory_fu: so it's possible that we could set that state
[16:28] <marcoceppi> which might be easier
[16:30] <cory_fu> marcoceppi: You could also have the action code check for the vpe.configured state itself and handle the fail instead of doing it in the reactive handler
[16:30] <marcoceppi> cory_fu: yeah, I was trying to avoid too much logic in the action file, wanted to keep it pretty boilerplate
[16:30] <marcoceppi> but that is true
[16:31] <cory_fu> Fair enough
[16:31] <marcoceppi> this is part strawman to see how actions in reactive would work
[16:32] <cory_fu> I do think that @when_any would be worthwhile to figure out, and more generally figuring out a better way to address the ambiguity in what states correspond to what params to a handler
[16:33] <cory_fu> One thought was to always pass in a single "context" arg that has methods for accessing the available instances.  Of course, you can also always call charms.reactive.relations.RelationBase.from_state('state') and we could wrap that in a helper
[16:34] <marcoceppi> cory_fu: kind of like how frameworks send in a single request object?
[16:34] <cory_fu> I had rather liked Whit's charm context proposal before he left, but no one picked that up.
[16:35] <marcoceppi> cory_fu: you still can ;)
[16:35] <cory_fu> I know.  :p
[16:37] <cory_fu> Switching to a single context param would be a pretty significant change to the reactive API, though.  Definitely a 2.0 thing
[16:49] <tertiary> i am currently evaluating juju as a solution, but am unsure of something. we have a use case where our clients would need to install our maas+juju cluster, and ideally i would like this to be done with a simple .deb package. is this possible? would i be able to automate juju in a way that it could autodeploy the services with an installer?
[16:58] <tvansteenburgh> tertiary: i don't see why not. you can automate via the juju cli pretty easily
[16:59] <tertiary> ah theres a cli, thanks
[20:33] <tertiary> trying to install juju on Ubuntu 15.10 Desktop with juju-quickstart, getting the following error: "ERROR there was an issue examining the environment: failure setting config: cannot find address of network-bridge: "lxcbr0": route ip+net: no such network interface". It's strange, this does not happen on Ubuntu 15.10 Server...
[20:35] <lazypower> tertiary did you install the juju-local package? and are you using the 'local' provider?
[20:36] <tertiary> yesyes, just confired juju-local is installed. yes using "local" provider
[20:39] <lazypower> tertiary:  ifconfig lxcbr0  returns nothing?
[20:39] <tertiary> yeah: lxcbr0: error fetching interface information: Device not found
[20:40] <lazypower> one sec, let me boot up a vm and try something before i recommend it
[20:40] <tertiary> k
[20:40] <jrwren> tertiary: try `sudo service lxc-net restart`
[20:41] <jrwren> tertiary: it can't hurt and its easy enough. then see if `ifconfig lxcbr0` returns status instead of error.
[20:41] <tertiary> yeah same error
[20:42] <skay> a very small docs comment: https://jujucharms.com/docs/1.25/authors-hook-debug someone has remapped ctl-b to ctl-a and it's written in to the docs as though ctl-a is hte default
[20:42] <skay> speaking about the tmux session
[20:43] <skay> just noticed it today
[20:43] <lazypower> o/ skay  long time on see :)
[20:43] <skay> lazypower: hiya
[20:43] <lazypower> skay : looks like the same issue was ported over into the devel docs - https://jujucharms.com/docs/devel/developer-debugging#the-'debug-hooks'-command
[20:44] <lazypower> skay can you file a bug? http://github.com/juju/docs/issues/
[20:44] <lazypower> we'll circle back and add a footnote that the default key binding is ctrl-b
[20:44] <skay> lazypower: I myself also remap ctl-b to ctl-a due to muscle memory of screen
[20:44] <skay> change the code to match the docs, ha!
[20:45] <lazypower> :) Thats possible too
[20:45] <lazypower> skay - if you use dhx, you can customize all of that, even upload your own tmux config w/ things like powerline and the like.
[20:46] <tertiary> `service lxc-net status` yields: "dnsmasq: failed to create listening socket for 10.0.3.1: Cannot assign requested address"
[20:46] <lazypower> ahh, this came up the other day
[20:47] <lazypower> dnsmasq is preventing the lxc bridge froms tarting
[20:47] <lazypower> you can stop dnsmasq, start lxc-net, then restart dnsmasq - or reboot.
[20:47] <bdx> mbruzek: http://bazaar.launchpad.net/~charmers/charms/trusty/postgresql/trunk/view/head:/hooks/service.py
[20:48] <bdx> mbruzek: in the configure_sources hook
[20:48] <mbruzek> bdx: What is up?
[20:48] <bdx> mbruzek: it looks to me as if the sources are only added if both conditions are met correct?
[20:49] <bdx> mbruzek: sudo sysctl -w kernel.shmmax=15032385536
[20:49] <bdx> ooops
[20:49] <bdx> my bad
[20:49] <bdx> mbruzek: if config['pgdg'] and config.changed('pgdg'):
[20:49] <tertiary> lazypower: service status looks good after reboot, working now. thank you much sir.
[20:50] <mbruzek> bdx: Yeah it looks OK to me, if pgdg exists and it has changed generate the debian install line.
[20:51] <bdx> mbruzek: all versions of postgres other than 9.3 fail to install the postgresql binary due to sources not being available
[20:52] <bdx> because for any other version other than whats default in the repos the key and source have to be added
[20:53] <bdx> mbruzek: what I'm getting at, is that config.changed('pgdg') shouldn't ever be true
[20:54] <mbruzek> bdx config.changed('pgdg') will be true on first run and if anyone sets something else.
[20:54] <mbruzek> bdx: If it has a value the first time, if it is none the first boolean check will fail
[20:55] <mbruzek> bdx: I often use this pattern when doing configuration values.   if config['key'
[20:56] <mbruzek> ] and config.changed('key'):
[20:57] <bdx> mbruzek: yes, but who wants to modify that config every time the `juju deploy postgresql` ?
[20:57] <lazypower> tertiary glad we got you unblocked :)
[20:58] <bdx> mbruzek: it should be a prerequisite to have to change that param to have postgresql install other versions on install hook
[20:58] <bdx> ?
[20:59] <bdx> mbruzek: because it has no default value?
[20:59] <bdx> mbruzek: so http://paste.ubuntu.com/14674572/
[21:00] <bdx> mbruze: will automaticall make config.changed('dbms') true
[21:00] <bdx> mbruzek: at the time of install hook?
[21:01] <bdx> mbruzek: I see, hmm, ok. thanks for clearifying that
[21:01] <mbruzek> bdx: Still checking, I am very confused thought we were hung up on pgpd parameter.  Let me look at dbmz
[21:01] <bdx> oooh my bad
[21:01] <bdx> mbruze: will automaticall make config.changed('pgdg') true
[21:03] <bdx> typo in the .yaml I pasted you as well
[21:03] <mbruzek> pgdg is a boolean so it _has_ to have a default value (so it will have "changed" on first run) so I would expect `if config('pgdg') and config.changed('pgdg'):` to be true the first run.
[21:04] <mbruzek> I don't know about dbms or the version parameter.
[21:04] <bdx> mbruzek: ok, no worries, thats all I was after
[21:04] <mbruzek> bdx: stub write this charm code, and hangs out in the channel.  If you have specific postgres questions you can ask Stewart.
[21:06] <bdx> mbruzek: my bad, I thought I saw you as the contrib for that, I see now it was stub
[21:06] <lazypower> bdx are you stirring up trouble again ;)
[21:06] <mbruzek> bdx: I am always happy to help, but I had no context what you were asking.
[21:07] <mbruzek> bdx: if you have questions stub knows that code much better than I do.  But again I am always happy to help if you have questions.
[21:09] <bdx> mbruzek, lazypower:  I'm currently replacing our postgres clusters with juju deployed ones, just running into a few issues, thats all
[21:10] <mbruzek> bdx: Sure.
[21:10] <bdx> mbruzek: thanks, totally, I see that now
[21:11] <mbruzek> bdx: postgresql is one of the more complex charms we have I can see that one being hard to debug
[21:39] <bolthole> Hi. I deployed a second mysql instance, and a gitlab instance, through juju-GUI on azure. They werent happy so I tried to delete them. BUt now they wont go away. How can I force them to go away?
[21:39] <bolthole> the gitlab status is currently "error", with message;
[21:39] <lazypower> bolthole if services are in error they will block
[21:39] <bolthole> hook failed: "Db-relation-changed" for mysqlgitlab:db
[21:40] <lazypower> bolthole you have 2 options - 1) to resolve every error (without retry) and just resolve it all the way down until it goes away
[21:40] <lazypower> 2) juju destroy-machine # --force
[21:40] <lazypower> which is a very very angry way to get rid of a service's units, and you can then juju destroy-service {{service}}
[21:41] <bolthole> so basically, the "resolve" button, actually means "shut up I I nkow about it already" ?
[21:41] <lazypower> correct. it will forcibly resolve the error (if you dont choose retry) and it will continue to the next hook in progression
[21:41] <bolthole> that seemed to work. thanks!
[21:42] <lazypower> np bolthole o/
[21:42] <bolthole> while i'm on the subject, how can I make a new instance of something with a different name, through the gui? ...
[21:42] <bolthole> command line of "juju deploy mysql mysqlfoo" works. but cant seem to find equivalent in gui that actually works
[21:42] <lazypower> when it is dragged onto the gui its "staged"
[21:42] <bolthole> I tried going to the Configure option, and changin ghe name, and pressing save... but it doesnt stick?
[21:42] <lazypower> you should be able to change the service name while its got the blue ring
[21:43] <lazypower> but once its committed, its committed. You cant change the name
[21:43] <bolthole> trying again...
[21:43] <bolthole> adding to canvas...
[21:44] <bolthole> Configure -> Serivce name: "Mysql-gitlab" ... Save changes..
[21:44] <bolthole> but when I click on configure again.. service anme is back to "mysql"
[21:44] <bolthole> seems broken
[21:45] <lazypower> bolthole: thats unfortunate :/ would you mind filing a bug? https://bugs.launchpad.net/juju-gui/+filebug
[21:46] <bolthole> okay
[22:00] <cory_fu> lazypower: I don't know if you saw my edit to my comment on https://github.com/juju-solutions/vpe-router/pull/16 that explains more about the try / else construct in Python
[22:00] <lazypower> i did
[22:00] <cory_fu> Ok.  :)
[22:00] <lazypower> that was all new to me, i had no idea python did try/except, and the except is intended to allow further exceptions to not be caught by the diaper
[22:01] <lazypower> #TIL
[22:01] <cory_fu> aisrael: ^ also.  I do think that Exception should be changed to something more specific.
[22:01] <cory_fu> "except Exception" is generally a bad pattern
[22:02] <cory_fu> The only thing worse is a bare "except:"
[22:02] <cory_fu> :)
[22:02] <lazypower> cory_fu: diaper exceptions ftw i guess?
[22:04] <aisrael> I'm indifferent about the Exception; it's just passing a string back to the action handler to call action_fail with
[22:06] <aisrael> ^^ marcoceppi
[22:09] <cory_fu> The main issue is that it will catch pretty much any type of exception, even ones you are not expecting.  E.g., if the ssh raises something, it will be caught and reported as a validation error, potentially robbing you of some useful stacktrace info
[22:21] <marcoceppi> .
[22:22] <marcoceppi> cory_fu: that method raises an Exception, haven't really scoped it yet :)
[22:23] <marcoceppi> cory_fu: I supposed I should create a new Exception class
[22:23] <marcoceppi> aisrael: I think the else can be squashed and set_state just moved to the last line in the try block