[01:25] <marcoceppi> bdx: yes
[02:31] <bdx> marcoceppi: can you let me in on the secret?
[08:41] <jamespage> fginther, dpb1_: cs:~james-page/xenial/ceph-mon-gated-0
[08:41] <jamespage> testing myself atm
[09:39] <lazyPower> arosales icey  - also just fyi, you dont need to set defaults. juju bootstrap my-amazon-controller aws/us-west-1 would work equally as well.
[11:41] <Rajith> Hi,   I am facing issue while installing mariadb from charm store, install hook error is displayed in status and logs have 2016-05-17 10:42:46 INFO config-changed gpg: requesting key 1BB943DB from hkp server keyserver.ubuntu.com 2016-05-17 10:43:07 INFO config-changed gpgkeys: key CBCB082A1BB943DB can't be retrieved
[11:43] <lazyPower> Rajith - ah, seems like they may have updated their key. Their dev is west coast based, so there's a bit of a delay before i can get confirmation. Do you mind filing a bug against the charm? https://bugs.launchpad.net/charms/+source/mariadb
[11:44] <Rajith> sure will raise a bug
[11:44] <lazyPower> thanks Rajith
[11:55] <icey> lazyPower: that's what I ended up doing
[11:56] <lazyPower> right on.
[12:01] <magicaltrout> I appear to have opened a can of monitoring worms
[12:03] <lazyPower> magicaltrout you knew exactly what you were doing :) And i'm happy you did
[12:03] <magicaltrout> hehe
[12:03] <magicaltrout> its interesting to get all the different perspectives
[12:03] <lazyPower> you started the discussion, you can lay claim to the fact its gone further than expected, but dont be sad/upset at all. its a brilliant convo
[13:09] <fginther> jamespage, thanks, are you also porting that to trusty?
[13:09] <jamespage> fginther, yes but I was testing on xenial
[13:10] <fginther> jamespage, thanks
[13:20] <shewless_> Hello. I'm trying to bootstrap lxd on 16.04 and I'm getting this error: "ERROR cannot find network interface "lxdbr0": route ip+net: no such network interface". I tried adding the bridge using "sudo dpkg-reconfigure -p medium lxd"
[13:20] <shewless_> any ideas?
[13:26] <lazyPower> neiljerram - which charm from calico relates to etcd? (sorry i should have looked this up) - i have a patch re-introducing the proxy relation
[13:26] <lazyPower> shewless_ - ah that looks familiar. did you install a prior beta of juju?
[13:30] <shewless_> lazyPower: I just did a "sudo apt-get install juju"
[13:30] <shewless_> should I have added some ppa first or something?
[13:31] <lazyPower> shewless_ - installation instructions for the current beta is here: https://jujucharms.com/docs/devel/getting-started
[13:33] <shewless_> thanks I'll have a look
[13:33] <lazyPower> np, dont hesitate to ping back if you get stuck
[13:34] <jamespage> fginther, do you need that published to trusty for testing as well?
[13:45] <neiljerram> lazyPower, it's neutron-calico and neutron-api
[13:45] <fginther> jamespage, yes that would be great. I could start testing that today for trusty
[13:46] <lazyPower> neiljerram - yikes thats a big dep chain :D
[13:46] <neiljerram> lazyPower, for which one?
[13:46] <lazyPower> neutron - full stop
[13:46] <neiljerram> lazyPower, unfortunately yes.
[13:47] <lazyPower> that comes with an openstack dependency. for validation of this branch i think i'll hack together a simple charm consuming the interface and go from there
[13:47] <lazyPower> all we need is a mirror of the initial-cluster-string right?
[13:47] <jamespage> fginther, cs:~james-page/xenial/ceph-mon-bug1577519
[13:47] <jamespage> no not that one
[13:47] <jamespage> one sec
[13:48] <jamespage> fginther, cs:~james-page/trusty/ceph-mon-bug1577519
[13:49] <neiljerram> lazyPower, that sounds sensible to me.  Yes, a proxy just needs a valid value for ETCD_INITIAL_CLUSTER.
[13:50] <lazyPower> neiljerram - here's the interface code - i'm validating the reactive bits before pushing up - https://github.com/chuckbutler/interface-etcd-proxy
[13:50] <neiljerram> lazyPower, It would actually be quite nice to have a charm for an etcd proxy - perhaps just a different flavour of the normal etcd charm, if that would make sense?
[13:51] <lazyPower> would that be a subordinate then? as it needs to co-locate with another service right?
[13:51] <neiljerram> lazyPower, Then I could just install that alongside neutron-calico and neutron-api, instead of putting etcd stuff into those charms.
[13:52] <neiljerram> lazyPower, I'm not sure I completely understand, but I believe that "subordinate" is not exactly the same concept as "co-located"?
[13:53] <neiljerram> lazyPower, For example, my current bundle uses decls like "to: [ bird ]" to indicate co-location.  But I think that's different from being subordinate, isn't it?
[13:53] <lazyPower> well, yes and no. Subordinates will automatically deploy to every unit of the charm, occupying the same "containment" space as that charm. So if its in lxd, both will be installed in the same lxd container. Or of its on a bare metal server, both will be installed to that bare metal. Its effectively like using to, but different constructs. You can deploy a single unit of a different charm using the --to directive, and it has no notion of the
[13:53] <lazyPower>  supporting service
[13:54] <lazyPower> whereas subordinates gain some notion of another service that it is dependent/interacting with over that relation, and it also replicates to every unit of the charm.
[13:54] <neiljerram> lazyPower, ah OK, it sounds like subordinate is the right concept, then.
[13:55] <neiljerram> lazyPower, so if there was an etcd proxy charm, neutron-calico could say that it should have a subordinate etcd proxy; and similarly neutron-api.  Is that right?
[13:56] <neiljerram> lazyPower, or would it be the bundle that said that?
[13:56] <lazyPower> yeah, you'll still need to add the relationship bits to both charms, and whatever supporting data-pass that needs to happen
[13:57] <neiljerram> lazyPower, we could almost get away without any explicit relation at all ... with the proxy users just assuming http://127.0.0.1:2379.  But that would be a slight hack.
[13:58] <lazyPower> yep, deploy it without the sub and watch it break.
[13:58] <lazyPower> with no clear indicator as to why :/
[13:58] <neiljerram> lazyPower, OK, happy to defer to your experience on that point!
[13:58] <lazyPower> using the sub approach you can use status messaging to tell the user its incomplete
[13:59] <lazyPower> status_set('waiting', "Waiting on missing relation: etcd-proxy")   which is pretty clear whats happened, and not a fail.
[14:00] <neiljerram> lazyPower, Yes, on reflection I agree that it absolutely makes sense to have an explicit relation; independently of whether any config data is passed across it.
[14:25] <neiljerram> lazyPower, BTW - in case not already obvious to you - it would be super-easy to test an etcd-proxy charm: just deploy 1 etcd and 2 etcd-proxies; do etcdctl set /xxx yyy on one proxy, and etcdctl get /xxx on the other.
[14:27] <lazyPower> nice. Thanks for the tip
[15:55] <bdx> hello everyone. Does anyone know of a legitimate path around this -> https://github.com/juju/juju/issues/5411 ?
[15:58] <bdx> I've been battling it for a few days now, thought I would see whats up :-)
[15:59] <lazyPower> bdx - i cant say for certain but i think you're running into some assumptions the lxd provider is making on your behalf.
[16:00] <lazyPower> admittedly i haven't tried the lxd provider with a modified networking profile by default
[16:00] <lazyPower> I'm curious if it will work if you leave the default networking in-tact, and add your bridged network as a second nic on the container
[16:11] <bdx> lazyPower: yea, that works fine
[16:11] <lazyPower> bdx paydirt! thats a legitimate path around it
[16:11] <bdx> ha - I'm paying thats for sure
[16:12] <lazyPower> its a dirty hack, and i dont know what thats doing in terms of public-address/private-address
[16:12] <lazyPower> but theory states, so long as you're not binding to an interface, it should work for remote-access to your lxd resources on your laptop so you can share w/ a co-worker
[16:12] <lazyPower> ymmv
[16:14] <bdx> try to bootstrap lxd with the default profile set to use a bridge on an external interface ... then tell me your theory :-)
[16:16] <lazyPower> bdx - i mean *adding* that bridge on an external interface
[16:16] <lazyPower> not replacing
[16:17] <bdx> lazyPower: yeah ...
[16:17] <lazyPower> same result?
[16:17] <bdx> lazyPower: yeah
[16:17] <lazyPower> > [12:11:01] bdx:	lazyPower: yea, that works fine
[16:17] <lazyPower> i took that as "it works"
[16:18] <lazyPower> neiljerram - https://github.com/juju-solutions/layer-etcd/pull/13
[16:18] <bdx> oh .... so the problem is that you have to set the default lxd profile to use the bridge on the external interface too
[16:18] <bdx> lazyPower: bc the lxd controller gets created with the default profile
[16:18] <lazyPower> bdx something is getting lost in translation here. I'll TAL and see if i can beat it into submission later on
[16:18] <catbus1> Hi, what's the developer tool to discover the interfaces of other charms?
[16:19] <lazyPower> catbus1 - http://interfaces.juju.solutions
[16:19] <bdx> awesome, thx!
[16:20] <lazyPower> neiljerram - I'll push this up to my namespace. I based this off the Xenial branch so you can test w/o tls to start with as there's time there. This interface doesn't support the certificate exchange yet, we'll gate that all through at the same time when the tls-branch lands
[16:23] <catbus1> lazyPower: let's say I am developing a subordinate charm that will need to work with an OpenStack charm, how do I find out the interface names, attributes of the openstack charms? I remember from the first charmer summit, that is a tool developed to discover that and makes updates easier to manage.
[16:24] <lazyPower> catbus1 - ah that information is listed in the charm store itself, right hand side at the top of the charms listing. eg: https://jujucharms.com/neutron-api/  -- click "show more"
[16:24] <lazyPower> you'll get relation-name:interface
[16:26] <catbus1> I see that. I remember seeing a command line way of finding it out.
[16:28] <lazyPower> there's also charm show cs:xenial/neutron-api
[16:28] <catbus1> the interfaces are also defined in metadata.yaml. I remember it allows you to pull in the charms you are going to work with and show the interfaces. maybe it's charm compose.
[16:29] <catbus1> I think charm show is what I am looking for. Thank you!
[16:33] <lazyPower> np :)
[16:53] <Garyx> Hey is it a known issue with maas 2.0 + juju 2.0 that sshkeys that are saved in the maas gui is not being deployed to nodes?
[16:54] <Garyx> Using juju 2.0 beta 7
[16:54] <lazyPower> neiljerram - and its up at cs:~lazypower/etcd-8   https://jujucharms.com/u/lazypower/etcd
[16:54] <Garyx> Everything else seems to bo working fine, but cant log in with my key pair
[16:56] <lazyPower> Garyx - a skim through the bug tracker didn't surface anything that looked relevant. Thats certainly bug-worthy, as i know maas 2.0 + juju 2.0 has been a focus recently for the core team.  Any associated logs, steps to reproduce would be helpful   https://bugs.launchpad.net/juju-core/+filebug
[16:58] <Garyx> lazypower Thanks, haven't found anything in the logs yet that could help. Was wondering if anyone had seen the same before filing a bug.
[17:04] <Garyx> lazypower before I log a new bug the default user created is still ubuntu right?
[17:05] <lazyPower> Yep
[17:05] <Garyx> okies cannot see anything on my end then :/
[17:42] <jamespage> beisner, thedac: I think this will do the trick, but I've not tested yet...
[17:42] <jamespage> https://code.launchpad.net/~james-page/charm-helpers/fixup-service-running/+merge/294942
[17:46] <beisner> thedac, tldr;  SRU bug 1273462 caused bug 1581171.  bug 1582813 raised to ID it as a regression.    thx jamespage
[17:46] <mup> Bug #1273462: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists <init> <sts> <trusty> <upstart> <verification-done> <lsb (Ubuntu):Fix Released> <upstart (Ubuntu):Fix Released by xnox> <lsb (Ubuntu Trusty):Fix Released by zhhuabj> <upstart (Ubuntu
[17:46] <mup> Trusty):Won't Fix by xnox> <lsb (Ubuntu Utopic):Fix Released> <upstart (Ubuntu Utopic):Fix Released by xnox> <upstart (Debian):Fix Released> <https://launchpad.net/bugs/1273462>
[17:46] <mup> Bug #1581171: pause/resume failing (workload status races) <landscape> <maintenance-mode> <uosci> <ceilometer-agent (Juju Charms Collection):In Progress by 1chb1n> <cinder (Juju Charms Collection):Fix Committed by thedac> <glance (Juju Charms Collection):Fix Committed by thedac> <keystone (Juju
[17:46] <mup> Charms Collection):In Progress by thedac> <https://launchpad.net/bugs/1581171>
[17:46] <mup> Bug #1582813: service --status-all always reports upstart managed daemons as running <amd64> <apport-bug> <ec2-images> <regression-update> <trusty> <lsb (Ubuntu):Confirmed> <https://launchpad.net/bugs/1582813>
[18:01] <mpjetta> I’m trying to setup a new MAAS 2.0 setup with juju 2.0 and running into an issue. I can add the hardware nodes just fine and I see them PXE boot and cloud-init and whatnot when commisioning. However when I go to actually bootstrap the juju CLI to the maas, the nodes PXE boot once, shutdown and then just hang at "Booting local disk. WARN: No MBR magic, treating disk as raw. Booting..."
[18:02] <mpjetta> any ideas?
[18:35] <bdx> mpjetta: format your disks
[18:36] <bdx> mpjetta: gpt + fat32
[18:36] <bdx> should do the trick
[18:36] <mpjetta> thanks, trying that now
[19:03] <thedac> beisner: jamespage. Ah that makes more sense. I'll try and take a look today
[19:03] <beisner> thedac, first - happy sprinting! :-)   2nd, i've got that sync'd into a couple of charms and testing where it was known failing w/out.
[19:04] <thedac> great
[19:07] <beisner> thedac, but plz do review that c-h change if you've got cycles
[20:27] <magicaltrout> hmmmmmm!
[20:27] <magicaltrout> maybe I should enhance my DC/OS mesos talk and head over to MesosCon
[20:27] <magicaltrout> http://events.linuxfoundation.org/events/mesoscon-europe/program
[20:32] <magicaltrout> http://events.linuxfoundation.org/events/linuxcon-europe
[20:32] <magicaltrout> and linuxcon \o/
[20:34] <lazyPower> magicaltrout - indeed you should!
[20:48] <marcoceppi> magicaltrout: hey, you've got a bunch of instances running for a while in cdp, do you need them still?
[20:50] <magicaltrout> juju status says I've got 1 failed node
[20:50] <magicaltrout> anything open to me marcoceppi tear it down
[20:50] <marcoceppi> magicaltrout: ack, there were leaks in earlier betas, will purge
[22:07] <anops> Hi
[22:08] <anops> I am unsure if juju is the right thing for me. I mainly do research and each project requires a custom and usually complex environment with a lot of dependencies. It's very important however to communicate, share and reproduce my environment
[22:09] <anops> with fellow researchers and to eventually deploy it to a server
[22:10] <anops> how can I create a custom juju app receipe/image/solution or however you call it? Do you think juju is the right thing for me? I run these projects on my local laptop.
[22:10] <magicaltrout> anops: depends, if the charms you require are available or you're willing to build it can be very helpful in that regard
[22:11] <anops> I would most likely need to build it, I work on machine-learning and web-development projects
[22:11] <magicaltrout> you can build a redeployable system that would work the same on your laptop or in the cloud, or on someone elses laptop assuming their running the same OS
[22:12] <magicaltrout> a charm is a single service, you're basically describing a bundle
[22:12] <anops> how complicated is it to build a juju app-solution... eh charm?
[22:12] <magicaltrout> https://jujucharms.com/openstack-base/bundle/42 bit like that ;)
[22:13] <magicaltrout> depends what the apps are and what they have to do, can you give me a clue?
[22:17] <anops> For example a topological analysis platform for data, anomaly detection via a deep learning framework, or just classic data-analyis. On the other hand there are isolated little projects involving haskell,java,c,c++ etc. each most preferrably in a container to keep dependencies isolated from the host syste
[22:17] <magicaltrout> okay well Juju has a new concept where you can use LXD on your local system
[22:18] <magicaltrout> so instead of building docker images for each one, you use a vanilla Xenial/Trusty etc image
[22:18] <magicaltrout> and install your stuff on it when its being spun up.
[22:18] <magicaltrout> so you have enacpsulation of your server within an LXD image
[22:18] <magicaltrout> but without having messed around creating a bunch of docker images and pushing them up to dockerhub etc
[22:19] <magicaltrout> at that point the charms understand the concept of relations
[22:20] <magicaltrout> so if you join various deep learning components together, they can configure themselves and get themselves up and running without users configuring them directly
[22:20] <magicaltrout> which is what those lines depict in a bundle
[22:20] <magicaltrout> relationships between different charms
[22:20] <anops> That sounds great, but wouldn't that make it extremely complicated to get running? Especially when you have to work on a hard research project and don't have too much time
[22:20] <magicaltrout> dunno, thats a choice you have to make :)
[22:20] <anops> don't want to sounds lazy, but sometimes you just need get work done :)
[22:22] <anops> magicaltrout: do you have an example?
[22:22] <magicaltrout> example of what?
[22:22] <magicaltrout> a charm?
[22:23] <magicaltrout> http://bazaar.launchpad.net/~spicule/charms/trusty/pentahodataintegration/trunk/view/head:/reactive/pdi.py thats the code that maintains my pentaho data integration charm
[22:23] <magicaltrout> just controls the installation, which services are started et
[22:23] <magicaltrout> c
[22:24] <anops> So juju is essentially something like ansible/salt/chef?
[22:24] <magicaltrout> 165 lines of code so i can do "juju deploy pentahodataintegration" on my local server, AWS cloud or anywhere else that takes my fancy is pretty good bang for your buck i'd have thought
[22:24] <magicaltrout> yerp
[22:24] <magicaltrout> sorta :)
[22:25] <magicaltrout> chef etc are generally lower level
[22:26] <anops> I would get  my hands dirty with that, but where is the part that creates "the container" to run your pentaho instance?
[22:26] <magicaltrout> i just run 'juju deploy ...' and if my local juju setup is configured to do LXD it will build the container and deploy it on the fly
[22:27] <magicaltrout> which takes the best part of about 15 seconds
[22:27] <magicaltrout> https://demo.jujucharms.com/ or you can use the gui
[22:27] <magicaltrout> which does the same thing
[22:28] <anops> hmm, ok but I don't deploy unless it works. Does it on-th-fly create containers localy and remove them when there's a bug in the python code?
[22:28] <anops> It would be harder to manage if I have 20 containers and need to find out which one was the working one..
[22:28] <magicaltrout> in my code above you can see me setting states
[22:29] <magicaltrout>   status_set('maintenance', 'PDI Installed')
[22:29] <magicaltrout>     set_state('pdi.installed')
[22:29] <magicaltrout> stuff like that
[22:29] <magicaltrout> so your charm would detect a failed bootstrap and set the state to failed
[22:29] <anops> does that result in a zfs snapshot or a state in a state-machine where you can rollback to?
[22:30] <anops> ah
[22:30] <magicaltrout> the containers themselves will allow you to take zfs snapshots if you so desire
[22:30] <magicaltrout> if a machine enters a failed state you can tear it down, login and fix it and mark it resolved
[22:30] <magicaltrout> whatever floats your boat
[22:30] <anops> Is the best way to start creating a charm setting up server 16.04 on my laptop?
[22:31] <magicaltrout> yeah
[22:31] <magicaltrout> marcoceppi: whats the best way to get charm tools? :0
[22:31] <magicaltrout> apt-get install charm-tools i believe anops
[22:32] <anops> is it possible to create a container with a personal desktop that runs on tty1? I'd like to keep the core, personal and work seperated so that snapshots are more granular
[22:32] <magicaltrout> then charm-create <charmname>
[22:32] <anops> also more secure
[22:32] <magicaltrout> https://jujucharms.com/u/kwmonroe/ubuntu-devenv/trusty/2
[22:32] <magicaltrout> something like that i suspect you want
[22:33] <magicaltrout> thats not GUI based but the idea is similar
[22:33] <magicaltrout> https://jujucharms.com/ubuntu/0 or that
[22:33] <anops> magicaltrout: oh you mean I should put the ubuntu-desktop into a charm too? I thought about lxc..
[22:34] <magicaltrout> you can do it direct in lxc
[22:34] <magicaltrout> lxc launch xenial
[22:34] <magicaltrout> or something like that
[22:34] <magicaltrout> lxc launch trusty
[22:34] <magicaltrout> depends what you want to bootstrap
[22:35] <magicaltrout> you might have some interesting issues with gfx though, although I did some ssh tunelling successfully
[22:36] <magicaltrout> https://github.com/ustuehler/lxc-desktop or something like that
[22:36] <magicaltrout> https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/
[22:36] <anops> cool,eactly what I need
[22:45] <magicaltrout> alright i need to run anops, you'll probably find some life in this channel if you need more questions answered, if not, I'll be back in about 9 hours ;)
[22:46] <anops> magicaltrout: have a nice day/night thank you very much for your great help!
[22:46] <magicaltrout> no problem
[22:47] <anops> I'm just looking into sandstorm.io for the web-app part, maybe that's the way to share these and juju for the heavy stuff like machine-learning
[23:05] <jhobbs> is there a way to use a "charm: " option in a bundle to get the latest version of the charm for the series being used in the deployment (default-series)?
[23:05] <jhobbs> like "charm: cs:nova-compute"
[23:06] <jhobbs> if my default-series is trusty i want that to get the latest trusty nova-compute charm
[23:06] <blahdeblah> Quick Q: is there an overview showing which versions of juju2 are in stable/proposed/devel?  Or an easy way to obtain this information without having the repositories enabled on my machine?
[23:17] <anops> blahdeblah: https://launchpad.net/juju-core maybe
[23:18] <anops> or https://jujucharms.com/docs/stable/reference-releases
[23:19] <blahdeblah> anops: Looked at the first one - couldn't see any reference to the ppas there, although I may need more coffee
[23:20] <anops> the milestone timeline graphic
[23:22] <blahdeblah> That does't appear to have anything to do with which version is in which ppa...
[23:24] <blahdeblah> Looks like comparing https://launchpad.net/~juju/+archive/ubuntu/stable https://launchpad.net/~juju/+archive/ubuntu/proposed & https://launchpad.net/~juju/+archive/ubuntu/devel is easiest, but only the last has juju 2 packages...