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