| SpamapS | hazmat: anyway, I have some other stuff to wrap up so I'm punting the upload until later tonight or tomorrow morning. | 00:00 |
|---|---|---|
| SpamapS | hazmat: would be great if I could re-enable that test then though. | 00:00 |
| hazmat | SpamapS, cool, thanks, i'm still looking. i haven't played with this part of the codebase in a while. still trying to understand the interaction. | 00:01 |
| hazmat | with the path information the error comes out as .. | 00:01 |
| hazmat | Failure: zookeeper.ClosingException: zookeeper is closing /units/unit-0000000000 | 00:01 |
| hazmat | why the unit is being touched at all is not clear | 00:01 |
| niemeyer | hazmat: Checking it out | 00:02 |
| niemeyer | hazmat: Very nice | 00:03 |
| niemeyer | hazmat: I suggest adding a colon here: | 00:03 |
| niemeyer | + error_msg += " %s" % path | 00:03 |
| niemeyer | error_msg += ": %s" % path | 00:03 |
| niemeyer | hazmat: +1 either way | 00:03 |
| hazmat | niemeyer, sounds good, i'm wondering now, if it should also have the op name | 00:03 |
| hazmat | like it would be nice to know what was happening here when the client was interacting with the unit state and zk closed | 00:04 |
| niemeyer | hazmat: Not sure.. I'd hope the error message + the traceback would make that clear | 00:04 |
| hazmat | twisted traceback is a general fail | 00:04 |
| niemeyer | hazmat: Hmm, true | 00:04 |
| hazmat | when the reactor is involved between call and result | 00:05 |
| hazmat | sometimes it works | 00:05 |
| niemeyer | hazmat: "%s %s: %s" % (op, path, msg) | 00:05 |
| niemeyer | hazmat: sound sgood | 00:05 |
| hazmat | yeah | 00:05 |
| hazmat | cool | 00:05 |
| SpamapS | is it possible there needs to be some kind of wait after some operation done earlier? | 00:05 |
| niemeyer | hazmat: as in "stat /foo/bar: blah blah" | 00:05 |
| hazmat | SpamapS, typically in the past its because there's a watch reset | 00:06 |
| hazmat | while the test is closing.. but here | 00:06 |
| hazmat | i can't think of any reason there'd be interaction with unit state node | 00:06 |
| hazmat | as part of hook execution | 00:07 |
| hazmat | oh.. unless its a workflow state change | 00:07 |
| hazmat | aha | 00:07 |
| hazmat | but config hooks don't modify workflow state.. | 00:08 |
| * hazmat tries to go back to rambling silently | 00:08 | |
| SpamapS | riveting, really | 00:09 |
| * SpamapS pushes back for a bit | 00:09 | |
| hazmat | ah.. that's the problem | 00:09 |
| hazmat | we started doing config-changed before start | 00:10 |
| hazmat | in addition to when it actually changed | 00:10 |
| hazmat | maybe | 00:10 |
| hazmat | nope.. the tests waits for start to complete before modifying the config | 00:14 |
| _mup_ | juju/ftests-new r4 committed by gustavo@niemeyer.net | 01:10 |
| _mup_ | A number of improvements, making ftests actually work for real: | 01:10 |
| _mup_ | - Prepare environment for tests to run juju | 01:10 |
| _mup_ | - Implemented support for test setup/teardown. | 01:10 |
| _mup_ | - Added ec2-wordpress test and relevant setup/teardown. | 01:10 |
| _mup_ | - Added unittests test. | 01:10 |
| _mup_ | - Other trivial stuff (changed file names, README, etc) | 01:10 |
| hazmat | so the op is get on the unit state when zk is closing | 01:12 |
| niemeyer | bcsaller: ping | 01:34 |
| bcsaller | niemeyer: hey | 01:34 |
| niemeyer | bcsaller: Hey! | 01:34 |
| niemeyer | bcsaller: Just having a last look in lxc-omega | 01:34 |
| niemeyer | bcsaller: What's this about: | 01:34 |
| niemeyer | +hostname=`ip -f inet addr |grep 192.168| grep -v '192\.168\.1\.' | awk '{print $2;}'|cut -f 1 -d '/'` | 01:34 |
| bcsaller | kapil and I were just talking through what I think is the last test failure there | 01:34 |
| bcsaller | niemeyer: you can use a name like bcsaller-laptop-wordpress-0 if you change resolv.conf | 01:35 |
| bcsaller | but we don't want to change the host level networking | 01:35 |
| bcsaller | so we went back to getting the ips and passing those to the relations | 01:35 |
| bcsaller | they can find eachother either way | 01:36 |
| hazmat | niemeyer, we can change back to something that will use hostname on those platfroms that support it when we add something like `unit-info --public-address` | 01:36 |
| bcsaller | but the host can't address the wordpress node by its symbolic name w/o the change | 01:36 |
| hazmat | else we end up with something that we can't resolve in the browser by name, and if we use ip, we hit the wrong vhost in apache | 01:37 |
| niemeyer | bcsaller: Besides looking very cryptic (not sure why all the greps and awks are needed there), doesn't that mean the example formulas won't work on ec2 anymore? | 01:37 |
| hazmat | sigh.. it does | 01:37 |
| hazmat | i guess i need to make unit-info happen tomorrow | 01:38 |
| niemeyer | Now that we just got http://wtf.labix.org/ working! ;-) | 01:38 |
| hazmat | still no luck in tracking down this bug SpamapS reported | 01:38 |
| hazmat | i don't see anything doing a 'get' op on the unit state | 01:38 |
| niemeyer | hazmat: Either that or injecting the ip.. not sure about what would be easier | 01:39 |
| niemeyer | hazmat: Injecting the ip has the advantage that we can maintain it automatically in the future | 01:39 |
| niemeyer | Well, somewhat | 01:40 |
| hazmat | niemeyer, injecting the ec2 public ip ? | 01:40 |
| hazmat | that needs the md server | 01:40 |
| hazmat | and charm specifivity to the provider | 01:40 |
| hazmat | awareness at least | 01:40 |
| niemeyer | hazmat: That's the internal ip, I think | 01:40 |
| niemeyer | hazmat: I mean, the one used in the relations | 01:40 |
| hazmat | niemeyer, yeah.. i was just going to inject the private address into all unit relation nodes | 01:41 |
| hazmat | but that doesn't help here | 01:41 |
| niemeyer | hazmat: For that line above I think it does | 01:42 |
| niemeyer | hazmat: It's replacing the internal ip trick | 01:43 |
| niemeyer | hazmat: There's another one that may not help | 01:43 |
| _mup_ | juju/lxc-omega-base r364 committed by gustavo@niemeyer.net | 01:45 |
| _mup_ | Preparing lxc-omega-base for review of lxc-omega. | 01:45 |
| hazmat | niemeyer, hmm... so instead it would grab its own address from the relation data | 01:46 |
| hazmat | yeah.. that works | 01:46 |
| niemeyer | hazmat: Its own address? I think the only reason it gets its own address is to provide to the other side, isn't it? | 01:47 |
| hazmat | niemeyer, not in this case | 01:47 |
| * niemeyer reads the example charms again | 01:47 | |
| hazmat | its setting up its own address for an apache vhost | 01:47 |
| niemeyer | hazmat: It is | 01:48 |
| niemeyer | relation-set database="$service" user="$service" password="$service_password" host="$hostname" | 01:48 |
| niemeyer | hazmat: These are the only places where the value is used | 01:48 |
| niemeyer | hazmat: In db-config-joined | 01:48 |
| * niemeyer looks at another one | 01:48 | |
| niemeyer | ServerName is an interesting one.. I think this needs hostname support or similar | 01:51 |
| niemeyer | hazmat: Yeah, I think that's the only case there | 01:52 |
| niemeyer | There's a bogus one as well | 01:52 |
| niemeyer | -hostname=`curl http://169.254.169.254/latest/meta-data/public-hostname` | 01:52 |
| niemeyer | +hostname=`ip -f inet addr |grep 192.168| grep -v '192\.168\.1\.' | awk '{print $2;}'|cut -f 1 -d '/'` | 01:52 |
| niemeyer | This isn't going to work I believe.. it's replacing the hostname by an ip | 01:53 |
| hazmat | niemeyer, it will work | 01:57 |
| hazmat | its still a valid server name | 01:57 |
| niemeyer | hazmat: How come? | 01:57 |
| hazmat | because an ip is a valid address for the server | 01:57 |
| hazmat | which is what the servername needs | 01:57 |
| niemeyer | hazmat: config-changed and db-relation-changed in wordpress disagree on the content | 01:57 |
| niemeyer | hazmat: I don't think that's generally the case.. if the server is a virtual server, the ip doesn't resolve properly | 01:58 |
| niemeyer | hazmat: and then config-changed and db-relation-changed disagree with each other either way | 01:58 |
| hazmat | the ip isn't used for resolving (its the server) its used for matching a vhost against the host heaader which works fine | 01:58 |
| niemeyer | hazmat: "Additionally, ServerName is used (possibly in conjunction with ServerAlias) to uniquely identify a virtual host, when using name-based virtual hosts. | 02:00 |
| niemeyer | " | 02:00 |
| hazmat | indeed | 02:00 |
| hazmat | but given a unit usage its not really germane afaics | 02:00 |
| hazmat | we can't alias to the ip even though it would match, since the redirect goes to the name which is non routable | 02:01 |
| hazmat | in the local provider case | 02:01 |
| hazmat | and the apache is dedicated to the unit | 02:01 |
| niemeyer | hazmat: and then | 02:01 |
| niemeyer | ln -s /usr/share/wordpress "/var/www/$hostname" | 02:01 |
| hazmat | so the ip serves as a unique identifier to the named vhost | 02:01 |
| niemeyer | hazmat: That points to a different path than what config-changed points to | 02:02 |
| niemeyer | hazmat: I'm really confused about how that could possibly work | 02:02 |
| hazmat | ugh.. yeah.. that needs to be fixed | 02:02 |
| hazmat | bcsaller, you've tried out with the ip based addressing? | 02:02 |
| bcsaller | niemeyer: in that case there might be an error in the config hook post the change back to ip | 02:02 |
| bcsaller | hazmat: I had tested it yesterday, yes | 02:02 |
| hazmat | i'm going to head out.. its been a long day.. have fun folks | 02:03 |
| bcsaller | but never set the config setting | 02:03 |
| niemeyer | hazmat: Enjoy the resting! | 02:04 |
| niemeyer | hazmat: are you off yet? Had a quick question | 02:06 |
| niemeyer | bcsaller: Just sent a (probably last) review | 02:16 |
| niemeyer | bcsaller: I suggest reverting the example changes so we can get lxc-omega in sooner | 02:16 |
| niemeyer | I'll step out for the day too | 02:17 |
| niemeyer | Have a good time all | 02:17 |
| bcsaller | niemeyer: and recommending the host level resolv.conf change? | 02:17 |
| hazmat | niemeyer shoot | 03:01 |
| hazmat | too late | 03:01 |
| hazmat | bcsaller, yeah.. that's fine for now, i don't see an alternative till we have tools that expose provider specific addresses better | 03:13 |
| hazmat | re revert to host | 03:13 |
| hazmat | name | 03:13 |
| bcsaller | k | 03:14 |
| _mup_ | juju/env-origin r367 committed by jim.baker@canonical.com | 03:28 |
| _mup_ | Removed code path going through get_default_origin in tests that do not need this; began refactoring of get_default_origin for its own separate testing | 03:28 |
| hazmat | think i've got this error nailed SpamapS | 03:42 |
| hazmat | its unfortunate though | 03:43 |
| hazmat | some very small percentage of the runs the second config hook seems to run and complete b4 the workflow state has been fully recorded for the initial transition | 03:46 |
| SpamapS | hazmat: sounds like its a real error and there's some lack of synchronization going on. | 03:49 |
| _mup_ | juju/env-origin r368 committed by jim.baker@canonical.com | 04:04 |
| _mup_ | Inline generation of alt apt-cache script in test | 04:04 |
| hazmat | its still not clear to me how its possible, even though async my understanding is we'd get back results in execution order | 04:13 |
| hazmat | perhaps not | 04:13 |
| hazmat | ah ic | 04:20 |
| hazmat | reconfigure does a circle state transition | 04:23 |
| hazmat | and we just wait on the hook execution, but the state transition is still happening | 04:24 |
| hazmat | after the hook | 04:24 |
| hazmat | i can probably just optimize away the state transition when cur state == next state | 04:24 |
| hazmat | although state variables may have changed | 04:24 |
| hazmat | er. optimize the storage of the new state | 04:28 |
| hazmat | yeah.. that seems to work without ill effects | 04:29 |
| hazmat | SpamapS, its not a real error, but it is a lack of sync as regards the test | 04:30 |
| hazmat | the options are put the sync into the test, or obviate away the need for the sync, since in this case the additional activity is superflous to the overall state | 04:31 |
| hazmat | we have quite a few circular transitions, transitions from a state that lead back to the same state | 04:31 |
| hazmat | both work well | 04:32 |
| hazmat | probably safer to add the sync in | 04:35 |
| hazmat | the other works well but has implication on state variables becoming stale, which we only use for error states | 04:35 |
| hazmat | something to sleep on | 04:36 |
| _mup_ | juju/env-origin r369 committed by jim.baker@canonical.com | 04:48 |
| _mup_ | Parse tests | 04:48 |
| _mup_ | juju/env-origin r370 committed by jim.baker@canonical.com | 04:49 |
| _mup_ | Removed unnecessary files | 04:49 |
| _mup_ | juju/env-origin r371 committed by jim.baker@canonical.com | 04:53 |
| _mup_ | PEP8 | 04:53 |
| _mup_ | juju/env-origin r372 committed by jim.baker@canonical.com | 05:22 |
| _mup_ | Docs and additional test suggested by doc revision | 05:22 |
| _mup_ | juju/env-origin r373 committed by jim.baker@canonical.com | 05:25 |
| _mup_ | Merged trunk | 05:25 |
| _mup_ | Bug #861225 was filed: Unit relations should be prepopulated with the unit address <juju:In Progress by hazmat> < https://launchpad.net/bugs/861225 > | 08:27 |
| _mup_ | Bug #861376 was filed: cannot download charms from remote repositories <juju:New> < https://launchpad.net/bugs/861376 > | 12:42 |
| jamespage | hi all | 14:24 |
| jamespage | is there a nice way that I can pickup provider information from within a charm | 14:24 |
| jamespage | I have a couple that can optimize for running in/out of ec2 for example | 14:24 |
| jamespage | I could pass it as config - but that does not feel like good juju :-) | 14:25 |
| rog | is niemeyer around today? | 15:11 |
| jimbaker | rog, niemeyer is at the brazilian python conference today & tomorrow | 15:13 |
| jimbaker | http://www.pythonbrasil.org.br/ | 15:15 |
| rog | jimbaker: thanks. i'll just have to keep on with destroying his zk interface then... | 15:18 |
| jimbaker | rog, sounds like a good plan! | 15:18 |
| jimbaker | rog, so how do things change in zk interface 2.0 ? | 15:19 |
| rog | jimbaker: i'll show you a paste of the current godoc output for it if you like | 15:22 |
| jimbaker | rog, cool, thanks | 15:22 |
| rog | jimbaker: http://paste.ubuntu.com/698558/ | 15:24 |
| rog | jimbaker: the Server stuff is new. the event changes i've just made and think they're a good thing, but Gustavo may easily think they're horrible :-) | 15:25 |
| jimbaker | rog, re Server, sounds nice. so now i understand your interest in log4j/the managed zk in python. it will be good to look at this code, since managing processes properly (especially misbehaved ones) will be important for porting to juju | 15:29 |
| hazmat | jamespage what sort of provider info | 15:30 |
| rog | jimbaker: it doesn't do much managing - though perhaps it should. it assumes that it takes a single process only. | 15:31 |
| jamespage | hazmat: for example, tomcat7 has some neat automagic clustering features - but they rely on multicast | 15:31 |
| jamespage | so they don't work in ec2 - but no reason why they would not if the charm was deployed on hardware or another cloud type | 15:32 |
| jamespage | or Cassandra as a snitch which sets up the ring based on ec2 avaliability zones for example | 15:32 |
| jamespage | but you would not run the same thing outside of ec2 | 15:32 |
| hazmat | jamespage, good stuff | 15:33 |
| hazmat | jamespage, we'll be introducing some mechanisms for units to get additional about their environment | 15:33 |
| jimbaker | rog, does the Exec package ensure that any pending output to stderr/stdout is flushed and available? just curious, since this as bitten us in terms of distinguishing - we could see a program exit before all output was ready | 15:36 |
| rog | jimbaker: if you read from stderr or stdout, you read until eof. program exit is independent of that. | 15:40 |
| jimbaker | rog, cool, that's what i would expect | 15:40 |
| rog | so the best course would be to read all the output, then wait for the program | 15:40 |
| jimbaker | rog, exactly what we do now in hook invocation, except we also need to timeout. that's a lot easier to do (and test) in go, of course, so looking forward to that | 15:41 |
| rog | jimbaker: hmm, looks like exec.Output is flawed in that respect. | 15:42 |
| jimbaker | rog, hmm... the reason this is important is that some executables are flawed in how they background (they don't properly daemonize), so the parent can exit, but children hold onto file descriptors | 15:43 |
| rog | yeah. it's not actually a possible problem to solve properly. | 15:44 |
| jimbaker | rog, can you characterize what the issues are with go for this problem? | 15:45 |
| jimbaker | because i would assume i could simply have a timeout participate in the select on the output channel. but i'm a complete go novice | 15:45 |
| SpamapS | Wow.. changing the default from _PPA to _DISTRO breaks about 16 tests. | 15:46 |
| jimbaker | SpamapS, it's no surprise to me | 15:46 |
| jimbaker | SpamapS, although env-origin is waiting for review again, i think it's ready. you might want to give it a try | 15:47 |
| SpamapS | I think a few of them might be a little too broad in scope | 15:47 |
| jimbaker | SpamapS, those tests are assuming that a ppa will be installed by cloud init, and so are looking for that in the corresponding cloud init yaml | 15:48 |
| SpamapS | yeah exactly, that seems heavy handed to me. | 15:48 |
| rog | jimbaker: a timeout is quite possible. but it's not a great solution - you either risk losing legitimate output or you introduce an artificial delay each time. | 15:48 |
| jimbaker | so they are being very fussy, but that's actually important | 15:48 |
| rog | jimbaker: there's no specific Go problem here, i think. | 15:48 |
| jimbaker | rog, this is for bad code. i don't know of any good options because of that | 15:48 |
| jimbaker | bad *external to us* code, that is | 15:49 |
| SpamapS | jimbaker: I tend to agree with that for full end-to-end integration tests.. but for unit tests.. if the individual bits are tested, I don't see why the whole has to be so rigid. | 15:49 |
| SpamapS | But, I digress | 15:49 |
| jimbaker | rog, so it sounds like go should work just fine. thanks for the feedback, it was very helpful! | 15:49 |
| SpamapS | I think I'll just upload w/o the DISTRO change, and we'll change it and turn off the test suite if we can't get the origin branch into 11.10 | 15:50 |
| jimbaker | SpamapS, sounds reasonable | 15:50 |
| rog | jimbaker: why do we have to stop reading the output from a program anyway? it's useful to keep collecting stdout/stderr - it might not be correctly being sent to a log file. | 15:51 |
| SpamapS | It can't ship w/ the PPA linking.. thats just not going to work.. but it can ship w/o the test suite. | 15:51 |
| jimbaker | although i do hope it makes it, because otherwise the ppa setting will not be user available there | 15:51 |
| jimbaker | ok, well that makes me feel better | 15:51 |
| SpamapS | jimbaker: if they want the PPA... they should.. use the PPA. ;) | 15:51 |
| jimbaker | SpamapS, a perfectly valid point | 15:51 |
| SpamapS | for the 0.001% of users who will be running juju without root on their own machines.. they can use juju-branch | 15:52 |
| rog | BTW, it seems that Output doesn't have the problem i thought it did. i did exec.Command("sh", "-c", "(sleep 3; echo hello) &").Output() and it waited for 3 seconds. | 15:53 |
| rog | dunno quite how it does it though. i'll look more closely. | 15:54 |
| jimbaker | rog, that's a good question, it seems more likely this is a test determinism issue that is bubbling up to how we do things | 15:54 |
| jimbaker | rog, so go allows us to change the parameters of this. it may be still desirable to wait around, but much less aggressively | 15:55 |
| rog | jimbaker: yeah. in fact for the purposes of this kind of thing, i'd prefer it if programs wrote log messages to stdout, because then they can be easily made available remotely, rather than having to delve into app-specific log files. | 15:58 |
| rog | but i'm not sure that's gonna happen in general | 15:59 |
| SpamapS | hazmat: is there a bug # for that test fail? I'd like to document it in the package so we can check on its progress and re-enable the test when it is fixed. | 15:59 |
| jimbaker | the precedent is certainly to do the daemonization + log to file, but for charms we are going the direction you suggest | 16:00 |
| hazmat | SpamapS, i'm just going to do the trivial fix on trunk doing the obvious thing, sync primitives for the test | 16:00 |
| rog | jimbaker: ah, i see how the exec package does it now. it's quite neat. | 16:01 |
| jimbaker | rog, ? | 16:01 |
| SpamapS | hazmat: ahh ok. Thanks! | 16:03 |
| rog | jimbaker: http://golang.org/src/pkg/exec/exec.go#L244 and one c.goroutine in this case is doing the io.Copy (until EOF), and c.Wait waits for the results of each goroutine. | 16:04 |
| _mup_ | Bug #861539 was filed: remote charm revision checking extremely inefficient <juju:In Progress> < https://launchpad.net/bugs/861539 > | 16:04 |
| hazmat | jimbaker, bcsaller, fwereade... could i get a +1 on this trivial.. http://paste.ubuntu.com/698569/ | 16:04 |
| rog | jimbaker: there's nothing to stop one doing a custom timeout too if that's desired | 16:04 |
| bcsaller | hazmat: lgtm | 16:05 |
| jimbaker | hazmat, +1 | 16:05 |
| hazmat | thanks guys | 16:06 |
| _mup_ | juju/trunk r364 committed by kapil.thangavelu@canonical.com | 16:09 |
| _mup_ | [trivial] fix config-changed test sync primitive to wait on workflow transition instead of hook execution.[r=bcsaller,jimbaker] | 16:09 |
| hazmat | SpamapS, that should fix it | 16:09 |
| SpamapS | hazmat: sweet thanks! | 16:16 |
| SpamapS | jimbaker: remind me again.. your new branch will set its origin based on where the 'juju' package came from, right? | 16:17 |
| jimbaker | SpamapS, correct | 16:17 |
| SpamapS | Cool. Really looking forward to testing that out soon. | 16:17 |
| SpamapS | SOON. :) | 16:17 |
| SpamapS | This actually makes perfect sense.. there has to be a 'juju' package in the archive before the distro method can even be tested. :) | 16:18 |
| jimbaker | or to use lp:juju, if installed from a branch. maybe it should use the actual branch, but this returns to what it was before | 16:18 |
| SpamapS | jimbaker: people using branches are on their own. :) | 16:18 |
| jimbaker | SpamapS, apparently we are ;) | 16:19 |
| jimbaker | SpamapS, correct about the distro dependency. i have pseudo mocked it (i could explain the distinction from using our standard mocker lib), but it waits until it gets in the distro before it can be truly tested | 16:20 |
| jimbaker | SpamapS, another outcome is that you do insist in environments.yaml that juju-origin be distro, you will get a unusable ec2 instance | 16:21 |
| jimbaker | until that change is made ;) | 16:21 |
| SpamapS | jimbaker: there's another way to test it which is to create an AMI that adds an apt source which has the package already. | 16:22 |
| jimbaker | SpamapS, ahh, stub it the other way. sounds good | 16:22 |
| SpamapS | jimbaker: better tho.. is to just have it in the distro. :) | 16:23 |
| SpamapS | I do think we may need to explore the idea that there's a need to be able to add arbitrary cloud-config data... | 16:24 |
| SpamapS | we can't possibly think of everything that people might want to do before juju starts. | 16:25 |
| jimbaker | SpamapS, that does make sense | 16:25 |
| SpamapS | But that may be too low level.. not sure. | 16:25 |
| rog | jimbaker: here's an example of a way you might do the timeout thing in Go | 16:26 |
| jimbaker | but at least it's centralized | 16:26 |
| rog | http://paste.ubuntu.com/698580/ | 16:26 |
| jimbaker | rog, thanks! | 16:27 |
| rog | jimbaker: and here's a version without the concurrent writer nastiness | 16:30 |
| rog | http://paste.ubuntu.com/698581/ | 16:30 |
| SpamapS | we need to add go to paste.ubuntu.com | 16:31 |
| rog | personally, i don't like syntax highlighting, so i'm not sad it's not there :-) | 16:34 |
| SpamapS | wow | 16:41 |
| SpamapS | I like, can't live without it anymore. | 16:41 |
| rog | i spent about 10 minutes earlier today working out how to turn it *off* in a diff tool i was using. i find it so distracting! | 16:43 |
| SpamapS | I think thats a global vs. details thing.. if you're global like me, it helps bring order to the big picture. if you're detail oriented, I can see where it would be distracting | 16:44 |
| jimbaker | at least there's the /plain option on the pastebin | 16:45 |
| jimbaker | but i prefer the syntax highlighting | 16:45 |
| rog | i think when the syntax is nice, the program structure itself is quite evident. the only caveat is long multi-line quoted strings, where i've been caught out before | 16:46 |
| rog | (but this is definitely a religious issue :-]) | 16:47 |
| SpamapS | rog: the best syntax formatting in the world just looks like a mass of gray gravy to me. :-P | 16:51 |
| SpamapS | I think this is less religious than editors and stuff.. its binary.. you like it or you don't. :) | 16:52 |
| === med_out is now known as medberry | ||
| Aram | hi. | 17:44 |
| Aram | so, niemeyer won't be here today? | 17:45 |
| Aram | regarding the syntax hilight thing above, don't care about it :-). | 17:46 |
| Aram | my editor doesn't support it. | 17:46 |
| adam_g | hey! so if a juju node (runnig a service unit, not the bootstrap node) reboots, what needs to be run to get juju back up and communicating with the bootstrap node so that future hooks execute? | 17:46 |
| SpamapS | adam_g: Thats actually a massive problem that has no good solution IIRC | 17:48 |
| adam_g | '' | 17:48 |
| SpamapS | adam_g: you can reconstruct the startup args from the cloud-init data | 17:48 |
| adam_g | SpamapS: thats what ive been trying to do | 17:49 |
| hazmat | well we can drop an upstart file down for the unit and machine agents | 17:49 |
| hazmat | which solves the structural issue | 17:49 |
| SpamapS | adam_g: hazmat has a better handle on this, but there's also a problem where any events that happened while the agent was gone will be missed | 17:49 |
| hazmat | the problem is we lose some state and end up with redundant and missed hook executions | 17:49 |
| adam_g | right | 17:49 |
| SpamapS | This is one of those production gotchyas of a critical nature. :-/ | 17:50 |
| hazmat | ie. we have some undefined behavior, till the unit agent suppor disk persistence | 17:50 |
| hazmat | its a very critical prod issue | 17:50 |
| adam_g | im just trying to reconstruct the services to a point where i can remove the relations and readd them, but so far those aren't even firing | 17:50 |
| SpamapS | hazmat: I still think you're better off making that persistence happen in zookeeper | 17:50 |
| hazmat | SpamapS, adam_g i didn't see any comments on the merge proposal for resurrect --placement, in the absence of that i'm going to let it drop | 17:50 |
| hazmat | SpamapS, true | 17:50 |
| SpamapS | hazmat: don't let it drop.. its desperately needed.. we're BUSY | 17:50 |
| adam_g | hazmat: ^ | 17:51 |
| hazmat | SpamapS, i need some firepower/reinforcements on it | 17:51 |
| SpamapS | hazmat: understood.. | 17:51 |
| hazmat | understood re busy | 17:51 |
| SpamapS | r361 is about to land in 11.10 btw | 17:51 |
| * rog is calling it a day. see ya tomorrow. | 17:52 | |
| hazmat | rog, have a good one | 17:52 |
| hazmat | SpamapS, my schedule is pretty clear outside of testing next week, i'll start addressing the restart issue then | 17:52 |
| SpamapS | hazmat: that would be pretty awesome. :) | 17:52 |
| SpamapS | adam_g: so I think right now the answer is "reinstall" ;) | 17:53 |
| adam_g | i know ive run into this before and got it to work after beating up the agents on every node | 17:54 |
| robbiew | bcsaller: hazmat: SpamapS: can one of you tell me how likely the LXC stuff will land in time for 11.10? or is it already too late, headed for SRU/PPA | 18:48 |
| hazmat | robbiew, i think we got the lost of the critical branches approved yesterday, we've got about 4 branches pending merges which can probably get done by end of day, that will at least allow usage, but their will be some usage caveats | 18:50 |
| robbiew | hazmat: ack | 18:50 |
| robbiew | thx | 18:50 |
| hazmat | bcsaller, can you go ahead and merge the lxc-lib-clone and omega? | 18:51 |
| hazmat | i guess i'm supposed to do another look at omega per the review comment | 18:51 |
| hazmat | bcsaller, it doesn't look like the fixes for the test failures have been pushed | 18:53 |
| hazmat | s/lost/most | 19:03 |
| hazmat | i'm going to head out in an hr to get to the conference | 19:09 |
| * hazmat heads out to the conference | 19:46 | |
| _mup_ | Bug #861821 was filed: setup.py needs to include some package_data <juju:New> < https://launchpad.net/bugs/861821 > | 20:56 |
| fwereade | bcsaller, hazmat, jimbaker: quick opinion | 21:13 |
| fwereade | __repr__ returning a string that isn't obviously a <FancyType object at 0xdeadbeef>, but still doesn't eval to the original object | 21:14 |
| fwereade | evil? | 21:14 |
| bcsaller | fwereade: something that __str__ can't do? | 21:15 |
| fwereade | bcsaller: hm, I may have wasted your time, I misread some context, it turns out the object in question will always be a str anyway | 21:17 |
| * fwereade looks embarrased | 21:17 | |
| fwereade | hazmat, jimbaker: ignore me | 21:17 |
| jimbaker | fwereade, no worries | 21:20 |
| jimbaker | but now that you mentioned repr vs str, i wonder if we have some lurking bugs with unicode | 21:21 |
| jimbaker | anyway, we will get to them. or perhaps not, go washes this issue away | 21:22 |
| jimbaker | fwereade, it's also possible that we can control the logging formatting process better - that's where of course i'm concerned | 21:23 |
| fwereade | jimbaker: that's a very nice point about go, and a very nice feature of go that hadn't really crossed my mental horizon | 21:24 |
| jimbaker | fwereade, yes, the standardization that everything is utf8 when serialized, that's the right one | 21:24 |
| fwereade | jimbaker: I'm sure we have some lurking unicode bugs, but most of the stuff I'm working with is rather restricted in character set anyway, so I don't *think* I'll be making anything worse, at least ;) | 21:24 |
| jimbaker | fwereade, yeah, if you can control those names. i'm thinking of charms with unicode paths, or stuff coming from environments.yaml | 21:25 |
| fwereade | jimbaker: unicode names are considered invalid ATM | 21:25 |
| fwereade | jimbaker: charm names | 21:26 |
| fwereade | jimbaker: environments.yaml scares me a lot more ;) | 21:26 |
| jimbaker | fwereade, so one test we could try is just to name an environment something in chinese. would juju break? | 21:26 |
| fwereade | jimbaker: probably :/ | 21:27 |
| niemeyer | Yo! | 21:42 |
| niemeyer | bcsaller: ping | 21:44 |
| bcsaller | niemeyer: hey | 21:44 |
| niemeyer | bcsaller: Heya | 21:44 |
| niemeyer | bcsaller: 365 seems to have broken trunk tests: http://wtf.labix.org/ | 21:44 |
| bcsaller | niemeyer: omega will fix that | 21:46 |
| bcsaller | its api drift from pre/post reqs | 21:46 |
| niemeyer | bcsaller: When is it going in? | 21:46 |
| bcsaller | still working on a test case thats causing issues, but soon | 21:46 |
| niemeyer | bcsaller: Ok.. having trunk broken is a big deal, so if it's going to take a while we need to fix the tests in trunk or revert the change | 21:48 |
| bcsaller | understood, but those features are useless, inaccessible and never used w/o the stuff in omega | 21:49 |
| bcsaller | and should be fixed soon | 21:49 |
| niemeyer | bcsaller: The point isn't that the features are useless, but just that we have trunk broken and other people cannot trust on the tests anymore | 21:51 |
| niemeyer | bcsaller: Such large changes should have a test run before committing, so that we never get in such a situation | 21:52 |
| bcsaller | I'd only been running the branch tests in isolation not thinking that some of the depends on the branch had been merged already | 21:52 |
| niemeyer | Hmm.. I'm going to link revision numbers to Launchpad in the wtf to be easier to follow it up | 21:53 |
| fwereade | niemeyer, wb | 21:55 |
| niemeyer | fwereade: Thanks! | 21:55 |
| niemeyer | fwereade: Sorry for the reviews chunked up | 21:55 |
| fwereade | niemeyer: np, much appreciated | 21:55 |
| fwereade | niemeyer: there's one quibble I have | 21:56 |
| fwereade | niemeyer: charm url/id | 21:56 |
| niemeyer | fwereade: I imagined ;) | 21:56 |
| fwereade | niemeyer: I'm fairly sure that a charm id is a *string* that can be parsed into a CharmURL with a revision | 21:56 |
| fwereade | niemeyer: if we pass CharmURLs throughout, we need to do a slightly annoying amount of str-ing/parsing when we yaml/unyaml them | 21:57 |
| niemeyer | fwereade: So is cs:~user/oneiric/wordpress-1 a charm URL, or is it not? | 21:57 |
| fwereade | niemeyer: it's a charm url, but not an instance of CharmURL | 21:57 |
| niemeyer | fwereade: Exactly | 21:57 |
| fwereade | niemeyer: does that make any sense? | 21:57 |
| niemeyer | fwereade: It does, and I agree.. | 21:57 |
| fwereade | niemeyer: cool :) | 21:57 |
| fwereade | niemeyer: so I feel that when we're workingwith charm ids, they should be strings | 21:58 |
| fwereade | niemeyer: when we need them to be urls, we can parse them | 21:58 |
| niemeyer | fwereade: The point I was making is just that a string representation of a charm url is still a charm url | 21:58 |
| fwereade | niemeyer: I'm happy about losing CharmIdError | 21:58 |
| niemeyer | fwereade: What's a charm id? | 21:59 |
| fwereade | niemeyer: it's a string, IMO, that parses to a CharmURL with a non-None revision | 21:59 |
| niemeyer | fwereade: If it's a string that parses into a charm url with a non None revision, it's simply a charm URL with a non-None revision | 22:00 |
| fwereade | niemeyer: I think we may be in violent agreement again then :) | 22:01 |
| fwereade | niemeyer: I have formed the impression, which may be mistaken, that you'd prefer to represent charm ids as CharmURL objects wherever possible | 22:01 |
| fwereade | niemeyer: is this correct? | 22:01 |
| niemeyer | fwereade: The only point of contention is that there's no reason to name this a "charm id".. it's already a charm url.. | 22:01 |
| niemeyer | fwereade: Yeah, I certainly think it'd be better to use charm urls throughout the code | 22:02 |
| fwereade | niemeyer: including string/parsing them when they go into and out of yaml when stored in zookeeper? | 22:03 |
| fwereade | niemeyer: ("str-ing/parsing" might be clearer) | 22:03 |
| hazmat | jimbaker the unicode issue isn't actually a problem for juju atm, its a problem when we interact with external systems like aws | 22:04 |
| niemeyer | fwereade: I hadn't thought about that, to be honest, but doesn't sound like a bad idea.. feels easy enough to have an internal schema time within juju.charm.url that would do that for us | 22:04 |
| niemeyer | fwereade: What do you think? | 22:04 |
| fwereade | niemeyer: I'm ambivalent: I tried it as part of the stuff I ended up reverting (with manual str-ing/parsing, and *that* was quite nice, but then having to explicitly str them again when do juju status felt wrong | 22:06 |
| niemeyer | fwereade: My main previous grip was about the distinct terminology for what is a single thing | 22:06 |
| niemeyer | fwereade: Hmm.. that sounds like a particularity of juju status only, and IIRC it's trivial to add support for stringifying them globally throught the yaml mechanics | 22:07 |
| niemeyer | through | 22:07 |
| fwereade | niemeyer: cool -- I'd got the impression that the occasional use of yaml.safe_dump was an explicit disavowal of that technique's legitimacy | 22:08 |
| niemeyer | fwereade: Hmm.. that's different | 22:08 |
| niemeyer | fwereade: I'm suggesting the precise opposite | 22:08 |
| niemeyer | fwereade: IOW, turning a charm url into a plain string | 22:08 |
| niemeyer | fwereade: safe_dump avoids dumping Python-specific information into the yaml output | 22:09 |
| niemeyer | fwereade: WIth all that said, I'm not specially concerned about this right now, to be honest | 22:09 |
| fwereade | niemeyer: indeed, I think I've derailed again :/ | 22:09 |
| niemeyer | fwereade: The only thing I'd like to reach agreement right now, and that impacts the branch, is the terminology and concepts we're agreeing to | 22:09 |
| niemeyer | fwereade: I want to kill the idea that cs:~user/series/foo-1 is both a url and an id, since it's the same thing | 22:10 |
| fwereade | niemeyer: yep, but cs:~user/series/foo is a url but not an id | 22:10 |
| fwereade | niemeyer: and therefore, IMO, there's a useful distinction to be maintained | 22:10 |
| niemeyer | fwereade: It's just a url, because there's no such thing as a charm id! :-) | 22:10 |
| niemeyer | fwereade: The former is a url with a revision.. the latter is a url without a revision | 22:11 |
| niemeyer | fwereade: Then, we can have curl.with_revision(n).. and curl.assert_revision().. | 22:11 |
| niemeyer | fwereade: To make the problem easier to deal with, if I understand your concerns | 22:11 |
| fwereade | niemeyer: that I'm 90% sure I like :) | 22:12 |
| fwereade | niemeyer: cool :) | 22:12 |
| niemeyer | fwereade: Woohay agreement! :-) | 22:13 |
| fwereade | niemeyer: and just to clarify: whenever we're loading yaml that contains a charm url, we pipe it through a schema that ensures it comes out the other side correctly | 22:13 |
| fwereade | niemeyer: and when we're yamling one, we automatically turn it into a string | 22:14 |
| niemeyer | fwereade: This _sounds_ like a good idea, but IMO it doesn't have to be done in that branch necessarily | 22:14 |
| niemeyer | fwereade: I don't know how much trouble it'd be to revise all code so that all charm urls are passes as objects rather than strings | 22:14 |
| * hazmat ponders | 22:15 | |
| hazmat | upgrade and deploy are the main ones | 22:15 |
| fwereade | niemeyer: it's not *that* much work to do it manually, and it does make some things simpler | 22:15 |
| niemeyer | fwereade: It sounds ok to have charm urls strings and values mixed up, and then clean it up as we go, in case you feel it would be painful | 22:15 |
| niemeyer | fwereade, hazmat: Cool, sounds awesome then | 22:15 |
| fwereade | niemeyer: but I'd rather get these branches put to bed in a *working* state asap | 22:16 |
| * hazmat goes back to practicing talk | 22:16 | |
| niemeyer | fwereade: I know that the schema coercer couldn't be more trivial since we already have parse.. | 22:16 |
| niemeyer | fwereade: +1! | 22:16 |
| hazmat | fwereade, so your talking about doing a custom yaml marshaller for charm urls? | 22:16 |
| fwereade | hazmat: yeah | 22:16 |
| niemeyer | http://wtf.labix.org/ is in a proper order, and has links to the revisions now.. | 22:16 |
| hazmat | fwereade, sounds good.. keeping safe_dump usage is also good, else pyyaml.. will take any random python object.. | 22:17 |
| fwereade | hazmat: I must have misread something -- I had the impression that safe_dump disallowed non-yaml-native types, even if there were custom marshallers | 22:18 |
| === Aram2 is now known as aram | ||
| === aram is now known as Aram | ||
| hazmat | fwereade, ah.. perhaps i'm not sure.. but without safe_dump.. it will pickle anything even without custom marshallers | 22:18 |
| fwereade | hazmat: I'll double-check and figure it out | 22:19 |
| fwereade | hazmat: it's not for a *current* branch anyway | 22:19 |
| fwereade | hazmat: not quite ;) | 22:19 |
| fwereade | niemeyer: another thing, hopefully quick | 22:20 |
| fwereade | niemeyer: resolve() is indeed not quite right | 22:20 |
| fwereade | niemeyer: CharmURL.infer and some sort of get_repository(url) are distinct | 22:21 |
| niemeyer | fwereade: Is this about my review point? | 22:21 |
| fwereade | niemeyer: but it would be much more convenient to do that in the check-latest-formulas branch, where resolve() changes anyway | 22:21 |
| fwereade | niemeyer: yep | 22:21 |
| niemeyer | fwereade: In that specific case, I was complaining more about location than anything else | 22:21 |
| fwereade | niemeyer: ah, ok, cool | 22:22 |
| niemeyer | fwereade: IMO, the charm url management should be within something like juju.charm.url | 22:22 |
| niemeyer | fwereade: and it should be fairly self-contained | 22:22 |
| niemeyer | fwereade: resolve() knows about the interface of repositories etc | 22:22 |
| niemeyer | fwereade: So it feels like it should be close to them | 22:23 |
| niemeyer | fwereade: Otherwise we get in a situation where we have repositories using urls that use repositories | 22:23 |
| fwereade | niemeyer: yep, they;re a bit mixed up | 22:24 |
| fwereade | niemeyer: I'll sort it out :) | 22:24 |
| niemeyer | fwereade: Thanks man | 22:24 |
| fwereade | niemeyer: thank you, I think I'm happy with everything now | 22:25 |
| niemeyer | fwereade: Woot | 22:25 |
| fwereade | niemeyer: although you'll no doubt hear from me about *something* :p | 22:25 |
| niemeyer | fwereade: Rest assured I take that _very_ positively! ;-) | 22:25 |
| * niemeyer orders some food in the hotel room | 22:26 | |
| hazmat | sweet 15s to spare on my talk, must talk fast :-) | 22:26 |
| niemeyer | hazmat: Wow.. that's being _precise_ ;-) | 22:33 |
| niemeyer | brb | 22:33 |
| === medberry is now known as med_out | ||
| niemeyer | Dinner.. biab | 23:01 |
| SpamapS | hazmat: where are you speaking? | 23:19 |
| SpamapS | https://launchpad.net/ubuntu/+source/juju | 23:35 |
| hazmat | SpamapS, surge 2011 | 23:36 |
| jimbaker | SpamapS, looking good | 23:36 |
| hazmat | baltimore | 23:36 |
| SpamapS | hazmat: oh cool! I'm a Schlossnagle fanboi.. so ^5 them from one of their first customers. ;) | 23:37 |
| hazmat | stepping out.. their starting | 23:39 |
| hazmat | SpamapS, yeah.. me too. i just saw a new presentation he gave earlier this year in paris on async architectures | 23:40 |
| hazmat | SpamapS, http://www.infoq.com/presentations/Building-Scalable-Systems-Asynchronous-Approach | 23:42 |
| _mup_ | Bug #861928 was filed: provisioning agent gets confused when machines are terminated <juju:New> < https://launchpad.net/bugs/861928 > | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!