| jcharette | anyone around to support MAAS with juju? | 00:47 |
|---|---|---|
| jcharette | anyone have experience making juju work with MAAS | 01:45 |
| zirpu | jcharette: did you try the #maas channel? | 01:57 |
| jcharette | no, but i can | 02:08 |
| jcharette | doesn't seem to be a maas problem, juju hasn't even tried to connect | 02:09 |
| m_3 | davecheney: yo | 04:30 |
| m_3 | davecheney: was gustavo's talk last night or is it tonight? | 04:30 |
| m_3 | davecheney: we got in about 6 this morning | 04:30 |
| davecheney | m_3: hey hey | 04:49 |
| davecheney | m_3: i think it will be friday | 04:49 |
| davecheney | so maybe the east coast friday | 04:50 |
| m_3 | ha | 04:52 |
| m_3 | ok | 04:52 |
| davecheney | m_3: so tired today, watched the google io demo live | 04:52 |
| davecheney | got home at 5:30 | 04:52 |
| m_3 | ah, ok... that's what I was asking about | 04:52 |
| m_3 | sorry thought that was gustavo's talk | 04:53 |
| davecheney | fwereade: howdy | 06:49 |
| davecheney | cmd/juju only lists bootstrap and destroy-environment as options, there is no deploy | 06:54 |
| davecheney | was this intentional ? | 06:54 |
| fwereade | davecheney, heh, no it wasn't | 07:02 |
| fwereade | davecheney, sorry about that | 07:02 |
| fwereade | davecheney, re your email, the ultra-short version is that no deploy doesn't publish secrets | 07:03 |
| fwereade | davecheney, I *think* that is something that should be handled by juju.Conn in the background; the first thing that should be done on client access to state is to check for complete environ config, and if keys are missing the secrets should be pushed | 07:04 |
| fwereade | davecheney, sounds sane? | 07:05 |
| davecheney | fwereade: yup | 07:08 |
| fwereade | davecheney, cool | 07:08 |
| davecheney | i hope this can be solved soon, and finally | 07:08 |
| davecheney | i always find myself butting up against it | 07:08 |
| davecheney | oh, also, spec, err := findInstanceSpec(defaultInstanceConstraint) | 07:08 |
| fwereade | davecheney, yeah, that is basically completely broken IMO | 07:09 |
| davecheney | ^ this is why we can't bootstrap into an arbitary region :) | 07:09 |
| davecheney | defaultInstanceConstraint says 'dude, use us-east-1' | 07:09 |
| fwereade | davecheney, I know | 07:09 |
| davecheney | not hard to fix | 07:09 |
| fwereade | davecheney, I was looking at exactly that last night and started swinging the axe before I realised that it was a distraction from what I *actually* need to do right now | 07:10 |
| davecheney | :) | 07:10 |
| davecheney | btw, i went to use juju deploy and found the command wasn't enabled yet | 07:10 |
| davecheney | is it not ready for prime time ? | 07:10 |
| fwereade | davecheney, yeah, but it's doing a bunch of stuff that is unnecessary, and some stuff that is flat-out wrong, and I'm not happy with some of the terminology, and grumble grumble grumble | 07:10 |
| fwereade | davecheney, it should *work* -- although it won't enable the PA -- it's just that I forgot to actually enable it | 07:11 |
| davecheney | s'ok, it was a one line change | 07:11 |
| fwereade | davecheney, propose it, it's a trivial | 07:11 |
| davecheney | but again, no PA secrets; no machines :( | 07:12 |
| davecheney | fwereade: kk | 07:12 |
| * davecheney afk for a few mins | 07:12 | |
| fwereade | davecheney, step by step :) | 07:12 |
| fwereade | davecheney, brb, weirdly sluggish system, restarting | 07:12 |
| davecheney | fwereade: intresting ... even with the correct image spec, it still booted an instance in us-east-1 | 07:28 |
| fwereade | davecheney, as I said, I am generally underwhelmed by that code | 07:29 |
| fwereade | davecheney, I think it needs a fair bit of work to be useful even *without* constraints | 07:29 |
| fwereade | davecheney, and that when we add constraints it will need still more | 07:29 |
| davecheney | right | 07:30 |
| fwereade | davecheney, sorry to bear bad tidings :( | 07:30 |
| davecheney | fwereade: gotta start somewhere | 07:30 |
| fwereade | davecheney, indeed :) | 07:31 |
| fwereade | davecheney, if you're planning to work on that code | 07:32 |
| davecheney | can i take a moment to whinge that --debug doesn't actually output anything more than you previously got | 07:32 |
| davecheney | thank you | 07:32 |
| fwereade | davecheney, may I suggest starting by removing the useless fields from InstanceConstraint? | 07:33 |
| fwereade | davecheney, we always want persistent storage, and we always want a released server image | 07:33 |
| davecheney | yeah, why would we ever want to boot an unstable desktop | 07:33 |
| davecheney | i'll make a bug for myself | 07:33 |
| fwereade | davecheney, quite so | 07:34 |
| fwereade | davecheney, cheers | 07:34 |
| davecheney | fwereade: can we talk about juju.Conn for a moment ? | 07:36 |
| fwereade | davecheney, ofc | 07:36 |
| davecheney | is that something you are working on in your sphere ? | 07:36 |
| davecheney | i kinda get the feeling that much has been discussed already | 07:36 |
| fwereade | davecheney, hmmm, it's something I'm reluctant to commit to *implementing* myself in a short timeframe | 07:36 |
| davecheney | fwereade: understood | 07:37 |
| fwereade | davecheney, but I think I have a reasonably clear view of the issues | 07:37 |
| davecheney | would i be well served by looking in the irc logs for the details ? | 07:37 |
| davecheney | (where are the irc logs btw) | 07:37 |
| davecheney | btw, great work on the watcher refactoring, the cargo culting of new watchers was starting to smell odd | 07:38 |
| fwereade | davecheney, hmmmm, probably not | 07:38 |
| fwereade | davecheney, cheers :) | 07:38 |
| fwereade | davecheney, let me run down what springs to mind immediately | 07:38 |
| davecheney | cool, iget the feeling that i'll be implementing it, 'cos I need it most urgently | 07:38 |
| fwereade | davecheney, it should be done at the Conn level rather than in response to specific operations just because we have a history of forgetting that it might need to be done :) | 07:39 |
| fwereade | davecheney, hmmm, it's a touch tangled in my mind, just trying to put thoughts in order | 07:40 |
| fwereade | davecheney, a lot of it is down to an issue in my mind that remains a source of some discomfort | 07:41 |
| fwereade | davecheney, I think there are 3 categories of environment setting | 07:41 |
| fwereade | davecheney, (hm, maybe more) there are those that must always be present, regardless of provider | 07:41 |
| * davecheney nods | 07:42 | |
| fwereade | davecheney, that is: type, name, default-series | 07:42 |
| fwereade | davecheney, I am adding default-series and type handling to Initialize as we speak | 07:42 |
| davecheney | fwereade: manditory, secret (but required), and optional (no sane default) | 07:42 |
| fwereade | davecheney, hmm, I hadn't been thinking of optional as a category | 07:43 |
| fwereade | davecheney, I was thinking juju-mandatory, provider-mandatory, and secret | 07:43 |
| fwereade | davecheney, I retain unease about the fact that we just poke all the juju-mandatory ones into the provider-specific config schemas -- that feels like a potential source of tedious bugs with little corresponding benefit | 07:45 |
| fwereade | davecheney, "name" is particularly an interesting one, because at the moment Initialize does not set (or even have access to ) the environment name | 07:45 |
| fwereade | davecheney, in some ways this is good because the lack of a name should, I hope, be sufficient to indicate an incomplete environ config even in the case of the dummy provider | 07:46 |
| davecheney | urk, that is because name is a synthetic property that comes via the yaml conversion ? | 07:46 |
| fwereade | davecheney, but it *also* feels like a source of potential avoidable bugs, because as discussed elsewhere we'll be in a world of hurt if we try to change an env name at runtime | 07:47 |
| fwereade | davecheney, I think it's just because "meh we don;t need it yet" | 07:47 |
| davecheney | fwereade: there are lots of those bits of information | 07:47 |
| davecheney | ec2 region is another example | 07:48 |
| fwereade | davecheney, however passing it up is a hassle -- we need to change userData, the initzk command, and state.Initialize to handle it | 07:48 |
| davecheney | early on in the config validation the region string from the config is turned into an aws.Region struct | 07:48 |
| davecheney | but, nowhere in that struct does it include its short name | 07:48 |
| davecheney | and so forth | 07:48 |
| fwereade | davecheney, yeah, I rather feel that the environ code has been implemented without paying close enough attention to the lessons learned working with multiple providers in the python | 07:49 |
| fwereade | davecheney, it's entirely understandable and forgivable, because those lessons don't rally strike home until you've done a bunch of work with them | 07:49 |
| fwereade | davecheney, but still a shame | 07:50 |
| davecheney | yup, maybe there is a case for doing an openstack or local provider concurrently | 07:50 |
| davecheney | to expose these issues sooner | 07:50 |
| fwereade | davecheney, there *definitely* is, but I think the decision to take those off the table is rational given the constraints we're working under | 07:50 |
| fwereade | davecheney, explicitly acknowledged tech debt is a lot better than the accidental kind | 07:51 |
| davecheney | yup, we don't get a prize if we have 3 sorta working providers, and no solid ec2 story | 07:51 |
| fwereade | davecheney, it's just that we've also taken on some accidental debt as well in the course of implementation | 07:51 |
| fwereade | davecheney, if you're looking into this stuff you could do worse than to take a casual look at the python provider implementations, though | 07:52 |
| fwereade | davecheney, while it's not perfect I think I did a reasonable job of separating the common from the provider-specific | 07:53 |
| davecheney | i think i don't spend enough time there | 07:53 |
| fwereade | davecheney, although I never addressed the flat-out retarded config issue whereby we leave "default" settings empty | 07:53 |
| fwereade | davecheney, and then do `config.get(key, default)` with the same default in multiple places | 07:54 |
| davecheney | ooh, that is a trao | 07:54 |
| davecheney | trap | 07:54 |
| fwereade | davecheney, yeah -- just something to be aware of | 07:54 |
| fwereade | davecheney, in the context of what you're currently working on, I think formalising (the equivalent of) the machine_data we have in python would be a good idea | 07:56 |
| davecheney | fwereade: thanks, i'll check it out | 07:57 |
| fwereade | davecheney, I'm not quite sure whether startInstance should take (*state.Info, *environs.MachineData), or just (*environs.MachineData) | 07:58 |
| fwereade | davecheney, but I'm 98% sure that a MachineData is a good idea :) | 07:58 |
| davecheney | i think the state.Info is a smell | 07:58 |
| davecheney | along with the secrets problem | 07:58 |
| fwereade | davecheney, there's something about that I'm not comfortable with, indeed, but I have yet to put my finger on it | 07:58 |
| davecheney | the argument about which state.Info you get has taken more than it's fair share of head space | 07:58 |
| fwereade | davecheney, yeah | 07:59 |
| fwereade | davecheney, there's probably a better way to do it :) | 07:59 |
| fwereade | davecheney, so... I hope this was slightly helpful, I feel what I've mostly said is "there are dragons here, here, and here, good luck!" | 08:00 |
| fwereade | davecheney, which is not without value but possibly I have skipped things that I think are "obvious"... so please let me know if I seem to have missed stuff | 08:01 |
| davecheney | fwereade: wrt startInstance and a state.Info, i think it's overengineered | 08:02 |
| davecheney | actually no | 08:03 |
| fwereade | davecheney, agree, I think there's quite enough info available internally | 08:03 |
| davecheney | i can't ever imagine how the provider could start a machine that would not talk to the state using exactly the same connection string as the pa | 08:03 |
| davecheney | hmm, i shuldn't use ever | 08:03 |
| davecheney | but it's certainly not the biggest problem at the moment | 08:04 |
| fwereade | davecheney, ah, but we don't know what the PA machine's address is at bootstrap time | 08:04 |
| fwereade | davecheney, so we have to start it pointing at localhost | 08:04 |
| fwereade | davecheney, and then figure out the actual address to use for the other machines later | 08:04 |
| fwereade | davecheney, it's not a problem we can just skip entirely | 08:04 |
| davecheney | this sounds like another secrets passing problem | 08:05 |
| fwereade | davecheney, it shares some features, yeah | 08:05 |
| davecheney | the details about the instance is started for machine/0 are so opaque we can't even say 'what is your public ip' | 08:05 |
| fwereade | davecheney, but I don't think we need any external input to figure out the right address -- surely we can figure that out on the machine? | 08:06 |
| fwereade | davecheney, doesn't the metadata service provide that? | 08:06 |
| davecheney | not sure what you mean by metadata service | 08:06 |
| fwereade | davecheney, environs/ec2/ec2.go:253 | 08:07 |
| fwereade | davecheney, it's what we use to figure out the instance id of the bootstrap machine at bootstrap time | 08:08 |
| davecheney | fwereade: ta | 08:08 |
| fwereade | davecheney, but honestly offhand I cannot remember what else it provides | 08:08 |
| davecheney | fwereade: wtf | 08:09 |
| davecheney | right so if you curl that url from inside your ec2 instance you can find out stuff about your instance | 08:09 |
| fwereade | davecheney, exactly | 08:14 |
| davecheney | that is both brilliant, and insane, in equal parts | 08:17 |
| fwereade | davecheney, ha, yeah | 08:21 |
| fwereade | davecheney, and ofc it can fail | 08:21 |
| fwereade | davecheney, which is not something we have actually handled now I come to think of it | 08:21 |
| fwereade | davecheney, I got botten by that at least once at my last job | 08:22 |
| davecheney | fwereade: maybe I should add something to goamz to talk directly to it | 08:22 |
| davecheney | rather than using the shell hammer | 08:22 |
| fwereade | davecheney, hmmmmm maybe | 08:22 |
| fwereade | davecheney, in this specific case we have providers where we *do* know the instance id before launch | 08:23 |
| fwereade | davecheney, and so passing it in on the command line seems to me like the right thing to do | 08:23 |
| fwereade | davecheney, rather than worrying about a provider-specific initialize | 08:24 |
| fwereade | davecheney, ...but yeah, getting it *reliably* is an issue that should be addresses | 08:24 |
| fwereade | davecheney, and I'm not actually sure if we do use the metadata service to figure out the long-term state info | 08:25 |
| fwereade | davecheney, I suspect that's something we do from the instance-id stored on S3, making use of secrets to interrgate aws | 08:25 |
| fwereade | davecheney, that's certainly what we need to do on the client, I think | 08:26 |
| fwereade | davecheney, but I'm getting a moderate sense that I may be talking crap, and that it would be wise to check the python | 08:26 |
| davecheney | fwereade: have a great day mate, i'm going offline now | 08:32 |
| fwereade | davecheney, cheers, take care | 08:32 |
| TheMue | Morning | 08:54 |
| * davecheney waves | 08:55 | |
| * TheMue waves back | 08:56 | |
| TheMue | Morning Aram | 09:15 |
| Aram | morning | 09:15 |
| TheMue | fwereade: Heya William, online again! ;) | 09:37 |
| fwereade | TheMue, heyhey, no idea what the issue was | 09:37 |
| TheMue | fwereade: It definitely shows how depended we are. | 09:37 |
| fwereade | TheMue, well, ok, the adsl was stuck "initializing LCP" for a long time... and then suddenly it wasn't :/ | 09:37 |
| fwereade | TheMue, indeed :) | 09:37 |
| TheMue | fwereade: My current provider is here thankfully pretty good. But I'll change to a different one in July (with an overlapping time having both). I hope it's so reliable too. | 09:39 |
| TheMue | fwereade: Got a neat bandwidth then. | 09:40 |
| Aram | meh, some dude came to tell me I have to pay 52€/2 months for TV and radio. | 09:40 |
| Aram | I don't have aither. | 09:40 |
| Aram | either. | 09:40 |
| Aram | I haven't watched TV in like 15 years. | 09:40 |
| TheMue | Aram: We have the same here. You may listen to the radio or watch TV, e.g. with the PC. So you've got to pay. | 09:42 |
| Aram | meh. | 09:42 |
| TheMue | Aram: But it's cheaper. | 09:42 |
| * TheMue and his family indeed watch TV and listen to the radio. :) | 09:43 | |
| TheMue | fwereade: Just merged your and my change to watcher, little text conflicts but no probs. | 09:44 |
| fwereade | TheMue, fantastic | 09:46 |
| TheMue | fwereade: But I'll have still to adopt your changes to the ServiceUnitsWatcher, just seen. :( The other one has been the deleted-is-now-removed-change. | 09:48 |
| TheMue | fwereade: I can't build and test jujud, see http://paste.ubuntu.com/1064020/. Can you reproduce that? | 10:02 |
| fwereade | TheMue, sorry, got distracted -- let me grab a fresh branch and try | 10:20 |
| fwereade | TheMue, works for me; if you've using the move-branches-around style of development you may want to delete your built package | 10:22 |
| TheMue | fwereade: Strange, no, will have a deeper look. | 10:26 |
| TheMue | fwereade: I took you watcher.go as merge base and only reproduced the changes regarding Deleted/Removed. | 10:27 |
| fwereade | TheMue, hmm; contentWatcher has Err and Stop, and everything should embed contentWatcher | 10:27 |
| TheMue | fwereade: Found it, melt took the wrong file. *sigh* I hate text conflicts. | 10:29 |
| fwereade | TheMue, heh, I just solve conflicts by hand every time, I think it saves me time on average ;) | 10:30 |
| twobottux | aujuju: "init: juju-..." errors in syslog after uninstalling juju <http://askubuntu.com/questions/157093/init-juju-errors-in-syslog-after-uninstalling-juju> | 10:32 |
| TheMue | fwereade: Yep, that has been the mistake, now it works. | 10:38 |
| fwereade | TheMue, cool | 10:38 |
| fwereade | TheMue, and, sorry: I only remember I said I'd wait for yours after I'd submitted :(( | 10:38 |
| TheMue | fwereade: No problem, that's always a risk using a VCS without locks (and with locks is even worse, I've once had been forced to use ClearCase). | 10:40 |
| fwereade | TheMue, haha | 10:40 |
| TheMue | fwereade: go test ./... still leads to a funny problem here. Due to my German locale one error message of mongo doesn't match and the test fails. ;) | 10:46 |
| fwereade | TheMue, eww | 10:46 |
| fwereade | TheMue, what test? | 10:46 |
| TheMue | fwereade: The store | 10:47 |
| TheMue | fwereade: bzr: ERROR: Kein Zweig: »/non-existent/~jeff/charms/precise/bad/trunk/«. | 10:48 |
| fwereade | TheMue, weird, that's only just started happening? | 10:48 |
| TheMue | fwereade: Expected is "Not a branch" instead of "Kein Zweig". | 10:48 |
| TheMue | fwereade: So far it's the only error. The returned error by type is the right one but the received string for it not. | 10:50 |
| TheMue | fwereade: That's also one reason why I dislike those generic error strings with errors.New() or fmt.Errorf(). | 10:50 |
| fwereade | TheMue, not i18nable? | 10:51 |
| TheMue | fwereade: In my apps/pkgs I use error types so that they can be compared (and later also be returned in the UI in the right language). | 10:51 |
| TheMue | fwereade: Yep | 10:51 |
| fwereade | TheMue, yeah, I think I probably do favour your approach; OTOH I see where niemeyer's coming from, we had an embarrassing mess of error types in python that didn't really help anything at all :) | 10:52 |
| TheMue | fwereade: As long as we only deploy instances with English locales everything is fine. | 10:53 |
| fwereade | TheMue, I agree that we shouldn't ever be depending on string values of errors in "real" code, and given that we have at least one core dev with a non-english locale I also agree we probably shouldn't be in tests either | 10:55 |
| TheMue | fwereade: We should talk about it in Lisbon. | 10:55 |
| fwereade | TheMue, SGTM | 10:56 |
| Aram | is machine 0 special? | 13:03 |
| Aram | right now I have a lot of code that tries to detect is a unit doesn't have a machine assigned or it's just machine 0. | 13:03 |
| Aram | if machine 0 is special I could remove all that crap | 13:03 |
| zirpu | Aram: machine 0 is currently the bootstrap node where zookeeper runs. | 13:15 |
| zirpu | so it's "special" in that sense. | 13:15 |
| Aram | so no new units can be assigned to it? | 13:15 |
| Aram | that's great. | 13:15 |
| zirpu | you can put subunits on it i think. | 13:16 |
| Aram | that's fine in my design. | 13:16 |
| zirpu | but mostly it's meant to orchestrate the rest of the units/services. | 13:16 |
| zirpu | there's a bug about making the bootstrap node high available, or have a 2ndardy. | 13:16 |
| zirpu | https://bugs.launchpad.net/juju/+bug/803042 | 13:16 |
| fwereade | Aram, sorry I missed that earlier: we really really should try not to make machine 0 special | 13:51 |
| Aram | hmm. | 13:51 |
| fwereade | Aram, it's also perfectly legitimate and expected to have any number of machines without units assigned | 13:51 |
| Aram | of course. | 13:52 |
| TheMue | fwereade: Just for info: I've adopted your watcher changes to the ServiceUnitsWatcher and it works pretty fine. | 13:53 |
| fwereade | TheMue, great | 13:53 |
| fwereade | TheMue, tiny nitpick -- any particular reason SUW is up at the top of the file away from the other topology watchers? | 13:54 |
| Aram | fwereade: I'm refactoring some really awful stuff I've worked on yesterday, I have a much better data model and the problem I had will not exist anymore, so everything is fine. | 13:54 |
| fwereade | Aram, cool | 13:54 |
| Aram | fwereade: btw, lbox was broken yesterday, niemeyer was kind enogh to fix it. | 13:57 |
| Aram | or was that the day before? | 13:57 |
| Aram | I guess the day before. | 13:57 |
| fwereade | Aram, yeah, I saw, and serendipitously had exactly the same failure the following day | 13:58 |
| fwereade | Aram, thanks for blazing that trail ;) | 13:58 |
| twobottux | aujuju: Can I specify tighter security group controls in EC2? <http://askubuntu.com/questions/156715/can-i-specify-tighter-security-group-controls-in-ec2> | 14:06 |
| fwereade | TheMue, how would you feel about vast and hideous surgery to the state tests? | 14:14 |
| fwereade | TheMue, I feel that state_test.go is way too big and we'd benefit from breaking things up into both separate files and separate suites within those files | 14:15 |
| TheMue | fwereade: +1 | 14:15 |
| fwereade | TheMue, cool, cheers | 14:15 |
| TheMue | fwereade: It has grown a lot over the time. | 14:15 |
| * fwereade dons tedium-proof outergarment | 14:16 | |
| TheMue | Did you know that rabbits can yawn? I'm sitting on the veranda, and one of our rabbits just done it. :D | 14:21 |
| Aram | fwereade: yes, state_test.go is way too big, for mstate I was planning to split it up and make it provider independent. | 14:23 |
| Aram | we could isolate mgo/zk things to a handful of utility functions. | 14:24 |
| fwereade | Aram, ouch, what are the provider dependencies? | 14:24 |
| Aram | and keep the tests pure. | 14:24 |
| fwereade | Aram, ahh, got you | 14:24 |
| TheMue | Hmm, firewall is tricky, multiple watchers, so multiple goroutines and tombs. | 15:10 |
| === imbrando1 is now known as imbrandon | ||
| bcsaller | google's compute engine will need a provider soon | 20:57 |
| === marrusl is now known as marrusl-ebayqbr | ||
| === marrusl-ebayqbr is now known as marrusl | ||
| === james_w` is now known as james_w | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!