| === frankban|afk is now known as frankban | ||
| TheAbsentOne | Ahn there is an actual channel for the juju-gui oopsie | 10:09 |
|---|---|---|
| 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:50 |
| rick_h | TheAbsentOne: I see you had some discussion going on about a project. Feel free to ask anything you need. | 12:52 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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! | 12:59 |
| 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 ! :) | 13:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!