[08:06] <ybaumy> can i move a juju controller folger in vcenter to another location or will this break functionality?
[08:06] <ybaumy> s/folger/folder
[08:43] <parlos> Is there any (easy) way to search the config options of a model? Either via gui or console?
[09:21] <zeestrat> parlos: Are you thinking of searching through the options of `juju model-config` or `juju config <charm>`?
[09:25] <parlos> @zeestrat not sure, probably model. Cf, I've got a model, that is made of several applications(charms, would this be the charm?), each application needs to have the same 'identifier' ..
[09:26] <parlos> The default identifier could be "myIdentifier", now as I want to change that to "theirID" I need to find all locations of "myIdentifier" and replace it...
[09:28] <parlos> as now, you need to know that myIdentifier is used in app A,B and C..and change it 'manually'
[09:35] <zeestrat> parlos: I'm sorry, but I'm not quite sure I understand. Could you try with an concrete example with commands that you're doing manually right now?
[09:35] <zeestrat> Haven't had my coffee yet :)
[09:36] <parlos> Get Coffee, I'm on my 3rd :)
[09:37] <parlos> So; I've selected the Openstack-bundle; by default there is a "region" called RegionOne. This appears in quite a few of the applications; (this is just an example)
[09:38] <parlos> If I'd like to change this, I need to identify what applications has a config option set to "RegionOne", and change that.
[09:40] <parlos> Now, for OS I have an idea what apps have this, but for a different model... Id probably be lost.
[09:45] <zeestrat> parlos: Gotcha. I actually don't think that there is an easy way to do that right now without scripting a bit and looping through all applications/charms in a model and running `juju config <name-of-charm>`. But it sounds like a valid use case so I'd file a request at https://bugs.launchpad.net/juju
[09:47] <zeestrat> Ideally you'd define the options you care about in the bundle so you know which values are where, but that does not cover inheriting models and charms with values (either default or otherwise).
[09:51] <parlos> Ok, for a bundle, I'd think it would be great if it has a list of default options, that will be applied, when the bundle is 'read'.. no clue how to do it..
[10:02] <parlos> zeestrat this isnt really a bug... is it used to track requests too?
[10:10] <zeestrat> Yup. You can also ask the mailing list about this. P.S. Most of the folks are in the US so the activity usually picks up in a few hours.
[10:21] <parlos> ok, will try to write it down.
[10:49] <zeestrat> parlos: I hear you about the bundle. Right now it's a balance of the options you define and relying on some sane defaults. My approach at work is to explicitly specify the charm revisions and some of the options and then test the heck out of config changes and charm upgrades. However the use case of managing large scale charm config changes in models after upgrades post bundle deployment are not covered.
[10:49] <zeestrat> I'll gladly voice some support on a mailing list post or bug if you write something up.
[16:57] <cynthiaoneill> What does it mean to expose the kubernetes-worker?  What exactly is exposed?
[17:00] <bdx> cynthiaoneill: juju help <command>
[17:00] <bdx> going to be your best friend
[17:00] <bdx> `juju help expose`
[17:01] <bdx> https://jujucharms.com/docs/2.3/charms-exposing
[17:01] <cynthiaoneill> cool.  I don’t think of a kubernetes worker as an application. It deploys several apps needed by kubernetes (kubelet, kube-proxy..)
[17:01] <bdx> in the context of juju
[17:02] <bdx> it is an application
[17:02] <bdx> https://jujucharms.com/docs/2.3/juju-concepts#unit-and-application
[17:02] <bdx> cynthiaoneill: has no one showed you the docs yet?
[17:03] <cynthiaoneill> I’ve seen them.  I’m trying to understand from a security point of view, if this makes our cluster insecure
[17:06] <gvseghbr> cynthiaoneill: In the case of K8s it is not really necessary to expose the workers. Especially if you have a secure API gateway serving access to the pods
[17:07] <cynthiaoneill> gvseghbr: Thanks!
[17:09] <gvseghbr> but what it basically does, is creating firewall rules in your cloud provider, to allow access to all the open_ports (known to Juju). You can see which ports are open via `juju status`
[17:14] <cynthiaoneill> gvseghbr: I see which charm is exposed, with juju status.  The Ports for each Unit are listed, so if Load balancer is exposed then only Port 443 is open?
[17:15] <cynthiaoneill> and tcp
[17:15] <cynthiaoneill> never mind 443 is a tcp port :)
[17:16] <cynthiaoneill> Ooh closing off the worker is important, 80 was exposed
[17:18] <gvseghbr> yes, (was looking for one of our k8s clusters with the loadbalancer), the loadbalancer only has port 443 open (over TCP)
[17:33] <Cynerva> cynthiaoneill: nginx-ingress-controller is the service that listens to ports 80 and 443 on kubernetes-worker, and it's responsible for handling Ingress resources in kubernetes. If you don't have any Ingress resources defined, all the incoming requests will get routed to default-http-backend, which I think serves up a 404 response
[17:47] <gvseghbr> Does anybody know how I can get the private IP address from within a charm? The introduction of FAN in Juju 2.3.x seem to have changed a lot. Even if I'm not using containers on GCE, FAN is still being setup. And now every time I try to get the private IP address of a unit (local or remote, it doesn't matter) I always get the FAN IP address, somewhere in the 252. range.
[17:54] <bdx> gvseghbr: you have to use network_get() now (I think)
[17:55] <gvseghbr> yes, but I always get the FAN IP address. I'm looking for the actual IP address of the machine
[17:57] <gvseghbr> I thought FAN only "kicked in" when I would use containers on a machine. However, it seems it is now the only private IP I can get from a charm
[17:59] <bdx> gvseghbr: its in the model-config
[18:00] <bdx> gvseghbr: I think you just set `$ juju model-config fan-config=""` if you don't want the fan
[18:02] <bdx> I think you also need to set `juju model-config container-networking-method=local` or `juju model-config container-networking-method=provider` - depending on what you want
[18:04] <bdx> gvseghbr: network_get() should return a dict with all of the ip address in formation ... are you parsing that?
[18:04] <bdx> not sure if this is the best example, but this is how I'm using it https://github.com/omnivector-solutions/layer-redis/blob/new_endpoints_trials/reactive/redis.py#L32
[18:04] <kwmonroe> gvseghbr: i think by default, network-get will return  address for all interfaces.. since the fan-XXX interface is last, you might be picking the last value.  using network-get with --ingress-address should get you the real private ip.
[18:04] <kwmonroe> https://charm-helpers.readthedocs.io/en/latest/api/charmhelpers.core.hookenv.html#charmhelpers.core.hookenv.ingress_address
[18:06] <gvseghbr> This is what I get from within debug-hooks: `>>> network_get('public') {'ingress-addresses': ['252.1.224.1'], 'bind-addresses': [{'macaddress': '62:b6:9e:a6:c7:8a', 'interfacename': 'fan-252', 'addresses': [{'cidr': '252.0.0.0/8', 'address': '252.1.224.1'}]}]}`
[18:06] <kwmonroe> gvseghbr: verify with: juju run --unit <app>/n 'network-get <endpoint> --ingress-address --format yaml
[18:07] <kwmonroe> oof, only 1 ingres address, eh?  and that sure looks fanny.
[18:07] <kwmonroe> gvseghbr: do it without debug hooks with that juju run above and see what it returns
[18:09] <gvseghbr> Only get the fan ip: sojobo@juju-e441d6-0:~$ juju run --unit elasticsearch/0 'network-get public --ingress-address --format yaml' >> 252.1.240.1
[18:10] <gvseghbr> the suggestions bdx made, shutting it off, do work, however ...
[18:11] <gvseghbr> I'm using libjuju to create my models, and unfortunately I cannot set fan-config to an empty string
[18:12] <gvseghbr> and setting the model-defaults on my controller doesn't help either, they get overwritten
[18:16] <gvseghbr> @kwmonroe, @bdx, a bit of context: I have a Google Controller, Juju 2.3.5 and I'm trying to deploy James Beedy's ElasticSearch and Kibana Charms.
[18:17] <bdx> ahh
[18:18] <bdx> gvseghbr: try this one https://jujucharms.com/u/omnivector/kibana-elasticsearch/
[18:18] <gvseghbr> Those are the charms I'm using :)
[18:18] <bdx> but the charm shouldn't matter
[18:19] <gvseghbr> On JAAS (Juju 2.2.9) and on our VMware cluster (2.3.5, but do not support FAN yet) everything works perfectly
[18:20] <bdx> ahh its just gce? - sounds like a bug to me
[18:20] <gvseghbr> I haven't tried AWS yet
[18:21] <bdx> those charms work great for me on aws and MAAS ... I'm a bit embarrassed to say I haven't a GCE account and haven't tested them there
[18:22] <bdx> gvseghbr: would you mind filing a bug for this issue ?
[18:22] <gvseghbr> sure, no problem. Where?
[18:22] <bdx> https://bugs.launchpad.net/juju
[18:22] <bdx> thanks
[18:25] <gvseghbr> you're welcome. Any idea why, on GCE, I cannot fix the fan-config setting in the model-default during bootstrap?