[00:03] hazmat, ok, just making sure [00:04] hazmat, i did just triage bug 846055 as invalid after some more analysis [00:04] <_mup_> Bug #846055: Occasional error when shutting down a machine from security group removal < https://launchpad.net/bugs/846055 > [00:04] jimbaker, cool [00:05] (related to my fix of bug 863510 a little bit ago) [00:05] <_mup_> Bug #863510: destory-environment errors and hangs forever < https://launchpad.net/bugs/863510 > [00:18] * hazmat noodles on a charm browser [02:38] ifup /win 20 [12:02] morning all [12:02] local provider is working really well for me [12:03] however can't upgrade charms - http://paste.ubuntu.com/703911/ [12:03] not the end of the world as destroying restarting is only a couple of minutes :-) [12:04] jamespage, g'morning [12:04] morning hazmat [12:05] oh.. ugh [12:06] i forgot that the unit agent downloads the charm... [12:06] so a filesystem solution isn't going to work very well [12:06] since the unit and machine agent both need access and are on separate fs mounts [12:07] jamespage, yeah.. upgrade is definitely broken [12:28] <_mup_> Bug #869945 was filed: upgrade broken for local provider < https://launchpad.net/bugs/869945 > [12:43] can i ask a quick question about the juju source again, please? [12:43] i'm trying to understand the machine startup process [12:43] rog, go for it [12:44] in ec2/__init__.py, there are these two lines: [12:44] constraints = machine_data.get("constraints", {}) [12:44] return EC2LaunchMachine(self, master, constraints).run(machine_id) [12:45] rog, so contraints are how we get the image [12:45] or what sort of machine we run, or where we run it [12:46] i'm wondering where the zookeepers argument to EC2LaunchMachine.start_machine comes form [12:46] s/form/from/ [12:47] the second line starts the machine, the master param is whether we start a a zookeeper and provisioning agent on the node by default. the machine id is to inform the machine of its zk machine id so its machine agent can connect back to the right place. [12:47] (and i think i've got confused over the two start_machine implementations... let me have another look) [12:47] ah, machine_id is the machine id of the zookeeper machine, not the new machine? [12:48] rog yes.. [12:48] the provider machine id is only known after the instance has been launched [12:49] rog, some of it is a little confusing because of the desire to reuse implementation and lots of similiar named things... it looks like constraints doesn't actually determine machine type now that i look at it, just image selection. [12:50] rog, start_machine gets called by a base class in common/launch.py [12:50] from the launchmachine base class run method [12:51] hazmat: yeah, it's winding in and out of the base class. [12:51] i was confused [12:51] i think i see it now [12:51] rog, it uses the findzookeeper class to get the zks to populate the arg to start_machine [12:51] rog, cool [12:51] yeah, i had looked at that before, but hadn't made the connection [12:51] thanks [12:51] np [12:52] <_mup_> juju/hooks-with-noninteractive-apt r395 committed by kapil.thangavelu@canonical.com [12:52] <_mup_> set debian noninteractive [12:53] hazmat: one last, Q: where's the run(machine_id) method defined? [12:54] rog which one? [12:54] the one in return EC2LaunchMachine(self, master, constraints).run(machine_id) [12:54] rog, its the primary entrance point into a LaunchMachine class, its invoked by the provider facade' start_machine method defined in each provider package [12:55] rog, its defined on the common/launch.py LaunchMachine class [12:56] so it is. grep fail. [12:57] ah, so machine_id *is* the id of the new machine, not of the zookeeper machine [12:59] thanks again [13:01] bug 863629 [13:01] <_mup_> Bug #863629: libvirt-lxc: virFileOpenTtyAt can't be called on /some/other/dev/pts

