[08:45] <jamespage> gnuoy, https://code.launchpad.net/~james-page/charms/trusty/nova-compute/lp1509267-stable/+merge/278286
[08:46] <gnuoy> +1
[08:59] <jamespage> gnuoy, https://bugs.launchpad.net/charms/+source/nova-compute/+bug/1518771
[08:59] <jamespage> ?
[08:59] <mup> Bug #1518771: nova-compute hugepages breaks the boot process <upstart :New> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1518771>
[15:13] <Icey> exporting a bundle through juju-gui doesn't export added storage?
[16:15] <marcoceppi> Icey: storage isn't in the bundle format AFAIK
[16:15] <marcoceppi> rick_h_: ^?
[16:19] <tvansteenburgh> marcoceppi: suggestions on this? https://bugs.launchpad.net/charms/+bug/1513612
[16:19] <mup> Bug #1513612: HyperV lis-test Charm <Juju Charms Collection:New> <https://launchpad.net/bugs/1513612>
[16:20] <marcoceppi> 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] <marcoceppi> that charm really only works right now on a MAAS enabled substrate with a Windows image baked in
[16:20] <mwenning> marcoceppi, how should I proceed then?
[16:20] <marcoceppi> tvansteenburgh: we need to probably blacklist LXC/LXD with charms in the windows series
[16:22] <marcoceppi> 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] <mwenning> 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] <marcoceppi> mwenning: sure, we need to get that into our charm-testing infrastructure so we can validate windows charms
[16:23] <marcoceppi> we've not had many go through our pipeline :)
[16:24] <marcoceppi> 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] <mwenning> 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] <mwenning> should I re-do this as a "fat charm" & include it?
[16:25] <mwenning> seems like it would be easier to control
[16:25] <marcoceppi> mwenning: is the zip accessible on the internet?
[16:26] <mwenning> marcoceppi, yes it is on git hub, but I'm using one that I've downloaded & modified
[16:28] <mwenning> marcoceppi, sorry the _zip_ is not accessible, source is.
[16:28] <marcoceppi> mwenning: you could fat-pack it, if it's not easily accessible from the public internet
[16:29] <mwenning> 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] <mwenning> marcoceppi, tvansteenburgh , will amulet work in windows?   that's probably the next thing
[16:31] <marcoceppi> 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] <marcoceppi> there's a lot of unknowns here, you're trail blazing a bit here ;)
[16:32] <mwenning> marcoceppi, :-)
[16:37] <rick_h_> 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] <rick_h_> marcoceppi: Icey but once that lands a gui release will have to be cut to support exporting it.
[16:37] <rick_h_> urulama: hatch fyi ^
[16:38] <frankban> rick_h_: yes storage is being added to bundlechanges and to the bundle format
[16:38] <rick_h_> frankban: and will export support that or do we need a card for that to get updated as well?
[16:38] <rick_h_> frankban: or the bundlechanges support adds the export as well?
[16:39] <frankban> rick_h_: export from the GUI? Jeff is working on adding storage to the GUI
[16:39] <rick_h_> frankban: ok
[16:57] <marcoceppi> cory_fu: I've got some justifications for the update-status hook
[16:58] <cory_fu> 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] <marcoceppi> cory_fu: they should have smarter handlers ;)
[16:59] <marcoceppi> this is what I'm trying to do, as an fyi: http://paste.ubuntu.com/13477912/
[16:59] <marcoceppi> 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] <cory_fu> 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] <marcoceppi> cory_fu: should I mail the list about including this?
[17:00] <cory_fu> Probably worth doing, yes
[17:01] <marcoceppi> cory_fu: cool, I'll drop a line today
[17:03] <cory_fu> 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] <marcoceppi> cory_fu: ohh, I'd love to, I've been trying to find a simple way to do this
[17:04] <marcoceppi> cory_fu: ah, I see, leveraging states more
[17:05] <marcoceppi> I like, I need to set/react to more states in general. I'm a little sparse in my layers to date
[17:06] <marcoceppi> cory_fu: I'll refactor my django layer a bit to use this approach
[17:06] <marcoceppi> cory_fu: I have a use case for actions in reactive too
[17:06] <marcoceppi> well, s/use case/need/
[17:09] <cory_fu> Agreed, we need to support actions
[17:15] <marcoceppi> cory_fu: is there a way to do something like `psql.changed()` to see if relation data has changed?
[17:20] <marcoceppi> cory_fu: nvm, I can just use states
[17:26] <jose> arosales, marcoceppi: hey! I wanted to confirm if you guys wanted to be mentors for Google Code-In
[17:26] <marcoceppi> jose: yes
[17:27] <cory_fu> marcoceppi: Were are you talking about setting the "changed" state from?  The charm layer?
[17:27] <jose> marcoceppi: ok, you're getting a PM to confirm something real quick and we'll get this rolling
[17:27] <arosales> jose: yes +1 :-)
[17:28] <marcoceppi> cory_fu: I was referring to postgresql recieving changed data, but I just realized I don't care that much
[17:28] <jose> woot woot! same for you!
[17:28] <marcoceppi> since the tinerface takes care of that
[17:29] <cory_fu> 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] <marcoceppi> cory_fu: yeah, I found a better way around what I was trying to work though
[17:30] <cory_fu> 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
[18:08] <marcoceppi> jose: can you send along good examples of tasks?
[18:11] <jose> marcoceppi: Code In Sample Tasks (https://docs.google.com/document/d/1povliHCv-_5AuTdRtrs-AJTZBbyNhufZYs_bykuALHA/edit?usp=docslist_api)
[18:14] <marcoceppi> 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] <jose> marcoceppi: those were just samples of things we do written in task format
[18:23] <marcoceppi> jose: ack, cool
[18:23] <marcoceppi> jose arosales we should meet up to discuss, to avoid building duplicate tasks?
[18:30] <jrwren> 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] <marcoceppi> jrwren: yes it does http://bazaar.launchpad.net/~evarlast/charms/trusty/apache2/add-logs-interface/view/head:/Makefile
[18:32] <jrwren> ok, something is very broken on my end. thanks.
[18:33] <jrwren> i'm going back to bed.
[19:03] <arosales> marcoceppi +1 on meeting up, perhaps post us holiday though
[19:05] <marcoceppi> arosales: well we have 14 days before they're due ;)
[19:06] <arosales> marcoceppi, ah well then :-)
[19:06] <arosales> I guess sooner rather than later
[19:06] <arosales> 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
[21:12] <beisner> 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] <mup> Bug #1518468: mongodb functional tests have race condition due to fixed sleep time <amulet> <uosci> <mongodb (Juju Charms Collection):New> <https://launchpad.net/bugs/1518468>
[21:14] <jrwren> beisner: thanks for the replies and this msg. I'll update the test to poll.
[21:15] <beisner> jrwren, awesome.  thanks!
[21:16] <tvansteenburgh> jrwren, i'm curious what you willing be checking for in the polling loop
[21:20] <tvansteenburgh> 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] <tvansteenburgh> i assume what you have in mind is specific to the mongodb charm?
[21:22] <jrwren> tvansteenburgh: i'll poll every 10s until some max timeout.
[21:22] <jrwren> 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] <tvansteenburgh> 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] <tvansteenburgh> jrwren: ah, i see
[22:07] <adam_g> spinning my wheels trying to bootstrap a manually provisioned container: http://paste.openstack.org/show/479791/ any ideas?
[23:35] <marcoceppi> thumper: lp:~ubucon-site-developers/ubucon-site/ubucon-layer and https://github.com/marcoceppi/layer-django
[23:36] <marcoceppi> 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] <marcoceppi> 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] <thumper> marcoceppi: I'd have to compare with what I currently deploy
[23:43] <thumper> I have a python-django charm that starts celery workers when related to rabbitmq
[23:43] <marcoceppi> thumper: yeah, I know you're doing a pretty expansive deployment
[23:43] <thumper> I haven't proposed it yet...
[23:44] <thumper> but my focus hasn't been charm development, but site development
[23:44] <thumper> I'd love it to be more useful...
[23:44] <marcoceppi> thumper: yeah, totally understand
[23:44] <blr> marcoceppi: is there some documentation somewhere on what layers provide?
[23:44] <marcoceppi> blr: not sure I understand what you mean
[23:45] <blr> I'm almost entirely ignorant of the changes in the reactive framework... our charms just use charmhelpers
[23:46] <marcoceppi> blr: so each layer provides it's own set of events it creates/reacts to
[23:46] <marcoceppi> they're typically documented in the readme
[23:50] <blr> marcoceppi: does this compliment the services framework, or is it orthogonal?
[23:51] <marcoceppi> blr: it replaces, services framework is still valid but reactive is the evolution of it
[23:51] <blr> right okay... so we should probably look at refactoring our charms.
[23:53] <marcoceppi> blr: well, I don't know if refactor is the right word
[23:54] <marcoceppi> blr: I think new charms going forward should be in reactive
[23:54] <marcoceppi> but services framework is still valid