[08:55] mornin' [09:09] hi all [09:12] 'lo rog, koolhead11 [09:13] how are you mpl [09:17] fine enough, thank you. [09:27] Do anyone know if the juju openstack version have a webinterface for managing vm's? something like horizon? [09:28] sanderj: no it does not [09:29] :( [09:32] sanderj: horizon is too new and because of rapid development packaging it becomes difficult. am sure once Essex comes you will have it all :D [09:33] you promise koolhead11 ? ;-) [09:34] I thought dashboard is the openstack web management console? [09:42] koolhead11, will it be horizon which will be the userinterface? [09:51] sanderj, Horizon is the Web UI of choice for managing a private OpenStack cloud environment [09:52] there are alternatives though [09:52] that one is one of the projects under the OpenStack banner though [09:53] uksysadmin: +1 :D [09:54] I use Hybridfox under Firefox - nice way of managing multiple clouds (although there is no direct connection between your private and public cloud per se) [09:55] It isn't closely knitted to OpenStack though like Horizon - but functional enough if you manage a small private OpenStack cloud and a small amount of public instances [09:55] * koolhead11 smiles [09:56] I've tried to set up horizon, without luck. [09:56] it is a pain in the ass - in fact I've just posed a q in #openstack on the best way of installing it [09:56] Unable to log in, just get directed to some nova url [09:56] currently it seems the best way is manually through bzr [09:57] uksysadmin: horizon is back on bazar? [09:57] sanderj, iirc there is some issue with authentication - something to do with deprecated auth [09:57] I thought it always was, koolhead11 ? [09:58] uksysadmin: no they moved everything to github [09:58] ah - its in git - not bzr [09:58] uksysadmin: you have to select correct branch [09:58] :P [09:58] there's a fine art in selecting the correct branch [09:58] the point is that it shouldn't be hard [09:59] hmm, i am not touching horizaon now [09:59] waiting for essex [09:59] :P [10:00] yeah I gave up too [10:00] its good for showing demos to team leads and C level execs though - they expect nice interfaces [10:03] Yeah.. That's why I want it up and running.. [10:04] uksysadmin, in which component is it an issue with authentication? [10:05] There was something I needed to change in /etc/nova/api-paste.ini [10:05] see the NOTE sections [10:05] you need keystone running too [10:05] BUT - I've not looked at Horizon for a while [10:06] I got keystone running [10:07] which horizon branch should I select? [10:08] diablo/stable [10:12] is horizon sort of the middleware below dashboard? [10:13] :P [10:13] dashboard to horizon [10:13] TeTeT: no they have renamed [10:13] ah, thx koolhead11 [10:17] koolhead11, I choose nova trunk [10:17] We're not running diablo [10:23] Yo all! [10:24] hola niemeyer [10:24] sanderj: you can use the stackx code than [10:24] uksysadmin: is it called stackx or what [10:25] what's stackx? [10:26] uksysadmin: i think that bash script for rackers for one step install [10:26] thought this was a juju channel? bash scripts not needed! ;-) [10:43] niemeyer: hi! [10:44] rog: Hey! [10:44] rog: Good timing.. looking at cloudinit right now [10:45] niemeyer: cool. [10:45] niemeyer: if you could have a look at go-juju-ec2-operations that would be nice too... [10:47] rog: Yeah, I'll clean everything up today [10:48] niemeyer: BTW i'm not quite sure how i managed all.bash to appear twice [10:49] niemeyer: i muddled up something and confused lbox i think [10:49] rog: I was curious as well, but not a big deal [10:49] rog: submit works, btw [10:49] rog: Not sure if you've seen the announcement [10:50] niemeyer: yes. i'm just updating now. [10:53] niemeyer: BTW i think perhaps -prep=false should be -mail=false. i.e. the mail should only be done when you explicitly ask for it [10:53] rog: I think "lbox propose" should actually propose [10:54] niemeyer: lbox propose -cr -for x -mail [10:54] reads well to me [10:54] rog: It reads well, but "lbox propose" should actually propose [10:54] niemeyer: ... unless you use -prep ? [10:54] rog: Yep.. then you said "I'm just preparing for now" explicitly [10:55] niemeyer: in my workflow, i *always* prepare before mailing [10:55] rog: It's easier to code than lbox prepare-proposal [10:55] rog: That sounds fine [10:55] niemeyer: so it's nicer to have the default being the thing that doesn't do anything non-retractable [10:56] niemeyer: it's fine, i can always hack my local version :-) [10:56] rog: Your default and my default differ.. there's no way out.. [10:56] niemeyer: i guess i'm just used to the way that Go's "hg change" etc work [10:57] rog: Yeah, that's probably it [10:58] niemeyer: but i do think the principle of making the default action the least drastic is a good one in general. [11:01] rog: There's nothing drastic about making a propose command propose.. [11:02] niemeyer: sending mail can be drastic! [11:02] rog: You're going to the quotes page for that one :-) [11:03] niemeyer: in Go code reviews, the number of times i did "hg change" then "hg mail" immediately without another "hg upload" is pretty small [11:04] niemeyer: it's nice to see exactly *what* you're proposing before actually making the proposal [11:04] rog: That sounds completely fine. I'm not trying to change your workflow in any way. Please feel free to create local "rog-propose" commands. [11:05] fair 'nuff [11:06] rog: Many people review their changes before they commit locally, for instance. [11:06] niemeyer: i do that too, but there's nothing quite like seeing the final thing [11:07] niemeyer: (given the number of heuristics in lbox...) [11:07] rog: Piece by piece, creating change logs that show the evolution towards the solution. [11:11] niemeyer: i agree entirely. my remarks are about notifying people at the right moment, not hiding change logs. [11:12] rog: That's cool.. I'm not trying to convince you. Just explaining the other side of the picture. [11:12] rog: My key point is that "lbox propose" should propose. That's all. [11:12] * nijaba waves from rainy paris [11:13] nijaba: Hey man [11:15] SpamapS: marcoceppi: would love to get a review on my merge proposal for roundcube. Now with ssl cert copied via scp in peer relation [11:16] niemeyer: how are you doing? as you can see, I am thanking juju for giving me something to do while it's raining outside. [11:58] nijaba: Hah, neat :) [11:58] niemeyer: Pretty good here.. [11:58] nijaba: Pretty good here.. [11:59] nijaba: Trying to catch up after being away for a few days [11:59] rog: One review out [12:08] niemeyer: the comments of the form "// apt_update_upgrade" refer to the cloudinit file that the option was taken from. [12:09] niemeyer: they're there to facilitate cross-checking with the original source. [12:13] rog: Could you please send the dependency graph we spoke about to me? Thx. [12:15] TheMue: just looking for it... [12:16] TheMue: http://paste.ubuntu.com/768876/ [12:17] TheMue: it's a little idiosyncratic [12:17] TheMue: the script that generated it is at the top [12:18] rog: Ok, can you please drop the comments? [12:18] rog: now that you have the code? [12:18] rog: It doesn't make sense for a reader, and they'll likely be wrong in a bit, even if they are right today [12:20] TheMue: Thx, so the modules on the left depend on the modules right of them? [12:21] niemeyer: i'd like to drop them, but i fear that when i come back to add some more options, i won't remember which ones have been done. would it make more sense if they were file names (more obvious that they referred directly to the cloudinit source, which is organised in that particular modular way) [12:21] TheMue: yes [12:22] rog: The name of the option is in the Go code.. how would you forget? [12:23] TheMue: BTW if you want to massage the script (i built it up incrementally), you should know that "9 sed" refers to the plan9port version of sed, which understand egrep-style regexps [12:24] niemeyer: yeah, grep "option" should be sufficient, i guess [12:27] rog: Now that TheMue has some free cycles, it would be nice to get started on the state logic front [12:28] rog: I'm trying to recall the details of our conversation at UDS, but I don't have full clarity [12:28] rog: Maybe we can recover that conversation together [12:29] niemeyer: i don't remember that much either! [12:29] rog: So let's figure the approach again.. this time it should be easier [12:30] rog, TheMue: Google+? [12:30] niemeyer: hangout? [12:30] rog: Yeah [12:30] niemeyer: i'd like to quickly finish these updates to cloudinit, if that's ok [12:31] niemeyer: I would have to do some preparations before hangout. [12:31] rog: Ok, please ping when you're ready then [12:31] TheMue: Sounds good [12:32] rog: Btw, I think we should rename the juju directory/package to "environ" [12:32] niemeyer: i'm not sure. [12:32] rog: Everything in the repository is juju.. juju/go/juju is confusing, and incorrect [12:32] niemeyer: i think using "juju" as a package identifier works well [12:33] niemeyer: i think eventually it will be launchpad.net/juju [12:33] rog: It doesn't to me.. everything in there is juju [12:33] rog: Precisely.. it will be launchpad.net/juju/{log,charm,...} [12:34] rog: now we'll build state [12:34] niemeyer: yes, but this is the code environment, and in go code, seeing juju.EnvironProvider works well [12:34] rog: the things under the juju directory are about the environments [12:34] environ is a very generic name for a package [12:34] rog: Again.. it makes sense for _everything_ to be under juju. [12:34] niemeyer: i'd thought of that package as the way in for all the top level juju entry pointer [12:35] niemeyer: e.g. deploy, add unit, etc [12:35] juju.Log, juju.Charm, ... [12:35] juju.Log can be used like usual log. "charm" is sufficiently distinctive in itself [12:35] rog: environ too [12:35] rog: It's completely analogous [12:36] niemeyer: "environ" is a highly generic name, used in many places besides juju [12:36] and juju is nice and short [12:36] rog: it is.. juju.Charm is nice too :) [12:36] niemeyer: i think it makes sense to have at least one package with the "juju" identifier [12:37] rog: Heh [12:37] niemeyer: and given that this is the central place, why not this one? [12:39] I would like a package below "juju" for each major entity or service. Importing "launchpad.net/juju/envronment" seem ok for me. [12:39] Here the env gets its context by the containment in the juju package. [12:41] So, changed place and took headset [12:42] rog: I don't buy the "we _need_ a package with this name" argument [12:42] TheMue: in my plan, the juju package is not only about the environment, it's also about control of juju. [12:42] rog: That won't work.. we'll have a state package now, that is unrelated to the environment [12:43] rog: and that's where good part of the "control" will lie [12:43] rog: I would only place a juju command inside this package. [12:44] niemeyer: i was thinking (as we discussed before i think) that the juju package would encapsulate an API interface to the "control" commands [12:44] niemeyer: so you could do: e, err := juju.Open("myenviron"); e.Deploy("wordpress") [12:45] rog: I'm not sure.. that's exactly the conversation we're supposed to have [12:45] niemeyer: ah, i thought we were going to talk about the nitty-gritty of state updating [12:45] rog: That sounds interesting, but the bulk of the environments implementation do not have to be within a juju package [12:45] rog: and it is now [12:46] rog: I'm happy to have the juju package as the entry point [12:46] rog: That's not what it is today [12:46] niemeyer: ok. that depends on whether we manage to factor it out without circular dependencies. [12:47] rog: There's no reason to have circular dependencies if juju is only the entry point [12:48] Right now I don't see them too. [12:48] rog: But I guess we're in agreement.. I'm happy to have juju, and happy to have entry points there.. let's just move the bulk of the environment implementation in its own package under what we today have as go/ [12:48] rog: In the future, we move go/juju/* onto go/, and rename go/ to juju/ [12:49] juju as a starter, additionally there will be some foundation packages like environment or misc utilities and then the service packages [12:49] rog: Sounds good? [12:50] niemeyer: my reluctance, i think, is that there's hardly anything to the environ package. it's essentially just a couple of type definitions and a registry hook. [12:50] niemeyer: i don't know that it deserves its own package [12:51] rog: Check out the log package.. [12:51] niemeyer: that's different - it needs to be its own package to avoid circular dependencies [12:52] niemeyer: i'm not dead set against the idea, BTW. i'm just not sure about it. [12:53] rog: So you're happy to have a package named log with two functions, but don't want to have an environment-specific package with hundreds of lines and multiple subpackages? The reasoning is pretty weak. [12:54] I only can get it if I would say, juju IS our environment. [12:55] TheMue: Everything there is juju.. the "go/" thing in the path makes this point less clear, but it's there just because we can't own the main namespace today [12:55] From this point of view all environment logic for sure could be inside juju [12:56] TheMue: Again, everything is inside juju.. [12:56] niemeyer: I know, but the environment.yaml is the local starting point [12:56] TheMue: It's juju/charm, juju/log, juju/schema, etc [12:56] TheMue: This isn't clear because we have a go/ prefix in the way, but that's how the package is intended to be used for real [12:57] i guess i don't believe that just because something *can* be factored out means that it *should* be factored out [12:57] TheMue: I know, I only tryed to understand rogs motivation [12:57] rog: I'm not suggesting to factor anything out.. I'm saying the package is clearly misnamed. [12:57] But I'll stop arguing now and will do something more relevant [12:58] at the moment, because it's early stages, all there is in the juju package is the environment, so it looks like it's misnamed, i think. [12:58] niemeyer: Btw, what is schema? The juju environment schema? [12:58] TheMue: bzr branch lp:juju/go ls go/schema [12:58] TheMue: bzr branch lp:juju/go; ls go/schema [12:58] niemeyer: No, wrong question, I got it here. [12:59] niemeyer: I asked for the semantics, because w/o context schema is as meaningless as yaml or xml) as file extension. [12:59] rog: No, there's a lot in the juju package.. there's juju/schema, juju/log, juju/charm, juju/environs, juju/state, ... [13:00] niemeyer: So, which schema is schema? [13:00] niemeyer: aren't those all separate packages? [13:00] niemeyer: just as io/ioutil is a separate package to io [13:00] rog: I would say so, as I understand niemeyer [13:01] rog: Yes, they are, and each encapsulate a well defined part of the problem that juju solves. I'm fine with your idea of using juju as an entry point, but now that I agreed with you you're changing the argument so we continue to disagree.. [13:01] rog: And that's looking fine to me [13:01] niemeyer: i don't want to disagree! [13:02] niemeyer: i just think that the entry points and the environment stuff can live in the same package [13:02] rog: So stop doing so.. you want juju as an entry point.. let's do this, and let's keep implementation details of environments clearly organized in their own package. Best of both worlds [13:04] niemeyer: won't that mean that anyone that actually wants to use the juju API will have to import both juju/environ (to read the environment) and juju/control (to actually do anything)? [13:04] rog: Open dummyprovider_test.go and tell me with a straight face that this pertains to a top-level package. [13:04] s/juju\/control/juju/ [13:05] rog: Why? func Open(name) *environ.Environ ? [13:08] niemeyer: yeah that would probably do the trick [13:08] niemeyer: sorry for my reluctance - it just shifted my world view :-) [13:08] Do we have an outline about the contents and the structure of the API? [13:09] rog: Well, no need to be sorry.. no feelings hurt. I'd rather having you arguing than having you silent. :-) [13:10] TheMue: We have an evolving idea about that [13:10] TheMue: We debated some high-level approaches about how to move forward in terms of the state integration at UDS [13:10] niemeyer: Any kind of living wiki document to collect the ideas? [13:10] TheMue: No.. the living collection of ideas is the code base [13:10] *sigh* [13:10] TheMue: ? [13:11] TheMue: Go has very good ways to define APIs, document them, and read that documentation [13:11] niemeyer: just curious, have you ever gotten any complaint from other users in the channel that you were flooding it? [13:11] TheMue: If we have ideas about how APIs should look like, the code base is a _much_ better place to put that documentation than any wiki [13:12] TheMue: rog has added a full skeleton of the environment API, despite it being pretty much unimplemented [13:12] TheMue: i've done a few forward-looking ideas for how i imagine some things looking [13:12] I surely see the importance of code. But especially when designing an API I like a good doc of the evolution so that anyone can not only see how it has been done but also why it has been done this way. [13:12] TheMue: Again, this is a great idea! [13:12] TheMue: And the code is the place to put it [13:13] It can be created in parallel and doesn't has to be a novel. [13:13] TheMue: You seem to see the code as a poor place for documentation.. we disagree in that regard [13:13] TheMue: at this point, i think the most important thing is how the API looks [13:13] Yep, we do [13:13] It is the most important, here we do agree [13:14] TheMue: that is, how the types are named, and what the entry points look like [13:15] TheMue: if you've been following the recent Go activity, you'll see that much of the stuff has been proposed in the form of godoc output [13:15] TheMue: i thought it worked pretty well [13:15] rog: Yep, it's most important how it looks. It's good for the user. [13:16] TheMue: and it means that when you come to actually implement stuff, you just need to fill in the bodies of the types and functions [13:16] rog: But for the maintainer some infos about the motivation for decisions are helpful too. [13:17] The "code" is where the project really lives.. around it we have revisioning of content, static analysis of names, reviewing workflows, automatic documentation generation, etc etc. [13:17] TheMue: i think that can go in the code too. [13:17] rog: I'm not only talking about implementing s/w the first time but also maintin it the whole lifecycle [13:17] TheMue: me too. [13:17] and me too [13:17] Even more important in maintenance, in fact [13:17] TheMue: documentation external to the code always lags... [13:18] Code documentation far from code == quick bitrot [13:18] rog++ [13:18] yep [13:19] Don't get me wrong, I want both. I can show you 20yrs code of mine with good comenting and naming. [13:19] which isn't to say that there shoudn't be some explanatory comments in the code about some particular decisions, if they're not obvious [13:19] the nice thing about proposing stuff with a Go API is that it keeps things concrete [13:20] * niemeyer perceives ethos in the rhetoric.. [13:20] where several paragraphs of text can be very ambiguous [13:22] FWIW, I'd laugh (or cry) about my code from 20 years ago [13:24] TheMue: here's my original skeleton API (well out of date now) but if you look in juju/conn.go, the commented-out method give an idea for where i was aiming: lp:~rogpeppe/juju/go-too-much-too-soon [13:25] i'm still using some small pieces of code i wrote 20 years ago... [13:26] Hehe, just digged around in some Pascal code from 1990. Looked neat. [13:27] TheMue: the thing is, we're not redesigning juju - we're specifying the API and the internal structure. the design already exists and is implemented. so design documents aren't really appropriate here IMHO. [13:27] Hmm, I need a shortcut to checkout links from here in XChat directly into my project directory ... [13:31] So, in only few words, how will our API look? One major type providing many methods? Is this an interface and do we work with factories? Can the user expect transactional behavior (or at least a searialization of jobs)? Or do we have many small types the API user instantiaties on his own? [13:31] rog: Very good point.. high-level (non-code) design documents are here: http://juju.ubuntu.com/docs [13:31] TheMue: In only a few words? It will look great! ;-) [13:32] niemeyer: h5 [13:32] Gooooood answer [13:33] TheMue: More seriously, the domain space is fairly intricate.. such statements ("we'll use factories") are a solution in search of a problem. We'll try to do the inverse.. understand the problem and then figure how to best design the solution. [13:35] niemeyer: I know, has only been an example question regarding a design principle of e.g. separating service interfaces and providers handled in a kind of internal container (goroutine able to encabsulate jobs performin on those services). [13:36] TheMue: Again, all of those things are solutions in search of a problem.. one can't tell whether something is appropriate in isolation of the actual problem being solved. [13:37] TheMue: i try to start from "this is the API i want to provide", then move to "how can i implement that API" [13:38] TheMue: luckily in this case, the problem itself is already specified (otherwise i'd start there) [13:38] TheMue: Depending on what we're trying to accomplish, we can go in one direction or the other [13:38] TheMue, niemeyer: i've done most of the cloudinit changes. am ready for G+. [13:38] rog: Kind of.. there are open problems in terms of API organization that we're trying to solve as well [13:39] niemeyer: it might be useful to make a list of some of the most pertinent of those problems. [13:39] This API organization is what I want to see. In a higher level than code, but less than a novel. [13:40] rog: YES! [13:40] rog: I've been doing that.. but you're already aware of them in the context we're debating [13:40] rog: That's the doc I'm referring to. A list of what we want to provide which evolve into how we do it. [13:40] TheMue: method stubs work well. no bodies necessary, but a type signature and a comment. [13:40] rog: or were, anyway [13:40] lol [13:41] maybe i am. [13:42] rog, TheMue: Invite sent [13:45] niemeyer: one mo, i'm just being banished upstairs [14:32] * hazmat yawns and digs into reviews [14:36] SpamapS: Hey so in your review of limesurvey I like how you tested the haproxy bits. [14:36] SpamapS: can I get a blog post out of that? I'd like a post highlighting that you can just add proxy things to charms and that we like that because it let's you addunit something fierce. [15:37] currently building py27-txzookeeper for juju port on mac… Next we will see if the juju port command will work. ;-) [15:38] mcclurmc, :-) [15:38] ugh.. keep doing that [15:38] mchenetz, cool, i'm curious to see how it goes, i've got an old mac pro i can setup if something needs debugging [15:39] no prob… I think i can handle the debugging. If i can't i will let you know. Thanks [15:39] I will right some instructions up if it works [15:39] mchenetz, awesome [15:39] robbiew, thanks for posting the lisa keynote talk, interesting stuff .. http://www.youtube.com/watch?v=3KpPBnEtRj4 [15:40] pretty high level stuff [15:40] hazmat: np...I missed Wednesday and was just looking to see which videos had been posted...luckily this one was [16:05] m_3: ping [16:06] robbiew: yo [16:06] g+? [16:06] m_3: yup [16:09] m_3: invite sent...I think [16:09] doh... from me too just now... lemme look for ytours [16:10] * koolhead11 wondering if robbiew going 4 hangout. :P [16:20] niemeyer: http://paste.ubuntu.com/769110/ [16:27] hazmat: the most interesting part was at 1h06m20s :) [16:29] niemeyer: any way i can reset the CL state, or do i have to create a new CL? [16:34] rog: Yo [16:34] niemeyer: hiya [16:35] rog: Let me check that paste [16:35] rog: Curious [16:37] I think i am going to create a macport repo on one of my servers for Juju so that other people will not have to go through what i am going through... [16:38] rog: So, do you have any idea of what was the story there? [16:38] rog: The file definitely looked weird.. I'm not sure about where to start looking [16:39] niemeyer: i think the sequence went something like this: [16:39] niemeyer: the wrong version of all.bash went in initially [16:39] niemeyer: i changed it. i might even have done bzr rm all.bash [16:39] niemeyer: then i added it again [16:40] oh, somewhere in the middle, it went wrong, so i couldn't view anything on the web site ("CL is uploading" or something like that) [16:40] and then somehow i got it back again [16:40] but... with two all.bash files visible [16:41] niemeyer: sorry it's not a very reproducible scenario [16:41] rog: Ok, no worrie [16:41] s [16:41] niemeyer: but currently i can't upload my changes, so the CL is stalled [16:41] rog: Can you please retry with -debug? [16:42] jcastro: ack.. in the server team meeting right now.. [16:43] ! [16:43] it's worked now [16:43] niemeyer: dunno what went right this time [16:44] niemeyer: BTW, i'm not sure what to do about all the comments for the various options [16:44] rog: Have you touched the branch in any way in between? (commit/whatever) [16:45] rog: let's figure what the options do.. smoser can help us [16:45] niemeyer: nope [16:45] niemeyer: i could make a guess at the docs but, yeah, some knowledgable help would be good [16:47] what options are you talking about, negronjl [16:47] oops [16:47] niemeyer, [16:47] smoser: cloud-init options [16:47] smoser: https://codereview.appspot.com/5444043/diff/20003/cloudinit/options.go [16:48] which options? most options for cloud-config are documented at http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt [16:48] Sweet! [16:48] smoser: "user" ? [16:49] smoser: thanks BTW [16:49] thats the 'user' that things are done to (like ssh-import-id, other stuff... its assumed that that user already exists in the image) [16:50] ie, 'ubuntu' [16:53] smoser: hmm. i'm trying to think of a good way to phrase that. [16:53] smoser: "SetUser sets the user that things are done to" doesn't quite get there for me :-) [16:54] many cloud-config things operate on a user account. [16:54] smoser: "SetUser sets the remote user name that will be used"? [16:54] (import keys being the most obvious) [16:54] smoser: is it essentially just setting the home directory? [16:54] they read the cloud-config user 'user' for which user to operate on [16:54] smoser: or do some things set uid to the user too? [16:55] smoser: yeah, i've seen a few get_cfg_option_str(cfg,"user","ubuntu") [16:57] its possible they get the uid for the user and use it, but i'm not usre. === niemeyer changed the topic of #juju to: http://j.mp/juju-florence | http://j.mp/juju-docs | http://j.mp/irclog | #juju-dev | Office Hours (1600-1900UTC) [16:58] New #juju-dev channel, for low-level development-related topics [16:59] smoser: yeah, byobu does sudo user. [17:00] (whatever byobu is :-]) [17:01] smoser: "SetUser sets the user name used for byobu, set_passwords, ssh_import_id and ssh_import_id"? [17:01] rog: byoby == screen with a configuration file from Dustin [17:02] (maybe enumerating the various things that uses it is easier that trying to say what it is) [17:05] next version of byobu is tmux based [17:05] quite nice actually [17:05] er.. i guess it supports both, but i tried out the tmux version [17:06] the docs say of apt-mirror, "Add apt repositories" but it only has one string argument [17:06] is the URL point to a list of apt repositories? [17:07] s/is/does/ [17:07] smoser: what does apt_old_mirror do? [17:09] darn it, i've got to go [17:09] smoser: thanks for the help. [17:10] anyone: feel free to add any docs to the above page (https://codereview.appspot.com/5444043/diff/20003/cloudinit/options.go) by double-clicking on a line [17:11] see y'all tomorrow [17:12] rog: Have a good evening [17:13] bcsaller, jimbaker, fwereade standup? [17:35] bcsaller re standalone needs review, https://code.launchpad.net/~hazmat/juju/upgrade-config-defaults/+merge/84710 [17:47] new charm-tools/charm-helpers uploaded to precise.. now with unit tests.. w00t. :) [17:56] SpamapS: thanks [18:51] SpamapS: woo \o/ [19:03] Finally got juju working on OSX, using Port, Brew and PIP… It was hard and it was ugly… I am going to work on fixing the port file and maybe even create a brew repo [19:03] except.. the tests fail on the buildds.. hrm [19:04] mchenetz: +1 for a brew repo [19:05] m_3: I like brew a lot better and i think it already had a lot of the dependencies… So, i think it would be the way to go... [19:06] much easier to publish and maintain imo... just pull requests [19:06] I haven't looked into it. But that is always what i hear. I will be looking at it shortly. :-) [19:07] * m_3 will have to break out the old osx drive for his mbp to test [19:10] okay, after all of that… during bootstrap: ERROR, no module named apt… hehe it's not linux [19:12] Now to look at the juju code [19:19] Okay, so this seems to be a local provider issue under pkg.py [19:19] I think we could do a little magic to use brew or something else in the pkg.py script [19:22] okay, so now i am thinking that a standardized repo for juju is quite important. We need to have similar packages for osx and linux. So someone, maybe me, needs to start a repo that includes the packages required to allow the charms to function correctly [19:24] SpamapS: marcoceppi: I would really appreciate if one of you would have time to review my mess :) [19:24] * SpamapS points nijaba to m_3 [19:24] nijaba: I'm a bit strapped this week between deadlines and "in-laws" visiting [19:24]