[04:36] <_mup_> juju/expose-refactor r411 committed by jim.baker@canonical.com [04:36] <_mup_> Refactored tests for firewall mgmt to break dependence on provisioning agent [04:40] <_mup_> juju/expose-refactor r412 committed by jim.baker@canonical.com [04:40] <_mup_> Added missing files from commit and removed debugging [10:19] <_mup_> Bug #882492 was filed: initial juju package. < https://launchpad.net/bugs/882492 > [14:07] hi [15:19] rog: Can you please resubmit the merge proposal against the proper target (lp:juju/go)? [15:19] ah, i just went with what lbox propose did [15:19] hmm, i wonder why it chose lp:juju [15:20] rog: Because that's the default project series [15:20] rog: You can use -for lp:juju/go [15:20] rog: With lbox [15:20] rog: You'll also need -bug N [15:21] rog: (to reuse the bug already opened) [15:23] niemeyer: https://code.launchpad.net/~rogpeppe/juju/go-initial-juju/+merge/80580 [15:24] rog: Cheers! [15:25] rog: As a minor, the description is also a bit cryptic, even more considering it goes into a bug as well [15:25] rog: Note the lack of context: https://bugs.launchpad.net/juju/+bug/882492 [15:25] rog: I'll handle this one [15:25] niemeyer: so what should the bug be? "There is no juju package." [15:25] rog: Go port must handle environments.yaml [15:26] rog: Just changed [15:26] i always find it a bit strange that it's all "bugs" and not "issues" [15:26] rog: You can mentally translate it to your preferred term :) [15:26] yeah, but it's the mind set of "there's a problem"... which there isn't! [15:26] rog: I personally prefer "ticket" [15:27] yeah. that's better. it seems weird that every feature change has to create a "bug". [15:29] rog: We're creating our own process on top of the existing infrastructure.. certain trade offs are inevitable [15:30] niemeyer: ah, i thought it was designed this way [15:30] rog: No.. our kanban view benefits from some additional associations [15:30] rog: So we enforce those [15:31] rog: The kanban is something Jamu wrote for Landscape originally, and extracts data via the API [15:31] niemeyer: i hadn't heard of kanban [15:31] rog: http://j.mp/juju-florence? [15:31] that's a kanban? [15:32] rog: http://en.wikipedia.org/wiki/Kanban [15:33] rog: http://leankitkanban.com/ [15:33] rog: It's inspired in those concepts [15:33] ok, i'll have a look [15:34] columns ordered by priority - is there more to it than that? [15:37] rog: These web sites contain more details than I could explain [15:37] * rog has to go and buy a birthday card [15:41] rog: I thought we had talked about Bootstrap and Destroy in Conn already [15:42] rog: Or I guess I misunderstand the terminology used there [15:42] rog: There are three different terms: conns, provider, and environ.. what's what? [15:43] a conn is what juju layers on top of an environ [15:43] rog: 485 +func (dummyProvider) NewEnviron(name string, attributes interface{}) (e juju.Environ, err os.Error) { [15:43] 486 + cfg := attributes.(schema.MapType) [15:43] 487 + return &dummyConn{ [15:43] rog: let's please compact these terms a bit more as we talked the last time [15:44] hmm, it should be named dummyEnviron there indeed [15:45] what should i call Conn, though. it will have state in the future. all the stuff that juju knows about that the environs do not [15:45] s/\./?/ [15:45] rog: Look at the existing code [15:46] rog: Also, please keep up with the existing convention for gocheck: [15:46] + C "launchpad.net/gocheck" [15:46] * rog hates importing to . [15:46] and i think it's unnecessary [15:46] rog: Sorry about that, but we'll need to listen to each other a bit more if we want to work together on this. [15:47] rog: We have existing code there using a convention [15:47] rog: and that convention is used in every single gocheck package [15:47] rog: Because that's how it has been built [15:47] rog: Just telling me you hate my convention won't make things easier [15:47] the reason seems to be entirely one of convenience. [15:48] i will change it. but i won't like it :-) [15:48] rog: I hope you like consistency. [15:48] the go authors have considered removing import ".", BTW [15:48] they might even do it some time [15:49] rog: Oh yeah, I bet [15:49] yeah, i'd prefer if everything was made consistent to avoid importing . :-) when looking at a gocheck package, i can never remember exactly which identifiers gocheck brings in [17:11] How would I expose port 59999 with Juju using hadoop-master charm? [18:53] rog: ping [18:54] niemeyer: hi [18:54] rog: Yo [18:54] rog: Just an early note before you live, the branch looks very good so far [18:54] rog: Some very minor comments, but awesome otherwise [18:54] i'm glad [18:55] rog: Still haven't finished, but running through it as I can [18:55] s/glad/so glad/ :-) [18:55] Conn ok? [18:56] rog: I think Conn is Environ [18:57] niemeyer: then what's Environ? :-) [18:57] rog: I haven't finished the review yet, as I pointed out, but it feels like they're both the same thing so far [18:58] rog: It's creating a new Environ just to embed in a Conn [18:58] rog: and Conn has Bootstrap and Destroy commands, which as we already talked should be in the Environ interface [18:59] niemeyer: the difference, as i envision it, is that Conn gets all the juju methods that the individual providers don't implement, e.g. Deploy, AddRelation, etc etc [18:59] rog: That's not how it works today.. we're reimplementing the existing system, rather than doing a complete new architecture from the ground up [19:00] rog: There is a well established model [19:00] rog: If we're changing it, I want to see a full fledged proposal that covers it all [19:00] rog: Rather than lose bits [19:00] rog: Otherwise we'll face new issues with the new design, and will not meet in the end [19:00] erm, i'm trying quite hard not to change it fundamentally. it's just moving things around as warranted (i think!) by the different Go package model [19:01] rog: Not in that case.. you picked two arbitrary methods out of the Environ interface [19:01] so the Conn gets the stuff that lived in control... (i think - i'll just go and have another look) [19:02] rog: control is the command line stuff [19:02] rog: destroy_environment lives in the MachineProvider interface today, which is Environ [19:02] rog: We're not going to change these interfaces without a good reason to do so, which should cover the whole application and be talked about [19:03] rog: We had already talked about that. [19:03] ok, that's exactly why i'm putting out this merge request [19:03] because it's a concrete thing we can talk about [19:03] rather than me waving my hands a lot! [19:04] rog: That's not how it works.. even more considering we had _already_ talked about this [19:04] i don't think you mentioned this aspect before [19:04] or at least if you did, i didn't understand [19:04] which is entirely possible [19:04] Oct 13 13:56:39 We cannot fight over details like this rog.. an Environ needs a Destroy method on its interface. There's zero doubts about that. [19:04] Oct 13 13:56:54 oh, definitely! [19:05] erm, Environ *does* have a Destroy method [19:05] doesn't it? [19:06] checked. yes, it does [19:06] rog: So what is this method about? [19:06] which method? [19:06] *Destroy* [19:06] the Destroy on Conn just calls the Destroy on the underlying Environ [19:06] rog: Ok.. why? [19:07] most users will never need to know about Environ [19:07] rog: Ok.. why? [19:07] because Environ does the low level stuff [19:07] Conn does all the actual juju stuff [19:07] Environ is the foundation on which juju lives [19:07] rog: There's no Conn today.. and the Conn in your proposed branch does nothing. [19:07] rog: Let's please get rid of it until we find a reason for it to exist. [19:07] no, it's there as a placeholder [19:08] thinking about it, it's really Control [19:08] rog: Yeah.. that placeholder doesn't exist in the current code base, despite it working! [19:08] except i think Conn works better as a name in this context than Control [19:08] :-( [19:09] would it look ok to you if Conn was renamed Control ? [19:09] rog: Conn does nothing.. please remove it until we agree it's a needed concept. [19:10] ok [19:10] rog: Or.. make an actual proposal [19:11] rog: Otherwise you're alone trying to introduce a concept in the code that does absolutely nothing, does not exist in the existing implementation, and so makes no sense unfortunately [19:11] well, my actual proposal is that Conn (or Control) is where all the juju logic lives. i.e. all the shared code that we don't want to duplicate in each individual provider [19:11] rog: Ok, but by _actual_ proposal I mean, read the code, and tell me how existing ideas map into your model [19:11] at the moment a lot of it is done with a superclass (which we can't have) [19:11] rog: Because the existing model we have today works and is well understood [19:12] rog: You're talking about Control, for instance, which in the current code base is just command line tools, indicating there's a big disconnect [19:12] rog: I already explained this as well :-( [19:12] oh doh [19:12] i meant State [19:12] i think [19:12] hold on [19:13] yes, state. sorry. [19:14] rog: Ok, try this: [19:14] or ServiceStateManager to be more accurate [19:14] (in one case at least) [19:14] rog: grep destroy juju/state/*.py [19:14] rog: You see.. there's a huge disconnect [19:14] rog: Which is why I can't feel ok about the proposal so far [19:15] rog: I don't want to discourage you from proposing something by any means, but this isn't going in a good direction yet [19:15] ok. [19:16] rog: We may end up with juju.Conn, and I'm fine with it as long as we have an architectural plan that is clear and still feels like a good idea after mapping the ideas we have today into it [19:17] rog: Otherwise, the existing model is well known [19:17] niemeyer: Hi Gustavo. welcome back. Could you please give me any hint (URL) about the architectural documentation of the current juju and how far the go implementation has gone? [19:18] TheMue: Hey! [19:18] TheMue: Thanks! [19:19] TheMue: All the docs live at https://juju.ubuntu.com/docs [19:19] niemeyer: i'll send you an email with a brief description of how i see the current design [19:19] TheMue: There's a lot of architectural details there [19:19] TheMue: The Go port is still young [19:19] rog: Sounds good, thanks, and sorry for making things more painful than they may look to you [19:21] niemeyer: OK, I'll take a deeper look. I'm already working from my new Ubuntu notebook. [19:22] TheMue: Woohay! :) [19:24] niemeyer: It's great, and building a go release is extreme fast. *bigGrin* [19:37] niemeyer: email sent [19:41] niemeyer: does that make some sort of sense? [19:44] rog: It does.. responded, let me know [19:54] niemeyer: sent response. PTAL. [19:54] rog: Sounds good [19:55] rog: I mean, the plan sounds good [19:55] niemeyer: erm, which plan? [19:55] rog: Your email :) [19:55] niemeyer: it's done [19:55] rog: Cool [19:55] niemeyer: hence the "PTAL" [19:55] rog: Oh, ok [20:35] <_mup_> juju/expose-refactor r413 committed by jim.baker@canonical.com [20:35] <_mup_> PEP8, PyFlakes, docstrings [20:40] rog: Review delivered