=== frankban|afk is now known as frankban
[10:09] <TheAbsentOne> Ahn there is an actual channel for the juju-gui oopsie 
[12:50] <rick_h> TheAbsentOne: yes, though tbh I love it more when we just use the #juju channel. I should bring up EOL'ing this one at some point
[12:52] <rick_h> TheAbsentOne: I see you had some discussion going on about a project. Feel free to ask anything you need. 
[12:54] <TheAbsentOne> Yeah well I might look into the juju-gui code to hack my way for a proof of concept. The other idea is to actually create a charm itself for my needs. Basicly I want to be able to have nodes in the gui that are small entities and not per definition services or applications
[12:54] <TheAbsentOne> rick_h: but as I understand that is not the direction juju wants to go ^^
[12:54] <rick_h> So there's been some things around proxy charms in the past
[12:55] <rick_h> the idea being that it'd map juju-isms into things that might be api calls, or other things that control a non-juju operated service
[12:55] <rick_h> e.g. someone did a route53 charm at one point
[12:55] <rick_h> so that you could relate things to it and they'd get dns entries and such
[12:55] <rick_h> TheAbsentOne: but yea, the GUI is about visually representing the Juju model and so things that aren't tied into that are hard to fit in cleanly. 
[12:56] <TheAbsentOne> for my dissertation specifically we want to model databases (and maybe tables) that are connected to a certain technology (existing charms) and these databases or tables are the nodes you want to connect your application with instead of the server
[12:57] <TheAbsentOne> this would solve the current restriction in wanting to deploy 2 different charms using one and the same table/database 
[12:57] <TheAbsentOne> if that kinda makes sense rick_h :)
[12:58] <rick_h> TheAbsentOne: hmmm, so that "right" fix for that issue is a known todo we call "relation config"
[12:58] <rick_h> the idea being that when you relate two things you might want to set specific config on that relation. 
[12:58] <rick_h> for instance relating a data input source charm to the database, and a second data processing/viewing charm to the same database
[12:58] <TheAbsentOne> is that todo documented? That might be very interesting to put in my dissertation
[12:58] <rick_h> you might then set the db name as part of the relation config passed between them
[12:59] <rick_h> I can see if there's the start of a spec for it. It might be worth a search through the mailing list for relation config
[12:59] <rick_h> it's come up as folks hit use cases over time
[12:59] <TheAbsentOne> great, thanks for that!
[13:00] <rick_h> np, have to run the little one to school but always happy to chat fun tech stuff
[13:00] <TheAbsentOne> Well I personally think that people like models and visual stuff right, but currently juju only models the services from a charm and visualise that as a node. And a lot of people would love to model "everything" in their infra ^^
[13:00] <TheAbsentOne> be safe rick_h ! :)