[00:00] You have clicked on propose for merging? [00:00] basically to enable cassandra to work in lxc [00:00] yup [00:00] should I press again? [00:00] hrmm... usually that creates a new bug [00:00] I can't find the bug. [00:00] ok [00:01] I'll press again [00:01] I see "Charles Butler: Pending requested 2015-04-22 " [00:01] I will review it right away [00:01] I'll propose for merging putting you as a reviewer now [00:01] Yes I see that too. I don't see how to approve or review these changes [00:02] Propose for merging and I will have a look [00:03] 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] OK let me check by that branch [00:03] let's see if I can just add you as a reviewer of the current proposal [00:03] I just need a link to the merge proposal [00:03] there [00:04] added [00:04] https://code.launchpad.net/~celebdor/charms/precise/cassandra/hostname_resolve/+merge/257120 [00:04] OK that is a different link [00:04] The reason this one is not in the review queue, is because the status is in "Work in progress" [00:04] It needs to be in "Fix committed" for the queue to pick it up. [00:06] try now [00:06] I can only move it to "needs review" [00:06] Oh my mistake [00:07] mbruzek: if you want to try the pinning [00:07] you can run it like so [00:08] mbruzek: http://paste.ubuntu.com/11833500/ [00:08] configuration yaml for deploying [00:08] and target an lxc machine [00:15] apuimedo: I found a problem. [00:16] apuimedo: Adding a configuration option like this must be added to config-changed. [00:17] mmm [00:17] let me see [00:18] where's config-changed? mbruzek [00:19] apuimedo: It is cassandra-common. Let me comment in the bug and [00:19] I will explain. [00:19] ok [00:23] OK. [00:24] This new configuration option is ONLY read on the install hook. [00:24] yes [00:24] If cassandra charm is installed and a user changes the package_version only the config-changed hook is called. [00:25] So the user would not see any error and *assume* the version has changed [00:25] juju set cassandra package_version=2.11 [00:26] apuimedo: I put my review in the Merge Proposal https://code.launchpad.net/~celebdor/charms/precise/cassandra/hostname_resolve/+merge/257120 [00:27] thanks for the review [00:28] I'll look into the changes you propose tomorrow [00:28] I was under the impression that as it stood, the charm didn't reinstall even if you changed the repo [00:29] (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] mbruzek: ^^ [00:31] apuimedo: I understand your point, but the immutable configuration breaks user expectations [00:32] If the user sets the version after install they would have no way to know the version was not changed. [00:32] You could have the same logic in the configure_cassandra function to run apt-get to get a specific version. [00:34] 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. === kadams54 is now known as kadams54-away === scuttlemonkey is now known as scuttle|afk === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === mhilton_ is now known as mhilton === lukasa_ is now known as lukasa_away === lukasa_away is now known as lukasa_ === scuttle|afk is now known as scuttlemonkey [13:08] 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 ? === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away === psivaa-afk is now known as psivaa [15:07] Is the juju-reboot statement still valid in a charm ? If so does it require a prior import in python ? [15:16] nevermind, I was just being stoopid === kadams54 is now known as kadams54-away === scuttlemonkey is now known as scuttle|afk === scuttle|afk is now known as scuttlemonkey === scuttlemonkey is now known as scuttle|afk === lukasa_ is now known as lukasa_away [17:10] stub: I think we lost you === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away === scuttle|afk is now known as scuttlemonkey === kadams54-away is now known as kadams54 [19:59] hi, I have a question related to quantum-gateway charm, I hope this is the right channel for it. [20:00] I see the TODO item on https://jujucharms.com/trusty/quantum-gateway : 'Support VLAN in addition to GRE+OpenFlow for L2 separation.' [20:01] does that mean that currently you cannot override the default and set it to VLAN only? [20:03] 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] 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] 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 === kadams54 is now known as kadams54-away [20:20] lazyPower: thanks, appreciate it! i'm in pacific time, so i would still be around late evening - midday EU. [20:20] 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] but its too soon to tap on them for questions like that :) [20:20] ddellav: ^ we're coming for you @_@ === kadams54-away is now known as kadams54 [20:21] lol [20:21] i'll do what I can [20:30] 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] i'm just browsing through the 'hooks' to see how its passed around.. [20:39] wolverineav: we don't really use quantum-gateway anymore,a nd instead use nuetron-api [20:39] is there a reason you need quantum? [20:40] fwiw, I believe the neutron charm supports VLAN with openvswitch [20:42] 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] marcoceppi: let me try it out with neutron-api. thanks! === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [21:23] 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] 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] what is the recommended combination when deploying with L3 and DHCP service? [21:26] 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] 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. === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [23:39] wolverineav: yes, sorry, seems liek you've gotten it now [23:39] if it helps I can give you a bundle that is a reference architecture for OpenStack which includes how neutron-api works [23:41] marcoceppi: yes, that would be helpful :) [23:42] wolverineav: https://jujucharms.com/openstack-base/ [23:43] wolverineav: and here's the actual bundle https://api.jujucharms.com/charmstore/v4/bundle/openstack-base-34/archive/bundle.yaml [23:55] marcoceppi: this is great! thanks! === kadams54 is now known as kadams54-away