[00:32] i'm trying to bootstrap a juju 2.0 controller behind a firewall. how do i specify a proxy to use? [00:53] the bootstrap is stuck trying to get the tools (i think) [01:03] bjf: there is config for proxies, http_proxy, https_proxy, ftp_proxy no_proxy [01:03] etc [01:03] also apt_http_proxy [01:03] * thumper looks for docs [01:04] bjf: https://jujucharms.com/docs/2.0/juju-misc#configure-proxy-access [01:19] thumper, juju 2.0 doesn't recognize "juju set-env" [01:23] thumper, if i set that in the environments.yaml file do i set it under "environments:" or under the next level "maas:" ? === wolverin_ is now known as wolverineav_ === natefinch-afk is now known as natefinch [02:10] bjf: set-model now [02:10] bjf: also there is no environments.yaml for 2.0 now [02:10] bjf: but clouds, accounts etc [02:10] thumper: so that doc is pretty much completely wrong :-) [02:10] wallyworld: do you know where the docs are now? [02:11] bjf: damn... [02:12] thumper, meh, it's fast moving .. i'm sure it will get fixed up [02:13] thumper, so, i have a fairly recent 2.0 install on this system, never a 1.x and yet there is a .juju/environments.yaml file [02:13] hmm... [02:13] weird [02:14] thumper, there is no set-model either [02:14] * thumper looks [02:14] set-model-config [02:14] `juju help commands` is helpful [02:15] thumper, ok, lots more there than i thought [02:16] thumper, that can only be used after i already have a controller [02:16] bjf: look at `juju help bootstrap` [02:17] you need to pass in some config yaml [02:17] thumper, and that config.yaml can just be name=value pairs? [02:18] look like --config=somefile.yaml works [02:18] and in there you have you keys and values, like: [02:18] default-series: xenial [02:18] apt-http-proxy: http://10.250.171.1:8000 [02:18] etc [02:18] thumper, ack, thanks, will give is a try [02:18] kk [02:18] let us know how it goes [02:19] will do [02:20] bootstrapping .. will take a while [03:02] thumper, i must not have it right. it's been sitting at "Fetching tools" for some time [03:02] my config file: [03:02] $ cat juju-bootstrap-config.yaml [03:02] http-proxy: http://squid.internal:3128 [03:02] https-proxy: http://squid.internal:3128 [03:02] [03:03] the command line: juju bootstrap kernel-controller kernel --constraints tags=juju-controller --debug --config=~/juju-bootstrap-config.yaml [03:05] hmm.... [03:05] wallyworld: thoughts ^^^^? [03:06] um [03:07] thumper, ok, may be my problem [03:07] looks ok, assuming there's a custom cloud called kernel [03:07] if the proxies are not working as expected, then tools will not be fetched [03:09] wallyworld, thumper yeah, i think i don't have the proxy right .. debugging [03:50] thumper, wallyworld thanks for the help. got it bootstrapped. had nothing to do with the proxy, maas config issue i hadn't noticed before [03:50] bjf: sweet [03:51] great === jamespag` is now known as jamespage [08:43] Hello Juju World! [08:43] Morning! === mwhudson_ is now known as mwhudson [13:19] Mornin #juju o/ [13:20] ahoyu [13:20] -u [13:20] ohaiyu magicaltrout [13:21] speaking of... We still need to do that sync [13:21] yeah we do [13:21] next week would actually be good because i'll be post op eye surgery and pretty incapacitated but with a bunch of spare time for talking [13:23] oh! [13:23] i scheduled for friday, any specific day next week? I'm happy to move [13:23] yeah friday is actually op day, so that wont be happening ;) [13:23] tuesday or wednesday would be good [13:23] lol! how dare you take care of yourself [13:23] same approx time work? I wanted to catch the UK/US overlap as best i could [13:24] 3pm UK would suit [13:26] Updated for Tuesday, 8/16 [13:26] thanks tom :) [13:26] no probs [13:27] should be good [13:27] just lmk if you need to resched. eye surgery... oi [13:27] i've thought about going down that path to get rid of the spectacles... i'm still iffy about having someone cut on my eye [13:28] should be 5 days unable to see properly cause i have to wear pretective contacts post op because of a thin cornea or something [13:28] so i have a bit more recovery time and annoyance, but should be good to get rid of the glasses [13:28] I'm going to live vicariously through you, and then goad myself into doing the same [13:29] they said the op takes about 30 seconds an eye?! [13:29] assuming you dont grow eye gremlins [13:29] if you grow eye gremlins all bets are off [13:29] lol [13:29] yeah well i might go blind [13:29] you never know [13:29] i sincerely hope thats not the case [13:29] hehe [13:29] i'm sure you'd pick up TTD pretty quick, but i digress [13:30] i'd rather not test the state of accessability in the world [13:30] well everyuone i spoke to have said it was the best thing they've had done [13:30] so I figured what the heck [13:31] Looking forward to derailing the meeting over the download from the experience :) [13:32] #destroyallmeetings [13:32] hehe [14:29] dynamic UID and GID on containers where root access isn't allowed [14:29] in docker [14:29] what a bloody hack [14:29] yup [14:29] the new security paradigm in docker confuses me [14:31] we have a bunch of NFS backed containers and the UID/GID for dev/staging/prod have to be different which is fair enough, so I had a semi hack with gosu in place [14:31] but that doesn't stop exec /bin/bash giving you a root shell [14:31] which makes security folks sad [14:32] admittedly the person would already have broken into your host, but thats beside the point [14:33] so now I have a hack that creates a user in the docker file, does its stuff, then in the entrypoint sudo's(sadface) modifies itself to set the new UID/GID, chowns a bunch of stuff then removes its own root access..... [14:39] https://www.minio.io/ -- neat [15:17] Hi people, we have in juju some funny command to change the public ip in one charm? [15:39] D4RKS1D3 - not sure what you mean by "some funny command ot change the public ip" [15:40] are you asking if you can change the units public-address? [15:40] yes lazyPower [15:41] D4RKS1D3 - i may be incorrect, but as i understand it, the public-address is auto-discovered by the agent, and is fed by metadata from your cloud. You could reasonably remote into the unit and manually change this in the agent config, but i dont know that I would advise doing that, as i'm not sure what unintended side effects it may have [15:41] D4RKS1D3 i do believe that our openstack provider has the notion of a floating ip. and I would urge you to mail the list about that [15:42] I have my lxc working to run openstack [15:42] I mean this lxc public ip [15:42] these* [16:22] rogpeppe, any concerns with migrating https://launchpad.net/gnuflag over to using git instead of bzr? I'm asking because we're encountering a bzr issue trying to build a juju snap using launchpad. [16:22] rogpeppe, you can see the details here: https://launchpadlibrarian.net/277983664/buildlog_snap_ubuntu_xenial_amd64_juju_BUILDING.txt.gz [16:22] balloons: is that the only remaining bzr dependency? [16:23] rogpeppe, if godeps could pull from a git source we would be a-ok. It's one of 2 remaining bzr depends. Interestingly enough the other is tomb, which I think could be updated to point to the git repo [16:23] so, it may very well be the only one [16:28] rogpeppe, it's interesting you still need a fork for the package after all these years [16:28] balloons: i'll take a look. i don't think there'll be any problem moving gnuflag. [16:29] rogpeppe, awesome. I'm happy to make the change in the dependencies.tsv and do a PR once it's done, or you can propose [16:29] balloons: sure [16:30] balloons: and it looks like we could move the tomb dep to gopkg.in/tomb.v1 without probs too [16:47] balloons: i've created https://github.com/juju/gnuflag [16:47] balloons: have fun :) [16:48] rogpeppe, ty! :-) === frankban is now known as frankban|afk [19:49] tvansteenburgh, got a bit of a hot one here. seeing test leaks (false passes) over this guy: https://github.com/juju-solutions/bundletester/issues/54 [19:49] and a patch to accompany: https://github.com/juju-solutions/bundletester/pull/55 [19:51] beisner: merged [19:53] tvansteenburgh, thx sir [19:59] wg 15 [20:09] kwmonroe: I'm going to be charming up a few grails apps over the next few days/weeks [20:10] kwmonroe: I'll be making use of openjdk charm quite a bit it looks like :-) [20:11] bdx - how did your ES/Kibana deployment go? get them all charm upgraded? [20:11] errr .. making use of the openjdk *layer [20:12] don't trust anything written by a texan [20:13] https://jujucharms.com/docs/2.0/authors-charm-writing seems to be completely out of date for JuJu 2.0 .. can anyone point me at more up-to-date docs for writing my first charm? [20:13] lazyPower: I barked up that tree for a while ... the app is being sold to a customer .... our project managers don't think it makes sense for our devs to spend cycles there I guess [20:13] at least I tried [20:13] :-( [20:14] bjf - wow you found a really crutfy doc, have a look here [20:14] https://jujucharms.com/docs/2.0/developer-getting-started [20:14] magicaltrout: are you tex-ist? [20:14] bjf: https://jujucharms.com/docs/2.0/authors-charm-building [20:14] cool bdx!! let me know if you run into things that you'd like. eg, we could make jvm params configurable and pass them on the relation.. so charms that required java could do @when(java.ready), function start_me_up(), java {java.get_tuning} myJar [20:14] bdx - no worries :) was just curious since we spent some time troubleshooting a really ancient tutorial [20:14] er, s/tutorial/installation [20:14] no bdx just kwmonroe-ist ;) [20:14] lazyPower, magicaltrout thanks [20:15] magicaltrout - stop linking to the author docs, they're basically deprecated at this point. [20:15] bjf - feedback / bugs / et-al welcome on the developer guide [20:15] bjf - if you do enounter any head scratchers - https://github.com/juju/docs/issues [20:15] lazyPower: i just googled charm layer writing [20:15] and that was top [20:15] surely that one can't be that out of date [20:15] i cannot change google :( i'm sadly not a panda [20:15] magicaltrout: hes going to get you for that one [20:16] like the boogieman [20:16] at a scan it looks current lazyPower what am I missing? [20:16] magicaltrout - it sure can, the author docs were the developer guide before we went through and re-wrote them as the dev guide. THey linger for purposes unknown to me [20:16] bdx: he's too lazy to get any body [20:16] magicaltrout, i got that by googleing "juju charm tutorial" [20:17] i feel like i should get somebody.. but i'm just gonna stay on the couch instead. [20:17] lazyPower: you say that but [20:17] https://jujucharms.com/docs/2.0/developer-layers [20:17] then you click on the Getting started link at the bottom [20:17] and it 404s :) [20:18] because it has a hard coded /devel link in there [20:18] * lazyPower sighs [20:18] * lazyPower resigns [20:19] hehe [20:19] heh [20:19] adios lazyPower ! ;) [20:19] noooooes [20:19] got my talk switched so i'm not clashing now lazyPower [20:19] amsterdam on the 31st [20:19] london on the 1st [20:19] eye op on the 12th [20:20] what could go wrong?! ;) [20:20] you could remind me that we have more work to do in the docs thanks to decisions that were made outside of anyone else knowing? [20:20] some cowboy out there owes us an explanation [20:20] don't forget you have more work to do on the docs due to decisions that were made outside of anyone else knowing [20:21] I think som cowbory out there owes you an explanation [20:21] kwmonroe: ? [20:21] * lazyPower sets off explosions and walks away [20:21] cool guys never watch the explosion [20:21] hehe [20:21] they're too busy walking away from it [20:21] it've seen that in films [20:21] so it must be true [20:22] anyone know how to rewrite jujucharms.com/docs commit history? asking for a friend. [20:22] hehe [20:22] here you go if you want to see a treat http://pastebin.com/F7mP83AB [20:22] the biggest hack ever to get the security i need in my docker entrypoint [20:22] jesus its taken all afternoon to figure out the correct order of hackage [20:23] kwmonroe - first time caller, long time listener - I hear its as simple as git rebase -i revno && git push upstream master --force [20:26] heh magicaltrout, "/bin/rm -rf /etc/sudoers", what could possibly go wrong? [20:26] i'm gonna giggle when /etc/sudoers is a symlink to / [20:26] lol i know [20:26] well i can clearly refine parts, but as I don't want sudo access any more [20:27] i'm just like "f-it, blow it away" [20:28] magicaltrout - <> [20:29] y u do dis [20:29] yeah magicaltrout, you not only said "f-it", you said "recursively f-it" [20:29] recursion is my life [20:31] you should totally do "rm -rf /${SUDOERS_FILE} || rm -rf /etc/sudoers". for security. make sure you get that leading slash in there. [20:32] i think this is more security by obscurity [20:32] * magicaltrout doesn't do what kwmonroe says anyway :P [20:37] anyway bdx, sorry for this trout spam, but i am really curious about your interactions with the java interface and openjdk layer. we could go really nuts with (making jvm params configurable, emitting a changed state so principal charms know they need to restart to get new jvm bits, etc). i feel it's a bit silly atm because it's just "install java... and done i guess." [20:38] you promised that when i said i was using jdk charm [20:38] never happened ;) [20:42] i remember magicaltrout. but you were just learning python, so i didn't want to make things too complicated. bdx can handle it. :P [20:43] hehe [20:43] you were all like "pyth... what comes next?" and i was all like "on dude, just type o-n!" [20:43] sad times [20:43] :) [20:53] kwmonroe: I think the elastic stack services could greatly benefit from those mods [20:54] kwmonroe: for example elasticsearch - cloud greatly benefit from the configurability of JAVA_OPTS [20:54] ES_HEAP_SIZE=10g [20:55] that currently defaults to 2g [20:55] glad you think so bdx, because that entitles me to ask you questions about the implementation. so.. if a principal service is running, would you (as the operator) be upset if some admin changed an openjdk config value and it restarted your service? [20:55] or would you rather that simply trigger a status update that sets the openjdk status to "settings changed, please restart the principal service"? [20:56] because, for example, restarting datanodes in a big data environment just because the heap size changed may not be a good idea for in-flight stuff. [21:00] on second thought.. it would be up to the principal charm author to decide how to react to java states.. so i guess it's not a big deal. java should tell/emit states and let whomever cares about it to deal with it. [21:00] they could check the config change [21:00] and see if its worth a reboot [21:01] yup, and the "worth" determination would be presented as a status change.. so the juju status would report "jdk settings changed; do something (or not)". i think i like that. === natefinch is now known as natefinch-afk [21:02] still, that's not on openjdk (or any java provider) to determine that. the principals that consume java would wire that in. [21:10] kwmonroe: so, people are writing java web apps because they want the security of the strongly typed/compiled app (majorly) right [21:10] kwmonroe: I would say puting each app in a silo would be optimal [21:13] kwmonroe: or each unit of an application [21:13] I see how that makes implementing shared javaops difficult though [21:14] yeah bdx, but we can't do each unit of an app.. or even each app in a silo. if you have ES, tomcat, and some big data stuff all related to the 'openjdk' charm, and you update the openjdk config, that's going to update for *all* apps related to java. [21:15] which is not great, i agree. you'd almost need to deploy openjdk as "es-jdk" and another for "bigdata-jdk" and another for "foo-jdk" and tweak the config as needed for each of those to get the silo'd config. [21:15] kwmonroe: yea .. I see that ... I think using it as a layer seems more reasonable in that scenario [21:16] but also slightly defeats the purpose [21:16] yeah, interesting.. i hadn't considered the java layer being a base layer for specific java apps. [21:16] i think i see what page you're on now. note, we're not on the *same* page, but at least i see yours over there. ;) [21:17] yes! [21:17] someone understands me [21:17] baha [21:18] its lonely overhere at creativedrive .... surrounded by php and rails devs [21:18] haha [21:18] im the only python guy in the company [21:19] bringing it [21:19] +1 bdx, i have faith in you! [21:20] kwmonroe: thx, I did too ... until I realized what one of our software projects was [21:20] -> https://www.morpheusdata.com/ [21:22] hello everyone.. [21:23] i am writing a charm and need help for the same [21:24] mayurisapre: is this related to https://askubuntu.com/questions/808638/juju-charm-how-to-get-ip-addresses-of-all-units-in-a-service-in-a-charm-hook-i/810156#810156? [21:26] yes [21:27] hi kwmonroe.. [21:28] i read your answer, bit still facing the same issue [21:30] mayurisapre: relation-list -r {id} should be returning all units in that relation. where are you calling relation-list? === menn0 is now known as menn0-exercise [21:30] i am calling it from myCharm [21:31] relation-changed hook [21:33] mayurisapre: what's the relation name that you're calling? [21:33] mayurisapre: relation-ids {name} <-- what's {name}? [21:33] halbaas [21:35] icey, kwmonroe: possibly you could hear me out on layer-consul [21:35] https://github.com/jamesbeedy/layer-consul [21:35] I have also tried this with mysql and wordpress [21:36] with db relation [21:36] in that case as well i got the same result [21:36] icey, kwmonroe: I immagine layer-consul could/should be used for the base layer for charm-consul, and subordinate charm-consul-agent [21:36] imagine* [21:38] the primary differences in charm-consul and charm-consul-agent is https://github.com/jamesbeedy/layer-consul/blob/master/templates/consul.json.tmpl#L12 [21:38] would be true for consul, and false for consul-agent [21:41] consul-agent wouldn't need to do any custom config on consul-relation-joined, it would be the consul server(s) that would run the `consul join ` on consul-agent-relation-joined [21:41] right? [21:42] here, let me finish whipping this together, then I'll ping you [21:46] mayurisapre: i deployed mysql and 3 wordpress charms and got this: http://paste.ubuntu.com/22850696/ [21:47] mayurisapre: the important bit is that last relation-list call that shows 3 values that correspond to the 3 wordpress units connected to the mysql charm [21:48] this is juju 2.0 right? [21:48] correct [21:50] i am currently using 1.25 [21:50] do you think this is causing the issue? [21:51] i don't think so mayurisapre, but i'll deploy on 1.25 and check [21:53] bdx: is charm-consul a principal and charm-consul-agent a subordinate? [21:54] bdx: if not, could you use leadership so the leader in a multi consul deployment set server: true and the rest false? [22:08] mayurisapre: what does this return for you? juju run --unit mysql/0 'relation-ids db' [22:15] i just tried it again [22:15] with juju run --unit mysql/0 'relation-ids db' it listed all three unit [22:15] but in debug mode [22:16] in db-relation-changed it listed just 1 unit [22:17] mayurisapre: how are you invoking debug mode? === menn0-exercise is now known as menn0 [22:18] with debug-hooks command [22:18] mayurisapre: how are you calling debug-hooks? juju debug-hooks mysql/0? [22:19] yes [22:20] mayurisapre: when you do that, the db-relation-changed hook will fire once for each connected unit. so it's possible you're only seeing the 1st wordpress unit. [22:21] but if I don't use debug mode even then in execution i get same results.. [22:21] i checked that from logs [22:24] mayurisapre: if "juju run --unit mysql/0 'relation-list -r db:x'" is showing multiple results (one for each connected unit), then it's working as it should [22:25] in a debug-hooks terminal, you'd have to run ./hooks/db-relation-changed, then exit, then let the debug-hook proceed to the next db-relation-changed hook for a subsequent unit [22:27] yes..things are clear to me now. [22:28] thanks a lot for your time. [22:28] i really appreciate it. [22:31] np mayurisapre, i'm glad you got it figured out! let us know if you have any other questions. [22:32] yes. It was really helpful. [22:32] thanks a lot again.