User1: https://bugs.launchpad.net/juju-core/+bug/1059921
User1: --format=json :(
User2: User1 I've been explicitly using --format=json to avoid formatting incompatibilities between go/python
User1: User2 yeah, i'm fixing the command line parser to handle this case
User1: lucky(~/src/launchpad.net/juju-core) % juju bootstrap --upload-tools
User1: lucky(~/src/launchpad.net/juju-core) % juju deploy mysql
User1: error: no reachable servers
User1: outstanding ... bootstrap didn't
User1: aws said yes
User1: but the console says that instance is stillborne
User1: https://code.launchpad.net/~dave-cheney/gnuflag/001-parse-more-gnu-args/+merge/127419
User1: ^ gnuflags doesn't have lbox setup
User3: fwereade, davechen1y: mornin'
User1: monring
User4: rogpeppe, davecheney, heyhey
User1: User3 i have a non CL patch for you to review
User4: rogpeppe, User1 I'm thinking I might actually take my swap day, I fell asleep really early last night and would prefer not to waste the sudden urge to rest
User4: rogpeppe, davecheney, *but* ofc I have reviews to respond to first :p
User1: User4 sgtm - don't forget meeting this aternoon
User3: User4 ok, have fun if so!
User4: davecheney, good point, ty
User3: User1 i was about to ask if you had any reviews you wanted me to look at
User1: one to gnuflags
User1: User3 https://code.launchpad.net/~dave-cheney/gnuflag/001-parse-more-gnu-args/+merge/127419
User1: needed, basically, because all the charms expect it
User3: User1 no codereview link?
User1: User3 it doesn't make one
User1: hang on
User3: User1 what doesn't make one?
User1: lbox
User1: just found the option
User3: User1 -cr
User1: https://codereview.appspot.com/6588060
User1: User3 why don't i need to do that on juju-core ?
User3: User1 there's a .lbox file in its root
User3: User1 with flags in
User1: fairy nuf
User3: User1 i'm on the review BTW
User3: User1 i'm not sure it's as simple as your CL tries to make it (which is why i didn't do it before)
User3: User1 you've got a review
User5: good morning
User5: hi fwereade
User4: TheMue, heyhey, I'm not really here :)
User5: oh, where you are?
User4: TheMue, swap-daying
User4: TheMue, I'm tired and it's my birthday :)
User5: User4 ah, ic. so what do you do here? ;)
User5: oh, happy birthday
User4: TheMue, well, the most entertaining thing I can do for the next 10 mins is poke at how we implement relations and try to come up with something cleaner than what we have for the current use cases
User4: TheMue, after that I'll go out for a while, but see you at the meeting
User5: User4 so it's a half swap-day
User4: TheMue, whatever :)
User5: User4 :D
User3: User4 hippy barday to you!
User3: User4 BTW AgentName isn't happening, but we're renaming PathKey to... something else.
User6: happy birthday fwereade.
User3: User4 my suggestion was Name, but that doesn't work because Service.Name already has implications. niemeyer suggested Key but that doesn't work because all kinds of things have keys.
User3: User4 currently going with an earlier of niemeyer's suggestions: EntityName
User3: User4 but i'm not greatly happy with that either - any suggestions welcome.
User6: meeting in 1 min or 61 min?
User6: ow
User6: now
User7: Morning!
User8: team meeting hangout invite sent
User8: https://plus.google.com/hangouts/_/557e6f4f5f9de98be4769ec91fc82db48a75d356?authuser=0&hl=en-GB
User7: User8 Thanks
User3: User4 meeting...
User1: User3 https://bugs.launchpad.net/mgo/+bug/1045678
User1: ^ may be of interest
User1: User7 --format=json
User1: gnuargs only supports --format json
User1: User7 all: https://bugs.launchpad.net/juju-core/+bug/1059921
User3: User1 i'm happy to do the gnuflag change if you like
User3: User1 i do bear responsibility for that package, after all
User1: User3 if you want to take a crack over night, i would be most grateful
User3: User1 ok
User1: i also tried splitting on the = and pushing the remainder back into f.procArgs, which worked, but the testFlagsetParse tests were not happy
User1: and I couldn't figure out why
User7: davecheney, User3 What's the problem with storing the empty flag in procFlag?
User7: davecheney, User3 Sorry, I think I meant procArgs
User3: User7 i'm not sure i understand the question
User1: User7 that would probably work, but TestFlagSetParse always failed for reasons I didn't understand
User7: User3 What's the problem with doing the straightforward and just splitting --foo=bar and storing "bar" as usual?
User1: User7 that is what I tried first
User1: pushing the remainder back into procArgs
User1: but I couldn't make the test pass
User3: User7 what if bar is empty?
User7: User3 What's the problem with that/
User7: ?
User7: User3 --foo "" is fine
User7: User3 and so is --foo=
User4: dammit -- did I completely miss it?
User7: User4 Happy birthday!
User4: niemeyer, haha, cheers :)
User7: :-)
User1: User4 happy annual celebration!
User4: niemeyer, went out for a nice casual brunch with cath and then got screwed by the busses on the way back :/
User4: niemeyer, the intent was there though :(
User4: davecheney, cheers :)
User7: User4 No worries really, it was a nice and quick sync up
User4: niemeyer, excellent
User3: User7 i have to remember the code properly, gimme a few moments
User7: User3 And btw, given your suggestion in the review, note that "--foo=bar" and "--foo =bar" mean different things
User3: User7 indeed, but i think that wouldn't be a problem if we did it the way i suggested
User3: User7 because we wouldn't put the latter argument into procFlag
User7: User3 Cool
User3: User7 the main immediate problem with storing an empty procFlag is that i want to be able to do --foo=false for boolean flags.
User3: User7 while still allowing --foo to mean the same as --foo=true
User7: User3 Sounds good, although I'm not familiar with the algorithm there to have an opinion
User3: User7 i'm nearly there. we'll see if the tests work :-)
User7: User3 Super :)
 * niemeyer gets some coffee
