=== natefinch-afk is now known as natefinch
[02:35] <beisner> thedac, ack on that.  driven by the mitaka template @ http://bazaar.launchpad.net/~openstack-charmers/charms/trusty/nova-cloud-controller/next/view/head:/templates/mitaka/api-paste.ini#L111
=== urulama__ is now known as urulama
=== cuzek is now known as gberginc
[09:13] <jamespage> urulama, morning - our /next branches under https://jujucharms.com/u/openstack-charmers-next appear to have stopped injesting  - could you take a look?
[09:13] <urulama> jamespage: will do
[09:15] <urulama> jamespage: https://api.jujucharms.com/charmstore/v4/changes/published?start=2016-02-17
[09:15]  * jamespage scratches his head
[09:16] <jamespage> urulama, not sure whey https://jujucharms.com/u/openstack-charmers-next/neutron-api/trusty
[09:16] <jamespage> != https://code.launchpad.net/~openstack-charmers-next/charms/trusty/neutron-api/trunk
[09:19] <urulama> jamespage: https://api.jujucharms.com/charmstore/v4/~openstack-charmers-next/neutron-api/meta/extra-info/bzr-digest shows it is the last revision ... however, the revision history is different. we did migration of some legacy services from PS3 to PS4.5, there might still be some issues
[09:20] <urulama> jamespage: also, https://api.jujucharms.com/charmstore/v5/~openstack-charmers-next/trusty/neutron-api/archive/tox.ini shows the change in code you did on Feb 16th
[09:21] <jamespage> hmm so its probably just the change history that is foobar right?
[09:21] <urulama> jamespage: yes
[09:21] <jamespage> urulama, ok thanks
[09:23] <urulama> jamespage: sorry for the confusion, but we're currently focused on new publishing process, keeping legacy ingestion alive but no improvements
[09:23] <jamespage> urulama, np - understand
[09:23] <jamespage> can't wait to switchover tbh
[09:24] <urulama> :) as do we
[09:55] <magicaltrout> okay I'm new to EC2 VPC having come from EC2 Classic. But whats Juju supposed to do wrt to firewalls and routing?
[09:55] <magicaltrout> if I expose a service I would assume I can connect to it from the outside world
[09:55] <magicaltrout> but I've had to slap on a custom rule in my VPC security group
[09:56] <magicaltrout> expose seems to be doing absolutely nothing
[10:07] <gennadiy> hi everybody. i have got some issues with my bundle again - new version doesn't appear in charm store -
[10:07] <gennadiy> https://jujucharms.com/u/tads2015dataart/
[10:07] <gennadiy> but it's pushed to launchpad - https://code.launchpad.net/~tads2015dataart/charms/bundles/tads2015-demo/bundle
[10:08] <gennadiy> how much time do i need to wait until new version will be published?
[10:09] <magicaltrout> last night was taking a couple of hours
[10:12] <gennadiy> thanks, do i need to attach bugtracker to bundle ? point #4 - https://jujucharms.com/docs/1.25/charms-bundles
[10:14] <magicaltrout> are you trying to get it into the recommended name space?
[10:14] <gennadiy> no, i need userspace only
[10:15] <magicaltrout> then you can ignore that
[10:15] <gennadiy> thanks
[10:15] <magicaltrout> the bundles will update eventually, I think its just running a bit slow
[10:51] <smartbit> How do I verify the version of juju-gui? I want to test https://bugs.launchpad.net/juju-gui/+bug/1542652
[10:51] <mup> Bug #1542652: juju-gui hangs on "Connecting to the Juju environment" <juju-gui:Fix Released by bac> <https://launchpad.net/bugs/1542652>
[10:53] <magicaltrout> smartbit: can you do juju status --format yaml juju-gui
[10:54] <magicaltrout> and get the charm version back?
[10:56] <magicaltrout> some people make me so sad, a company I work for deem it acceptable to have an 11 minute Hive query running in a reporting tool
[10:56]  * magicaltrout whips out the shotgun
[10:56] <marcoceppi> magicaltrout: welcome to the bleeding edge
[10:56] <magicaltrout> hehe
[10:56] <smartbit> Which .box files do you recommend downloading with the newer juju-gui?
[10:56] <magicaltrout> its fun
[10:57] <magicaltrout> although a way to "export" running nodes and import them into a newly bootstrapped environment would be cool
[12:27] <bac> smartbit: if you follow the same vagrant instructions you'll get the new juju-gui charm.  look forward to hearing if it now works for you.
[12:31] <smartbit> bac: Thanks will give it a try. Tried ubuntu/trusty64-juju' (v20160210.0.0) and that had juju-gui/0 agent-version: 1.25.3.1
[12:32] <bac> smartbit: that is the version of the juju agent, not the juju-gui
[12:33] <smartbit> bac: all the output I got from "juju status --format yaml juju-gui"
[12:36] <bac> smartbit: the default charm at cs:juju-gui has the fix and is the one that vagrant pulls
[12:39] <bac> smartbit: you can check the version of the gui that is running by going to http://<your gui IP>/version
=== redelmann__ is now known as redelmann
[13:18] <smartbit> bac: https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-juju-vagrant-disk1.box works like a charm :-)
[13:18] <smartbit> http://127.0.0.1:6079/version showed "version": "2.0.3"
[13:18] <smartbit> Thanks for helping out.
[13:26] <bac> smartbit: good news!  thanks for the bug report.  sorry for the inconvenience.  we'll keep an eye on vagrant in the future.
[13:35] <smartbit> bac: took me quite some time. Fixed now.
[13:35] <smartbit> Two other inconvenient items: 1) "Installing Virtualbox Guest Additions 5.0.14 - guest version is 4.3.36" which takes quite some time.
[13:35] <smartbit> 2) after "You have not informed bzr of your Launchpad ID, and you must do this to
[13:35] <smartbit> ==> default: write to Launchpad or access private data.  See "bzr help launchpad-login".
[13:35] <smartbit> ==> default: Branched 19 revisions." the output scrolls some 200-500 lines in bold-red mostly with a single character, while receiving some data.
[13:35] <smartbit> Should I file a bug for each of these? If so, what would be most appropriate topic?
[13:48] <bac> smartbit: those should be filed against the vagrant image project...but i'm not sure where that is on launchpad
[13:48] <bac> smartbit: i'll find out
[13:50] <rick_h_> aisrael: ^ do you know?
[14:06] <jamespage> icey, sorry but can you rebase https://code.launchpad.net/~chris.macnaughton/charms/trusty/ceph-osd/storage-hooks/+merge/284445 as well? showing a conflict
[14:07] <icey> ack jamespage
[14:13] <icey> done jamespage
[14:17] <jamespage> icey, ta - I'll let osci run and then take a look
[14:24] <aisrael> rick_h_: bac: Vagrant bugs can be opened here: https://launchpad.net/juju-vagrant-images
[14:25] <rick_h_> aisrael: ty
[14:25] <rick_h_> smartbit: ^
[14:25] <bac> thanks aisrael
[14:25] <smartbit> rick_h: thanks
[14:29] <smartbit> bac: added comment to https://launchpad.net/bugs/1542652 regarding description of ws-secure. It seems to me ws_secure has three states (trivalent, ternary, or trilean) now: True, False and Unset. The description says it is Boolean.
[14:29] <mup> Bug #1542652: juju-gui hangs on "Connecting to the Juju environment" <juju-gui:Fix Released by bac> <https://launchpad.net/bugs/1542652>
[14:32] <bac> smartbit: juju does not support such a type.  sorry for the imprecision but i think the description does adequately describe it.
[14:32] <smartbit> bac: understand. No prob.
[14:46] <lazyPower> kjackal o/ heyo
[14:46] <lazyPower> i hear you're having an issue with your OpenStack deployment?
[14:47] <kjackal> yes indeed
[14:47] <lazyPower> can you re-paste the bits about the symptoms?
[14:48] <kjackal> request (https://cyclades.okeanos.grnet.gr/compute/v2.0/os-availability-zone) returned unexpected status: 400; error info: {"badRequest": {"message": "API endpoint not found", "code": 400, "details": ""}}
[14:48] <kjackal> this happens when I try to bootstrap this private Openstack cloud
[14:48] <lazyPower> beisner jamespage ddellav - have either of you seen this happen after standing up the openstack bundle?
[14:48] <kjackal> I am not sure if this cloud runs on the latest release
[14:49] <kjackal> no no wait
[14:49] <kjackal> I didn't setup this cloud myself
[14:49] <lazyPower> ah so this isn't charmed openstack?
[14:49] <kjackal> no, it is not
[14:49] <lazyPower> well that changes things a bit
[14:49] <beisner> trying to juju deploy something on top of an openstack cloud using the openstack provider?
[14:50] <kjackal> yes
[14:50] <kjackal> the cloud already exists
[14:50] <kjackal> they claim they offer an openstack API
[14:50] <beisner> kjackal, what cloud is it?
[14:50] <kjackal> I am wondering how does juju figureout the API version to use when talking to openstack
[14:51] <beisner> kjackal, also any idea what openstack release it's running?   also, whether it's got keystone v1/v2 support?
[14:51] <kjackal> the cloud is this one: https://okeanos.grnet.gr/home/
[14:52] <kjackal> I am not sure about the versions
[14:52] <kjackal> is there a way to check this?
[14:52] <kjackal> Ahh wait
[14:53] <kjackal> auth-url: https://accounts.okeanos.grnet.gr/identity/v2.0auth-url: https://accounts.okeanos.grnet.gr/identity/v2.0
[14:53] <kjackal> sorry auth-url: https://accounts.okeanos.grnet.gr/identity/v2.0
[14:53] <kjackal> so this should indicate it is a 2.0 ?
[14:54] <beisner> ok good, there are some known issues w/ keystone v3 at the moment so that's not it
[14:55] <beisner> kjackal, at this point, i'd tend to export the openstack credentials and poke around their cloud as your user with openstack clients.  there are a ton of variables in play.
[14:55] <kjackal> sounds like a plan
[14:56] <kjackal> any suggestions on the client?
[14:57] <beisner> python-openstackclient python-novaclient python-keystoneclient
[14:57] <kjackal> ah I see what you are saying! I got myself a weekend project then :)
[14:59] <kjackal> are there any "hidden/special" config options that can be used in environments.yaml ?
[15:00] <beisner> kjackal, yah, basically inspect the keystone catalog   keystone endpoint-list   and use nova to create/delete instances and security groups in the same way that juju would.   fyi --debug on the client cmds for eyebleeding detail.
[15:01] <beisner> i'm not sure of any undocumented enviro options on this
[15:01] <jamespage> dosaboy, re https://code.launchpad.net/~hopem/charms/trusty/cinder/default-to-glance-v2-api/+merge/284752
[15:02] <jamespage> where is the cutoff for use of v2? if its icehouse, lets drop the config option altogether and just set v2 please
[15:02] <jamespage> essex did not have cinder...
[15:05] <beisner> rockstar, zul - i've got a 2-node lxd deployment topology in the amulet test, and i'm seeing inconsistency on lxc config options on units:
[15:05] <beisner> http://pastebin.ubuntu.com/15111185/
[15:06] <beisner> storage.lvm_thinpool_name: LXDPool
[15:06] <beisner> seems like it should be on both units
[15:07] <beisner> doh.  the 2nd unit also has an empty `lvs` whereas the first unit has the LXDPool volume group as expected
[15:08] <dosaboy> jamespage: good point, and the only < I version we support still is E so i'll drop the config option
[15:08] <dosaboy> jamespage: is it safe to just remove the config option altogether?
[15:08] <beisner> rockstar, issue:  i can't file a stinkin' bug against the lxd charm until it promulgates some time down the line.  where do we track/file bugs?
[15:09] <dosaboy> i guess if you upgrade it will ignore it and complain if you try to set it again, so should be safe
[15:14] <gennadiy> hi everybody, i pushed my bundle 5 hrs ago - but it have not updated in store yet - https://code.launchpad.net/~tads2015dataart/charms/bundles/tads2015-demo/bundle
[15:14] <gennadiy> i used juju bundle prof before commit, everything was ok
[15:15] <jamespage> dosaboy, +1 yes - we may need to update bundles to reflect that change but I think that's fine
[15:15] <jamespage> no point having a knob that's useless
[15:18] <jamespage> beisner, updated my os dash mp - testing ok with the default bundle on xenial - lets see what amulet says...
[15:19] <jamespage> dosaboy, only people we might annoy is those with that set in a bundle
[15:19] <jamespage> but we can release note this
[15:19] <rockstar> beisner: I'm not sure where we track lxd charm bugs.
[15:19] <rockstar> lxd proper bugs are handled on github.
[15:22] <jamespage> can someone do me a quick +1 on https://code.launchpad.net/~james-page/charm-helpers/fixup-midonet-liberty-nonmem/+merge/286524
[15:22] <jamespage> testing ok with neutron-api
[15:23] <lazyPower> jamespage - approved
[15:23] <jamespage> lazyPower, ta
[15:31] <thedac> beisner: nova-cc merged
[15:31] <beisner> thedac, thx sir
[15:33] <stokachu> latest juju 2.0 beta1 login api started giving me this error on login: this version of Juju does not support login from old clients (not supported)
[15:34] <stokachu> I do pass Version: 2 into the parameters to utilize the older login api
[15:35] <stokachu> here is the request parameters used: https://github.com/Ubuntu-Solutions-Engineering/macumba/blob/master/macumba/api.py#L59-L64
[15:35] <stokachu> I also tried version 3 but same error message, any ideas?
[15:36] <magicaltrout> I found similar today
[15:36] <magicaltrout> the solution from the people that know was tear it down and start again ;'(
[15:36] <magicaltrout> so I did :)
[15:36] <magicaltrout> client <-> server mismatch
[15:37] <stokachu> magicaltrout: that directed to me?
[15:37] <magicaltrout> yeah
[15:37] <stokachu> ok ill try again with a fresh bootstrap
[15:38] <stokachu> magicaltrout: did that work for you? what api client are you using
[15:40] <marcoceppi> stokachu: what do you use to draw the full screen openstack-installer stuff from python?
[15:40] <stokachu> urwid is the toolkit
[15:41] <stokachu> marcoceppi: ^
[15:41] <rick_h_> marcoceppi: we used the same python tool in quickstart
[15:41] <stokachu> marcoceppi: i also have a library for widgets i commonly use https://github.com/Ubuntu-Solutions-Engineering/urwid-ubuntu
[15:41] <rick_h_> ooh, custom widgets ftw
[15:41]  * marcoceppi wants to take a crack at juju-top
[15:42] <stokachu> that would be cool
[15:43] <stokachu> magicaltrout: doesn't look like that works for me
[15:43] <stokachu> fresh bootstrap and the login api is failing
[15:44] <magicaltrout> soory stokachu clearly I lied :(
[15:45] <stokachu> wallyworld: https://github.com/juju/juju/commit/472e2d83a4edceea11e7dbee28c5bde78a920ce2 i think this is what is affecting me
[15:46] <stokachu> wallyworld: i attempted to set my version to 3 but i must still be doing something wrong
[15:52] <jamespage> dosaboy, so the multi l3 networks stuff - did you see my comments on the ceph one?
[15:53] <dosaboy> jamespage: yeah i fixed it already
[16:25] <stokachu> wallyworld: ok i got it worked out now
[16:25] <stokachu> disregard last messages
[16:30] <jamespage> oh lookling now then dosaboy
[16:31] <jamespage> dosaboy, not sure that's quite what I mean't
[16:31]  * jamespage looks some more
[16:33] <jamespage> dosaboy, you still need get_network_addrs to deal with resolution of public address when multiple l3 nets are in use
[16:39] <dosaboy> jamespage: otp, i'll take a closer look after, i might have rushed that one :(
[16:40] <jamespage> dosaboy, you went to far!
[16:49] <dosaboy> jamespage: oops now i see it ;)
[17:13] <kwmonroe> lazyPower: what's the right way to deal with a layered charm that has no unit_tests dir? layer-basic has it in the Makefile, but if the consuming charm doesn't include a unit_tests dir, lint gives this "unit_tests:1:1: E902 IOError: [Errno 2] No such file or directory: 'unit_tests'"
[17:14] <lazyPower> either provide a makefile that doesn't look for unit_test, or write unit_tests i suppose
[17:14] <kwmonroe> kjackal just ran into that ^^  i see in one of your charms, you used an empty __init__.py.  i'm curious if that's the best way to do it.
[17:20] <beisner> jamespage, your dashboard MP test hit bug 1546209 for wily
[17:20] <mup> Bug #1546209: Wily: apache2 Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:70 <uosci> <openstack-dashboard (Juju Charms Collection):New> <https://launchpad.net/bugs/1546209>
[17:20] <jamespage> beisner, I saw
[17:20] <beisner> jamespage, ack.
[17:20] <jamespage> I'll take a peek now
[17:21] <gennadiy>  can somebody help me with ? "i pushed my bundle 5 hrs ago - but it have not updated in store yet - https://code.launchpad.net/~tads2015dataart/charms/bundles/tads2015-demo/bundle"
[17:25] <jamespage> beisner, https://bugs.launchpad.net/charms/+source/neutron-gateway/+bug/1547122
[17:25] <mup> Bug #1547122: xenial: nova-api-metadata not running post deployment <openstack> <xenial> <neutron-gateway (Juju Charms Collection):New> <https://launchpad.net/bugs/1547122>
[17:26] <jamespage> nice
[17:27] <beisner> jamespage, hah.  oh neat
[17:29] <dosaboy> jamespage: sanity hopefully restored to l3 patches
[17:29]  * jamespage peeks
[17:29] <dosaboy> jamespage: i'm deploying now to test but let me know if that is what you were after
[17:38] <jrwren> gennadiy: i'm looking into it.
[17:39] <jrwren> gennadiy: bundle verification failed: ["cannot validate service \"restcomm\": configuration option \"sms_proxy\" not found in charm \"cs:~tads2015dataart/trusty/restcomm-4mesos-1\""]
[17:57] <balloons> marcoceppi, how's the list looking today? I have down charms for haystack and parse.
[17:57] <marcoceppi> what are those?
[17:58] <balloons> no idea, it was just in the pad of old ideas.
[17:58] <marcoceppi> balloons: we want layers
[17:59] <marcoceppi> so we want a rails layer, php layer
[17:59] <marcoceppi> to start
[18:00] <balloons> ok, brillant. I'll add those
[18:01] <balloons> what can we quantify as the deliverable. A published layer?
[18:01] <marcoceppi> balloons: i'll ahve a few more
[18:02] <marcoceppi> a layer that's published and used by one charm
[18:02] <marcoceppi> typically to prove the layer is good the author will publish a charm using it
[18:06] <balloons> ahh, makes sense
[18:10] <jamespage> beisner, I think the wily/liberty failure is a restart race on apache2
[18:10] <beisner> jamespage, yup looks like it
[18:10] <metsuke> does juju support multi-user environments?  I know we can make users, but can they be segregated between environments?
[18:10] <beisner> jamespage, trying to bind before the old proc has let go
[18:12] <jamespage> beisner, I think so but I can't repro on the box
[18:18] <jamespage> beisner, well anyway i've disable that test for now - I'd like to see if we get the same on xenial
[18:19] <beisner> jamespage, clearly this is a lie :-)   Feb 13 04:14:33 ubuntu systemd[1]: Stopped LSB: Apache2 web server.    i'd suspect that bit in apache2 init scripts (validating that it has stopped).
[18:20] <beisner> jamespage, ack thx
[18:20] <gennadiy> 2jrwren thanks a lot
[18:43] <pmatulis> i tried to 'create-model' and got this: "cmd supercommand.go:448 opening model: "controller-resource-group" config not specified" - what is that about?
[18:46] <Razva> is there any way to tail a juju deployment via autopilot? I cannot really find any logs of the ingoing installation...
[18:47] <pmatulis> something to do with the azure provider
[18:48] <pmatulis> axw: do you know?
[18:49] <pmatulis> this is the first time i hear of a parameter for azure called 'controller-resource-group'
=== urulama is now known as urulama__
[19:09] <beisner> hey coreycb - any clue of topology, config, relations, etc., for the barbican + aodh thing?
[19:09] <beisner> also, what u:os release combos should they be used for?
[19:10] <coreycb> beisner, I think we still need charms for those 2
[19:10] <coreycb> bug designate I believe would be ready for putting in bundles
[19:10] <beisner> coreycb, oh ok.   /me ignores card until charms exist with amulet tests.
[19:11] <coreycb> ddellav and I are just working through package updates so we can get the packages into main and I realized we don't have a great way to test them
[19:11] <coreycb> beisner, ok
[20:15] <cloudguru> Can anyone confirm the latest version of the layer/docker charm fully supports and has tested DOCKER_OPTS ?
[20:37] <firl> lazyPower any updates on kubernetes and the charming progress?
[20:40] <lazyPower> firl mbruzek and i are on a hangout right now debugging the etcd bug we thought we had squshed
[20:40] <firl> haha ok
[20:40] <lazyPower> if you want to join we can riff on some k8s
[20:40] <mbruzek> firl: What parts are you interested in?
[20:40] <firl> I have 20 minutes; don’t mind getting on
[20:40] <lazyPower> https://plus.google.com/hangouts/_/canonical.com/help-charm-helpers
[20:41] <lazyPower> the more the merrier
[20:42] <firl> requested
[20:44] <beisner> zul, o-c-t merged
[20:48] <beisner> zul, i get an error instance when i use raw instead of root-tar for the image format.
[20:48] <beisner> it works with root-tar
[20:51] <firl> celpa.firl@gmail.com
[20:52] <lazyPower> icey - did you get a PR formed for consul?
[20:52] <icey> lazyPower: I'll send you an MP today, I need to make 2 actually :)
[20:52] <icey> fix the install, and then one to integrate with a consul-agent
[20:53] <lazyPower> ok just curious - i went and looked. are you planning on proposing against upstream github or the ~zoology lp repo or?
[20:55] <icey> I can do whichever you'd rather, where is the GH repo?
[20:55] <lazyPower> mbruzek ^
[20:56] <mbruzek> icey: https://github.com/mbruzek/consul-charm
[20:57] <mbruzek> icey: that was written before I knew about layers
[20:57] <icey> mbruzek: I know :) I'm going to send a couple of PRs that are fairly small :)
[21:07] <icey> mbruzek: you already did the updates to change the release path
[21:07] <icey> WHY ISN'T THAT ON THE CHARMSTORE!?
[21:07] <mbruzek> icey: we are working on different stuff
[21:07] <mbruzek> my bad
[21:08]  * icey sadface
[21:08] <mbruzek> icey: truth be told I want to rewrite it in reactive.
[21:08] <mbruzek> I find those charms much easier to read and maintain.
[21:08] <icey> awesome
[21:09] <mbruzek> but you want what is in my github in the charmstore?
[21:18] <mbruzek> icey: I am running the bundletests now if they work I will propose that as a new charmstore branch
[21:19] <icey> mbruzek: the version currently in the charmstore cannot deploy so yes, that would be nice :)
[21:19] <mbruzek> icey: well then *you* can review the changes to expedite the process
[21:20] <icey> mbruzek: I can say they're nice but I'm community ;-)
[21:20] <icey> and I think the one in the charmstore is namespaces under zoologists
[21:20] <mbruzek> yeah that is the right place for it, I never got it proposed to ~charmers
[21:21] <mbruzek> I don't want to until it is a layer
[21:21] <mbruzek> but I can put it in the zoo
[21:23] <icey> mbruzek: let me know where you'd like me to look at it and I'm happy to do so
[21:26] <cory_fu> lazyPower: Hrm.  https://github.com/juju/charm-tools/pull/103 is missing a way to remove values from merged lists.
[21:27] <cory_fu> I feel like we need an extension to or a generalization of the "deletes" functionality in layer.yaml: https://github.com/juju/charm-tools/blob/master/doc/source/build.md#layeryaml
[21:27] <lazyPower> yeah i had made mention during my 1x1 that the PR was probably not a full fix for what we were looking at trying to do
[21:49] <lazyPower> cory_fu lets back that out until its gotten a proper round of tests yeah?
[21:49] <lazyPower> cory_fu would you prefer i submit an uncommit or do you want to peel it back?
[21:51] <cory_fu> Hrm.  This merged into master and not road-to-2.0, so I'm guessing it won't go into the next release anyway?
[21:51] <cory_fu> Or is that backwards?
[21:52] <lazyPower> I'm not certain tbh
[21:54] <cory_fu> What further testing are you wanting to do, though?
[21:58] <lazyPower> find out what is actually happening to metadata.yaml thats causing the sum mismatch in the test
[21:59] <cory_fu> I think it's pretty clear that the categories list is getting combined and the "databases" key is duped
[22:00] <cory_fu> Due to it being present in both layers.  I'm actually ok with that, now that I've thought about it for a while, but we do need some way of removing list values set by lower layers if we're going to do merging
[22:00] <lazyPower> ok, de-dupe by default right?
[23:04] <axw> pmatulis: controller-resource-group is an internal thing. if it's complaining about that not being set, there's a bug - you shouldn't need to set it
[23:09] <pmatulis> axw: ok, i opened a bug
[23:09] <axw> pmatulis: thanks