| SpamapS | m_3: yeah buildd's are pretty busy leading up to alpha1 on Dec 1 | 03:06 |
|---|---|---|
| SpamapS | m_3: I'm about to make them even more busy as soon as mysql 5.5 finishes building... | 03:06 |
| SpamapS | found another non-deterministic test that will likely have to be disabled. :-P | 03:07 |
| marcoceppi | So, I started a small collection of bash functions for this charm-helper idea. Any requests? | 03:37 |
| SpamapS | marcoceppi: one that always returns an IP from a hostname or IP that is passed to it | 06:32 |
| tazz | hmm so i came across juju right now, dosnt puppet+mcollective solve the same problem ? | 10:57 |
| noodles775 | tazz: I'm just a user of juju - so best to wait for one of the juju team to answer, but my impression is that mcollective helps you manage servers and clusters of servers, where as juju is about managing services and their relationships. | 11:18 |
| noodles775 | (meant to say, I've only read docs of mcollective - it's not my area) | 11:18 |
| tazz | right... | 11:18 |
| noodles775 | tazz: there are probably better demo's of juju around, but I created a demo yesterday from an experiment which highlights the service-orientation: | 11:22 |
| noodles775 | http://micknelson.wordpress.com/2011/11/22/a-generic-juju-charm-for-django-apps/ | 11:22 |
| hazmat | james_w, success! re reconnoiter pkgs | 11:35 |
| hazmat | james_w, hm... actually i'm a little confused, the src pkg gens 3 bin pkgs but i only see one pkg in the ppa | 11:40 |
| hazmat | hmm.. actually that doesn't look like it actually built correctly, false success | 11:40 |
| hazmat | fwereade_, could you have a look at this trivial.. https://code.launchpad.net/~hazmat/juju/preserve-unit-for-external-gc/+merge/82413 | 12:24 |
| fwereade_ | hazmat, sure | 12:24 |
| hazmat | fwereade_, thanks | 12:24 |
| fwereade_ | hazmat, I'm a bit wary of this given that there isn't actually any GC | 12:27 |
| marcoceppi | SpamapS: What about hostnames with more than one ip? | 12:27 |
| hazmat | fwereade_, we already have a need for gc | 12:27 |
| hazmat | fwereade_, its been assumed, ie if there's a state conflict at any point we have a need for gc, because there is a leftover state | 12:27 |
| hazmat | fwereade_, we use the topology to sync/commit changes for multi node ops | 12:27 |
| fwereade_ | hazmat, ok, so the motivation is that we're already leaving stale crap in ZK, and we need a general solution for that, but this fixes an unrelated problem and doens't make the GC problem significantly worse? | 12:27 |
| hazmat | fwereade_, exactly | 12:28 |
| fwereade_ | hazmat, ok, I'm happy | 12:28 |
| hazmat | fwereade_, say for example we go to create a service state, and we get a topology conflict, we end up leaving a stale service state | 12:28 |
| fwereade_ | hazmat, yep, I've noticed an instance or two of that sort of thing | 12:29 |
| hazmat | i know there's a bug already for it.. | 12:29 |
| fwereade_ | hazmat, cool | 12:30 |
| * hazmat wishes lp would search comments | 12:30 | |
| rog | hazmat: that's interesting. could you explain how that happens? | 12:37 |
| rog | (leaving a stale service state, that is) | 12:37 |
| hazmat | rog, sure | 12:59 |
| hazmat | rog, so say two clients go to create a service named 'mysql' concurrently, they'll first create a service state, which is done against with a sequence node in the /services container, and both succeed, then both go to modify the topology, only one will succeed, the other will get a statechanged error | 13:01 |
| hazmat | but that will leave a stale/unused service state | 13:02 |
| rog | hazmat: can't the one that failed remove its own (stale) service state? | 13:02 |
| hazmat | rog, or take debug-log which currently uses zk as a storage mechanism.. those records are effectively dead after debug-log is terminated | 13:02 |
| hazmat | rog, its a simplification of a general problem, yes in some cases the ops could clean up after state | 13:03 |
| hazmat | rog, the general form though is a multi-node operation, that is 'committed' after topology state modification, the op may span apis and service states | 13:03 |
| rog | isn't debug-log a slightly different problem? | 13:03 |
| hazmat | rog, both generate zk nodes that need gc | 13:04 |
| hazmat | although the latter is indeed different since an ideal solution is to not use zk | 13:04 |
| rog | and it seems to me that the debug-log garbage isn't generated as a result of conflict either? | 13:04 |
| hazmat | rog, effectively we would need either rollback operations per mod, multi-node transactions, or gc | 13:05 |
| hazmat | the former is a rather large code burden, the second is viable though also at some cost of rearchitecting, the gc solution here is quite simple and the garbage cost neglible | 13:06 |
| rog | is the multi-node operation always initiated by a single client? | 13:06 |
| hazmat | rog, there's care taken such that the same multi-node op can be concurrent with predicatable results | 13:06 |
| hazmat | ie. either complete success or state changed error | 13:07 |
| hazmat | with errors not effecting the consideration of live changes | 13:07 |
| rog | hazmat: i think i'm trying to ask if nodes created by more than one client can be invalidated by a single topology commit. | 13:08 |
| rog | by "the former" you mean getting the client to remove its own garbage after commit failure? | 13:09 |
| hazmat | rog i'm not sure i understand the question, a single commit either adds or removes nodes, either can invalidate other concurrent operations | 13:10 |
| hazmat | although only the add conflict scenario would leave state to be gc'd | 13:10 |
| hazmat | and the b) multi-node transaction capabilities are only exposed as of zk 3.4 | 13:10 |
| rog | i was just wondering if the "remove your own garbage" option was generally viable | 13:11 |
| rog | of course, you'd need a GC anyway in case the connection failed halfway through, leaving the garbage around. | 13:11 |
| hazmat | rog, indeed i did mean the post clean up of every state mod api having a parallel cleanup api is rather a large code burden | 13:11 |
| hazmat | rog, indeed | 13:11 |
| rog | hazmat: how common is conflict anyway? | 13:13 |
| rog | hazmat: i'd guess it is currently vanishingly rare, but perhaps people will start doing more concurrent topology mods in the future | 13:13 |
| hazmat | rog, at the moment extremely rare, its more that the system was designed for concurrency, in practice we don't really have it outside of someone using the cli programmatically | 13:14 |
| hazmat | there are lots of tests around concurrent changes in the code base | 13:14 |
| rog | hazmat: so GC is more of an academic argument for the time being | 13:14 |
| hazmat | rog, absolutely | 13:15 |
| rog | hazmat: and i'd guess the node sizes are pretty small, so the amount of garbage even in bad cases will be fairly smal | 13:15 |
| rog | l | 13:15 |
| hazmat | rog, its actually a non problem for the most part.. for large installs, the biggest issue is going to be node size limitations around topology | 13:15 |
| hazmat | which we can alleviate for 10k nodes + via compression | 13:16 |
| rog | hazmat: i was about to suggest that | 13:16 |
| hazmat | rog, its potentially an issue for large and long lived installations over time, all zk nodes are effectively held in ram | 13:16 |
| hazmat | but the per garbage overhead is on the order a few hundred bytes | 13:16 |
| hazmat | the gc algorithm and impl is also pretty trivial | 13:17 |
| rog | maybe just a way to manually initiate GC would be sufficient | 13:17 |
| hazmat | yeah.. or just another agent or fold into an existing privileged one (provisioning i suppose) | 13:18 |
| rog | another very simple agent seems fine. sleep for a day, have a look, GC as necessary, repeat | 13:18 |
| rog | but i guess provisioning is already doing a kind of GC by examining running nodes and squaring that with desired topology | 13:19 |
| rog | hazmat: anyway, thanks, that's been useful | 13:20 |
| hazmat | rog, indeed it is, though that's a different sort of gc.. resource gc, vs state | 13:33 |
| hazmat | rog, did you ever review go-new-revisions.. https://code.launchpad.net/~niemeyer/juju/go-new-revisions/+merge/78728 | 13:46 |
| hazmat | ah.. i guess so | 13:46 |
| rog | i'm not sure gustavo saw my response | 13:48 |
| hazmat | rog, hmm.. yeah. not sure.. i just pushed into the approved queue, he'll look at it prior to merge | 13:53 |
| hazmat | rog, wrt to https://code.launchpad.net/~rogpeppe/juju/go-juju-initial-ec2/+merge/82669 it doesn't appear that the changes that address william's comments have been pushed | 14:01 |
| rog | hmm, i thought i had | 14:01 |
| hazmat | rog, nevermind.. i see the issue now.. its an entirely new review | 14:02 |
| hazmat | not linked to the old review | 14:02 |
| rog | hazmat: yeah, and i actually have to create another one too, as it has the wrong target | 14:02 |
| rog | and i can't do resubmit because of an lp bug | 14:03 |
| rog | sigh | 14:03 |
| hazmat | rog, yeah.. i was just noticing that | 14:03 |
| hazmat | its odd | 14:03 |
| hazmat | i don't even see the resubmit link | 14:04 |
| hazmat | rog, did that get submitted with lbox propose -cr ? | 14:04 |
| rog | hazmat: yes. i'm not sure the heuristics for determining branch target are quite there yet | 14:04 |
| rog | hazmat: actually, i think i'd merged go-error-fixes into my trunk and then pushed. | 14:06 |
| rog | hazmat: so probably the trunk remembered the wrong target | 14:06 |
| rog | hmm | 14:06 |
| rog | problem is you can't specify an explicit lp: target - you have to specify the disk location of a branch, but then the lp: target is implicit | 14:07 |
| hazmat | fwereade_, one more review request, could you have a look at either of jim's branches in the queue, i'll ask bcsaller to look at the other | 14:07 |
| hazmat | so close to an empty queue ;-) | 14:07 |
| fwereade_ | hazmat, sure | 14:07 |
| rog | i still haven't worked out how to deal with the proliferation of bzr branches in a sane way | 14:07 |
| fwereade_ | hazmat, expose-refactor? | 14:08 |
| hazmat | fwereade_, which ever you prefer | 14:08 |
| hazmat | fwereade_, expose refactor is pretty straightforward its mostly a code transplant | 14:08 |
| hazmat | rog, you mean you prefer the hg/git many branches in one dir? | 14:08 |
| hazmat | rog, there are bzr plugins to emulate that (bzr-colo) | 14:09 |
| fwereade_ | hazmat, well then, I'll take a look at the other one, sounds a bit more interesting :) | 14:09 |
| rog | hazmat: i don't know. i never worked with many branches before, in one dir or not. | 14:09 |
| hazmat | rog, but else that's pretty bot standard vcs using feature branches | 14:09 |
| hazmat | s/bot/bog | 14:09 |
| rog | i think i get confused by the fact that there are (at least) three independently varying things about a branch: the uncommitted changes; the target; and the currently committed version. | 14:11 |
| rog | BTW james_w said the timeout bug may be this one: https://bugs.launchpad.net/launchpad/+bug/793830 | 14:12 |
| _mup_ | Bug #793830: Branch:+register-merge time out due to substring matching many tables <critical-analysis> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/793830 > | 14:12 |
| * hazmat finishes xapian indexing all the juju bugs | 14:14 | |
| hazmat | rog, i've only see lp issues for merges a handful of times, but they are annoying.. in this case i don't even see the link so i can't trigger the resubmit, except via url surgery | 14:15 |
| rog | hazmat: maybe only the author of a proposal can resubmit it | 14:16 |
| rog | i don't really see why you can't just edit the target | 14:16 |
| hazmat | rog, no i can resubmit other proposals normally | 14:16 |
| rog | i get this link: https://code.launchpad.net/~rogpeppe/juju/go-juju-initial-ec2/+merge/82669/+resubmit | 14:16 |
| rog | yeah, i still get the same time out | 14:18 |
| rog | yay! i made a new proposal and it kept the comments around anyway. | 14:26 |
| SpamapS | marcoceppi: for multiple IPs, randomly choose one | 14:52 |
| marcoceppi | SpamapS: cool | 14:59 |
| marcoceppi | I'll push these up in a bit for feedback, I don't want to get too deep | 15:03 |
| SpamapS | marcoceppi: technically your resolver should be randomizing multiple-IP's .. so you could probably just return the first one. | 15:03 |
| SpamapS | marcoceppi: are these bash functions that you have already used in multiple charms? | 15:04 |
| marcoceppi | SpamapS: Two were, the IP one I just made | 15:04 |
| marcoceppi | I retooled them though, to be more generic | 15:04 |
| SpamapS | marcoceppi: I can make use of the IP one in the ceph charm | 15:05 |
| marcoceppi | cppl | 15:06 |
| marcoceppi | cool* I'll start weeding through charms in the store to see what other functions I can abstract | 15:06 |
| marcoceppi | then I'll just write the equivalent functions in Python | 15:07 |
| SpamapS | ehh | 15:07 |
| marcoceppi | ruby, php, etc | 15:07 |
| SpamapS | wait wait wait | 15:07 |
| marcoceppi | waiting | 15:07 |
| SpamapS | Lets not reinvent configuration management. :) | 15:07 |
| marcoceppi | oh? | 15:08 |
| SpamapS | The idea is to take stuff that we can clearly see has been copy/pasted between charms, and put it into charm-helper | 15:08 |
| marcoceppi | ah | 15:08 |
| SpamapS | Not to build a new config management solution. :) | 15:08 |
| SpamapS | I mean | 15:08 |
| SpamapS | go ahead if you really want to! | 15:08 |
| SpamapS | But it could get really big, really fast, and I'd like to make sure it stays focused on things that "many" charms can use, not just a few. :) | 15:08 |
| marcoceppi | aye | 15:09 |
| marcoceppi | I tend to jump ahead rather quickly :) | 15:09 |
| SpamapS | really? | 15:09 |
| SpamapS | hadn't noticed | 15:09 |
| SpamapS | +1! | 15:09 |
| SpamapS | (I tend to overuse the !) | 15:09 |
| jcastro | marcoceppi: hey does the think up charm work for you? | 16:22 |
| jcastro | I get that relationship error I put in the bug | 16:22 |
| marcoceppi | jcastro: It worked for me, there's a warning with charm proof but that warning is going away in the next build | 16:26 |
| marcoceppi | Let me find the bug... | 16:26 |
| jcastro | I wonder if I just hit "lxc weirdness" | 16:27 |
| jcastro | marcoceppi: do you have time to give the charm a review today? I figure with both you and mmims checking it we should be good | 16:27 |
| marcoceppi | yeah, it deployed fine - but I didn't get a chance to look into the code yesterday | 16:28 |
| jcastro | nice nice! | 16:28 |
| jcastro | I think they had problems with their ec2 launcher. | 16:30 |
| jcastro | I can't find it on their site anymore. | 16:30 |
| marcoceppi | jcastro: room for Juju to rule! | 16:30 |
| jcastro | this will be nice for them. :) | 16:30 |
| SpamapS | We should add charm bugs to the bot | 16:32 |
| marcoceppi | jcastro: https://bugs.launchpad.net/charm-tools/+bug/893363 | 16:32 |
| _mup_ | Bug #893363: charm proof should not warn on a relation without hooks <Juju Charm Tools:Triaged> < https://launchpad.net/bugs/893363 > | 16:32 |
| jcastro | @marcoceppi when you investigate adding AU questions to the bots in IRC, see if we can get for example juju tagged questions mentioned by the bot in here. | 16:33 |
| jcastro | that would be jawesome. | 16:33 |
| jcastro | <--- off to lunch | 16:33 |
| jcastro | SpamapS: if mims pops in before I get back can you poke him to review the thinkup charm? | 16:34 |
| jcastro | I'm dying to get with upstream on this one | 16:34 |
| SpamapS | jcastro: mmkay | 16:36 |
| m_3 | hey... here... just in a meeting on another channel | 16:37 |
| m_3 | yesterday george was going to go off and add in postfix... I'll check status of the charm in a bit | 16:37 |
| _mup_ | Bug #894060 was filed: cannot restart unit agent (no unit workflow restart transition) <juju:In Progress by fwereade> < https://launchpad.net/bugs/894060 > | 16:39 |
| marcoceppi | jcastro et al: where is the bot's code? | 16:43 |
| SpamapS | m_3: I was thinking about that.. if the local charm just needs to send mail.. ssmtp would be one option | 16:43 |
| m_3 | SpamapS: I think it's gotta receive too... account validation | 16:46 |
| m_3 | not sure though... didn't get that far with george | 16:46 |
| m_3 | if it's just send it's a _much_ simpler dep | 16:46 |
| SpamapS | oh that can be much more difficult | 16:48 |
| SpamapS | domains.. mx's.. meh meh meh | 16:48 |
| m_3 | SpamapS: phracking nightmare | 16:50 |
| m_3 | staying off of blacklists is the hardest part | 16:50 |
| SpamapS | on ec2 most IPs get blacklisted pretty fast from what I understand. | 16:51 |
| SpamapS | which is why they have the email api | 16:51 |
| mainerror | jcastro: That would be amazing! I have the juju and charms tag set as mail subscription. | 16:57 |
| fwereade_ | hazmat, jimbaker, bcsaller: standup? | 17:00 |
| hazmat | fwereade_, indeed | 17:00 |
| hazmat | jimbaker, bcsaller, fwereade_ invites out | 17:03 |
| mainerror | The juju documentation could use a common errors section, possibly linked to Ask Ubuntu questions with an answer to given problem or error. | 17:04 |
| jimbaker | just saw the notice re standup, sounds good | 17:11 |
| m_3 | hazmat: build was missing libprotobuf-c... I'm adding an explicit dep to the control file and trying again. | 17:12 |
| hazmat | fwereade_, bcsaller woot! new record 5m32s | 17:13 |
| fwereade_ | go us! | 17:13 |
| marcoceppi | So, this is what I've got so far for charm-helper lp:~marcoceppi/charm/oneiric/charm-helper/trunk | 17:13 |
| marcoceppi | I couldn't think of a better place to push it to | 17:14 |
| hazmat | m_3, if it succeeds would you mind moving it into a dedicated ppa | 17:14 |
| hazmat | m_3, i'm always nervous grabbing stuff from ppas with unrelated packages | 17:14 |
| marcoceppi | er: https://code.launchpad.net/~marcoceppi/charm/oneiric/charm-helper/trunk | 17:14 |
| jimbaker | hazmat, looks like i saw the closing end of the standup. better sync next time | 17:14 |
| m_3 | hazmat: sure thang | 17:14 |
| hazmat | i ended up using an html 5 timer.. couldnt find a decent app in the repos.. for a count down timer.. http://helvetimer.com/ | 17:14 |
| hazmat | jimbaker, yeah.. trying to keep them short and sweet and on the dot.. wasn't much to miss | 17:15 |
| jimbaker | hazmat, sounds like a good plan. i'm definitely up for on the dot, for the next one on monday | 17:16 |
| jimbaker | i'm making good progress on the ssh key mgmt is my standup report | 17:16 |
| hazmat | jimbaker, cool | 17:16 |
| * jcastro returns from chow | 17:26 | |
| jcastro | hey m_3 | 17:26 |
| jcastro | he updated the charm | 17:26 |
| jcastro | and is doing the first thing you mentioned, wrt. debconfig postfix | 17:26 |
| rog | in bzr, is there a way i can change a bogus message on an old commit? (i presume not, but you never know...) | 17:27 |
| hazmat | rog, no | 17:27 |
| m_3 | jcastro: cool, I'll do a review | 17:27 |
| hazmat | rog, bzr has immutable history view, bzr rebase is the extent of playing with it that i'm aware of | 17:28 |
| rog | hazmat: darn. a few days ago i ran commit in the wrong directory... i knew i'd run it *somewhere* (because i had to commit again) but i've only just discovered where... | 17:28 |
| hazmat | er. bzr rewrite plugin | 17:28 |
| hazmat | rog, IFF you haven't pushed it yet, you can uncommit | 17:29 |
| hazmat | but you have to wind down the stack | 17:29 |
| rog | hazmat: i've three commits sitting on top of it... | 17:29 |
| hazmat | rog you could try.. bzr uncommit, bzr shelve --all -n "top"... if its really important.. alternatively you can commit the inverse diff on that dir | 17:30 |
| rog | i guess i theoretically i could encode each delta as a patch, then wind it forwards using the patches. | 17:30 |
| hazmat | rog, ie bzr diff -r -2..-3 | patch -p0 | 17:31 |
| marcoceppi | m_3: The charm doesn't check thinkup.zip against any hash, since it's a git repository - would it be better to just have it get cloned instead? | 17:31 |
| m_3 | marcoceppi: no difference from a security-standpoint I think | 17:34 |
| jcastro | hazmat: hey does cs:charmname work yet? | 17:35 |
| jcastro | when deploying? | 17:35 |
| marcoceppi | m_3 couldn't you do a host fingerprint validation since git would clone via SSH? | 17:35 |
| marcoceppi | The fingerprint is far less likely to change compared to the hash of a tarbal | 17:36 |
| m_3 | marcoceppi: yes, if you're going over ssh... maybe something similar when cloning over ssl | 17:36 |
| m_3 | haven't looked at what the git client does with an ssl url... i.e., does it at least verify the cert's ok? | 17:37 |
| marcoceppi | I don't know, let me check | 17:38 |
| SpamapS | marcoceppi: files fetched over ssh with a static key counts as cryptographically verified. | 17:42 |
| SpamapS | m_3: most cmdline tools seem to ignore PKI and just accept any old cert | 17:42 |
| marcoceppi | SpamapS: Cool, too bad Github doesn't have anonymous SSH Read access | 17:42 |
| m_3 | SpamapS: ok | 17:42 |
| * m_3 looking at what the actual charm is doing now | 17:43 | |
| SpamapS | marcoceppi: the alternative is to embed the zip file in the charm, and verify it by hand. | 17:43 |
| SpamapS | Oo | 17:43 |
| SpamapS | you know.. charm get/charm getall should really verify the charms | 17:43 |
| SpamapS | I mean, we already talk to launchpad w/ https.. | 17:44 |
| SpamapS | and/or ssh | 17:44 |
| SpamapS | so I guess its not that critical | 17:44 |
| m_3 | marcoceppi: do you have a snippet of hash-verification of a payload? | 17:51 |
| marcoceppi | Yeah | 17:52 |
| marcoceppi | m_3: It's wrapped into "get_file" http://bazaar.launchpad.net/~marcoceppi/charm/oneiric/charm-helper/trunk/view/head:/net.sh | 17:52 |
| m_3 | gracias! | 17:53 |
| hazmat | jcastro, no the charmstore is not operational yet | 17:54 |
| jcastro | hazmat: is there a tracking bug for that I can follow along with? | 17:56 |
| hazmat | jcastro, https://blueprints.launchpad.net/juju/+spec/formula-store | 17:58 |
| jcastro | ta | 17:58 |
| mainerror | Alright. Quick question. In my weird logic, when both of my services, in this case mediawiki and mysql have the status running and have a working relation then I should be able to reach the mediawiki instance using it's public IP address. Right? | 17:58 |
| jcastro | juju expose wordpress | 17:58 |
| jcastro | sorry, I mean mediawiki | 17:58 |
| jcastro | you need to explicitly expose the service to the outside world | 17:59 |
| mainerror | oh god | 17:59 |
| mainerror | How did I miss that? lol | 17:59 |
| mainerror | Thanks. :D | 17:59 |
| jcastro | hey, what did it return after you inputted that? | 17:59 |
| mainerror | 2011-11-23 18:59:16,982 INFO Service 'mediawiki' was exposed. | 18:00 |
| mainerror | 2011-11-23 18:59:16,985 INFO 'expose' command finished successfully | 18:00 |
| mainerror | mhm | 18:00 |
| mainerror | I should probably mention that I'm running it off a local provider. | 18:01 |
| mainerror | What is funny is that the public address I get is not on the same subnet. | 18:02 |
| marcoceppi | mainerror: It's probably for the virtual network interface created on your local machine | 18:02 |
| jcastro | yeah | 18:02 |
| mainerror | Oh. | 18:03 |
| SpamapS | mainerror: yeah it should be 192.168.122.xx .. | 18:03 |
| mainerror | Indeed. | 18:03 |
| jcastro | "Service 'mediawiki' was exposed on 192.168.122.xxx" would be way more useful, I hate having to go back in my status and find the right IP | 18:04 |
| * jcastro goes to file a bug | 18:04 | |
| * mainerror will confirm the bug! | 18:04 | |
| SpamapS | +1 from me too, should be easy | 18:04 |
| mainerror | So basically I have no way to access my mediawiki instance? | 18:06 |
| _mup_ | Bug #894094 was filed: "juju expose" should tell me exactly where a service is exposed. <juju:New> < https://launchpad.net/bugs/894094 > | 18:07 |
| marcoceppi | m_3: SpamapS it appears git uses curl and does validate SSL certificates | 18:07 |
| m_3 | mainerror, you should be able to open 192.168.122.xx (whatever status tells you) in a browser and see mediawiki | 18:07 |
| marcoceppi | However, couldn't someone still perform a man-in-the-middle attack even through SSL? | 18:08 |
| mainerror | Should I go ahead and confirm that bug? | 18:09 |
| mainerror | Never mind. :) | 18:10 |
| === PandorBox is now known as MrDerp | ||
| mainerror | Mhm, I can't access my mediawiki instance. | 18:10 |
| === MrDerp is now known as MisterDerp | ||
| m_3 | mainerror: 'juju -elocal status' should show an address associated with the mediawiki unit... (also if it's started or not) | 18:16 |
| jimbaker | zookeeper 3.4.0 was just released | 18:16 |
| jcastro | m_3: ok, so I can get to thinkup, everything worked once I did the :db thing | 18:19 |
| mainerror | m_3: The address I get is 192.168.122.80, my subnet is 192.168.0.x. | 18:19 |
| jcastro | m_3: and according to the machine log it sent the mail, just waiting for it now, then I'll bang on the service a bit. | 18:19 |
| mainerror | Status is up, started and exposed. | 18:20 |
| mainerror | I mean state, relation state and exposed state respectively. | 18:20 |
| m_3 | mainerror: nice, ok... when you open 192.168.122.80 in a browser? | 18:22 |
| mainerror | It times out after some time. | 18:23 |
| m_3 | if that's no good, then 'ping -c4 192.168.122.80' | 18:24 |
| mainerror | 100% packet loss. | 18:24 |
| m_3 | what does 'juju ssh mediawiki/0' give you? | 18:25 |
| mainerror | The machine juju runs on is a VirtualBox instance of Ubuntu 11.10 Server with a bridged interface. | 18:25 |
| m_3 | ah, thanks... | 18:25 |
| m_3 | are you running the cli from the virtualbox instance? | 18:26 |
| mainerror | Yes. | 18:26 |
| mainerror | Well I'm connected to the VB instance via SSH. | 18:26 |
| m_3 | understood | 18:27 |
| jimbaker | jcastro, re bug 894094, i'm not certain if that's meaningful or not without the status. services are exposed, not individual machines, so potentially this could mean a large list. also it's possible that any corresponding ports have not yet been opened by the charm | 18:27 |
| m_3 | so I haven't seen juju local run on a bridged physical interface... it's always been a virtual bridge | 18:27 |
| _mup_ | Bug #894094: "juju expose" should tell me exactly where a service is exposed. <juju:Confirmed> < https://launchpad.net/bugs/894094 > | 18:27 |
| hazmat | mainerror, the wordpress instance is only accessible to the local machine | 18:28 |
| jcastro | marcoceppi: aha, that's why I got the thinkup error, the hook isn't idempotent, but it looks like m_3 caught that in the review | 18:28 |
| hazmat | mainerror, you'd have to route the bridge on the local machine to make it accessible to other machines on the net | 18:28 |
| mainerror | mhmm, I'll try lynx on that IP from the VB instance. | 18:28 |
| hazmat | mainerror, its mainly intended as a development tool for well local development | 18:28 |
| m_3 | mainerror: from your VirtualBox instance (hereafter deemed "host")... you should see a libvirt std network setup... virbr, dnsmasq, etc | 18:29 |
| mainerror | So basically I should run juju on my machine directly or on a normal desktop install on the VM. | 18:29 |
| m_3 | ah, right... you can also forward a port... something like 'ssh -L8888:192.168.122.80:80 VirtualBoxAddress' from your base machine | 18:30 |
| mainerror | hmm, that sounds like a good plan. | 18:30 |
| m_3 | but should be able to tell pretty quickly from the cli... 'curl 192.168.122.80' or something similar | 18:31 |
| mainerror | Whoops! Alright. I've just tried lynx on that IP. | 18:32 |
| mainerror | Got a 500 Server error from mediawiki. | 18:32 |
| mainerror | But it is deployed. :) | 18:32 |
| m_3 | nice! | 18:32 |
| mainerror | Alright. Here is what I'll do next. I'll just install juju directly on my machine and work from there. :D | 18:33 |
| mainerror | Less complexity. | 18:34 |
| m_3 | mainerror: yeah, that's probably the best plan | 18:34 |
| m_3 | it doesn't bite | 18:34 |
| mainerror | Indeed. | 18:34 |
| m_3 | I typically work in VMs as much as possible myself, but lxc runs fine as long as you're setup is happy with libvirt networking | 18:35 |
| m_3 | s/you're/your/ :) | 18:35 |
| * m_3 food | 18:36 | |
| mainerror | I don't have any kind of special setup so in theory there should be no problem. | 18:36 |
| mainerror | Thanks for your help! :) | 18:36 |
| marcoceppi | jcastro: Cool, good to know | 19:10 |
| hazmat | hmm.. would be nice to get a vpn charm to make that scenario a little easier | 19:23 |
| jcastro | somoeone on my blog had an awesome charm idea | 19:23 |
| jcastro | an ubuntu mirror charm | 19:23 |
| jcastro | "run this on an m1.large, then pay your bill." | 19:23 |
| SpamapS | Hmm.. | 19:25 |
| SpamapS | does that person know that Ubuntu maintains full mirrors in EC2 already? | 19:25 |
| SpamapS | in every availability zone | 19:25 |
| jcastro | well, for internal reasons | 19:26 |
| jcastro | though, I suppose with orchestra you wouldn't really need that | 19:26 |
| SpamapS | It would actually be really cool for orchestra | 19:26 |
| SpamapS | most places want a local mirror that they can control | 19:26 |
| jcastro | right | 19:26 |
| jcastro | and | 19:26 |
| jcastro | ubumirror is packaged | 19:26 |
| jcastro | it really just needs to be installed and run | 19:26 |
| * jcastro pencils himself in for this one since it's simple | 19:27 | |
| SpamapS | juju set local-mirror releases="lucid precise" | 19:27 |
| jcastro | I will finish my Alice IRC today | 19:27 |
| SpamapS | Alice the IRC bot? | 19:27 |
| jcastro | web hosted irc | 19:28 |
| jcastro | I saw people asking for a ZNC service for work | 19:28 |
| jcastro | I am like, forget that, I want a web client | 19:28 |
| SpamapS | Oh.. there used to be an IRC bot that was slightly smarter than a tic-tac called Alice | 19:28 |
| mainerror | There is also that creepy server (AI control) of the Umbrella Corporation hive that was called Alice. That creepy little girl. | 19:36 |
| mainerror | We definitely don't need a Charm for her! | 19:36 |
| jcastro | https://www.usealice.org/ | 19:38 |
| marcoceppi | jcastro: So it's irccloud but I host it? | 19:43 |
| mainerror | irccloud is awesome! | 19:47 |
| marcoceppi | Where is the charm-tools package? | 19:59 |
| m_3 | marcoceppi: https://code.launchpad.net/charm-tools | 20:01 |
| jcastro | marcoceppi: yeah, I like it better than irccloud actually | 20:14 |
| marcoceppi | m_3: Thanks! | 20:14 |
| SpamapS | marcoceppi: do you like that idea, to put the helpers in charm-tools? | 20:34 |
| SpamapS | marcoceppi: I figure it makes sense .. they're quite related | 20:34 |
| marcoceppi | I'm fine with that. Does charm-tools get pulled into the environment at all on deploy? | 20:50 |
| marcoceppi | SpamapS: What I mean is, will we still have to copy/paste these functions out or is there a way we can have them float in the env? | 20:50 |
| SpamapS | no, but we'll make these separate packages from charm-tools | 20:50 |
| SpamapS | They'll jus thave to be part of the install hook. | 20:51 |
| SpamapS | apt-get install charm-helper-sh | 20:51 |
| marcoceppi | ah, right gotchya | 20:51 |
| marcoceppi | Yeah, good idea about the namepsaceing too | 20:52 |
| SpamapS | marcoceppi: I'd suggest branching charm-tools, and submitting a merge proposal. I'll review ASAP | 20:57 |
| marcoceppi | SpamapS: Yeah, that's what I'm doing now | 20:59 |
| jcastro | m_3: hypothetically, what kind of charm would use db-admin? | 21:05 |
| marcoceppi | phpmyadmin maybe? | 21:05 |
| mainerror | phpPgAdmin for PostgreSQL | 21:06 |
| jcastro | ah ok, now that's obvious to me | 21:07 |
| SpamapS | jcastro: I believe cloudfoundry also needs root | 21:08 |
| SpamapS | jcastro: since it has to create multi-tenant databases.. it pretty much pwns the box | 21:08 |
| * jcastro nods | 21:08 | |
| jcastro | SpamapS: I don't like that I have to care when executing | 21:08 |
| jcastro | I'd rather have db be the default | 21:09 |
| jcastro | and for the services that need that stuff then explicitly mention that | 21:09 |
| jcastro | but I don't feel strongly enough about it to complain | 21:09 |
| jcastro | other than to you I mean. :) | 21:09 |
| SpamapS | jcastro: one could argue that db-admin is a different interface | 21:10 |
| jcastro | I more mean default to one interface | 21:10 |
| SpamapS | jcastro: since db gives you just one database... | 21:10 |
| jcastro | "most charms will use db so be lazy here" | 21:10 |
| m_3 | jcastro: I think it's just a problem because mysql is so common in our examples | 21:11 |
| jcastro | yeah | 21:11 |
| jcastro | it's just I cringe every time our deploy command adds length | 21:11 |
| m_3 | but yeah, maybe worth splitting into a separate relation | 21:11 |
| marcoceppi | SpamapS: In regards to add-relationship, shouldn't juju see that the charm has no db-admin interface requirement and only show the ambiguity message when it's ambiguious? | 21:11 |
| * mainerror nods | 21:12 | |
| m_3 | sorry, I mean split into a separate interfaces | 21:12 |
| jcastro | SpamapS: so basically my complaint is that makes "juju deploy cs:mysql" longer than it needs to be ... | 21:12 |
| SpamapS | marcoceppi: they're both interface: mysql | 21:12 |
| marcoceppi | Err, the db-admin relationship | 21:13 |
| SpamapS | I think its actually a bug in the mysql charm | 21:13 |
| SpamapS | we should fix it | 21:13 |
| SpamapS | make it interface: mysql-root | 21:13 |
| marcoceppi | Ah, I see. Good alternative | 21:14 |
| SpamapS | I don't see any downside to that | 21:14 |
| SpamapS | things either need root, or they don't | 21:15 |
| m_3 | +1 | 21:16 |
| * SpamapS feels like the Charm Ceaser today.. "MAKE IT SO!, and bring me WINE!!" | 21:17 | |
| * SpamapS wanders off to find food | 21:17 | |
| * marcoceppi wanders off to find wine | 21:17 | |
| jcastro | SpamapS: ok I'll file that badboy | 21:19 |
| marcoceppi | So, what's the safest License for this charm-helper? MIT? | 21:54 |
| mainerror | WTFPL. :D | 21:55 |
| mainerror | It does really exist, no joke. .P | 21:55 |
| marcoceppi | I googled just to be sure | 21:56 |
| jcastro | hazmat: hey before I file a bug humor me for a second | 21:58 |
| * hazmat laughs @ jcastro | 21:58 | |
| jcastro | hazmat: so at UDS I saw juan's .juju dir, he had a bunch of environment.yamls | 21:58 |
| * hazmat nods | 21:58 | |
| jcastro | and would symlink what he wants to use | 21:58 |
| jcastro | how about a convenience switch function | 21:58 |
| jcastro | like: | 21:58 |
| hazmat | jcastro, -e | 21:59 |
| jcastro | son of a .... | 21:59 |
| mainerror | :D | 21:59 |
| jcastro | hazmat: how long has that been there? | 21:59 |
| jcastro | you know what, don't tell me | 22:00 |
| mainerror | hehe | 22:00 |
| marcoceppi | jcastro: I thought you showed me that? Maybe it was m_3. I've got two environments in my file, EC2 and local | 22:01 |
| hazmat | jcastro, that allows picking from multiple envs in a single file, you can set a default: ${env-name} label in the file to set a default one (sans -e usage).. the multiple file thing is useful for demos to avoid showing your passwords on screen. | 22:02 |
| jcastro | aaaaaah. | 22:03 |
| SpamapS | marcoceppi: GPLv3 is what charm-tools is under.. simpler if you just keep it all charm-tools. *using* something is not *linking* to it. | 22:04 |
| marcoceppi | SpamapS: Thanks, easy enough | 22:05 |
| SpamapS | hmm | 22:05 |
| SpamapS | the python bit may actually be linking if we do it | 22:05 |
| SpamapS | so LGPL might be more appropriate for that | 22:05 |
| SpamapS | but, we'll cross that bridge when we come to it. | 22:05 |
| marcoceppi | fair enough | 22:09 |
| marcoceppi | I really wish I could figure this Ondina name thing out | 22:10 |
| marcoceppi | on LaunchPad, any idea where I could start to diagnose this? | 22:11 |
| jcastro | what, your display name? | 22:11 |
| marcoceppi | Yeah, I made sure whoami and launchpad login both go to marcoceppi account, but it keeps showing Ondina as the name | 22:12 |
| james_w | marcoceppi, it's because the ondina team has marco@ondina.co set as the contact address | 22:20 |
| james_w | and that's the address that you are committing the revisions in bzr as I expect | 22:20 |
| marcoceppi | james_w: So? My commits come from marco@ceppi.net | 22:21 |
| james_w | i.e. what bzr whoami says | 22:21 |
| james_w | oh, hmm | 22:21 |
| marcoceppi | Marco Ceppi <marco@ceppi.net> | 22:21 |
| james_w | sounds like a Launchpad bug then | 22:21 |
| jcastro | m_3: SpamapS: http://dl.dropbox.com/u/5720/Screenshot%20at%202011-11-23%2017%3A21%3A00.png | 22:23 |
| jcastro | we should try to do an office hours in a hangout | 22:23 |
| marcoceppi | james_w: Probably, I'm checking it out in the launchpad room | 22:24 |
| m_3 | I like the iphone icon on there | 22:24 |
| hazmat | jcastro, what's the benefit of the hangout in this context/ | 22:27 |
| m_3 | jcastro: maybe let's see how irc goes first? | 22:28 |
| jcastro | m_3: yeah I was keeping an eye on it | 22:29 |
| jcastro | hazmat: more personal, high bandwidth for explaining concepts, etc. | 22:30 |
| mainerror | Oh that is Reto. :) | 22:31 |
| marcoceppi | SpamapS Seems odd, I probably shouldn't put a copyright on the net.sh charm helper, right? | 23:46 |
| SpamapS | marcoceppi: it should have a license/copyright header in the file | 23:46 |
| marcoceppi | this is what I have now | 23:46 |
| SpamapS | marcoceppi: push to a branch? | 23:47 |
| marcoceppi | http://paste.ubuntu.com/747686/ | 23:47 |
| marcoceppi | I don't want to stain the commit with a bad header :) | 23:47 |
| marcoceppi | Still really green when it comes to how licenses and copyrights work | 23:51 |
| SpamapS | marcoceppi: that header looks a little off, where did you get it? | 23:54 |
| marcoceppi | The internet: http://stackoverflow.com/q/153489/196832 | 23:55 |
| SpamapS | http://www.gnu.org/licenses/gpl-howto.html | 23:55 |
| SpamapS | marcoceppi: heh, you just forgot the spacing. ;) | 23:56 |
| marcoceppi | Spacing is important? | 23:56 |
| SpamapS | For my eyes it is.. because otherwise I read every word and go "wtf? this SOUNDS ok" .. | 23:56 |
| SpamapS | :) | 23:56 |
| marcoceppi | So http://paste.ubuntu.com/747700/ ? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
