=== menn0 is now known as menn0-school-run === menn0-school-run is now known as menn90 === menn90 is now known as menn0 === axino` is now known as axino === frankban|afk is now known as frankban === mpavone1 is now known as mpavone [08:37] Hello Juju World [12:43] o/ mornin kjackal [12:43] Hi lazyPower! [12:44] How is you google fiber? You got one, right? [12:44] You betcha! Its crazy fast on just the 5g wifi, i'm excited to get a proper cat6 connection and really flex it [12:45] kjackal - prelim benchmark numbers here: https://www.evernote.com/l/AX4wf7WjnZJNo4WzhugoNuHlcFT9-f_-JPQB/image.png [12:45] lazyPower: whoa, cool. how much ipv6 space do they give you? [12:45] Wow! [12:46] jrwren - no idea, i haven't investigated that [12:46] What do you mean by ipv6 space? [12:47] You also get a range of public IPs?? [12:47] some ISP give two or three /64, others give a /56. [12:47] kjackal: yes, a range of billions [12:47] Wow!!! [12:48] kjackal: yeah, its pretty cool to have all my home systems including virtual machines and containers on public internet with unique addresses. [12:49] it is just too bad the whole world isn't ipv6 enabled. I can't really serve things on those address only. [12:49] jrwren - also, that post you were looking at got published this morning :) http://dasroot.net/posts/2016-08-03-layer-docker-deep-dive/ [12:49] insane!!! IPv6 = Hackers paradise! [12:49] i'll hit up the mailing list later today. bugs/comments welcome :) [12:49] lazyPower: thanks! [12:51] jrwren - i'm not sure i want everything in my home ot be addressable on the www [12:51] I rather like the idea of NAT traversal for that, and well defined routes/dmz [12:53] lazyPower: me too. it was scary when I realized I never set an ingress deny all rule for ipv6. [12:53] lazyPower: once i setup a basic firewall, it was nice. [12:53] jrwren - so, ipv4 SDN it is ;) [12:53] and then an ingress reverse proxy [12:54] i'm going to spin all my ip enabled lights up on calico *Does the hokey pokey shuffle* [12:54] lazyPower: well, that ruins the whole point, but I guess we've gotten so good at reverse proxy config that it is trivial. [12:54] i fear change :| [12:54] lazyPower: now you sound like me. [12:54] (not realy, but it helps frame the picture here) [12:55] yeah, it frames the picture. total role reversal from our usual discussions ;] [12:57] :D [12:57] its funny because its true [13:00] yup. I think it is a good example of our comfort zones. [13:19] lazyPower: You up for PROMULGATION? Or is that marcoceppi or mbruzek ? [13:19] stub - i'm in a meeting, when i'm out of it i'm happy to lend a hand [13:19] i'm scheduled for another 45 minutes [13:19] what up stub? [13:19] PROMULGATION! [13:19] https://jujucharms.com/u/prometheus-charmers/collectd https://jujucharms.com/u/prometheus-charmers/prometheus https://jujucharms.com/u/prometheus-charmers/prometheus-pushgateway https://jujucharms.com/u/prometheus-charmers/prometheus-alertmanager https://jujucharms.com/u/prometheus-charmers/grafana [13:19] i actually had to google that word the first time I saw it..... [13:20] Its a real word? [13:20] magicaltrout: I am pretty sure we made that word up [13:20] it is, and it's here for historical reasons :) [13:20] I would hope so. Can't have anyone accusing you of being literate ;) [13:20] stub: in the future, could you use "software-team" instead of -charmers? [13:20] to make known by open declaration; publish; proclaim formally or put into operation (a law, decree of a court, etc.). [13:21] I could... although I chose charmers to avoid stomping on the toes of the teams developing the actual software. [13:21] stub: well, the teams developing the software should eventually own the charms ;) ;) ;) [13:22] And I'd be more than happy to promote them to CHARMERS! [13:23] stub: haha, fair enough. The reason i bring it up is because the team name shows as the owner of the charm now (FINALLY) and people are confused by what a charmer is from a user/consumer level [13:23] mbruzek: are you goind to do the promulgation/review? [13:24] For 6 charms? [13:24] yup. We can change it without breaking the URLs - team name is not used anywhere except in the unpromulgated cs: URL [13:24] 5! [13:24] But the second and third don't have readmes yet. [13:24] mbruzek: I can take a swing instead if you'd like [13:25] marcoceppi: I seem to remember you are on vacation [13:25] So no [13:25] mbruzek: yeah and I'm also a member of the Ubuntu Community [13:25] marcoceppi: I can do this. [13:25] which I do in my spare time [13:25] vacawhat? [13:26] i don't believe anyone in IT actually takes a vacation [13:26] mbruzek: So collectd is just https://bugs.launchpad.net/charms/+bug/1538573 , which got as far as landing in a ~charmers branch at which point injestion failed and it froze. [13:26] Bug #1538573: New collectd subordinate charm [13:26] stub: The last 2 do not have icons or readmes. I can not promulgate those [13:27] stub is there a bundle that includes all these charms? Do they have tests? [13:27] We have mojo jobs using some of them [13:28] stub: that is nice. You know we use bundletester. [13:28] So prometheus and grafana and collectd being tested. === redelmann_ is now known as redelmann [13:32] Looks like we have amulet/bundletester for collectd, which deploys and connects it to an ubuntu charm. [13:33] Just a basic deploy for prometheus, no relations [13:34] Nothing for grafana apart from the mojo specs, and a few production deploys. [13:36] stub: looking at these readmes, this is all 1.25.x right? [13:38] mbruzek: Yes, only tested with 1.25 and trusty at the moment. [13:38] stub: OK, let me run bundletester and take a look at the beautiful code before I promulgate [13:39] Its not mine, so no need to be gentle :) I'm just trying to organize it into a shared area so we stop treading on each others toes. [13:40] https://launchpad.net/prometheus-charms [13:41] mbruzek: I'll pop out for an hour then, I'm being requested downstairs. [15:04] marcoceppi: hey, could I ask you to help me make sure everything's straight in this reactive charm I've inherited that tries to do a juju-info relation? [15:04] marcoceppi: it seems to be based on https://gist.github.com/marcoceppi/fb911c63eac6a1db5c649a2f96439074 [15:05] Hi Spads: Marco is on vacation today, I can take a look. [15:05] Does it not work ? What is the issue? [15:05] well [15:05] we were hoping to make a subordinate that would use juju-info with its parent to get the IP [15:05] and then crack on [15:06] but the @when('push-gateway.available') function never seems to fire [15:06] despite the relation seeming to be established [15:06] and I am looking at all this reactive charming stuff and there's a lot of boilerplate full of magic strings and I worry it's not wired up the right way [15:07] Spads - i wrote the juju-info interface. Are you seeing some side-effecty behavior of that interface? [15:07] (in reactive anyway) [15:07] lazyPower: well no, I'm just not sure if my reactive code is wired up right [15:08] like, I get silence [15:08] and no idea what's wrong [15:08] yeah, that *should* work according to your gist [15:08] https://github.com/juju-solutions/interface-juju-info [15:08] we raise both .connected and .available [15:09] well hangon [15:09] this has a custom class JujuInfoClient(RelationBase): to do that [15:09] however i see we have -broken in there, and that's not good. decorating for -broken will -broken the interface. [15:09] I have a scenario wherein I will have to add a relation between apache2 charm and my charm thereby I need to feed vhost.tmpl file from my charm to apache2 charm. So, Is there any interface available @ interface.juju.solutions for apache vhost configuration? [15:09] Here I want everything to be done thru charm only and I don’t want user to feed vhost.tmpl file using juju set command. Please suggest me on this scenario. [15:09] because I think the juju-info layer had some problem and they couldn't use it? [15:10] Spads - interesting, i'm curious to know what that problem may be [15:10] I mean quite frankly I look at https://github.com/juju-solutions/interface-juju-info and immediately say "wait, what do you mean {{name}}?? What is that? HOw do I know when I've chosen correctly?" [15:10] Spads - thats defined by the relation name in metadata.yaml [15:10] we do need to update the readme on that interface [15:11] could you make that clearer in the readme? [15:11] good catch [15:11] you bet [15:11] like maybe give a concrete example? [15:11] because I feel like the problem I'm having is looking at a mess of wires connecting things to other things and getting dead air [15:11] and I'm not sure how to work out the correct way to wire these things up [15:11] so in a debug-hooks session [15:11] run 'charms.reactive get_states' [15:11] lets get a snapshot of what is actually set on the unit, and draw some conclusions about what should be there [15:12] so in debug-hooks I need to actually break something, right? [15:12] shouldn't, once you're attached via debug-hooks, and the relations have been set/run - you can run 'charms.reactive get_states' on the bash shell in that ocntext, and get a listing of what states are set on the unit [15:13] how do i set/run the relations? [15:13] they're already connected [15:13] remove/re-add? [15:13] if they're already connected, you shouldn't need to do anything other than attach via debug-hooks, and either trigger a config-changed, or update-status (wait) [15:13] hm [15:13] then run the command: 'charms.reactive get_states' [15:13] it's clumsy getting multiple shells in this env. hangon [15:16] Huh [15:17] so I guess the relation is never joined? [15:18] oh n'mind [15:20] Spads - not sure what you're seeing at this point ;) [15:20] yeah it's a subordinate so it's odd [15:21] I'm re-adding and working through all the hooks [15:21] so my thoughts are, if you've seen the relation-hook run, and you dont see the associated state, there's something wrong with the interface code thats not properly setting the state [15:21] oh gads [15:21] which would explain why you're not seeing your reactive code trigger [15:21] I think nothing is linked [15:22] like theres no relation hook script in hooks [15:22] grrrrr [15:22] okay [15:22] too obvious [15:22] ok, thats another good indicator [15:22] Spads - can you link me to the charm layer in question? [15:22] i'm happy to take a look [15:22] lazyPower: not sure it'll help but https://bazaar.launchpad.net/%7Ecanonical-losas/canonical-is-charms/snappy-kpi-scripts/files [15:23] Spads - here's the culprit [15:23] - "layer:juju-info" [15:24] layer: directives wont trigger the builder to include the hooks/relations/<> [15:24] mmm [15:24] that will *need* to be an interface to have that behavior [15:24] Spads - if you convert that to 'interface:juju-info' [15:24] in includes not requires? [15:24] that was in your layer.yaml [15:24] yes [15:25] https://gist.github.com/marcoceppi/fb911c63eac6a1db5c649a2f96439074 <-- in requires section [15:25] ours has it in includes section [15:25] which should it be? [15:26] includes is the proper keyword [15:26] includes: [layer:basic, interface:juju-info] ? [15:26] ok [15:26] that requires blurb is wrong, i dont know where that came from [15:26] heh [15:26] ok [15:27] I wish charm build didn't need so many magic directories and env vars [15:27] i don't think it does. [15:27] the docs are wrong. I ran charm build yesterday without ANY dirs or env vars. [15:28] I don't remember the details, but IIRC those dirs are only needed if you are using local/private layers or interfaces. [15:28] jrwren those are only required if you're going to do local development [15:28] if you are using only published layers or interfaces, you don't need them. [15:28] OSError: [Errno 2] No such file or directory: '/home/nick/work/snappy-kpi/snappy-kpi-scripts/trusty/snappy-kpi-scripts/requires.py' [15:28] such as revving 2 interfaces before you publish to the interfaces repository [15:28] correct [15:28] hm [15:28] charm build did NOT like that [15:29] I have a requires.py in $PWD [15:29] err, is $PWD your $INTERFACE_PATH? [15:29] it should be in $INTERFACE_PATH/<>/requires.py [15:29] Ithought you said env vars didn't matter [15:29] only if you're using layers from the interface repository [15:30] I don't have an $INTERFACE_PATH [15:30] if you're doing local development, you'll need to have those env vars set. [15:30] ew [15:30] okay [15:30] I just want to build the charm into ./trusty/etc [15:30] so I can commit it and deploy it [15:30] if those interfaces are not listed on http://interfaces.juju.solutions, you'll need to have thos env vars set [15:31] but juju-info and base are, no? [15:31] juju info is, layer:basic is as well, yes [15:32] hmmmm [15:32] not sure why I'd need that to build this then? [15:32] Spads - you can override any local search behavior: charm build -r --no-local-layers [15:32] that defaults any local repository searching, and will *only* build from the interfaces webservice provided layers/interfaces [15:32] build: Added unexpected file, should be in a base layer: deps/interface/interface-juju-info/requires.py [15:32] etc ad infinitum [15:33] oh deps is left over? [15:33] hmmmmm [15:34] * Spads tidies up [15:36] Spads: I wouldn't built to ./trusty, or you will recursively blow off your foot when you run charm build a second time [15:37] that sounds like a terrible default then [15:37] Its the default? Hmm... [15:37] it relies on the presence of $JUJU_REPOSITORY to output your build by default. if you dont have that set, it will default to ./ [15:37] bugs welcome [15:37] https://github.com/juju/charm-tools/issues/ [15:37] heh [15:38] yeah I finally had to make a github account for snappy stuff. [15:38] Spads - but to be completely fair, we outlined what you *should* have set, in teh building docs. [15:38] and those environment variables shape the behavior of your charm-build experience [15:39] sure but I shouldn't have to [15:39] this is the only build tool I've ever used that needed magic env vars, aside from maybe mojo [15:40] and I'm not sure I like the pattern [15:41] anyway I think I've worked out what hacks were done to get around charm build here [15:41] Spads - well capturing that feedback in any case would be good. Bugs welcome, we want this to be a good experience for everyone out of the box, no matter how much hate for environment variables you may have :) === frankban is now known as frankban|afk [16:28] mbruzek: Let me know if any pass :) I'm powering down for the night. [16:28] stub is there a bug or issue filed for the review? [16:29] mbruzek: No. I'm being annoying in person instead ;) [16:29] I have some blocking issues with collectd, working on prometheus now, much of the same so far. The code actually looks pretty good, but the readme and tests are not really good [16:30] stub, to whom shall I send the review comments to? [16:30] Yup, what I was expecting [16:30] mbruzek: Its me and jacek at the moment [16:31] stub: Its not mine, so no need to be gentle :) [16:32] stub: ok [16:35] We have most of the branches collated anyway, in a central spot. It was looking like becoming a mess of forks. Next up, get them to the top level namespace. [16:42] jrwren aisrael - offtopic, but totally worthy of your attention https://www.kickstarter.com/projects/kcgreen/this-is-fine-plush-dog [16:44] lazyPower: hahahahahaha [16:46] i nearly funded that until i realized i would have more plushes than your average adolescent... [16:52] I have a scenario wherein I will have to add a relation between apache2 charm and my charm thereby I need to feed vhost.tmpl file from my charm to apache2 charm. So, Is there any interface available @ interface.juju.solutions for apache vhost configuration? Here I want everything to be done thru charm only and I don’t want user to feed vhost.tmpl file using juju set command. Please suggest me on this scenario. [16:53] Prabakaran - i dont see anything listed on http://interfaces.juju.solutions/ that looks helpful to this goal. The interface may need to be created. [16:53] Prabakaran: I don't think we currently have a relation that does a vhost.tmpl file on the interfaces site yet [16:53] mbruzek - go get lunch ;) [16:53] i got dis [16:53] Prabakaran: I remember there may be a vhost config option on the apache2 charm, can you do that? [16:54] yes, but it uses juju set-config [16:54] Prabakaran: I see you don't want to have the user juju set the vhost, sorry i [16:54] Prabakaran: what would be in the vhost.tmpl? [16:55] Prabakaran: Can you template the vhost in the charm? Or use templates to replace a few variables such as public-address, port or something? [16:55] do you have any alternative method or suggesstion for my requirement? [16:55] Prabakaran - as juju uses bundles, you could reasonably encapsulate that vhost config in the bundle you distribute with your solution. That removes the need for the user to specify it, and you can use the existing primitives. [16:55] Prabakaran: What is the requirement? When you attach a http relationship, you want to configure a specific vhost? [16:56] i am not sure how i will do vhost config if i use http [16:56] as per apache2 readme i can do vhost config using juju set-config [16:57] welp, 3 cooks in the kitchen. /me dips out [16:57] i went and checked inside the apache2 charm and it places the vhost file under /etc/apache2/sites-available/ [16:58] i meant if i use juju set-config [16:58] Prabakaran: Yes that is what I remember from apache2 charm. [16:58] Prabakaran: But that does not work for what you want. [16:59] if i am using any interface in between also i will have to think about ssh exchange from my charm side and apache2 charm side [16:59] Prabakaran: Yes you could do that. I am trying to think of other options. [16:59] yes pls [17:00] Prabakaran: what is the relation name that you are connecting between apache2 and your charm? [17:01] vhost-config relation [17:07] Prabakaran: It looks like that vhost-config a relation that has not been made reactive yet. You should be able to prototype a vhost-config relation in your $INTERFACE_PATH and make a provides.py (I would recommend doing both, but at a minimum do provides) that sends "vhosts" and "port" over that relation. The code that handles the vhost-config relation is in hooks.py of apache2 charm. [17:11] Prabakaran: It looks like the landscape server charm uses this vhost-config relation. [17:11] https://jujucharms.com/landscape-server/precise/17 [17:12] If you look at hooks.py in that charm, you may be able to figure out how to write a new reactive interface for that relation. [17:12] Prabakaran: If I remember correctly the vhost file had to be base64 encoded so it does not have any characters that would escape the string when transporting the file. [17:13] ya correct it uses base64 [17:13] Prabakaran: so the vhost template/file did not have any special characters that would terminate a transport string. I found that odd when I looked at it. [17:14] yes, lets consider this.. i will be having prototype of vhost.tmpl file and from my charm if i am sending ip and port, how i will handle it on apache2 side? [17:17] what i feel is.. this is something how mysql-client is installed for its remote operation [17:17] Prabakaran: Look how the landscape charm provides that relationship. I see config/vhost.tmpl files in the landscape charm, those are base64 encoded in the hooks.py. In that file, I see a juju.relation_set() method called with the key "vhosts"=yaml.dump(vhosts) [17:18] so I think you have to send more than ip and port, I think you need to send a vhosts object which is a yaml file of a specific format, you can get the format from the landscape charm hooks.py or looking at how the 'vhosts' key is decoded from the apache2 hooks.py side. [17:19] Prabakaran: You could write this in a new interface and be the first one to implement the vhosts-config relation. [17:20] Prabakaran: I have to step out for lunch, and will be back in 30 minutes [17:20] ya sure.. meanwhile if u think something also ..please mail me [17:22] Prabakaran: that is my answer! You will have to look at the landscape charm for hints on how to properly set the object and I believe the apache2 charm will set the vhost correctly if you can manage to figure that vhosts object correctly. [17:30] thanks mbruzek [17:30] let me have a look at it [18:32] mbruzek - ready for some stellar news? We had our first pure community submission against the k8s work in upstream -- https://github.com/cusspvz/kubernetes/commit/fdec5d12288b896ac7b45abf8081be179abc823a [18:32] adding osx compat to the kube-up scripts [18:32] sweet [20:08] generic question... does interfaces.juju.solutions/interface have versioning? [20:08] seems like somebody pulled the rug from under us with http://interfaces.juju.solutions/interface/pgsql/ but I have no idea what interface I was pointing at previously... [20:12] lutostag - we dont [20:12] we do have an audit trail though [20:12] but its not exposed afaict. its just an additional collection we're tracking internally to know who did what for reasons like this [20:13] lazyPower: ok, I'll see if I can track it down my side to see if I can find the 'old' repo [20:13] thanks for info