< https://launchpad.net/bugs/863629 > [13:03] hazmat: lp:810649 (Revision number should be optional in metadata) has now been fully addressed, I think; but not in the manner suggested in the bug [13:03] hazmat: shall I mark it invalid? [13:03] fwereade, i'm not sure [13:03] fwereade, the common case the bug is raising isn't addressed [13:04] which is i modify a formula, go to deploy it, and transparently the on in storage is used instead [13:04] s/on/one [13:04] hazmat: hmm, you're right [13:23] fwereade, so i started to look at exposing the provider storage over http to allow units to download for upgrades [13:23] hazmat: oh yes? [13:24] fwereade, yeah.. i forget the unit agents download the charms directly for upgrades only [13:24] but i ran into the issue that the charm urls (from provider storage) aren't the same if i bind the webserver on localhost in the host [13:24] its localhost in the provider and 192.168.122.1 in the unit [13:25] * hazmat wonders if he should break for coffee [13:26] what does 192.168.122.1 resolve to in the host? [13:27] ah.. i can bind it explicitly to that interface probably [13:27] fwereade, it is the host [13:27] yeah.. that's the ticket [13:27] fwereade, thanks [13:32] hazmat: yw [13:39] Morning all! [13:39] Sorry, a bit late.. there was a fierce fight with bed this morning [13:39] heya niemeyer [13:40] fwereade: yo! [13:40] fwereade: Some of the fight was useful.. I woke up with a thought in my head about errors and the store [13:40] niemeyer: we could certainly make the error handling much more sophisticated [13:40] fwereade: We need to tell people about non-existent and bad charms somehow [13:41] niemeyer: bad in what sense? [13:41] fwereade: I think it's straightforward, but we need a patch soonish, and support on the fake thingy to see if it's working [13:41] fwereade: bad as in there's content in a branch that the store can't pack [13:41] niemeyer: ah, ok [13:42] niemeyer: the fake needs some work anyway, it's only barely good enough to tell that it ought to work [13:42] fwereade: My suggestion is this: [13:42] niemeyer: and doesn't even consider usernames [13:43] fwereade: let's introduce a couple of additional keys for each entry returned through /charm-info [13:43] fwereade: "warning", and "error" [13:43] fwereade: The store would take these like that: [13:43] Erm, sorry [13:43] fwereade: The client would take these like that: [13:44] 1) If there's a "warning", print it as a warning (duh) and continue using the received info normally [13:44] niemeyer: daring and unorthodox, but I can get behind that [13:44] :p [13:44] 2) If there's an "error" raise a CharmError with the received string and the given charm URL [13:44] niemeyer: fair enough; what about multiple errors? [13:45] niemeyer: well, I guess we don't need to worry about them yet [13:45] niemeyer: API sounds sensible though [13:45] fwereade: Yeah, we'll sort them out in the server side for now [13:45] fwereade: Please note these go inside each individual charm's json doc [13:45] fwereade: So, e.g.: [13:45] fwereade: {charm_url: {"error": "no metadata.yaml found"}} [13:45] niemeyer: yep, they're charm info not request info [13:45] fwereade: Yeah, +1 [13:46] niemeyer: sounds good, I'll have a go at that now then [13:46] fwereade: Thanks! [13:46] SpamapS: We have a couple of bug fixes in the pipeline, FYI [13:47] SpamapS: One is merged, the other fwereade is working on right now [13:48] <_mup_> Bug #870000 was filed: client should understand errors and warnings from the charm store < https://launchpad.net/bugs/870000 > [13:50] niemeyer: suggestion: list of warnings, rather than restricting ourselves to just one? [13:51] fwereade: List of warnings and list of errors? Hmm [13:51] niemeyer: I'd imagined an error to be a "you're boned, processing stops now" condition [13:52] niemeyer: whereas if a warning doesn't stop anything, more warnings are possible [13:52] fwereade: Yeah, but there is always the "you're _seriously_ boned" case [13:52] fwereade: +1 on lists for both [13:53] niemeyer: ok, sounds good [13:53] niemeyer, are you planning on doing a web ui on the store to start? [13:53] fwereade: and calling them "warnings"/"errors" instead [13:53] niemeyer: indeed [13:53] hazmat: Not to start.. I'm planning to maybe get it in time at all :-) [13:53] niemeyer, i was playing around with something yesterday, just because i needed a list of interfaces available from other formulas [13:54] hazmat: Nice [13:54] hazmat: Did you put the client interface to test? [13:54] niemeyer, i'm just querying lp and scanning bzr branches [13:54] hazmat: Ah, ok [13:54] niemeyer, is there a store endpoint up already? [13:54] hazmat: Nope [13:55] SpamapS, there's one more bug in progress on a fix for local provider upgrades as well [13:55] SpamapS, feel free to merge the deb dir removal as well [13:56] hazmat, SpamapS: Erm, hold on? [13:56] hazmat, SpamapS: Please don't remove the debian dir now.. the PPA depends on it, this isn't important right now I'd guess? [13:57] niemeyer, its not to me.. but SpamapS had a pending branch out for a while regarding [13:57] niemeyer, i pushed it to the review queue, and its currently awaiting a merge [13:58] hazmat: Ok, I'm pushing it back then [13:58] hazmat: and retargetting to the florence milestone [13:59] hazmat: There's no reason for us to rush this in and have to fix the PPA _right now_ [13:59] niemeyer, fine by me [14:20] Review queue is empty [14:21] hazmat: and man, good catch on the DEBIAN_FRONTEND [14:22] Totally forgot about it [14:35] niemeyer: i'm still waiting for some feedback on the changes i made on my merge proposals in response to your comments, BTW. not that it's that crucial. [14:35] rog: Yeah, I know.. I've been focusing on the release since yesterday [14:36] niemeyer: that's fine, just checking. [14:36] rog: The changes to the Server interface I think should really be postponed, btw [14:36] niemeyer: you mean the factoring out of the service package? [14:36] rog: Yeah [14:36] rog: I'll check your branches now [14:36] niemeyer: i've gone with you on that, yes [14:36] rog: Cool, cheers [14:37] niemeyer: i've merged back in the fixes that were in that branch [14:37] rog: Sweet, checking it out [14:38] rog: Your juju branch is ready for action, btw [14:38] ? [14:40] ah, you mean fix-tutorial-with-expose? [14:44] niemeyer: when i try to push to lp:juju, i get: [14:44] bzr: ERROR: Cannot lock LockDir(lp-82305296:///%2Bbranch/juju/.bzr/branchlock): Transport operation not possible: readonly transport [14:44] rog: You probably have a wrong url there [14:44] ok [14:44] rog: What's "bzr info" telling you about the push location? [14:44] i did an explicit push [14:45] % bzr push lp:juju [14:46] http://paste.ubuntu.com/703998/ [14:59] * hazmat is annoyed by twistd === wrtp is now known as rog [15:05] odd [15:06] hazmat: http://paste.ubuntu.com/704017/ [15:06] not sure libzookeeper-java is going to give us quite enough for the local provider [15:06] jamespage, ah.... that's why we wanted zookeeperd [15:06] jamespage, we can work around that [15:06] well zookeeper is actually enough [15:06] but its a bug [15:07] that way nothing starts - but you still get the configuration files [15:08] jamespage, i think zookeeperd actually setups /etc/zookeeper/conf [15:08] we source it for env variables [15:08] I just tried on a clean server install - zookeeper is enough [15:08] jamespage, cool [15:08] zookeeperd just installs the init scripts I think [15:09] QQs: what's the difference between machine_id and instance_id, and why does ec2.securitygroup.open_provider_port take both a machine and machine_id? [15:09] ( can't you get a machine_id from a machine?) [15:09] jamespage, i'm not sure who set its up i see /etc/zookeeper/conf_example from zookeeper .. but it looks like its some sort of script that setups the actual directory /etc/zookeeper/conf [15:10] hazmat, the configuration is managed by the alternatives system [15:10] (I think) [15:10] * jamespage goes to look [15:10] * jamespage worries is memory is not what it used to be [15:12] hazmat: yep - http://tinyurl.com/6a88tag [15:12] * jamespage not so worried anymore [15:13] I personally don't like that much - inherited from previous package maintainer [15:15] jamespage, well your the maintainer now.. :-) [15:15] jamespage, thanks, i'll update the pkg check and docs for zookeeper [15:16] <_mup_> juju/local-provider-docs r394 committed by kapil.thangavelu@canonical.com [15:16] <_mup_> update dependency s/libzookeeper-java/zookeeper [15:16] jamespage, alternatively we could manually scan /usr/share/java for the ones we need (minus version numbers).. but its more of a slippery slope [15:16] libs we need that is [15:16] bcsaller, you mentioned you might have some additions to the local provider docs? [15:17] for some reason twistd won't daemonize for me.. [15:17] * hazmat smells a rabbit hole [15:28] wrong cli arg [15:35] niemeyer: [15:35] package provider [15:35] // Machine represents a running machine instance. [15:35] type Machine interface { [15:35] Id() string [15:35] DNSName() string [15:35] PrivateDNSName() string [15:35] } [15:35] type Port struct { [15:35] Proto string [15:35] Number int [15:35] } [15:35] type Interface { [15:35] // StartMachine asks for a new machine instance to be created. [15:36] // The id of the new machine is given by id. [15:36] // The currently running list of zookeeper machines [15:36] // is given by zookeepers. [15:36] // It returns the new Machine (which is not necessarily [15:36] rog: paste.ubuntu.com [15:36] // running yet). [15:36] rog: paste.ubuntu.com [15:36] rog: paste.ubuntu.com [15:36] rog: paste.ubuntu.com [15:36] StartMachine(id string, zookeepers []Machine) (Machine, os.Error) [15:36] // Machines returns the list of currently started instances. [15:36] Machines() ([]Machine, os.Error) [15:36] // OpenPort opens a new port on m to the outside world. [15:36] WTF [15:36] OpenPort(m Machine, p Port) os.Error [15:36] // ClosePort closes the port on m. [15:36] ClosePort(m Machine, p Port) os.Error [15:36] // OpenedPorts returns the list of currently open ports [15:36] // on m. [15:36] OpenedPorts(m Machine) ([]Port, os.Error) [15:36] // FileURL returns a URL that can be used to access the given file. [15:36] URL(file string) (string, os.Error) [15:36] // Get returns the contents of the given file as a string. [15:36] Get(file string) (string, os.Error) [15:36] // Put writes contents to the given file. [15:36] Put(file string, contents string) os.Error [15:36] // Destroy shuts down all machines and destroys the environment. [15:36] Destroy() os.Error [15:36] } [15:36] // Register registers a new provider. Name gives the name [15:36] // of the provider. The connect function is to be used to connect [15:36] // to the given provider type; attrs gives any provider-specific [15:36] // attributes; and it should return the newly created provider.Interface. [15:36] // [15:48] muchos apologies folks [15:48] it seems that xclip does not work [15:50] rog: It worked very well apparently! ;-) [15:50] rog: Btw, your url was indeed wrong [15:50] rog: The trunk branch belongs to the juju team [15:50] rog: which you're part of [15:50] rog: So to be able to commit/push, you need to be using it as lp:~juju/juju/trunk [15:51] rog: Please be extra careful there [15:52] niemeyer: no, xclip didn't work. i'd told it to hold the URL! [15:52] rog: LOL [15:52] rog: update-server-interface reviewed [15:52] rog: A few comments, but good stuff overall [15:52] it seems that X clipboards are fundamentally broken, a fact which i knew once, but had forgotten. [15:52] rog: Yeah, I do know that one [15:52] rog: For a while! [15:52] * niemeyer => lunch [15:53] niemeyer: i'm also off for the weekend [15:53] rog: Nice, enjoy! [15:53] niemeyer: have a good one! [15:53] rog: Btw, warm +1 on "error" [15:53] rog: Let's try to get this one in [15:53] niemeyer: yeah, i think it works ok [15:53] niemeyer: when i thought of it, i was "yeah, that works" [15:53] rog: I was looking for an alternative to the ugly error.Value [15:54] niemeyer: me too. [15:54] rog: But couldn't find anything else.. a standard "error" would be delicious [15:54] yup [15:54] Hmmm.. delicious.. lunch! [15:54] Cheers! [15:54] :) [15:54] ttfn [15:54] have a good w/e [15:59] ha ha! it seems that my editor uses the xclip's default clipboard, but everything else uses a different one. so i can't make xclip work with both. for god's sake. [16:04] force majeur: http://paste.ubuntu.com/704053/ [16:05] that seems to work. i promise that i will try very hard not to do multiline pastes again [16:09] plan9? [16:10] hazmat: a plan 9 compatibility library i use to introduce some sanity into my command line [16:11] hazmat: (and my C programs, when i write them) [16:11] rc is a nice minimal shell for scripting in. [16:11] it fixes some of the fundamental problems with direct sh/csh derivatives [16:13] niemeyer: here's what i was originally trying to paste [16:13] http://paste.ubuntu.com/704063/ [16:14] a sketch of what the juju provider interface might look like in Go. [16:15] any inputs as to whether or not that might be approaching sufficient would be much appreciated. [16:15] right, gotta go. see y'all on monday. [16:16] i'll leave the machine on IRC for a while though, so i'll see any comments. [16:28] rog have a good one [16:55] rog: THe interface looks pretty good [17:02] The new logo is quite neat [17:02] https://juju.ubuntu.com/ [17:05] niemeyer, but i liked the juju man ;-) [17:06] hazmat: Yeah, I liked it as well, but some people didn't [17:15] hazmat: Do you want to have a quick look at this, given we don't have much time to get it wrong: https://code.launchpad.net/~fwereade/juju/charm-store-errors/+merge/78635 [17:16] niemeyer, looking [17:16] niemeyer, i've got one last branch that i need to push as well [17:17] niemeyer, also if you have a chance to look over the local provider docs [17:18] hazmat: I've already reviewed everything this morning [17:18] hazmat: If you have a few comments in the branches that were up [17:18] s/If// [17:18] niemeyer, nice [17:21] niemeyer, fwiw empty tuple is also a single allocation in python () [17:22] hmm.. maybenot === kim0 is now known as kim0|holiday [17:24] interesting.. id func in python has some strange behavior id(object()) == id(object()) [17:26] hazmat, that's almost certainly because the memory is immediately reclaimed, then used again [17:27] if you hold a ref to the first object(), no such equality [17:27] jimbaker, thanks.. that was rather confusing [17:28] so indeed python does a single allocation for the empty tuple [17:28] such object pooling is an important optimization in cpython. also in part why unladen swallow was doomed [17:29] hazmat, correct, i believe that's the behavior in jython too [17:29] again, just an optimization [17:30] http://docs.python.org/library/functions.html#id - Two objects with non-overlapping lifetimes may have the same id() value [17:31] hazmat: Hmm.. that was actually my point [17:31] niemeyer, oh.. i thought you where just referencing go [17:31] hazmat: No, it was a brain hiccup [17:32] hazmat: There's no such thing as a () object in Go [17:33] hazmat: The empty tuple is a rock. :-) [17:33] niemeyer, this interface is a little.. we're expecting to get back json errors and warnings from the charm server? [17:33] embedded in a charm info? [17:33] hazmat: Hmm [17:33] oh.. its a collection url [17:33] hazmat: I'd put it slightly differently [17:34] hazmat: We're expecting to get errors and warnings related to the charm as part of the charm info [17:34] niemeyer, what sort of errors and warnings? [17:34] hazmat: Completely broken charms, for intance [17:34] instance [17:35] hazmat: Since it's a bazaar branch, there's no way to prevent them from being pushed [17:35] niemeyer, i noticed :-).. all kinds of style variations on the pushes [17:35] trunk-1, trunk, random stuff .. its really all over the place already [17:35] it looked like trunk-1 was an attempt to add series to existing trunks [17:36] hazmat: Yeah.. the store will help making them more even [17:36] hazmat: That's not entirely strange.. hmm.. I suspect it may actually have been done by LP itself at some point [17:36] hazmat: Either way, we'll only be looking at /trunk for now [17:36] that leaves about 22 charms [17:37] from ~charmers [17:37] out of 70 some [17:37] numbers change.. practices evolve [17:37] hazmat: Sounds ok.. easy to fix [17:38] hazmat: In practice, we'll want the branch name to become invisible in the future [17:38] niemeyer, definitely [17:38] niemeyer, some times the end segment is actually the charm name.. only for collectd and collectd-node that i saw [17:39] hazmat: You mean it's repeated? Like collectd/collectd? [17:39] * hazmat digs out his script [17:39] niemeyer, yup [17:39] skipping r-B ~charmers/charm/oneiric/collectd/collectd [17:39] skipping r-B ~charmers/charm/oneiric/collectd/collectd-node [17:40] hazmat: Cool.. these should be collectd/trunk and collectd-node/trunk [17:40] hazmat: It also highlights the importance of a strong convention there [17:40] niemeyer, well i expect juju push charm_name .. .will help alot [17:40] hazmat: =1 [17:40] +1 [17:42] review in.. back to networking local provider storage [17:42] fwereade, ^ [17:43] hazmat: Cheers! [18:19] <_mup_> juju/go-charm-bits r14 committed by gustavo@niemeyer.net [18:19] <_mup_> Moved expanding logic to its own function as suggested by Rog [18:19] <_mup_> in the review. [18:19] <_mup_> juju/local-provider-storage r395 committed by kapil.thangavelu@canonical.com [18:19] <_mup_> web access to the local provider disk storage [18:40] <_mup_> juju/local-provider-storage r396 committed by kapil.thangavelu@canonical.com [18:40] <_mup_> wire in storage server into provider bootstrap and destroy-env [18:42] <_mup_> juju/go-charm-bits r15 committed by gustavo@niemeyer.net [18:42] <_mup_> Remove internal filepath.Rel. It's now upstream. [18:44] <_mup_> juju/go r12 committed by gustavo@niemeyer.net [18:44] <_mup_> Merged go-charm-bits branch [r=fwereade,rogpeppe] [18:44] <_mup_> This fixes several problems in the bundling and expansion of [18:44] <_mup_> charms in the Go port. [18:50] niemeyer, jimbaker, bcsaller if you have a moment the network'd local provider storage could use a look [18:51] hazmat, i will take a look [18:51] jimbaker, thanks [19:01] niemeyer, just a fwiw, the zk project ended up linking directly to our out of date docs on zookeeper usage within juju [19:02] hazmat: http://pastebin.ubuntu.com/702946/ [19:26] Hmm [19:26] hazmat: Which docs are that? [19:26] SpamapS: How is the openstack conf going? [19:32] niemeyer, the ones linked to from the zookeeper poweredby wiki page.. they linked (not at my request to) to https://juju.ubuntu.com/docs/internals/zookeeper.html [19:32] i gave them juju.ubuntu.com as a link.. but oh well.. i did notice how out of date those docs are [19:33] hazmat: Cool.. still a quite reasonable overview I guess, from the perspective of someone interested in a vague feeling of what we do [19:34] hazmat: From our end, though, yeah, that's quite out of date [19:42] <_mup_> juju/hooks-with-noninteractive-apt r396 committed by kapil.thangavelu@canonical.com [19:42] <_mup_> also capture APT_LISTCHANGES_FRONTEND for noninteractive hook usage [19:44] bcsaller, +1 on the trivial.. we should have someone else look as well [19:44] jimbaker, thanks for the review [19:45] niemeyer, jimbaker could either of you look at that trivial ben just posted.. it forces the dnsmasq into the resolver config by inserting into head.. both jamespage and bcsaller had problems getting dns resolution working without it.. i don't understand why its needed as it should be picked up from dhcp.. but it works and solves a real issue for some. [19:46] er.. fixes the issue for those who had it [19:47] hazmat: Isn't it because it's being regenerated/ [19:47] ? [19:47] niemeyer, so we set it manually for the chroot customize script.. but when the container boots, it should pick it up from the dhcp server (dnsmasq) [19:48] hazmat: Ok.. I don't understand it either, but if it fixes the problem it looks good for the moment [19:48] bcsaller: Extra space after the ">" please, as usual for other similar lines in the same file [19:48] but for some reason its not.. doing this insertion into /etc/resolvconf/resolve.conf.d/base assures that its *always* included in the generated resolve.conf [19:49] i wonder if its a race condition exposed by ssd vs rotating disk. [19:49] jimbaker, does your desktop you tested local provider with have a rotating disk? [19:51] hazmat: What content ends up in the file when it doesn't work? [19:51] niemeyer, resolv.conf is empty [19:51] Hmm [19:51] which makes no sense.. because their networking is running, and dnsmasq handed out the address, and can resolve the container name.. [19:51] hazmat: Has someone tried to re-get the dhcp information after that? [19:51] hazmat: I'm wondering if the started dhcp is actually not answering DNS requests properly [19:51] niemeyer, not afaik [19:52] hazmat, it has an ssd [19:52] oh well there goes that idea.. [19:53] bcsaller, ^ you want to try and debug root cause [19:54] hazmat, i certainly have not needed ben's trivial, not certain what makes my env diff [19:54] jimbaker, it worked for you, me, and kim0|holiday without the change.. but it didn't work for jamespage or bcsaller without it [19:54] hazmat: I can look at it again, sure [19:55] bcsaller, we should still go ahead and commit, i'm curious if we can get a better understanding of the problem, else its a chicken ;-) [19:56] bcsaller, might need tcpdump to look at the queries on the wire [19:57] * hazmat gives up on sup [19:57] too many random messages won't load [20:04] <_mup_> juju/local-provider-docs r395 committed by kapil.thangavelu@canonical.com [20:04] <_mup_> address review comments [20:06] <_mup_> juju/trunk r396 committed by kapil.thangavelu@canonical.com [20:06] <_mup_> merge local-provider-docs [r=jimbaker,niemeyer][f=867991] [20:06] <_mup_> Basic usage docs for using the local provider. [20:07] <_mup_> juju/go-charm-url r16 committed by gustavo@niemeyer.net [20:07] <_mup_> Syncing regex from Python code. [20:10] niemeyer, btw.. it looks like the resolved install_error does indeed go all the way through to start, i must have fixed it and forgotten about it [20:11] hazmat: Ah, phew.. sweet [20:12] so afaics the pending for eureka is good, just two important items in the review queue. [20:12] actually i'd consider the orchestra docs to be important but i think andreas is still at openstack conf [20:13] * hazmat goes back to playing with a charm browser [20:35] <_mup_> juju/go-charm-url r17 committed by gustavo@niemeyer.net [20:35] <_mup_> - Changed error messages as suggested by Rog. [20:35] <_mup_> - More tests on charm URL parsing. [20:35] <_mup_> - Fixed parsing bug. [20:57] <_mup_> juju/go r13 committed by gustavo@niemeyer.net [20:57] <_mup_> Merged go-charm-url branch [r=rogpeppe,fwereade] [20:57] <_mup_> This introduces support for charm URLs in the Go port. [21:20] I'll head out for some exercising [21:20] niemeyer, enjoy! [21:20] Will try to work a bit on that stuff over the weekend [21:20] jimbaker: Cheers [21:26] niemeyer, cool, have a good one [21:57]