| * vino here | 00:17 | |
| === cassiocassio_ is now known as cassiocassio | ||
| === seyeongkim_ is now known as seyeongkim | ||
| === markthomas_ is now known as markthomas | ||
| === lonroth_scania_ is now known as lonroth_scania | ||
| === WillMoogle_ is now known as WillMoogle | ||
| === jamespage_ is now known as jamespage | ||
| === hazmat_ is now known as hazmat | ||
| thumper | jam: mostly lost ya | 04:11 |
|---|---|---|
| jam | thumper: yeah, was just coming around to ping you. will be right back | 04:11 |
| veebers | ugh, can someone better versed in find/xargs tell me what I'm doing wrong? I just want the file name sans .py etc: "find . -name "assess_*.py" -print0 | xargs -0I{} -n1 echo $(basename {} .py)" | 04:31 |
| anastasiamac | can I plz get a review of https://github.com/juju/juju/pull/8659? | 05:25 |
| jam | manadart: I've started looking at 8656, any chance you could look at 8660 ? | 06:41 |
| jam | anastasiamac: looking. though "similar PR" to what? can you link the PR it is similar to? | 06:42 |
| anastasiamac | jam: where r u seeing similar? | 06:43 |
| anastasiamac | jam: i don't understand what r asking, i think... | 06:43 |
| jam | anastasiamac: in your PR description you say: "Similar PR to ensure" | 06:47 |
| jam | but I don't know what it is similar to | 06:47 |
| jam | anastasiamac: anyway, code reviewed mostly LGTM | 06:48 |
| anastasiamac | jam: my PR description says "simple" | 06:48 |
| anastasiamac | r u sure u r reading the same PR? :D | 06:48 |
| jam | anastasiamac: maybe I need glasses. :) | 06:52 |
| jam | but I swear I read it multiple times | 06:52 |
| anastasiamac | jam: must b one of these days \o/ thnx for looking :D | 06:53 |
| manadart | jam: Yep. | 06:58 |
| jam | manadart: just finishing up lunch, sorry I'm late | 08:33 |
| rts-sander | hey I'm getting on update-series: "ERROR updating the application series is not supported by this API server" | 09:03 |
| rts-sander | even though juju --version gives "2.3.7-xenial-amd64" | 09:03 |
| rts-sander | which should be a feature of 2.3: https://jujucharms.com/docs/2.3/howto-updateseries | 09:03 |
| rts-sander | so what am I doing wrong? | 09:04 |
| rts-sander | guess I'm going to have to go with juju remove-application, and add it again with the correct series which is regrettable | 09:11 |
| anastasiamac | rts-sander: juju --version gives u a client version | 09:19 |
| anastasiamac | rts-sander: to get juju controller version, u'd need to run 'juju status' | 09:20 |
| anastasiamac | that'll give u an "API server" version | 09:20 |
| rts-sander | anastasiamac, ah now I'm getting 2.2.6 | 09:28 |
| rts-sander | there ya go | 09:29 |
| manadart | jam: Approved 8660 with one comment. | 09:48 |
| jam | manadart: thanks. removing hasPriority and changing the pretty function to print it out. | 10:37 |
| manadart | jam: What is point of the "juju/" prefixed alias? | 11:22 |
| jam | manadart: so that we are authoritative about what image we're pointing at. And also so people can change it and know that they aren't changing what "ubuntu/xenial" is, just that we are deciding what to use for juju | 11:41 |
| jam | that said, the official name is actually ubuntu/xenial/amd64 IIRC | 11:41 |
| jam | balloons: for standup stuff. I've been reviewing manadart's patch for LXD. I'll probably still finish that up tonight. And then I've managed to get "juju remove-machine" working when you only have 2 machines left. | 12:19 |
| jam | and we did the Architecture review. | 12:19 |
| jam | and a bit of oracle review | 12:19 |
| jam | manadart: ^^ gabriel has pushed up the changes we asked for, so likely its ready to $$merge$$ the next one. | 12:20 |
| manadart | jam: I will look. | 12:20 |
| manadart | jam: BTW, The image *is* cached when you use CreateContainerFromImage, but without intervention it does not have the juju alias. | 12:24 |
| manadart | So it gets picked up thereafter, but to get the local target, you still need to use the remote server with the alias. | 12:24 |
| manadart | I am working a change now to copy the image and add the alias (rather like before). | 12:25 |
| rick_h_ | kwmonroe: ping if you get a sec | 14:18 |
| rick_h_ | anyone know on my k8s cluster doing the proxy and going to the /ui gets me a list of api endpoints vs the dashboard. | 14:27 |
| rick_h_ | it was working, but not messed with it in a while. Did an upgrade on it today and so not sure what I might have borked | 14:28 |
| erik_lonroth | Hello, anyone aware of whats happening with lxd cloudimages for bionic ? | 14:42 |
| erik_lonroth | http://paste.ubuntu.com/p/XBZ8GHCgJB/ | 14:42 |
| erik_lonroth | I've tried to bootstrap a local lxd juju controller and fail every time | 14:43 |
| pmatulis_ | erik_lonroth, why is it trying to look for Bionic? and why are you calling the controller lxd-xenial if you are expecting Bionic? | 14:50 |
| erik_lonroth | I'm sorry about the syntax. I've tried other commands and on our xenial node which was working perfectly yesterday | 14:51 |
| erik_lonroth | "juju bootstrap localhost" -> gives the same errors | 14:51 |
| erik_lonroth | Could this be somehow related to the mechanism (whatever it is) that points to like "current" or something else suddenly starting to point towards something that is neweer than before bionic release date ? | 14:52 |
| pmatulis_ | erik_lonroth, what version of Juju are you running on the client? | 14:53 |
| erik_lonroth | I'm not at my workplace anymore so I can't check. | 14:53 |
| erik_lonroth | But I know Its from ubuntu 16.04.4 | 14:54 |
| pmatulis_ | erik_lonroth, do you use snaps or apt? | 14:54 |
| erik_lonroth | standard "apt install juju" | 14:54 |
| erik_lonroth | I'm happy to file a bug report tomorrow, but I think you should be aware. | 14:55 |
| pmatulis_ | ok, that will get you 2.3.7 if you installed within the last 48 hours | 14:58 |
| pmatulis_ | which is the latest stable | 14:58 |
| kwmonroe | rick_h_: what does your dashboard url look like? also, what does "kubectl get po -n kube-system" say about the dashboard (if anything)? | 15:49 |
| TheAbsentOne | what is currently the right way to put information on a relation with the reactive framework? I don't find a relation-set function or anything in the api. Do I need hookenv.config and config['key'] = value or is there a better approach? | 16:10 |
| pmatulis_ | erik_lonroth, fwiw, i just created a xenial LXD controller on my xenial client (running 2.3.7). all with 'juju bootstrap --no-gui localhost lxd' | 16:11 |
| magicaltrout | https://github.com/johnsca/juju-relation-mysql i borrow cory_fu_ 's mysql relation as my pattern for most stuff | 16:12 |
| magicaltrout | mostly cause he documents things much better than i do :) | 16:12 |
| pmatulis_ | erik_lonroth, but --no-gui prolly doesn't matter | 16:12 |
| magicaltrout | actually on that note, cory_fu_ can you tell me what the new endpoints pattern is all about? | 16:13 |
| TheAbsentOne | yeah I find myself always looking back at that repo too magicaltrout hmm, I'll guess I'll just try it out later today | 16:14 |
| kwmonroe | magicaltrout: Endpoints are the evolution of the previous RelationBase | 16:14 |
| TheAbsentOne | I see, so relationbase is depricated as well kwmonroe ? | 16:15 |
| kwmonroe | magicaltrout: so if you previously had an interface provide/require subclass of RelationBase, you would switch that to Endpoint | 16:15 |
| kwmonroe | TheAbsentOne: endpoints are back compat with relationbase (at least for now -- not sure about the roadmap there) | 16:16 |
| kwmonroe | magicaltrout: endpoints are nice when writing reactive handlers for a couple reasons.. you don't have to worry about param ordering for the handler, eg, @when foo, bar; def handle(bar, foo). you just always get the endpoint with endpoint_from_flag('foo'). | 16:17 |
| TheAbsentOne | I see, another quick question. I'm still a bit confused on how the connection_string() function in the juju-relation-mysql works as it is described in the requires file and not the provides file | 16:18 |
| TheAbsentOne | These are two different classes o.O | 16:18 |
| kwmonroe | better endpoint docs than i could describe are here: https://charmsreactive.readthedocs.io/en/latest/charms.reactive.relations.html#charms.reactive.endpoints.Endpoint | 16:19 |
| kwmonroe | TheAbsentOne: you'll have 2 sides of juju-relation-mysql. the provider is the mysql charm itself (which doesn't exist in a reactive form today, so don't go looking for it). if it did exist, that charm would handle a client joining the relation by creating a new database and calling provide_database (https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py#L51). | 16:25 |
| kwmonroe | TheAbsentOne: the *consumer* of juju-relation-mysql would use the requires.py bits and would be something like wordpress, which needs to know what db mysql has created for it. | 16:27 |
| kwmonroe | TheAbsentOne: so in the consuming charm, you would have something like "@when mysql.available; def configure_db(); db = endpoint_from_flag('mysql.available'); conn_string = db.connection_string() | 16:28 |
| TheAbsentOne | Owkey I see so I completely had it the other way around, thanks a lot for that clarification kwmonroe ! | 16:29 |
| kwmonroe | np | 16:29 |
| TheAbsentOne | so if you use reactive framework you will never create a provides.py? kwmonroe | 16:29 |
| kwmonroe | not quite TheAbsentOne -- if you are creating an interface layer (https://jujucharms.com/docs/devel/developer-layers-interfaces) you will always create the provides.py and requires.py. if you are creating a reactive charm that uses an interface, the provider (mysql) will call the interface provides.py methods to effectively do "relation-set" and the consumer (wordpress) will call the interface requires.py methods to " | 16:33 |
| kwmonroe | relation-get" the stuff sent by the provider. | 16:33 |
| TheAbsentOne | kwmonroe allright, I will chew a bit on that and come back to you thanks man | 16:36 |
| kwmonroe | TheAbsentOne: sounds good. the takeaway is that provides.py and requires.py are 2 sides of an interface that can be used by charms whether they're reactive or not. the Endpoint class simply makes it easier to work with (ahem, react to) the data that's getting passed around. | 16:44 |
| === frankban_ is now known as frankban|afk | ||
| bdx | kwmonroe: I was able to get a strawman working with hadoop <-> cephfs | 17:49 |
| kwmonroe | noice! | 17:50 |
| bdx | kwmonroe: my guys are dead set on using for the hadoop that will run in our openstack | 17:50 |
| bdx | I don't think its the worst idea | 17:50 |
| bdx | either way, I'm going to be working on charming the bits over the next few | 17:50 |
| kwmonroe | "I don't think its the worst idea" <-- well there's a glowing recommendation if i ever heard one | 17:51 |
| bdx | :) | 17:51 |
| rick_h_ | kwmonroe: howdy, so kube-system says kubernetes-dashboard-5bd6f767c7-5d7rc 1/1 Running 0 3h | 18:10 |
| rick_h_ | kwmonroe: url is just the 127.0.0.1:8001/ui | 18:11 |
| rick_h_ | and gets me https://www.irccloud.com/pastebin/RGCPnRZ2/ | 18:11 |
| kwmonroe | rick_h_: try replacing /ui with /api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy | 18:13 |
| kwmonroe | the latter is way easier to remember | 18:13 |
| rick_h_ | kwmonroe: hmm, ok that worked | 18:14 |
| kwmonroe | my work here is done | 18:14 |
| kwmonroe | send bitcoins | 18:15 |
| * rick_h_ now ponders wtf | 18:15 | |
| kwmonroe | rick_h_: see https://github.com/kubernetes/dashboard, NOTE: | 18:15 |
| kwmonroe | The shortcut http://localhost:8001/ui is deprecated. Use the full proxy URL shown above. | 18:15 |
| rick_h_ | well, that makes me sad for the world | 18:16 |
| kwmonroe | rick_h_: how did you know to go to /ui? i thought 'kubectl cluster-info' would show you the new url nowadays | 18:16 |
| rick_h_ | kwmonroe: because the readme says so? | 18:16 |
| kwmonroe | when you're paid by the character, you don't want /ui | 18:16 |
| rick_h_ | To reach the Kubernetes dashboard, visit | 18:17 |
| rick_h_ | http://localhost:8001/ui | 18:17 |
| kwmonroe | ahhh rick_h_, fair enough.. if our readmes are borked, that's on us. would you please file an issue at https://github.com/juju-solutions/bundle-canonical-kubernetes/issues | 18:17 |
| kwmonroe | you can keep your bitcoins... for now. | 18:17 |
| rick_h_ | kwmonroe: I liked the readme version better | 18:18 |
| kwmonroe | lol | 18:18 |
| kwmonroe | if only readmes made it so | 18:18 |
| rick_h_ | and when I did try the cluster-info I felt like that failed for some reason. /me goes to look wtf | 18:18 |
| rick_h_ | ah, that's right, that doesn't use the proxy url so you get "message: "services "https:kubernetes-dashboard:" is forbidden: User "system:anonymous" cannot get services/proxy in the namespace "kube-system""," | 18:18 |
| rick_h_ | so you have to mix the two, use the localhost domain, but the rest of the url so you can get to it | 18:19 |
| kwmonroe | yeah, duh. | 18:19 |
| cory_fu_ | magicaltrout, kwmonroe, TheAbsentOne: Sorry, I was on my chromebook which doesn't give me notifications for pings and I missed that whole convo. Sounds like kwmonroe explained things well, though I haven't finished getting caught up. | 18:53 |
| kwmonroe | cory_fu_: please correct as needed. i tried to summon your voice in my head with everything i typed, but still good to get it straight from the horse. | 18:55 |
| cory_fu_ | magicaltrout, kwmonroe, TheAbsentOne: One thing I did want to clarify that kwmonroe said is that you can use endpoint_from_flag with RelationBase style relations as well. Honestly, charm authors shouldn't care how interface layers are implemented, so they will always be compatible. But yeah, you can now just have no-arg handlers and always use endpoint_from_flag (or relation_from_flag if you like that better, but it's deprecated and the | 18:55 |
| cory_fu_ | terminology of the former is more precise) | 18:55 |
| cory_fu_ | The main benefit of Endpoints vs RelationBase is that you don't have to worry about scopes or conversations or any of that mess. You always just iterate over self.relations[*].units and access unit.received (or received_raw for older interfaces), or you can use self.all_joined_units.received if you don't care which unit the data comes from. | 18:57 |
| cory_fu_ | Or iterate over self.all_joined_units, etc. There are several convenience views to hopefully make whatever use-case as natural as possible | 18:58 |
| kwmonroe | oh yeah cory_fu_! i told magicaltrout that there were a couple reaons why endpoints were better, but only mentioned how nice it is to have no-arg handlers. the other was for sure the paving over of scope/convos. in fact, i'll always believe you pioneered this pattern so i would stop asking you if my interface was global or unit. | 19:01 |
| cory_fu_ | If you're familiar with the RelationBase pattern, using self.all_joined_units.recieved is analogous to scope=GLOBAL, using self.relations[*].joined_units.received is analogous to scope=SERVICE, and iterating over self.all_joined_units or iterating over self.relations[*].joined_units is like scope=UNIT. Something like that | 19:03 |
| cory_fu_ | Switching to Endpoints from RelationBase should hopefully be pretty painless, and mostly just involve getting rid of the confusing bits in favor of using those more explicit collections | 19:04 |
| TheAbsentOne | cory_fu_: thanks for bringing it up. It's still a maze for me but I hope I will get there. I talked yesterday with magicaltrout about my project btw: if you are interested and you have the time to look at it, I would love some recommendations on how to approach it all: https://www.dropbox.com/s/adiyp4qqkx4wg3i/Charm%20prototypingv0.pdf?dl=0 | 19:04 |
| cory_fu_ | kwmonroe: Oh! Another big thing is you no longer need @hook at all, which also makes them work with upgrades from non-reactive charms to reactive, where RelationBase failed miserably | 19:05 |
| TheAbsentOne | You know what I kinda miss in the whole reactive pattern + writing charms. A "state of the art" example that or roadmap. I hope to document my project in such a way, hopefully it can be used as some sort of tutorial or something | 19:05 |
| kwmonroe | TheAbsentOne: if you do that, rick_h_ will feature you on the juju show and probably send you bitcoins. | 19:06 |
| TheAbsentOne | Haha xD no need for that as long as I end up with a working thing I would be the happiest guy on earth | 19:07 |
| TheAbsentOne | kwmonroe cory_fu_ the juju show is every 2 weeks right? You guys know by heart if there was a show about libjuju? | 19:29 |
| kwmonroe | TheAbsentOne: yup, every 2 weeks. i don't recall libjuju being featured off hand, but maybe rick_h_ or cory_fu_ would remember. | 19:32 |
| cory_fu_ | kwmonroe, TheAbsentOne: I know we've talked about it in the past, but I don't recall in what depth, nor exactly when it was. | 19:33 |
| TheAbsentOne | That's ok! | 19:34 |
| cory_fu_ | TheAbsentOne: Looking over your PDF, making a generic database interface protocol is a really good idea but I think if you can create the interface, ideally you would want to update the individual database charms to support it directly rather than requiring a proxy charm to relay the relation data. | 19:39 |
| cory_fu_ | Also, there's something to be said for the inherent typing that the different interface protocols provide... Not every application will realistically work with just any DB, especially for ones as different as MongoDB is from relational DBs | 19:40 |
| TheAbsentOne | cory_fu_ thanks for looking into it! Hmm I kinda don't want to edit existing charms + I really want to have the option to have multiple charms to connect to 1 and the same database. | 19:40 |
| cory_fu_ | Sure, I can see that. Updating the existing charms can be intimidating, and there's nothing wrong with having a proxy charm as a first step, but I just wanted to say that getting the charms updated would be the ideal end-goal, to me. | 19:41 |
| TheAbsentOne | cory_fu_ correct but my "proxy charm" should find out from data on the relation what specific service should be used | 19:41 |
| TheAbsentOne | ah I see gotcha | 19:41 |
| cory_fu_ | TheAbsentOne: One of the benefits of modelling software in Juju is that it's easy* to look at the model diagram and see what applications have relationships and thus dependencies on which other applications. The abstraction layer of the proxy charm seems appealing, but you end up not knowing what applications are actually using mysql, postresql, mongo, etc. which can make it harder to reason about load, usage patterns, security, etc. | 19:44 |
| cory_fu_ | *: for some definitions of "easy" ;) | 19:44 |
| TheAbsentOne | cory_fu_: my goal of the "generic-database" charm is based on 3 things: 1 that he can determine what service needs to be used by the consumer charm, 2 that he acts as a proxy to relay information from existing charms to consumer charm and 3 if a new consumer comes in and wants to use it all he needs to do is add a relation and all information is already there | 19:44 |
| TheAbsentOne | That is a really good remark there, and I realised I was trying things with juju that it wasn't really designed for when theorycrafting | 19:46 |
| TheAbsentOne | Then again the focus I have is to create a charm that "stupid users without operational knowledge" can use without being bothered by different technologies, their setup and their connectionstrings | 19:47 |
| cory_fu_ | TheAbsentOne: But don't let me naysay your idea. :) What you're proposing is certainly possible and I know there are cases where it would make operational management easier. You should just also keep in mind what your trade-offs are. :) | 19:47 |
| TheAbsentOne | I will keep you posted cory_fu_ and probably ask for in depth technical questions as I'm really a noob when it comes to writing python code for the charms and interfaces x) I appreciate your thoughts! | 19:48 |
| cory_fu_ | TheAbsentOne: kwmonroe and I started going down a similar thought route with the big data charms at one point, starting to come up with ideas about service discovery and a central hub for big data components. | 19:48 |
| cory_fu_ | TheAbsentOne: Happy to help, any time | 19:49 |
| cory_fu_ | TheAbsentOne: Regarding your questions toward the end, it's definitely a good idea to keep interface layers as simple as possible. Really, the interface layer should just be there to provide a structured API over top of the data that goes over the wire and give you room to change that data if needed without breaking the API | 19:51 |
| TheAbsentOne | I see, that's pretty close in terms of approach/goal. I hope to get a working proof of concept real soon (although it will seem really inefficient without libjuju as all supported database services need to be up and running) | 19:52 |
| TheAbsentOne | that's good to hear, I guess that's the first step to properly work on the interface layer ;) I'll let you review it real soon cory_fu_ | 19:52 |
| TheAbsentOne | and all others here ofcourse | 19:52 |
| cory_fu_ | TheAbsentOne: As for removing relations from within charms, it's definitely not possible without essentially providing the charm with credentials for Juju and using something like libjuju to drive it. You're essentially describing an operator charm (an autoscaler would be another example), which is possible but again requires giving your charm access to the Juju controller that it doesn't get out of the box | 19:52 |
| cory_fu_ | TheAbsentOne: The beta version of Juju now has a concept of granting "trust" to give a charm access to cloud credentials to talk directly to the cloud API. The logical next step would be something similar to allow the charm to talk to the Juju API. The Juju GUI would be a good candidate for that, along with things like autoscalers and your charm | 19:54 |
| TheAbsentOne | Yep that's what I thought and found when browsing the docs and stuff, so I hope to look at libjuju but that's on another whole new level | 19:54 |
| TheAbsentOne | that would be really interesting | 19:55 |
| TheAbsentOne | cory_fu_: Is libjuju hard to use and is such an operator charm hard to write on top of an existing charm? | 19:56 |
| TheAbsentOne | so in other words if I have a charm that does my stuff pretty good could I use libjuju and add that functionality? | 19:57 |
| arosales | Happy 18.04 release day :-) | 19:57 |
| cory_fu_ | TheAbsentOne: Well, I'm probably a bad one to ask, as I work on libjuju quite a bit, so it doesn't seem too hard to me. ;) But it does use the async pattern, which can be confusing if you're not familiar with it. | 19:57 |
| cory_fu_ | arosales! o/ | 19:57 |
| TheAbsentOne | Welp good to know I will just ping you a lot if I reach that point x) thanks again cory_fu_ | 19:58 |
| arosales | waves to cory_fu_ | 19:58 |
| TheAbsentOne | big day arosales ! ^^ | 19:59 |
| cory_fu_ | TheAbsentOne: In general, though, I don't think libjuju is terribly hard to use. The examples/ directory has some good examples, such as this one: https://github.com/juju/python-libjuju/blob/master/examples/credential.py | 20:00 |
| arosales | TheAbsentOne: indeed, LTS! :-) | 20:01 |
| cory_fu_ | TheAbsentOne: And the docs have examples for adding and removing relations: https://pythonlibjuju.readthedocs.io/en/latest/narrative/application.html#adding-and-removing-relations | 20:01 |
| TheAbsentOne | cory_fu_: great, I will bookmark these and I pray I will use them in the near future x) | 20:03 |
| kwmonroe | TheAbsentOne: i find it better to open tabs for required links without bookmarking them. that forces you to read them before you browser crashes (assuming you don't have a tab resumer -- best to disable that in this case) | 20:06 |
| kwmonroe | ;) | 20:06 |
| magicaltrout | i've had D and Julia tabs open in my firefox browser since i was in DC in january | 20:07 |
| magicaltrout | it keeps crashing | 20:07 |
| magicaltrout | and they keep coming back | 20:07 |
| kwmonroe | ahoy arosales! i assume you're bionic as ever. | 20:07 |
| TheAbsentOne | haha I'll keep that one in mind kwmonroe xD | 20:08 |
| kwmonroe | yeah magicaltrout, these new fangled browser innovations are fueling my procrastination | 20:08 |
| kwmonroe | "tab suspended since Nov 2016"... i'm sure i'll get there soon. | 20:08 |
| arosales | There are tooo many jokes, mostly not in a good taste, for Bionic Beaver | 20:08 |
| arosales | Great Suspender! | 20:09 |
| kwmonroe | i learned it from watching you arosales. never before had i seen 700 tabs open until i watched you present. i thought "no way that browser stays up", then i learned of your suspenders. | 20:10 |
| kwmonroe | been not reading things ever since | 20:10 |
| arosales | Glad I had such a positive effect on your procrastination | 20:11 |
| magicaltrout | don't get him procrastinating more... | 20:12 |
| arosales | magicaltrout: all you need to do is fuel him with cheap beer | 20:14 |
| arosales | magicaltrout: that _does_ have diminishing returns though | 20:14 |
| magicaltrout | i know... gone are the days when you used to take us to nice joints arosales ... all i've got left is kev and cheap beer ;) | 20:15 |
| arosales | lol, always good to see folks put kwmonroe and cheap beer in the same sentence | 20:15 |
| magicaltrout | and thats tricky cause cory_fu_ still refuses to drink beer... | 20:15 |
| arosales | magicaltrout: we will have to make our own conference featuring unicorn tears for beer | 20:16 |
| magicaltrout | sounds like an excellent plan | 20:16 |
| arosales | oh cory_fu_ you have to fuel with top shelf bourbon | 20:16 |
| magicaltrout | i know | 20:17 |
| magicaltrout | one day it'll bankrupt me | 20:17 |
| cory_fu_ | lol | 20:17 |
| magicaltrout | i told him i'll supply him hats to offset the lack of affordable bourbon | 20:17 |
| arosales | only fedoras | 20:17 |
| magicaltrout | yeah | 20:18 |
| magicaltrout | posh git | 20:18 |
| veebers | Morning all o/ | 20:33 |
| thumper | morning | 20:38 |
| magicaltrout | can we have a straw poll herer | 21:16 |
| magicaltrout | -r | 21:16 |
| magicaltrout | here's more wrong me or marco | 21:16 |
| magicaltrout | can't type | 21:16 |
| magicaltrout | who's more wrong | 21:16 |
| magicaltrout | https://github.com/marcoceppi/charm-mysql/issues/25#issuecomment-384791236 | 21:16 |
| magicaltrout | https://jujucharms.com/mysql/58 | 21:16 |
| magicaltrout | oh he seems to suggest the fix is in candidate not the zesty support | 21:19 |
| magicaltrout | makes a bit more sense | 21:19 |
| TheAbsentOne | Welp i'm off to bed, talk to you all in a few hours! | 21:34 |
| wallyworld | vino: standup? | 23:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!