[11:23] <Akshay> Hi All, while deploying openstack charm(pike bits) keystone charm is failing at shared-db relation with error "keystoneauth1.exceptions.http.InternalServerError: Internal Server Error (HTTP 500)"
[11:24] <Akshay> can someone please help me here
[11:25] <Akshay> i am refering charms from location: https://jujucharms.com/u/openstack-charmers-next/openstack-base-xenial-pike/
[14:41] <EdS> Yo Tim :) this is awesome! https://insights.ubuntu.com/2017/10/11/private-docker-registries-and-the-canonical-distribution-of-kubernetes/ Am I right in thinking that this places the docker registry IN k8s? Would you have any advice for/against considering just adding a docker registry to our juju bundle definition of CDK?
[14:43] <EdS> I think I can figure most of it out, I'm just so early in the process of getting to grips with k8s/juju/maas I've been planning what to do almost as you're writing up "nearly what I want"!
[14:46] <EdS> Although, I suppose your method is much more efficient on the use of hardware. I like that.
[16:54] <BlackDex>  /win 3
[17:00] <jamesbenson> morning all
[17:49] <rick_h> juju show, juju show...everyone loves the juju show...10min
[17:51] <rick_h> participation linky : https://hangouts.google.com/hangouts/_/52rzxhpdfff6fobzkl6vyf7txqe
[17:51] <rick_h> and watching linky: https://www.youtube.com/watch?v=ZJG_1-ulGvI
[17:58] <rick_h> 2min warning
[18:38] <mattrae> hi juju reload-spaces with 2.2 is not properly getting changes to spaces from MAAS. juju spaces shows a subnet ended up under a wrong space, and also the cidr isn't getting updated. I'd like to repair the environment, is it ok to update the subnets and spaces collection to manually fix the enviornment until issues with reload-spaces are resolved? https://bugs.launchpad.net/juju/+bug/1705767
[18:38] <mup> Bug #1705767: reload-spaces doesn't update space names. <network> <spaces> <sts> <juju:Triaged> <https://launchpad.net/bugs/1705767>
[18:38] <mattrae> is it enough to update subnets an spaces collection to manually fix juju spaces? https://pastebin.com/eyVDJUja
[18:39] <rick_h> wpk: jam ^ ?
[18:39] <rick_h> mattrae: isn't there a command to update them from MAAS?
[18:40] <jam> rick_h: it doesn't handle if you move a subnet from one space to another
[18:40] <jam> we notice new ones
[18:40] <jam> but we don't update existing ones
[18:40] <rick_h> jam: oic, yea reload-spaces I was thinking of
[18:40] <jam> there is a risk associated with moving a subnet if that subnet was in use
[18:40] <jam> cause then apps that were using it are suddenly in another space
[18:42] <mattrae> yeah the changes to the spaces/subnets in maas are not all getting reflected in juju spaces
[18:42] <jam> mattrae: are these subnets in use, or not in use yet?
[18:42] <jam> if they aren't in use, then probably updating the DB is ok
[18:43] <mattrae> jam: yeah the subnet is currently in use, some units are bound to it right now i believe
[18:43] <jam> mattrae: in which case, what will happen when you move it into another space is very much undefined behavior
[18:44] <jam> mattrae: applications will have been configured to use specific IP addresses for particular use cases, etc, and suddenly those are no longer the right ones
[18:44] <jam> which is why we didn't do all the work in refresh-spaces, because it has potentially long tails
[18:46] <mattrae> jam: cool sounds good, i'll have to do some testing of the behavior in this environment
[20:04] <rick_h> cory_fu: have a sec? I'm trying to figure out my best path forward for updating the prometheus charm with the updated trunk of charmhelpers then. I manually built using make source and copied it into the charm, but that's not going to work for the actual charm source.
[20:40] <atrius> Hello all. I'm seeing something with a recently installed set where jujud is consuming 300 - 600% cpu time on a 32 core system
[20:41] <atrius> I imagine that isn't expected?
[20:43] <atrius> And now mongo is consuming 2600% O.o
[20:53] <jamesbenson> impressive, I'm still struggling to get juju to install.
[20:54] <pmatulis> jamesbenson, what's wrong?
[20:55] <atrius> The install was easy.. the consuming all the resources in sight was less easy/good
[20:56] <jamesbenson> atrius: I installed maas and have that working properly
[20:57] <jamesbenson> but getting juju to function is difficult.  I just fixed some networking issues
[20:57] <jamesbenson> but if I can ping you perhaps tomorrow that might be nice :-)
[20:59] <atrius> jamesbenson: Honestly, I just used snap and then conjure-up
[20:59] <atrius> Maybe that was my mistake since doing it that way seems to have resulted in.. interesting.. results
[20:59] <jamesbenson> well I actually am trying conjure-up currently
[21:00] <jamesbenson> but seems like nothing was actually setup...
[21:00] <jamesbenson> we are trying to tie it into maas here... both juju and conjure.
[21:01] <stokachu> jamesbenson:hit me up if you have questions
[21:01] <jamesbenson> thank you!  I will take you up on that.  Where are you based out of?
[21:02] <bdx> rick_h, cory_fu: I want to know too!
[21:05] <rick_h> bdx: so https://code.launchpad.net/~rharding/prometheus-charm/+git/prometheus-charm is my MP that with the updated charmhelpers that should work. I've tested it in non-CMR setup and will test it in a CMR setup later tonight
[21:05] <rick_h> bdx: but in case that's useful to see how to use the new relation data and network-get stuff.
[21:07] <bdx> rick_h: great
[21:07] <bdx> thanks
[21:07] <bdx> but how do you get that charmhelpers branch into your charm?
[21:08] <bdx> do you have to build the sheel manually and put it in there?
[21:08] <bdx> wheel*
[21:09] <rick_h> bdx: so I did ancharm build, and from checked out charmhelpers branch did a 'make source' and replaced the charmhelpers in the wheelhouse directory of the built charm.
[21:10] <bdx> ok, thats what I thought, perfect
[21:10] <bdx> thx thx
[21:13] <bdx> rick_h: https://github.com/jamesbeedy/interface-redis/blob/master/provides.py#L23
[21:14] <bdx> its that ^ which I will want to be replacing with network_get() right?
[21:14] <bdx> anywhere where unit_get('private-address') is used
[21:15] <rick_h> bdx: yes
[21:15] <rick_h> You want to use ingress address
[21:16] <bdx> totally
[21:17] <bdx> but I think we didnt come to a conclusion about what happens when you want ingress from your private address space
[21:17] <bdx> because by default you get the public
[21:17] <bdx> right
[21:18] <bdx> so, when you only have private address space it should fall back to it though
[21:18] <bdx> is what jam was saying I think
[21:18] <rick_h> bdx: yea the result is try it and see what is in the network info returned
[21:18] <bdx> totally
[21:23] <bdx> rick_h: so, its not really clear how I would use that in a interface, I need to pass it a relation_id obtained from the conversation ?
[21:24] <bdx> similar to https://github.com/jamesbeedy/interface-memcache/blob/master/requires.py#L36
[21:24] <bdx> kind of
[21:24] <bdx> ?
[21:29] <bdx> or
[21:29] <bdx> I guess I see the other input param for relation id there
[21:30] <bdx> so, basically ... not really sure how I will get the endpoint name from the interface perspective
[21:30] <bdx> to be able to pass into network_get()
[21:31] <bdx> rick_h: possibly its an architectural flaw of mine in the interface design
[21:32] <bdx> and I possibly shouldn't be trying to get the local info about the node like network_get() in the interface
[21:32] <bdx> otherwise, I just think that the interfaces will need to be passed an extra argument by the layer
[21:32] <bdx> such that the interface knows what the endpoint name is
[21:33] <bdx> because the name is arbitrary at the layer level right?
[21:33] <bdx> so yeah, make it something thats passed in as relation info im thinking
[21:34] <bdx> oh, or I could just make the call to network_get() in the layer, and pass the 'host' info into the relation as relation info
[21:34] <stokachu> jamesbenson: etc
[21:36] <jamesbenson> ?
[21:37] <stokachu> jamesbenson:east coast
[21:37] <stokachu> US
[21:37] <jamesbenson> ah, okay
[21:37] <jamesbenson> thanks :-) CST here