[00:00] * fwereade wishes axw was here, I've suddenly thought it would be a really good idea to drop null providers from environments.yaml entirely [00:01] it's probably time for me to go to bed, if it's actually sane I'll probably remember it in the morning [00:01] hopefully you'll wajke up and release will be good :-) [00:05] davecheney: any chance of confirming that this works for you? https://pastebin.canonical.com/98846/ [00:25] * davecheney look [00:25] ha, and you called my hack gross [00:25] :) [00:25] give it a go [00:25] can't make it any worse [00:37] this hack won't change cli though [00:57] davecheney: if it works: https://codereview.appspot.com/14592044 [01:21] anyone around? [01:22] marcoceppi_, whats up? [01:22] hazmat: any idea of `juju bundle` is going to be used at all in the near future? [01:22] s/of/if/ [01:24] marcoceppi_, there's some discussion for bundle v2 @ the sprint [01:25] marcoceppi_, afaik no use, what were you thinking of? [01:25] hazmat: okay, I've got plans to land a juju-bundle plugin I might hold off on that name for now [01:25] marcoceppi_, bundle plugin that would export a bundle? [01:25] marcoceppi_, there's already one of those in deployer fwiw [01:26] hazmat: I'm adding bundle support to charm-tools, ie `juju charm create --bundle`, wanted to make `juju bundle create` an alias of charm with --bundle flag [01:26] marcoceppi_.. hmm.. i think there's likely some confusion there with exporting a bundle [01:27] marcoceppi_, not sure i understand the value of an empty bundle though [01:27] its not just a single file but the metadata format that gui is pushing? [01:27] ie. a dir and icon and export file? [01:27] hazmat: this would create a directory with a README on how to create bundles from the gui [01:27] hazmat: gui stuff [01:27] hazmat: also adding proof support for GUI bundles [01:28] I feel bundles are too commonly used for too many things [01:28] marcoceppi_, that's bad because? [01:28] hazmat: the bundle name, not the deployer config stuff itself :) [01:29] marcoceppi_, re the dir thing and readme, that sounds like it belongs the in the new gui help system [01:29] ie i don't generally go to the commandline to seek help on the gui [01:29] or perhaps in the docs [01:30] marcoceppi_, fair enough.. i'd love to see them back with their original name.. 'stack' [01:30] hazmat: good point, I might defer that portion and simply update proof to proof bundles. As for creating, I orininally spec'd that for charm-tools since there was mention of README, icon.svg, and bundle.yaml [01:30] but sadly too much baggage atm re stack [01:30] but the icon.svg req was dropped [01:31] marcoceppi_, yeah... the only place that spec is used is the unpublished/undocumented used internally by charmworld afaik [01:31] almost every real world bundle is just a yaml/json file [01:31] argh.. grammar fail late night [01:31] hazmat: right, up until next week when bundles land in the gui and they expect a readme and bundle file [01:32] marcoceppi_, ic. hence the proof support [01:33] marcoceppi_, the create thing sounds like it would be better done as an addition to the doc [01:33] hazmat: right, proof and promulgation support [01:33] the gui has some significant issues with its bundle exports last i looked [01:33] marcoceppi_, the promulgation should just work the same as charms afaicr [01:33] hazmat: I'm going to defer the create stuff, since both promulgate and proof can determine if it's a charm or bundle automatically [01:34] hazmat: right, with the exception it's lp:~charmers/charms/bundles//bundle [01:34] hazmat: which is easy enough to sort out [01:34] namely it exported default config as explicitly set config, and some exporting of empty constraints. [01:34] marcoceppi_, cool [01:34] hazmat: I'm not aware of any of those issues [01:35] * marcoceppi_ just needs to make sure proof and prom work [01:35] marcoceppi_, try an export in the gui, view the output, notice that all the config options are set [01:35] even though none where actually changed from the charm default [01:35] hazmat: will give it a go [01:38] just filed a bug on it [01:39] bug 1237739 fwiw [01:44] the empty constraints thing looks like its solved on comingsoon though not on jujucharms.com [01:58] juju lucky(~/src/launchpad.net/juju-core) % juju ssh p1/0 [01:58] ERROR unit "p1/0" has no public address [01:58] getting this quite a lot lately [01:59] wallyworld, did you say that sync-tools can send tools to a testing location, such as /juju-dist/testing/tools? [01:59] sinzui: i think user specified destination can currently only be a local directory [02:00] otherwise it uploads to control bucket in the "proper" location [02:00] let me quickly check [02:01] wallyworld, that's all fine. I will use swiftclient to deliver the tools to /juju-dist/testing as I did last week [02:01] ok [02:01] we can add something to the tool if needed [02:02] davecheney: is the logging change any good? [02:03] wallyworld: try it now [02:03] wil be a while [02:04] everything is slow [02:04] :-( [02:12] sinzui: 1.16.0 isn't cut yet right? fwereade OK'd merging in https://bugs.launchpad.net/juju-core/+bug/1235716 overnight [02:13] wallyworld: what si the MP for that change ? [02:13] axw, you can add to it. [02:13] again [02:13] sorry [02:13] bueno [02:16] davecheney: https://code.launchpad.net/%7Ewallyworld/juju-core/default-debug-logging/+merge/190282 [02:18] ta [02:19] testing now [02:27] Guys, is there any away I can tell juju to just download the precise-amd64 tools AND NOTHING ELSE? [02:27] I'm not deploying saucy-armhf any time soon. [02:27] jpds: this is when bootstrapping i assume [02:27] wallyworld: Yes. [02:28] the logic to get all series has been around forever. it's not currently possible afaik [02:28] how critical is it? [02:29] Not critical, I'm just on a super slow link here and I just need one of the tools. [02:29] yeah, understand [02:30] you could download just the one and then sync-tools manually [02:30] then when you bootstrap, it will find it and not attempt to download anything else [02:31] So, how do I do that? [02:31] wallyworld: works perfectly [02:32] thank you for fixing it [02:32] davecheney: \o/ [02:32] jpds: get the tarball, copy it to /tools/releases, then run juju sync-tools --source= [02:32] davecheney: if you can lgtm that would be great [02:33] jpds: that will upload that one tarball to your control bucket [02:33] which is one of the places bootstrap looks [02:33] https://pastebin.canonical.com/98849/ [02:33] so it will be found [02:33] soordered [02:34] wow 18kbps [02:34] fast, not :-( [02:35] sinzui: i am about to land a logging fix for davecheney. is it too late to include that in 1.16? [02:35] wallyworld: It can trail at <1kB/s. [02:35] wow [02:35] jpds: this should make it so no outside net access is reuired [02:36] Yeah, it'll make my life so much easier. [02:38] Now the customer is complaining that juju needs to download too much stuff from the internet. [02:38] only the tools, and this will fix that [02:38] jpds: the doco for all this obviously needs to be written [02:38] wallyworld, no. [02:38] we need a "how do i set up my private cloud" faq [02:39] I want to complaing about places in sub-Saharana Africa having a better net connections. [02:39] sinzui: i've proposed for trunk. i'll put up a mp for 1.16 and then land [02:39] wallyworld: That would be nice. [02:40] All this stuff is just shoved in my head at the moment. [02:40] jpds: as with these things, the code comes first to make ti woek, then the doc follows [02:40] we are all scrambling to make the 1.16 cut off [02:41] we do know the doc needs to be written [02:41] maybe one day we can shove a usb cable in our neck and it will all just flow out [03:01] all: if I do relation-set in a hook [03:01] then relation-get in the same hook without commiting the hook [03:02] will I be able to see the value I just set ? [03:12] sinzui: the logging change has merged [03:23] thank you wallyworld [03:23] hopefully everything works ok :-) [03:23] dave tested it so should be good [03:25] wallyworld: Is 'juju sync-tools --source=' only in devel? [03:25] jpds: it was included before 1.16 branched [03:25] what version are you running? [03:25] 1.14. [03:25] stable. [03:26] oh. i'm not sure what's in that version. give me a sec to have a look [03:27] jpds: actually for 1.14, i'm not sure that using the private storage is even an option :-( [03:27] I have a /home/ubuntu/tools/releases/juju-1.14.1-precise-amd64.tgz [03:27] i'll check [03:30] jpds: a quick look tells me that --source should work [03:31] $ juju sync-tools -v --source=/home/ubuntu/ [03:31] error:: no available tools. [03:32] 1.14 may have required the tools just to be under tools not tools/releases [03:33] try putting the tarball in /home/ubuntu/tools [03:33] the releases location is a simplestreams thing [03:33] There we go. [03:33] and 1.14 did not fully support that when it was created [03:45] jpds: i have to go to the school - my kid has left his viola at home. do you need to ask anything or is it going ok with the tools uploaded? i'll be back soon anyways [03:45] wallyworld: Yes, it's bootstrapping. [03:46] Thanks! [03:46] great!! [03:46] np [06:00] davecheney: any ideas on a ETA for the squid charm merges I proposed? I'm needing to do other work on the charms, and it'd be nice to not have to work around the unmerged code [07:24] davecheney, yes, you should be able to [07:51] mornin' all [07:52] morning rogpeppe [07:52] and fwereade [07:54] fwereade, morning, don't suppose you can elaborate on the meaning of this comment? https://codereview.appspot.com/14389043/diff/9001/cmd/juju/helptool_test.go#newcode37 [07:55] mattyw: he loves it? :) [07:55] mattyw, it means "thank you, I sincerely appreciate you fixing this" [07:55] axw, rogpeppe: heyhey [07:55] fwereade, axw ok thanks :) [08:02] axw, so, I'm sorry about the sudo password thing, I should probably have just approved it straight off... did you get an opportunity to get it in for 1.16? (and... eh, can *you* think of any way to use the values we ought to..? at all?) [08:02] fwereade: not a problem - it's merged [08:02] fwereade: I haven't come up with any good ideas [08:03] fwereade: "any way to use the values we ought to?" [08:03] non capisco [08:03] axw, sorry, to use the command context's stdin/out/err [08:03] oh right [08:04] fwereade: the only thought I had was to have some central package in juju, akin to "os", that has a pseudo Stdin/Stdout/Stderr [08:04] but... not really sure if that's any better than using os :) [08:04] axw, eh,replacing one global with another ain't so great really [08:04] indeed [08:06] axw, there may be a case to be made for requiring a cmd.Context (OSContext or something maybe?) in a whole bunch more places... eg access to env vars is not usefully restricted, and they're even more global than globals [08:06] axw, tedious to have to thread that through everywhere though ofc [08:07] fwereade: hmm yeah good point on env vars. [08:08] fwereade: when is ctx.Stdout ever going to be something other than os.Stdout? only for tests? [08:08] axw, in jujuc commands it's not [08:09] axw, they don't create envs/env configs though, so not really very relevant [08:09] fwereade: ah yes. [08:10] fwereade: not sure if it was quite obvious, but sshstorage's requirement is extra special: stdin must be a tty/pty [08:10] for remote sudo [08:11] axw, ha, yes [08:11] and its use of stdout only makes sense if it's interactive [08:20] axw, rogpeppe, wallyworld: ok, I'm now thinking about the manual-bootstrap default-series problem [08:20] i'm not familiar with the issue [08:21] wallyworld: https://codereview.appspot.com/14433058/ [08:21] axw, rogpeppe, wallyworld: it fails if default-series doesn't match the actual series of the bootstrap machine [08:21] wallyworld, rogpeppe : gist is: null provider's bootstrap machine should dictate what the boostrap tools are [08:22] but bootstrap tools are always default-series [08:22] axw, rogpeppe, wallyworld: and this is because we restrict the possibleTools we pass in by that series, even though there's no real reason to [08:22] yeah, i've always had doubts about our approach [08:22] axw, rogpeppe, wallyworld: and ISTM that this is because we didn't manage to finish getting tools out of that interface entirely [08:23] axw, rogpeppe, wallyworld: they should never have been there in the first place, but turning it completely inside out was too much work [08:23] i sorta kept them in the interface because that's how it was and i didn't want to change too much [08:24] axw, rogpeppe, wallyworld: yeah, indeed, but I think we're now at the point where we have to push further there [08:24] +1 to that [08:24] * wallyworld is about to eat dinner, bacl later [08:24] wallyworld, enjoy [08:24] fwereade: sorry, i'm not quite with you here. what are you proposing to change? [08:25] rogpeppe, I think we shouldn't be passing possibleTools into bootstrap (or really StartInstance for that matter) [08:26] fwereade: one problem I can think of immediately, is how to ensure tools are in storage [08:26] rogpeppe, does that make approximate sense, independent of the question of how we might get there from here? [08:26] that fun bit of code we were looking at yesterday [08:26] axw, yeah, I think that code is just in the wrong place [08:27] axw: that's a good question [08:27] axw, fwereade: what if StartInstance itself was responsible for ensuring the tools are there? [08:27] rogpeppe, I'm not 100% sure about StartInstance, but Bootstrap almost certainly should be [08:28] this would have to lead to --upload-tools disappearing [08:29] axw: really? [08:29] and rely on sync-tools if you want to do those kinds of things [08:29] axw: i'm not sure i see the reasoning there [08:29] rogpeppe: what would --upload-tools do if Environ.Bootstrap is responsible for ensuring tools are in storage? [08:29] or you have the logic in two places [08:30] I suppose [08:30] axw: they can potentially re-use some of the same logic [08:31] axw, rogpeppe: I think that --upload-tools could probably still work -- putting the tools is conceptually independent of choosing them I think [08:32] axw, rogpeppe: but the auto-sync logic would need to move inside bootstrap [08:32] axw, rogpeppe: and I think we'd need to untangle upload from sync tomake that sane [08:32] fwereade, rogpeppe: fair enough. you could upload in the command, and do the rest in bootstrap [08:32] fwereade: agreed. that would be a good thing anyway imho [08:33] rogpeppe, +1000 [08:34] bugger, I need to help cath a bit [08:34] and I need to get dinner on [08:34] bbs [08:35] it would be nice if StartInstance would be responsible for fetching tools on demand; then we wouldn't need to push all that stuff up front [08:35] however, i'm not sure it's possible, as i don't think there's any way of syncing tools concurrently [08:46] morning folks! hows 1.16.0 looking? milestoned bugs list looks great to me [09:16] jamespage, I have not heard from sinzui since last night, but he said he was doing preliminary tests without the last (logging config) bug -- so I hope that if there had been problems I would have heard [09:18] fwereade, do you have a moment? [09:18] mattyw, sure [09:19] fwereade, thanks. just looking at your comment here https://codereview.appspot.com/14389043/diff/9001/worker/uniter/context.go#newcode69. I like the idea of putting all the args into a stuct, but it would look very similar to the HookConext struct which it builds anyway [09:20] so I'm wondering if there's much value in taking the args in as a struct? [09:20] mattyw, ha, yes, it would, wouldn't it [09:22] mattyw, the value is in documenting the meanings of the params, I guess [09:22] mattyw, but I'm not sure it's that valuable really [09:22] mattyw, just one client [09:23] mattyw, but then it is an exported func [09:24] mattyw, how about unexporting it? and adding a NewHookContext passthrough in export_test? [09:24] mattyw, or we could just say "this bit's a bit smelly" and move on [09:24] mattyw, if the unexport idea doesn't immediately strike you, personally, as a good idea, feelfree to leave it as it is [09:27] fwereade, I'll let the marinate for a bit, in the meantime I'll propose the changes I've made for the other comments if that's ok? [09:28] mattyw, sounds great, thanks [09:31] someone on #juju having issues with OS X, if anyone has the time/knowledge [09:32] he's trying trunk to get past the EC2/VPC bug [09:37] how do I get juju to show more output from hook errors? [09:42] TheMue, you're probably the man to respond to axw's suggestion [09:43] fwereade: I think it's an impasse [09:43] he's trying to run 1.17.0 [09:43] teknico, if the env is already running, `juju set-env logging-config="=DEBUG"` [09:43] well, trunk [09:43] which can't find released tools, so tries and fails to upload [09:43] axw, hum, yeah, that's need tools built [09:43] fwereade, whenever you're ready https://codereview.appspot.com/14389043/ thanks [09:44] fwereade: thank you, trying that [09:48] axw: will contact him [09:51] mattyw, ha, I just spotted something, I feel dumb now -- micro-review sent [09:54] fwereade, if I put it in the service doc doesn't that mean it goes into mongo? I thought we were trying to avoid that for the moment? [09:56] mattyw, the method can still return what we return from the service though, right? [09:56] mattyw, no need for a field yet [09:57] mattyw, I'm just thinking of where we put the logic [10:06] fwereade, do you mean I could just do OwnerTag: svc.GetOwnerTag() in megawatcher.go:134? [10:06] and then make GetOwnerTag() a method on serviceDoc - until we implement it properly? [10:06] mattyw, essentially, if you just put that method onto serviceDoc instead of Service [10:06] mattyw, yeah exactly [10:07] mattyw, you can even keep it on serviceDoc indefinitely I think [10:07] mattyw, just call through from Service [10:07] fwereade, there don't seem to be any other method on serviceDoc, so this would be the first? [10:08] mattyw, it would -- I'm not sure whether it's better as a method or a freefunc [10:20] fwereade: you've gone... [10:21] https://launchpad.net/juju-core/+milestone/1.17.0 [10:21] rogpeppe, so it seems, I have been having some luck lately with sshuttle, thought it was goodenoughfornow [10:21] fwereade: :-( [10:22] :b3 [10:22] ^^ that was meant for vim [10:32] fwereade, sorry me again :), is this basically what you had in mind? http://pastebin.ubuntu.com/6217438/ [10:53] fwereade, you probably missed me asking if I roughly had the right idea here http://pastebin.ubuntu.com/6217438/ [11:05] TheMue: do you drink coffee? trying to plan for how much coffee to bring to SF. I roast my own coffee and don't want to have to live off hotel coffee for a week. [11:06] natefinch: hey, cool. yes, i like coffee very much. sounds fantastic. [11:07] TheMue: awesome. I'll make sure to bring a few different kinds. [11:07] natefinch: having a coffee gourmet as roomie has been a good decision. :) [11:10] TheMue: haha yep. I have like 10 different varieties of beans at home right now., I buy them from here: http://www.sweetmarias.com/prod.greencoffee.mvc.php [11:11] natefinch: that's slightly unbelievably coffee-snobish :) [11:11] mgz: it's a hobby. it helps that buying unroasted beans is 1/2 the price, and they're shelf stable for up to a year [11:12] :) [11:12] it sounds fun, right up to the point where you have to start travelling with roasting and grinding apparatus :) [11:13] well, I won't be roasting in SF... it produces a bunch of smoke, I think the hotel would get mad at me... that and the roaster is rather large. [11:14] I haven't decided what to do about grinding. Ideally you grind immediately before brewing, but my grinder weighs like 8 pounds [11:15] I may have to suck it up and grind ahead of time like some sort of plebe [11:40] jam, fwereade: unset is now exposed. a review of https://codereview.appspot.com/14439053 please [11:41] or anyone else [11:44] TheMue, LGTM, thanks [11:44] fwereade: TheMue: reviewed [11:45] TheMue: it would be nice to have 1 more test, but I wouldn't block landing that for 1.16. [11:47] jam: unset has so few options, had no idea what to test more ;) [11:47] TheMue: just 'juju unset --help" [11:48] which is the only way *I've* found of reliably asserting you've actually registered the command. [11:48] jam: sound good, yes, will keep it in mind. just oriented at the set command [11:52] fwereade: need some help, merging it in trunk is well known to me. but how do i get it in 1.16? [11:56] jam: or you? [11:56] TheMue: "lbox propose -for lp:juju-core/1.16" [11:56] but you need to build it from "lp:juju-core/1.16" [11:56] and then the same "Mark Approved, set commit message" [11:57] jam: thx, and shit, built it from trunk [11:58] TheMue: so generalyl something like "bzr branch lp:juju-core/1.16 $SOMEWHERE"; bzr switch $SOMEWHERE; bzr merge $EXISTING_BRANCH -c -1, bzr commit -m "Just the cmd_unset change"; lbox propose -for lp:juju-core/1.1.6 [11:58] the merge might need to be a bigger range [11:58] if you have more than one commit [11:59] jam: no, just one commit [11:59] jam: will try now, thx [12:06] jam: don't get it with the switch, where do i have to call it? because from where i've done the branching or inside the branch it doesn't work [12:06] * TheMue feels like a bazaar noob [12:06] TheMue: use whatever mechanism you usually do to create a new branch, just base it from "lp:juju-core/1.1.6" [12:06] `1.16" of course [12:07] jam: yeah, branch is created [12:07] TheMue: so for the merge you can do: bzr merge -c -1 lp:~themue/juju-core/052-expose-unset [12:08] you don't have to do the switch, it is just what *I* do to create a new branch and point src/launchpad.net/juju-core to it [12:08] ic [12:11] "All changes applied successfully." welcome to the world of branching and merging. [12:16] jam: so, now proposed. now approving with message. [12:17] jam: done. and for trunk? simply approve the first one too? [12:18] TheMue: so we can do it that way. The way *I*'ve done it on other projects was to just continually merge a stable branch => trunk (so once your patch lands on 1.16, then merge 1.16 => trunk) [12:18] * TheMue has to write this down in his work process document [12:18] TheMue: but there is a bit of discussion as to whether we are landing on trunk and backporting [12:18] or landing on stable and merging up [12:18] *I* like the latter, but I was part of developing bzr :) [12:19] I prefer the simpler way. so if you you got one with one command and another one with two or more I'll take the first one. ;) [12:20] TheMue: well what you just did was cherrypick the trunk proposal back to 1.16, so it is obviously more straightforward for *this* patch to just land it on trunk [12:20] but going forward [12:20] if you know we want a change in the stable branch [12:21] it doesn't require thinking about it as much to just commit to something branched from 1.16 and merge it up [12:21] TheMue: does that make sense/ [12:21] ? [12:21] jam: yes, absolutely [12:21] you don't have to think about how to cherrypick which is sometimes confusing to get the right bits [12:21] jam: so for this time i'll take the simple way but next time i start with the according branch directly. has been my fault. [12:22] TheMue: well the team as a whole hasn't done much stable + dev development [12:22] in Bazaar, we had 3+ stable branches for various Ubuntu releases [12:22] imagine if we were supporting 1.12, 1.14 and 1.16 for 6+ months [12:22] being able to land in 1.12 [12:22] and then just merge into 1.14 and then 1.16 [12:22] was very nice [12:23] jam: gna, so multiple switches the whole time every day. fantastic [12:24] jam: in my former jobs we mostly worked on trunk and only tagged it (no product business, all linear projects) [12:24] jam: only once in good old cvs times worked on a product which has to be maintained [12:24] TheMue: to be fair, that is pretty close to what we're doing in juju-core so far [12:25] TheMue: yeah, CVS made it very hard to manage multiple ongoing branches [12:25] jam: but what will change [12:26] jam: I'm happy that I now get more and more into git workflows for my private projects [12:28] TheMue: yeah, I'm not sure how much we'll actually commit to a "stable" juju. I would hope we commit to a stable *client* for Ubuntu 14.04 [12:28] [12:29] jam: but to be more philosophical, what in the world is stable? ;) [12:30] TheMue: committing that you'll make changes that can be rolled out directly to clients that won't accidentally introduce regressions because of introducing new functionality they aren't using [12:32] jam: that's how it should be [12:32] jam: btw, thanks, branch has landed in 1.16 [12:34] sinzui: TheMue's patch for exposing "unset" has landed in 1.16, so you should be good to go [12:34] ! [12:34] thank you very much jam [12:35] * TheMue => lunch (wife just called) [13:21] * fwereade needs to look after laura for a while, she's about to get back from school and cath isn't yet; bbl [13:33] a simple review for anyone that wants to take a look - no logic changes, just a bit of type juggling: https://codereview.appspot.com/14529050 [13:33] * rogpeppe goes for lunch [13:33] looking [13:49] anyone interested in looking at my new constraint that covers ec2 instance names?cd ../ [13:49] heh oops [13:50] here's the CR for ^^ https://codereview.appspot.com/14523052 [13:51] *click* [14:23] natefinch: what is when you're using a type which is not matching the hardware constraints? [14:24] TheMue: not sure I understand the question. But if you're asking about types other than EC2 instances.... right now we don't support it, and it would be a constraint that can't be fulfilled, like if you asked for a machine with 10T of memory [14:25] TheMue: we probably should just error out early and tell the user they've specified a constraint that isn't valid... but I wasn't sure if I should special case the type constraint, or if we should write a general constraint validator (since other constraints can also just be plain wrong... like tags that don't exist in MaaS) [14:26] TheMue: it's also possible to mix type constraints with other constraints to produce an impossible combination.... like asking for an m1.small with 4 CPUs. We could error out early on that, as well. [14:34] * sinzui really must optimise what is uploaded to azure for testing [14:35] natefinch: that's what I meant. I could use constraints regarding mem and cpu that doesn't match the type [14:35] natefinch: and I'm not sure what has precedence [14:36] natefinch: or how it is detected and reported as problem [14:42] TheMue: right now it is not specifically reported as a problem... what it will do is simply not match any existing instance types, so the procurement will fail [14:43] TheMue: type is just another attribute, like number of CPU cores. It just happens to be an attribute that is unique to a single type of EC2 machine. [14:44] TheMue: so it would be like asking for a machine with 8 CPUs and 32G of RAM, if EC2 didn't have such an instance - it would fail to find any matching instance [14:44] natefinch: ok, so I can use the type to ease my work but I also can add more constraints with the risk that the command fails [14:45] TheMue: correct. For example, root-disk will work just fine with it. You can ask for a m1.medium with 20G of root-disk, and that'll work. [14:46] TheMue: I think sanity checking constraints before sending them off to the server is something we should do, but it involves more than just the instance type constraint I just wrote. It probably should be done as a separate changelist [14:48] natefinch: ok, thx, got it [15:09] mgz: did you get around to reviewing that CL? https://codereview.appspot.com/14529050 [15:16] rogpeppe: sorry, still have that tab open, resuming [15:16] mgz: np [15:24] fwereade, mgz: FYI this is the mechanism i'm implementing to enable filtering of RPC log events: http://paste.ubuntu.com/6218476/ [15:24] rogpeppe: lgtm'd [15:24] mgz: ta! [15:28] natefinch, fwiw axw has a prechecker mechanism that will enable just that [15:28] fwereade: swet [15:28] sweet too [15:29] natefinch, but I *think* that we need some additional complexity around instance-type vs mem/cpu/etc [15:29] natefinch, in python we had the notion of conflicting constraints [15:29] natefinch, ie you cannot specify both mem and instance-type together [15:30] natefinch, and if you have an instance-type env constraint, and a mem service constraint, the mem constraint masks out the instance-type one when you combine them [15:30] natefinch, but *that* then introduces root-disk confusion [15:31] natefinch, because openstack instance types do mask them, but ec2 ones don't [15:32] jamespage, fwereade I am blessing lp:juju-core/1.16 r1969. I will make the tarball [15:32] sinzui, <3 [15:38] fwereade: I think we need per-provider constraint resolution... because it's entirely possible that constraints could be easily detectable as impossible on EC2 and easily detectable as ok on azure [15:39] natefinch, we do indeed, but while we're still using one provider per environment it's not too bad [15:39] sinzui: I just merged a branch to 1.16 btw, after 1969 [15:40] natefinch, as we move towards multi-provider environments, we'll need to disambiguate by provider [15:40] oh? I don't need to panic [15:40] sinzui: it's just docs changes, but it would be good to have in 1.16 [15:41]