[20:18] <Kokolo> Bello channel. I hace a question. I upgrade budgie 17.04 to 17.10 and some programa were removed like terminix. Alzó at the login screen i ser gnome as al option but when trying to login with gnome nothing happens. It is normal? How to remove gnome desktop? Thank you
[20:21] <fossfreedom> Kokolo, terminix has been replaced by "Tilix"
[20:22] <fossfreedom> Kokolo, it sounds like you have part of the gnome-session still installed but not all of the necessary packages
[20:22] <fossfreedom> suggest - sudo apt purge gnome-session
[20:29] <Kokolo> Gnome-session is partir budgie?
[20:29] <fossfreedom> no
[21:29] <kiwilinux> hello has any one had any issues with budgie crashing back to the ubuntu login screen
[21:30] <fossfreedom> kiwilinux, what are you doing before the crash?
[21:32] <kiwilinux> at one time i was working on libredraw trying to export a drawing to a png which happen serveral times
[21:33] <kiwilinux> it seemed to refresh the whole desktop a couple of times and then crash
[21:34] <fossfreedom> try opening raven - budgie-settings - style . turn off animations.  log off and log on.
[21:34] <kiwilinux> ok i will try that thanks


[02:00] <McL0v1n> thedac: My juju version is 2.3.1-xenial-amd64
[02:03] <McL0v1n> thedac, maas version is 2.3.0-6434-gd354690-0ubuntu1~16.04.1
[03:38] <jac_cplane> is there anyway to completly wipe a juju controller/env?   I made the mistake of trying to upgrade juju version - which corrupted the env.   while trying to recover/remove/clean I just released the bootstrap node and uninstalled juju apt-get remove juju.    then tried to start from scratch - install juju,etc.   the problem is there are still remnants of the old system.   I just want to wipe and start from scratch.   juju
[03:38] <jac_cplane> kill-controller, destroy-controller all fail.
[03:40] <jac_cplane> found this on the web - will this still work ?  "sudo apt-get purge --auto-remove juju"
[03:42] <McL0v1n> jac_cplane that doesnt work, i tried
[03:42] <jac_cplane> yep
[03:42] <jac_cplane> I just tried.   btw- i guess there is no way to update juju
[03:42] <McL0v1n> ops, i found the error with lxc's, This is in the logs:
[03:43] <McL0v1n> ERROR juju.worker runner.go:392 exited "0-container-watcher": worker "0-container-watcher" exited: setting up container dependencies on host machine: could not find unused subnet
[03:44] <McL0v1n> thedac ^^
[03:45] <pmatulis> jac_cplane, can you open a doc issue on the wipe stuff please? https://github.com/juju/docs/issues/new
[03:46] <jac_cplane> McL0v1n - looks like i found the way.    juju unregister <controller-name>
[03:46] <jac_cplane> then create a new one - same name overwrites the prev.  then you can bootstrap it
[03:48] <McL0v1n> ahh, forgot about that
[03:48] <McL0v1n> also juju kill-controller
[03:48] <jac_cplane> juju kill-controller does not work in this case i mentioned.
[03:48] <jac_cplane> I'll add to tghe docs
[03:50] <McL0v1n> any idea about why my lxcs are not provisioning? The error i posted above is in the host machine's logs
[03:59] <pmatulis> jac_cplane, see it, thanks
[04:03] <McL0v1n> I think it might have to be with: https://bugs.launchpad.net/juju/+bug/1665648
[04:03] <mup> Bug #1665648: Juju 2.0.3 fails to deploy LXD container lxdbr0 overlapping subnets <juju> <maas> <juju:Fix Released by hduran-8> <juju 2.1:Fix Released by jameinel> <https://launchpad.net/bugs/1665648>
[04:03] <McL0v1n> mup we posted at the same time
[04:03] <McL0v1n> i'm using a /8 10. subnet
[14:30] <mattyw> hey folks, can you have key names like "foo-bar" in config.yaml or do you need to use underscore (foo_bar) ?
[14:33] <jam> mattyw: we do stuff like:
[14:33] <jam> storage-default-block-source:
[14:33] <jam>   value: maas
[14:33] <jam>   source: model
[14:33] <jam> so foo-bar seems fine in yaml
[14:33] <mattyw> jam, ok great thanks
[14:34] <jam> mattyw: yamllint.com likes it fine, too
[14:34] <mattyw> jam, I've seen lots of charms use _, even going so far as converting them back to - in the charm code
[14:34] <mattyw> jam, so maybe it was a problem and not anymore?
[14:35] <jam> mattyw: being ok in yaml != being ok in Mongo docs
[14:35] <jam> though I think it is ok there, too.
[14:35] <mattyw> jam, charm config docs?
[14:35] <jam> as we certainly use {"model-uuid": blah}
[14:35] <mattyw> ok great
[14:35] <mattyw> I'll go with - for now thanks
[17:06] <ybaumy> when i bootstrap a controller to eg vsphere/dc1 and want another one in vsphere/dc2. what do i have to do
[17:07] <ybaumy> i mean a failover controller
[17:09] <ybaumy> or do i have to add another controller and move it with vmotion
[17:22] <hml> ybaumy: here is some documention on juju high availablity: https://jujucharms.com/docs/2.3/controllers-ha
[17:22] <hml> ybaumy: the juju enable-ha help page has info on specifying already created machines to be controllers.  not sure if the vsphere dcs are part of constraints or not.
[17:23] <hml> ybaumy: you’d spin up a vsphere instance where you wanted it - then use juju add-machine ssh:…. to let juju know about it
[17:24] <hml> ybaumy: but the —to or —constaints flags would be better if possible
[17:27] <ybaumy> hml i did now a enable ha and moved one controller to dc2
[17:27] <ybaumy> hml couldnt find anything that relates to creating it in dc2 in the first place
[17:30] <ybaumy> it also would make sense to distribute kubernetes etcd and master VM's to diffrent DC's
[17:31] <ybaumy> but appart from that and some dns problems im happy so far with it
[17:34] <hml> ybaumy: typically juju distributes between zones,
[17:35] <hml> ybaumy: looks like juju considers a vsphere dc as a region
[17:36] <hml> ybaumy: not sure if a region works with a placement directive or not.
[17:36] <ybaumy> hml so i have to create yaml to create masters in region dc1  and then dc2 ... with constraints?
[17:38] <hml> ybaumy: you don’t specify a region with a constraint: https://jujucharms.com/docs/2.3/reference-constraints#vsphere-provider:
[17:44] <hml> rick_h: any ideas on how to do juju ha across regions (or vsphere dc)?
[17:47] <rick_h> hml: hmm, can you add-machine into the region and try to enable-ha --to ?
[17:47] <rick_h> hml: I think it'll be on your to make sure the controllers are reachable on a network level there
[17:47] <hml> rick_h: that was my thought too, just wondering…
[17:47] <rick_h> hml: yea, not tried it but I think that should work
[17:47] <hml> ybaumy: ^^^
[17:48] <hml> rick_h: regions don’t work with placement directives correct?
[17:48] <rick_h> hml: no, they're model level when you add-model and such
[17:48] <rick_h> hml: as all of the model is in the same region, otherwise there could be issue
[17:49] <rick_h> hml: region->region would need to be a CMR setup and controllers don't do that atm
[17:49] <hml> rick_h: right
[18:00] <ybaumy> rick_h: hml thanks for clearing that up. but from a HA perspective its suboptimal
[18:01] <rick_h> ybaumy: I'm sure there's ways to do it differently but my experience with clouds has been regions are for fallback and cross region coms can be slower/more $$ then inner region.
[18:01] <rick_h> having a controller in different regions raises all kinds of questions about the workloads in that region/etc.
[18:04] <ybaumy> rick_h: from your perspective its ok to handle it this way. from mine it doesnt since datacenters are only few kilometers away
[18:05] <ybaumy> rick_h: so HA is something im looking for
[18:05] <rick_h> ybaumy: understand, it's an interesting perspective and if the networking/latency is good I can see that. It starts to feel like regions should be zones in that situation as far as spreading all units of workloads out across them as well.
[18:06] <rick_h> I mean if the region goes boom than any workloads the controller is managing goes with it
[18:06] <ybaumy> rick_h: well im talking on premise cloud though
[18:06] <rick_h> ybaumy: right, do you have zones in each region?
[18:07] <ybaumy> rick_h: thats a different approach
[18:07]  * rick_h is curious how it's setup
[18:08] <ybaumy> currently we spread masters and workers and etcd 's accross two datacenters. pods are also setup in a way to handle workloads if one DC is out
[18:08] <ybaumy> kubernetes is what we are interessted in with juju
[18:08] <rick_h> ybaumy: which on prem cloud is this? /me reads back
[18:09] <rick_h> oic, vsphere
[18:09] <ybaumy> rick_h: our companies vsphere
[18:09] <ybaumy> rick_h: we are using openshift atm from redhat but it costs .. though im looking into other directions
[18:10] <rick_h> yea, I'm not familiar with vsphere as much. I know in maas/openstack the we think of zones as you're doing dc's in vsphere. It's why we're hitting this mismatch as we obviously really care/want to have HA whereever possible in Juju and the workloads running.
[18:10] <ybaumy> rick_h: we would really like to see that
[18:12] <ybaumy> rick_h: first i made test with maas and vsphere and juju and then on top kubernetes but maas lets is also not what i want. 2.3 is really neat
[18:12] <ybaumy> juju 2.3
[18:12] <ybaumy> i like that its talking directly now with API
[18:12] <rick_h> ybaumy: I'm glad you're finding Juju interesting. I wish I had better news on the cross zone HA setup. Like I was saying, you can work around it by manually adding machines I think, but then once you go deploy things they'll only go into the original region which isn't what you're going to want
[18:14] <ybaumy> rick_h: maybe in the future. tomorow our architects will get a presentation with juju setup from me. i hope they like it
[18:14] <ybaumy> as much as i do
[18:14] <rick_h> ybaumy: in the long run it'd be interesting with 2.3 and cross model relations if the charms in k8s could treat relations across the models as a way to do its HA work and so you'd just deploy two k8s and relate them and they'd combine into a super k8s
[18:14] <rick_h> ybaumy: cool, let us know if we can be of any help
[18:14] <ybaumy> rick_h: i will give a feedback
[18:14] <rick_h> <3
[18:15] <ybaumy> im the canonical guy though .. most ppl think of canonical as desktop client OS and services
[18:15] <ybaumy> i hope i can change that
[18:19] <rick_h> ybaumy: same here, we've put a lot of time and effort beyond the desktop :)
[18:22] <ybaumy> rick_h: in germany i tell you its really hard to find ppl who use ubuntu and other serivces professionaly
[18:23] <rick_h> ybaumy: ah you're in germany? Yea, that's a tough nut there. Wasn't/isn't germany still very suse friendly as they were from there?
[18:24] <ybaumy> rick_h: we use suse for SAP of course cause there is no competition in this case. we use redhat and centos for everything else. but you are right SuSe is really popular
[18:25] <ybaumy> i tried their container platform lol
[18:26] <ybaumy> and ceph storage
[18:26] <ybaumy> its full of bugs
[18:26] <ybaumy> you just cant use it
[18:26] <ybaumy> SLES enterprise server is really stable for SAP and HANA
[18:32] <ybaumy> anyways i call it a day. beer is waiting. ttyl


