=== shadoxx_ is now known as shadoxx [04:29] thumper: you around? === frankban|afk is now known as frankban [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] 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] skay: hey [16:47] o/ [16:48] I've beaten that path [16:48] so [16:48] I know @stub is/was aware of this, as I brought it to his attention when I was having trouble it [16:48] the solution [16:49] (is there a bug I can subscribe to to keep up to date?) [16:49] looking [16:49] thank you [16:49] meanwhile, halp [16:49] :) [16:50] s/halp/thanks [16:51] np [16:52] so, I cant find the bug [16:52] https://bugs.launchpad.net/postgresql-charm [16:52] there are only ~12 bugs there [16:52] skay: what's the database that you're connecting? [16:52] mysql/maria/db2/pgres? [16:52] and I dont see any the ones I've filed in the past [16:52] postgresql [16:52] I just assumed you were using postgresql too because of the functions you are calling [16:53] kwmonroe: postgresql [16:54] bdx: how did you work around it? [16:57] https://bugs.launchpad.net/postgresql-charm/+bug/1618248 [16:57] finally [16:57] ha [16:58] I had to search by bug number [16:58] it looks to be private or something [16:59] having a tough time finding the mailing list thread [16:59] anyway [16:59] oh. I wonder if that is a mistake [17:00] yeah, possibly it has been fixed by using the api differently [17:01] 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] my work-around was to do this https://github.com/jamesbeedy/layer-django-web/blob/master/reactive/django_web.py#L70,L74 [17:03] 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] 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] 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] it's named after the unit (which is the default,right?) [17:06] I mean the app [17:06] yea [17:06] I could get it from my charm's config if I need to [17:07] as a work around [17:07] 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] ~codersquid [17:08] skay: I think this has been fixed though [17:08] fwiw, i can't see the bug that bdx opened [17:08] oh [17:08] just subscribed both of you [17:11] 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] what is happening to me is that my charm joins a db relation with the posgresql charm [17:12] and when I get the relation, it is not reflecting the dbname I set when the relation was joined [17:12] I could maybe make a tiny charm to demonstrate [17:12] oh totally, I linked the wrong bug [17:12] darn [17:12] I explictely call pgsql.set_database [17:14] 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] I'll go ahead and write a small example and file a new bug [17:14] here's another bug I have open in that area https://bugs.launchpad.net/interface-pgsql/+bug/1666337 [17:14] Bug #1666337: 'NoneType' object has no attribute 'uri' [17:16] here's the mailing list thread https://lists.ubuntu.com/archives/juju/2017-February/008638.html [17:16] well, @skay possily I didnt file a bug on your exact issue [17:16] 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] I know I've hit what you are describing though [17:19] * skay nods [17:19] and I would have filed a bug had I hit this [17:19] but meh [17:19] srry [17:19] lol [17:22] so essentially, I think the first bug I linked is this bug [17:22] because you are getting back the wrong db [17:22] it means that the rest of the information in the relation is also incorrect [17:23] because there is a user/database/password affinity [17:23] so if you are getting the wrong db back [17:23] then everything else is wrong too [17:23] not just the db === frankban is now known as frankban|afk === TikTok is now known as michealb [20:34] 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] maybe like a --force on remove-unit could auto resolve a unit? [20:43] kwmonroe: nothing I'm aware of, I wonder if you restart the agent what happens [20:48] 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] woohoo! === rick_h_ is now known as rick_h === icey_ is now known as icey === arosales_ is now known as arosales === wpk_ is now known as wpk === skay is now known as Guest71369