[Openstack-community] OpenStack User Group in Stockholm?
Hi all, I have been exploring and asking around since a while about the use of OpenStack in Stockholm (or in Sweden in general, but since I'm based in Stockholm, this is the area of interest) and it seems that there are some groups and scattered users. I would like to find out if anyone has heard of ideas of starting a user group in Stockholm. In case you have, please point me to the right contacts; In case you have not, are there any reasons to not start one? I have been working with Erlang (a niche language that grew into some nice projects lately) and the user group here in Stockholm proved to be quite a good spot for sharing ideas and experience outside of regular conferences. Thank you! /Nico. -- Mailing list: https://launchpad.net/~openstack-community Post to : openstack-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-community More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova-compute doesn't start on reboot, only manually
Was it a fresh install, or did you have already those components installed before ? Alessandro Tagliapietra 28 mai 2012 23:22The line before isso i think rabbitmq is already started isn't it?Best Regards Razique Mahroua 28 mai 2012 11:00 Hi Stephenlooks like the amqp server doesn't start.make sure it starts along with the nova-scheduler first.Does both services start on boot ?Razique Stephen Gran 28 mai 2012 10:53Hi, On Mon, 2012-05-28 at 11:41 +0300, Alessandro Tagliapietra wrote: Hello, i've installed openstack following the ubuntu 12.04 deploy guide, only problem is that nova-compute has to be started manually, by default it doesn't start on boot, this is the error log: ... 2012-05-27 23:48:14 TRACE nova.rpc.common timeout: timed out ... 2012-05-27 23:48:14 TRACE nova Timeout: Timeout while waiting on RPC response. Then after system boot a start nova-compute make everything working. Any idea? Both of these are MQ timeouts. You'll want to arrange for your MQ server to be running when nova starts up. How you do that depends on your local architecture. Cheers, Alessandro Tagliapietra 28 mai 2012 10:41Hello, i've installed openstack following the ubuntu 12.04 deploy guide, only problem is that nova-compute has to be started manually, by default it doesn't start on boot, this is the error log:2012-05-27 23:47:14 INFO nova.rpc.common [req-46624af9-9d2a-4901-b635-66f557d3b54c None None] Connected to AMQP server on 10.8.0.1:56722012-05-27 23:48:14 ERROR nova.rpc.common [req-46624af9-9d2a-4901-b635-66f557d3b54c None None] Timed out waiting for RPC response: timed out2012-05-27 23:48:14 TRACE nova.rpc.common Traceback (most recent call last):2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/nova/rpc/impl_kombu.py", line 490, in ensure2012-05-27 23:48:14 TRACE nova.rpc.common return method(*args, **kwargs)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/nova/rpc/impl_kombu.py", line 567, in _consume2012-05-27 23:48:14 TRACE nova.rpc.common return self.connection.drain_events(timeout=timeout)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/kombu/connection.py", line 175, in drain_events2012-05-27 23:48:14 TRACE nova.rpc.common return self.transport.drain_events(self.connection, **kwargs)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py", line 238, in drain_events2012-05-27 23:48:14 TRACE nova.rpc.common return connection.drain_events(**kwargs)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py", line 57, in drain_events2012-05-27 23:48:14 TRACE nova.rpc.common return self.wait_multi(self.channels.values(), timeout=timeout)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py", line 63, in wait_multi2012-05-27 23:48:14 TRACE nova.rpc.common chanmap.keys(), allowed_methods, timeout=timeout)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py", line 120, in _wait_multiple2012-05-27 23:48:14 TRACE nova.rpc.common channel, method_sig, args, content = read_timeout(timeout)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py", line 94, in read_timeout2012-05-27 23:48:14 TRACE nova.rpc.common return self.method_reader.read_method()2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/amqplib/client_0_8/method_framing.py", line 221, in read_method2012-05-27 23:48:14 TRACE nova.rpc.common raise m2012-05-27 23:48:14 TRACE nova.rpc.common timeout: timed out2012-05-27 23:48:14 TRACE nova.rpc.common 2012-05-27 23:48:14CRITICAL nova [-] Timeout while waiting on RPC response.2012-05-27 23:48:14 TRACE nova Traceback (most recent call last):2012-05-27 23:48:14 TRACE nova File "/usr/bin/nova-compute", line 49, in module 2012-05-27 23:48:14 TRACE nova service.wait()2012-05-27 23:48:14 TRACE nova File "/usr/lib/python2.7/dist-packages/nova/service.py", line 413, in wait 2012-05-27 23:48:14 TRACE nova _launcher.wait()2012-05-27 23:48:14 TRACE nova File "/usr/lib/python2.7/dist-packages/nova/service.py", line 131, in wait2012-05-27 23:48:14 TRACE nova service.wait()2012-05-27 23:48:14 TRACE nova File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 166, in wait2012-05-27 23:48:14 TRACE nova return self._exit_event.wait()2012-05-27 23:48:14 TRACE nova File "/usr/lib/python2.7/dist-packages/eventlet/event.py", line 116, in wait2012-05-27 23:48:14 TRACE nova return hubs.get_hub().switch()2012-05-27 23:48:14 TRACE nova File "/usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 177, in
Re: [Openstack] Fwd: Nodejs in horizon
On 28/05/12 16:21, Thierry Carrez wrote: John Postlethwait wrote: Sorry if I've missed anything below, this thread has become rather fragmented and messy (at least in my email clients) but I will try to address the main points I have seen so far: Sorry, if I jump in late in this thread, I may have skipped some basics. If I get it right, nodejs is just required to compile LESS to css, right? There is at least one alternative without requiring nodejs: https://github.com/leafo/lessphp -- Matthias Runge mru...@matthias-runge.de ___ 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] cfg usage - option registration, global objects
Hey, I had the chance to discuss the global conf issue with a good number of folks at the design summit and the conclusion I came away with was that opinions range from meh, it's fairly inelegant but I don't care much either way to I actually like the simplicity to we use global conf, it works and we're not changing. Indeed, at the common configuration patterns, there was very little in the way of opinion expressed at all: http://etherpad.openstack.org/FolsomCommonConfigPatterns Given that my goal here is to establish a common pattern used by all projects, that both Nova and Keystone uses global conf and there isn't a huge amount of interest in moving away from it, I'm proposing adding support for it to openstack-common: https://blueprints.launchpad.net/openstack-common/+spec/cfg-global-object Adopting this pattern across all projects will actually help openstack-common more generally. For example, Russell is moving the RPC code into openstack-common and it has a bunch of configuration options. If it can assume a global configuration object, things become much easier. I've posted patches to openstack-common, Nova, Glance and Keystone: https://review.openstack.org/#/q/status:open+branch:master+topic:bp/cfg-global-object,n,z Cheers, Mark. On Tue, 2012-03-06 at 10:10 +, Mark McLoughlin wrote: Hey, The original cfg design[1] assumed certain usage patterns that I hoped would be adopted by all projects using it. In gerrit, we're debating a set of patch to make keystone use these patterns: https://review.openstack.org/4547 I thought it was best to move some of that discussion here since I'm hoping we can get some rough consensus across projects. I really think it will be beneficial if we can share common idioms and patterns across projects, rather than just using the same library in different ways. [snip] Thread archived here: https://lists.launchpad.net/openstack/msg08329.html ___ 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] release fixed_ip
Hi I noticed that when I delete a instance, the fixed ip that associate with it will not be used for other newly launched instance I want to know if there is a timeout for a fixed ip to be reused, how long this time is Thanks -- William Herry williamherrych...@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] release fixed_ip
Are you using Quantum? Endre. 2012/5/29 William Herry william.herry.ch...@gmail.com Hi I noticed that when I delete a instance, the fixed ip that associate with it will not be used for other newly launched instance I want to know if there is a timeout for a fixed ip to be reused, how long this time is Thanks -- William Herry williamherrych...@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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova-compute doesn't start on reboot, only manually
Fresh install, it did that multiple times because this is like the 6th install and i've only that problem now.RegardsIl giorno 29/mag/2012, alle ore 10:07, Razique Mahroua ha scritto: Was it a fresh install, or did you have already those components installed before ? Alessandro Tagliapietra 28 mai 2012 23:22The line before isso i think rabbitmq is already started isn't it?Best Regards Razique Mahroua 28 mai 2012 11:00 Hi Stephenlooks like the amqp server doesn't start.make sure it starts along with the nova-scheduler first.Does both services start on boot ?Razique Stephen Gran 28 mai 2012 10:53Hi, On Mon, 2012-05-28 at 11:41 +0300, Alessandro Tagliapietra wrote: Hello, i've installed openstack following the ubuntu 12.04 deploy guide, only problem is that nova-compute has to be started manually, by default it doesn't start on boot, this is the error log: ... 2012-05-27 23:48:14 TRACE nova.rpc.common timeout: timed out ... 2012-05-27 23:48:14 TRACE nova Timeout: Timeout while waiting on RPC response. Then after system boot a start nova-compute make everything working. Any idea? Both of these are MQ timeouts. You'll want to arrange for your MQ server to be running when nova starts up. How you do that depends on your local architecture. Cheers, Alessandro Tagliapietra 28 mai 2012 10:41Hello, i've installed openstack following the ubuntu 12.04 deploy guide, only problem is that nova-compute has to be started manually, by default it doesn't start on boot, this is the error log:2012-05-27 23:47:14 INFO nova.rpc.common [req-46624af9-9d2a-4901-b635-66f557d3b54c None None] Connected to AMQP server on 10.8.0.1:56722012-05-27 23:48:14 ERROR nova.rpc.common [req-46624af9-9d2a-4901-b635-66f557d3b54c None None] Timed out waiting for RPC response: timed out2012-05-27 23:48:14 TRACE nova.rpc.common Traceback (most recent call last):2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/nova/rpc/impl_kombu.py", line 490, in ensure2012-05-27 23:48:14 TRACE nova.rpc.common return method(*args, **kwargs)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/nova/rpc/impl_kombu.py", line 567, in _consume2012-05-27 23:48:14 TRACE nova.rpc.common return self.connection.drain_events(timeout=timeout)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/kombu/connection.py", line 175, in drain_events2012-05-27 23:48:14 TRACE nova.rpc.common return self.transport.drain_events(self.connection, **kwargs)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py", line 238, in drain_events2012-05-27 23:48:14 TRACE nova.rpc.common return connection.drain_events(**kwargs)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py", line 57, in drain_events2012-05-27 23:48:14 TRACE nova.rpc.common return self.wait_multi(self.channels.values(), timeout=timeout)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py", line 63, in wait_multi2012-05-27 23:48:14 TRACE nova.rpc.common chanmap.keys(), allowed_methods, timeout=timeout)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py", line 120, in _wait_multiple2012-05-27 23:48:14 TRACE nova.rpc.common channel, method_sig, args, content = read_timeout(timeout)2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/kombu/transport/pyamqplib.py", line 94, in read_timeout2012-05-27 23:48:14 TRACE nova.rpc.common return self.method_reader.read_method()2012-05-27 23:48:14 TRACE nova.rpc.common File "/usr/lib/python2.7/dist-packages/amqplib/client_0_8/method_framing.py", line 221, in read_method2012-05-27 23:48:14 TRACE nova.rpc.common raise m2012-05-27 23:48:14 TRACE nova.rpc.common timeout: timed out2012-05-27 23:48:14 TRACE nova.rpc.common 2012-05-27 23:48:14CRITICAL nova [-] Timeout while waiting on RPC response.2012-05-27 23:48:14 TRACE nova Traceback (most recent call last):2012-05-27 23:48:14 TRACE nova File "/usr/bin/nova-compute", line 49, in module 2012-05-27 23:48:14 TRACE nova service.wait()2012-05-27 23:48:14 TRACE nova File "/usr/lib/python2.7/dist-packages/nova/service.py", line 413, in wait 2012-05-27 23:48:14 TRACE nova _launcher.wait()2012-05-27 23:48:14 TRACE nova File "/usr/lib/python2.7/dist-packages/nova/service.py", line 131, in wait2012-05-27 23:48:14 TRACE nova service.wait()2012-05-27 23:48:14 TRACE nova File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 166, in wait2012-05-27 23:48:14 TRACE nova return self._exit_event.wait()2012-05-27 23:48:14 TRACE nova File "/usr/lib/python2.7/dist-packages/eventlet/event.py", line
Re: [Openstack] release fixed_ip
Which IPAM ? This behavior is fixed for mélange IPAM . Please look at https://bugs.launchpad.net/melange/+bug/971504 Also see this : https://bugs.launchpad.net/nova/+bug/973442 -Mandar From: openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net [mailto:openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net] On Behalf Of Endre Karlson Sent: Tuesday, May 29, 2012 2:08 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] release fixed_ip Are you using Quantum? Endre. 2012/5/29 William Herry william.herry.ch...@gmail.commailto:william.herry.ch...@gmail.com Hi I noticed that when I delete a instance, the fixed ip that associate with it will not be used for other newly launched instance I want to know if there is a timeout for a fixed ip to be reused, how long this time is Thanks -- William Herry williamherrych...@gmail.commailto:williamherrych...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding___ 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] release fixed_ip
I want to know if there is a timeout for a fixed ip to be reused, how long this time is Parameter you are looking for is fixed_ip_disassociate_timeout. Set it to low value like 1 (This is number of seconds) Default value is 600 i.e. 10 minutes. -Mandar __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding ___ 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] live migration with libvirt error ---inet_listen_opts: bind Cannot assign requested address---is this a bug or something?..
Hello ,all I am doing live-migration with 3 nodes installation .Everything is set just as the official document instructed here: http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-live-migrations.html When I use the command nova live-migration vm1 HostC , nova wouldn't give me any error information.But I checked the vm with nova show vm1,and found the migration is not succeeded, *vm1* is still running on the source compute node .I checked the /var/log/libvirt/libvirtd.log ,and found the following error: 2012-05-29 03:43:47.543+: 8875: error : virNetClientProgramDispatchError:174 : internal error process exited while connecting to monitor: char device redirected to /dev/pts/1 inet_listen_opts: bind(ipv4,192.168.0.205,5900): Cannot assign requested address inet_listen_opts: FAILED 2012-05-29 06:30:29.828+: 8875: error : virNetClientProgramDispatchError:174 : Unable to read from monitor: Connection reset by peer if , I disabled the vnc by commenting out all the vnc related lines in /etc/nova/nova.conf on both compute nodes ,and launched a new instance *vm2 *,then vm2 can be migrated between the two compute nodes freely without any error. So I guess there may be some problems with the vnc when doing live migration in nova? Also ,I googled and found a bug report here ,please check it out: https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=703851 I don't know whether it is related to my problems here .Please tell me if it is a bug of nova or just something I did wrong. Thank you in advance! . Eric Luo. -- Stay with me,stay with my heart,honey. -- Stay with me,stay with my heart,honey. ___ 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] [Swift] 1.5.0 release proposed candidate
Hi everyone, A milestone-proposed branch was created for Swift in preparation for the 1.5.0 release, planned on Thursday. Please test the proposed delivery to ensure no critical regression found its way in. Release-critical fixes might be backported to the milestone-proposed branch until final release, and will be tracked using the 1.5.0 milestone targeting. You can find the candidate tarball at: http://swift.openstack.org/tarballs/swift-1.5.0~20120529.r1891.tar.gz (Future candidate tarballs might be posted as swift-1.5.0~XXX.tar.gz) You can access the milestone-proposed branch directly at: https://github.com/openstack/swift/tree/milestone-proposed Regards, -- 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
[Openstack] [Nova] Instances which use flavors with disk space fail to spawn
Hello,
I'm unable to boot any image with a flavor that has a disk space associated
with it. It always fails at the spawning state. Below it the log output of
nova-compute:
2012-05-28 16:20:25 ERROR nova.compute.manager
[req-1c725f9c-acae-47c4-b5ae-9ed5d2d9830c 9494d025721c4d7bb28a16fa796f9414
04282e9aff474d2383bb4d4417673e0a] [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] Instance failed to spawn
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] Traceback (most recent call last):
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] File
/usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 592, in
_spawn
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7]
self._legacy_nw_info(network_info), block_device_info)
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] File
/usr/lib/python2.7/dist-packages/nova/exception.py, line 114, in wrapped
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] return f(*args, **kw)
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
922, in spawn
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] self._create_new_domain(xml)
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line
1575, in _create_new_domain
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7]
domain.createWithFlags(launch_flags)
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] File
/usr/lib/python2.7/dist-packages/libvirt.py, line 581, in createWithFlags
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] if ret == -1: raise libvirtError
('virDomainCreateWithFlags() failed', dom=self)
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] libvirtError: Unable to read from
monitor: Connection reset by peer
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7]
2012-05-28 16:20:25 DEBUG nova.compute.manager
[req-1c725f9c-acae-47c4-b5ae-9ed5d2d9830c 9494d025721c4d7bb28a16fa796f9414
04282e9aff474d2383bb4d4417673e0a] [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] Deallocating network for instance
from (pid=23518) _deallocate_network
/usr/lib/python2.7/dist-packages/nova/compute/manager.py:616
2012-05-28 16:20:25 DEBUG nova.rpc.amqp
[req-1c725f9c-acae-47c4-b5ae-9ed5d2d9830c 9494d025721c4d7bb28a16fa796f9414
04282e9aff474d2383bb4d4417673e0a] Making asynchronous cast on network...
from (pid=23518) cast /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:346
2012-05-28 16:20:26 ERROR nova.rpc.amqp
[req-1c725f9c-acae-47c4-b5ae-9ed5d2d9830c 9494d025721c4d7bb28a16fa796f9414
04282e9aff474d2383bb4d4417673e0a] Exception during message handling
2012-05-28 16:20:26 TRACE nova.rpc.amqp Traceback (most recent call last):
2012-05-28 16:20:26 TRACE nova.rpc.amqp File
/usr/lib/python2.7/dist-packages/nova/rpc/amqp.py, line 252, in
_process_data
2012-05-28 16:20:26 TRACE nova.rpc.amqp rval = node_func(context=ctxt,
**node_args)
2012-05-28 16:20:26 TRACE nova.rpc.amqp File
/usr/lib/python2.7/dist-packages/nova/exception.py, line 114, in wrapped
2012-05-28 16:20:26 TRACE nova.rpc.amqp return f(*args, **kw)
2012-05-28 16:20:26 TRACE nova.rpc.amqp File
/usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 177, in
decorated_function
2012-05-28 16:20:26 TRACE nova.rpc.amqp sys.exc_info())
2012-05-28 16:20:26 TRACE nova.rpc.amqp File
/usr/lib/python2.7/contextlib.py, line 24, in __exit__
2012-05-28 16:20:26 TRACE nova.rpc.amqp self.gen.next()
2012-05-28 16:20:26 TRACE nova.rpc.amqp File
/usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 171, in
decorated_function
2012-05-28 16:20:26 TRACE nova.rpc.amqp return function(self, context,
instance_uuid, *args, **kwargs)
2012-05-28 16:20:26 TRACE nova.rpc.amqp File
/usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 651, in
run_instance
2012-05-28 16:20:26 TRACE nova.rpc.amqp do_run_instance()
2012-05-28 16:20:26 TRACE nova.rpc.amqp File
/usr/lib/python2.7/dist-packages/nova/utils.py, line 945, in inner
2012-05-28 16:20:26 TRACE nova.rpc.amqp retval = f(*args, **kwargs)
2012-05-28 16:20:26 TRACE nova.rpc.amqp File
/usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 650, in
do_run_instance
2012-05-28 16:20:26 TRACE nova.rpc.amqp
[Openstack] [OpenStack][Glance][Nova] How to export images created from running instances?
Hello, Is there any way to export an image created from another instance so that it can be upload elsewhere? In this particular case, i want to export a snapshot created in diablo to use in essex. 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] 回复： Re: [OpenStack][Nova] live migration with libvirt error ---inet_listen_opts: bind Cannot assign requested address---is this a bug or something?..
check the vnc port agsigned for the wm on the destination node weather used by the other, base the log, the 5900 port on the destination node is occupied by another. the min vnc port used by libvirt is 5900 by default. ps:if use vmware ESXi hypervisor hot migrate can success weather the vncport of the vm used or not on the destination node. -原信息- 发自： Eric Luo 发送： 2012/05/29, 17:44 收件人: openstack@lists.launchpad.net 主题： Re: [Openstack] [OpenStack][Nova] live migration with libvirt error ---inet_listen_opts: bind Cannot assign requested address---is this a bug or something?.. Hello ,all I am doing live-migration with 3 nodes installation .Everything is set just as the official document instructed here: http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-live-migrations.html When I use the command nova live-migration vm1 HostC , nova wouldn't give me any error information.But I checked the vm with nova show vm1,and found the migration is not succeeded, *vm1* is still running on the source compute node .I checked the /var/log/libvirt/libvirtd.log ,and found the following error: 2012-05-29 03:43:47.543+: 8875: error : virNetClientProgramDispatchError:174 : internal error process exited while connecting to monitor: char device redirected to /dev/pts/1 inet_listen_opts: bind(ipv4,192.168.0.205,5900): Cannot assign requested address inet_listen_opts: FAILED 2012-05-29 06:30:29.828+: 8875: error : virNetClientProgramDispatchError:174 : Unable to read from monitor: Connection reset by peer if , I disabled the vnc by commenting out all the vnc related lines in /etc/nova/nova.conf on both compute nodes ,and launched a new instance *vm2 *,then vm2 can be migrated between the two compute nodes freely without any error. So I guess there may be some problems with the vnc when doing live migration in nova? Also ,I googled and found a bug report here ,please check it out: https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=703851 I don't know whether it is related to my problems here .Please tell me if it is a bug of nova or just something I did wrong. Thank you in advance! . Eric Luo. -- Stay with me,stay with my heart,honey. -- Stay with me,stay with my heart,honey. ___ 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][Glance][Nova] How to export images created from running instances?
Hi, I did that. Create snapshot from the running machine, identify the file corresponding to the snapshot. In my case was a qcow2 file and then add to essex with glance add Regards, Gabriel From: Leander Bessa Beernaert leande...@gmail.com To: openstack@lists.launchpad.net Sent: Tuesday, May 29, 2012 2:19 PM Subject: [Openstack] [OpenStack][Glance][Nova] How to export images created from running instances? Hello, Is there any way to export an image created from another instance so that it can be upload elsewhere? In this particular case, i want to export a snapshot created in diablo to use in essex. 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] [OpenStack][Glance][Nova] How to export images created from running instances?
Thanks, i though it wouldn't be that simple! Regards, Leander On Tue, May 29, 2012 at 1:18 PM, Staicu Gabriel gabriel_sta...@yahoo.comwrote: Hi, I did that. Create snapshot from the running machine, identify the file corresponding to the snapshot. In my case was a qcow2 file and then add to essex with glance add Regards, Gabriel -- *From:* Leander Bessa Beernaert leande...@gmail.com *To:* openstack@lists.launchpad.net *Sent:* Tuesday, May 29, 2012 2:19 PM *Subject:* [Openstack] [OpenStack][Glance][Nova] How to export images created from running instances? Hello, Is there any way to export an image created from another instance so that it can be upload elsewhere? In this particular case, i want to export a snapshot created in diablo to use in essex. 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
[Openstack] Fwd: [Infra] administration of new mailinglists
-- Forwarded message -- From: Thierry Carrez thie...@openstack.org Date: Sat, May 26, 2012 at 2:38 PM Subject: Re: administration of new mailinglists To: Monty Taylor mord...@inaugust.com Cc: Stefano Maffulli stef...@openstack.org, Duncan McGreggor dun...@dreamhost.com, Michael Tietz ti...@b1-systems.de, Christian Berendt bere...@b1-systems.de, James E. Blair cor...@inaugust.com Monty Taylor wrote: On 05/25/2012 03:27 AM, Thierry Carrez wrote: Stefano Maffulli wrote: On 05/23/2012 05:58 PM, Stefano Maffulli wrote: http://etherpad.openstack.org/newmlist-layout re-reading this list, I think it's not clear to me what purpose the 'old' list on launchpad will serve. How shall we re-purpose it? If we keep it, do we need to keep also operators (in what would they differ?) The current list (the General list) is the default discussion list about everything openstack. We have decided to move the development discussions (focused on the next release of OpenStack) out of this list and on its own list. That doesn't suddenly make it empty. It's still the list for discussing everything openstack, with a focus on the latest stable release. I think we should keep it, because it is certainly the biggest openstack list out there, with 2072 subscribers. tl;dr - I could not possible disagree more strongly. There should be one place for mailing lists. If we are running our own mailman properly already, this list should move there. I think the 2072 subscribers will be able to figure out it. That's a valid point (my point was about the topic of the list, not so much about its location). I'm not really attached to the LP setup, it's more a question of disruption for our existing users, but the benefit might be worth it. That said, I still think there is value in a default discussion list, separate from the development list. I guess we could have: openstack@l.o.o - default discussion about openstack - present-looking openstack-dev@l.o.o - development discussions - forward-looking openstack-operators@l.o.o - operators (??) Alternatively we can have a more classic: openstack-announce@l.o.o - Important announcements openstack-users@l.o.o - discussion about using openstack, present-lookin openstack-dev@l.o.o - development discussions - forward-looking We would rename operators to users and encourage current subscribers to join it. Two questions: how do you merge the old archives with the operators archive ? And for announce: who gets the right to post to it ? Or rather, who gets to moderate the posts to it ? PPB ? PTL/relmgr ? Any volunteer ? -- 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
[Openstack] Fwd: [Infra] administration of new mailinglists
-- Forwarded message -- From: Stefano Maffulli stef...@openstack.org Date: Tue, May 29, 2012 at 11:13 AM Subject: Re: administration of new mailinglists To: Thierry Carrez thie...@openstack.org Cc: Monty Taylor mord...@inaugust.com, Duncan McGreggor dun...@dreamhost.com, Michael Tietz ti...@b1-systems.de, Christian Berendt bere...@b1-systems.de, James E. Blair cor...@inaugust.com On 05/26/2012 11:38 AM, Thierry Carrez wrote: That's a valid point (my point was about the topic of the list, not so much about its location). I'm not really attached to the LP setup, it's more a question of disruption for our existing users, but the benefit might be worth it. I don't think there is an easy way to migrate over 2000 users from one place to another but I also think that we should have one place for all the lists, ideally. Moving those subscribers will not be an easy task, so I would consider that a project in itself. We should move this discussion to the public list. That said, I still think there is value in a default discussion list, separate from the development list. I guess we could have: openstack@l.o.o - default discussion about openstack - present-looking openstack-dev@l.o.o - development discussions - forward-looking openstack-operators@l.o.o - operators (??) I like this setup, so we don't have to change names/addresses. We can keep openstack@ on LP until we have the new l.o.o up and running. Migrating will be complicate. We would rename operators to users and encourage current subscribers to join it. I don't see the value in renaming the list. Why would you want to create this pain for the current subscribers? Two questions: how do you merge the old archives with the operators archive ? which old archives? And for announce: who gets the right to post to it ? Or rather, who gets to moderate the posts to it ? PPB ? PTL/relmgr ? Any volunteer ? You'll have to work very hard to convince me that an announce list is worth the trouble :) 'Tradition' is not a good argument. First of all, it's not clear to me *who* would need to send out announcements. Can somebody start from there? I'll start enumerating why I don't think such list is needed by community managers: - more lists, more policies, more complexity for newcomers, things that they need to learn. - more lists, more policies, more complexity to manage (moderators, spam masters, etc) - the announce list has not been used for over 8 months, nobody noticed - multiplying contact points for people increases the need for cross-posting, more messages - an announce is fundamentally a one-way communication, no need to have 'discussions' around it, mailing list is the wrong tool *today* (it made sense in the 90s) - an announce sent to a mailman list is fundamentally shouting in the wind: there might be people listening, you'll never know if they heard something. A *segmented* (developers, operators, business folks) newsletter is the best way to send out announcements. /stef ___ 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] Fwd: [Infra] administration of new mailinglists
-- Forwarded message -- From: Monty Taylor mord...@inaugust.com Date: Tue, May 29, 2012 at 11:24 AM Subject: Re: administration of new mailinglists To: Stefano Maffulli stef...@openstack.org Cc: Thierry Carrez thie...@openstack.org, Duncan McGreggor dun...@dreamhost.com, Michael Tietz ti...@b1-systems.de, Christian Berendt bere...@b1-systems.de, James E. Blair cor...@inaugust.com On 05/29/2012 11:13 AM, Stefano Maffulli wrote: On 05/26/2012 11:38 AM, Thierry Carrez wrote: That's a valid point (my point was about the topic of the list, not so much about its location). I'm not really attached to the LP setup, it's more a question of disruption for our existing users, but the benefit might be worth it. I don't think there is an easy way to migrate over 2000 users from one place to another but I also think that we should have one place for all the lists, ideally. Moving those subscribers will not be an easy task, so I would consider that a project in itself. We should move this discussion to the public list. That said, I still think there is value in a default discussion list, separate from the development list. I guess we could have: openstack@l.o.o - default discussion about openstack - present-looking openstack-dev@l.o.o - development discussions - forward-looking openstack-operators@l.o.o - operators (??) I like this setup, so we don't have to change names/addresses. We can keep openstack@ on LP until we have the new l.o.o up and running. Migrating will be complicate. We would rename operators to users and encourage current subscribers to join it. I don't see the value in renaming the list. Why would you want to create this pain for the current subscribers? Two questions: how do you merge the old archives with the operators archive ? which old archives? And for announce: who gets the right to post to it ? Or rather, who gets to moderate the posts to it ? PPB ? PTL/relmgr ? Any volunteer ? You'll have to work very hard to convince me that an announce list is worth the trouble :) 'Tradition' is not a good argument. First of all, it's not clear to me *who* would need to send out announcements. Can somebody start from there? I'll start enumerating why I don't think such list is needed by community managers: - more lists, more policies, more complexity for newcomers, things that they need to learn. - more lists, more policies, more complexity to manage (moderators, spam masters, etc) - the announce list has not been used for over 8 months, nobody noticed - multiplying contact points for people increases the need for cross-posting, more messages - an announce is fundamentally a one-way communication, no need to have 'discussions' around it, mailing list is the wrong tool *today* (it made sense in the 90s) - an announce sent to a mailman list is fundamentally shouting in the wind: there might be people listening, you'll never know if they heard something. A *segmented* (developers, operators, business folks) newsletter is the best way to send out announcements. I agree with this about the announce list. Announcements these days are usually done via some combination of blog/rss/twitter. ___ 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] [metering] delta vs. cumulative meters
IIRC, the meters discussed in the wiki [1] are supposed to show delta values (usage since the last time an event was generated), although the Alternate Gauge Design section discusses cumulative meters instead. The libvirt pollsters we have now produce cumulative data, and it might be complicated and error-prone to change them to compute the deltas internally before generating events. On the other hand, some of the other counters may be more complicated to generate as cumulative values. Rather than taking an either/or approach, I propose we document for each counter whether it uses the delta or cumulative approach. The API server can ask the meter plugin for that piece of information when calculating the aggregate value so that the caller does not have to keep track of the rules for each meter. Thoughts? Doug [1] http://wiki.openstack.org/EfficientMetering ___ 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] [metering] Changes to the ceilometer Jenkins job
Hi, We noticed that currently, on Stackforge, the ceilometer project has only one Jenkins job, checking that the merge occurs correctly. We'd like to add jobs to run unit tests, pep8, etc… I took a look at the openstack-ci-puppet repo, but I'm not sure of the changes, so I prefer to ask here for someone that understand this to help. From what I see, it's likely we would like to use the default python_jobs template. If anything is missing on our side to use the standard set of checks, we'll do what is necessary to be able to use them. :) Thanks in advance! Cheers, -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] git-based jenkins jobs and pre-approval check jobs
On 05/28/2012 04:32 PM, Paul Belanger wrote: On 12-05-25 03:58 PM, Monty Taylor wrote: Hey guys! We just finished rolling out the first in a sequence of upcoming changes to gerrit and jenkins based on needs described at the design summit. We now have the basic jobs for all of the projects (except for horizon, because it's slightly different and I want to spend a little more time with it) applied to jenkins based on some scripts and some yaml files that are in a git repo. This means that anybody could conceivably do some hacking and submit a change to gerrit, instead of the current status quo which is that you have to be a jenkins admin to touch anything. If you want to look at it, it's all in this dir: https://github.com/openstack/openstack-ci-puppet/tree/master/modules/jenkins_jobs/files What was the reason for moving these files directly into puppet and not in a separate git repo? I'm surprise they are not actually packaged to be honest. WELL... a couple of things. First of all, this is stab one, and as we add more openstack projects and jobs we keep finding more features, etc. that we need. It seemed like just doing it directly in one place at the start while we're rapidly iterating on it was less painful. However, as it solidifies, I'm hoping we can have a thing that is the jenkins job filler that can be installed, and then the _config_ of that that's specific to a project is something that puppet can manage. So let's call it coming-soon. :) We're also still a little specifically openstack oriented at the moment ... but we do want to go back through and re-generalize some things as we get a handle on where we need config bits and whatnot. Additionally, it's grouped/templated, so we've actually got identical jenkins jobs running for all of the projects... which means we can hopefully stop running in to the whole oops, I forgot to update the glance jobs situation. But wait, that's not all ... By popular demand, as part of rolling out those jobs, we have added pre-approval check jobs. We are now running merge checks, pep8 checks and unittest jobs on the patch-uploaded event and reporting the results into the code review so that people can skip code reviewing patches that don't work yet. We're also still running tests post-approval so that we ensure the patch as it is to be merged is still good. We have several more great bits that will be rolling out in the next week or two, in the attempt to streamline the set of things that need review, and also speed up the testing of reviewed things. Happy hacking Nice work! I always enjoy looking to your work and see what you guys are doing in the world of automation. Thanks! ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Work in progress on Openstack provider for Juju
FYI below for those interested in Juju [1]. TL;DR There is work in progress to add an OpenStack API provider to complement our existing set of EC2 and LXC (local dev) providers. -Robbie [1] http://juju.ubuntu.com Original Message Subject: Work in progress on Openstack provider Date: Tue, 29 May 2012 15:57:21 +0100 From: Martin Packman martin.pack...@canonical.com To: juju j...@lists.ubuntu.com A couple of months ago to help myself better understand what juju needed from a cloud api, I hacked together most of an Openstack provider for juju. There's now interest in getting such a thing merged, so I'm currently looking at filling in the gaps and doing a tidy up. For the curious, you can branch the code and have a poke around: https://code.launchpad.net/~gz/juju/openstack_provider This is not production quality code, so I would not recommend testing it against real Openstack deployments yet unless you're comfortable cleaning up manually when it breaks. That said, any comments and suggestions are welcome. Martin -- Juju mailing list j...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju ___ 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] cfg usage - option registration, global objects
On Tue, May 29, 2012 at 4:04 AM, Mark McLoughlin mar...@redhat.com wrote: Hey, I had the chance to discuss the global conf issue with a good number of folks at the design summit and the conclusion I came away with was that opinions range from meh, it's fairly inelegant but I don't care much either way to I actually like the simplicity to we use global conf, it works and we're not changing. Indeed, at the common configuration patterns, there was very little in the way of opinion expressed at all: http://etherpad.openstack.org/FolsomCommonConfigPatterns Given that my goal here is to establish a common pattern used by all projects, that both Nova and Keystone uses global conf and there isn't a huge amount of interest in moving away from it, I'm proposing adding support for it to openstack-common: https://blueprints.launchpad.net/openstack-common/+spec/cfg-global-object Adopting this pattern across all projects will actually help openstack-common more generally. For example, Russell is moving the RPC code into openstack-common and it has a bunch of configuration options. If it can assume a global configuration object, things become much easier. Though not a fan of global objects, I've used (and still do use) them to simplify things. 99% of my usage of them in other projects are for configuration, as one might expect. I've avoided this in the past through passing parameters, but that often ends up quite messy and rather cumbersome to trace when debugging. More often than not, even when passed, configuration ends up getting used in contexts that are almost global anyway. If I do use a global object, I am deeply loathe to do it without the following: * ample documentation - how to use it, when not to use it, what one needs to do first, etc. * an API for it - no direct use of an object itself I have used zope.components to address the last point (the first one being addressed by good discipline ;-) ). It's simple to use: from zope.component import getGlobalSiteManager, getUtility from zope.interface import Interface class IConfig(Interface): A marker interface for configuration instances. gsm = getGlobalSiteManager() gsm.registerUtility(some_config_object, IConfig) That's done once, often in the __init__.py of a subpackage. All child modules and/or subpackages should need that configuration to be declared. Any code that doesn't need such configuration should be in a sibling (or higher) subpackage. Any time you need the config object: config = getUtility(IConfig) Note that you can register any object using this approach (including imported modules). The use of a marker interface may seem like overkill, but it provides a very natural place for documentation. Also, I usually wrap these calls in convenience functions in my projects, making use as simple, self-documenting, and maintainable as possible. More benefits to this approach (and why I chose to use it): I've got several projects (non-OpenStack) that have one or more other projects as their base -- the base project defines a configuration setup that is used in part or completely by the projects which depend upon it. zope.components let's me use a global registry to look up a config by interface, and this means that as long as a child project registers its config before the parent/base project code does, the base project code will be referencing the child projects configs. This does require strong import discipline, and careful subpackage organization, but I've found it a wonderful compromise for the global configuration problem. Note that the Pyramid project also uses the zope.components capabilities for configuration registry, so you might want to check out their code for potential use-cases. Hope this is helpful, d I've posted patches to openstack-common, Nova, Glance and Keystone: https://review.openstack.org/#/q/status:open+branch:master+topic:bp/cfg-global-object,n,z Cheers, Mark. On Tue, 2012-03-06 at 10:10 +, Mark McLoughlin wrote: Hey, The original cfg design[1] assumed certain usage patterns that I hoped would be adopted by all projects using it. In gerrit, we're debating a set of patch to make keystone use these patterns: https://review.openstack.org/4547 I thought it was best to move some of that discussion here since I'm hoping we can get some rough consensus across projects. I really think it will be beneficial if we can share common idioms and patterns across projects, rather than just using the same library in different ways. [snip] Thread archived here: https://lists.launchpad.net/openstack/msg08329.html ___ 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 :
Re: [Openstack] Fwd: Nodejs in horizon
Without rehashing backstory which is available in public archives of this thread, while node is currently on the table for LESS it also may play a role in future needs as well. As for your link, yes there are LESS compilers in other languages (there's even a nascent one in Python that's very much not ready for prime time) but requiring PHP or any other language besides Python opens a similar can of worms, and PHP gets us nowhere on any other fronts. /me refrains from any other comments about PHP. Moreover, the canonical LESS compiler which is the best supported and most stable is the main one written for node.js. Unless there were a 100% working Python version I see no reason not to favor the real LESS compiler. All the best, - Gabriel On May 29, 2012, at 1:00 AM, Matthias Runge mru...@matthias-runge.de wrote: On 28/05/12 16:21, Thierry Carrez wrote: John Postlethwait wrote: Sorry if I've missed anything below, this thread has become rather fragmented and messy (at least in my email clients) but I will try to address the main points I have seen so far: Sorry, if I jump in late in this thread, I may have skipped some basics. If I get it right, nodejs is just required to compile LESS to css, right? There is at least one alternative without requiring nodejs: https://github.com/leafo/lessphp -- Matthias Runge mru...@matthias-runge.de ___ 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] [metering] delta vs. cumulative meters
On 05/29/2012 05:42 PM, Doug Hellmann wrote: IIRC, the meters discussed in the wiki [1] are supposed to show delta values (usage since the last time an event was generated), although the Alternate Gauge Design section discusses cumulative meters instead. The libvirt pollsters we have now produce cumulative data, and it might be complicated and error-prone to change them to compute the deltas internally before generating events. On the other hand, some of the other counters may be more complicated to generate as cumulative values. Rather than taking an either/or approach, I propose we document for each counter whether it uses the delta or cumulative approach. The API server can ask the meter plugin for that piece of information when calculating the aggregate value so that the caller does not have to keep track of the rules for each meter. I tend to prefer using a gauge and I agree that documenting what was preferred (gauge or delta) for a given meter / counter is enough. My 2ct ;-) -- Loïc Dachary Chief Research Officer // eNovance labs http://labs.enovance.com // ✉ l...@enovance.com ☎ +33 1 49 70 99 82 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova-compute doesn't start on reboot, only manually
On 05/28/2012 01:21 PM, Clint Byrum wrote: Looks to me that you need to make sure the other side of that RPC connection is up before nova-compute. I am not familiar with the specifics of what Nova needs at startup, but I'd guess this is nova-api or keystone. Thats a pretty easy thing to do in a single system (just mess with the upstart jobs or init scripts) but across multiple systems, you'll need some kind of orchestration layer, and even then modeling the dependencies on the network with some other tool seems like something just begging to break. In this case, it's nova-compute expecting nova-network to be up and running when it starts up. This also causes a problem when restarting all of the services at the same time, as seen here: https://bugs.launchpad.net/nova/+bug/999698 Instead, the timeout should just be multiple minutes during startup, and the services should all be able to start in parallel if they are on the same box. I always think of one of those HP EcoPOD that is pre-installed with everything you need for OpenStack, and just shipped and then turned on. You could spend a lot of time trying to get that order just right, or you could just have everything extend their timeouts and get as far as they can without contact with the other services. nova-compute doesn't *know* that the other side is in error, it just knows that it is not responding. This is not a problem with nova-compute, so why should nova-compute fail so quickly? One could even argue that nova-compute should wait *forever* for the other side. From an ops standpoint, they're both down, so why make the operations team take two actions when the actual broken service recovers? The problem is that since nova-network isn't up, the request gets lost. nova-compute is sitting there waiting for a response to a message that was never even received most likely. It's also possible that nova-network received the message but the service stopped before it responded (but that is less likely, I think). The message queues get created by the consumer of messages in nova. So, in this case, nova-network creates the queue. Some possible solutions: 1) We could adjust this code path to just loop around and try again if it hits a timeout. We could make the timeout much shorter than the default, to make recover quicker. The downside would be that we're fixing a single place, when this issue could pop up elsewhere. 2) We could make it so the sender creates the queue if it doesn't exist. This is good because it covers all cases. The bad thing is that we would not be able to set the queue to be auto-deleted in this case, so we could end up with a leak of unwanted message queues. I'm tempted to just write a patch that does #1 for now to address the immediate issue and then do something better later if we come up with something. -- 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] [Swift] Question about cloudfiles API
On 5/24/2012 4:29 PM, Greg wrote: It is mostly the likely the self-signed certificate issue you suspected. Java (and other languages) are pretty notorious for rejecting such unless you configure them just right. I haven't worked with Java in 10 years, so my knowledge of how to fix that is pretty useless, hopefully another will speak up and help. You probably had to use -k with curl right? That would confirm the self-signed issue. I was using the curl command from the howto, I can confirm that it has -k. Just as a note, the SSL capabilities for the Swift proxy server are truly for basic testing only. You might want to start with non-SSL and then lock it down after you get things working otherwise. It took a few tries to figure out everything, but I finally got it working with SSL turned off. I will look at an SSL terminating load balancer for production. Thanks, Shawn ___ 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] [metering] delta vs. cumulative meters
Do we want a history of deltas or just last delta and leave the history to UI implementers? On Tue, May 29, 2012 at 9:30 AM, Loic Dachary l...@enovance.com wrote: On 05/29/2012 05:42 PM, Doug Hellmann wrote: IIRC, the meters discussed in the wiki [1] are supposed to show delta values (usage since the last time an event was generated), although the Alternate Gauge Design section discusses cumulative meters instead. The libvirt pollsters we have now produce cumulative data, and it might be complicated and error-prone to change them to compute the deltas internally before generating events. On the other hand, some of the other counters may be more complicated to generate as cumulative values. Rather than taking an either/or approach, I propose we document for each counter whether it uses the delta or cumulative approach. The API server can ask the meter plugin for that piece of information when calculating the aggregate value so that the caller does not have to keep track of the rules for each meter. I tend to prefer using a gauge and I agree that documenting what was preferred (gauge or delta) for a given meter / counter is enough. My 2ct ;-) -- Loïc Dachary Chief Research Officer // eNovance labs http://labs.enovance.com // ✉ l...@enovance.com ☎ +33 1 49 70 99 82 ___ 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] Identity API v3 - Why allow multi-tenant users?
One of the major complication I see in the API is that users can be associated with multiple tenants. What is the benefit of this? What functionality would be lost if a human user merely had to use a different account with each tenant? There are numerous issues with multi-tenant users. For example, if a user is associated with multiple tenants, who resets the user's password? ___ 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] Fwd: Nodejs in horizon
On 05/29/2012 12:29 PM, Gabriel Hurley wrote: Without rehashing backstory which is available in public archives of this thread, while node is currently on the table for LESS it also may play a role in future needs as well. As for your link, yes there are LESS compilers in other languages (there's even a nascent one in Python that's very much not ready for prime time) but requiring PHP or any other language besides Python opens a similar can of worms, and PHP gets us nowhere on any other fronts. /me refrains from any other comments about PHP. Moreover, the canonical LESS compiler which is the best supported and most stable is the main one written for node.js. Unless there were a 100% working Python version I see no reason not to favor the real LESS compiler. All the best, For LESS, it think it is fine to use even server side Javascript. The CSS should be compiled at RPM/DEB build time, and not at run time for live deployments, so that is a bit of a non-issue. I'd also be fine with using the client side LESS implementation, especially if we want to use the same implementation at development and live deployment time, but I can understand if there are issues with doing this. Node.js is a whole different server side technology, and that should not be implemented at this time. - Gabriel On May 29, 2012, at 1:00 AM, Matthias Rungemru...@matthias-runge.de wrote: On 28/05/12 16:21, Thierry Carrez wrote: John Postlethwait wrote: Sorry if I've missed anything below, this thread has become rather fragmented and messy (at least in my email clients) but I will try to address the main points I have seen so far: Sorry, if I jump in late in this thread, I may have skipped some basics. If I get it right, nodejs is just required to compile LESS to css, right? There is at least one alternative without requiring nodejs: https://github.com/leafo/lessphp -- Matthias Rungemru...@matthias-runge.de ___ 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
Re: [Openstack] Keystone service catalogue has non-core services?
Perhaps the Nova folks may know the answer to this question... Are the ec2 and nova-volume services part of the core services now? Or are they extension services? Thanks, Liem From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf Of Nguyen, Liem Manh Sent: Friday, May 18, 2012 9:52 AM To: openstack@lists.launchpad.net Subject: [Openstack] Keystone service catalogue has non-core services? Hi Stackers, I ran the sample_data.sh script in Keystone and saw that we have populated a few more services, such as ec2, dashboard and nova-volume. Are these meant to be core services or extension services? The definition of core services is defined here: https://github.com/openstack/identity-api/blob/3d2e8a470733979b792d04bcfe3745731befbe8d/openstack-identity-api/src/docbkx/common/xsd/services.xsd Extension services should be in the format of extension prefix:service type Thanks, Liem ___ 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] Fwd: [Infra] administration of new mailinglists
Duncan McGreggor dun...@dreamhost.com writes: And for announce: who gets the right to post to it ? Or rather, who gets to moderate the posts to it ? PPB ? PTL/relmgr ? Any volunteer ? Release announcements, and security updates should go to the announce list, so it seems reasonable to allow the release and security teams to moderate it. You'll have to work very hard to convince me that an announce list is worth the trouble :) 'Tradition' is not a good argument. Someone pointed out that since the security announcements _haven't_ been going to the announce list, but the main mailing list instead, that they are concerned that people may have missed them. That seems like a very important and valid concern to me. I believe that operators, distributors, and news organizations who aren't 100% focused on OpenStack but still have an interest would appreciate a low-volume announcement list. When I'm responsible for running instances of several free software projects, I like subscribe to the announce list of all of them, even if I'm not subscribed to the -users or -dev list. To punt and say people will see it on G+ or Twitter or whatever (as stated elsewhere in this thread) isn't good enough for a project of this size. What user should they follow? What hashtag should they search for? Fundamentally, the same problems will show up -- either search for #openstack and run the risk of having to read every tweet about someone who loves #openstack, or follow @openstack and, well, from the looks of it, have the same problem. Who gets to post from the @openstack account? Is the answer to that any better than what we could do with the announce list? Security updates frequently don't fit within 140 characters. First of all, it's not clear to me *who* would need to send out announcements. Can somebody start from there? Release team. Security team. I'll start enumerating why I don't think such list is needed by community managers: - more lists, more policies, more complexity for newcomers, things that they need to learn. - more lists, more policies, more complexity to manage (moderators, spam masters, etc) The announce, user, developer triplicate is widely used and understood. Very few people need to learn something new, and those that do will be well served by learning it. - the announce list has not been used for over 8 months, nobody noticed The announce list is not listed here: http://wiki.openstack.org/MailingLists As far as I'm concerned, that means we don't have an announce list. No wonder no one knew about it or used it. We have releases in production now, people have a more pressing need for seeing these announcements, and we now have a need to make them. This is a good time to start using it properly. - multiplying contact points for people increases the need for cross-posting, more messages Most decent mail providers have Message-ID based duplicate suppression; cross-posting isn't the issue it used to be. Or don't cross-post. Or subscribe the user list to the announce list. Announce lists are low traffic -- no one is going to be upset at the flood of messages from it. - an announce is fundamentally a one-way communication, no need to have 'discussions' around it, mailing list is the wrong tool *today* (it made sense in the 90s) An announce list is a great tool for one-way communication. It's easy to configure it to discard unsolicited replies. There's no rule that says you have to reply to every email you receive. Email is a useful way to receive pertinent information. As long as the rest of the project uses mailing lists at all, it's not a burden to have an announcement list. - an announce sent to a mailman list is fundamentally shouting in the wind: there might be people listening, you'll never know if they heard something. A *segmented* (developers, operators, business folks) newsletter is the best way to send out announcements. I disagree with that; people who need to see information of the highest importance from the project -- releases and security updates -- will self-select only to subscribe to the announce mailing list, and if we start using it properly, they will know they are getting the information they need. Without that structure in place, the sheer amount of information (newsletters, twitter feeds, blog posts, G+ posts, general purpose mailing list) a person who just wants to know when they should upgrade is quite daunting, and in my mind, much more like shouting in the wind. I believe we should at least have the common set of three mailing lists (announce, user/operator, dev) and have a web page that lists them. -Jim ___ 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] Identity API v3 - Why allow multi-tenant users?
Hi Caitlin, A user is able to be associated with multiple tenants in the current API as well - this API just attempt to make is significantly more clear what you're asking for and what you're getting back. It was one of the earliest requests and requirements of the auth system. For the back-ends of Keystone that allow resetting of passwords, it would generally be an administrator of Keystone (as it is today) that would be required to reset a user's password, but with the additional domain model, it's possible to expand that a bit if a local implementation wanted to allow a domain admin to reset a user's password as well. -joe On May 29, 2012, at 10:18 AM, Caitlin Bestler wrote: One of the major complication I see in the API is that users can be associated with multiple tenants. What is the benefit of this? What functionality would be lost if a human user merely had to use a different account with each tenant? There are numerous issues with multi-tenant users. For example, if a user is associated with multiple tenants, who resets the user’s password? ___ 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] centos 6 images
Thanks much, feel free to submit some patches, I'll work on the wiki in my off-time, since we have people here making these images for the openstack deployment we are doing and I guess they want me working on other stuff at work, haha. On 5/25/12 7:24 PM, Jason Ford ja...@chatinara.com wrote: Joshua, First off, thanks for getting something together. I think you have a bug in your spec file at line 1. After that I got it to build after renaming some directories. I am in the process of testing this out now in a devstack install. I will give you feedback when I get it. jason - Original Message - From: Joshua Harlow harlo...@yahoo-inc.com To: Jason Ford ja...@chatinara.com Cc: Fedora Cloud SIG cl...@lists.fedoraproject.org, Andy Grimm agr...@gmail.com, openstack openstack@lists.launchpad.net, Pádraig Brady p...@draigbrady.com Sent: Thursday, May 24, 2012 9:18:06 PM Subject: Re: [Openstack] centos 6 images Starting this @ https://github.com/yahoo/Openstack-Condense/wiki/How-To-Use-This I'll try to finish it up soon :-P On 5/22/12 6:33 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: Let me write something up that should explain this. Its not that hard. On 5/22/12 6:31 PM, Jason Ford ja...@chatinara.com wrote: Joshua, Do you have some basic instructions on how to push this into an image and configure it? Any information about what you have here would be great! jason - Original Message - From: Joshua Harlow harlo...@yahoo-inc.com To: Jason ja...@chatinara.com , Pádraig Brady p...@draigbrady.com Cc: Fedora Cloud SIG cl...@lists.fedoraproject.org , Andy Grimm agr...@gmail.com , openstack openstack@lists.launchpad.net Sent: Tuesday, May 22, 2012 1:49:06 PM Subject: Re: [Openstack] centos 6 images U might want to check out, https://github.com/yahoo/Openstack-Condense Its a stripped down/cleaned up/... version of cloud-init that I know works on RHEL6. I tried to improve the following: 1. Code cleanliness (constants being uppercase, paths using os.path.join and so-on) 2. Stripping out some of the odd handlers (byobu, right-scale and such) 3. Improving logging by a lot (so that u can debug this thing) 4. Making what handlers I left work on RH and ubuntu... Might be useful if u want to try it. I know just from doing the above work that the cloud-init for ubuntu, requires some work to get it to work on RH, but not tons, eventually I hope that I can merge this back, but for now its forked so that I could focus on getting it working and cleaned up, rather than pushing code through some review process via launchpad and such (ie the slow as molasses approach). On 5/22/12 10:05 AM, Jason ja...@chatinara.com wrote: I will give these a shot later today and reply with feedback. Thanks for looking into this! Jason On May 22, 2012, at 11:44 AM, Pádraig Brady p...@draigbrady.com wrote: On 05/22/2012 03:39 PM, Andy Grimm wrote: On Tue, May 22, 2012 at 9:38 AM, Pádraig Brady p...@draigbrady.com wrote: On 05/22/2012 04:07 AM, Jason Ford wrote: I am trying to put together an image for centos 6 that works like cloud-init on ubuntu does. Currently I have ssh keys getting imported but having some problems getting the disk to dynamically resize to the flavor template as well as the hostname set in horizon to be pushed into the image. Does anyone have any howtos or suggestions on how to get this done? Is there cloud-init for centos just like ubuntu? I would also be interested in how to do this with debian as well. Well I notice there is no cloud-init package for EPEL. I took a quick stab at it here: http://pbrady.fedorapeople.org/cloud-init-el6/ I've already responded in IRC, but it wouldn't hurt to have a response in the mail archive. In short, the reason there isn't already a cloud-init for EL6 (or EL5, for that matter) is that upstream has been using python 2.7-only calls for a while now. In particular, a couple of calls to subprocess.check_output need to be replaced, and I think there are a few other issues as well. I don't think it's a huge amount of work to make it functional, but it hasn't been high on anyone's list. It would be cool if you have time to fix / test it, though. Ok I've fixed the check_output calls at the above URL. 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 ___ 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] [metering] delta vs. cumulative meters
On Tue, May 29, 2012 at 12:30 PM, Loic Dachary l...@enovance.com wrote: On 05/29/2012 05:42 PM, Doug Hellmann wrote: IIRC, the meters discussed in the wiki [1] are supposed to show delta values (usage since the last time an event was generated), although the Alternate Gauge Design section discusses cumulative meters instead. The libvirt pollsters we have now produce cumulative data, and it might be complicated and error-prone to change them to compute the deltas internally before generating events. On the other hand, some of the other counters may be more complicated to generate as cumulative values. Rather than taking an either/or approach, I propose we document for each counter whether it uses the delta or cumulative approach. The API server can ask the meter plugin for that piece of information when calculating the aggregate value so that the caller does not have to keep track of the rules for each meter. I tend to prefer using a gauge and I agree that documenting what was preferred (gauge or delta) for a given meter / counter is enough. Just to be clear, by gauge do you mean the cumulative form of the counter? My 2ct ;-) -- Loïc Dachary Chief Research Officer // eNovance labs http://labs.enovance.com // ✉ l...@enovance.com ☎ +33 1 49 70 99 82 ___ 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] [metering] delta vs. cumulative meters
On Tue, May 29, 2012 at 1:10 PM, Matt Joyce matt.jo...@cloudscaling.comwrote: Do we want a history of deltas or just last delta and leave the history to UI implementers? The collector should record everything and we should make the query API work so the caller can get what they want out of the datastore. On Tue, May 29, 2012 at 9:30 AM, Loic Dachary l...@enovance.com wrote: On 05/29/2012 05:42 PM, Doug Hellmann wrote: IIRC, the meters discussed in the wiki [1] are supposed to show delta values (usage since the last time an event was generated), although the Alternate Gauge Design section discusses cumulative meters instead. The libvirt pollsters we have now produce cumulative data, and it might be complicated and error-prone to change them to compute the deltas internally before generating events. On the other hand, some of the other counters may be more complicated to generate as cumulative values. Rather than taking an either/or approach, I propose we document for each counter whether it uses the delta or cumulative approach. The API server can ask the meter plugin for that piece of information when calculating the aggregate value so that the caller does not have to keep track of the rules for each meter. I tend to prefer using a gauge and I agree that documenting what was preferred (gauge or delta) for a given meter / counter is enough. My 2ct ;-) -- Loïc Dachary Chief Research Officer // eNovance labs http://labs.enovance.com // ✉ l...@enovance.com ☎ +33 1 49 70 99 82 ___ 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
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
Allowing a user to be associated with multiple tenants (a.k.a. projects) is what we have currently, and it works reasonably well. It has not produced a significantly more complicated system. I would argue the flipside of your point, which is that the admin permission system in keystone is particularly convoluted and not clearly scoped. The lack of differentiation between the abilities of a project admin vs. a system admin, etc the fact that being granted admin permissions on *any* project gives you admin permissions for *all* of your Openstack installation... There are some very odd issues in the details of that side of the equation. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Caitlin Bestler Sent: Tuesday, May 29, 2012 10:18 AM To: openstack@lists.launchpad.net Subject: [Openstack] Identity API v3 - Why allow multi-tenant users? One of the major complication I see in the API is that users can be associated with multiple tenants. What is the benefit of this? What functionality would be lost if a human user merely had to use a different account with each tenant? There are numerous issues with multi-tenant users. For example, if a user is associated with multiple tenants, who resets the user's password? ___ 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] Identity API v3 - Why allow multi-tenant users?
On Tue, 2012-05-29 at 17:18 +, Caitlin Bestler wrote: One of the major complication I see in the API is that users can be associated with multiple tenants. What is the benefit of this? What functionality would be lost if a human user merely had to use a different account with each tenant? There are numerous issues with multi-tenant users. For example, if a user is associated with multiple tenants, who resets the user’s password? The use case that immediately springs to mind is that of a consultant. A consultant may be working for several clients that all happen to use one OpenStack-powered provider, and it would be handy for that consultant to only have to worry about a single set of login credentials, but still be able to access the relevant parts of all the tenants for which he or she is working. I could imagine several other somewhat similar scenarios, such as the value-added reseller; having multiple tenants allows them to ensure the proper client is billed the proper amount, while still being able to perform whatever their value-add is. -- Kevin L. Mitchell kevin.mitch...@rackspace.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] Caimito - WebDAV frontend for OpenStack Swift CloudStorage
Hi Endre, Caimito is now on github: https://github.com/ngasiproj/caimito Cheers Re: [Openstack] Caimito - WebDAV frontend for OpenStack Swift CloudStorage From: Endre KarlsonAdd to Contacts Sent: Mon, May 28, 2012 at 3:27 pm To: openstack@lists.launchpad.net Would it be possible for you to put this on github? Endre. 2012/5/28 Gabe Wong gabri...@ngasi.com Hi all, My company has developed an open-source WebDAV server for Swift. It has been tested with Softlayer's Object Storage. Feel free to download. I would like to hear people's feedback on how it works on other Swift installations. Download Caimito here: [http://caimito.ngasi.com] http://caimito.ngasi.com Cheers. ___ Mailing list: [https://launchpad.net/%7Eopenstack] https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : [https://launchpad.net/%7Eopenstack] https://launchpad.net/~openstack More help : [https://help.launchpad.net/ListHelp] 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] [metering] Changes to the ceilometer Jenkins job
Hi Julien, On 29/05/12 16:46, Julien Danjou wrote: We noticed that currently, on Stackforge, the ceilometer project has only one Jenkins job, checking that the merge occurs correctly. We'd like to add jobs to run unit tests, pep8, etc… I took a look at the openstack-ci-puppet repo, but I'm not sure of the changes, so I prefer to ask here for someone that understand this to help. From what I see, it's likely we would like to use the default python_jobs template. If anything is missing on our side to use the standard set of checks, we'll do what is necessary to be able to use them. :) Within an hour of this landing it will be done automatically for you: https://review.openstack.org/7884 We can then see if there are any jobs not working right for you. Please let me know if there are any problems. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ ___ 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] [metering] Changes to the ceilometer Jenkins job
Hi Julien, On 29/05/12 19:12, Andrew Hutchings wrote: Within an hour of this landing it will be done automatically for you: https://review.openstack.org/7884 We can then see if there are any jobs not working right for you. Please let me know if there are any problems. It is also worth noting that Stackforge now has an IRC bot for gerrit in the #stackforge-dev Freenode channel. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ ___ 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 service catalogue has non-core services?
Hey Liem, We had a brief conversation about this at the summit. Ec2 and volume are core services not extension services -- this was described in a wiki somewhere. Carlos has gone through the contracts cleaned them up and updated them to reflect reality -- and they include this particular change. His changes are still pending review: https://review.openstack.org/#/c/7774/ That said, the rule of having extension services use extension prefix:service type still applies. -jOrGe W. On May 29, 2012, at 12:25 PM, Nguyen, Liem Manh wrote: Perhaps the Nova folks may know the answer to this question… Are the “ec2” and “nova-volume” services part of the core services now? Or are they extension services? Thanks, Liem From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.netmailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf Of Nguyen, Liem Manh Sent: Friday, May 18, 2012 9:52 AM To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Keystone service catalogue has non-core services? Hi Stackers, I ran the sample_data.sh script in Keystone and saw that we have populated a few more services, such as ec2, dashboard and nova-volume. Are these meant to be “core” services or extension services? The definition of “core” services is defined here: https://github.com/openstack/identity-api/blob/3d2e8a470733979b792d04bcfe3745731befbe8d/openstack-identity-api/src/docbkx/common/xsd/services.xsd Extension services should be in the format of extension prefix:service type Thanks, Liem ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: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] Identity API v3 - Why allow multi-tenant users?
In the research environment, we have frequent cases where a user is associated with multiple tenants. For example, when you are finishing work on a previous project but are mainly working on the new one. As we move towards domain/tenant/user, we need to ensure that the tools support multi-tenant per user. Correct accounting is critical. This does require extra code but it is relevant given the use cases. Tim Bell CERN From: openstack-bounces+tim.bell=cern...@lists.launchpad.net [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] On Behalf Of Caitlin Bestler Sent: 29 May 2012 19:18 To: openstack@lists.launchpad.net Subject: [Openstack] Identity API v3 - Why allow multi-tenant users? One of the major complication I see in the API is that users can be associated with multiple tenants. What is the benefit of this? What functionality would be lost if a human user merely had to use a different account with each tenant? There are numerous issues with multi-tenant users. For example, if a user is associated with multiple tenants, who resets the user's password? smime.p7s Description: S/MIME cryptographic signature ___ 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] Identity API v3 - Why allow multi-tenant users?
Tim Bell wrote: ➢ In the research environment, we have frequent cases where a user is associated with multiple tenants. For example, when you are finishing work on a previous project but are mainly working on the new one. As we move towards domain/tenant/user, we need to ensure that the tools support multi-tenant per user. Correct accounting is critical. This does require extra code but it is relevant given the use cases. What you are describing strikes me as a single tenant with multiple projects. It is similar to a corporate environment with multiple departments. I am seeing a major problem here when the tenants are truly separate and the only possible administrator in common is the service provider. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Nova] Instances which use flavors with disk space fail to spawn
Leander, I would submit a bug about this. The error message is cryptic
(to say the least!) and I think it would be better if the scheduler
determined if the flavor requested has a memory request greater than the
total amount available on the server! I'm a bit disappointed that the
request even went through to the compute node to build the instance, as
the scheduler *should* already know the memory exceeds the available
memory on the box.
Best,
-jay
On 05/29/2012 11:07 AM, Leander Bessa Beernaert wrote:
For anyone interested, i've figured out that the instances were not
getting spawned because the amount of memory in the flavor was equal to
the maximum memory available through the underlying hardware.
On Tue, May 29, 2012 at 11:10 AM, Leander Bessa Beernaert
leande...@gmail.com mailto:leande...@gmail.com wrote:
Hello,
I'm unable to boot any image with a flavor that has a disk space
associated with it. It always fails at the spawning state. Below it
the log output of nova-compute:
2012-05-28 16:20:25 ERROR nova.compute.manager
[req-1c725f9c-acae-47c4-b5ae-9ed5d2d9830c
9494d025721c4d7bb28a16fa796f9414
04282e9aff474d2383bb4d4417673e0a] [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] Instance failed to spawn
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] Traceback (most recent
call last):
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] File
/usr/lib/python2.7/dist-packages/nova/compute/manager.py,
line 592, in _spawn
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7]
self._legacy_nw_info(network_info), block_device_info)
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] File
/usr/lib/python2.7/dist-packages/nova/exception.py, line
114, in wrapped
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] return f(*args, **kw)
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py,
line 922, in spawn
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7]
self._create_new_domain(xml)
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] File
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py,
line 1575, in _create_new_domain
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7]
domain.createWithFlags(launch_flags)
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] File
/usr/lib/python2.7/dist-packages/libvirt.py, line 581, in
createWithFlags
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] if ret == -1:
raise libvirtError ('virDomainCreateWithFlags() failed',
dom=self)
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] libvirtError: Unable
to read from monitor: Connection reset by peer
2012-05-28 16:20:25 TRACE nova.compute.manager [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7]
2012-05-28 16:20:25 DEBUG nova.compute.manager
[req-1c725f9c-acae-47c4-b5ae-9ed5d2d9830c
9494d025721c4d7bb28a16fa796f9414
04282e9aff474d2383bb4d4417673e0a] [instance:
10d7c8e0-e05b-4e57-b722-dab5771261b7] Deallocating network
for instance from (pid=23518) _deallocate_network
/usr/lib/python2.7/dist-packages/nova/compute/manager.py:616
2012-05-28 16:20:25 DEBUG nova.rpc.amqp
[req-1c725f9c-acae-47c4-b5ae-9ed5d2d9830c
9494d025721c4d7bb28a16fa796f9414
04282e9aff474d2383bb4d4417673e0a] Making asynchronous cast
on network... from (pid=23518) cast
/usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:346
2012-05-28 16:20:26 ERROR nova.rpc.amqp
[req-1c725f9c-acae-47c4-b5ae-9ed5d2d9830c
9494d025721c4d7bb28a16fa796f9414
04282e9aff474d2383bb4d4417673e0a] Exception during message
handling
2012-05-28 16:20:26 TRACE nova.rpc.amqp Traceback (most
recent call last):
2012-05-28
Re: [Openstack] Fwd: [Infra] administration of new mailinglists
James E. Blair wrote: I believe we should at least have the common set of three mailing lists (announce, user/operator, dev) and have a web page that lists them. +1 We need an official channel for reference information about, at the very least, milestones/releases and security updates. We also need it for major community events (think announce the next design summit or upcoming elections). So far we (ab)used the general mailing-list for that, and I think the amount of traffic now makes it an inappropriate channel for reference information. We never used the existing -announce list because it was never exposed as the medium for reference information. An -announce list still sounds like the best way to achieve that. You can have direct posters like security or release team. You can have a moderation team so that anyone can potentially post reference information. That doesn't mean we can't use other channels like Twitter, blogs, G+, newsletter or whatever is cool these days, but none of those are actually a reference channel, so they are complementary rather than a replacement. If we go for -announce and -dev, I think we should use the classic names and move the openstack@lists.launchpad.net to openstack-us...@lists.openstack.org. Then it would make sense to merge openstack-operators into it. Regards, -- 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] Keystone issue?
Has this issue been reported as a bug yet?
Everett
On Thu, May 17, 2012 at 10:21 PM, Luis Gervaso l...@woorea.es wrote:
To reproduce:
First delete a role that is assigned to a tenant-user pair
If you delete tenant-user-role first, and then delete the role all works
fine
Regards
On Fri, May 18, 2012 at 4:33 AM, Luis Gervaso l...@woorea.es wrote:
Hi,
Working on stable/essex:
When I delete a user-tenant-role keystone continues returning null for
the deleted roles
In the example I have deleted KeystoneAdmin and KeystoneServiceAdmin
roles from a
devstack installation and then added them again as part of my tests
This is the result,
{roles: [{id: 5172006c48c942c499beb79740a8021a, name: admin},
*null,
null*, {id: 5adca868452746388f5d526db1bfcf9c, name:
KeystoneAdmin}, {id: fea9871c0e2d492da75c2d4a73c7269b, name:
KeystoneServiceAdmin}]}
which causes every nova api call become unusable :
error on auth_token.py [line 398]
TypeError: 'NoneType' object has no attribute '__getitem__'
I think this issue is related to metadata table where roles are not
updated
when a role is deleted
--
---
Luis Alberto Gervaso Martin
Woorea Solutions, S.L
CEO CTO
mobile: (+34) 627983344
luis@ luis.gerv...@gmail.comwoorea.es
--
---
Luis Alberto Gervaso Martin
Woorea Solutions, S.L
CEO CTO
mobile: (+34) 627983344
luis@ luis.gerv...@gmail.comwoorea.es
___
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] File injection support
https://help.ubuntu.com/community/CloudInit Might want to check this little beastie out. Folks using kvm seem to end up here for certain use cases. -Matt On Tue, May 29, 2012 at 11:35 AM, Nicolae Paladi n.pal...@gmail.com wrote: Hello, I am looking for more information about file injection support in OpenStack and find it increasingly inconsistent and incomplete. I have several questions: * This wiki article (http://wiki.openstack.org/HypervisorSupportMatrix) claims that file injection is supported in XenServer, is NOT supported inn KVM it's not clear about the others. is that still the case? At least there is some mentioning of file injection in the openstack xenserver wiki: http://wiki.openstack.org/XenServer/Development * Is there any guide or man page where file injection is explained? in this use case I would like to inject a file to e.g. /etc/security/.conf at launch time -- is that possible, and if yes how can it be done in the Essex release. * Are there any discussions about the future of file injection? Thanks a lot! /Nico. ___ 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] [metering] delta vs. cumulative meters
On 05/29/2012 07:58 PM, Doug Hellmann wrote: On Tue, May 29, 2012 at 12:30 PM, Loic Dachary l...@enovance.com mailto:l...@enovance.com wrote: On 05/29/2012 05:42 PM, Doug Hellmann wrote: IIRC, the meters discussed in the wiki [1] are supposed to show delta values (usage since the last time an event was generated), although the Alternate Gauge Design section discusses cumulative meters instead. The libvirt pollsters we have now produce cumulative data, and it might be complicated and error-prone to change them to compute the deltas internally before generating events. On the other hand, some of the other counters may be more complicated to generate as cumulative values. Rather than taking an either/or approach, I propose we document for each counter whether it uses the delta or cumulative approach. The API server can ask the meter plugin for that piece of information when calculating the aggregate value so that the caller does not have to keep track of the rules for each meter. I tend to prefer using a gauge and I agree that documenting what was preferred (gauge or delta) for a given meter / counter is enough. Just to be clear, by gauge do you mean the cumulative form of the counter? Yes, I do ;-) ___ 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] Fwd: [Infra] administration of new mailinglists
On Tue 29 May 2012 10:36:05 AM PDT, James E. Blair wrote: Someone pointed out that since the security announcements _haven't_ been going to the announce list, but the main mailing list instead, that they are concerned that people may have missed them. That seems like a very important and valid concern to me. Same here, I'm concerned that important information is sent out through the wrong channel, not reaching the relevant people. To punt and say people will see it on G+ or Twitter or whatever (as stated elsewhere in this thread) isn't good enough for a project of this size. What user should they follow? What hashtag should they search for? Fundamentally, the same problems will show up That's because, fundamentally, sending out a message to the relevant people is a complex problem. Even if you setup the announce- list, you still have to make sure that people will subscribe to it, and make sure the announcers will use it properly. I assumed that since the list existed formally but nobody cared to use it, it was not needed. First of all, it's not clear to me *who* would need to send out announcements. Can somebody start from there? Release team. Security team. Sounds good enough for me. If those teams want to take care of it, I don't have a problem, as long as they're happy with such a tool. The announce list is not listed here: http://wiki.openstack.org/MailingLists As far as I'm concerned, that means we don't have an announce list. No wonder no one knew about it or used it. I think I removed it from there a couple of weeks ago while rethinking the whole set of mlists. It was there together with other unused lists, I assumed nobody was interested in it. Feel free to add it back and hand the keys to release and security teams. I disagree with that; people who need to see information of the highest importance from the project -- releases and security updates -- will self-select only to subscribe to the announce mailing list, and if we start using it properly, they will know they are getting the information they need. We clearly have two different use cases in mind. Since now it's clear that the announce list is for the release and security team, I remove my objection to have a list for announcements. thanks /stef ___ 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] Signed Tokens Proof-of-concept
I've gotten The PKI signed tokens code working, although not ready for submission. Still needs some cleanup. https://github.com/admiyo/keystone/tree/signed-tokens-2 Commit is here: https://github.com/admiyo/keystone/commit/e566167f45d71f4e3e6cec7524e7097a86d68b80 Feel free to provide line level comments. Configuration is still a little wonky. auth_token inherits the past Config from the service that calls it. Thus, sign and verify are hacked to use different conf systems. I don't think these config values should be in past, but rather in the good config files for the various services. I'd also like to provide decent defaults for them. Guang and Liem talked me out of trying to piggy back on the SSL config options, even though the CA certs will be the same, and the Signing keys can be the same. We both agree that the certs should not be the same. I can explain in depth why this is if anyone really cares. This puts a new dependency into the system: The OpenSSL binary. Fropm what I can tell, the only safe way to call OpenSSL is from the POpen API, as Eventlet wraps it. This should work equally as well from HTTPD. The signing is done without using any interim files or directories: input and output are using the standard file descriptors. I think this is an elegant solution. Rafaduran had a good point about memory usage for KVS. Since the tokens will be roughly 10 times the size they were previously, KVS might be too expensive. An optimization in the future is to drop recording the tokens into a datastore, and merely log them to an audit log. Even Keystone can use the cryptographic approach to validate. I'm going to avoid putting in a revocation mechanism for the first approximation. I'll make sure that token time-out is a well documented config option, and we'll go with the shortest time-frame that we can for default expiry. ___ 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] Fwd: Question about cloudfiles API
On 5/24/2012 7:25 PM, Luis Gervaso wrote: Hi Shawn, You can try with OpenStack Java SDK https://github.com/woorea/openstack-java-sdk https://github.com/woorea/openstack-java-sdk/wiki/Swift-Tutorial Is there a jar I can download and a list of dependencies? That appears to be a source archive, I'm looking for a binary release. Is this API faster than the rackspace cloudfiles API? I am getting terrible performance numbers with cloudfiles. This is in bytes per second, both the proxy and storage networks are gigabit: totalCount: 10024 Max rate: 16290 Median rate: 2859 99th percentile rate: 9126 95th percentile rate: 6673 75th percentile rate: 4266 A similar program using the GridFS API in MongoDB several weeks ago, running on the same server testbed: totalCount: 9050 Max rate: 121353 Median rate: 42377 99th percentile rate: 102912 95th percentile rate: 91223 75th percentile rate: 67423 Thanks, Shawn ___ 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] Fwd: [Infra] administration of new mailinglists
On Tue 29 May 2012 10:36:05 AM PDT, James E. Blair wrote: Someone pointed out that since the security announcements _haven't_ been going to the announce list, but the main mailing list instead, that they are concerned that people may have missed them. That seems like a very important and valid concern to me. Same here, I'm concerned that important information is sent out through the wrong channel, not reaching the relevant people. To punt and say people will see it on G+ or Twitter or whatever (as stated elsewhere in this thread) isn't good enough for a project of this size. What user should they follow? What hashtag should they search for? Fundamentally, the same problems will show up That's because, fundamentally, sending out a message to the relevant people is a complex problem. Even if you setup the announce- list, you still have to make sure that people will subscribe to it, and make sure the announcers will use it properly. I assumed that since the list existed formally but nobody cared to use it, it was not needed. First of all, it's not clear to me *who* would need to send out announcements. Can somebody start from there? Release team. Security team. Sounds good enough for me. If those teams want to take care of it, I don't have a problem, as long as they're happy with such a tool. The announce list is not listed here: http://wiki.openstack.org/MailingLists As far as I'm concerned, that means we don't have an announce list. No wonder no one knew about it or used it. I think I removed it from there a couple of weeks ago while rethinking the whole set of mlists. It was there together with other unused lists, I assumed nobody was interested in it. Feel free to add it back and hand the keys to release and security teams. I disagree with that; people who need to see information of the highest importance from the project -- releases and security updates -- will self-select only to subscribe to the announce mailing list, and if we start using it properly, they will know they are getting the information they need. We clearly have two different use cases in mind. Since now it's clear that the announce list is for the release and security team, I remove my objection to have a list for announcements. thanks /stef ___ 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] Fwd: [Infra] administration of new mailinglists
+1 Simple. And works for most other projects well enough. -Matt On Tue, May 29, 2012 at 1:01 PM, Thierry Carrez thie...@openstack.orgwrote: James E. Blair wrote: I believe we should at least have the common set of three mailing lists (announce, user/operator, dev) and have a web page that lists them. +1 We need an official channel for reference information about, at the very least, milestones/releases and security updates. We also need it for major community events (think announce the next design summit or upcoming elections). So far we (ab)used the general mailing-list for that, and I think the amount of traffic now makes it an inappropriate channel for reference information. We never used the existing -announce list because it was never exposed as the medium for reference information. An -announce list still sounds like the best way to achieve that. You can have direct posters like security or release team. You can have a moderation team so that anyone can potentially post reference information. That doesn't mean we can't use other channels like Twitter, blogs, G+, newsletter or whatever is cool these days, but none of those are actually a reference channel, so they are complementary rather than a replacement. If we go for -announce and -dev, I think we should use the classic names and move the openstack@lists.launchpad.net to openstack-us...@lists.openstack.org. Then it would make sense to merge openstack-operators into it. Regards, -- 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 ___ 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] Identity API v3 - Why allow multi-tenant users?
Terminology: Project == Tenant. They are equivalent in Keystone parlance. What you're referring to as a tenant in that last email is the role a domain might play going forward in Keystone. 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 Caitlin Bestler Sent: Tuesday, May 29, 2012 11:47 AM To: Tim Bell; openstack@lists.launchpad.net Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users? Tim Bell wrote: ➢ In the research environment, we have frequent cases where a user is associated with multiple tenants. For example, when you are finishing work on a previous project but are mainly working on the new one. As we move towards domain/tenant/user, we need to ensure that the tools support multi-tenant per user. Correct accounting is critical. This does require extra code but it is relevant given the use cases. What you are describing strikes me as a single tenant with multiple projects. It is similar to a corporate environment with multiple departments. I am seeing a major problem here when the tenants are truly separate and the only possible administrator in common is the service provider. ___ 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][keystone] V3 API draft
I wanted to throw quotas out there for inclusion in the v3 API. In the
format from the doc.
API Resources
Quota
- resource quotas associated with a tenant
- a tenant may have 0 or more quotas
resource attributes:
- name (unique per tenant)
- value
- id
- url (fully qualified resource URL)
V3 CORE API
Policy?
Quota
The key use cases we need to cover:
- CRUD for quotas
(GET) /tenants/{tenant_id}/quotas == get_quotas
(GET) /tenants/{tenant_id}/quotas/{quota} == get_quota
(PUT) /tenants/{tenant_id}/quotas == create_or_replace_quotas
(DELETE) /tenants/{tenant_id}/quotas == delete_quotas
Quotas may be more applicable to an API extension but I wanted to put this
out there for consideration.
Everett
On Mon, May 21, 2012 at 10:11 AM, Joseph Heck he...@mac.com wrote:
Good morning,
I wanted to announce that we have the first strawman/draft of a V3 API for
Keystone available for comment and feedback. This is an early draft, and I
expect there to be more than one.
https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit
The general theme of this proposal is a broad CRUD based API supporting
authentication and authorization needs in OpenStack. Back-end
implementations of Keystone may not support all components of the API,
hence an API return may be NotImplemented. This is to support Keystone as a
programmatic facade to an deployment’s existing authentication and
authorization system(s).
Themes for changes:
• different style of pagination that I hope will be more effective
for UI work
• consolidate CRUD operations currently in contrib into CORE
• adding a url resource attribute that's the fully qualified
resource location for the keystone service
• flatten the service catalog structure
• added in a domains (collection of tenants)
• restructure role API calls to be specific to user-tenant or
user-domain
• tokens are now very explicit to user+tenant combinations
• new API mechanisms to get tenants associated with a user
• generalized credentials associated with a user/tenant combo (ec2,
pki, ssh keys, etc)
• propose an extended policy-implementation-specific API
If you're interested, please review and provide feedback through the above
Google Doc, or feel free to open broader discussion questions here on the
list.
-joe
___
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] [metering] Changes to the ceilometer Jenkins job
Hi Julien, On 29/05/12 19:12, Andrew Hutchings wrote: If anything is missing on our side to use the standard set of checks, we'll do what is necessary to be able to use them. :) We can then see if there are any jobs not working right for you. Please let me know if there are any problems. All done on the Jenkins side. The one thing you are currently missing is a tox.ini file. I can help you create this tomorrow or if you want to do it in the mean time look at the examples in other projects. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ ___ 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] File injection support
On 05/29/2012 07:35 PM, Nicolae Paladi wrote: Hello, I am looking for more information about file injection support in OpenStack and find it increasingly inconsistent and incomplete. I have several questions: * This wiki article (http://wiki.openstack.org/HypervisorSupportMatrix) claims that file injection is supported in XenServer, is NOT supported inn KVM it's not clear about the others. is that still the case? One of the key Essex Features was Hypervisor Feature Parity, including: Disk Config, resize and file injection. I've updated the wiki accordingly. So there is support in kvm for injecting ssh keys, net info, root password, or arbitrary files. By default there are 3 methods tried in turn to do this: loopback mount, qemu-nbd, libguestfs. In Essex injection is supported to the first partition of guest images. Folsom enables further libguestfs functionality to inspect arbitrarily complex guest images and find the root partition to inject to. At least there is some mentioning of file injection in the openstack xenserver wiki: http://wiki.openstack.org/XenServer/Development * Is there any guide or man page where file injection is explained? in this use case I would like to inject a file to e.g. /etc/security/.conf at launch time -- is that possible, and if yes how can it be done in the Essex release. The API docs explain the personality parameter to achieve this: http://docs.openstack.org/api/openstack-compute/2/content/CreateServers.html This is exposed on the nova command line tool though the --injected-files option. * Are there any discussions about the future of file injection? There are other options, like cloud-init or using a config drive. You enable a config drive with the nova --config-drive option, with value as a boolean or a volume ID. See also: https://blueprints.launchpad.net/nova/+spec/config-drive-v2 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
[Openstack] Migrate use nova
I am trying to do openstack migrate and get stuck My coworker told me that I can use nova-manage to migrate, but I can't find any migrate options within nova-manage, it must be removed in Essex there is migrate option with nova command, but it has very little options and help info, I am confuse with that usage: nova migrate [--poll] server Migrate a server. Positional arguments: server Name or ID of server. Optional arguments: --pollBlocks while instance migrates so progress can be reported. there is not option to specify which host I want migrate an instance to I run 'nova migrate --poll name-of-instance', this error shows: ERROR: Policy doesn't allow compute_extension:admin_actions:migrate to be performed. (HTTP 403) (Request-ID: req-17fafbff-5264-4ba5-a5bd-141520601f78 I have not setup share storage so live migrate not work (and I am not looking for live migrate) can some one share any experience about migrate? Thanks -- William Herry williamherrych...@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
[Openstack] Fwd: Migrate use nova
sorry, I googled and find that error was because I am normal user now my only question is that it have to option to let me specify which host to migrate to, which host well be migrate to ? -- Forwarded message -- From: William Herry william.herry.ch...@gmail.com Date: Wed, May 30, 2012 at 10:00 AM Subject: [Openstack] Migrate use nova To: openstack@lists.launchpad.net I am trying to do openstack migrate and get stuck My coworker told me that I can use nova-manage to migrate, but I can't find any migrate options within nova-manage, it must be removed in Essex there is migrate option with nova command, but it has very little options and help info, I am confuse with that usage: nova migrate [--poll] server Migrate a server. Positional arguments: server Name or ID of server. Optional arguments: --pollBlocks while instance migrates so progress can be reported. there is not option to specify which host I want migrate an instance to I run 'nova migrate --poll name-of-instance', this error shows: ERROR: Policy doesn't allow compute_extension:admin_actions:migrate to be performed. (HTTP 403) (Request-ID: req-17fafbff-5264-4ba5-a5bd-141520601f78 I have not setup share storage so live migrate not work (and I am not looking for live migrate) can some one share any experience about migrate? Thanks -- William Herry williamherrych...@gmail.com -- William Herry williamherrych...@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
[Openstack] force resize at same host
hi: When i have multi compute host in openstack; 'allow_resize_to_same_host=True' may be make the instance resize at the same host; but if i want to force make the instance resize at the same host,what should i do? Thanks :) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Identity API v3 - Why allow multi-tenant users?
Just to echo Tim's comments here about the research space - we certainly have this requirement over in NeCTAR (Australia's national cloud for research). Australia actually has entire institutions setup to work in this mode - helping out multiple universities simultaneously with software development et al, and it's certainly a common case with our OpenStack cloud. Regards, Tom On 05/30/2012 07:16 AM, Gabriel Hurley wrote: Terminology: Project == Tenant. They are equivalent in Keystone parlance. What you're referring to as a tenant in that last email is the role a domain might play going forward in Keystone. 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 Caitlin Bestler Sent: Tuesday, May 29, 2012 11:47 AM To: Tim Bell; openstack@lists.launchpad.net Subject: Re: [Openstack] Identity API v3 - Why allow multi-tenant users? Tim Bell wrote: ➢ In the research environment, we have frequent cases where a user is associated with multiple tenants. For example, when you are finishing work on a previous project but are mainly working on the new one. As we move towards domain/tenant/user, we need to ensure that the tools support multi-tenant per user. Correct accounting is critical. This does require extra code but it is relevant given the use cases. What you are describing strikes me as a single tenant with multiple projects. It is similar to a corporate environment with multiple departments. I am seeing a major problem here when the tenants are truly separate and the only possible administrator in common is the service provider. ___ 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] Fwd: Nodejs in horizon
I want to second Adam's comment: Node.js is a whole different server side technology, and that should not be implemented at this time. for all the reasons others have expressed in this thread. Martin On 30 May 2012 03:26, Adam Young ayo...@redhat.com wrote: On 05/29/2012 12:29 PM, Gabriel Hurley wrote: Without rehashing backstory which is available in public archives of this thread, while node is currently on the table for LESS it also may play a role in future needs as well. As for your link, yes there are LESS compilers in other languages (there's even a nascent one in Python that's very much not ready for prime time) but requiring PHP or any other language besides Python opens a similar can of worms, and PHP gets us nowhere on any other fronts. /me refrains from any other comments about PHP. Moreover, the canonical LESS compiler which is the best supported and most stable is the main one written for node.js. Unless there were a 100% working Python version I see no reason not to favor the real LESS compiler. All the best, For LESS, it think it is fine to use even server side Javascript. The CSS should be compiled at RPM/DEB build time, and not at run time for live deployments, so that is a bit of a non-issue. I'd also be fine with using the client side LESS implementation, especially if we want to use the same implementation at development and live deployment time, but I can understand if there are issues with doing this. Node.js is a whole different server side technology, and that should not be implemented at this time. - Gabriel On May 29, 2012, at 1:00 AM, Matthias Rungemrunge@matthias-runge.**demru...@matthias-runge.de wrote: On 28/05/12 16:21, Thierry Carrez wrote: John Postlethwait wrote: Sorry if I've missed anything below, this thread has become rather fragmented and messy (at least in my email clients) but I will try to address the main points I have seen so far: Sorry, if I jump in late in this thread, I may have skipped some basics. If I get it right, nodejs is just required to compile LESS to css, right? There is at least one alternative without requiring nodejs: https://github.com/leafo/**lessphp https://github.com/leafo/lessphp -- Matthias Rungemru...@matthias-runge.de** __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp -- == Martin Paulo, BSc. Software Developer Tel : +61-3-9434 2508 (Home) Tel : 04 205 20339 (Mobile) Site: http://www.thepaulofamily.net Nobody goes there any more. It's too crowded - Yogi Berra. ___ 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] Greatest deployment?
Matt, LXC is not a good alternative for several obvious reasons. So think on all of that. Could you expand on why you believe LXC is not a good alternative? As an HPC provider we're currently weighing up options to get the most we can out of our Openstack deployment performance-wise. In particular we have quite a bit of IB, a fairly large Lustre deployment and some GPUs, and are seriously considering going down the LXC route to try to avoid wasting all of that by putting a hypervisor on top. - Michael Chapman On Fri, May 25, 2012 at 1:34 AM, Matt Joyce matt.jo...@cloudscaling.comwrote: We did some considerable HPC testing when I worked over at NASA Ames with the Nebula project. So I think we may have been the first to try out openstack in an HPC capacity. If you can find Piyush Mehrotra from the NAS division at Ames, ( I'll leave it to you to look him up ) he has comprehensive OpenStack tests from the Bexar days. He'd probably be willing to share some of that data if there was interest ( assuming he hasn't already ). Several points of interest I think worth mentioning are: I think fundamentally many of the folks who are used to doing HPC work dislike working with hypervisors in general. The memory management and general i/o latency is something they find to be a bit intolerable. OpenNebula, and OpenStack rely on the same sets of open source hypervisors. In fact, I believe OpenStack supports more. What they do fundamentally is operate as an orchestration layer on top of the hypervisor layer of the stack. So in terms of performance you should not see much difference between the two at all. That being said, that's ignoring the possibility of scheduler customisation and the sort. We ultimately, much like Amazon HPC ended up handing over VMs to customers that consumed all the resources on a system thus negating the benefit of VMs by a large amount. 1 primary reason for this is pinning the 10 gig drivers, or infiniband if you have it, to a single VM allows for direct pass through and no hypervisor latency. We were seeing a maximum throughput on our 10 gigs of about 8-9 gbit with virtio / jumbo frames via kvm, while hardware was slightly above 10. Several vendors in the area I have spoken with are engaged in efforts to tie in physical layer provisioning with OpenStack orchestration to bypass the hypervisor entirely. LXC is not a good alternative for several obvious reasons. So think on all of that. GPUs are highly specialised. Depending on your workloads you may not benefit from them. Again you have the hardware pinning issue in VMs. As far as Disk I/O is concerned, large datasets need large disk volumes. Large non immutable disk volumes. So swift / lafs go right out the window. nova-volume has some limitations ( or it did at the time ) euca tools couldn't handle 1 TB volumes and the APT maxed out around 2. So we had users raiding their volumes and asking how to target them to nodes to increase I/O. This was sub optimal. Luster or gluster would be better options here. We chose gluster because we've used luster before, and anyone who has knows it's pain. As for node targeting users cared about specific families of cpus. Many people optimised by cpu and wanted to target westmeres of nehalems. We had no means to do that at the time. Scheduling full instances is somewhat easier so long as all the nodes in your zone are full instance use only. Matt Joyce Now at Cloudscaling On Thu, May 24, 2012 at 5:49 AM, John Paul Walters jwalt...@isi.eduwrote: Hi, On May 24, 2012, at 5:45 AM, Thierry Carrez wrote: OpenNebula has also this advantage, for me, that it's designed also to provide scientific cloud and it's used by few research centres and even supercomputing centres. How about Openstack? Anyone tried deploy it in supercomputing environment? Maybe huge cluster or GPU cluster or any other scientific group is using Openstack? Is anyone using Openstack in scentific environement or Openstack's purpose is to create commercial only cloud (business - large and small companies)? OpenStack is being used in a number of research clouds, including NeCTAR (Australia's national research cloud). There is huge interest around bridging the gap there, with companies like Nimbis or Bull being involved. Hopefully people with more information than I have will comment on this thread. We're developing GPU, bare metal, and large SMP (think SGI UV) support for Openstack and we're targeting HPC/scientific computing workloads. It's a work in progress, but we have people using our code and we're talking to folks about getting our code onto nodes within FutureGrid. We have GPU support for LXC right now, and we're working on adding support for other hypervisors as well. We're also working on getting the code into shape for merging upstream, some of which (the bare metal work) has already been done. We had an HPC