[01:50] <cyphermox> Pharaoh_Atem: no, I'm sorry I can't right now. I'm busy with other stuff that must take priority for the time being. I will get to it as soon as I have a chance
[07:51] <cpaelzer> thanks coreycb
[16:29] <LocutusOfBorg> Unit193, looks like jbicha syncd assaultcube-data...
[16:29] <LocutusOfBorg> and assaultcube
[23:01] <Unit193> Unfortunate.


[10:08] <Odd_Bloke> How do tests get run against charms; trying to understand how I can (a) include unit testing in test runs, and (b) replicate what is done elsewhere.
[11:32] <lazyPower> Odd_Bloke: there is a project called bundletester which is pip installable (in a venv) - and it sniffs out the tests in teh charm
[11:32] <lazyPower> Odd_Bloke: the unit test setup is different between charms, so bundletester evaluates a makefile to find the test targets
[11:33] <lazyPower> Additionally, if you have the package `charm-tools` installed - you can issue 'charm add tests' and it will setup a test scaffolding for integration tests using amulet.
[11:35] <Odd_Bloke> lazyPower: Thanks!
[11:37] <lazyPower> No problem
[12:11] <Odd_Bloke> I'm hitting a traceback with bundletester: https://gist.github.com/anonymous/389baade22b077abd190
[12:11] <Odd_Bloke> The tests are those generated by "juju charm create".
[12:13] <lazyPower> tvansteenburgh: are we tracking bundletester bugs on github or launchpad?
[12:13] <tvansteenburgh> lazyPower: let's use github
[12:14] <lazyPower> Odd_Bloke: can you file a bug against the project here: https://github.com/juju-solutions/bundletester
[12:16] <Odd_Bloke> https://github.com/juju-solutions/bundletester/issues/2
[12:17] <lazyPower> Thanks Odd_Bloke
[12:17] <tvansteenburgh> Odd_Bloke: for a workaround you might try downgrading juju-deployer to 3.8
[12:18] <tvansteenburgh> Odd_Bloke: i don't have time to test it right now but that's what i'd try first
[12:19] <Odd_Bloke> Trying that now.
[12:20] <Odd_Bloke> tvansteenburgh: lazyPower: Same traceback.
[12:21] <tvansteenburgh> Odd_Bloke: gimme a min, i'll give it a try
[12:22] <Odd_Bloke> tvansteenburgh: Thanks. :)
[13:06] <natefinch> man, digital ocean is so much faster than AWS
[13:06] <natefinch> deploying my discourse charm takes 21 minutes on AWS and 7 on DO
[13:09] <marcoceppi> natefinch: welcome to the world of SSDs
[13:09] <tvansteenburgh> Odd_Bloke: i haven't been able to repro that error. i have some other things i need to do atm but will circle back
[13:09] <marcoceppi> natefinch: also, congrats on the deployment
[13:09] <marcoceppi> natefinch: finally, haha at it taking forever with docker :P
[13:10] <natefinch> marcoceppi: right?  It looks like they do a crapload of stuff after the docker image is deployed... no idea why
[13:10] <marcoceppi> natefinch: because why bother using imaged based workflows ;)
[13:13] <natefinch> marcoceppi: "I: relation website has no hooks"  .... I don't actually know if I should have a hook for that relation or not?  is there something I would need to do with that?  Are there docs I can look at for what that should do?
[13:14] <marcoceppi> natefinch: no docs, just examples of charms that implement that relation at the moment. We;re working on a way to documentate relations
[13:14] <natefinch> marcoceppi: IIRC we talked about documenting relations a year ago ;)
[13:14]  * marcoceppi gets the long list of core features that were discussed a year ago and don't exist
[13:14] <marcoceppi> ;)
[13:15] <lazyPower> zing!
[13:15] <marcoceppi> natefinch: here's an example http://bazaar.launchpad.net/~charmers/charms/precise/wordpress/trunk/view/head:/hooks/website-relation-joined
[13:17] <natefinch> marcoceppi: ok, so it looks like I could just copy and paste that, right?
[13:17] <marcoceppi> natefinch: and replace the port with the right value
[13:17] <marcoceppi> typically it's 80, depends on the service
[13:17] <natefinch> marcoceppi: what's the right value?
[13:18] <marcoceppi> natefinch: whatever port the service runs on
[13:18] <natefinch> marcoceppi: so just the value the service is listening on?
[13:18] <natefinch> marcoceppi: ok
[13:45] <lazyPower> jcastro, mbruzek: https://github.com/juju/docs/pull/171
[13:46] <jcastro> I don't like the term "user space charms"
[13:46] <jcastro> Just say "charms in your personal namespace"
[13:46] <jcastro> otherwise that's like another new term people won't understand
[13:48] <lazyPower> jcastro: updated
[13:48] <rick_h_> jcastro: or even just your published charms?
[13:48] <jcastro> yeah
[13:49] <rick_h_> jcastro: lazyPower just to start to beat the drum on the publishing idea as we move that forward.
[13:49] <lazyPower> rick_h_: I'm going to bake you a cake when 'publish' lands.
[13:50] <lazyPower> and i'll send a print copy of the reworked doc page when that happens.
[13:50] <natefinch> space charms sound pretty cool though
[13:51]  * natefinch whistles the star trek theme
[14:27] <josepht> to boldly deploy where no charm has gone before
[14:44] <natefinch> jcastro: maybe I'm not understanding what you mean by version specific stuff in charms.  Actions won't ever work in 1.18, therefore it's a version specific feature in a charm, isn't it?
[14:44] <jcastro> right
[14:44] <jcastro> I think having version specific anything in charms is a bad idea
[14:45] <natefinch> but my point is, if there's ever a new feature we want to support in a charm, it'll be version specific
[14:45] <jcastro> right
[14:45] <jcastro> I think if you were to tell a charm author
[14:45] <natefinch> and we need new features, unless you want to tell Mark S we can't do actions :)
[14:45] <jcastro> "check out these new features, but 1.20 only"
[14:46] <jcastro> my answer would be "well I'm not going to add it to my charm until someone asks for it."
[14:46] <jcastro> I would tell people "upgrade to 1.20"
[14:46] <jcastro> I wouldn't make my charm more complex
[14:52] <natefinch> jcastro: I guess I look at it differently.  I'd see all the new functionality in 1.20 and say "hey, this could make my charm a lot more useful to people", so I'd update it and tell people to get off their butts and upgrade ;)
[14:53] <jcastro> sure
[14:53] <jcastro> until you realize that most people are and will remain on 1.18
[14:53] <jcastro> I would just be like "this charm requires 1.20"
[14:53] <natefinch> jcastro: that's what we're doing
[14:54] <jcastro> yeah but this lets you pick and choose afaict.
[14:54] <natefinch> jcastro: in implementation, yes, but in actuality... feature X and Y will require 1.20, and feature Z will require 1.21, so if you use all three, your charm effectively requires 1.21
[14:55] <jcastro> right, so why not just something simpler like "> 1.21"
[14:55] <jcastro> like how packages do it?
[14:55] <jcastro> I feel like the granularity will just end up with different permutations for everything
[14:56] <jcastro> in the worst place to have it, the store
[14:56] <natefinch> I think that's perfectly valid.  It wasn't my design.... I think it was William's... who is conveniently out today :)
[14:58] <natefinch> I can guess about why it was done this way - so that if you backport a feature, the charms that use that feature all of a sudden work in the old version, rather than having a hard-coded revision number
[14:59] <jcastro> well, I think of it this way
[14:59] <natefinch> but it is significantly less obvious to the end user what versions will support any particular charm... they have to go look up the documentation for each feature and see what version it supports
[14:59] <jcastro> we know X version of juju is in Ubuntu version Z
[14:59] <jcastro> those charms are series'ed
[14:59] <jcastro> so I know on precise I'll have Juju version X with charm version Z
[15:00] <jcastro> when I move to trusty, I'll have X+1 and Z+1
[15:00] <jcastro> the charm might or might not have new features based on what corresponding version of juju comes with that new version of ubuntu
[15:00] <jcastro> basically, charm series are already tied to juju core versions we ship
[15:01] <jcastro> so if I want to use juju actions I'll use utopic charms
[15:01] <jcastro> but I wouldn't update the precise charm to use actions
[15:01] <natefinch> that's a very interesting point
[15:01] <jcastro> and if you use a PPA on an older serioes
[15:01] <jcastro> blam, you use the newer series charm as well, even on the old distro
[15:02] <jcastro> then it's easier for us to say
[15:02] <natefinch> the only problem then, is that you're now requiring that charms with new features use a non-LTS host OS
[15:02] <jcastro> "if you want to use actions, you need to put them in charms utopic and newer"
[15:03] <jcastro> not really, we're only doing LTS series anyway
[15:04] <natefinch> wait, so are you saying you'd deploy the utopic charm to Trusty?
[15:04] <jcastro> well we don't have utopic charms, that was an example
[15:04] <jcastro> it'd be whatever the next LTS is
[15:05] <natefinch> ok, so no new features until 2016 then?
[15:05] <jcastro> land as many as you want
[15:05] <jcastro> but like the "trusty" and "precise" stores are pretty much locked to the published version of juju in them
[15:06] <jcastro> which is why in the mail I think moving to getting newer juju's backported to those is a nicer win
[15:06] <jcastro> because then you'd bring them up along with you instead of having them hold you back
[15:08] <jcastro> (I realize that's also another set of problems)
[15:08] <natefinch> yeah... believe me, we'd love to have 1.20 in precise and trusty
[15:09] <natefinch> I think we're working on getting it into trusty, actually
[15:09] <jcastro> I just really think having version fragmentation in the store will be bad
[15:10] <jcastro> I mean, the hard truth is our customers and users use LTSes, and don't want radical change
[15:10] <jcastro> shifting the change from juju to the store seems just as bad to me, if not worse
[15:10] <jcastro> "don't worry, juju itself won't change, now we'll just put all the churn in the charm instead!"
[15:12] <natefinch> the problem is really that we just can't force people to upgrade
[15:13] <natefinch> I'm sure there's people out there running merrilly long with a 1.14 juju server, and someday they're going to say "hey, you know what? I want X new charm" and do juju deploy foo ... and it'll not work, in some weird and non-obvious way
[15:13] <natefinch> the point of this code is to make it not work in an obvious and immediate way
[15:15] <marcoceppi> woo who! pprint lands in trunk https://github.com/juju/juju/pull/757
[15:16] <marcoceppi> juju status --format=oneline
[15:18] <natefinch> nice!
[15:39] <aisrael> lazyPower: are there test lab credentials re https://bugs.launchpad.net/charms/+bug/1325700 that you can share, or should I assign it to you to re-review?
[15:39] <mup> Bug #1325700: New Charm: Dell OpenManage Server Administrator (OMSA) <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1325700>
[18:37] <aisrael> Has relation-list been deprecated?
[18:47] <arosales> aisrael: not sure, but be a good question to pop into #juju-dev
[18:47] <aisrael> ack
[18:47] <arosales> got a DB questoin from the folks working on the Zend charm.
[18:47] <arosales> "When I add MySQL relation I need 2 seperate DBs. One for Zend Server cluster data and one for the application. When I ask for "db_db=`relation-get database`" I get a database name "zend-server". Is it possible to get another DB from the same MySQL unit for Magento?"
[18:48] <arosales> hints/tips/tricks on how to create two DBs from one relation?
[18:49] <fuzzy_> in SQL it's called views
[18:50] <fuzzy_> where you can build a view of a dataset
[18:50] <fuzzy_> But I think your question is more Zend related :)
[18:59] <arosales> fuzzy_: thanks for the comments. I may have to see how the zend folks are trying to use this in their charm.
[19:00] <fuzzy_> If you have sql questions, feel free to ask
[21:07]  * arosales taking a look at the review queue
[21:07]  * arosales reviwing nginx
[21:08] <arosales> filled https://github.com/marcoceppi/review-queue/issues/9  -- not auto charm testing comment
[21:12] <jcastro> if I have a directory in my charm
[21:12] <jcastro> say "files/"
[21:12] <jcastro> where I want to put like random config files I want on the units
[21:12] <jcastro> when calling it from say an install hook, what's the pwd?
[21:12] <jcastro> will "cp -f files/foo destination" work?
[21:32] <arosales> mbruzek: can I get you to kick off a tests for the items in the review queue?
[21:32] <arosales> s/a//
[21:32] <mbruzek> sure
[21:32] <arosales> mbruzek: specifically the ones that don't have a test stuat
[21:33] <mbruzek> arosales: when I tried this yesterday it did not work for me let me try again today.
[21:33] <arosales> ah ok, let me know if it still fails
[21:34] <mbruzek> arosales: I did the Review Queue with Jose yesterday and told him about the new feature.
[21:34] <mbruzek> But I was unable to kick new tests off
[21:34] <mbruzek> arosales: I was incorrect, it does seem to work today.
[21:34] <arosales> mbruzek: ah ok, good to hear
[21:34] <mbruzek> specifically which ones?
[21:35] <mbruzek> arosales: all of them in the queue?
[21:36] <mbruzek> kicked them all off.
[21:38] <arosales> yes, I think they all need a test before ack
[21:38] <arosales> mbruzek: thanks
[22:22] <ayr-ton> Two quick questions, maybe is good to have this on askubuntu later. In the future will be possible to add relations between environments? And a friend of mine asked about official support do centos deployments.
[22:26] <alexisb> ./join #docker-dev
[22:39] <ayr-ton> alexisb, docker-dev?
[22:41] <alexisb> ayr-ton, yeah I added the "." by mistake
[22:41] <ayr-ton> Ah, ok.
[22:54] <arosales> ayr-ton: re your question, it is on the road map to have juju have relations between environments.  Its been dubbed cross environment relaitons.
[22:54] <arosales> s/relaitons/relations
[22:54] <arosales> charmer needed to update https://code.launchpad.net/~jorge/charms/trusty/mysql/fix-proof/+merge/234020
[22:55] <ayr-ton> interesting.
[22:55] <arosales> its been superceded by https://code.launchpad.net/~a.rosales/charms/trusty/mysql/add-default-keys/+merge/235064
[23:05] <arosales> charmer also needed to update the MP status on https://code.launchpad.net/~tvansteenburgh/charms/precise/block-storage-broker/fix-tests/+merge/234168