[06:21] rogpeppe: morning [06:21] urulama: hiya [06:22] rogpeppe: did anyone provide any feedback yesterday? [06:22] urulama: not that i've seen [06:25] rogpeppe: ok. nevertheless, we still need to make v4 as a charmstore "stub" for London ... [06:25] rogpeppe: be here soon, just making quick breakfast [07:01] rogpeppe: ready ... and i just remembered, that it would be great if I buy some GBP for Sunday ... [07:01] urulama: good plan :-) [07:02] urulama: or just use your card when over here [07:02] rogpeppe: yeah, just to be on the safe side to have for a bus from Stansted to Liverpool station [07:03] urulama: ah yes. you'll need some cash for that. [07:03] urulama: presumably you mean Liverpool Street station... [07:03] rogpeppe: indeed :D [07:03] urulama: we don't want you ending up in Liverpool! [07:06] rogpeppe: is it v4 branch now? [07:06] urulama: yes [07:06] urulama: the PR is here: https://github.com/juju/charmstore/pull/14 [07:20] rogpeppe: what about 004-restructure branch? [07:20] rogpeppe: 004-restructure-1 [07:21] that was the last commit afaics [07:21] urulama: it can't be easily reviewed until the previous pull request goes in [07:22] ok [10:49] urulama: https://github.com/juju/charmstore/pull/15 [11:51] rogpeppe: ping me when you return [13:15] urulama: ha, only just saw your "ping me" message [13:16] urulama: i've been back a while :-) [13:23] rogpeppe: urulama: how is it going? [13:23] frankban: pretty well, i'd say [13:23] frankban: wanna gogogo? [13:24] rogpeppe: sure, I'll be there in a bit [13:27] frankban: hi there [13:27] rogpeppe: i was stuck on a rick_h__ comment about how version numbers could be interpreted (min vs max version) [13:27] urulama: in which document? [13:29] rogpeppe: this is related to the package version compared to api version [13:29] rogpeppe: that we had an initial thought on yesterday [13:29] rick_h__: ah yes [13:30] rick_h__: my current inclination is to treat the package version and the api version as two entirely distinct things [13:30] rick_h__: because the package version is all about compilability [13:31] rogpeppe: ok, that's fine by me. I was just concerned with matching package version with latest api version (the v4 update and such) [13:31] rick_h__: cool. yeah, i'll change that [13:31] rogpeppe: I think that makes sense as well and is traditional/expected [13:32] rick_h__: i think it's reasonable not to have to change the import paths in programs that use charmstore because the api versions have changed. [13:33] rick_h__: especially as it could even be dynamic which versions are served up [13:34] rick_h__: (for example, with a command line flag or environment variable to determine which versions the API serves) [13:34] rogpeppe: +1 [13:34] rick_h__: i'll go for a v2 branch, as with the charm package. and i think we'll move the import path to gopkg.in/juju/charmstore.v2 [13:35] rogpeppe: ok sounds like a plan [14:23] jujugui heads up I've got laggy network, casuing me to lose my irc ssh connections/etc in case I'm not as responsive as usual. [14:53] jujugui call in 8 [15:13] rogpeppe I have no idea what Dominion cards are but if you have enough for extra decks then I'd learn :) [15:13] hatch: i have the base set, but it's much more fun with extra sets [15:13] ahh [15:13] hatch: http://en.wikipedia.org/wiki/Dominion_(card_game) [15:14] yeah I checked it out [15:14] I won't be able to buy any before I take off....oh wells [15:15] I'll see how many CaH cards I can fit into my carry on :) [15:15] I can't believe that game is so popular when everyone on the internet gets offended by everything lol [15:15] clearly they are all pretend offended [15:19] i've only played it once. i was not offended. [15:19] mind you, i'm not easily offended [15:19] here here! [15:51] rick_h__, hatch: I'm seeing additional oddness when replicating the bug I'm working on, https://bugs.launchpad.net/juju-gui/+bug/1341653 [15:51] <_mup_> Bug #1341653: Cannot drop an unplaced unit on a ghost container [15:52] kadams54 otp, can chat in a sec [15:53] The service unit I tried to drop is still unplaced, but there's a machine listed without an ID and it seems to have the service deployed: http://cl.ly/image/0j3c122P171M [15:55] kadams54 hm looking [15:55] kadams54 ok that might be happening because the placeUnit isn't removing the ghost unit token from the db [15:56] there is probably an error somewhere which is causing it to not find the ghost unit, and because of that, not remove it [15:56] So we have a bug in rollback scenarios [15:57] kadams54 it might be worth outlining all of the different interactions we can take with that and then going through step by step [15:57] that way we know that each time we modify that code that it's not breaking something else [15:58] Transactional commits, rollbacks… if only they made datastores that supported these things! [15:59] I think it would be worth outlining if that was the first step in creating a functional test (or suite of tests). [16:00] hatch: But I'm not sure that's the problem here (unspecified/tested interactions). The problem seems more basic: how do we ensure, when an error occurs, that we can recover to a clean and good state? [16:00] kadams54 well it should be impossible to enter a dirty state [16:00] there is no way we can get out of it if the code is broken :) [16:01] Why would that be? [16:01] What happens when we send a command off to juju-core and it fails? [16:01] We've often already updated the GUI and the client DB [16:01] So those changes need to be rolled back [16:02] well yes the environment handles that [16:02] this ECS stuff is new uncharted territories [16:02] there are going to be a whole slew of interactions which need to be tested [16:03] jujugui see you in London [16:03] cya urulama safe travels [16:04] i'm also off now [16:04] urulama: safe travels [16:04] urulama: be safe [16:04] safe travels to all [16:04] rogpeppe: you too [16:04] no missiles anyone, ok? [16:05] thanks, same to you [16:05] hatch: sure, but being able to recover from a failed transaction seems pretty low level. It shouldn't care about what kind of work is happening in the transaction, so you don't need to test every type of transaction to ensure clean rollbacks. [16:06] right - but the issue is that we create ghost records in the db then the env creates the real ones [16:06] the issue you're experiencing looks like the ghost record isn't being removed [16:06] likely because of a name missmatch or something [16:08] hatch: I guess I had a different perspective: in my view, the problem wasn't that the ghost record still existed. The transaction failed, so IMO it should still be an unplaced unit. Rather, the problem was that this mystery ID-less machine popped up, with an equally mysterious mysql unit deployed on it. [16:08] Those should have been rolled back when the transaction failed, leaving me back at an unplaced unit. [16:11] yes I agree, I'm just trying to think of how this is to be done with the current ecs/ghost/db implementation [16:20] kadams54: hatch sorry, call is over. Everyone ok or need another set of eyes? [16:21] I have to run in a bit so when I get to the airport I'll pop it open again and look at the code [16:22] rick_h__: Not sure we need a second set of eyes, we just may have another bug, in addition to the one I'm working on. [16:22] kadams54: ok [16:31] cya everyone, have a safe trip [16:31] safe flight hatch [16:31] thanks [16:41] * rick_h__ makes lunch [19:23] jujugui I'm out, going to get the bags packed up. See you all soon. [19:26] ccccccdiltnnrhthtkkkvghvfrtgecbuiivndeblduie === alexpilotti_ is now known as alexpilotti