=== 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
[15:54] <sfeole> hey 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?
=== frankban is now known as frankban|afk
[16:31] <bdx> sfeole: there is a charm ci workflow for jenkins that exists somewhere, I'm now curious where its at too
[16:32] <bdx> sfeole: possibly this is it https://github.com/juju-solutions/bundle-cwr-ci
[16:32] <bdx> there may be another though
[16:33] <bdx> sfeole: https://github.com/juju-solutions/bundle-cwr-ci#test-charm-when-the-repository-changes
[16:33] <bdx> kwmonroe: +1
[16:33] <sfeole> bdx, thanks, i'll take a look .
[16:34] <bdx> sfeole: np
[17:23] <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:25] <bdx> xarses_: yeah ... its not really pre-defined but there is a simple path
[17:29] <kwmonroe> xarses_: 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 that
[17:30] <kwmonroe> of course, the faux-db-charm would need to do the actual work of relation-setting the configured data.
[17:30] <kwmonroe> so, 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:42] <xarses_> ya, it seems simple, so simple that there should be a pattern and or charm-generator for it
[17:42] <bdx> kwmonroe, 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 around
[17:43] <bdx> xarses_: I'm right there with you, +1^
[17:45] <bdx> I originally thought subordinate charms might be a fit for the external service use case, but I don't think they are
[17:47] <xarses_> oh, I was going down that route for the relations I currently need to model, but you think no?
[17:51] <bdx> well... from what I know about subordinates, I think they have to be related to a primary charm to be able to run code
[17:52] <bdx> so 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 config
[17:52] <bdx> xarses_: I created this https://github.com/jamesbeedy/interface-db-info/blob/master/provides.py#L17
[17:53] <bdx> simple way to set and get db info from one application to the next
[17:54] <bdx> xarses_: so then you could have the leader of one application set the dbinfo, and other applications can relate to it to get the db-info
[17:55] <bdx> xarses_: you can then just make the db-info config values in your primary charm that get set into the db-info relation
[17:56] <xarses_> ya, thats about what I figured
[17:56] <bdx> xarses_: 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] <bdx> reinforces that we need something* ^
[17:57] <bdx> xarses_: because the majority of the time (despite what we may like to think) NOT everything is deployed via Juju right
[17:57] <xarses_> not even that
[17:57] <xarses_> not everything will be deployed by juju
[17:59] <xarses_> or even be deployed in this model
[17:59] <xarses_> or managed by this controller
[17:59] <bdx> right
[17:59] <bdx> so
[18:00] <bdx> I've hit my head on this all to much too
[18:01] <bdx> xarses_: heres something I came up with a wile back https://github.com/jamesbeedy/juju-layer-barbican-client/blob/master/config.yaml
[18:02] <bdx> you have to have barbican deployed
[18:02] <bdx> and keystone
[18:02] <bdx> then you set your keystone creds in the barbican-client
[18:03] <bdx> then you can relate your charms to via the barbican-client and have them get the secrets from barbican
[18:03] <bdx> all that to say
[18:03] <bdx> that is a lot of work to get something "so simple that there should be a pattern and or charm-generator for it"
[18:04] <bdx> :)
[18:05] <bdx> xarses_: I dropped the barbican idea because I didn't like all of the things having a hard dep on having a connection to barbican
[18:07] <bdx> and 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 things
[18:08] <bdx> I'm not sure if any of that is best practice for anything
[18:08] <bdx> but I think your totally right ... we need some sort of generic external application proxy manager or something
[18:09] <bdx> the guys working on the CAAS stuff might be thinking about a similar problem trying to present k8s application endpoints
[18:10] <bdx> mmcc:^?
[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 relation
[18:10] <bdx> right