| davecheney | thumper: I think you need to repropose https://codereview.appspot.com/8701043/ | 00:04 |
|---|---|---|
| davecheney | it talks about a StringSet type | 00:04 |
| thumper | ok... | 00:04 |
| davecheney | but one does not exist in trunk | 00:04 |
| * thumper proposes | 00:04 | |
| bigjools | I had no idea you loved me | 00:04 |
| thumper | I also tweaked a few bits in the stringset file, to remove some ", _" bits | 00:04 |
| thumper | when iterating over the dict | 00:05 |
| thumper | bigjools: I do love you, but you are married already | 00:05 |
| bigjools | and I have baggage | 00:05 |
| davecheney | pick me pick me | 00:07 |
| davecheney | i only have carry on | 00:07 |
| thumper | davecheney: updated | 00:07 |
| davecheney | thumper: responded | 00:22 |
| davecheney | very nice | 00:22 |
| davecheney | just a few thigns | 00:22 |
| thumper | ta | 00:22 |
| thumper | I'll look after I've made some lunch :) | 00:22 |
| thumper | thinking bacon, cheese and egg toasty | 00:22 |
| davecheney | kk | 00:23 |
| davecheney | m_3: ping | 00:27 |
| thumper | davecheney: it isn't possible to provide an interface for a structure that'll support iterating using range is there? | 00:43 |
| davecheney | thumper: no sadly not, user types cannot implement whatever range wants | 00:44 |
| thumper | :( | 00:44 |
| thumper | davecheney: by using NewStrings in the union, intersection, difference methods, means we can directly poke the implementation map knowing that it has been initialized | 00:56 |
| thumper | davecheney: otherwise we'd need to use the Add function that has the check every time | 00:56 |
| davecheney | thumper: fair enough, ignore that comment | 00:57 |
| thumper | ok | 00:57 |
| * thumper continues... | 00:57 | |
| === wedgwood_away is now known as wedgwood | ||
| === wedgwood is now known as wedgwood_away | ||
| thumper | davecheney: does the juju team have a pgp key-pair for signing packages? | 03:27 |
| thumper | davecheney: I'm thinking about the tool signing process | 03:27 |
| thumper | davecheney: for uploading tools, and for verification | 03:27 |
| thumper | I'm messing around with go.crypto trying to see how it works | 03:27 |
| thumper | in particular, how we could verify keys | 03:27 |
| davecheney | thumper: ~juju does not have keys, to the best of my knowledge | 03:58 |
| thumper | davecheney: I've just created a 4096 bit RSA gpg key here for juju-dev | 03:58 |
| thumper | davecheney: for my experimentation | 03:58 |
| thumper | perhaps we could use that... | 03:58 |
| thumper | if this works | 03:58 |
| davecheney | sure | 04:02 |
| davecheney | it's just entropy | 04:02 |
| thumper | davecheney: I'm now getting go people following me on twitter... | 04:02 |
| davecheney | this is a bad thing ? | 04:02 |
| thumper | not necessarily | 04:05 |
| thumper | maybe if I tweet enough, we'll get generics :) | 04:05 |
| thumper | perhaps it is time for me to write my inaugral go blog post | 04:05 |
| davecheney | gotta do it once a year, just like changing your jocks | 04:06 |
| thumper | :) | 04:06 |
| * thumper is looking for examples of someone actually using go.crypto/openpgp | 04:08 | |
| davecheney | jamespage_: ping | 04:13 |
| davecheney | mramm said that you had mongo for quantal available | 04:14 |
| davecheney | can you hook me up ? | 04:14 |
| jamespage | davecheney, I've requested the backports for 12.04 and 12.10 | 04:15 |
| jamespage | ppa:james-page/mongodb2.2 contains backports for 12.04 and 12.10 | 04:15 |
| davecheney | jamespage: fantastic | 04:15 |
| jamespage | suggest that those packages are copied to some sort of official PPA until the packages land in backports | 04:15 |
| davecheney | ok, checking it out | 04:16 |
| davecheney | we have ~juju/experimental as the PPA which is injected into cloudinit for P and Q machines when they are bootstrapped | 04:16 |
| * thumper off to take the kids ice-skating... | 04:34 | |
| thumper | davecheney: just in case you know people working on go.crypto : http://stackoverflow.com/questions/16007695/verifying-a-signature-using-go-crypto-openpgp | 04:34 |
| davecheney | jamespage: https://launchpad.net/~juju/+archive/experimental/+packages | 05:08 |
| davecheney | is it possible to bump the build version for quantal ? | 05:08 |
| davecheney | I need a 0ubuntu2 | 05:08 |
| davecheney | unless it is possible to delete from a PPA (which I assume is not possible) | 05:08 |
| jam | wallyworld_: welcome back, I see you escaped the lions, but did you do so all in one piece? :) | 05:56 |
| wallyworld_ | jam: thanks. yes, all in one piece. they are quite placid, unless you are a zebra wtc | 05:57 |
| wallyworld_ | jam: bloody brilliant. i apt-upgraded this morning and now it appears no usb devices can be seen :-( | 05:59 |
| jam | wallyworld_: is your keyboard and mouse PS2 then? | 05:59 |
| jam | that is pretty awful | 05:59 |
| wallyworld_ | jam: no, i'm referring to my headphones, and also checked with a memory stick | 05:59 |
| wallyworld_ | just now, preparing for meeting | 05:59 |
| jam | sure | 05:59 |
| wallyworld_ | let me reboot. works for windows :-( | 06:00 |
| jam | try another port perhaps? | 06:00 |
| jam | :) | 06:00 |
| wallyworld_ | done that | 06:00 |
| jam | wallyworld_: saw you for a moment there | 06:05 |
| wallyworld_ | yeah, usual mumble shittiness | 06:05 |
| wallyworld_ | still trying to make it happy | 06:05 |
| jam | wallyworld_: I'm fine doing google chat for our 1:1's if it works better for you. It is just the standup where we can't all get along. | 06:06 |
| wallyworld_ | i'll try once more | 06:06 |
| mramm | davecheney, thumper: hi | 06:20 |
| davecheney | mramm: could you please expand on your prevoius reply | 06:20 |
| davecheney | should I stop or continue ? | 06:20 |
| mramm | keep working on what you are working on | 06:20 |
| davecheney | mramm: understood | 06:20 |
| * davecheney goes back to compiling | 06:21 | |
| mramm | I'm saying that they will be working on whatever needs working on to get stuff into the release | 06:21 |
| davecheney | understood | 06:22 |
| wallyworld_ | jam: mumble died, sec | 06:36 |
| jam | wallyworld_: I heard you for a second | 06:36 |
| jam | but apparently you don't hear me | 06:36 |
| rogpeppe | mornin' all | 06:51 |
| rogpeppe | fwereade_: pin | 06:51 |
| rogpeppe | g | 06:51 |
| fwereade_ | rogpeppe, heyhey | 06:51 |
| rogpeppe | fwereade_: fancy a chat? | 06:51 |
| fwereade_ | rogpeppe, sure, would you start one please? | 06:52 |
| rogpeppe | fwereade_: https://plus.google.com/hangouts/_/a978de2c1b769c0250011c76024919656376b1f8?authuser=0&hl=en-GB | 06:52 |
| aero1 | Hi all! I've been working on https://github.com/AeroNotix/hpcloud before learning about juju. Would my help be worthwhile in juju itself or do we follow different goals? | 07:41 |
| aero1 | HPCloud has some extensions to OpenStack such as RDMS etc, I have bindings to those. | 07:41 |
| jam | aero1: do you mean 'hpcloud' vs "goose' (the openstack bindings?) | 08:06 |
| aero1 | sure | 08:06 |
| jam | juju is more about being able to deploy ubuntu packages into the cloud. | 08:06 |
| aero1 | oh ok | 08:06 |
| davecheney | Uploading mongodb-clients_2.2.4-0ubuntu2_amd64.deb: 2645k/19783k | 08:06 |
| aero1 | so, goose. | 08:06 |
| davecheney | Uploading mongodb-clients_2.2.4-0ubuntu2_amd64.deb: 2645k/19783k | 08:06 |
| davecheney | whoo | 08:06 |
| davecheney | finally | 08:07 |
| davecheney | only taken all day | 08:07 |
| jam | davecheney: grats | 08:07 |
| jam | goose is meant to be reasonably generic, I don't think we have a problem with having some extensions as well. | 08:07 |
| davecheney | jam: this should fix the problem bootstrapping quantal nodes | 08:07 |
| jam | aero1: but it certainly is focused on being access to any openstack deployment. | 08:07 |
| * fwereade_ cheers at davecheney | 08:07 | |
| jam | davecheney: so the ppa had non-ssl? | 08:07 |
| davecheney | jam: nope, bigjools fucked it up :) | 08:07 |
| davecheney | we had a fight with LP, and lost | 08:08 |
| bigjools | bollocks did I | 08:08 |
| jam | bigjools: well, as long as we can blame you, it doesn't matter if you did :) | 08:08 |
| davecheney | bigjools: https://bugs.launchpad.net/juju-core/+bug/1168196 | 08:08 |
| davecheney | the web doesn't lie | 08:08 |
| davecheney | something is broken, you probably did it | 08:08 |
| bigjools | sure | 08:08 |
| bigjools | the executable had ssl options on it. NEXT. | 08:09 |
| davecheney | good, i'm glad we're all clear on that | 08:09 |
| davecheney | bigjools: jam Successfully uploaded packages. | 08:20 |
| davecheney | but it hasn't shown up on the PPA page yet | 08:20 |
| davecheney | how long is the delay ? | 08:20 |
| jam | davecheney: if those are source packages, you get queued into the builders, and it depends how busy they are. | 08:20 |
| jam | Generally a couple hours. | 08:20 |
| davecheney | this was a binary | 08:20 |
| davecheney | i spent most of the day building it | 08:21 |
| jam | davecheney: personally, I didn't think you could upload binaries to PPAs. I thought LP had to build it. | 08:21 |
| davecheney | http://paste.ubuntu.com/5709833/ | 08:21 |
| davecheney | where did it go ? | 08:21 |
| davecheney | i have to go and make dinner | 08:24 |
| jam | davecheney: I believe the deb handler will silently ignore files it doesn't like, to avoid being an attack vector. | 08:24 |
| davecheney | if anyone knows where that package has gone, pleas let me know | 08:24 |
| davecheney | maybe i nede to push my gpg key to LP | 08:25 |
| davecheney | is there a command for that ? | 08:25 |
| jam | davecheney: I'll ask around on Launchpad, but I'm pretty sure the default is that you can only upload source packages to LP | 08:25 |
| davecheney | i'm following the instructions mims sent me | 08:25 |
| davecheney | which produced the current ppa's we have in experimental | 08:25 |
| jam | bigjools: can you confirm? | 08:26 |
| jam | davecheney: I thought there was a <10min time for the archive to poll the new uploads before it will see them. | 08:26 |
| jam | But that should be reasonably fast. | 08:26 |
| jam | so we might just be waiting there. | 08:26 |
| jam | It sounds like you should get an email | 08:27 |
| davecheney | it's awesome that the instructions for doing this on LP are completely out of date | 08:29 |
| davecheney | i think there was a problem with my gpg key | 08:30 |
| davecheney | i suspect LP just threw away that upload | 08:31 |
| davecheney | lucky(~/pbuilder/quantal_result) % dput ppa:juju/experimental mongodb_2.2.4-0ubuntu2_amd64.changes | 08:32 |
| davecheney | Package has already been uploaded to ppa on ppa.launchpad.net | 08:32 |
| davecheney | Nothing more to do for mongodb_2.2.4-0ubuntu2_amd64.changes | 08:32 |
| davecheney | you mean I have to build it again ! | 08:32 |
| davecheney | FUCK | 08:32 |
| jam | davecheney: I don't see any gpg keys here: https://launchpad.net/~dave-cheney | 08:39 |
| jam | davecheney: so you probably do need to at least add that bit. | 08:40 |
| jam | If it is saying "already uploaded" it may or may not still be in the queue of things to finish. | 08:40 |
| jam | davecheney: if/when you get back, wgrant and stevenk would be interested in talking to you about it in #launchpad-dev | 08:58 |
| danilos | davecheney, hi, I am still having test failures on raring 64bit with system mongodb: http://paste.ubuntu.com/5709879/ (if I simply change my path to first include the extracted 2.2.0 tarball binaries, then all the tests pass) | 09:07 |
| === edamato is now known as ed-afk | ||
| TheMue | lunchtime | 10:31 |
| dimitern | fwereade_: ping | 10:49 |
| fwereade_ | dimitern, pong | 10:49 |
| dimitern | fwereade_: just run the partial implementation of openstack instance selection past you | 10:50 |
| fwereade_ | dimitern, cool, g+? | 10:50 |
| dimitern | fwereade_: i'll start one | 10:50 |
| dimitern | fwereade_: https://plus.google.com/hangouts/_/d16686e011ab34034d07f07641d351a34b0c6c9d?authuser=0&hl=en | 10:51 |
| dimitern | fwereade_: https://codereview.appspot.com/8753044 | 11:03 |
| rogpeppe | fwereade_: just looking at tools.ReadList - given that we no longer fetch just the tools with a given major version from the provider, i don't think there's any particular reason, AFAICS, to have majorVersion as an argument any more. i *think* that's the only reason for ErrNoTools to exist. | 11:04 |
| fwereade_ | rogpeppe, hmm, I think it still has value, on the basis that you can only ever be legitimately interested in a single major version at a time | 11:07 |
| fwereade_ | rogpeppe, otherwise you need to remember to do a filter step everywhere that uses it (and filter needs a new field to do that) | 11:08 |
| rogpeppe | fwereade_: i'm not sure - it seems like pre-guessing the uses it might be useful for. we might want to know which major versions are supported in an environment. and in our particular case, we want to know about other major versions so we can know if there are any tools. | 11:09 |
| rogpeppe | fwereade_: yeah, filter would need another field | 11:09 |
| rogpeppe | fwereade_: but that seems more intuitive, i think | 11:09 |
| fwereade_ | rogpeppe, I don't think it's ever legitimate for the CLI to upgrade juju to a non-matching major version | 11:09 |
| rogpeppe | fwereade_: that might not be why we're calling ReadList | 11:10 |
| rogpeppe | fwereade_: it's a utility function | 11:10 |
| rogpeppe | fwereade_: one review, BTW: https://codereview.appspot.com/8727044/ | 11:12 |
| fwereade_ | rogpeppe, tyvm | 11:12 |
| fwereade_ | rogpeppe, feels a bit speculative to me tbh | 11:12 |
| fwereade_ | rogpeppe, not saying that use case will never show up, just that it's not here now | 11:13 |
| rogpeppe | fwereade_: i like to pare down functions to their minimum if possible. streamlining increases the possibility for elegant generality in the future | 11:13 |
| rogpeppe | fwereade_: it feels like we're putting a special case in for this one scenario | 11:13 |
| fwereade_ | rogpeppe, well, actually, I'm preserving behaviour that, on consideration, does what we need right now | 11:14 |
| fwereade_ | rogpeppe, there was a definite temptation to take that on as well but... we wouldn't use it | 11:15 |
| rogpeppe | fwereade_: i'm not suggesting you change the behaviour. just that i know that i added the major-version argument specifically so that we could fetch only tools that matched it. we're no longer doing that, so i think it could go. and that simplies other stuff too, i think. but if you think it's worth it, fine. | 11:16 |
| fwereade_ | rogpeppe, I think that as it stands its benefits outweigh its costs... that's not to say that everything I've done over the last few days couldn't be done much better, ofc | 11:28 |
| fwereade_ | rogpeppe, believe it or not, I've been trying to keep this stuff focused | 11:28 |
| fwereade_ | rogpeppe, I just keep bumping up against weird little interactions | 11:28 |
| rogpeppe | fwereade_: i guess i don't see the benefits, but i believe you! | 11:28 |
| jam | dimitern: poke | 11:32 |
| fwereade | rogpeppe, I see what you mean about the name/effect of FindBootstrapTools but I'm not sure about the alternative | 11:33 |
| rogpeppe | fwereade: it was just one thought | 11:33 |
| rogpeppe | fwereade: the fact that you didn't actually test that side effect is quite indicative to me that the name isn't right | 11:34 |
| fwereade | rogpeppe, yeah, that is pretty embarrassing | 11:34 |
| rogpeppe | fwereade: i think that making the side effect the primary purpose feels good to me, but i'm totally unsure about the right name for it | 11:35 |
| rogpeppe | fwereade: BTW, what's the reasoning behind the "usefulVersion" name i've seen in a few places? | 11:36 |
| fwereade | rogpeppe, "it means FFS this test depends on something, let's fake it up and move on" | 11:37 |
| rogpeppe | fwereade: ah | 11:37 |
| rogpeppe | fwereade: perhaps "requiredVersion" might be more helpful? | 11:37 |
| fwereade | rogpeppe, +1, thanks | 11:38 |
| rogpeppe | fwereade: and perhaps a comment saying what actually requires it, for future reference | 11:38 |
| fwereade | rogpeppe, yeah, sounds reasonable | 11:38 |
| * fwereade now has to figure them all out again ;p | 11:39 | |
| * fwereade wonders whether that'll maybe learn him | 11:39 | |
| rogpeppe | fwereade: :-) | 11:58 |
| fwereade | wtf, the provisioner doesn't remove dead machines? | 12:02 |
| fwereade | gaah | 12:02 |
| * fwereade knows what he's doing *now* then | 12:02 | |
| * dimitern lunch | 12:04 | |
| jam | fwereade: going to lunch with dimitern to drink away your sorrow ? :) | 12:11 |
| rogpeppe | fwereade: have you tested any of your recent branches live? | 12:14 |
| fwereade | rogpeppe, yes, they appear to all do as they should | 12:18 |
| fwereade | rogpeppe, I'll be doing a final one after whatever total set of changes land | 12:18 |
| fwereade | rogpeppe, (land in my branches, I mean, not land in trunk) | 12:19 |
| rogpeppe | fwereade: cool. i saw the APIInfo being erased in FinishMachineConfig and thought "huh?" but i see now why it's happening | 12:19 |
| rogpeppe | fwereade: i've got a suggestion in my review, just coming up | 12:19 |
| fwereade | rogpeppe, yeah, that bit's still a bit squirrely but it's better than before, I'm pretty sure | 12:19 |
| rogpeppe | fwereade: i hope you like my suggestion, which hopefully is better still. | 12:19 |
| fwereade | rogpeppe, cool | 12:20 |
| fwereade | rogpeppe, I look forward to it | 12:20 |
| rogpeppe | fwereade: i've published my comments so far: https://codereview.appspot.com/8726044/ | 12:28 |
| fwereade | rogpeppe, tyvm | 12:34 |
| fwereade | rogpeppe, I felt like changes to MachineConfig itself were out of scope here... the changes I made will, I think, make it easier to fix MachineConfig in the future | 12:39 |
| fwereade | rogpeppe, but there's something smarter struggling to get out, I think, I'm just not quite sure what it is yet | 12:40 |
| rogpeppe | fwereade: hmm, i see now that you haven't changed environs/cloudinit at all | 12:41 |
| fwereade | rogpeppe, yeah, I was just drawing duplicated behaviour together | 12:41 |
| rogpeppe | fwereade: i really don't like FinishMachineConfig though - it feels highly squirrely | 12:41 |
| rogpeppe | fwereade: although... | 12:42 |
| fwereade | rogpeppe, it's a single squirrel instead of a... <looks up collective nouns...> dray, or scurry, thereof | 12:42 |
| rogpeppe | fwereade: the basic idea of using lots of info from the config.Config to inform our cloudinit script seems dead right | 12:42 |
| fwereade | rogpeppe, I don;t claim it's anything more that that | 12:42 |
| fwereade | rogpeppe, yeah, I'm confident it's a good direction, but only a first step | 12:43 |
| rogpeppe | fwereade: it's just that now for any potential provider-writer, it is totally non-obvious which fields in the MachineConfig should be filled out be whom. | 12:44 |
| rogpeppe | s/be whom/by whom/ | 12:44 |
| fwereade | rogpeppe, agreed, but MachineConfig has pretty solid validation, so I'm not too botherered there | 12:44 |
| rogpeppe | fwereade: that's not the point! | 12:44 |
| fwereade | rogpeppe, it all had to be cargo-culter from ec2 for the existing ones anyway, really | 12:45 |
| rogpeppe | fwereade: it still does | 12:45 |
| rogpeppe | fwereade: but the amount of code copied will be smaller, which is good | 12:45 |
| fwereade | rogpeppe, precisely my point, no worse than before ;p | 12:45 |
| rogpeppe | fwereade: i'm not entirely sure. | 12:46 |
| rogpeppe | fwereade: you're probably right. | 12:46 |
| rogpeppe | fwereade: but it doesn't feel like a proper simplification | 12:47 |
| rogpeppe | fwereade: and there's definitely one to be made. | 12:47 |
| fwereade | rogpeppe, totally agreed | 12:47 |
| fwereade | rogpeppe, I was trying to do that before atlanta but got too tangled | 12:47 |
| rogpeppe | fwereade: basically the MachineConfig fields are parameters to cloudinit.Configure and now half of them are redundant | 12:47 |
| fwereade | rogpeppe, well, none are *redundant* yet, but they're plainly due for the chopping block | 12:48 |
| rogpeppe | fwereade: they are redundant, i think - it would be wrong if a provider didn't call FinishMachineConfig immediately before Configure. | 12:49 |
| rogpeppe | fwereade: here's a suggestion: | 12:49 |
| rogpeppe | fwereade: don't remove any fields fron MachineConfig | 12:49 |
| rogpeppe | fwereade: but... | 12:49 |
| rogpeppe | fwereade: move FinishMachineConfig into cloudinit.Configure | 12:50 |
| rogpeppe | fwereade: and mark the fields that it fills out as deprecated in the MachineConfig | 12:50 |
| rogpeppe | fwereade: i would be much happier with that | 12:50 |
| rogpeppe | fwereade: and the providers would be simpler still. | 12:50 |
| rogpeppe | fwereade: and they wouldn't need to change when the fields go | 12:52 |
| fwereade | rogpeppe, I really just want to avoid touching environs/cloudinit in this pass through the code | 12:53 |
| rogpeppe | fwereade: ok, then please leave a TODO comment on FinishMachineConfig. | 12:53 |
| fwereade | rogpeppe, they were generated in a disturbing fashion; now they are generated in a slightly less disturbing one; that's all :) | 12:54 |
| fwereade | rogpeppe, sgtm | 12:54 |
| jam | wallyworld: poke | 13:12 |
| rogpeppe | fwereade: rest of comments published | 13:24 |
| rogpeppe | fwereade: interestingly, sync-tools is probably a place where we *do* want to do a ReadList across major versions. there's no particular reason why we only want to copy tools with a single major version AFAICS. | 13:31 |
| TheMue | fwereade: do i get it right that regarding the units and the relations "only" the relation-errors are interesting? | 13:32 |
| fwereade | rogpeppe, my view is that a given CLI major version can and will, for now, only interact with tools sharing a major version | 13:33 |
| fwereade | TheMue, we don't really have relation errors | 13:33 |
| rogpeppe | fwereade: even to the extent of refusing to copy tools for other major versions? i think that's a bit gratuitous - we see them but we can't touch them. | 13:34 |
| fwereade | rogpeppe, we can't deploy them either, so... | 13:34 |
| rogpeppe | fwereade: someone else might be able to though | 13:34 |
| fwereade | rogpeppe, then they can run sync-tools? | 13:34 |
| rogpeppe | fwereade: maybe they want to use a public bucket? | 13:34 |
| fwereade | rogpeppe, when I hear a user complaining that they need to run two different major versions of juju out of the same bucket, but *don't* have CLI tools for all the major versions they are running, I will ask the user how they plan to run the alternate major versions without suitable CLI tools | 13:36 |
| rogpeppe | fwereade: it means that if you're an admin and want to copy several versions into a public bucket, you have to have a separate juju binary for each major version, and run it that many times. | 13:36 |
| TheMue | fwereade: aha?!? that's the only stuff generated out of the relations and the relation service map in Python I can find. *wonder* | 13:38 |
| rogpeppe | fwereade: the point is that you can use sync-tools for many users | 13:38 |
| fwereade | TheMue, I'm sure we had a chat about relation errors | 13:38 |
| rogpeppe | fwereade: if there wasn't a --public flag i'd tend to agree | 13:38 |
| fwereade | TheMue, does it not check for unit presence in the relation? I'm pretty sure it does | 13:41 |
| fwereade | rogpeppe, I see the public flag as a convenience for users who want their tools shared across a few of their own environments at this stage | 13:42 |
| fwereade | rogpeppe, it's probably worth revisiting when we get another major version though :) | 13:42 |
| fwereade | TheMue, coming up with a sensible plan (and justification for it) is your main job here I think | 13:43 |
| TheMue | fwereade: _process_unit passes the relations and the service map to _process_unit_relations, and there below unit only relation errors are generated as output | 13:43 |
| fwereade | TheMue, that's frickin' awesome news | 13:45 |
| fwereade | TheMue, nothing to do for units | 13:45 |
| fwereade | TheMue, yay! | 13:45 |
| TheMue | fwereade: afaics yes. i'm checking the tests, but there also only relation-errors are mentioned | 13:47 |
| fwereade | TheMue, (incidentally, this informs my suspicion of specs -- there's a python doc explaining in detail why they had to make a backward-incompatible change to unit relation status output, describing relation-errors plus a bunch of other things -- and I didn't check the code for that bit) | 13:47 |
| fwereade | TheMue, it now emerges it isn't there, I agree | 13:47 |
| TheMue | fwereade: *phew* ;) | 13:48 |
| rogpeppe | fwereade: you've got another review: https://codereview.appspot.com/8748046/ | 13:48 |
| TheMue | fwereade: btw, the change after your last review is proposed again | 13:48 |
| === wedgwood_away is now known as wedgwood | ||
| rogpeppe | fwereade: i'm wondering whether to put juju-wait in its own repo, or make a repo for several like-minded tools. juju-utils, perhaps? | 13:49 |
| dimitern | rogpeppe: we already discussed having something like lp:juju-core-tools, there's even a card for that | 13:52 |
| rogpeppe | dimitern: ha. too late! | 13:52 |
| rogpeppe | dimitern: https://launchpad.net/juju-utils | 13:52 |
| dimitern | rogpeppe: :) the card can be changed as well | 13:53 |
| fwereade | rogpeppe, lovely, thanks | 13:53 |
| dimitern | rogpeppe: it's in Blue backlog btw | 13:54 |
| rogpeppe | fwereade, mramm: https://plus.google.com/hangouts/_/539f4239bf2fd8f454b789d64cd7307166bc9083 | 14:07 |
| rvba | fwereade: here it is: https://code.launchpad.net/~rvb/juju-core/fix-maas-pvd-conf/+merge/158938 | 14:32 |
| rogpeppe | lunch | 14:43 |
| fwereade | rvba, thanks | 14:49 |
| TheMue | fwereade: thx for review. sorting is IMHO only interesting for testing, so you can exactly test against the expected value | 14:53 |
| fwereade | TheMue, it's the dupes, not the sorting | 14:54 |
| fwereade | TheMue, I kinda feel that if there's a dupe it's probably meant to be there | 14:54 |
| fwereade | TheMue, or even if it represents total crack, we should show it | 14:54 |
| TheMue | fwereade: ok, so i'll change it into a sorted slice again and we'll what happes during the audit | 14:59 |
| TheMue | fwereade: ;) | 14:59 |
| fwereade | TheMue, well, I was suggesting we keep it out of paranoia but flag it with a TODO for later investigation | 15:00 |
| fwereade | rvba, hey, I have a theory re mysql/mediawiki: was mediawiki in an error state trying to leave the relation? | 15:09 |
| rvba | fwereade: you mean after I ran "juju destroy mysql"? | 15:10 |
| fwereade | rvba, yeah | 15:10 |
| dimitern | TheMue: how about peer relations? | 15:11 |
| rvba | I don't know but it happens that I have this setup in the lab right now http://paste.ubuntu.com/5710574/ so I can try to destroy mysql and have a look… | 15:11 |
| TheMue | dimitern: just seen your review, thanks, will add. | 15:14 |
| fwereade | rvba, I would be interested to see what happens, yeah, because I *do* have a local tweak to the code in mine... that I *think* is actually not necessary | 15:14 |
| fwereade | dimitern, TheMue: good point re peers | 15:14 |
| fwereade | TheMue, should just need a test; but also, subordinates; but please land this one as-is (just a peer relation test should be fine) | 15:15 |
| dimitern | TheMue: yeah, peer relations are simple enough to make it a separate test case; this one is already complex enough | 15:17 |
| TheMue | fwereade, dimitern: sure, won't make it larger | 15:18 |
| fwereade | rvba, ah, hell, it has finally clicked | 15:19 |
| fwereade | rvba, you *do* need my code change | 15:19 |
| rvba | fwereade: here are the state I'm in now, with links to all the logs. http://paste.ubuntu.com/5710599/ | 15:19 |
| dimitern | fwereade: 3 reviewed, 2 to go | 15:19 |
| fwereade | rvba, but even with that, if mediawiki has a hook error on mysql's departure, it won't drop its reference to that relation until it's resolved | 15:20 |
| fwereade | rvba, and that will keep the service alive | 15:20 |
| fwereade | rvba, nothing to do with your unit situation | 15:20 |
| dimitern | fwereade: if you don't mind, I'll wait for your https://codereview.appspot.com/8726044/ to land first, and then I'll land my openstack constraints branch | 15:21 |
| fwereade | dimitern, +1, tyvm | 15:21 |
| rvba | fwereade: right. | 15:22 |
| fwereade | rvba, ok, sorry for crack suggestion just now, but I think I know (1) what's wrong and (2) how to fix it, and will hopefully nail (3) how to test it before too long | 15:23 |
| rvba | dimitern: Thanks for the review of lp:~rvb/juju-core/fix-maas-pvd-conf. Would you mind landing it for me please? lbox refuses to cooperate with me. | 15:25 |
| dimitern | rvba: sure, I'll pull your branch and land it for you, if you're fine with that | 15:25 |
| rvba | dimitern: that would be great, thanks! | 15:26 |
| rvba | fwereade: cool… once you have a branch ready, I can help with the real-world testing if you want. | 15:26 |
| fwereade | rvba, I've approved https://code.launchpad.net/~rvb/juju-core/fix-maas-pvd-conf/+merge/158938 -- I think it's a trivial | 15:28 |
| fwereade | rvba, go ahead and land it :) | 15:28 |
| dimitern | fwereade, rvba: I'll land it for him | 15:29 |
| dimitern | fwereade: (problems with lbox) | 15:29 |
| dimitern | rvba: here it is: https://codereview.appspot.com/8772043 | 15:47 |
| fwereade | dimitern, ofc, thanks | 15:47 |
| dimitern | rvba: take a look if it's ok, I'll submit it | 15:47 |
| dimitern | fwereade: set the old MP to Rejected because of the above | 15:47 |
| fwereade | dimitern, sgtm, just comment it | 15:48 |
| dimitern | fwereade: yeah, did and linked the new CL in the old MP | 15:48 |
| fwereade | dimitern, <3 | 15:48 |
| rvba | dimitern: looks good, thanks for doing this. | 15:48 |
| dimitern | rvba: np, lbox is a bitch at first, I know :) | 15:50 |
| rvba | dimitern: if that error rings a bell: http://paste.ubuntu.com/5710470/, please do advise :) | 15:51 |
| dimitern | rvba: rings a bell, but not sure how. I had to patch lbox locally to use it, I can send you a diff to see if it works for you | 15:52 |
| rvba | dimitern: that would be great… I was also thinking about manually hacking lbox's inferPushURL() method… | 15:53 |
| dimitern | rvba: actually, it's not lbox - it's lpad the one that lbox uses to communicate with lp | 15:58 |
| dimitern | rvba: http://paste.ubuntu.com/5710712/ | 15:58 |
| rvba | dimitern: ta | 15:59 |
| dimitern | rvba: apply this (well, change dimitern to match your lp id) and see if it helps - you can try a simple branch and "lbox propose -wip" | 15:59 |
| rvba | dimitern: will do, thanks again. | 16:00 |
| dimitern | rvba: just a reminder, after patching, run "cd $GOPATH/src/launchpad.net/lbox && go install" | 16:02 |
| fwereade | dimitern, rvba: https://codereview.appspot.com/8748048 | 16:07 |
| fwereade | rvba, confirmation that it works in your exact scenario would be appreciated, but I'm pretty confident | 16:08 |
| fwereade | bbiab | 16:08 |
| rvba | fwereade: dimitern: I'm testing this in the lab right now… | 16:10 |
| dimitern | fwereade: LGTM | 16:11 |
| rogpeppe | fwereade: is there a ticket for the python/go environments.yaml incompatibility issue? | 16:26 |
| rogpeppe | fwereade: i'm having difficulty reproducing the problem | 16:26 |
| rogpeppe | mgz: ^ | 16:27 |
| dimitern | danilos: I see you have a kanban account already | 16:29 |
| dimitern | rogpeppe: is a defer statement function-scoped or block-scoped? | 16:31 |
| === deryck is now known as deryck[lunch] | ||
| rvba | fwereade: doesn't look like your fix worked: http://paste.ubuntu.com/5710819/ | 16:34 |
| rogpeppe | dimitern: the former | 16:34 |
| dimitern | rogpeppe: I thought so, although seeing it into an if block within a function raised an eyebrow | 16:35 |
| rogpeppe | dimitern: that's just fine | 16:35 |
| rogpeppe | dimitern: can be in a for loop too... | 16:35 |
| dimitern | rogpeppe: ah, cool - although potentially messy (for i=1-1000 defer something each time..) | 16:36 |
| dimitern | rvba: I can see the unit is removed, but the service seems still there | 16:37 |
| rvba | dimitern: yep | 16:38 |
| dimitern | rvba: that wasn't the case before, right? the both the unit and the service were in the status output | 16:38 |
| rvba | dimitern: indeed (that was before the fix: http://paste.ubuntu.com/5710599/) | 16:39 |
| dimitern | fwereade , rvba: I think the fix should include removeOps in the amended case, like we're doing a bit further up in the "if s.doc.Life == Dying && s.doc.RelationCount == 0 && s.doc.UnitCount == 1" case | 16:41 |
| dimitern | rvba: removeOps is responsible for removing the service itself; the change is in removeUnitOps, which only removes the unit (except in the former mentioned case) | 16:42 |
| mgz | rogpeppe: there is a ticket, that might have been overly general, then closed when a specific issue was fixed | 16:45 |
| dimitern | rvba: added comment to the proposal | 16:45 |
| rogpeppe | mgz: do you know of a specific problem? | 16:47 |
| rogpeppe | mgz: as far as i can tell, go juju will parse unknown environment attributes without complaint | 16:47 |
| rogpeppe | mgz: but i'm pretty sure that's actually not the case, and that this really is a genuine issue | 16:48 |
| rogpeppe | dimitern: you chatted to ian about this - do you know anything about the problem? | 16:49 |
| dimitern | rogpeppe: if should ignore unknown keys (like "placement: local"), but barf on known keys whose type was changed | 16:49 |
| dimitern | rogpeppe: we didn't discuss specifics yet, and from the kanban chart I can see danilos actually picked that one now | 16:49 |
| rogpeppe | dimitern: ah, do you mean we want a *single environment entry* to work with both go and python juju? | 16:50 |
| dimitern | rogpeppe: i'm sure that's not what we need - not for a bootstrapped env for sure | 16:50 |
| dimitern | rogpeppe: but for a fresh one, perhaps | 16:50 |
| rogpeppe | dimitern: i don't know. seems like a somewhat dubious requirement to me. | 16:51 |
| rogpeppe | dimitern: if that's really what the requirement is | 16:51 |
| dimitern | rogpeppe: we'll never make existing py-juju envs work with go-juju, but at least trying to do something with an existing py-env.yaml should fail gracefully, I think | 16:52 |
| rogpeppe | dimitern: i'm not sure what you mean by "fail gracefully" there | 16:52 |
| dimitern | rogpeppe: like producing a meaningful error | 16:52 |
| dimitern | rogpeppe: can we detect a py env with certainty from the yaml only? | 16:53 |
| rogpeppe | dimitern: only with dodgy heuristics, probably | 16:54 |
| rogpeppe | dimitern: basically, i can't see this as a high priority task | 16:54 |
| dimitern | rogpeppe: i think the general idea, after having py/go juju co-installable, is to detect incompatible yaml and report it early | 16:55 |
| rogpeppe | dimitern: but i'd really like to talk to someone for whom this is a priority | 16:55 |
| rogpeppe | dimitern: we do that | 16:55 |
| dimitern | rogpeppe: how does it look? | 16:56 |
| rogpeppe | dimitern: you get an error like: | 16:56 |
| rogpeppe | error: placement: expected nothing, got "345" | 16:56 |
| dimitern | rogpeppe: and how is this helpful? | 16:56 |
| dimitern | rogpeppe: for the user | 16:57 |
| rogpeppe | dimitern: it's detecting incompatible yaml and reporting it early... | 16:57 |
| dimitern | rogpeppe: but not in a meaningful for the user way | 16:57 |
| rogpeppe | dimitern: the error message could probably do with some work, it's true | 16:57 |
| rogpeppe | dimitern: i'd like us to work on stuff that is important functionally as we've only got hours remaining | 16:57 |
| dimitern | rogpeppe: put yourself in the user's shoes - the error should provide a hint what's actually wrong and how to fix it | 16:57 |
| rogpeppe | dimitern: i agree | 16:58 |
| rogpeppe | dimitern: but i wouldn't put this at the top of the list of things that need solving *now* | 16:58 |
| dimitern | rogpeppe: +1, not sure how and why this is high prio | 16:58 |
| rogpeppe | dimitern: also, i think that the whole idea behind all the JUJU_HOME work was so that we would not have to share the environments.yaml file! | 16:59 |
| rogpeppe | dimitern: and that added loads of complexity to the system | 16:59 |
| rogpeppe | dimitern: and now we're saying that it's not enough | 16:59 |
| dimitern | rogpeppe: we discussed this on the standup; jam said he suggested having a different name/path for go-env.yaml, but it was rejected | 17:00 |
| rogpeppe | dimitern: i also think that's the wrong solution | 17:00 |
| rogpeppe | dimitern: a) we *can* currently use the same environments.yaml, AFAIK (but you can't have the same environment entry for both go and py juju) | 17:01 |
| rogpeppe | dimitern: b) we have JUJU_HOME | 17:01 |
| dimitern | rogpeppe: agreed, on both points (except for the more helpful error msg) | 17:02 |
| rogpeppe | m_3, hazmat: do you know anything more about this issue, by any chance? | 17:03 |
| rogpeppe | dimitern: which ticket on the kanban board are you referring to? | 17:07 |
| dimitern | rogpeppe: "environments.yaml should cope with pyjuju and gojuju environments" | 17:08 |
| dimitern | rogpeppe: the description seems to shed some light on the actual issue as well | 17:08 |
| fwereade | rvba, working as intended according to that paste | 17:09 |
| rogpeppe | dimitern: the problem is that the "best compromise" is exactly what we do now | 17:09 |
| rogpeppe | dimitern: i fixed the issue, was writing tests, and then realised that | 17:09 |
| fwereade | rvba, the errored mediawiki is keeping a ref to the relation, which is keeping a ref to the service | 17:09 |
| dimitern | fwereade: ah, ok then | 17:10 |
| rogpeppe | dimitern: AFAICS the description "juju-core will fail to start if there are any unrecognized keys" is not true | 17:10 |
| fwereade | rvba, if you resolve mediawiki/0 it mysql should go away | 17:10 |
| fwereade | gtg again | 17:10 |
| dimitern | rogpeppe: it's still dubious imho | 17:10 |
| rogpeppe | dimitern: what's still dubious? | 17:10 |
| rogpeppe | dimitern: our error messages? | 17:10 |
| dimitern | rogpeppe: that's for sure, but the "fail to start" as well | 17:11 |
| rogpeppe | dimitern: we don't fail to start if there are any unrecognised keys in environments.yaml | 17:11 |
| dimitern | rogpeppe: start=? bootstrap? connect? return an error on any cmd? | 17:11 |
| rogpeppe | dimitern: any of the above | 17:11 |
| dimitern | rogpeppe: so it seems we're good then | 17:12 |
| rogpeppe | dimitern: when the unrecognised keys aren't part of the chosen environment | 17:12 |
| rogpeppe | dimitern: exactly | 17:12 |
| rogpeppe | dimitern: but perhaps i'm wrong and there's a subtle issue i've missed | 17:12 |
| rogpeppe | dimitern: which is why i want to speak to someone that's experienced the issue | 17:12 |
| rogpeppe | dimitern: before dismissing the ticket | 17:13 |
| dimitern | rogpeppe: it's probably worth a @juju-dev post | 17:13 |
| rogpeppe | dimitern: yeah | 17:13 |
| dimitern | eod or me | 17:28 |
| dimitern | good night all! | 17:28 |
| === deryck[lunch] is now known as deryck | ||
| rogpeppe | fwereade: does this LGTY in its new location? https://codereview.appspot.com/8565044/ | 18:04 |
| m_3 | rogpeppe: hey | 18:04 |
| rogpeppe | m_3: hiya | 18:04 |
| m_3 | did you get the answer you needed about shared envs? | 18:05 |
| rogpeppe | m_3: not really | 18:05 |
| m_3 | 'origin: ppa' is usually the biggest difference atm | 18:05 |
| rogpeppe | m_3: do you want to be able to use the same environment entry in both go and py juju? | 18:05 |
| rogpeppe | m_3: i'm not entirely sure whether that's a goal worth striving for | 18:06 |
| m_3 | rogpeppe: yeah, that'd be the preference, but not too high of a priority | 18:06 |
| m_3 | rogpeppe: let's say goju envs and pyju envs in the same file | 18:07 |
| m_3 | rogpeppe: but not the same envs | 18:07 |
| rogpeppe | m_3: we can do that currently | 18:07 |
| rogpeppe | m_3: unless you know something that i don't... | 18:07 |
| m_3 | i.e., we don't want to promote people trying to use the same environment | 18:07 |
| * rogpeppe realises that m_3 knows *loads* of things that he doesn't | 18:07 | |
| rogpeppe | m_3: yeah, that's what i'm thinking | 18:08 |
| rogpeppe | m_3: so by my thinking there's nothing that currently needs to be solved | 18:08 |
| m_3 | lemme check to see if I can use them together | 18:08 |
| rogpeppe | m_3: thanks | 18:08 |
| m_3 | I've been using dedicated environments.yaml files to day | 18:08 |
| m_3 | date | 18:08 |
| m_3 | until package changes (with update-alternatives) lands | 18:09 |
| rogpeppe | m_3: BTW if you have some moments free, i'd very much appreciate your thoughts on the new juju-wait command, which i *think* is just about as we discussed: https://codereview.appspot.com/8565044/ | 18:09 |
| m_3 | rogpeppe: looks like they can coexist in the same file | 18:11 |
| rogpeppe | m_3: cool | 18:11 |
| rogpeppe | m_3: you can try out the juju-wait cmd by doing: go get launchpad.net/~rogpeppe/juju-utils/000-juju-wait/cmd/juju-wait | 18:11 |
| m_3 | no need to change anything atm then | 18:11 |
| rogpeppe | m_3: great! | 18:11 |
| rogpeppe | m_3: although you probably want to delete $GOPATH/src/launchpad.net/~rogpeppe afterwards... | 18:12 |
| m_3 | rogpeppe: will that change enough that I should tear the envi down before go getting? | 18:12 |
| rogpeppe | m_3: nope | 18:12 |
| rogpeppe | m_3: it should just work | 18:12 |
| m_3 | ack | 18:12 |
| m_3 | I'll try it in scale stuff now then | 18:12 |
| rogpeppe | m_3: brill | 18:12 |
| m_3 | gotta rebuild tho? | 18:13 |
| rogpeppe | m_3: nope | 18:15 |
| rogpeppe | m_3: that one command should have made "juju-wait" available | 18:15 |
| rogpeppe | m_3: assuming $GOPATH/bin is in your PATH | 18:15 |
| m_3 | rocking | 18:16 |
| rogpeppe | m_3: although... | 18:16 |
| rogpeppe | m_3: it depends what revno of juju-core you're on | 18:16 |
| rogpeppe | m_3: and what version you've bootstrapped | 18:17 |
| rogpeppe | m_3: if you've bootstrapped 1127 or later, you should be good | 18:17 |
| m_3 | yup | 18:17 |
| rogpeppe | fwereade: ping | 18:20 |
| fwereade | rogpeppe, pong | 18:21 |
| m_3 | sorry.... suuuuper-latent | 18:21 |
| fwereade | rogpeppe, supper is just here | 18:21 |
| rogpeppe | fwereade: ok, back later? | 18:21 |
| fwereade | rogpeppe, definitely | 18:21 |
| rogpeppe | fwereade: cool, ping us then | 18:21 |
| * rogpeppe smells curry odours drifting up the stairs | 18:22 | |
| m_3 | rogpeppe: http://paste.ubuntu.com/5711150/ | 18:35 |
| rogpeppe | m_3: ah! | 18:36 |
| rogpeppe | m_3: trivially fixed | 18:36 |
| rogpeppe | m_3: try go get -u launchpad.net/~rogpeppe/juju-utils/000-juju-wait/cmd/juju-wait | 18:38 |
| rogpeppe | m_3: and try the command again | 18:38 |
| rogpeppe | m_3: i had forgotten to import all the providers | 18:38 |
| rogpeppe | m_3: it's an interesting point actually - we probably want to make it easier for commands to import all providers. | 18:39 |
| m_3 | rogpeppe: trying | 18:45 |
| rogpeppe | m_3: any joy? | 19:07 |
| m_3 | rogpeppe: still waiting | 19:09 |
| m_3 | rogpeppe: it seems to be waiting on hadoop-slave/99 | 19:09 |
| m_3 | so now I'm just waiting for provisioning | 19:09 |
| m_3 | might have to do something with secgroups | 19:09 |
| m_3 | not sure atm | 19:09 |
| rogpeppe | m_3: a good first test is to juju-wait for something that you already know is in the state you're waiting for | 19:10 |
| m_3 | lemme try it on a lower number :) | 19:10 |
| rogpeppe | m_3: you can do it without interrupting the other one | 19:10 |
| m_3 | rogpeppe: seems to be beautiful | 19:11 |
| rogpeppe | m_3: there's a known provisioning problem at the moment - if the provisioner gets a temporary error, it just marks the machine with the error and never retries | 19:11 |
| rogpeppe | m_3: excellent! | 19:11 |
| fwereade | rogpeppe, ping | 19:15 |
| rogpeppe | fwereade: pong | 19:15 |
| fwereade | rogpeppe, more-or-less back | 19:16 |
| rogpeppe | fwereade: i'm just implementing service config settings in the AllWatcher | 19:16 |
| rogpeppe | fwereade: i just wanted to run my plan by you in case it's crack | 19:16 |
| rogpeppe | fwereade: i'll watch the settings collection; if i see a service settings change, i look at the current service info that i've got stored; if the settings are for a different url, then i ignore the change, otherwise i set it. | 19:18 |
| rogpeppe | fwereade: when i see a new service, i fetch the settings too | 19:18 |
| rogpeppe | fwereade: basically a similar approach to the constraints | 19:18 |
| rogpeppe | fwereade: does that sound more or less right? | 19:18 |
| fwereade | rogpeppe, hmm,have you considered per-charm settings? | 19:21 |
| rogpeppe | fwereade: that's the "if the settings are for a different url" part | 19:21 |
| fwereade | rogpeppe, sorry, I did not read as closely as I should have: yes, that sounds perfectly correct | 19:22 |
| rogpeppe | fwereade: great | 19:22 |
| fwereade | rogpeppe, service existence should guarantee settings existence for the its charm url | 19:23 |
| rogpeppe | fwereade: i'm not sure | 19:23 |
| rogpeppe | fwereade: i don't think there's an ordering guarantee on transaction ops | 19:23 |
| fwereade | rogpeppe, they execute inthe order passed, AIUI | 19:24 |
| rogpeppe | fwereade: i'd like to know that for sure. i thought transactions with ops in different collections could execute concurrently. | 19:25 |
| rogpeppe | fwereade: i've been assuming there's no such guarantee | 19:25 |
| rogpeppe | fwereade: it makes my life easier if there is such a guarantee, but i'd like chapter and verse from the txn package before i change things accordingly. | 19:26 |
| fwereade | rogpeppe, this is one where I fall back to argument from authority rather than experience -- niemeyer said they execute in order, and I believe him | 19:26 |
| niemeyer | fwereade, rogpeppe: you can trust it.. it'd be a very weak system otherwise | 19:27 |
| niemeyer | fwereade, rogpeppe: Silly example: a bank transference might temporarily have more total money than exists | 19:27 |
| rogpeppe | niemeyer: ok. it might be worth adjusting the documentation for txn.Runner.Run then. | 19:28 |
| rogpeppe | niemeyer: it doesn't mention ordering at all | 19:28 |
| rogpeppe | niemeyer: " | 19:28 |
| rogpeppe | Operations across documents are not atomically applied, but are | 19:28 |
| rogpeppe | guaranteed to be eventually all applied or all aborted | 19:28 |
| rogpeppe | " | 19:28 |
| rogpeppe | niemeyer: i'd read that as "no ordering guaranteed" | 19:28 |
| rogpeppe | niemeyer: BTW in benchmarks, i'm only seeing 20-30 transaction-based operations per second. is there some way we can speed that up, or is that to be expected? | 19:30 |
| niemeyer | rogpeppe: It's significantly faster than that.. | 19:32 |
| niemeyer | rogpeppe: IIRC, txn can pump about ~250 operations per second | 19:32 |
| niemeyer | rogpeppe: Of course, that depends on the operations performed | 19:32 |
| TheRealMue | so, time to stop, cu tomorrow | 19:33 |
| niemeyer | rogpeppe: In fact, it's actually better than this | 19:33 |
| niemeyer | rogpeppe: My original tests were showing about 200 *transactions* per second | 19:33 |
| niemeyer | rogpeppe: So that was at least double that in operations, or about 500 operations per second | 19:34 |
| niemeyer | rogpeppe: If transactions increase the number of operations, naturally that will impact the volume of *transactions* you get | 19:34 |
| m_3 | hey, can somebody help me turn off secgroup per machine?... just temporarily for scale testing | 19:34 |
| rogpeppe | niemeyer: there's a benchmark in state that i'd be interested in trying to improve | 19:35 |
| rogpeppe | niemeyer: BenchmarkAddUnit | 19:35 |
| niemeyer | rogpeppe: Sure, so.. hmm.. improve it..? :) | 19:35 |
| rogpeppe | niemeyer: i can call AddUnit about 47 times a second | 19:35 |
| rogpeppe | niemeyer: (as of just now) | 19:35 |
| m_3 | I'll let dave check this for profiling, but just wanna get past this hurdle | 19:35 |
| rogpeppe | niemeyer: it's true that AddUnit is reasonably complex (it does a fetch, then a transaction), but it's not unrepresentative of the kinds of things we'll want to do | 19:37 |
| rogpeppe | niemeyer: and adding 10000 units is something we do want to do | 19:37 |
| niemeyer | rogpeppe: Sure | 19:38 |
| niemeyer | rogpeppe: +1 :) | 19:38 |
| * rogpeppe goes for something to eat | 19:38 | |
| rogpeppe | back in a bit | 19:38 |
| fwereade | m_3, firewall-mode: global, I *think* | 19:54 |
| fwereade | m_3, you definitely need a fresh environment for that though | 19:55 |
| fwereade | m_3, I don't know how the firewaller will react to a mode switch but it is very unlikely to be pretty | 19:55 |
| fwereade | m_3: yeah, firewall-mode: global should do it | 19:57 |
| rogpeppe | back | 20:12 |
| m_3 | fwereade: got it thanks... that got us past the hump | 20:30 |
| fwereade | m_3, sweet | 20:30 |
| m_3 | next hump is ram limits on the acct :( | 20:43 |
| m_3 | rogpeppe: wait working like a champ | 20:45 |
| rogpeppe | m_3: that's very good to know! | 20:45 |
| rogpeppe | m_3: will submit soon. then it'll be go get launchpad.net/juju-utils/cmd/juju-wait | 20:45 |
| rogpeppe | fwereade: oh darn, i've forgotten the other wrinkle - watching the settings collection doesn't give you values which are defaulted. i guess i'll need to keep all the charm metadata around and merge each time. | 20:57 |
| thumper | morning | 21:21 |
| rogpeppe | thumper: hiya | 21:26 |
| thumper | hi rogpeppe | 21:27 |
| rogpeppe | thumper: i'd appreciate a review of this branch, if you have a moment: https://codereview.appspot.com/8761045/ | 22:46 |
| rogpeppe | m_3: juju-wait has landed | 22:48 |
| m_3 | rogpeppe: ack, thanks! | 22:53 |
| rogpeppe | m_3: np | 22:53 |
| rogpeppe | m_3: is it working? | 22:54 |
| rogpeppe | m_3: (i mean juju-core in general, really) | 22:54 |
| thumper | rogpeppe: sure, just looking at one for fwereade_ | 22:57 |
| rogpeppe | thumper: np | 22:57 |
| m_3 | rogpeppe: we're waiting to get past some more acct limits | 23:05 |
| m_3 | but great so far | 23:05 |
| rogpeppe | m_3: that's good to hear | 23:06 |
| * thumper goes to make coffee and bagel | 23:06 | |
| m_3 | rogpeppe: we're gonna do the wed charmschool with juju-core | 23:06 |
| m_3 | I think | 23:06 |
| m_3 | barring anything we run into tomorrow | 23:06 |
| rogpeppe | m_3: that will be interesting | 23:06 |
| m_3 | I'll do a dry-run tomorrow to decide | 23:18 |
| rogpeppe | right, that's me done and dusted | 23:25 |
| rogpeppe | g'night all | 23:25 |
| thumper | night | 23:26 |
| === wedgwood is now known as wedgwood_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!