| andrewsmedina | niemeyer: error: Get https://api.launchpad.net/devel/people/+me: x509: certificate has expired or is not yet valid | 03:40 |
|---|---|---|
| niemeyer | andrewsmedina: I get Object: <lp.registry.model.person.PersonSet object at 0xa787750>, name: u'+me:' | 03:52 |
| andrewsmedina | niemeyer: Im trying to send a proposal with lbox and returns this error | 03:59 |
| niemeyer | andrewsmedina: Ok, not sure then | 04:03 |
| niemeyer | andrewsmedina: Please ping me tomorrow if you still have the issue.. I really need some bed time now | 04:04 |
| rogpeppe | davecheney: yo! | 06:35 |
| davecheney | rogpeppe: howdy | 06:36 |
| davecheney | you've got some commits to make my man | 06:36 |
| rogpeppe | brilliant | 06:36 |
| davecheney | gustavo green lighted a heap of branches overnight | 06:36 |
| davecheney | I would also be very keen to hear your feedback on my proposal for the provisioning agent | 06:37 |
| rogpeppe | davecheney: i only see one actually, but maybe i'm missing something | 06:38 |
| davecheney | rogpeppe: the ConfigNode one got the tick | 06:38 |
| davecheney | what about upload-tools ? | 06:38 |
| rogpeppe | davecheney: i already submitted the confignode one | 06:38 |
| davecheney | ok | 06:39 |
| rogpeppe | davecheney: i'm interested in feedback on https://codereview.appspot.com/6213050/ | 06:39 |
| * davecheney looks | 06:39 | |
| rogpeppe | davecheney: any particular reason that ProviderService is an interface? | 06:50 |
| davecheney | So I can mock it | 06:50 |
| davecheney | you could make an argument either way | 06:50 |
| davecheney | it's still a wip | 06:50 |
| rogpeppe | davecheney: i'm wondering if there's a need to mock it when we can mock the state itself. | 06:51 |
| davecheney | rogpeppe: indeed, there are probably other ways to do it | 06:51 |
| davecheney | rogpeppe: but putting that to one side, do you have any comments on the use of the an internal goroutine which insulates callers from the environ reloading ? | 06:56 |
| rogpeppe | davecheney: i think it looks good. | 06:56 |
| rogpeppe | davecheney: although i'm still mulling over the implications | 06:56 |
| davecheney | understood | 06:56 |
| davecheney | rogpeppe: when I sat down yesterday and realised I had two loops of control going on at once; the machines watcher and the environ watcher | 06:57 |
| davecheney | it appeared simpler to model it this way | 06:57 |
| davecheney | there are also interesting possibilities to introduce paralism | 06:58 |
| davecheney | rogpeppe: also, rewriting machine watcher (again), https://codereview.appspot.com/6210066/ | 06:59 |
| rogpeppe | davecheney: i guess i'm slightly surprised that the machines watcher doesn't just watch the environs config too | 07:00 |
| rogpeppe | davecheney: it looks like you've still got two loops of control going on | 07:00 |
| rogpeppe | davecheney: although i may misunderstand how AddMachine etc are intended to be used. | 07:01 |
| davecheney | rogpeppe: s/AddMachine/StartInstance/g, s/RemoveMachine/StopInstance/g | 07:01 |
| davecheney | I should have used better names | 07:01 |
| rogpeppe | davecheney: i don't think that affects the point though. who's calling those methods? | 07:02 |
| davecheney | rogpeppe: provisioning.go | 07:02 |
| davecheney | rogpeppe: it also just occured to me, why don't I just implement the environs.Envrion interface | 07:03 |
| rogpeppe | davecheney: we've got dummy for that, perhaps. | 07:03 |
| davecheney | the goal is to buffer callers to those methods from having to deal wit the fact the environ is not ready/available | 07:03 |
| rogpeppe | davecheney: that's only right at the start though, yes? | 07:03 |
| rogpeppe | davecheney: can we do anything at all until that happens, in fact? | 07:04 |
| davecheney | rogpeppe: hmm, the way gustavo explained it, we have to deal with the fact that environ can change at any time | 07:06 |
| rogpeppe | davecheney: that's no problem i think. i'll paste a little pseudo code to try and explain what i'm thinking. | 07:07 |
| davecheney | kk | 07:07 |
| rogpeppe | davecheney: http://paste.ubuntu.com/993735/ | 07:11 |
| rogpeppe | davecheney: as a very rough sketch | 07:11 |
| davecheney | rogpeppe: yup, that is what I had first | 07:11 |
| rogpeppe | davecheney: so where's the other loop of control? | 07:11 |
| davecheney | so, what happens if case e := <-envWatcher: env = e | 07:12 |
| davecheney | fires, and the env is now broken or nil | 07:12 |
| davecheney | also, once c := <-configWatcher has fired, we need to keep trying that action until it succeeds, or the process exits | 07:13 |
| davecheney | so, if e is broken, then we need to put c somewhere, then come back to it when e is not broken | 07:13 |
| rogpeppe | davecheney: two possibilities: either you loop inside that arm of the select when env is broken, until it's not; or you introduce another goroutine so that only valid environments are send on the env watch channel | 07:14 |
| davecheney | rogpeppe: I think i've implemented the latter | 07:14 |
| davecheney | rogpeppe: but sort of inside out | 07:15 |
| rogpeppe | davecheney: yeah | 07:15 |
| rogpeppe | davecheney: i *think* things would be clearer (and probably smaller) if the extra goroutine *just* did that - another component in the pipeline, with no side effects. | 07:15 |
| davecheney | rogpeppe: hmm, i do like simplicity | 07:16 |
| davecheney | and it would resolve the requirement to have two stages, waiting for the first environ, then acting on changes | 07:16 |
| davecheney | rogpeppe: you are right, that is a lot simpler | 07:17 |
| rogpeppe | davecheney: we have to decide if having an invalid environ should cause the provisioning agent to stop until it's valid, or continue with the old, valid environ | 07:17 |
| davecheney | rogpeppe: that could be the blocker | 07:17 |
| rogpeppe | davecheney: my problem with the current proposal is that there are really two loci of control, and i think that's awkward. | 07:17 |
| rogpeppe | davecheney: both are possible, i think, and not hard. | 07:17 |
| rogpeppe | davecheney: we just have to decide what semantic we actually want | 07:18 |
| davecheney | rogpeppe: in your env <- channel approach, you always have _an_ environ; but there is no way to give it a broken one | 07:18 |
| davecheney | in my approach, you always hold a proxy environ, which may block calls through it if the undernlying environ is invalid | 07:18 |
| rogpeppe | davecheney: in that case, you choose the first approach i mentioned | 07:18 |
| rogpeppe | davecheney: "loop inside that arm of the select when env is broken, until it's not" | 07:19 |
| davecheney | rogpeppe: i need to ponder this | 07:19 |
| rogpeppe | davecheney: that automatically excludes the other part of the select from acting on it. | 07:19 |
| davecheney | i like your approach, it's less code and clearer | 07:19 |
| rogpeppe | davecheney: cool. | 07:20 |
| davecheney | rogpeppe: i guess it comes down to 'what is broken' | 07:21 |
| rogpeppe | davecheney: yes - and "what do we want to do about that?" | 07:21 |
| davecheney | i see there are two kinds of broken, one is missing key fields, basically unyaml'ing "" | 07:21 |
| davecheney | the other is valid, but incorrect, so incorrect AWS credentials | 07:22 |
| davecheney | which I don't think is invalid, tf/ it shuld be passed to the provisioning agent, and provisioning attempted against it | 07:22 |
| rogpeppe | davecheney: yeah. so the first *should* never happen. a goroutine filtering out those occurrences and logging them would probably be fine. | 07:23 |
| davecheney | rogpeppe: i think it's the opposite | 07:23 |
| davecheney | the first will always happen | 07:23 |
| rogpeppe | davecheney: agreed. i don't think you can tell otherwise. | 07:23 |
| rogpeppe | davecheney: really? | 07:23 |
| davecheney | when the provisioning agent starts up, /environment is "" | 07:23 |
| rogpeppe | yes, but that's a special case at the start, which we cater for specifically | 07:24 |
| davecheney | it has to wait until it gets a config node that is properly formed | 07:24 |
| rogpeppe | we wait until that time has passed before entering the provisioning loop proper | 07:24 |
| rogpeppe | what about when we're *in* the loop? | 07:24 |
| rogpeppe | i don't *think* we should see it then | 07:24 |
| rogpeppe | unless something else fucks up | 07:25 |
| rogpeppe | davecheney: BTW what happened to our idea of having a goroutine per machine? | 07:26 |
| davecheney | rogpeppe: kinda fell in a heap when I understood that environment could change over time | 07:27 |
| rogpeppe | davecheney: hmm. i *wonder*... we could just model the environ as a global variable, guarded by an RWMutex. | 07:28 |
| davecheney | rogpeppe: that is what I was aiming for with the ProviderService | 07:28 |
| davecheney | by communicating with it via a channel, it has a mutex of sorts | 07:28 |
| davecheney | it only accepts your commands when it's in a state to act on them | 07:28 |
| davecheney | otherwise they block | 07:29 |
| * rogpeppe thinks | 07:30 | |
| rogpeppe | davecheney: thing is, if we want any concurrency at all, when the environment changes, there are still going to be actions acting on the old environment. | 07:33 |
| davecheney | rogpeppe: i agree | 07:34 |
| rogpeppe | davecheney: which i think is ok. we just want to make sure that any new actions use the new environment. | 07:34 |
| davecheney | rogpeppe: so actions on the Environ are going to fail, and should be retried (via some business logic) | 07:34 |
| davecheney | so the key will be they can pick up the new value of Environ | 07:35 |
| davecheney | rogpeppe: which sort of leans me back to my original proposal this morning | 07:35 |
| rogpeppe | davecheney: exactly - we need to distribute the new Environ to everyone | 07:35 |
| davecheney | 'except i'll make it implment a full proxy Environ, so you can just keep retrying against the proxy. | 07:35 |
| rogpeppe | davecheney: i think it's quite a lot of code for something that's really just a mutexed global variable at heart. | 07:36 |
| rogpeppe | davecheney: and if you do it that way, we can keep the original vision of having a separate goroutine for each machine, right at the heart of the provisioning agent. | 07:38 |
| davecheney | rogpeppe: here is a quick stab at your version, http://paste.ubuntu.com/993760/ | 07:38 |
| davecheney | rogpeppe: yes! so each 'machine' proxy has a channel for commands, provision yourself, deprovision yourself | 07:39 |
| davecheney | and those commands talk to the Environ proxy | 07:39 |
| rogpeppe | davecheney: yeah | 07:39 |
| davecheney | and they retry according to some business logic | 07:40 |
| davecheney | that would solve one of my concerns about running adds and deletes in parallel | 07:40 |
| rogpeppe | davecheney: yeah | 07:40 |
| davecheney | this has been very useful | 07:40 |
| rogpeppe | davecheney: great! | 07:40 |
| davecheney | unfortuntely i'm going out in 20 minutes | 07:40 |
| davecheney | but i'll hack on this when I get home | 07:41 |
| rogpeppe | davecheney: np, i'm glad i got up early... | 07:41 |
| davecheney | what time is it in +1 over there ? | 07:41 |
| davecheney | it's 17:40 | 07:41 |
| rogpeppe | davecheney: 0841 | 07:41 |
| davecheney | right | 07:42 |
| rogpeppe | davecheney: thanks for the comments on the simplified provider interface, BTW | 07:43 |
| davecheney | rogpeppe: i think i attempted a half assed version of that when I did environ.NewEnviron, but ended up backing out most of it | 07:43 |
| rogpeppe | davecheney: it seems to mesh well. and i think the overall line count probably dropped, which is always a good sign... | 07:44 |
| davecheney | never hurts | 07:45 |
| rogpeppe | davecheney: i like the fact that Check now matches NewEnviron. and when we have Marshal, that'll return the same type too. | 07:46 |
| davecheney | rogpeppe: now that is good, and less untyped interface{}'s | 07:48 |
| rogpeppe | davecheney: defo | 07:48 |
| rogpeppe | davecheney: BTW in the provisioning agent, i *think* you'll only want one channel to the machine goroutine - to remove the machine. | 07:51 |
| davecheney | rogpeppe: yeah, i'll be doing some surgery on that tomorrow | 07:51 |
| davecheney | but for now, it's good night from me | 07:51 |
| rogpeppe | davecheney: have a good one! | 07:51 |
| rogpeppe | fwereade: ping | 10:18 |
| fwereade | rogpeppe, pong | 10:21 |
| rogpeppe | fwereade: hiya | 10:21 |
| fwereade | rogpeppe, (landing stuff doesn't count as working :p) | 10:21 |
| fwereade | rogpeppe, heyhey | 10:21 |
| rogpeppe | ? | 10:21 |
| fwereade | rogpeppe, but I am actually about to stop ;p | 10:21 |
| rogpeppe | ah... | 10:21 |
| fwereade | rogpeppe, I'm off until weds now :0 | 10:21 |
| rogpeppe | cool | 10:21 |
| rogpeppe | fwereade: just wondered if you could clarify about the machine key stuff, but don't worry if you're stopping | 10:22 |
| fwereade | rogpeppe, regardless, what can I do for you while I'm here? | 10:22 |
| fwereade | rogpeppe, it's just a vague sense that the correspondence between keys and ids feel coincidental rather than fundamental | 10:22 |
| rogpeppe | fwereade: what is a machine key? | 10:22 |
| rogpeppe | fwereade: i know about machine ids and instance ids | 10:22 |
| rogpeppe | but not machine keys... | 10:23 |
| fwereade | rogpeppe, it's the node name in zookeeper | 10:23 |
| fwereade | rogpeppe, machine-0000000001 | 10:23 |
| rogpeppe | fwereade: and that's not named after the machine id? | 10:23 |
| fwereade | rogpeppe, it feels to me that that's an accident of happenstance rather than a fundamental truth | 10:24 |
| rogpeppe | fwereade: it's not always fmt.Sprintf("machine-%010d", machine.Id) ? | 10:24 |
| rogpeppe | fwereade: what's primary? | 10:24 |
| rogpeppe | fwereade: we talk about machine id 0 for the bootstrap machine, for example | 10:24 |
| fwereade | rogpeppe, I guess it's just an idea that juju ids *ought* to increase "smoothly" rather than just monotonically | 10:25 |
| rogpeppe | fwereade: what's the difference? | 10:25 |
| fwereade | rogpeppe, just that the fact that we can end up skipping an id that's held by an orphan node has the feel of a leaked implementation detail | 10:25 |
| rogpeppe | fwereade: when are we going to add more than 1 to the new machine id? | 10:26 |
| rogpeppe | ah | 10:26 |
| fwereade | rogpeppe, and that the platonic ideal of juju would have machines 0-N without skipping any | 10:26 |
| rogpeppe | fwereade: when do we get an orphan node? | 10:26 |
| fwereade | rogpeppe, when something bad happens after the node has been created but before the topology is updated | 10:26 |
| rogpeppe | "something bad"? | 10:26 |
| fwereade | rogpeppe, someone trips over a network cable, say | 10:27 |
| fwereade | rogpeppe, this is not something I'm strongly invested in though | 10:28 |
| fwereade | rogpeppe, I think I'm -0 rather than -1 | 10:28 |
| rogpeppe | fwereade: i'm slightly surprised that the node is created *before* the topology is changed. | 10:28 |
| fwereade | rogpeppe, the topology needs to know which node it's pointing to | 10:28 |
| rogpeppe | fwereade: that doesn't square with my understanding of the way things work, but that's fairly sketchy! | 10:28 |
| fwereade | rogpeppe, if we update the topology first, we can't guarantee what the next sequence node will be | 10:29 |
| rogpeppe | fwereade: the topology doesn't just talk about "machine 0", "machine 1", etc? | 10:29 |
| fwereade | rogpeppe, I'm pretty sure it knows which keys it's pointing to, but I could be on crack | 10:30 |
| rogpeppe | fwereade: so the machine-000001 node name can skip numbers, but not the machine id, right? | 10:30 |
| fwereade | rogpeppe, coincidentally they do always correspond IIRC | 10:30 |
| rogpeppe | fwereade: what about orphans? | 10:30 |
| fwereade | rogpeppe, they're just trash | 10:30 |
| fwereade | rogpeppe, they don't exist according to the topology, which is the sole source of truth | 10:31 |
| rogpeppe | fwereade: what are they named? | 10:31 |
| fwereade | rogpeppe, they would, I think, be named after the key; but they don't exist so the question is philosophically shaky ;) | 10:31 |
| rogpeppe | fwereade: i'll try to explain what i think i understand, and perhaps you can tell me if i'm more-or-less right | 10:31 |
| rogpeppe | 1) someone calls add-unit | 10:31 |
| rogpeppe | 2) the client adds a machine node to the state | 10:32 |
| rogpeppe | 3) the client adds a topology node referencing the new machine node | 10:32 |
| fwereade | rogpeppe, I think so, yeah | 10:32 |
| rogpeppe | 4) the provisioning agent sees the change to the topology node and starts a new instance | 10:32 |
| fwereade | rogpeppe, exactly | 10:33 |
| rogpeppe | 5) the new machine registers that it's up in its machine node. | 10:33 |
| rogpeppe | so the problem with orphan nodes happens if the network breaks between 2) and 3) | 10:33 |
| fwereade | rogpeppe, probably, I forget the details of the machine agent; I think it has a separate presence node | 10:34 |
| fwereade | rogpeppe, yeah | 10:34 |
| fwereade | rogpeppe, sorry: but lunch is on the table | 10:34 |
| rogpeppe | fwereade: ok | 10:34 |
| rogpeppe | fwereade: one last question to ponder: | 10:34 |
| fwereade | rogpeppe, may have a moment before I leave later but don;t count on it | 10:34 |
| * fwereade listens | 10:34 | |
| rogpeppe | fwereade: why doesn't the provisioning agent allocate the new machine node? | 10:34 |
| rogpeppe | fwereade: anyway, enjoy your time at home! go to lunch! (early lunch, BTW! i've just had breaky...) | 10:35 |
| fwereade | rogpeppe, I can't think of a good reason, that may be a nicer way to do it | 10:36 |
| fwereade | I'll think :) | 10:36 |
| fwereade | rogpeppe, train at proper lunchtime :) | 10:36 |
| fwereade | rogpeppe, cheers | 10:36 |
| rogpeppe | fwereade: ttfn | 10:36 |
| rogpeppe | there ought to be a word for the noise a branch makes when landing. | 11:23 |
| niemeyer | GOod morning all | 13:30 |
| rogpeppe | niemeyer: hiya! | 13:39 |
| rogpeppe | niemeyer: pretty quiet around here... | 13:39 |
| rogpeppe | niemeyer: thanks for okaying that huge branch BTW | 13:39 |
| niemeyer | rogpeppe: Yeah, quiet indeed | 13:46 |
| niemeyer | rogpeppe: Must be Friday :) | 13:46 |
| niemeyer | rogpeppe: I'm just sipping some chimarrão and going over the inbox for a moment | 13:46 |
| rogpeppe | niemeyer: fwereade's on hols. don't know about TheMue | 13:46 |
| niemeyer | mthaddon: Thanks for checking out that charm | 13:46 |
| niemeyer | rogpeppe: He said he'd be out too.. don't recall if he'd be back today or not | 13:47 |
| rogpeppe | niemeyer: i'm thinking about refactoring dummy a little | 13:47 |
| niemeyer | rogpeppe: I think it's fine for the moment.. | 13:47 |
| rogpeppe | niemeyer: i realised that i wanted it to serve urls (for the storage URL service) and it's awkwardly structured for that | 13:47 |
| niemeyer | rogpeppe: I'd prefer to keep pushing forward, and then get back later once we have some more use cases known | 13:48 |
| niemeyer | rogpeppe: Hmm | 13:48 |
| niemeyer | rogpeppe: What's the issue? | 13:48 |
| rogpeppe | niemeyer: the difficulty is that we now want two storage services from the same dummy environ | 13:49 |
| niemeyer | rogpeppe: How's that a problem? | 13:49 |
| rogpeppe | niemeyer: and the way environ is the same as storage doesn't work too well with that | 13:49 |
| niemeyer | rogpeppe: Ah, I see, yeah, might be good to have that fixed | 13:50 |
| rogpeppe | niemeyer: and i realised that really the environ shouldn't be recreated with every Environ.Open | 13:50 |
| rogpeppe | niemeyer: it should be shared, as part of state. | 13:50 |
| rogpeppe | niemeyer: so... | 13:50 |
| rogpeppe | niemeyer: that means that we can't take all the environ settings from the environ config (otherwise that gives too much precedence to the first one parsed) | 13:51 |
| rogpeppe | niemeyer: so... | 13:51 |
| niemeyer | rogpeppe: Hmm.. yeah, and it wasn't recreated..? | 13:51 |
| niemeyer | rogpeppe: That's what we had Reset for, right? | 13:51 |
| rogpeppe | niemeyer: i'm thinking that perhaps Reset should take an argument which asks for the kind of capabilities we want | 13:51 |
| niemeyer | rogpeppe: I don't think that's necessary | 13:51 |
| rogpeppe | niemeyer: so you can ask for a dummy env that mocks zookeeper, perhaps (in the future), or serves a storage web server, or has a required field in the config | 13:52 |
| rogpeppe | niemeyer: at the moment all those things are determined by the provider config, which seems slightly wrong. | 13:53 |
| niemeyer | rogpeppe: I don't think that's necessary.. config is passed onto Open.. mocking ZooKeeper is not on the table right now, and serving a storage web server may be done a single way | 13:53 |
| niemeyer | rogpeppe: There's really no great reason to increase the number of knobs there | 13:53 |
| niemeyer | rogpeppe: Why is it wrong ? dummy is a provider.. and you're talking about configuring it | 13:54 |
| niemeyer | rogpeppe: I'd like to make it simpler, not more complex | 13:54 |
| rogpeppe | niemeyer: because the configuration is shared; the configuration is used to connect to it, not create it. | 13:54 |
| rogpeppe | niemeyer: also, i was slightly hoping to avoid starting a new web server on every Reset. but i guess that's ok really. | 13:55 |
| rogpeppe | niemeyer: it currently seems slightly bogus that i require a zookeeper attribute on all dummy environ configs, just so i can check that starting an environment with a missing attribute fails correctly. | 13:57 |
| rogpeppe | [14:54:39] <rogpeppe> niemeyer: because the configuration is shared; the configuration is used to connect to it, not create it. | 13:58 |
| rogpeppe | that was badly said | 13:58 |
| rogpeppe | i meant "the environment is shared" | 13:58 |
| Aram | evening. | 14:18 |
| niemeyer | Aram: Heya | 14:19 |
| andrewsmedina | niemeyer: Hi | 14:20 |
| niemeyer | andrewsmedina: Yo | 14:39 |
| niemeyer | rogpeppe: Re. https://codereview.appspot.com/6203083/, did you discuss ideas with Dave this morning? | 14:43 |
| rogpeppe | niemeyer: yeah. we came up with something quite nice i think. | 14:44 |
| niemeyer | rogpeppe: That's great, thanks a lot | 14:44 |
| rogpeppe | niemeyer: i could paste the relevant log if you like | 14:44 |
| niemeyer | rogpeppe: I'll mark the branch as WIP | 14:44 |
| niemeyer | rogpeppe: I'm happy to wait for the result of it | 14:44 |
| rogpeppe | niemeyer: i think it should be marked as that anyway - at least that was his intention | 14:44 |
| rogpeppe | niemeyer: did you take a look at https://codereview.appspot.com/6213050/ ? | 14:45 |
| niemeyer | Ah, and so it is | 14:45 |
| rogpeppe | niemeyer: it's my "i have an idea" from the other evening | 14:45 |
| niemeyer | rogpeppe: Not yet.. it's the largest branch in the queue, so I've been reviewing the others first | 14:45 |
| rogpeppe | niemeyer: np | 14:45 |
| niemeyer | rogpeppe: But I'll get there | 14:46 |
| niemeyer | We should dial back the branch sizes.. yesterday most of them were over 400 lines | 14:46 |
| niemeyer | (of diff) | 14:46 |
| rogpeppe | niemeyer: BTW the tests are broken at the moment. i think william forgot to run tests before submitting... | 14:47 |
| niemeyer | rogpeppe: Cool, we should get a fix in soon | 14:47 |
| rogpeppe | niemeyer: i wanted to but the fix wasn't immediately obvious to me and i'm trying to get this stuff proposed. | 14:48 |
| rogpeppe | niemeyer: only problem is, in integrating the previous branches, i want to insert a branch before one i've already proposed... it's a pity that's not easy. i'll just not stack them, i think, and mark the last one as WIP | 14:48 |
| rogpeppe | niemeyer: some of the diffs are made larger by the fact that not everyone runs gofmt before proposing/submitting. | 14:51 |
| rogpeppe | niemeyer: some time it might be nice to make lbox fail if go files aren't gofmted. | 14:52 |
| niemeyer | rogpeppe: I generally try to make branches independent when pushing my own work | 14:53 |
| niemeyer | rogpeppe: Tends to pay off in these cases | 14:53 |
| rogpeppe | niemeyer: me too, but in this case, the reason i want to insert a branch is because i want to use some of that functionality in the upcoming branch, but don't want to bloat it. | 14:54 |
| niemeyer | rogpeppe: Well, in that case there's no choice.. just propose the branch and put the follow up as WIP or repropose with pre-req | 14:54 |
| rogpeppe | niemeyer: can't change the prereq once proposed, sadly | 14:55 |
| rogpeppe | i think | 14:55 |
| rogpeppe | i'll just wait until the prereq is submitted | 14:55 |
| niemeyer | Cool | 15:04 |
| niemeyer | Lunch! | 15:14 |
| rogpeppe | niemeyer: here's the prereq: https://codereview.appspot.com/6209078/ | 16:47 |
| niemeyer | rogpeppe: Checking | 16:49 |
| rogpeppe | niemeyer: it's time for me to go; have a great weekend! | 17:02 |
| niemeyer | rogpeppe: For you as well.. almost finishing the review | 17:03 |
| rogpeppe | niemeyer: great, thanks a lot | 17:03 |
| hazmat | rogpeppe, have a good one | 17:03 |
| rogpeppe | hazmat: and you. you still up for that editor challenge BTW? :-) | 17:05 |
| hazmat | rogpeppe, anytime! :-) | 17:06 |
| rogpeppe | hazmat: alright, i'll see how much sublime costs and whether i can deal with it... | 17:07 |
| * hazmat wonders if he should start recruiting some ringers for the challenge | 17:07 | |
| hazmat | rogpeppe, its free to try out | 17:07 |
| rogpeppe | hazmat: ringers? | 17:07 |
| hazmat | rogpeppe, experts posing as novices | 17:07 |
| hazmat | rogpeppe, so wait.. i have to learn acme then? | 17:08 |
| hazmat | :-) | 17:08 |
| rogpeppe | hazmat: that's the deal | 17:08 |
| * hazmat forget the challenge details | 17:08 | |
| rogpeppe | hazmat: acme exclusively for a month | 17:08 |
| rogpeppe | hazmat: well, apart from when it's not possible | 17:08 |
| hazmat | rogpeppe, not this month then | 17:08 |
| hazmat | rogpeppe, incidentally how do you install it? | 17:08 |
| rogpeppe | hazmat: grab the plan9port tarball, run INSTALL | 17:09 |
| hazmat | rogpeppe, cool thanks | 17:10 |
| hazmat | rogpeppe, yeah.. i'm under some tight deadlines, so not this month, but i'm game | 17:10 |
| rogpeppe | hazmat: i am too (he says, worried about dropping productivity :-]) | 17:11 |
| rogpeppe | http://swtch.com/plan9port/plan9port.tgz | 17:11 |
| rogpeppe | anyway, gotta go | 17:11 |
| andrewsmedina | niemeyer: I still could not send the proposal | 17:33 |
| niemeyer | andrewsmedina: Ok, let's see then | 17:33 |
| niemeyer | andrewsmedina: What's going on? | 17:33 |
| andrewsmedina | niemeyer: http://dpaste.org/XKeHn/ | 17:39 |
| niemeyer | andrewsmedina: Try to load https://api.launchpad.net/ in your browser | 17:42 |
| niemeyer | andrewsmedina: What OS and OS version are you using? | 17:42 |
| andrewsmedina | niemeyer: ubuntu and centos | 17:42 |
| niemeyer | andrewsmedina: At the same time!? :-) | 17:42 |
| andrewsmedina | niemeyer: yes, with vms :) | 17:43 |
| niemeyer | andrewsmedina: I mean where is this command failing | 17:43 |
| niemeyer | andrewsmedina: On both? | 17:44 |
| andrewsmedina | niemeyer: I tryed do a wget http://paste.ubuntu.com/ | 17:44 |
| andrewsmedina | niemeyer: I tried on ubuntu and centos | 17:44 |
| andrewsmedina | ubuntu 12.04 | 17:44 |
| niemeyer | andrewsmedina: Ok, that's pretty weird | 17:44 |
| niemeyer | andrewsmedina: Are you under a proxy? | 17:45 |
| niemeyer | andrewsmedina: Could the proxy be getting in the way of the https connection? | 17:45 |
| andrewsmedina | niemeyer: I dont use proxy here | 17:46 |
| niemeyer | andrewsmedina: Wow, do you develop as root? | 17:46 |
| andrewsmedina | niemeyer: :-p | 17:47 |
| niemeyer | andrewsmedina: Can you see my look of disapproval from there? ;-) | 17:47 |
| andrewsmedina | niemeyer: I use "andrezias" user to (on ubuntu). But in centos I use root :-p | 17:48 |
| niemeyer | andrewsmedina: Can you please try to wget from https://api.launchpad.net/devel/branches? | 17:48 |
| niemeyer | andrewsmedina: Tsc tsc :) | 17:48 |
| andrewsmedina | niemeyer: same result | 17:50 |
| andrewsmedina | http://paste.ubuntu.com/994583/ | 17:50 |
| niemeyer | andrewsmedina: Sounds like you have a bad set of certs | 17:55 |
| niemeyer | andrewsmedina: Have you tried to update your installation? | 17:55 |
| andrewsmedina | niemeyer: installation of? | 17:58 |
| niemeyer | andrewsmedina: Of your OS | 18:01 |
| andrewsmedina | why? how so version can affect the launchpad certs? | 18:03 |
| andrewsmedina | so == OS :p | 18:04 |
| niemeyer | andrewsmedina: The certificates that are used to verify the validity of a given site certificate are installed in your disk | 18:15 |
| andrewsmedina | niemeyer: humm.. my vms are headless | 18:16 |
| andrewsmedina | but I already used lbox another times without problem | 18:17 |
| niemeyer | andrewsmedina: Why is it an issue that your vms are headless? | 18:18 |
| andrewsmedina | niemeyer: when lpad tell do aprove the req I opened it on my mac os ( :-p ) | 18:25 |
| niemeyer | andrewsmedina: This is irrelevant for the problem.. the certificates within the vms must work too | 18:25 |
| andrewsmedina | niemeyer: you're right | 18:28 |
| * hazmat lunches bbiab | 18:43 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!