Re: [openstack-dev] [Neutron][SR-IOV]How to assign VF to a VM?

[Beliveau, Ludovic]

I believe you are getting this problem because you are trying to use SR-IOV 
over a flat network, which is not supported.

From the logs:

2015-08-21 04:29:44.619 9644 DEBUG neutron.plugins.ml2.managers 
[req-314733e3-17ab-4e20-951a-0c75744016b5 ] Attempting to bind port 
620187c5-b4ac-4aca-bdeb-96205503344d on host compute for vnic_type direct with 
profile {pci_slot: :09:11.5, physical_network: external, 
pci_vendor_info: 8086:1520} bind_port 
/usr/lib/python2.7/site-packages/neutron/plugins/ml2/managers.py:611
2015-08-21 04:29:44.619 9644 DEBUG neutron.plugins.ml2.managers 
[req-314733e3-17ab-4e20-951a-0c75744016b5 ] Attempting to bind port 
620187c5-b4ac-4aca-bdeb-96205503344d on host compute at level 0 using segments 
[{'segmentation_id': None, 'physical_network': u'external', 'id': 
u'f3dee69f-ee4a-4c1b-bfa9-05689dc9b07b', 'network_type': u'flat'}] 
_bind_port_level 
/usr/lib/python2.7/site-packages/neutron/plugins/ml2/managers.py:628

You should try to use a segmented/VLAN based network.

Regards,
/ludovic

From: Moshe Levi [mailto:mosh...@mellanox.com]
Sent: Friday, August 21, 2015 5:15 AM
To: OpenStack Development Mailing List (not for usage questions); 
openstack-operators
Subject: Re: [openstack-dev] [Neutron][SR-IOV]How to assign VF to a VM?

The problem is the sriov mechanism drive failed to bind the port.

For the log I see that you are working with agent_required=True, but the device 
mapping is empty {u'devices': 0, u'device_mappings': {}
Please check the agent configuration file see that you have the following
[securitygroup]
firewall_driver = neutron.agent.firewall.NoopFirewallDriver
[sriov_nic]
physical_device_mappings = physnet1:eth1
exclude_devices =

also can you send the output of “ps �Cef | grep neutron-sriov-nic-agent” 
command?



From: 于洁 [mailto:16189...@qq.com]
Sent: Friday, August 21, 2015 12:01 PM
To: openstack-operators 
openstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org;
 openstack-dev 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][SR-IOV]How to assign VF to a VM?

Hi all,

I try to configure SRIOV on OpenStack Kilo referring the information below.
http://www.qlogic.com/solutions/Documents/UsersGuide_OpenStack_SR-IOV.pdf
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking

Until creating port it works well. But after creating VM using the port created 
before, it was in the state of ERROR. Below is the port information:
neutron port-show 620187c5-b4ac-4aca-bdeb-96205503344d
+---+--+
| Field | Value 
   |
+---+--+
| admin_state_up| True  
   |
| allowed_address_pairs |   
   |
| binding:host_id   | compute   
   |
| binding:profile   | {pci_slot: :09:11.5, physical_network: 
external, pci_vendor_info: 8086:1520} |
| binding:vif_details   | {}
   |
| binding:vif_type  | binding_failed
   |
| binding:vnic_type | direct
   |
| device_id | baab9ba5-80e8-45f7-b86a-8ac3ce8ba944  
   |
| device_owner  | compute:None  
   |
| extra_dhcp_opts   |   
   |
| fixed_ips | {subnet_id: 86849224-a0a7-4059-a6b0-689a2b35c995, 
ip_address: 10.254.4.64}   |
| id| 620187c5-b4ac-4aca-bdeb-96205503344d  
   |
| mac_address   | fa:16:3e:8a:92:9b 
   |
| name  |   
   |
| network_id| db078c2d-63f1-40c0-b6c3-b49de487362b  
   |
| security_groups   | 8e12a661-09b5-41ac-ade8-fddf6d997262  
   |
| status| DOWN  
   |
| tenant_id

[openstack-dev] pci_alias

[Beliveau, Ludovic]

Hi,

I'm configuring multiple pci_alias like so:

