[07:10] Are interfaces a thing of the past? I found this URL on the NFS charm page - http://jujucharms.com/interfaces/mount - which appears to no longer exist. [07:24] hey I installed juju-core from ppa:juju/stable but there's no juju command [07:26] had to install juju-1-default, now there's a juju command.. [07:56] jcastro: i think thats probably a good idea, ill bring it up today (big data spain) [07:56] jcastro: only problem is it conflicts directly with apachecon [07:58] aye [08:00] oh it only conflicts with ApacheCon Core, not ApacheCon Big Data [08:00] that would have been really silly [08:03] i'm submitting talks to both and planning a week in the autumn sun ;) === ant_ is now known as Guest59427 [08:13] What is the best practise for installing (and later running) an external program from a charm? If, for example, I would like to download source from git and compile it during the install-hook, where should I place the executable? Would it be fine to symlink, "ln -s $GIT_ROOT/bin/program /usr/local/bin"? [08:14] general best practice would dictate you compile it prior to charm building I would have thought, sysadmins would cry if you told them you were compiling at install time ;) [08:14] other than that, your suggestion seems fine eeemil_ [08:19] Hehe. :) Thanks! === eeemil_ is now known as eeemil [08:46] I'm still quite new to Juju, when I try to deploy some units, their public adress (as reported by `juju status`) is a 10.0.0.*-address. Commands such as `juju ssh unitname/0` doesnt work. Are some units supposed to behave this way? If not, what could be wrong? [08:48] I don't believe they are supposed to work that way eeemil [08:48] did I spot you are an openstack user? If so, I've never touched it so I could be wrong [08:48] but it sounds unlikely they should be spinning up and unaccessible [08:50] Yeah, I'm working on a charm that is supposed to work with openstack. I myself has quite limited experience of the inner workings of openstack, so right now I'm learning about OpenStack and Juju at the same time... :) [08:50] yeah I've not touched it before, I prefer a simpler life :) [08:50] see if jamespage et al, are around [08:50] they should be able to help [08:51] Haha ;) Sure! [08:55] morning folks [08:55] eeemil, are you deploying to an openstack cloud? [08:55] or deploying a openstack cloud? [08:57] eeemil, btw we also have an #openstack-charms channel now as well [09:01] I'm deploying a openstack cloud on aws! [09:02] sounds like a cost effective way of getting a cloud.... in a cloud....! ;) [09:15] magicaltrout: ah good point re the confs [09:16] i have many good points [09:30] I heard you like clouds so i put a cloud in your cloud, so you can compute when you compute... I'm just testing stuff out. :) [09:45] ionutbalutoiu, hey - I just made some comments on https://review.openstack.org/#/c/335276 [09:45] needs some test case fixes to deal with different mechanism driver configurations between releases. [10:03] dosaboy, hey can you join #openstack-charms pls [10:03] ionutbalutoiu, hey can you join #openstack-charms as well pls [11:20] admcleod: magicaltrout: it might be worth having 2 teams go, one to each show, or an overlap, whatever makes the most sense? [11:23] jcastro: ApacheCon Core in Vancouver wasn't anything special, so having Big Data folk go to ApacheCon Big Data and then onto Big Data Spain would probably suffice... who knows [11:24] I have Pentaho Europe Community meetup the week before as well, so I'll be doing Antwerp -> Spain -> Spain [11:24] I need a bigger suitcase [11:27] jcastro: yeah, basically what magicaltrout said [11:27] see [11:27] I have many good points [11:28] are they both in barcelona or different parts of spain? [11:28] Seville and BCN [11:29] dang, further than I was expecting [11:29] seville? [11:29] yeah [11:29] that's not a train ride is it? [11:30] just get mark to send his jet [11:30] bigdataspain is in madrid [11:30] ah [11:30] fair enough, I assumed jcastro knew what he was talking about :P [11:30] magicaltrout just wants to go to seville [11:30] no [11:30] magicaltro+╡ Seville and BCN [11:30] ApacheCon is in Seville [11:31] Big Data Spain... it in Madrid [11:31] jcastro mentioned barcelona first [11:31] so I blame him [11:31] hmm.. something is also happening in bcn [11:32] or i thought it was. anyway, madrid to seville is only 2.5 hr [11:32] it sounds like a big data team spanish train tour is in order [11:33] hehe [11:33] what are the trains like admcleod ? :) [11:33] I took madrid->caceres by train once and they were awesome [11:34] I've not travelled in spain just been for meetups [11:40] jamespage: sure thing [12:22] jamespage, thank-you! I will fix them asap. Joined #openstack-charms as well :) [12:32] jcastro: http://conf.dato.com/2016/us/agenda_day2/ this one just popped up in my feed. Too late this year but worth keeping an eye out for next year [12:33] * jcastro nods [12:34] also Intel are making some efforts to gain traffic in that sector with TAP [12:34] http://trustedanalytics.org/what-is-tap/ you guys might want to make contact with them to discuss Juju with them [12:34] oooh [12:35] I can tell you who to make contact with [12:35] 2 mins [12:35] https://twitter.com/mchmarny find this guy on linkedin or somewhere and ping him [12:36] dang, the installation pages are blank github wiki pages [12:36] the link is borked jcastro [12:36] https://github.com/trustedanalytics/platform-wiki-0.7/wiki [12:37] got it [12:49] ionutbalutoiu, awesome! [12:52] mbruzek, are you around for another question about etcd/TLS? [13:01] neiljerram: Yes I am [13:03] mbruzek, Thanks. I wanted to check my understanding of how client certificates are generated. IIUC, the etcd leader unit (via layer-tls and tlslib) generates just one client certificate, and hands this out to however many etcd clients connect to it - as opposed to, say, generating a different client certificate for each client that connects. [13:04] mbruzek, Is that correct? [13:05] neiljerram: Yes I think for the client certificate that is correct. Each peer (unit of the same charm) generates a certificate signing request (CSR) and the leader/CA signs a server certificate for them. [13:06] neiljerram: but yeah the client cert/key is only generated once and shared on leader data if I am not mistaken. [13:07] mbruzek, Thanks. I don't see any problem with that, just wanted to check. [13:07] neiljerram: OK [13:08] mbruzek, A detail, though: does this imply that the client cert doesn't need to have a name in it (e.g. hostname) that is specific to each client? Is that because the etcd/TLS server doesn't check any such field? [13:09] * mbruzek is checking the code [13:11] neiljerram: OK it looks like the client certificate is generated with the CN of the leader server, and the same Subject Alt Names as the leader... [13:13] But I thought for some reason that easy rsa omitted the name in the client cert generation [13:14] Unfortunately I don't have a deployment up right now, so can't confirm that... [13:14] I am bootstrapping... let me check this out [13:15] neiljerram: Are you getting a problem with the client cert? [13:15] No, not at all - just wanted to fully understand how things are working. [13:16] OK [13:23] neiljerram: I am spinning up an etcd cluster now to verify, you can ask all the questions you wish. [13:23] mbruzek, I have a cluster on the way up too... [13:29] http://paste.ubuntu.com/18701906/ [13:30] neiljerram: This is the client.crt on an etcd cluster. The issuer is always going to be set, but the Subject name is "client" [13:31] OK. [13:31] It looks like the code does set subject alt name to the three things identifying the server: IP Address:10.84.141.15, IP Address:10.84.141.15, DNS:juju-f9bdca-0 [13:31] It probably doesn't need to do that [13:31] Yes, I see that too. [13:32] So presumably, when an etcd client submits its certificate, the server (i.e. etcd master node) is happy with "client" ? [13:33] That is my understanding. the same TLS code is used for kubernetes and I have been successful using the client key in kubernetes as well [13:34] OK, that's great, thanks very much for checking all this. [13:35] neiljerram: If you have any problems or want us to change they way they are generated: https://github.com/juju-solutions/layer-tls/issues [13:35] Sure - thanks! [13:35] neiljerram: I don't think SANS should be set for the client, as this could be used by any client [13:37] mbruzek, I'm not sure I understand the impact there... [13:38] neiljerram: We worked hard to get the SANS in the server certificates so they could be referred to by the public and private and dns name. I don't think the client certificate needs that. I don't think there is a problem with them there just not technically correct. [13:40] mbruzek, Do you mean "not technically correct" because those SANS are names/IPs of the server and not of the client? If so, I think I understand :-) [13:41] yes. My understanding of the client certificate is it can be used by any client (like your laptop) and if the SANs are baked in then those addresses are not correct. [13:41] I don't think they are checked [13:41] We were working so hard to get SANs in the sever cert I must have put them everywhere. [13:42] :-) [13:42] tls is hard [14:39] is there a reasonably direct way of accessing all unit IPs of a service in amulet? [14:41] icey: loop over the dict? [14:41] icey: public or private? [14:42] marcoceppi: doesn't really matter, I'm testing something that is outside of Juju's scope but I want to test from amulet [14:44] icey: x['public-address'] for x in d.sentry[appname] ? [14:44] jrwren: thanks, looks like it should do it :) [14:52] * marcoceppi recommends doing x.get() to avoid key errors [15:02] marcoceppi: coreycb: urulama|afk just let me know that there can only be one promulgated charm per user across all series [15:03] so there can't be a promulgated xenial zookeeper under cory and separate promulgated precise zookeeper under james [15:03] the issue this really brings up is how we handle upgrades between non-layered and layered charms [15:17] neiljerram: Still here? [15:17] mbruzek, Hi, yes. [15:17] neiljerram: https://github.com/juju-solutions/layer-tls/pull/40 [15:17] neiljerram: Please review and let me know if that is OK with you [15:18] mbruzek, Sure, will do. [15:18] I built etcd with that tls layer, everything still worked and there were no SANs in the client certificate. [15:25] mbruzek - i pruned the layer-tls issue tracker. it looks like we hadn't been in there in a bit, and had closed out an additional 3 bugs [15:25] lazyPower: I would like your help on one of them [15:26] sure, whats up? [15:29] lazyPower: Wasn't there a need to put additional SANs in the leader's cert for 10.1.0.1 ? Or was that an issue on a different layer? [15:29] mbruzek - we do need to get the SDN address of the unit added to its CSR [15:30] lazyPower: I need your help on how to do that in a generic way, that sounds like something the tls layer will have to grow support for [15:30] i dont think we have any notion of delaying until the SDN probe has completed. we might have to re-tool the sequence of states so the SSL CSR Generation is dependent on the SDN being available first [15:31] mbruzek - so, i guess there's 2 approaches here. either we delay CSR generation, or we have ot account for and allow charms to update their CSR and re-request a certificate [15:33] lazyPower: hrmm. that is a problem. I thought the toughest problem would be to have a layer above send additional SANs to the tls layer [15:34] we can use the unitdata module to pass info through the layers, i dont think thats as tough of a nut to crack as getting the sequencing right and not taking 30 minutes to deploy k8s [15:34] if we delay on sdn turnup, that'll likely bloat the install time :/ [15:35] but there's really no way to know what ip range we've been given until that happens [15:35] Good point batman, this is a tough riddle. [15:36] mbruzek - i'm not sure just yet what is the right way to do this... i guess we can "pick a path and revise" [15:37] lazyPower: we pass in a cidr config parameter for kubernetes. Could we not calculate the SDN address based on the cidr? [15:38] thats a huge range we've given it by default [15:38] thats a big guess :) [15:39] mbruzek - i think we're hard coding that 10.1.0.1 address for the api server. Its that or when we spin up, flannel is always getting the exact same response for which cidr to consume. [16:21] Hello Team, Getting this error http://pastebin.ubuntu.com/18712357/ while bootstrapping the enviroment in Juju 2.0 installation on Ubuntu Trusty Power machine. Please advise. [16:23] Juju 2.0 Installation Steps which i have followed is http://pastebin.ubuntu.com/18712502/ [16:23] Prabakaran: Juju 2.0 uses lxd which is in xenial. The devel PPA is not supported with lxd on trusty at this time [16:24] Prabakaran: ic, you grabbed lxd from backports. [16:25] seems there's some combo of issue init'ing lxd there. can you specify what version of lxd you have? [16:25] Hello Kevin, Getting this error http://pastebin.ubuntu.com/18712357/ while bootstrapping the enviroment in Juju 2.0 installation on Ubuntu Trusty Power machine. Juju 2.0 Installation Steps which i have followed is http://pastebin.ubuntu.com/18712502/ . Please advise [16:27] Do u have any command to check lxd version [16:29] Prabakaran: lxd --version [16:29] it is 2.0.3 [16:31] Prabakaran: do you get an error message if you run the lxd command manually that might give a hint? From line 5 in the pastebin with your output from bootstrap [16:35] I am not getting any error when i am running lxd commands manually.... I am getting this issue while bootstrapping juju [16:36] Prabakaran: right, but Juju tried to run that command and it failed. [16:36] Prabakaran: can you paste the logs from /var/log/lxd/lxd.log and /var/log/lxd/juju-*/*.log? [16:36] Prabakaran: so I'm wondering if it works correctly by hand or gives more clear messaging than "exit 1" [16:36] ah, and kwmonroe points out the logs that might be much more useful :) [16:38] hello, I am trying to push a charm to the store, but "charm login" gives an error ERROR login failed: cannot get user details for .... / When I login to the SSO page, it shows that the charm command has logged in properly though. [16:38] Logs are here //paste.ubuntu.com/18713495/ [16:39] jobot: can you run charm whoami ? [16:40] Error: whoami is not a valid subcommand usage: charm subcommand Available subcommands are: add build compose create generate get getall help info inspect layers list promulgate proof pull-source refresh review review-queue search subscribers test unpromulgate update version [16:40] Prabakaran: sorry, meant jobot there [16:40] whoami gives an error that says i'm not logged in [16:40] kevin i am seeing lots of logs are in the sub directories [16:42] jobot: did you login through jujucharms.com as well? === urulama|afk is now known as urulama [16:43] See these logs if it helps [16:43] http://paste.ubuntu.com/18713849/ http://paste.ubuntu.com/18713851/ http://paste.ubuntu.com/18713852/ [16:43] urulama: ah, might be a "I don't have a record in charmstore" issue? [16:43] rick_h_: yes [16:44] jobot: so, please login through jujucharms.com first, then use charm login again [16:44] ok will try thanks [16:46] @urulama that worked. thank you guys [16:46] jobot: what docs were you following? We should update for that case [16:47] https://jujucharms.com/docs/devel/authors-charm-store#submitting-a-new-charm [16:47] jobot: ty, will go through that and make sure that's in there [16:47] petevg: https://plus.google.com/events/col2a1aertqj329rjb8tgg314u0 [16:47] petevg: (related to https://github.com/juju-solutions/jujubigdata/pull/59) [16:48] rick_h_: ok, adding an issue for those docs [16:48] Prabakaran: still looking.. i have trusty/lxd working on intel, so i'm trying to compare your logs with mine. [16:48] cory_fu: cool. I'll make a note to drop in. [16:50] Is there a clash between Juju 1.25 which i was installed before in the same machine? Because i uninstalled juju 1.25 which i have installed in the same machine. and tried juju 2.0 [17:06] Prabakaran: there shouldn't be a clash.. when you install juju-2.0, it should have made 2.0 the default. i have both juju-1 and juju-2 installed on my host and they work fine together. [17:07] Prabakaran: can you verify your user is indeed in the lxd group? run "id | grep lxd" [17:09] Prabakaran: it looks like something related to seccomp -- line 132 of http://paste.ubuntu.com/18713851/ says "ERROR lxc_seccomp - seccomp.c:lxc_seccomp_load:615 - Error loading the seccomp policy" [17:09] but i'm not sure what that really means. anyone else have issues with lxd on trusty? [17:10] specifically with failures to bootstrap [17:11] Prabakaran: can you paste the output of 'lxc-checkconfig'? [17:14] kwmonroe - i didn't know we supported lxd provider on trusty. i thought it was wiley + [17:17] lazyPower: i don't know that we do either, but i know it's working well for me using 14.04.4 (kernel 3.13.0-91-generic) with lxd-2.0.3 and juju2 beta 11. [17:18] nice [17:18] #TIL [17:18] i suppose it was only a matter of time before the packages got backported [17:24] yup yup, trusty-backports ftw [17:37] kwmonroe .. id | grep lxd ----> Shows nothing [17:38] lxc-checkconfig ----> output is http://pastebin.ubuntu.com/18718695/ [17:39] Prabakaran: woohoo! i think we have an easy fix.. do you see your user listed with 'grep lxd /etc/group'? [17:40] lxd:x:121:pll [17:41] here i have a question..can i install juju 2.0 as a non-root user? [17:41] i have tried in both the ways [17:41] ok Prabakaran, try running 'newgrp lxd' as the pll user.. then you should see output from 'id | grep lxd' [17:42] dunno about juju-2 as non root.. i always install with 'sudo apt install juju-2.0' [17:43] here i am not able to run this command newgrp lxd.. so switched as root [17:43] and got this o/p "uid=0(root) gid=121(lxd) groups=0(root),121(lxd)" [17:53] Hi folks. Trying to bootstrap an LXD controller, but running into a problem on 2.0-beta12: http://paste.ubuntu.com/18719911/ Any thoughts on this? [18:03] nvm, got it. Wish the error mentioned --upload-tools :/ [18:06] Makyo - rockin that not-in-devel-ppa beta release i see :) [18:08] Prabakaran: were you able to bootstrap with the root user? [18:11] lazyPower: GUI dev knows no bounds. [18:11] no i am not able to do bootstrap [18:12] same error? [18:24] kwmonroe , yes i am getting same error "ERROR failed to bootstrap model: cannot start bootstrap instance: Error calling 'lxd forkstart juju-f46a2e-0 /var/lib/lxd/containers /var/log/lxd/juju-f46a2e-0/lxc.conf': err='exit status 1'" [18:25] Prabakaran: anything new in /var/log/lxd/juju-f46a2e-0/*.log? [18:27] i think logs looks simillar.. anyway see the logs http://paste.ubuntu.com/18722657/ http://paste.ubuntu.com/18722658/ http://paste.ubuntu.com/18722660/ [18:30] kwmonroe i think logs looks simillar.. anyway see the logs http://paste.ubuntu.com/18722657/ http://paste.ubuntu.com/18722658/ http://paste.ubuntu.com/18722660/ [18:38] , If you find any fix on this ...please mail me on the same. And its time for me to sleep.. Thanks :) [18:38] np Prabakaran -- have a good night! [18:56] Hello again. After doing ,"charm push" and/or "charm publish" does the code eventually end up on launchpad? [18:57] jobot: no, it's disconnected from LP [18:57] jobot: do your charm dev where you wish, and push to the store when it's ready [18:59] \o/ its liberating to say that huh rick_h_ [18:59] :) === scuttle|afk is now known as scuttlemonkey [19:06] Hah ok thanks. But to connect bug reporting, I would still need to forward to something like launchpad? [19:06] jobot: sure, there's a charm set-bug-url and set-homepage-url I think that lets you set those atrributes [19:07] jobot: so supply those to where the charm is managed [19:08] Ok. Lastly, I recall an ingestion cycle from lp to the store. Is that similar for the new method? The charm is not yet searchable [19:09] jobot https://jujucharms.com/docs/devel/authors-charm-store - we have a document guiding how the new publishing process works [19:10] jobot - any feedback here is appreciated, as its still relatively new documentation, and we may have forgotten something or need to clarify some steps. [19:11] Ok thanks for your help === urulama is now known as urulama|__ [19:44] mbruzek - ping [19:44] pong [19:44] have a sec to take a look at this? https://code.launchpad.net/~lazypower/charms/trusty/kibana/dockerbeat-dashboard/+merge/297804 [19:49] 25 files of json added? Are these custom files or did you copy them from somewhere? [19:55] mbruzek - imported from a fork of the beats dashboard repository === scuttlemonkey is now known as scuttle|afk === redir_sprint is now known as redir === freeflying__ is now known as freeflying [23:43] admcleod: hi there, any chance you could have a look at https://bugs.launchpad.net/juju-core/+bug/1600054 and see if I'm doing something obviously wrong or unsupported? [23:43] Bug #1600054: Running generate-image twice with separate virt-types overwrites rather than appends