| _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:36 |
| _mup_ | juju/expose-refactor r412 committed by jim.baker@canonical.com | 04:40 |
| _mup_ | Added missing files from commit and removed debugging | 04:40 |
| _mup_ | Bug #882492 was filed: initial juju package. <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/882492 > | 10:19 |
| Pau | hi | 14:07 |
| 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:19 |
| 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:20 |
| niemeyer | rog: (to reuse the bug already opened) | 15:21 |
| rog | niemeyer: https://code.launchpad.net/~rogpeppe/juju/go-initial-juju/+merge/80580 | 15:23 |
| niemeyer | rog: Cheers! | 15:24 |
| 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:25 |
| 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:26 |
| rog | yeah. that's better. it seems weird that every feature change has to create a "bug". | 15:27 |
| niemeyer | rog: We're creating our own process on top of the existing infrastructure.. certain trade offs are inevitable | 15:29 |
| 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:30 |
| 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:31 |
| niemeyer | rog: http://en.wikipedia.org/wiki/Kanban | 15:32 |
| 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:33 |
| rog | columns ordered by priority - is there more to it than that? | 15:34 |
| niemeyer | rog: These web sites contain more details than I could explain | 15:37 |
| * rog has to go and buy a birthday card | 15:37 | |
| niemeyer | rog: I thought we had talked about Bootstrap and Destroy in Conn already | 15:41 |
| 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:42 |
| 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:43 |
| rog | hmm, it should be named dummyEnviron there indeed | 15:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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 | 15:49 |
| evan_ | How would I expose port 59999 with Juju using hadoop-master charm? | 17:11 |
| niemeyer | rog: ping | 18:53 |
| 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:54 |
| 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:55 |
| niemeyer | rog: I think Conn is Environ | 18:56 |
| 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:57 |
| 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:58 |
| 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 | 18:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| rog | erm, Environ *does* have a Destroy method | 19:05 |
| rog | doesn't it? | 19:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| rog | ok | 19:10 |
| niemeyer | rog: Or.. make an actual proposal | 19:10 |
| 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:11 |
| 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:12 |
| rog | yes, state. sorry. | 19:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| niemeyer | TheMue: Hey! | 19:18 |
| niemeyer | TheMue: Thanks! | 19:18 |
| 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:19 |
| TheMue | niemeyer: OK, I'll take a deeper look. I'm already working from my new Ubuntu notebook. | 19:21 |
| niemeyer | TheMue: Woohay! :) | 19:22 |
| TheMue | niemeyer: It's great, and building a go release is extreme fast. *bigGrin* | 19:24 |
| rog | niemeyer: email sent | 19:37 |
| rog | niemeyer: does that make some sort of sense? | 19:41 |
| niemeyer | rog: It does.. responded, let me know | 19:44 |
| rog | niemeyer: sent response. PTAL. | 19:54 |
| niemeyer | rog: Sounds good | 19:54 |
| 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 | 19:55 |
| _mup_ | juju/expose-refactor r413 committed by jim.baker@canonical.com | 20:35 |
| _mup_ | PEP8, PyFlakes, docstrings | 20:35 |
| niemeyer | rog: Review delivered | 20:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!