[00:00] <mbruzek> You have clicked on propose for merging?
[00:00] <apuimedo> basically to enable cassandra to work in lxc
[00:00] <apuimedo> yup
[00:00] <apuimedo> should I press again?
[00:00] <mbruzek> hrmm... usually that creates a new bug
[00:00] <mbruzek> I can't find the bug.
[00:00] <apuimedo> ok
[00:01] <apuimedo> I'll press again
[00:01] <apuimedo> I see "Charles Butler: Pending requested 2015-04-22 "
[00:01] <mbruzek> I will review it right away
[00:01] <apuimedo> I'll propose for merging putting you as a reviewer now
[00:01] <mbruzek> Yes I see that too.  I don't see how to approve or review these changes
[00:02] <mbruzek> Propose for merging and I will have a look
[00:03] <apuimedo> it tells me "There is already a branch merge proposal registered for branch lp:~celebdor/charms/precise/cassandra/hostname_resolve to land on lp:charms/cassandra that is still active."
[00:03] <mbruzek> OK let me check by that branch
[00:03] <apuimedo> let's see if I can just add you as a reviewer of the current proposal
[00:03] <mbruzek> I just need a link to the merge proposal
[00:03] <apuimedo> there
[00:04] <apuimedo> added
[00:04] <apuimedo> https://code.launchpad.net/~celebdor/charms/precise/cassandra/hostname_resolve/+merge/257120
[00:04] <mbruzek> OK that is a different link
[00:04] <mbruzek> The reason this one is not in the review queue, is because the status is in "Work in progress"
[00:04] <mbruzek> It needs to be in "Fix committed" for the queue to pick it up.
[00:06] <apuimedo> try now
[00:06] <apuimedo> I can only move it to "needs review"
[00:06] <mbruzek> Oh my mistake
[00:07] <apuimedo> mbruzek: if you want to try the pinning
[00:07] <apuimedo> you can run it like so
[00:08] <apuimedo> mbruzek: http://paste.ubuntu.com/11833500/
[00:08] <apuimedo> configuration yaml for deploying
[00:08] <apuimedo> and target an lxc machine
[00:15] <mbruzek> apuimedo: I found a problem.
[00:16] <mbruzek> apuimedo: Adding a configuration option like this must be added to config-changed.
[00:17] <apuimedo> mmm
[00:17] <apuimedo> let me see
[00:18] <apuimedo> where's config-changed? mbruzek
[00:19] <mbruzek> apuimedo: It is cassandra-common.  Let me comment  in the bug and
[00:19] <mbruzek> I will explain.
[00:19] <apuimedo> ok
[00:23] <mbruzek> OK.
[00:24] <mbruzek> This new configuration option is ONLY read on the install hook.
[00:24] <apuimedo> yes
[00:24] <mbruzek> If cassandra charm is installed and a user changes the package_version  only the config-changed hook is called.
[00:25] <mbruzek> So the user would not see any error and *assume* the version has changed
[00:25] <mbruzek> juju set cassandra package_version=2.11
[00:26] <mbruzek> apuimedo: I put my review in the Merge Proposal  https://code.launchpad.net/~celebdor/charms/precise/cassandra/hostname_resolve/+merge/257120
[00:27] <apuimedo> thanks for the review
[00:28] <apuimedo> I'll look into the changes you propose tomorrow
[00:28] <apuimedo> I was under the impression that as it stood, the charm didn't reinstall even if you changed the repo
[00:29] <apuimedo> (which is an already present configuration option) so that's why I did not consider the need for taking the config change into account
[00:29] <apuimedo> mbruzek: ^^
[00:31] <mbruzek> apuimedo: I understand your point, but the immutable configuration breaks user expectations
[00:32] <mbruzek> If the user sets the version after install they would have no way to know the version was not changed.
[00:32] <mbruzek> You could have the same logic in the configure_cassandra function to run apt-get to get a specific version.
[00:34] <mbruzek> Once you have the change put the Merge Proposal back in Ready for Review and give me a ping I will review it straight away.
[13:08] <caribou> Hi, is there some specific helper to add debconf values before installing a package or we should just shell out the debconf-set-selections command ?
[15:07] <caribou> Is the juju-reboot statement still valid in a charm ? If so does it require a prior import in python ?
[15:16] <caribou> nevermind, I was just being stoopid
[17:10] <cory_fu> stub: I think we lost you
[19:59] <wolverineav> hi, I have a question related to quantum-gateway charm, I hope this is the right channel for it.
[20:00] <wolverineav> I see the TODO item on https://jujucharms.com/trusty/quantum-gateway : 'Support VLAN in addition to GRE+OpenFlow for L2 separation.'
[20:01] <wolverineav> does that mean that currently you cannot override the default and set it to VLAN only?
[20:03] <wolverineav> if that's the case, I guess the first step would be to submit an upstream patch to add a new configurable property, right?
[20:04] <wolverineav> oh, some context - this property would apply to the ML2 plugin in neutron (quantum-gateway for juju), which is currently set to 'type_drivers = gre,vxlan,vlan,flat'
[20:15] <lazyPower> wolverineav: this is the correct channel, but most of our openstack charmers are EU based. That would be a great question for the list - and I'll make sure to circle back and piont them at it
[20:20] <wolverineav> lazyPower: thanks, appreciate it! i'm in  pacific time, so i would still be around late evening - midday EU.
[20:20] <lazyPower> yeah - we have some fresh blood just now ramping up in the OS charm space that should be able to lend a hand moving forward
[20:20] <lazyPower> but its too soon to tap on them for questions like that :)
[20:20] <lazyPower> ddellav: ^ we're coming for you @_@
[20:21] <ddellav> lol
[20:21] <ddellav> i'll do what I can
[20:30] <wolverineav> haha..I guess this might be the perfect fit for ramping up - how to add a new config property which is set in the *.ini file before the charm is first applied ;-)
[20:32] <wolverineav> i'm just browsing through the 'hooks' to see how its passed around..
[20:39] <marcoceppi> wolverineav: we don't really use quantum-gateway anymore,a nd instead use nuetron-api
[20:39] <marcoceppi> is there a reason you need quantum?
[20:40] <marcoceppi> fwiw, I believe the neutron charm supports VLAN with openvswitch
[20:42] <wolverineav> ah, I guess the example I saw was an old one which used quantum-gateway. and since it had 'trusty' and supported juno, I assumed its up to date
[20:43] <wolverineav> marcoceppi: let me try it out with neutron-api. thanks!
[21:23] <wolverineav> marcoceppi: when specifying 'network-manager: Neutron' in nova-cloud-controller, it is mentioned "When using the Neutron option you will most likely want to use the neutron-gateway charm to provide L3 routing and DHCP Services."
[21:24] <wolverineav> when I search for neutron-gateway: https://jujucharms.com/q/neutron-gateway , I see three relevant charms - quantum-gateway, neutron-openvswitch and neutron-api
[21:25] <wolverineav> what is the recommended combination when deploying with L3 and DHCP service?
[21:26] <wolverineav> I'm guessing its nova-cloud-controller + quantum-gateway + neutron-api. and the last one (neutron-api) is what I was missing earlier
[21:35] <wolverineav> ah, actually no - nova-cloud-controller + neutron-api are part of openstack controller. neutron-openvswitch is on every compute node and the node where we deploy quantum-gateway.
[23:39] <marcoceppi> wolverineav: yes, sorry, seems liek you've gotten it now
[23:39] <marcoceppi> if it helps I can give you a bundle that is a reference architecture for OpenStack which includes how neutron-api works
[23:41] <wolverineav> marcoceppi: yes, that would be helpful :)
[23:42] <marcoceppi> wolverineav: https://jujucharms.com/openstack-base/
[23:43] <marcoceppi> wolverineav: and here's the actual bundle https://api.jujucharms.com/charmstore/v4/bundle/openstack-base-34/archive/bundle.yaml
[23:55] <wolverineav> marcoceppi: this is great! thanks!