pci_alias=[{"vendor_id":"8086", "product_id":"0443", "name":"a1"}, 
{"vendor_id":"8086", "product_id":"0443", "name":"a2"}]

But I'm getting the following error when booting an instance:

ERROR (BadRequest): Invalid PCI alias definition: [{u'vendor_id': u'8086', 
u'product_id': u'0443', u'name': u'a1'}, {u'vendor_id': u'8086', u'product_id': 
u'0443', u'name': u'a2'}] is not of type 'object'

Failed validating 'type' in schema:
{'additionalProperties': False,
 'properties': {'capability_type': {'enum': ['pci'],
'type': 'string'},
'device_type': {'enum': ['NIC', 'ACCEL', 'GPU'],
'type': 'string'},
'name': {'maxLength': 256,
 'minLength': 1,
 'type': 'string'},
'product_id': {'pattern': '^([\\da-fA-F]{4})$',
   'type': 'string'},
'vendor_id': {'pattern': '^([\\da-fA-F]{4})$',
  'type': 'string'}},
 'required': ['name'],
 'type': 'object'}

On instance:
[{u'name': u'a1', u'product_id': u'0443', u'vendor_id': u'8086'},
 {u'name': u'a2', u'product_id': u'0443', u'vendor_id': u'8086'}] (HTTP 
400) (Request-ID: req-3fe994bc-6a99-4c0c-be98-1a22703c58ee)


Based on the code, the default value for the pci_alias is an array.  So I'm 
expecting that defining multiple pci_alias withing an array would be supported. 
 Or am I missing something ?

The workaround to this issue would be to declare each pci_alias in a separate 
line in nova.conf:

pci_alias={"vendor_id":"8086", "product_id":"0443", "name":"a1"}
pci_alias={"vendor_id":"8086", "product_id":"0443", "name":"a2"}

This format is valid for a pci_passthrough_whitelist, I think for clarity and 
consistency they should align.

Furthermore, the nova puppet module (puppet/modules/nova/manifests/api.pp) is 
also expecting the pci_alias to be defined as a list.

Thanks,
/ludovic
__
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] [Nova] SR-IOV subteam

[Beliveau, Ludovic]

Is there a meeting planned for this week ?

Thanks,
/ludovic

On 11/03/2015 12:02 AM, Nikola Đipanov wrote:
> Hello Nova,
>
> Looking at Mitaka specs, but also during the Tokyo design summit
> sessions, we've seen several discussions and requests for enhancements
> to the Nova SR-IOV functionality.
>
> It has been brought up during the Summit that we may want to organize as
> a subteam to track all of the efforts better and make sure we get all
> the expert reviews on stuff more quickly.
>
> I have already added an entry on the subteams page [1] and on the
> reviews etherpad for Mitaka [2]. We may also want to have a meeting
> slot. As I am out for the week, I'll let others propose a time for it
> (that will hopefully work for all interested parites and their
> timezones) and we can take it from there next week.
>
> As always - comments and suggestions much appreciated.
>
> Many thanks,
> Nikola
>
> [1] https://wiki.openstack.org/wiki/Nova#Nova_subteams
> [2] https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
>
> __
> 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] sqlalchemy-utils fails devstack install

[Beliveau, Ludovic]

A bug has been raised against SQLAlchemy-Utils and a fixed has been proposed 
(but not yet merged):
https://github.com/kvesteri/sqlalchemy-utils/pull/193

Workaround for running devstack:

