| ernop | hey guys, got a question - i had an AMI in one region and used cloudyscripts "copy AMI to another region" thing to copy it. but when I start the new instance, I can't connect - ssl times out. Is there some step i'm missing? I can start copies of it in the original region and connect no problem. | 03:58 |
|---|---|---|
| ernop | (and I am running a modified 10.10 server AMI) | 04:01 |
| SpamapS | ernop: my first question would be why are you using a modified AMI? (keep in mind, I'm a novice, but I only ever use cloud-config customized instances) | 06:46 |
| Makere | kind of lost of where to start to get an image dl'd from http://uec-images.ubuntu.com/releases/ to run | 07:13 |
| Makere | any ideas what I should check? | 07:13 |
| ernop | SpamapS - by modified I just mean that I have installed a bunch of my own stuff on it. Thing is, it worked in the original region. | 07:22 |
| SpamapS | Makere: meaning downloaded to run in UEC (as in, eucalyptus) ? | 07:40 |
| SpamapS | ernop: yeah, I think I'd do that by putting all of my stuff in a dir and tarring that dir up, or use a proper config management system like puppet/chef. | 07:42 |
| Makere | SpamapS: yes | 07:42 |
| Makere | and used the uec-publish-tarball | 07:43 |
| Makere | to push it there | 07:43 |
| Makere | fml | 07:53 |
| ernop | SpamapS ok, good idea. | 08:43 |
| === nijaba is now known as nijaba_afk | ||
| === nijaba_afk is now known as nijaba | ||
| Makere | So I tried creating a new uec image using this guide: http://cssoss.wordpress.com/2010/05/10/eucalyptus-beginner%E2%80%99s-guide-%E2%80%93-uec-edition-chapter-4-%E2%80%93-image%C2%A0management/ | 11:47 |
| Makere | the instances get stuck on pending, any troubleshooting tips? | 11:48 |
| Makere | why the store images run | 13:23 |
| Makere | but I can't get my own images to run | 13:23 |
| Makere | nor images from uec-images.ubuntu.com | 13:24 |
| Makere | ok | 13:43 |
| Makere | the problem I had was that it doesn't work if I bundle on cloud controller | 13:43 |
| === zul is now known as ep | ||
| === ep is now known as zul | ||
| smoser | Makere, i would doubt that its related to where you bundle | 14:16 |
| smoser | remember that when you do a run-instances after uploading, the first time it will have to copy from walrus to node, change format of image (adding a partition table and such), before running | 14:17 |
| smoser | that is a lot of IO and will be very slow for something large | 14:17 |
| smoser | you can debug a bit more by figuring out where your instance is going to run (euca_conf --list-nodes) and then looking at the node. top will show you some things. likely there is something in /var/log/eucalyptus or /var/lib/libvirt | 14:19 |
| Makere | smoser: well I waited for an half an hour, kvm doesn't run on the node | 14:52 |
| Makere | node logs don't have any errors | 14:53 |
| smoser | hm.. | 14:53 |
| Makere | I have nc log upped somewhere | 14:54 |
| Makere | if you want I cna put it to pastebin | 14:55 |
| Makere | but personally I think to myself as case closed, and will not compile on the cloud controller anymore | 14:55 |
| Makere | bundle* not compile | 14:55 |
| Makere | it worked charmed after bundling on cluster controller | 14:56 |
| Makere | like a charm* | 14:56 |
| Makere | sorry, a bit tired | 14:56 |
| Makere | I have walrus and cloud controller on same machine | 14:57 |
| Makere | and cluster controller + storage controller on other two | 14:57 |
| Makere | plus nodes | 14:57 |
| smoser | well, for what its worht, i have a cloud (10.04 right now, but i've used 10.10) with just 2 systems | 14:57 |
| smoser | one is CC CLC and SC, one is just NC | 14:57 |
| smoser | and i do everything from the CC/CLC/SC node. | 14:57 |
| Makere | I think it might have something to do on cloud/walrus controller not having CC on same machine | 14:58 |
| smoser | it won't make any difference, but if you find the bundle and upload process to be a bit obtuse, you can use 'uec-publish-tarball' or 'uec-publish-image' | 14:58 |
| === dendrobates is now known as dendro-afk | ||
| Makere | I did my own image with the publish-image | 14:59 |
| Makere | same thing as with publish-tarball on official images | 14:59 |
| smoser | ah. ok. | 14:59 |
| smoser | just wanted to make you aware that is there. | 14:59 |
| Makere | yea thanks | 14:59 |
| smoser | once you've uploaded, i seriously can't see a difference in where the bundle was done | 14:59 |
| === dendro-afk is now known as dendrobates | ||
| smoser | after bundle, its already loaded into walrus, and the NC will do the get from walrus. no path there would be affected by where the 'bundle' command was run. | 15:00 |
| Makere | http://open.eucalyptus.com/forum/i-still-can-only-run-instances-store-images same problem here | 15:00 |
| Makere | found the answer from there | 15:01 |
| Makere | although in the "answer" I got the guy seems to have run CLC CC SC and Walrus on same PC | 15:02 |
| Makere | ("Ok, so I really don't know" by seigie) in the middle | 15:02 |
| Makere | weird thing is that I/We reinstalled the cloud 4 times | 15:03 |
| Makere | and everytime same problem | 15:03 |
| Makere | with diff settings etc | 15:03 |
| Makere | ah well, just wanted too put a heads up if anyone gets same kind of problem | 15:04 |
| smoser | you get the errors like that in the logs ? | 15:04 |
| Makere | don't have the logs here now | 15:05 |
| smoser | well, the right thing to do is open an ubuntu bug | 15:06 |
| Makere | yea | 15:06 |
| smoser | so, go through the steps again | 15:06 |
| smoser | writing down what you do and your setup (CC/CLC and such) | 15:06 |
| smoser | see the failure | 15:06 |
| smoser | then run 'ubuntu-bug eucalyptus' on the system that has those ERROR messages in the logs | 15:06 |
| smoser | sorry to give youthe run-around, but in the end, that is what is most likely to get the problem solved for you. | 15:07 |
| TritoLux_ | hello there, anybody? | 15:31 |
| TritoLux_ | I am trying to setup a cloud test environment and I managed to get it to work, but it gives random network problems when multiple users run multiple instances. The Eucalyptus team told me that it is a UEC specific problem and I would need some help to troubleshoot. Is there anybody willing to help? | 15:32 |
| TeTeT | TritoLux_: can't promise anything, have you tried connecting via public or private ip? And are the instances really up and running? You can check that with euca-get-console-output | 16:23 |
| TritoLux_ | hi there, yes everything seems to work fine, I can administer the instances via hybridfox with no problems, apparently.. but when a second user starts his own instance, then the other users loose the attached volumes from the SC and they even have to reboot their instance in orger to regain connectivity | 16:25 |
| TritoLux_ | after rebooting the instances, then nobody can detach the previously attached volumes and I have to reboot the cloud to restore functionality, until the same problem occurs again | 16:26 |
| TritoLux_ | thanks for replying btw | 16:26 |
| TritoLux_ | I have been troubleshooting this problem with the Eucalyptus team, but after a couple of months they are still puzzled and they said that it is UEC specific | 16:30 |
| TeTeT | TritoLux_: sounds bad. I would recommend opening a bug about this in Launchpad against the eucalyptus package | 16:31 |
| TritoLux_ | the Eucalyptus team suspects AoE to be the problem | 16:32 |
| TritoLux_ | for instance, when I launch an instance, I get this error message in the livirt log: pci_add_option_rom: failed to find romfile "pxe-e1000.bin" | 16:33 |
| TritoLux_ | for instance, when I launch an instance, I get this error message in the libvirt log: pci_add_option_rom: failed to find romfile "pxe-e1000.bin" | 16:33 |
| TritoLux_ | I wonder if it is related | 16:33 |
| TritoLux_ | I also removed the AppArmor security layer in order to see if it was causing the problem, but pretty much nothing has changed | 16:34 |
| TritoLux_ | as a matter of fact, I was never able to have a stable cloud based on UEC | 16:36 |
| TritoLux_ | thanks for your responses TeTeT, I will eventually shoot a bug in Launchpad, but if anybody else has any advices in the meanwhile that would great. I can provide you with all logs and configs of course | 16:39 |
| TeTeT | TritoLux_: I think the error is unrelated. it goes away when you add some kvm-pxe package | 16:41 |
| TeTeT | TritoLux_: btw are you on 10.04 LTS or on 10.10? | 16:41 |
| TritoLux_ | I started with 10.04 LTS and I performed a dist-upgrade | 16:41 |
| TritoLux_ | it is currently running with all latest available packages | 16:42 |
| TritoLux_ | the environment is set with 2 machines, one running CLC, CC, SC, Walrus and the other one running the NC | 16:44 |
| TritoLux_ | both have dual NIC's, the CLC uses a public NIC and the CC is installed on a private NIC | 16:45 |
| TritoLux_ | eucalyptus.conf is set to run both priv and public traffic on the bridge configured on the non public interface | 16:46 |
| TritoLux_ | the nic's are configured for multiclustering, even if it is running only one at the moment | 16:47 |
| TritoLux_ | the eucalyptus guys had a look at the network config and they said that it is supposed to work fine | 16:48 |
| TritoLux_ | however, because both public NIC and private NIC are configured with a static address, then avahi autoregistration failed during UEC installation and it cost me some troubles to arrange a properly registered node. Now the node registration seems fine, but I wonder if the initial failure might have caused more problems | 16:52 |
| TritoLux_ | the network mode is MANAGED-NOVLAN | 16:52 |
| TritoLux_ | I have no error messages in the logs, until the above problem occurs | 16:53 |
| TeTeT | TritoLux_: I register nodes from hand all the time and have not discovered your problem. But then I just do training and not some pre-production tests | 16:53 |
| TritoLux_ | if you try to install a cloud where the CC is running on a private NIC with a static IP then you will reproduce above registration problem | 16:54 |
| TritoLux_ | so to have a main IF on the public NIC and the nodes to be discovered on a private NIC, both with static IP's | 16:55 |
| TritoLux_ | the UEC installation process allows you to choose a static IP on the main NIC, but the same question is not asked for the secondary NIC and it assumes DHCP on that one | 16:57 |
| TritoLux_ | then autoregistration fails | 16:57 |
| TritoLux_ | the above problems are preventing us to start our cloud business at the moment and switching to Debian is currently being taken into consideration to be honest | 16:58 |
| TritoLux_ | basically, it seems that I cannot run more than a customer onto an apparently working cloud, otherwise the entire network gets messed up, as in connectivity getting lost, attached volumes becoming unaccessible, etc. rebooting the cloud seems the only solution to restore funzionality again.. for a single user, until a second one starts another instance. | 17:04 |
| TritoLux_ | I have tried to run more instances from a single user and it seems to work fine. The problems occur mainly or only when a different user starts to interact with the cloud. | 17:06 |
| TeTeT | TritoLux_: not sure if the multi user scenario is well tested. I use it in the trainings, but this cloud only exists for a week | 17:09 |
| TritoLux_ | I think that multiuser is essential to a cloud, otherwise we miss the point of having a cloud. But I think that the multi-nic scenario is even less tested. | 17:10 |
| TritoLux_ | at least when you have both IF's with static IP addresses | 17:11 |
| TritoLux_ | my idea is to have just the CLC facing the public and the rest of the cloud interacting through a private network so that the public cannot even reach the other nodes | 17:13 |
| TeTeT | TritoLux_: sound idea | 17:16 |
| TritoLux_ | eheh, it might be a good idea, but I wasn't able to get it to work in practice so far, unfortunately | 17:18 |
| TeTeT | TritoLux_: I believe it's a scenario that should be supported | 17:18 |
| TritoLux_ | I am quite sure it is supported indeed, but it hasn't worked for me so far | 17:19 |
| TritoLux_ | and I dunno why | 17:19 |
| TritoLux_ | as we speak, two more boxes are being setup for a debian testing environment which will be configured in the same way, so to see if it is really an UEC problem or not.. thing is that Debian alred | 17:21 |
| TeTeT | good luck with that | 17:22 |
| TritoLux_ | as we speak, two more boxes are being setup for a debian testing environment which will be configured in the same way, so to see if it is really an UEC problem or not.. thing is that Debian already runs Eucalyptus 2.0 | 17:22 |
| TeTeT | as does maverick | 17:22 |
| TritoLux_ | and UEC is running 1.6.2 | 17:22 |
| TritoLux_ | Maverick is not the dist I have then | 17:22 |
| TeTeT | TritoLux_: hmm, you really should try it then, I believe | 17:23 |
| TeTeT | TritoLux_: it's not an LTS, so support will run out in 18 months time though | 17:23 |
| TritoLux_ | I am running the LTS distribution | 17:23 |
| TeTeT | that's 10.04 LTS | 17:24 |
| TritoLux_ | yes | 17:24 |
| TritoLux_ | I thought that the LTS was more stable though, that's why my boss set it as a requirement | 17:25 |
| TritoLux_ | or at least better tested | 17:25 |
| TeTeT | TritoLux_: it basically is, but with UEC it's still a pretty new product and big improvements are made with each release | 17:27 |
| TritoLux_ | that's understandable | 17:27 |
| TeTeT | TritoLux_: the biggest step for 10.04 LTS in regards to UEC was IMO the neat installation via the CD | 17:27 |
| TeTeT | TritoLux_: I know there have been made all kind of tests for stability, but I doubt the multi user and multi nic scenario is one of them | 17:28 |
| TritoLux_ | I think that the multiuser and multi nic scenario would be one of the most requested for production environments though | 17:29 |
| TritoLux_ | if I remember correctly, the initial tests we run when we approved UEC were run on a single NIC and everything went pretty much ok, but when we had to go in production environment, then things changed of course and more requirements were set.. but UEC didn't work well anymore | 17:32 |
| TritoLux_ | when do you think that Euca 2.0 will be available for LTS? | 17:32 |
| TeTeT | TritoLux_: not sure, unless there's a strong business case probably never. I don't see anyone putting resources into a backport | 17:33 |
| TritoLux_ | auch, sorry what's the advantage of running LTS then? | 17:34 |
| TeTeT | TritoLux_: security updates for 5 years on the server. It's not about getting the latest software | 17:35 |
| TeTeT | TritoLux_: it's just my 2 cent, but I'd evaluate UEC on Maverick, upgrade that on a six month base and then go with the next LTS for long term production deployment | 17:35 |
| TeTeT | TritoLux_: but not sure if that meets your project specs | 17:36 |
| TritoLux_ | mmh.. I thought it was both | 17:36 |
| TritoLux_ | that's a good suggestion indeed | 17:36 |
| TritoLux_ | thanks for your help, I will have to discuss this with my colleagues and better explain the scenario | 17:37 |
| TritoLux_ | there might have been misunderstandings on the LTS concepts | 17:38 |
| TeTeT | TritoLux_: good luck, couldn't provide much though | 17:38 |
| TritoLux_ | I appreciate your response anyway, thanks for your effort nevertheless | 17:39 |
| TritoLux_ | it's not a simple issue anyway | 17:39 |
| TeTeT | agreed | 17:40 |
| TritoLux_ | I'll go for a break now, speak you soon maybe | 17:41 |
| TritoLux_ | thanks again | 17:41 |
| TeTeT | will be off soon, bye | 17:41 |
| TritoLux_ | bye bye | 17:42 |
| === zul_ is now known as zul | ||
| === xfaf is now known as zul | ||
| smoser | erichammond, you still unable to find anyway to update ami pages, right? | 19:26 |
| smoser | it sure seems like they're just in flux, but i opened a ticket and reopened several times. iwas told that to edit a page i should "submit an ami" and mention that it is an update to an existing page in the body. | 19:27 |
| kiall | anyone had any luck using the EC2 PHP SDK with euca/UEC? | 19:37 |
| erichammond | smoser: I guess I've given up on Amazon's AMI pages since I haven't updated them in forever. | 21:18 |
| smoser | i'm somewhat peeved at them over it. | 21:18 |
| erichammond | smoser: I guess I should put in one more update that just says "this AMI has been superceded by the new recommended official Ubuntu AMIs..." | 21:18 |
| smoser | i recently made an effort on them, to move out of the canonical account (the one that owns our images) to another | 21:18 |
| smoser | so that people who updated those dont have to know credentials that could cause issues. | 21:18 |
| smoser | but now, i can't even update the ones we have | 21:19 |
| erichammond | :( | 21:23 |
| smoser | i really think that they're probably just in transition. visually there are changes. | 21:24 |
| smoser | but there is no external announcemnt of such a thing, and its been going on for the better part of a month | 21:25 |
| kiall | humm, smoser think I just discovered a bug in the UEC API .. Might be normal tho! You know sec group names on describe instances come back as "group" while on run_instances come back as "<uec_username>_group" .. | 21:32 |
| kiall | that the way EC2 does it? (I havent used their API) | 21:33 |
| smoser | what is uec_username ? | 21:34 |
| kiall | the username you use to login to the CLC web UI | 21:34 |
| smoser | i think its probably a bug. | 21:35 |
| kiall | so desc instances might return "default" while run will return "admin_default" when using the admin account ... | 21:35 |
| kiall | crap .. time to go digging again ;) | 21:35 |
| smoser | some things are different with admin | 21:36 |
| kiall | Also .. the only way I've gotton euca to build is on a PPA with updates turned off .. is there some trick to built it after you do a "apt-get dist-upgrade"? | 21:36 |
| kiall | Well, im not using the admin user .. just thought it was a good example ;) | 21:36 |
| smoser | if it fails to build from source, then please open a bug | 21:38 |
| smoser | and you're saying the API lists the user name ? | 21:38 |
| kiall | yes - the group name returned (assuming group = "app" and username = "kiall") by describe is "app" while run instance returns "kiall_app" | 21:39 |
| smoser | kiall, i'd have to look at it more, but i've never noticed differing output in the utility | 21:53 |
| smoser | in euca2ools when working with ec2 verusus uec | 21:53 |
| smoser | so i'd expect that its not different from what comes back from the api | 21:53 |
| smoser | but i dont use security groups much | 21:53 |
| kiall | I'll dig in a little more and look at the raw output rather than what the PHP EC2 SDK is giving me .. possibly a bug elsewhere | 21:53 |
| kiall | Yup - The euca API is def handles group names differently .. | 21:59 |
| TritoLux_ | hello there, I would like to upgrade 10.04LTS to 10.10, which means also a major upgrade from Eucalyptus 1.6.2 to 2.0.. is there any particular step to be concerned of? any known problems? would the existing cloud keep all volumes, credentials and configurations? thanks in advance for your answers | 22:02 |
| smoser | kiall, thanks. please do open a bug against eucalyptus | 22:02 |
| kiall | just getting it together now | 22:03 |
| smoser | again, using 'ubuntu-bug eucalyptus' | 22:03 |
| kiall | humm? | 22:03 |
| smoser | if you use 'ubuntu-bug eucalyptus' on the system, then it will put some info in the bug about what versions you're using | 22:03 |
| smoser | it will also collect logs if you allow it | 22:03 |
| smoser | thats why i suggested you do that on the machine with the Errors earlier (regariding your fialure to leave 'pending') | 22:04 |
| smoser | i've got to run. | 22:04 |
| kiall | Ah that wasnt me ;) | 22:04 |
| smoser | i think it was | 22:04 |
| kiall | Nope - last thing we talked about was hairpin NAT | 22:04 |
| smoser | hm.. so it was. i confused you with Makere | 22:05 |
| smoser | anyway. | 22:05 |
| smoser | same deal goes for you :) | 22:05 |
| smoser | use ubuntu-bug eucalyptus , that collects some system info | 22:05 |
| kiall | I'll see if that works over SSH to the server .. dont have it installed locally.. | 22:06 |
| kiall | thanks ... | 22:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!