User4: niemeyer, User6 can we talk a little about relations and their creation, retrieval, and watchery?
User6: sure
User4: Aram, teh relation key is now a string with N service:relation pairs, in sort order, right?
User6: yes
User4: Aram, this is interesting from my POV because we identify relations to hooks in a not-quite-neatly-fitting way
User6: it's also used in some watchers to identify that the relation belongs to a service.
User4: Aram, as I see it we can either have an API that gets a relation by pre-existing ID number, rather than by key
User4: Aram, which will be convenient for the hook tools
User4: Aram, or we can try to do more interesting things with the key and do everything that way
User4: Aram, User7 and I'm rather hoping someone else has some thoughts on this because I can't tell which is better
User6: so, the hook cares about the id of the relation?
User4: niemeyer, eg, do we think that anyone is depending on any way on the format of the JUJU_RELATION env vars?
User4: Aram, the hook needs to differentiate between different relations on the same endpoint
User4: Aram, there's a JUJU_RELATION which is, say, "db", and a JUJU_RELATION_ID which is, say "db:7"
User4: Aram, User7 if we were to specify, instead, a JUJU_RELATION_ID of "db:otherservice:otherrelation"
User4: Aram, User7 I think it should be pretty simple to transform back and forth into real relation keys
User4: Aram, User7 which would resolve the icky two-Relation-getter-methods-on-State thing
User4: niemeyer, User6 I am then *very* torn on the issue of AddRelation and what params it should take
User4: niemeyer, User6 on the one hand, it's very convenient to be able to make up any old relations we like
User4: niemeyer, User6 and we make wanton use of this ability in the tests
User4: niemeyer, User6 (thought, derail atm: there's some always-on relation we should always be able to handle, right? for subordinates?)
User4: niemeyer, User6 on the other, it's pretty clearly a Bad Thing to be able to create any nonsensical relation we like, we ought to be validating them against the charms, just like we should be on upgrade
User4: niemeyer, Aram, so my instinct is drawn towards a fuzzy-name interface for both AddRelation and Relation: ie it accepts things like "wordpress mysql" and figures out the right answer without ambiguity
User4: niemeyer, User6 but which mostly wants and expects real keys for normal usage
 * niemeyer catches up
User6: hmm?
User6: how would it resolve the fuzzy naming?
User4: niemeyer, User6 do I sound like I'm on crack, and just making needless work? I *think* there's something important buried in there somewhere
User4: Aram, not very fuzzy -- you have to specify the service names, but can leave the :relation bit off if there's no ambiguity
User7: User4 No, I think you're on a good track
User4: Aram, the point is just that it allows for a single clean API that includes appropriate validation for all uses
User7: User4 I dislike a bit the way relations are referred to right now
User4: Aram, it's definitely not a polished proposal just a feel that *something* is wrong
User4: niemeyer, in what context?
User7: User4 In general
User4: niemeyer, they're represented too many ways already, I think ;)
User7: User4 Oh, sory
User7: sorry
User7: User4 I mean the way we refer to them by a string that is a concatenation of the endpoints
User7: User4 It ended up as a convenient way, though
User4: niemeyer, ha, I've been coming to rather like that -- if it is (or is trivially transformable to/from) the relation "names" that the user types/sees, I think it is a good thing
User7: User4 So, let me try to help on a few of your questions above
 * fwereade sits attentively
User7: User4 I don't think we should change the environment variable
User7: User4 It's breakage that sounds easy to avoid
User4: niemeyer, ok, wholeheartedly accept that argument
User7: User4 It sounds fine to have a method that grabs the relation by its numeric id
User7: User4 I'm not sure I get the problem you describe referring to AddRelation, though
User4: niemeyer, a client of the API is perfectly able to AddRelation(<wordpress:lol>, <mysql:giggle>)
User4: niemeyer, and we will consider that a perfectly good relation, and join it, and just not run any hooks
User4: niemeyer, IMO this is bad because if that relation *becomes* valid in future charms, to which we upgrade, we'll start running hooks in a weird weird state -- not installed, for a start
User3: davecheney, User7 https://codereview.appspot.com/6598052/
User3: now for some lunch
User4: niemeyer, so, we should really just not be allowed to create them, just as we don't create services referring to charms that cdon't exist
User6: User4 yeah, we should validate the relation, we didn't do so because we didn't have the emans when I've written that/
User6: s/emans/means/
User4: Aram, did we not? I thought charm.Meta was all we needed?
User4: Aram, ok, but it's not just a matter of validating the endpoints
User7: User4 Curious.. :-)
User4: Aram, it's a matter of specifying them in the first place, in add-relation, which requires that we do the validation
User7: User4 A bit of history.. https://codereview.appspot.com/6305067/ ;-)
User4: niemeyer, ok, that is referring (I think) to a somewhat lower standard of validity
User4: niemeyer, I think that in apprehending the charm-upgrade issue, my thoughts on this matter have taken a harder line
User7: User4 Yeah, your thoughts on it are well appreciated
User7: User4 So, hmm.. what prevents a relation from being added while an upgrade is in progress?
User4: niemeyer, nothing yet
User4: niemeyer, things are still changing under my feet enough that I don't have a clear picture of the final shape of the solution
User4: niemeyer, I just know it's something that should be borne in mind
User7: User4 We should certainly validate the relation.. just trying to imagine how to do it properly
User4: niemeyer, I don't see any way around getting the charms' Metas
User7: User4 We can add an assertion against the revision numbers of the involved services, I suppose
User4: niemeyer, I think it's easier that that if we are careful with the lifetimes and with what upgrades we allow
User4: niemeyer, block upgrades which would change non-Dead relations
User7: User4 Yeah, this is the basic need.. the next question is which charm
User7: User4 That's already an agreement I think, although we didn't put it in place yet
User4: niemeyer, the current one of the service -- by blocking upgrades until incompatible relations are gone we can always use the service's current charm
User7: User4 But besides that, we must also prevent adding a relation after the decision that it was ok to upgrade happens
User4: niemeyer, it becomes a matter of figuring out what races we have to deal with between client 1 adding relations and client 2 upgrading charms
User7: User4 Yeah, that's what I was referring to above
User7: User4 We can add an assertion against the revision numbers of the involved services, I suppose
User4: niemeyer, I am hoping that we will be able to express suitable asserts in the transactions
User7: User4 To prevent adding a relation to a service that holds an unknown charm
User4: niemeyer, yeah, exactly
User7: User4 Cool, nothing sounds too bad so far
User4: niemeyer, as long as we express the changes correctly on the client, we can find some way to keep not-yet-ok charms off to one side until the deployed charm can handle them
User4: niemeyer, not really sure how to do that yet
User4: niemeyer, doesn't feel likely to be a real dealbreaker
User7: User4 You mean not-yet-ok relations?
 * fwereade slaps self