- Download SQLAlchemy-Utils source code (see 
https://sqlalchemy-utils.readthedocs.org/en/latest/installation.html)
- Patch source code locally based on the proposed fix
- Install the package

Regards,
/ludovic

On 02/25/2016 08:27 AM, Sean Dague wrote:
> On 02/24/2016 11:45 PM, Watanabe, Isao wrote:
>> Hello team
>>
>> Does anyone know about why sqlalchemy-utils fails devstack install since 
>> about 3:00 UTC, Feb 25th?
>>
>> Our CI start to fail and in log it says:
>>
>> 2016-02-25 03:34:22.515 | Collecting SQLAlchemy-Utils===0.31.6 (from -c 
>> /opt/stack/new/requirements/upper-constraints.txt (line 24))
>> 2016-02-25 03:34:22.602 |   Downloading SQLAlchemy-Utils-0.31.6.tar.gz 
>> (112kB)
>> 2016-02-25 03:34:23.031 | Complete output from command python setup.py 
>> egg_info:
>> 2016-02-25 03:34:23.031 | error in SQLAlchemy-Utils setup command: 
>> 'extras_require' must be a dictionary whose values are strings or lists of 
>> strings containing valid project/version requirement specifiers.
>> 2016-02-25 03:34:23.031 | 
>> 2016-02-25 03:34:23.031 | 
>> 2016-02-25 03:34:23.062 | Command "python setup.py egg_info" failed with 
>> error code 1 in /tmp/pip-build-eRYND2/SQLAlchemy-Utils
>>
>> However, in mirror[1] which we are using, the package is just there, which 
>> confused me.
>> [1] http://mirror.dfw.rax.openstack.org/pypi/simple/sqlalchemy-utils/
>>
>> Thanks for any help.
>>
>> Best regards,
>> Watanabe.isao
> The failure only exists if you are installing from tar.gz and not from
> wheels. For performance reasons the upstream gate builds a wheel mirror
> and installs from that.
>
> Those wheels were built on old setuptools, work on any version. There is
> a setuptools bug registered for this, which should hopefully be fixed today.
>
>   -Sean
>


__
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] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

[Beliveau, Ludovic]

I'm getting these nova tox errors now (from pip-missing-reqs):
Missing requirements:
nova/crypto.py:29 dist=pycrypto module=Crypto.PublicKey.RSA

I think requirements.txt should now include pycrypto ?  Or am I missing 
something.

Thanks,
/ludovic

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: Sunday, February 14, 2016 5:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto 
vs pycryptodome

Hi,

Short Story:
pycryptodome if installed inadvertently will break several projects:
Example : https://review.openstack.org/#/c/279926/

Long Story:
There's a new kid in town pycryptodome:
https://github.com/Legrandin/pycryptodome

Because pycrypto itself has not been maintained for a while:
https://github.com/dlitz/pycrypto

So folks like pysaml2 and paramiko are trying to switch over:
https://github.com/rohe/pysaml2/commit/0e4f5fa48b1965b269f69bd383bbfbde6b41ac63
https://github.com/paramiko/paramiko/issues/637

In fact pysaml2===4.0.3 has already switched over. So the requirements 
bot/script has been trying to alert us to this new dependency, you can see Nova 
fail.
https://review.openstack.org/#/c/279926/

Why does it fail? For example, the new library is strict about getting bytes 
for keys and has dropped some parameters in methods. for
example:
https://github.com/Legrandin/pycryptodome/blob/master/lib/Crypto/PublicKey/RSA.py#L405
https://github.com/dlitz/pycrypto/blob/master/lib/Crypto/PublicKey/RSA.py#L499

Another problem, if pycrypto gets installed last then things will work, if it 
pycryptodome gets installed last, things will fail. So we definitely cannot 
allow both in our global-requirements and upper-constraints. We can always try 
to pin stuff, but things will fail as there are a lot of jobs that do not honor 
upper-constraints.
And things will fail in the field for Mitaka.

Action:
So what can we do? One possibility is to pin requirements and hope for the 
best. Another is to tolerate the install of either pycrypto or pycryptodome and 
test both combinations so we don't have to fight this battle.

Example for Nova : https://review.openstack.org/#/c/279909/
Example for Glance : https://review.openstack.org/#/c/280008/
Example for Barbican : https://review.openstack.org/#/c/280014/

What do you think?

Thanks,
Dims


--
Davanum Srinivas :: https://twitter.com/dims

__
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] [Nova][SR-IOV][pci-passthrough] Reporting pci devices in hypervisor-show

[Beliveau, Ludovic]

I see a lot of values in having something like this for inventory purposes and 
troubleshooting.

IMHO the information should be provided in two ways.

1. Show PCI pools status per compute.  Currently the pools only have 
information about how many devices are allocated in a pool ("count").  We 
should also derive from the pci_devices db table the number of PCI devices that 
are available per pool (not just the number of allocated).  This information 
could be included in the hypervisor-show (or a new REST API if this is found to 
be too noisy).

