| niemeyer | Aaaaand, that's it.. lbox is ready for inline reviews on Launchpad. | 02:36 |
|---|---|---|
| niemeyer | Now, package and docs.. | 02:36 |
| hazmat | niemeyer, nice | 02:46 |
| hazmat | SpamapS, thanks for doing the bug weeding | 03:05 |
| noodles775 | Hi, any reason why I'd start seeing the following on juju units? http://paste.ubuntu.com/741073/ | 11:26 |
| * noodles775 checks the mail list for api changes. | 11:26 | |
| noodles775 | seems JUJU_AGENT_SOCKET is no longer set? | 11:27 |
| hazmat | noodles775, the juju cli api is only setup for automatic usage from a hook or a debug hook terminal.. other uses need to setup variables to connect to the remote end | 12:17 |
| hazmat | we should probably default these though to their common known values | 12:18 |
| fwereade | hazmat, may I borrow you for a quick pre-review? | 12:25 |
| fwereade | hazmat, http://paste.ubuntu.com/741112/ has the changes I've made for upstartification; they're verified but not yet tested and I wanted to check if there were any serious issues before I go too much further | 12:26 |
| fwereade | hazmat, the first 270 lines are the important ones, the rest are consequential changes to test data | 12:26 |
| fwereade | bbs lunch | 12:29 |
| === mainerror_ is now known as mainerror | ||
| rog | niemeyer: mornin' | 13:28 |
| mainerror | Hello. | 13:29 |
| hazmat | fwereade, functionally it looks fine, except the stop handling needs better, i'm still wondering if it wouldn't be better served by a more complete abstraction of upstart config | 13:30 |
| hazmat | er .. stop needs error handling | 13:30 |
| fwereade | hazmat, good point re stop | 13:31 |
| hazmat | some of the use cases are pretty general purpose outside of existing agents, starting containers, zookeeper, webservers.. etc. | 13:31 |
| fwereade | hazmat, I'm reluctant to do that until those use cases are actually in play | 13:32 |
| fwereade | hazmat, although that makes me think | 13:32 |
| hazmat | fwereade, those cases exist now, and could be simplified via upstart | 13:32 |
| fwereade | hazmat, actually no it doesn't | 13:32 |
| hazmat | fwereade, much of the local provider code is really just process management stuff that could go away | 13:32 |
| fwereade | hazmat, ah, ok, I haven't really dug very deep into that | 13:33 |
| fwereade | hazmat, I'll poke around for further opportunities to use it then, better abstraction should come from that quite naturally | 13:33 |
| fwereade | hazmat, thanks | 13:34 |
| hazmat | fwereade, a straight conversion of http://upstart.ubuntu.com/cookbook/#id119 would look alike the bootstrap, with a **kw constructor for convience | 13:35 |
| hazmat | its not a direct 1-1 | 13:35 |
| hazmat | but it would cover all our use cases | 13:36 |
| hazmat | maybe | 13:36 |
| niemeyer | rog: Yo | 13:36 |
| hazmat | well definitely.. but not clear we really need it | 13:36 |
| niemeyer | hazmat, fwereade: Mornings as well | 13:37 |
| hazmat | niemeyer, greetings | 13:37 |
| niemeyer | fwereade: Well, aft. for you :) | 13:37 |
| fwereade | hi niemeyer | 13:37 |
| fwereade | (details, details) | 13:37 |
| niemeyer | rog: Thanks for the log.. I think there's much better heuristic I can use to find out the proper URLs | 13:37 |
| niemeyer | rog: I'll try that now | 13:37 |
| rog | niemeyer: cool. | 13:42 |
| jcastro | hazmat: nice graphs, <3 | 14:27 |
| * niemeyer => lunch | 15:18 | |
| * mpl <- cookies | 15:34 | |
| mpl | :) | 15:34 |
| fwereade | hey guys, cath's stuck in the lift and laura is somewhat distraught, back later | 16:23 |
| niemeyer | fwereade: Ouch | 16:26 |
| SpamapS | https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-juju-charm-testing | 17:24 |
| SpamapS | This has the juju team as the drafter.. | 17:24 |
| SpamapS | I went ahead and added a few work items that I think will be part of it, but it would be good for somebody from the juju team to review them and change the Definition from Discussion to Review once that is done. | 17:25 |
| niemeyer | rog: Alright, I think I'm done with lbox.. | 18:01 |
| rog | niemeyer: yay! | 18:01 |
| niemeyer | Unfortunately codereview seems down for maintenance.. *now* from all times | 18:01 |
| rog | niemeyer: damn, i remember it was announced. | 18:02 |
| niemeyer | rog: The heuristics are much better now | 18:02 |
| niemeyer | Simpler too.. | 18:02 |
| rog | niemeyer: good. nothing like someone actually using some heuristics to sort 'em out... | 18:02 |
| niemeyer | rog: Yeah, definitely | 18:02 |
| === wckd_ is now known as wckd | ||
| rog | niemeyer: BTW currently i'm trying to get one of the simplest tests in ec2 to run against my test server. | 18:03 |
| niemeyer | rog: Cool, that's awesome | 18:03 |
| rog | niemeyer: it's by no means awesome yet :-) | 18:04 |
| niemeyer | rog: Ugh :) | 18:04 |
| rog | niemeyer: and the code is grungy | 18:04 |
| rog | niemeyer: here's a current snapshot of the server code: http://paste.ubuntu.com/741436/ | 18:05 |
| niemeyer | rog: This is quite involved already | 18:07 |
| rog | niemeyer: all it does currently is allow a client to induce a failure (FailNow) and to inspect the set of actions afterwards. | 18:07 |
| rog | niemeyer: i know, i'm not entirely happy | 18:07 |
| rog | niemeyer: i can't think of a way of making it simpler though, while keeping our current approach | 18:07 |
| niemeyer | rog: I mean, even in terms of features | 18:07 |
| niemeyer | rog: We should be able to have a simpler test case that doesn't involve all of those calls | 18:08 |
| niemeyer | rog: To get started | 18:08 |
| niemeyer | rog: E.g. whatever call reads the machine state | 18:08 |
| rog | niemeyer: most of those calls are currently unimplemented | 18:08 |
| rog | niemeyer: i was after getting instance starting and stopping working | 18:09 |
| niemeyer | rog: The overall direction looks interesting, though | 18:09 |
| rog | niemeyer: i need DescribeInstances and then i think i'll have enough for a juju machine | 18:10 |
| niemeyer | rog: // Address returns the URI of the server. | 18:10 |
| niemeyer | rog: I wonder about this one | 18:10 |
| rog | niemeyer: is that a problem? | 18:11 |
| niemeyer | rog: It feels useful for sure | 18:11 |
| rog | niemeyer: i don't want to clash with other potential services | 18:11 |
| niemeyer | rog: But we can't expose that to the tests, otherwise we're binding them to a particular implementation | 18:11 |
| jcastro | m_3: ~45 minutes until that call | 18:11 |
| niemeyer | rog: The backend semantics may need multiple URLs, etc | 18:11 |
| rog | niemeyer: i don't think so - we just make an environments.yaml that includes that string | 18:11 |
| niemeyer | rog: Right, something like that should be cool | 18:12 |
| rog | actually, we allow registration of a new region | 18:12 |
| rog | which includes the url | 18:12 |
| niemeyer | rog: FailNext may not be enough.. | 18:12 |
| niemeyer | rog: interactions will generally take several roundtrips | 18:13 |
| rog | niemeyer: yeah, it's just my placeholder for whatever is needed | 18:13 |
| niemeyer | rog: The first one may not be interesting to fail | 18:13 |
| rog | niemeyer: it's enough for my first test | 18:13 |
| niemeyer | rog: Cool | 18:13 |
| niemeyer | rog: +1 | 18:13 |
| niemeyer | rog: Looks nice overall | 18:13 |
| rog | niemeyer: but in general it's an interesting question | 18:13 |
| rog | niemeyer: the testing code can't know how many requests will be generated | 18:13 |
| niemeyer | rog: Some nastiness will go away when Go is fixed | 18:13 |
| niemeyer | Go's xml, that is | 18:14 |
| niemeyer | rog: That's right | 18:14 |
| niemeyer | rog: We'll need to think through that one a bit | 18:14 |
| rog | niemeyer: yeah, i think xml could do with a thorough rethink | 18:14 |
| niemeyer | rog: It sounds like failure scenarios are too bound to the backend | 18:14 |
| rog | niemeyer: yes | 18:15 |
| niemeyer | rog: We'll probably need a richer interface on the fake server, and provider-specific tests | 18:15 |
| niemeyer | rog: Otherwise we'll be spending years on that framework creating something extremely involved | 18:15 |
| rog | niemeyer: for example ec2 generates errors in a particular form | 18:15 |
| niemeyer | rog: yeah, and on particular calls, etc | 18:15 |
| rog | niemeyer: hmm. a possible idea: | 18:16 |
| rog | niemeyer: given that hardly any code reacts to the actual content of an error | 18:16 |
| rog | niemeyer: and that most of the stuff we're testing will be single threaded and therefore deterministic | 18:16 |
| niemeyer | rog: Both of these assumptions don't seem necessarily valid, FWIW | 18:17 |
| rog | niemeyer: you could have a scheme where you run a test once, record the number of operations, then run it again several times failing at a different place each time | 18:17 |
| rog | true.. | 18:17 |
| niemeyer | rog: See the "spending years" comment above.. :) | 18:17 |
| rog | yeah | 18:18 |
| rog | hmm. anyway, i think the important thing is the constructive tests. | 18:20 |
| rog | we can do provider specific tests for provider specific error scenarios | 18:20 |
| jcastro | yep | 18:23 |
| niemeyer | rog: Agreed | 18:25 |
| m_3 | petecheslock: great talking to you guys again... I'll get portertech some examples | 19:48 |
| petecheslock | m_3: sounds great - we're excited to bring sensu to more automation platforms. | 19:48 |
| hazmat | this is cool http://news.opensuse.org/wp-content/uploads/2011/11/snapper.png | 20:21 |
| hazmat | btrfs snapshot visualization | 20:21 |
| hazmat | imagine hooks doing btrfs snapshots, with introspectable diffs | 20:22 |
| hazmat | not quite dry run, but a different level of introspection | 20:22 |
| jrgifford | i do **not** need to do `sudo juju bootstrap`, correct? | 20:48 |
| jrgifford | just a normal juju boostrap, from my normal user? | 20:48 |
| m_3 | jrgifford: correct, ordinary user | 20:57 |
| marcoceppi | jrgifford o/ | 20:57 |
| jrgifford | m_3: thanks | 20:58 |
| jrgifford | marcoceppi: ? | 21:00 |
| mainerror | He meant that there is no such thing as a normal user since it would imply the existence of an abnormal user which doesn't make sense. :) | 22:01 |
| portertech | due to being a ruby whore, I require ruby to be present in order to write my hooks in ruby | 22:51 |
| portertech | is there a common solution in this case, for charms? | 22:51 |
| portertech | check if installed, if not, install, a ruby charm out in the wild? | 22:52 |
| portertech | just do an apt-get install then? ;) | 22:53 |
| brunopereira81 | hello, I need some help setting up a install script for a juju charm | 22:54 |
| jrgifford | portertech: hey, another ruby charmer. :P | 22:59 |
| jrgifford | i was actually wondering the same thing... | 23:00 |
| fwereade | portertech, an apt-get install in your install hook should be fine | 23:00 |
| fwereade | brunopereira81, I'll help if I can, but I know a lot more about the code than about the charms | 23:00 |
| portertech | jrgifford fwereade: yeah, doing a quick which & $? to determine if it's present, installing if not, then go have a ruby party | 23:00 |
| fwereade | portertech, perfect | 23:01 |
| jrgifford | portertech: thanks for the suggestion | 23:01 |
| brunopereira81 | fwereade, I think I got it, thx | 23:01 |
| fwereade | brunopereira81, cool | 23:01 |
| portertech | tricky way: [[ ! `which ruby` ]] && apt-get -y install ruby | 23:04 |
| portertech | so is the install hook the default? what's the standard way to call another hook from it? | 23:05 |
| brunopereira81 | I have a config.yaml file in my charm folder, how can I read an key from it to use in my install hook? | 23:10 |
| portertech | fwereade: would I "$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"/ruby_hook from within the install hook? | 23:15 |
| portertech | must be a sexy way of doing it | 23:15 |
| fwereade | sorry guys, distracted | 23:15 |
| fwereade | you should be able to get your config stuff via relation-get | 23:17 |
| fwereade | which is available to all relation-related hooks | 23:18 |
| brunopereira81 | so for instance if I want to get a token string from my config.yaml i just need call 'relation-get token'? | 23:20 |
| fwereade | brunopereira81, sorry, needed to refamiliarise myself | 23:21 |
| fwereade | that should be config-get | 23:21 |
| fwereade | and that should be available in all your hooks including start and install (which aren't anything to do with relations) | 23:21 |
| brunopereira81 | fwereade, thx | 23:22 |
| fwereade | sorry brainfart :) | 23:22 |
| brunopereira81 | lol, np | 23:22 |
| fwereade | portertech, my bash-fu is weak :) | 23:23 |
| fwereade | portertech, as a suggestion, you *probably* don't need to do a great deal of work in the install hook; and if the install hook is just a bunch of "apt-get install"s, subsequent hooks (like start) can just be ruby | 23:24 |
| portertech | yeah, since install only runs once | 23:25 |
| portertech | nothing special | 23:25 |
| fwereade | portertech, indeed, you'll get an "install" and a "start" and then it's all about the relations | 23:25 |
| fwereade | oh, I think there's a config-changed one as well, let me check | 23:26 |
| fwereade | yep, it's "config-changed" | 23:26 |
| portertech | does anyone use facter or ohai w/ there charms? :P | 23:29 |
| portertech | where a large amount of system info is required | 23:29 |
| fwereade | portertech, we're very deliberately agnostic about what tools you use within the hooks | 23:30 |
| fwereade | portertech, I don't know for sure what people are using though | 23:30 |
| portertech | lots of freedom | 23:31 |
| portertech | i dig it | 23:31 |
| fwereade | :D | 23:31 |
| * hazmat catches up | 23:33 | |
| SpamapS | portertech: yes there are charms that use facter already | 23:34 |
| brunopereira81 | after creating a charm what is the easiest way to test it? | 23:34 |
| SpamapS | portertech: btw, for the "run another hook" case I use this | 23:34 |
| SpamapS | home=`dirname $0` | 23:34 |
| SpamapS | $home/hookname | 23:34 |
| hazmat | $CHARM_DIR is defined as well | 23:34 |
| portertech | SpamapS: cool | 23:34 |
| * SpamapS is all about self reliance :) | 23:35 | |
| * SpamapS heads off to do some of the wife's bidding | 23:36 | |
| brunopereira81 | (nvm, found how) | 23:36 |
| hazmat | most of these formulas use facter.. http://charms.kapilt.com/~negronjl | 23:37 |
| hazmat | albeit just as a k/v store, which could be done with just about any tool.. | 23:37 |
| _mup_ | Bug #891868 was filed: juju cli api should be invokable outside of units <juju:New> < https://launchpad.net/bugs/891868 > | 23:39 |
| portertech | hazmat: is $CHARM_DIR the current charm dir absolute path? | 23:42 |
| portertech | or just a user specified var | 23:43 |
| m_3 | portertech: that's the charm path (/var/lib/juju/units/<unit-name>/charm/ on the deployed nodes) | 23:49 |
| portertech | m_3: ah, ok, thanks | 23:50 |
| m_3 | and CWD druing hook exec | 23:50 |
| m_3 | I usually just use relative | 23:50 |
| m_3 | portertech: incidentally when debugging... /var/lib/juju/units/<unit-name>/charm.log is useful (along with /var/log/juju/unit-agent.log) | 23:51 |
| m_3 | (from memory, but something like that) | 23:52 |
| portertech | so if i call another script in the current dir from within install, i could do $CHARM_DIR/script? | 23:53 |
| portertech | or ./ | 23:53 |
| m_3 | I guess I use [[ -f "$(dirname $0)/common.sh" ]] && source "$(dirname $0)/common.sh" | 23:55 |
| m_3 | but that's probably easier with CHARM_DIR now | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
