[00:47] <jcharette> anyone around to support MAAS with juju?
[01:45] <jcharette> anyone have experience making juju work with MAAS
[01:57] <zirpu> jcharette: did you try the #maas channel?
[02:08] <jcharette> no, but i can
[02:09] <jcharette> doesn't seem to be a maas problem, juju hasn't even tried to connect
[04:30] <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:49] <davecheney> m_3: hey hey
[04:49] <davecheney> m_3: i think it will be friday
[04:50] <davecheney> so maybe the east coast friday
[04:52] <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:53] <m_3> sorry thought that was gustavo's talk
[06:49] <davecheney> fwereade: howdy
[06:54] <davecheney> cmd/juju only lists bootstrap and destroy-environment as options, there is no deploy
[06:54] <davecheney> was this intentional ?
[07:02] <fwereade> davecheney, heh, no it wasn't
[07:02] <fwereade> davecheney, sorry about that
[07:03] <fwereade> davecheney, re your email, the ultra-short version is that no deploy doesn't publish secrets
[07:04] <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:05] <fwereade> davecheney, sounds sane?
[07:08] <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:09] <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:10] <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:11] <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:12] <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:28] <davecheney> fwereade: intresting ... even with the correct image spec, it still booted an instance in us-east-1
[07:29] <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:30] <davecheney> right
[07:30] <fwereade> davecheney, sorry to bear bad tidings :(
[07:30] <davecheney> fwereade: gotta start somewhere
[07:31] <fwereade> davecheney, indeed :)
[07:32] <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:33] <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:34] <fwereade> davecheney, quite so
[07:34] <fwereade> davecheney, cheers
[07:36] <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:37] <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:38] <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:39] <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:40] <fwereade> davecheney, hmmm, it's a touch tangled in my mind, just trying to put thoughts in order
[07:41] <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:42]  * 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:43] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <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:54] <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:56] <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:57] <davecheney> fwereade: thanks, i'll check it out
[07:58] <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:59] <fwereade> davecheney, yeah
[07:59] <fwereade> davecheney, there's probably a better way to do it :)
[08:00] <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:01] <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:02] <davecheney> fwereade: wrt startInstance and a state.Info, i think it's overengineered
[08:03] <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:04] <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:05] <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:06] <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:07] <fwereade> davecheney, environs/ec2/ec2.go:253
[08:08] <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:09] <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:14] <fwereade> davecheney, exactly
[08:17] <davecheney> that is both brilliant, and insane, in equal parts
[08:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:32] <davecheney> fwereade: have a great day mate, i'm going offline now
[08:32] <fwereade> davecheney, cheers, take care
[08:54] <TheMue> Morning
[08:55]  * davecheney waves
[08:56]  * TheMue waves back
[09:15] <TheMue> Morning Aram
[09:15] <Aram> morning
[09:37] <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:39] <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:40] <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:42] <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:43]  * TheMue and his family indeed watch TV and listen to the radio. :)
[09:44] <TheMue> fwereade: Just merged your and my change to watcher, little text conflicts but no probs.
[09:46] <fwereade> TheMue, fantastic
[09:48] <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.
[10:02] <TheMue> fwereade: I can't build and test jujud, see http://paste.ubuntu.com/1064020/. Can you reproduce that?
[10:20] <fwereade> TheMue, sorry, got distracted -- let me grab a fresh branch and try
[10:22] <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:26] <TheMue> fwereade: Strange, no, will have a deeper look.
[10:27] <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:29] <TheMue> fwereade: Found it, melt took the wrong file. *sigh* I hate text conflicts.
[10:30] <fwereade> TheMue, heh, I just solve conflicts by hand every time, I think it saves me time on average ;)
[10:32] <twobottux> aujuju: "init: juju-..." errors in syslog after uninstalling juju <http://askubuntu.com/questions/157093/init-juju-errors-in-syslog-after-uninstalling-juju>
[10:38] <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:40] <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:46] <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:47] <TheMue> fwereade: The store
[10:48] <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:50] <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:51] <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:52] <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:53] <TheMue> fwereade: As long as we only deploy instances with English locales everything is fine.
[10:55] <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:56] <fwereade> TheMue, SGTM
[13:03] <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:15] <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:16] <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:51] <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:52] <Aram> of course.
[13:53] <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:54] <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:57] <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:58] <fwereade> Aram, yeah, I saw, and serendipitously had exactly the same failure the following day
[13:58] <fwereade> Aram, thanks for blazing that trail ;)
[14:06] <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:14] <fwereade> TheMue, how would you feel about vast and hideous surgery to the state tests?
[14:15] <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:16]  * fwereade dons tedium-proof outergarment
[14:21] <TheMue> Did you know that rabbits can yawn? I'm sitting on the veranda, and one of our rabbits just done it. :D
[14:23] <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:24] <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
[15:10] <TheMue> Hmm, firewall is tricky, multiple watchers, so multiple goroutines and tombs.
=== imbrando1 is now known as imbrandon
[20:57] <bcsaller> google's compute engine will need a provider soon
=== marrusl is now known as marrusl-ebayqbr
=== marrusl-ebayqbr is now known as marrusl
=== james_w` is now known as james_w