| _mup_ | ensemble/expose-provision-service-hierarchy r243 committed by jim.baker@canonical.com | 00:21 |
|---|---|---|
| _mup_ | Method cleanup, more tests | 00:21 |
| _mup_ | ensemble/expose-provision-service-hierarchy r244 committed by jim.baker@canonical.com | 01:59 |
| _mup_ | Guard refactoring on watching exposed services | 01:59 |
| _mup_ | ensemble/expose-provision-service-hierarchy r245 committed by jim.baker@canonical.com | 02:08 |
| _mup_ | Name refactoring | 02:08 |
| niemeyer | Bed time! | 02:48 |
| niemeyer | NIght all | 02:48 |
| _mup_ | ensemble/expose-provision-service-hierarchy r246 committed by jim.baker@canonical.com | 04:42 |
| _mup_ | Naming and PEP8 | 04:42 |
| _mup_ | ensemble/expose-provision-service-hierarchy r247 committed by jim.baker@canonical.com | 05:57 |
| _mup_ | Testing through the check_service_unit_ports funnel | 05:57 |
| _mup_ | ensemble/expose-provision-service-hierarchy r248 committed by jim.baker@canonical.com | 05:59 |
| _mup_ | Removed unnecessary code in guard | 05:59 |
| _mup_ | ensemble/expose-provision-service-hierarchy r249 committed by jim.baker@canonical.com | 06:05 |
| _mup_ | Uncommented raising StopWatcher | 06:05 |
| _mup_ | ensemble/watching-godot-redux r250 committed by kapil.thangavelu@canonical.com | 12:20 |
| _mup_ | change the ordering to ensure we wait on a second callback after a failure callback. | 12:20 |
| _mup_ | ensemble/watching-godot-redux r251 committed by kapil.thangavelu@canonical.com | 12:31 |
| _mup_ | merge trunk and resolve conflict | 12:31 |
| hazmat | i'm seeing a few errors on trunk | 12:37 |
| niemeyer | Good morning! | 12:48 |
| niemeyer | hazmat: What kind of error? | 12:48 |
| kim0 | Morning everyone | 13:36 |
| niemeyer | kim0: Morning! | 13:42 |
| kim0 | hey | 13:42 |
| hazmat | niemeyer, have you thought about dns integration | 14:18 |
| hazmat | niemeyer, i've been thinking about how we've laid out port exposing, and one case that concerned me | 14:18 |
| niemeyer | hazmat: Not enough | 14:18 |
| niemeyer | hazmat: What kind of problem were you referring to earlier, btw? | 14:19 |
| hazmat | If we don’t have static information, how can we prevent port conflicts when doing unit placement, short answer, we can’t. Now we need a way for services to interrogate information on open ports on their machine so they can select a non-conflicting port (container network is separate than the machine so no way of identifying within the container). So let’s say thats fine for app servers, now we connect a proxy service to them, and we have a def | 14:19 |
| hazmat | ined traffic port, ideally we’d just assign a dns entry to the proxy service, but now we have a problem in that we have a port offset on the url. | 14:19 |
| hazmat | niemeyer, trunk unit test failures, and several additional ones on the godot branch. | 14:19 |
| hazmat | niemeyer, one of them is fixed in godot, but the other two are new | 14:20 |
| niemeyer | hazmat: Haven't seen that yet, no | 14:20 |
| hazmat | https://pastebin.canonical.com/47875/ | 14:21 |
| hazmat | failures | 14:21 |
| niemeyer | hazmat: I don't understand the problem you're describing re. DNS | 14:21 |
| hazmat | niemeyer, its tangentially dns in that case, but the use case is i want to assign a domain name to some service i've deployed, and i don't want to have any port offset as part of the url | 14:22 |
| hazmat | without unit placement consideration of ports taking place, there will be conflicts | 14:22 |
| niemeyer | hazmat: I don't really understand what you mean by that | 14:23 |
| niemeyer | hazmat: Yes, we know about the conflict problem.. we've discussed that before, but I don't understand what's new about it | 14:23 |
| hazmat | those conflicts are silent incidentally.. till the ports are exposed, (different network devices between the container and host) those conflicts would need to be resolved by a mechanism which would allow the unit to determine an unallocated port | 14:24 |
| hazmat | okay so now we have a bunch of appservers for this to be exposed web service, and then we connect a proxy to them, and want to assign the domain name to the proxy | 14:24 |
| hazmat | hmm | 14:24 |
| hazmat | so in the end we get a proxy with a domain name which contains a non port 80 response.. the question is how to avoid that | 14:26 |
| niemeyer | hazmat: We put the port on 80? | 14:26 |
| niemeyer | kim0: Review for tutorial delivered! | 14:28 |
| hazmat | niemeyer, that assumes we new what port a service unit was going to use | 14:30 |
| hazmat | knewd | 14:30 |
| niemeyer | hazmat: Indeed it does | 14:30 |
| niemeyer | hazmat: All of the discussion about ports we had before applies. | 14:31 |
| niemeyer | robbiew! | 15:10 |
| niemeyer | robbiew: Welcome to our little party | 15:10 |
| robbiew | heh | 15:10 |
| robbiew | getting crowded in here | 15:11 |
| hazmat | skype goes dark | 15:11 |
| niemeyer | hazmat: What? | 15:11 |
| hazmat | http://www.thinq.co.uk/2011/5/26/skype-crashes-and-burns/ | 15:11 |
| kim0 | The MS effect | 15:12 |
| niemeyer | Man.. | 15:12 |
| niemeyer | They were probably helding sysadmins hostage in a room before they managed to sell it. | 15:13 |
| niemeyer | It's too soon to blame MS for that | 15:14 |
| niemeyer | Skype was always extremely sensitive to the wind direction | 15:14 |
| hazmat | true enough | 15:15 |
| _mup_ | ensemble/trunk r232 committed by gustavo@niemeyer.net | 15:20 |
| _mup_ | Merging doc-typo branch from mthaddon. [r=niemeyer] | 15:20 |
| _mup_ | This fixes a couple of minor issues in the documentation. | 15:20 |
| _mup_ | ensemble/trunk r233 committed by gustavo@niemeyer.net | 15:26 |
| _mup_ | Merged doc-fixes branch by Ahmed. [r=kapil,niemeyer] | 15:26 |
| _mup_ | A couple of tweaks in the documentation. | 15:26 |
| _mup_ | ensemble/watching-godot-redux r252 committed by kapil.thangavelu@canonical.com | 15:55 |
| _mup_ | fix missing return from last trunk merge conflict resolution | 15:55 |
| SpamapS | niemeyer: how's the daily build PPA going? | 16:29 |
| koolhead17 | niemeyer: found u on Twitter :P | 16:36 |
| niemeyer | SpamapS: Sorry, was on a call | 16:55 |
| niemeyer | SpamapS: It's going *very* well now :) | 16:55 |
| niemeyer | SpamapS: I've suffered somewhat to get through the maze, but we've got ZooKeeper 3.3.3 up and building fine on Oneiric, Natty and Maverick now | 16:55 |
| niemeyer | SpamapS: and I'll push the other packages after I manage to do a round of reviews after lunch | 16:56 |
| niemeyer | I have to unblock hazmat, jimbaker, and bcsaller first on reviews | 16:56 |
| niemeyer | Actually, bcsaller and jimbaker only for now | 16:56 |
| niemeyer | I'll grab some lunch now.. back in a bit | 16:57 |
| SpamapS | niemeyer: sweet. I think we'll actually upload Zookeeper into Oneiric and we can probably push to get it into lucid/natty backports as well. | 17:03 |
| hazmat | bcsaller, i'm looking at ensemble.hooks.tests.test_communications.TestCommunications.test_get_no_such_unit it appears that sometimes the exception doesn't get translated back to NoSuchUnit, and instead just comes out as an Exception class, just curious if that rings any bells | 17:05 |
| bcsaller | hazmat: no, doesn't ring a bell | 17:08 |
| bcsaller | hazmat: I can can look at it later, but I'm prepping for that conference today, going to give a lightning talk | 17:09 |
| hazmat | bcsaller nice | 17:22 |
| hazmat | bcsaller, i think it might be an amp issue | 17:22 |
| bcsaller | hazmat: there was a change there that allowed passing exceptions back in their raw form to aid in debugging. in hook/protocol.py :: Exception: "Exception" It could be that its upcasting the exception to pass its message over the wire? | 17:24 |
| hazmat | bcsaller, not sure, the they have different value tags for the wire protocol so its not clear, its a test that fails sometimes.. sometimes it works | 17:25 |
| SpamapS | So I'm curious.. I had this crazy idea that you could write a "Local" machine provider that just does stuff on your local machine. Is there any reason this won't work other than sometimes services will want to listen on the same port? | 17:32 |
| hazmat | SpamapS, no reason offhand | 17:38 |
| hazmat | SpamapS, the lxc provider was going to be looking at doing effectively that via libvirt | 17:38 |
| hazmat | SpamapS, one could also concievably ditch the lxc provider, if you where willing to run arbitrary formulas on your laptop.. but currently the placement logic for a unit wants a 1-1 mapping machine to unit. | 17:39 |
| SpamapS | I feel quite strongly that we will lock ourselves out of the lower end sites if we don't enable deploying to less than 1 machine per service unit. | 17:40 |
| hazmat | SpamapS, absolutely, we can address separately in the ec2 lxc integration | 17:41 |
| hazmat | but that's distinct to running formulas local to the admin client | 17:41 |
| SpamapS | I think it would be cool if deploy or add-unit had a '--machine ##' parameter | 17:53 |
| hazmat | bcsaller, yeah.. its picking the generic exception one sometimes, because its going through the dictionary the result is random | 17:58 |
| bcsaller | huh, maybe I should just take that back out | 17:58 |
| bcsaller | it does slightly easy development though | 17:59 |
| bcsaller | SpamapS: I'd still like to see a local provider that just fires up fully virtualized instances. That way you have some notion of containment and you don't mess with the local package space | 18:00 |
| _mup_ | ensemble/watching-godot-redux r253 committed by kapil.thangavelu@canonical.com | 18:01 |
| _mup_ | fix unreliable tests from trunk, dont trap generic exceptions in the protocol as it interferes with more specific exception handling, the generic will get a ampremoteexception by default | 18:01 |
| hazmat | bcsaller, doesn't the generic amp exception work for that? | 18:01 |
| hazmat | bcsaller, looks like it will just throw the description with an UnknownRemoteError which is about the same as what was there before instead of a generic Exception class | 18:02 |
| hazmat | s/class/instance | 18:02 |
| bcsaller | hazmat: if its not in the list you don't see it. The amp exception just shows up as unknown error, if there is better native support for that I am unaware | 18:02 |
| hazmat | bcsaller, hmm so the unknownremote error is a probably treated as a fatal exception then | 18:03 |
| bcsaller | I believe so, yes | 18:03 |
| SpamapS | bcsaller: yes, I think LXC is totally the way to go. I'm really whining about two things. 1) no lxc, 2) no way to specify which physical machine to run the LXC container on. | 18:04 |
| bcsaller | SpamapS: I wasn't talking about LXC, I think the fast path is to fire up full instances | 18:04 |
| bcsaller | its heavy, but for testing small, 2-4 node deployment scripts it should be ok | 18:05 |
| SpamapS | er, you mean kvm? | 18:05 |
| bcsaller | yeah, for example or any of the others | 18:06 |
| SpamapS | Sure, in fact really that should just be "libvirt" | 18:06 |
| _mup_ | ensemble/trunk r234 committed by kapil.thangavelu@canonical.com | 18:06 |
| _mup_ | merge waiting-for-godot [r=niemeyer][f=778628] | 18:06 |
| _mup_ | Improve watch apis to wait for their initial invocation against the | 18:06 |
| _mup_ | current state before returning. This allows for much better | 18:06 |
| _mup_ | synchronization betewen the invoker and background activity. Also | 18:06 |
| _mup_ | fixes some broken tests from trunk. | 18:06 |
| bcsaller | that seems like a small project that would still be a real gain | 18:07 |
| _mup_ | ensemble/ensemble-deploy-auto-resolve r225 committed by kapil.thangavelu@canonical.com | 18:07 |
| _mup_ | merge trunk | 18:07 |
| bcsaller | it might also help us identify where we currently depend on the provider too much in the example formula | 18:07 |
| bcsaller | things like curl to the metadata server | 18:08 |
| _mup_ | Bug #788735 was filed: deploy command with auto-resolve dependency support <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/788735 > | 18:10 |
| hazmat | bcsaller, SpamapS yeah.. any desktop integration should probably go via libvirt, it takes care of some of the networking/bridge/dnsmasq setup.. which we'd rather not touch on an end user's computer. | 18:13 |
| * niemeyer waves | 18:16 | |
| SpamapS | bcsaller: I'm not sure why we curl the hostname from the metadata server. `hostname -f` is perfectly accurate. :) | 18:51 |
| bcsaller | I thought that returned the internal local name | 18:52 |
| bcsaller | which for the cases its used for would be fine as well, but because things like apache dir names were using the public name it became a pattern | 18:53 |
| jimbaker | we actually make a distinction between the internal name and the external name; the latter one would require this metadata server usage | 18:54 |
| jimbaker | i know we talked at some point about making something like "ensemble info" for this type of service unit properties | 18:54 |
| SpamapS | It should be provided via tools that query the machine provider. | 18:54 |
| SpamapS | relation-get needs a local partner | 18:55 |
| SpamapS | "tell me about myself" | 18:55 |
| SpamapS | because one of the formulas I want to write is a DNS server formula | 18:56 |
| SpamapS | so we can have route53 type service in ensemble | 18:56 |
| SpamapS | But it requires that there be a generic relation.. "info", that I can always relate to. | 18:57 |
| SpamapS | (which I plan to implement in each formula until ensemble does it) | 18:57 |
| jimbaker | SpamapS, i know that we have been trying to avoid generic relations like this, fwiw | 18:57 |
| SpamapS | *every* service relationship seems to at one level benefit from knowing the IP of the other side | 18:58 |
| jimbaker | my original plan for expose was to use something a generic relation concept too | 18:58 |
| SpamapS | I was just working on adding @'$remote_ip' to the mysql formula in principia | 18:58 |
| SpamapS | so that the user given can only be used from the one unit's ip | 18:59 |
| jimbaker | SpamapS, the ip we can probably special case on the relation itself, it would seem | 18:59 |
| SpamapS | Lets talk though the use case for a DNS service | 18:59 |
| SpamapS | I want to deploy named .. and relate it to haproxy | 19:00 |
| SpamapS | I don't want to use the actual external IP of the instance though | 19:01 |
| SpamapS | I want to use an elastic IP... hrm | 19:01 |
| SpamapS | This is too tricky for IRC, n/m ;) | 19:01 |
| jimbaker | SpamapS, maybe you can discuss this over our standup, which is scheduled for this time anyway? | 19:02 |
| jimbaker | bcsaller, hazmat, niemeyer - speaking of which, standup? | 19:02 |
| hazmat | jimbaker, skype is dying on me constantly.. i could mumble | 19:03 |
| jimbaker | hazmat, i dpn | 19:03 |
| jimbaker | i don't have a headset w/ me... that's going to be tough | 19:03 |
| hazmat | jimbaker, push to talk works | 19:03 |
| SpamapS | jimbaker: push to talk works fine on mumble | 19:03 |
| SpamapS | jinx! | 19:03 |
| niemeyer | hazmat: Sounds good | 19:03 |
| bcsaller | I don't have that configured on this computer yet, but I can try to set it up again | 19:03 |
| jimbaker | my recollection is that you needed push to talk + headset to get anything decent, but ok | 19:04 |
| SpamapS | I've found that the right super key works well | 19:04 |
| jimbaker | let me install | 19:04 |
| SpamapS | headset helps w/ the echo but it can work w/o it | 19:04 |
| niemeyer | I've had success with the auto-detection of voice on today's meeting | 19:06 |
| jimbaker | are we going to use the canonical mumble server, or is there an open one for ubuntu? | 19:08 |
| hazmat | jimbaker, its on the wiki | 19:09 |
| jimbaker | i only see the canonical mumble server there... | 19:09 |
| hazmat | bcsaller, ping | 19:11 |
| bcsaller | setting it up | 19:11 |
| === deryck[lunch] is now known as deryck | ||
| jimbaker | not taking off just yet, of course :) but for standup tuesday | 19:47 |
| kim0 | niemeyer: I applied the modifications for hook execution traces .. since initially I was merging into the bashified branch, I ended up with a new propose for merge | 19:54 |
| kim0 | https://code.launchpad.net/~kim0/ensemble/adding-hook-traces-to-readme-for-bashified-example | 19:54 |
| kim0 | https://code.launchpad.net/~kim0/ensemble/adding-hook-traces-to-readme-for-bashified-example/+merge/62537 that is | 19:54 |
| niemeyer | kim0: That's fine, thanks a lot for pushing it | 19:55 |
| kim0 | cool | 19:55 |
| kim0 | niemeyer: thanks for the review to the contribution doc .. I'll add a more concrete example to that | 19:55 |
| kim0 | I thought this would be simpler to follow .. but yeah, it's probably not | 19:56 |
| niemeyer | kim0: Awesome! This is a critical piece | 19:56 |
| niemeyer | bcsaller: ping | 20:22 |
| bcsaller | niemeyer: pong, haven't left yet | 20:22 |
| niemeyer | bcsaller: Oh, cool.. just a small note re. the review: [5] seems untouched | 20:23 |
| bcsaller | checking | 20:23 |
| niemeyer | bcsaller: Re. [6], thanks for the test. We really need tests specific to the feature, otherwise you remove the other method later and this logic goes untested | 20:24 |
| niemeyer | bcsaller: It would be fine to move the logic from the other tests though | 20:24 |
| niemeyer | bcsaller: and only test on the layer above what you haven't already tested for the layer below | 20:24 |
| niemeyer | bcsaller: Having a ton of logic on a layer below which is only touched by tests for upper layers is the issue | 20:24 |
| bcsaller | yeah, looks like maybe I did miss [5], I think I made changes related to [9] and thought I got it | 20:24 |
| niemeyer | bcsaller: No worris | 20:25 |
| niemeyer | es | 20:25 |
| niemeyer | bcsaller: re [8], is there a reason why you didn't use our schema framework in the same way we do for metadata and configuration? | 20:27 |
| bcsaller | niemeyer: yes, the formula author has to write these things, so either I did something simple or I had to write a yaml serialization of the schema denifnition | 20:28 |
| niemeyer | bcsaller: I don't understand.. how's that different from the metadata file, or the environments configuration file? | 20:28 |
| bcsaller | because the schema is coded in Python by us for the metadata file, for the config.yaml they are writing a validation spec of their own | 20:29 |
| niemeyer | bcsaller: No, it's not.. | 20:29 |
| niemeyer | bcsaller: The schema is a generic piece of framework which you can use to parse plain dictionaries and values | 20:29 |
| niemeyer | bcsaller: and is used both for the metadata and the environments file, which are also written by hand | 20:30 |
| bcsaller | yes, but the desc of that is done in python | 20:30 |
| niemeyer | bcsaller: Yes, and we can do the same for the config yaml, I believe | 20:30 |
| niemeyer | ? | 20:30 |
| bcsaller | I didn't want formula authors to have to write in python to use the schema system | 20:30 |
| niemeyer | bcsaller: They don't have to.. | 20:30 |
| niemeyer | bcsaller: We're talking about validating a yaml file | 20:30 |
| bcsaller | oh, you mean to validate that the config.yaml is correct | 20:31 |
| niemeyer | bcsaller: Yes | 20:31 |
| niemeyer | bcsaller: Point [8] in the review | 20:31 |
| bcsaller | that's fine, yes, I implemented validation of option values | 20:31 |
| niemeyer | bcsaller: Yes, and why isn't that written using our schema framework? | 20:31 |
| bcsaller | I think I misunderstood in that case, oh well we get a new feature | 20:31 |
| niemeyer | bcsaller: in declarative style.. that was the actual questoin | 20:31 |
| bcsaller | validating the config.yaml (which isn't really done now) using the schema would be fine | 20:32 |
| niemeyer | bcsaller: Yeah, that was point [8] | 20:32 |
| niemeyer | bcsaller: You can do that in a follow up branch | 20:32 |
| bcsaller | I have no objection to that, I thought you wanted to have them write schema to validate the options they allow for the service | 20:32 |
| niemeyer | bcsaller: Nope | 20:32 |
| niemeyer | bcsaller: We just have to validate the file format before bundling a formula | 20:32 |
| niemeyer | bcsaller: Otherwise it will blow up when the formula is deployed only, which would be quite sad | 20:33 |
| bcsaller | ok, I can add that tonight, it's a small change | 20:33 |
| niemeyer | bcsaller: Should be indeed, no rush, and thanks! | 20:34 |
| niemeyer | bcsaller: Just [5] then, plus that in a separate branch | 20:36 |
| niemeyer | bcsaller: and +1 | 20:36 |
| bcsaller | ok, cool | 20:36 |
| _mup_ | ensemble/test-api r235 committed by kapil.thangavelu@canonical.com | 20:36 |
| _mup_ | extract the test api base class from the auto resolve work | 20:36 |
| jimbaker | https://ensemble.ubuntu.com/kanban/dublin.html is not updating again | 21:25 |
| _mup_ | Bug #788825 was filed: Update watch_exposed_flag <Ensemble:In Progress by jimbaker> < https://launchpad.net/bugs/788825 > | 21:29 |
| niemeyer | jimbaker: Indeed :-( | 22:22 |
| niemeyer | jimbaker: Will ping is | 22:22 |
| niemeyer | jimbaker: Will ping IS | 22:22 |
| niemeyer | jimbaker: Meanwhile: http://people.canonical.com/~niemeyer/dublin.html | 22:22 |
| niemeyer | jimbaker: Paul had a look at it and it should be unstuck now | 22:29 |
| jimbaker | niemeyer, sounds good | 22:31 |
| jimbaker | niemeyer, it's interesting that the needs release column has what looks like a different template being applied - apparently from the css - and that it's different from what is on your personal pages | 22:34 |
| niemeyer | jimbaker: Hmm | 22:37 |
| niemeyer | jimbaker: I see what you mean | 22:38 |
| niemeyer | jimbaker: Weird indeed | 22:38 |
| niemeyer | Looks a bit nicer actually | 22:38 |
| jimbaker | agreed about https://ensemble.ubuntu.com/kanban/dublin.html having a better layout | 22:40 |
| poolie | hi niemeyer | 22:44 |
| niemeyer | poolie: Hey! | 22:44 |
| niemeyer | Man, I'm very excited about the whole bzr branch + PPA = daily build thing | 22:46 |
| poolie | so you should be :) | 22:47 |
| niemeyer | :-) | 22:48 |
| niemeyer | and another package set is churning! | 22:54 |
| niemeyer | Another one bites the dust: https://code.launchpad.net/~ensemble/+recipe/txaws | 23:10 |
| poolie | i just last week stopped them sending excessive email | 23:33 |
| poolie | which is a good start | 23:33 |
| niemeyer | poolie: Indeed, no issues on that area | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!