Re: [openstack-dev] [puppet] Distribution (in)dependent acceptance tests
For the puppet software itself, using the puppetlabs apt and yum repos is the standard installation procedure. The distribution provided versions are always to old, and the development effort has always been targeting the latest stable puppet release. For modules, I have always disagreed with packaging puppet modules by the operating system. Even library modules like inifile have too much volatility to be good candidates for packaging in a LTS distro. For openstack technology like puppet-keystone, the goal is to move to zuul-cloner (currently being driven by infra) so that the puppet modules can all share a gate test with each other. -- Spencer Krum n...@spencerkrum.com On Fri, May 22, 2015, at 05:21 PM, Gabriele Cerami wrote: Hi, why are current beaker-rspec tests installing puppet from puppetlabs instead of using a package from a distribution repo, like what is done for git ? More generally, spec_helper_acceptance.rb is setting up what it seems to be a distribution independent environment that is using a lot of external repos, and only in part the packages offered by the distributions. Generic dependencies (like puppet-inifile) and even specific dependencies (like puppet-keystone) are probably already offered by distribution packages. I think that doing this defeats in part the purpose of launching acceptance tests on different distributions, because a consistent part of the test environment remains always the same. -- Gabriele panda Cerami Software Engineer, Openstack CI Red Hat __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [heat][nova]: anti-affinity policy via heat in IceHouse?
Hi, I'm aware of the anti-affinity policy which you can create via nova cli and associated instances with it. I'm also aware of the default policies in nova.conf by creating instances via HEAT is any alternatives to create instances part of anti-affinity group? Thx, Dani __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][nova]: anti-affinity policy via heat in IceHouse?
It works with heat. You can use a scheduler hint on the instance and the server group resource to make a new one. Thanks, Kevin From: Daniel Comnea Sent: Saturday, May 23, 2015 3:17:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [heat][nova]: anti-affinity policy via heat in IceHouse? Hi, I'm aware of the anti-affinity policy which you can create via nova cli and associated instances with it. I'm also aware of the default policies in nova.conf by creating instances via HEAT is any alternatives to create instances part of anti-affinity group? Thx, Dani __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] usefulness of device parameter at volumeAttachment
Hi, When someone calls nova volume-attach or the block-device-mapping parameter at boot, it is possible to specify a device name for the guest. However I couldn't find any guest OS which would honor this. E.g. with libvirt/kvm, if the guest has two virtio disks already (vda and vdb), specifying vdf would be ignored and the disk will be attached as vdc in the guest. I propose to deprecate this option and at boot where it is not optional to accept only auto as an option. Best regards, Geza __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support
Hi all, I just wanted to make a note about a couple things here. I'll also try to attend any meeting that is scheduled. GLSB may be implemented a few ways. One method is via DNS, as Kunal mentioned. It's not very granular and unless you have very low TTL on your records and the ability to change your records rapidly at the edge, it can be difficult to control. A second way to implement GSLB is to use Layer 7 to redirect client traffic. Typically you'll tell a load balancer where to redirect traffic and it will do something like an HTTP redirect. I've used this implementation for things like site maintenance, or load based redirection. (I think A10 and F5 implement Layer 7 GSLB solutions in at least some of their products that offer GSLB?) Something to keep in mind about a DNS based strategy is that recursive resolvers may not respect record order, some implement broken caching (ignoring authoritative TTL values), and that authoritative servers may not be queried evenly. I'd be very happy to discuss specifics offline with anybody that might have questions about authoritative DNS operator quirks, implementations, or what they generally see behavior wise from recursive servers. Otherwise, I look forward to the meeting. -- Tom Cameron Network Architect Rackspace From: Gandhi, Kunal kunalhgan...@gmail.com Sent: Friday, May 22, 2015 22:24 To: openstack-dev@lists.openstack.org Cc: do...@a10networks.com; v.jain...@gmail.com Subject: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support Hi All I wanted to start a discussion about adding support for GSLB to neutron-lbaas and designate. To be brief for folks who are new to GLB, GLB stands for Global Load Balancing and we use it for load balancing traffic across various geographical regions. A more detail description of GLB can be found at my talk at the summit this week here. To my understanding, there are two sides to a GSLB - DNS side and LB side. DNS side Most of the GSLB’s provided by various vendors are DNS servers and are authoritative for the GLB domains. The global fqdn’s that belong the GLB domains resolve to multiple public VIP’s across various regions based on various configurations on the global fqdn on the GLB. LBaaS side A few of the common functionalities provided by a standard GSLB provides are health monitoring on the public VIP’s and the local LB’s on which these public VIP’s sit on. Some additional features that a GSLB can provide are configuring admin status and weights on your public VIP’s. Based on these configurations and settings, the GLB returns the appropriate number of public VIP’s to any DNS resolve queries for the global fqdn’s. I would like to have the designate and lbaas to start a discussion on GSLB and discuss the following topics: What parts of GSLB belongs to Designate and LBaaS ? Once we have an understanding of the above, my team at eBay/PayPal would like work with the community on submitting a blueprint for this. To kick start this conversation, I would like to schedule an irc meeting regarding this with folks from designate and neutron-lbaas. Please let me know a time and day that works for you guys. I am available on Thursday and Friday next week. Regards Kunal __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Thanks to all the folks on the plane tour to glaciers
Vincent, So sorry you were not feeling well during the tour. Those things happen though...No worries. We were glad to get the e-mail letting us know that you were ok and feeling better! Glad that you could join us on the trip and see the Alpine lake and get pictures with us. I will send you a copy of the pictures. Safe travels back home! Jay On 05/22/2015 10:53 PM, Sheng Bo Hou wrote: Hi all the folks on the plane tour to the glaciers, This is Vincent Hou. I am sorry about getting a bit plane-sick during our trip. It was a sort of harsh for me, but the wonderful thing is that I really enjoyed the snow, the mountain, the lake, the glaciers, etc. I hope the uncomfortable me did not bring too much trouble to you folks. It felt like that the blood in my body had stopped flowing. I got no strength to see, no strength to hear, no strength to sit, even no strength to think... Sorry about that I did not even say goodbye and wish you folks a nice trip back to your place. Thank Kurt. This trip is perhaps the only once in my life with the best view I ever see. Thank Sean. You words helped me a lot. I might not be able to make the trip in the last section without them. Thank Jay, Walter... Thank everybody. One more request in the end. Can you guys share some photos you have taken in our tour? I have missed some view. Thank you so much. I am feeling much better now in the hotel. Take care, folks! Safe trip back home! See you. Best wishes, Vincent Hou (侯胜博) Staff Software Engineer, Open Standards and Open Source Team, Emerging Technology Institute, IBM China Software Development Lab Tel: 86-10-82450778 Fax: 86-10-82453660 Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Setting cluster status when provisioning a node
Hi folks! Recently I encountered an issue [1] that the Deploy Changes button in the web ui is still active when a provisioning of single node is started using the command line client. The background for that issue is that the provisioning task does not seem to update the cluster status correctly and Nailgun’s API returns it as NEW even while some of the node are been provisioned. The reason for raising this thread in the mailing list is that provisioning a node is a feature for developers and basically end-users should not do that. What is the best solution for that: fix Nailgun to set the correct status, or make this provisioning feature available only for developers? 1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086 - romcheg signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Why need br-int and br-tun in openstack neutron
There's no real reason as far as I'm aware, just an implementation decision. On 21 במאי 2015, at 01:48, Na Zhu na...@cn.ibm.com wrote: Dear, When OVS plugin is used with GRE option in Neutron, I see that each compute node has br-tun and br-int bridges created. I'm trying to understand why we need the additional br-tun bridge here. Can't we create tunneling ports in br-int bridge, and have br-int relay traffic between VM ports and tunneling ports directly? Why do we have to introduce another br-tun bridge? Regards, Juno Zhu Staff Software Engineer, System Networking China Systems and Technology Lab (CSTL), IBM Wuxi Email: na...@cn.ibm.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] meeting with the zaqar team at summit; my notes
Thank you. Ill look for this right away. Long term, we would prefer some way for the resources to be associated with the tenant so that it simplifies quotas/billing since there are just instances/volumes we already quota. This would need some kind of service vm flag in nova to prevent via policy non admins from messing with them. In addition, this is still a case where some users had an opertunity to get into a vm they shouldnt, and a multitenant message queue would then have privided extra protection. Thanks, Kevin From: Zane Bitter Sent: Friday, May 22, 2015 10:07:42 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] meeting with the zaqar team at summit; my notes On 22/05/15 19:01, Fox, Kevin M wrote: I believe that trove still needs the multi tenant isolation of a multi tenant message queue due to the fact that the vm runs in the tenant, and the tenant can then force a reboot, go to the console, root it, and inject messages at queues destened for other tenants vm's. And there are other routes too. So what I gathered is that according to the Trove folks you are Doing It Wrong(TM), even though you installed it in the default configuration. You should have modified the Trove code in undocumented ways to create the VMs in a project that Trove itself owns, not the user's project. This is a major problem, and I think our site is going to have to strongly consider uninstalling trove until fixed. I think if you made that change the configuration it would be a lot less dangerous. Arguably even then it would be better to use something multi-tenant capable and authenticated (if it's so safe why not use the same RabbitMQ as all the other services?), but it would be less of an 'immediate uninstall' case. cheers, Zane. Thanks, Kevin * * *From:* Zane Bitter *Sent:* Friday, May 22, 2015 12:34:01 PM *To:* openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] meeting with the zaqar team at summit; my notes On 22/05/15 11:48, Amrith Kumar wrote: I’m posting this to the mailing list to summarize my notes from a meeting at 5pm yesterday at Summit relative to Zaqar and lightweight multi-tenant messaging and how it may be applicable to a number of projects. I’ll begin by saying these are not ‘minutes’ of a meeting, merely my notes and observations after the meeting and how they relate specifically to Trove. I don’t claim to speak for Trove, other contributors to Trove, other projects who were at the meeting, for zaqar, etc., etc., After the meeting I think I have a slightly better understanding of what Zaqar is but I am still not entirely sure. As best as I can tell, it is a lightweight, keystone authenticated, multi-tenant messaging system. I'm not sure what 'lightweight' means in this context. I'd describe it as a keystone-authenticated multi-tenant reliable messaging system a la Amazon SQS. I am still a little troubled that of the many people in the room who were knowledgeable of zaqar, there appeared to be some disagreement on how best to describe or explain the project. I don't think there's any disagreement. It just seems to be hard to explain to people, because everyone instinctively wants to compare it to Rabbit, which is a completely different thing with completely different use cases. IMHO part of the problem has been that folks have been reluctant to name SQS specifically, and so we end up talking elliptically. I learned that users of zaqar can authenticate with keystone and then interact with zaqar, and pass messages using it. I learned also that zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t zaquar as I had thought it was. It became clear that the underlying transport in zaqar is not based on an existing AMQP service, rather zaqar is a “from the ground up” implementation. This scares me (a lot). Yes, literally every person who has ever heard of Zaqar complains about this and it's getting a little boring. It's irrelevant because Zaqar is not a replacement for AMQP, it's a replacement for SQS. I gather there is currently no oslo.messaging integration with zaqar; Right, Zaqar has never been intended as a replacement for Rabbit in Oslo messaging. (Although that could be an interesting idea, it's another discussion altogether.) for Trove to use zaqar we would have to either (a) abandon oslo.messaging and use zaqar, or (b) build in smarts within Trove to determine at run time whether we are using zaqar or o.m and implement code in Trove to handle the differences between them if any. It wasn’t clear to me after the meeting what differences there may be with Trove; one which was alluded to was the inability to do a synchronous (call()) style message and the statement was that this was something that “could be built into a driver”. Where Zaqar really provides the biggest
Re: [openstack-dev] [nova] usefulness of device parameter at volumeAttachment
I believe xen supports it. Thanks, Kevin From: Géza Gémes Sent: Saturday, May 23, 2015 2:00:32 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [nova] usefulness of device parameter at volumeAttachment Hi, When someone calls nova volume-attach or the block-device-mapping parameter at boot, it is possible to specify a device name for the guest. However I couldn't find any guest OS which would honor this. E.g. with libvirt/kvm, if the guest has two virtio disks already (vda and vdb), specifying vdf would be ignored and the disk will be attached as vdc in the guest. I propose to deprecate this option and at boot where it is not optional to accept only auto as an option. Best regards, Geza __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] PCI pass-through SRIOV
Hi,
Am deploying controller-compute openstack setup , in controller I configured
openvswitch bridges and in computed node I configured PCI nic supported SRIOV
capability and while am spawning VM am getting following error as in attached
file:
I followed the link for setting up the sriov
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking and
http://www.qlogic.com/solutions/Documents/UsersGuide_OpenStack_SR-IOV.pdf
Could any one help me regarding this issue
Thanks and Regards,
Raghavendrachari kamsali,
Embedded Computing and Power,
Hyderabad, AndhraPradesh , India
2015-05-23 21:24:35.061 DEBUG nova.virt.libvirt.vif [-] vif_type=binding_failed
instance=Instance(access_ip_v4=Non
e,access_ip_v6=None,architecture=None,auto_disk_config=False,availability_zone=None,cell_name=None,cleaned=False,c
onfig_drive='',created_at=2015-05-23T04:23:17Z,default_ephemeral_device=None,default_swap_device=None,deleted=Fals
e,deleted_at=None,disable_terminate=False,display_description='ubuntuvm',display_name='ubuntuvm',ephemeral_gb=0,ep
hemeral_key_uuid=None,fault=?,host='atca7480',hostname='ubuntuvm',id=6,image_ref='0f945b95-df76-4ef1-9ed0-3d072b
ac360f',info_cache=InstanceInfoCache,instance_type_id=5,kernel_id='',key_data=None,key_name=None,launch_index=0,la
unched_at=None,launched_on='atca7480',locked=False,locked_by=None,memory_mb=2048,metadata={},node='atca7480',numa_
topology=None,os_type=None,pci_devices=PciDeviceList,power_state=0,progress=0,project_id='51b00a98b1ac471684cad9b1
ee248cc5',ramdisk_id='',reservation_id='r-2r0v9idg',root_device_name='/dev/vda',root_gb=20,scheduled_at=None,secur
ity_groups=SecurityGroupList,shutdown_terminate=False,system_metadata={image_base_image_ref='0f945b95-df76-4ef1-9e
d0-3d072bac360f',image_container_format='bare',image_disk_format='qcow2',image_min_disk='20',image_min_ram='0',ins
tance_type_ephemeral_gb='0',instance_type_flavorid='2',instance_type_id='5',instance_type_memory_mb='2048',instanc
e_type_name='m1.small',instance_type_root_gb='20',instance_type_rxtx_factor='1.0',instance_type_swap='0',instance_
type_vcpu_weight=None,instance_type_vcpus='1',network_allocated='True'},task_state='spawning',terminated_at=None,u
pdated_at=2015-05-23T04:23:20Z,user_data=None,user_id='e51e176aee744f35bb1e2fb05ecd615f',uuid=39d27b92-295f-4f18-b
b76-e0bba4d0666b,vcpus=1,vm_mode=None,vm_state='building') vif=VIF({'profile':
{u'pci_slot': u':81:02.3', u'ph
ysical_network': u'default', u'pci_vendor_info': u'8086:154c'},
'ovs_interfaceid': None, 'network': Network({'brid
ge': None, 'subnets': [Subnet({'ips': [FixedIP({'meta': {}, 'version': 4,
'type': 'fixed', 'floating_ips': [], 'ad
dress': u'11.0.0.8'})], 'version': 4, 'meta': {'dhcp_server': u'11.0.0.7'},
'dns': [], 'routes': [], 'cidr': u'11.
0.0.0/24', 'gateway': IP({'meta': {}, 'version': 4, 'type': 'gateway',
'address': u'11.0.0.1'})})], 'meta': {'inje
cted': False, 'tenant_id': u'51b00a98b1ac471684cad9b1ee248cc5',
'physical_network': u'default'}, 'id': u'5ef1662f-
8bb4-4124-8b68-2a2fe240170e', 'label': u'sriov'}), 'devname':
u'tap5281222e-4c', 'vnic_type': u'direct', 'qbh_para
ms': None, 'meta': {}, 'details': {}, 'address': u'fa:16:3e:fd:55:1e',
'active': False, 'type': u'binding_failed',
'id': u'5281222e-4c3b-47af-a851-6b0254c0d85a', 'qbg_params': None})
virt_typekvm from (pid=29295) get_config /opt
/stack/nova/nova/virt/libvirt/vif.py:342
2015-05-23 21:24:35.063 ERROR nova.compute.manager [-] [instance:
39d27b92-295f-4f18-bb76-e0bba4d0666b] Instance f
ailed to spawn
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance:
39d27b92-295f-4f18-bb76-e0bba4d0666b] Traceback (mos
t recent call last):
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance:
39d27b92-295f-4f18-bb76-e0bba4d0666b] File /opt/s
tack/nova/nova/compute/manager.py, line 2266, in _build_resources
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance:
39d27b92-295f-4f18-bb76-e0bba4d0666b] yield reso
urces
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance:
39d27b92-295f-4f18-bb76-e0bba4d0666b] File /opt/s
tack/nova/nova/compute/manager.py, line 2136, in _build_and_run_instance
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance:
39d27b92-295f-4f18-bb76-e0bba4d0666b] block_device_info=block_device_info)
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance:
39d27b92-295f-4f18-bb76-e0bba4d0666b] File
/opt/stack/nova/nova/virt/libvirt/driver.py, line 2662, in spawn
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance:
39d27b92-295f-4f18-bb76-e0bba4d0666b] write_to_disk=True)
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance:
39d27b92-295f-4f18-bb76-e0bba4d0666b] File
/opt/stack/nova/nova/virt/libvirt/driver.py, line 4200, in _get_guest_xml
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance:
39d27b92-295f-4f18-bb76-e0bba4d0666b] context)
2015-05-23 21:24:35.063 TRACE nova.compute.manager [instance:
Re: [openstack-dev] [security] Nominating Mike McCune as Security-Doc Core
+1 from me On 22 May 2015, at 13:55, Nathan Kinder nkin...@redhat.com wrote: On 05/19/2015 05:20 PM, Dillon, Nathaniel wrote: To the Security and Docs groups as well as other interested parties, I would like to nominate Mike McCune to the Security Guide core. He has been contributing to the Security Guide for about six months now, and he has been a consistent participant improving content and helping new submittors. In addition, he knows the inner workings of the guide, having created and merged for the security guide the chapter on Sahara. Please chime in with your agreement, or concerns. +1! Mike's work has been great. -NGK Thanks, Nathaniel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [docs] improving app Dev docs
On 21 May 2015, at 2:12 pm, michael mccune m...@redhat.com wrote: On 05/21/2015 01:10 PM, Anne Gentle wrote: Hi all, please come to the API doc working session this morning at 11:50 in 305 if you want to work on plans for next-gen API docs in Liberty. https://libertydesignsummit.sched.org/mobile/#session:29e7d4effc10832b4d6aa50339e0c973 is there an etherpad available for this session? https://etherpad.openstack.org/p/Documentation__API_Work_Session L i was, sadly, unable to attend but i am very interested in this effort. mike __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Lana Brindley Technical Writer Rackspace Cloud Builders Australia signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] PCI pass-through SRIOV
Hi Kamsali, According to the logs you got binding failed error, which mean neutron failed to bind the port. Can you send the neutron server log and the your neutron ml2 conf file? Thank, Moshe Levi From: Kamsali, RaghavendraChari (Artesyn)mailto:raghavendrachari.kams...@artesyn.com Sent: ?Saturday?, ?May? ?23?, ?2015 ?6?:?38? ?AM To: OpenStack Development Mailing List (not for usage questions)mailto:openstack-dev@lists.openstack.org, openst...@lists.openstack.orgmailto:openst...@lists.openstack.org Hi, Am deploying controller-compute openstack setup , in controller I configured openvswitch bridges and in computed node I configured PCI nic supported SRIOV capability and while am spawning VM am getting following error as in attached file: I followed the link for setting up the sriov https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking and http://www.qlogic.com/solutions/Documents/UsersGuide_OpenStack_SR-IOV.pdf Could any one help me regarding this issue Thanks and Regards, Raghavendrachari kamsali, Embedded Computing and Power, Hyderabad, AndhraPradesh , India __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Redis as Messaging System
Does anybody know of a way (either current projects or future plans) to use Redis PubSub as the messaging system for OpenStack? -Todd signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
