[00:47] <bdx> Mmike: https://gist.github.com/jamesbeedy/7a2226b7ab097e7e329cb45c54c5097d
[00:48] <bdx> Mmike: I hacked at it for a while, that is as clean and simple as I could get it
[07:46] <Mmike> kwmonroe, heh, did't know that ;) 'juju switch' and 'juju whoami' are fast enough, it seems
[07:47] <Mmike> bdx, thnx! I'll expand that a bit, so that it shows JUJU_MODEL, unless it is set up it will do 'juju whoami/juju switch' and display what's relevant. I actually prefer JUJU_MODEL because that way I can control two different environments/models within different terminals, or so.
[07:57] <TheAbsentOne> Is it possible with actions to deploy a new charm or a subordinate?
[10:01] <TheAbsentOne> Someone willing to take a look at this: https://ciberth.gitbooks.io/logboek-thesis/content/actions.html I want to know if this is possible in juju and if so how you can deploy subordinates or charms inside actions! Thanks for the help!
[11:22] <zeestrat> TheAbsentOne: I haven't seen anything about deploying charms or subordinates (kind of the same thing) from actions so you might want to ask the mailing list about that one. Just so I understand your use case, is there a reason why you want to use something like a generic-db-manager and subordinates instead of talking directly to the mysql server? The MySQL shared interface might be helpful if you want work with sharing multiple
[11:22] <zeestrat> db's with different applications: https://github.com/openstack/charm-interface-mysql-shared
[11:27] <TheAbsentOne> Thanks for replying zeestrat! Maybe I should try the mailing list idd. To clarify the situation: I'm doing a research about virtual data administrators. The basic idea is that a user can request a generic database instead of a certain technology. For example if an applications needs some kind of SQL database then the user doesn't really care if it's on mysql, mariadb or even postgresql
[11:28] <TheAbsentOne> Part of my research is looking into this matter conceptually and with oasis tosca, but we want to implement (or try at least) some parts of it with juju as well. The big problem I have is that I want to create charms that do not really represent applications but in this case a database. I hope this clarifies it a bit, zeestrat? :)
[11:29] <TheAbsentOne> So in a concrete example: imagine a charm requiring a generic-sql interface and the generic-db-manager providing that then the whole ecosystem should work if under the generic-db-manager hangs a mysql or a mariadb charm from the charmstore
[11:30] <TheAbsentOne> I need some sort of manager node though because I want to offer flexibility to create databases and re-use them as needed
[11:37] <zeestrat> I think I understand. Well the current mysql interfaces allow you to use either mysql and percona-cluster already but I understand that you want a more generalised version for other sql's so I'd check with the mailing list for the best approach.
[11:41] <TheAbsentOne> Well I'm by far not an expert (not in juju and not with all database technologies) but I try to find ways to make it work ^^ thanks for trying to help though zeestrat . Could you recommend someone to talk about this before using the mailing list? The last juju show kinda comes close tbh
[11:52] <TheAbsentOne> In addition to that, either I'm really missing something but it seems that when I use the mysql charm, I can't choose a specific database name?
[11:53] <zeestrat> TheAbsentOne: rick_h_ might know or who to ask (NA time zone), but you might as well hit the list to get some more eyes.
[11:54] <TheAbsentOne> He follows PT? I'll try to keep that in mind
[11:54] <TheAbsentOne> Thanks again though!
[11:56] <zeestrat> Right, so the mysql charm just installs and sets up a mysql server. A charm that wants to use a mysql then needs to specify what it needs, dbname, username, password etc using the mysql interface which is what talks to the mysql charm. If you look at the readme in https://github.com/openstack/charm-interface-mysql-shared you see example use cases where an example charm configures a couple of db's.
[11:57] <zeestrat> Both the mysql charm which deploys the mysql server and the charm requiring mysql communicate using the mysql interface which is their common language so to speak.
[12:25] <TheAbsentOne> Exactly, maybe I'm a bit too focussed on the wordpress example and that is confusing me. But in the db-relation-changed hook there is this line "database=`relation-get database`" getting the database name right? But where is this defined originally, because when I tried it all values are kinda random. Is that default behaviour when it's not filled in or something zeestrat ?
[12:26] <TheAbsentOne> I think I played mindgames with myself here. Sorry for the stupid questions
[12:38] <zeestrat> No no, it's most likely just a not good enough example, especially with the wordpress charm which is a bit old and only has the standard mysql interface (which page are you looking at btw?). The thing is, there are a bunch of different interface that are defined that charms either provide (server) or require (client). You can see the list here: https://github.com/juju/layer-index. If you look closely, there are multiple
[12:38] <zeestrat> different mysql interfaces. The links I posted earlier are for the `mysql-shared` interface which is a bit more fully featured where you can define things yourself compared to the standard `mysql` interface. The wordpress charm you're looking at only knows about the standard `mysql` interface which I think just generates a database for you.
[12:39] <zeestrat> You can see the different interfaces that a charm supports by looking at the interface widget in the charm store, for example https://jujucharms.com/wordpress/ and https://jujucharms.com/percona-cluster/, or in the `metadata.yaml` in the charm directories.
[12:40] <TheAbsentOne> I was looking at the api from the wordpress charm. I'm gonna use the shared one with a custom example later today.
[12:41] <TheAbsentOne> Yeah I get the workflows, bit confused by the auto generated values and not finding where it's auto generated
[12:42] <TheAbsentOne> I'm gonna toy a bit around with it and come back later to it. I need to figure out a way though to communicate with juju from within hooks for my desired action functionalities :/
[12:46] <zeestrat> Gotcha. Then I'd really recommend reaching out the list. I've seen some charms use a bit of a workaround by adding an service user to the juju model which they then connect to from the charm (https://jujucharms.com/charmscaler/), but there's probably a better way to do what you want so I'd ask.
[12:49] <TheAbsentOne> nice, yeah I'll think I'm gonna mail. But I'll prepare some clear documentation first as it might be a bit abstract. Thanks again man, I don't know what I would do without the help of you guys!
[12:52] <zeestrat> No problemo. Please do make sure to add a comment in the mail and/or in a bug (https://github.com/juju/docs/issues) on where the docs and examples are unclear or lead you astray :)
[12:53] <TheAbsentOne> I've been thinking about suggesting a tutorial/roadmap when I'm done!
[14:11] <rick_h_> TheAbsentOne: zeestrat so ideally there's on real love in the db names. They're named after the relation other end so it's somewhat identifiable but doesn't require manual input and if you setup > 1 you don't have name collisions
[14:11] <rick_h_> TheAbsentOne: zeestrat, however, one thing is that I was talking about enabling things like new dbs, that normally take place over a relation, to be able to be done via a charm action
[14:11] <rick_h_> in that case having things like optional db names as part of running the action would be sweet
[14:12] <rick_h_> that was a basic note during the juju show stuff from last week.
[14:14] <TheAbsentOne> Exactly! The question then pops up where do we want that action be performed on? Do you want "juju run-action mysql create name=mynewdb" or do you want to perform this action to another charm.
[14:16] <rick_h_> TheAbsentOne: ? I don't get the "on another charm" bit
[14:16] <TheAbsentOne> For most use cases the mysql charm would be the fitting answer. But for my use cases with generic databases I want some knowledge to happen on a higher level. Do you know by any chance rick_h_ if it's possible to deploy charms/subordinates inside an action/hook?
[14:16] <rick_h_> TheAbsentOne: so the idea there is that the various dbs you want to support need to have a common action language. So the same action can work the same way on different charms and the charms are wrapping the 'how to' knowledge
[14:16] <TheAbsentOne> https://ciberth.gitbooks.io/logboek-thesis/content/actions.html This might illustrate it or clarify.
[14:17] <TheAbsentOne> Yes exactly
[14:17] <rick_h_> TheAbsentOne: so yea, I'd propose that the manager isn't really necessary if everything supports the same list of actions that are common
[14:17] <TheAbsentOne> Meaning that it doesn't matter if you have a mysql or mariadb charm when talking about sql databases.
[14:18] <rick_h_> then you just run it where you need it, but that's just a quick glance
[14:18] <rick_h_> TheAbsentOne: rgr
[14:19] <TheAbsentOne> That is true, the manager is not needed if the mysql charm, mariadb charm, postgrescharm, mongodb charm, cassandra charm, ... all support that action
[14:20] <TheAbsentOne> Now I'm curious what rgr means? :o rick_h_
[14:20] <rick_h_> TheAbsentOne: ah sorry, roger
[14:20] <rick_h_> like "I hear you, roger" or whatever
[14:21] <rick_h_> it's my short way of saying ... kk
[14:21] <TheAbsentOne> ohn gotcha xD haha
[14:21] <rick_h_> or something
[14:23] <TheAbsentOne> rick_h_: In my ultimate working proof of concept I would have an application that needs a database (and it's allowed to be anything so mysql, mariadb, postgres but mongodb would be fine too!) and that my "generic database" charm would determine what kinda service the app would use and everything would still work.
[14:23] <TheAbsentOne> But it might be impossible with juju
[14:23] <rick_h_> TheAbsentOne: right, but in the end you still need to ask the user what db to use and you still need those dbs deployed, and they still need to have the right actions/etc.
[14:24] <TheAbsentOne> Well that's the thing the user in my use case won't need to worry about that
[14:24] <rick_h_> TheAbsentOne: so its' running a VM you're paying for and maybe it'll do more later, but just for selecting which db to add a new database to I'm not sure how much value it's adding there.
[14:24] <rick_h_> gotcha
[14:25] <TheAbsentOne> Another way of looking at it is this: you have a bundle that deploys a set of big data tools and stuff right. The data scientist will get some data from "a database" but it doesn't matter what it is. I kinda want to model his infrastructure with these generic db charms
[14:25] <TheAbsentOne> But you are definitely right about the added value part rick_h_ therefore they are letting me (a stupid student) research it :P
[16:21] <parlos> Good Morning
[21:36] <kwmonroe> rick_h_: grafana-11 is in the beta channel (includes your gettingstarted)
[21:37] <rick_h_> kwmonroe: awesomesauce