User4: niemeyer, yes, thank you
User7: User4 Cool, np
User7: User4 Yeah, agreed.. we have easy access to the current charm from the uniter
User4: niemeyer, yeah, it feels quite neat
User4: niemeyer, you had doubts about the appropriateness of the current "foo:bar baz:qux" key, though?
User4: niemeyer, actually, that's in backward form :p
User7: User4 I have a tiny dislike for it.. but it's not a big deal I think
User4: niemeyer, I *think* that the ease of transformation to/from user-speak is very nice
User7: User4 The only change I'll likely propose in the short term is to order the keys by role
User4: niemeyer, +1
User7: User4 Otherwise we have "wordpress:db mysql:server" and "mysql:server blogger:foo"
User7: Which is not great
User4: niemeyer, requirer then provider?
User7: User4 Yeah,  that sounds sensible
User4: ok then -- since the ids-in-watchers change, I have no way to progress on relations without working on some of this stuff
User4: niemeyer, ^^
User4: niemeyer, I really don't think it is sensible for me to get sidetracked by the CLI-related bit when the uniter is still to be done, so I think I will just add a minimal RelationById(int) (*Relation, error) and change Relation() to take a key instead of endpoints
User4: Aram, how are the watchers looking?
User4: Aram, specifically ServiceRelationsWatcher :)
User6: nothing done on that front, there's one in review you can look at, it will definetly look very similar.
User4: Aram, great, I will * try* to check that out this evening
User7: User4 Hmm
 * fwereade listens
