[00:04] * negronjl is afk [00:13] m_3: Thanks for the review and consolidating everything into one [00:13] I was never able to wrap my head around Cheetah, which is why I still bow to the gods of sed :) [00:15] SpamapS: you too ^^ (thanks!) :) [00:18] marcoceppi: yeah, I'm kinda trying to add discussion as part of the review too... those parts aren't crucial, just opinion, but it's good to talk them over [00:19] marcoceppi: I took some notes on cheetah from a shell script... [00:19] * m_3 digs around [00:20] I think most of the time heredocs are simpler than cheetah [00:20] m_3: I just find cheetah to be, overkill? for the small configurations [00:21] cheetah is great when you want to loop over complex objects [00:21] but most of the time just >>'ing to a new version of the file is actually a better way to go IMO [00:24] SpamapS m_3 are there any other lightweight configuration tools, that just use templating? Like Smarty for bash? [00:26] marcoceppi: the only time I see templating as an important option is when you can look at the template w/o the logic that fills it... like HTML templates that are worked on by designers. [00:26] marcoceppi: for config files.. just build the thing by appending. [00:26] where I've used cheetah.. I've felt it was overkill ;) [00:26] disagree... there's lots of use for lightweight templating [00:27] Its mostly a style choice [00:27] it's not that painful either... no code... it can be called from the command line [00:27] heredocs are just one form of templating [00:27] agree... totally a style choice [00:28] stitching various here-docs together can even do complex templating [00:34] m_3: I'd be interested in your bash notes :) [00:37] DOWNLOAD=`ch_get_file "http://iweb.dl.sourceforge.net/project/phpmyadmin/phpMyAdmin/3.4.7.1/phpMyAdmin-3.4.7.1-all-languages.tar.gz" "726df0e9ef918f9433364744141f67a8"` [00:37] that is so awesome [00:38] cat > $apache_config_file < SpamapS: <3 [00:39] marcoceppi: so, for my money, its better to > to a tmpfile .. then mv -f [00:40] marcoceppi: and probably worth adding a charm helper function that takes a heredoc as its stdin and a filename to rename to as $! [00:40] err [00:40] $1 [00:40] sh/file.sh sound good? [00:40] or should there just be one file, helper.sh ? [00:41] not sure... [00:41] I like the idea of breaking them up into groups [00:41] I may be trying to split too soon :\ [00:41] but it also means people have to lookup which one each function is in... [00:42] maybe have an all.sh that just sources them all [00:42] good idea [00:42] one thing that sucks is that we want to cleanup temp files on any fails..which is usually done w/ a trap.. but traps in sourced files can be ugly [00:43] marcoceppi: also.. VirtualHost with ServerName .. not sure thats a great idea [00:43] marcoceppi: for the most part I think we can think of these as standalone boxes [00:44] tho I guess the first VirtualHost is also the default one [00:44] What about when co-location happens? [00:44] * marcoceppi looks longingly into the future [00:44] marcoceppi: that isn't something I think we should think about. co-location is supposed to be for things that don't conflict. [00:45] and anyway, if you co-located two things that did it this way, they'd have conflicting ServerName fields and break. [00:46] I kinda like adding apache vhosts w explicit aliases (to /phpmyadmin) instead of overloading root [00:46] SpamapS: I guess, I keep envisioning there being an http relation with an apache interface. So an apache charm and charms like thinkup and phpmyadmin would require the apache charm and apache charm would setup the proper virtualhosts based on X things [00:46] results in the lame "It works" though :) [00:46] via colocation [00:47] marcoceppi: more likely you'd use a reverse-proxy in any real situation though [00:47] that works now without charms.. just apt-get install the two things, they're both on port :80 at /foo and /bar .. [00:48] charms tho, are oriented around configuring the machine for the one thing they do [00:48] right, it's because I have a slightly different use case that I look at warping juju to do that :) [00:50] I think the way subordinate/colocated charms is being implemented, it may work that way.. [00:50] where you could have an apache charm.. and deploying apps that support the apache interface as subordinates of it, would give them a chance to tell apache that they want to be at /foo [00:52] open-port 80/tcp [00:52] chown -R www-data:www-data /var/www [00:52] marcoceppi: open the port only when the service is configured [00:52] kk, thanks [00:52] Since phpmyadmin is kind of nothing w/o databases.. I'd say it should be opened in the relation hook, not install [00:53] Or, can it work w/o any sources configured? [00:55] marcoceppi: simple cheetah example from the command line: http://paste.ubuntu.com/753201/ [00:57] marcoceppi: and the other extreme... a more complex template using eruby https://gist.github.com/1402781 [00:59] SpamapS: It _can_ be run without a db, but it's pointless without one [01:20] marcoceppi: I don't understand this change... [01:20] 8 -if not slave and not broken and not admin: [01:20] 9 +if not slave and not broken: [01:21] marcoceppi: seems like we'd still want that.. who cares if the database already exists? [01:22] marcoceppi: anyway, I have to run.. but that does seem confusing [01:22] marcoceppi: oh sorry, in relation to https://code.launchpad.net/~marcoceppi/charm/oneiric/mysql/db-admin-relation-fix/+merge/83690 [01:28] SpamapS: In my trials, if you destroy phpMyAdmin then deploy the service again, MySQL would error on join because it tries to create the database again [01:33] marcoceppi: we should disable the creation on admin [01:34] marcoceppi: they have root.. let them create their own db :) [01:34] SpamapS: that was my first course of action, then I realized that phpMyAdmin requires a database [01:34] oh haha [01:34] So I put it back, looking back on it now it should be disabled though [01:34] I'll update my branch for the merge proposal [01:34] just use 'mysql' [01:35] or create one conditionally.. if not exists.. [01:35] anyway.. GONE [01:35] SpamapS: I'll just have the db-admin hook create it, no bigs [01:37] SpamapS: Damn, well when you get back I've pushed up the changes [02:46] * marcoceppi wanders away to play Zelda [03:23] zelda +1 [03:38] * SpamapS creates ppa:charmers/charm-helpers [03:41] sweet [03:42] More I think about it, the more I think we need a charm-helpers addon that reads metadata.yaml for declarative stuff [03:43] or a juju add on I guess [03:43] * SpamapS loathes writing specs, so would prefer charm-helpers ;) [03:44] How would it read metadata.yaml? as in metadata defining what helpers needed to be loaded into the environments? [03:45] Just have a single command at the outset that bootstraps in charm-helpers [03:45] and after it does the declarative bits, runs hooks/install.charmhelper or something [03:46] actually you can just have install be something like [03:47] #/bin/sh [03:47] charm-helper [03:47] ... install steps [03:48] charm-helper would need to be in the OS [03:48] or in juju's cloud init [03:50] otherwise for now just add-apt-repository -y ppa:charmers/charm-helper && apt-get update && apt-get -y charm-helper [04:44] sweet [05:43] Hey folks i am having a little trouble bootstraping [05:44] Fails to find and register any hosts [05:45] Even though the hosts r alive and pingable [05:46] My aim is to deploy openstack on servers deployed through juj and orchestra [05:49] Cobbel does its job and allows the hosts to build but the do not register and juju bootstrap fails to find an orchestra server [08:34] hazmat: around [09:37] is zookeeper a compulsary pkg to be on the VM clients/cloud-image once they are started via juju-bootstrap? [09:39] if that is the case then i can never run juju in my openstack environment if the Internal IP has no internet access :( [09:40] koolhead11: i should think so. zookeeper is used for all juju coordination (e.g. hook execution) [09:40] koolhead11: is that because you can't install zookeeper with no internet access? [09:40] rog: http://paste.ubuntu.com/753467/ [09:40] i confirmed it after the console log [09:41] rog: true [09:41] so if am running juju with openstack then i need to have internal network access to internet [09:41] koolhead11: what command is that paste output from? [09:42] $ euca-get-console-output instance-id [09:42] koolhead11: alternatively you could use an image with zookeeper preinstalled, presumably [09:42] rog: +1 [09:43] so it means i have to re-create the image :D [09:43] with adding all these pkgs [09:43] koolhead11: given that you've got no internet access, i don't see an alternative, other than setting up your own local PPA [09:44] koolhead11: (and i've no idea how much work that would be) [09:45] koolhead11: i imagine that the only package that you need to preinstall is juju, which will have all those other packages as dependencies [09:45] koolhead11: i may be wrong though - i'm quite new to all this [09:48] rog: am going to add all those pkg and remaster the cloud-image i have just downloaded. I will have to check/work on repository issue :) [09:48] rog: thanks a lot :) [09:54] koolhead11: no probs. hope it works! [09:56] rog: and i think the issue am facing is more to do with my internal network :( [11:25] hi all [11:26] i need one more info, i just need my ubuntu image along with cloud-init? am trying 2 build a custom ubuntu image because i have to provide network info in it [11:32] Morning all [11:32] koolhead11: Hi! [11:32] koolhead11: Custom Ubuntu images are generally not encouraged with juju [11:33] koolhead11: We use the charms to tweak the image to one's nee [11:33] d [11:34] morning niemeyer! [11:47] fwereade: Hey dude [11:58] niemeyer: hellos [11:59] actully i need to add proxy info in my apt so the zookeper and other pkgs gets downloaded once instance starts [12:03] niemeyer: euca-get-console-output instance-id is this [12:03] http://paste.ubuntu.com/753480/ [12:03] i hope you agree to me on this ;D [12:03] koolhead11, pong [12:04] hazmat: hola [12:04] its my running instance which has not connected to internet and failed to download zookeeper [12:04] koolhead11, indeed you do need your cloud to have access to the internet [12:04] as result of that am having all the issue [12:05] koolhead11, alternatively you need a proxy/cache setup [12:05] http://askubuntu.com/questions/83134/using-juju-on-openstack-returns-ssh-invalid-key-error/83698 [12:05] hazmat: where will i do proxy/setup [12:05] because my nova via which my instance gets network routed needs proxy [12:06] so the only thing came to my mind is to add proxy info in the cloud-image i downloaded [12:06] koolhead11, your question/problem is different then the original thread, its more appropriate to start a separate conversation regarding [12:06] at least its not clear to me that their the same [12:06] koolhead11, what do you expect juju to be able to do if you have no network access? [12:07] just curious [12:07] hazmat: yes i got the reason for problem i was having. [12:08] by any chance juju during bootstrap has any option to define proxy? or i need to hardcode it inside my image and then upload it again to the bucket [12:08] * hazmat checks if cloud-init supports it [12:09] koolhead11, do you have a machine accessible from the vm/cloud network that has internet access? i guess you can setup an instance that way if you associate a public address to it? [12:09] g'morning [12:09] all ;-) [12:10] fwereade, i was looking over the restart-transitions branch last night, in general it looks good, i had one major concern about it, in that it would automatically effect error transitions (from error states) to started and up without user intervention [12:11] hazmat: if you will not kick me then does juju has option like " juju bootstrap --proxy= " :D [12:11] which is a significant change unintended change in behavior [12:11] koolhead11, that seems reasonable [12:11] i mean some option to that effect [12:11] hazmat, reading code... [12:11] hazmat: so is it there, can i try that? [12:12] koolhead11, its not there yet, i'm investigating how it can be done [12:12] hazmat: awesome!! [12:12] hazmat, yes, you're absolutely right [12:12] hazmat: also you were correct, the internal network in openstack gets access to internat routed via Nova [12:12] cool - would be useful [12:12] uksysadmin: +1 [12:13] hazmat, am I right in thinking that all I actually need to fix is to verify sensible states before I attempt the transition? [12:13] but in my case even nova is running on proxy :( [12:13] koolhead11, if that's the case the instances should have internet access for normal apt usage? [12:13] fwereade, yeah.. i think just checking that 'error' not in current_state suffices [12:13] but in my case even nova is running on proxy :( [12:13] fwereade, but its a little tricker than that [12:14] hmm [12:14] fwereade, just wondering if the unit is in error, do the unit rel states need to be initialized [12:14] hazmat, I had wondered whether I could guarantee error state by "error" in current state [12:14] hazmat: so you got this trick issue :D [12:14] probably not, they can be lazy initiaized [12:15] fwereade, yeah.. its a property of all the error states that they have an error in the name, i would some strong wording to that effect in workflow.py [12:15] hazmat, cool [12:16] fwereade, actually just having a func or method in workflow.py is_error_state should suffice to abstract [12:16] hazmat, good point [12:17] hazmat, I suspect that I'm still some way away from getting restart behaviour correct in all cases [12:17] hazmat, I think I finally have a decent handle on all the workflows and lifecycles, and the hook scheduler [12:17] fwereade, yeah.. there's several more corner cases [12:17] fwereade, cool [12:18] hazmat, but I have yet to translate all that into a coherent plan [12:18] the scheduler still has transient state [12:18] i'm still wary of trying to store that in zk, given the connection to zk may be dead [12:20] hazmat, the scheduler certainly does; there's also some minor complication with the unit workflow, I think, in that it'll need to put the lifecycle into a sensible ._running state when it's recovering into a surprising state (if it's *only* error states, it's not too bad, but I'm not certain of that yet) [12:21] <_mup_> Bug #897645 was filed: juju should support an apt proxy for private clouds < https://launchpad.net/bugs/897645 > [12:21] hazmat, and I agree, I think we want the HS state on disk [12:22] hazmat, the relation stuff does indeed seem to be ok if we do everything lazily [12:22] hazmat: any ubuntu image with cloud-init should work for juju i suppose [12:24] fwereade, interesting re _running, we do need to ensure that its the lifecyle is running, regardless of the transition to started in this case, it will need an additional public accessor/mutator, although i wonder if needs to support external on/off or just on. [12:24] needs more thought [12:24] koolhead11, yes, but we do require fairly recent versions of cloud-init [12:25] hazmat, as I understand it, the current transitions will start and stop the lifecycle as appropriate [12:25] hazmat: the comes with oneiric [12:25] hazmat, what I'm lacking is certainty about the mapping from states to should-lifecycle-be-running [12:25] fwereade, they do, but that's based on a notion that start is called on the lifecycle [12:25] hazmat: cloud-init 0.5.10-0ubuntu1.5 will do? [12:26] fwereade, yeah.. it needs more thought, my thought in this case, is that regardless of state we'd want lifecycle running [12:26] fwereade, maybe not.. [12:27] hazmat: hm, a config error, for example, explicitly stops lifecycle [12:27] fwereade, thinking about error states like install_error, or start_error [12:27] exactly [12:27] hazmat, if it's *just* errors that do that, and we can guarantee that forever, that's easy, but I'm fretting about it [12:28] fwereade, yeah.. its fine without manipulating _running, effectively the guarantee ic is that its only running after started, and error states will stop that [12:28] if we come back in an error state, we can still recover... the unit rels are only active if started [12:29] and we don't need to manipulate the lifecycle internals [12:29] koolhead11, and that corresponds to what? [12:29] hazmat: is it the latest cloud-init pkg which juju needs :D [12:30] because am making my own image adding the proxy issue in it and cloud-init has to be installed to [12:30] hazmat, then perhaps it's even simpler -- if we're in an error state do *nothing*, if we're already "started" just lifecycle.start(False), otherwise do the usual transitions into started? [12:31] i cannot log in to the machine which i booted and uses image http://uec-images.ubuntu.com/ [12:32] fwereade, yeah... that sounds about right, just wondering if that can be simplified [12:38] hazmat: 0.5.10-0ubuntu1.5 version of cloud-init get installed, you think its sufficient to run juju ? [12:38] koolhead11, that corresponds to what distro release version? [12:39] koolhead11, specifically for cloud-init there where fixes for the oneiric release regarding openstack [12:40] hazmat: so it will work :D [12:40] koolhead11, the version in oneiric is 0.6.1-0ubuntu22 [12:41] hmm. so i will get the latest oneiric one installed. [12:41] koolhead11, which implies to me that no.. 0.5.10 won't work for openstack, there was specifically a problem around installing the ssh key in older versions [12:41] thanks. let me test this [12:41] hazmat: no my bad, i was on my natty system :) [12:42] and got that version [12:42] koolhead11, no worries [12:42] koolhead11, uksysadmin Bug #897645 is to track the apt-mirror/proxy support [12:42] <_mup_> Bug #897645: juju should support an apt proxy for private clouds < https://launchpad.net/bugs/897645 > [12:43] awesome, ta hazmat [12:54] mpl: ping [13:00] rog: ping [13:00] niemeyer: hiya [13:00] rog: Yo [13:00] niemeyer: how're them reviews coming on? :-) :-) [13:00] rog: Just looking at mpl's review, and I noticed you've replied via email, which interestingly went to the merge proposal and not to codereview [13:01] niemeyer: interesting. i don't *think* i got an email from codereview about it. [13:02] niemeyer: nope, i didn't. is this a flaw in the cunning plan? [13:02] rog: Not sure.. just thinking [13:02] rog: and yes, you certainly have reviews coming your way [13:02] niemeyer: whee! i've been stacking up the merge requests, i'm afraid [13:02] niemeyer: i hope i haven't gone way off track [13:03] rog: For now, let's start the review online in the codereview page.. this will ensure you get added to the reviewers list [13:03] niemeyer: you mean, reply on that page rather than reply to the email? [13:03] rog: That's alright.. we'll sort it out.. please don't pile up things too much in the same branch, though [13:03] rog: That first ec2 branch took way too long, and I'm actually wondering if we'll have to break it down [13:03] rog: But let me go over it in a first pass before anything [13:04] niemeyer: yeah, it was bigger than i wanted, but i couldn't see a way to break it down into nice easy steps [13:04] rog: That's right.. reply in the codereview page first [13:04] rog: That will add you to the reviewers list [13:04] niemeyer: since that branch, i'm trying hard to keep the branches small and to the point [13:04] rog: That's awesome, thank you [13:06] niemeyer: pong [13:06] mpl: Hey there! [13:06] hi [13:06] mpl: Just going over your change and we're mostly ready for merging [13:06] mpl: One question: have you signed the contribution agreement from Canonical before, for any project? [13:07] mpl: I don't recall if I actually asked that before [13:07] niemeyer, can lbox propose send an existing branch to codereview site ? [13:07] niemeyer: nope, I don't thing I did. [13:07] hazmat: Yep.. just propose it again with -cr [13:07] *think [13:07] niemeyer, awesome [13:07] hazmat: It will find the existing merge proposal, and will do the delta [13:07] niemeyer, does that work even if the merge proposal belongs to someone else? [13:07] hazmat: Hmm [13:07] niemeyer: same kind of procedure as with Google I suppose? [13:07] hazmat: Maaaaybe [13:08] ie. does it actually resubmit it,or can it just do the diff and add the comment [13:08] hazmat: As long as you have editing permissions, I *think* it may work [13:08] niemeyer, cool, i'll have to experiment [13:08] hazmat: Oh, actually, probably not [13:08] hazmat: Because it will attempt to push the branch [13:08] hazmat: But try anyway [13:08] ah [13:09] mpl: Yeah, mostly [13:09] mpl: Except it's a single agreement for all Canonical projects [13:09] mpl: So you won't have to be doing this again for juju, etc [13:09] mpl: The details are here: [13:09] mpl: http://www.canonical.com/contributors [13:09] mpl: It's non-draconian, and quite straightforward [13:09] niemeyer: kthx, I'm on it right away then. [13:12] mpl: No problem [13:12] mpl: and thank you [13:13] sure, thank you for putting me on track. [13:13] mpl: I've just reviewed your change, and there's one minor nit to address.. [13:13] mpl: Once you do it, just run "lbox propose -cr" again, and I'll merge it [13:16] I'm on a different machine now, I'll just have to setup things again. [13:16] CA submitted btw. [13:16] mpl: Beautiful, thanks! [13:16] Ok, I suggest going through the same procedure you did originally [13:16] one question regarding the submit procedure (open to anyone here): [13:17] mpl: and then run "bzr pull" once you're inside of the branch [13:17] when I lbox proposed, it took me to the browser page where I have to agree to let launchpad access things on my behalf [13:17] mpl: That's right [13:17] mpl: Well, almost right anyway [13:17] I selected the most permissive option [13:18] mpl: It's actually lbox asking Launchpad so lbox can do things on your behalf [13:18] mpl: Yeah, I think that's necessary in this case, since it's actually writing content on your behalf [13:18] yes. what's the minimum working level I was supposed to agree on there? [13:18] ok [13:19] mpl: Btw, if that's a machine you're not comfortable leaving your credentials around, make sure you kill "~/.lpad*" when you stop working there [13:19] ah, good to know, thx. [13:19] mpl: It's not your real credentials, but rather just a token [13:19] mpl: Even then, someone can impersonate you with it [13:20] ok. no worries though. both are my laptops and somehow secure. [13:20] *somewhat [13:22] niemeyer: btw, I'm new to bzr (ok with hg and pretty comfy with git) so I might make mistakes with it at first. I've read the minimum docs so far. [13:22] mpl: Not a problem by any means [13:28] niemeyer: so you're saying I should pull from the original branch. not simply 'bzr branch lp:~mathieu-lonjaret/gozk/zookeeper' ? [13:29] mpl: Yeah, I suggest you follow the original process, and once you have the local environment setup, get inside your feature branch and pull from your changes at that URL [13:29] mpl: The reason being that this way you'll preserve the parent link with the local trunk [13:29] mpl: You can also do it in other ways, but that one is simple to follow and explain :) [13:30] ah, I think I see, thx. [13:34] niemeyer: for further changes, I suppose it's cleaner I append them to the current commit (#22), rather than creating new commits, right? I mean, if there's such a thing with bzr... [13:34] mpl: No, we generally don't encourage reorganization of history [13:35] mpl: Even more considering it has been published [13:35] mpl: This would be discouraged even with git [13:35] well published, but not yet merged. [13:35] mpl: Yeah, but it's published.. the review was made on a given revision, which we should be able to look at again if necessary [13:36] rog: Is Jacek the guy you told me about at UDS? [13:36] niemeyer: no [13:36] rog: Ok, so he mailed us independently.. cool [13:36] ok, I just got used to doing that way with brad for camlistore. but we're using gerrit, so nothing's "published" until it's merged yeah. [13:37] mpl: Ok, it feels like a bad idea even with gerrit [13:37] mpl: FWIW [13:38] mpl: Otherwise you have a review published, for which you don't have the codebase anymore [13:38] true. the only trace of the patchsets are in gerrit. [13:39] otoh it encourages to commit often for small changes in the same review without fearing of filling the log with ridiculous commits. [13:40] but anyway, not suggesting anything, was just asking. :) [13:45] mpl: Yeah, there are two religious camps.. we're on the side that don't really care about the history of feature branches [13:45] mpl: The history of trunk we care about, though [13:45] mpl: So we're generally more careful on the merge messages [13:46] uh, that's odd. the tests all passed on that machine and yet I have no recollection of installing/trying more zookeeper things on here. [13:58] niemeyer: so I've branched from lp:gozk/zk, made a feature branch, cded into it, pulled from lp:~mathieu-lonjaret/gozk/zookeeper, made my changes, made a new commit. now if I lbox propose -cr, it will know that we're still in the same CL, and not create a new one, right? [13:58] or am I forgetting something? [14:02] hazmat, i'm interested in what you think of my comments to bug 897645 [14:02] <_mup_> Bug #897645: juju should support an apt proxy for private clouds < https://launchpad.net/bugs/897645 > [14:05] mpl: That's right [14:05] mpl: Just propose -cr again [14:05] mpl: Then, visit the codereview page, and mention it's ready [14:06] mpl: In the future, I'll change lbox propose so that it adds a note by itself [14:12] hmm I must have messed up somewhere: [14:12] bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~mathieu-lonjaret/gozk/zookeeper/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() [14:14] mpl: did you kill a bzr process? [14:15] mpl: actually, no that gives a different error [14:17] no, I don't think I did. [14:21] mpl: Ah, I see what's going on [14:21] mpl: try this: [14:21] mpl: within the branch [14:21] bzr push --remember lp:~mathieu-lonjaret/gozk/zookeeper [14:21] mpl: Then try to propose again [14:21] niemeyer: maybe #juju is better for this conversation [14:21] rog: Yeah, both are cool [14:21] rog: Oh, no, I guess you're right [14:22] rog: We're moving onto juju territory [14:22] niemeyer: that's what i thought [14:22] rog: +1 [14:22] niemeyer: i'm not sure of a good way to test the juju cloudinit code though [14:22] niemeyer: it's a public function in the juju package, so it should have a test, but i'm not sure what level would be best. [14:23] niemeyer: maybe just compare the output, as discussed [14:23] smoser, replied on the bug [14:23] niemeyer: at least that'll guard against regression [14:23] stepping out to run some errands, back in 40m [14:24] rog: yeah, that sounds sane [14:24] hazmat: Cheers [14:24] niemeyer: whoa I hit a go runtime panic [14:25] mpl: Oh, I wanna know about that one [14:25] (while proposing). the command you gave me worked to deblock the situation though. [14:25] k, sending you the stack by e-mail then. [14:25] mpl: Can you please paste the output somewhere? [14:25] ok, a paste then. [14:26] hazmat, i think juju should expose cloud-init to end users. [14:27] niemeyer: http://paste.ubuntu.com/753711/ [14:27] not by default, but at least allow the user to specify "start all my instances with these parts" [14:27] as that would generically solve local customization problems that you will undoubtedly run into. [14:29] mpl: Oh.. hmm [14:29] mpl: Damn.. I think that's the bug I fixed in Go's http package itself [14:29] niemeyer: I have some RL work to finish, so I might get a little laggy but I'll catch up [14:29] mpl: I'll have to recompile lbox with the latest tip [14:30] ok [14:30] mpl: Let me do that [14:50] smoser, hmm [14:51] niemeyer, what do you think about cloud-init for end users exposed directly via juju? [14:51] hazmat: Sounds bad is my first instinct [14:52] smoser, it does makes sense, its already a generic high level language for customization, its just whether or not it promotes different practices (machine think vs container think) then what we're aiming for [14:52] hazmat: It's an implementation detail.. we already have providers where cloud-init doesn't exist [14:53] niemeyer, just one.. and in that one cloud-init doesn't nesc. make sense, and its something we could add.. but thats a different context cloud-init there would be in a container, not a machine [14:54] what is the provider where you have no cloud-init ? [14:54] smoser, local provider [14:54] lxc runs as a container, no ? [14:54] smoser, yup [14:54] you really *should* have cloud-init there. [14:54] imo [14:55] smoser, we debated it, its lack there is mostly as optimization, it cuts down the unit creation time via lxc clone considerably [14:55]