Re: [Openstack] reviewday
Can you explain what some of the errors mean? For instance, for this merge proposal: https://review.openstack.org/#change,1950 the unit tests passed, but the libvirt tests were Hit by Torpedo and XenServer tests had a Chef client timeout. Am I right to assume that at least the chef client timeout problem is an issue in the test setup rather than indicative of a problem with the merge proposal? I have no idea what Hit by Torpedo means :) -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] nova compute node error [diablo]
hi ,everybody nova compute node error : 2011-12-01 17:35:52,871 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:37:27,531 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:38:27,540 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:39:01,621 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:40:36,781 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:41:36,782 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:42:11,045 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:43:45,621 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:44:45,621 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:45:20,981 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:46:55,161 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:47:55,171 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:48:29,746 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:50:04,291 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:51:04,292 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:51:38,771 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:53:13,591 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:54:13,592 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:54:48,022 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:56:23,211 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:57:23,221 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:57:57,921 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:59:32,065 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 18:00:32,066 INFO nova.compute.manager [-] Updating host status 2011-12-01 18:01:06,801 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 18:02:41,632 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 18:03:41,632 INFO nova.compute.manager [-] Updating host status 2011-12-01 18:04:15,962 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] nova compute node error [diablo]
Hi Thats an sqlalchemy error, what database backend are you using ? That error is that actually youre not closing connections and they are not returning to the pool Regards On Thu, Dec 1, 2011 at 7:04 AM, darkfower atk...@gmail.com wrote: hi ,everybody nova compute node error : 2011-12-01 17:35:52,871 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:37:27,531 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:38:27,540 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:39:01,621 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:40:36,781 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:41:36,782 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:42:11,045 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:43:45,621 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:44:45,621 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:45:20,981 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:46:55,161 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:47:55,171 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:48:29,746 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:50:04,291 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:51:04,292 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:51:38,771 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:53:13,591 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:54:13,592 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:54:48,022 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:56:23,211 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:57:23,221 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:57:57,921 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:59:32,065 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 18:00:32,066 INFO nova.compute.manager [-] Updating host status 2011-12-01 18:01:06,801 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 18:02:41,632 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 18:03:41,632 INFO nova.compute.manager [-] Updating host status 2011-12-01 18:04:15,962 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] reviewday
Sure! Sorry about that :) Torpedo is just the set of ruby tests that we have been using for a while to smoketest the API, separated into a project outside of VPC - the project that was running for a while on the jenkins server. Source is here: https://github.com/dprince/torpedo When one is hit by torpedo, that means the OS API functional tests failed in some way. In this particular case we got an error when connecting to glance, (searching for traceback in the paste is a good way to find the errors) Dan, maybe you can provide some insight into why this particular one is hit by torpedo when there is no test output? I suspect this was caused by an invalid glance paste config issue that was addressed later, but I'm not 100% sure. I kicked this particular one off again to see if it was addressed since that issue was fixed. Typically its a bit more clear which test failed and why. For example, take a look at this paste from another test run, and search for Error: http://paste.openstack.org/show/3583/ You can see that an instance failed to come up after this change was merged. The system dumps logs from several servers including installation info from chef as well as the nova logs, so it can get a bit long, but in the interest of getting something out quickly that was useful, that route was chosen over trying to focus in on the specific issues. It will run tempest (new name for openstack-integration-tests) in addition since everyone is familiar with that project, just haven't had a chance yet. Chef client timeout means there was a problem with deploying which is often caused by code changes that have an associated required config change, and the like. New required middleware could cause that, anything that keeps services from starting or anything like that. It means that there was a failure that prevented chef from finishing installation. In this case though, it appears to be because we were unable to get an additional cloud server for nova1, and this prevented chef from installing since it had no where to install to. This is the exception rather than the rule, but there are already some ideas on how to prevent this from happening. Again, just haven't had time to address that yet. In the end, when I see all green, I feel confident that something passes basic smoke tests for both ec2 and openstack api. When I see red on libvirt or xen server, it definitely takes some investigation and my first instinct was to wonder about the installation when I see chef client timeout messages, but more often than not there is an api-paste change or something similar that is causing that issue. At the same time, I recognize it can be frustrating to not know why something is red and until you see it for yourself, there is lower confidence in those being issues with code.. I'm sure Dan would accept patches that made things a bit more accessible if anyone has interest in that and is familiar with how to read the various logs including chef logs! Gabe On 12/1/11 3:59 AM, Soren Hansen so...@linux2go.dk wrote: Can you explain what some of the errors mean? For instance, for this merge proposal: https://review.openstack.org/#change,1950 the unit tests passed, but the libvirt tests were Hit by Torpedo and XenServer tests had a Chef client timeout. Am I right to assume that at least the chef client timeout problem is an issue in the test setup rather than indicative of a problem with the merge proposal? I have no idea what Hit by Torpedo means :) -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] boot from ISO
It finally works. The problem was the flag checks while looking for the ISO SR. inside the find_iso_sr method (in nova/virt/xenapi/vm_utils.py), I found that the ISO SR must have these settings: content type: iso other-config:i18n-key=local-storage-iso As far as I know, this wasn't documented anywhere. Hope this can be useful for people from the future. cheers, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 29/11/11 23:10, Donal Lafferty a écrit : Off the top of my head, I'd look to see if the compute node can see that ISO SR. DL *From:*Michaël Van de Borne [mailto:michael.vandebo...@cetic.be] *Sent:* 29 November 2011 18:15 *To:* Donal Lafferty; openstack@lists.launchpad.net *Subject:* Re: [Openstack] boot from ISO Hi Donal, hi all, I'm trying to test the Boot From ISO feature. So I've set a XenServer host and installed a Ubuntu 11.10 PV DomU in it. Then I used the following commands but, as you can see in the attached nova-compute log excerpt, there was a problem. glance add name=fedora_iso disk_format=iso ../Fedora-16-x86_64-Live-LXDE.iso ID: 4 nova boot test_iso --flavor 2 --image 4 I can see the ISO images using nova list but not using glance index. The error seems to be: 'Cannot find SR of content-type ISO'. However, I've set a NFS ISO Library using XenCenter, so that there is an actual ISO content-typed SR. How to tell OpenStack to use this SR for the ISO images I post using glance? Any clue? I feel I'm rather close to make it work. thanks, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be http://www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 22/11/11 00:18, Donal Lafferty a écrit : Hi Michaël, Boot from ISO should be ISO image agnostic. The feature overcomes restrictions placed on the distribution of modified Windows' images. People can use their ISO instead, but they may still need to use dedicated hardware. You should have no problem with a Linux distribution. However, I wrote it for XenAPI, so we need someone to duplicate the work for KVM and VMWare. DL *From:*openstack-bounces+donal.lafferty=citrix@lists.launchpad.net mailto:openstack-bounces+donal.lafferty=citrix@lists.launchpad.net [mailto:openstack-bounces+donal.lafferty=citrix@lists.launchpad.net] *On Behalf Of *Michaël Van de Borne *Sent:* 21 November 2011 17:28 *To:* openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] boot from ISO up? anybody? Le 14/11/11 14:44, Michaël Van de Borne a écrit : Hi all, I'm very interested in the Boot From ISO feature described here: http://wiki.openstack.org/bootFromISO In a few words, it's about the ability to boot a VM from the CDROM with an ISO image attached. A blank hard disk being attached to install the OS files in it. I've got some questions about this: 1. Is the feature available today using a standard Diablo install? I've seen the code about this feature is stored under nova/tests and glance/tests. Does this mean it isn't finished yet and could only be tested under specific conditions? Which ones? 2. the spec tells about a Windows use case. Why just Windows? What should I do to test with a Linux distribution? 3. I can see here http://bazaar.launchpad.net/%7Ehudson-openstack/nova/trunk/revision/1433?start_revid=1433 that the Xen hypervisor only has been impacted by the source code changes. Are KVM and VMWare planned to be supported in the future? May I help/be helped to develop KVM and VMWare support for this 'Boot From Iso' feature? Any help appreaciated thank you, michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be http://www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list:https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to :openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe :https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help :https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] boot from ISO
Hi Michaël,that would be great if you can provide us an how-to for that that we will integrate into the documentation !Regards,Razique Nuage Co - Razique Mahrouarazique.mahr...@gmail.com Le 1 déc. 2011 à 16:14, Michaël Van de Borne a écrit : It finally works. The problem was the flag checks while looking for the ISO SR. inside the find_iso_sr method (in nova/virt/xenapi/vm_utils.py), I found that the ISO SR must have these settings: content type: iso other-config:i18n-key=local-storage-iso As far as I know, this wasn't documented anywhere. Hope this can be useful for people from the future. cheers, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 29/11/11 23:10, Donal Lafferty a écrit: Off the top of my head, Id look to see if the compute node can see that ISO SR.DL From: Michaël Van de Borne [mailto:michael.vandebo...@cetic.be] Sent: 29 November 2011 18:15 To: Donal Lafferty; openstack@lists.launchpad.net Subject: Re: [Openstack] boot from ISO Hi Donal, hi all, I'm trying to test the Boot From ISO feature. So I've set a XenServer host and installed a Ubuntu 11.10 PV DomU in it. Then I used the following commands but, as you can see in the attached nova-compute log excerpt, there was a problem. glance add name=fedora_iso disk_format=iso ../Fedora-16-x86_64-Live-LXDE.iso ID: 4 nova boot test_iso --flavor 2 --image 4 I can see the ISO images using "nova list" but not using "glance index". The error seems to be: 'Cannot find SR of content-type ISO'. However, I've set a NFS ISO Library using XenCenter, so that there is an actual ISO content-typed SR. How to tell OpenStack to use this SR for the ISO images I post using glance? Any clue? I feel I'm rather close to make it work. thanks, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 22/11/11 00:18, Donal Lafferty a écrit: Hi Michaël,Boot from ISO should be ISO image agnostic. The feature overcomes restrictions placed on the distribution of modified Windows images. People can use their ISO instead, but they may still need to use dedicated hardware. You should have no problem with a Linux distribution. However, I wrote it for XenAPI, so we need someone to duplicate the work for KVM and VMWare.DL From: openstack-bounces+donal.lafferty=citrix@lists.launchpad.net [mailto:openstack-bounces+donal.lafferty=citrix@lists.launchpad.net] On Behalf Of Michaël Van de Borne Sent: 21 November 2011 17:28 To: openstack@lists.launchpad.net Subject: Re: [Openstack] boot from ISO up? anybody? Le 14/11/11 14:44, Michaël Van de Borne a écrit: Hi all, I'm very interested in the "Boot From ISO" feature described here: http://wiki.openstack.org/bootFromISO In a few words, it's about the ability to boot a VM from the CDROM with an ISO image attached. A blank hard disk being attached to install the OS files in it. I've got some questions about this: 1. Is the feature available today using a standard Diablo install? I've seen the code about this feature is stored under nova/tests and glance/tests. Does this mean it isn't finished yet and could only be tested under specific conditions? Which ones? 2. the spec tells about a Windows use case. Why just Windows? What should I do to test with a Linux distribution? 3. I can see here that the Xen hypervisor only has been impacted by the source code changes. Are KVM and VMWare planned
Re: [Openstack] boot from ISO
Thanks for the info! I've logged bug 898682 [1] to ensure it gets added to the documentation. Based on this note, is this a solution for Xen only? Is this the same as using a config drive? I had heard a config drive works on KVM but not Xen. If someone who's familiar with this area could work on the docs that would be great. Thanks, Anne [1] https://bugs.launchpad.net/openstack-manuals/+bug/898682 On Thu, Dec 1, 2011 at 9:14 AM, Michaël Van de Borne michael.vandebo...@cetic.be wrote: It finally works. The problem was the flag checks while looking for the ISO SR. inside the find_iso_sr method (in nova/virt/xenapi/vm_utils.py), I found that the ISO SR must have these settings: content type: iso other-config:i18n-key=local-storage-iso As far as I know, this wasn't documented anywhere. Hope this can be useful for people from the future. cheers, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 29/11/11 23:10, Donal Lafferty a écrit : Off the top of my head, I’d look to see if the compute node can see that ISO SR. DL From: Michaël Van de Borne [mailto:michael.vandebo...@cetic.be] Sent: 29 November 2011 18:15 To: Donal Lafferty; openstack@lists.launchpad.net Subject: Re: [Openstack] boot from ISO Hi Donal, hi all, I'm trying to test the Boot From ISO feature. So I've set a XenServer host and installed a Ubuntu 11.10 PV DomU in it. Then I used the following commands but, as you can see in the attached nova-compute log excerpt, there was a problem. glance add name=fedora_iso disk_format=iso ../Fedora-16-x86_64-Live-LXDE.iso ID: 4 nova boot test_iso --flavor 2 --image 4 I can see the ISO images using nova list but not using glance index. The error seems to be: 'Cannot find SR of content-type ISO'. However, I've set a NFS ISO Library using XenCenter, so that there is an actual ISO content-typed SR. How to tell OpenStack to use this SR for the ISO images I post using glance? Any clue? I feel I'm rather close to make it work. thanks, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 22/11/11 00:18, Donal Lafferty a écrit : Hi Michaël, “Boot from ISO” should be ISO image agnostic. The feature overcomes restrictions placed on the distribution of modified Windows’ images. People can use their ISO instead, but they may still need to use dedicated hardware. You should have no problem with a Linux distribution. However, I wrote it for XenAPI, so we need someone to duplicate the work for KVM and VMWare. DL From: openstack-bounces+donal.lafferty=citrix@lists.launchpad.net [mailto:openstack-bounces+donal.lafferty=citrix@lists.launchpad.net] On Behalf Of Michaël Van de Borne Sent: 21 November 2011 17:28 To: openstack@lists.launchpad.net Subject: Re: [Openstack] boot from ISO up? anybody? Le 14/11/11 14:44, Michaël Van de Borne a écrit : Hi all, I'm very interested in the Boot From ISO feature described here: http://wiki.openstack.org/bootFromISO In a few words, it's about the ability to boot a VM from the CDROM with an ISO image attached. A blank hard disk being attached to install the OS files in it. I've got some questions about this: 1. Is the feature available today using a standard Diablo install? I've seen the code about this feature is stored under nova/tests and glance/tests. Does this mean it isn't finished yet and could only be tested under specific conditions? Which ones? 2. the spec tells about a Windows use case. Why just Windows? What should I do to test with a Linux distribution? 3. I can see here that the Xen hypervisor only has been impacted by the source code changes. Are KVM and VMWare planned to be supported in the future? May I help/be helped to develop KVM and VMWare support for this 'Boot From Iso' feature? Any help appreaciated thank you, michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to :
[Openstack] [GLANCE] Proposal: Combine the container_format and disk_format fields in 2.0 Images API
Hey all, OK, so I'm almost done with Draft 3 of the OpenStack Images API 2.0 Proposal. While doing this, however, I have come to the conclusion that the container_format we added in the Cactus timeframe just makes things more confusing and should probably be removed. We have two fields in the current API that store information about the disk file format and any container/package format for an image. http://glance.openstack.org/formats.html The disk_format field currently allows the following: raw - This is an unstructured disk image format vhd - This is the VHD disk format, a common disk format used by virtual machine monitors from VMWare, Xen, Microsoft, VirtualBox, and others vmdk - Another common disk format supported by many common virtual machine monitors vdi - A disk format supported by VirtualBox virtual machine monitor and the QEMU emulator iso - An archive format for the data contents of an optical disc (e.g. CDROM). qcow2 - A disk format supported by the QEMU emulator that can expand dynamically and supports Copy on Write aki - This indicates what is stored in Glance is an Amazon kernel image ari - This indicates what is stored in Glance is an Amazon ramdisk image ami - This indicates what is stored in Glance is an Amazon machine image For container formats, we currently allow: ovf - This is the OVF container format bare - This indicates there is no container or metadata envelope for the image aki - This indicates what is stored in Glance is an Amazon kernel image ari - This indicates what is stored in Glance is an Amazon ramdisk image ami - This indicates what is stored in Glance is an Amazon machine image The problem I see is that really OVF is the only real container format and I'm just not sure it's useful to have users set a container format. The goal was to allow Glance to report that the image file stored in Glance is an OVA file and not an image file itself. An OVA file is a single file that contains the OVF directory structure tar'd up. However, I think this can be more easily accomplished by consolidating the disk and container formats in the 2.0 API to just a single format field with the possible values: ova - This indicates the data stored in Glance is an OVF container that may actually contain multiple virtual appliances that has been tar'd into the single-file OVA format raw - This is an unstructured disk image format vhd - This is the VHD disk format, a common disk format used by virtual machine monitors from VMWare, Xen, Microsoft, VirtualBox, and others vmdk - Another common disk format supported by many common virtual machine monitors vdi - A disk format supported by VirtualBox virtual machine monitor and the QEMU emulator iso - An archive format for the data contents of an optical disc (e.g. CDROM). qcow2 - A disk format supported by the QEMU emulator that can expand dynamically and supports Copy on Write aki - This indicates what is stored in Glance is an Amazon kernel image ari - This indicates what is stored in Glance is an Amazon ramdisk image ami - This indicates what is stored in Glance is an Amazon machine image What do people think of this proposal to combine the two into a single format field? Thanks in advance for your feedback, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] boot from ISO
That's right, it's a Xen*Server* only feature. I insist on XenServer because it's been implemented only inside the xenapi. If you wish to manage VMs using KVM or Xen hypervisor (the community hypervisor packaged in Linux distributions), this will utilize the libvirt API, and not XenAPI. So, one needs to use XenServer (btw, openstack works great with XenServer 6.0 even if documentation claims that the supported release is 5.5 http://docs.openstack.org/diablo/openstack-compute/admin/content/hypervisors.html) in order for the XenAPI to be used. I made use of this documentation http://wiki.openstack.org/XenServerDevelopment in order to set up the environement. What is missing is that, in order to activate the Boot From ISO http://wiki.openstack.org/bootFromISO feature, the SR elements on XenServer host must be configured that way: 1. create an ISO-typed SR, such as an NFS ISO library, for instance. For this, using XenCenter is pretty easy. You need to export an NFS volume from a remote NFS server. Make sure it is exported in RW mode. 2. on the host, find the uuid of this ISO SR: # xe host-list write the uuid down 3. # xe sr-list content-type=iso locate the uuid of the NFS ISO library 4. # xe sr-param-set uuid=iso sr uuid other-config:i18n-key=local-storage-iso Even if an NFS mount point isn't local storage, you must specify local-storage-iso. 5. # xe pbd-list sr-uuid=iso sr uuid make sure the host-uuid from xe pbd-list equals the uuid of the host you found at step 2 then apply the rest of the tutorial http://wiki.openstack.org/XenServerDevelopment#Configure_SR_storage and publish an ISO image this way: glance add name=fedora_iso disk_format=iso container_format=bare Fedora-16-x86_64-netinst.iso nova boot test_iso --flavor flavor ID --image image ID I've posted this in the bug you filed, Anne. By the way, I'm going to work on porting this feature on libvirt API and VMWare API (if nobody works on it yet). Is the config drive yet available for Diablo?? cheers, michaël http://wiki.openstack.org/XenServerDevelopment Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 01/12/11 16:29, Anne Gentle a écrit : Thanks for the info! I've logged bug 898682 [1] to ensure it gets added to the documentation. Based on this note, is this a solution for Xen only? Is this the same as using a config drive? I had heard a config drive works on KVM but not Xen. If someone who's familiar with this area could work on the docs that would be great. Thanks, Anne [1] https://bugs.launchpad.net/openstack-manuals/+bug/898682 On Thu, Dec 1, 2011 at 9:14 AM, Michaël Van de Borne michael.vandebo...@cetic.be wrote: It finally works. The problem was the flag checks while looking for the ISO SR. inside the find_iso_sr method (in nova/virt/xenapi/vm_utils.py), I found that the ISO SR must have these settings: content type: iso other-config:i18n-key=local-storage-iso As far as I know, this wasn't documented anywhere. Hope this can be useful for people from the future. cheers, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 29/11/11 23:10, Donal Lafferty a écrit : Off the top of my head, I’d look to see if the compute node can see that ISO SR. DL From: Michaël Van de Borne [mailto:michael.vandebo...@cetic.be] Sent: 29 November 2011 18:15 To: Donal Lafferty; openstack@lists.launchpad.net Subject: Re: [Openstack] boot from ISO Hi Donal, hi all, I'm trying to test the Boot From ISO feature. So I've set a XenServer host and installed a Ubuntu 11.10 PV DomU in it. Then I used the following commands but, as you can see in the attached nova-compute log excerpt, there was a problem. glance add name=fedora_iso disk_format=iso ../Fedora-16-x86_64-Live-LXDE.iso ID: 4 nova boot test_iso --flavor 2 --image 4 I can see the ISO images using nova list but not using glance index. The error seems to be: 'Cannot find SR of content-type ISO'. However, I've set a NFS ISO Library using XenCenter, so that there is an actual ISO content-typed SR. How to tell OpenStack to use this SR for the ISO images I post using glance? Any clue? I feel I'm rather close to make it work. thanks, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 22/11/11 00:18, Donal Lafferty a écrit : Hi Michaël, “Boot from ISO” should be ISO image agnostic. The feature overcomes restrictions placed on the distribution of modified Windows’ images. People can use their ISO instead, but they may still need to use dedicated hardware. You should have no problem with a Linux distribution.
Re: [Openstack] [nova-testing] Efforts for Essex
On 30 Nov 2011 - 11:07, Duncan McGreggor wrote: On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen so...@linux2go.dk wrote: It's been a bit over a week since I started this thread. So far we've agreed that running the test suite is too slow, mostly because there are too many things in there that aren't unit tests. We've also discussed my fake db implementation at length. I think we've generally agreed that it isn't completely insane, so that's moving along nicely. Duncan has taken the first steps needed to split the test suite into unit tests and everything else: ? https://review.openstack.org/#change,1879 Just one more core +1 needed. Will someone beat me to it? Only time will tell :) Thanks, Duncan! Anything else around unit testing anyone wants to get into The Great Big Plan[tm]? Actually, yeah... one more thing :-) Jay and I were chatting about organization of infrastructure last night/this morning (on the review comments for the branch I submitted). He said that I should raise a concern I expressed for wider discussion: right now, tests are all piled into the tests directory. Below are my thoughts on this. I think such an approach is just fine for smaller projects; there's not a lot there, and it's all pretty easy to find. For large projects, this seems like not such a good idea for the following reasons: * tests are kept separate from the code they relate to * there are often odd test module file naming practices required (e.g., nova/a/api.py and nova/b/api.py both needing test cases in nova/tests/) * there's no standard exercised for whether a subpackage gets a single test case module or whether it gets a test case subpackage * test modules tend to be very long (and thus hard to navigate) due to the awkwardness of naming modules when all the code lives together * it makes it harder for newcomers to find code; when they live together, it's a no-brainer OpenStack is definitely not a small project, and as our test coverage becomes more complete, these issues will have increased impact. I would like to clean all of this up :-) And I'm volunteering to do the work! Here's the sort of thing I envision, using nova.volume as an example: * create nova/volume/tests * move all scheduler-related tests (there are several) from nova/tests into nova/volume/tests This was a typo, and should have read: * move all volume-related tests ... d * break out tests on a per-module basis (e.g., nova/volume/driver.py would get the test module nova/volume/tests/test_driver.py, etc.) * for modules that have already been broken out at a more fine-grained level, keep (smaller test case modules are nice!) * only nova/*.py files will have a test case module in nova/tests * bonus: update the test runner to print the full dotted path so it's immediately (and visually) clear where one has to go to address any failures Given approval, this work would be done in its own blueprint. All this work would be done in small chunks (probably one branch per module) so that it will be easy to review and adjust the approach as needed. Thoughts? d -- Soren Hansen ? ? ? ?| http://linux2go.dk/ Ubuntu Developer ? ?| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to ? ? : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help ? : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] API specifications
Hi Nova-cores Is the Console function in OS API 1.1 specs? (See https://bugs.launchpad.net/nova/+bug/898266) The implementation is not in contrib directory, so it didn't looks an extension. But as 898266 mentioned, it is not described in API docs. And also, I checked API spces from code. (I know this is reverse way. :)) There are another example, Create server could get, name (*) imageRef (*) flavorRef (*) accessIPv4 accessIPv6 adminPass config_drive security_groups networks blob keyname availability_zone reservation_id min_count max_count metadata (*) personality (*) And only * one is documented on API. http://docs.openstack.org/api/openstack-compute/1.1/content/CreateServers.html Doc-Team can not decide specs, so I suppose Nova-core are responsible to define these specs. Cheers Nachi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] development document: about swift slogging system
hi all i write a document about openstack swift distributed log system slogging http://wiki.openstack.org/development/swift/slogging if some one can put it into the development document i will very appreciate. thanks. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [GLANCE] Proposal: Combine the container_format and disk_format fields in 2.0 Images API
On Dec 1, 2011, at 10:52 AM, Jay Pipes wrote: What do people think of this proposal to combine the two into a single format field? I think it's a good idea. When I was trying to figure out how to migrate the glance-upload examples to glance add, I found it confusing that there were two different format fields that needed to be set. Simplifying the UI will make it easier on the users. Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] nova compute node error [diablo]
This might be a bug .launchpad.net/horizon/+bug/876663 The fix that was backported into Diablo/stable was to retry connections a few times. Here's info about the fix: https:// review.openstack.org/#change,1661 On Dec 1, 2011 11:16 PM, darkfower atk...@gmail.com wrote: hi,nova.conf as follow: #general --logdir=/var/log/nova --state_path=/var/lib/nova --lock_path=/var/lock/nova --verbose=True --use_syslog=False #nova-objectstore --use_s3=True --s3_host=192.168.1.2 --s3_port= #rabbit --rabbit_host=192.168.1.2 --rabbit_port=5672 --rabbit_password=16bcb168c55b9f4fa881 #ec2 --ec2_host=192.168.1.2 --ec2_port=8773 --ec2_url=http://192.168.1.2:8773/services/Cloud #osapi --osapi_host=192.168.1.2 --osapi_port=8774 #db --sql_connection=mysql://nova:nova@192.168.1.2/nova --sql_idle_timeout=600 --sql_max_retries=3 --sql_retry_interval=3 #glance --glance_host=192.168.1.2 --glance_api_servers=192.168.1.2:9292 --image_service=nova.image.glance.GlanceImageService #libvirt --connection_type=libvirt --libvirt_type=kvm --snapshot_image_format=qcow2 --use_cow_image=True --libvirt_use_virtio_for_bridges=True #auth --use_deprecated_auth=True #--start_guests_on_host_boot=True #--resume_guests_state_on_host_boot=True #nova-network --dhcpbridge_flagfile=/etc/nova/nova.conf --public_interface=eth0 --dhcpbridge=/usr/bin/nova-dhcpbridge --routing_source_ip=x.x.x.x --network_manager=nova.network.manager.FlatDHCPManager --linuxnet_interface_driver=nova.network.linux_net.LinuxBridgeInterfaceDriver --flat_injected=False --flat_interface=eth1 --multi_host=True --floating_range=x.x.x.x --fixed_range=10.0.0.0/23 --fixed_ip_disassociate_timeout=600 --force_dhcp_release=True --use_ipv6=False --allow_resize_to_same_host=True --dhcp_lease_time=62208000 2011/12/1 Leandro Reox leandro.r...@gmail.com: Hi Thats an sqlalchemy error, what database backend are you using ? That error is that actually youre not closing connections and they are not returning to the pool Regards On Thu, Dec 1, 2011 at 7:04 AM, darkfower atk...@gmail.com wrote: hi ,everybody nova compute node error : 2011-12-01 17:35:52,871 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:37:27,531 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:38:27,540 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:39:01,621 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:40:36,781 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:41:36,782 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:42:11,045 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:43:45,621 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:44:45,621 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:45:20,981 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:46:55,161 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:47:55,171 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:48:29,746 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:50:04,291 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:51:04,292 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:51:38,771 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:53:13,591 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:54:13,592 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:54:48,022 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:56:23,211 WARNING nova.compute.manager [-] Error during power_state
Re: [Openstack] nova compute node error [diablo]
o,thanks 2011/12/2 Leandro Reox leandro.r...@gmail.com: This might be a bug .launchpad.net/horizon/+bug/876663 The fix that was backported into Diablo/stable was to retry connections a few times. Here's info about the fix: https:// review.openstack.org/#change,1661 On Dec 1, 2011 11:16 PM, darkfower atk...@gmail.com wrote: hi,nova.conf as follow: #general --logdir=/var/log/nova --state_path=/var/lib/nova --lock_path=/var/lock/nova --verbose=True --use_syslog=False #nova-objectstore --use_s3=True --s3_host=192.168.1.2 --s3_port= #rabbit --rabbit_host=192.168.1.2 --rabbit_port=5672 --rabbit_password=16bcb168c55b9f4fa881 #ec2 --ec2_host=192.168.1.2 --ec2_port=8773 --ec2_url=http://192.168.1.2:8773/services/Cloud #osapi --osapi_host=192.168.1.2 --osapi_port=8774 #db --sql_connection=mysql://nova:nova@192.168.1.2/nova --sql_idle_timeout=600 --sql_max_retries=3 --sql_retry_interval=3 #glance --glance_host=192.168.1.2 --glance_api_servers=192.168.1.2:9292 --image_service=nova.image.glance.GlanceImageService #libvirt --connection_type=libvirt --libvirt_type=kvm --snapshot_image_format=qcow2 --use_cow_image=True --libvirt_use_virtio_for_bridges=True #auth --use_deprecated_auth=True #--start_guests_on_host_boot=True #--resume_guests_state_on_host_boot=True #nova-network --dhcpbridge_flagfile=/etc/nova/nova.conf --public_interface=eth0 --dhcpbridge=/usr/bin/nova-dhcpbridge --routing_source_ip=x.x.x.x --network_manager=nova.network.manager.FlatDHCPManager --linuxnet_interface_driver=nova.network.linux_net.LinuxBridgeInterfaceDriver --flat_injected=False --flat_interface=eth1 --multi_host=True --floating_range=x.x.x.x --fixed_range=10.0.0.0/23 --fixed_ip_disassociate_timeout=600 --force_dhcp_release=True --use_ipv6=False --allow_resize_to_same_host=True --dhcp_lease_time=62208000 2011/12/1 Leandro Reox leandro.r...@gmail.com: Hi Thats an sqlalchemy error, what database backend are you using ? That error is that actually youre not closing connections and they are not returning to the pool Regards On Thu, Dec 1, 2011 at 7:04 AM, darkfower atk...@gmail.com wrote: hi ,everybody nova compute node error : 2011-12-01 17:35:52,871 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:37:27,531 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:38:27,540 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:39:01,621 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:40:36,781 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:41:36,782 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:42:11,045 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:43:45,621 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:44:45,621 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:45:20,981 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:46:55,161 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:47:55,171 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:48:29,746 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:50:04,291 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:51:04,292 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:51:38,771 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:53:13,591 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01 17:54:13,592 INFO nova.compute.manager [-] Updating host status 2011-12-01 17:54:48,022 WARNING nova.compute.manager [-] Error during power_state sync: QueuePool limit of size 10 overflow 10 reached, connection timed out, timeout 30 2011-12-01
