[02:02] <Danni-33> hello, is anyone here familiar with the kubernetes-core bundle? it keeps failing to install easyrsa for me and I am unsure how to debug...
[02:02] <Danni-33> seems to stop with this: 2016-11-14 01:07:33 INFO client-relation-changed error: could not download resource: HTTP request failed: resource#easyrsa/easyrsa not found
[08:01] <kjackal> good morning juju world
[10:08] <Mmike> Hello, guys. Do  you know when 1.25.7 is going to hit trusty archives? (or at least stable juju ppa?) I see that 1.25.7 got release almost two weeks ago: https://launchpad.net/juju-core/+milestone/1.25.7
[10:22] <magicaltrout> kjackal: its a shame you're not here, i need someone to laugh at!
[10:22] <magicaltrout> .. i mean with
[10:42] <kjackal> magicaltrout: :)
[10:53] <kjackal> magicaltrout: so what are the highlights from apache big data?
[10:56] <magicaltrout> kjackal: admcleod 's shiny head, SaMnCo 's campness and my sobriety so far.....
[11:03] <magicaltrout> marcoceppi: when you wake up, i spun up a bunch of stuff the otherday, then did apt-get update which amazingly removed everything from my /home directory
[11:03] <magicaltrout> so I can't shut the nodes down
[11:04] <magicaltrout> so when you clean stuff up, i've got a bunch of crap running doing nothing cause I can't access them
[11:04] <marcoceppi> magicaltrout: I'm in EU time zones
[11:04] <magicaltrout> or that
[11:04] <magicaltrout> fair enough
[11:04] <marcoceppi> magicaltrout: so I'll do tha tnow
[11:04] <magicaltrout> i have some nodes running :P
[11:05] <marcoceppi> magicaltrout: in eu-west-1?
[11:05] <magicaltrout> sounds correct
[11:08] <marcoceppi> magicaltrout: cleaned up, you may need to kill-controller to reset
[11:08] <magicaltrout> i have no home directory, it's as reset as it comes :P
[11:08] <magicaltrout> thanks
[11:20] <admcleod> i wonder if the code of conduct specifies 'cant slap tom' explicitly
[11:22] <magicaltrout> doubt it, but as you're a woman i'm not allowed to retort either which is deeply unfair admcleod
[11:23] <admcleod> excellent
[11:32] <magicaltrout> admcleod: one of you chaps should sit down with Rich Bowen and do a quick interview about why juju works well with Apache projects
[11:32] <magicaltrout> i'm sure you wont, but just a thought
[11:32] <magicaltrout> send petevg along to talk nonsense
[11:35] <admcleod> *cut* *paste*
[11:38] <petevg> I can talk nonsense. Sounds fun.
[11:39] <magicaltrout> well we're wanting more projects other than Bigtop to upstream charms
[11:39] <magicaltrout> so chatting with Rich about it in an audio blog thing wouldn't be a bad way to get the message out a bit
[11:49] <petevg> magicaltrout: has Rich established a base of operations somewhere, or is it a matter of bumping into him?
[11:51] <magicaltrout> he'll just be milling around petevg
[11:52] <magicaltrout> I asked him earlier he said the best bet is getting him whilst sessions are on as it'll be a quiet period
[11:52] <petevg> Cool. Thx, magicaltrout
[12:00] <rock> Hi all.  We need to know the answer for one question. This is very important for us. In order to interact with charm store we need Ubuntu SSO account and we need to login to launchpad even once right. We created Ubuntu SSO account with Mail ID: "Harish.Kannamthodath.CTR@kaminario.com"  and username is "kaminario". We had account authentication issue. So without deactivating launchpad account unknowingly we deleted Ubuntu SSO account perm
[12:00] <rock> Then we tried to create Ubuntu SSO account  using the same mail ID and username. But we got an issue like "kaminario" username already in use. Probably "kaminario" username has stored somewhere in server cache. So please provide me the way to get "kaminario" username back. Because we want "kaminario" username account to push our charm store. How can we delete "kaminario" username from ubuntu server cache?
[12:00] <rock> We raised the bug. But didn't get reply. https://github.com/CanonicalLtd/jujucharms.com/issues/372
[12:54] <axino> rock: hi, please email rt@ubuntu.com with your request and we'll sort it out
[14:14] <rock> axino: OK. Thanks.
[14:28] <rock> axino: We will put mail very soon. Please provide me the resolution as soon as possible. Thanks.
[16:10] <pascalmazon> Hello, I'm developping a charm that takes control replaces the standard network driver to use our own userland one.
[16:10] <pascalmazon> To do so, it performs an `ifdown -a` then `ifup -a` to re-record the interfaces configuration.
[16:10] <pascalmazon> Unfortunately, the lxd-bridge is not registered in /etc/network, and lxdbr0 ports to my containers are lost.
[16:10] <pascalmazon> I have to manually re-add veth ifaces into lxdbr0.
[16:10] <pascalmazon> Do you people have a suggestion on how to deal with that properly?
[16:14] <pascalmazon> I tried `systemctl restart lxd-bridge` just in case. didn't change the situation
[16:28] <jproulx> is there a complete reference for the YAML I can use in specifying a private OpenStack cloud?  specifically now I'm trying to define what network to use but seems like a full reference would be quite handy
[17:06] <rick_h> jproulx: I believe you just need --config network=$uuid
[17:08] <bloodearnest> marcoceppi, many thanks for charm-tools 2.1.6 \o/, works for me on trusty
[17:11] <marcoceppi> bloodearnest: thanks for the confirmation. Can't wait for snaps on trusty then i can boot out these debs and dep management
[17:11] <bloodearnest> marcoceppi, looking forward to it! :)
[17:22] <cory_fu> marcoceppi, mbruzek, aisrael: Please take a look at https://github.com/juju/charm-tools/issues/276
[17:23] <mbruzek> cory_fu:  on it
[17:23] <mbruzek> cory_fu: Do you mean: https://github.com/juju/charm-tools/pull/282
[17:23] <aisrael> cory_fu: ack, I ran into that problem as well
[17:24] <cory_fu> mbruzek: Yes, the PR not the issue.  Thanks
[17:25] <cory_fu> aisrael: I believe the PR should resolve both issues, as I believe they were both due to the venv not being used and it instead trying to upgrade pip on the system.  I'm not 100% certain about it fixing #274, though
[17:26] <cory_fu> aisrael: Hrm.  On second thought, I think it probably won't, since that's failing in load_entry_point
[17:32] <cory_fu> mbruzek: Comments addressed or replied to
[17:33] <mbruzek> cory_fu:  OK. I had another one just now. I think venv parameter is unused.
[17:34] <cory_fu> mbruzek: Hrm.  It's not exactly unused, but I agree that it's confusing
[17:35] <mbruzek> cory_fu:  oh? let me take another look then.
[17:35] <cory_fu> I changed it to a state var because we had multiple levels of passing it through now.
[17:35] <cory_fu> mbruzek: Take a look now.  param removed entirely
[17:35] <mbruzek> cory_fu: How/where does __call__ get invoked?
[17:36] <cory_fu> mbruzek: That's the main entry point for the tactic.  It's invoked by the build system
[17:37] <mbruzek> Ok thanks cory_fu
[17:37] <cory_fu> mbruzek: https://github.com/juju/charm-tools/blob/master/charmtools/build/builder.py#L448
[17:37] <cory_fu> That's the initial call, and the call within WheelhouseTactic.__call__ is recursion
[17:38] <cory_fu> (Sort of)
[17:42] <cory_fu> mbruzek: I added a clarification to my explanation about the difference between the 1.x and 9.x pips and why each is needed.  I think the verison pin in the PR is needed, but I am a little worried that it is a bit "hidden" in the code.
[17:42] <cory_fu> But having it should prevent breakages due to newer versions being released in the future.
[17:43] <jproulx> rick_h: thanks --config network=$uuid was the next puzzle piece
[17:43] <mbruzek> cory_fu: Yes I am trying to verify the .join logic, then you get my +1
[17:43] <rick_h> jproulx: so you should be able to stick that in the cloud file via nested yaml
[17:43] <rick_h> config: <newline and indent>network=$uuid
[17:44] <rick_h> jproulx: you were the one on the mailing list thread?
[17:44] <jproulx> thanks it was the 'config:' section I was missing
[17:44] <jproulx> rick_h: yup that's me
[17:45] <mbruzek> cory_fu: When I make a local path _venv I tried this command: 'bash', '-c', ' '.join(('.', _venv / 'bin' / 'activate', ';', 'pip3') + args)
[17:45] <mbruzek> I get: TypeError: can only concatenate tuple (not "list") to tuple
[17:46] <rick_h> jproulx: k, I'll reply to the thread as well to make sure it's documented. thanks for fighting through it
[17:46] <cory_fu> mbruzek: def foo(*args): comes in as a tuple.  If you defined it as a list, it won't wokr
[17:46] <cory_fu> mbruzek: i.e., use args = ('foo',) instead of args = ['foo']
[17:47] <mbruzek> oh
[17:47] <cory_fu> I never really understood why Python rejects tuple + list or list + tuple.  They seem like reasonably compatible types
[17:47] <cory_fu> I mean, list.extend(tuple) works fine
[17:48] <mbruzek> TypeError: can only concatenate tuple (not "dict") to tuple
[17:48] <cory_fu> As does a_tuple + tuple(a_list)
[17:48] <cory_fu> mbruzek: lolwut
[17:48] <mbruzek> I made args['foo']='bar'
[17:49] <cory_fu> mbruzek: Yeah, a dict is not a tuple
[17:49] <mbruzek> my mistake
[17:49] <mbruzek> I see the error of my ways now
[17:49] <mbruzek> thanks
[17:49] <cory_fu> :)
[17:51] <cory_fu> marcoceppi: Can you take a look at https://github.com/juju/charm-tools/pull/282 and include that in the release?
[18:01] <sk_> Hi, I have a query related to juju relations. When we add a relation say juju add-relation Service A Service B, the relation is added at service level.So if Service B has multiple units deployed, each and every unit of Service B will connect to Service A.
[18:02] <sk_> But I have this requirement where I want relations to be added at unit level, can we achieve this ?
[18:03] <magicaltrout> what does the unit stuff achieve sk_ ?
[18:03] <magicaltrout> for example you could detect if it was the leader unit and act on that I guess, or pick out other unit specifics
[18:04] <sk_> the scenario is that unit1 of Service A gets connected only to unit1 of Service B and similarly unit2 of Service A gets connected to unit2 of Service B and so on
[18:06] <magicaltrout> sk_: but how would you ensure the same number of units existed in each?
[18:06] <magicaltrout> that said, when the relation is joined you could ask for a list of units from the other side
[18:07] <magicaltrout> and use some logic to pick the one you want, no?
[18:07] <rick_h> sk_: I think you'd have to basically allow juju to manage the juju relation data, but work with the leader to coordinate exact to exact requirements
[18:07] <rick_h> sk_: the issue would be that what happens when unit 3 goes down and you add unit 9 and you want A9 to work with B3
[18:08] <magicaltrout> you could setup some config based hash to maintain the connection list, not sure what happens if machines go missing though
[18:10] <sk_> ok, thanks I would try out these options and see it works for my requirement
[18:10] <magicaltrout> demoed some juju stuff to some folk from JPL today rick_h they have plans to upstream a Solr Cloud charm and some other bits hopefully
[18:11] <rick_h> magicaltrout: <3 awesome, solr the fulltext tool or something different?
[18:11] <magicaltrout> yeah they make use of solr a lot instead of elasticsearch. I believe they have some spark <-connector->solr platform
[18:11] <magicaltrout> so were looking to use the spark charms with some solr stuff
[18:12] <magicaltrout> they were trying to do it in docker so we ran through the juju stuff and quickly got them converted
[18:13] <rick_h> nice
[18:42] <marcoceppi> cory_fu: that didn't fix it
[18:45] <cory_fu> marcoceppi: I'm getting a different error now: Command 'lsb_release -a' returned non-zero exit status 1
[18:45] <marcoceppi> cory_fu: yeah
[18:45] <marcoceppi> because you're using bash
[18:45] <cory_fu> It is using the venv pip, though
[18:45] <cory_fu> marcoceppi: Why is using bash a problem?
[18:45] <marcoceppi> well, maybe not
[18:46] <cory_fu> marcoceppi: File "/tmp/tmpJDK3hF/bin/pip3", line 11, in <module>
[18:46] <marcoceppi> pip 9.0 i using lsb_release
[18:46] <marcoceppi> ugh, I hate software
[18:46] <cory_fu> It is using the venv pip correctly.  I don't understand why lsb_release would fail
[18:46] <marcoceppi> because it's a sap
[18:46] <marcoceppi> snap*
[18:46] <cory_fu> Snaps can't see what system they're running on?
[18:47] <marcoceppi> no
[18:47] <marcoceppi> it's confined. /etc/lsb-release just doesn't exist (really, practically) for snaps
[18:47] <marcoceppi> why does pip need to query lsb_release
[18:47] <cory_fu> I have no idea
[18:47]  * marcoceppi angrily digs into code
[18:56] <marcoceppi> cory_fu: so, it's just doing distro detection, which, whatever
[18:56] <marcoceppi> I'll update the snap, angrily
[18:57] <cory_fu> marcoceppi: How can you work around that in the snap?
[18:58] <marcoceppi> cory_fu: ANGRILY
[18:58] <marcoceppi> not sure, but I'm going to try
[19:15] <MotherDuckingNew> Salutations.
[19:16] <MotherDuckingNew> I was following THIS video tutorial: https://www.youtube.com/watch?v=bxvCkPnC53U, but it seems he already has some clouds set up on his first video, so I can't really follow along, since I have zero clouds set up. What's a really good beginner tutorial on juju?
[19:19] <MotherDuckingNew> p-please reply guys. :3
[19:34] <tvansteenburgh> MotherDuckingNew: https://jujucharms.com/docs/stable/getting-started
[19:57] <andrey-mp> Hi! I have a question about bundles. Is it right place to ask it?
[19:59] <skay_> I am trying to debug hooks. I don't have the commands listed here, https://jujucharms.com/docs/stable/developer-debugging#debugging-reactive
[19:59] <skay_> did I not install everything?
[20:04] <cory_fu> skay_: Those commands must be run on the deployed unit, in a hook context, and will only be available if your charm is reactive.  Also, if your charm specifies use_venv in layer.yaml, then you will have to activate the venv from /var/lib/juju/agents/unit-<app>-X/.venv/bin/activate
[20:05] <cory_fu> skay_: So, the main two questions are: Are you in a debug-hooks session, and does your charm use_venv?
[20:05] <skay_> cory_fu: hi, I started off by running juju dhx, which starts up tmux then eventually drops me to a window for the hook
[20:06] <skay_> cory_fu: my charm doesn't use venv, I wonder if that would be helpful?
[20:06] <cory_fu> Ok, good, so you're already in a debug-hooks session
[20:06] <skay_> cory_fu: do I have to do anything special when I've got a charm with layers? I'm not clear from reading the docs
[20:06] <cory_fu> skay_: It's recommended for subordinate charms, and it is probably better for all charms but does add a step when debugging hte charms
[20:07] <cory_fu> skay_: Nothing other than building the charm with `charm build`.  Can you point me to, or pastebin your layer.yaml file?
[20:08] <cory_fu> The only other thing I can think of is that maybe you forgot to add 'layer:basic' to your includes: list
[20:08] <andrey-mp> question about bundle: In juju 1.25 I can use prepared machines for bundle. But Juju 2.0 ignores created machines even they have same "names". Is it a bug?
[20:09] <rick_h> andrey-mp: no, it's a difference in the built in bundle deploy vs the deployer tool
[20:09] <rick_h> andrey-mp: the goal of the built in bundle deploy is to use bundles that are portable for all users and to leave it to the deployer to do special case things that only work locally
[20:11] <skay_> cory_fu: done
[20:11] <andrey-mp> rick_h: thank you for answer. I made this solution because bundle didn't support disks for machines. Is it possible to specify disks for each machine in 2.0?
[20:11] <cory_fu> skay_: That seems fine.  You should be able to run charms.reactive from the command line in your dhx session.  What do you get when you type that?
[20:13] <skay_> cory_fu: I get 'command not found' https://paste.ubuntu.com/23477174/
[20:14] <skay_> cory_fu: perhaps I missed something when building my charm?
[20:15] <cory_fu> skay_: That's very strange.  Check the wheelhouse/ directory in the built charm and see if it has the charms.reactive wheel in there
[20:16] <skay_> cory_fu: I do not see a wheelhouse directory (I didn't build this one with a venv enabled)
[20:17] <skay_> cory_fu: where would a wheelhouse directory go, or is it only around when someone uses a venv
[20:21] <cory_fu> skay_: When you do `charm build`, one of the first lines output by that command says what directory it's building into.  The wheelhouse directory will be there.  Alternatively, it will be on the deployed unit in /var/lib/juju/agents/unit-<app>-X/charm/wheelhouse
[20:22] <skay_> cory_fu: it's not in /var/lib/juju/agents/unit-<app>-X/charm/wheelhouse
[20:22] <skay_> cory_fu: I'm going to rebuild
[20:24] <skay_> (I can't remember what to put in metadata.yaml to use a venv and I don't remember where the docs are for valid metadata entries)
[20:24] <lazyPower> skay_ - its layer.yaml, virtualenv: true  as a layer option
[20:25] <lazyPower> https://github.com/juju-solutions/layer-basic#layer-configuration - to anyone following along at home
[20:25] <skay_> lazyPower: thanks, that was driving me to distraction
[20:25] <lazyPower> np skay_  :)
[20:36] <skay_> thnks lazyPower and cory_fu. I've rebuilt my charm, and I have access to the commands I didn't have before (and I also am using a venv now)
[20:47] <lazyPower> \o/ nice
[21:12] <brandor5> Hello everyone: quick question, how can i map a juju machine to the maas system it lives on?
[21:22] <brandor5> anyone?
[21:22] <marcoceppi> brandor5: in Juju, it lists the instance-id, which is the ID for the MAAS node
[21:23] <brandor5> marcoceppi: oh, i wasn't aware. thanks !
[21:23] <marcoceppi> np!
[21:51] <MotherDuckingNew> I'm feeling kind of nervous and jittery. Can someone tell me everything will be alright?
[21:54] <Walex> MotherDuckingNew: difficult to do that in the #Juju channel :-)
[21:55]  * rick_h passes juju juice around for calming effect
[21:55] <Walex> but most things will be allright
[22:11] <skay_> I'm unable to install snap with the snap-layer. it fails on grabbing ubuntu-core
[22:11] <skay_> systemctl pastebin https://paste.ubuntu.com/23477593/
[22:11] <skay_> journalctl pastebin https://paste.ubuntu.com/23477594/
[22:12] <skay_> I'm trying to install a snap via  resource file
[22:13] <skay_> it failed, then I started up a debug session and tried running a snap install command directly to see the output
[22:17] <skay_> it's actually called layer-snap https://github.com/stub42/layer-snap
[22:18] <skay_> stub: hi, have you seen a problem where someone is unable to install ubuntu-core when trying to install a snap?