User7: User4 Sorry, still pondering on the scheme you mention there
User7: User4 Having the relation taking a key instead of endpoints doesn't feel great
User7: User4 The way we have the current interface pretty consistent on that front feels like a nice win we have
User4: niemeyer, hmm; I need to get relations both by key (because I presume that is how the watcher will deliver them) and by id (because that is how I express them to the hooks, which might pass them back to me)
User4: niemeyer, getting relations, and watching relations, by key, seems natural to me
 * rogpeppe had never realised the subtle difference in Gnu flags between -u=foo and --u=foo
User4: niemeyer, the intent is that at some stage we can change over AddRelation to take a string, just as GetRelation does, that does the appropriate inference of unambiguously underspecified endpoints
User4: niemeyer, and sorts appropriately, I guess
User7: User4 :-)
User7: User4 Effectively manipulating the key onto a different key
User4: niemeyer, and thereby as a second step get back a unified API, that is backward-compatible with the stuff I've been doing in the uniter
User4: niemeyer, ok, the heart of it is this
User4: niemeyer, I need to look them up in 2 different ways, neither of which is the same as the current way to get a relation
User7: User4 What is the real underlying needs you have?
User4: niemeyer, if I just add two trivial RelationByKey and RelationById methods, I'm golden
User7: User4 -1 on relation by key
User7: User4 key is internal, and is a compilation of the current endpoint semantics
User7: User4 I'm pretty sure we'll regret if we change it
User4: niemeyer, ah -- I had thought we were loving away from internal keys that differed from external names
User4: niemeyer, but, ok, if it's not the thing that we use to look things up by, and to send in watchers, it's not much of a key, is it?
User7: User4 That's one of the reasons why I dislike the key mechanism. That said, I'm pretty sure exposing it as suggested will lead to many other issues that don't feel great to get into.
User7: User4 You just mentioned one of them.. we cannot add a relation by its key, because we have to manipulate the key first
User7: User4 It's a primary key used in the database.. there's no single place in our API that exposes this key
User7: User4 It's an implementation detail
User7: User4 To enable the API that we've agreed on so far
User7: User4 We can kill the idea of using it as a key if we change the API
User4: niemeyer, ok, then ID remains the primary way of identifying relations?
User7: User4 It depends on the way you look at it
User7: User4 how does our API look like? Are we using id as a primary way to identify relations?
User4: niemeyer, ok: SRW will send IDs, and I will call a State method that takes an ID when I want to see what relation it refers to
User4: niemeyer, I have assumed ID to be the main way, yes, but little committed code depends on this
User7: User4 We can make the concept more first class
User7: User4 For instance, state.Relation(id) sounds fine..
User7: User4 Feels a lot more sensible than obtaining all the endpoints to grab the relation
User7: User4 We can then have e.g. state.EndpointsRelation(endpoints ...RelationEndpoint) (*Relation, error)
User4: niemeyer, great, +1
User4: Aram, in the absence of other feedback, then, I will probably move on to a SRW that generates IDs at some point tomorrow; please let me know if you suspect collisions
User4: Aram, I imagine I will implement it along the lines of your proposal
User7: User4 This kills the inconsistency, I think, and makes state.Relation(relation.Id()) work, as usual for everything else
User4: niemeyer, yeah, that is fine by me
User6: User4 I don't anticipate any collisions, everythung should be smooth
User4: niemeyer, and then we can have a state.InferEndpoints(eps ...string) ([]RelationEndpoint, error), that can be used by the CLI tools
User7: User4 Yeah, that sounds great
User4: niemeyer, and as a bonus we can keep the AddRelation logic as it is for now and do that properly in concert with the upgrady bits
User7: User4 Cool
User7: User4 Btw, there's a great benefit of having the DB _id being the key as it is today
User7: User4 The service relations watcher doesn't have to load the document to tell what service it targets
User4: niemeyer, +100
User4: niemeyer, I *knew* there *was* something really good about it
User7: User4 Yeah, that was kind of an unanticipated benefit.. the real reason we changed was the transaction mechanism
User7: User4 Without this, we can't add a unique relation
User7: User4 Because we don't have anything to assert on
User4: niemeyer, very neat :)
User7: User4 We can't assert on non-existence of something else that contains a given field
User7: User4 Do you have a moment to talk about https://codereview.appspot.com/6588053/diff/2001/worker/uniter/modes.go#newcode171
User7: User4 happy to postpone if you're in flow on something else
User9: :(
User9: <niemeyer> User4 Do you have a moment to talk about https://codereview.appspot.com/6588053/diff/2001/worker/uniter/modes.go#newcode171
User9: <niemeyer> User4 happy to postpone if you're in flow on something else
User5: hmm, the current test in environs/ec2 in trunk has one fail and one panic. anybody working on that?
User7: User5 What's the failure/panic?
User7: Hmm.. something in the last two revisions broke it
User5: User7 Fail is NoSuchBucket in TearDownTest
User7: Ah
User7: That's Dave's change
User5: User7 Panic is in localServerSuite.TestBootstrapInstanceUserDataAndState
User7: Let's see in the previous revision
User7: User5 Proposing
User5: User7 Pardon?
User7: User5 I've fixed it.. CL up in a moment
User7: User5 https://codereview.appspot.com/6596056
User5: User7 LGTM
User3: User7 PathKey->EntityName https://codereview.appspot.com/6593061/
User7: User3 LGTM
User3: User7 thanks!
User4: niemeyer, I think I can for a mo :)
User7: User3 np, and thanks
User7: User4 Sorry, I just read your mail and didn't realize you were out before
User4: niemeyer, nah, I was explicitly doing it because I realised I needed to and, meh, cath was out :)
User4: niemeyer, while C&L are distracted together I'm more than happy to talk if it helps us progress
User4: niemeyer, it just means I may disappear abruptly for hours at a time :)
User7: User4 I was just going to mention that the issue there was simpler than it sounded
User7: User4 I was questioning why we do the wantEvent+waitForConfig dance at all
User7: User4 Rather than just running the hook directly
User4: niemeyer, yeah -- as it turned out I really did have a reason ;)
User4: niemeyer, not well expressed in the comments though ;)
User4: niemeyer, oh yeah, I meant to ask about the resolved business
User7: User4 Cool, I'm curious about why that is, but I can wait for the comment easily :)
User4: niemeyer, in suggesting that no ResolvedNone event needs to be sent, I imagine that, to go with this, a wantResolved would just do nothing if the state was ResolvedNone
User4: niemeyer, which makes "want" not quite right, maybe
User4: niemeyer, or maybe "want" is just right :)
User4: niemeyer, regardless, it would necessarily I think break the want-always-causes-a-send-as-soon-as-possible feature
User4: niemeyer, the immediate consequences are generally good
User4: niemeyer, but that property did seem like quite a nice one
User7: User4 Yeah, a slight change in perspective.. it does send an event immediately, as long as the current state is sensible
User4: niemeyer, ha, actually, the way I expressed it above, it *doesn't* break it
User4: niemeyer, ok, if you've already considered it from that perspective I'm very happy indeed to do it that way
User2: User4 aren't you supposed to be doing celebratory chores?
User7: User4 Yeah, I wish we could do the same for upgrades actually
User4: SpamapS, did some, now I can relax again ;p
User4: niemeyer, upgrades aren't so simple, the upgradiness of a given service charm differs depending on mode
User7: User4 You mean force vs. non-force?
User4: niemeyer, and what it's to
User4: niemeyer, X is not an interesting request when we're already upgrading to X even if it's forced
User4: nie sorry gtg for a while again
User7: User4 Please do go :)
 * niemeyer => lunch
