[00:02] <R_P_S> but I'm guessing it's not supposed to go through the kubeapi-load-balancer... which means I need something else that has a public IP (AWS ELB, proxy instance in public subnet, some other juju charm?)
[00:02] <R_P_S> holy crap, EOD... I'll need to pick this up in the morning and I'll check logs when I get in :\
[00:05] <[Kid]> yeah, i know what you mean
[01:18] <bdx> R_P_S, [Kid]: using conjure-up, there is the 'deis' post install option I think
[01:18] <bdx> that deis install should also bring with it a load-balancer for your apllication level ingress
[01:19] <bdx> might be an easy option for you
[01:19] <bdx> I know doing ingress correctly can be a battle
[01:20] <bdx> and there are different way of doing it depending on what framework/workflow/architecture your targeting
[01:20] <bdx> to tell you the truth I'm not sure how the deis deploy works outside of the aws provider
[04:12] <admcleod_> if i have a charm which doesnt support say, artful, how can i force that deployment in a bundle?
[07:59] <tingwei> Hi there! My juju is running on lxd, it hanged after fill up the lxd space. The lxd space was expanded which is zfs. But juju is still not responding. Is there any way to get it back?
[08:00] <tingwei> *The lxd space was expanded using zfs at backend.
[08:26] <tingwei> It works after rebooting the container.
[16:23] <R_P_S>  bdx: I'm unsure how to invoke conjure-up now that all my infrastructure is already online.  it wants to create a new controller.  If I try specifying my controller + model, it complains that my "controller name" is not a spell
[16:23] <bdx> ahh, yeah, so
[16:23] <R_P_S> deis does not appear to be a spell either
[16:24] <R_P_S> oh hey, while you're here... is deis and helm the same thing?
[16:24] <bdx> R_P_S: deis is an "addon"
[16:24] <bdx> no
[16:24] <bdx> R_P_S: I took about 2 weeks and became very familiar with all of the tooling surrounding k8s
[16:24] <bdx> when I was first diving in
[16:24] <bdx> I highly suggest you do the same
[16:25] <bdx> it will enable you to be proactive in your k8s dev instead of always wondering wtf
[16:25] <bdx> you need to go down a few rabbit holes my friend
[16:25] <R_P_S> as indicated earlier, I do not have that time... my manager has already asked me why it's taking so long :(
[16:25] <bdx> oh man
[16:25] <bdx> yeah
[16:26] <bdx> well if your only interface to this thing is to get it standing, and not to understand it
[16:26] <bdx> then you shouldn't need to concern your self with the tooling
[16:27] <R_P_S> well, I have a kubernetes cluster online, but I did a demo app and it tried to create a load balancer which got stuck in pending forever
[16:27] <bdx> I see
[16:28] <bdx> follow the instructions here https://jujucharms.com/canonical-kubernetes/
[16:28] <bdx> and deploy the microbot example
[16:28] <bdx> then cut the cord
[16:28] <bdx> thats your best bet
[16:28] <bdx> unless you plan on learning some thing
[16:28] <bdx> s
[16:29] <R_P_S> the diagram at the top of the page is essentially what I have now
[16:29] <bdx> and you boss will need to understand that its going to take you 1 month of k8s academia to start being able to understand how it works and deploy apps and what not
[16:29] <bdx> exactly
[16:30] <bdx> so just follow the instructions there
[16:30] <bdx> had you not seen those yet?
[16:30] <R_P_S> no, I'
[16:30] <R_P_S> I've never seen anything related to squid config
[16:31] <R_P_S> oh, the squid is for egress... don't think that's an issue at this time
[16:31] <R_P_S> I can't get any ingress except for the kubeapi-load-balancer
[16:32] <bdx> try ^ example
[16:32] <bdx> if it doesn't work
[16:32] <bdx> create a bug
[16:32] <bdx> there is a link to "submit a bug" on ^ page
[16:33] <bdx> ^ is more productive/proactive way of getting to the bottom of what ever you are having trouble with
[16:35] <R_P_S> so I don't understand why I'm asked to select deis or helm in conjure-up.  I tried googling the difference, and the first link was
[16:35] <R_P_S> https://deis.com/blog/2015/why-kubernetes-needs-helm/
[16:36] <bdx> R_P_S: helm is used to install deis
[16:36] <bdx> `helm repo add deis https://charts.deis.com/workflow`
[16:36] <R_P_S> is helm is required for deis, why can I install deis without helm?
[16:36] <bdx> `helm install deis/workflow --namespace deis`
[16:36] <bdx> the conjure-up deis addon takes care of that for you
[16:37] <bdx> so you can just get a platform bootstrapped with the deis workflow, and you can start deploying apps with a single command
[16:37] <bdx> and you can just know how to use deis
[16:37] <bdx> you don't need to understand how anything works underneath
[16:37] <R_P_S> that is not clear at all in the conjure-up screen that asks between deis or helm :\
[16:38] <stokachu> if you pick deis everything is setup for you including helm
[16:38] <stokachu> if you pick helm then you just get helm
[16:38] <bdx> well if you understand what deis is it would make sense
[16:38] <R_P_S> that feels like chicken and egg lol
[16:39] <stokachu> how so
[16:39] <R_P_S> "here's an explanation of 2 tools in conjure-up, but if you don't understand the tools, this explanation will make no sense"
[16:39] <R_P_S> so either you already know what they do and need no explanation, or you don't know what they do and the explanations might as well be written in another language
[16:40] <bdx> well if I told you openstack would serve you better then a public cloud, it wouldn't make sense unless you understood what openstack was
[16:40] <bdx> or a car over a bike
[16:41] <bdx> you would have to know what a bike is
[16:41] <bdx> to understand
[16:41] <bdx> and a car
[16:43] <bdx> correct me if I'm wrong here, but its not conjure-up, or juju's responsibility to provide education on 3rd party software
[16:44] <bdx> conjure-up/juju, provide the thing
[16:44] <bdx> its up to you to know how to use it
[16:47] <R_P_S> this conversation is devolving :(  I do hope you understand I'm trying my best here
[16:48] <stokachu> R_P_S: what more would you want in the screen listing the addons?
[16:48] <stokachu> urls to their websites?
[16:50] <R_P_S> this line here actually explains a ton: <stokachu> if you pick deis everything is setup for you including helm
[16:51] <stokachu> not really as you stated you don't know what deis or helm actually is
[16:52] <R_P_S> I am presented with 2 options.  Except you stated that option 1 includes option 2.  That alone makes decisions much easier going forward
[16:53] <stokachu> hmm ok
[16:53] <R_P_S> actually, I'm presented with 3 options... I can go with neither
[16:54] <R_P_S> and when selecting deis or helm, it doesn't become clear why the options are limtied to aws afterwards, since googling "deis on azure" yields ocs from deis own website
[16:56] <stokachu> avaialble clouds are enabled according to the spell, we just actually fixed it to show all clouds but give you a reason as to why some are enabled and not others
[16:56] <stokachu> https://github.com/conjure-up/conjure-up/issues/1222
[16:57] <R_P_S> that's a nice feature
[17:17] <Navin> Hi guys
[17:17] <Navin> I am fairly new to juju
[17:17] <Navin> Hoping for some help from you guys
[17:18] <Navin> I have been trying to bootstrap juju to openstack, that is hosted in one of the VM's I have spun up on a bare-metal
[17:18] <Navin> But, this is following error I have been receiving:
[17:18] <Navin> 11:36:59 ERROR juju.cmd.juju.commands bootstrap.go:496 failed to bootstrap model: cannot start bootstrap instance: cannot run instance: No valid host was found.
[17:19] <Navin> Any inputs on this would be highly appreciated, thanks
[17:19] <Navin> or if there's any other info required for troubleshooting, I would be more than happy to provide with the same..thanks so mcuh
[17:22] <rick_h> Navin: try with --debug on the command and see if there's more details. It should show you what kind of instance it's looking for
[17:23] <Navin> Thank rick for your reponse
[17:23] <Navin> I did use the --debug command
[17:24] <Navin> 11:36:41 DEBUG goose <autogenerated>:22 discovered API versions: [{Version:{major:2 minor:0} Links:[{Href:http://192.168.122.166:9696/v2.0/ Rel:self}] Status:CURRENT}] 11:36:41 DEBUG juju.provider.openstack provider.go:1022 using network id "5227f5c1-3857-4295-be56-2b1acb3af717" 11:36:46 INFO  juju.provider.openstack provider.go:1146 trying to build instance in availability zone "nova" 11:36:59 INFO  juju.provider.openstack provider.go:11
[17:24] <Navin> 11:36:59 INFO  juju.provider.openstack provider.go:1126 Instance "bce33e58-51dd-4eef-aaf8-4a67298ce90e" in ERROR state with fault "No valid host was found. "
[17:26] <Navin> I can see it's pointing to a specific instance "bce33e58-51dd-4eef-aaf8-4a67298ce90e" in ERROR state but I am not sure how to fix this
[17:26] <Navin> Any advise on this Nick?
[18:57] <R_P_S> the deis addon failed to install as part of conjure-up/canonical-kubernetes.  It looks like it created all the infrastructure (juju status shows everything operational)
[20:12] <R_P_S> so there's a charm for kubeapi-load-balancer, which is meant to be a public facing instance for the masters (auto config etc)
[20:13] <R_P_S> is there a juju charm for load-balancing the workers?  From what I can tell, I can either expose the workers by putting them in a public subnet, which is less than ideal, or by having a load balancer charm that is in a public subnet on it's own with a relationship to the workers
[20:14] <bdx> cory_fu: http://paste.ubuntu.com/26014595/
[20:15] <R_P_S> when searching nginx, I only came across one option - "nginx dh" which states it requires a whole pile of other charms including psql, "devicehive", zookeeper and kafka...
[20:15] <bdx> is there something else that needs to change, other then using endpoint_from_name('endpoint-name')
[20:18] <bdx> R_P_S: deploy vanilla k8s using conjure up with no private subnets
[20:19] <bdx> and the load balancing ingress and deis work
[20:19] <bdx> you *should* end up with an elb endpoint that will proxy to your workers
[20:19] <cory_fu> bdx: No, that looks like my mistake.  I’ll take a quick look
[20:21] <bdx> cory_fu: thank_u
[20:22] <R_P_S> bdx: I tried a vanilla install of k8s with deis and it bailed at the deis addon part... Exception: Failure in step /home/R_P_S/.cache/conjure-up/canonical-kubernetes/addons/deis/steps/step-01_install-workflow
[20:23] <R_P_S> so I've got full infrastructure running without deis
[20:23] <bdx> I see
[20:23] <bdx> R_P_S: to get that fixed, so it will work for you, please file a bug with conjure-up
[20:36] <cory_fu> bdx: Oh, sorry.  There was one thing that has to change.  The flag pattern is now “endpoint.{endpoint_name}.foo” to be consistent
[20:38] <bdx> ahh, in my interface layers, gotcha
[20:38] <bdx> thanks
[20:44] <bdx> cory_fu: looking through the Endpoints class, I don't see self.relations or self.endpoints, do those come from RelationFactory ?
[20:45] <bdx> cory_fu: might you be kind enough to point me in the direction of where that code lives?
[20:45] <bdx> cory_fu: or possibly there is only self.endpoints now, because we are ditching the relation metaphor ?
[20:47] <bdx> Endpoint* class^
[20:47] <cory_fu> bdx: The terminology is that “endpoints” are the named connection point which form either end of a relation, with the “relation” being the active connection.  So, the name is associated with the endpoint, and the Endpoint instance has a list of established relations
[20:48] <bdx> aaha
[20:48] <bdx> thanks for that
[20:48] <cory_fu> bdx: The relations property is defined here: https://github.com/juju-solutions/charms.reactive/blob/feature/new-relations/charms/reactive/endpoints.py#L127
[20:48] <bdx> excellent, thank you
[20:49] <bdx> so self.relations is still a thing
[20:49] <bdx> ok
[20:49] <bdx> sweet, tracking
[20:50] <cory_fu> I know it’s a terminology change, but I’m hopeful that it is more precise and avoids some confusion, even though it is more to grok at first.
[20:51] <cory_fu> I thought we had a write-up of the terminology somewhere, but I’m having trouble finding it
[20:51] <bdx> it totally does
[21:16] <bdx> cory_fu: did context go away too?
[21:17] <cory_fu> bdx: It did.  I thought I mentioned that to you the other day?
[21:17] <cory_fu> Unfortunately, it doesn’t work with old-style interfaces, so we can’t really support it.
[21:18] <bdx> http://paste.ubuntu.com/26014988/
[21:19] <bdx> cory_fu: how do I access the api provided by the interface layer?
[21:19] <bdx> I must have missed that part my bad
[21:21] <cory_fu> bdx: Instead of “endpoint = context.endpoints.name”, you would use “endpoint = endpoint_from_name(“name”)"
[21:21] <cory_fu> Then it should otherwise be the same
[21:24] <bdx> so http://paste.ubuntu.com/26015030/
[21:24] <bdx> would not work
[21:24] <bdx> because I need to index into "endpoint = endpoint_from_name(“name”)" to pull out to relation data ?
[21:50] <cory_fu> bdx: Sorry, I’m actually on the road and lost connection
[21:50] <R_P_S> cory_fu bsx left #juju
[21:52] <cory_fu> Oh, shoot
[23:07] <R_P_S> so I've got a default conjure-up k8s cluster running with helm, I went to install nginx-ingress with helm, and it's trying to create a load balancer indefinitely pending