[08:29] <jam> manadart: just making some coffee will be a couple min late
[08:29] <manadart> jam: Ack.
[09:21] <jam> manadart: any chance you could look at https://github.com/juju/juju/pull/8654
[09:21] <jam> it handles the Addresses() being empty
[09:22] <manadart> jam: Yep.
[09:26] <manadart> jam: LGTM'd
[13:10] <jam> stickupkid: I confirmed your change on 8655, do you want to $$merge$$ your first PR?
[13:12] <stickupkid> sure :D
[13:12] <jam> stickupkid: I like your GH profile picture
[13:14] <jam> stickupkid: can you set up a pic for Trello as well? It can be the same pic, just nice to have something than SR
[13:14] <stickupkid> jam: yeah of course
[13:19] <jam> hml: you also still just have your "HL" in trello.
[13:30] <jam> manadart: there was always "if it compiles, ship it", now we also have "if it bootstraps, ship it" :)
[13:31] <manadart> jam: Words to live by :)
[13:33] <manadart> Some thing to go on the next Juju shirt/sticker/flair.
[16:50] <rick_h_> bdx: cory_fu_ kwmonroe hml magicaltrout zeestrat and folks juju show in an hour. Party time!
[17:51] <rick_h_> getting the hangout setup
[17:51] <rick_h_> if you want to watch the stream hit up https://www.youtube.com/watch?v=cxAsJpmwDFE
[17:53] <rick_h_> https://hangouts.google.com/hangouts/_/qmpic4iiazfmffm7to5kw7ohq4e if you want to chat on the call
[17:53] <rick_h_> zeestrat: bdx coreycb kwmonroe hml and anyone else interested ^
[18:03] <balloons> rick_h_, bionic release hype! Folks should use 2.3.7 or 2.4-beta1 client to be ready for it :-)
[18:30] <rick_h_> thanks zeestrat, appreciate you joining in!
[18:30] <rick_h_> third time you join you have to show something cool, no pressure :P
[18:30] <rick_h_> first two are free lol
[18:30] <zeestrat> rick_h_: That's how they get you!
[18:33] <zeestrat> rick_h_: Yeah, I had a small blog post about some juju upgrade woes a couple of weeks ago, but I need to up my game to match stub's posts. Just got a large shipment of supermicro boxes that we're going to expand our juju deployed ceph cluster with. Been hitting (and fixing) the ceph-osd charm a bit to make that smooth so might write up something there.
[18:33] <rick_h_> zeestrat: love it, and saw your upgrade post. Thanks for that. Was solid.
[18:33] <rick_h_> well, sucked you hit the bugs there, but good stuff that folks helped out and you pushed through and got things rocking
[18:36] <zeestrat> rick_h_: Yupp, things got sorted in the end and it seems the guys will be focusing more on testing which is great. Not to mention having dedicated staging setups has saved our butts more than once.
[18:37] <rick_h_> Yea, good practices are good practices for sure.
[18:38] <zeestrat> rick_h_: Can't promise a live upgrade of our prod cluster, but let me see if I can cobble together something fun.
[20:10] <thumper> morning team
[20:31] <balloons> thumper, good morning
[20:34] <veebers> Morning o/
[21:55] <TheAbsentOne> As it is almost midnight for me I will be offline soon but are there expert charm writers online right now by any chance?
[21:55] <magicaltrout> whats broken TheAbsentOne ?
[21:56] <TheAbsentOne> nothing is (yet) but I want huge insights and opinions :D
[21:56] <magicaltrout> ha
[21:56] <TheAbsentOne> is it okay to post dropbox url (pdf) here magicaltrout ?
[21:56] <magicaltrout> sure
[21:56] <TheAbsentOne> https://www.dropbox.com/s/adiyp4qqkx4wg3i/Charm%20prototypingv0.pdf?dl=0
[21:57] <magicaltrout> ah this badboy
[21:57] <TheAbsentOne> I created a document to illustrate what I want to create and I want some tips and help from the real experts ^^
[21:57] <TheAbsentOne> hehe sorry man!
[21:59] <TheAbsentOne> I added the link to a github repo where everybody can leave a response as well (if I would be offline). I'll ask it tomorrow again though no worries. You guys will be mad at me soon enough x)
[22:01] <magicaltrout> i do like this idea TheAbsentOne. So in simple terms its an SQL dump for a bunch of different databases, and depending on which you connect to it will install the correct database and provide connection details?
[22:02] <TheAbsentOne> magicaltrout: so yeah you can actually see it even bigger and add nosql technologies to the stack as well
[22:02] <magicaltrout> yeah i used sql as the common example
[22:02] <magicaltrout> but json dump or whatever
[22:03] <TheAbsentOne> yeah exactly and the generic-database charm handles all complex material if the requirements are not clear. And if let's say the using charm knows it's stuff it will just act as a proxy
[22:03] <magicaltrout> i have a few questions off the top of my head
[22:04] <TheAbsentOne> sure shoot!
[22:04] <magicaltrout> a) why not ship the schema with the application, and import the database at relation connection time to the app? rather than the proxy charm
[22:05] <magicaltrout> b) if developer a updates the webapp but the schema differs from v1 to v2 and someone then deploys the 2 charms it'll die horribly, how is that mitigated?
[22:06] <TheAbsentOne> a) We really want a charm that represents a database (and not a service). The major use would be to have the ability to have multiple charms to "easily" connect to the same database.
[22:06] <TheAbsentOne> And I kinda think that also answers the b question. If a developer updates the webapp, the database itself is not changed whatsoever
[22:07] <magicaltrout> ah yeah the multiple charm thing, i did read that!
[22:08] <magicaltrout> in answer to your questions, i think you're right in keeping the mid layer simple that way it can be leveraged by more projects
[22:08] <magicaltrout> and
[22:08] <TheAbsentOne> My whole conceptual idea of my research comes down to modeling things in juju that are not services and in my specific case it's about databases. But the same use case could be mapped to load balancers, message brokers, topics, caches
[22:09] <magicaltrout> you can't delete relations to my knowledge, but you could block up th eothers so if they end up being used you could publish a status message saying "We're serving on database x, your database y connection will have no effect"
[22:09] <magicaltrout> or something of that nature
[22:11] <TheAbsentOne> Right, that would be a good solution. The only thing that kinda feels awkward right now is that I assume relations are made between the providing technology charms (the charms from the charm store) and my generic-database. So this means that for every non-used database technology a useless database will be created because that is default behaviour right now, right?
[22:12] <TheAbsentOne> A second step (if I get this generic-database charm to work) would be to use libjuju to dynamically deploy the services on the fly, resolving this issue. But I'm a bit scared to use libjuju right now (as I'm a still a complete beginner/noob)
[22:12] <magicaltrout> pretty much
[22:13] <TheAbsentOne> That isn't the end of the world though in this proof of concept ^^
[22:14] <TheAbsentOne> So do you thing the structure of the charm is somewhat okay? Do you think it's feasible magicaltrout?
[22:14] <magicaltrout> i think its perfectly viable TheAbsentOne i like the idea. For example I'm working on a bunch of data viz and SQL tooling
[22:15] <magicaltrout> so in using that, I'd get connectivity to your app in Apache Drill or something with zeroconf
[22:15] <magicaltrout> at which point I can then expose the schema to the data viz tools who know about it automatically
[22:16] <TheAbsentOne> That's really cool to hear. I have no experience with drill or zeroconf so I'm not completely following but it would be cool if it could help others too!
[22:16] <magicaltrout> well i deal in the data analysis sector
[22:16] <magicaltrout> so if I can tap into your "webshop" without knowing anything about it to provide more reports etc
[22:16] <TheAbsentOne> Great I will start on setting up a repo asap and hopefully I get somewhere
[22:16] <magicaltrout> thats a good thing
[22:16] <TheAbsentOne> yes exactly!
[22:17] <TheAbsentOne> that's exactly the goal actually
[22:17] <magicaltrout> well then
[22:17] <magicaltrout> make it so!
[22:17] <TheAbsentOne> hehe I will do my best. But first some sleep. Talk to you later and thanks for looking into it!
[22:18] <magicaltrout> no probs
[22:18] <magicaltrout> have a good night
[22:51] <veebers> could I get a quick review for this please? https://github.com/juju/juju/pull/8658 adds a file that should have been added in my original PR.
[22:52] <veebers> currently looking at updating the merge/check jobs to catch stuff like this.
[22:53] <thumper> veebers: why is this check-merge failing? https://github.com/juju/juju/pull/8651
[22:54] <thumper> I can't work it out
[22:54]  * veebers looks
[22:55] <veebers> thumper: odd, probably related to a change I made this morning so the checkout failed on error (instead of ignoring it). I'll get it sorted now
[22:55] <thumper> veebers: thanks, I was just confused
[22:59] <veebers> thumper: fixed now, the script was doing "git config core.sparseCheckout" instead of "git config core.sparseCheckout true" so was exiting non-zero (with no error message)
[22:59] <thumper> ah
[22:59] <thumper> what is the sparse checkout option?
[23:02] <veebers> thumper: here it's intended to reduce the amount of work when pulling, checking out and merging a PR. Although the fact that it's never actually been properly set makes me question it's worth. Perhaps I should remove it. Although I'll see how the fixed run goes
[23:13] <veebers> kelvinliu: Do you have your lint fixes in a separate PR? If not I might do a quick fix now as I'm adding checks to the merge/check job :-)
[23:16] <thumper> veebers: it passed the check this time
[23:17] <veebers> thumper: ack, the issue was an error in the checkout script, I added -eux to catch merge errors early etc. seems it was glossing over that issue earlier
[23:20] <kelvinliu> veebers, not yet. yeah, you can do. appreciate for that. ^^
[23:21] <veebers> kelvinliu: ack, sounds good.
[23:26] <thumper> wallyworld: got 5 minutes?
[23:26] <wallyworld> thumper: after standup, sure, give me 15
[23:26] <thumper> wallyworld: I'm trying to recall how we gracefully degrade in commands when facades don't define the methods we want
[23:28] <anastasiamac> thumper: we call the previous call version of any... for example - https://github.com/juju/juju/blob/develop/cmd/juju/application/config.go#L272
[23:29] <anastasiamac> thumper: or just err out if no equivalent existed - https://github.com/juju/juju/blob/develop/cmd/juju/application/addunit.go#L201
[23:31] <thumper> that has the client explicitly checking api version
[23:31] <thumper> which I guess I could do
[23:31] <thumper> rather than making the api call itself
[23:31] <thumper> probably better that way
[23:32] <thumper> there was an error returned from the facades if the method wasn't there but I can't seem to find a reference
[23:37] <anastasiamac> ha, dunno of any specialised errors coming from there except for NotFound and NotImplemented..
[23:38] <wallyworld> thumper: free now, just finished standup
[23:38] <wallyworld> we do use BestVersion()
[23:38] <wallyworld> to check up front
[23:38] <thumper> wallyworld: yeah, that's what I'm doing now
[23:38] <wallyworld> rather than making the call
[23:38] <thumper> wallyworld: so we don't need to chat
[23:38] <wallyworld> ok
[23:40] <anastasiamac> thumper: wallyworld: well, if u r after a totally complete answer... we do actually check bestapi version at api layer too but mostly if we change args to call between facade versions, for e.g. https://github.com/juju/juju/blob/develop/api/applicationoffers/client.go#L293
[23:40] <anastasiamac> i do not recall that we actually do that for any calls per se