[08:13] <gnuoy> jamespage, got a sec for https://github.com/openstack-charmers/charm-tempest/pull/5 ? fwiw I've tested it
[08:14] <jamespage> gnuoy, +1 merged
[08:15] <gnuoy> thanks
[14:03] <rye_> https://gist.githubusercontent.com/anonymous/569083600b2e95057add2d188e8d1687/raw/665602596e56b071ace4d0b79c6a3c48f489cb06/gistfile1.txt
[14:03] <rye_> sorry, wrong chat
[14:49] <DavidRama> hi foilks, got an issue with juju2.0b6/xenial I can't delete a charm from my status:
[14:49] <DavidRama> [Units]
[14:49] <DavidRama> ID      WORKLOAD-STATUS JUJU-STATUS VERSION   MACHINE PORTS PUBLIC-ADDRESS MESSAGE
[14:49] <DavidRama> mysql/0 error           idle        2.0-beta6 1             10.168.71.15   hook failed: "db-relation-broken" for mediawiki:db
[14:51] <verterok> DavidRama: hi, tried marking the unit as resolved? (juju resolved mysql/0)
[14:54] <DavidRama> ah yes thanks
[14:56] <DavidRama> And is there a way to stop/remove a whole bundle easily ?
[15:00] <lazyPower> DavidRama - not really. Unless you're using the gui you can mark every charm in a single transaction.
[15:00] <lazyPower> but thats the only easy way i can see to remove an entire bundle in one go.
[15:01] <cory_fu> kjackal_: https://github.com/juju-solutions/layer-apache-bigtop-base/pull/3
[15:01] <cory_fu> kjackal_: Example changes in namenode: https://github.com/juju-solutions/layer-apache-bigtop-namenode/pull/1
[15:01] <cory_fu> kjackal_: And you'll need this openjdk: https://github.com/juju-solutions/layer-openjdk/pull/2
[15:09] <stub> cory_fu: Have you had a chance to look at the charms.reactive action branch?
[15:20] <ddellav> jamespage or gnuoy can one of you guys take a look at this and land it? lp:~ddellav/+junk/charm-helpers its the change to support neutron 8.1 in mitaka
[15:21] <jamespage> ddellav, can you propose that as a merge against lp:charm-helpers please
[15:21] <ddellav> jamespage sure
[15:21] <jamespage> ddellav, you might need to rename your branch to lp:~ddellav/charm-helpers/branchname
[15:21] <jamespage> otherwise lp might lose its target...
[15:21] <ddellav> it's been awhile since i did a launchpad merge
[15:21] <ddellav> ok, i'll check it out
[15:24] <ddellav> jamespage https://code.launchpad.net/~ddellav/charm-helpers/neutron-mitaka-stable/+merge/294529
[15:31] <cory_fu> stub: Some.  I was discussing it with bcsaller.  I think I'm more inclined to use the state-based version in layer-basic, though we have also realized that auto-removing states like that are not the right way forward long-term, so there's still some discussion
[15:32] <stub> cory_fu: yes, I expect people will prefer using the states. I felt the @action decorator was needed though to setup that state if necessary, similar to @hook
[15:34] <stub> cory_fu: The basic model works for you though? Jumping into the reactive handlers and they can choose to call action-set, action-fail? And that actions and hooks are sharing the same bag of handlers?
[15:58] <jhobbs> juju's api-port, 17070, is what a remote client like python-jujuclient/juju deployer connect to, right?
[15:59] <rick_h_> jhobbs: yes
[15:59] <jhobbs> thanks rick_h_
[16:04] <beisner> marcoceppi, cory_fu - i'm needing to determine a reliable way to programmatically determine from the code tree alone whether a charm is to-be-built or already built.  it looks like the layer.yaml + whether or not the .build.manifest file exists is indicative.  do you have any other suggestions along these lines?
[16:05] <cory_fu> beisner: I think the .build.manifest would be the most authoritative
[16:05] <beisner> cory_fu, right so there's no case you can think of where that file would/should exist in a layer or interface?
[16:06] <cory_fu> beisner: Someone might check it in by mistake, but it really should not be
[16:06] <cory_fu> If they did that, we would nack them on review
[16:12] <beisner> cory_fu, ack thx sir
[16:13] <beisner> cory_fu, is there any case where a built charm or a layer would contain a interface.yaml?
[16:14] <cory_fu> It will if it includes any interface layers, but it wouldn't be at the top level
[16:56] <rye_> When my charm is deployed under bundletester, I briefly see a status of "Agent is lost, sorry! ...", but normal deployment goes fine. Is there some common pitfall I might be hitting, here? (juju2)
[16:59] <jhobbs> i've seen that with juju2 also rye_, not using bundletester
[17:01] <cory_fu> rye_: Juju always reports "Agent is lost" for a brief period while the unit is bootstrapped.  It just indicates that the unit is up but the agent hasn't checked in with the bootstrap node yet.  It should go away on its own after a second or two
[17:02] <cory_fu> So, now I have a question about subordinates....
[17:04] <cory_fu> Can someone tell me if it's possible to "chain" subordinates?  As in, I have the plugin charm that is subordinate to some principal, which is to install Hadoop.  But that requires Java, which is provided by a subordinate charm itself.  So I have openjdk -> plugin -> client where "->" is "subordinate to"
[17:04] <cory_fu> Juju seems to accept the relation, but the plugin never gets an openjdk unit
[17:20] <marcoceppi> aisrael: are you going to make 1x1?
[17:20] <rye_> cory_fu: good to know, thanks!
[17:21] <aisrael> marcoceppi: I'll be there!
[17:22] <magicaltrout> marcoceppi: can you find a definitive date when you guys will be in Pasadena so I can dump it in my calendar? We discussed it here and would be cool to hook up with you guys and I can combine it with a NASA onsite at the same time.
[17:24] <aisrael> NASA?!
[17:27] <magicaltrout> er yeah
[17:27] <lazyPower> cory_fu - yeah no, you cant build subordinates on top of one another
[17:27] <magicaltrout> i moonlight for NASA JPL
[17:28] <lazyPower> you can use 2 subordinates on the same principal, and exchange the java runtime information that way, but i dont think you can plug in interface:java on your subordinate - unless i completely missed teh question
[17:29] <lazyPower> what would happen is you need openjdk => client,  and plugin => client, and you'll have to do some data pass in that chain, either through states, unit data, or plain ol relationship proxy'ing info on the same unit
[17:30] <lazyPower> also rye_  sorry i missed ya lastnight. it was past EOD for me
[17:30] <lazyPower> rye_ - did you get your charmbox questions sorted in my absence?
[17:30] <cory_fu> lazyPower: Yeah, you're correct.  You can't chain subordinates currently due to technical / implementation reasons.  However, the modeling of the relations don't work the way you're describing so I'm basically just stuck
[17:30] <lazyPower> "modeling of the relations dont work that way" - wut
[17:30] <rye_> lazyPower: not yet, started putting out another fire :)
[17:30] <cory_fu> lazyPower: Juju is a modeling language.  ;)
[17:30] <lazyPower> cory_fu no thats fine, but what do you mean "dont work that way"
[17:31] <lazyPower> you can certainly pass data between layers with unitdata + state combos
[17:31] <lazyPower> ooo wait no you cant
[17:31] <lazyPower> thats a different unitdata.db for each sub
[17:31] <lazyPower> yeah, you're going to have to relation-set -r  out of band for any data you need to get from one to the others via the proxy. and thats messy, i did that with old docker-charm code and it ended in tears
[17:31] <cory_fu> So, semantically, the relationship is between the two subordinates.  I don't want to demand that every single charm that might want to use the plugin have to *also* support the java relation and *also* have to implement proxying that relationship across
[17:32] <lazyPower> by tears i mean it was fiddly and always needed attention, and wound up being a big pain to debug and trace that datapass across the charms.
[17:32] <cory_fu> So, when I said "don't work that way" I meant that it's not semantically meaningful to do that
[17:32] <lazyPower> yeah
[17:32] <lazyPower> i agree
[17:32] <lazyPower> make better choices cory_fu
[17:33] <lazyPower> <3
[17:34] <cory_fu> lazyPower: The response I got from asking in #juju-dev was resources  are probably a better fit, with which I mostly agree, except that it drastically reduces discoverability and makes ownership a bit of a nightmare.
[17:34] <lazyPower> well, resources are still a blocking item right now
[17:34] <cory_fu> Also, doesn't work in 1.x
[17:34] <cory_fu> Yeah, that too
[17:34] <lazyPower> i have a charm thats pending a release because resources coming from the store are currently pooched
[17:34] <lazyPower> it'll be fixed soon enough, but you're right, it locks you into a 2.0+ deployment scenario
[17:34] <lazyPower> and thats not always ideal either
[17:42] <aisrael> magicaltrout: Awesome!
[17:51] <marcoceppi> magicaltrout: http://summit.juju.solutions/
[17:52] <marcoceppi> magicaltrout: we should be announcing early next week, but it's all but signed at this point
[18:03] <magicaltrout> thanks marcoceppi
[18:04] <magicaltrout> kwmonroe kept changing his mind on the month
[18:14] <tvansteenburgh> cory_fu: latest bundletester on pypi has your new feature
[18:14] <cory_fu> Sweet!
[18:14] <cory_fu> Thanks
[18:24] <kwmonroe> magicaltrout: i feel like you should be teaching a session right now, and not so much chatting about the summit.
[19:51] <cory_fu> kwmonroe: Deploy looks good on those PRs
[19:54] <kwmonroe> thx cory_fu
[19:59] <marcoceppi> who has used extra-bindings?
[20:00] <rick_h_> marcoceppi: the openstack team
[20:01] <rick_h_> marcoceppi: they're the only folks that have updated charms to use it yet
[20:01] <marcoceppi> beisner: got an example of a charm with extra-bindings?
[20:01]  * marcoceppi has a need
[20:01]  * rick_h_ starts loading charms from openstack-base
[20:01] <beisner> maybe marcoceppi, sec..
[20:03] <rick_h_> marcoceppi: https://api.jujucharms.com/charmstore/v5/xenial/ceph-osd-0/archive/metadata.yaml
[20:03] <beisner> marcoceppi, https://github.com/openstack/charm-cinder/blob/master/metadata.yaml#L10
[20:03] <rick_h_> marcoceppi: and https://api.jujucharms.com/charmstore/v5/xenial/ceph-radosgw-0/archive/metadata.yaml
[20:03] <beisner> lolz, yah those
[20:03] <beisner> o/ rick_h_ :)
[20:03] <rick_h_> :)
[20:03] <marcoceppi> so it's just an empty dict?
[20:04] <rick_h_> ? you mean how you define it?
[20:04] <beisner> usage ex. @ https://github.com/openstack/charm-cinder/blob/master/hooks/charmhelpers/contrib/openstack/ip.py#L112
[20:04] <marcoceppi> rick_h_: yeah
[20:05] <marcoceppi> interesting.
[20:06] <marcoceppi> rick_h_: will these create network interfaces?
[20:06] <rick_h_> marcoceppi: you can run network-get on those
[20:06] <rick_h_> in your hooks
[20:06] <rick_h_> and get config/info
[20:07] <marcoceppi> right, but does that mean these machines get virtual nics, or what?
[20:11] <beisner> marcoceppi, thedac + jamespage have championed our initial net spaces implementation - i'm not sure how e/n/i ends up first-hand.
[20:12] <marcoceppi> beisner: thanks, I'll ping thedac tomorrow about it
[20:13] <thedac> I am here
[20:13] <marcoceppi> oh, hey thedac, extra-bindings, how does that translate to the unit?
[20:14] <thedac> marcoceppi: So  this only works with MAAS for now. The physical machine needs to have an interface defined in a specific network space in MAAS
[20:14] <thedac> And this just allows the charm to "choose" which interface a relation sends data over
[20:16] <thedac> for the extra bindings part it maps directly to what the OS charms had as a config value os-{pubilc,admin,internal}-network
[20:16] <wolsen> marcoceppi: so for that mongodb charm change that I mentioned last week, you mentioned it was a new review so I believe I followed the docs https://jujucharms.com/docs/stable/authors-charm-store#submitting ...
[20:18] <wolsen> marcoceppi: I ended up not pulling out master/slave because its needed for the amulet tests for sharding, so this only moves stuff out of the upstart/init script modifications to pushing it into the /etc/mongodb.conf --> https://code.launchpad.net/~billy-olsen/charms/xenial/mongodb/trunk
[20:18] <marcoceppi> thedac: interesting, okay. This is definitely geared towards maas so that's nice
[20:19] <marcoceppi> wolsen: that should be it, the old review queue is slowly chugging through things so it should show up by tomorrow morning
[20:20] <wolsen> marcoceppi: ack thanks just wasn't sure - the changes I have are safe for trusty as well fwiw, and I think I'll do a mp for them too
[20:20] <marcoceppi> wolsen: sounds good
[20:20] <wolsen> s/them/trusty
[20:21] <lazyPower> wolsen thank you for adopting some fixes on that charm
[20:21] <lazyPower> <3
[20:21] <wolsen> lazyPower: sure thing
[20:40]  * beisner woots for ppa:juju/daily  \o/
[20:52] <beisner> hi thedac, so i randomly chose cinder to convert from juju test, amulet, et al via debs --> to bundletester, amulet and friends purely from venv ... and that's all looking good.  now if i can get cinder itself to work as planned.  i'm seeing that pause/resume in cinder isn't really working.  bug 1581171  curious if you can lend a set of eyes on that?
[20:52] <mup> Bug #1581171: pause/resume failing <uosci> <cinder (Juju Charms Collection):New> <https://launchpad.net/bugs/1581171>
[20:56] <thedac> beisner: I'll take a look
[20:57] <beisner> thedac, muchos.   i'm taking a break from good ole cinder before i push overwrite a blank dir to it lol.
[20:57]  * beisner picks one that passes @master ;-) ...
[21:02] <beisner> --> glance.
[21:19] <cmars> mbruzek, lazyPower I'm getting an install hook error in the kubernetes charm. is github.com/kubernetes/kubernetes the right place to open a bug?
[21:20] <cmars> mbruzek, lazyPower https://paste.ubuntu.com/16382142/
[21:21] <mbruzek> cmars: Thanks for using our stuff. If you determine the problem is with Kubernetes code itself use that repo. If the bug is in the charm code then please open it here https://github.com/mbruzek/layer-k8s
[21:22] <mbruzek> actually cmars that is a bug in the docker layer
[21:22] <mbruzek> https://github.com/juju-solutions/layer-docker/issues
[21:23] <cmars> mbruzek, thanks, i'll open a bug. do you think it's possibly caused by deploying this on lxd?
[21:24] <mbruzek> cmars: Absolutely.
[21:24] <cmars> mbruzek, got it :) ok, i'll find a real cloud
[21:24] <mbruzek> Docker *can* run  inside lxd, but Juju does not use the docker profile as far as I remember
[21:24] <mbruzek> There is a core bug my bug got duped against for that
[21:25] <mbruzek> As far as I know you can not run kubernetes in lxd  at this time.
[21:25] <mbruzek> because docker will not run by default inside lxd and I don't think they have fixed that yet.
[21:25] <cmars> mbruzek, ok. we might want to note that on the bundle READMEs, in case anyone tries it
[21:26] <mbruzek> cmars: is that how you got this?
[21:26] <mbruzek> cmars bundle?
[21:26] <cmars> mbruzek, yes
[21:26] <mbruzek> cmars which one?
[21:26] <mbruzek> kubernetes-core or observable-kubernetes?
[21:26] <cmars> mbruzek, observable-kubernetes
[21:40] <rick_h_> cmars: you need to make the lxd docker profile the one juju uses
[21:40] <rick_h_> cmars: why i mentioned gce and such
[21:44] <cmars> mbruzek, what about this one? https://github.com/juju-solutions/layer-etcd/issues/11
[21:48] <mbruzek> cmars: sorry for the problem. etcd charm can be reved to 2. This bundle is out of date, hard to keep it in sync for all the charms are in
[21:48] <mbruzek> the bundle
[21:49] <cmars> mbruzek, thanks!
[21:51] <cmars> so in theory.. i could just edit the juju-default lxd profile and add the docker stuff. worth a shot
[22:01] <mbruzek> cmars: I really don't think everything will work inside
[22:01] <mbruzek> lxd
[22:05] <cmars> mbruzek, it's possible, but i had to set security.privileged=true on the containers
[22:06] <cmars> mbruzek, that got past the install hook, anyway. no idea if it actually works :)
[22:06] <mbruzek> cmars: tych0 indicated that some docker containers will not run well inside lxd.  I would suggest saving the bundle and incrementing the charms to the latest revno and deploying this on a real cloud like amazon or azure.
[22:06] <cmars> mbruzek, ok, ok :)
[22:06] <mbruzek> cmars: otherwise your mileage may vary.
[22:07] <tych0> well, it really depends on what the container is doing
[22:07] <mbruzek> tych0: These docker containers are go binaries running kubernetes.
[22:09] <tych0> yeah, i guess i don't know what kubernetes needs to do :)
[22:10] <lazyPower> tych0 - its going to do the same things any other deployment would request. Run a container confined in cgroups (potentially), request network and disk resources, and add iptables rulesets for the proxy
[22:11] <LiftedKilt> how does the maas2 feature flag work with conjure-up?
[22:11] <lazyPower> cmars - how did you get that?
[22:12] <lazyPower> its failing on setuptools/distutils? thats a new one on me
[22:14] <cmars> lazyPower, the etcd one? i deployed observable-kubernetes on lxd (which I've since learned is not really supported)
[22:15] <cmars> lazyPower, but the etcd hook error, i think it's fixed in the latest etcd-2?
[22:15] <cmars> about to try that
[22:20] <lazyPower> ok
[22:21] <lazyPower> lmk if its not, i had a bit of a stir looking over the bug+logs
[22:22] <cmars> lazyPower, mbruzek etcd-2 fixes my issue. here's a fix for the bundle: https://github.com/juju-solutions/bundle-observable-kubernetes/pull/5
[22:23] <lazyPower> cmars <333333333 keep em comin
[22:23] <mbruzek> Thanks cmars
[22:23] <mbruzek> I am almost done with the readme fix and elasticsearch charm can also be bumped.
[22:24] <mbruzek> cmars: if you just want kubernetes to run may I suggest the kubernetes-core bundle?
[22:25] <mbruzek> cmars: it does not have the high constraints as the observable one
[22:26] <cmars> mbruzek, good point, thanks
[22:26] <LiftedKilt> nevermind on that front - I just took a guess and got it working
[22:26] <LiftedKilt> however autopilot is not yet updated to xenial?
[22:30] <mbruzek> cmars: lazyPower: https://github.com/juju-solutions/bundle-observable-kubernetes/pull/6
[22:42] <mbruzek> cmars: lazyPower: https://github.com/juju-solutions/bundle-kubernetes-core/pull/5
[22:42] <mbruzek> cmars those should include the updates you asked about today.
[22:43] <cmars> mbruzek, thanks, LGTM
[23:05] <cmars> mbruzek, hey, i've got kubernetes-core deployed in GCE now, thanks for the help
[23:05] <mbruzek> cmars: great
[23:06] <mbruzek> cmars: I can publish those bundles here soon I just wanted to test the new YAML as you pointed out in the review
[23:06] <mbruzek> So far deployer seems OK with it
[23:07] <cmars> mbruzek, juju 2.0 likes it just fine, i deployed the bundle from the command line
[23:07] <mbruzek> OK. That new YAML was output from my tool that just bumps the revision numbers of all the charms to the latest according to the charmstore. Keeping bundles up-to-date was too manual for me
[23:08] <mbruzek> I know why they need to be locked to revision numbers, but that makes it very difficult to maintain large bundles.