/srv/irclogs.ubuntu.com/2017/09/22/#juju.txt

=== frankban|afk is now known as frankban
=== urulama changed the topic of #juju to: Juju as a Service Beta now available at https://jujucharms.com/jaas | https://review.jujucharms.com/ | https://jujucharms.com/docs/ | http://goo.gl/MsNu4I || https://www.youtube.com/c/jujucharms | JAAS login issues
=== urulama changed the topic of #juju to: Juju as a Service Beta now available at https://jujucharms.com/jaas | https://review.jujucharms.com/ | https://jujucharms.com/docs/ | http://goo.gl/MsNu4I || https://www.youtube.com/c/jujucharms
sfeolehey all, is there a way to build charms in launchpad?? push the source to a branch and have a recipe that builds the charm for you?15:54
=== frankban is now known as frankban|afk
bdxsfeole: there is a charm ci workflow for jenkins that exists somewhere, I'm now curious where its at too16:31
bdxsfeole: possibly this is it https://github.com/juju-solutions/bundle-cwr-ci16:32
bdxthere may be another though16:32
bdxsfeole: https://github.com/juju-solutions/bundle-cwr-ci#test-charm-when-the-repository-changes16:33
bdxkwmonroe: +116:33
sfeolebdx, thanks, i'll take a look .16:33
bdxsfeole: np16:34
xarses_(re-ask, I think it wasn't responded to) Is there a pre-defined way to build stub|shim charms that are simply data providers to satisfy relations to systems that are deployed outside of juju?17:23
bdxxarses_: yeah ... its not really pre-defined but there is a simple path17:25
kwmonroexarses_: i think you're getting at the idea of a proxy charm... eg, faux-db-charm might allow a user to "juju config faux-db-charm ip=<real-db-ip> user=<real-user> pass=<real-password>" and would also provide the db relation.  this would allow you to proxy the db connection details via juju config to a db relation that could then be related to other charms that require a db.17:29
xarses_yep, something like that17:29
kwmonroeof course, the faux-db-charm would need to do the actual work of relation-setting the configured data.17:30
kwmonroeso, i don't know of any docs or pre-defined workflows for proxy charms, but it seems pretty simple in theory (famous last words).17:30
xarses_ya, it seems simple, so simple that there should be a pattern and or charm-generator for it17:42
bdxkwmonroe, xarses_: looking back at the areas where I've had to have my charms connect to an external service I've implemented it custom in each charm, probably +10 places where I've copied my external service handlers around17:42
bdxxarses_: I'm right there with you, +1^17:43
bdxI originally thought subordinate charms might be a fit for the external service use case, but I don't think they are17:45
xarses_oh, I was going down that route for the relations I currently need to model, but you think no?17:47
bdxwell... from what I know about subordinates, I think they have to be related to a primary charm to be able to run code17:51
bdxso I don't think you could just have a subordinate deployed to your model that isn't related to a primary, that is just handing out config17:52
bdxxarses_: I created this https://github.com/jamesbeedy/interface-db-info/blob/master/provides.py#L1717:52
bdxsimple way to set and get db info from one application to the next17:53
bdxxarses_: so then you could have the leader of one application set the dbinfo, and other applications can relate to it to get the db-info17:54
bdxxarses_: you can then just make the db-info config values in your primary charm that get set into the db-info relation17:55
xarses_ya, thats about what I figured17:56
bdxxarses_: not sure if this will get you what you want, but it definitely reinforces "so simple that there should be a pattern and or charm-generator for it"17:56
bdxreinforces that we need something* ^17:56
bdxxarses_: because the majority of the time (despite what we may like to think) NOT everything is deployed via Juju right17:57
xarses_not even that17:57
xarses_not everything will be deployed by juju17:57
xarses_or even be deployed in this model17:59
xarses_or managed by this controller17:59
bdxright17:59
bdxso17:59
bdxI've hit my head on this all to much too18:00
bdxxarses_: heres something I came up with a wile back https://github.com/jamesbeedy/juju-layer-barbican-client/blob/master/config.yaml18:01
bdxyou have to have barbican deployed18:02
bdxand keystone18:02
bdxthen you set your keystone creds in the barbican-client18:02
bdxthen you can relate your charms to via the barbican-client and have them get the secrets from barbican18:03
bdxall that to say18:03
bdxthat is a lot of work to get something "so simple that there should be a pattern and or charm-generator for it"18:03
bdx:)18:04
bdxxarses_: I dropped the barbican idea because I didn't like all of the things having a hard dep on having a connection to barbican18:05
bdxand then trying to facilitate getting the information from the relations if the service exists and deployed via juju, or if not deployed via juju get the info from barbican .... it was becoming more then I bit off to chew, so I just ditched it in favor of setting charm configs for external things18:07
bdxI'm not sure if any of that is best practice for anything18:08
bdxbut I think your totally right ... we need some sort of generic external application proxy manager or something18:08
bdxthe guys working on the CAAS stuff might be thinking about a similar problem trying to present k8s application endpoints18:09
bdxmmcc:^?18:10
xarses_or something with some relation and config factory generators that are just like take "this relation" and give me something that I can relate, and set the config that was passed in the relation18:10
bdxright18:10

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!