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