[00:13] niemeyer, there is some redundancy with the new format since we're showing the service relations : db : [myblog, teamblog] at the service level and showing the same for each unit as well in the relations/relation-errors block [00:23] we had talked about collapsing them, but per unit rel status is important [00:24] * hazmat looks for previous context [01:42] hazmat: Wasn't the redundancy always there? [01:43] hazmat: The distinction is we show the active relations [01:43] hazmat: Maybe all we need is relation-errors? [01:43] niemeyer, yeah.. that sounds reasonable [01:43] there's not really anypoint to showing it duplicated, and we flag errrors separately [01:44] s/their [01:44] hazmat: yeah.. and if we regret we can always go back [01:44] sounds good, i'll do it up that way [01:45] niemeyer, thanks [01:45] hazmat: np [01:55] hmm.. some of the dot rendering needs that info [02:00] nm [04:03] * hazmat yawns [07:04] mornin' to anyone silly enough to be up at this hour [07:04] andrewsmedina: pong [07:12] speak for yourself, it's 5:12pm here :) [07:16] bigjools: :-) i knew it was a silly thing to say. [07:17] bigjools: australia? [07:17] yup [07:18] gah, this whole juju branching from LP thing has really screwed my day [07:18] bigjools: how's that? [07:19] I waited for a bootstrap to finish while it was setting up a node (takes ages) and then: [07:19] bzr: ERROR: http://bazaar.launchpad.net/%2Bbranch-id/348938/.bzr/repository/packs/c77bcca4ec91aee207a8f9d37b1a8608.pack is redirected to https://launchpad.net [07:19] which is a bug in LP/bzr somewhere [07:19] and the whole bootstrap grinds to a halt [07:20] aren't web services marvellous? [07:20] not today :) [07:20] bigjools: BTW how long does it take for you to bootstrap an environment? [07:21] (usually) [07:21] but I'm still gobsmacked at juju branching off LP at all during deployment/bootstrap :/ [07:21] bigjools: depends on the environment settings, right? [07:21] it depends. I am testing maas, and if I wait for a machine to install, an hour, otherwise it depends on network speed for apt-get update/install etc. [07:22] are you talking about juju-origin? [07:22] bigjools: yeah [07:22] I still think that's crazy [07:22] bigjools: that you should have the option? [07:23] that it tries to check out a branch [07:23] bigjools: does it do that even when juju-origin is distro or ppa? [07:23] is this an artifact of my dev environment, or does it always do that by default? [07:24] bigjools: i couldn't say i'm afraid [07:24] let me rephrase - does it always bzr branch/checkout? or does it try to use other ways to get the code down? [07:25] bigjools: i was under the impression that if you used juju-origin=distro or ppa that it would just do apt-get [07:25] ah ok, I didn't know that [07:25] so just the default is crazy then :) [07:26] bigjools: ah, the default depends on your local environment [07:26] bigjools: i'd forgotten about that. [07:26] ah, that's what I was getting at [07:26] * rog looks at the code [07:27] bigjools: it looks at the output of apt-cache policy [07:28] ok [07:29] bigjools: what does "apt-cache policy juju" produce for you when you run it? [07:30] bigjools: to be honest, i didn't really understand the motivation behind the code when i ported it to Go. i just copied the semantics and the tests :-) insight into why it's good or bad would be useful... [07:31] I really have no idea :/ [07:31] juju is not installed locally, anyway, which is why I guess it branches it [07:36] bigjools: no idea what happened there [07:36] bigjools: last thing i saw from you was: [07:36] [07:31] I really have no idea :/ [07:37] wrtp: I just said that juju is not installed from a package [07:37] bigjools: could you paste the exact output of apt-cache policy juju, please? [07:38] bigjools: i'm just looking to see how the code would deal with it - it's got quite a few cases. [07:38] wrtp: http://pastebin.ubuntu.com/891862/ [07:41] bigjools: thanks [07:42] bigjools: yeah, it's the "Installed: (none)" that triggers it [07:43] wrtp: right [07:43] bigjools: set juju-origin and you'll be fine, i guess [07:43] wrtp: I am using it to pull my dev branch from LP [07:43] but got caught by that LP bug [07:43] bigjools: the underlying problem is outlined in this email: https://lists.ubuntu.com/archives/juju/2012-March/001337.html [07:43] :) [07:50] rog, fwereade: moin [07:50] heya wrtp, TheMue, bigjools [07:51] fwereade: yo! [07:51] hello fwereade [07:55] wrtp: I found what looks like a bug, can you verify this: [07:55] the user-data contains lines that append to the /etc/init/..conf files [07:56] so on multiple boots you end up with it saying to start the provisioning agent etc multiple times [08:07] bigjools: multiple juju bootstraps? or multiple boots of the machine? [08:08] bigjools: BTW it's ironic that the problem i'm currently trying to debug with the Go port is directly to do with the issue you had above... [08:16] wrtp: heh - each boot uses the cloud-init user-date to append the same stuff to the conf files [08:17] bigjools: hmm. i think juju usually assumes a fresh machine each time. [08:17] wrtp: not sure why it is using >> in the bash script then [08:18] bigjools: is that in juju or in cloudinit.py ? [08:19] wrtp: the user-data's runcmd coming via cloudinit [08:20] afk for a while [08:21] bigjools: i don't see that, but maybe i'm looking in the wrong place. [08:21] oh yeah, i do now. [08:24] bigjools: i think that might have changed since i did the port. hmm. [08:27] fwereade: you did the upstart stuff, right? [08:28] wrtp, yeah, reading back... [08:28] fwereade: from a test data file (cloud_init_ppa): [08:29] /var/log/juju, 'cat >> /etc/init/juju-machine-agent.conf < why the append? [08:29] wrtp, because, apparently, the crack was strong with me that day, but let me check something [08:30] wrtp, yeah, crack [08:30] bigjools: ^ [08:30] :-) [08:31] fwereade: do any of the tests try rebooting the instances? [08:31] wrtp, hm, no [08:31] fwereade: it seems to me that it might be a good idea to try to test this stuff [08:31] wrtp, but rebooting them has AFAICT always worked in the past [08:32] fwereade: lucky :-) [08:32] wrtp, well, it tests that it has behaviour that has been experimentally verified to work, even if that was by sheer luck :/ [08:34] fwereade: :-) [08:34] wrtp, it seems that ec2 runs user scripts only one anyway [08:35] fwereade: that would be very sensible [08:35] fwereade: maybe can say it's a bug in MaaS? [08:35] wrtp, nah, my bug [08:35] fwereade: but... isn't it up to the OS to decide whether the run the init scripts or not? [08:36] wrtp, I think of it as being up to cloud-init, and it's not not-a-bug just because ec2 machines happen to be set to run them only once [08:36] wrtp, it was hitherto a latent bug [08:37] fwereade: BTW, looking at juju/providers/common/tests/data/cloud_init_ppa, it looks like the "--session-file" argument is on a different line to the "exec python -m juju.agents.machine" command. [08:37] fwereade: how can that work then? [08:38] wrtp, isn't that yaml being "clever"? [08:38] wrtp, in that section line breaks are represented as pairs of line breaks, AFAICT [08:39] fwereade: quite probably. i haven't found a good explanation of all yaml's cleverness anywhere yet [08:39] fwereade: i'd have thought that stuff inside ' ... ' is treated literally. [08:41] fwereade: jeeze who could ever think of calling it "simple"? [08:41] wrtp, I basically treat yaml as a binary format [08:41] wrtp, it passes through a library that causes it to make sense, somehow, and I'm happy enough with that :p [08:41] fwereade: can we move to json sometime, please? [08:42] wrtp, I have no idea, I think that's one to punt to niemeyer [08:42] wrtp, I don;t know where the original yaml dependency came from [08:42] fwereade: yeah. i think niemeyer likes the indentation-based format. [08:42] wrtp, tbh I'm not *so* bothered by it -- in the paces where users might use it, it's usually pretty clear and obvious [08:43] wrtp, but, yeah, it gets ungainly with our own data [08:45] "In addition, it is only possible to break a long single-quoted line where a space character is surrounded by non-spaces." [08:45] from: http://www.yaml.org/spec/1.2/spec.html#id2788097 [08:45] wrtp, OTOH note that cloud-init is not our code, and that needs to be yaml anyway [08:45] fwereade: yeah, i realise that. [08:45] fwereade: unfortunately. [08:46] wrtp, so this specific example is not really directly relevant to the cause anyway ;) [08:46] fwereade: yeah, it was more of a by-the-by. [08:48] fwereade: i can't see where in that section it says that newlines are removed. [08:49] fwereade: i suppose example 7.9 implies that though. [08:49] wrtp, I'm afraid I have little stomach for a deep dive into the yaml spec, but the way it converted all the \ns to \n\n (in that section only) seems to me to be strong-enough circumstantial evidence for my position ;) [08:50] fwereade: true 'nuff :-) [08:59] wrtp, hmm, I wonder whether deploying machine constraints will break everyone's jujus again :/ [08:59] fwereade: it'll probably break the hacks that everyone's been using to get around the lack of machine constraints... [09:00] wrtp, oh, *that* is guaranteed, but *hopefully* people have known they were going away since last year [09:00] wrtp, I'm just worried about the impat on stuff that's already deployed from PPA, at the point it hits the PPA [09:02] fwereade: hmm, yeah. is the zk schema backwardly compatible? [09:03] wrtp, I need to double-check what happens if the constraints key is ever not found... but actually, that should be broken *already* if it's a problem === jelmer_ is now known as jelmer [09:34] wrtp, fwereade_: a simple review: https://codereview.appspot.com/5843068 [09:34] wrtp: btw, why today wrtp and not rog? [09:45] TheMue, the big question is "what will this be used for?" [09:46] fwereade_: inside WaitAgentAlive() of Unit and Machine, like discussed yesterday with niemeyer [09:49] TheMue, ok, and we definitely need a timeout for that? [09:51] fwereade_: we should leave waiting users the option to have a timeout (as usual in concurrent and distributed computing). which concerns do you have with timeouts? [09:52] TheMue, those waiting users being? [09:53] TheMue, my only concern is that it's code that won't be used, and we don't have enough information to choose a sensible timeout [09:53] TheMue, the only thinks that wait for agents are command-line tools [09:54] TheMue, I was under the impression that we deliberately *didn't* time those out so that people can write scripts that bootstrap and just keep going with the next command [09:55] TheMue, I can understand that there are other plausible scenarios in which we might want to do have a timeout, but they don;t exist yet [09:55] (sorry mangled english) [09:58] fwereade_: one moment please, doing esta in parallel ;) back in a few seconds [10:23] fwereade_: so, back again, started ESTA for UDS [10:23] TheMue, ah cool [10:24] TheMue, anyway it's not bad code; it's not a bad idea; it's just not something we have a reasonable certainty of needing imminently, so I'd prefer it if it just didn't exist [10:24] TheMue, every line of code is a small weight on each of our brains ;) [10:25] fwereade_: WaitAlive() is the same functionality as it has been before in Unit and Machine. afaik a low level func like this one should provide the possibility for timeouts and it's task of its using code to determine how long it is willing to wait [10:26] fwereade_: no more code duplication later for selects with time.After [10:26] fwereade_: this argument by rog yesterday lead to the reduction to one func [10:26] fwereade_: btw, why no concerns before when the same code has been in Unit and Machine? [10:26] TheMue, my point is that nobody's going to be doing anything other than "alive, ok = <-watch", without select, regardless [10:27] fwereade_: even you in your tests worked with a timeout [10:27] TheMue, very specifically, only in the tests [10:27] fwereade_: timeouts and there handlings are essential in distributed and concurrent programming [10:28] TheMue, by adding this mechanism, you *force* me to choose a timeout [10:28] fwereade_: so you think it's ok that parts of the software block forever until anyone kills the process? [10:29] TheMue, exactly so [10:29] fwereade_: i could add a -1 for automatic max duration ... [10:29] fwereade_: but again, why hasn't been that question beforin when the same code has been in Agent or later in Unit or Machine? [10:30] TheMue, that's still forcing me to make a choice, it's just that there's still only 1 meaningful choice [10:30] fwereade_: and btw, nobody is forced to use this function, anyone can use the other functions, they are unchanged [10:31] TheMue, if I failed to spot and complain about the timeout before, I apologise for my inattention [10:31] TheMue, sure; and if nobody does use the function, why have it in the first place? [10:31] fwereade_: i will use it, in Unit and Machine [10:31] TheMue, to do what? [10:32] fwereade_: like discussed yesterday with niemeyer and rog [10:32] fwereade_: wait for an agent [10:32] TheMue, I'm sorry I missed that; what are the new use cases in which a timeout doesn't break user expectations? [10:32] TheMue: out of interest, BTW, what code waits for an agent? [10:33] rogpeppe: would have to look again who is calling it [10:33] TheMue, it's juju-ssh and juju debug-hooks [10:33] TheMue, and that's it [10:34] fwereade_: interesting. why do they wait for an agent? (and which agent do they wait for?) [10:34] TheMue, in both cases it's the command line and it will break existing behaviour that users expect [10:34] rogpeppe: there are several callers of watch_agent() in todays py code [10:35] TheMue, I see two [10:35] fwereade_: just counted the search results, they include the tests [10:35] rogpeppe, ssh waits for the machine agent [10:36] fwereade_: both of those occurrences just seem to be there to get the ip address of the machine [10:37] TheMue, yeah; there are 2 non-test uses [10:37] rogpeppe, I don't entirely agree with it in juju ssh [10:37] rogpeppe, but that's what was agreed [10:37] fwereade_: i suppose it's better than polling ec2 for the ip address to appear [10:38] rogpeppe, but it's needed for debug-hooks because it's utterly meaningless without an active unit agent at the other end effectively forwarding you a session [10:38] fwereade_: ah [10:39] TheMue: the existing watch_agent doesn't seem to have a timeout [10:39] fwereade_, rogpeppe: is anybody of you intereted in continue the agent method implementation (2 x 3 simple methods)? it's real fun, with a lot of principal discussions over different timezones and languages ... [10:40] :-) [10:40] rogpeppe: i exactly (!) implemented today behavior as a first draft. and that had to be changed. [10:40] TheMue, sorry, I am honestly trying to save you work, but I don;t think I'm succeeding :( [10:41] TheMue: i seem to remember interfaces and embedding in the first draft :-) [10:42] actually, no interface, probably [10:42] rogpeppe: one interface (that only has been to verify that Unit and Machine provide the right methods, else useless) and three simple functions to directly use them [10:42] rogpeppe: embed has already been another way, after also switching to presence [10:44] fwereade_: which work do you wonna save? it's already done and changing it is new work. each time. [10:47] fwereade_: the wish of reducing code duplication (yes, the one with (!) timeout) has been by rog, niemeyer followed it and my only part has been to move it to presence instead of one single func in any of the state files to provide this functionality (waiting with timeout) also for other users in future (afaik there are several more watches). [10:48] TheMue, I just don't understand why you need a timeout at all [10:48] TheMue, perhaps one day you will [10:48] TheMue, but I don't see what it gains us except lines of code [10:49] TheMue, I clearly failed to adequately express my concerns with the original watcher type [10:49] Unit.WatchHookDebug(), Unit.WatchResolved(), but i don't know if they will base on presence, only some notes of methods that still have to be implemented [10:50] TheMue, they certainly won't wait on presence [10:50] TheMue: i was under the impression that that only agents will be based on the presence package [10:50] TheMue, they're called by the unit agent itself [10:50] TheMue, it *knows* it exists ;) [10:50] rogpeppe, we also have presence nodes for unit relations as I recall [10:51] fwereade_: interesting. [10:51] rogpeppe, used to signal active participation in a relation (as distinct from "it may be working now by coincidence, but the unit won't react to changes") [10:53] TheMue, I seem to recall pointing out the very limited us cases for agent watching before, but perhaps that got lost in the noise [10:53] fwereade_: is that implied by the unit agent's presence, but duplicated in a different place for convenience? i haven't looked into how this stuff works at all. [10:53] rogpeppe, unit relations have state, of which "up" and "down" are generally relevant [10:54] fwereade_: a unit relation can be down when its unit agent is up? [10:54] rogpeppe, certainly; failed hook? [10:54] ah, sure [10:55] rogpeppe, the unit relation state has the last value written by the agent [10:55] rogpeppe, but if the agent isn't even well enough to maintain its presence node we can be pretty sure that something is rotten in the state of... um, the service [10:55] fwereade_: i suppose what i'm trying to work out is if the pinger thing is necessary in this case, or whether we can just use zk as usual. [10:56] ah, ephemeral nodes. [10:56] rogpeppe, we need some way to know that a remote thing is active [10:56] rogpeppe, indeed :) [10:56] fwereade_: so the presence package is only for agents? [10:57] TheMue, no, it's a general replacement for ephemeral nodes, which we have decided aren't worth the trouble [10:57] fwereade_: if we know the unit agent is alive, doesn't that imply the unit relation is, erm, actively inactive? [10:57] fwereade_: and there is no such usage of ephermeral nodes where the watcher isn't willing to wait endlessly? [10:58] rogpeppe, if the unit agent is alive we hope/trust that it's also watching its watches [10:58] TheMue, we don't wait on ephemeral nodes except in the 2 cases I mentioned [10:59] fwereade_: if the unit agent is dead, we can assume its unit relations are dead? [10:59] TheMue, and we only directly care about unit relation ephemeral nodes in the context of `juju status` in which we definitely don't want to wait on them [10:59] i'm speculating wildly. please ignore me. [11:00] rogpeppe, if it's dead then the service may well still be working correctly underneath [11:00] rogpeppe, but we can be sure that it won't respond correctly to settings changes etc [11:01] TheMue, the trouble is that this is not obvious from reading the python code :( [11:03] fwereade_: i'm trying to think slightly deeper about why we use a pinger. AFAICS it's to signify that there's something active pinging the node. given that (i think) the unit relation node is managed by the same code that manages the unit agent presence node, the activeness of the former could be used to imply the activeness of the latter, perhaps, is what i'm thinking. [11:03] oops [11:03] fwereade_: how do those other watches work? what do they watch? the presence of nodes or the change of node contents? [11:03] activeness of the latter could... activeness of the former [11:04] rogpeppe, I think that's what we already do [11:04] fwereade_: so perhaps an ephemeral/presence node is unnecessary for the unit relation? [11:04] TheMue, the only ephemeral watches I am aware of are those in ssh and debug-hooks, which simply wait for the presence of the thing at the other end [11:05] rogpeppe, hm, that's interesting [11:05] fwereade_: so you say it's ok to wait forever there? [11:06] rogpeppe, something's knocking at the corner of my mind, gimme a sec [11:06] TheMue, yes, absolutely [11:06] fwereade_: i can imagine there might be race conditions that make it difficult [11:06] fwereade_: how shall i test it without blocking the test forever? [11:06] TheMue, we explicitly got rid of timeouts on command line tools [11:07] TheMue, you do something like I did in the original presence node tests? [11:07] TheMue: what i tend to do is to make sure that it blocks by waiting for a short period, then unblock it and check it unblocks. [11:08] fwereade_: hmm, yes, could do so too, indeed [11:09] TheMue: in fact you'll be testing almost exactly the same code... [11:10] rogpeppe, ServiceRelationState.get_unit_state also checks the ephemeral node, not going to analyse all the callers of that at this stage ;) [11:11] fwereade_: the unit relation ephemeral node? [11:11] rogpeppe, yeah [11:11] rogpeppe, (also we use an ephemeral node to signal presence of an active debug-hooks session, watched by the unit agent; that one should also wait forever) [11:11] fwereade_: still got pain with code waiting for external events endlessly. it disregards the knowledge of > 20 yrs distributed and concurrent systems and caused so much pain. [11:12] TheMue, it *is* basically the underlying model of juju though [11:12] fwereade_: but maybe indeed it's irrelevant for our system [11:12] TheMue, I can't actually think of many places where timeouts are appropriate at the juju level [11:13] fwereade_: yeah, seams so [11:13] TheMue, ZK is keepalive like hell underneath, but from our perspective we can wait forever [11:13] we've already got timeouts and retries happening at a low level [11:13] TheMue, if there are problems we trust ZK to tell us about it [11:13] fwereade_: yeah [11:13] fwereade_: once again i'm driven by my history where this had been a bad behavior [11:14] TheMue, yeah, we all carry baggage [11:14] TheMue, it's hard for me to separate "what the python does" from "how juju should actually do it" ;) [11:14] TheMue, but I think this is a juju-level property not a code-level one [11:14] TheMue, if you see what I mean [11:15] perhaps the question is not: "should there be a timeout?" but "where should the timeout be?" [11:15] fwereade_: but i would like you to discuss it with niemeyer as he said "yes, implement it in presence" and i don't want to follow know your advise and get another one by him in the evening. [11:15] TheMue, I think it comes down to "do you trust zookeeper" ;) [11:15] TheMue, I can totally understand that [11:16] TheMue: for now, why not just make a function in the state package, as suggested by niemeyer? [11:16] TheMue, niemeyer has firm opinions and the final say and while they are not arbitrary or capricious they are hard to predict with 100% accuracy [11:16] rogpeppe: the one in presence as an own branch is by niemeyer [11:17] rogpeppe: we talked about it yesterday when you stepped out [11:17] rogpeppe: the problems of time zones ;) [11:17] TheMue, did he implement it because he knew it was needed himself, or as an alternative to your watcher proposal? [11:17] TheMue, on the assumption that it *was* a necessary feature [11:17] rogpeppe: btw, now rogpeppe, this morning wrtp, yesterday rog. whay this? [11:18] TheMue, I always assumed it was low-level psyops to contribute to an aura of glamorous mystery [11:18] TheMue: better than rogpeppe_ and rogpeppe__, i thought [11:18] fwereade_: that too [11:18] fwereade_: no, the implementation is by me. niemeyer and i talked about moving it to presence yesterday. [11:19] rogpeppe: and why not only one? [11:19] TheMue: because my irc client sometimes reconnects when the irc server already thinks i'm connected, so it has to choose a different one [11:19] rogpeppe: ic [11:20] rogpeppe: thankfully it's seldom here. and short time after reconnect i get my nick back automatically [11:20] rogpeppe: irc is sometimes really unstable, yep [11:21] fwereade_: i think we should let presence.WaitAlive through, despite misgivings. it can go later if we find it's never used. [11:21] rogpeppe, TheMue: I'm ok with that [11:23] rog, fwereade_: hehe, and when i use it in Unit and Machine i'll get the next comments by you? *LOL* [11:23] TheMue: i'll be interested to see what value you choose for the timeout :-) [11:23] TheMue, well, yes, because IMO if you're using timeouts by default then you're using ZK wrong [11:24] * TheMue again wonders why the timeout hasn't been a topic before? [11:24] TheMue, and I don't think you can come up with a timeout value that is a 100% accurate indicator of "something is wrong" as opposed to "ec2 is taking ages, whaddayagonnado?" [11:25] TheMue, I'm pretty certain I have already talked with you about the very small set of clients for watch_agent, and their very limited use cases [11:25] fwereade_: but not about the timeout [11:26] yeah, i don't think we've really discussed timeouts before [11:26] TheMue, no; when I said that it was all unnecessary, and the presence package covers all the use cases already, that's what I meant [11:26] fwereade_: i'm not good in intention reading ;) [11:27] TheMue, nor does it have a custom memory allocator, because it doesn't need that either ;p [11:27] TheMue, I think I honestly did try to direct you to the places you needed to see to understand the use cases [11:28] fwereade_: indeed [11:28] TheMue, the fact that all user interactions must block forever is I suspect the crucial bit of floating context that you were missing [11:29] TheMue, I know that only because I was around when it was discussed and changed to that behaviour [11:30] TheMue, let's put it this way [11:30] fwereade_: exactly, this "block forever" is hard to get. i know different behaviors from those systems i've done in the past. [11:30] TheMue, sorry I forgot what I was going to say [11:31] fwereade_: hehe [11:31] TheMue, really it comes down to trusting ZK [11:31] TheMue, if we do, we should generally assume that the events will land according to ZK's limited guaranteed; and if we don't, we should panic [11:32] fwereade_: a software written in java? no, never! *scnr* [11:32] TheMue, haha :) [11:33] * TheMue has done JEE for > 7 yrs, it has been no (!) good time [11:33] TheMue, I can imagine [11:34] rogpeppe, TheMue: lunchtime :) [11:34] fwereade_: enjoy [11:34] fwereade_: likewise [12:42] TheMue, fwereade_: i'm off to get the train down to london now. will probably be incommunicado tomorrow morning too. see you tomorrow! [12:43] rogpeppe: have fun, take videos, copy slides, publish everything. ;) [13:14] fwereade_, ping [13:14] fwereade_, i'm a little concerned about the ambiguity around the ec2-instance-type arch.. esp as its the most common way people will use constraints [13:14] on ec2 [13:15] hazmat, pong [13:15] hazmat, there was a quiet discussion on the lists about how a 64-bit default would be a good idea, let's do it [13:16] Mornings [13:16] hazmat, is there some other ambiguity? [13:16] niemeyer, mornings [13:16] heya niemeyer [13:18] fwereade_, ah right, yeah.. given 64bit on all types its not much of a concern [13:18] hazmat, I can accept that it's a bit annoying not to be able to type "ec2-instance-type=m1.medium arch=i386" [13:18] hazmat, but there are what, 4 arch-choice types [13:19] hazmat, t1.micro is a bit of a joke really [13:19] hazmat, m1.small is the default in many people's minds, and is what you get if you specify bare "arch=i386" [13:20] hazmat, I think the proportion of our user base who specifically need 32-bit m1.medium, c1.medium, and t1.micro may have to bear it [13:21] fwereade_, fair enough [13:21] hazmat, in fact, they get to experience the awesome productivity shortcut of typing fewer characters in total! ("ec2-instance-type" is a bit of a mouthful...) [13:22] hazmat, niemeyer: of more concern is the HVM image thing [13:23] fwereade_: hm? [13:23] fwereade_, people will choose the explicit when possible [13:23] fwereade_ are there ubuntu images for hvm? [13:23] hazmat, niemeyer: I misread the EC2 information back in the day and somehow got the impression that hvm images were a nice improvement on cluster machines, not a hard requirement [13:23] hazmat, I think so, just a mo [13:24] hazmat, http://uec-images.ubuntu.com/query/oneiric/server/released.current.txt [13:24] hazmat, oneiric server release 20120222 ebs amd64 us-east-1 ami-beba68d7 hvm [13:25] fwereade_, it looks like its only in us-east-1 [13:25] hazmat, just the one, but hopefully that's good enough [13:26] hazmat, cluster instances are only available in us-east-1 [13:28] hazmat, it does mean that get_image_id and get_instance_type are no longer independent, but they were already slightly uncomfortably linked [13:29] hazmat, if I manage to do that quickly this afternoon, would you try to review it in your afternoon? [13:29] fwereade_, cool, that makes more sense then, as for the image_id/instance_type.. that's fine. [13:29] hazmat, I also wanted to ask about your branch [13:29] fwereade_, i could, but i'm wondering if its worth the trouble [13:30] re cc larges [13:30] it would be nice i guess [13:30] hazmat, I'd rather spend a couple of hours to make it not be *guaranteed* to break [13:30] hazmat, it's just way too shoddy to put up with [13:30] fwereade_, if your up for it, it would be nice to round out our ec2 constraints support with the support for the biggest baddest vm on the block ;-) [13:30] hazmat, exactly :) [13:31] hazmat, I already need to check that field anyway, so I don't *accidentally* get an hvm image that won't work with normal instances ;) [13:31] jimbaker: You've got a review on https://codereview.appspot.com/5836049 [13:31] fwereade_, the series from charm branch? [13:32] hazmat, yeah [13:32] hazmat, just let me find it [13:32] fwereade_, https://codereview.appspot.com/5845073/ [13:32] hazmat, AFAICT it's a no-op [13:32] fwereade_: So, what's the deal about 386 vs. amd64? [13:33] niemeyer, you can choose arch on more instance types than just t1.micro now [13:33] fwereade_, hmm. yeah. with_constraints returns the new constraint.. [13:33] niemeyer, for that, I was already defaulting to 64-bit [13:33] fwereade_: Ok, so you were just wondering if it was fine to default to amd64 to all? [13:33] hazmat, and the series certainly is baked into the constraints; it's just happens not to be done at that point [13:34] niemeyer, I think we discussed that on the lists; seemed to get a muted "yeah, sounds good" sort of response [13:34] fwereade_: Yeah, it certainly sounds good to me [13:34] fwereade_: Is there any other contentious point? [13:34] niemeyer, it's a little ungainly specifying 32-bit instances other than m1.smalls, but I think that's an acceptable price [13:36] niemeyer, you'd have to ask for "arch=i386 cpu=5" instead of "arch=i386 instance-type=c1.medium" [13:36] fwereade_, hmm.. ic, its part of the service state api [13:36] s/instance-type/ec2-instance-type/ [13:36] k, i'll yank that branch [13:36] fwereade_: Uh, why? [13:36] hazmat, yeah: the service knows the charm, the series isn't *important* until you've got an actual unit that needs to find a machine [13:37] niemeyer, because of the overlapping behaviour that I think we agreed on [13:37] niemeyer, I could just as easily decouple arch from ec2-instance-type [13:38] niemeyer, but that opens us up to "arch=i386 ec2-instance-type=c1.xlarge" which is still a nonsensical request [13:38] fwereade_: If there is a possibility of selecting the architecture, it means that there isn't an overlap [13:39] niemeyer, true [13:39]