[Openstack-community] Beyond the wiki page: planning an International Community Portal
Hello folks, with the large growth of OpenStack internationally comes the need to have a better system to list the international resources for new users of OpenStack. At the moment we have a couple of wiki pages like http://wiki.openstack.org/OpenStackUserGroups, this list and the map on the /community page on openstack.org. All that content is available only in English. We need more. I would like to discuss the needs of the international community and get a new system in place in the next few weeks. Basic needs • A directory of OpenStack user groups (OSUG) that is more flexible and appealing than a wiki page. • A system to get in touch with members (all members or just the coordinators/leaders?) of the international communities. Features • Register users using SSO ∘ as a user I would like to be able to associate my profile from Launchpad, Linkedin or Google to the site • Support content in multiple languages (switch list and automatic recognition via browser agent configuration) • Support roles: managers of the groups can add resources, members can sign up as members, anonymous can read all content • Show activity from all groups in my own language on the portal home page • Directory of OSUGroups, with geographic representation ∘ be able to view the groups on a chart ∘ display also the full list of groups • Manage content (pages) of generic interest ∘ to host content like how to start a group, general, policies, trademark stuff, generic icons, etc • Per each group, ∘ allow users to add events, each group will expose its ical feed ∘ show to list additional resources for the group: mailing lists, forums, wiki pages, home page, url of blogs, ∘ import RSS feed from blogs to aggregate content on groups page ∘ display photostreams from flickr and such on the home page Questions: • is that all we need? • do we want to host and provide web apps for any of the local groups (mlists, blog, forums, etc)? • can we reuse code from Ubuntu Loco portal? https://code.launchpad.net/loco-team-portal The code is tightly integrated in Launchpad, local teams need to be created as Launchpad Teams, it uses Launchpad as OpenID provider (bugs included) but it's already there, it's a django app • What other tools can we use for this and would you volunteer to manage such tool? I'm interested in your opinions. /stef -- 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
[Openstack] nova-manage network documentation
Hi all, I might be missing something, but I can't find any comprehensive documentation of the 'nova-manage network' subcommand. The only doc entries I find about this are examples, but no list of flags, neither in 'man nova-manage', nor in 'nova-manage --help' nor in http://nova.openstack.org/runnova/nova.manage.html any ideas? thanks, michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ 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-manage network documentation
Hi Michaël,would you please fill a bug herehttps://bugs.launchpad.net/openstack-manualsSo the team could check/ update the docRegards,Razique Nuage Co - Razique Mahrouarazique.mahr...@gmail.com Le 9 mai 2012 à 09:40, Michaël Van de Borne a écrit :Hi all,I might be missing something, but I can't find any comprehensive documentation of the 'nova-manage network' subcommand.The only doc entries I find about this are examples, but no list of flags, neither in 'man nova-manage', nor in 'nova-manage --help' nor in http://nova.openstack.org/runnova/nova.manage.htmlany ideas?thanks,michaël-- Michaël Van de BorneRD Engineer, SOA team, CETICPhone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgliwww.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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-manage network documentation
ok, done here: https://bugs.launchpad.net/openstack-manuals/+bug/996970 cheers, michal Michal Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frres Wright, 29/3, B-6041 Charleroi Le 09/05/2012 09:50, Razique Mahroua a crit: Hi Michal, would you please fill a bug here https://bugs.launchpad.net/openstack-manuals So the team could check/ update the doc Regards, Razique Nuage Co - Razique Mahroua razique.mahr...@gmail.com Le 9 mai 2012 09:40, Michal Van de Borne a crit : Hi all, I might be missing something, but I can't find any comprehensive documentation of the 'nova-manage network' subcommand. The only doc entries I find about this are examples, but no list of flags, neither in 'man nova-manage', nor in 'nova-manage --help' nor in http://nova.openstack.org/runnova/nova.manage.html any ideas? thanks, michal -- Michal Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frres Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] nova-manage network documentation
The flags can be viewed using the --help command (see below). Dan danwent@ubuntu:~/nova$ bin/nova-manage network --help --help does not match any options: create delete list modify quantum_list danwent@ubuntu:~/nova$ bin/nova-manage network create --help Usage: nova-manage network create args [options] Options: -h, --helpshow this help message and exit --label=label Label for network (ex: public) --fixed_range_v4=x.x.x.x/yy IPv4 subnet (ex: 10.0.0.0/8) --num_networks=number Number of networks to create --network_size=number Number of IPs per network --vlan=vlan id vlan id --vpn=VPN_START vpn start --fixed_range_v6=FIXED_RANGE_V6 IPv6 subnet (ex: fe80::/64 --gateway=GATEWAY gateway --gateway_v6=GATEWAY_V6 ipv6 gateway --bridge=bridge VIFs on this network are connected to this bridge --bridge_interface=bridge interface the bridge is connected to this interface --multi_host='T'|'F' Multi host --dns1=DNS Address First DNS --dns2=DNS Address Second DNS --uuid=network uuid Network UUID --fixed_cidr=x.x.x.x/yy IPv4 subnet for fixed IPS (ex: 10.20.0.0/16) --project_id=project id Project id --priority=number Network interface priority On Wed, May 9, 2012 at 12:40 AM, Michaël Van de Borne michael.vandebo...@cetic.be wrote: Hi all, I might be missing something, but I can't find any comprehensive documentation of the 'nova-manage network' subcommand. The only doc entries I find about this are examples, but no list of flags, neither in 'man nova-manage', nor in 'nova-manage --help' nor in http://nova.openstack.org/**runnova/nova.manage.htmlhttp://nova.openstack.org/runnova/nova.manage.html any ideas? thanks, michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/~openstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ 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] why does notification use a topic exchange instead of fanout?
Hi Doug, I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given notification. That's only true if each client is consuming from the same queue bound to the exchange. So just to be clear, if I understand you correctly within the nova service/rpc abstraction layers the code is set up so that all services do bind to the same queue, and hence we get the round-robin delivery. But, if someone wanted to write a separate notification consumer so that they didn't block anyone else from seeing the same messages then they (the consumer) should create a new queue on the existing topic exchange. Is that correct - and is there any worked example of doing this ? I thought within the nova code both the exchange and topic queues were set up by the consumer (so for example all compute_managers try to create the compute exchange and topic queue, but its only created by the first one and the others connect to the same queue). In that context I'm finding it hard to see how to change this model to have multiple notify.info topic queues into the same exchange ? Cheers, Phil From: openstack-bounces+philip.day=hp@lists.launchpad.net [mailto:openstack-bounces+philip.day=hp@lists.launchpad.net] On Behalf Of Doug Hellmann Sent: 08 May 2012 23:34 To: Russell Bryant Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? On Tue, May 8, 2012 at 6:04 PM, Russell Bryant rbry...@redhat.commailto:rbry...@redhat.com wrote: On 05/08/2012 05:59 PM, Doug Hellmann wrote: Here is a relevant section pulled out of the amqp 0-9-1 spec: 3.1.3.3 The Topic Exchange Type The topic exchange type works as follows: 1. A message queue binds to the exchange using a routing pattern, P. 2. A publisher sends the exchange a message with the routing key R. 3. The message is passed to the message queue if R matches P. The routing key used for a topic exchange MUST consist of zero or more words delimited by dots. Each word may contain the letters A-Z and a-z and digits 0-9. The routing pattern follows the same rules as the routing key with the addition that * matches a single word, and # matches zero or more words. Thus the routing pattern *.stock.# matches the routing keys usd.stock and eur.stock.db but not stock.nasdaq. In nova, for a given topic such as 'scheduler', all of the consumers are binding to the same queue on the topic exchange, resulting in round-robin delivery to each of the consumers. If instead you make a new queue, you can get your own copy of each message. There is an additional benefit of using a topic exchange here. The topic used for notifications is 'notifications.priority'. That means that when you create your queue, you can set it up to receive all notifications, or only notifications of a certain priority. Topic exchanges make a lot of sense for messages that should only be consumed once, such as tasks. Notifications are different. Lots of different clients might want to know that some event happened in the system. The way things are in Nova today, they can't. The first client who consumes a notification message will prevent all of the other clients from seeing that message at all. I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given notification. That's only true if each client is consuming from the same queue bound to the exchange. Yes, that wasn't obvious from any of the kombu documentation I've seen so far. I'll keep looking. Thanks, Doug I can change Nova's notification system to use a fanout exchange (in impl_kombu.py changing the exchange type used by NotifyPublisher), but before I submit a patch I want to make sure the current implementation using a topic exchange wasn't selected deliberately for some reason. I think using a fanout exchange would be a downgrade. As I mentioned before, a topic exchange allows you to create a queue to get all notifications or only notifications of a specific priority. If the exchange type is changed to fanout, it's everybody gets everything, and that's it. -- 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
[Openstack] Munin plugins for essex (nova, keystone, glance)
Hi, I have recently updated and created some munin plugin for nova, keystone, glance of the essex release. The following metrics are retrieved: - glance: total/used size by tenant - glance: number of images per status - keystone: number of tenant enabled and total tenants - nova: total/allocated/associated number of floating ip - nova: number of each king of nova services are available - nova: number of launched instances - nova: number instances per power_state/vm_state/vcpus/root_gb... (any field in nova instances table) Let me known if other interesting metrics can be retrieved or if something is wrong with this one. This plugins can be found here: - https://github.com/sileht/openstack-munin Or directly in munin contrib repo: - https://github.com/munin-monitoring/contrib Regards, -- Mehdi ABAAKOUK sil...@sileht.net ___ 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] why does notification use a topic exchange instead of fanout?
Your own queue listener should attempt to declare the exchange, using the same settings as Nova does. If the exchange exists, its a noop. Otherwise it's created for you. After that, if you start up Nova, it will do the same and reuse your exchange. Obviously this works both ways, and either nova or your code can declare the exchange. AMQP is designed to be a configuration-less protocol, where resources are configured by the first consumer attempting to use them. Thanks, Kiall Sent from my phone. On May 9, 2012 9:52 a.m., Day, Phil philip@hp.com wrote: Hi Doug, ** ** I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given notification. That's only true if each client is consuming from the same queue bound to the exchange. ** ** So just to be clear, if I understand you correctly within the nova service/rpc abstraction layers the code is set up so that all services do bind to the same queue, and hence we get the round-robin delivery. But, if someone wanted to write a separate notification consumer so that they didn’t block anyone else from seeing the same messages then they (the consumer) should create a new queue on the existing topic exchange. ** ** Is that correct – and is there any worked example of doing this ? ** ** I thought within the nova code both the exchange and topic queues were set up by the consumer (so for example all compute_managers try to create the “compute” exchange and topic queue, but its only created by the first one and the others connect to the same queue). In that context I’m finding it hard to see how to change this model to have multiple “notify.info” topic queues into the same exchange ? ** ** Cheers, Phil ** ** ** ** ** ** ** ** *From:* openstack-bounces+philip.day=hp@lists.launchpad.net [mailto: openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of *Doug Hellmann *Sent:* 08 May 2012 23:34 *To:* Russell Bryant *Cc:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? ** ** ** ** On Tue, May 8, 2012 at 6:04 PM, Russell Bryant rbry...@redhat.com wrote: On 05/08/2012 05:59 PM, Doug Hellmann wrote: Here is a relevant section pulled out of the amqp 0-9-1 spec: 3.1.3.3 The Topic Exchange Type The topic exchange type works as follows: 1. A message queue binds to the exchange using a routing pattern, P. 2. A publisher sends the exchange a message with the routing key R. 3. The message is passed to the message queue if R matches P. The routing key used for a topic exchange MUST consist of zero or more words delimited by dots. Each word may contain the letters A-Z and a-z and digits 0-9. The routing pattern follows the same rules as the routing key with the addition that * matches a single word, and # matches zero or more words. Thus the routing pattern *.stock.# matches the routing keys usd.stock and eur.stock.db but not stock.nasdaq. In nova, for a given topic such as 'scheduler', all of the consumers are binding to the same queue on the topic exchange, resulting in round-robin delivery to each of the consumers. If instead you make a new queue, you can get your own copy of each message. There is an additional benefit of using a topic exchange here. The topic used for notifications is 'notifications.priority'. That means that when you create your queue, you can set it up to receive all notifications, or only notifications of a certain priority. Topic exchanges make a lot of sense for messages that should only be consumed once, such as tasks. Notifications are different. Lots of different clients might want to know that some event happened in the system. The way things are in Nova today, they can't. The first client who consumes a notification message will prevent all of the other clients from seeing that message at all. I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given notification. That's only true if each client is consuming from the same queue bound to the exchange. ** ** Yes, that wasn't obvious from any of the kombu documentation I've seen so far. I'll keep looking. ** ** Thanks, Doug I can change Nova's notification system to use a fanout exchange (in impl_kombu.py changing the exchange type used by NotifyPublisher), but before I submit a patch I want to make sure the current implementation using a topic exchange wasn't selected deliberately for some reason. I think using a fanout exchange would be a
Re: [Openstack] Munin plugins for essex (nova, keystone, glance)
Amazing workcongratulations and thank you.I'm myself working on zabbix templates. Maybe we could share our effort and create a monitoring repo for openstack (bash scripts, monitoring templates, etc..)what you guys think ? Nuage Co - Razique Mahrouarazique.mahr...@gmail.com Le 9 mai 2012 à 11:31, Abaakouk Mehdi a écrit :Hi,I have recently updated and created some munin plugin for nova, keystone, glance of the essex release.The following metrics are retrieved:- glance: total/used size by tenant- glance: number of images per status- keystone: number of tenant enabled and total tenants- nova: total/allocated/associated number of floating ip- nova: number of each king of nova services are available- nova: number of launched instances- nova: number instances per power_state/vm_state/vcpus/root_gb... (any field in nova instances table)Let me known if other interesting metrics can be retrieved or if something is wrong with this one.This plugins can be found here:- https://github.com/sileht/openstack-muninOr directly in munin contrib repo:- https://github.com/munin-monitoring/contribRegards,-- Mehdi ABAAKOUKsil...@sileht.net___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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] dimenssion of vnc console window
Hi, I found a way to change the dimenssion of the window image for the vnc console. The file to be changed is: /usr/share/pyshared/horizon/dashboards/nova/templates/nova/instances_and_volumes/instances/_detail_vnc.html. The parameters are: width=1280 height=900 Regards, Gabriel ___ 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 Object Storage
On 09/05/12 04:02, Sid Sudhi wrote: I am trying to write a script to upload large sized files. I am encountering the following limitations - can some one shed some light if they can help me over come the issue? When files are big and they uploaded with chunks these chunks do not delete automatically. And the file composed from these chunks has no size metadata. I reported a bug about container object listing: https://bugs.launchpad.net/swift/+bug/874119 You should get the right information if you run a GET or HEAD request over the object (check the bug report for an example). Any suggestions? AFAIK the chunks need to be there. There are two different things: - objects parts (chunks) - manifest file (that tells swift how to assemble the file) Regards, Juan ___ 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] why does notification use a topic exchange instead of fanout?
OK, get that so far - so both consumers need to declare and use the same exchange. But If I understand the next step right, to get multiple consumers of info notification messages they would all need to create separate notifications.info queues into that exchange.And isn't that exactly what Nova currently does to create a shared queue ? Phil From: Kiall Mac Innes [mailto:ki...@managedit.ie] Sent: 09 May 2012 10:51 To: Day, Phil Cc: openstack@lists.launchpad.net; Russell Bryant; Doug Hellmann Subject: Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? Your own queue listener should attempt to declare the exchange, using the same settings as Nova does. If the exchange exists, its a noop. Otherwise it's created for you. After that, if you start up Nova, it will do the same and reuse your exchange. Obviously this works both ways, and either nova or your code can declare the exchange. AMQP is designed to be a configuration-less protocol, where resources are configured by the first consumer attempting to use them. Thanks, Kiall Sent from my phone. On May 9, 2012 9:52 a.m., Day, Phil philip@hp.commailto:philip@hp.com wrote: Hi Doug, I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given notification. That's only true if each client is consuming from the same queue bound to the exchange. So just to be clear, if I understand you correctly within the nova service/rpc abstraction layers the code is set up so that all services do bind to the same queue, and hence we get the round-robin delivery. But, if someone wanted to write a separate notification consumer so that they didn't block anyone else from seeing the same messages then they (the consumer) should create a new queue on the existing topic exchange. Is that correct - and is there any worked example of doing this ? I thought within the nova code both the exchange and topic queues were set up by the consumer (so for example all compute_managers try to create the compute exchange and topic queue, but its only created by the first one and the others connect to the same queue). In that context I'm finding it hard to see how to change this model to have multiple notify.infohttp://notify.info topic queues into the same exchange ? Cheers, Phil From: openstack-bounces+philip.day=hp@lists.launchpad.netmailto:hp@lists.launchpad.net [mailto:openstack-bounces+philip.daymailto:openstack-bounces%2Bphilip.day=hp@lists.launchpad.netmailto:hp@lists.launchpad.net] On Behalf Of Doug Hellmann Sent: 08 May 2012 23:34 To: Russell Bryant Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? On Tue, May 8, 2012 at 6:04 PM, Russell Bryant rbry...@redhat.commailto:rbry...@redhat.com wrote: On 05/08/2012 05:59 PM, Doug Hellmann wrote: Here is a relevant section pulled out of the amqp 0-9-1 spec: 3.1.3.3 The Topic Exchange Type The topic exchange type works as follows: 1. A message queue binds to the exchange using a routing pattern, P. 2. A publisher sends the exchange a message with the routing key R. 3. The message is passed to the message queue if R matches P. The routing key used for a topic exchange MUST consist of zero or more words delimited by dots. Each word may contain the letters A-Z and a-z and digits 0-9. The routing pattern follows the same rules as the routing key with the addition that * matches a single word, and # matches zero or more words. Thus the routing pattern *.stock.# matches the routing keys usd.stock and eur.stock.db but not stock.nasdaq. In nova, for a given topic such as 'scheduler', all of the consumers are binding to the same queue on the topic exchange, resulting in round-robin delivery to each of the consumers. If instead you make a new queue, you can get your own copy of each message. There is an additional benefit of using a topic exchange here. The topic used for notifications is 'notifications.priority'. That means that when you create your queue, you can set it up to receive all notifications, or only notifications of a certain priority. Topic exchanges make a lot of sense for messages that should only be consumed once, such as tasks. Notifications are different. Lots of different clients might want to know that some event happened in the system. The way things are in Nova today, they can't. The first client who consumes a notification message will prevent all of the other clients from seeing that message at all. I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given
Re: [Openstack] Pending review
On Wed, May 09, 2012 at 05:38:44AM +, Vaze, Mandar wrote: https://review.openstack.org/#/c/6829/ Kevin Mitchell has reviewed as Looks good to me Additional reviews and approval required This looks like it should also go to stable/essex, once it got merged to master? Best Christoph -- Christoph Thiel, Project Manager, SUSE Cloud Infrastructure SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ 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] why does notification use a topic exchange instead of fanout?
Kinda! The queue has a name, but that name has no bearing on the set of messages received. If you create a queue called MyCustomNotificationQueue, you can bind that to the notifications exchange using the notifications.info routing key. (I'm guessing some of the names here.. I know AMQP, and not the specific naming nova uses!) Nova just happens to use the same queue name and routing key. I believe this is causing the confusion. Does this make sense? Anyway - The RabbitMQ docs probably explain it better than I.. http://www.rabbitmq.com/tutorials/tutorial-five-python.html Thanks, Kiall On Wed, May 9, 2012 at 11:30 AM, Day, Phil philip@hp.com wrote: OK, get that so far – so both consumers need to declare and use the same exchange. ** ** But If I understand the next step right, to get multiple consumers of info notification messages they would all need to create separate “ notifications.info” queues into that exchange.And isn’t that exactly what Nova currently does to create a shared queue ? ** ** Phil ** ** *From:* Kiall Mac Innes [mailto:ki...@managedit.ie] *Sent:* 09 May 2012 10:51 *To:* Day, Phil *Cc:* openstack@lists.launchpad.net; Russell Bryant; Doug Hellmann *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? ** ** Your own queue listener should attempt to declare the exchange, using the same settings as Nova does. If the exchange exists, its a noop. Otherwise it's created for you. After that, if you start up Nova, it will do the same and reuse your exchange. Obviously this works both ways, and either nova or your code can declare the exchange. AMQP is designed to be a configuration-less protocol, where resources are configured by the first consumer attempting to use them. Thanks, Kiall Sent from my phone. On May 9, 2012 9:52 a.m., Day, Phil philip@hp.com wrote: Hi Doug, I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given notification. That's only true if each client is consuming from the same queue bound to the exchange. So just to be clear, if I understand you correctly within the nova service/rpc abstraction layers the code is set up so that all services do bind to the same queue, and hence we get the round-robin delivery. But, if someone wanted to write a separate notification consumer so that they didn’t block anyone else from seeing the same messages then they (the consumer) should create a new queue on the existing topic exchange. Is that correct – and is there any worked example of doing this ? I thought within the nova code both the exchange and topic queues were set up by the consumer (so for example all compute_managers try to create the “compute” exchange and topic queue, but its only created by the first one and the others connect to the same queue). In that context I’m finding it hard to see how to change this model to have multiple “notify.info” topic queues into the same exchange ? Cheers, Phil *From:* openstack-bounces+philip.day=hp@lists.launchpad.net [mailto: openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of *Doug Hellmann *Sent:* 08 May 2012 23:34 *To:* Russell Bryant *Cc:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? On Tue, May 8, 2012 at 6:04 PM, Russell Bryant rbry...@redhat.com wrote: On 05/08/2012 05:59 PM, Doug Hellmann wrote: Here is a relevant section pulled out of the amqp 0-9-1 spec: 3.1.3.3 The Topic Exchange Type The topic exchange type works as follows: 1. A message queue binds to the exchange using a routing pattern, P. 2. A publisher sends the exchange a message with the routing key R. 3. The message is passed to the message queue if R matches P. The routing key used for a topic exchange MUST consist of zero or more words delimited by dots. Each word may contain the letters A-Z and a-z and digits 0-9. The routing pattern follows the same rules as the routing key with the addition that * matches a single word, and # matches zero or more words. Thus the routing pattern *.stock.# matches the routing keys usd.stock and eur.stock.db but not stock.nasdaq. In nova, for a given topic such as 'scheduler', all of the consumers are binding to the same queue on the topic exchange, resulting in round-robin delivery to each of the consumers. If instead you make a new queue, you can get your own copy of each message. There is an additional benefit of using a
Re: [Openstack] Pending review
Yes, it should. I'll tag it for essex back-port once this review is approved and code is merged to master. -Mandar -Original Message- From: openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net [mailto:openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net] On Behalf Of Christoph Thiel Sent: Wednesday, May 09, 2012 4:04 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Pending review On Wed, May 09, 2012 at 05:38:44AM +, Vaze, Mandar wrote: https://review.openstack.org/#/c/6829/ Kevin Mitchell has reviewed as Looks good to me Additional reviews and approval required This looks like it should also go to stable/essex, once it got merged to master? Best Christoph -- Christoph Thiel, Project Manager, SUSE Cloud Infrastructure SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ Mailing list: https://launchpad.net/~openstack Post to : 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
[Openstack] Floating IPs don't get dissociated after delete
Hi , I am having this problem just like many others. Each time I delete a VM, the floating IP doesn't get automatically dissociated, has anyone encountred this problem and solved it ? ___ 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] Munin plugins for essex (nova, keystone, glance)
Very useful ! Thanks, Jérôme On Wed, May 9, 2012 at 11:58 AM, Razique Mahroua razique.mahr...@gmail.comwrote: Amazing work congratulations and thank you. I'm myself working on zabbix templates. Maybe we could share our effort and create a monitoring repo for openstack (bash scripts, monitoring templates, etc..) what you guys think ? *Nuage Co - Razique Mahroua** * razique.mahr...@gmail.com Le 9 mai 2012 à 11:31, Abaakouk Mehdi a écrit : Hi, I have recently updated and created some munin plugin for nova, keystone, glance of the essex release. The following metrics are retrieved: - glance: total/used size by tenant - glance: number of images per status - keystone: number of tenant enabled and total tenants - nova: total/allocated/associated number of floating ip - nova: number of each king of nova services are available - nova: number of launched instances - nova: number instances per power_state/vm_state/vcpus/root_gb... (any field in nova instances table) Let me known if other interesting metrics can be retrieved or if something is wrong with this one. This plugins can be found here: - https://github.com/sileht/openstack-munin Or directly in munin contrib repo: - https://github.com/munin-monitoring/contrib Regards, -- Mehdi ABAAKOUK sil...@sileht.net ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Metering] Bootstrapping, first counter implementation
Hi there, I've added a first script that's able to connect to the AMQP notification queue using Nova RPC module. Later it will be able to treat them when we'll know what to do with them. https://review.stackforge.org/#/c/26/ https://review.stackforge.org/#/c/27/ https://review.stackforge.org/#/c/28/ I wish I could use nova.service.Service, but the code is too RPC oriented so that it can't grab notification from the notifier, so for now the daemon is rather simple. -- 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] Swift on Webob-1.2 anyone?
Hi Pete, On Wed, May 9, 2012 at 4:45 AM, Pete Zaitcev zait...@redhat.com wrote: on adapting Swift for WebOb 1.2 and if a patch is available somewhere. I see Ionut fixed lp:984042, but clearly it wasn't enough. If nobody's done it yet, I suppose I could take a swing at it. New webob I started doing that sometime ago (~6 month) and abandoned working on it since some of the changes were pretty intrusive[1] with the way swift works and webob 1.2 was in beta at that time (and still is). The challenge if you are taking a stab at it would probably be to support webob 1.1* and 1.2 at the same time in the code. Cheers, Chmouel. [1] I can't remember the details. ___ 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] Floating IPs don't get dissociated after delete
On 05/09/2012 07:20 AM, Bilel Msekni wrote: Hi , I am having this problem just like many others. Each time I delete a VM, the floating IP doesn't get automatically dissociated, has anyone encountred this problem and solved it ? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Bilel, We had this problem in openstack during our floating ip implementation of heat (http://www.heat-api.org). We solved it by using the floating ip.delete api in nova. See: https://github.com/heat-api/heat/blob/master/heat/engine/eip.py line 118 The program flow on delete is: delete an instance wait for instance to disappear delete floating ip Regards -steve ___ 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] External API definition
On 05/08/2012 08:27 AM, Nick Barcet wrote: [..] Thinking about this, I think we need to expend the API a bit to reflect the evolutions of the schema that we decided last week. Here are my proposals: * Requests allow to GET account_id list change to: GET [user_id|project_id|source] list GET list of counter_type GET list of events per account optional start and end for counter_datetime optional counter_type change to: GET list of events per [user_id|project_id|source] optional start and end for counter_datetime optional counter_type GET sum of (counter_volume, counter_duration) for counter_type and account_id optional start and end for counter_datetime GET sum of (counter_volume, counter_duration) for counter_type and [user_id|project_id|source] optional start and end for counter_datetime Hope this makes sense. Another item that we need to discuss is extensibility of this API. Nick signature.asc Description: OpenPGP digital 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] ceilometer (java implementation)
On Tue, May 8, 2012 at 7:19 PM, Luis Gervaso l...@woorea.es wrote: Hi, I have uploaded a toy version of ceilometer (java implementation). It does implement the first two counters (instance : rabbitmq listener and cpu : polling from libvirt) i need more clarification on the meaining: counter_volume counter_duration counter_datetaime I hope this helps to figure out how to agreggate these data. http://github.com/woorea/ceilometer-java Nice! I have also been experimenting. I have some Python code in https://github.com/dhellmann/metering-prototype that listens for notifications related to instances (create, delete, exists) and converts them to counter output (see spy.py). There is also a pair of scripts for recording an event stream and playing it back (useful for testing, see recorder.py and player.py). I don't have any libvirt polling, yet, though. In the course of looking at the notifications being generated for different scenarios, I discovered that the instance delete messages do not have any duration information right now. I don't know if that is a bug, or if the idea is to figure out the durations from looking at the most recent exists event. What do other people think? Doug ___ 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] why does notification use a topic exchange instead of fanout?
On Wed, May 9, 2012 at 6:42 AM, Kiall Mac Innes ki...@managedit.ie wrote: Kinda! The queue has a name, but that name has no bearing on the set of messages received. If you create a queue called MyCustomNotificationQueue, you can bind that to the notifications exchange using the notifications.info routing key. (I'm guessing some of the names here.. I know AMQP, and not the specific naming nova uses!) notifications.info is right. Nova just happens to use the same queue name and routing key. I believe this is causing the confusion. Exactly. I ended up creating a separate queue for each client that I have and setting them to auto-delete when the client disconnects. That way I can have as many clients connecting and listening as I want. The code is in https://github.com/dhellmann/metering-prototype if you want to take a look. Does this make sense? Anyway - The RabbitMQ docs probably explain it better than I.. http://www.rabbitmq.com/tutorials/tutorial-five-python.html Thanks, Kiall On Wed, May 9, 2012 at 11:30 AM, Day, Phil philip@hp.com wrote: OK, get that so far – so both consumers need to declare and use the same exchange. ** ** But If I understand the next step right, to get multiple consumers of info notification messages they would all need to create separate “ notifications.info” queues into that exchange.And isn’t that exactly what Nova currently does to create a shared queue ? ** ** Phil ** ** *From:* Kiall Mac Innes [mailto:ki...@managedit.ie] *Sent:* 09 May 2012 10:51 *To:* Day, Phil *Cc:* openstack@lists.launchpad.net; Russell Bryant; Doug Hellmann *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? ** ** Your own queue listener should attempt to declare the exchange, using the same settings as Nova does. If the exchange exists, its a noop. Otherwise it's created for you. After that, if you start up Nova, it will do the same and reuse your exchange. Obviously this works both ways, and either nova or your code can declare the exchange. AMQP is designed to be a configuration-less protocol, where resources are configured by the first consumer attempting to use them. Thanks, Kiall Sent from my phone. On May 9, 2012 9:52 a.m., Day, Phil philip@hp.com wrote: Hi Doug, I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given notification. That's only true if each client is consuming from the same queue bound to the exchange. So just to be clear, if I understand you correctly within the nova service/rpc abstraction layers the code is set up so that all services do bind to the same queue, and hence we get the round-robin delivery. But, if someone wanted to write a separate notification consumer so that they didn’t block anyone else from seeing the same messages then they (the consumer) should create a new queue on the existing topic exchange. Is that correct – and is there any worked example of doing this ? I thought within the nova code both the exchange and topic queues were set up by the consumer (so for example all compute_managers try to create the “compute” exchange and topic queue, but its only created by the first one and the others connect to the same queue). In that context I’m finding it hard to see how to change this model to have multiple “ notify.info” topic queues into the same exchange ? Cheers, Phil *From:* openstack-bounces+philip.day=hp@lists.launchpad.net [mailto: openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of *Doug Hellmann *Sent:* 08 May 2012 23:34 *To:* Russell Bryant *Cc:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? On Tue, May 8, 2012 at 6:04 PM, Russell Bryant rbry...@redhat.com wrote: On 05/08/2012 05:59 PM, Doug Hellmann wrote: Here is a relevant section pulled out of the amqp 0-9-1 spec: 3.1.3.3 The Topic Exchange Type The topic exchange type works as follows: 1. A message queue binds to the exchange using a routing pattern, P. 2. A publisher sends the exchange a message with the routing key R. 3. The message is passed to the message queue if R matches P. The routing key used for a topic exchange MUST consist of zero or more words delimited by dots. Each word may contain the letters A-Z and a-z and digits 0-9. The routing pattern follows the same rules as the routing key with the addition that * matches a single word, and # matches zero or more words. Thus the routing pattern
Re: [Openstack] [Metering] External API definition
On Tue, May 8, 2012 at 8:43 PM, Nick Barcet nick.bar...@canonical.comwrote: On 05/08/2012 11:39 AM, Doug Hellmann wrote: [..] * Requests must be authenticated (separate from keystone, or only linked to accounting type account) What is the motivation for authenticating with a service other than keystone? The only thing I am trying to express here is that that profiles that have access to other OpenStack components should not necessarily have access to metering information. This information should be accessible only a few select users which group may or may not intersect with users stored in Keystone already. I see. Is it enough to say that the API is meant for admin users only, or does that still imply more access than we want to grant? Nick ___ 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] Bootstrapping, first counter implementation
What is the difference between review.stackforge.org and review.openstack.org and why aren't we using the latter? On Wed, May 9, 2012 at 11:13 AM, Julien Danjou julien.dan...@enovance.comwrote: Hi there, I've added a first script that's able to connect to the AMQP notification queue using Nova RPC module. Later it will be able to treat them when we'll know what to do with them. https://review.stackforge.org/#/c/26/ https://review.stackforge.org/#/c/27/ https://review.stackforge.org/#/c/28/ I wish I could use nova.service.Service, but the code is too RPC oriented so that it can't grab notification from the notifier, so for now the daemon is rather simple. -- 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 ___ 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] External API definition
On 05/09/2012 08:36 AM, Doug Hellmann wrote: On Tue, May 8, 2012 at 8:43 PM, Nick Barcet nick.bar...@canonical.com mailto:nick.bar...@canonical.com wrote: On 05/08/2012 11:39 AM, Doug Hellmann wrote: [..] * Requests must be authenticated (separate from keystone, or only linked to accounting type account) What is the motivation for authenticating with a service other than keystone? The only thing I am trying to express here is that that profiles that have access to other OpenStack components should not necessarily have access to metering information. This information should be accessible only a few select users which group may or may not intersect with users stored in Keystone already. I see. Is it enough to say that the API is meant for admin users only, or does that still imply more access than we want to grant? I don't see the point to try to restrict admins from this, as it would be mostly pointless in the end, but I do see the need to define a type of account which only right is to consult this information without any other privilege. Nick signature.asc Description: OpenPGP digital 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] [Metering] External API definition
On Wed, May 9, 2012 at 11:27 AM, Nick Barcet nick.bar...@canonical.comwrote: On 05/08/2012 08:27 AM, Nick Barcet wrote: [..] Thinking about this, I think we need to expend the API a bit to reflect the evolutions of the schema that we decided last week. Here are my proposals: * Requests allow to GET account_id list change to: GET [user_id|project_id|source] list Does the [value|value] syntax mean choose one or combine? I assume choose one and you are using square brackets because parens are used in some of the other queries. GET list of counter_type GET list of events per account optional start and end for counter_datetime optional counter_type change to: GET list of events per [user_id|project_id|source] optional start and end for counter_datetime optional counter_type Users may cross projects, so I'm not sure it makes sense to ask for the events generated by a user without restricting it by the project. At the very least we may need to allow them to specify user_id or project_id or both. GET sum of (counter_volume, counter_duration) for counter_type and account_id optional start and end for counter_datetime GET sum of (counter_volume, counter_duration) for counter_type and [user_id|project_id|source] optional start and end for counter_datetime Hope this makes sense. Another item that we need to discuss is extensibility of this API. Nick ___ 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] Translation and Internationalization in OpenStack
On 05/08/2012 09:56 PM, Thierry Carrez wrote: Gabriel Hurley wrote: Having worked with all three tools, I would strongly suggest Transifex, particularly given that we as a community have to do almost no work to maintain it, it's the only tool that supports OpenStack as a project hub with shared teams and management, and it offers us a strong crowdsourced translation community. Getting a strong crowdsourced translation community is the most important aspect to me. We can relatively easily bridge the tooling/integration gap, but we can't invent a translation community :) I know for a fact that Launchpad has a magic translation community (just pushing stuff there makes it translated). If Transifex's community is as efficient and gives us better integration, then we should go for it. As per Thierry's call for volunteers, I will throw my hat in the ring to spearhead translation efforts in OpenStack for the time being. Great! I'm happy to defer the tool decision to the people that will own and push that work forward ;) Same here. Transifex seems like it meets our needs - and if it's got a champion who wants to do the work, then stellar! ___ 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] [Netstack] About python versions that we are planning to support
[I'm moving this thread to the openstack list because it potentially impacts openstack-common.] On 05/07/2012 11:53 PM, Maru Newby wrote: Hi, Python 2.4 compatibility is required, but only for agent code. Agent code needs to be deployable on Xen dom0, which uses CentoOS 5.5 and only supports 2.4 out of the box. Maru, I'm very concerned about the potential of this XenServer/XCP requirement to interfere with making the various Quantum agents first-class OpenStack services by utilizing current and future openstack-common facilities for configuration, logging, DB, RPC, etc.. Are there any other possible ways forward here? How is the nova compute service currently handled for XenServer? Could a fully supported version of python be parallel-installed on dom0? Could the actual quantum agent run somewhere else and remotely execute commands on dom0? Or does the python 2.4 compatibility requirement need to be applied to openstack-common? Thanks, -Bob Both quantum and nova have agent code that needs to be deployed to dom0, but up until now both projects have relied on savvy reviewers and bug reports to ensure compatibility. I'm working on it, though. I'll be adding a tox build to quantum that will run agent tests - and agent tests only - under 2.4, and then openstack-ci can add a jenkins job to run that build on CentOS and gate merges. The relevant bug: https://bugs.launchpad.net/quantum/+bug/995278 Thanks, Maru On 2012-05-07, at 6:54 PM, Yong Sheng Gong wrote: Hi, I see some ones are trying to support python2.4. But our tox.ini under quantum is only supporting test py26 and py27. So my question is if we are trying to support py24. In addition I remember that we will support py30. As far as I know, py2.4 does not support many new syntaxes introduced by py2.5+. Other projects such as nova, horizon are also adopting some of these new syntaxes. Moreover some third party components such as Django 1.4 required by horizon are only tested under py2.6 and py2.7. So if py2.4 is out of our scope, we should stop that trying. If we need py2.4, we have to make all of us know it and keep our code 2.4 compatible. Thanks Yong Sheng Gong -- Mailing list: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net mailto:netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack 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] Swift on Webob-1.2 anyone?
On 05/09/2012 05:45 AM, Pete Zaitcev wrote: I ran .unittests on a box with python-webob-1.2b3 and it throws left and right: errors=72, failures=6. I'm wondering if anyone is working on adapting Swift for WebOb 1.2 and if a patch is available somewhere. I see Ionut fixed lp:984042, but clearly it wasn't enough. If nobody's done it yet, I suppose I could take a swing at it. New webob is required to address the S3-with-colon problem lp:936998. -- Pete We started at 1.2b3, but saw too many failing unittests so we downgraded to 1.1.1 which we now have working. It would be great to have it on 1.2b3, though. -Ionuț ___ 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] route problem in multi-host enviroment
there are two zone with fix IP: Zone1 10.8.0.0/23 Zone2 10.9.0.0/23 there are some network host in each zone, and the vm in same zone can own different gateway. if i need to route VMs in zone1 with VMs in Zone2, how can set it? -- 彭勇 (Peng Yong) ___ 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] schema and counter definitions
Here is the simplified version of my code (without ampq support, counter stored directly to mysql db). https://github.com/ss7pro/rescnt Code is started from main.py which is constantly collecting counters from libvirt and storing them in a mysql database. On Mon, May 7, 2012 at 9:25 PM, Tomasz Paszkowski ss7...@gmail.com wrote: On Mon, May 7, 2012 at 5:21 PM, Loic Dachary l...@enovance.com wrote: Hi Tomasz, Hi I could not agree more and this is the reason why I/O shows in the list of meters shown in http://wiki.openstack.org/EfficientMetering (c5) disk IO in megabyte per second has a high impact on the service availability and could be billed separately . Yes but for disk drives I/O (number of read/write ops) are the key resource usage information. It's very hard to setup a billing model for disk drive usage on bandwidth as low bandwidth disk operations (small random read/writes) can utilize disk drive more than huge sequential reads/writes. I need also to mention that AWS is also charging for I/O in their volume service. It looks like you already have a codebase that could be useful for the metering implementation. Would you be willing to share it ? Yes. Just give me few days. -- Tomasz Paszkowski SS7, Asterisk, SAN, Datacenter, Cloud Computing +48500166299 -- Tomasz Paszkowski SS7, Asterisk, SAN, Datacenter, Cloud Computing +48500166299 ___ 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] External API definition
Doug Hellmann doug.hellm...@dreamhost.com wrote: On Wed, May 9, 2012 at 11:27 AM, Nick Barcet nick.bar...@canonical.comwrote: On 05/08/2012 08:27 AM, Nick Barcet wrote: [..] Thinking about this, I think we need to expend the API a bit to reflect the evolutions of the schema that we decided last week. Here are my proposals: * Requests allow to GET account_id list change to: GET [user_id|project_id|source] list Does the [value|value] syntax mean choose one or combine? I assume choose one and you are using square brackets because parens are used in some of the other queries. You assumed correctly :) GET list of counter_type GET list of events per account optional start and end for counter_datetime optional counter_type change to: GET list of events per [user_id|project_id|source] optional start and end for counter_datetime optional counter_type Users may cross projects, so I'm not sure it makes sense to ask for the events generated by a user without restricting it by the project. At the very least we may need to allow them to specify user_id or project_id or both. Good point. Thanks for catching this. GET sum of (counter_volume, counter_duration) for counter_type and account_id optional start and end for counter_datetime GET sum of (counter_volume, counter_duration) for counter_type and [user_id|project_id|source] optional start and end for counter_datetime Hope this makes sense. Another item that we need to discuss is extensibility of this API. Nick ___ 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] Bootstrapping, first counter implementation
stackForge is a Gerrit review and Jenkins CI setup similar to that of the main OpenStack project but for use with projects that are not under the main OpenStack umbrella. Any project can be added to StackForge as long as it is related to OpenStack in some way. 2012/5/9 Doug Hellmann doug.hellm...@dreamhost.com: What is the difference between review.stackforge.org and review.openstack.org and why aren't we using the latter? On Wed, May 9, 2012 at 11:13 AM, Julien Danjou julien.dan...@enovance.com wrote: Hi there, I've added a first script that's able to connect to the AMQP notification queue using Nova RPC module. Later it will be able to treat them when we'll know what to do with them. https://review.stackforge.org/#/c/26/ https://review.stackforge.org/#/c/27/ https://review.stackforge.org/#/c/28/ I wish I could use nova.service.Service, but the code is too RPC oriented so that it can't grab notification from the notifier, so for now the daemon is rather simple. -- 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 ___ 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] ceilometer (java implementation)
That's fantastic! What I mind is that the counters only should gather event info. Maybe multiple counters listening, collecting info about the system. But only one persist the event. Other process agreggates the data and creates different views/reports/billing, this should be outside of openstack (since it depends on the business rules, not depends on the infrastructure) The agreggator, also should offer an api for polling or can be configured throught drivers to push the the 3rd systems Now, in my implementation i'm putting all the stuff on a directory but it can be as well: - AMQP - SQL / NoSQL (the persistent layer shold be interchangeable) So as response to your duration question, this think is out scope for the counter tasks. On Wed, May 9, 2012 at 5:30 PM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Tue, May 8, 2012 at 7:19 PM, Luis Gervaso l...@woorea.es wrote: Hi, I have uploaded a toy version of ceilometer (java implementation). It does implement the first two counters (instance : rabbitmq listener and cpu : polling from libvirt) i need more clarification on the meaining: counter_volume counter_duration counter_datetaime I hope this helps to figure out how to agreggate these data. http://github.com/woorea/ceilometer-java Nice! I have also been experimenting. I have some Python code in https://github.com/dhellmann/metering-prototype that listens for notifications related to instances (create, delete, exists) and converts them to counter output (see spy.py). There is also a pair of scripts for recording an event stream and playing it back (useful for testing, see recorder.py and player.py). I don't have any libvirt polling, yet, though. In the course of looking at the notifications being generated for different scenarios, I discovered that the instance delete messages do not have any duration information right now. I don't know if that is a bug, or if the idea is to figure out the durations from looking at the most recent exists event. What do other people think? Doug -- --- 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
Re: [Openstack] dimenssion of vnc console window
On May 9, 2012, at 6:06 AM, Staicu Gabriel wrote: Hi, I found a way to change the dimenssion of the window image for the vnc console. The file to be changed is: /usr/share/pyshared/horizon/dashboards/nova/templates/nova/instances_and_volumes/instances/_detail_vnc.html. The parameters are: width=1280 height=900 Regards, Gabriel Thanks, Gabriel. I proposed adding this info to the docs: https://review.openstack.org/7278 Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.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] [Metering] Bootstrapping, first counter implementation
Ah, got it. Thanks! On Wed, May 9, 2012 at 12:45 PM, heut2008 heut2...@gmail.com wrote: stackForge is a Gerrit review and Jenkins CI setup similar to that of the main OpenStack project but for use with projects that are not under the main OpenStack umbrella. Any project can be added to StackForge as long as it is related to OpenStack in some way. 2012/5/9 Doug Hellmann doug.hellm...@dreamhost.com: What is the difference between review.stackforge.org and review.openstack.org and why aren't we using the latter? On Wed, May 9, 2012 at 11:13 AM, Julien Danjou julien.dan...@enovance.com wrote: Hi there, I've added a first script that's able to connect to the AMQP notification queue using Nova RPC module. Later it will be able to treat them when we'll know what to do with them. https://review.stackforge.org/#/c/26/ https://review.stackforge.org/#/c/27/ https://review.stackforge.org/#/c/28/ I wish I could use nova.service.Service, but the code is too RPC oriented so that it can't grab notification from the notifier, so for now the daemon is rather simple. -- 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 ___ 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: ceilometer (java implementation)
Forgot to copy the list -- Forwarded message -- From: Luis Gervaso l...@woorea.es Date: Wed, May 9, 2012 at 7:14 PM Subject: Re: [Openstack] ceilometer (java implementation) To: Doug Hellmann doug.hellm...@dreamhost.com I asked for these fields in my previous email, they are not clear enough. After analyze the problem, i ended that metrics can not be calculated per event. We need at least 2 events to calculate the duration (start/end) in some metrics. We can afford this on the counter processes, but it requires an update of the previous pesisted start event. So as we can calculate this info everywhere, and i don't like updates on the counters logic i'm calculating the duration as part of agreggation/mediation process (this will be only a view of the raw data). This way we maintain a very simple logic on the counters: * counters listen for specific events * the interpretation of raw data can be outside On Wed, May 9, 2012 at 7:01 PM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Wed, May 9, 2012 at 12:46 PM, Luis Gervaso l...@woorea.es wrote: That's fantastic! What I mind is that the counters only should gather event info. Maybe multiple counters listening, collecting info about the system. But only one persist the event. That makes sense. It seems like we will need to split the event-based processing from the polling. The agent that runs on the compute node should poll libvirt (and any other services on that node) and generate counter messages using a metering exchange. A separate set of daemons running in a more central location will watch messages on the metering exchange and save them to the database. Those same processes can watch for notification messages and convert them directly to metering data to be written to the database. That saves the extra traffic from notification messages resulting in several extra metering messages. Other process agreggates the data and creates different views/reports/billing, this should be outside of openstack (since it depends on the business rules, not depends on the infrastructure) If I understand Nick's proposal for the API, we will have some minimal aggregation there but you are right that any other interpretation will probably need to be handled by a custom app. The agreggator, also should offer an api for polling or can be configured throught drivers to push the the 3rd systems Now, in my implementation i'm putting all the stuff on a directory but it can be as well: - AMQP - SQL / NoSQL (the persistent layer shold be interchangeable) So as response to your duration question, this think is out scope for the counter tasks. I think you misunderstood my question. The duration to which I referred was the field in the counter schema (counter_duration). Only the exists notification for instances includes enough information to calculate the duration. The create notification should result in a 0 duration, so that can be ignored. The delete notification should record the data since the end of the last cycle, but does not today (at least it does not seem to). On Wed, May 9, 2012 at 5:30 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Tue, May 8, 2012 at 7:19 PM, Luis Gervaso l...@woorea.es wrote: Hi, I have uploaded a toy version of ceilometer (java implementation). It does implement the first two counters (instance : rabbitmq listener and cpu : polling from libvirt) i need more clarification on the meaining: counter_volume counter_duration counter_datetaime I hope this helps to figure out how to agreggate these data. http://github.com/woorea/ceilometer-java Nice! I have also been experimenting. I have some Python code in https://github.com/dhellmann/metering-prototype that listens for notifications related to instances (create, delete, exists) and converts them to counter output (see spy.py). There is also a pair of scripts for recording an event stream and playing it back (useful for testing, see recorder.py and player.py). I don't have any libvirt polling, yet, though. In the course of looking at the notifications being generated for different scenarios, I discovered that the instance delete messages do not have any duration information right now. I don't know if that is a bug, or if the idea is to figure out the durations from looking at the most recent exists event. What do other people think? Doug -- --- 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 -- --- Luis Alberto Gervaso Martin Woorea Solutions, S.L CEO CTO mobile: (+34) 627983344 luis@ luis.gerv...@gmail.comwoorea.es
Re: [Openstack] Swift on Webob-1.2 anyone?
On Wed, 9 May 2012 16:14:48 +0100 Chmouel Boudjnah chmo...@chmouel.com wrote: The challenge if you are taking a stab at it would probably be to support webob 1.1* and 1.2 at the same time in the code. I noticed that too. 1.1.1 made some intermediate choices that are difficult to reconcile, namely throwing warnings that break tests. The None values that they sprinkled over 1.2 ironically help. Fedora is likely to ship 1.1 in F17, so I guess I have to deal with it somehow. What a pain. -- Pete ___ 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] Bootstrapping, first counter implementation
On 05/09/2012 05:38 PM, Doug Hellmann wrote: What is the difference between review.stackforge.org http://review.stackforge.org and review.openstack.org http://review.openstack.org and why aren't we using the latter? There is no technical difference (to my knowledge ;-). Only review.stackforge.org http://review.stackforge.org is for projects that are not incubated yet. Cheers On Wed, May 9, 2012 at 11:13 AM, Julien Danjou julien.dan...@enovance.com mailto:julien.dan...@enovance.com wrote: Hi there, I've added a first script that's able to connect to the AMQP notification queue using Nova RPC module. Later it will be able to treat them when we'll know what to do with them. https://review.stackforge.org/#/c/26/ https://review.stackforge.org/#/c/27/ https://review.stackforge.org/#/c/28/ I wish I could use nova.service.Service, but the code is too RPC oriented so that it can't grab notification from the notifier, so for now the daemon is rather simple. -- Julien Danjou // eNovance http://enovance.com // ? julien.dan...@enovance.com mailto:julien.dan...@enovance.com ? +33 1 49 70 99 81 tel:%2B33%201%2049%2070%2099%2081 ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- 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] why does notification use a topic exchange instead of fanout?
You can allow nova to send notifications to multiple topics by setting this option in your nova.conf. ## (ListOpt) AMQP topic used for Nova notifications notification_topics=notifications,metering,monitoring This will allow you to consume all the messages from a different service. On Wed, May 9, 2012 at 10:34 AM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Wed, May 9, 2012 at 6:42 AM, Kiall Mac Innes ki...@managedit.iewrote: Kinda! The queue has a name, but that name has no bearing on the set of messages received. If you create a queue called MyCustomNotificationQueue, you can bind that to the notifications exchange using the notifications.info routing key. (I'm guessing some of the names here.. I know AMQP, and not the specific naming nova uses!) notifications.info is right. Nova just happens to use the same queue name and routing key. I believe this is causing the confusion. Exactly. I ended up creating a separate queue for each client that I have and setting them to auto-delete when the client disconnects. That way I can have as many clients connecting and listening as I want. The code is in https://github.com/dhellmann/metering-prototype if you want to take a look. Does this make sense? Anyway - The RabbitMQ docs probably explain it better than I.. http://www.rabbitmq.com/tutorials/tutorial-five-python.html Thanks, Kiall On Wed, May 9, 2012 at 11:30 AM, Day, Phil philip@hp.com wrote: OK, get that so far – so both consumers need to declare and use the same exchange. ** ** But If I understand the next step right, to get multiple consumers of info notification messages they would all need to create separate “ notifications.info” queues into that exchange.And isn’t that exactly what Nova currently does to create a shared queue ? ** ** Phil ** ** *From:* Kiall Mac Innes [mailto:ki...@managedit.ie] *Sent:* 09 May 2012 10:51 *To:* Day, Phil *Cc:* openstack@lists.launchpad.net; Russell Bryant; Doug Hellmann *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? ** ** Your own queue listener should attempt to declare the exchange, using the same settings as Nova does. If the exchange exists, its a noop. Otherwise it's created for you. After that, if you start up Nova, it will do the same and reuse your exchange. Obviously this works both ways, and either nova or your code can declare the exchange. AMQP is designed to be a configuration-less protocol, where resources are configured by the first consumer attempting to use them. Thanks, Kiall Sent from my phone. On May 9, 2012 9:52 a.m., Day, Phil philip@hp.com wrote: Hi Doug, I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given notification. That's only true if each client is consuming from the same queue bound to the exchange. So just to be clear, if I understand you correctly within the nova service/rpc abstraction layers the code is set up so that all services do bind to the same queue, and hence we get the round-robin delivery. But, if someone wanted to write a separate notification consumer so that they didn’t block anyone else from seeing the same messages then they (the consumer) should create a new queue on the existing topic exchange. Is that correct – and is there any worked example of doing this ? I thought within the nova code both the exchange and topic queues were set up by the consumer (so for example all compute_managers try to create the “compute” exchange and topic queue, but its only created by the first one and the others connect to the same queue). In that context I’m finding it hard to see how to change this model to have multiple “ notify.info” topic queues into the same exchange ? Cheers, Phil *From:* openstack-bounces+philip.day=hp@lists.launchpad.net [mailto: openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of *Doug Hellmann *Sent:* 08 May 2012 23:34 *To:* Russell Bryant *Cc:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? On Tue, May 8, 2012 at 6:04 PM, Russell Bryant rbry...@redhat.com wrote: On 05/08/2012 05:59 PM, Doug Hellmann wrote: Here is a relevant section pulled out of the amqp 0-9-1 spec: 3.1.3.3 The Topic Exchange Type The topic exchange type works as follows: 1. A message queue binds to the exchange using a routing pattern, P. 2. A publisher sends the exchange a message with the routing key R. 3. The message is passed to the message queue if R matches P.
Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout?
Is that the preferred way to do it, rather than attaching another queue to the existing exchange with the same routing key? On Wed, May 9, 2012 at 1:46 PM, Craig Vyvial cp16...@gmail.com wrote: You can allow nova to send notifications to multiple topics by setting this option in your nova.conf. ## (ListOpt) AMQP topic used for Nova notifications notification_topics=notifications,metering,monitoring This will allow you to consume all the messages from a different service. On Wed, May 9, 2012 at 10:34 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Wed, May 9, 2012 at 6:42 AM, Kiall Mac Innes ki...@managedit.iewrote: Kinda! The queue has a name, but that name has no bearing on the set of messages received. If you create a queue called MyCustomNotificationQueue, you can bind that to the notifications exchange using the notifications.info routing key. (I'm guessing some of the names here.. I know AMQP, and not the specific naming nova uses!) notifications.info is right. Nova just happens to use the same queue name and routing key. I believe this is causing the confusion. Exactly. I ended up creating a separate queue for each client that I have and setting them to auto-delete when the client disconnects. That way I can have as many clients connecting and listening as I want. The code is in https://github.com/dhellmann/metering-prototype if you want to take a look. Does this make sense? Anyway - The RabbitMQ docs probably explain it better than I.. http://www.rabbitmq.com/tutorials/tutorial-five-python.html Thanks, Kiall On Wed, May 9, 2012 at 11:30 AM, Day, Phil philip@hp.com wrote: OK, get that so far – so both consumers need to declare and use the same exchange. ** ** But If I understand the next step right, to get multiple consumers of info notification messages they would all need to create separate “ notifications.info” queues into that exchange.And isn’t that exactly what Nova currently does to create a shared queue ? ** ** Phil ** ** *From:* Kiall Mac Innes [mailto:ki...@managedit.ie] *Sent:* 09 May 2012 10:51 *To:* Day, Phil *Cc:* openstack@lists.launchpad.net; Russell Bryant; Doug Hellmann *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? ** ** Your own queue listener should attempt to declare the exchange, using the same settings as Nova does. If the exchange exists, its a noop. Otherwise it's created for you. After that, if you start up Nova, it will do the same and reuse your exchange. Obviously this works both ways, and either nova or your code can declare the exchange. AMQP is designed to be a configuration-less protocol, where resources are configured by the first consumer attempting to use them. Thanks, Kiall Sent from my phone. On May 9, 2012 9:52 a.m., Day, Phil philip@hp.com wrote: Hi Doug, I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given notification. That's only true if each client is consuming from the same queue bound to the exchange. So just to be clear, if I understand you correctly within the nova service/rpc abstraction layers the code is set up so that all services do bind to the same queue, and hence we get the round-robin delivery. But, if someone wanted to write a separate notification consumer so that they didn’t block anyone else from seeing the same messages then they (the consumer) should create a new queue on the existing topic exchange. Is that correct – and is there any worked example of doing this ? I thought within the nova code both the exchange and topic queues were set up by the consumer (so for example all compute_managers try to create the “compute” exchange and topic queue, but its only created by the first one and the others connect to the same queue). In that context I’m finding it hard to see how to change this model to have multiple “ notify.info” topic queues into the same exchange ? Cheers, Phil *From:* openstack-bounces+philip.day=hp@lists.launchpad.net[mailto: openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of *Doug Hellmann *Sent:* 08 May 2012 23:34 *To:* Russell Bryant *Cc:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? On Tue, May 8, 2012 at 6:04 PM, Russell Bryant rbry...@redhat.com wrote: On 05/08/2012 05:59 PM, Doug Hellmann wrote: Here is a relevant section pulled out of the amqp 0-9-1 spec: 3.1.3.3 The Topic Exchange Type The topic exchange type works as follows: 1. A message queue binds to the exchange using a routing
Re: [Openstack] [Metering] schema and counter definitions
On Wed, May 9, 2012 at 12:42 PM, Tomasz Paszkowski ss7...@gmail.com wrote: Here is the simplified version of my code (without ampq support, counter stored directly to mysql db). https://github.com/ss7pro/rescnt Code is started from main.py which is constantly collecting counters from libvirt and storing them in a mysql database. Nice! For production code I think we are going to want to separate collection from storage, aren't we? We don't want each compute node to require access to the database server (that's an issue with nova that they are trying to fix during the folsom release, IIRC). On Mon, May 7, 2012 at 9:25 PM, Tomasz Paszkowski ss7...@gmail.com wrote: On Mon, May 7, 2012 at 5:21 PM, Loic Dachary l...@enovance.com wrote: Hi Tomasz, Hi I could not agree more and this is the reason why I/O shows in the list of meters shown in http://wiki.openstack.org/EfficientMetering (c5) disk IO in megabyte per second has a high impact on the service availability and could be billed separately . Yes but for disk drives I/O (number of read/write ops) are the key resource usage information. It's very hard to setup a billing model for disk drive usage on bandwidth as low bandwidth disk operations (small random read/writes) can utilize disk drive more than huge sequential reads/writes. I need also to mention that AWS is also charging for I/O in their volume service. It looks like you already have a codebase that could be useful for the metering implementation. Would you be willing to share it ? Yes. Just give me few days. -- Tomasz Paszkowski SS7, Asterisk, SAN, Datacenter, Cloud Computing +48500166299 -- Tomasz Paszkowski SS7, Asterisk, SAN, Datacenter, Cloud Computing +48500166299 ___ 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] ERROR: Malformed request url (HTTP 400)
Hi all from sunny Kiev!
Have the problem below:
$ nova image-list
ERROR: Malformed request url (HTTP 400)
$ nova --debug image-list
connect: (192.168.1.71, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost:
192.168.1.71:5000\r\nContent-Length: 117\r\ncontent-type:
application/json\r\naccept-encoding: gzip, deflate\r\naccept:
application/json\r\nuser-agent: python-novaclient\r\n\r\n{auth:
{tenantName: labSpaceDemo, passwordCredentials: {username:
adminUser, password: lfplhfgthvf}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Type: application/json
header: Vary: X-Auth-Token
header: Date: Wed, 09 May 2012 18:23:48 GMT
header: Transfer-Encoding: chunked
connect: (192.168.1.71, 8774)
send: u'GET /v2/7033300637bc4964a8d0a43649fcf898/images/detail
HTTP/1.1\r\nHost: 192.168.1.71:8774\r\nx-auth-project-id:
labSpaceDemo\r\nx-auth-token:
65e6d91f80f047a7b1a49ede0aa7c0f1\r\naccept-encoding: gzip,
deflate\r\naccept: application/json\r\nuser-agent:
python-novaclient\r\n\r\n'
reply: 'HTTP/1.1 400 Bad Request\r\n'
header: Content-Length: 65
header: Content-Type: application/json; charset=UTF-8
header: X-Compute-Request-Id: req-faef2b77-9f53-4849-b0f5-c0508fe2cf21
header: Date: Wed, 09 May 2012 18:23:48 GMT
DEBUG (shell:416) Malformed request url (HTTP 400)
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 413, in main
OpenStackComputeShell().main(sys.argv[1:])
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 364, in main
args.func(self.cs, args)
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/shell.py,
line 350, in do_image_list
image_list = cs.images.list()
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/images.py,
line 47, in list
return self._list(/images/detail, images)
File /usr/lib/python2.7/dist-packages/novaclient/base.py, line 71, in _list
resp, body = self.api.client.get(url)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 136, in get
return self._cs_request(url, 'GET', **kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line
124, in _cs_request
**kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line
107, in request
raise exceptions.from_response(resp, body)
BadRequest: Malformed request url (HTTP 400)
ERROR: Malformed request url (HTTP 400)
At the same time $ glance index works well.
And I have --auth_strategy=keystone in my nova.conf.
--
Igor Laskovy
___
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 Core Cleanup
On Wed, 2012-05-09 at 11:34 +0100, Mark McLoughlin wrote: I rarely -2, because I see it as a strong veto which blocks the patch or later revisions of the patch until I remove the -2. Maybe it's just the fact that I know I'm likely to be slow to come back and review later revisions of a patch that I've put a -2 on. Maybe I should just fix that :-) Ok, here's what I'm going to try - it might help others too I've set up a filter to catch mails containing: Gerrit-Reviewer: Mark McLoughlin and move them into a myreviews folder. That way I separate follow-ups to my reviews from all the rest of the gerrit spam Cheers, Mark. ___ 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] [Netstack] About python versions that we are planning to support
I'm concerned about a need to support python 2.4 as well, especially if it would have a ripple effect into openstack-common, which otherwise does not have that requirement. With XenServer, nova-compute actually runs in a service VM (which is running a modern version of python). I believe Salvatore or others may have done some work around forcing network traffic through this service VM to allow iptables rules from nova-compute / nova-network to be enforced, but I'm not familiar enough with that work to say for sure. Can anyone shed light on this? Another option would be to just create a simple Quantum plugin specific to XenServer that doesn't require an agent. This plugin could use XAPI to create networks, but as a result might only support a base feature set (e.g., L2 connectivity using VLANs). Dan On Wed, May 9, 2012 at 9:07 AM, Robert Kukura rkuk...@redhat.com wrote: [I'm moving this thread to the openstack list because it potentially impacts openstack-common.] On 05/07/2012 11:53 PM, Maru Newby wrote: Hi, Python 2.4 compatibility is required, but only for agent code. Agent code needs to be deployable on Xen dom0, which uses CentoOS 5.5 and only supports 2.4 out of the box. Maru, I'm very concerned about the potential of this XenServer/XCP requirement to interfere with making the various Quantum agents first-class OpenStack services by utilizing current and future openstack-common facilities for configuration, logging, DB, RPC, etc.. Are there any other possible ways forward here? How is the nova compute service currently handled for XenServer? Could a fully supported version of python be parallel-installed on dom0? Could the actual quantum agent run somewhere else and remotely execute commands on dom0? Or does the python 2.4 compatibility requirement need to be applied to openstack-common? Thanks, -Bob Both quantum and nova have agent code that needs to be deployed to dom0, but up until now both projects have relied on savvy reviewers and bug reports to ensure compatibility. I'm working on it, though. I'll be adding a tox build to quantum that will run agent tests - and agent tests only - under 2.4, and then openstack-ci can add a jenkins job to run that build on CentOS and gate merges. The relevant bug: https://bugs.launchpad.net/quantum/+bug/995278 Thanks, Maru On 2012-05-07, at 6:54 PM, Yong Sheng Gong wrote: Hi, I see some ones are trying to support python2.4. But our tox.ini under quantum is only supporting test py26 and py27. So my question is if we are trying to support py24. In addition I remember that we will support py30. As far as I know, py2.4 does not support many new syntaxes introduced by py2.5+. Other projects such as nova, horizon are also adopting some of these new syntaxes. Moreover some third party components such as Django 1.4 required by horizon are only tested under py2.6 and py2.7. So if py2.4 is out of our scope, we should stop that trying. If we need py2.4, we have to make all of us know it and keep our code 2.4 compatible. Thanks Yong Sheng Gong -- Mailing list: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net mailto:netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack 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 -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~ ___ 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] schema and counter definitions
On Wed, May 9, 2012 at 8:02 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Nice! For production code I think we are going to want to separate collection from storage, aren't we? We don't want each compute node to require access to the database server (that's an issue with nova that they are trying to fix during the folsom release, IIRC). Yes. Part of the code responsible for amqp support is not functional yet :( -- Tomasz Paszkowski SS7, Asterisk, SAN, Datacenter, Cloud Computing +48500166299 ___ 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] Instances can't access eachother via external (floating) ips?
On 04/25/2012 01:03 PM, Calvin Walton wrote: On Mon, 2012-04-23 at 06:45 -0700, Mike Scherbakov wrote: Hi Calvin, Sorry I didn't respond earlier, the email temporarily got lost :) show us iptables -nL -t nat | grep NAT on the node with nova-network. (192.168.0.101 is the nova-network node's external address) DNAT all -- 0.0.0.0/0192.168.0.33to:192.168.22.35 DNAT all -- 0.0.0.0/0192.168.0.88 to:192.168.22.41 ACCEPT all -- 192.168.22.32/27 192.168.22.32/27 ! ctstate DNAT DNAT tcp -- 0.0.0.0/0169.254.169.254 tcp dpt:80 to:192.168.0.101:8775 DNAT all -- 0.0.0.0/0192.168.0.33 to:192.168.22.35 DNAT all -- 0.0.0.0/0192.168.0.88 to:192.168.22.41 SNAT all -- 192.168.22.350.0.0.0/0to:192.168.0.33 SNAT all -- 192.168.22.410.0.0.0/0to:192.168.0.88 SNAT all -- 192.168.22.32/27 0.0.0.0/0to:192.168.0.101 Note that the nova-network is actually colocated on a machine that also runs nova-compute; this is a small 2-node lab deployment. Could it be that your fixed_range flag in nova.conf covers both subnets, like 192.168.0.0/16 ? My fixed_range is very small, and doesn't overlap: --fixed_range=192.168.22.32/27 Second reason - I presume that the traffic from VM will go via your router if you access another VM via floating IP, so router should know the route to 192.168.0.x (static/ospf?) 192.168.0.x is the office network, and communication between other machines on that network and the router on that network all work fine. In the course of trying some other things out, I found that when I enabled ipv4 forwarding on the nova-network box: echo 1 /proc/sys/net/ipv4/ip_forward Then the virtual machines /were/ able to communicate with each-other via their floating IP addresses. I'm still not sure about what's going on, but it's good enough for our lab use now. In lab environments where openstack network isn't routed, you will need some special magic. Linux iptables doesn't allow a nat through a nat. Read more details here: https://github.com/heat-api/heat/wiki/Configuring-Floating-IPs Regards, On Fri, Apr 20, 2012 at 7:03 AM, Calvin Walton calvin.wal...@kepstin.ca wrote: Hi, I have instances running in Openstack using FlatDHCP networking mode. Each one has an IP address in the internal subnet (192.168.22.x) and a floating IP from the external subnet (192.168.0.x). I've found that from one instance, I cannot connect to another instance (or, in fact, even the same instance) via the external floating address (I have some monitoring tools that attempt to do this to verify that a server is running). Connections from external computers work fine. My best guess is that there is an issue with the NAT on my nova-network node not allowing loopback connections. Is this intentional, or a bug? Is there a workaround available? For reference, I'm currently using OpenStack from the 'latest-milestone-test' OpenStack PPA on Ubuntu 12.04 Precise. ___ 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] why does notification use a topic exchange instead of fanout?
Hi Doug, not sure if you've hit the same problem, but I've spent some time on that when I started using RabbitMQ. As I see from the example, you've provided: queue = Queue(name='notifications.info', exchange=Exchange(name='nova'... So you set explicitly a name for the queue. If you have two queues declared with the same name, when they are bound to an Exchange, actually each message is received only by the one queue at a time. Just leave the name field empty(it will be auto-generated), and each queue will receive its copy of the message. So the logic is that the first queue with that name acknowledges the message, and the other one receives nothing. Besides that, the topics are more powerful and handy to use than fanout. On Wed, May 9, 2012 at 6:34 PM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Wed, May 9, 2012 at 6:42 AM, Kiall Mac Innes ki...@managedit.iewrote: Kinda! The queue has a name, but that name has no bearing on the set of messages received. If you create a queue called MyCustomNotificationQueue, you can bind that to the notifications exchange using the notifications.info routing key. (I'm guessing some of the names here.. I know AMQP, and not the specific naming nova uses!) notifications.info is right. Nova just happens to use the same queue name and routing key. I believe this is causing the confusion. Exactly. I ended up creating a separate queue for each client that I have and setting them to auto-delete when the client disconnects. That way I can have as many clients connecting and listening as I want. The code is in https://github.com/dhellmann/metering-prototype if you want to take a look. Does this make sense? Anyway - The RabbitMQ docs probably explain it better than I.. http://www.rabbitmq.com/tutorials/tutorial-five-python.html Thanks, Kiall On Wed, May 9, 2012 at 11:30 AM, Day, Phil philip@hp.com wrote: OK, get that so far – so both consumers need to declare and use the same exchange. ** ** But If I understand the next step right, to get multiple consumers of info notification messages they would all need to create separate “ notifications.info” queues into that exchange.And isn’t that exactly what Nova currently does to create a shared queue ? ** ** Phil ** ** *From:* Kiall Mac Innes [mailto:ki...@managedit.ie] *Sent:* 09 May 2012 10:51 *To:* Day, Phil *Cc:* openstack@lists.launchpad.net; Russell Bryant; Doug Hellmann *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? ** ** Your own queue listener should attempt to declare the exchange, using the same settings as Nova does. If the exchange exists, its a noop. Otherwise it's created for you. After that, if you start up Nova, it will do the same and reuse your exchange. Obviously this works both ways, and either nova or your code can declare the exchange. AMQP is designed to be a configuration-less protocol, where resources are configured by the first consumer attempting to use them. Thanks, Kiall Sent from my phone. On May 9, 2012 9:52 a.m., Day, Phil philip@hp.com wrote: Hi Doug, I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given notification. That's only true if each client is consuming from the same queue bound to the exchange. So just to be clear, if I understand you correctly within the nova service/rpc abstraction layers the code is set up so that all services do bind to the same queue, and hence we get the round-robin delivery. But, if someone wanted to write a separate notification consumer so that they didn’t block anyone else from seeing the same messages then they (the consumer) should create a new queue on the existing topic exchange. Is that correct – and is there any worked example of doing this ? I thought within the nova code both the exchange and topic queues were set up by the consumer (so for example all compute_managers try to create the “compute” exchange and topic queue, but its only created by the first one and the others connect to the same queue). In that context I’m finding it hard to see how to change this model to have multiple “ notify.info” topic queues into the same exchange ? Cheers, Phil *From:* openstack-bounces+philip.day=hp@lists.launchpad.net [mailto: openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of *Doug Hellmann *Sent:* 08 May 2012 23:34 *To:* Russell Bryant *Cc:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? On Tue, May 8, 2012 at 6:04 PM, Russell Bryant rbry...@redhat.com wrote: On 05/08/2012 05:59
Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout?
On Wed, May 9, 2012 at 3:17 PM, Tihomir Trifonov t.trifo...@gmail.comwrote: Hi Doug, not sure if you've hit the same problem, but I've spent some time on that when I started using RabbitMQ. As I see from the example, you've provided: queue = Queue(name='notifications.info', exchange=Exchange(name='nova'... So you set explicitly a name for the queue. If you have two queues declared with the same name, when they are bound to an Exchange, actually each message is received only by the one queue at a time. Just leave the name field empty(it will be auto-generated), and each queue will receive its copy of the message. So the logic is that the first queue with that name acknowledges the message, and the other one receives nothing. Besides that, the topics are more powerful and handy to use than fanout. Now that I see how it works, I agree. :-) On Wed, May 9, 2012 at 6:34 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Wed, May 9, 2012 at 6:42 AM, Kiall Mac Innes ki...@managedit.iewrote: Kinda! The queue has a name, but that name has no bearing on the set of messages received. If you create a queue called MyCustomNotificationQueue, you can bind that to the notifications exchange using the notifications.info routing key. (I'm guessing some of the names here.. I know AMQP, and not the specific naming nova uses!) notifications.info is right. Nova just happens to use the same queue name and routing key. I believe this is causing the confusion. Exactly. I ended up creating a separate queue for each client that I have and setting them to auto-delete when the client disconnects. That way I can have as many clients connecting and listening as I want. The code is in https://github.com/dhellmann/metering-prototype if you want to take a look. Does this make sense? Anyway - The RabbitMQ docs probably explain it better than I.. http://www.rabbitmq.com/tutorials/tutorial-five-python.html Thanks, Kiall On Wed, May 9, 2012 at 11:30 AM, Day, Phil philip@hp.com wrote: OK, get that so far – so both consumers need to declare and use the same exchange. ** ** But If I understand the next step right, to get multiple consumers of info notification messages they would all need to create separate “ notifications.info” queues into that exchange.And isn’t that exactly what Nova currently does to create a shared queue ? ** ** Phil ** ** *From:* Kiall Mac Innes [mailto:ki...@managedit.ie] *Sent:* 09 May 2012 10:51 *To:* Day, Phil *Cc:* openstack@lists.launchpad.net; Russell Bryant; Doug Hellmann *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout? ** ** Your own queue listener should attempt to declare the exchange, using the same settings as Nova does. If the exchange exists, its a noop. Otherwise it's created for you. After that, if you start up Nova, it will do the same and reuse your exchange. Obviously this works both ways, and either nova or your code can declare the exchange. AMQP is designed to be a configuration-less protocol, where resources are configured by the first consumer attempting to use them. Thanks, Kiall Sent from my phone. On May 9, 2012 9:52 a.m., Day, Phil philip@hp.com wrote: Hi Doug, I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given notification. That's only true if each client is consuming from the same queue bound to the exchange. So just to be clear, if I understand you correctly within the nova service/rpc abstraction layers the code is set up so that all services do bind to the same queue, and hence we get the round-robin delivery. But, if someone wanted to write a separate notification consumer so that they didn’t block anyone else from seeing the same messages then they (the consumer) should create a new queue on the existing topic exchange. Is that correct – and is there any worked example of doing this ? I thought within the nova code both the exchange and topic queues were set up by the consumer (so for example all compute_managers try to create the “compute” exchange and topic queue, but its only created by the first one and the others connect to the same queue). In that context I’m finding it hard to see how to change this model to have multiple “ notify.info” topic queues into the same exchange ? Cheers, Phil *From:* openstack-bounces+philip.day=hp@lists.launchpad.net[mailto: openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of *Doug Hellmann *Sent:* 08 May 2012 23:34 *To:* Russell Bryant *Cc:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] [nova] why does notification use a topic exchange
Re: [Openstack] Floating IPs don't get dissociated after delete
This definitely sounds like a bug. Floating Ips should be automatically disassociated on delete Vish On May 9, 2012, at 8:26 AM, Steven Dake wrote: On 05/09/2012 07:20 AM, Bilel Msekni wrote: Hi , I am having this problem just like many others. Each time I delete a VM, the floating IP doesn't get automatically dissociated, has anyone encountred this problem and solved it ? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Bilel, We had this problem in openstack during our floating ip implementation of heat (http://www.heat-api.org). We solved it by using the floating ip.delete api in nova. See: https://github.com/heat-api/heat/blob/master/heat/engine/eip.py line 118 The program flow on delete is: delete an instance wait for instance to disappear delete floating ip Regards -steve ___ 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 Core Cleanup
The problem here is there are two opposing points: the idea that there are too many core reviewers, and the idea that patches aren't being reviewed fast enough. *Drags a yak into the room* Beyond that, what makes 20 better than 25, or 15, especially in light of the fact that we're not happy with how quickly reviews are moving? It seems like the answer here isn't just quantity, but a matter of focus and relative skill sets. I'm a core developer but, beyond code quality, I couldn't review in the best interests of functionality in and around KVM. Conversely, I'm sure most core developers couldn't do any better for XenServer. I liked the idea of lieutenants when it first came up almost 2 years ago. Have we talked about reinstating that? On 5/9/12 5:34 AM, Mark McLoughlin mar...@redhat.com wrote: On Tue, 2012-05-08 at 15:44 -0700, Vishvananda Ishaya wrote: The -2 issue is a good point. I personally treat a -1 (or +1) from the author of a given piece of code quite strongly when I do reviews, but you're right that the -1 could be more trivially overridden. Coincidentally, dprince and I discussed this a bit yesterday. I rarely -2, because I see it as a strong veto which blocks the patch or later revisions of the patch until I remove the -2. Maybe it's just the fact that I know I'm likely to be slow to come back and review later revisions of a patch that I've put a -2 on. Maybe I should just fix that :-) On the flip-side, I respect (and expect others to respect) a -1 from a core reviewer when reviewing later revisions of a patch - i.e. if I see a -1 from a core reviewer, then I check that the later revisions of the patch have actually addressed the previous concerns. If core reviewers' concerns are consistently ignored, that'd definitely cause me to pull out the big old -2. The removal is primarily to keep core a manageable size. We currently have 25 core members and still have many patches that are not being quickly reviewed. Giving too many people the ability to approve patches leads to inconsistency in code and the review process. It seems like overkill to have 20 people. I expect this number to decrease further if out plans to create substystem branches materialize. I agree, FWIW. 20 seems like the right number, more than that and I think folks assume someone else will do it, core membership isn't for life, the requirement that core members are actually active is a great incentive to do reviews, folks can easily be re-added again later, etc. etc. Cheers, Mark. ___ 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] why does notification use a topic exchange instead of fanout?
On 05/09/2012 01:57 PM, Doug Hellmann wrote: Is that the preferred way to do it, rather than attaching another queue to the existing exchange with the same routing key? I would just do what you're doing now, which is to use the existing exchange. That lets the message broker do the work of duplicating the message as opposed to making nova send the message multiple times. Perhaps using another exchange would make sense if it made ACLs easier for ensuring that an application can only get notifications, and nothing else on the nova exchange. -- 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] ERROR: Malformed request url (HTTP 400)
The request URL is actually fine, but the request body is quite malformed:
{tenantName: labSpaceDemo, passwordCredentials: {username:
adminUser,
password: lfplhfgthvf}}}
What's there would be just fine if it were wrapped in an auth element
(see http://keystone.openstack.org/api_curl_examples.html#id4 ):
{auth: {tenantName: labSpaceDemo, passwordCredentials:
{username: adminUser, password: lfplhfgthvf
-Dolph
On Wed, May 9, 2012 at 1:25 PM, Igor Laskovy igor.lask...@gmail.com wrote:
Hi all from sunny Kiev!
Have the problem below:
$ nova image-list
ERROR: Malformed request url (HTTP 400)
$ nova --debug image-list
connect: (192.168.1.71, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost:
192.168.1.71:5000\r\nContent-Length: 117\r\ncontent-type:
application/json\r\naccept-encoding: gzip, deflate\r\naccept:
application/json\r\nuser-agent: python-novaclient\r\n\r\n{auth:
{tenantName: labSpaceDemo, passwordCredentials: {username:
adminUser, password: lfplhfgthvf}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Type: application/json
header: Vary: X-Auth-Token
header: Date: Wed, 09 May 2012 18:23:48 GMT
header: Transfer-Encoding: chunked
connect: (192.168.1.71, 8774)
send: u'GET /v2/7033300637bc4964a8d0a43649fcf898/images/detail
HTTP/1.1\r\nHost: 192.168.1.71:8774\r\nx-auth-project-id:
labSpaceDemo\r\nx-auth-token:
65e6d91f80f047a7b1a49ede0aa7c0f1\r\naccept-encoding: gzip,
deflate\r\naccept: application/json\r\nuser-agent:
python-novaclient\r\n\r\n'
reply: 'HTTP/1.1 400 Bad Request\r\n'
header: Content-Length: 65
header: Content-Type: application/json; charset=UTF-8
header: X-Compute-Request-Id: req-faef2b77-9f53-4849-b0f5-c0508fe2cf21
header: Date: Wed, 09 May 2012 18:23:48 GMT
DEBUG (shell:416) Malformed request url (HTTP 400)
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 413, in
main
OpenStackComputeShell().main(sys.argv[1:])
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 364, in
main
args.func(self.cs, args)
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/shell.py,
line 350, in do_image_list
image_list = cs.images.list()
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/images.py,
line 47, in list
return self._list(/images/detail, images)
File /usr/lib/python2.7/dist-packages/novaclient/base.py, line 71, in
_list
resp, body = self.api.client.get(url)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 136,
in get
return self._cs_request(url, 'GET', **kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line
124, in _cs_request
**kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line
107, in request
raise exceptions.from_response(resp, body)
BadRequest: Malformed request url (HTTP 400)
ERROR: Malformed request url (HTTP 400)
At the same time $ glance index works well.
And I have --auth_strategy=keystone in my nova.conf.
--
Igor Laskovy
___
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] ERROR: Malformed request url (HTTP 400)
It also just occurred to me that perhaps you're using a *very* old
novaclient against a more recent version of keystone?
-Dolph
On Wed, May 9, 2012 at 3:30 PM, Dolph Mathews dolph.math...@gmail.comwrote:
The request URL is actually fine, but the request body is quite malformed:
{tenantName: labSpaceDemo, passwordCredentials: {username:
adminUser,
password: lfplhfgthvf}}}
What's there would be just fine if it were wrapped in an auth element
(see http://keystone.openstack.org/api_curl_examples.html#id4 ):
{auth: {tenantName: labSpaceDemo, passwordCredentials:
{username: adminUser, password: lfplhfgthvf
-Dolph
On Wed, May 9, 2012 at 1:25 PM, Igor Laskovy igor.lask...@gmail.comwrote:
Hi all from sunny Kiev!
Have the problem below:
$ nova image-list
ERROR: Malformed request url (HTTP 400)
$ nova --debug image-list
connect: (192.168.1.71, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost:
192.168.1.71:5000\r\nContent-Length: 117\r\ncontent-type:
application/json\r\naccept-encoding: gzip, deflate\r\naccept:
application/json\r\nuser-agent: python-novaclient\r\n\r\n{auth:
{tenantName: labSpaceDemo, passwordCredentials: {username:
adminUser, password: lfplhfgthvf}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Type: application/json
header: Vary: X-Auth-Token
header: Date: Wed, 09 May 2012 18:23:48 GMT
header: Transfer-Encoding: chunked
connect: (192.168.1.71, 8774)
send: u'GET /v2/7033300637bc4964a8d0a43649fcf898/images/detail
HTTP/1.1\r\nHost: 192.168.1.71:8774\r\nx-auth-project-id:
labSpaceDemo\r\nx-auth-token:
65e6d91f80f047a7b1a49ede0aa7c0f1\r\naccept-encoding: gzip,
deflate\r\naccept: application/json\r\nuser-agent:
python-novaclient\r\n\r\n'
reply: 'HTTP/1.1 400 Bad Request\r\n'
header: Content-Length: 65
header: Content-Type: application/json; charset=UTF-8
header: X-Compute-Request-Id: req-faef2b77-9f53-4849-b0f5-c0508fe2cf21
header: Date: Wed, 09 May 2012 18:23:48 GMT
DEBUG (shell:416) Malformed request url (HTTP 400)
Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 413,
in main
OpenStackComputeShell().main(sys.argv[1:])
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 364,
in main
args.func(self.cs, args)
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/shell.py,
line 350, in do_image_list
image_list = cs.images.list()
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/images.py,
line 47, in list
return self._list(/images/detail, images)
File /usr/lib/python2.7/dist-packages/novaclient/base.py, line 71, in
_list
resp, body = self.api.client.get(url)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 136,
in get
return self._cs_request(url, 'GET', **kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line
124, in _cs_request
**kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line
107, in request
raise exceptions.from_response(resp, body)
BadRequest: Malformed request url (HTTP 400)
ERROR: Malformed request url (HTTP 400)
At the same time $ glance index works well.
And I have --auth_strategy=keystone in my nova.conf.
--
Igor Laskovy
___
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] Keystone client, user belongs to many tenants?
A question,
I am using anvil to setup the keystone roles/users/tenants.
It seems like the python keystone client has the following command:
client.users.create
Which seems to take in the following:
create(self, name, password, email, tenant_id=None, enabled=True):
I would assume a user name can be used in multiple tenants but when I am trying
to create a user that spans tenants and it seems like it borks.
ClientException: Conflict occurred attempting to store user. (IntegrityError)
(1062, Duplicate entry 'admin' for key 'name') 'INSERT INTO user (id, name,
extra) VALUES (%s, %s, %s)' ('3e14a9c1fd404c7e81c0dba8bd640575', 'admin',
'{password:
$6$rounds=4$yX5fL51OyGKjuPjr$8yv.S3GpqsKeaHv4GjNY4YW2vvykWzrEV7RX.qJpyy3CjmyXrZMRRJifEzfa7xv1l.NzoggQBXUAESn3Oqm0x/,
enabled: true, email: ad...@example.com, tenantId:
d1506184877a449a91fc6adcb553ad97}') (HTTP 409)
Is this supposed to happen? Is the client supposed to send back this much info
also (hashed password??) :-P
Any ideas?
___
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] [Netstack] About python versions that we are planning to support
On Wed, May 09, 2012, Robert Kukura rkuk...@redhat.com wrote: I'm very concerned about the potential of this XenServer/XCP requirement to interfere with making the various Quantum agents first-class OpenStack services by utilizing current and future openstack-common facilities for configuration, logging, DB, RPC, etc.. Are there any other possible ways forward here? How is the nova compute service currently handled for XenServer? Could a fully supported version of python be parallel-installed on dom0? Could the actual quantum agent run somewhere else and remotely execute commands on dom0? Or does the python 2.4 compatibility requirement need to be applied to openstack-common? I'm confused what openstack-common has to do with the dom0 plugins? I don't know what these Quantum agents do, but it sounds like they are trying to do too much on the XS dom0. Why would you want to communicate with the DB or RPC from dom0? The nova plugins (which exist in plugins/xenserver/xenapi) are basically the minimal amount of code that is necessary to run on dom0. I'm not a fan of how XenServer userspace is lagging and is only Python 2.4, but Nova has been able to develop plugins with only a couple of workarounds necessary. I'm not sure I understand what Quantum is doing and why it appears to want to do so much on dom0. JE ___ 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 Core Cleanup
On Wed, 2012-05-09 at 19:58 +, Matt Dietz wrote: The problem here is there are two opposing points: the idea that there are too many core reviewers, and the idea that patches aren't being reviewed fast enough. *Drags a yak into the room* Beyond that, what makes 20 better than 25, or 15, especially in light of the fact that we're not happy with how quickly reviews are moving? I think the idea is that letting core reviewers know that their membership of core is dependent on them actually doing reviews is an incentive for core members to be more active reviewers. It seems like the answer here isn't just quantity, but a matter of focus and relative skill sets. I'm a core developer but, beyond code quality, I couldn't review in the best interests of functionality in and around KVM. Conversely, I'm sure most core developers couldn't do any better for XenServer. I liked the idea of lieutenants when it first came up almost 2 years ago. Have we talked about reinstating that? Yes, see the Nova subsystem branches and feature branches thread this week Cheers, Mark. ___ 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] Bootstrapping, first counter implementation
On Wed, May 9, 2012 at 11:13 AM, Julien Danjou julien.dan...@enovance.comwrote: Hi there, I've added a first script that's able to connect to the AMQP notification queue using Nova RPC module. Later it will be able to treat them when we'll know what to do with them. https://review.stackforge.org/#/c/26/ https://review.stackforge.org/#/c/27/ https://review.stackforge.org/#/c/28/ I wish I could use nova.service.Service, but the code is too RPC oriented so that it can't grab notification from the notifier, so for now the daemon is rather simple. I'm not sure what you mean. I was able to use nova.service to create a metering server and a simple manager that subscribes to the notification events. See https://github.com/dhellmann/metering-prototype (metering-test is the main program and testmanager.py is the manager class). I borrowed your Connection code. -- 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 ___ 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] schema and counter definitions
On Wed, May 9, 2012 at 3:07 PM, Tomasz Paszkowski ss7...@gmail.com wrote: On Wed, May 9, 2012 at 8:02 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Nice! For production code I think we are going to want to separate collection from storage, aren't we? We don't want each compute node to require access to the database server (that's an issue with nova that they are trying to fix during the folsom release, IIRC). Yes. Part of the code responsible for amqp support is not functional yet :( OK, that's what I thought. We all seem to be reinventing different parts of the services that we will eventually need, which is good for education but may be wasting a bit of energy. Is it premature to start talking a little more about architecture so we can start splitting up the implementation work and focusing that energy differently? There is a lot of work we can do independently of the remaining decisions outlined in http://wiki.openstack.org/Meetings/MeteringAgenda. -- Tomasz Paszkowski SS7, Asterisk, SAN, Datacenter, Cloud Computing +48500166299 ___ 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] Instances can't access eachother via external (floating) ips?
On 05/09/2012 02:09 PM, Steven Dake wrote: Read more details here: https://github.com/heat-api/heat/wiki/Configuring-Floating-IPs Is there a reason this is on a GitHub wiki versus on the official OpenStack wiki and/or the documentation? Seems like some great information that really should be shared... -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Metering] schema and counter definitions
I agree. Do you have any plans how to coordinate our efforts ? On Wed, May 9, 2012 at 11:11 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Wed, May 9, 2012 at 3:07 PM, Tomasz Paszkowski ss7...@gmail.com wrote: On Wed, May 9, 2012 at 8:02 PM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Nice! For production code I think we are going to want to separate collection from storage, aren't we? We don't want each compute node to require access to the database server (that's an issue with nova that they are trying to fix during the folsom release, IIRC). Yes. Part of the code responsible for amqp support is not functional yet :( OK, that's what I thought. We all seem to be reinventing different parts of the services that we will eventually need, which is good for education but may be wasting a bit of energy. Is it premature to start talking a little more about architecture so we can start splitting up the implementation work and focusing that energy differently? There is a lot of work we can do independently of the remaining decisions outlined in http://wiki.openstack.org/Meetings/MeteringAgenda. -- Tomasz Paszkowski SS7, Asterisk, SAN, Datacenter, Cloud Computing +48500166299 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Tomasz Paszkowski SS7, Asterisk, SAN, Datacenter, Cloud Computing +48500166299 ___ 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] ERROR: Malformed request url (HTTP 400)
On Wed, 2012-05-09 at 15:32 -0500, Dolph Mathews wrote:
It also just occurred to me that perhaps you're using a *very* old
novaclient against a more recent version of keystone?
Actually, if you look a little more closely:
$ nova --debug image-list
connect: (192.168.1.71, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost:
192.168.1.71:5000\r\nContent-Length: 117\r
\ncontent-type:
application/json\r\naccept-encoding: gzip, deflate\r
\naccept:
application/json\r\nuser-agent: python-novaclient\r\n
\r\n{auth:
{tenantName: labSpaceDemo, passwordCredentials:
{username:
adminUser, password: lfplhfgthvf}}}'
The request body for Keystone is not, in fact, malformed. It would be
interesting to look at the nova-api logs for this request…
--
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
[Openstack] 'nova flavor-list' fails with ERROR: string indices must be integers, not str, but 'nova-manage flavor list' succeeds.
Hey Folks, Any idea why 'nova flavor-list' (among other things) would fail with a 503 but 'nova-manage flavor list' succeeds? bash-4.1$ sudo nova-manage flavor list Password: m1.medium: Memory: 4096MB, VCPUS: 2, Root: 10GB, Ephemeral: 40Gb, FlavorID: 3, Swap: 0MB, RXTX Factor: 1.0 m1.large: Memory: 8192MB, VCPUS: 4, Root: 10GB, Ephemeral: 80Gb, FlavorID: 4, Swap: 0MB, RXTX Factor: 1.0 m1.tiny: Memory: 512MB, VCPUS: 1, Root: 0GB, Ephemeral: 0Gb, FlavorID: 1, Swap: 0MB, RXTX Factor: 1.0 m1.xlarge: Memory: 16384MB, VCPUS: 8, Root: 10GB, Ephemeral: 160Gb, FlavorID: 5, Swap: 0MB, RXTX Factor: 1.0 m1.small: Memory: 2048MB, VCPUS: 1, Root: 10GB, Ephemeral: 20Gb, FlavorID: 2, Swap: 0MB, RXTX Factor: 1.0 bash-4.1$ nova flavor-list ERROR: string indices must be integers, not str bash-4.1$ As an aside: That error is a result of a 503 being passed back in the body of the get, which is then blindly passed to the json parser, and missed by the resp.status check in client.py: if resp.status in (400, 401, 403, 404, 408, 409, 413, 500, 501): raise exceptions.from_response(resp, body) Adding a 503 to that status list above will at least cause it to fail correctly: bash-4.1$ nova flavor-list ERROR: n/a (HTTP 503) bash-4.1$ That said, help? Thanks! -James ___ 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 client, user belongs to many tenants?
users are defined as globally unique in keystone
what's anvil?
-joe
On May 9, 2012, at 1:46 PM, Joshua Harlow wrote:
A question,
I am using anvil to setup the keystone roles/users/tenants.
It seems like the python keystone client has the following command:
client.users.create
Which seems to take in the following:
create(self, name, password, email, tenant_id=None, enabled=True):
I would assume a user name can be used in multiple tenants but when I am
trying to create a user that spans tenants and it seems like it borks.
ClientException: Conflict occurred attempting to store user. (IntegrityError)
(1062, Duplicate entry 'admin' for key 'name') 'INSERT INTO user (id, name,
extra) VALUES (%s, %s, %s)' ('3e14a9c1fd404c7e81c0dba8bd640575', 'admin',
'{password:
$6$rounds=4$yX5fL51OyGKjuPjr$8yv.S3GpqsKeaHv4GjNY4YW2vvykWzrEV7RX.qJpyy3CjmyXrZMRRJifEzfa7xv1l.NzoggQBXUAESn3Oqm0x/,
enabled: true, email: ad...@example.com, tenantId:
d1506184877a449a91fc6adcb553ad97}') (HTTP 409)
Is this supposed to happen? Is the client supposed to send back this much
info also (hashed password??) :-P
Any ideas?
___
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] ERROR: Malformed request url (HTTP 400)
Hrm, good catch! I see no problems with that request at all...
-Dolph Mathews
On May 9, 2012, at 5:58 PM, Kevin L. Mitchell kevin.mitch...@rackspace.com
wrote:
On Wed, 2012-05-09 at 15:32 -0500, Dolph Mathews wrote:
It also just occurred to me that perhaps you're using a *very* old
novaclient against a more recent version of keystone?
Actually, if you look a little more closely:
$ nova --debug image-list
connect: (192.168.1.71, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost:
192.168.1.71:5000\r\nContent-Length: 117\r
\ncontent-type:
application/json\r\naccept-encoding: gzip, deflate\r
\naccept:
application/json\r\nuser-agent: python-novaclient\r\n
\r\n{auth:
{tenantName: labSpaceDemo, passwordCredentials:
{username:
adminUser, password: lfplhfgthvf}}}'
The request body for Keystone is not, in fact, malformed. It would be
interesting to look at the nova-api logs for this request…
--
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] Keystone client, user belongs to many tenants?
The user create command is actually creating discrete users, each with a
default tenant reference.
While that's fine for a lot of simple use cases, it doesn't directly support a
user accessing multiple tenants at all.
Instead, create a role, and grant that role to a user-tenant pair, creating an
explicit relationship between the two. Using default tenants is optional with
this method, but will affect how users must auth.
-Dolph Mathews
On May 9, 2012, at 3:46 PM, Joshua Harlow harlo...@yahoo-inc.com wrote:
A question,
I am using anvil to setup the keystone roles/users/tenants.
It seems like the python keystone client has the following command:
client.users.create
Which seems to take in the following:
create(self, name, password, email, tenant_id=None, enabled=True):
I would assume a user name can be used in multiple tenants but when I am
trying to create a user that spans tenants and it seems like it borks.
ClientException: Conflict occurred attempting to store user. (IntegrityError)
(1062, Duplicate entry 'admin' for key 'name') 'INSERT INTO user (id, name,
extra) VALUES (%s, %s, %s)' ('3e14a9c1fd404c7e81c0dba8bd640575', 'admin',
'{password:
$6$rounds=4$yX5fL51OyGKjuPjr$8yv.S3GpqsKeaHv4GjNY4YW2vvykWzrEV7RX.qJpyy3CjmyXrZMRRJifEzfa7xv1l.NzoggQBXUAESn3Oqm0x/,
enabled: true, email: ad...@example.com, tenantId:
d1506184877a449a91fc6adcb553ad97}') (HTTP 409)
Is this supposed to happen? Is the client supposed to send back this much
info also (hashed password??) :-P
Any ideas?
___
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] Beyond the Usergroups wiki page
Hello folks, if you manage a user group or want to create one or you're simply interested in OpenStack User Groups I would suggest to join this conversation: https://lists.launchpad.net/openstack-community/msg00081.html I'd like to gather the specifications for a system to keep a better directory of user groups, offer content for the international community in languages other than English and have a system to identify/contact all coordinators of user groups around the world. Your opinion is appreciated. In a couple of weeks I'd like to have fixed the specs for the system and move to the proof of concept/prototype phase. 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] Keystone client, user belongs to many tenants?
The tenant_id field on user creation is the default tenant for the user.
Adding a user to additional tenants is done by granting the user one or more
roles on those tenants.
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 Joshua Harlow
Sent: Wednesday, May 09, 2012 1:46 PM
To: openstack
Subject: [Openstack] Keystone client, user belongs to many tenants?
A question,
I am using anvil to setup the keystone roles/users/tenants.
It seems like the python keystone client has the following command:
client.users.create
Which seems to take in the following:
create(self, name, password, email, tenant_id=None, enabled=True):
I would assume a user name can be used in multiple tenants but when I am trying
to create a user that spans tenants and it seems like it borks.
ClientException: Conflict occurred attempting to store user. (IntegrityError)
(1062, Duplicate entry 'admin' for key 'name') 'INSERT INTO user (id, name,
extra) VALUES (%s, %s, %s)' ('3e14a9c1fd404c7e81c0dba8bd640575', 'admin',
'{password:
$6$rounds=4$yX5fL51OyGKjuPjr$8yv.S3GpqsKeaHv4GjNY4YW2vvykWzrEV7RX.qJpyy3CjmyXrZMRRJifEzfa7xv1l.NzoggQBXUAESn3Oqm0x/,
enabled: true, email: ad...@example.com, tenantId:
d1506184877a449a91fc6adcb553ad97}') (HTTP 409)
Is this supposed to happen? Is the client supposed to send back this much info
also (hashed password??) :-P
Any ideas?
___
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] questions on the dynamic loading of virt drivers in nova
No this is mostly just legacy stuff that was never refactored. Vish On May 9, 2012 3:33 PM, Sean Dague sda...@linux.vnet.ibm.com wrote: I'm familiarizing myself with the nova code and trying to reconcile that while there is dynamic class based loading in ComputeManager using import_utils in __init__() there is also a defaulting to the nova.virt.connection.get_**connection function. That's actually got a big if / else statement of string literals of known virt drivers, and then loads specific virt drivers from there. Is there a reason for both approaches? Can we refactor to a point where we don't need need of a common file with driver specific imports and string literals? Is there a reason not to? Thanks, -Sean -- Sean Dague IBM Linux Technology Center email: sda...@linux.vnet.ibm.com alt-email: slda...@us.ibm.com __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/~openstack More help : https://help.launchpad.net/**ListHelphttps://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 flavor-list' fails with ERROR: string indices must be integers, not str, but 'nova-manage flavor list' succeeds.
Is there a traceback from nova-api? ___ 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 flavor-list' fails with ERROR: string indices must be integers, not str, but 'nova-manage flavor list' succeeds.
Sorry, forgot to include that:
bash-4.1$ nova —debug image-list
connect: (127.0.0.1, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost: 127.0.0.1:5000\r\nAccept-Encoding:
identity\r\nContent-Length: 101\r\ncontent-type: application/json\r\naccept:
application/json\r\nuser-agent: python-novaclient\r\n\r\n'
send: '{auth: {tenantName: vmops, passwordCredentials: {username:
penick, password: tacos}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Type: application/json
header: Vary: X-Auth-Token
header: Content-Length: 1903
header: Date: Thu, 10 May 2012 00:37:02 GMT
connect: (208.67.66.91, 8774)
send: u'GET /v2/c9d7f45d980d494fab3d69d9fc57547c/images/detail
HTTP/1.1\r\nHost: 208.67.66.91:8774\r\nx-auth-project-id:
vmops\r\nx-auth-token: 3261ef74e6494561830949780838\r\naccept-encoding:
compress, gzip\r\naccept: application/json\r\nuser-agent:
python-novaclient\r\n\r\n'
reply: 'HTTP/1.1 503 Service Unavailable\r\n'
header: Content-Length: 100
header: Content-Type: text/plain; charset=UTF-8
header: Date: Thu, 10 May 2012 00:37:02 GMT
DEBUG (shell:415) string indices must be integers, not str
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/novaclient/shell.py, line 412, in main
OpenStackComputeShell().main(sys.argv[1:])
File /usr/lib/python2.6/site-packages/novaclient/shell.py, line 363, in main
args.func(self.cs, args)
File /usr/lib/python2.6/site-packages/novaclient/v1_1/shell.py, line 350,
in do_image_list
image_list = cs.images.list()
File /usr/lib/python2.6/site-packages/novaclient/v1_1/images.py, line 47,
in list
return self._list(/images/detail, images)
File /usr/lib/python2.6/site-packages/novaclient/base.py, line 80, in _list
data = body[response_key]
TypeError: string indices must be integers, not str
ERROR: string indices must be integers, not str
bash-4.1$
From: Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com
To: James R Penick pen...@yahoo-inc.commailto:pen...@yahoo-inc.com
Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] 'nova flavor-list' fails with ERROR: string indices
must be integers, not str, but 'nova-manage flavor list' succeeds.
Is there a traceback from nova-api?
___
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 client, user belongs to many tenants?
On May 9, 2012, at 4:46 PM, Joshua Harlow wrote:
A question,
I am using anvil to setup the keystone roles/users/tenants.
It seems like the python keystone client has the following command:
client.users.create
Which seems to take in the following:
create(self, name, password, email, tenant_id=None, enabled=True):
I would assume a user name can be used in multiple tenants but when I am
trying to create a user that spans tenants and it seems like it borks.
My guess is that once you have a user created, you would then use the
client.tenants.add_user method to add the user to different tenants:
add_user(tenant, user, role)
I think you would do something like:
user=client.users.create(…)
role=…
for tenant in other_tenants:
client.tenants.add_user(tenant, user, role)
ClientException: Conflict occurred attempting to store user. (IntegrityError)
(1062, Duplicate entry 'admin' for key 'name') 'INSERT INTO user (id, name,
extra) VALUES (%s, %s, %s)' ('3e14a9c1fd404c7e81c0dba8bd640575', 'admin',
'{password:
$6$rounds=4$yX5fL51OyGKjuPjr$8yv.S3GpqsKeaHv4GjNY4YW2vvykWzrEV7RX.qJpyy3CjmyXrZMRRJifEzfa7xv1l.NzoggQBXUAESn3Oqm0x/,
enabled: true, email: ad...@example.com, tenantId:
d1506184877a449a91fc6adcb553ad97}') (HTTP 409)
Is this supposed to happen? Is the client supposed to send back this much
info also (hashed password??) :-P
Not sure about this one.
Take care,
Lorin
--
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.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] [QA] Aligning smoke / acceptance / promotion test efforts
On 05/03/2012 03:54 PM, Daryl Walleck wrote: So my first question is around this. So is the claim is that the client tools are the default interface for the applications? Sorry, perhaps a better term would have been the most common interface to OpenStack Compute... While that works for coders in python, what about people using other languages? Even then, there's no guarantee that the clients in different languages are implemented in the same way. Tempest was designed originally because while it does use an abstraction between the API and the tests, there is nothing to assist the user by retrying and the like. While I think there's a place for writing tests using the command line clients, to me that would be a smoke test of a client and not as much a smoke test of the API. I understand your point, and I want to make it clear that I'm not advocating for getting rid of the Tempest REST client at all. I'm only advocating that we have a set of tests -- smoke tests -- that use the Python novaclient library, run a small subset of the total tests, and exercise only the most common and simple use cases for OpenStack. Here is where I think a sensible breakdown is: * Smoke tests - Test ONLY *simple*, *fast* code paths for common use cases - Use a Manager class that has a novaclient Client object * Negative tests - Test all code paths that should produce errors or negative results (NotFound, etc) - Use a Manager class that has the Tempest REST client * Fuzz tests - Test all code paths with randomized input data - Use a Manager class that has the Tempest REST client * Advanced tests - Test extensions, interaction between multiple components, advanced features of the API, etc - Use a Manager class that has a novaclient Client object OR the Tempest REST client, depending on whether: - novaclient actually has the ability to perform the necessary actions - If the test needs to poke at the API in a way that novaclient would interfere with -- and thus the Tempest REST client would be ideal Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [QA] Aligning smoke / acceptance / promotion test efforts
On 05/03/2012 10:54 PM, Maru Newby wrote: The rest api is the default interface, and the client tools target that interface. Since the clients are cli more than python api, they can be used by any language that can use a shell. What exactly does reimplementing the clients for the sake of testing accomplish? Double the maintenance effort for the same result, imho. There is a very specific reason that the novaclient library wasn't used. We needed a client that would enable us to throw invalid and random bad input data at the APIs. novaclient is designed to eliminate the ability to get an API call wrong, since it successfully constructs the proper HTTP API calls. We need a client that allows Tempest's negative tests to throw bad stuff at the API and verify the server's robustness in responding to that invalid data. Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Swift] swift news and plans
2012/5/4 John Dickinson m...@not.mn: TL;DR: removing code from swift, associated projects doc, swift 1.5.0 This is interesting stuff. Where was this discussed? -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Metering] External API definition
Is it your assumption that there will be one metering service per installation or one per service (i.e swift, nova)? My assumption would be a single metering service, so the API would need to handle some additional use cases: -list services supported -list metrics for a service type -get metric details I would also consider separate use cases for accessing raw events vs. aggregated metrics. Dan Dyer dan.d...@hp.com On Wed, May 9, 2012 at 10:44 AM, Nick Barcet nick.bar...@canonical.comwrote: Doug Hellmann doug.hellm...@dreamhost.com wrote: On Wed, May 9, 2012 at 11:27 AM, Nick Barcet nick.bar...@canonical.comwrote: On 05/08/2012 08:27 AM, Nick Barcet wrote: [..] Thinking about this, I think we need to expend the API a bit to reflect the evolutions of the schema that we decided last week. Here are my proposals: * Requests allow to GET account_id list change to: GET [user_id|project_id|source] list Does the [value|value] syntax mean choose one or combine? I assume choose one and you are using square brackets because parens are used in some of the other queries. You assumed correctly :) GET list of counter_type GET list of events per account optional start and end for counter_datetime optional counter_type change to: GET list of events per [user_id|project_id|source] optional start and end for counter_datetime optional counter_type Users may cross projects, so I'm not sure it makes sense to ask for the events generated by a user without restricting it by the project. At the very least we may need to allow them to specify user_id or project_id or both. Good point. Thanks for catching this. GET sum of (counter_volume, counter_duration) for counter_type and account_id optional start and end for counter_datetime GET sum of (counter_volume, counter_duration) for counter_type and [user_id|project_id|source] optional start and end for counter_datetime Hope this makes sense. Another item that we need to discuss is extensibility of this API. Nick ___ 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 flavor-list' fails with ERROR: string indices must be integers, not str, but 'nova-manage flavor list' succeeds.
That's the traceback from novaclient. If you're getting a 503, there's likely
a traceback in the nova-api service logs.
- Chris
On May 9, 2012, at 5:38 PM, James R Penick pen...@yahoo-inc.com wrote:
Sorry, forgot to include that:
bash-4.1$ nova —debug image-list
connect: (127.0.0.1, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost: 127.0.0.1:5000\r\nAccept-Encoding:
identity\r\nContent-Length: 101\r\ncontent-type: application/json\r\naccept:
application/json\r\nuser-agent: python-novaclient\r\n\r\n'
send: '{auth: {tenantName: vmops, passwordCredentials: {username:
penick, password: tacos}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Type: application/json
header: Vary: X-Auth-Token
header: Content-Length: 1903
header: Date: Thu, 10 May 2012 00:37:02 GMT
connect: (208.67.66.91, 8774)
send: u'GET /v2/c9d7f45d980d494fab3d69d9fc57547c/images/detail
HTTP/1.1\r\nHost: 208.67.66.91:8774\r\nx-auth-project-id:
vmops\r\nx-auth-token: 3261ef74e6494561830949780838\r\naccept-encoding:
compress, gzip\r\naccept: application/json\r\nuser-agent:
python-novaclient\r\n\r\n'
reply: 'HTTP/1.1 503 Service Unavailable\r\n'
header: Content-Length: 100
header: Content-Type: text/plain; charset=UTF-8
header: Date: Thu, 10 May 2012 00:37:02 GMT
DEBUG (shell:415) string indices must be integers, not str
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/novaclient/shell.py, line 412, in
main
OpenStackComputeShell().main(sys.argv[1:])
File /usr/lib/python2.6/site-packages/novaclient/shell.py, line 363, in
main
args.func(self.cs, args)
File /usr/lib/python2.6/site-packages/novaclient/v1_1/shell.py, line 350,
in do_image_list
image_list = cs.images.list()
File /usr/lib/python2.6/site-packages/novaclient/v1_1/images.py, line 47,
in list
return self._list(/images/detail, images)
File /usr/lib/python2.6/site-packages/novaclient/base.py, line 80, in
_list
data = body[response_key]
TypeError: string indices must be integers, not str
ERROR: string indices must be integers, not str
bash-4.1$
From: Vishvananda Ishaya vishvana...@gmail.com
To: James R Penick pen...@yahoo-inc.com
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net
Subject: Re: [Openstack] 'nova flavor-list' fails with ERROR: string indices
must be integers, not str, but 'nova-manage flavor list' succeeds.
Is there a traceback from nova-api?
___
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] Meeting agenda for today 16:00 UTC (May 3rd, 2012)
A question/comment about the scope of the schema or maybe the architecture. Assuming the services will provide the instrumentation to populate the raw metric data, it seems likely that you will need to define an interface between the services/agents that are providing the data and the metering system which stores the generated metric data in the database (as opposed to having the services write directly to the DB). Is the schema intended to be this kind of interop format between the services and the meter's datastore or just the end result of the storage? Thanks, Dan Dyer On Thu, May 3, 2012 at 11:10 AM, Loic Dachary l...@enovance.com wrote: On 05/03/2012 02:22 PM, Loic Dachary wrote: Hi, The metering project team holds a meeting in #openstack-meeting, Thursdays at 1600 UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=0sec=0. Everyone is welcome. I propose an agenda based on the discussions we had on this list. http://wiki.openstack.org/Meetings/MeteringAgenda Topic : schema and counter definitions * counter definitions * Proposed http://wiki.openstack.org/EfficientMetering#Counters * schema definition * Proposed http://wiki.openstack.org/EfficientMetering#Storage * discuss storage assumptions * the storage will store all events * no aggregated value is permanently stored * discuss API assumptions * the API provide a sum() function to aggregate values * the API may transparently store results of the sum function in a cache * discuss event collection * events are collected from a components when possible * ceilometer agent is installed on a node when the a component does not provide the value * contribute to the component instead of developping a ceilometer agent plugin * engaging discussions with core components * nova * cinder * glance * swift * quantum * open discussion For the record, the first two points used all the time but that was the goal of the meeting. The other points would have been nice to discuss but can each be turned into a mailing list thread ;-) == #openstack-meeting Meeting == Meeting started by dachary at 16:00:16 UTC. The full logs are available athttp://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-03-16.00.log.html . Meeting summary --- * actions from previous meetings (dachary, 16:00:36) * creation of the ceilometer project (dachary, 16:00:36) * The repository for the ceilometer project has been created (dachary, 16:00:36) * LINK: https://github.com/stackforge/ceilometer (dachary, 16:00:36) * and the first commit was successfully reviewed and merged today https://review.stackforge.org/#/c/25/ (dachary, 16:00:37) * meeting organisation (dachary, 16:01:03) * This is 1/5 meetings to decide the architecture of the Metering project https://launchpad.net/ceilometer (dachary, 16:01:03) * Today's focus is on the definition of the counters / meters and the associated schema for the storage (dachary, 16:01:03) * It is the conclusion of the discussions held on the mailing list and the goal is to make a final choice that will then be implemented. (dachary, 16:01:03) * The meeting is time boxed and there will not be enough time to introduce inovative ideas and research for solutions. (dachary, 16:01:03) * The debate will be about the pro and cons of the options already discussed on the mailing list. (dachary, 16:01:03) * LINK: https://lists.launchpad.net/openstack/msg10810.html (dachary, 16:01:03) * counter definitions (dachary, 16:02:10) * Proposed http://wiki.openstack.org/EfficientMetering#Counters (dachary, 16:02:10) * ACTION: dachary fix the note for net_float still talks about number of floating IPs (dachary, 16:09:18) * ACTION: jd___ include Number of object in Swift, Number of containers in Swift, Number of GET/HEAD/PUT/POST requests in Swift in the table (dachary, 16:10:11) * ACTION: dachary add note about the fact that the resource_id for the object count is the container_id (dachary, 16:21:44) * LINK: http://wiki.openstack.org/EfficientMetering#Counters is agreed on, provided the actions listed above are carried out. (dachary, 16:25:35) * ACTION: jd___ document the resource_id for each counter (dachary, 16:30:33) * ACTION: jd___ describes the general table schema and then something that says for each counter exactly what goes in the fields of that table and show how secondary field counters are recorded in the in the schema too (dachary, 16:33:27) * AGREED: s/counter/meter/ (dachary, 16:37:11) * LINK: http://wiki.openstack.org/EfficientMetering#Counters is agreed on, provided the actions listed above are carried out. ? (dachary, 16:37:38) * AGREED:
[Openstack] Improving Xen support in the libvirt driver
Hi, I've been tinkering with improving Xen support in the libvirt driver and wanted to discuss a few issues before submitting patches. Even the latest upstream release of Xen (4.1.x) contains a rather old qemu, version 0.10.2, which rejects qcow2 images with cluster size 64K. The libvirt driver creates the COW image with cluster size of 2M. Is this for performance reasons? Any objections to removing that option and going with 'qemu-img create' default of 64K? In a setup with both Xen and KVM compute nodes, I've found a few options for controlling scheduling of an instance to the correct node. One option uses availability zones, e.g. # nova.conf on Xen compute nodes node_availability_zone=xen-hosts # launching a Xen PV instance nova boot --image xen-pv-image --availability_zone xen-hosts ... The other involves a recent commit adding additional capabilities for compute nodes [1] and the vm_mode image property [2] used by the XenServer driver to distinguish HVM vs PV images. E.g. # nova.conf on Xen compute nodes additional_compute_capabilities=pv,hvm # Set vm_mode property on Xen image glance update image-uuid vm_mode=pv I prefer that latter approach since vm_mode will be needed in the libvirt driver anyhow to create proper config for PV vs HVM instances. Currently, the driver creates usable config for PV instances, but needs some adjustments for HVM. Regards, Jim [1] https://github.com/openstack/nova/commit/bd30eb36bbf2c5164ac47256355c543f6b77e064 [2] https://github.com/openstack/nova/commit/bd30eb36bbf2c5164ac47256355c543f6b77e064 ___ 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 client, user belongs to many tenants?
I think this use case underscores one of the key differences between the fat
Keystone (Diablo - E3) and KSL (Essex final). In fat Keystone, users and
tenants are loosely coupled. They are bind together by role assignments. In
KSL, users and tenants are tightly coupled, and IMHO very inflexible. Maybe the
following example would further clarify this …
Suppose you have tenants Dodgers, Giants, and Brewers, user Bud Selid, roles
Commissioner and Minority Owner, and service MLB. And you want Bud Selid to
have the Commissioner role for Dodgers, Giants, and Brewers, but Minority Owner
role for Brewers only.
In fat Keystone, there a couple of ways you can accomplish this.
1) Make Commissioner a “global role” (unscoped) and assign it to user Bud
Selid. Assign the Minority Owner role to Bud Selid for tenant Brewers by
creating a role reference. When Bud Selid tries to access MLB with his unscoped
token, MLB will get his Commissioner role back from Keystone. When Bud Selid
tries to access MLB with his token scoped to Brewers, MLB will get both his
Commissioner and Minority Owner roles back from Keystone. When Bud Selid tries
to acess MLB with his token scoped to Giants or Dodgers, MLB will only get his
Commissioner role back from Keystone.
2) Assign the Commissioner role to Bud Selid to tenants Giants, Dodgers,
and Brewers individually by creating the respective role references. Assign the
Minority Owner role to Bud Selid for tenant Brewers by creating another role
reference. In this scenario, Bud Selid will always need a scoped token to
access MLB.
In KSL, there really aren’t any effective ways to accomplish the same thing.
Global roles are no longer supported. A given user must assign to exactly one
tenant. I suppose you can have Bud Selid under the “Default Tenant”, and assign
both Commissioner and Minority Owner roles to him. But there are two major side
effects.
1) Bud Selid must access MLB with the token scoped to the “Default Tenant”
in order for MLB to recognize him as Commissioner. Which means he IS ALSO the
Minority Owner for Dodgers, Giants, and Brewers. J
2) If Bud Selid tries to access MLB with the token scoped to either
Giants, Dodgers, or Brewers, his a NOBODY. J
The upcoming Domains blueprint (to be implemented for Folsom), which offers
true multitenancy, should support these types of use cases.
https://blueprints.launchpad.net/keystone/+spec/keystone-domains
With Domains, you can create a MLB domain with tenants Dodgers, Giants, and
Brewers. And have Bud Selid under the MLB domain. Notice that users will no
longer be assigned to tenants. They will be under a domain. Create roles
Commissioner and Minority Owner in the MLB domain. Assign the Commissioner role
to Bud Selid, and the Minority Owner role scoped to Brewers. Suppose you have
another domain NFL, Bud Selid will not be able to access any tenants in the NFL
domain, unless the NFL domain administrator explicitly assign NFL roles to Bud
Selid.
Guang
From: openstack-bounces+guang.yee=hp@lists.launchpad.net
[mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of
Dolph Mathews
Sent: Wednesday, May 09, 2012 4:34 PM
To: Joshua Harlow
Cc: openstack
Subject: Re: [Openstack] Keystone client, user belongs to many tenants?
The user create command is actually creating discrete users, each with a
default tenant reference.
While that's fine for a lot of simple use cases, it doesn't directly support a
user accessing multiple tenants at all.
Instead, create a role, and grant that role to a user-tenant pair, creating an
explicit relationship between the two. Using default tenants is optional with
this method, but will affect how users must auth.
-Dolph Mathews
On May 9, 2012, at 3:46 PM, Joshua Harlow harlo...@yahoo-inc.com wrote:
A question,
I am using anvil to setup the keystone roles/users/tenants.
It seems like the python keystone client has the following command:
client.users.create
Which seems to take in the following:
create(self, name, password, email, tenant_id=None, enabled=True):
I would assume a user name can be used in multiple tenants but when I am trying
to create a user that spans tenants and it seems like it borks.
ClientException: Conflict occurred attempting to store user. (IntegrityError)
(1062, Duplicate entry 'admin' for key 'name') 'INSERT INTO user (id, name,
extra) VALUES (%s, %s, %s)' ('3e14a9c1fd404c7e81c0dba8bd640575', 'admin',
'{password:
$6$rounds=4$yX5fL51OyGKjuPjr$8yv.S3GpqsKeaHv4GjNY4YW2vvykWzrEV7RX.qJpyy3CjmyXrZMRRJifEzfa7xv1l.NzoggQBXUAESn3Oqm0x/,
enabled: true, email: ad...@example.com, tenantId:
d1506184877a449a91fc6adcb553ad97}') (HTTP 409)
Is this supposed to happen? Is the client supposed to send back this much info
also (hashed password??) :-P
Any ideas?
___
Mailing list:
Re: [Openstack] [nova] why does notification use a topic exchange instead of fanout?
On 05/09/2012 03:17 PM, Tihomir Trifonov wrote: Hi Doug, not sure if you've hit the same problem, but I've spent some time on that when I started using RabbitMQ. As I see from the example, you've provided: queue = Queue(name='notifications.info', exchange=Exchange(name='nova'... So you set explicitly a name for the queue. If you have two queues declared with the same name, when they are bound to an Exchange, actually each message is received only by the one queue at a time. To be a bit pedantic, the result is that there is only one queue and two consumers from that queue. Only one consumer gets each message. When there is more than one consumer from the same queue, messages will be distributed in a round-robin fashion. -- 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