User5: User7 a final propose of https://codereview.appspot.com/6596051/ for the error message of illegal firewall modes
User3: User7 any idea why this doesn't work? http://paste.ubuntu.com/1256219/
User7: User3 Because you're authenticating against the wrong database
User3: User7 ah, i wondered if it might be something like that
User7: User3 The "/dbname" at the end of the URL does the trick
User7: User3 That said, I don't think we want to use it like that, FWIW
User7: User3 Login is a lot easier
User3: User7 i don't think so either
User3: User7 but i wanted something to verify that AddUser was actually doing something
User3: User7 and in fact, for non-SSL connections, perhaps we do want to do it this way
User3: User7 Login... hmm, i started doing it that way, then thought this was easier!
User3: User7 SetPassword in state: https://codereview.appspot.com/6587060/
User7: User3 Reviewed
User3: User7 thanks
User7: User3 np
User3: User7 i'm not entirely sure how i can check that the presence database is authenticated. currently there's no difference between an authenticated and an unauthenticated connection AFAIK
User7: User3 Perhaps we should fix that first then?
User3: User7 i'm not sure i can do that without running mongo in auth mode, which comes in the next CL
User7: User3 Perhaps we should do that first?
User3: User7 hmm, yeah, we could do that
User7: User3 As it is the CL has a bug that went unperceived because we had no tests.. feels like a good reason to step back
User3: User7 i'm not entirely sure i understand how the auth mode thing works - the mongodb docs seem pretty sketchy
User3: User7 i don't think the bug comment was published
User7: User3 ?
User3: User7 i don't see any comment in your review that points out a bug
User3: User7 (apart from "Just needs a test to ensure the bug is fixed")
User7: User3 Try to add the test then :-)
User3: User7 ha
User3: User7 i just looked at the comment in context :-)
User7: User3 In terms of --auth, just running with --auth enables secure mode.. it allows connecting locally to the database before a user is added
User7: User3 Which is quite handy for what we want
User3: User7 ok, i'll make another CL that runs the testing mongodb server in auth mode.
User3: User7 once a user is added, does it stop any further unauthenticated local connections?
User7: User3 I think all we'd need is running the test mgo in auth mode, and use SetAdminPassword on it
User7: User3 Right
User3: User7 i don't see a SetAdminPassword method in mgo
User7: User3 That's about juju :-)
User3: User7 but we can add a user in state.Initialize
User3: User7 i'd thought we might add a password argument to state.Initialize
User7: User3 and then how do we connect?
User7: User3 Well, sorry, that's irrelevant
User3: User7 with Open as usual, no?:
User7: User3 Yeah
User7: User3 Either way, Initialize can be made in terms of SetAdminPassword..
User3: User7 seems reasonable
User3: User7 BTW in environs/cloudinit, i'm planning to write the entity name and password to $dataDir/admin/mongodb-auth
User3: User7 then the agents will read that and put the info into the state.Info before connecting
User3: User7 i've gotta go and cook up some wild mushrooms for tea :-)
User7: User3 Sounds fine, except a "/auth" file sounds enough. We need to consider how to handle the multiple agents too. $dataDir is shared, IIRC
User3: User7 ok. i wondered if there might be a problem with people reading the length of the file, given that $dataDir is globally readable.
User3: User7 for multiple agents, i'd thought we'd use agents/$entityname/auth
User7: User3 Not sure.. agents/ was going away, I think.. we'll have containers/ instead IIRC
User3: User7 i think i'll fold in the Initialize changes into the current CL otherwise we've got a small chicken/egg problem .
User7: User3 We must also think about how to avoid having the admin password exposed..
User3: User7 well, the same directory that's used for the agent anyway
User7: User3 I don't see the chicken/egg problem
User3: User7 i think it's got to sit in a file. as long as it's in a 700 file in a 700 directory, i don't think there's a problem
User7: User3 I mean how to get the admin password to be set in a way that doesn't leak it
User7: User3 and at the same time is known by the client
User3: User7 Initialize relies on SetPassword (well SetAdminPassword which is almost exactly the same thing), and that's what's in the current CL
User7: User3 That's how we end up with big unfocused branches
User7: User3 It doesn't really on unit.SetPassword or machine.SetPassword
User7: rely
User3: User7 yes, but the testing will be exactly the same (they both share tests)
User3: User7 as will the implementation
User3: User7 and we'll need the changes from the current CL that do the login too
User7: User3 What happens if you login with an invalid user?
User3: User7 you get an "auth failed" error
User7: User3 s.Session.Login("admin", "foo")
User7: User3 This means one can trivially implement SetAdminPassword, and test it
User3: User7 ok, so that's stage 1. the next stage needs to have all the other login stuff in. and that's the bulk of it. SetAdminPassword is about two lines of code.
User7: User3 Without Open, or machine.SetPassword, or unit.SetPassword, or Initialize, etc
User7: User3 No, it doesn't
User7: User3 The next stage can have just the changes to state.Open, I believe
User7: User3 Without anything else again
User3: User7 that's what i meant
User7: User3 No unit.SetPassword, no machine.SetPassword, etc
User3: User7 i didn't mean those as login stuff.
User3: User7 anyway, it's all pretty small. i don't think there's a danger (currently) of the branch getting too unfocused
User7: User3 That's how it starts every time
User7: User3 and that's the direction that it was going again
User7: User3 It's extremely rewarding to have small branches quickly integrated
User3: User7 i will try
User3: User7 BTW your admin password question is salient
User3: User7 i don't know how we can get the admin password to the bootstrap machine without putting it in cloudinit
User3: User7 and hence making it available forever
User7: User3 I think we can use a hash trick on the original password
User7: User3 hash it together with a well known token, and use that as the first password.
User3: User7 yeah, i suppose we could use a hash designed for passwords.
User7: User3 On first connection, replace with the actual password
User7: User3 That's not the issue
User7: User3 If we use a hash designed for passwords as the password, we'd still have the same issue
User3: User7 i realise we have to change the password on first connection
User3: User7 but we also need to use a hash designed for passwords, i think
User7: User3 Not super worried about it, as long as it's a cryptographic hash
User3: User7 otherwise someone can reverse the hash and connect as admin
User7: User3 None of the traditional hashing algorithms are reversible
User3: User7 i think it's important actually, if we're concerned about security from the bootstrap machine
User3: User7 they don't need to be reversible if the password isn't so strong
User7: User3 In fact, hashes are not reversible by definition.. they may have other weaknesses, but not reversibility
User3: User7 i should've said "crack" not "reverse"
User7: User3 It doesn't matter in this context
User3: User7 because they can't make that many connections to mongodb?
User7: User3 Sorry, I don't understand what problem you're trying to solve
User3: User7 i'm imagining someone malicious on the bootstrap machine. they have the hash of the password from cloud-init; now they're trying to log in as admin
User7: User3 Okay.. they have a hash based on the password.. so what?
User3: User7 they can go through a few hundred billion passwords quite easily; when they find one that hashes to the same thing, they have the admin password.
User3: User7 hence we slow down that process by using a hash designed for that purpose.
User3: User7 i really must go; i'll pop my head in a little later.
User7: User3 Enjoy
User7: I've got a doc appointment.. back soon
User4: niemeyer, ping
User7: User4 you're probably off by now, but I just sent a question in the review
User7: User4 Have seen your email too, and pondering.. will reply later
User1: state_test.go:250: c.Assert(current, DeepEquals, initial)
User1: ... obtained map[string]interface {} = map[string]interface {}{"firewall-mode":"default", "name":"test", "development":true, "authorized-keys":"i-am-a-key", "default-series":"precise", "type":"test"}
User1: ... expected map[string]interface {} = map[string]interface {}{"type":"test", "name":"test", "development":true, "authorized-keys":"i-am-a-key", "default-series":"precise"}
User1: ^ when was firewall-mode added ?
User1: User7 https://bugs.launchpad.net/juju-core/+bug/1060509
User1: can anyone else reproduce this, i'm getting it on two systems
User7: User1 It was added today
User7: User1 Well, yesterday from your perspective
User7: User1 Frank probably didn't run the full test suite
User1: https://codereview.appspot.com/6590064 has the fix
User7: User1 LGTM
User1: ta
User1: what happened with rogers gnuflag patch ?
User1: ok, the mysql charm is failing because falvor doesn't have a valid default
User1: User7 it looks like charm setting's defaults are broken
juju-dev
Ubuntu IRC