[00:38] <AlecTaylor> hi
[01:11] <marcoceppi> Hi AlecTaylor
[04:59] <AlecTaylor> hi
[05:01] <AlecTaylor> Each of the charm dependencies and juju in general, are they available as seperate packages? - E.g.: kubernetes, etcd, mesos
[09:07] <jamespage> gnuoy, I need a +1 on https://code.launchpad.net/~james-page/charm-helpers/systemd-support/+merge/281742 if you have time
[09:07] <gnuoy> looking
[09:07] <jamespage> that will unblock amulet tests on keystone glance and swift-*
[09:11] <jamespage> gnuoy, and then:
[09:11] <jamespage> https://code.launchpad.net/~james-page/charm-helpers/haproxy-stats-1.6/+merge/281747
[09:12] <jamespage> that fixes mitaka/xenial and a long standing security concern from elmo
[09:12] <gnuoy> ack
[09:12] <jamespage> gnuoy, ta for the +1 on the first
[09:13] <gnuoy> jamespage, want me to land it or will you?
[09:13] <jamespage> gnuoy, I'll land them and then re-sync the failing branches
[09:13] <gnuoy> kk
=== ejat_ is now known as ejat
[11:43] <jamespage> gnuoy, those last four blocking mps for resyncs now test ok so landing them
[11:44] <gnuoy> tip top
[13:37] <durschatz> Is there an issue with ppa:juju/stable?
[13:37] <durschatz> sudo add-apt-repository ppa:juju/stable
[13:37] <durschatz> Cannot add PPA: 'ppa:juju/stable'.
[13:37] <durschatz> Please check that the PPA name or format is correct.
=== rogpeppe2 is now known as rogpeppe
[13:52] <durschatz> sorry the problem was my DNS config
[14:05] <jamespage> gnuoy, thedac: time for a review? - https://code.launchpad.net/~james-page/charms/trusty/cinder/lp1521604/+merge/281799
[14:05] <gnuoy> jamespage, looking
[14:08] <gnuoy> jamespage, +1
[14:17] <jamespage> gnuoy, ta - I also have a cherry pick of the version detection fix to land into stable charms - just raising the MP's now
[15:34] <cmars> can layers include layers, or is layer.yaml only valid at the top level?
[15:36] <rick_h_> cory_fu_: ^ ?
[15:37] <marcoceppi> cmars: you acn include as many layers as you'd like
[15:38] <cmars> so let's say i have layers a, b, and c. b has a layer.yaml that includes a, c has a layer.yaml that includes b, result gets a+b+c?
[15:38] <marcoceppi> cmars: yes
[15:38] <cmars> awesomesauce
[15:38] <cmars> thanks
[15:59] <lazyPower> cmars: be careful about recursively linking charm layers - there are scenarios where the builder will get caught in an infinite loop
[16:00] <lazyPower> eg if layer a and c depend on b, but b includes a, you'll get caught in a never-ending loop of fetching those layers/wheels/etc.
[16:00] <cmars> lazyPower, thanks for the warning. no cycles in this graph :)
=== med_` is now known as med_
=== med_ is now known as med
=== med is now known as med_
=== scuttle` is now known as scuttle|afk
=== scuttle|afk is now known as scuttlemonkey
[19:00] <natefinch> urulama, rick_h_: not sure who to address this to but... is it me, or is the charm search kinda... wacky?
[19:08] <urulama> natefinch: oh?
[19:08] <urulama> natefinch: what seems to be wrong?
[19:16] <natefinch> urulama: well, searches seem to return a bunch of random charms that have nothing to do with the search term
[19:17] <natefinch> urulama: like, I can search for "natefinch" and it returns 100 charms, only 3 of which actually seem to reference my username anywhere
[19:19] <urulama> natefinch: if nothing relevant is found, search term is broken to n-grams of different sizes
[19:19] <urulama> natefinch: so, nch is 3-gram for vbench ... not good, but if nothing relevant if found, all is equally bad :)
[19:20] <rick_h_> natefinch: it's the whole "promulgated shows up first" problem
[19:20] <rick_h_> natefinch: agreed jujucharms.com needs to move past that as we get giong
[19:20] <rick_h_> natefinch: e.g. not showing all user's charms but showing users might work out.
[19:20] <natefinch> urulama: I'd rather see no hits than things that are very very very unlikely to be what I'm looking for.  Or at least say "limited results, here are some potential other charms that matches searches like yours"
[19:20] <rick_h_> natefinch: and ratcheting up the scoring for matches so that fewer promulgated 'potential matches' are displayed in these bad cases
[19:21] <rick_h_> natefinch: the first ones in the "Recommended" section are the real best matches
[19:21] <rick_h_> natefinch: but we never show user material above promulgated
[19:21] <rick_h_> urulama: weren't those going to get renamed?
[19:21] <urulama> natefinch: yeah, agree, and search is being redefined
[19:21] <rick_h_> urulama: did that deploy not get out yet?
[19:21] <jrwren> a stemming search instead of ngram?
[19:21] <urulama> rick_h_: with new deploy, yes
[19:21] <rick_h_> urulama: ok, I wasn't sure when the deploy timeline was
[19:22] <urulama> rick_h_: it goes on staging next week and then production
[19:22] <rick_h_> natefinch: but in answer to your question, a bug filed with replication results and expected behavior is the 'who to adress this'
[19:22] <rick_h_> urulama: gotcha cool
[19:22] <natefinch> rick_h_: cool, will do
[19:23] <rick_h_> natefinch: but yes, it's a known shortcoming of search and something that'll be tweaked as the store moves forward and expands
[19:23] <natefinch> rick_h_: ok, good to hear.  'cause right now, the impression is "search is (almost) completely broken"
[19:24] <natefinch> (at least if you're searching for a non-promulgated charm and/or your search methodology is poor :)
[19:24] <rick_h_> natefinch: it all depends on what you look for
[19:24] <rick_h_> search for 'open' and you get a ton of openstack as you should
[19:24] <rick_h_> natefinch: but usernames, not general great but that'll get better with new publish and users 'owning' their promuglated stuff
[19:25] <natefinch> rick_h_: the first thing I searched for was a charm name that I wanted to know if it had been picked up yet or not... I expected either 0 or 1 result. I got 100
[19:26] <rick_h_> natefinch: right, and we want to be amazingly helpful and see if you typod, or if you meant something else, or ...
[19:27] <natefinch> rick_h_: all it takes is a "no exact matches found, here's some others..." I think.  BUt I'll file a bug.
[19:28] <bdx> thedac: sup
[19:28] <thedac> hey bdx how's it going?
[19:29] <bdx> hey whats up man? going well....I was wondering if I can get your take on an issue I'm having
[19:29] <thedac> bdx: I'll try I am currently juggling a few issues.
[19:29] <natefinch> rick_h_: uh... dumb question.  where do I file the bug?
[19:30] <bdx> thedac: its cool man...no worries...
[19:30] <rick_h_> natefinch: footer, "Report a bug on this site"
[19:30] <natefinch> rick_h_: oh man.  It's snuck in with the copyright.  Never would have found that.
[19:30] <bdx> I guess I could just let er' rip
[19:31] <natefinch> rick_h_: (I even looked in the footer)
[19:31] <rick_h_> natefinch: good, most folks will not report bugs then bwuhahaha!
[19:32] <bdx> openstack-charmers: I'm experiencing an issue where, when I try to attach > 1 networks to a neutron router....everything breaks
[19:33] <bdx> openstack-charmers: I've vlan tenant networks configured, and flat external
[19:33] <bdx> using dvr
[19:34]  * natefinch reports a bug about how hard it is to find the report a bug link.
[19:35] <bdx> openstack-charmers: I have had success connecting multiple vlan networks to the same router before in kilo, just not with openstack deployed by juju
[19:36] <bdx> I'm hesitent to say, but I think there is a misconfiguration somewhere within the neutron config
[19:37] <thedac> bdx: best bet is to file a bug https://bugs.launchpad.net/charms/+filebug with as much detail on how to recreate the failure as possibe. (proably against neutron-api)
=== Makyo is now known as Guest3473
[19:37] <bdx> openstack-charmers: I'm currently in the process of writing up a bug for this, but I was hoping to get some insight from someone asap
=== CyberJacob_ is now known as Guest58713
=== Saviq_ is now known as Saviq
[19:39] <bdx> I'm super bummed, because I only created a /24 network, and now need to expand ip space
[19:39] <thedac> bdx: sorry, I have not run into this. so no off the cuff ideas
=== plars_ is now known as plars
[19:41] <bdx> openstack-charmers: I can create other netron routers, and add networks to them, and then create routes to eachother through the use of another router, static routes on each network and static ports
[19:41] <bdx> but it hacky
[19:41] <bdx> neutron*
[19:42] <bdx> thedac: its cool man....I just am at a point where I can't be taking down the stack, neutron, or network anymore, so dealing with this is slightly more touchy
[19:43] <bdx> and nerve wrecking
[19:44] <lazyPower> bdx: understandable
[19:45] <bdx> thedac: I was hoping you might help put some heat on this as you have with in the past, but if you are busy, no worries
[19:45] <bdx> lazyPower: you trying to get some of this?
[19:46] <lazyPower> no but i follow wha tyou're asking
[19:46] <thedac> bdx: yeah, we have a number of priorities at the moment. So the bug report with logs is the best way to get a response
[19:46] <lazyPower> and i dont have any off the cuff ideas either.
[19:48] <bdx> lazyPower, thedac: my approach to this is to replicate the issue on a test stack, and test/apply fixes there
[19:50] <lazyPower> bdx: sounds reasonable
[19:50]  * bdx is sad
[19:51]  * bdx is easily enabled to build new test stack and replicate issue w/o wasting time or effort
[19:52]  * bdx is thankfull for juju
[19:52] <bdx> *thankful
[19:53] <bdx> openstack-charmers: ok bug time, look out
[20:06] <natefinch> urulama: is the charm store ingesting stuff from launchpad still?  I pushed a charm to my local namespace 8 hours ago and it's still not showing up.
[20:13] <lazyPower> natefinch: any proof errors when you run `charm proof`?
[20:13] <lazyPower> natefinch: and the store is still ingesting from launchpad unless that changed today
[20:15] <natefinch> lazyPower: does my charm have to pass charm proof for it to get published to my personal namespace?
[20:16] <lazyPower> i feel like that was myth=busted in the past, but it doesn't hurt to give it a go
[20:18] <rick_h_> natefinch: use charm2 and no
[20:18] <rick_h_> natefinch: highly suggest trying the charm2 publish work vs ingestion and it'd be great to expand the folks dog fooding internally
[20:19] <rick_h_> natefinch: yes, the old ingestion will skip things that have an E in charm proof
[20:19] <natefinch> ah that may well be it
[20:19] <natefinch> I'll try charm2, though. Certainly better than push and wait with no feedback :)
[20:19] <rick_h_> natefinch: that's the plan :)
[20:20] <marcoceppi> rick_h_: if you use charm2 publish, deployer won't work
[20:20] <rick_h_> marcoceppi: oh? do we know why?
[20:20] <marcoceppi> rick_h_: it's not in the v3 api
[20:21] <marcoceppi> we didn't roll forward because we were expecting juju deploy in 1.26
[20:21] <rick_h_> marcoceppi: huh? why does deployer look at v3 api for a deploy to work with a cs url?
[20:21] <marcoceppi> rick_h_: /me shrugs
[20:21] <marcoceppi> rick_h_: I thought that was the reason
[20:22] <marcoceppi> it might not be
[20:22] <rick_h_> marcoceppi: I'd hope not. I wasn't aware of it sorry.
[20:22] <rick_h_> marcoceppi: a charmstore charm uploaded, published, and public ACLs I'd expect juju to deploy with deployer just fine
[20:23] <marcoceppi> rick_h_: it doesn't atm, otp but I'll get some debug info
[20:23] <marcoceppi> kwmonroe: ^^
[20:23]  * natefinch has never in his life used deployer, so no problem there
[20:23] <rick_h_> marcoceppi: k, getting bac to join so we can look into it
[20:24] <bac> hi rick_h_
[20:24] <rick_h_> bac: marcoceppi was telling me of an issue with charm2 and deployer: http://paste.ubuntu.com/14432496/
[20:25] <rick_h_> bac: can you work with uros to schedule investigating this please?
[20:25] <rick_h_> bac: I'd expect it to work fine, but must be missing something
[20:25] <bac> rick_h_: sure
[20:25] <rick_h_> bac: marcoceppi will get some more debug info on specific charm/bundle file used, etc
[20:26] <rick_h_> bac: ty!
[20:26] <urulama> marcoceppi: which charm is that? also, is it multiseries charm? if it is, not sure juju handles that already
[20:27] <rick_h_> urulama: go EOD :P
[20:27] <urulama> rick_h_: waiting for my summer clothes to get out of the washer :)
[20:27] <urulama> not much use for them lately :)
[20:27] <rick_h_> urulama: heh same here
[20:27] <rick_h_> last load in the dryer!
[20:28] <marcoceppi> urulama rick_h_ benchmark-gui
[20:28] <marcoceppi> not multi-series
[20:31] <urulama> marcoceppi: https://api.jujucharms.com/charmstore/v4/benchmark-gui/meta/extra-info
[20:31] <urulama> marcoceppi: is this latest?
[20:32] <marcoceppi> urulama: yup
[20:36] <urulama> marcoceppi: hm, have just deployed that charm
[20:36] <urulama> using 1.25 that is
[20:37] <natefinch> so... how do I get charm2?
[20:37] <marcoceppi> urulama: put it in a bundle and use deployer
[20:37] <urulama> marcoceppi: ha, i think i know what it might be ... do "rm ~/.go-cookies" please
[20:38] <urulama> natefinch: it's under PPA in yellow. if you want to be tester, we can add you
[20:39] <natefinch> urulama: would love to help test.  No idea what yellow is, though :)
[20:39] <rick_h_> natefinch: think LP teams
[20:40] <rick_h_> natefinch: that have never been renamed over the years because that's work
[20:40] <natefinch> lol
[20:40] <rick_h_> now you know what yellow is :)
[20:40] <natefinch> I think I joined just as the color teams were being phased out.
[20:40] <rick_h_> natefinch: ah ok
[20:44] <urulama> marcoceppi: did that help?
[20:44] <marcoceppi> urulama: in a meeting, will have to try later
[20:45] <urulama> kk
[20:53] <kwmonroe> urulama: marcoceppi:  quick test.yaml with benchmark-gui fails with deployer giving a 404: http://paste.ubuntu.com/14432687/
[20:55] <kwmonroe> bac: fyi  ^^ in case you're looking at deployer failing with charm2 publish
[20:59] <bac> thanks kwmonroe
[21:00] <kwmonroe> np bac, fwiw, the store_url it's hitting is https://store.juju.ubuntu.com/charm/trusty/benchmark-gui-0
[21:00] <urulama> hm
[21:04] <urulama> kwmonroe: deployer uses legacy charm store
[21:04] <urulama> PING store.juju.ubuntu.com (91.189.95.67) 56(84) bytes of data.
[21:04] <urulama> 64 bytes from pupunha.canonical.com (91.189.95.67): icmp_seq=1 ttl=128 time=35.4 ms
[21:05] <kwmonroe> also fwiw, "juju quickstart test.yaml" deploys the gui and then doesn't seem to do anything.  notification area in the gui says "deployment in progress", but the benchmark-gui charm is never deployed.
[21:05] <urulama> jujucharms is on 162.213.33.121
[21:05] <urulama> so, no wonder it doesn't exist, you're not using the charmstore to which it was uploaded
[21:05] <kwmonroe> that's with juju-quickstart-2.2.4+bzr147+ppa42~ubuntu15.04.1
[21:07] <d4rks1d3> Hi
[21:08] <d4rks1d3> Anyone know if it is possible to have different settings for units
[21:09] <urulama> kwmonroe: ok, we'll look into it
[21:10] <kwmonroe> thanks urulama - do you want me to try a different store url in deployer?
[21:10] <urulama> kwmonroe: try with https://api.jujucharms.com/charmstore
[21:13] <kwmonroe> yup urulama, that works when deployer grabs https://api.jujucharms.com/charmstore/charm/trusty/benchmark-gui-0
[21:13] <kwmonroe> would something simliar be causing the apparently stalled deployment with quickstart?
[21:14] <urulama> quickstart should be using the new store already
[21:16] <kwmonroe> hm, ok.  i'll open a bug with the potential fix for deployer and repro steps for quickstart
[21:37] <d4rks1d3> Does anyone know whether or not is possible to have different config settings for 2 instances/units of the same service? thanks in advance for your support
[21:38] <blahdeblah> d4rks1d3: configs apply to all units of a service; to have different ones you need to create a new service with the same charm and set the config differently for that service
[21:40] <d4rks1d3> Thanks blahdeblah you mean to copy the whole charms and mofidy the "name:" field in metadata.yaml?
[21:41] <blahdeblah> d4rks1d3: No, there's no need to copy the charm; you just deploy it using a different service name
[21:41]  * blahdeblah digs for exact syntax
[21:41] <d4rks1d3> Thanks a lot blahdeblah
[21:43] <blahdeblah> d4rks1d3: Looks like you just add the service name on the end of the deploy command.  By default it matches the charm name, but you can specify something different.  juju deploy --help should show you all you need to know.
[21:44] <d4rks1d3> Thanks a lot blahdeblah
[21:49] <blahdeblah> d4rks1d3: You're welcome! :-)
[21:53] <kwmonroe> bac: urulama: marcoceppi, bugs for deployment failure with charm2 charms for quickstart (https://bugs.launchpad.net/juju-quickstart/+bug/1532005) and deployer (https://bugs.launchpad.net/juju-deployer/+bug/1531999)
[21:53] <mup> Bug #1532005: deployment failure when bundle includes charm2 published charm <juju-quickstart:New> <https://launchpad.net/bugs/1532005>
[21:53] <mup> Bug #1531999: deployer 404s on new published charms <juju-deployer:New> <https://launchpad.net/bugs/1531999>
[21:55] <frankban> kwmonroe: the quickstart bug does not really seem a bug, did the deployment fail?
[21:56] <kwmonroe> frankban: it didn't deploy any charm from the bundle.. it just stops after juju-gui.
[21:56] <frankban> kwmonroe: oh I think it will fail because it still uses the deployer under the hood
[21:58] <kwmonroe> ah, gotcha frankban.. so a deployer fix would fix quickstart too.. i'll note that in the quickstart bug.
[21:58] <frankban> kwmonroe: I am updating quickstart bug
[21:58] <kwmonroe> ack - thanks frankban!
[22:00] <frankban> kwmonroe: done, ty
=== alexisb is now known as alexisb-afk
[22:58] <lazyPower> blahdeblah nice pickup. :+1:
[23:15] <blahdeblah> lazyPower: why thank ya! :-)
[23:33] <blahdeblah> lazyPower: BTW, still trying to get my head around your DNS-Charm; still keen for a hangout or something to pick your brain on it sometime.
[23:33] <lazyPower> sure
[23:33] <lazyPower> I'd really like to re-write it using layers
[23:34] <lazyPower> as implementing new providers as layers would be much easier than the python module rig-a-maroo i have in there now
[23:34] <lazyPower> but thats an exercise in time management i cant afford this cycle
[23:35] <blahdeblah> Yeah - layers makes a huge amount of sense for that