| === 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 | ||
| jamespage | gnuoy, https://code.launchpad.net/~james-page/charms/trusty/nova-compute/lp1509267-stable/+merge/278286 | 08:45 |
|---|---|---|
| gnuoy | +1 | 08:46 |
| 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> | 08:59 |
| === mhall119|fossetc is now known as mhall119 | ||
| Icey | exporting a bundle through juju-gui doesn't export added storage? | 15:13 |
| === jacekn_ is now known as jacekn | ||
| === luqas is now known as lezbar | ||
| marcoceppi | Icey: storage isn't in the bundle format AFAIK | 16:15 |
| marcoceppi | rick_h_: ^? | 16:15 |
| 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:19 |
| 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:20 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| mwenning | marcoceppi, yes it is on git hub, but I'm using one that I've downloaded & modified | 16:26 |
| 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:28 |
| 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:29 |
| mwenning | marcoceppi, tvansteenburgh , will amulet work in windows? that's probably the next thing | 16:30 |
| 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:31 |
| marcoceppi | there's a lot of unknowns here, you're trail blazing a bit here ;) | 16:32 |
| mwenning | marcoceppi, :-) | 16:32 |
| 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:37 |
| 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:38 |
| frankban | rick_h_: export from the GUI? Jeff is working on adding storage to the GUI | 16:39 |
| rick_h_ | frankban: ok | 16:39 |
| marcoceppi | cory_fu: I've got some justifications for the update-status hook | 16:57 |
| 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:58 |
| 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 | 16:59 |
| marcoceppi | cory_fu: should I mail the list about including this? | 17:00 |
| cory_fu | Probably worth doing, yes | 17:00 |
| marcoceppi | cory_fu: cool, I'll drop a line today | 17:01 |
| 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:03 |
| marcoceppi | cory_fu: ah, I see, leveraging states more | 17:04 |
| marcoceppi | I like, I need to set/react to more states in general. I'm a little sparse in my layers to date | 17:05 |
| 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:06 |
| cory_fu | Agreed, we need to support actions | 17:09 |
| marcoceppi | cory_fu: is there a way to do something like `psql.changed()` to see if relation data has changed? | 17:15 |
| marcoceppi | cory_fu: nvm, I can just use states | 17:20 |
| === Spads_ is now known as Spads | ||
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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 | 17:30 |
| === Spads_ is now known as Spads | ||
| marcoceppi | jose: can you send along good examples of tasks? | 18:08 |
| jose | marcoceppi: Code In Sample Tasks (https://docs.google.com/document/d/1povliHCv-_5AuTdRtrs-AJTZBbyNhufZYs_bykuALHA/edit?usp=docslist_api) | 18:11 |
| 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:14 |
| 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:23 |
| 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:30 |
| 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:32 |
| jrwren | i'm going back to bed. | 18:33 |
| arosales | marcoceppi +1 on meeting up, perhaps post us holiday though | 19:03 |
| marcoceppi | arosales: well we have 14 days before they're due ;) | 19:05 |
| 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:06 |
| * marcoceppi dunno | 19:07 | |
| === urulama is now known as urulama__ | ||
| 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:12 |
| jrwren | beisner: thanks for the replies and this msg. I'll update the test to poll. | 21:14 |
| beisner | jrwren, awesome. thanks! | 21:15 |
| tvansteenburgh | jrwren, i'm curious what you willing be checking for in the polling loop | 21:16 |
| 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:20 |
| tvansteenburgh | i assume what you have in mind is specific to the mongodb charm? | 21:21 |
| 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:22 |
| 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 | 21:23 |
| adam_g | spinning my wheels trying to bootstrap a manually provisioned container: http://paste.openstack.org/show/479791/ any ideas? | 22:07 |
| marcoceppi | thumper: lp:~ubucon-site-developers/ubucon-site/ubucon-layer and https://github.com/marcoceppi/layer-django | 23:35 |
| 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:36 | |
| 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:42 |
| 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:43 |
| 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:44 |
| blr | I'm almost entirely ignorant of the changes in the reactive framework... our charms just use charmhelpers | 23:45 |
| 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:46 |
| blr | marcoceppi: does this compliment the services framework, or is it orthogonal? | 23:50 |
| 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:51 |
| marcoceppi | blr: well, I don't know if refactor is the right word | 23:53 |
| marcoceppi | blr: I think new charms going forward should be in reactive | 23:54 |
| marcoceppi | but services framework is still valid | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!