2. More detailed information about each individual PCI devices (like you are 
suggesting: parent device relationships, etc.).  This could be in a separate 
REST API call.

We could even think about a third option where we could be showing global PCI 
pools information for a whole region.

For discussions purposes, here's what pci_stats for a compute looks like today:
{"count": 1, "numa_node": 0, "vendor_id": "8086", "product_id": "10fb", "tags": 
{"dev_type": "type-PF", "physical_network": "default"}}, 
"nova_object.namespace": "nova"}
{"count": 3, "numa_node": 0, "vendor_id": "8086", "product_id": "10ed", "tags": 
{"dev_type": "type-VF", "physical_network": "default"}}, 
"nova_object.namespace": "nova"}]}, "nova_object.namespace": "nova"}

Is there an intention to write a blueprint for this feature ?  If there are 
interests, I don't mind working on it.

/ludovic


On 07/08/2016 07:11 AM, Murray, Paul (HP Cloud) wrote:
Hi All,

At the moment I am not aware of a nova api call that provides information about 
the pci devices on a host. The most obvious place to put this would be in 
hypervisor-show. I wonder if anyone has made an attempt at this already or if 
there are any reasons for not adding pci information there?

Assuming pci device information was put in hypervisor-show I would be 
interested in how people think it would be presented. There are different types 
of pci device and things like virtual functions and parent device 
relationships. The information should include the allocation status.

If hypervisor-show is not the place for this I would be interested in 
suggestions on where it should go.

Paul


__
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] [neutron][nova][SR-IOV] deprecation of supported_pci_vendor_devs

[Beliveau, Ludovic]

+1

This validation in neutron is redundant.

/ludovic

-Original Message-
From: Moshe Levi [mailto:mosh...@mellanox.com] 
Sent: August-08-16 8:43 AM
To: OpenStack Development Mailing List (not for usage questions) 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [neutron][nova][SR-IOV] deprecation of 
supported_pci_vendor_devs

Hi all,

To reduce complexity in configuring SR-IOV I want to deprecate the 
supported_pci_vendor_devs option [1] in the neutron-server ml2 config.
This option is doing extra validation that pci vendor id and product id 
provided by nova in the neutron port binding profile is matching to the vendor 
id and product id  in supported_pci_vendor_devs. 

In my opinion this is redundant, nova-scheduler is the point to do validation 
and select a suitable hypervisor. 
The compute node is already validating this through the 
pci_passthrough_whitelist option in nova.conf [2].

I don't see a reason why the neutron-server should validate the pci vendor_id 
and product_id again from the neutron port binding profile. 

If there is good reason to keep it please let me know, otherwise I will 
deprecate it.

[1] - supported_pci_vendor_devs = ['15b3:1004', '8086:10ca'] [2] - 
pci_passthrough_whitelist = 
{"address":"*:06:00.*","physical_network":"physnet1"} 


Thanks,
Moshe

__
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] [nova] Getting DetachedInstanceError from sqlalchemy on instance.get_by_uuid()

[Beliveau, Ludovic]

Hi all,

