[00:14] nice fixed debug-hooks to work for early in the agent lifecycle [00:14] er. charm [00:17] hazmat: Ohhh.. that's sweet [00:18] hazmat: unix modes in zip is in upstream, btw.. we'll just need tip for the moment [00:18] niemeyer, cool, i've got a tip build i can utilize [00:18] niemeyer, its going to be a little while till the next release? [00:18] hazmat: I've upgraded the PPA, but failed to put the series in the version number [00:18] since they just released [00:18] hazmat: There's a bug in the build procedure with the colon in the path that I'll have to check out when I get a moment [00:19] hazmat: Yeah, but it shouldn't be a big deal for us for the server side [00:19] hazmat: We can deploy with tip [00:19] hazmat: Well.. and that'll be in the weekly in a couple of days [00:19] niemeyer, cool [01:30] <_mup_> juju/status-with-unit-address r403 committed by kapil.thangavelu@canonical.com [01:30] <_mup_> debug hooks works with unit address, also address deficiency around debugging early unit lifecycle, by allowing debug-hooks command to wait for the unit to be running [01:31] niemeyer, i think i'm going to go ahead and try to address the placement stuff after the lxc merge [01:31] hazmat: Sound ok.. but I also think it's going to be surprisingly trivial to handle it as suggested [01:31] Sounds [01:32] hazmat: It's indeed fine either way, though [01:32] niemeyer, i know.. i'm just fading, and want to get merges in.. this stuff needs to go upstream... maybe i should hold off till i get full night's rest [01:32] anyways.. last of the branches is ready for review ( cli with unit address) [01:33] hazmat: Yeah, get some rest [01:33] hazmat: I'll probably do the same to get up early tomorrow [01:33] niemeyer, there are places where i think placement on the cli is useful, and placement is a global provider option.. [01:34] some of the discussion from earlier w/ bcsaller.. [01:34] the cross-az stuff in particular is of interest to me [01:34] hazmat: I think it's overthinking the problem a bit [01:34] hazmat: This is well beyond what we need for the feature at hand [01:35] hazmat: I'd rather keep it simple and clean until practice shows the need for the cli [01:35] i'm concerned that placement is going to get out of hand on responsibilities on the one hand, and on the other i see it as being very convienent for implementing features like deploy this unit in the a differrent az [01:36] hazmat: I feel uncertain about that [01:36] ic cross az as something required for production on ec2.. i'm not sure where else we can put this sort of decision [01:36] hazmat: We're implementing one feature, and imagining something else without carefully taking into account the side effects [01:37] fair enough [01:37] hazmat: It's not required really.. [01:37] hazmat: cross az can be done with a single cluster [01:37] niemeyer, sure it can.. but how do we place it such that is [01:37] er.. place such that it is [01:37] hazmat: Yeah, good question.. I don';t think the placement branch answers it [01:38] hazmat: So I'd rather keep it in a way we're comfortable rather than creeping up without properly figuring what we're targeting at [01:38] it doesn't but cli placement is easy facility for it.. i agree there are ramifications there given provider validation that bear more thought, but it works pretty simply afaics [01:39] hazmat: I'm not sure, and given that it really won't work either way right now, I'd rather not do it for now. [01:40] hazmat: If nothing else, we're offering a visible interface to something that makes no sense to the user, with some intermangling in the implementation that we're not totally comfortable with. [01:40] hazmat: Feels like a perfect situation to raise KISS and YAGNI [01:42] * hazmat ponders [01:43] i'll sleep on it... i still think cross-az stuff is very important.. and that this is probably the simplest way to offer it to users. [01:44] but perhaps its a red herring... much else to do for internal failure scenario recovery [01:44] reconnects, restarts, etc [01:45] hazmat: That's not even the point.. no matter if it's the implementation we want or not, it doesn't work today, and won't work for quite a while. [01:45] niemeyer, i could implement this cross-az with via cli placement in a day i think. [01:45] hazmat: I'd rather not have this stuff creeping up in the code base until we figure it out. [01:45] tomorrow even [01:45] hazmat: Heh [01:46] ;-) [01:46] hazmat: I suggest we KISS and you suggest doing even more.. get some sleep. :) [01:46] indeed [01:52] <_mup_> Bug #859308 was filed: Juju commands (ssh/status/debug-hooks) should work with unit addresses. < https://launchpad.net/bugs/859308 > [10:48] Hello! [10:49] niemeyer: hiya! [10:50] rog: Hey! [10:56] niemeyer: what's the best way for me to update to your merged version? [10:56] (of gozk) [10:57] is it now in a new repository? [10:57] rog: It's a new branch.. just branch from lp:gozk/zk [10:57] rog: Which is an alias for lp:~juju/gozk/zk [10:58] rog: In the future it'll go back to being lp:~juju/gozk/trunk, once we kill launchpad.net/gozk [10:58] I mean, kill as in not support this import path [10:58] ok [11:16] <__lucio__> hi! is there a way to compose to formulas so i can say, for example, deploy a database server + a monitoring agent to this node? [11:22] * rog finds lots of documentation bugs. oops. [11:27] __lucio__: Absolutely [11:27] <__lucio__> niemeyer, how? (hello!) [11:27] __lucio__: Hey! :) [11:28] __lucio__: Charms (previously known as formulas) interconnect via relations that follow a loose protocol [11:29] __lucio__: We give a name to the interface between them so that we can distinguish the protocols [11:29] __lucio__: So, you can define in one of the formulas that it requires (consumes) a given relation interface, and in the other side that it provides (serves) the given relation interface [11:30] __lucio__: This way both sides can be interconnected at runtime [11:30] __lucio__: Using the "juju add-relation" command [11:30] __lucio__: The charms will be notified when such a relation is established via the hooks [11:31] rog: Hm? [11:31] __lucio__: Does that make sense? :) [11:32] <__lucio__> niemeyer, not exactly what i mean. imagine i get the mysql charm and want to deploy it. get machine 1 with mysql. then i want to deploy some agent to monitor the system stats there. i want to create a new charm and say "deploy this charm to this machine that already exists" [11:32] <__lucio__> is that the "placement policy"? [11:32] __lucio__: Ah [11:32] __lucio__: I see [11:32] <__lucio__> the key part in here would be that those charms should know nothing of each other [11:33] __lucio__: This will be supported in the coming future through what we're calling co-located charms [11:33] __lucio__: In practice it'll be just a flag in the relation [11:33] __lucio__: and juju will put the charms together based on that [11:33] __lucio__: It's not implemented yet, though [11:33] __lucio__: and it's not the placement policy [11:34] hazmat: See? :) [11:34] __lucio__: Yeah, exactly [11:34] __lucio__: Re. knowing nothing about each other [11:34] __lucio__: They will use exactly the same interface for communication that normal charms use [11:34] <__lucio__> niemeyer, ack. nice to see you guys thought about it :) [11:35] __lucio__: Despite them being in the same machine [11:35] __lucio__: Yeah, there's a lot of very nice stuff to come.. just a matter of time [12:33] niemeyer: ping [12:34] fwereade: Hey! [12:34] niemeyer: thanks for the review :) [12:34] niemeyer: how's it going? [12:34] fwereade: np [12:34] fwereade: Going in a roll! [12:35] niemeyer: sweet :D [12:35] fwereade: I was wondering about charm id/url/collection/etc terminology [12:35] fwereade: Ok [12:35] niemeyer: and wanted to know what your theoughts were re: the hash at the end [12:36] niemeyer: I see it as not really part of the *id* so much as just a useful bit of verification [12:36] niemeyer: but... well, it's an important bit of verification :) [12:36] fwereade: Which hash? [12:37] niemeyer: lp:foo/bar-1:ry4xn987ytx984qty498tx984ww [12:37] when they're stored [12:37] Howdy folks .. did the LXC work land already? [12:37] seeing lots of cool comments [12:37] fwereade: It must be there [12:37] commits I mean [12:37] fwereade: For storage, specifically [12:37] (yes that was a keyboard-mash, not a hash, but close enough ;)) [12:38] fwereade: The issue isn't verification, but uniqueness [12:38] kim0: Heya! [12:38] kim0: It's on the way [12:38] niemeyer: ...ha, good point, hadn't internalised the issues with revision uniqueness [12:38] niemeyer: except, wait, doesn't the collection-revision pair guarantee uniqueness? [12:39] niemeyer: I know rvisions and names wouldn't be enough [12:39] fwereade: Define "guarantee" [12:39] fwereade: ;_) [12:40] cool, can't wait to tell the world about this .. It's such a nice feature [12:40] fwereade: A hash is a reasonable "guarantee", even if it's not 100% certain. Trusting the user to provide a unique pair isn't very trustworthy. [12:40] * kim0 compiles regular juju progress report .. shares with planet earth [12:40] kim0: It is indeed! And we're almost there [12:41] niemeyer: ok, it feels like the bad assumption is that a collection + a name will uniquely identify a (monotonically increasing) sequence of revisions [12:41] niemeyer: confirm? [12:42] fwereade: I'd say more generally that the tuple (collection, name, id) can't be proven unique [12:43] fwereade: If we were the only ones in control of releasing them, we could make it so, but we're not [12:43] niemeyer: hm, indeed :) [12:43] niemeyer: ok, makes sense [12:43] niemeyer: in that case, I don't see where we'd ever want the revision without the hash [12:44] fwereade: That seems a bit extreme [12:44] mm .. the juju list is not on https://lists.ubuntu.com/ [12:45] fwereade: The revision number is informative [12:46] fwereade: and in the store it will uniquely identify the content [12:46] fwereade: FWIW, the same thing is true for packages [12:48] lunch [12:48] niemeyer: ok... but if we ever have reason to be concerned about uniqueness of coll+name+rev, in what circumstances *can* we assume that that alone is good enough to identify a charm? [12:49] niemeyer: (ok: we can if it came from the store, probably (assuming *we* don't screw anything up) but it doesn't seem sensible to special case that [12:50] niemeyer: ) [12:50] fwereade: Pretty much in all cases we can assume it's unique within the code [12:51] niemeyer: if we want the bundles to be stored with keys including the hash, why would we eschew that requirement for the ZK node names? [12:51] niemeyer: um, "pretty much in all cases" == "not in all cases" :p [12:52] fwereade: Sure, you've just found one case where we're concerned about clashes [12:52] fwereade: Maybe we can change that logic, actually.. hmm [12:53] fwereade: The real problem there is that it's very easy for the user to tweak a formula and ask to deploy it, and then deploy something else [12:54] fwereade: The question is how to avoid that situation [12:54] niemeyer: sorry, are we talking about upgrades, or just normal deploys? [12:55] fwereade: I'm happy for us to remove the hash from the name if we can find a way to avoid surprising results in these scenarios [12:55] fwereade: Both [12:55] niemeyer: heh, I was more in favour of making the hash a required part of the ID throughout (at least internally) [12:56] niemeyer: my issue was that it *wasn't* included in the ZK node name at the moment [12:56] niemeyer: that seemed like a problem :) [12:56] fwereade: That will mean we'll get two things deployed with the same name-id [12:56] fwereade: Not a situation I want to be around for debugging ;-) [12:57] fwereade: HmM! [12:57] fwereade: What about revisioning local formulas automatically based on the latest stored version in the env? [12:58] fwereade: Effectively bumping it [12:58] fwereade: The spec actually already suggests that, despite that problem [12:58] fwereade: This way we can remove the hash.. but we must never overwrite a previously existing charm [12:59] niemeyer: I'm confused [12:59] fwereade: Ok, let me unconfuse you then [12:59] fwereade: What's the worst point in the above explanation? :) [13:00] niemeyer: can we agree that (1) we can't guarantee that a (coll, name, rev) doesn't necessarily uniquely identify a charm [13:01] (2) therefore, we need something else to guarantee uniqueness [13:01] fwereade: My suggestion is to guarantee uniqueness "at the door" [13:01] fwereade: We never replace a previous (coll, name, rev) [13:02] fwereade: If we detect the user is trying to do that, we error out [13:02] fwereade: To facilitate development, though, we must give people a way to quickly iterate over versions of a charm [13:03] fwereade: Which means we need to bump charm revisions in the local case based on what was previously deployed [13:03] fwereade: Makes sense? [13:04] niemeyer: I think so [13:04] * fwereade thinks... [13:04] fwereade: This way we can remove the hash [13:04] fwereade: But you'll have to review logic around that a bit so that we're sure we're not naively replacing a previous version [13:05] fwereade: It shouldn't be hard, IIRC [13:05] niemeyer: I don't remember it being exceptionally complex [13:05] fwereade: Because we consciously store the charm in zk after uploading [13:05] fwereade: So if the charm is in zk, it must be in the storage [13:05] niemeyer: I have a vague feeling it'lll already complain if we try to overwrite a charm in zk [13:05] fwereade: and thus we shouldn't replace [13:06] fwereade: I think upgrade is a bit more naive [13:06] fwereade: But I'm not sure [13:06] fwereade: Perhaps my memory is failing me [13:06] niemeyer: I know less about the code than you might think, I was working most of last week with about 3 mental registers operating properly :/ [13:08] niemeyer: CharmStateManager calls client.create with a hashless ID, so that should explode reliably already [13:09] fwereade: Not sure really.. but please review it.. it'll be time well spent [13:09] fwereade: Then, we'll need to implement the revision bumping that is in the spec [13:09] fwereade: For the local case, that is [13:10] niemeyer: there was atlk a little while ago about allowing people to just ignore revisions locally [13:10] niemeyer: which seems to me to be quite nice for charm authors [13:11] fwereade: Exactly.. that's a way to do exactly that [13:12] fwereade: The user will be able to ignore it, because we'll be sorting out automatically [13:12] fwereade: Please see details in the spec [13:12] Will get a bite.. biab [13:12] niemeyer: by overwriting the revision file in the local repo? (the spec seems to me to be talking about how the formula store should work, not local repos) === med_out is now known as medberry [13:28] fwereade: CTRL-F for "local formula" within "Formula revisions" [13:28] fwereade: Sorry.. [13:28] fwereade: CTRL-F for "local deployment" within "Formula revisions" [13:29] niemeyer: hm, I see it now, sorry [13:29] fwereade: np [13:29] niemeyer: for some reason I'm not very happy with us writing into a local repo though [13:30] fwereade: That's why the revision is being taken out of the metadata [13:30] niemeyer: ...and it seems to say we should bump on every deploy, which feels rather aggressive [13:31] niemeyer: just a suggestion: if the revision and the hash don't match, we blow up as expected [13:31] fwereade: You have the context for why this is being done now.. I'm happy to take suggestions :) [13:31] fwereade: The hash of what? [13:31] fwereade: Directories have no hashe [13:31] niemeyer: don't they? [13:31] niemeyer: ok, it's the hash of the bundle [13:32] but they do have the appropriate method [13:32] fwereade: Yeah. it's a hack really [13:32] fwereade: Plus, not updating means we'll force users to bump it manually [13:32] fwereade: Effectively doing the "rather aggressive" part manually, which sucks [13:34] niemeyer: what if we treat a revision file that exists as important -- so if you change a revisioned formula but don't change the rev, you blow up -- but allow people to just delete the revision file locally, in which case we identofy purely by hash and treat the has of the current local version as "newer" than any other hashes that might be around [13:34] fwereade: I don't get what's the problem you're solving with that behavior [13:35] niemeyer: the failure-to-upgrade-without-manually-tweaking-revision [13:35] fwereade: The solution in the spec solves that without using hashes [13:36] fwereade: Why is your suggestion better? [13:36] niemeyer: but at the cost of repeatedly uploading the same formula every time it's deployed whether or not it's required [13:36] fwereade: Hmm [13:37] niemeyer: I'm also a bit suspicious of requiring write access to local repos, just to deploy from them [13:37] niemeyer: feels icky ;) [13:38] fwereade: That's trivial to solve.. but let's see, your earlier point is a good one [13:43] fwereade: Hmm.. I think we can specialize the behavior to upgrade [13:44] fwereade: and make deploy consistent for local/remote [13:44] fwereade: In deploy, if there's a charm in the env, use it no matter what [13:44] fwereade: Well, assuming no revision was provided, which is always true nowadays [13:45] fwereade: In upgrade, if it is local, bump the revision to the the revision currently deployed (in the *env*) + 1 [13:46] niemeyer: so we *might* still needlessly upload, but less frequently... not entirely unreasonable, I guess :p [13:47] fwereade: Sure, which gets us back to the original issue.. we need a method that: [13:47] 1) Does not needlessly bump the revision [13:47] 2) Does not require people to bump the revision manually [13:47] That's one solution [13:48] fwereade: I don't want to get into the business of comparing the hash of an open directory with a file in the env [13:48] fwereade: At least not right now.. to solve the problem we'd need to create a unique way to hash the content that doesn't vary with different bundlings [13:49] niemeyer: hm, I wasn't aware we had different bundlings to deal with..? [13:49] fwereade: Well.. [13:49] fwereade: There's a file in the env.. there's an open directory in the disk [13:49] fwereade: How do we compare the two? [13:51] niemeyer: well, at the moment, we zip up the env and hash the zipfile; I understand you think that's a hack, but I don't understand how it makes the situation any worse [13:51] niemeyer: hm, I wasn't aware we had different bundlings to deal with..? [13:51] fwereade: So you do understand we have different bundlings to deal with [13:51] niemeyer: we have different representations of charms, but the hashing is the same [13:51] fwereade: Why is it the same? [13:52] fwereade: Where's the zipping algorithm described that guarantees that zipping the same directory twice necessarily produces the same hash? [13:52] niemeyer: because we convert dirs to bundles to hash them? [13:52] niemeyer: and we *also* convert dirs to bundles to deploy them [13:52] fwereade: Where's the zipping algorithm described that guarantees that zipping the same directory twice necessarily produces the same hash? [13:52] niemeyer: ah-ha [13:53] zip files hold modification times... [13:54] niemeyer, rog: hmm. [13:54] niemeyer: i did something like this before [13:54] rog: modification times can be preserved.. but there are other aspects like ordering that are entirely unspecified [13:54] yup [13:55] niemeyer: my fs file traversal thing (which later became alphabet) solved this by always archiving in canonical order [13:55] So, there are two choices: either we define a directory/content hashing algorithm, or we don't take the content into account [13:56] and i added a filter for canonicalising metadata we don't care about (e.g. mtime, atime) [13:56] oh yes, permissions were a problem too. [13:56] it worked very well in the end though [13:56] rog: Sure, I'm not saying it's not possible.. I'm just saying that it requires diving into the problem more than "hash the zip files" [13:56] sure [13:57] zip files aren't canonical [13:58] niemeyer: as a side note: what's the trivial solution to my discomfort with requiring write access to local repos? [13:58] fwereade: bundle the revision dynamically [13:59] niemeyer: so we'd have local repos with different revs to the deployed versions? that feels like a pain to debug, too [13:59] fwereade: That may be the case either way, and there's absolutely nothing we can do to prevent it [14:00] fwereade: The prove being that the local version is user modifiable [14:01] fwereade: Either way, the normal case is writing the revision.. so let's not worry about the read-only case for now [14:02] niemeyer: ok then :) [14:02] fwereade: local: is really targeting development.. [14:03] niemeyer: true [14:03] fwereade: Again, please note that the local revision bumping must take the revision from the env + 1, rather than taking the local revision number in consideration [14:03] fwereade: On upgrade, specifically.. [14:04] fwereade: I believe we can handle the deploy case exactly the same for local/remote [14:04] niemeyer: understood, I just feel that "local newer than env" is easily comprehensible, while "env newer than local (from which it was deployed" is a touch confusing [14:04] niemeyer: agree on deploy: just use the one already deployed if it exists [14:05] niemeyer: (I know I'm still talking about the magic non-writing case, I'll try to forget about that) [14:06] fwereade: I don't understand the first comment in this series [14:06] niemeyer: sorry, I was still wittering on about the non-writing case, it's not relevant ATM [14:07] fwereade: The local namespace is flat.. [14:07] fwereade: Ponder for a second what happens if both of us start deploying the same "local" formula on the env [14:08] fwereade: and what the revision numbers mean in that case [14:08] niemeyer: I've been having quiet nightmares about that, actually ;) [14:09] fwereade: There's no nightmare that, if you acknowledge that local: is targeting development most importantly [14:09] s/that,/there,/ [14:09] niemeyer: I think the only sensible thing we can say is Don't Do That [14:09] fwereade: It's fine actually.. the last deployment will win [14:09] fwereade: Which is a perfect valid scenario when development is being done [14:09] perfectly [14:09] Can't write today [14:10] fwereade: "local:" is _not_ about handling all non-store cases.. [14:10] fwereade: We'll eventually have a "custom store" people will be able to deploy in-house [14:11] niemeyer: ok, a separate piece fell into place, part of my brain was conflating services and charms [14:12] niemeyer: I'm happy about that now [14:12] fwereade: Ah, phew, ok :-) [14:14] niemeyer: so... we trash hashes, then, and double-check that we'll explode if we try to overwrite a (coll, name, rev) in ZK [14:14] fwereade: Yeah, "explode" as in "error out nicely".. :-) [14:15] niemeyer: quote so ;) [14:15] gaah, I can't write either :/ [14:16] niemeyer: tyvm, very illuminating discussion [14:16] fwereade: It's been my pleasure.. have been learning as well [14:16] niemeyer: cheers :) [14:17] fwereade: Btw, the critical piece to review is whether we might overwrite the storage content or not [14:17] fwereade: We have some protection from zk that create(...) won't work if it already exists [14:17] fwereade: But we have none from the storage [14:17] fwereade: So if the logic is not as we think it is, it'll blindly overwrite and we'll figure later [14:18] fwereade: The hash protected us from that, even if not in an ideal way as you pointed out [14:18] niemeyer: yes indeed, I'll need to be careful but it's not insoluble [14:19] fwereade: I _think_ the original logic had "store + put in zk" for exactly that reason [14:19] niemeyer: btw, really quick lazy question: what would cause a zk charm node to be deleted? [14:19] fwereade: The ordering means that if an upload breaks mid-way, we still retry and overwrite [14:19] fwereade: Nothing, IIRC [14:20] fwereade: We debated a bit about garbage collecting it [14:20] niemeyer: ok, I thought I saw some logic to deal with that case, and was a bit surprised [14:20] fwereade: and we can do it at some point [14:20] fwereade: but I don't recall supporting it ATM [14:22] niemeyer: cool, I won't fret too much about that [14:30] Man.. empty review queue.. I'll run and do some addition server-side work on the store [14:30] additional.. [14:47] * hazmat catches up on the backlog [14:48] <_mup_> juju/go-store r14 committed by gustavo@niemeyer.net [14:48] <_mup_> Bootstrapping store package. [14:49] fwereade, niemeyer interesting about col/name/rev uniqueness.. one of the bugs/useability things for charm authors, is being able to do away with constant rev increments for iteration and just relying on hash [14:49] hazmat: morning! [14:49] its something that bites pretty much every charm author [14:49] hazmat: indeed, but niemeyer has convinced me that auto-incrementing on upgrade from local repos should solve that [14:50] hazmat: Yeah.. there are other ways to handle this without relying on hash, though.. read through :) [14:50] * hazmat continues the backlog [14:50] long conversation indeed [14:57] m_3: howdy .. please ping me hwen you're up [14:57] <_mup_> juju/go-store r15 committed by gustavo@niemeyer.net [14:57] <_mup_> Imported the mgo test suite setup/teardown from personal project. [15:06] niemeyer, so the conclusion is, for local repositories, always increment the version on deploy regardless of any change to the formula? [15:06] hazmat: Not quit [15:06] e [15:07] fwereade: Hmm.. I think we can specialize the behavior to upgrade [15:07] fwereade: and make deploy consistent for local/remote [15:07] fwereade: In deploy, if there's a charm in the env, use it no matter what [15:07] fwereade: Well, assuming no revision was provided, which is always true nowadays [15:07] fwereade: In upgrade, if it is local, bump the revision to the the revision currently deployed (in the *env*) + 1 [15:07] hazmat: ^ [15:09] hmm. also we should log at info level the formula we're using on deploy (already in env, vs uploaded) [15:09] hazmat: True [15:09] that's part of what bites people, lack of discovery into the problem till they go inspecting things [15:09] hmm. also we should log at info level the formula we're using on deploy (already in env, vs uploaded) [15:09] fwereade: ^ [15:10] LOL [15:10] hazmat: True [15:10] hmm. also we should log at info level the formula we're using on deploy (already in env, vs uploaded) [15:10] that's part of what bites people, lack of discovery into the problem till they go inspecting things [15:10] fwereade: ^^^ [15:10] niemeyer, hazmat: sounds sensible [15:11] auto increment on upgrade sounds good [15:12] the upgrade implementation is pretty strict on newer versions, which is why i punted on a hash based approach, it was hard to maintain that notion [15:14] hazmat: Agreed. The hash stuff sounds interesting to detect coincidences for sure, but the detail is that it won't really solve the problems we have.. we need to consider larger versions anyway, and need to be able to update the previous deployment [15:14] ... without manual interaction [15:14] So for now it feels like the auto-increment upgrade is enough [15:16] fwereade: When do you think the new CharmURL & CharmCollection abstractions will be available? [15:16] fwereade: Just want to sync up because I'd like to have a look at them before mimicking in Go [15:16] fwereade: So we match logic [15:16] niemeyer: hopefully EOmyD, but I'm not quite sure when that will be [15:17] fwereade: Cool, thks [15:17] niemeyer: certainly before strot of your day tomorrow though [15:17] fwereade: Ok [15:17] gaah *start* of your day [15:17] fwereade: Are you planning on doing any modifications to the suggested API? [15:18] I think I'm happy with everything you proposed [15:18] fwereade: Awesome, I'll get started on it then [15:19] niemeyer: I'll let you know ASAP if I come up with any problems [15:19] fwereade: Superb, cheers [15:19] fwereade: Will do the same on my end [15:37] kim0: hey man... what's up? [15:42] <_mup_> juju/config-juju-origin r358 committed by jim.baker@canonical.com [15:42] <_mup_> Merged trunk [15:47] fwereade, do you know if the orchestra machines generally have useable fqdns? [15:48] hazmat: better check with roaksoax, but I don't think you can guarantee it [15:48] hazmat: context? [15:48] fwereade, niemeyer, re the delta with local/lxc vs orchestra on address retrieval.. with local the fqdn isn't resolvable, but the ip address is routable and there is a known interface. with orchestra the number of nics on a machine isn't knowable, but i was hoping we could say fqdns are resolvable [15:49] hazmat: IIRC the dns_name should work from other machines, but I don't think we have any guarantees about how it works from outside that network [15:49] this also per SpamapS comments on the original implementation that we should favor fqdn over ip address, and neatly sidesteps ipv4 vs ipv6 behind dns [15:49] hazmat: We can't guarantee it ATM [15:49] hazmat: Most of the tests I recall were done with IP addresses [15:50] niemeyer, on the address branch its all just a popen... local with ip, ec2 and orchestra with fqdn hostnames [15:50] hazmat: The fully qualified domain will also not resolve the problem.. it may have multiple nics despite the existence of a fqdn [15:51] niemeyer, multiple nics is fine if the fqdn is resolvable [15:51] hazmat: I believe it's not.. it'll resolve to an arbitrary ip address [15:51] hazmat: Which may not be the right one if a machine has multiple ips [15:51] hazmat: ec2 is a different case.. [15:51] hazmat: We know what we're doing there [15:52] niemeyer ? hostname -f returns the fqdn of the host regardless of multiple nics [15:52] For multiple NIC's, the FQDN should resolve to the NIC that you wish the host to be externally reachable on... [15:52] which is what we do for orchestra [15:52] hazmat: hostname -f returns *a* name, that may be resolvable or not, and that may map to the right ip or not [15:53] I *can* see a situation where you have a management NIC, and a service NIC .. each needing different handling. [15:53] SpamapS, we've got separation of public/private addresses for units, but getting those addresses on on orchestra deployments is the question [15:54] doesn't seem like we can do that apriori [15:54] Indeed. DNS is the only reliable way, IMO, to handle something so loosely coupled. [15:55] hazmat: I suggest checking with smoser and RoAkSoAx then [15:55] hazmat: If they're happy, I'm happy :) [15:57] hi all [15:58] koolhead11: Hey! [15:58]