_mup_juju/expose-refactor r411 committed by jim.baker@canonical.com04:36
_mup_Refactored tests for firewall mgmt to break dependence on provisioning agent04:36
_mup_juju/expose-refactor r412 committed by jim.baker@canonical.com04:40
_mup_Added missing files from commit and removed debugging04:40
_mup_Bug #882492 was filed: initial juju package. <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/882492 >10:19
niemeyerrog: Can you please resubmit the merge proposal against the proper target (lp:juju/go)?15:19
rogah, i just went with what lbox propose did15:19
roghmm, i wonder why it chose lp:juju15:19
niemeyerrog: Because that's the default project series15:20
niemeyerrog: You can use -for lp:juju/go15:20
niemeyerrog: With lbox15:20
niemeyerrog: You'll also need -bug N15:20
niemeyerrog: (to reuse the bug already opened)15:21
rogniemeyer: https://code.launchpad.net/~rogpeppe/juju/go-initial-juju/+merge/8058015:23
niemeyerrog: Cheers!15:24
niemeyerrog: As a minor, the description is also a bit cryptic, even more considering it goes into a bug as well15:25
niemeyerrog: Note the lack of context: https://bugs.launchpad.net/juju/+bug/88249215:25
niemeyerrog: I'll handle this one15:25
rogniemeyer: so what should the bug be? "There is no juju package."15:25
niemeyerrog: Go port must handle environments.yaml15:25
niemeyerrog: Just changed15:26
rogi always find it a bit strange that it's all "bugs" and not "issues"15:26
niemeyerrog: You can mentally translate it to your preferred term :)15:26
rogyeah, but it's the mind set of "there's a problem"... which there isn't!15:26
niemeyerrog: I personally prefer "ticket"15:26
rogyeah. that's better. it seems weird that every feature change has to create a "bug".15:27
niemeyerrog: We're creating our own process on top of the existing infrastructure.. certain trade offs are inevitable15:29
rogniemeyer: ah, i thought it was designed this way15:30
niemeyerrog: No.. our kanban view benefits from some additional associations15:30
niemeyerrog: So we enforce those15:30
niemeyerrog: The kanban is something Jamu wrote for Landscape originally, and extracts data via the API15:31
rogniemeyer: i hadn't heard of kanban15:31
niemeyerrog: http://j.mp/juju-florence?15:31
rogthat's a kanban?15:31
niemeyerrog: http://en.wikipedia.org/wiki/Kanban15:32
niemeyerrog: http://leankitkanban.com/15:33
niemeyerrog: It's inspired in those concepts15:33
rogok, i'll have a look15:33
rogcolumns ordered by priority - is there more to it than that?15:34
niemeyerrog: These web sites contain more details than I could explain15:37
* rog has to go and buy a birthday card15:37
niemeyerrog: I thought we had talked about Bootstrap and Destroy in Conn already15:41
niemeyerrog: Or I guess I misunderstand the terminology used there15:42
niemeyerrog: There are three different terms: conns, provider, and environ.. what's what?15:42
roga conn is what juju layers on top of an environ15:43
niemeyerrog: 485+func (dummyProvider) NewEnviron(name string, attributes interface{}) (e juju.Environ, err os.Error) {15:43
niemeyer486+cfg := attributes.(schema.MapType)15:43
niemeyer487+return &dummyConn{15:43
niemeyerrog: let's please compact these terms a bit more as we talked the last time15:43
roghmm, it should be named dummyEnviron there indeed15:44
rogwhat should i call Conn, though. it will have state in the future. all the stuff that juju knows about that the environs do not15:45
niemeyerrog: Look at the existing code15:45
niemeyerrog: Also, please keep up with the existing convention for gocheck:15:46
niemeyer+C "launchpad.net/gocheck"15:46
* rog hates importing to .15:46
rogand i think it's unnecessary15:46
niemeyerrog: Sorry about that, but we'll need to listen to each other a bit more if we want to work together on this.15:46
niemeyerrog: We have existing code there using a convention15:47
niemeyerrog: and that convention is used in every single gocheck package15:47
niemeyerrog: Because that's how it has been built15:47
niemeyerrog: Just telling me you hate my convention won't make things easier15:47
rogthe reason seems to be entirely one of convenience.15:47
rogi will change it. but i won't like it :-)15:48
niemeyerrog: I hope you like consistency.15:48
rogthe go authors have considered removing import ".", BTW15:48
rogthey might even do it some time15:48
niemeyerrog: Oh yeah, I bet15:49
rogyeah, 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 in15:49
evan_How would I expose port 59999 with Juju using hadoop-master charm?17:11
niemeyerrog: ping18:53
rogniemeyer: hi18:54
niemeyerrog: Yo18:54
niemeyerrog: Just an early note before you live, the branch looks very good so far18:54
niemeyerrog: Some very minor comments, but awesome otherwise18:54
rogi'm glad18:54
niemeyerrog: Still haven't finished, but running through it as I can18:55
rogs/glad/so glad/ :-)18:55
rogConn ok?18:55
niemeyerrog: I think Conn is Environ18:56
rogniemeyer: then what's Environ? :-)18:57
niemeyerrog: I haven't finished the review yet, as I pointed out, but it feels like they're both the same thing so far18:57
niemeyerrog: It's creating a new Environ just to embed in a Conn18:58
niemeyerrog: and Conn has Bootstrap and Destroy commands, which as we already talked should be in the Environ interface18:58
rogniemeyer: 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 etc18:59
niemeyerrog: That's not how it works today.. we're reimplementing the existing system, rather than doing a complete new architecture from the ground up18:59
niemeyerrog: There is a well established model19:00
niemeyerrog: If we're changing it, I want to see a full fledged proposal that covers it all19:00
niemeyerrog: Rather than lose bits19:00
niemeyerrog: Otherwise we'll face new issues with the new design, and will not meet in the end19:00
rogerm, 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 model19:00
niemeyerrog: Not in that case.. you picked two arbitrary methods out of the Environ interface19:01
rogso the Conn gets the stuff that lived in control... (i think - i'll just go and have another look)19:01
niemeyerrog: control is the command line stuff19:02
niemeyerrog: destroy_environment lives in the MachineProvider interface today, which is Environ19:02
niemeyerrog: We're not going to change these interfaces without a good reason to do so, which should cover the whole application and be talked about19:02
niemeyerrog: We had already talked about that.19:03
rogok, that's exactly why i'm putting out this merge request19:03
rogbecause it's a concrete thing we can talk about19:03
rograther than me waving my hands a lot!19:03
niemeyerrog: That's not how it works.. even more considering we had _already_ talked about this19:04
rogi don't think you mentioned this aspect before19:04
rogor at least if you did, i didn't understand19:04
rogwhich is entirely possible19:04
niemeyerOct 13 13:56:39 <niemeyer>      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
niemeyerOct 13 13:56:54 <rog>   oh, definitely!19:04
rogerm, Environ *does* have a Destroy method19:05
rogdoesn't it?19:05
rogchecked. yes, it does19:06
niemeyerrog: So what is this method about?19:06
rogwhich method?19:06
rogthe Destroy on Conn just calls the Destroy on the underlying Environ19:06
niemeyerrog: Ok.. why?19:06
rogmost users will never need to know about Environ19:07
niemeyerrog: Ok.. why?19:07
rogbecause Environ does the low level stuff19:07
rogConn does all the actual juju stuff19:07
rogEnviron is the foundation on which juju lives19:07
niemeyerrog: There's no Conn today.. and the Conn in your proposed branch does nothing.19:07
niemeyerrog: Let's please get rid of it until we find a reason for it to exist.19:07
rogno, it's there as a placeholder19:07
rogthinking about it, it's really Control19:08
niemeyerrog: Yeah.. that placeholder doesn't exist in the current code base, despite it working!19:08
rogexcept i think Conn works better as a name in this context than Control19:08
rogwould it look ok to you if Conn was renamed Control ?19:09
niemeyerrog: Conn does nothing.. please remove it until we agree it's a needed concept.19:09
niemeyerrog: Or.. make an actual proposal19:10
niemeyerrog: 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 unfortunately19:11
rogwell, 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 provider19:11
niemeyerrog: Ok, but by _actual_ proposal I mean, read the code, and tell me how existing ideas map into your model19:11
rogat the moment a lot of it is done with a superclass (which we can't have)19:11
niemeyerrog: Because the existing model we have today works and is well understood19:11
niemeyerrog: You're talking about Control, for instance, which in the current code base is just command line tools, indicating there's a big disconnect19:12
niemeyerrog: I already explained this as well :-(19:12
rogoh doh19:12
rogi meant State19:12
rogi think19:12
roghold on19:12
rogyes, state. sorry.19:13
niemeyerrog: Ok, try this:19:14
rogor ServiceStateManager to be more accurate19:14
rog(in one case at least)19:14
niemeyerrog: grep destroy juju/state/*.py19:14
niemeyerrog: You see.. there's a huge disconnect19:14
niemeyerrog: Which is why I can't feel ok about the proposal so far19:14
niemeyerrog: I don't want to discourage you from proposing something by any means, but this isn't going in a good direction yet19:15
niemeyerrog: 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 it19:16
niemeyerrog: Otherwise, the existing model is well known19:17
TheMueniemeyer: 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:17
niemeyerTheMue: Hey!19:18
niemeyerTheMue: Thanks!19:18
niemeyerTheMue: All the docs live at https://juju.ubuntu.com/docs19:19
rogniemeyer: i'll send you an email with a brief description of how i see the current design19:19
niemeyerTheMue: There's a lot of architectural details there19:19
niemeyerTheMue: The Go port is still young19:19
niemeyerrog: Sounds good, thanks, and sorry for making things more painful than they may look to you19:19
TheMueniemeyer: OK, I'll take a deeper look. I'm already working from my new Ubuntu notebook.19:21
niemeyerTheMue: Woohay! :)19:22
TheMueniemeyer: It's great, and building a go release is extreme fast. *bigGrin*19:24
rogniemeyer: email sent19:37
rogniemeyer: does that make some sort of sense?19:41
niemeyerrog: It does.. responded, let me know19:44
rogniemeyer: sent response. PTAL.19:54
niemeyerrog: Sounds good19:54
niemeyerrog: I mean, the plan sounds good19:55
rogniemeyer: erm, which plan?19:55
niemeyerrog: Your email :)19:55
rogniemeyer: it's done19:55
niemeyerrog: Cool19:55
rogniemeyer: hence the "PTAL"19:55
niemeyerrog: Oh, ok19:55
_mup_juju/expose-refactor r413 committed by jim.baker@canonical.com20:35
_mup_PEP8, PyFlakes, docstrings20:35
niemeyerrog: Review delivered20:40

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!