In kilo (yeah I know it's an old release, but still :)), I was getting a nova 
errors for DetachedInstanceError on instance.get_by_uuid().

2016-10-05 18:30:53.791 103618 ERROR nova.api.metadata.handler 
[req-5aa7b422-d6c0-424e-b40f-cea79d3a3963 - - - - -] Failed to get metadata for 
instance id: 859aba9c-7620-4cbf-a5aa-f6f29c320980
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler Traceback (most 
recent call last):
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/api/metadata/handler.py", line 220, in 
_handle_instance_id_request
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler 
remote_address)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/api/metadata/handler.py", line 106, in 
get_metadata_by_instance_id
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler instance_id, 
address)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/api/metadata/base.py", line 531, in 
get_metadata_by_instance_id
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler instance = 
objects.Instance.get_by_uuid(ctxt, instance_id)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/objects/base.py", line 163, in wrapper
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler result = 
fn(cls, context, *args, **kwargs)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/objects/instance.py", line 654, in 
get_by_uuid
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler 
expected_attrs)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/objects/instance.py", line 608, in 
_from_db_object
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler 
instance._maybe_migrate_flavor(db_inst, expected_attrs)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/nova/objects/instance.py", line 535, in 
_maybe_migrate_flavor
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler if 
instance_extra.get('flavor') is not None:
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/oslo_db/sqlalchemy/models.py", line 60, in 
get
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler return 
getattr(self, key, default)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/attributes.py", line 239, in 
__get__
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler return 
self.impl.get(instance_state(instance), dict_)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/attributes.py", line 591, in 
get
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler value = 
self.callable_(state, passive)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/strategies.py", line 279, in 
_load_for_state
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler 
(orm_util.state_str(state), self.key)
2016-10-05 18:30:53.791 103618 TRACE nova.api.metadata.handler 
DetachedInstanceError: Parent instance  is not 
bound to a Session; deferred load operation of attribute 'flavor' cannot proceed

Now I've fixed it by adding a "joinedload" in the database query (in 
instance_get_by_uuid()) on 'extra'.

So this fixes the issue, what I'd like to understand is why in most cases (like 
99.9% of the time), the code was still working without the "joinedload" ?  What 
could explain that the children object was loaded but at some point dropped 
from the session ?

I tried to reproduce the issue in mitaka (sorry didn't had a newton setup), but 
it appears I can't reproduce it there ...  I was hoping to reproduce it and 
make sure there is no latent bug in nova.

Has anybody seen this issue before or something similar ?

Thanks for the help,
/ludovic
__
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] SRIOV-port refused to bind

[Beliveau, Ludovic]

Also, here’s the pointer to the latest guide which had been updated in this 
last cycle: http://docs.openstack.org/draft/networking-guide/config-sriov.html

Which release are you using ?

What is the content of your neutron ml2_conf.ini file ?

/ludovic

From: Lenny Verkhovsky [mailto:len...@mellanox.com]
Sent: September-29-16 3:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] SRIOV-port refused to bind

HI,
Did you configured everything according to 
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking?
( including intel_iommu=on ) ?
Can you attach more logs and config files of the nova/neutron/neutron plugins
Are you working with devstack or distro?


From: Murali B [mailto:mbi...@gmail.com]
Sent: Thursday, September 29, 2016 5:52 AM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: [openstack-dev] SRIOV-port refused to bind

Hi

I am using the SRIOV on mitaka. When I try to launch the VM with SRIOV port its 
failed.

When I see the neutrn-server.log I see that below message on controller.

ddf81 - - -] Refusing to bind due to unsupported vnic_type: direct bind_port 
/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/mech_agent.py:65
2016-09-28 18:55:18.384 16531 ERROR neutron.plugins.ml2.managers 
[req-443e9b6a-45c6-4b30-aa50-52a9b0a4926c 7d0ef58dd1214f54983c9d843fec0bde 
238c9900a2ae4b57b01fa72abdeddf81 - - -] Failed to bind port 
e96eadf3-5501-442a-8bcc-0b4d64617b26 on host A1-22932-compute1 for vnic_type 
direct using segments [{'segmentation_id': 123, 'physical_network': 
u'physnet1', 'id': u'30b77081-d02c-4e29-a41a-f8997c1f9f66', 'network_type': 
u'vlan'}]

On compute node I see the below error.

2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] flavor, virt_type, self._host)
2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482]   File 
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py", line 447, in 
get_config
2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] _("Unexpected vif_type=%s") % 
vif_type)
2016-09-28 18:55:18.688 7651 ERROR nova.compute.manager [instance: 
4c737a89-51b8-4504-a208-05f2da178482] NovaException: Unexpected 
vif_type=binding_failed

Could somebody help me to come-out this issue.


Thanks
-Murali
__
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] [devstack]VersionConflict exception during stack.sh

[Beliveau, Ludovic]

Try to manually uninstall it first: sudo pip uninstall python-heatclient

Then launch devstack again.  It will re-install the right version.

/ludovic

-Original Message-
From: Wanjing Xu (waxu) [mailto:w...@cisco.com] 
Sent: December-06-16 2:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [devstack]VersionConflict exception during stack.sh

 Hi

