[Openstack] Why Image upload functionality is not there in Horizon ?
Hi all, After playing around with Openstack Mangement Console, Horizon, I realize that the image upload functionality is not provided there. Is there any special reason for that? Is it because there are no Rest services available at the moment? or else is it felt that providing image upload via the UI is not practically important? -- Best Regards Sajith ___ 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] Live Migration with libvirtError
HI everyone,
when I test live migration use NFS ,that's my sitting according to
http://docs.openstack.org/essex/openstack-compute/admin/content/configuring-live-migrations.html
1.add this line /var/lib/nova/instances *(rw,sync,fsid=0,no_root_squash) in
/etc/exports
2.mount -t nfs 172.18.32.7:/var/lib/nova/instances /var/lib/nova/instances
at compute
and change some setting in libvirt.conf and libvird-bin.conf add a option -l
3.restart service
then I create instance in compute node ,find error
that's my nova-compute.log as follow:
2012-08-09 13:13:03 ERROR nova.manager [-] Error during
ComputeManager.update_available_resource: Failed to connect socket to
'/var/run/libvirt/libvirt-sock': No such file or directory
2012-08-09 13:13:03 TRACE nova.manager Traceback (most recent call last):
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/manager.py, line 155, in
periodic_tasks
2012-08-09 13:13:03 TRACE nova.manager task(self, context)
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 2409, in
update_available_resource
2012-08-09 13:13:03 TRACE nova.manager
self.driver.update_available_resource(context, self.host)
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
1936, in update_available_resource
2012-08-09 13:13:03 TRACE nova.manager 'vcpus_used': self.get_vcpu_used(),
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
1742, in get_vcpu_used
2012-08-09 13:13:03 TRACE nova.manager for dom_id in
self._conn.listDomainsID():
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
298, in _get_connection
2012-08-09 13:13:03 TRACE nova.manager self.read_only)
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
341, in _connect
2012-08-09 13:13:03 TRACE nova.manager return libvirt.openAuth(uri, auth, 0)
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/libvirt.py, line 102, in openAuth
2012-08-09 13:13:03 TRACE nova.manager if ret is None:raise
libvirtError('virConnectOpenAuth() failed')
2012-08-09 13:13:03 TRACE nova.manager libvirtError: Failed to connect
socket to '/var/run/libvirt/libvirt-sock': No such file or directory
2012-08-09 13:13:03 TRACE nova.manager
what's /var/run/libvirt/libvirt-sock'?
why this error?
___
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] DHCP and kernel 3.2
Hello guys, i've just installed kernel 3.4 from Ubuntu kernel PPA archive and after this upgrade VM aren't able to get the DHCP address but with tcpdump i see the request and offer on the network. Someone else experienced this? I've tried also with 3.3, same story. Rolling back to 3.2 and everything works fine. I've tried with both flatdhcp and vlan mode. Best Alessandro ___ 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] KVM live block migration: stability, future, docs
Hi Daniel, Thanks for following this up! On 8 August 2012 19:53, Daniel P. Berrange berra...@redhat.com wrote: not tune this downtime setting, I don't see how you'd see 4 mins downtime unless it was not truely live migration, or there was Yes, quite right. It turns out Nova is not passing/setting libvirt's VIR_MIGRATE_LIVE when it is asked to live-migrate a guest, so it is not proper live-migration. That is the default behaviour unless the flag is added to the migrate flags in nova.conf, unfortunately that flag isn't currently mentioned in the OpenStack docs either. -- Cheers, ~Blairo ___ 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] KVM live block migration: stability, future, docs
Daniel, Thanks for providing this insight, most useful. I'm interpreting this as: block migration can be used in non-critical applications, mileage will vary, thorough testing in the particular environment is recommended. An alternative implementation will come, but the higher level feature (live-migration without shared storage) is unlikely to disappear. Is that a reasonable appraisal? On 8 August 2012 19:59, Daniel P. Berrange berra...@redhat.com wrote: Block migration is a part of the KVM that none of the upstream developers really like, is not entirely reliable, and most distros typically do not want to support it due to its poor design (eg not supported in RHEL). Would you mind/be-able-to elaborate on those reliability issues? E.g., is there anything we can do to mitigate them? -- Cheers, ~Blairo ___ 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] DHCP and kernel 3.2
That sounds like a kernel, kvm or dnsmasq issue, rather than OpenStack itself. I think Quantal is on the 3.5 kernel, and I assume OpenStack is working there.. Maybe give it's dnsmasq package a go first as it's probably the easiest thing to check... Ubuntu also have some 3.5 packages for Precise, although they are test packages.. http://packages.qa.ubuntu.com/qatracker/milestones/223/builds Thanks, Kiall On Aug 9, 2012 8:14 AM, Alessandro Tagliapietra tagliapietra.alessan...@gmail.com wrote: Hello guys, i've just installed kernel 3.4 from Ubuntu kernel PPA archive and after this upgrade VM aren't able to get the DHCP address but with tcpdump i see the request and offer on the network. Someone else experienced this? I've tried also with 3.3, same story. Rolling back to 3.2 and everything works fine. I've tried with both flatdhcp and vlan mode. Best Alessandro ___ 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] [Quantum] Removing quantum-rootwrap
j...@redhat.com wrote: From: Dan Wendlandt d...@nicira.com If someone (Bob?) has the immediate cycles to make rootwrap work in Folsom with low to medium risk of disruption, I'd be open to exploring that, even if it meant inconsistent usage in quantum vs. nova/cinder. Hi Dan. I've been working with Bob, getting myself up to speed on quantum. I've just talked it over with Bob, and I'll take a crack at this one. My approach is going to be to get the quantum rootwrap stuff up to parity with nova. It sounded like some further work might get done in this area for Grizzly, but for the short term, this ought to be fairly non-disruptive. There are a number of changes: * Switch to configuration-based filters This should be relatively straightforward, although Quantum makes use of root_helper in *many* more places than Nova/Cinder do. You can have a look at: https://github.com/openstack/cinder/commit/d2d3c9cba4a647724f75c036a1985a10c966da35 * Switch to rootwrap_config and deprecate root_helper This would fully align quantum-rootwrap with nova-rootwrap. However I'm not sure it's reasonable to deprecate root_helper=sudo in Folsom, given how little tested quantum-rootwrap seems to be on Folsom. Maybe just introducing rootwrap_config but leaving the deprecation message out ? You can have a look at: https://github.com/openstack/cinder/commit/2b2c97eb5ca332ce7d1f83e4fd2e81fabe0acb66 * Add missing filters, fix incomplete ones You have to audit all uses of root_helper and add the corresponding filter. In some cases the filter is there but the parameters are wrong (kill, missing -HUP as an allowed signal). I also spotted one call that sets environment before calling root_helper: that needs to use a specific filter since rootwrap filters the environment out (see how DnsmasqFilter works). * Testing The fact that nobody filed bugs around quantum-rootwrap being unusable tends to show nobody actually uses Quantum with it (hence my suggestion to remove it). If we are to ship that option, it needs to be tested one way or another. I don't think it would be that disruptive (given that quantum-rootwrap doesn't really work right now anyway). It is, however, a significant amount of work to complete before the F3 cut Tuesday at end of day. Corner-case missing filters can be treated as bugs post-F3 though. I'm available to help you and answer any question on the design of the rootwrap you may have. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] DHCP and kernel 3.2
Il giorno 09/ago/2012, alle ore 10:44, Alessandro Tagliapietra tagliapietra.alessan...@gmail.com ha scritto: Il giorno 09/ago/2012, alle ore 10:19, Kiall Mac Innes ki...@managedit.ie ha scritto: That sounds like a kernel, kvm or dnsmasq issue, rather than OpenStack itself. I think Quantal is on the 3.5 kernel, and I assume OpenStack is working there.. Maybe give it's dnsmasq package a go first as it's probably the easiest thing to check… I think that dnsmasq is not the issue, as it's replying to dhcp requests with a dhcp reply. Maybe more a kernel issue with packets, because they don't reach the vm or the vm doesn't receive them. Ubuntu also have some 3.5 packages for Precise, although they are test packages.. http://packages.qa.ubuntu.com/qatracker/milestones/223/builds Going to try with them. I'll reply in a few mins. Got the same issue, this is the tcpdump output: http://pastie.org/4425169 and the vm doesn't get the ip and give up due timeout. Best Alessandro Best Alessandro Thanks, Kiall On Aug 9, 2012 8:14 AM, Alessandro Tagliapietra tagliapietra.alessan...@gmail.com wrote: Hello guys, i've just installed kernel 3.4 from Ubuntu kernel PPA archive and after this upgrade VM aren't able to get the DHCP address but with tcpdump i see the request and offer on the network. Someone else experienced this? I've tried also with 3.3, same story. Rolling back to 3.2 and everything works fine. I've tried with both flatdhcp and vlan mode. Best Alessandro ___ 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] Invoking Glance REST API
Hi all, I'm trying to invoke Openstack Glance REST API s using a Java client, to get image details. etc (Ultimately I need to upload an image) When I invoke http://Glance_URL:PORT/images/detail GET request in Java code, I'm getting *HTTP 300 *as the response code. 4 300 4 Date: Thu, 09 Aug 2012 08:56:29 GMT 4 Content-Length: 222 4 Content-Type: application/json 4 Connection: keep-alive Any idea what could have gone wrong there? -- Best Regards Sajith ___ 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] Live Migration with libvirtError
Hello,
I'm no expert on the subject, but i think you should just use mount -t nfs
172.18.32.7:/ /var/lib/nova/instances instead of mount -t nfs 172.18.32.7:
/var/lib/nova/instances /var/lib/nova/instances. Also from the stack trace
it seems your libvirtd is not running.
On Thu, Aug 9, 2012 at 7:55 AM, 王鹏 breakwin...@gmail.com wrote:
HI everyone,
when I test live migration use NFS ,that's my sitting according to
http://docs.openstack.org/essex/openstack-compute/admin/content/configuring-live-migrations.html
1.add this line /var/lib/nova/instances *(rw,sync,fsid=0,no_root_squash)
in /etc/exports
2.mount -t nfs 172.18.32.7:/var/lib/nova/instances
/var/lib/nova/instances at compute
and change some setting in libvirt.conf and libvird-bin.conf add a option
-l
3.restart service
then I create instance in compute node ,find error
that's my nova-compute.log as follow:
2012-08-09 13:13:03 ERROR nova.manager [-] Error during
ComputeManager.update_available_resource: Failed to connect socket to
'/var/run/libvirt/libvirt-sock': No such file or directory
2012-08-09 13:13:03 TRACE nova.manager Traceback (most recent call last):
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/manager.py, line 155, in
periodic_tasks
2012-08-09 13:13:03 TRACE nova.manager task(self, context)
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 2409, in
update_available_resource
2012-08-09 13:13:03 TRACE nova.manager
self.driver.update_available_resource(context, self.host)
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
1936, in update_available_resource
2012-08-09 13:13:03 TRACE nova.manager 'vcpus_used': self.get_vcpu_used(),
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
1742, in get_vcpu_used
2012-08-09 13:13:03 TRACE nova.manager for dom_id in
self._conn.listDomainsID():
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
298, in _get_connection
2012-08-09 13:13:03 TRACE nova.manager self.read_only)
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
341, in _connect
2012-08-09 13:13:03 TRACE nova.manager return libvirt.openAuth(uri, auth,
0)
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/libvirt.py, line 102, in openAuth
2012-08-09 13:13:03 TRACE nova.manager if ret is None:raise
libvirtError('virConnectOpenAuth() failed')
2012-08-09 13:13:03 TRACE nova.manager libvirtError: Failed to connect
socket to '/var/run/libvirt/libvirt-sock': No such file or directory
2012-08-09 13:13:03 TRACE nova.manager
what's /var/run/libvirt/libvirt-sock'?
why this error?
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
--
Cumprimentos / Regards,
Leander
___
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] Help with meta-data
On 08/09/2012 01:11 PM, tacy lee wrote: try adding metadata_host to nova.conf The thing is the iptable rules have 169.254.169.254 NATed correctly. So the address is correct. It's just that the VMs cannot access it. -- simonsmicrophone.com ___ 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] Help with meta-data
On 08/09/2012 12:59 PM, Scott Moser wrote: On Aug 8, 2012, at 8:20 PM, Simon Walter si...@gikaku.com wrote: On 08/09/2012 06:45 AM, Jay Pipes I guess I'll have to build a VM from scratch, as I was relying on the ssh key to be able to ssh into the VM, which apparently is supplied by the meta-data service. use cirros. load an image, ssh on with 'cirros' user. pass is 'cubswin:)' Thank you. That was good advice. Somehow I was not able to connect via ssh. I managed to get novnc working and logged into the VM. I can't find anything about connecting via serial or the like as you can with Xen. I need to read more about KVM I guess. Anyway, I think my networking setup is stuffed. I thought the 10 minutes install would be the quickest way to get and running. Now I find myself pouring over documentation trying to understand how best to setup FlatDHCPManager with two network interfaces. I understand many things have changed. So I don't want to go reading something out of date. I found these blog posts which explained a lot: http://www.mirantis.com/blog/openstack-networking-flatmanager-and-flatdhcpmanager/#comments http://www.mirantis.com/blog/openstack-networking-single-host-flatdhcpmanager/ But am I reading the wrong thing? I like the way Stackgeek had it set up: http://stackgeek.com/guides/gettingstarted.html But I think they are missing details or it's out dated. For example, with their setup the vnc console in horizon does not work because nova-vncproxy is installed rather than novnc. I'm pretty sure I can figure the networking out if I have the right documentation in the first place. Is there a clear instructions for this anywhere? Or would someone mind walking me through it again. So far I've followed the stackgeek setup above, but the networking is obviously stuffed. Must I have the flat_interface in promiscuous mode? Or does it actually need an IP address? Why are my VMs picking up an IP address from the public_interface DHCP server and not from the flat_network_bridge? Too many questions to ask. So I thought I should just ask: what is missing or incorrect from Stackgeeks 10 minute scripts? Many thanks for any advice, tips, docs, etc. Cheers, Simon -- simonsmicrophone.com ___ 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] Live Migration with libvirtError
On 08/09/2012 07:55 AM, 王鹏 wrote: HI everyone, when I test live migration use NFS ,that's my sitting according to http://docs.openstack.org/essex/openstack-compute/admin/content/configuring-live-migrations.html 1.add this line /var/lib/nova/instances *(rw,sync,fsid=0,no_root_squash) in /etc/exports 2.mount -t nfs 172.18.32.7:/var/lib/nova/instances /var/lib/nova/instances at compute and change some setting in libvirt.conf and libvird-bin.conf add a option -l 3.restart service then I create instance in compute node ,find error that's my nova-compute.log as follow: 2012-08-09 13:13:03 TRACE nova.manager libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory what's /var/run/libvirt/libvirt-sock'? why this error? That usually means libvirtd isn't running. I'd double check the libvirt option settings you changed, and then check in /var/log/libvirt/ For reference, here are the Fedora notes for configuring the feature: https://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL#Live_Migration_of_VM_instances cheers, Pádraig. ___ 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] Live Migration with libvirtError
Hi
Probably, before We had same problem.
Could you check libvirt log and resolve your host domain and nova.conf
vncserver_listen part?
(vncserver_listen=0.0.0.0)
Thanks!
Suzuki
On Thu, Aug 9, 2012 at 6:27 PM, Leander Bessa Beernaert
leande...@gmail.com wrote:
Hello,
I'm no expert on the subject, but i think you should just use mount -t nfs
172.18.32.7:/ /var/lib/nova/instances instead of mount -t nfs
172.18.32.7:/var/lib/nova/instances /var/lib/nova/instances. Also from the
stack trace it seems your libvirtd is not running.
On Thu, Aug 9, 2012 at 7:55 AM, 王鹏 breakwin...@gmail.com wrote:
HI everyone,
when I test live migration use NFS ,that's my sitting according to
http://docs.openstack.org/essex/openstack-compute/admin/content/configuring-live-migrations.html
1.add this line /var/lib/nova/instances *(rw,sync,fsid=0,no_root_squash)
in /etc/exports
2.mount -t nfs 172.18.32.7:/var/lib/nova/instances /var/lib/nova/instances
at compute
and change some setting in libvirt.conf and libvird-bin.conf add a option
-l
3.restart service
then I create instance in compute node ,find error
that's my nova-compute.log as follow:
2012-08-09 13:13:03 ERROR nova.manager [-] Error during
ComputeManager.update_available_resource: Failed to connect socket to
'/var/run/libvirt/libvirt-sock': No such file or directory
2012-08-09 13:13:03 TRACE nova.manager Traceback (most recent call last):
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/manager.py, line 155, in
periodic_tasks
2012-08-09 13:13:03 TRACE nova.manager task(self, context)
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 2409, in
update_available_resource
2012-08-09 13:13:03 TRACE nova.manager
self.driver.update_available_resource(context, self.host)
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
1936, in update_available_resource
2012-08-09 13:13:03 TRACE nova.manager 'vcpus_used': self.get_vcpu_used(),
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
1742, in get_vcpu_used
2012-08-09 13:13:03 TRACE nova.manager for dom_id in
self._conn.listDomainsID():
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
298, in _get_connection
2012-08-09 13:13:03 TRACE nova.manager self.read_only)
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
341, in _connect
2012-08-09 13:13:03 TRACE nova.manager return libvirt.openAuth(uri, auth,
0)
2012-08-09 13:13:03 TRACE nova.manager File
/usr/lib/python2.7/dist-packages/libvirt.py, line 102, in openAuth
2012-08-09 13:13:03 TRACE nova.manager if ret is None:raise
libvirtError('virConnectOpenAuth() failed')
2012-08-09 13:13:03 TRACE nova.manager libvirtError: Failed to connect
socket to '/var/run/libvirt/libvirt-sock': No such file or directory
2012-08-09 13:13:03 TRACE nova.manager
what's /var/run/libvirt/libvirt-sock'?
why this error?
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
--
Cumprimentos / Regards,
Leander
___
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] [Quantum] Removing quantum-rootwrap
From: Thierry Carrez thie...@openstack.org Date: Thu, 09 Aug 2012 10:34:17 +0200 j...@redhat.com wrote: From: Dan Wendlandt d...@nicira.com If someone (Bob?) has the immediate cycles to make rootwrap work in Folsom with low to medium risk of disruption, I'd be open to exploring that, even if it meant inconsistent usage in quantum vs. nova/cinder. Hi Dan. I've been working with Bob, getting myself up to speed on quantum. I've just talked it over with Bob, and I'll take a crack at this one. My approach is going to be to get the quantum rootwrap stuff up to parity with nova. It sounded like some further work might get done in this area for Grizzly, but for the short term, this ought to be fairly non-disruptive. There are a number of changes: * Switch to configuration-based filters This should be relatively straightforward, although Quantum makes use of root_helper in *many* more places than Nova/Cinder do. You can have a look at: https://github.com/openstack/cinder/commit/d2d3c9cba4a647724f75c036a1985a10c966da35 Yes, I believe that's one of the changesets I've already been looking at. Glad to know I'm not off in the weeds :-) * Switch to rootwrap_config and deprecate root_helper This would fully align quantum-rootwrap with nova-rootwrap. However I'm not sure it's reasonable to deprecate root_helper=sudo in Folsom, given how little tested quantum-rootwrap seems to be on Folsom. Maybe just introducing rootwrap_config but leaving the deprecation message out ? You can have a look at: https://github.com/openstack/cinder/commit/2b2c97eb5ca332ce7d1f83e4fd2e81fabe0acb66 Ok. I did talk through this issue with Bob yesterday, but I'd be lying if I said I understood it all yet. Let me ask this: Since, as you say, there's not a lot of evidence of traffic through quantum-rootwrap, is there an obvious downside to deprecating root_helper=sudo at this stage? I'm not advocating either way, just trying to get up to speed on all the parts of the issue. * Add missing filters, fix incomplete ones You have to audit all uses of root_helper and add the corresponding filter. In some cases the filter is there but the parameters are wrong (kill, missing -HUP as an allowed signal). I also spotted one call that sets environment before calling root_helper: that needs to use a specific filter since rootwrap filters the environment out (see how DnsmasqFilter works). Ok. I haven't seen those, or didn't know what I was looking at, but I'll keep attention out for that stuff. * Testing The fact that nobody filed bugs around quantum-rootwrap being unusable tends to show nobody actually uses Quantum with it (hence my suggestion to remove it). If we are to ship that option, it needs to be tested one way or another. Yes. Honestly, this is the part which I feel most unsure about. But I've decided to try to get my head around the code first, and then understand the testing implications. I will doubtless have more questions about that. I don't think it would be that disruptive (given that quantum-rootwrap doesn't really work right now anyway). It is, however, a significant amount of work to complete before the F3 cut Tuesday at end of day. Corner-case missing filters can be treated as bugs post-F3 though. Ok, understood. My goal is by end of today , or tomorrow morning latest, to have at least a reasonably complete understanding of the changes necessary to get the quantum-rootwrap facility up to parity with nova/cinder. If I get to that deadline and I'm not there, I'll probably punt, as it becomes too much of a hail-mary to get the stuff stabilized and reviewed etc by tues. I'm available to help you and answer any question on the design of the rootwrap you may have. Thanks very much. I will certainly have more questions as I proceed. ___ 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] Keystone: 'PKI Signed Tokens' lack support for revocation
Hi Adam, The blueprint as revised to address Joe's comments looks good to me - nice work. I especially like how the middleware is intended to cache the revocation list for a configurable amount of time - it mirrors how token caching already works. Cheers, Maru On 2012-08-07, at 10:09 AM, Adam Young wrote: On 08/01/2012 09:19 PM, Maru Newby wrote: I see that support for PKI Signed Tokens has been added to Keystone without support for token revocation. I tried to raise this issue on the bug report: https://bugs.launchpad.net/keystone/+bug/1003962/comments/4 And the review: https://review.openstack.org/#/c/7754/ I'm curious as to whether anybody shares my concern and if there is a specific reason why nobody responded to my question as to why revocation is not required for this new token scheme. Anybody? I have written up a blueprint for PKI token revocation. Please provide feedback. https://blueprints.launchpad.net/keystone/+spec/pki-revoke Thanks, Maru ___ 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Essex multi-node setup/ can't ssh to compute node
Hi, list, I'm setting up openstack on Ubuntu 12.04 LTS with FlatDHCP mode network configuration. . Everything is OK in control node, but in compute node, I always meet with the following issue. So I can’t ssh to the vm instance. 2012-08-09 13:31:28,290 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [50/120s]: url error [timed out] 2012-08-09 13:32:19,342 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [101/120s]: url error [timed out] 2012-08-09 13:32:37,361 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [119/120s]: url error [timed out] 2012-08-09 13:32:38,363 - DataSourceEc2.py[CRITICAL]: giving up on md after 120 seconds This is my nova.conf [DEFAULT] ## LOGS/STATE #verbose=True verbose=False ## AUTHENTICATION auth_strategy=keystone ## SCHEDULER #--compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler scheduler_driver=nova.scheduler.simple.SimpleScheduler ## VOLUMES volume_group=nova-volumes volume_name_template=volume-%08x iscsi_helper=tgtadm ## DATABASE sql_connection=mysql://nova:pwd@10.10.135.30/nova ## COMPUTE libvirt_type=kvm #libvirt_type=qemu connection_type=libvirt instance_name_template=instance-%08x api_paste_config=/etc/nova/api-paste.ini allow_resize_to_same_host=True libvirt_use_virtio_for_bridges=true start_guests_on_host_boot=true resume_guests_state_on_host_boot=true ## APIS osapi_compute_extension=nova.api.openstack.compute.contrib.standard_extensio ns allow_admin_api=true s3_host=10.10.135.30 cc_host=10.10.135.30 ## RABBITMQ rabbit_host=10.10.135.30 ## GLANCE image_service=nova.image.glance.GlanceImageService glance_api_servers=10.10.135.30:9292 ## NETWORK network_manager=nova.network.manager.FlatDHCPManager force_dhcp_release=True dhcpbridge_flagfile=/etc/nova/nova.conf dhcpbridge=/usr/bin/nova-dhcpbridge firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver public_interface=eth0 flat_interface=eth1 flat_network_bridge=br100 fixed_range=192.168.1.0/24 multi_host=true ## NOVNC CONSOLE novnc_enabled=true novncproxy_base_url= http://10.10.135.30:6080/vnc_auto.html vncserver_proxyclient_address=10.10.135.29 vncserver_listen=10.10.135.29 Nova logdir=/var/log/nova state_path=/var/lib/nova lock_path=/var/lock/nova metadata_host=10.10.135.29 #MISC use_deprecated_auth=false root_helper=sudo nova-rootwrap Thanks Danming ___ 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] KVM live block migration: stability, future, docs
On Aug 9, 2012, at 1:03 AM, Blair Bethwaite blair.bethwa...@gmail.com wrote: Hi Daniel, Thanks for following this up! On 8 August 2012 19:53, Daniel P. Berrange berra...@redhat.com wrote: not tune this downtime setting, I don't see how you'd see 4 mins downtime unless it was not truely live migration, or there was Yes, quite right. It turns out Nova is not passing/setting libvirt's VIR_MIGRATE_LIVE when it is asked to live-migrate a guest, so it is not proper live-migration. That is the default behaviour unless the flag is added to the migrate flags in nova.conf, unfortunately that flag isn't currently mentioned in the OpenStack docs either. Can you file a bug on this to change the default? I don't see any reason why this should be off. Vish ___ 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] KVM live block migration: stability, future, docs
On Thu, Aug 09, 2012 at 07:10:17AM -0700, Vishvananda Ishaya wrote: On Aug 9, 2012, at 1:03 AM, Blair Bethwaite blair.bethwa...@gmail.com wrote: Hi Daniel, Thanks for following this up! On 8 August 2012 19:53, Daniel P. Berrange berra...@redhat.com wrote: not tune this downtime setting, I don't see how you'd see 4 mins downtime unless it was not truely live migration, or there was Yes, quite right. It turns out Nova is not passing/setting libvirt's VIR_MIGRATE_LIVE when it is asked to live-migrate a guest, so it is not proper live-migration. That is the default behaviour unless the flag is added to the migrate flags in nova.conf, unfortunately that flag isn't currently mentioned in the OpenStack docs either. Can you file a bug on this to change the default? I don't see any reason why this should be off. With non-live migration, the migration operation is guaranteed to complete. With live migration, you can get into a non-convergence scenario where the guest is dirtying data faster than it can be migrated. With the way Nova currently works the live migration will just run forever with no way to stop it. So if you want to enable live migration by default, we'll need todo more than simply set the flag. Nova will need to be able to monitor the migration, and either cancel it after some time, or tune the max allowed downtime to let it complete Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ 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] KVM live block migration: stability, future, docs
On Aug 9, 2012, at 7:13 AM, Daniel P. Berrange berra...@redhat.com wrote: With non-live migration, the migration operation is guaranteed to complete. With live migration, you can get into a non-convergence scenario where the guest is dirtying data faster than it can be migrated. With the way Nova currently works the live migration will just run forever with no way to stop it. So if you want to enable live migration by default, we'll need todo more than simply set the flag. Nova will need to be able to monitor the migration, and either cancel it after some time, or tune the max allowed downtime to let it complete Ah good to know. So it sounds like we should keep the default as-is for now and revisit it later. Vish ___ 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] [Quantum] Removing quantum-rootwrap
j...@redhat.com wrote: * Switch to rootwrap_config and deprecate root_helper This would fully align quantum-rootwrap with nova-rootwrap. However I'm not sure it's reasonable to deprecate root_helper=sudo in Folsom, given how little tested quantum-rootwrap seems to be on Folsom. Maybe just introducing rootwrap_config but leaving the deprecation message out ? You can have a look at: https://github.com/openstack/cinder/commit/2b2c97eb5ca332ce7d1f83e4fd2e81fabe0acb66 Ok. I did talk through this issue with Bob yesterday, but I'd be lying if I said I understood it all yet. Let me ask this: Since, as you say, there's not a lot of evidence of traffic through quantum-rootwrap, is there an obvious downside to deprecating root_helper=sudo at this stage? I'm not advocating either way, just trying to get up to speed on all the parts of the issue. Well, since there is not a lot of evidence of traffic through the rootwrap, that means almost everyone is using root_helper=sudo. Marking it deprecated, and recommending that everyone switches to the (untested yet) rootwrap doesn't sound that much like a great idea. I think we should deprecate root_helper=sudo when we are confident that most people are using rootwrap and are satisfied with it. My goal is by end of today , or tomorrow morning latest, to have at least a reasonably complete understanding of the changes necessary to get the quantum-rootwrap facility up to parity with nova/cinder. If I get to that deadline and I'm not there, I'll probably punt, as it becomes too much of a hail-mary to get the stuff stabilized and reviewed etc by tues. That sounds reasonable. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] [Quantum] Removing quantum-rootwrap
From: Thierry Carrez thie...@openstack.org Date: Thu, 09 Aug 2012 16:32:23 +0200 j...@redhat.com wrote: * Switch to rootwrap_config and deprecate root_helper This would fully align quantum-rootwrap with nova-rootwrap. However I'm not sure it's reasonable to deprecate root_helper=sudo in Folsom, given how little tested quantum-rootwrap seems to be on Folsom. Maybe just introducing rootwrap_config but leaving the deprecation message out ? You can have a look at: https://github.com/openstack/cinder/commit/2b2c97eb5ca332ce7d1f83e4fd2e81fabe0acb66 Ok. I did talk through this issue with Bob yesterday, but I'd be lying if I said I understood it all yet. Let me ask this: Since, as you say, there's not a lot of evidence of traffic through quantum-rootwrap, is there an obvious downside to deprecating root_helper=sudo at this stage? I'm not advocating either way, just trying to get up to speed on all the parts of the issue. Well, since there is not a lot of evidence of traffic through the rootwrap, that means almost everyone is using root_helper=sudo. Marking it deprecated, and recommending that everyone switches to the (untested yet) rootwrap doesn't sound that much like a great idea. Ah. Ok, got it. I think we should deprecate root_helper=sudo when we are confident that most people are using rootwrap and are satisfied with it. Yes, concur. Thanks. Onward... ___ 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] Essex multi-node setup/ can't ssh to compute node
With multihost=True, every nova-compute node also needs nova-api-metadata installed.. That should sort it out... Thanks, Kiall On Aug 9, 2012 2:58 PM, 谢丹铭 xiedanm...@qiyi.com wrote: Hi, list, I'm setting up openstack on Ubuntu 12.04 LTS with FlatDHCP mode network configuration. . Everything is OK in control node, but in compute node, I always meet with the following issue. So I can’t ssh to the vm instance. 2012-08-09 13:31:28,290 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [50/120s]: url error [timed out] 2012-08-09 13:32:19,342 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [101/120s]: url error [timed out] 2012-08-09 13:32:37,361 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [119/120s]: url error [timed out] 2012-08-09 13:32:38,363 - DataSourceEc2.py[CRITICAL]: giving up on md after 120 seconds This is my nova.conf [DEFAULT] ## LOGS/STATE #verbose=True verbose=False ## AUTHENTICATION auth_strategy=keystone ## SCHEDULER #--compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler scheduler_driver=nova.scheduler.simple.SimpleScheduler ## VOLUMES volume_group=nova-volumes volume_name_template=volume-%08x iscsi_helper=tgtadm ## DATABASE sql_connection=mysql://nova:pwd@10.10.135.30/nova ## COMPUTE libvirt_type=kvm #libvirt_type=qemu connection_type=libvirt instance_name_template=instance-%08x api_paste_config=/etc/nova/api-paste.ini allow_resize_to_same_host=True libvirt_use_virtio_for_bridges=true start_guests_on_host_boot=true resume_guests_state_on_host_boot=true ## APIS osapi_compute_extension=nova.api.openstack.compute.contrib.standard_extensio ns allow_admin_api=true s3_host=10.10.135.30 cc_host=10.10.135.30 ## RABBITMQ rabbit_host=10.10.135.30 ## GLANCE image_service=nova.image.glance.GlanceImageService glance_api_servers=10.10.135.30:9292 ## NETWORK network_manager=nova.network.manager.FlatDHCPManager force_dhcp_release=True dhcpbridge_flagfile=/etc/nova/nova.conf dhcpbridge=/usr/bin/nova-dhcpbridge firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver public_interface=eth0 flat_interface=eth1 flat_network_bridge=br100 fixed_range=192.168.1.0/24 multi_host=true ## NOVNC CONSOLE novnc_enabled=true novncproxy_base_url= http://10.10.135.30:6080/vnc_auto.html vncserver_proxyclient_address=10.10.135.29 vncserver_listen=10.10.135.29 Nova logdir=/var/log/nova state_path=/var/lib/nova lock_path=/var/lock/nova metadata_host=10.10.135.29 #MISC use_deprecated_auth=false root_helper=sudo nova-rootwrap Thanks Danming ___ 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] Essex multi-node setup/ can't ssh to compute node
Also the metadata host should be set to 127.0.0.1 for multihost=True.. Thanks, Kiall On Aug 9, 2012 2:58 PM, 谢丹铭 xiedanm...@qiyi.com wrote: Hi, list, I'm setting up openstack on Ubuntu 12.04 LTS with FlatDHCP mode network configuration. . Everything is OK in control node, but in compute node, I always meet with the following issue. So I can’t ssh to the vm instance. 2012-08-09 13:31:28,290 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [50/120s]: url error [timed out] 2012-08-09 13:32:19,342 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [101/120s]: url error [timed out] 2012-08-09 13:32:37,361 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [119/120s]: url error [timed out] 2012-08-09 13:32:38,363 - DataSourceEc2.py[CRITICAL]: giving up on md after 120 seconds This is my nova.conf [DEFAULT] ## LOGS/STATE #verbose=True verbose=False ## AUTHENTICATION auth_strategy=keystone ## SCHEDULER #--compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler scheduler_driver=nova.scheduler.simple.SimpleScheduler ## VOLUMES volume_group=nova-volumes volume_name_template=volume-%08x iscsi_helper=tgtadm ## DATABASE sql_connection=mysql://nova:pwd@10.10.135.30/nova ## COMPUTE libvirt_type=kvm #libvirt_type=qemu connection_type=libvirt instance_name_template=instance-%08x api_paste_config=/etc/nova/api-paste.ini allow_resize_to_same_host=True libvirt_use_virtio_for_bridges=true start_guests_on_host_boot=true resume_guests_state_on_host_boot=true ## APIS osapi_compute_extension=nova.api.openstack.compute.contrib.standard_extensio ns allow_admin_api=true s3_host=10.10.135.30 cc_host=10.10.135.30 ## RABBITMQ rabbit_host=10.10.135.30 ## GLANCE image_service=nova.image.glance.GlanceImageService glance_api_servers=10.10.135.30:9292 ## NETWORK network_manager=nova.network.manager.FlatDHCPManager force_dhcp_release=True dhcpbridge_flagfile=/etc/nova/nova.conf dhcpbridge=/usr/bin/nova-dhcpbridge firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver public_interface=eth0 flat_interface=eth1 flat_network_bridge=br100 fixed_range=192.168.1.0/24 multi_host=true ## NOVNC CONSOLE novnc_enabled=true novncproxy_base_url= http://10.10.135.30:6080/vnc_auto.html vncserver_proxyclient_address=10.10.135.29 vncserver_listen=10.10.135.29 Nova logdir=/var/log/nova state_path=/var/lib/nova lock_path=/var/lock/nova metadata_host=10.10.135.29 #MISC use_deprecated_auth=false root_helper=sudo nova-rootwrap Thanks Danming ___ 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] Help with meta-data
All, sorry for top posting, but this is a fine example of why we really need bloggers to help with the documentation. These fragmented instructions are difficult to rely on - we need maintainable, process-oriented treatment of content. Mirantis peeps, you have added in your blog entries to the docs in the past, let's find ways to continually do that and maintain going forward. I'm not so interested in more install guides, but definitely interested in more configuration guides. So Kord, while I like the idea (and execution!) of the StackGeek 10-minute guide, it's not one to bring into the official docs. But we would definitely welcome your reviews of incoming updates to the docs! Thanks Simon for bringing your difficulties to the list - we continually work on improving the docs. What you learn now could help hundreds if not thousands of others, so I'd love for you to improve the official docs with your findings. Thanks, Anne On Thu, Aug 9, 2012 at 4:42 AM, Simon Walter si...@gikaku.com wrote: On 08/09/2012 12:59 PM, Scott Moser wrote: On Aug 8, 2012, at 8:20 PM, Simon Walter si...@gikaku.com wrote: On 08/09/2012 06:45 AM, Jay Pipes I guess I'll have to build a VM from scratch, as I was relying on the ssh key to be able to ssh into the VM, which apparently is supplied by the meta-data service. use cirros. load an image, ssh on with 'cirros' user. pass is 'cubswin:)' Thank you. That was good advice. Somehow I was not able to connect via ssh. I managed to get novnc working and logged into the VM. I can't find anything about connecting via serial or the like as you can with Xen. I need to read more about KVM I guess. Anyway, I think my networking setup is stuffed. I thought the 10 minutes install would be the quickest way to get and running. Now I find myself pouring over documentation trying to understand how best to setup FlatDHCPManager with two network interfaces. I understand many things have changed. So I don't want to go reading something out of date. I found these blog posts which explained a lot: http://www.mirantis.com/blog/openstack-networking-flatmanager-and-flatdhcpmanager/#comments http://www.mirantis.com/blog/openstack-networking-single-host-flatdhcpmanager/ But am I reading the wrong thing? I like the way Stackgeek had it set up: http://stackgeek.com/guides/gettingstarted.html But I think they are missing details or it's out dated. For example, with their setup the vnc console in horizon does not work because nova-vncproxy is installed rather than novnc. I'm pretty sure I can figure the networking out if I have the right documentation in the first place. Is there a clear instructions for this anywhere? Or would someone mind walking me through it again. So far I've followed the stackgeek setup above, but the networking is obviously stuffed. Must I have the flat_interface in promiscuous mode? Or does it actually need an IP address? Why are my VMs picking up an IP address from the public_interface DHCP server and not from the flat_network_bridge? Too many questions to ask. So I thought I should just ask: what is missing or incorrect from Stackgeeks 10 minute scripts? Many thanks for any advice, tips, docs, etc. Cheers, Simon -- simonsmicrophone.com ___ 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] using extra specs
Hi guys,
I currently have a working cloud with a working GPU passthrough setup
(CentOS/libvirt/Xen 4.1.2), now I need to work on adding this new resource to
openstack.
Here is the plan:
1. Create a new instance type (g1.small) with an extra spec like
xpu_arch = radeon
2. Modify the compute side so that nova-compute publishes this new
capability
I'm in between step 1 and step 2, so normally, when I try and launch a VM with
the new instance type, the scheduling should fail since there is no compute
node publishing this capability yet, but the scheduling does go through despite
having the ComputeFilter available.
My understanding is that by having:
scheduler_available_filters=nova.schedulre.filters.standard_filters
scheduler_default_filters=ComputeFilter
The ComputeFilter should try and ensure that the hosts satisfies the extra
specs but the filter is not doing its job since the VM is scheduler and casted
to the compute node although it does not advertise any of the extra spec.
The extra spec is definitely part of the instance_type, I can see it in the
scheduler log:
(TRUNCATED) u'8895af5063b176bef97ab81f076d57f3', u'min_disk': u'0',
u'is_public': True, u'deleted_at': None, u'properties': {u'os_type':
u'windows'}, u'size': 9256562688}, u'instance_type': {u'root_gb': 0,
u'deleted_at': None, u'name': u'g1.small', u'deleted': False, u'created_at':
u'2012-08-08 18:33:29', u'ephemeral_gb': 0, u'updated_at': None, u'memory_mb':
2048, u'vcpus': 1, u'extra_specs': {u'xpu_arch': u'radeon'}, u'swap': 0,
u'rxtx_factor': 1.0, u'flavorid': u'105', u'vcpu_weight': None, u'id': 6},
u'instance_properties': {u'vm_state': u'building', u'availability_zone':
(TRUNCATED)
So again, this VM should not be casted to any compute node and the scheduler
should complain about no host having the required capability but it does not...
the VM is instantiated on the one compute node even though it never published
the required capability.
It looks like the ComputeFilter is either not used properly or I'm missing
something. Basically I want the scheduler to fail when I launch the VM before
I start working on step 2.
Any help appreciated.
Boris
___
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] [Quantum] Removing quantum-rootwrap
On 08/09/2012 10:32 AM, Thierry Carrez wrote: j...@redhat.com wrote: * Switch to rootwrap_config and deprecate root_helper This would fully align quantum-rootwrap with nova-rootwrap. However I'm not sure it's reasonable to deprecate root_helper=sudo in Folsom, given how little tested quantum-rootwrap seems to be on Folsom. Maybe just introducing rootwrap_config but leaving the deprecation message out ? You can have a look at: https://github.com/openstack/cinder/commit/2b2c97eb5ca332ce7d1f83e4fd2e81fabe0acb66 Ok. I did talk through this issue with Bob yesterday, but I'd be lying if I said I understood it all yet. Let me ask this: Since, as you say, there's not a lot of evidence of traffic through quantum-rootwrap, is there an obvious downside to deprecating root_helper=sudo at this stage? I'm not advocating either way, just trying to get up to speed on all the parts of the issue. Well, since there is not a lot of evidence of traffic through the rootwrap, that means almost everyone is using root_helper=sudo. Marking it deprecated, and recommending that everyone switches to the (untested yet) rootwrap doesn't sound that much like a great idea. I think we should deprecate root_helper=sudo when we are confident that most people are using rootwrap and are satisfied with it. By almost everyone and most people, do you mean users of devstack? I'd hate to think people are trying to deploy the quantum Folsom master branch with all the change that's been going on. We should immediately change devstack to stop running the quantum agents as root, so at least the root_helper=sudo functionality is really being used. It looks like devstack does configure nova with the new rootwrap/rootwrap_config and does not run any of its services as root. Doing the same for quantum would seem get some mileage on it. What exactly is involved in deprecating root_helper=sudo? Is this something we could chose whether or not to do at the last minute after implementing the new rootwrap and changing devstack to use it? Thanks, -Bob My goal is by end of today , or tomorrow morning latest, to have at least a reasonably complete understanding of the changes necessary to get the quantum-rootwrap facility up to parity with nova/cinder. If I get to that deadline and I'm not there, I'll probably punt, as it becomes too much of a hail-mary to get the stuff stabilized and reviewed etc by tues. That sounds reasonable. ___ 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] using extra specs
Boris-Michel,
One thing that I noticed was a typo: schedulre that can cause malfunction. I am
not sure what version you are using, but recently the extra_spec checking is
moved to compute_capabilities_filter.py (ComputeCapabilitiesFilter). As far as
I understand, the current ComputeFilter does not check extra_specs.
Thanks,
Joseph
(w) 703-248-6160
(c) 571-340-2434
(f) 703-812-3712
http://www.east.isi.edu/~jsuh
Information Sciences Institute
University of Southern California
3811 N. Fairfax Drive Suite 200
Arlington, VA, 22203, USA
- Original Message -
From: Boris-Michel Deschenes boris-michel.desche...@ubisoft.com
To: openstack@lists.launchpad.net
Sent: Thursday, August 9, 2012 11:10:15 AM
Subject: [Openstack] using extra specs
Hi guys,
I currently have a working cloud with a working GPU passthrough setup
(CentOS/libvirt/Xen 4.1.2), now I need to work on adding this new resource to
openstack.
Here is the plan:
1. Create a new instance type (g1.small) with an extra spec like “xpu_arch =
radeon”
2. Modify the compute side so that nova-compute publishes this new capability
I’m in between step 1 and step 2, so normally, when I try and launch a VM with
the new instance type, the scheduling should fail since there is no compute
node publishing this capability yet, but the scheduling does go through despite
having the ComputeFilter available.
My understanding is that by having:
scheduler_available_filters=nova.schedulre.filters.standard_filters
scheduler_default_filters=ComputeFilter
The ComputeFilter should try and ensure that the hosts satisfies the extra
specs but the filter is not doing its job since the VM is scheduler and casted
to the compute node although it does not advertise any of the extra spec.
The extra spec is definitely part of the instance_type, I can see it in the
scheduler log:
(TRUNCATED) u'8895af5063b176bef97ab81f076d57f3', u'min_disk': u'0',
u'is_public': True, u'deleted_at': None, u'properties': {u'os_type':
u'windows'}, u'size': 9256562688}, u'instance_type': {u'root_gb': 0,
u'deleted_at': None, u'name': u'g1.small', u'deleted': False, u'created_at':
u'2012-08-08 18:33:29', u'ephemeral_gb': 0, u'updated_at': None, u'memory_mb':
2048, u'vcpus': 1, u'extra_specs': {u'xpu_arch': u'radeon'}, u'swap': 0,
u'rxtx_factor': 1.0, u'flavorid': u'105', u'vcpu_weight': None, u'id': 6},
u'instance_properties': {u'vm_state': u'building', u'availability_zone':
(TRUNCATED)
So again, this VM should not be casted to any compute node and the scheduler
should complain about no host having the required capability but it does not…
the VM is instantiated on the one compute node even though it never published
the required capability.
It looks like the ComputeFilter is either not used properly or I’m missing
something. Basically I want the scheduler to fail when I launch the VM before I
start working on step 2.
Any help appreciated.
Boris
___
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] Invoking Glance REST API
You're getting a '300 Multiple Choices' response as you haven't indicated a version in your request. You can parse the body as json (indicated in the headers) to see what API versions are available to you at any given time. If you don't care about taking that extra step, just use a URI with 'v1' as the first token in your path: http://Glance_URL:PORT/v1/images/detail Brian Waldon On Aug 9, 2012, at 2:05 AM, Sajith Kariyawasam wrote: Hi all, I'm trying to invoke Openstack Glance REST API s using a Java client, to get image details. etc (Ultimately I need to upload an image) When I invoke http://Glance_URL:PORT/images/detail GET request in Java code, I'm getting HTTP 300 as the response code. 4 300 4 Date: Thu, 09 Aug 2012 08:56:29 GMT 4 Content-Length: 222 4 Content-Type: application/json 4 Connection: keep-alive Any idea what could have gone wrong there? -- Best Regards Sajith ___ 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] LBaaS IRC meeting notes
REMINDER: Another meeting will take place today, in ~2 hours from now (19:00 UTC), on #openstack-meeting (use http://webchat.freenode.net/ to join). On Mon, Aug 6, 2012 at 3:09 PM, Eugene Kirpichov ekirpic...@gmail.com wrote: Hi, Below are the meeting notes from the IRC meeting about LBaaS which took place on Aug 2. The logs can be found at http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-02-17.00.log.html [19:18:27 .. 19:56:41] === Status on our side === https://github.com/Mirantis/openstack-lbaas * HAproxy and ACE implemented to some level. * F5 to be finished in 6 weeks. By that time driver API will be stable. * Support for device capabilities (drivers report them, users request them) on its way to master. === Discussion with Dan Went of Quantum === Dan said: * Quantum is moving up the stack: L2 in essex, L3 in folsom, and in Grizzly we'll be moving into L4-L7 * Many people in Quantum are generally interested in LBaaS * We need to make sure we're not duplicating effort by developing our own CLI/GUI for LBaaS. We should at least integrate with the Quantum CLI framework and generally collaborate with the Quantum community (circulate blueprints and POC). The next meeting will take place Aug 9, 19:00 UTC at #openstack-meeting. -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov ___ 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] using extra specs
Joseph,
Yes sorry about the typo I was retyping these lines in the email.
Whatever, the problem seems to be that the Simple Scheduler I'm using is not
running the filters at all, so I now use the filter_scheduler (I'm on essex by
the way) and the filter does its job and filters out the host since it does not
have the extra spec.
Thanks,
Boris
-Message d'origine-
De : Joseph Suh [mailto:j...@isi.edu]
Envoyé : 9 août 2012 12:29
À : Boris-Michel Deschenes
Cc : openstack@lists.launchpad.net
Objet : Re: [Openstack] using extra specs
Boris-Michel,
One thing that I noticed was a typo: schedulre that can cause malfunction. I am
not sure what version you are using, but recently the extra_spec checking is
moved to compute_capabilities_filter.py (ComputeCapabilitiesFilter). As far as
I understand, the current ComputeFilter does not check extra_specs.
Thanks,
Joseph
(w) 703-248-6160
(c) 571-340-2434
(f) 703-812-3712
http://www.east.isi.edu/~jsuh
Information Sciences Institute
University of Southern California
3811 N. Fairfax Drive Suite 200
Arlington, VA, 22203, USA
- Original Message -
From: Boris-Michel Deschenes boris-michel.desche...@ubisoft.com
To: openstack@lists.launchpad.net
Sent: Thursday, August 9, 2012 11:10:15 AM
Subject: [Openstack] using extra specs
Hi guys,
I currently have a working cloud with a working GPU passthrough setup
(CentOS/libvirt/Xen 4.1.2), now I need to work on adding this new resource to
openstack.
Here is the plan:
1. Create a new instance type (g1.small) with an extra spec like “xpu_arch =
radeon”
2. Modify the compute side so that nova-compute publishes this new capability
I’m in between step 1 and step 2, so normally, when I try and launch a VM with
the new instance type, the scheduling should fail since there is no compute
node publishing this capability yet, but the scheduling does go through despite
having the ComputeFilter available.
My understanding is that by having:
scheduler_available_filters=nova.schedulre.filters.standard_filters
scheduler_default_filters=ComputeFilter
The ComputeFilter should try and ensure that the hosts satisfies the extra
specs but the filter is not doing its job since the VM is scheduler and casted
to the compute node although it does not advertise any of the extra spec.
The extra spec is definitely part of the instance_type, I can see it in the
scheduler log:
(TRUNCATED) u'8895af5063b176bef97ab81f076d57f3', u'min_disk': u'0',
u'is_public': True, u'deleted_at': None, u'properties': {u'os_type':
u'windows'}, u'size': 9256562688}, u'instance_type': {u'root_gb': 0,
u'deleted_at': None, u'name': u'g1.small', u'deleted': False, u'created_at':
u'2012-08-08 18:33:29', u'ephemeral_gb': 0, u'updated_at': None, u'memory_mb':
2048, u'vcpus': 1, u'extra_specs': {u'xpu_arch': u'radeon'}, u'swap': 0,
u'rxtx_factor': 1.0, u'flavorid': u'105', u'vcpu_weight': None, u'id': 6},
u'instance_properties': {u'vm_state': u'building', u'availability_zone':
(TRUNCATED)
So again, this VM should not be casted to any compute node and the scheduler
should complain about no host having the required capability but it does not…
the VM is instantiated on the one compute node even though it never published
the required capability.
It looks like the ComputeFilter is either not used properly or I’m missing
something. Basically I want the scheduler to fail when I launch the VM before I
start working on step 2.
Any help appreciated.
Boris
___
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] Making the RPC backend a required configuration parameter
CC'ing openstack-dev since that is a more appropriate list for this discussion. On 08/08/2012 04:35 PM, Eric Windisch wrote: I believe that the RPC backend should no longer have any default. I disagree and my reason is fairly straight-forward. Changing the default will break existing configurations. The benefits must outweight that. I don't see enough benefit to outweigh any inconvenience to users. Historically, it seems that the Kombu driver is default only because it existed before all others and before there was an abstraction. With multiple implementations now available, it may be time for a change. Why? * A default skews the attitudes and subsequent architectures toward a specific implementation * A default skews the practical testing scenarios, ensuring maturity of one driver over others. I don't think these are true. * The kombu driver does not work out of the box, so it is no more reasonable as a default than impl_fake. My issue is that existing configuration files and configuration examples are broken by this change. I also don't understand why having a default that doesn't work for anyone makes any sense. * The RPC code is now in openstack-common, so addressing this later will only create additional technical debt. I don't feel that it's something that ever *needs* to be addressed, so it's not technical debt. -- Russell Bryant ___ 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] [Quantum] Removing quantum-rootwrap
On Aug 9, 2012, at 8:13 AM, Robert Kukura rkuk...@redhat.com wrote: We should immediately change devstack to stop running the quantum agents as root, so at least the root_helper=sudo functionality is really being used. It looks like devstack does configure nova with the new rootwrap/rootwrap_config and does not run any of its services as root. Doing the same for quantum would seem get some mileage on it. +1 Getting quantum into the devstack-gate would also make sure that we don't break it in the future. ___ 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] Why Image upload functionality is not there in Horizon ?
Indeed, uploading large files with the Horizon webserver as an intermediate relay is a nasty business which we want to discourage. We are looking at ways to send files directly from the Horizon client-side UI to swift/glance for large file upload in the future. All the best, - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Jay Pipes Sent: Thursday, August 09, 2012 10:43 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Why Image upload functionality is not there in Horizon ? On 08/09/2012 02:35 AM, Sajith Kariyawasam wrote: Hi all, After playing around with Openstack Mangement Console, Horizon, I realize that the image upload functionality is not provided there. Is there any special reason for that? Is it because there are no Rest services available at the moment? or else is it felt that providing image upload via the UI is not practically important? Probably because sending 20G Windows image files through a web form interface isn't very efficient ;) It's also not something a regular user of Glance/Nova would do -- and system administrators won't do it very often, and when they do, they'll use the glance CLI tool to do it. Best, -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 ___ 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] devstack + exercise.sh failures
Hi! I'm working on some code for scheduler_hints to be used during migration and was running devstack/exercise.sh on the latest greatest git. Without any of my changes installed I see on a 12.04 install the following failures: = SKIP quantum SKIP swift PASS aggregates PASS bundle PASS client-args PASS client-env PASS sec_groups FAILED boot_from_volume FAILED euca FAILED floating_ips FAILED volumes = I'm new so certainly possible I've missed an email/bug that documents this. I did also try on f17 but the results were exactly the same. Not that it should matter but I have devstack running inside of a kvm partition. Nothing obvious seems amiss. localrc has nothing in it but the settings for MYSQL_PASSWORD, RABBIT_PASSWORD, SERVICE_TOKEN, SERVICE_PASSWORD, ADMIN_PASSWORD Known problem or ? Regards, Tom ___ 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] LBaaS IRC meeting notes
This time I was the sole participant and here's what I had to say :) Our current progress is as follows: The team has almost finished the core code and is about to start working on the F5 driver. Most of the external API is implemented, and it's planned to polish the driver/core interaction logic while working on F5 Also, filtering of LB's by their capabilities is almost ready in a separate branch, will be merged to master in the nearest few days We've been also talking with a few LB vendors and they seem very excited. The dominating topic is Quantum integration, on which we'll have more news in the next days. On Thu, Aug 9, 2012 at 9:48 AM, Eugene Kirpichov ekirpic...@gmail.com wrote: REMINDER: Another meeting will take place today, in ~2 hours from now (19:00 UTC), on #openstack-meeting (use http://webchat.freenode.net/ to join). On Mon, Aug 6, 2012 at 3:09 PM, Eugene Kirpichov ekirpic...@gmail.com wrote: Hi, Below are the meeting notes from the IRC meeting about LBaaS which took place on Aug 2. The logs can be found at http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-02-17.00.log.html [19:18:27 .. 19:56:41] === Status on our side === https://github.com/Mirantis/openstack-lbaas * HAproxy and ACE implemented to some level. * F5 to be finished in 6 weeks. By that time driver API will be stable. * Support for device capabilities (drivers report them, users request them) on its way to master. === Discussion with Dan Went of Quantum === Dan said: * Quantum is moving up the stack: L2 in essex, L3 in folsom, and in Grizzly we'll be moving into L4-L7 * Many people in Quantum are generally interested in LBaaS * We need to make sure we're not duplicating effort by developing our own CLI/GUI for LBaaS. We should at least integrate with the Quantum CLI framework and generally collaborate with the Quantum community (circulate blueprints and POC). The next meeting will take place Aug 9, 19:00 UTC at #openstack-meeting. -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov ___ 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] [openstack-dev] Making the RPC backend a required configuration parameter
On 08/09/2012 02:39 PM, Eric Windisch wrote: I also don't understand why having a default that doesn't work for anyone makes any sense. I would hope that a localhost only installation with a username and password of 'guest' include a very small number of anyones. Who is really using a completely stock, default configuration successfully, and do they really care? Everyone else is using configuration management of sorts, at which point this discussion is moot. Even devstack changes this configuration. If someone really is installing Nova from scratch and using a default configuration… Does setuptools also install RabbitMQ for you? No? Right, you need to read documentation and recognize that RabbitMQ needs to be installed. Sure, once it is installed, no configuration is required; Unless you're /actually/ going to use it, of course. From everything I've seen, the general recommendation on the mailing list for those installing Nova on a single node is to use devstack. In that case, the configuration is prompt-driven, and whatever changes need to be made, can be made. I'm not talking about all configuration options. I'm talking about this single configuration option. Existing installations that did not specify rpc_backend because they did not need to will break if the default is changed. -- Russell Bryant ___ 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] [openstack-dev] Making the RPC backend a required configuration parameter
I'm not talking about all configuration options. I'm talking about this single configuration option. Existing installations that did not specify rpc_backend because they did not need to will break if the default is changed. They would only break in Grizzly, following a one-release depreciation schedule. During Folsom, if they run Folsom, they'll only get warnings. When it becomes required, if they haven't yet updated their configuration, and if they don't see it clearly stated in release-notes, they'll discover the change quickly within their testing. If they ignore the warnings in Folsom, don't notice the release-notes, and don't do any testing before deploying; If they don't test Grizzly, deploy into production, and run into this… well, I hope they're a small deployment, in which case it won't be a very big thorn. If they're a large deployment and they ignore all of this, including ignoring any need for testing before doing a large rollout… Regards, Eric Windisch ___ 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] Trouble getting instances back up after hard server reboot
Hi all, I am having a terrible time getting my instances to work after a hard reboot. I am using the most up-to date version of all openstack packages provided by Ubuntu. I have included a list of packages, with version, at the end of this email. After a hard reboot nova list reports that the instance is active, but there are no kvm processes running. grepping the log file for errors I find this in nova-compute.log: 2012-08-09 14:32:51 INFO nova.rpc.common [req-dd6fcade-73ec-4378-9a6b-7bc709eefcd4 None None] Connected to AMQP server on cloudy-priv:5672 2012-08-09 14:33:51 ERROR nova.rpc.common [req-dd6fcade-73ec-4378-9a6b-7bc709eefcd4 None None] Timed out waiting for RPC response: timed out 2012-08-09 14:33:51 TRACE nova.rpc.common Traceback (most recent call last): 2012-08-09 14:33:51 TRACE nova.rpc.common File /usr/lib/python2.7/dist-packages/nova/rpc/impl_kombu.py, line 490, in ensure 2012-08-09 14:33:51 TRACE nova.rpc.common return method(*args, **kwargs) 2012-08-09 14:33:51 TRACE nova.rpc.common File /usr/lib/python2.7/dist-packages/nova/rpc/impl_kombu.py, line 567, in _consume 2012-08-09 14:33:51 TRACE nova.rpc.common return self.connection.drain_events(timeout=timeout) 2012-08-09 14:33:51 TRACE nova.rpc.common File /usr/lib/python2.7/dist-packages/kombu/connection.py, line 175, in drain_events 2012-08-09 14:33:51 TRACE nova.rpc.common return self.transport.drain_events(self.connection, **kwargs) 2012-08-09 14:33:51 TRACE nova.rpc.common File /usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py, line 238, in drain_events 2012-08-09 14:33:51 TRACE nova.rpc.common return connection.drain_events(**kwargs) 2012-08-09 14:33:51 TRACE nova.rpc.common File /usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py, line 57, in drain_events 2012-08-09 14:33:51 TRACE nova.rpc.common return self.wait_multi(self.channels.values(), timeout=timeout) 2012-08-09 14:33:51 TRACE nova.rpc.common File /usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py, line 63, in wait_multi 2012-08-09 14:33:51 TRACE nova.rpc.common chanmap.keys(), allowed_methods, timeout=timeout) 2012-08-09 14:33:51 TRACE nova.rpc.common File /usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py, line 120, in _wait_multiple 2012-08-09 14:33:51 TRACE nova.rpc.common channel, method_sig, args, content = read_timeout(timeout) 2012-08-09 14:33:51 TRACE nova.rpc.common File /usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py, line 94, in read_timeout 2012-08-09 14:33:51 TRACE nova.rpc.common return self.method_reader.read_method() 2012-08-09 14:33:51 TRACE nova.rpc.common File /usr/lib/python2.7/dist-packages/amqplib/client_0_8/method_framing.py, line 221, in read_method 2012-08-09 14:33:51 TRACE nova.rpc.common raise m 2012-08-09 14:33:51 TRACE nova.rpc.common timeout: timed out 2012-08-09 14:33:51 TRACE nova.rpc.common 2012-08-09 14:33:51 CRITICAL nova [-] Timeout while waiting on RPC response. restarting nova-compute brings the instance up, so it looks like nova-compute is starting before rabbitmq? Is there a clean way around this, or should I put service nova-compute restart in rc.local? If I have a volume attached things get much worse. I can still start the instance by restarting nova-compute, but the volume does not attach. I can not seem to detach the volume in order to attach it again. Below is the only error in the log file, and how I mount the image that contains the nova-volume logical group.The error occurs because it tries to start nova-volume before the loopback device is setup. The command in rc.local restarts the service, making the logical group available. From nova-volume.log 2012-08-09 14:32:40 CRITICAL nova [-] volume group nova-volumes doesn't exist From rc.local losetup -f /var/lib/nova/nova-volumes.img service nova-volume restart Any idea how I should solve these problems? I could disable upstart from bringing the services up automatically and start them in the correct order in rc.local, but I don't think this would solve the volume attachment issue. I am so frustrated that I created this script for testing which completely resets the nova database table, iptables, and recreates everything. http://paste2.org/p/2100211 I know it is a dirty dirty hack, but I can't seem to figure out what is going on. Thanks in advance for the help. Sam root@cloudy:/var/log/nova# dpkg -l | grep -E (nova|glance|keystone|tgt|rabbit|ntp|mysql|libvirt|kvm) ii glance 2012.1+stable~20120608-5462295-0ubuntu2.2 OpenStack Image Registry and Delivery Service - Daemons ii glance-api 2012.1+stable~20120608-5462295-0ubuntu2.2 OpenStack Image Registry and Delivery Service - API ii glance-client 2012.1+stable~20120608-5462295-0ubuntu2.2 OpenStack Image Registry and Delivery Service - Registry ii glance-common 2012.1+stable~20120608-5462295-0ubuntu2.2 OpenStack Image Registry and Delivery Service - Common ii glance-registry
Re: [Openstack] devstack + exercise.sh failures
On Thu, Aug 9, 2012 at 1:57 PM, Joe Gordon j...@cloudscaling.com wrote: Did you turn off rate limiting in devstack? I have hit that in the past On Aug 9, 2012 12:36 PM, Thomas Gall thomasag...@gmail.com wrote: Hi! I'm working on some code for scheduler_hints to be used during migration and was running devstack/exercise.sh on the latest greatest git. Without any of my changes installed I see on a 12.04 install the following failures: = SKIP quantum SKIP swift PASS aggregates PASS bundle PASS client-args PASS client-env PASS sec_groups FAILED boot_from_volume FAILED euca FAILED floating_ips FAILED volumes = I'm new so certainly possible I've missed an email/bug that documents this. I did also try on f17 but the results were exactly the same. Not that it should matter but I have devstack running inside of a kvm partition. Nothing obvious seems amiss. localrc has nothing in it but the settings for MYSQL_PASSWORD, RABBIT_PASSWORD, SERVICE_TOKEN, SERVICE_PASSWORD, ADMIN_PASSWORD Known problem or ? Regards, Tom ___ 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 Sadly the boot from volume tests haven't worked for a while, and I suspect the following failures you're seeing are aftermath. ___ 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] devstack + exercise.sh failures
On Thu, Aug 9, 2012 at 2:33 PM, Thomas Gall thomasag...@gmail.com wrote: FAILED boot_from_volume FAILED euca FAILED floating_ips FAILED volumes These all spawn instances so there's the first thing to check... I'm new so certainly possible I've missed an email/bug that documents this. I did also try on f17 but the results were exactly the same. Not that it should matter but I have devstack running inside of a kvm partition. Nothing obvious seems amiss. Yes, running inside a VM does make a difference, mostly in the default timeouts. Also, how much ram does your devstack VM have? You'll need 1G minimum to run everything unless you have Swift enabled, then at least 1.5G. localrc has nothing in it but the settings for MYSQL_PASSWORD, RABBIT_PASSWORD, SERVICE_TOKEN, SERVICE_PASSWORD, ADMIN_PASSWORD I usually set the following timeouts running in a Rax VM (VirtualBox often needs a bit longer for me): # Timeouts ACTIVE_TIMEOUT=120 ASSOCIATE_TIMEOUT=60 BOOT_TIMEOUT=120 SERVICE_TIMEOUT=120 If you immediately do the following: . openrc nova list after the exercise failure, what to you see? If there is one running VM and maybe one or more in error state, you may be up agains the timeouts or possibly don't have enough RAM in your devstack vm. Try running just one exercise at a time to debug this, exercises/floating_ips.sh is what I usually use. Another trick I use to reduce the RAM required for the VMs is to create an m1.miro flavor and set in localrc: DEFAULT_INSTANCE_TYPE=m1.micro The exercises will honor that in selecting the VM to create when they run. The commands to do that are in samples/local.sh in the devstack directory. dt -- Dean Troyer dtro...@gmail.com ___ 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] [OpenStack][Nova] Question regarding multiple network interfaces
If your eth0 (public interface) can access Internet, with the ip_forward your instance should be able too... On Wed, Aug 8, 2012 at 12:05 PM, Leander Bessa Beernaert leande...@gmail.com wrote: So i have set up a small proof of concept, one controller node and two compute nodes. Since the switches do not support VLAN i'm using flat dhcp. Each machine has two network interfaces. Eth0 is connected to the public switch and eth1 to the private switch. The private switch has no access to the internet. Both compute nodes have the value of cat /proc/sys/net/ipv4/ip_forward set to 1. However, i still can't make an instance connect to the outside. Any thoughts? On Tue, Aug 7, 2012 at 11:32 PM, Sébastien Han han.sebast...@gmail.comwrote: It's part of the operating system # echo 1 /proc/sys/net/ipv4/ip_forward Then edit your /etc/sysctl.conf and uncomment net.ipv4.ip_forward=1 to make this persistent after reboot. Finally run -- # sysctl -p That's all, cheers! On Tue, Aug 7, 2012 at 11:50 PM, Leander Bessa Beernaert leande...@gmail.com wrote: Is there a flag in the nova.conf file or is this something that needs to be done on the operating system? On Tue, Aug 7, 2012 at 8:26 PM, Sébastien Han han.sebast...@gmail.com wrote: Hi, If eth0 is connected to the public switch and if eth1 is connected to the private switch you can enable the ipv4 forwarding on the compute node. Thanks to this the VMs will have access to the outside world and the packet will be routed from eth1 to eth0 :). Cheers! On Tue, Aug 7, 2012 at 5:18 PM, Leander Bessa Beernaert leande...@gmail.com wrote: Hello, I have a question regarding the use of two network interfaces. According to the official documentation, one of the interfaces is used for public access and the other for internal access (inter-vm communication). What i'd like to know is how does an instance connect to the outside world (internet access)? Is it done through the switch connected to the private interface or the public interface? -- Cumprimentos / Regards, Leander ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Cumprimentos / Regards, Leander -- Cumprimentos / Regards, Leander ___ 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] Team Meeting Summary
Hello Everyone, The nova meeting today was quite eventful. Minutes are included below. A couple of important updates: * we are putting nova-core review days on hold. * nova-core is going to pay extra attention to reviewing so that we can get everything merged by Tuesday * after F-3 nova-core will shift focus to bugs. Thanks, Vish Meeting summary --- * LINK: Agenda: http://wiki.openstack.org/Meetings/Nova (vishy, 21:01:31) * XML Support in Nova (vishy, 21:03:09) * LINK: http://etherpad.openstack.org/NovaAPIXMLSupport (vishy, 21:04:01) * ACTION: vishy to email the list about current state of xml and ask for bug reports and volunteers to fix it. (vishy, 21:11:04) * Blueprint / Review Updates (vishy, 21:13:04) * LINK: https://blueprints.launchpad.net/nova/+spec/general-host-aggregates (markmc, 21:13:42) * LINK: https://review.openstack.org/#/c/10934/ (russellb, 21:15:36) * LINK: https://review.openstack.org/#/c/10256/ (russellb, 21:17:08) * LINK: https://blueprints.launchpad.net/nova/+spec/general-host-aggregates (markmc, 21:17:26) * we are probably fine pushing this one to grizzly: https://review.openstack.org/#/c/10826/ (vishy, 21:17:59) * LINK: https://review.openstack.org/#/c/11009/ (vishy, 21:19:22) * LINK: https://blueprints.launchpad.net/nova/+spec/integrate-python-glanceclient (markmc, 21:20:15) * LINK: https://blueprints.launchpad.net/nova/+spec/task-management (vishy, 21:22:12) * LINK: https://review.openstack.org/#/q/topic:bp/disable-server-extensions,n,z (vishy, 21:23:05) * ACTION: dansmith to repropose is revert_state decorator (vishy, 21:24:49) * ACTION: nova-core to help review bare-metal patches (vishy, 21:32:58) * LINK: https://blueprints.launchpad.net/nova/+spec/general-bare-metal-provisioning-framework (markmc, 21:33:21) * LINK: https://review.openstack.org/10903 (vishy, 21:33:37) * LINK: https://review.openstack.org/#/c/10707/ (vishy, 21:34:14) * LINK: : https://launchpad.net/nova/+milestone/folsom-3 (vishy, 21:36:27) * Core Work Planning (vishy, 21:42:22) * LINK: http://173.203.107.207/~soren/stats/nova-30days.json (vishy, 21:43:36) * ACTION: nova-core to do lots of reviews by Tuesday (vishy, 21:51:08) * ACTION: nova-core to switch to bug-fixing after F-3 (vishy, 21:51:46) * XML redux (vishy, 21:52:17) * ACTION: markmc start a ReviewerTips wiki page (markmc, 21:52:39) * LINK: : https://review.openstack.org/#/c/10535/ (sdague, 22:03:01) * LINK: http://lists.openstack.org/pipermail/openstack-dev/2012-August/000445.html (markmc, 22:03:39) * ACTION: vishy to review power_vm driver (vishy, 22:07:29) * LINK: : https://review.openstack.org/#/c/9666/ (sdague, 22:07:44) Meeting ended at 22:09:54 UTC. ___ 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] Call for Help -- OpenStack API XML Support
Hello Everyone, We are in the unfortunate position of not knowing how good our OpenStack API XML support is. All of our integration tests use json. Many of the compute extensions don't even have XML deserializers. We also assume that there bugs we don't even know about due to underuse. We need to do something about XML by Folsom, because releasing a buggy api isn't good for anyone. We don't want to alienate the communtity by dropping XML support, but we also can't recommend it in its current state. If there are people out there who use XML (or want to use XML) we need your help. We need help identifying what works and what doesn't, we need bug reports, and we need merge proposals for the extra serializers and fixes that are important. Nova-core has too much going on right now to tackle XML. I see a few potential results from this effort. 1) We get a lot of community support and we manage to get XML into usable shape by Folsom. 2) We get enough community support to get the core api working and the most important extensions in place. We release clear documentation on what is expected to work. 3) We get no support, in which case we mark XML support deprecated and encourage people to use JSON only. Note that other openstack projects only support json, and there are already java bindings that use json so option 3) isn't terrible, but we don't want to go that route without discussing it with the community first. If anyone has alternative solutions or suggestions, feel free to let me know. Thanks, Vish ___ 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] Can't update the metadata via nova cli
On Aug 9, 2012, at 1:56 PM, Sébastien Han han.sebast...@gmail.com wrote: Did I miss something? Unfortunately this is confusing because the term metadata is used for two different things. the metadata visible to the instance is a replication of the aws metadata server. it is constructed from the database (mostly the instances table) The metadata you were setting with your command are sets of keys and values that are visible in the compute api: http://docs.openstack.org/trunk/openstack-compute/developer/openstack-compute-api-1.1/content/MetadataSection.html which is stored in the instance_metadata table Last question, is there a way to update the metadata of a running instance. I mean instead of updating the db record... For example re-injecting a SSH key? no, there is currently no way of doing this through the api. Vish___ 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] DHCP and kernel 3.2
On 08/09/2012 12:13 AM, Alessandro Tagliapietra wrote: Hello guys, i've just installed kernel 3.4 from Ubuntu kernel PPA archive and after this upgrade VM aren't able to get the DHCP address but with tcpdump i see the request and offer on the network. Someone else experienced this? I've tried also with 3.3, same story. Rolling back to 3.2 and everything works fine. I've tried with both flatdhcp and vlan mode. Best Alessandro Hey Alessandro- I'm able to confirm this affects the quantal kernel (on both quantal and precise) and vanilla kernels since 3.2.26 (at least those available from http://kernel.ubuntu.com/~kernel-ppa/mainline/) I began looking at this issue a while back and doing some packet dumping, but I seem to have misplaced those .pcaps. IIRC, what I saw happening was the instances' DHCP DICOVERY makes it to the server, dnsmasq properly sends an OFFER, but the the instance never returns with the REQUEST. I feel like, at one point, I was seeing an external DHCP server (on the public network) responding to the DISCOVERYs with OFFERs of addresses from the wrong network, and the instance actually REQUEST'ing and getting an IP from the wrong server. I will open a bug about this in Launchpad against the kernel and see if we can get some help bisecting and figuring out what broke. Adam ___ 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] [openstack-dev] [nova] Call for Help -- OpenStack API XML Support
On Aug 9, 2012, at 3:32 PM, George Reese george.re...@imaginary.com wrote: Why aren't the integration tests both XML and JSON? The simple answer is that no one has taken the time to write them. Our devstack exercises use the python client bindings. Tempest has json clients but no xml clients[1]. I think this demonstrates that there just isn't a huge desire for xml. Users that I have chatted with just seem to care that the api works and that they they have good bindings. I am definitely willing to be proven wrong on this point, but I'm secretly hoping everyone agrees with me. It is a lot of work to maintain three APIs (we are still maintaining EC2 as well) and keep them all functioning well, so if people are happy without OpenStack XML I would be perfectly content to deprecate it. Vish [1] https://github.com/openstack/tempest/tree/master/tempest/services/nova/xml ___ 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] DHCP and kernel 3.2
On 08/09/2012 12:13 AM, Alessandro Tagliapietra wrote: Hello guys, i've just installed kernel 3.4 from Ubuntu kernel PPA archive and after this upgrade VM aren't able to get the DHCP address but with tcpdump i see the request and offer on the network. Someone else experienced this? I've tried also with 3.3, same story. Rolling back to 3.2 and everything works fine. I've tried with both flatdhcp and vlan mode. Best Alessandro ___ Also, when testing FlatDHCPManager are you using multi_host mode, or is DHCP being served from a central nova-network node? What ethernet driver are you using? Thanks, Adam ___ 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] Essex multi-node setup/ can't ssh to compute node
right. hope the document can help you . it is chinese. the network is flatdchp + mutilhost http://www.chenshake.com/ubuntu-12-04-openstack-essex-multinode-installation/ On Thu, Aug 9, 2012 at 10:51 PM, Kiall Mac Innes ki...@managedit.ie wrote: Also the metadata host should be set to 127.0.0.1 for multihost=True.. Thanks, Kiall On Aug 9, 2012 2:58 PM, 谢丹铭 xiedanm...@qiyi.com wrote: Hi, list, I'm setting up openstack on Ubuntu 12.04 LTS with FlatDHCP mode network configuration. . Everything is OK in control node, but in compute node, I always meet with the following issue. So I can’t ssh to the vm instance. 2012-08-09 13:31:28,290 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [50/120s]: url error [timed out] 2012-08-09 13:32:19,342 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [101/120s]: url error [timed out] 2012-08-09 13:32:37,361 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [119/120s]: url error [timed out] 2012-08-09 13:32:38,363 - DataSourceEc2.py[CRITICAL]: giving up on md after 120 seconds This is my nova.conf [DEFAULT] ## LOGS/STATE #verbose=True verbose=False ## AUTHENTICATION auth_strategy=keystone ## SCHEDULER #--compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler scheduler_driver=nova.scheduler.simple.SimpleScheduler ## VOLUMES volume_group=nova-volumes volume_name_template=volume-%08x iscsi_helper=tgtadm ## DATABASE sql_connection=mysql://nova:pwd@10.10.135.30/nova ## COMPUTE libvirt_type=kvm #libvirt_type=qemu connection_type=libvirt instance_name_template=instance-%08x api_paste_config=/etc/nova/api-paste.ini allow_resize_to_same_host=True libvirt_use_virtio_for_bridges=true start_guests_on_host_boot=true resume_guests_state_on_host_boot=true ## APIS osapi_compute_extension=nova.api.openstack.compute.contrib.standard_extensio ns allow_admin_api=true s3_host=10.10.135.30 cc_host=10.10.135.30 ## RABBITMQ rabbit_host=10.10.135.30 ## GLANCE image_service=nova.image.glance.GlanceImageService glance_api_servers=10.10.135.30:9292 ## NETWORK network_manager=nova.network.manager.FlatDHCPManager force_dhcp_release=True dhcpbridge_flagfile=/etc/nova/nova.conf dhcpbridge=/usr/bin/nova-dhcpbridge firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver public_interface=eth0 flat_interface=eth1 flat_network_bridge=br100 fixed_range=192.168.1.0/24 multi_host=true ## NOVNC CONSOLE novnc_enabled=true novncproxy_base_url= http://10.10.135.30:6080/vnc_auto.html vncserver_proxyclient_address=10.10.135.29 vncserver_listen=10.10.135.29 Nova logdir=/var/log/nova state_path=/var/lib/nova lock_path=/var/lock/nova metadata_host=10.10.135.29 #MISC use_deprecated_auth=false root_helper=sudo nova-rootwrap Thanks Danming ___ 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 -- Shake Chen ___ 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] [openstack-dev] [nova] Call for Help -- OpenStack API XML Support
Has anyone surveyed those subscribed to openstack-operators@lists.openstack.org list for usage? While imperfect, at least it would be asking the constituency that might be most affected. You might also consider asking whether they would prefer JSON or XML, regardless of what they use today.I agree with George that weighing developer interest in writing some test cases is likely not the best measure of how widely the XML API is used in practice.One last slightly unrelated point. There was discussion and a PPB decision not to maintain 3rd party APIs in core. Why does the EC2 API remain? Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -To: OpenStack Development Mailing Listopenstack-...@lists.openstack.orgFrom: Vishvananda Ishaya Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.netDate: 08/09/2012 07:05PMCc: "openstack@lists.launchpad.net \(openstack@lists.launchpad.net\)"openstack@lists.launchpad.netSubject: Re: [Openstack] [openstack-dev] [nova] Call for Help --OpenStack API XML SupportOn Aug 9, 2012, at 3:32 PM, George Reese george.re...@imaginary.comwrote:Why aren't the integration tests both XML and JSON?The simple answer is that no one has taken the time to write them.Our devstack exercises use the python client bindings. Tempest hasjson clients but no xml clients[1]. I think this demonstrates thatthere just isn't a huge desire for xml. Users that I have chattedwith just seem to care that the api works and that they they havegood bindings.I am definitely willing to be proven wrong on this point, but I'msecretly hoping everyone agrees with me. It is a lot of work tomaintain three APIs (we are still maintaining EC2 as well) and keepthem all functioning well, so if people are happy without OpenStackXML I would be perfectly content to deprecate it.Vish[1]https://github.com/openstack/tempest/tree/master/tempest/services/nova/xml ___ 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] [openstack-dev] [nova] Call for Help -- OpenStack API XML Support
Situations like this are always interesting to watch. :-) On the one hand its open-source, so if you care about something then put up the resources to make it happen. On the other hand, that doesn't mean that as a developer you get to ignore the bigger picture and only do 1/2 of the work because you don't care about the other 1/2. Overall, I tend to agree with the attitude that as long as XML is officially supported then all code changes need to make sure they run through both the JSON and XML codepaths. And if this means twice the testcases then so be it. People committing code shouldn't have a choice in this - its either you do the full job or your code is rejected. Having said that, it is a valid question to ask whether we want to continue to support both JSON and XML going forward. But, until that decision is formally made letting 1/2 of the APIs atrophy makes the entire community look bad and therefore should not be allowed to happen. My vote: from now on don't let any code change in unless if works for both. I suspect we'll either see the XML side come up to speed really quickly or it'll force an ugly vote. But either way, this needs to be resolved before the next release. thanks -Doug STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.com The more I'm around some people, the more I like my dog. George Reese george.re...@imaginary.com 08/09/2012 07:02 PM Please respond to OpenStack Development Mailing List openstack-...@lists.openstack.org To OpenStack Development Mailing List openstack-...@lists.openstack.org cc openstack@lists.launchpad.net \(openstack@lists.launchpad.net\) openstack@lists.launchpad.net Subject Re: [openstack-dev] [nova] Call for Help -- OpenStack API XML Support And this is why I go off on the developer-oriented mentality of the OpenStack community. The fact that there is no one in the OpenStack developer community writing XML stuff is not a reflection of the fact that there's no huge desire for XML. It's in the spec for a reason: BECAUSE ENTERPRISES USE XML HEAVILY OpenStack developers aren't that audience. They use JSON. That the project can get to this point and not have tests for these things shows a flaw in the development processes, not some grand illustration of supply and demand. Do I really have to point out that if the spec calls for JSON and XML, you should bloody well write integration tests to check for JSON and XML? You don't write whatever happens to please you. You know how I know all of this? I have an API that supports both XML and JSON. I personally prefer JSON. Most of my friends and colleagues prefer and use JSON. Most of my customers use XML. Thank $deity I actually write unit tests for each format. -George File under: - statistics 101 - software development 101 On Aug 9, 2012, at 5:52 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: On Aug 9, 2012, at 3:32 PM, George Reese george.re...@imaginary.com wrote: Why aren't the integration tests both XML and JSON? The simple answer is that no one has taken the time to write them. Our devstack exercises use the python client bindings. Tempest has json clients but no xml clients[1]. I think this demonstrates that there just isn't a huge desire for xml. Users that I have chatted with just seem to care that the api works and that they they have good bindings. I am definitely willing to be proven wrong on this point, but I'm secretly hoping everyone agrees with me. It is a lot of work to maintain three APIs (we are still maintaining EC2 as well) and keep them all functioning well, so if people are happy without OpenStack XML I would be perfectly content to deprecate it. Vish [1] https://github.com/openstack/tempest/tree/master/tempest/services/nova/xml ___ OpenStack-dev mailing list openstack-...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- George Reese (george.re...@imaginary.com) t: @GeorgeReese m: +1(207)956-0217 Skype: nspollution cal: http://tungle.me/GeorgeReese ___ OpenStack-dev mailing list openstack-...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ 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] [openstack-dev] [nova] Call for Help -- OpenStack API XML Support
As part of my work on Tempest, I've created an alternate backend configuration to use XML requests/responses. This right now mostly covers Nova, but could easily be extended to test other projects as well. I hadn't pushed it yet because it seemed to be low priority, but I'd be more than glad to accelerate and get this committed. Daryl On Aug 9, 2012, at 8:14 PM, Doug Davis d...@us.ibm.commailto:d...@us.ibm.com wrote: Situations like this are always interesting to watch. :-) On the one hand its open-source, so if you care about something then put up the resources to make it happen. On the other hand, that doesn't mean that as a developer you get to ignore the bigger picture and only do 1/2 of the work because you don't care about the other 1/2. Overall, I tend to agree with the attitude that as long as XML is officially supported then all code changes need to make sure they run through both the JSON and XML codepaths. And if this means twice the testcases then so be it. People committing code shouldn't have a choice in this - its either you do the full job or your code is rejected. Having said that, it is a valid question to ask whether we want to continue to support both JSON and XML going forward. But, until that decision is formally made letting 1/2 of the APIs atrophy makes the entire community look bad and therefore should not be allowed to happen. My vote: from now on don't let any code change in unless if works for both. I suspect we'll either see the XML side come up to speed really quickly or it'll force an ugly vote. But either way, this needs to be resolved before the next release. thanks -Doug STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.commailto:d...@us.ibm.com The more I'm around some people, the more I like my dog. George Reese george.re...@imaginary.commailto:george.re...@imaginary.com 08/09/2012 07:02 PM Please respond to OpenStack Development Mailing List openstack-...@lists.openstack.orgmailto:openstack-...@lists.openstack.org To OpenStack Development Mailing List openstack-...@lists.openstack.orgmailto:openstack-...@lists.openstack.org cc openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net \(openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net\) openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject Re: [openstack-dev] [nova] Call for Help -- OpenStack API XML Support And this is why I go off on the developer-oriented mentality of the OpenStack community. The fact that there is no one in the OpenStack developer community writing XML stuff is not a reflection of the fact that there's no huge desire for XML. It's in the spec for a reason: BECAUSE ENTERPRISES USE XML HEAVILY OpenStack developers aren't that audience. They use JSON. That the project can get to this point and not have tests for these things shows a flaw in the development processes, not some grand illustration of supply and demand. Do I really have to point out that if the spec calls for JSON and XML, you should bloody well write integration tests to check for JSON and XML? You don't write whatever happens to please you. You know how I know all of this? I have an API that supports both XML and JSON. I personally prefer JSON. Most of my friends and colleagues prefer and use JSON. Most of my customers use XML. Thank $deity I actually write unit tests for each format. -George File under: - statistics 101 - software development 101 On Aug 9, 2012, at 5:52 PM, Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com wrote: On Aug 9, 2012, at 3:32 PM, George Reese george.re...@imaginary.commailto:george.re...@imaginary.com wrote: Why aren't the integration tests both XML and JSON? The simple answer is that no one has taken the time to write them. Our devstack exercises use the python client bindings. Tempest has json clients but no xml clients[1]. I think this demonstrates that there just isn't a huge desire for xml. Users that I have chatted with just seem to care that the api works and that they they have good bindings. I am definitely willing to be proven wrong on this point, but I'm secretly hoping everyone agrees with me. It is a lot of work to maintain three APIs (we are still maintaining EC2 as well) and keep them all functioning well, so if people are happy without OpenStack XML I would be perfectly content to deprecate it. Vish [1] https://github.com/openstack/tempest/tree/master/tempest/services/nova/xml ___ OpenStack-dev mailing list openstack-...@lists.openstack.orgmailto:openstack-...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- George Reese (george.re...@imaginary.commailto:george.re...@imaginary.com) t: @GeorgeReese m:
[Openstack] metadata service problem
Hello, In my essex install on RHEL6, there is a problem with the metadata service. The metadata service works for instances running on the controller node, where the nova-api(metadata service) is running. But for the other worker nodes, the metadata service is intermittent, ie. the instances sometimes can get its metadata, sometime it fails with errors like: $ curl -v http://169.254.169.254:8775/ * About to connect() to 169.254.169.254 port 8775 (#0) * Trying 169.254.169.254... Connection timed out * couldn't connect to host * Closing connection #0 curl: (7) couldn't connect to host Any idea where should I start investigating this? Thanks, Xin ___ 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] metadata service problem
I would start to check out iptables and routes that are being setup (in vms and outside). If you are running a flat (no dhcp) network that usually makes it a lot harder also. On 8/9/12 7:31 PM, Xin Zhao xz...@bnl.gov wrote: Hello, In my essex install on RHEL6, there is a problem with the metadata service. The metadata service works for instances running on the controller node, where the nova-api(metadata service) is running. But for the other worker nodes, the metadata service is intermittent, ie. the instances sometimes can get its metadata, sometime it fails with errors like: $ curl -v http://169.254.169.254:8775/ * About to connect() to 169.254.169.254 port 8775 (#0) * Trying 169.254.169.254... Connection timed out * couldn't connect to host * Closing connection #0 curl: (7) couldn't connect to host Any idea where should I start investigating this? Thanks, Xin ___ 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] [openstack-dev] [nova] Call for Help -- OpenStack API XML Support
On Aug 9, 2012, at 8:14 PM, Doug Davis d...@us.ibm.com wrote: Situations like this are always interesting to watch. :-) On the one hand its open-source, so if you care about something then put up the resources to make it happen. This attitude always bothers me. This isn't some Open Source labor of love. It's a commercial collaboration in which many of the contributors have a significant economic interest. To be more blunt: if I'm writing code, it's for enStratus. On the other hand, that doesn't mean that as a developer you get to ignore the bigger picture and only do 1/2 of the work because you don't care about the other 1/2. Overall, I tend to agree with the attitude that as long as XML is officially supported then all code changes need to make sure they run through both the JSON and XML codepaths. And if this means twice the testcases then so be it. People committing code shouldn't have a choice in this - its either you do the full job or your code is rejected. +10 Having said that, it is a valid question to ask whether we want to continue to support both JSON and XML going forward. But, until that decision is formally made letting 1/2 of the APIs atrophy makes the entire community look bad and therefore should not be allowed to happen. Actually, it's not a valid question. That ship has sailed. XML is part of the spec, and we're talking about Folsom not Bexar. The API is the heart of the ecosystem. You never, ever deprecate code unless there's some strong compelling reason like a significant security flaw that can be addressed only through incompatibility. My vote: from now on don't let any code change in unless if works for both. I suspect we'll either see the XML side come up to speed really quickly or it'll force an ugly vote. But either way, this needs to be resolved before the next release. thanks -Doug STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.com The more I'm around some people, the more I like my dog. George Reese george.re...@imaginary.com 08/09/2012 07:02 PM Please respond to OpenStack Development Mailing List openstack-...@lists.openstack.org To OpenStack Development Mailing List openstack-...@lists.openstack.org cc openstack@lists.launchpad.net \(openstack@lists.launchpad.net\) openstack@lists.launchpad.net Subject Re: [openstack-dev] [nova] Call for Help -- OpenStack API XMLSupport And this is why I go off on the developer-oriented mentality of the OpenStack community. The fact that there is no one in the OpenStack developer community writing XML stuff is not a reflection of the fact that there's no huge desire for XML. It's in the spec for a reason: BECAUSE ENTERPRISES USE XML HEAVILY OpenStack developers aren't that audience. They use JSON. That the project can get to this point and not have tests for these things shows a flaw in the development processes, not some grand illustration of supply and demand. Do I really have to point out that if the spec calls for JSON and XML, you should bloody well write integration tests to check for JSON and XML? You don't write whatever happens to please you. You know how I know all of this? I have an API that supports both XML and JSON. I personally prefer JSON. Most of my friends and colleagues prefer and use JSON. Most of my customers use XML. Thank $deity I actually write unit tests for each format. -George File under: - statistics 101 - software development 101 On Aug 9, 2012, at 5:52 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: On Aug 9, 2012, at 3:32 PM, George Reese george.re...@imaginary.com wrote: Why aren't the integration tests both XML and JSON? The simple answer is that no one has taken the time to write them. Our devstack exercises use the python client bindings. Tempest has json clients but no xml clients[1]. I think this demonstrates that there just isn't a huge desire for xml. Users that I have chatted with just seem to care that the api works and that they they have good bindings. I am definitely willing to be proven wrong on this point, but I'm secretly hoping everyone agrees with me. It is a lot of work to maintain three APIs (we are still maintaining EC2 as well) and keep them all functioning well, so if people are happy without OpenStack XML I would be perfectly content to deprecate it. Vish [1] https://github.com/openstack/tempest/tree/master/tempest/services/nova/xml ___ OpenStack-dev mailing list openstack-...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- George Reese (george.re...@imaginary.com) t: @GeorgeReese m: +1(207)956-0217 Skype: nspollution
Re: [Openstack] [openstack-dev] [nova] Call for Help -- OpenStack API XML Support
On Aug 9, 2012, at 6:28 PM, Daryl Walleck daryl.wall...@rackspace.com wrote: As part of my work on Tempest, I've created an alternate backend configuration to use XML requests/responses. This right now mostly covers Nova, but could easily be extended to test other projects as well. I hadn't pushed it yet because it seemed to be low priority, but I'd be more than glad to accelerate and get this committed. Daryl That is awesome news Daryl! Yes, please get this up as soon as possible so others can help. There definitely seems to be enough interest to at least have a go at cleaning up XML support. It would be great to know where the gaps are. Vish ___ 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] metadata service problem
On Aug 9, 2012, at 7:31 PM, Xin Zhao xz...@bnl.gov wrote: Hello, In my essex install on RHEL6, there is a problem with the metadata service. The metadata service works for instances running on the controller node, where the nova-api(metadata service) is running. But for the other worker nodes, the metadata service is intermittent, ie. the instances sometimes can get its metadata, sometime it fails with errors like: $ curl -v http://169.254.169.254:8775/ * About to connect() to 169.254.169.254 port 8775 (#0) * Trying 169.254.169.254... Connection timed out * couldn't connect to host * Closing connection #0 curl: (7) couldn't connect to host Any idea where should I start investigating this? This looks strange, the instance should not be putting port 8775 in the request, it should be on port 80. Vish ___ 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] metadata service problem
On 08/10/2012 12:17 PM, Vishvananda Ishaya wrote: $ curl -v http://169.254.169.254:8775/ * About to connect() to 169.254.169.254 port 8775 (#0) * Trying 169.254.169.254... Connection timed out * couldn't connect to host * Closing connection #0 curl: (7) couldn't connect to host Any idea where should I start investigating this? This looks strange, the instance should not be putting port 8775 in the request, it should be on port 80. Generally iptables should be set up to translate 8775 to 80 on 169.254.169.254. -- simonsmicrophone.com ___ 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-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_nova_trunk #351
Title: quantal_folsom_nova_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/351/Project:quantal_folsom_nova_trunkDate of build:Thu, 09 Aug 2012 02:01:54 -0400Build duration:3 min 34 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesAdd a 50 char git title limit test to hacking.by jogoedittools/hacking.pyeditHACKING.rstConsole Output[...truncated 5122 lines...]* Automated Ubuntu testing build:* [c5a9c75] Ensure that the dom0 we're connected to is the right one* [2dcd825] Pass context to notification drivers when we can.* [b841b6a] Fix innodb tests again* [d14ac4b] Adding 'host' info to volume-compute connection information.* [ac21815] Allow blank adminPass on server create* [03a331c] Log instance consistently.* [2511f01] Use additional task states during resize* Automated Ubuntu testing build:* [29dc47b] Use save_and_reraise_exception() from common.* [b841b6a] Fix innodb tests again* [ca2bb06] Remove unused images* [d14ac4b] Adding 'host' info to volume-compute connection information.* [524bfb8] Update common.importutils from openstack-common.' --fixes 'lp:1002111'Can't exec "bzr": Argument list too long at /usr/bin/debcommit line 484, line 9954.debcommit: commit failedERROR:root:Error occurred during package creation/build: Command '['debcommit']' returned non-zero exit status 7ERROR:root:Command '['debcommit']' returned non-zero exit status 7INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/nova/quantal-folsom-proposed /tmp/tmpgtHxLc/novamk-build-deps -i -r -t apt-get -y /tmp/tmpgtHxLc/nova/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0e6fc4f4ddca1ea76f9f03ef03d960cad888c810..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/nova/quantal-folsom --forcedch -b -D quantal --newversion 2012.2+git201208090203~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2012.2+git201208090203~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Failure: precise_folsom_nova_trunk #361
Title: precise_folsom_nova_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_nova_trunk/361/Project:precise_folsom_nova_trunkDate of build:Thu, 09 Aug 2012 12:02:08 -0400Build duration:49 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80ChangesNo ChangesConsole Output[...truncated 4 lines...]Last Built Revision: Revision 220ab5cfcbea8c500d45d3805c88f661730f7014 (origin/master)Checkout:nova / /var/lib/jenkins/slave/workspace/precise_folsom_nova_trunk/nova - hudson.remoting.LocalChannel@42eb0c97Wiping out workspace first.Cloning the remote Git repositoryCloning repository originFetching upstream changes from https://github.com/openstack/nova.gitERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway.hudson.plugins.git.GitException: Error performing command: git fetch -t https://github.com/openstack/nova.git +refs/heads/*:refs/remotes/origin/*Command "git fetch -t https://github.com/openstack/nova.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: error: The requested URL returned error: 403 while accessing https://github.com/openstack/nova.git/info/refsfatal: HTTP request failed at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:776) at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:741) at hudson.plugins.git.GitAPI.fetch(GitAPI.java:190) at hudson.plugins.git.GitAPI.fetch(GitAPI.java:978) at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1093) at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1014) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1994) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Thread.java:679)Caused by: hudson.plugins.git.GitException: Command "git fetch -t https://github.com/openstack/nova.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: error: The requested URL returned error: 403 while accessing https://github.com/openstack/nova.git/info/refsfatal: HTTP request failed at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:771) ... 16 moreERROR: Could not fetch from any repositoryFATAL: Could not fetch from any repositoryhudson.plugins.git.GitException: Could not fetch from any repository at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1105) at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1014) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1994) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Thread.java:679)-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_nova_trunk #353
Title: quantal_folsom_nova_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/353/Project:quantal_folsom_nova_trunkDate of build:Thu, 09 Aug 2012 12:01:57 -0400Build duration:22 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesNo ChangesConsole Output[...truncated 12 lines...] at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1073) at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1014) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1994) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Thread.java:679)Caused by: hudson.plugins.git.GitException: Error performing command: git clone --progress -o origin https://github.com/openstack/nova.git /var/lib/jenkins/slave/workspace/quantal_folsom_nova_trunk/novaCommand "git clone --progress -o origin https://github.com/openstack/nova.git /var/lib/jenkins/slave/workspace/quantal_folsom_nova_trunk/nova" returned status code 128: Cloning into '/var/lib/jenkins/slave/workspace/quantal_folsom_nova_trunk/nova'...error: The requested URL returned error: 403 while accessing https://github.com/openstack/nova.git/info/refsfatal: HTTP request failed at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:776) at hudson.plugins.git.GitAPI.access$000(GitAPI.java:38) at hudson.plugins.git.GitAPI$1.invoke(GitAPI.java:241) at hudson.plugins.git.GitAPI$1.invoke(GitAPI.java:221) at hudson.FilePath.act(FilePath.java:758) at hudson.FilePath.act(FilePath.java:740) at hudson.plugins.git.GitAPI.clone(GitAPI.java:221) ... 13 moreCaused by: hudson.plugins.git.GitException: Command "git clone --progress -o origin https://github.com/openstack/nova.git /var/lib/jenkins/slave/workspace/quantal_folsom_nova_trunk/nova" returned status code 128: Cloning into '/var/lib/jenkins/slave/workspace/quantal_folsom_nova_trunk/nova'...error: The requested URL returned error: 403 while accessing https://github.com/openstack/nova.git/info/refsfatal: HTTP request failed at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:771) ... 19 moreTrying next repositoryERROR: Could not clone repositoryFATAL: Could not clonehudson.plugins.git.GitException: Could not clone at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1085) at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1014) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1994) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Thread.java:679)-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_nova_trunk #355
Title: quantal_folsom_nova_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/355/Project:quantal_folsom_nova_trunkDate of build:Thu, 09 Aug 2012 13:01:55 -0400Build duration:3 min 41 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesFix traceback when detaching volumes via EC2by chuck.shorteditnova/api/ec2/cloud.pyConsole Output[...truncated 5146 lines...]* Automated Ubuntu testing build:* [c5a9c75] Ensure that the dom0 we're connected to is the right one* [2dcd825] Pass context to notification drivers when we can.* [b841b6a] Fix innodb tests again* [d14ac4b] Adding 'host' info to volume-compute connection information.* [ac21815] Allow blank adminPass on server create* [03a331c] Log instance consistently.* [2511f01] Use additional task states during resize* Automated Ubuntu testing build:* [29dc47b] Use save_and_reraise_exception() from common.* [b841b6a] Fix innodb tests again* [ca2bb06] Remove unused images* [d14ac4b] Adding 'host' info to volume-compute connection information.* [524bfb8] Update common.importutils from openstack-common.' --fixes 'lp:1002111'Can't exec "bzr": Argument list too long at /usr/bin/debcommit line 484, line 9982.debcommit: commit failedERROR:root:Error occurred during package creation/build: Command '['debcommit']' returned non-zero exit status 7ERROR:root:Command '['debcommit']' returned non-zero exit status 7INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/nova/quantal-folsom-proposed /tmp/tmpYMCme9/novamk-build-deps -i -r -t apt-get -y /tmp/tmpYMCme9/nova/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0e6fc4f4ddca1ea76f9f03ef03d960cad888c810..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/nova/quantal-folsom --forcedch -b -D quantal --newversion 2012.2+git201208091303~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2012.2+git201208091303~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Failure: precise_folsom_deploy #226
Title: precise_folsom_deploy General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_deploy/226/Project:precise_folsom_deployDate of build:Thu, 09 Aug 2012 13:23:28 -0400Build duration:2 min 20 secBuild cause:Started by command lineBuilt on:masterHealth ReportWDescriptionScoreBuild stability: 2 out of the last 5 builds failed.60ChangesNo ChangesBuild Artifactslogs/syslog.tar.gzlogs/test-02.os.magners.qa.lexington-log.tar.gzlogs/test-03.os.magners.qa.lexington-log.tar.gzlogs/test-04.os.magners.qa.lexington-log.tar.gzlogs/test-06.os.magners.qa.lexington-log.tar.gzlogs/test-07.os.magners.qa.lexington-log.tar.gzlogs/test-08.os.magners.qa.lexington-log.tar.gzlogs/test-09.os.magners.qa.lexington-log.tar.gzlogs/test-10.os.magners.qa.lexington-log.tar.gzlogs/test-11.os.magners.qa.lexington-log.tar.gzConsole Output[...truncated 564 lines...]INFO:root:Setting up connection to test-03.os.magners.qa.lexingtonERROR:root:Could not setup SSH connection to test-03.os.magners.qa.lexingtonINFO:root:Setting up connection to test-07.os.magners.qa.lexingtonERROR:root:Could not setup SSH connection to test-07.os.magners.qa.lexingtonINFO:root:Setting up connection to test-09.os.magners.qa.lexingtonERROR:root:Could not setup SSH connection to test-09.os.magners.qa.lexingtonINFO:root:Setting up connection to test-11.os.magners.qa.lexingtonERROR:root:Could not setup SSH connection to test-11.os.magners.qa.lexingtonINFO:root:Archiving logs on test-07.os.magners.qa.lexingtonERROR:root:Coult not create tarball of logs on test-07.os.magners.qa.lexingtonINFO:root:Archiving logs on test-08.os.magners.qa.lexingtonERROR:root:Coult not create tarball of logs on test-08.os.magners.qa.lexingtonINFO:root:Archiving logs on test-09.os.magners.qa.lexingtonERROR:root:Coult not create tarball of logs on test-09.os.magners.qa.lexingtonINFO:root:Archiving logs on test-04.os.magners.qa.lexingtonINFO:paramiko.transport:Secsh channel 2 opened.INFO:root:Archiving logs on test-11.os.magners.qa.lexingtonERROR:root:Coult not create tarball of logs on test-11.os.magners.qa.lexingtonINFO:root:Archiving logs on test-03.os.magners.qa.lexingtonERROR:root:Coult not create tarball of logs on test-03.os.magners.qa.lexingtonINFO:root:Archiving logs on test-06.os.magners.qa.lexingtonINFO:paramiko.transport:Secsh channel 2 opened.INFO:root:Archiving logs on test-10.os.magners.qa.lexingtonINFO:paramiko.transport:Secsh channel 2 opened.INFO:root:Archiving logs on test-02.os.magners.qa.lexingtonINFO:paramiko.transport:Secsh channel 2 opened.INFO:root:Grabbing information from test-07.os.magners.qa.lexingtonERROR:root:Unable to get information from test-07.os.magners.qa.lexingtonINFO:root:Grabbing information from test-08.os.magners.qa.lexingtonERROR:root:Unable to get information from test-08.os.magners.qa.lexingtonINFO:root:Grabbing information from test-09.os.magners.qa.lexingtonERROR:root:Unable to get information from test-09.os.magners.qa.lexingtonINFO:root:Grabbing information from test-04.os.magners.qa.lexingtonINFO:root:Grabbing information from test-11.os.magners.qa.lexingtonERROR:root:Unable to get information from test-11.os.magners.qa.lexingtonINFO:root:Grabbing information from test-03.os.magners.qa.lexingtonERROR:root:Unable to get information from test-03.os.magners.qa.lexingtonINFO:root:Grabbing information from test-06.os.magners.qa.lexingtonINFO:root:Grabbing information from test-10.os.magners.qa.lexingtonINFO:root:Grabbing information from test-02.os.magners.qa.lexingtonTraceback (most recent call last): File "/var/lib/jenkins/tools/jenkins-scripts/collate-test-logs.py", line 91, in connections[host]["sftp"].close()KeyError: 'sftp'+ exit 1Build step 'Execute shell' marked build as failureArchiving artifactsEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: precise_folsom_deploy #227
Title: precise_folsom_deploy
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_deploy/227/Project:precise_folsom_deployDate of build:Thu, 09 Aug 2012 13:44:06 -0400Build duration:36 secBuild cause:Started by command lineBuilt on:masterHealth ReportWDescriptionScoreBuild stability: 2 out of the last 5 builds failed.60ChangesNo ChangesBuild Artifactslogs/syslog.tar.gzlogs/test-02.os.magners.qa.lexington-log.tar.gzlogs/test-03.os.magners.qa.lexington-log.tar.gzlogs/test-04.os.magners.qa.lexington-log.tar.gzlogs/test-06.os.magners.qa.lexington-log.tar.gzlogs/test-07.os.magners.qa.lexington-log.tar.gzlogs/test-08.os.magners.qa.lexington-log.tar.gzlogs/test-09.os.magners.qa.lexington-log.tar.gzlogs/test-10.os.magners.qa.lexington-log.tar.gzlogs/test-11.os.magners.qa.lexington-log.tar.gzConsole Output[...truncated 287 lines...]warning: kernel option length exceeds 255warning: kernel option length exceeds 255warning: kernel option length exceeds 255copying files for distro: precise-x86_64copying files for distro: precise-i386copying files for distro: quantal-x86_64copying files for distro: precise-i386-maas-ephemeralcopying files for distro: maverick-x86_64copying files for distro: lucid-x86_64copying files for distro: precise-x86_64-maas-ephemeralcopying files for distro: natty-i386copying files for distro: hardy-i386copying files for distro: hardy-x86_64trying hardlink /var/www/cobbler/ks_mirror/hardy-x86_64/initrd.gz -> /var/www/cobbler/images/hardy-x86_64/initrd.gztrying symlink /var/www/cobbler/ks_mirror/hardy-x86_64/initrd.gz -> /var/www/cobbler/images/hardy-x86_64/initrd.gzrunning: /usr/bin/sha1sum /var/www/cobbler/ks_mirror/hardy-x86_64/initrd.gzreceived on stdout: 914ef9fb9fb186b18d30df1f0cda8dbb424b1d83 /var/www/cobbler/ks_mirror/hardy-x86_64/initrd.gzreceived on stderr: trying to create cache file /var/www/cobbler/images/.link_cache/914ef9fb9fb186b18d30df1f0cda8dbb424b1d83copying: /var/www/cobbler/ks_mirror/hardy-x86_64/initrd.gz -> /var/www/cobbler/images/.link_cache/914ef9fb9fb186b18d30df1f0cda8dbb424b1d83trying cachelink /var/www/cobbler/ks_mirror/hardy-x86_64/initrd.gz -> /var/www/cobbler/images/.link_cache/914ef9fb9fb186b18d30df1f0cda8dbb424b1d83 -> /var/www/cobbler/images/hardy-x86_64/initrd.gzcopying: /var/www/cobbler/ks_mirror/hardy-x86_64/initrd.gz -> /var/www/cobbler/images/hardy-x86_64/initrd.gzException occured: Exception value: [Errno 2] No such file or directory: '/var/www/cobbler/images/hardy-x86_64/initrd.gz'Exception Info: File "/usr/lib/python2.7/dist-packages/cobbler/remote.py", line 89, in runrc = self._run(self) File "/usr/lib/python2.7/dist-packages/cobbler/remote.py", line 184, in runnerreturn self.remote.api.sync(self.options.get("verbose",False),logger=self.logger) File "/usr/lib/python2.7/dist-packages/cobbler/api.py", line 701, in syncreturn sync.run() File "/usr/lib/python2.7/dist-packages/cobbler/action_sync.py", line 123, in runself.settings.webdir,True) File "/usr/lib/python2.7/dist-packages/cobbler/pxegen.py", line 184, in copy_single_distro_filesapi=self.api, logger=self.logger) File "/usr/lib/python2.7/dist-packages/cobbler/utils.py", line 1195, in linkfilereturn copyfile(src, dst, api=api, logger=logger) File "/usr/lib/python2.7/dist-packages/cobbler/utils.py", line 1206, in copyfileif not os.path.samefile(src,dst): File "/usr/lib/python2.7/posixpath.py", line 154, in samefiles2 = os.stat(f2)!!! TASK FAILED !!!+ exit 1Build step 'Execute shell' marked build as failureArchiving artifactsEmail was triggered for: FailureSending email for trigger: Failure--
Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications
Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications
More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Fixed: precise_folsom_deploy #228
Title: precise_folsom_deploy General InformationBUILD SUCCESSBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_deploy/228/Project:precise_folsom_deployDate of build:Thu, 09 Aug 2012 14:43:52 -0400Build duration:14 minBuild cause:Started by user adamBuilt on:masterHealth ReportWDescriptionScoreBuild stability: 2 out of the last 5 builds failed.60ChangesNo ChangesBuild Artifactslogs/syslog.tar.gzlogs/test-02.os.magners.qa.lexington-log.tar.gzlogs/test-03.os.magners.qa.lexington-log.tar.gzlogs/test-04.os.magners.qa.lexington-log.tar.gzlogs/test-06.os.magners.qa.lexington-log.tar.gzlogs/test-07.os.magners.qa.lexington-log.tar.gzlogs/test-08.os.magners.qa.lexington-log.tar.gzlogs/test-09.os.magners.qa.lexington-log.tar.gzlogs/test-10.os.magners.qa.lexington-log.tar.gzlogs/test-11.os.magners.qa.lexington-log.tar.gzConsole Output[...truncated 2381 lines...] -> Relation: nova-cloud-controller:identity-service <-> keystone:identity-service -> Relation: glance:shared-db <-> mysql:shared-db -> Relation: glance:identity-service <-> keystone:identity-service -> Relation: nova-volume:shared-db <-> mysql:shared-db -> Relation: nova-volume:amqp <-> rabbitmq:amqp -> Relation: openstack-dashboard:identity-service <-> keystone:identity-service -> Relation: nova-compute:shared-db <-> mysql:shared-db -> Relation: nova-compute:amqp <-> rabbitmq:amqp -> Relation: nova-compute:image-service <-> glance:image-service -> Relation: nova-compute:network-manager <-> nova-cloud-controller:network-manager -> Relation: nova-compute:identity-service <-> keystone:identity-service- Ensuring relation state- Deployment complete in 836 seconds.- Juju command log:juju deploy --config=/tmp/tmpctrPzC --repository=/var/lib/jenkins/jobs/precise_folsom_deploy/workspace local:nova-compute nova-computejuju deploy --config=/tmp/tmpctrPzC --repository=/var/lib/jenkins/jobs/precise_folsom_deploy/workspace local:nova-volume nova-volumejuju deploy --config=/tmp/tmpctrPzC --repository=/var/lib/jenkins/jobs/precise_folsom_deploy/workspace local:nova-cloud-controller nova-cloud-controllerjuju deploy --config=/tmp/tmpctrPzC --repository=/var/lib/jenkins/jobs/precise_folsom_deploy/workspace local:keystone keystonejuju deploy --repository=/var/lib/jenkins/jobs/precise_folsom_deploy/workspace local:rabbitmq rabbitmqjuju deploy --repository=/var/lib/jenkins/jobs/precise_folsom_deploy/workspace local:mysql mysqljuju deploy --repository=/var/lib/jenkins/jobs/precise_folsom_deploy/workspace local:openstack-dashboard openstack-dashboardjuju deploy --config=/tmp/tmpctrPzC --repository=/var/lib/jenkins/jobs/precise_folsom_deploy/workspace local:glance glancejuju add-relation keystone:shared-db mysql:shared-dbjuju add-relation nova-cloud-controller:shared-db mysql:shared-dbjuju add-relation nova-cloud-controller:amqp rabbitmq:amqpjuju add-relation nova-cloud-controller:image-service glance:image-servicejuju add-relation nova-cloud-controller:identity-service keystone:identity-servicejuju add-relation glance:shared-db mysql:shared-dbjuju add-relation glance:identity-service keystone:identity-servicejuju add-relation nova-volume:shared-db mysql:shared-dbjuju add-relation nova-volume:amqp rabbitmq:amqpjuju add-relation openstack-dashboard:identity-service keystone:identity-servicejuju add-relation nova-compute:shared-db mysql:shared-dbjuju add-relation nova-compute:amqp rabbitmq:amqpjuju add-relation nova-compute:image-service glance:image-servicejuju add-relation nova-compute:network-manager nova-cloud-controller:network-managerjuju add-relation nova-compute:identity-service keystone:identity-service+ rc=0+ echo 'Deployer returned: 0'Deployer returned: 0+ [[ 0 != 0 ]]+ jenkins-cli build precise_folsom_coverage+ exit 0Archiving artifactsEmail was triggered for: FixedTrigger Success was overridden by another trigger and will not send an email.Sending email for trigger: Fixed-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_nova_trunk #357
Title: quantal_folsom_nova_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/357/Project:quantal_folsom_nova_trunkDate of build:Thu, 09 Aug 2012 16:01:56 -0400Build duration:6 min 20 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesFix the inject_metadata_into_fs in the disk API.by dprinceeditnova/virt/disk/api.pyeditnova/tests/test_virt.pyMake update_db an opt arg in scheduler manager.by dprinceeditnova/scheduler/manager.pyConsole Output[...truncated 5170 lines...]* Automated Ubuntu testing build:* [c5a9c75] Ensure that the dom0 we're connected to is the right one* [2dcd825] Pass context to notification drivers when we can.* [b841b6a] Fix innodb tests again* [d14ac4b] Adding 'host' info to volume-compute connection information.* [ac21815] Allow blank adminPass on server create* [03a331c] Log instance consistently.* [2511f01] Use additional task states during resize* Automated Ubuntu testing build:* [29dc47b] Use save_and_reraise_exception() from common.* [b841b6a] Fix innodb tests again* [ca2bb06] Remove unused images* [d14ac4b] Adding 'host' info to volume-compute connection information.* [524bfb8] Update common.importutils from openstack-common.' --fixes 'lp:1002111'Can't exec "bzr": Argument list too long at /usr/bin/debcommit line 484, line 10010.debcommit: commit failedERROR:root:Error occurred during package creation/build: Command '['debcommit']' returned non-zero exit status 7ERROR:root:Command '['debcommit']' returned non-zero exit status 7INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/nova/quantal-folsom-proposed /tmp/tmpRX9uc7/novamk-build-deps -i -r -t apt-get -y /tmp/tmpRX9uc7/nova/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0e6fc4f4ddca1ea76f9f03ef03d960cad888c810..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/nova/quantal-folsom --forcedch -b -D quantal --newversion 2012.2+git201208091605~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2012.2+git201208091605~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_nova_trunk #358
Title: quantal_folsom_nova_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/358/Project:quantal_folsom_nova_trunkDate of build:Thu, 09 Aug 2012 18:31:55 -0400Build duration:4 min 39 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesMake TerminateInstances compatible with EC2 apiby thorsteneditnova/tests/api/ec2/test_cloud.pyeditnova/api/ec2/cloud.pyTraceback when over allocating IP addressesby chuck.shorteditnova/api/ec2/cloud.pyConsole Output[...truncated 5182 lines...]* Automated Ubuntu testing build:* [c5a9c75] Ensure that the dom0 we're connected to is the right one* [2dcd825] Pass context to notification drivers when we can.* [b841b6a] Fix innodb tests again* [d14ac4b] Adding 'host' info to volume-compute connection information.* [ac21815] Allow blank adminPass on server create* [03a331c] Log instance consistently.* [2511f01] Use additional task states during resize* Automated Ubuntu testing build:* [29dc47b] Use save_and_reraise_exception() from common.* [b841b6a] Fix innodb tests again* [ca2bb06] Remove unused images* [d14ac4b] Adding 'host' info to volume-compute connection information.* [524bfb8] Update common.importutils from openstack-common.' --fixes 'lp:1002111'Can't exec "bzr": Argument list too long at /usr/bin/debcommit line 484, line 10024.debcommit: commit failedERROR:root:Error occurred during package creation/build: Command '['debcommit']' returned non-zero exit status 7ERROR:root:Command '['debcommit']' returned non-zero exit status 7INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/nova/quantal-folsom-proposed /tmp/tmpPKAJ6n/novamk-build-deps -i -r -t apt-get -y /tmp/tmpPKAJ6n/nova/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0e6fc4f4ddca1ea76f9f03ef03d960cad888c810..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/nova/quantal-folsom --forcedch -b -D quantal --newversion 2012.2+git201208091834~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2012.2+git201208091834~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Failure: quantal_folsom_deploy #34
Title: quantal_folsom_deploy
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_deploy/34/Project:quantal_folsom_deployDate of build:Thu, 09 Aug 2012 18:55:31 -0400Build duration:1 min 3 secBuild cause:Started by user adamBuilt on:masterHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80ChangesNo ChangesBuild Artifactslogs/test-02.os.magners.qa.lexington-log.tar.gzlogs/test-03.os.magners.qa.lexington-log.tar.gzlogs/test-04.os.magners.qa.lexington-log.tar.gzlogs/test-05.os.magners.qa.lexington-log.tar.gzlogs/test-06.os.magners.qa.lexington-log.tar.gzlogs/test-07.os.magners.qa.lexington-log.tar.gzlogs/test-09.os.magners.qa.lexington-log.tar.gzlogs/test-10.os.magners.qa.lexington-log.tar.gzlogs/test-11.os.magners.qa.lexington-log.tar.gzlogs/test-12.os.magners.qa.lexington-log.tar.gzConsole Output[...truncated 1049 lines...]+ ks_dir=/var/www/cobbler/ks_mirror/quantal-x86_64+ [[ ! -d /var/www/cobbler/ks_mirror/quantal-x86_64 ]]+ kernel=/var/www/cobbler/ks_mirror/quantal-x86_64/linux+ [[ ! -e /var/www/cobbler/ks_mirror/quantal-x86_64/linux ]]++ strings /var/www/cobbler/ks_mirror/quantal-x86_64/linux++ grep generic++ awk '{ print $1 }'+ cur_kernel=3.5.0-8-generic+ [[ -z 3.5.0-8-generic ]]+ echo 'Derived version 3.5.0-8-generic from /var/www/cobbler/ks_mirror/quantal-x86_64/linux'Derived version 3.5.0-8-generic from /var/www/cobbler/ks_mirror/quantal-x86_64/linux+ mkdir /tmp/get_snapshot_ko-20199+ packages=http://archive.ubuntu.com/ubuntu/dists/quantal/main/binary-amd64/Packages.bz2+ wget -O /tmp/get_snapshot_ko-20199/Packages.bz2 http://archive.ubuntu.com/ubuntu/dists/quantal/main/binary-amd64/Packages.bz2+ bunzip2 /tmp/get_snapshot_ko-20199/Packages.bz2++ cat /tmp/get_snapshot_ko-20199/Packages++ grep linux-image-3.5.0-8-generic++ grep Filename++ awk '{ print $2 }'+ deb_path=pool/main/l/linux/linux-image-3.5.0-8-generic_3.5.0-8.8_amd64.deb+ [[ -z pool/main/l/linux/linux-image-3.5.0-8-generic_3.5.0-8.8_amd64.deb ]]+ deb_url=http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-3.5.0-8-generic_3.5.0-8.8_amd64.deb+ deb_file=linux-image-3.5.0-8-generic_3.5.0-8.8_amd64.deb+ echo deb_url=http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-3.5.0-8-generic_3.5.0-8.8_amd64.debdeb_url=http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-3.5.0-8-generic_3.5.0-8.8_amd64.deb+ echo deb_file=linux-image-3.5.0-8-generic_3.5.0-8.8_amd64.debdeb_file=linux-image-3.5.0-8-generic_3.5.0-8.8_amd64.deb+ cd /tmp/get_snapshot_ko-20199+ wget http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-3.5.0-8-generic_3.5.0-8.8_amd64.deb+ [[ ! -e linux-image-3.5.0-8-generic_3.5.0-8.8_amd64.deb ]]+ ar xf linux-image-3.5.0-8-generic_3.5.0-8.8_amd64.deb+ tar -jxf data.tar.bz2+ mod_path=/tmp/get_snapshot_ko-20199/lib/modules/3.5.0-8-generic/kernel/drivers/md/dm-snapshot.ko+ [[ ! -e /tmp/get_snapshot_ko-20199/lib/modules/3.5.0-8-generic/kernel/drivers/md/dm-snapshot.ko ]]+ [[ -e /var/www/lvm/dm-snapshot.quantal.ko ]]+ sudo cp /tmp/get_snapshot_ko-20199/lib/modules/3.5.0-8-generic/kernel/drivers/md/dm-snapshot.ko /var/www/lvm/dm-snapshot.ko.quantal+ out 'Extracted module to /var/www/lvm/dm-snapshot.ko.quantal' 0+ echo 'Extracted module to /var/www/lvm/dm-snapshot.ko.quantal'Extracted module to /var/www/lvm/dm-snapshot.ko.quantal+ rm -rf /tmp/get_snapshot_ko-20199+ exit 0+ /var/lib/jenkins/tools/jenkins-scripts/repack_q_initrd.sh89224 blockscp: cannot stat `lib/firmware/3.5.0-8-generic/bnx2/bnx2-mips-09-6.2.1a.fw': No such file or directory+ exit 1Build step 'Execute shell' marked build as failureArchiving artifactsEmail was triggered for: FailureSending email for trigger: Failure--
Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications
Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications
More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_nova_trunk #359
Title: quantal_folsom_nova_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/359/Project:quantal_folsom_nova_trunkDate of build:Thu, 09 Aug 2012 19:01:55 -0400Build duration:4 min 15 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesDriver for IBM Storwize and SVC storage.by avishayeditetc/nova/nova.conf.sampleaddnova/tests/test_storwize_svc.pyeditnova/exception.pyaddnova/volume/storwize_svc.pyConsole Output[...truncated 5190 lines...]* Automated Ubuntu testing build:* [c5a9c75] Ensure that the dom0 we're connected to is the right one* [2dcd825] Pass context to notification drivers when we can.* [b841b6a] Fix innodb tests again* [d14ac4b] Adding 'host' info to volume-compute connection information.* [ac21815] Allow blank adminPass on server create* [03a331c] Log instance consistently.* [2511f01] Use additional task states during resize* Automated Ubuntu testing build:* [29dc47b] Use save_and_reraise_exception() from common.* [b841b6a] Fix innodb tests again* [ca2bb06] Remove unused images* [d14ac4b] Adding 'host' info to volume-compute connection information.* [524bfb8] Update common.importutils from openstack-common.' --fixes 'lp:1002111'Can't exec "bzr": Argument list too long at /usr/bin/debcommit line 484, line 10031.debcommit: commit failedERROR:root:Error occurred during package creation/build: Command '['debcommit']' returned non-zero exit status 7ERROR:root:Command '['debcommit']' returned non-zero exit status 7INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/nova/quantal-folsom-proposed /tmp/tmpc6HcKP/novamk-build-deps -i -r -t apt-get -y /tmp/tmpc6HcKP/nova/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0e6fc4f4ddca1ea76f9f03ef03d960cad888c810..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/nova/quantal-folsom --forcedch -b -D quantal --newversion 2012.2+git201208091903~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2012.2+git201208091903~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_nova_trunk #360
Title: quantal_folsom_nova_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/360/Project:quantal_folsom_nova_trunkDate of build:Thu, 09 Aug 2012 19:31:55 -0400Build duration:3 min 58 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesSend create volume from snapshot to the proper hostby zrzhiteditetc/nova/nova.conf.sampleeditnova/volume/api.pyeditnova/tests/api/ec2/test_cloud.pyConsole Output[...truncated 5196 lines...]* Automated Ubuntu testing build:* [c5a9c75] Ensure that the dom0 we're connected to is the right one* [2dcd825] Pass context to notification drivers when we can.* [b841b6a] Fix innodb tests again* [d14ac4b] Adding 'host' info to volume-compute connection information.* [ac21815] Allow blank adminPass on server create* [03a331c] Log instance consistently.* [2511f01] Use additional task states during resize* Automated Ubuntu testing build:* [29dc47b] Use save_and_reraise_exception() from common.* [b841b6a] Fix innodb tests again* [ca2bb06] Remove unused images* [d14ac4b] Adding 'host' info to volume-compute connection information.* [524bfb8] Update common.importutils from openstack-common.' --fixes 'lp:1002111'Can't exec "bzr": Argument list too long at /usr/bin/debcommit line 484, line 10038.debcommit: commit failedERROR:root:Error occurred during package creation/build: Command '['debcommit']' returned non-zero exit status 7ERROR:root:Command '['debcommit']' returned non-zero exit status 7INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/nova/quantal-folsom-proposed /tmp/tmp1bS_Yf/novamk-build-deps -i -r -t apt-get -y /tmp/tmp1bS_Yf/nova/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0e6fc4f4ddca1ea76f9f03ef03d960cad888c810..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/nova/quantal-folsom --forcedch -b -D quantal --newversion 2012.2+git201208091933~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2012.2+git201208091933~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_nova_trunk #361
Title: quantal_folsom_nova_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/361/Project:quantal_folsom_nova_trunkDate of build:Thu, 09 Aug 2012 21:02:00 -0400Build duration:6 min 21 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesAvoid double-reduction of quota for repeated delete.by eglynneditnova/compute/api.pyeditnova/tests/compute/test_compute.pyConsole Output[...truncated 5202 lines...]* Automated Ubuntu testing build:* [c5a9c75] Ensure that the dom0 we're connected to is the right one* [2dcd825] Pass context to notification drivers when we can.* [b841b6a] Fix innodb tests again* [d14ac4b] Adding 'host' info to volume-compute connection information.* [ac21815] Allow blank adminPass on server create* [03a331c] Log instance consistently.* [2511f01] Use additional task states during resize* Automated Ubuntu testing build:* [29dc47b] Use save_and_reraise_exception() from common.* [b841b6a] Fix innodb tests again* [ca2bb06] Remove unused images* [d14ac4b] Adding 'host' info to volume-compute connection information.* [524bfb8] Update common.importutils from openstack-common.' --fixes 'lp:1002111'Can't exec "bzr": Argument list too long at /usr/bin/debcommit line 484, line 10045.debcommit: commit failedERROR:root:Error occurred during package creation/build: Command '['debcommit']' returned non-zero exit status 7ERROR:root:Command '['debcommit']' returned non-zero exit status 7INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/nova/quantal-folsom-proposed /tmp/tmp4TuHBG/novamk-build-deps -i -r -t apt-get -y /tmp/tmp4TuHBG/nova/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0e6fc4f4ddca1ea76f9f03ef03d960cad888c810..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/nova/quantal-folsom --forcedch -b -D quantal --newversion 2012.2+git201208092105~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2012.2+git201208092105~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 140, in raise esubprocess.CalledProcessError: Command '['debcommit']' returned non-zero exit status 7Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Fixed: quantal_folsom_quantum_trunk #76
Title: quantal_folsom_quantum_trunk General InformationBUILD SUCCESSBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_quantum_trunk/76/Project:quantal_folsom_quantum_trunkDate of build:Thu, 09 Aug 2012 22:01:58 -0400Build duration:7 min 47 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80Changesfix missing deallocation of gateway ipby daneditquantum/db/db_base_plugin_v2.pyConsole Output[...truncated 4195 lines...]Uploading to ppa (via ftp to ppa.launchpad.net): Uploading quantum_2012.2+git201208092202~quantal-0ubuntu1.dsc: done. Uploading quantum_2012.2+git201208092202~quantal.orig.tar.gz: done. Uploading quantum_2012.2+git201208092202~quantal-0ubuntu1.debian.tar.gz: done. Uploading quantum_2012.2+git201208092202~quantal-0ubuntu1_source.changes: done.Successfully uploaded packages.INFO:root:Installing build artifacts into /var/lib/jenkins/www/aptDEBUG:root:['reprepro', '--waitforlock', '10', '-Vb', '/var/lib/jenkins/www/apt', 'include', 'quantal-folsom', 'quantum_2012.2+git201208092202~quantal-0ubuntu1_amd64.changes']Exporting indices...Successfully created '/var/lib/jenkins/www/apt/dists/quantal-folsom/Release.gpg.new'Successfully created '/var/lib/jenkins/www/apt/dists/quantal-folsom/InRelease.new'Deleting files no longer referenced...deleting and forgetting pool/main/q/quantum/python-quantum_2012.2+git201208070501~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/q/quantum/quantum-common_2012.2+git201208070501~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/q/quantum/quantum-plugin-cisco_2012.2+git201208070501~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/q/quantum/quantum-plugin-linuxbridge-agent_2012.2+git201208070501~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/q/quantum/quantum-plugin-linuxbridge_2012.2+git201208070501~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/q/quantum/quantum-plugin-nicira_2012.2+git201208070501~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/q/quantum/quantum-plugin-openvswitch-agent_2012.2+git201208070501~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/q/quantum/quantum-plugin-openvswitch_2012.2+git201208070501~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/q/quantum/quantum-plugin-ryu-agent_2012.2+git201208070501~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/q/quantum/quantum-plugin-ryu_2012.2+git201208070501~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/q/quantum/quantum-server_2012.2+git201208070501~quantal-0ubuntu1_all.debINFO:root:Pushing changes back to bzr testing branchDEBUG:root:['bzr', 'push', 'lp:~openstack-ubuntu-testing/quantum/quantal-folsom']Pushed up to revision 47.INFO:root:Storing current commit for next build: bcde97b48552072bda453e08f6a5c669b2838c05INFO:root:Complete command log:INFO:root:Destroying schroot.git archive master --format tar --prefix quantum-2012.2-201208092202/git archive master --format tar --prefix quantum-2012.2-201208092202/git log -n1 --no-merges --pretty=format:%Hgit log fe09214372f199d4cfbff76aabf76470543c26f2..HEAD --no-merges --pretty=format:[%h] %sbzr branch lp:~openstack-ubuntu-testing/quantum/quantal-folsom-proposed quantumbzr merge lp:~openstack-ubuntu-testing/quantum/quantal-folsom --forcedch -b -D quantal --newversion 2012.2+git201208092202~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2012.2+git201208092202~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucmk-build-deps -i -r -t apt-get -y /tmp/tmpTtmYcb/quantum/debian/controlbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC quantum_2012.2+git201208092202~quantal-0ubuntu1_source.changessbuild -d quantal-folsom -n -A quantum_2012.2+git201208092202~quantal-0ubuntu1.dscdput ppa:openstack-ubuntu-testing/folsom-trunk-testing quantum_2012.2+git201208092202~quantal-0ubuntu1_source.changesreprepro --waitforlock 10 -Vb /var/lib/jenkins/www/apt include quantal-folsom quantum_2012.2+git201208092202~quantal-0ubuntu1_amd64.changesbzr push lp:~openstack-ubuntu-testing/quantum/quantal-folsomEmail was triggered for: FixedTrigger Success was overridden by another trigger and will not send an email.Sending email for trigger: Fixed-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
