[04:29] <blahdeblah> thumper: you around?
[13:36] <[Kid]> kwmonroe, that means anything i deploy with juju has to be in a cloud. I have two sites that i manage and would do cloud, but it is only a tertiary option.
[16:43] <skay> for my charm, I have a db relation, and call set_database and set_roles when the relation is joined. why does the relation not reflect the dbname when I get the relation info?
[16:47] <bdx> skay: hey
[16:47] <skay> o/
[16:48] <bdx> I've beaten that path
[16:48] <bdx> so
[16:48] <bdx> I know @stub is/was aware of this, as I brought it to his attention when I was having trouble it
[16:48] <bdx> the solution
[16:49] <skay> (is there a bug I can subscribe to to keep up to date?)
[16:49] <bdx> looking
[16:49] <skay> thank you
[16:49] <skay> meanwhile, halp
[16:49] <skay> :)
[16:50] <skay> s/halp/thanks
[16:51] <bdx> np
[16:52] <bdx> so, I cant find the bug
[16:52] <bdx> https://bugs.launchpad.net/postgresql-charm
[16:52] <bdx> there are only ~12 bugs there
[16:52] <kwmonroe> skay: what's the database that you're connecting?
[16:52] <kwmonroe> mysql/maria/db2/pgres?
[16:52] <bdx> and I dont see any the ones I've filed in the past
[16:52] <bdx> postgresql
[16:52] <bdx> I just assumed you were using postgresql too because of the functions you are calling
[16:53] <skay> kwmonroe: postgresql
[16:54] <skay> bdx: how did you work around it?
[16:57] <bdx> https://bugs.launchpad.net/postgresql-charm/+bug/1618248
[16:57] <bdx> finally
[16:57] <bdx> ha
[16:58] <bdx> I had to search by bug number
[16:58] <bdx> it looks to be private or something
[16:59] <bdx> having a tough time finding the mailing list thread
[16:59] <bdx> anyway
[16:59] <skay> oh. I wonder if that is a mistake
[17:00] <bdx> yeah, possibly it has been fixed by using the api differently
[17:01] <bdx> if the api did change (which it sounds like it did), then I havent started using  it yet in my charms and probably need to refactor my postgresql relations to take advantage of this
[17:03] <bdx> my work-around was to do this https://github.com/jamesbeedy/layer-django-web/blob/master/reactive/django_web.py#L70,L74
[17:03] <bdx> but it was really just a poor cover up
[17:04]  * bdx ashamed to have moved forward with ^ in so many places previously
[17:05] <kwmonroe> yeah skay, it looks like the requested db name gets stored as part of the connection string, so parsing it back out like bdx did (pgsql.master.dbname) seems like a fine way to get it back.
[17:06] <skay> kwmonroe: while debugging my hook, I did a relation-get to see the connection string, and it does not have the appropriate name
[17:06] <skay> it's named after the unit (which is the default,right?)
[17:06] <skay> I mean the app
[17:06] <bdx> yea
[17:06] <skay> I could get it from my charm's config if I need to
[17:07] <skay> as a work around
[17:07] <skay> if someone could subscribe me to the bug, I'd appreciate it so that I can keep track for when I don't need a workaround
[17:07] <skay> ~codersquid
[17:08] <bdx> skay: I think this has been fixed though
[17:08] <kwmonroe> fwiw, i can't see the bug that bdx opened
[17:08] <bdx> oh
[17:08] <bdx> just subscribed both of you
[17:11] <kwmonroe> cool, i'm in bdx.  skay's issue feels a bit different though.  sounds like if you don't explicitly call pgsql.set_database, pg will default to the unit name, yet that dbname isn't coming back with pgsql.master data.
[17:11] <skay> what is happening to me is that my charm joins a db relation with the posgresql charm
[17:12] <skay> and when I get the relation, it is not reflecting the dbname I set when the relation was joined
[17:12] <skay> I could maybe make a tiny charm to demonstrate
[17:12] <bdx> oh totally, I linked the wrong bug
[17:12] <bdx> darn
[17:12] <skay> I explictely call pgsql.set_database
[17:14] <kwmonroe> ah, ok skay, i wasn't sure if you were calling set_db or not.  either way, sounds like a new bug to me if the connection string from an available pg master doesn't contain the dbname.
[17:14] <skay> I'll go ahead and write a small example and file a new bug
[17:14] <bdx> here's another bug I have open in that area https://bugs.launchpad.net/interface-pgsql/+bug/1666337
[17:14] <mup> Bug #1666337: 'NoneType' object has no attribute 'uri' <pgsql Interface for charms.reactive:Fix Released> <https://launchpad.net/bugs/1666337>
[17:16] <bdx> here's the mailing list thread https://lists.ubuntu.com/archives/juju/2017-February/008638.html
[17:16] <bdx> well, @skay possily I didnt file a bug on your exact issue
[17:16] <bdx> or at least I cant find it .... I had a lot going on with that charm/interface for a while as you can see
[17:18] <bdx> I know I've hit what you are describing though
[17:19]  * skay nods
[17:19] <bdx> and I would have filed a bug had I hit this
[17:19] <bdx> but meh
[17:19] <bdx> srry
[17:19] <bdx> lol
[17:22] <bdx> so essentially, I think the first bug I linked is this bug
[17:22] <bdx> because you are getting back the wrong db
[17:22] <bdx> it means that the rest of the information in the relation is also incorrect
[17:23] <bdx> because there is a user/database/password affinity
[17:23] <bdx> so if you are getting the wrong db back
[17:23] <bdx> then everything else is wrong too
[17:23] <bdx> not just the db
[20:34] <kwmonroe> rick_h: is there a fast way to clear the hook queue for a failed unit?  [Kid] had a unit go into error state and he wanted to remove it.  however, leadership-hook-foo and like 9 other hooks queued up, so he had to 'resolved --no-retry' 10 times before the remove-unit could go to work.
[20:35] <kwmonroe> maybe like a --force on remove-unit could auto resolve a unit?
[20:43] <rick_h> kwmonroe: nothing I'm aware of, I wonder if you restart the agent what happens
[20:48] <kwmonroe> dunno rick_h, none of my units ever go into error state ;)  but i'll try to wedge one and see what agent horrors i can perform.
[21:03] <[Kid]> kwmonroe, everything is right again
[21:03] <[Kid]> i about about to re-deploy
[21:04] <kwmonroe> woohoo!