[00:13] m_3: sure, I'll take a look at it tomorrow. [00:13] SpamapS: around? [00:16] nijaba: thanks [00:16] well, maybe someone else can help me decide on this. I think I have found an easy way to trigger a copy to all peers from a confg-change event [00:16] My question is, how should I implement this: [00:17] 1/ sh_peer_rsync_replay: replays exactly the same copies that were done in the peer relation events [00:19] 2/ sh_peer_rsync sourcepath destpath: copy the given path(s) to all host that were done in the peer relation event [00:19] 3/ both? [00:50] nijaba: here now [00:51] SpamapS: here to. working on 3/ [00:51] SpamapS: here to. working on 3 [00:51] lots of lag.. [00:52] nijaba: so I think another way to look at it is that if we avoid ever calling relation-* in these peer functions, then we can use them anywhere.... [00:53] SpamapS: nope, that won't work. the initial copy needs to be through a handshake capable mechanism [00:53] nijaba: or another way to do it is to detect whether or not we're in a relation, if we are, cache the results of relation-* , and if we're not, use any cached results [00:53] oo.. I like that.. hmm [00:53] SpamapS: subsequent one can cache [00:53] Yeah, so if you haven't cached, just exit gracefully [00:53] yep [00:53] EAGAIN ;) [00:54] * SpamapS finds it interesting that we're running into all the same things one does with every event loop system [00:54] yup [00:55] nijaba: I'm just now opening up your branch for review :-P [00:56] * SpamapS curses the way his attention deficit "condition" has put his fingers in so many pies [00:56] SpamapS: cool. again, my first issue it the test_peer.sh which needs to run with sudo [00:56] nijaba: yeah, that has to be fixed [00:56] I'm 99.9% sure we can run sshd as whoever we want [00:57] SpamapS: the problem is not who, but how sshd handle certificates. Short of building a full chroot, I got stuck [00:57] nijaba: have you merged with trunk recently? I took a quick look and it looks like you didn't pull in the test reorg that I did. [00:58] SpamapS: yes, I have. let me check [00:59] SpamapS: looks like I may not have pushed the merge... [00:59] test_peer.sh is gone in lp:~nijaba/charm-tools/peer-scp [00:59] ah ok [01:00] SpamapS: nope, I forgot a bzr add [01:01] SpamapS: fixed now [01:01] and pushed [01:05] right thats still broken [01:06] how so? [01:06] oh its the sudo thing never mind ;) [01:06] running it in a sudo-less chroot it was not happy [01:06] nah, it's not :) [01:06] so you didn't want to just generate a key for the test, and use cmdline options to point sshd at it? [01:07] SpamapS: I tried... my problem was with the host keys [01:07] right thats what I mean [01:08] well, I did figure out how to point it to different host keys, not owned by root, so that it would not block the hanshake [01:08] this is what I was trying up to rev 102 [01:09] mchenetz: Wow, easy_install worked. [01:10] SpamapS: of before that.... [01:10] Evilbill: awesome [01:10] nijaba: I just did a ssh-keygen -t rsa -b 1024 -n -f /tmp/foobar/my_host_key , then sshd -o HostKey=/tmp/foobar/my_host_key -p 29292 .. and its working as I'd expect it to [01:11] Yeah, no kidding. :) Thanks for the work on that. [01:11] SpamapS: you are able to scp to it? [01:11] duh.... [01:11] evillbill: no prob… i am still refining the process [01:11] must have been something else [01:11] nijaba: trying that now [01:11] * nijaba slaps himself [01:11] nijaba: but I can ssh to it [01:12] SpamapS: if you can ssh, then there is no issue with the handshake [01:18] nijaba: so, its pretys imple really. You just have to generate the key, then add [localhost]:29292 right before the ssh-rsa in the key, and thats your known hosts file (-o UserKnownHostsFile=...) [01:18] typing accurately, however, not so simple. ;) [01:19] SpamapS: ah, that's why my handshake was failing.... thanks! I'll fix and re-submit. maybe not tonight though [01:19] why being the port num in the knowhosts [01:22] nijaba: because two sshd's can have different host keys [01:23] SpamapS: I did not think of that [01:23] SpamapS: thanks so much [01:25] nijaba: np, I'll try to look at the other stuff with a blind eye to the tests. :) [01:26] :) [01:40] hi SpamapS, did you see my reply to bug 906000 ? [01:40] <_mup_> Bug #906000: opens new connection for each charm that is fetched < https://launchpad.net/bugs/906000 > [02:11] * nijaba falling asleep -> bed [04:55] <_mup_> juju/ssh-known_hosts r452 committed by jim.baker@canonical.com [04:55] <_mup_> Mock bootstrap [05:30] <_mup_> juju/ssh-known_hosts r453 committed by jim.baker@canonical.com [05:30] <_mup_> Cleanup of mocking [10:05] m_3: review of juju-classroom done [12:01] Helloooo [12:01] Ho ho ho [12:01] Oh, wait.. not there yet.. [13:13] juju works with Lucid too? correct? [13:33] SpamapS: Have you been testing it in Lucid? [13:34] niemeyer: i have found a friend who wants to try juju on eucalyptus :D [13:34] koolhead11: Ah, nice! [13:34] koolhead11: That should work, I think [13:35] i asked him to get it from PPA [13:35] niemeyer: am on it. once we get success will pastebin steps sumwer and later push it on documentation :D [13:37] koolhead11: Sweet! [13:48] hello guys [13:48] im having this error on juju bootstrap command -- Failure: twisted.internet.error.TCPTimedOutError: TCP connection timed out: 110: Connection timed out. [13:48] niemeyer: tyska is testing eucalyptus/juj [13:48] on lucid [13:48] tyska: Looks like a timeout indeed.. :-) [13:49] tyska: It's unable to communicate with the server [13:50] niemeyer: but my machine has internet access, what could be the problem then? [13:51] tyska: can you see /home//juju/enviornments.yaml file [13:51] you have to modify it for your local settings :P [13:51] koolhead11: what needs to be there? [13:51] 1 sec [13:52] koolhead11: i think i need to set type as ec2, not local [13:52] Sorry guys, I have a scheduled lunch and can't be late, but I'll be back later [13:52] koolhead11: beucause im trying to use juju with eucalyptus [13:52] niemeyer: np, im going to lunch too [13:52] koolhead11: i will be right back [13:52] tyska: k [13:59] tyska: http://paste.ubuntu.com/777428/ [14:20] im back [14:20] are u there koolhead11 [14:20] ? [14:20] yes [14:20] [19:29] tyska: http://paste.ubuntu.com/777428/ [14:21] yeah [14:21] will check this [14:24] after editing environments.yaml -- Connection was refused by other side: 111: Connection refused. [14:27] tyska: juju -v bootstrap [14:28] Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused. [14:28] it seems the clc of eucalyptus refused the connection, put i used the same access and secret key on credentials generated by euca_conf [14:28] *but [14:29] tyska: so see if your putting correct credentials [14:29] :d [14:29] already did it [14:29] the credentials are the same as eucarc [14:31] tyska: i dont see any other issue rather than wrong credentials. [14:31] me neither [14:32] =/ [14:32] tyska: how about the ec2 url path :P [14:32] ec2-uri: http://my.private.cloud:8773/services/Cloud s3-uri: http://my.private.s3:3333 [14:33] the same as in eucarc file [14:43] koolhead11: some good new? [14:49] tyska: tell me [14:49] koolhead11: ec2-urL instead of ec2-urI =) [14:49] koolhead11: no [14:49] koolhead11: false clue [14:50] koolhead11: but there something wrong, regardless the adress of ec2 and s3, anything i put there returns the same error [14:53] jimbaker: Can you please help tyska out? [15:02] nijaba: thanks! [15:04] m_3: np. sorry to be picky. hope not to be wrong too :) [15:06] nijaba: hey... no problem at all [15:07] most of this is really old from the byobu-classroom charm and needs to be updated [15:07] it's good to catch both of them now [15:08] tyska: Can you please run the same command with strace, and send me the output? [15:09] niemeyer: ok [15:09] m_3: yep, I figured you inherited most of this from the original charm [15:09] nijaba: without looking too carefully :) [15:09] that's what the review process is for [15:10] +1 [15:13] niemeyer: here it is http://pastebin.com/txjnw0KK [15:15] tyska: Can you please run "telnet 10.0.0.125 80" on the same machine? [15:16] niemeyer: sure, but why on 80? [15:16] niemeyer: why not on 8773? [15:17] tyska: How does your configuration look like? [15:17] niemeyer: see it here http://paste.ubuntu.com/777428/ [15:18] niemeyer: im trying to configure juju with eucalyptus, then i change ec2-uri to my ec2_url which is http://10.0.0.125:8773/services/Eucalyptus [15:21] tyska: Good question.. apparently it's not where it is connecting.. [15:22] yeah [15:22] i saw in strace it trying to connect port 80, but i dont understood why [15:23] telnet on port 80 fails [15:23] but in 8773 works well [15:23] tyska: Btw, the URL you paste above is not the URL that is in the configuration [15:25] niemeyer: yeah i know, that pastebin is just a template [15:25] i changed that for my cloud url [15:26] tyska: Yeah, it's just that I have to trust the information you provide [15:26] tyska: Otherwise we'll get nowhere :) [15:26] hehe, ok, let me paste my config file [15:27] http://pastebin.com/KNF8g9ph [15:31] tyska: Ok, can you please run the command again, while running this in a separate terminal: sudo tcpdump -vv -i any 'host 10.0.0.125' [15:31] tyska: I suspect it won't help much, but at least we'll kill another possibility [15:32] niemeyer: before that i wanna know a thing [15:32] niemeyer: im running this command from the machine 10.0.0.125 [15:32] niemeyer: could i run this from another machine that is in the same subnet right? [15:33] tyska: I'd prefer if you run it in the same environment [15:33] tyska: can you successfully spin up instances using just euca-tools? i.e., no juju [15:33] tyska: and are you in one of the 'MANAGED' networking modes? [15:33] m_3: juju seems to be talking to the wrong port for whatever reason [15:33] m_3: eucalyptus working fine, using managed novlan [15:34] niemeyer: in fact, i tried to do from another machine, and the error changed, but the machine connected in the port 8773 [15:34] cool just making sure there's a baseline [15:34] niemeyer: wanna u see the strace or wanna keep trying from the machine 10.0.0.125? [15:35] tyska: The new error please [15:35] tyska: It connects to the right port here, FWIW [15:35] tyska: Which juju version are you running? [15:36] 0.5 i think [15:36] tyska: The full version you get out of dpkg -l [15:37] 0.5+bzr432 on 10.0.0.125 machine and 0.5+bzr398 on my notebook [15:38] niemeyer: http://paste.ubuntu.com/777552/ the connection error from my notebook [15:38] same juju config file [15:43] hmmm [15:43] that seems *odd* [15:43] you got the PPA version on the machines, but the archive version on your notebook [15:44] tyska: or are the notebook and the 10.0.0.125 machines totally unrelated? [15:44] SpamapS: unrelated [15:44] ok [15:45] SpamapS: but the clc (10.0.0.125) is lucid, with ppa added via add-apt-repository, and my notebook is oneiric without ppa [15:45] oneiric repositories already have juju package [15:45] jelmer: I did see your reply to bug 906000 .. I am very far behind on replying to things. ;) I'll gather my thoughts on that soon. [15:45] <_mup_> Bug #906000: opens new connection for each charm that is fetched < https://launchpad.net/bugs/906000 > [15:46] niemeyer: I have not been testing juju on lucid, no. (answering your question from backscroll...) [15:46] i dont know why the things simply dont work on the first time to me [15:46] tyska: Right, the PPA version is *a lot* newer and has a few bug fixes that you'll probably want. [15:47] SpamapS: thanks - no hurry, I just wasn't sure whether you'd seen it [15:47] SpamapS: but oddly the ppa version does not consider the port i put in the config file (8773) and try to connect into port 80 [15:47] SpamapS: the older version try to connect on the right port [15:48] tyska: I'm fairly certain the URL is just handed to a lower library, txaws [15:48] tyska: so what version of python-txaws do you have installed? [15:49] tyska: Can you please paste the normal output from the command you're running? [15:49] 0.0.1bzr-0juju92~lucid1 [15:49] niemeyer: in which machine? [15:50] SpamapS: 0.2-0ubuntu5 on my notebook [15:50] so perhaps txaws needs updating on lucid [15:53] tyska: did you do apt-get upgrade too [15:53] SpamapS: but from which repository? the lucid repositories are just showing 0.0.1 [15:55] koolhead11: already did [15:55] niemeyer: the error on my notebook is 500 internal server error [15:55] niemeyer: on the clc the error is Connection was refused by other side: 111: Connection refused. [15:56] tyska: Looks like Eucalyptus is failing on you [15:56] tyska: We're probably touching a bad edge there [15:57] niemeyer: euca commands works fine from my notebook, eucalyptus is working fine [15:57] niemeyer: i can run new instances, see the resources available, create volumes and upload new images with no problem [15:58] tyska: 500 is an error from the server side [15:58] tyska: Please check out the logs [15:58] greetings [15:58] * hazmat catches up [15:59] you mean eucalyptus logs? [15:59] tyska: Yes, looks for the reason why it's returning a 500/internal error [15:59] niemeyer: there is no error on the logs [16:01] tyska: Maybe on S3 then [16:02] We haven't tested against euca in a while, but I thought I remembered us doing it at least a couple of times before OpenStack was usable. [16:02] tyska: Can you please paste the actual error? [16:03] this is debugging juju with eucalyptus? do we have a traceback from juju -v bootstrap? [16:04] hazmat: He's about to paste it [16:04] hmm.... yeah.. that looks like an s3 error [16:04] niemeyer: 500 error is an auth error, maybe juju is not passing the keys in the right way [16:04] tyska: No, it's an internal error from the server [16:04] tyska, the server error would be in the walrus logs [16:04] tyska: Can you please paste the actual error? [16:05] 500 internal server error [16:05] walrus does not have log [16:05] just cloud-error.log [16:05] and there is no error in this log [16:07] if i try to connect to the url from my browser, i get 500 internal server error [16:07] i think juju is trying to do that without using the access and secret keys [16:07] tyska: 500 is not an authentication error.. [16:08] tyska: and juju does use the keys to access S3, otherwise nothing else would work [16:09] walrus and clc are on the same machine [16:09] tyska: You can dump the TCP session with tcpdump if you want to check what's going through the wire [16:09] tyska: As I suggested earlier [16:09] niemeyer: sure [16:09] from my notebook or clc machine? [16:10] tyska: From the place you want to debug :) [16:11] ok [16:12] tyska: rushing home. hope it works. :) [16:12] koolhead11: ok, tks for the help [16:13] niemeyer: V [16:13] http://paste.ubuntu.com/777594/ [16:16] tyska: That's not printing the actual packets, sorry.. let me check which option we need [16:19] tyska: -X [16:19] tyska: Can you please run the same experiment again with -X in tcpdump, rather than -vv [16:19] niemeyer: sure [16:20] http://paste.ubuntu.com/777597/ [16:20] tyska: Btw, where are you located? [16:20] Brazil [16:21] tyska: Alright, that dump is useful.. let's see [16:21] tyska: Where? [16:21] tyska: I mean, where in Brazil? [16:21] Rio Grande do Sul, did you know Brazil? [16:21] tyska: I live about 60km from you [16:21] niemeyer: =O where are u? [16:22] tyska: Pelotas [16:23] niemeyer: are u brazilian? [16:23] tyska: Yep [16:23] niemeyer: hahaha then why are we talking in english? [16:24] tyska: Because that's the language that most people here understand [16:24] niemeyer: off course [16:24] niemeyer: where do you work? [16:25] tyska: I work at Canonical, on juju [16:25] niemeyer: cool [16:25] tyska: "ization:.AWS.WKy" [16:25] tyska: You see that in the dump? [16:25] tyska: It's juju sending the auth keys [16:25] yeah [16:26] tyska: And here is Walrus blowing up: "HTTP/1.1.500" [16:26] tyska: it was doing a GET: "GET./juju-f8" [16:27] tyska: We used to have someone from Eucalyptus here.. hold on [16:27] niemeyer: but this reply is not from walrus [16:28] niemeyer: it is the reply from services/Cloud, i can see it if i access from my browser [16:28] tyska: Is it not? [16:28] What's sitting at clc.cloud.c3.furg.br.8773? [16:28] niemeyer: if i access services/Walrus i get another error response, but in xml format [16:28] both clc and walrus [16:29] tyska: That sounds suspect.. [16:29] tyska: You can't have the two processes listening on the same IP port [16:30] s/ip/tcp [16:30] it's make sense [16:31] but maybe there is just one process that handle with the requests [16:31] when you request services/Eucalyptus it sends you to clc, services/Walrus sends to Walrus [16:32] tyska: and what does "sends to Walrus" mean? [16:33] i think its just a webservice handler listening the 8773 port [16:34] and when i say 'i think' it is because i dont know for sure [16:35] that redirect the requests to the right processes [16:35] tyska: Sorry, I don't get it.. services/Walrus sends you to what? [16:35] to the walrus process [16:35] eucalyptus-walrus [16:36] niemeyer: see it here: http://paste.ubuntu.com/777617/ - this is the response when i acess 10.0.0.125:8773/services/Walrus [16:37] niemeyer: and this is the response if i access 10.0.0.125:8773/services/Walrus - Failure: 500 Internal Server Error [16:37] niemeyer: and if i acess just 10.0.0.125:8773 the answer is the error 500 too [16:38] tyska: You said you were using other tools, right? [16:38] tyska: Which tools were you using to interact with walrus? [16:39] tyska: i never did direct interactions with walrus, but node controllers need to access walrus to get the images to run instances [16:39] ops [16:40] niemeyer: [16:40] tyska: Perhaps it's just like you said.. walrus might be embedded within the HTTP server as a Java app [16:40] and walrus is used too, to upload images, which i did three times [16:40] tyska: Under a specific URL [16:40] niemeyer: I think its proxied [16:40] tyska: and I'm not quite sure juju, or other tools, handle it like that to be honest [16:40] tyska: perhaps try http://localhost:8773/services/{Eucalyptus,Walrus} from the clc directly? [16:41] but again, "i think" .. you probably need somebody with an actual clue at this point [16:41] m_3: hey, you fit that bill.. [16:41] m_3: already tried it [16:41] SpamapS: I don't think so.. I think it's all jars onto the java app server [16:41] Oh even more fun. :) [16:41] m_3: but in the clc i think i have another problem with juju, which is old version of python-txaws [16:42] tyska: Have you used s3cmd before? [16:42] tyska: ok, so I'd start with just getting s3curl or similar to work with the http://localhost:8773/services/Walrus [16:42] niemeyer: exactly [16:42] m_3: the ec2-uri is not correctly parsed from the config file [16:42] niemeyer: never used s3cmd before [16:42] m_3: Why is it not? [16:42] mchenetz: hey so I've incorporated bill's feedback into the OSX instructions [16:42] m_3: Seems to be working correctly so far.. [16:43] Sorry.. [16:43] tyska: Why is it not? [16:43] tyska: It seems to work well so far.. [16:43] tyska: The error is not related to the ec2-uri [16:43] jcastro: Sounds good… Evilbill installed successfully with Easy_install method [16:43] niemeyer: remember that in the first machine, the strace shows that it tying to connect to the port 80 [16:43] instead 8773 [16:43] tyska: It's quite possible that the problem is that txaws isn't handling the prefix /eucalyptus/Walrus correctly [16:44] tyska: This was strange, but we never got to know why that was happening [16:44] niemeyer: let me remove the prefix just to see it grabs the right port [16:44] mchenetz: did that permission problem he talked about end up being a real problem? [16:44] tyska: It's incorrect to say that ec2-uri isn't being parsed correctly, though.. we use it in other situations, e.g. to set different EC2 regions, and it actually works [16:44] mchenetz: I can widen the call for testing if you'd like [16:45] jcastro: Yes, i ask working on the permission problem. I created a VM to test with. [16:45] tyska: You also just pointed out you have an old version of python-txaws in that machine [16:45] definitely s3 usage supports ports, the url path suffix doesn't appear to have been tested previously though [16:45] tyska: Which is exactly what's used to access the services [16:45] jcastro: I am currently working on a mac app store version too... [16:45] hazmat: Yeah, it's probably it.. [16:45] mchenetz: ok so do you think you want more testers? [16:46] hazmat: I'd just like to check if walrus itself is working at that URL at all before spending any time on it [16:46] niemeyer, maybe.. its not clear walrus is fully functional in this installation [16:46] hazmat: It's at least answering at that URL, apparently [16:46] jcastro: Hold off for right now… I will update the script and then test again [16:46] * jcastro nods [16:46] hazmat: and, regardless, the URL juju is accessing is not prefixed [16:46] hazmat: as we can see in the dump [16:47] niemeyer: removing the suffix does not help, juju bootstrap keeps trying to connect to port 80 instead 8773 [16:47] hazmat: It's also suspect because it doesn't seem to be informing the bucket name [16:47] niemeyer: im saying in this specific case, the port in the config file is being ignorated [16:47] tyska: In your laptop it's not trying to connect to that URL [16:48] tyska: as we could see in the dump [16:48] niemeyer: in the laptop it is connecting to the right port [16:48] tyska: Right? [16:48] niemeyer: right [16:48] tyska: and in the one that is connecting to the wrong URL, you have an out of date python-txaws, right? [16:48] niemeyer: i was saying to m_3, that i cant test if localhost:8773 works, because for some reason it grabs the wrong port [16:48] niemeyer: yeah [16:49] tyska: Cool.. so all I'm saying we can't take any conclusions out of that [16:49] niemeyer: version is 0.0.1 instead 0.2, and that is probably the reason for the wrong parse [16:49] tyska: The first thing to put in your clc the same package versions you have in your other machine [16:49] s/to/is to/ [16:50] niemeyer: yeah, but how? since one is lucid and another is oneiric [16:50] niemeyer: there is no 0.2 package in the lucid repositories [16:51] tyska: Ok, there's an issue there then.. [16:51] tyska: But you don't need those packages in that machine [16:51] tyska: Just use your laptop [16:51] niemeyer: no problem [16:51] tyska: Everything juju needs will work fine that [16:51] way [16:51] as i sayd, i was just saying to m_3, that i cant test if localhost:8773 works, because for some reason it grabs the wrong port [16:51] tyska: What we have to sort out is why S3 isn't working [16:51] tyska: Well, the first thing anyway [16:51] in the clc machine [16:52] tyska: So.. can you please try with s3cmd? [16:52] niemeyer: we cant say S3 isn't working, at least yet [16:52] niemeyer: we need to use the s3cmd to know that for sure [16:52] tyska: We can say the S3 interaction between juju and walrus is not working [16:52] niemeyer: yeah, this we can [16:52] Good :) [16:53] tyska: So, please try s3cmd out.. or any other S3 client, for that matter, and see how it goes.. if it's working, we'll likely need to fix txaws to work with path prefixes [16:53] tyska: Thanks for debugging that, btw [16:53] niemeyer: ok [16:53] niemeyer: no problem, i thanks for the help [16:54] s3curl might be a little easier to configure for eucalyptus than s3cmd [16:55] both are covered in http://cssoss.wordpress.com/2010/05/10/eucalyptus-beginner%E2%80%99s-guide-%E2%80%93-uec-edition-chapter-6-%E2%80%93-storage%C2%A0management/ [17:00] thanks m_3, i was suffering to configure s3cmd [17:02] tyska: s3cmd is a pain [17:07] i cant find the package perl-Digest-HMAC [17:07] to install s3curl [17:09] tyska: apt-get doesn't have s3cmd? [17:09] tyska: usually its just 'sudo apt-get install s3cmd' [17:09] SpamapS: s3cmd yes, but it is complex to configurate [17:09] SpamapS: i just wanna a simple tool to test, it seems s3curl is simplest [17:11] tyska: libdigest-hmac-perl on lucid [17:12] m_3: tks [17:13] m_3: i already have this package installed, but im on oneiric (notebook) [17:16] tyska: Can't see how s3cmd is any worse to configure than any other alternative [17:17] tyska: You'll need access key, secret key, and the endpoints [17:17] on all of htem [17:17]