=== Spads_ is now known as Spads === CyberJacob is now known as zz_CyberJacob === zz_CyberJacob is now known as CyberJacob === axino` is now known as axino [08:45] gnuoy, https://code.launchpad.net/~james-page/charms/trusty/nova-compute/lp1509267-stable/+merge/278286 [08:46] +1 [08:59] gnuoy, https://bugs.launchpad.net/charms/+source/nova-compute/+bug/1518771 [08:59] ? [08:59] Bug #1518771: nova-compute hugepages breaks the boot process

=== mhall119|fossetc is now known as mhall119 [15:13] exporting a bundle through juju-gui doesn't export added storage? === jacekn_ is now known as jacekn === luqas is now known as lezbar [16:15] Icey: storage isn't in the bundle format AFAIK [16:15] rick_h_: ^? [16:19] marcoceppi: suggestions on this? https://bugs.launchpad.net/charms/+bug/1513612 [16:19] Bug #1513612: HyperV lis-test Charm [16:20] tvansteenburgh: we can't really test it with the automated testing because we don't have a windows machine in our CI and we don't have simplestreams for Windows deployments [16:20] that charm really only works right now on a MAAS enabled substrate with a Windows image baked in [16:20] marcoceppi, how should I proceed then? [16:20] tvansteenburgh: we need to probably blacklist LXC/LXD with charms in the windows series [16:22] mwenning: I'm not sure. We should review the code as normal, if possible. But testing is the best way for us to be sure it works. I'll see if we can get a windows enabled substrate for the test runner [16:23] marcoceppi, the OIL team has a windows image that will deploy (from blake_r). That's what I've bee using to develop [16:23] mwenning: sure, we need to get that into our charm-testing infrastructure so we can validate windows charms [16:23] we've not had many go through our pipeline :) [16:24] mwenning: for the time being I have a maas and might be able to load the windows image on there to test this one off [16:24] * marcoceppi looks into how we can get resources to test this [16:24] marcoceppi, tvansteenburgh , also had a question (in the bug) - this charm requires a download of ~6M zip file containing the lis-test code. [16:25] should I re-do this as a "fat charm" & include it? [16:25] seems like it would be easier to control [16:25] mwenning: is the zip accessible on the internet? [16:26] marcoceppi, yes it is on git hub, but I'm using one that I've downloaded & modified [16:28] marcoceppi, sorry the _zip_ is not accessible, source is. [16:28] mwenning: you could fat-pack it, if it's not easily accessible from the public internet [16:29] marcoceppi, cool I'd prefer that, easier to control new versions. Also it's going in OIL and they don't like outside downloads [16:30] marcoceppi, tvansteenburgh , will amulet work in windows? that's probably the next thing [16:31] mwenning: amulet is python, Python can be installed in Windows, it should work. However, I'm not sure how juju-run/juju ssh work in a Windows environment [16:32] there's a lot of unknowns here, you're trail blazing a bit here ;) [16:32] marcoceppi, :-) [16:37] marcoceppi: Icey I think there's work underway to add it. axw was doing something and frankban was reviewing it if I recall [16:37] marcoceppi: Icey but once that lands a gui release will have to be cut to support exporting it. [16:37] urulama: hatch fyi ^ [16:38] rick_h_: yes storage is being added to bundlechanges and to the bundle format [16:38] frankban: and will export support that or do we need a card for that to get updated as well? [16:38] frankban: or the bundlechanges support adds the export as well? [16:39] rick_h_: export from the GUI? Jeff is working on adding storage to the GUI [16:39] frankban: ok [16:57] cory_fu: I've got some justifications for the update-status hook [16:58] FYI, in case I wasn't clear before, I'm for including the update-status hook, I just don't want anyone to be surprised when their handlers run every 5 minutes [16:59] cory_fu: they should have smarter handlers ;) [16:59] this is what I'm trying to do, as an fyi: http://paste.ubuntu.com/13477912/ [16:59] since there's so many different layers at play, each method just calls update_status() at the end of it's run atm [16:59] Agreed. And having them re-run every 5 minutes has actually been really helpful for me when developing and having my charms get into a blocked state that I needed to resolve just by re-running a hook w/o changing any config [17:00] cory_fu: should I mail the list about including this? [17:00] Probably worth doing, yes [17:01] cory_fu: cool, I'll drop a line today [17:03] marcoceppi: I'd also like you to compare how we're handling the status logic in https://github.com/johnsca/layer-apache-spark/blob/master/reactive/spark.py and https://github.com/ktsakalozos/layered-hive-charm/blob/master/reactive/hive.py to your approach [17:03] cory_fu: ohh, I'd love to, I've been trying to find a simple way to do this [17:04] cory_fu: ah, I see, leveraging states more [17:05] I like, I need to set/react to more states in general. I'm a little sparse in my layers to date [17:06] cory_fu: I'll refactor my django layer a bit to use this approach [17:06] cory_fu: I have a use case for actions in reactive too [17:06] well, s/use case/need/ [17:09] Agreed, we need to support actions [17:15] cory_fu: is there a way to do something like `psql.changed()` to see if relation data has changed? [17:20] cory_fu: nvm, I can just use states === Spads_ is now known as Spads [17:26] arosales, marcoceppi: hey! I wanted to confirm if you guys wanted to be mentors for Google Code-In [17:26] jose: yes [17:27] marcoceppi: Were are you talking about setting the "changed" state from? The charm layer? [17:27] marcoceppi: ok, you're getting a PM to confirm something real quick and we'll get this rolling [17:27] jose: yes +1 :-) [17:28] cory_fu: I was referring to postgresql recieving changed data, but I just realized I don't care that much [17:28] woot woot! same for you! [17:28] since the tinerface takes care of that [17:29] marcoceppi: Right. The interface should handle changes and turn them into appropriate states. But you also shouldn't expect a "db.changed" state or similar from an interface layer (nor try to create one) because it almost certainly won't work the way you expect (I know from experience) [17:30] cory_fu: yeah, I found a better way around what I was trying to work though [17:30] marcoceppi: If you do need to track changes in data, though, you can use https://pythonhosted.org/charms.reactive/charms.reactive.helpers.html#charms.reactive.helpers.data_changed === Spads_ is now known as Spads [18:08] jose: can you send along good examples of tasks? [18:11] marcoceppi: Code In Sample Tasks (https://docs.google.com/document/d/1povliHCv-_5AuTdRtrs-AJTZBbyNhufZYs_bykuALHA/edit?usp=docslist_api) [18:14] jose arosales I really don't think we want to encourage a charm review as a task? Not sure the scope of this though [18:23] marcoceppi: those were just samples of things we do written in task format [18:23] jose: ack, cool [18:23] jose arosales we should meet up to discuss, to avoid building duplicate tasks? [18:30] can someone help me understand some failing test output? http://juju-ci.vapour.ws:8080/job/charm-bundle-test-lxc/1485/console I see a make -s lint and make -s test being run, but the charm doesn't have a Makefile. what is happening? [18:32] jrwren: yes it does http://bazaar.launchpad.net/~evarlast/charms/trusty/apache2/add-logs-interface/view/head:/Makefile [18:32] ok, something is very broken on my end. thanks. [18:33] i'm going back to bed. [19:03] marcoceppi +1 on meeting up, perhaps post us holiday though [19:05] arosales: well we have 14 days before they're due ;) [19:06] marcoceppi, ah well then :-) [19:06] I guess sooner rather than later [19:06] marcoceppi: my first thought is failing charm test triage or picking a few charms we know need some tlc, or is that to deep of a task? [19:07] * marcoceppi dunno === urulama is now known as urulama__ [21:12] hi jrwren, tvansteenburgh - looks like we are all hitting the same mongodb test race. in my observation, when everything is just right, and under low-load, the tests will generally pass. but the sleep time is really just a bug in itself, and the tests will need to be more clever about knowing when to start poking. re: bug 1518468 [21:12] Bug #1518468: mongodb functional tests have race condition due to fixed sleep time [21:14] beisner: thanks for the replies and this msg. I'll update the test to poll. [21:15] jrwren, awesome. thanks! [21:16] jrwren, i'm curious what you willing be checking for in the polling loop [21:20] i ask because amulet's sentry.wait() already does this in a non-charm-specific way, waiting for every unit to quiesce (no running hooks) for at least 30 seconds [21:21] i assume what you have in mind is specific to the mongodb charm? [21:22] tvansteenburgh: i'll poll every 10s until some max timeout. [21:22] tvansteenburgh: I'm unsure, but I think the issue is not juju and something sentry.wait() would trigger, but mongodb and its replset choosing a primary [21:23] fwiw, i think the most correct way forward is to do what beisner suggested and have the charm implement extended status to advertise when it is ready, then use amulet's sentry.wait_for_messages() to block until that status is set. but i realize that may not be a feasible change to make right now [21:23] jrwren: ah, i see [22:07] spinning my wheels trying to bootstrap a manually provisioned container: http://paste.openstack.org/show/479791/ any ideas? [23:35] thumper: lp:~ubucon-site-developers/ubucon-site/ubucon-layer and https://github.com/marcoceppi/layer-django [23:36] thumper: zero to no documentation yet, the first branch is what a consumer of the django layer looks like and the second is the actual guts of it [23:36] * thumper nods [23:42] thumper: I've charmed ubucon site and and working on taiga which is also django. Trying to make the layer as useful as possible [23:43] marcoceppi: I'd have to compare with what I currently deploy [23:43] I have a python-django charm that starts celery workers when related to rabbitmq [23:43] thumper: yeah, I know you're doing a pretty expansive deployment [23:43] I haven't proposed it yet... [23:44] but my focus hasn't been charm development, but site development [23:44] I'd love it to be more useful... [23:44] thumper: yeah, totally understand [23:44] marcoceppi: is there some documentation somewhere on what layers provide? [23:44] blr: not sure I understand what you mean [23:45] I'm almost entirely ignorant of the changes in the reactive framework... our charms just use charmhelpers [23:46] blr: so each layer provides it's own set of events it creates/reacts to [23:46] they're typically documented in the readme [23:50] marcoceppi: does this compliment the services framework, or is it orthogonal? [23:51] blr: it replaces, services framework is still valid but reactive is the evolution of it [23:51] right okay... so we should probably look at refactoring our charms. [23:53] blr: well, I don't know if refactor is the right word [23:54] blr: I think new charms going forward should be in reactive [23:54] but services framework is still valid