| kirkland | SpamapS: plus metadata | 00:00 |
|---|---|---|
| SpamapS | does facter know the ec2 public hostname? thats the tough one to get right now | 00:00 |
| kirkland | SpamapS: it's really easy | 00:00 |
| kirkland | SpamapS: wget -q -O- http://169.254.169.254/latest/meta-data/public-hostname | 00:00 |
| kirkland | SpamapS: if that fails, then use hostname -s | 00:00 |
| niemeyer | SpamapS: Heh | 00:00 |
| niemeyer | SpamapS: https happens to be a superset of http | 00:01 |
| kirkland | SpamapS: http://paste.ubuntu.com/626933/ | 00:04 |
| kirkland | niemeyer: hmm, i'm not sure about that ... try https://ec2-50-17-174-12.compute-1.amazonaws.com:80 | 00:04 |
| kirkland | niemeyer: ie, point https to a port that talks http | 00:05 |
| SpamapS | niemeyer: yes, I can see where you could also just add 'ssl=1' to the http interface.. | 00:05 |
| kirkland | niemeyer: and the browser is unhappy | 00:05 |
| niemeyer | kirkland: Ok, my apologies for the imprecise wording... | 00:05 |
| niemeyer | HTTPS is merely an encryption wrapping on top of HTTP itself | 00:05 |
| kirkland | niemeyer: oh, sorry, i wasn't trying to be an ass; i just thought for a second, "whoa, that's neat, I didn't know that!" then tried it, and it didn't work :-) | 00:05 |
| kirkland | niemeyer: okay, cool | 00:06 |
| SpamapS | kirkland: sure, I'd like to abstract that into a tool that is like facter, but not as clunky as facter. :) | 00:06 |
| niemeyer | But either way, website is a much better term | 00:06 |
| kirkland | SpamapS: +1 from me | 00:06 |
| SpamapS | kirkland: I was reading facter, and one thing it gets really, really wrong, is that it only runs one process at a time. | 00:06 |
| kirkland | SpamapS: i posted something like this to ubuntu-devel@, if you can to comment there | 00:06 |
| niemeyer | and "http" would lead to all kinds of confusion regarding protocol vs. relation.. | 00:06 |
| niemeyer | So I stand corrected. | 00:06 |
| SpamapS | kirkland: it runs 100+ external processes, but waits on each one before moving to the next. | 00:06 |
| kirkland | SpamapS: i got *reamed* in #ubuntu-devel today, though | 00:06 |
| SpamapS | kirkland: eh? | 00:06 |
| kirkland | niemeyer: okay, i've changed it to website | 00:06 |
| SpamapS | kirkland: I saw your post to the ml .. | 00:07 |
| kirkland | SpamapS: see today's log, between me, keybuk, cjwatson, and friends | 00:07 |
| kirkland | SpamapS: they have a few good points | 00:07 |
| kirkland | SpamapS: but still, i think we could use something, if it's named and documented appropriately | 00:07 |
| kirkland | bzr: ERROR: Invalid url supplied to transport: "lp:~kirkland/principia/oneiric/byobu-web/trunk": No such source package byobu-web. | 00:13 |
| kirkland | SpamapS: did you warn me about this yesterday? | 00:13 |
| SpamapS | kirkland: no, but its a known problem | 00:14 |
| SpamapS | kirkland: and being worked on | 00:14 |
| kirkland | SpamapS: okay... what's the solution? | 00:14 |
| SpamapS | kirkland: for now you have to use +junk, or upload a package naemd 'byobu-web' to a PPA somewhere | 00:14 |
| kirkland | SpamapS: hah, seriously? | 00:14 |
| kirkland | :-) | 00:14 |
| SpamapS | kirkland: re the conversation w/ Keybuk .. his point about DNS is *quite* good. | 00:14 |
| SpamapS | we could just simply stop passing around IP | 00:14 |
| SpamapS | The good thing about using DNS is it can be contextualized for the requester... | 00:15 |
| kirkland | SpamapS: mokay | 00:15 |
| SpamapS | It was glossed over, but I see the point | 00:15 |
| niemeyer | Dinner time! | 00:51 |
| _mup_ | ensemble/expose-watch-exposed-flag r245 committed by jim.baker@canonical.com | 00:53 |
| _mup_ | Fixed tests with respect to watch_exposed_flag using its callback on its first value, instead of yielding it | 00:53 |
| _mup_ | ensemble/expose-watch-exposed-flag r246 committed by jim.baker@canonical.com | 00:54 |
| _mup_ | PEP8 | 00:54 |
| _mup_ | ensemble/expose-watch-exposed-flag r248 committed by jim.baker@canonical.com | 01:00 |
| _mup_ | Better comments | 01:00 |
| _mup_ | ensemble/expose-provision-service-hierarchy r293 committed by jim.baker@canonical.com | 01:01 |
| _mup_ | Merged upstream expose-watch-exposed-flag | 01:01 |
| kirkland | SpamapS: hmm, so my relation-set items are not showing up in 'ensemble status' | 01:07 |
| kirkland | No ENSEMBLE_AGENT_SOCKET/-s option found | 01:08 |
| SpamapS | relation-set shouldn't show in status unless a new change was made | 01:11 |
| SpamapS | that error though, means that the environment is screwed up somehow | 01:11 |
| SpamapS | kirkland: is your formula in a branch I can look at? | 01:11 |
| kirkland | SpamapS: lp:~kirkland/+junk/byobu-web | 01:12 |
| kirkland | SpamapS: thanks for your review and all your help | 01:13 |
| SpamapS | kirkland: no problem.. its fun. :) | 01:15 |
| kirkland | SpamapS: ;-) | 01:16 |
| SpamapS | kirkland: are you running that via debug-hooks ? | 01:17 |
| kirkland | SpamapS: um, no | 01:17 |
| SpamapS | kirkland: where are you seeing the error about ENSEMBLE_AGENT_SOCKET? | 01:21 |
| kirkland | SpamapS: oh, i just tried to run the relation-set by hand | 01:27 |
| SpamapS | kirkland: right, that won't ever work. :) | 01:27 |
| kirkland | SpamapS: heh | 01:27 |
| SpamapS | kirkland: I mean, you can make it work but you need to be on the machine, the socket is for talking to the local unit agent | 01:28 |
| SpamapS | kirkland: thats why debug-hooks is so pimp | 01:28 |
| kirkland | SpamapS: then that should probably be moved to /usr/lib/ensemble | 01:28 |
| SpamapS | kirkland: tried it yet? | 01:28 |
| kirkland | SpamapS: if it's not meant be run by hand | 01:28 |
| SpamapS | kirkland: not really, you can run it in a cron job.. :) | 01:29 |
| kirkland | SpamapS: no, how do i do that? | 01:29 |
| SpamapS | ensemble debug-hooks service/0 | 01:29 |
| SpamapS | you MIGHT recognize the interface.. ;) | 01:29 |
| SpamapS | do that, then relate something to it | 01:29 |
| kirkland | SpamapS: nice ;-) | 01:31 |
| kirkland | SpamapS: hmm, okay, i'm missing something, conceptually here | 01:34 |
| SpamapS | kirkland: about to wrap up and go join the cloudcamp pre-camp cocktail party. :) | 01:34 |
| SpamapS | kirkland: whats up? | 01:35 |
| kirkland | SpamapS: meh, it can wait | 01:38 |
| kirkland | SpamapS: perhaps you can help me more tomorrow | 01:38 |
| SpamapS | kirkland: I've got 5 more minutes | 01:40 |
| SpamapS | alright.. I'm out.. good luck. :) | 01:47 |
| kirkland | just wondering if anyone's around for some more formula help | 03:35 |
| kirkland | okay, i've been beating my head against the wall for a while now and I'm just now realizing | 03:38 |
| kirkland | that I'm changing the formula in my local repository | 03:38 |
| kirkland | and then i'm trying to deploy it | 03:39 |
| kirkland | but the modified formula isn't getting deployed | 03:39 |
| _mup_ | Bug #797493 was filed: unresolved revision %r in upgrade-formula error message <Ensemble:New> < https://launchpad.net/bugs/797493 > | 03:41 |
| kirkland | i'm getting a lot of these: | 04:07 |
| kirkland | 2011-06-15 02:50:48,534: hook.output@ERROR: debconf: unable to initialize frontend: Readline | 04:07 |
| kirkland | niemeyer: i'm disappointed to see byobu pruned from head :-( | 05:08 |
| kirkland | niemeyer: for tmux | 05:08 |
| kirkland | niemeyer: i see an obscure note about "race" conditions, but no other explanation | 05:08 |
| niemeyer | kirkland: We didn't intend to exclude byobu specifically, of course | 05:17 |
| niemeyer | kirkland: We replaced screen | 05:17 |
| niemeyer | kirkland: I did, actually | 05:17 |
| kirkland | niemeyer: right, bzr-blame told me :-) | 05:18 |
| niemeyer | kirkland: Because tmux behaves in a better way when facing concurrent executions | 05:18 |
| niemeyer | kirkland: If we fix that, we can bring screen back | 05:18 |
| kirkland | niemeyer: so I'd love to help you fix that so that ensemble can use screen/byobu for this | 05:18 |
| kirkland | niemeyer: by all means, I'm at your disposal | 05:18 |
| niemeyer | kirkland: Sounds good.. I have no special attachment to either in this case | 05:18 |
| kirkland | niemeyer: right-o; I sorta do :-) | 05:18 |
| niemeyer | kirkland: Used screen for a long time.. have been experimenting with tmux lately.. can use either without worries | 05:19 |
| niemeyer | kirkland: Yeah, I know ;) | 05:19 |
| kirkland | niemeyer: it doesn't have to be now, but can you explain to me your concurrency problems? | 05:19 |
| niemeyer | kirkland: Will be happy to put your stuff to crank :) | 05:19 |
| niemeyer | kirkland: We just need to sort the race | 05:19 |
| niemeyer | kirkland: It's pretty simple to explain, actually | 05:19 |
| kirkland | niemeyer: and i'll gladly write a custom configuration file for ensemble-debug-hooks-byobu | 05:19 |
| niemeyer | kirkland: Given a session name, screen offers no way that I could perceive to avoid the same user from potentially getting two different sessions started | 05:20 |
| kirkland | niemeyer: as I'm using it now, I can see the things I want to know about a system when I'm logged into it through debug | 05:20 |
| kirkland | niemeyer: do you want 1 session, or 2? | 05:20 |
| niemeyer | kirkland: The first | 05:20 |
| kirkland | niemeyer: okay, so you want 1 session, call it "ensemble-debug" or something, right? | 05:21 |
| niemeyer | kirkland: For both | 05:21 |
| kirkland | niemeyer: okay, and you also want to attach to that one and only one session? | 05:21 |
| niemeyer | kirkland: Yes, just a non-racy way to create a named session | 05:22 |
| niemeyer | kirkland: If the same user executes the same command twice in different terminals, the command should fail or succeed, but it should never yield two different sessions | 05:22 |
| niemeyer | kirkland: We can't _join_ the session, though.. | 05:23 |
| niemeyer | kirkland: Simply new-session + exec command in new session, without races | 05:23 |
| kirkland | niemeyer: to reproduce the problem you're experience in screen ... | 05:24 |
| kirkland | niemeyer: i'm going to create a screen session with "screen -S debug" | 05:24 |
| kirkland | niemeyer: okay, now I have a session | 05:25 |
| kirkland | niemeyer: called 'debug' | 05:25 |
| kirkland | niemeyer: and now I want to run a command in that sesion | 05:25 |
| niemeyer | Ok | 05:25 |
| niemeyer | kirkland: You want to create it if it doesn't exist, and run it in the single session | 05:25 |
| kirkland | niemeyer: okay, using the "at" command | 05:26 |
| kirkland | niemeyer: i mean, screen's at | 05:26 |
| niemeyer | kirkland: Executing the command isn't the problem.. the problem is creating the session in a non-racy way | 05:28 |
| kirkland | niemeyer: byobu -xRS %s-hook-debug -t shell | 05:33 |
| kirkland | niemeyer: that's what you were using before, right? | 05:33 |
| kirkland | niemeyer: and that's what you found to be racy? | 05:33 |
| niemeyer | kirkland: No, that'd join the session | 05:34 |
| kirkland | niemeyer: what were you using to create it? | 05:34 |
| kirkland | niemeyer: i'm trying to reproduce the race | 05:35 |
| niemeyer | kirkland: This is being run from a script.. it can't join the session | 05:35 |
| kirkland | niemeyer: right, so you create the session detached | 05:35 |
| niemeyer | kirkland: You don't have to reproduce the race.. any solution will do :-) | 05:35 |
| kirkland | niemeyer: some people create their byobu session in a cronjob at boot | 05:35 |
| kirkland | niemeyer: so that they can launch irssi and use byobu+irssi as their irc proxy | 05:36 |
| niemeyer | kirkland: Yeah, that should be fine.. the machine won't boot twice at the same time. | 05:36 |
| kirkland | niemeyer: if it does, I want to see it! | 05:36 |
| niemeyer | +1! :-) | 05:36 |
| kirkland | niemeyer: let me find my emails where I've helped someone do this | 05:36 |
| kirkland | niemeyer: it's a permutation of this: | 05:37 |
| kirkland | -d -m Start screen in "detached" mode. This creates a new session but doesn't attach to it. This is useful for system startup scripts. | 05:37 |
| kirkland | niemeyer: one more question... you want this session owned by root, or ubuntu? | 05:38 |
| kirkland | niemeyer: i've noticed both your tmux and byobu solutions use sudo to get to a shell | 05:38 |
| niemeyer | kirkland: Yeah | 05:38 |
| kirkland | niemeyer: i found a minor bug with the way that was being called | 05:38 |
| kirkland | niemeyer: which I'll fix as I work on this | 05:38 |
| niemeyer | kirkland: What was it? | 05:38 |
| kirkland | niemeyer: but I'm curious about the motivation and design | 05:38 |
| niemeyer | kirkland: It's just a script on the server feeding a screen/tmux session | 05:40 |
| kirkland | niemeyer: right | 05:40 |
| kirkland | niemeyer: but putting the user in a root shell | 05:40 |
| kirkland | niemeyer: rather than an ubuntu shell | 05:41 |
| niemeyer | kirkland: The race comes from the fact that the session can be started by the server feeding a new shell, or by the user starting the debugging session | 05:41 |
| kirkland | niemeyer: is that by design? | 05:41 |
| kirkland | niemeyer: sorry, this is aside from the race :-) | 05:41 |
| niemeyer | kirkland: There are details, but that's the core idea | 05:41 |
| niemeyer | kirkland: It's root because the formula runs as root for good reasons | 05:41 |
| niemeyer | kirkland: So to emulate the same environment, we run the hook as root too | 05:41 |
| kirkland | niemeyer: okay | 05:41 |
| kirkland | niemeyer: fair enough; that's the explanation i was looking for | 05:42 |
| niemeyer | kirkland: Cool.. we should document that there too | 05:42 |
| kirkland | niemeyer: so basically, we just need this in /etc/rc.local or an upstart boot script: | 05:52 |
| kirkland | byobu -d -m -S byobu.debug bash | 05:53 |
| kirkland | niemeyer: which will start a screen+byobu session, in detached mode at boot; name it "byobu.debug", and run a single window called bash | 05:53 |
| niemeyer | [niemeyer@gopher ~]% screen -d -m -S byobu.debug bash | 05:53 |
| niemeyer | [niemeyer@gopher ~]% screen -d -m -S byobu.debug bash | 05:53 |
| niemeyer | [niemeyer@gopher ~]% screen -ls | 05:53 |
| niemeyer | There are screens on: | 05:53 |
| niemeyer | 20923.byobu.debug (06/15/2011 01:53:33 AM) (Detached) | 05:53 |
| niemeyer | 20792.byobu.debug (06/15/2011 01:53:31 AM) (Detached) | 05:53 |
| kirkland | niemeyer: obviously we can doctor this up a bit | 05:53 |
| kirkland | niemeyer: right, but you'd do that on boot, just once, no? | 05:54 |
| niemeyer | kirkland: This is done withing the script which starts the debugging session | 05:54 |
| niemeyer | kirkland: and by the user's ssh | 05:55 |
| kirkland | niemeyer: okay, so my first thought, what i've been working on here, is to start the screen debugging session at boot; and then attach to it when/if the user decides to go into the debug_hook mode | 05:56 |
| niemeyer | kirkland: This has to be started by the script that starts the debugging session, or the user ssh shell, whatever comes up first | 05:56 |
| niemeyer | kirkland: This session is terminated when the user leaves the debugging sessoin | 05:56 |
| kirkland | niemeyer: okay | 05:57 |
| kirkland | niemeyer: so the trigger is when the user starts the debug session | 05:57 |
| niemeyer | kirkland: Yeah.. the problem is really how to start two sessions without races | 05:57 |
| kirkland | niemeyer: and if the user ssh's in (outside of the debug hook), do you want them in the debug session or not? | 05:57 |
| niemeyer | Erm.. | 05:57 |
| niemeyer | a single session without races | 05:57 |
| niemeyer | kirkland: A single session with the given name should be created | 05:58 |
| niemeyer | kirkland: In tmux, that's "tmux new-session" | 05:58 |
| niemeyer | kirkland: It prevents the same session from being started multiple times | 05:59 |
| === almaisan-away is now known as al-maisan | ||
| kirkland | niemeyer: hmm, perhaps still racy, but what about: | 06:05 |
| kirkland | niemeyer: byobu -r byobu.debug || byobu -S byobu.debug | 06:05 |
| kirkland | niemeyer: so reattach, if possible; if not, create | 06:05 |
| niemeyer | kirkland: Yeah the window even has a nice shape in the middle ;-) | 06:06 |
| kirkland | niemeyer: let me dig through the screen source code | 06:07 |
| niemeyer | kirkland: Ok.. it's very late here.. I'll really have to step out to bed now | 06:07 |
| kirkland | niemeyer: sure; I am *going* to solve this for you ;-) | 06:08 |
| niemeyer | kirkland: but please let me know what you find.. we can switch back if there's an elegant way to do this in screen | 06:08 |
| niemeyer | kirkland: Awesome, thanks :-) | 06:08 |
| niemeyer | Night! | 06:08 |
| kirkland | niemeyer: night | 06:08 |
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| === daker_ is now known as daker | ||
| * hazmat catches up on the night discussion | 14:03 | |
| hazmat | if anyone has a moment to approve a trivial.. https://pastebin.canonical.com/48502/ | 14:10 |
| hazmat | which fixes bug 797493 | 14:10 |
| _mup_ | Bug #797493: unresolved revision %r in upgrade-formula error message <Ensemble:New> < https://launchpad.net/bugs/797493 > | 14:10 |
| _mup_ | Bug #797696 was filed: FAQ page needs updating <Ensemble:New for kim0> < https://launchpad.net/bugs/797696 > | 14:11 |
| * niemeyer waves | 14:36 | |
| niemeyer | hmm.. compiz update.. let's hope it fixes some of the stability issues. | 14:52 |
| hazmat | niemeyer, indeed | 14:53 |
| hazmat | niemeyer, if you haz a moment to approve a trivial.. https://pastebin.canonical.com/48502/ | 14:53 |
| niemeyer | hazmat: Hey man | 14:53 |
| niemeyer | Looking | 14:53 |
| hazmat | its a fix for the upgrade reporting output in bug 797493 | 14:54 |
| _mup_ | Bug #797493: unresolved revision %r in upgrade-formula error message <Ensemble:New> < https://launchpad.net/bugs/797493 > | 14:54 |
| niemeyer | hazmat: +1! | 14:54 |
| hazmat | niemeyer, just looking over the google lang performance.. i hadn't realized how much slower golang was | 14:54 |
| niemeyer | hazmat: How much slower than what? | 14:54 |
| hazmat | niemeyer, https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf | 14:54 |
| hazmat | java, c++, scala are the comparisons | 14:55 |
| niemeyer | hazmat: Ah, yeah, I've seen that paper | 14:58 |
| niemeyer | hazmat: Go is slower than hugely optimized C++, no questions about that :-) | 14:58 |
| hazmat | what was surprising was how well the naive scala did | 14:59 |
| niemeyer | hazmat: Also note that there's really no "Go Pro" in the paper | 15:00 |
| hazmat | niemeyer, right their just doing optimizations a go 'pro' developer would do | 15:01 |
| niemeyer | hazmat: The person doing the optimization reportedly didn't spend much time on it | 15:01 |
| hazmat | ah | 15:01 |
| niemeyer | hazmat: and was surprised when the paper was published | 15:01 |
| hazmat | niemeyer, i thought they solicited robP for feedback on the pro stuff | 15:01 |
| niemeyer | hazmat: No, it was Ian Tailor, the guy from gccgo | 15:02 |
| niemeyer | Taylor even | 15:03 |
| niemeyer | hazmat: http://j.mp/lwuiAv | 15:03 |
| m_3 | will the bootstrap instance be unhappy if: A) I restart zookeeper on a node during install, and B) zookeeper comes back up on that node with a sun-java6-jdk instead of openjdk? | 15:04 |
| m_3 | (trying to install sun java as part of a formula) | 15:04 |
| niemeyer | m_3: We haven't exercised much that kind of scenario yet | 15:05 |
| m_3 | I'd rather do a update-alternatives which would probably effect zookeeper | 15:05 |
| niemeyer | m_3: Restarting ZooKeeper is supposed to work fine, and it's not hard even | 15:05 |
| m_3 | I'll experiment... | 15:05 |
| niemeyer | m_3: We know about a few issues that may complicate it right now | 15:05 |
| niemeyer | Specifically, we get a spurious event about the session that we're not handling properly yet | 15:06 |
| niemeyer | m_3: The event has to be ignored.. | 15:06 |
| kim0 | hey guys, is the multiple formulas per machine feature landing soonish ? Also is this the same as, machine policy formulas or whatever its called | 15:07 |
| m_3 | niemeyer: is there a way to mute events from that node before I do a zk restart? | 15:07 |
| niemeyer | m_3: mute? | 15:08 |
| niemeyer | m_3: What kind of event? | 15:08 |
| m_3 | sorry, don't know the txzk infterface... | 15:08 |
| niemeyer | m_3: No worries.. just trying to figure what do you really mean | 15:09 |
| m_3 | is there a way to warn the bootstrap instance before bouncing zk on a node | 15:09 |
| niemeyer | kim0: We're not working on it right now, so it won't land _soon_, but we don't want to take too long either | 15:09 |
| niemeyer | m_3: I still don't get what you mean.. it sounds a bit reversed.. | 15:10 |
| m_3 | ...so it can ignore the bad session events you mentioned | 15:10 |
| niemeyer | m_3: zk is _inside_ the bootstrap node | 15:10 |
| m_3 | niemeyer: if I bounce the zk instance running on the new node you said the bootstrap instance gets spurious session events that it doesn't like | 15:12 |
| m_3 | niemeyer: so is there a way for the new node to warn the bootstrap instance about the pending bounce of zk on the new node | 15:13 |
| niemeyer | m_3: Right now there's only a single zk instance, and it is inside the bootstrap node | 15:14 |
| m_3 | niemeyer: oh wow... | 15:14 |
| m_3 | niemeyer: I see zk instance running on new node... let me make sure I'm on the right instance | 15:15 |
| m_3 | niemeyer: yeah, running on both | 15:16 |
| niemeyer | m_3: That's likely an artifact of installing the package on the second instance | 15:18 |
| niemeyer | m_3: Can you please investigate how zookeeper is being started on the second instance? | 15:18 |
| niemeyer | m_3: It's certainly not being used | 15:18 |
| m_3 | niemeyer: ok, will do... thanks | 15:20 |
| hazmat | niemeyer, its because its part of the install image | 15:20 |
| hazmat | niemeyer, we should probably just go ahead and install java, but not zookeeper, and let cloud-init install zk | 15:21 |
| hazmat | that will remove the extraneous zk | 15:21 |
| hazmat | on the service machines | 15:21 |
| niemeyer | hazmat: You mean it's indeed an artifact of installing the package? | 15:21 |
| hazmat | niemeyer, yes | 15:21 |
| niemeyer | hazmat: Ok, hmm | 15:21 |
| hazmat | niemeyer, we don't need it on the service machines, just the python zk extension and libzk | 15:22 |
| niemeyer | hazmat: Your suggestion feels good | 15:22 |
| niemeyer | hazmat: I was going to suggest we disable starting the service, but indeed there's no reason for the package to even exist there | 15:22 |
| hazmat | niemeyer, has upstart grown a nice way to do that? | 15:22 |
| hazmat | my understanding was you need to do some sort of override file that explicitly depended on a nonexistant event | 15:23 |
| niemeyer | hazmat: Not sure.. I recall hearing that it would. Either way, several services check /etc/default/* for info on whether to start or not | 15:23 |
| hazmat | hmm.. true | 15:23 |
| m_3 | niemeyer, hazmat: thanks y'all | 15:25 |
| hazmat | it looks like the other way (via upstart in natty) is echo manual >> /etc/init/zookeeper.override | 15:25 |
| hazmat | niemeyer, i think ben's is blocked on bleeding test failures in one of the service lifecycle integration branches.. | 15:27 |
| hazmat | i had a quick look on monday.. but its going to take some more time to dig into. | 15:27 |
| _mup_ | ensemble/trunk r254 committed by kapil.thangavelu@canonical.com | 15:28 |
| _mup_ | [trivial] fix formatting for upgrade error [r=niemeyer][f=797493] | 15:28 |
| niemeyer | hazmat: Ok.. it'd be good to have more of that conversation happening in the open | 15:28 |
| niemeyer | hazmat: So that we can get a feeling of what to do about it.. I'd really like to make our tests rock solid in this milestone | 15:29 |
| niemeyer | hazmat: and not rely on any kind of timing | 15:29 |
| hazmat | niemeyer, this isn't a timing issue, the its some sort of bleeding issue.. the tests run fine looped in isolation, but full test runs are busted | 15:30 |
| hazmat | i suspect its the reset_logging/save_logging stuff.. because its overly ambitious in the reset, which cascades to others | 15:30 |
| hazmat | which depend on the default | 15:30 |
| niemeyer | hazmat: Have you seen Jim's branch? | 15:31 |
| hazmat | at least that was the case last time around | 15:31 |
| hazmat | niemeyer, yeah.. i've discussed it with him, there are more timing issues there.. but i think the problem is having async cb chained call stacks without an explicit control point | 15:31 |
| hazmat | ie. more of a design issue there | 15:31 |
| hazmat | i've also expressed i'd prefer to see that encapsulated better so that refactoring it to the machine agent is a bit easier | 15:32 |
| niemeyer | hazmat: One of the things there is that it kills reset and save_logging entirely | 15:32 |
| hazmat | niemeyer, ah that branch | 15:32 |
| hazmat | i haven't looked at it.. that might certainly help | 15:32 |
| _mup_ | ensemble/bootstrap-shutdown-environment r250 committed by kapil.thangavelu@canonical.com | 15:38 |
| _mup_ | note the shutdown prompt in the user guide | 15:38 |
| _mup_ | ensemble/trunk r255 committed by kapil.thangavelu@canonical.com | 15:41 |
| _mup_ | merge bootstrap-shutdown-environment [r=bcsaller,niemeyer][f=756685] | 15:41 |
| _mup_ | Ensemble bootstrap and shutdown subcommands now operate on a single | 15:41 |
| _mup_ | environment. The shutdown command also requires a user confirmation | 15:41 |
| _mup_ | before destroying the environment. | 15:41 |
| kim0 | The instructions to run from ppa https://ensemble.ubuntu.com/docs/getting-started.html#running-from-ppa | 15:47 |
| kim0 | are missing a apt-get update, does this require filing a bug/branch, or is there a simpler way | 15:47 |
| hazmat | kim0, ugh.. mea culpa.. a trivial for that sounds good | 15:48 |
| kim0 | hazmat: what's the workflow for a trivial fix | 15:48 |
| hazmat | kim0, change the files, paste a diff, ask for an +1 on the trivial | 15:50 |
| hazmat | kim0, after receiving such, commit the diff to trunk with a [trivial] tag in the commit msg | 15:51 |
| hazmat | at least that's the workflow i've been following for such | 15:51 |
| kim0 | hazmat: http://paste.ubuntu.com/627384/ | 15:52 |
| hazmat | kim0, looks good, +1 | 15:52 |
| hazmat | ;-) | 15:52 |
| niemeyer | hazmat: +1 on the workflow.. sometimes I cowboy extremely obvious things, but I've also found useful comments from others on things I initially found obvious | 15:54 |
| kim0 | merged | 15:57 |
| kim0 | I'd like to contact Iain Farrel from design team, to ask for an Ensemble mascot. Now is probably a good time for one :) any +1/-1s | 16:00 |
| hazmat | kim0, sounds great | 16:01 |
| === al-maisan is now known as almaisan-away | ||
| jimbaker | hazmat, is there still a timing issue in the standardize-log-testing branch? | 16:34 |
| hazmat | jimbaker, checking.. un momento | 16:35 |
| kirkland | hey guys -- any feedback on my bash-completion branch? :-) | 16:36 |
| jimbaker | hazmat, it should be fixing a problem with HookContext that's causing this "bleeding" | 16:37 |
| jimbaker | i believe the save_logging/reset_logging simply were masking this issue | 16:37 |
| jimbaker | kirkland, i like the idea of completion. but i did wonder, what sort of testing is typically done around stuff like this? | 16:39 |
| kirkland | jimbaker: ensemble<space><tab><tab> | 16:40 |
| kirkland | jimbaker: the framework is there for each subcommand to have completion too | 16:40 |
| kirkland | jimbaker: i tried grepping "ensemble status" for that, but it's too slow | 16:40 |
| kirkland | jimbaker: i think i'd need to cache that output | 16:41 |
| kirkland | jimbaker: from a user experience perspective | 16:41 |
| niemeyer | kirkland: Sorry, it wasn't in my radar.. we generally use this view for reviews: | 16:41 |
| niemeyer | kirkland: https://ensemble.ubuntu.com/kanban/dublin.html | 16:41 |
| jimbaker | kirkland, yeah, that makes sense re ensemble status being too slow | 16:41 |
| niemeyer | kirkland: But it only gets there if there's a bug linked, in progress, and attached to the milestone | 16:42 |
| niemeyer | kirkland: I'll check it out today | 16:42 |
| niemeyer | kirkland: I think completion on status wouldn't be ideal indeed | 16:42 |
| niemeyer | kirkland: I'd rather not complete than wait | 16:43 |
| hazmat | kirkland, are you saying that grepping ensemble status -h is too slow for completion? | 16:44 |
| hazmat | it shouldn't be doing any work before it has parsed the cli | 16:44 |
| kirkland | niemeyer: right, i just tried it lightly, and it was really bad performance | 16:45 |
| jimbaker | my assumption was that kirkland was actually getting names from ensemble status... | 16:45 |
| kirkland | niemeyer: but getting the initial actions is really fast | 16:45 |
| kirkland | niemeyer: and it keeps me from having to go back to ensemble --help all the time to find the right commands | 16:45 |
| kirkland | jimbaker: no, not doing that | 16:46 |
| jimbaker | kirkland, ok | 16:46 |
| kirkland | hazmat: no, not -h | 16:47 |
| hazmat | kirkland, we could probably give a an additional option to status to make if faster for completion | 16:49 |
| hazmat | its pulling in almost the whole subgraph atm, but really we just need one node | 16:49 |
| hazmat | i take that back.. the connection setup would still dominate, we do need a local cache for completion | 16:50 |
| _mup_ | ensemble/bash-completion r257 committed by bcsaller@gmail.com | 16:51 |
| _mup_ | bash_completion support with some argument support | 16:51 |
| hazmat | assuming that is we were completing actual variable/value names | 16:52 |
| kirkland | hazmat: yeah, i was thinking something like that; caching status to disk; backgrounding an update of the cache when it's deemed expired | 16:53 |
| kirkland | hazmat: anyway, it's not urgent, but would make for a damn cool interface :-) | 16:53 |
| jimbaker | kirkland, your background process could simply listen to topology changes like any other zk client can | 16:55 |
| jimbaker | in terms of watching a given node | 16:55 |
| kirkland | jimbaker: cool; | 16:56 |
| jimbaker | probably better to do that way than using ensemble status (except for spiking) | 16:56 |
| kirkland | jimbaker: hazmat: niemeyer: in any case, we now have the framework for the bash-completion piece; if and when we can get ensemble status instantly (or at least comb a cache of ensemble status), I'll extend the bash-completion for subcommands to leverage the status info | 16:57 |
| niemeyer | kirkland: Sounds good | 16:57 |
| niemeyer | kirkland: Completion helps for sure | 16:58 |
| hazmat | kirkland, we don't have any client side daemon ... its not clear to me what would do the background update, perhaps just invoking the cli again in the background with a cache option.. although having a daemon might be nice with the ssh tunnel reuse | 16:58 |
| kirkland | hazmat: a daemon would be one approach | 16:58 |
| kirkland | hazmat: another would be in the bash-completion command itself | 16:59 |
| kirkland | hazmat: in there, i'd test the age of the cache | 16:59 |
| hazmat | kirkland, indeed.. yeah. we'd need to show stale data in that case afaics | 16:59 |
| kirkland | hazmat: if it's not expired, then i'd use it; and background an update | 16:59 |
| hazmat | or get random waits | 16:59 |
| kirkland | hazmat: if it is expired; i'd probably just return "null" immediately (ie, no complete) and background an update | 16:59 |
| kirkland | hazmat: where an update is something like 'ensemble status > $HOME/.cache/ensemble-status &' | 17:00 |
| SpamapS | FYI, I just updated the builder recipes for ensemble to make the bzr revno part of the upstream version. | 17:00 |
| SpamapS | hazmat: a local daemon that does the ssh tunnel and listens to zookeeper updates for all status info would be doable, would it not? | 17:02 |
| SpamapS | hazmat: we could even leverage dbus and have it spun up when needed. | 17:02 |
| niemeyer | Lunch time! | 17:03 |
| kirkland | SpamapS: do you mind trying out bzr+ssh://bazaar.launchpad.net/~kirkland/%2Bjunk/byobu-web/ ? | 17:05 |
| jimbaker | wouldn't such a status daemon also be useful for an indicator? | 17:06 |
| SpamapS | kirkland: bootstrapping.. :) | 17:06 |
| SpamapS | kirkland: yesterday you were saying you felt like you were missing a concept.. did you figure it out? | 17:07 |
| kirkland | SpamapS: sort of | 17:07 |
| kirkland | SpamapS: i think it was around bumping the formula revision number | 17:08 |
| kirkland | SpamapS: and pushing an upgrade | 17:08 |
| kirkland | SpamapS: i spent 4 hours making changes locally | 17:08 |
| kirkland | SpamapS: but not seeing those in my deployments | 17:08 |
| kirkland | (okay, 4 is an exaggeration :-) | 17:08 |
| SpamapS | DOH I hate that | 17:09 |
| SpamapS | I still am pretty convinced that users will despise the revno too and just wonder why we don't use a hash of the zip file or something. | 17:09 |
| kirkland | SpamapS: i feel like if my --repository=./ then obviously i want it upgraded every time | 17:10 |
| kirkland | SpamapS: agreed; if we have to use a revno, i want it bumped automatically for me | 17:10 |
| kirkland | SpamapS: i don't want to think about tht | 17:10 |
| SpamapS | kirkland: I spent like, 30 seconds trying to write a script to do that automatically, but got annoyed with the yaml libraries available. ;) | 17:10 |
| kirkland | SpamapS: how good or bad is it/ | 17:14 |
| hazmat | maybe a --force on upgrade, to bypass the version checking | 17:15 |
| kirkland | hazmat: sure, i'd use that (probably all the time :-) | 17:16 |
| hazmat | looks pretty straightforward to implement | 17:18 |
| kirkland | SpamapS: the only tricky part is that you have to set a password for ubuntu for the formula to be useful | 17:20 |
| kirkland | SpamapS: so i'm keen on finding a way of doing that, before blogging about it :-) | 17:20 |
| hazmat | SpamapS, we could use a md5 checksum for verifying instead of numbers, but we're playing pretty fast an loose with version numbers at that point | 17:24 |
| SpamapS | kirkland: right thats where config settings come. | 17:32 |
| SpamapS | hazmat: we've talked about this before.. --force is a nice band-aid. Users will *still* hate the revno. ;) | 17:33 |
| kirkland | SpamapS: right, unimplemented at this point, no? | 17:33 |
| SpamapS | principle of least surprise: I changed my formula, it should deploy anew. | 17:33 |
| SpamapS | At least warn me that you didn't deploy the same content as whats on disk locally. | 17:35 |
| SpamapS | kirkland: --force is unimplemented, as is the config settings (not sure which you were asking about) | 17:42 |
| kirkland | SpamapS: config | 17:42 |
| kirkland | SpamapS: i'm looking for the best work around for setting an ubuntu password | 17:42 |
| kirkland | SpamapS: to a configurable value | 17:42 |
| kirkland | SpamapS: or randomly generating it | 17:42 |
| kirkland | SpamapS: and getting that back to the user | 17:43 |
| kirkland | SpamapS: perhaps as a relation? | 17:43 |
| SpamapS | kirkland: randomly generate it, and log it with ensemble-log INFO level | 17:43 |
| SpamapS | ensemble-log --log-level INFO password=f94k1X | 17:44 |
| SpamapS | kirkland: I suggest pwgen for the generation btw. | 17:44 |
| SpamapS | kirkland: ajaxterm runs its own HTTP daemon right? | 18:31 |
| kirkland | SpamapS: yeah, on 8022 | 18:31 |
| kirkland | SpamapS: which doesn't need to be opened to the world | 18:32 |
| kirkland | SpamapS: just to itself | 18:32 |
| SpamapS | kirkland: wondering if you could do some kind of SSO thing | 18:32 |
| kirkland | SpamapS: hmm | 18:33 |
| kirkland | SpamapS: openid-ish you mean? | 18:33 |
| kirkland | SpamapS: that would be so sexy .... | 18:33 |
| SpamapS | Wordpress has an openid provider plugin.. >:) | 18:34 |
| SpamapS | kirkland: I was going to suggest Launchpad.. but how do you know which groups to accept? ;) | 18:46 |
| Daviey | anyone who has signed the CoC is good cookie :) | 18:47 |
| kirkland | SpamapS: i figured you'd just add your LP id as part of the config | 18:48 |
| kirkland | SpamapS: which could be a group, maybe | 18:48 |
| SpamapS | Daviey: hm that reminds me I should add that as a requirement for contributing to principia. | 18:49 |
| Daviey | oh aye | 18:59 |
| kim0 | I'm collecting a list of weekly happenings in the Ensemble space, preparing for a blog post | 19:03 |
| kim0 | so far, I've collcted these http://paste.ubuntu.com/627516/ | 19:03 |
| kim0 | feel free to add any comments on any points, and add new points (perhaps recent development) that I'm not aware of | 19:04 |
| SpamapS | kim0: In addition to point 1, principia-tools has a script, 'promulgate', that assigns a branch as the official branch for a formula. | 19:06 |
| kim0 | SpamapS: so a branch like lp:~kim0/+junk/drupal could now be marked as official branch for lp:principia/drupal right ? | 19:07 |
| kim0 | cool | 19:08 |
| kim0 | niemeyer: hazmat if anyone has any development related points I should add .. let me know .. thanks | 19:10 |
| niemeyer | kim0: The debug-hooks fixes have landed | 19:10 |
| kim0 | got it | 19:11 |
| niemeyer | kim0: Btw, "source package branches" is an internal implementation detail rather than something that would make sense to advertise as such | 19:11 |
| niemeyer | kim0: I.e. principia has formulas, not source packages | 19:11 |
| kim0 | yeah, this part I found confusing to understand | 19:12 |
| kim0 | so I'll just say that formulas can now be referenced like lp:principia/mediawiki | 19:12 |
| niemeyer | kim0: It's an internal Launchpad detail.. we're reusing existing infrastructure because it's similar to what we need | 19:12 |
| niemeyer | kim0: The key point there is that principia is moving forward, and we not have means for tagging officially recommended branches | 19:13 |
| niemeyer | kim0: s/and we not/and we now/ | 19:13 |
| kim0 | awesome, I'll note that as well | 19:13 |
| kim0 | daker: o/ | 19:13 |
| daker | kim0: sorry i need to leave the office :/ | 19:14 |
| kim0 | daker: oh still at the office .. okie ..catch you at home :) | 19:14 |
| daker | :) | 19:14 |
| SpamapS | kim0: hopefully nobody will link +junk branches though. :) | 19:18 |
| kim0 | haha :D | 19:18 |
| kim0 | yeah bad example | 19:19 |
| niemeyer | +1 :-) | 19:22 |
| koolhead17 | hi all | 19:24 |
| koolhead17 | hello kim0 niemeyer | 19:24 |
| niemeyer | Hey koolhead17 | 19:24 |
| kim0 | koolhead17: hey hey | 19:24 |
| koolhead17 | Daviey: hazmat and all :) | 19:24 |
| kim0 | koolhead17: how's the ec2 playing going | 19:25 |
| koolhead17 | kim0: having fun time :) | 19:25 |
| koolhead17 | thanks 2 you :) | 19:25 |
| kim0 | awesome | 19:25 |
| koolhead17 | i make sure to run ensemble shutdown :D | 19:25 |
| kim0 | hehe :) | 19:25 |
| koolhead17 | niemeyer: kim0 i have a question | 19:25 |
| kim0 | shoot | 19:26 |
| koolhead17 | the package which is not available via apt-get | 19:26 |
| koolhead17 | can i write formula for that? | 19:26 |
| kim0 | SpamapS: would kick you though :) | 19:27 |
| hazmat | koolhead17, yes.. you can download and install from anywhere you want in the 'install' hook, however | 19:27 |
| kim0 | I think the discussion for that is ongoing | 19:27 |
| * koolhead17 looks at SpamapS :) | 19:27 | |
| koolhead17 | hazmat: yeah that`s what i wanted the permission for :P | 19:27 |
| hazmat | such formulas probably won't be accepted for an official release of principia.. but they can be installed easily from the command line with a different namespace prefix | 19:27 |
| kim0 | my understanding is, ofc you can, but it won't be a blessed formula | 19:27 |
| koolhead17 | kim0: blessed formula :D | 19:28 |
| hazmat | ie ensemble deploy koolhead17:wordpress | 19:28 |
| koolhead17 | hazmat: yes i saw and checked that via EC2 | 19:28 |
| jimbaker | bcsaller, hazmat - were you able to see if standardize-log-testing branch was helpful for looping problems? | 19:28 |
| bcsaller | jimbaker: I haven't merged it, you found an issue with the hook context? | 19:29 |
| jimbaker | bcsaller, yes, it was using processExited instead of processEnded | 19:29 |
| jimbaker | i think the save_logging etc stuff was masking this | 19:30 |
| jimbaker | bcsaller, so it may be helpful for your work, based on what hazmat was saying earlier today | 19:32 |
| bcsaller | I'll take a look, thanks | 19:32 |
| niemeyer | kim0: That's right.. it's fine to do it, it just won't be part of the core formulas | 19:39 |
| kim0 | although if the only concern is getting security updates, I'm not sure why we can't just request the formula author to add a suitable update mechanism | 19:41 |
| kim0 | like for drupal/drush "drush upc" would update drupal-core and all modules .. many modules are not even packaged | 19:42 |
| SpamapS | hazmat: should we keep pushing txaws trunk into the ensemble PPA, or backport the oneiric version? | 19:43 |
| hazmat | SpamapS, hmmm.. i think we're okay with trunk for the foreseeable future ... if we do make a fix to txaws, we want the ppa to capture that | 19:44 |
| hazmat | and most of what's happened there is just bug fixing | 19:44 |
| SpamapS | hazmat: at some point we need to make a stable PPA | 19:44 |
| SpamapS | hazmat: once we get past beta1 of oneiric maybe.. | 19:45 |
| hazmat | SpamapS, definitely | 19:45 |
| SpamapS | hazmat: So that people can get teh 11.10 version of ensemble on natty/maverick/lucid | 19:45 |
| niemeyer | kim0: In that case, it won't be an official formula.. we can't enforce how the user will handle security updates | 19:50 |
| niemeyer | kim0: We can only offer the mechanisms | 19:50 |
| kim0 | but we're already enforcing, we're saying if you dont use apt-get you wont be accepted in official | 19:51 |
| SpamapS | kim0: practically, drush upc is meant to do the same thing. But we don't want to take responsibility for that. | 19:51 |
| kim0 | the formula author takes responsibility | 19:52 |
| SpamapS | Hence it not being "official" | 19:52 |
| kim0 | We should only verify that the update mechannism works | 19:52 |
| SpamapS | Official means "we take responsibility for it working a certain way" | 19:52 |
| SpamapS | We don't know their security update process, we don't know how long they'll support a version.. also what if they break compatiblity with other software in a version that also fixes security? We don't do that. | 19:53 |
| SpamapS | kim0: It will be available, but like the thread was saying, it won't be quite as automatic to get it. | 19:53 |
| kim0 | would users be able to query non official repos for all drupal formulas ? | 19:54 |
| kim0 | perhaps we should allow user-rating and commenting, a la android market | 19:55 |
| kim0 | if user formulas (non official) are not searchable/discoverable .. that pretty much kills them though | 19:56 |
| SpamapS | No they'll show up in searches.. with a namespace that identifies them clearly as "not official" | 20:03 |
| SpamapS | I like the idea of "contrib" .. "These are useful formulas but not part of Ubuntu" | 20:04 |
| SpamapS | kim0: I actually think these formulas are the killer app of ensemble.. and making the distinction isn't going to kill them or harm them in any way. It just signals to users what risk is involved. | 20:05 |
| niemeyer | kim0: We're not enforcing, in the same way we don't enforce what people put in PPAs | 20:11 |
| SpamapS | True, we're still speculating on what we want 'official' to mean. | 20:11 |
| niemeyer | kim0: There's a significant difference between "you can't create a package" and "your package is not part of main" | 20:11 |
| niemeyer | kim0: Most people don't care that their packages are not part of main | 20:12 |
| kim0 | SpamapS: cool, as long as they show up in searches .. that's lovely :) | 20:12 |
| kim0 | yeah | 20:12 |
| daker | back | 20:50 |
| daker | niemeyer: license question | 20:50 |
| niemeyer | daker: Sure | 20:50 |
| daker | my formula is based on the wp one, what should i do ? | 20:51 |
| SpamapS | daker: merge the latest copyright file from the wordpress formula, and then add your own copyright to it where appropriate. | 20:53 |
| SpamapS | daker: http://bazaar.launchpad.net/~ensemble-composers/principia/oneiric/wordpress/trunk/view/head:/copyright | 20:54 |
| daker | SpamapS: can you give an example on how my copyright should be ? | 20:55 |
| SpamapS | daker: on the next line after Copyright: Copyright 2011, Canonical Ltd., All Rights Reserved. | 20:55 |
| SpamapS | actually | 20:55 |
| SpamapS | no, add a Files: section.. | 20:55 |
| SpamapS | Files: hooks/db-relation-changed | 20:55 |
| SpamapS | Copyright: 2011, Canonical Ltd., All Rights Reserved | 20:56 |
| SpamapS | 2011, YOUR NAME <your@email.com> | 20:56 |
| SpamapS | License: GPL-3 | 20:56 |
| SpamapS | That should do it | 20:56 |
| daker | ok | 20:56 |
| daker | SpamapS: thanks | 20:57 |
| SpamapS | daker: if you totally rewrote hooks/install , you can list it there too | 20:57 |
| daker | SpamapS: is it good http://paste.ubuntu.com/627597/ ? | 21:05 |
| SpamapS | daker: you do not need to create a Files section for anything you did not change. Just let the 'File: *' handle that | 21:07 |
| SpamapS | daker: each Files: section needs a License: portion, but does not have to repeat the text. | 21:08 |
| daker | headache :/ | 21:09 |
| daker | SpamapS: good http://paste.ubuntu.com/627606/ ? | 21:19 |
| SpamapS | daker: as I said, you don't have to repeat the text, just the License: GPL-3 part | 21:21 |
| SpamapS | daker: the format specification is the first link in that file, it might be helpful | 21:22 |
| SpamapS | daker: http://paste.ubuntu.com/627613/ | 21:24 |
| SpamapS | daker: much simpler, see? | 21:24 |
| daker | ah ok | 21:24 |
| SpamapS | err, I repeated hooks/install oops ;) | 21:24 |
| daker | SpamapS: one last time http://paste.ubuntu.com/627614/ | 21:27 |
| SpamapS | daker: you are missing the original Files: * section | 21:29 |
| SpamapS | daker: which you shouldn't be altering | 21:29 |
| daker | SpamapS: it will be copyrighted to ? canonical ? | 21:31 |
| daker | or me ? | 21:31 |
| SpamapS | daker: You have copyrights on anything you changed by more than a few lines. | 21:33 |
| SpamapS | daker: so metadata.yaml you also probably deserve copyright on. | 21:33 |
| SpamapS | daker: honestly you can just dump the wordpress copyright file in there, without your copyrights.. I'm more concerned with the license than the copyrights. | 21:34 |
| daker | SpamapS: just one more time pls http://paste.ubuntu.com/627620/ | 21:35 |
| jimbaker | hazmat, i don't think this got through: i've been experimenting with client.connected for watch_expose_flag. this is of course the common pattern for watches | 21:39 |
| jimbaker | hazmat, i was trying to determine why my provisioning agent tests would fail after approximately 200 iterations or so. i was under the impression that a single poke i was doing at teardown ensured watches would always run | 21:41 |
| hazmat | jimbaker, a poke is just a roundtrip communication, the watch would have to have already fired for a poke to be sync point | 21:42 |
| jimbaker | hazmat, right. so i think there's a very small chance that a new watch is getting setup in the background by another watch as tests terminate | 21:43 |
| jimbaker | hazmat, having the watch cb depend on some app state definitely is working, as you suggested | 21:44 |
| jimbaker | hazmat, but maybe i can try one more tack here - have the test on app state before each watch setup too | 21:45 |
| _mup_ | ensemble/expose-provision-service-hierarchy r294 committed by jim.baker@canonical.com | 21:47 |
| _mup_ | Removed unused code, comments | 21:47 |
| jimbaker | hazmat, no, that doesn't work | 21:57 |
| * niemeyer breaks | 21:58 | |
| jimbaker | hazmat, maybe what's going on here is the following: test teardown occurs; as part of that, the zk tree is deleted; but this triggers a watch on exposed flag (because it has been exposed, and in a separate node than the topology) | 21:59 |
| hazmat | jimbaker, the tests are supposed to close the client, and open a new client to tear down the tree | 21:59 |
| jimbaker | then the watch runs, but the client is already disconnected | 21:59 |
| hazmat | closing the first client, shutsdown extant watches | 22:00 |
| jimbaker | hazmat, ok, that theory doesn't work then :) | 22:00 |
| hazmat | jimbaker, you might want to verify your tests are inheriting from the state test base which has this behavior | 22:00 |
| jimbaker | hazmat, yes it is: class AgentTestBase(StateTestBase) ... | 22:01 |
| jimbaker | hazmat, so i wonder if this argues for reinstating the test on client.connected in the watch... putting it there, i looped > 1000 times, at which point i control-c | 22:02 |
| jimbaker | i'm controlling the callback on the agent (a new boolean agent._running), but the watch itself doesn't have access before it does exists_and_watch | 22:04 |
| hazmat | jimbaker, that | 22:04 |
| hazmat | er.. that's fine by me | 22:04 |
| jimbaker | hazmat, yes, i know. i think i have spent easily a number of days looking at this question raised by niemeyer on two lines of code | 22:05 |
| jimbaker | so that's all good, i think we have a good answer for why it's necessary, and the best pattern to write code | 22:06 |
| jimbaker | hazmat, 1) have the watch be guarded by client.connected upon entry, as is our common practice; 2) have the callback be guarded on something at the app level | 22:07 |
| jimbaker | hazmat, anyway, i'm going to push up that change to expose-watch-exposed-flag | 22:09 |
| _mup_ | ensemble/expose-watch-exposed-flag r249 committed by jim.baker@canonical.com | 22:12 |
| _mup_ | Guard entry into the watch with client.connected for watch_exposed_flag (again) | 22:12 |
| hazmat | SpamapS, kirkland i took a look at the force upgrade.. it looked pretty easy initially but it ends up violating some assumptions we have that a formula id (namespace:name-revision) is unique in the deployment | 22:13 |
| hazmat | jimbaker, the standardize-log-testing didn't resolve the issues on bcsaller's branch.. but it looks good to me | 22:14 |
| jimbaker | hazmat, cool about my branch, just too bad it wasn't as powerful as i had hoped :) | 22:15 |
| _mup_ | ensemble/expose-provision-service-hierarchy r295 committed by jim.baker@canonical.com | 22:15 |
| _mup_ | Merged upstream expose-watch-exposed-flag | 22:15 |
| jimbaker | hazmat, feel free to grab a review of standardize-log-testing if that works for you - want to get it into trunk and need that 2nd review | 22:17 |
| hazmat | jimbaker, sounds good | 22:27 |
| SpamapS | hazmat: so maybe it would be even easier to just use the hash? ;-) | 22:27 |
| hazmat | SpamapS, indeed, it might at that | 22:28 |
| SpamapS | hazmat: anyway, thanks for looking into it | 22:35 |
| daker | SpamapS: can you give me your opinion http://paste.ubuntu.com/627620/ pls ? | 22:36 |
| SpamapS | daker: re your last one.. read it logically (not just based on what I've asked you to do). You have removed Canonical's copyrights and added your own. Thats not appropriate. | 22:36 |
| SpamapS | daker: the point of the file is to document what the license and copyright status of each file is. The 'Files: *' means *all files not otherwise specified* | 22:37 |
| daker | i am really confused :/ | 22:38 |
| SpamapS | You should ask a question then, I am happy to answer. | 22:38 |
| daker | you said that i have rights on anything i have changed, and i didn't remove Canonical's copyrights | 22:41 |
| SpamapS | Files: * | 22:42 |
| SpamapS | Copyright: 2011, Adnane Belmadiaf <daker@ubuntu.com> | 22:42 |
| SpamapS | License: GPL-3 | 22:42 |
| SpamapS | No mention of Canonical there | 22:42 |
| SpamapS | but canonical retains all of its copyrights. | 22:42 |
| SpamapS | Unless you completely replaced most of the file. | 22:42 |
| SpamapS | At which point you would have an explicit entry that just lists you. | 22:43 |
| daker | SpamapS: so the Files: * section is copyrighted to canonical ? | 22:46 |
| _mup_ | ensemble/expose-provision-service-hierarchy r296 committed by jim.baker@canonical.com | 22:48 |
| _mup_ | Doc string | 22:48 |
| SpamapS | daker: yes, then you add a "Files" section for each file that has something other than that for its Copyright/License. | 22:50 |
| hazmat | jimbaker, one comment on the log stuff merge, the sleep looks a little out of place, else its pretty nice (and mp approved) | 23:26 |
| Daviey | Can i confirm that there is no intetion to get ensemble in main for release? | 23:32 |
| SpamapS | Daviey: not for 11.10, but I do intend to MIR some of its dependencies. | 23:37 |
| _mup_ | ensemble/standardize-log-testing r259 committed by jim.baker@canonical.com | 23:39 |
| _mup_ | Removed spurious sleep (shouldn't have been part of push) | 23:39 |
| Daviey | SpamapS: Do you have a list of those? | 23:39 |
| Daviey | What is the reasoning for MIR'ing them, if ensemble will remain in universe for this release? | 23:40 |
| SpamapS | Daviey: to spread out the load on the MIR team and give us time to get ensemble ready. | 23:42 |
| SpamapS | Daviey: essentially, we know we want ensemble in main for 12.04 .. but we also know it probably won't be ready. | 23:42 |
| _mup_ | ensemble/standardize-log-testing r260 committed by jim.baker@canonical.com | 23:43 |
| _mup_ | Merged trunk | 23:43 |
| Daviey | SpamapS: Agreed. 'Spreading the burden' doesn't make much sense IMO. We already have to raise enough MIR's for our other commitments, which hasn't been compariable since karmic. | 23:47 |
| jimbaker | hazmat, i fixed up that sleep per the commit message, sorry about that! | 23:47 |
| jimbaker | i generally try to mark such debug statements with an XXX so they don't sneak in... but forgot this time | 23:48 |
| SpamapS | Daviey: Hrm, I figure raise it now because we know we'll need it then. | 23:51 |
| hazmat | jimbaker, sounds good | 23:51 |
| jimbaker | seeing trunk fail again: http://paste.ubuntu.com/627672/ (just running ./test ensemble.control) | 23:57 |
| niemeyer | jimbaker: Are you sure that's up to date? | 23:58 |
| niemeyer | jimbaker: Ah | 23:58 |
| niemeyer | jimbaker: find -name '*.pyc' -exec rm {} \; | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!