[00:16] <bdx> thedac, beisner, jamespage: here is my keystone.endpoint table post deploy: http://paste.ubuntu.com/12890703/
[00:17] <bdx> the endpoints ending in .3x are vips, and are noticably absent
[00:17] <bdx> thedac: how did your deploy go? same?
[01:14] <thedac> turns out I can't do lxc deploys in a nested cloud. I'll have to find another way to test
[01:21] <bdx> thedac: ha-bindiface also sets to 'eth0' by default
[01:22] <bdx> I going to redeploy with these set appropriately....I'm hoping for a win here
[01:27] <thedac> ack. let us know
[01:38] <lathiat> marcoceppi: interesting, blew away my environment,m installed again.. got the same EOF errors about the containers etc but it otherwise worked fine.. weird.
[03:36] <bdx> thedac: notice my latest comment -> https://bugs.launchpad.net/charms/+source/keystone/+bug/1508575
[03:36] <mup> Bug #1508575: Keystone DB gets all non vip endpoints + openstack service conf files get keystone non vip <ha> <keystone> <openstack> <server> <keystone (Juju Charms Collection):New> <https://launchpad.net/bugs/1508575>
[03:37] <bdx> thedac: second to latest
[10:56] <jamespage> marcoceppi, hey - could you add a 16.01 and 16.04 milestones to the charms distro please?
[10:58] <jamespage> I need to bump outstanding bugs off 15.10 and can't do that yet as 16.01 does not exist :-)
[12:28] <joec> hi folks, any juju azure users or experts in the house?
[12:29] <joec> .. can anyone tell me if juju supports Azure Resource Groups or can anyone lead me to related documentation?
[12:30] <joec> https://azure.microsoft.com/en-gb/documentation/articles/resource-group-overview/
[12:34] <joec> AFAIK juju still uses classic deployment but was wondering if anyone had info regarding support for Resource Groups in Azure https://azure.microsoft.com/en-gb/documentation/articles/resource-manager-deployment-model/
[12:49] <lazypower> joec, afaik it does not.
[12:50] <lazypower> joec, however if this is something you need, it would be good to file a bug on to track the conversation
[12:55] <joec> thanks @lazypower, for now I'll stick with classic deployment, I'm not sure I actually need Resource Groups functionality yet, still planning -  but will raise a bug on launchpad
=== JoshStrobl is now known as JoshStrobl|Nap
[13:40] <marcoceppi> joec: 16.01 >
[13:40] <marcoceppi> err, jamespage 16.01 >
[13:40] <marcoceppi> ugh ?*
[13:40] <jamespage> milestones on the charms distro
[13:41] <jamespage> I use them for targetting bugs
[13:41] <marcoceppi> yeah, but what's 16.01 ?
[13:41] <jamespage> january next year
[13:41] <marcoceppi> okay, I get that, but it's not an ubuntu release
[13:41] <jamespage> I know - its a charm release
[13:41] <jamespage> we do them every 3 months
[13:42] <marcoceppi> the 16.01 isn't a milestone in the distro, it's a series
[13:43] <marcoceppi> oh wait, I see
[13:46] <jamespage> marcoceppi, you create them here - https://launchpad.net/charms/+milestones
[13:46] <jamespage> they are tied to arbitary dates of our own choosing
[13:46] <marcoceppi> jamespage: yes, I see that now. I've created the xenial series in the distro, so it's open for charms to be uploaded to
[13:46] <marcoceppi> I'll add the milestone now
[13:47] <jamespage> ta
[13:54] <marcoceppi> jamespage: good to go
[14:09] <jamespage> marcoceppi, thanks!
=== perrito667 is now known as perrito666
=== Odd_Blok1 is now known as Odd_Bloke
=== jcsackett_ is now known as jcsackett
=== frobware_ is now known as frobware
=== Tristit1a is now known as Tristitia
[15:54] <jcastro> mthaddon: http://blog.dasroot.net/2015-charming-2-point-oh.html
[15:54] <jcastro> mthaddon: https://jujucharms.com/docs/devel/authors-charm-composing
=== CyberJacob is now known as zz_CyberJacob
=== JoshStrobl|Nap is now known as JoshStrobl
=== wendar_ is now known as wendar
[17:28] <mattrae> hi i'm making a charm layer.. should a file in a higher layer override a file in a lower layer?
[17:28] <mattrae> i'd like to override site.conf in the apache-php layer
[17:56] <marcoceppi> mattrae: we have a vendoring method for that
=== skay_ is now known as skay
=== skay is now known as Guest69639
[18:00] <mattrae> marcoceppi: ahh cool where would i look to see how to use that?
[18:01] <marcoceppi> mattrae: https://github.com/johnsca/apache-php#usage
=== Guest69639 is now known as skay
[18:17] <mattrae> marcoceppi: looks like each site specified in apache.yaml will use the apache config template site.conf. i don't see a way to use a file other than site.conf, or override site.conf in a different layer
[18:17] <marcoceppi> mattrae: site.conf is put in templates. If your layer has a site.conf file in a templates directory it'll overwrite it
[18:18] <mattrae> marcoceppi: great, thats what i expect.. i have a site.conf in my layer but it when i compose, the composed charm still has the site.conf from the apache-php layer
[18:18] <marcoceppi> mattrae: interesting
[18:18] <marcoceppi> bcsaller cory_fu ^ ?
[18:22] <cory_fu> marcoceppi, mattrae: Just tested on the vanilla layer and I'm able to override site.conf with no problem.
[18:22] <marcoceppi> mattrae: do you have your layer somewhere?
[18:23] <mattrae> cool thanks guys for confirming. i don't have my layer uploaded anywhere yet. i'll put it up on github
[18:23] <cory_fu> marcoceppi: Has the newest charm-tools been released?
[18:23] <marcoceppi> cory_fu: no, I'm OTP, but it's going out the door tomorrow
[18:23] <marcoceppi> err
[18:23] <marcoceppi> today
[18:23] <cory_fu> Ok
[18:23] <marcoceppi> TODAY!
[18:23] <cory_fu> mattrae: Can you confirm which version of charm-tools you're using?
[18:24] <mattrae> cory_fu: i'm using version 1.7.1-0ubuntu4~ubuntu14.04.1~ppa1
[18:24] <cory_fu> Ok, that's the one I tested with
[18:28] <marcoceppi> cory_fu: I've got a feature request
[18:28] <marcoceppi> cory_fu: for reactive
[18:28] <cory_fu> What's that?
[18:29] <cory_fu> btw, I also just tested with master from charm-tools on GH and overriding site.conf works as expected
[18:29] <marcoceppi> cory_fu: it would be cool if all I needed to was have an actions.yaml file, and then on creation it'll create action stubs like it does for hooks and then I can do @hook('action-name') and have it all in my reactive thing
[18:29] <cory_fu> mattrae: http://pastebin.ubuntu.com/12896191/ is the expected behavior (with the name change from "compose" to "build")
[18:31] <marcoceppi> cory_fu: Although, I guess that's actuall part of the build process, huh?
[18:31] <cory_fu> marcoceppi: Yeah, I had planned to add support for actions, but I hadn't gotten around to it yet.  I'm also not 100% sure if we need to consider anything else for that, though.  When an action is called, you don't necessarily want any other reactive handlers triggering, do you?
[18:31] <mattrae> cory_fu: great thanks :)
[18:32] <marcoceppi> cory_fu: potentially
[18:32] <marcoceppi> though i guess not
[18:32] <marcoceppi> I just don't want to have to mess with paths in my action file
[18:32] <marcoceppi> to get at deps in lib
[18:33] <cory_fu> marcoceppi: Right.  Hook handlers obviously won't trigger, and any other handlers that do trigger ought to be safe, so it's probably the right thing to do.
[18:34] <marcoceppi> cory_fu: so I guess it's like @action as a handler?
[18:34] <cory_fu> marcoceppi: Because you also ought to be able to guard an action based on state (e.g., only run an action handler if the DB is available)
[18:34] <marcoceppi> right
[18:35] <cory_fu> marcoceppi: The only thing I'm not 100% confident in is how surprising it will be for other, non-@hook handlers to be triggered.  I guess we just document it and teach it
[18:35] <marcoceppi> yeah
[18:38] <cory_fu> marcoceppi: So, there are a couple of parts to that.  We'll need an @action handler, analogous to @hook, in charms.reactive.  We'll also want `charm build` to parse actions.yaml and generate the boilerplate actions/ files
[18:38] <marcoceppi> cory_fu: yeah
[18:39] <cory_fu> I think with that, it will also become more important to fix the issue that @hook (and now @action) can't be combined with @when, et al.
[18:49] <cory_fu> marcoceppi: https://github.com/juju/charm-tools/issues/30 and https://github.com/juju-solutions/charms.reactive/issues/11
[18:49] <bcsaller> I feel like the semantics around action handling here are quite different, we should talk about this more
[18:49] <cory_fu> bcsaller: Ok, I am on board with discussing it
[18:49] <marcoceppi> ditto
=== natefinch is now known as natefinch-afk
=== urulama_ is now known as urulama
[19:05] <dweaver> Anyone know how long it should take for the new openstack charms to appear in the charm store, nova-compute charm is still version 29 and should be updating to version 30?
[19:19] <marcoceppi> dweaver: it can take a few hours
[19:19] <marcoceppi> upwards of 2-3
[19:20] <dweaver> hi marcoceppi , reason I ask is all the others are there except nova-compute and it looks like 5 hours ago it was committed.
[19:21] <marcoceppi> dweaver: then you'll need to ping rick_h_ to get some insights into ingestion
[19:23] <dweaver> marcoceppi, no problem, not urgent from me, just thought it looked a bit odd and there might be a problem, I was just trying a liberty deployment and nova-compute barfed.  I'll wait until tomorrow.
[19:26] <dweaver> marcoceppi, thanks anyway and hopefully see you in Belgium in Feb.
[19:30] <marcoceppi> dweaver: definitely see you in belgium!
=== zz_CyberJacob is now known as CyberJacob
[19:58] <marcoceppi> Office hours starting in a few mins! https://www.youtube.com/watch?v=hQ4nq_6zKJ0
[20:00] <lazypower>  Greetings office hours lurkers o/
[20:03] <bdx> hey whats up guys
[20:03] <cory_fu> Greetings
[20:05] <bdx> I can't make office hours, but wanted to get a collective take on my findings in comment #5 here: https://bugs.launchpad.net/charms/+source/keystone/+bug/1508575
[20:05] <mup> Bug #1508575: Keystone DB gets all non vip endpoints + openstack service conf files get keystone non vip <ha> <keystone> <openstack> <server> <keystone (Juju Charms Collection):New> <https://launchpad.net/bugs/1508575>
[20:06] <bdx> would you guys be knid enough to address it? thanks
[20:08] <bdx> kind*
[20:09] <cory_fu> bdx: Sure thing, we can touch on it
[20:10] <bdx> cory_fu: thanks
[20:23] <marcoceppi> http://blog.dasroot.net/2015-charming-2-point-oh.html
[20:24] <marcoceppi> http://interfaces.juju.solutions/
[21:03] <bdx> beisner: thanks
[22:08] <thedac> bdx: ok, I just stood up a maas deployed (partial) openstack with keystone and other api services as lxcs. Everything is getting keystone's vip address. I also notice the lxc's have eth0 and not juju-br0 which is only on physical hosts.
[22:09] <thedac> bdx: so I am still trying to re-create your env. Is there anyting you are doing to preseeds (curtin or debiain-installer)? Can you confirm you have juju-br *inside* the lxcs?
[22:11] <thedac> So let's try 'juju run --service keystone -- "ifconfig"'
[22:49] <bdx> thedac: omp...give me 5
[22:50] <thedac> thanks
[23:16] <thedac> bdx: I need to head out shortly. To answer your questions in the bug we have not broken any conceptual problem. We have not yet identified what is causing the problem in your environment. I guess the next step is to post keystone juju logs for us to analyze.
[23:27] <bdx> thedac: I'll update you with these things tonight at some point
=== CyberJacob is now known as zz_CyberJacob
[23:43] <bdx> shoot....after an upgrade to 1.24.7 I cant get lxc units to get past allocating
[23:44] <bdx> i'll revert to 1.24.6 and report back
[23:50] <bdx> ok...for some odd reason when I upgraded only juju was upgraded, not juju-core...things are moving along quite nicely now