2016-12-06 18:50:28.095 | +inc/python:setup_package:354  
pip_install -e /opt/stack/horizon
2016-12-06 18:50:28.881 | +inc/python:pip_install:155    sudo 
-H http_proxy= https_proxy= no_proxy= PIP_FIND_LINKS= 
SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite /usr/local/bin/pip2.7 install -c 
/opt/stack/requirements/upper-constraints.txt --upgrade -e /opt/stack/horizon
2016-12-06 18:50:29.930 | Ignoring dnspython3: markers 'python_version == 
"3.4"' don't match your environment
2016-12-06 18:50:29.931 | Ignoring dnspython3: markers 'python_version == 
"3.5"' don't match your environment
2016-12-06 18:50:30.276 | Obtaining file:///opt/stack/horizon
2016-12-06 18:50:33.097 | Exception:
2016-12-06 18:50:33.098 | Traceback (most recent call last):
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/basecommand.py", line 215, in main
2016-12-06 18:50:33.098 | status = self.run(options, args)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/commands/install.py", line 335, in 
run
2016-12-06 18:50:33.098 | wb.build(autobuilding=True)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
2016-12-06 18:50:33.098 | self.requirement_set.prepare_files(self.finder)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, in 
prepare_files
2016-12-06 18:50:33.098 | ignore_dependencies=self.ignore_dependencies))
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_set.py", line 521, in 
_prepare_file
2016-12-06 18:50:33.098 | req_to_install.check_if_exists()
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/req/req_install.py", line 1036, in 
check_if_exists
2016-12-06 18:50:33.098 | self.req.name
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 558, in get_distribution
2016-12-06 18:50:33.098 | dist = get_provider(dist)
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 432, in get_provider
2016-12-06 18:50:33.098 | return working_set.find(moduleOrReq) or 
require(str(moduleOrReq))[0]
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 968, in require
2016-12-06 18:50:33.098 | needed = 
self.resolve(parse_requirements(requirements))
2016-12-06 18:50:33.098 |   File 
"/usr/local/lib/python2.7/dist-packages/pip/_vendor/pkg_resources/__init__.py", 
line 859, in resolve
2016-12-06 18:50:33.098 | raise VersionConflict(dist, 
req).with_context(dependent_req)
2016-12-06 18:50:33.098 | ContextualVersionConflict: (python-heatclient 1.5.0 
(/usr/local/lib/python2.7/dist-packages), 
Requirement.parse('python-heatclient>=1.6.1'), set(['horizon']))
2016-12-06 18:50:33.233 | +inc/python:pip_install:1  
exit_trap
2016-12-06 18:50:33.240 | +./stack.sh:exit_trap:487  local 
r=2
2016-12-06 18:50:33.250 | ++./stack.sh:exit_trap:488  jobs 
-p
2016-12-06 18:50:33.260 | +./stack.sh:exit_trap:488  jobs=
2016-12-06 18:50:33.269 | +./stack.sh:exit_trap:491  [[ -n 
'' ]]
2016-12-06 18:50:33.278 | +./stack.sh:exit_trap:497  
kill_spinner

__
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] [nova][SR-IOV] update the SR-IOV meeting to bi-weekly

[Beliveau, Ludovic]

Agreed.  Also considering that the amount of known bugs is under control 
(compared to previous cycle), I'm in favor of going to bi-weekly meetings.

/ludovic

-Original Message-
From: Stephen Finucane [mailto:sfinu...@redhat.com] 
Sent: December-01-16 12:38 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][SR-IOV] update the SR-IOV meeting to 
bi-weekly

On Thu, 2016-12-01 at 14:48 +, Moshe Levi wrote:
> Hi all,
> 
> I would like to update the frequency of the SR-IOV meeting to be  bi- 
> weekly [1].
> Does anyone see value in keeping it as weekly meeting?
> 
> [1] - https://review.openstack.org/#/c/405415/

Seeing as we don't have any specs during this short cycle, I think moving back 
to bi-weekly is a good idea. We can reassess come February and the Pike cycle.

Stephen

__
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