=== urulama_ is now known as urulama === zz_CyberJacob is now known as CyberJacob === lukasa_away is now known as lukasa === CyberJacob is now known as zz_CyberJacob === lukasa is now known as lukasa_away === lukasa_away is now known as lukasa === lukasa is now known as lukasa_away === lukasa_away is now known as lukasa [08:48] jose: Sorry I didn't get back to you the other day; other work preempted the charm I was working on. I ended up basing mine on a newer python-based charm. [09:49] Could a charmer have a look at https://code.launchpad.net/~daniel-thewatkins/charms/trusty/ubuntu-repository-cache/hotfix-leader-election/+merge/270838, please? [09:50] marcoceppi: lazypower: $others: ^ [10:10] jamespage, would you mind taking a look at https://code.launchpad.net/~gnuoy/charm-helpers/1496746/+merge/271443 when you have a moment? [10:12] gnuoy, For pagesize, size, min_size and nr_inodes options, you [10:12] can use [G|g]/[M|m]/[K|k] to represent giga/mega/kilo. [10:13] jamespage, ok, but that leaves me with some horrible code converting that to bytes. [10:15] gnuoy, hmm [10:16] gnuoy, well we need to support human usable config somewhere in the stack [10:16] gnuoy, but I don't think that's exposed just yet right? [10:16] gnuoy, some sort of general K M G functions would be good I think [10:17] ok === lukasa is now known as lukasa_away [11:05] jamespage, would you mind taking another look pls? [11:08] gnuoy, +1 === lukasa_away is now known as lukasa [11:12] jamespage, thanks [12:22] jamespage, got a sec for https://code.launchpad.net/~gnuoy/charms/trusty/nova-compute/1496746/+merge/271451 ? Mainly just a charmhelper sync plus setting the new set_shmmax [13:03] anyone know of a charm with amulet tests that test the upgrade step from previous version of the charm? [13:06] I can just install from the charmstore, right? Like cs:trusty/gunicorn-0 ? [14:45] jose: marcoceppi: lazypower: Any chance you could have a look at the merge I linked about? [14:45] There's also https://code.launchpad.net/~cjwatson/charms/trusty/ubuntu-repository-cache/inline-release/+merge/271107 [14:54] Odd_Bloke: I think they're sprinting today so might be slow to respond [14:56] rick_h_: Ah, thanks for the heads up. [14:56] I'll try in all caps in a bit, I'm sure that'll help. ;) [14:57] Odd_Bloke: wfm :) [14:59] Odd_Bloke: lazypower says that he'll take a look later today and merge, we're in a summit right now [15:00] jose: lazypower: <3 thanks. [15:00] thanks to you! [15:08] thedac, can you tip the video down a bit [15:08] thehi [15:08] thedac, hi (is what I meant [15:08] hi [15:08] hey, this is aditya [15:10] thedac, question sounds like its about branching strategy? [15:10] yes [15:11] You also have options when you branch a charm. bzr branch lp:charms/trusty/$CHARM [15:13] thedac, this https://github.com/openstack-charmers is probably waht the charms will look like once migrated to git [15:14] I have a question very specific to openstack neutron - the subordinate charm for DHCP and L3 agent is deployed on the controller node (the neutron-api / gateway). [15:14] now, is there a way to deploy this on the compute node instead? (at scale, the controller node becomes a bottleneck when VMs are brought up and it requests DHCP and L3). so i would like to disable DHCP and L3 on controller and enable it only on compute. (or enable it on all nodes) [15:14] 15.10 [15:14] thanks [15:15] thedac, we'll switchover once we release from bzr [15:15] wolverineav, not at the moment. You can have dhcp and metadata on the compute nodes but only if the gateway is not deployed [15:15] probably [15:16] neutron-gateway would always have to be deployed, right? [15:16] wolverineav, right [15:16] jamespage: is the hangout public? [15:16] probably not [15:16] wolverineav, you can use DVR t oreduce traffic through the gateway [15:16] wolverineav, erm not sure that's accurate [15:18] fwiw the link quality isn't good enough to follow everything that's being said [15:19] we've got some people here that want to screen share so can we switch to a public hangout so they can be invited? [15:19] or how else should we accomplish this? [15:19] I'm happy to switch [15:19] jamesbeedy@gmail.com [15:20] ah, so the bottleneck I'm talking about is pre-DVR [15:20] I haven't tried it with DVR enabled. === skaro is now known as Guest38173 [15:28] wolverineav, https://git.launchpad.net/~sdn-charmers/charms/+source/openvswitch-odl/tree/ [15:30] wolverineav, http://bazaar.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk/view/head:/bundles/ovs-odl/ovs-odl.yaml [15:33] are you guys seeing the juju-gui jamespage gnuoy ? He's got a full openstack deployment but juju-gui is not displaying any charms [15:33] we've got mbruzek helping him but it's pretty bazaar [15:34] I see the gui, not sure whats causing the issue though [15:35] ddellav: gui issue? hatch can help if you need a hand with something. [15:36] hello [15:36] hey hatch we have a charm partner that's having issues with the gui [15:37] he has the gui deployed to an lxc container alongside a full openstack deployment but the gui is showing no charms or machines [15:37] it previously worked but in the last few weeks it started doing this [15:38] ddellav: can you get them to open the browser console to see if there are any errors? [15:38] also, do they still have to log into the gui? (it didn't get switched to sandbox mode by accident?) [15:39] hatch: he does log in [15:39] hatch, no errors in the browser console [15:40] hmm [15:40] and the `juju status` in the cli shows the gui? [15:40] Yes as well as the rest of the openstack deploy [15:41] ok give me a moment to think about this one :) [15:41] sure. One other point is this is a MAAS deploy [15:42] thedac: which browser are they using? [15:42] chrome [15:42] Merlijn_S: Welcome. https://jujucharms.com/docs/devel/authors-charm-composing [15:42] ddellav: thedac ok I'm going to investigate locally here and will get back to you [15:42] cory_fu: Thanks [15:43] hatch: thanks [15:45] tvansteenburgh1: http://juju-ci.vapour.ws:8080/view/Juju%20Ecosystem/job/charm-bundle-test-aws/735/console is looking promising. Formatting a little off with the update, but close enough. [15:45] thedac, coreycb: for those interested - https://review.openstack.org/#/c/224797/ [15:45] gnuoy, ^^ [15:46] pulled my finger out [15:46] jamespage, tip top. thanks [15:47] stub: \o/ [15:47] jamespage, when do you think we'll have base charms available for SDN charm composing? === tvansteenburgh1 is now known as tvansteenburgh [15:48] wolverineav, https://jujucharms.com/docs/devel/authors-charm-composing [15:48] coreycb, context? [15:48] coreycb, probably this month [15:48] need to make some time [15:48] thanks hatch [15:48] stub: i have some follow-up questions/comments to your latest remarks, but will get to those later today. thanks for taking the time [15:48] jamespage, I'm chatting with wolverineav from big switch and showing him the odl charm [15:48] coreycb, right [15:50] hatch, not sure if this helps but here's a screenshot: http://cl.ly/image/2z1F3Y100I12 [15:51] ddellav: very odd, thanks - I'm just spinning up a local env here to see if I can reproduce [15:54] ddellav: can you check `juju get juju-gui` and look for the 'sandbox' property value [15:58] wolsen, dosaboy, Tribaal: https://review.openstack.org/#/c/224797/2 [15:58] hatch: http://paste.ubuntu.com/12438918/ [15:59] hatch, bdx is the user with the gui issue, he's pasted that output you wanted [15:59] ahh alright [15:59] yeah so this is very weird [16:01] hatch, can you let us know the best place to submit a bug report for this issue? [16:01] bdx: ddellav https://bugs.launchpad.net/juju-gui [16:01] but this shouldn't be possible :) [16:03] love those impossible bugs haha [16:03] bdx: can you run `app.env.getAttrs()` [16:04] it shouldn't contain any sensitive information, just take a look before pasting [16:05] bdx: does the machine view show your other maas machines? have you tried to deploy something? If you deploy a simple charm via the gui, like say Ghost, does it deploy as expected? [16:05] ddellav: yeah I could see this happening if there was some exception raised, but with no errors in the browser console it's quite odd [16:05] hatch: no, the juju-gui shows no sign of anything from my juju env. [16:06] omp [16:09] hatch: I don't know how you want this formatted: http://paste.ubuntu.com/12438981/ [16:10] or I don't know how to get it into a better format [16:10] :) no that's fine [16:10] thanks [16:11] bdx: and the ip of your bootstrap node is 10.16.100.73? [16:11] hatch: .73 is my juju-gui [16:12] ahh alright, so bdx what I would recommend trying is destroying this instance and deploying a new one [16:12] it appears that the connection between the GUI and your bootstrap node has somehow become broken [16:15] bdx: are you able to destroy/deploy the GUI to see if it resolves? [16:24] hatch: he has destroyed and redeployed several times. Same result. [16:24] he is at lunch at the moment [16:24] understood [16:24] ok [16:26] maybe the best case would be to file a bug...the issue is that the gui server is not able to communicate with the bootstrap node to get the environment details [16:26] so we need to surface that error [16:26] as there isn't anything the GUI can do to resolve it [16:41] hatch: I am working with bdx on this problem. [16:41] We will file a bug on this when he returns from lunch. [16:42] hatch: I had him destroy the service and redeploy with the same result. The juju status shows all the deployed units, but the gui does not. [16:42] mbruzek: great thanks - The only way I was able to reproduce was to block the gui server from accessing the bootstrap node [16:43] so I'm assuming that there is something from the guiserver > bootstrap node which is blocking that communication [16:44] We did find an error in the web browser console a connection problem. [16:44] ahh there we go [16:44] Is there anything else that I can check. [16:44] did you happen to copy it somewhere I could see the error? [16:44] He is still at lunch [16:44] mbruzek: well the GUI thinks that it's connected [16:45] So ssh to the gui and see if I can ping the bootstrap node? [16:45] mbruzek: yeah that would be a good place to start [16:45] also, if there is an error in the console that might explain it [17:01] jamespage: woot! on it [17:15] Odd_Bloke, o/ [17:15] having a look now [17:18] lazypower: Yo! Thanks! [17:19] Odd_Bloke, this merge makes me a little sad but I understand why its necessary [17:19] Odd_Bloke, did you run into instances where this code was not being run on >= 1.23.2 [17:19] lazypower: The problem is that other parts of the code assume that 'lowest numbered == leader'. [17:20] ah [17:20] was this the only merge? or was there another one? [17:21] lazypower: So, for example, unit 0 would go "I'm not the leader, I don't need to sync stuff down" and other units would still try to sync from unit 0. [17:21] Proofs to tier 1 reset currency: 806.52 Qa / 1.18 Qt (+3.89 Qa Proofs/tick) [17:21] Proofs to tier 1 reset currency: 806.52 Qa / 1.18 Qt (+3.89 Qa Proofs/tick) [17:21] NICE [17:21] https://code.launchpad.net/~cjwatson/charms/trusty/ubuntu-repository-cache/inline-release/+merge/271107 [17:21] lazypower: ^ [17:21] Odd_Bloke, yeah, that makes sense that the rest of the charm would need to be updated to us leader-set receivers on where they should sync from [17:22] lazypower: Yeah, precisely. [17:22] Odd_Bloke, as the leader may change in flight over the course of the lifetime [17:22] *service lifecycle [17:22] Yeah. [17:22] So we do have a way of coping with the leader changing, but it isn't plumbed in to the leader election stuff yet. [17:23] yeah this works for me as a conceptual fix until proper leader election bits can be landed [17:23] (And, actually, given the response on that hook bug earlier, it might actually never get called.) [17:23] OK, great! [17:29] Odd_Bloke, not suree what should be done to the bug triage here if anything. https://bugs.launchpad.net/launchpad/+bug/804252 [17:29] Bug #804252: Please support InRelease files [17:29] i'm going to head back into the charmer summit. Ping if you need anything else [17:29] o/ [17:30] lazypower: I'll just let cjwatson know. :) [18:48] mbruzek: hey, any luck? === zz_CyberJacob is now known as CyberJacob [19:03] hatch: whats up [19:06] hatch: so what I was able to ascertain about the juju-gui not showing env issue is that.... it doesn't look like it is requesting to the bootstrap node....it seems to be requesting to itself....http://cl.ly/image/2q001V0F3v1o [19:07] 10.16.100.73 is the address of the juju-gui [19:07] 10.16.100.151 is the ip of the bootstrap node [19:09] bdx: ok thanks, I'll look into that code to see if I can figure out why it might be doing that [19:09] awesome, thanks [19:20] bdx: what version of juju are you using? [19:20] the gui used to work then just stopped? Can you remember any changes to the env made around that time? [19:20] the issue appears to be with the gui's websocket connection to the gui's server === urulama is now known as urulama__ === CyberJacob is now known as zz_CyberJacob