Re: [openstack-dev] [ironic][neutron] SmartNics with Ironic

[Moshe Levi]

Hi Julia,

Apologize we were not able to be there to better represent the use case.

PSB

From: Julia Kreger 
Sent: Monday, October 1, 2018 11:07 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: isaku.yamah...@intel.com; Eyal Lavee 
Subject: Re: [openstack-dev] [ironic][neutron] SmartNics with Ironic

Greetings, Comments in-line.

Thanks,

-Julia

On Sat, Sep 29, 2018 at 11:27 PM Moshe Levi 
mailto:mosh...@mellanox.com>> wrote:
Hi Julia,

I don't mind to update the ironic spec [1]. Unfortunately, I wasn't in the PTG 
but I had a sync meeting with Isuku.

As I see it there is 2 use-cases:
1.   Running the neutron ovs agent in the smartnic
2.   Running the neutron super ovs agent which manage the ovs running on 
the smartnic.

My takeaway from the meeting with neutron is that there would not be a neutron 
ovs agent running on the smartnic. That the configuration would need to be 
pushed at all times, which is ultimately better security wise if the tenant NIC 
is somehow compromised it reduces the control plane exposure.
[ML] - Can you elaborate on  the security concerns with running the neutron ovs 
agent on the smart NIC?
If you compare this to the standard virtualization use case, this is as secure 
if not more secure.
The tenant image runs in the bare metal host and receives only a network 
interface/port.
The host has no way to access the OS/services/agents running on the smart NIC 
CPUs, in the same way that a tenant image running in a VM has no way to access 
the services/agents running in the hypervisor.
It is in fact event more secure, as they are running in physically disjoint 
hardware and memory (thus not accessible even through side-channel 
vulnerabilities such as meltdown/spectre).

1.

It seem that most of the discussion was around the second use-case.

By the time Ironic and Neutron met together, it seemed like the first use case 
was no longer under consideration. I may be wrong, but very strong preference 
existed for the second scenario when we met the next day.
[ML] –
We are seeing great interest on smart NICs for bare metal use cases to allow to 
provide services (networking, storage and others) to bare metal servers that 
were previously only possible for VMs.
Conceptually the smart NIC can be thought of as an isolated hypervisor layer 
for the bare metal host.
The first service we are targeting in this spec is aligning the bare metal 
networking with the standard neutron ovs agent.
The target is to try to align (as possible) the bare metal implementation to 
the virtualization use case, up to the point of actually running (as possible) 
the same agents on the smart NIC (again acting as a hypervisor for the bare 
metal host use case).
This allows to reuse/align the implementation, and naturally scales with the 
number of bare metal servers, as opposed to running the agents on controller 
nodes, requiring potentially scaling the controllers to match the number of 
bare metal servers.
It also provides a path to providing more advanced services in the smart NIC in 
the next steps (not limiting the implementation to be OVSDB protocol specific).


This is my understanding on the ironic neutron PTG meeting:

  1.  Ironic cores don't want to change the deployment interface as proposed in 
[1].
  2.  We should  a new network_interface for use case 2. But what about the 
first use case? Should it be a new network_interface as well?
  3.  We should delay the port binding until the baremetal is powered on the 
ovs is running.

 *   For the first use case I was thinking to change the neutron server to 
just keep the port binding information in the neutron DB. Then when the neutron 
ovs agent is a live it will retrieve all the baremeal port , add them to the 
ovsdb and start the neutron ovs agent fullsync.
 *   For the second use case the agent is alive so the agent itself can 
monitor the ovsdb of the baremetal and configure it when it up

  1.  How to notify that neutron agent successfully/unsuccessfully bind the 
port ?

 *   In both use-cases we should use neutron-ironic notification to make 
sure the port binding was done successfully.

Is my understanding correct?

Not quite.

1) We as in Ironic recognize that there would need to be changes, it is the 
method as to how that we would prefer to be explicit and have chosen by the 
interface. The underlying behavior needs to be different, and the new 
network_interface should support both cases 1 and 2 because that interface 
contain needed logic for the conductor to determine the appropriate path 
forward. We should likely also put some guards in to prevent non-smart 
interfaces from being used in the same configuration due to the security issues 
that creates.
3) I believe this would be more of a matter of the network_interface knowing 
that the machine is powered up, and attempting to assert configuration through 
Neutron to push configuration to the smartnic.
3a) The con

Re: [openstack-dev] [ironic][neutron] SmartNics with Ironic

[Moshe Levi]

Hi Julia,

I don't mind to update the ironic spec [1]. Unfortunately, I wasn't in the PTG 
but I had a sync meeting with Isuku.

As I see it there is 2 use-cases:

  1.  Running the neutron ovs agent in the smartnic
  2.  Running the neutron super ovs agent which manage the ovs running on the 
smartnic.

It seem that most of the discussion was around the second use-case.

This is my understanding on the ironic neutron PTG meeting:

  1.  Ironic cores don't want to change the deployment interface as proposed in 
[1].
  2.  We should  a new network_interface for use case 2. But what about the 
first use case? Should it be a new network_interface as well?
  3.  We should delay the port binding until the baremetal is powered on the 
ovs is running.
 *   For the first use case I was thinking to change the neutron server to 
just keep the port binding information in the neutron DB. Then when the neutron 
ovs agent is a live it will retrieve all the baremeal port , add them to the 
ovsdb and start the neutron ovs agent fullsync.
 *   For the second use case the agent is alive so the agent itself can 
monitor the ovsdb of the baremetal and configure it when it up
  4.  How to notify that neutron agent successfully/unsuccessfully bind the 
port ?
 *   In both use-cases we should use neutron-ironic notification to make 
sure the port binding was done successfully.

Is my understanding correct?



[1] - https://review.openstack.org/#/c/582767/

From: Miguel Lavalle 
Sent: Sunday, September 30, 2018 3:20 AM
To: OpenStack Development Mailing List 
Subject: Re: [openstack-dev] [ironic][neutron] SmartNics with Ironic

Hi,

Yes, this also matches the recollection of the joint conversation in Denver. 
Please look at the "Ironic x-project discussion - Smartnics" section in 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/135032.html

Regards

Miguel



On Thu, Sep 27, 2018 at 1:31 PM Julia Kreger 
mailto:juliaashleykre...@gmail.com>> wrote:
Greetings everyone,

Now that the PTG is over, I would like to go ahead and get the
specification that was proposed to ironic-specs updated to represent
the discussions that took place at the PTG.

A few highlights from my recollection:

* Ironic being the source of truth for the hardware configuration for
the neutron agent to determine where to push configuration to. This
would include the address and credential information (certificates
right?).
* The information required is somehow sent to neutron (possibly as
part of the binding profile, which we could send at each time port
actions are requested by Ironic.)
* The Neutron agent running on the control plane connects outbound to
the smartnic, using information supplied to perform the appropriate
network configuration.
* In Ironic, this would likely be a new network_interface driver
module, with some additional methods that help facilitate the
work-flow logic changes needed in each deploy_interface driver module.
* Ironic would then be informed or gain awareness that the
configuration has been completed and that the deployment can proceed.
(A different spec has been proposed regarding this.)

I have submitted a forum session based upon this and the agreed upon
goal at the PTG was to have the ironic spec written up to describe the
required changes.

I guess the next question is, who wants to update the specification?

-Julia

__
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] [tripleo][nova] nova rx_queue_size tx_queue_size config options breaks booting vm with SR-IOV

[Moshe Levi]

Hi all,

Recent change in tripleo [1] configure nova rx_queue_size tx_queue_size config 
by default.
It seem that this config option breaks booting vm with SR-IOV. See [2]
The issues is because of this code [3] which configure virtio queue size if the 
in the interface xml the driver is vhost or None.
In case of SR-IOV the driver is also None and that why we get the error.
A quick fix will be adding driver=vfio to [4]
I just wonder if there are other interface in the libvirt xml which this can 
have the same issue.


[1] - 
https://github.com/openstack/tripleo-heat-templates/commit/444fc042dca3f9a85e8f7076ce68114ac45478c7#diff-99a22d37b829681d157f41d35c38e4c5
[2] - http://paste.openstack.org/show/728666/
[3] -  https://review.openstack.org/#/c/595592/
[4] - 
https://github.com/openstack/nova/blob/34956bea4beb8e5ba474b42ba777eb88a5eadd76/nova/virt/libvirt/designer.py#L123
__
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] testing 123

[Moshe Levi]

__
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] Removing networking-mlnx from Debian?

[Moshe Levi]

> -Original Message-
> From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> Sent: Monday, April 16, 2018 10:44 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] Removing networking-mlnx from Debian?
> 
> On 2018-04-13 14:17:29 + (+), Moshe Levi wrote:
> [...]
> > Yes, How can we add python3 job in zuul for testing it?
> 
> I've proposed
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> iew.openstack.org%2F561703=02%7C01%7Cmoshele%40mellanox.com
> %7C5bffbf4cda7b4efc8df408d5a3d26fad%7Ca652971c7d2e4d9ba6a4d149256f
> 461b%7C0%7C0%7C636595046579652523=7pNgYdNQnNvno%2FH29ZF
> qh00D6Sn0l5cB6tqnGMePrQ4%3D=0 to add the corresponding
> Python3.5 version of your unit test jobs. Looks like it's passing if you want 
> to
> the openstack-tox-py35 job (Ran: 176 tests in 8.8742 sec.) if you feel like
> approving.
Approved. Thanks :) 
> --
> Jeremy Stanley

__
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] Removing networking-mlnx from Debian?

[Moshe Levi]

What are the python3 issues that you see?

tox -epy34 and all the unit test are passing? (tested on cento 7.4) 



[1] 
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_port_processing_network
 2.642
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_network_filter_phynset
  2.572
networking_mlnx.tests.unit.ml2.drivers.mlnx.test_mech_mlnx.MlnxMechanismIbPortTestCase.test_precommit_ib_config_dont_update
  2.310
networking_mlnx.tests.unit.ml2.drivers.mlnx.test_mech_mlnx.MlnxMechanismIbPortTestCase.test_precommit_ib_port_deleted_port
   2.291
networking_mlnx.tests.unit.ml2.drivers.mlnx.test_mech_mlnx.MlnxMechanismIbPortTestCase.test_precommit_ib_port_non_migration
  2.252
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_port_delete_pending_port_update
 2.250
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_port_filter_phynset
 2.237
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_driver
  2.201
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_network_update_pending_network_create
   2.135
networking_mlnx.tests.unit.ml2.drivers.sdn.test_mechanism_sdn.SdnDriverTestCase.test_network
 1.981
__
 summary 
___
  py34: commands succeeded
  congratulations :)



> -Original Message-
> From: Moshe Levi
> Sent: Friday, April 13, 2018 5:14 PM
> To: OpenStack Development Mailing List  d...@lists.openstack.org>
> Subject: RE: [openstack-dev] Removing networking-mlnx from Debian?
> 
> Hi Thomas,
> 
> Networking-mlnx is still maintained.
> We will fix all the issues next week and I will create a tag for it.
> 
> > -Original Message-
> > From: Thomas Goirand [mailto:z...@debian.org]
> > Sent: Friday, April 13, 2018 2:50 PM
> > To: OpenStack Development Mailing List  > d...@lists.openstack.org>
> > Subject: [openstack-dev] Removing networking-mlnx from Debian?
> >
> > Hi,
> >
> > Is networking-mlnx actively maintained? It doesn't look like it to me,
> > there's still no Queens release. It also fails to build in Debian,
> > with apparently no Python 3 support.
> >
> > Without any reply from an active maintainer, I'll ask for this package
> > to be removed from Debian.
> >
> > Please let me know,
> > Cheers,
> >
> > Thomas Goirand (zigo)
> >
> >
> __
> > 
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> > requ...@lists.openstack.org?subject:unsubscribe
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> > openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> >
> dev=02%7C01%7Cmoshele%40mellanox.com%7C7cb48464a3b24d0fc10
> >
> e08d5a134b5a0%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6365
> >
> 92171104919078=BFuUnC5qJWNm0J7WPZtosLJeuww%2BVwc4s%2Bu
> > rIaF3jbQ%3D=0
__
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] Removing networking-mlnx from Debian?

[Moshe Levi]

> -Original Message-
> From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> Sent: Friday, April 13, 2018 3:08 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] Removing networking-mlnx from Debian?
> 
> On 2018-04-13 13:49:47 +0200 (+0200), Thomas Goirand wrote:
> > Is networking-mlnx actively maintained? It doesn't look like it to me,
> > there's still no Queens release.
> 
> It looks like they were merging changes to master and backporting to
> stable/queens as recently as three weeks ago, but I agree they don't seem
> to have tagged their 9.0.0 release yet. They're not part of any official 
> project
> though, so it's hard to guess what their release timeframe might be.
> 
> > It also fails to build in Debian, with apparently no Python 3 support.
> [...]
> 
> Right, from what I can see they're not testing Python 3 support for their
> changes, not even in a non-voting capacity.
Yes, How can we add python3 job in zuul for testing it?

> --
> Jeremy Stanley

__
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] Removing networking-mlnx from Debian?

[Moshe Levi]

Hi Thomas,

Networking-mlnx is still maintained. 
We will fix all the issues next week and I will create a tag for it.  

> -Original Message-
> From: Thomas Goirand [mailto:z...@debian.org]
> Sent: Friday, April 13, 2018 2:50 PM
> To: OpenStack Development Mailing List  d...@lists.openstack.org>
> Subject: [openstack-dev] Removing networking-mlnx from Debian?
> 
> Hi,
> 
> Is networking-mlnx actively maintained? It doesn't look like it to me, there's
> still no Queens release. It also fails to build in Debian, with apparently no
> Python 3 support.
> 
> Without any reply from an active maintainer, I'll ask for this package to be
> removed from Debian.
> 
> Please let me know,
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C7cb48464a3b24d0fc10
> e08d5a134b5a0%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6365
> 92171104919078=BFuUnC5qJWNm0J7WPZtosLJeuww%2BVwc4s%2Bu
> rIaF3jbQ%3D=0
__
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] [ironic][triploe] support for firmware update

[Moshe Levi]

Hi all,

I saw that ironic-python-agent support custom hardware manager.
I would like to support firmware updates (In my case Mellanox nic) and I was 
wandering how custom hardware manager can be used in such case?
How it is integrated with ironic-python agent and also is there an integration 
to tripleO as well.

The use case for use is just to make sure the correct firmware is installed on 
the nic and if not update it during the triple deployment.




[1] - 
https://docs.openstack.org/ironic-python-agent/pike/contributor/hardware_managers.html
__
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] [ironic][neutron] bare metal on vxlan network

[Moshe Levi]

Hi all,

Ironic supports  mutli tenancy for quite few releases and according to the spec 
[1] it can work with vlan/vxlan networks.
I see lot of mechanism driver that support vlan network such as [2] and [3] , 
but I didn't find any mechanism driver that work on vxlan network.
Is there a mechanism driver that can configure vtep on a switch exist for the 
bare metal?

Help would be appreciated


[1] 
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html
[2] https://github.com/openstack/networking-arista
[3] https://github.com/openstack/networking-generic-switch
__
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] [tripleo] opendaylight OpenDaylightConnectionProtocol deprecation issue

[Moshe Levi]

> -Original Message-
> From: Ben Nemec [mailto:openst...@nemebean.com]
> Sent: Wednesday, January 31, 2018 5:10 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>; Moshe Levi
> <mosh...@mellanox.com>
> Subject: Re: [openstack-dev] [tripleo] opendaylight
> OpenDaylightConnectionProtocol deprecation issue
> 
> 
> 
> On 01/29/2018 04:27 AM, Moshe Levi wrote:
> > Hi all,
> >
> > It seem that this commit [1] deprecated the
> > OpenDaylightConnectionProtocol, but it also remove it.
> >
> > This is causing the following issue when we deploy opendaylight non
> > containerized. See [2]
> >
> > One solution is to add back the OpenDaylightConnectionProtocol [3] the
> > other solution is to remove the OpenDaylightConnectionProtocol from
> > the deprecated parameter_groups [4].
> 
> Looks like the deprecation was done incorrectly.  The parameter should have
> been left in place and referenced in the deprecated group.  So I think the fix
> would just be to put the parameter definition back.
Ok I proposed this fix https://review.openstack.org/#/c/539917/  to resolve it. 


> 
> >
> > [1] -
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Fopenstack%2Ftripleo-heat-
> templates%2Fcommit%2Faf4ce05dc5270b
> >
> 84864a382ddb2a1161d9082eab=02%7C01%7Cmoshele%40mellanox.co
> m%7C5d3
> >
> 64a8250a14e007a2608d568bca27e%7Ca652971c7d2e4d9ba6a4d149256f461b%
> 7C0%7
> >
> C0%7C636530081767314146=gNmuv%2FzlusnYp7TXI6t9dFIRbPRC2MDj
> F5yoxa
> > ktGGE%3D=0
> >
> >
> > [2] -
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpast
> >
> e.openstack.org%2Fshow%2F656702%2F=02%7C01%7Cmoshele%40m
> ellanox.c
> >
> om%7C5d364a8250a14e007a2608d568bca27e%7Ca652971c7d2e4d9ba6a4d14
> 9256f46
> >
> 1b%7C0%7C0%7C636530081767314146=AMfcY2FcaOm8lZNMOu3iYKYf
> 4ecjgP18
> > 6im32Ujg1tE%3D=0
> >
> > [3] -
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Fopenstack%2Ftripleo-heat-
> templates%2Fcommit%2Faf4ce05dc5270b
> > 84864a382ddb2a1161d9082eab%23diff-
> 21674daa44a327c016a80173efeb10e7L20&
> >
> data=02%7C01%7Cmoshele%40mellanox.com%7C5d364a8250a14e007a2608d
> 568bca2
> >
> 7e%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636530081767314
> 146
> >
> ta=5pyiYUINi%2FmQ1%2F19kaIJY2KQ35bHhbZ%2Fq7PvUnRFZP4%3D
> ed=0
> >
> >
> > [4] -
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Fopenstack%2Ftripleo-heat-
> templates%2Fcommit%2Faf4ce05dc5270b
> > 84864a382ddb2a1161d9082eab%23diff-
> 21674daa44a327c016a80173efeb10e7R112
> >
> =02%7C01%7Cmoshele%40mellanox.com%7C5d364a8250a14e007a260
> 8d568bca
> >
> 27e%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63653008176731
> 4146
> >
> ata=uUi6XJbZs6LOuGkqDD%2BWTLaZvso8U7srwbL%2BKXvGm44%3D
> ved=0
> >
> >
> >
> >
> >
> __
> 
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C5d364a8250a14e007a
> 2608d568bca27e%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636
> 530081767314146=m2R5u%2FXA6SnPFk%2FHW13W%2BCYtMbGUI9p
> Ww%2B3U2qFmUaw%3D=0
> >

__
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] [tripleo][opendaylight puppet] failed to deploy odl master with latest opendaylight puppet

[Moshe Levi]

Hi all,

We are trying to test solution of the odl hw offload in tripleo.
We have already merged the odl support for ovs hardware offload [1].
We are trying to test that everting is working with tripleo, but we get failure 
with jetty.xml.orig.
For some reason it get configure like [2] and causing opendaylight for failed 
to load http.
It seem that there is problem with opendaylight puppet that is misconfiguring 
jetty.xml.orig

Any help would be appreciated


[1] -  https://git.opendaylight.org/gerrit/#/c/67704/
[2] - http://paste.openstack.org/show/657899/
__
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] [tripleo] opendaylight OpenDaylightConnectionProtocol deprecation issue

[Moshe Levi]

Hi all,

It seem that this commit [1] deprecated the OpenDaylightConnectionProtocol, but 
it also remove it.
This is causing the following issue when we deploy opendaylight non 
containerized. See [2]

One solution is to add back the OpenDaylightConnectionProtocol [3] the other 
solution is to remove the OpenDaylightConnectionProtocol from the deprecated 
parameter_groups [4].



[1] - 
https://github.com/openstack/tripleo-heat-templates/commit/af4ce05dc5270b84864a382ddb2a1161d9082eab

[2] - http://paste.openstack.org/show/656702/

[3] - 
https://github.com/openstack/tripleo-heat-templates/commit/af4ce05dc5270b84864a382ddb2a1161d9082eab#diff-21674daa44a327c016a80173efeb10e7L20

[4] - 
https://github.com/openstack/tripleo-heat-templates/commit/af4ce05dc5270b84864a382ddb2a1161d9082eab#diff-21674daa44a327c016a80173efeb10e7R112

__
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] [tripleO] quickstart with containers deployment failed

[Moshe Levi]

Hi,

We are trying to add container support ovs hw offload.
We were able to do the deployment  a few weeks ago, but now we getting an 
errors .
Jan 14 07:14:32 localhost os-collect-config: "2018-01-14 07:14:28,568 WARNING: 
18476 -- retrying pulling image: 
192.168.24.1:8787/tripleomaster/centos-binary-neutron-server:current-tripleo",
Jan 14 07:14:32 localhost os-collect-config: "2018-01-14 07:14:31,587 WARNING: 
18476 -- docker pull failed: Get
https://192.168.24.1:8787/v1/_ping: dial tcp 192.168.24.1:8787: getsockopt: 
connection refused",
see log below [1].
We tried to run
openstack overcloud container image tag discover   --image 
trunk.registry.rdoproject.org/master/centos-binary-base:current-tripleo-rdo   
--tag-from-label rdo_version

and we are getting the errors below [2]

Help would be much appreciated.



[1] http://paste.openstack.org/show/644227/
[2] http://paste.openstack.org/show/644228/
__
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] [tripleo] odl deployment failed due to opendaylight websocket config in haproxy

[Moshe Levi]

Hi,

So I did some investigation and it seem that the problem is with 
puppet-opendaylight.
The was a change to allow configure the ip address for the web sockets which 
uses 
restconf.cfg<https://git.opendaylight.org/gerrit/#/c/64242/1/restconf/sal-rest-connector-config/src/main/resources/initial/restconf.cfg>
 config file see [1].
This change was backport to nitrogen as well.
The carbon change for allowing configure websocket ip address is different [2] 
and uses 
10-rest-connector.xml<https://git.opendaylight.org/gerrit/#/c/64602/7/restconf/sal-rest-connector-config/src/main/resources/initial/10-rest-connector.xml>.

In the puppet opendaylight the change that was introduce is according to carbon 
to create 
10-rest-connector.xml<https://git.opendaylight.org/gerrit/#/c/64602/7/restconf/sal-rest-connector-config/src/main/resources/initial/10-rest-connector.xml>.
I create a patch that configure the 
restconf.cfg<https://git.opendaylight.org/gerrit/#/c/64242/1/restconf/sal-rest-connector-config/src/main/resources/initial/restconf.cfg>
 [4]. I tested and it solve  my issue. It should be backport to nitrogen as 
well.


[1] - https://git.opendaylight.org/gerrit/#/c/64242
[2] - https://git.opendaylight.org/gerrit/#/c/64602/
[3] - https://git.opendaylight.org/gerrit/#/c/64775/
[4] - https://git.opendaylight.org/gerrit/#/c/66777/




From: Janki Chhatbar [mailto:jankih...@gmail.com]
Sent: Wednesday, December 27, 2017 6:33 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; Moshe Levi <mosh...@mellanox.com>
Subject: Re: [openstack-dev] [tripleo] odl deployment failed due to 
opendaylight websocket config in haproxy

Hi Moshe

There is a corresponding ODL patch [1]. To verify if the rpm you are using has 
it, see if 
10-rest-connector.xml<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.opendaylight.org%2Fgerrit%2F%23%2Fc%2F64602%2F7%2Frestconf%2Fsal-rest-connector-config%2Fsrc%2Fmain%2Fresources%2Finitial%2F10-rest-connector.xml=02%7C01%7Cmoshele%40mellanox.com%7C3f265f35ab734eeccb5a08d54ce2fb98%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636499460131485309=%2FK0hyyD8yOx%2BhZNBA8j8k6qpoNXTvArOCk8CO%2FaVa40%3D=0>
 has a line ""



[1]. 
https://git.opendaylight.org/gerrit/#/c/64602/<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.opendaylight.org%2Fgerrit%2F%23%2Fc%2F64602%2F=02%7C01%7Cmoshele%40mellanox.com%7C3f265f35ab734eeccb5a08d54ce2fb98%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636499460131485309=NLNE%2BjsILG6Q2111Mn7RLqUAjTMcQQHZvIQNRiFwSik%3D=0>

On Tue, Dec 26, 2017 at 4:29 PM, Moshe Levi 
<mosh...@mellanox.com<mailto:mosh...@mellanox.com>> wrote:
Hi all,

When I try to deploy tripleo with opendaylight oxygen release (we did a private 
build for master) it failed with haproxy failing
that it can't bind the opendaylight_ws: cannot bind socket see [1]. This is 
failing all the deployment as the haproxy is down.

The opendaylight_ws was introduced in this commit 
https://github.com/openstack/puppet-tripleo/commit/bc3feec75f8dc1bac6691ce8cd05a37c27aa5e42<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenstack%2Fpuppet-tripleo%2Fcommit%2Fbc3feec75f8dc1bac6691ce8cd05a37c27aa5e42=02%7C01%7Cmoshele%40mellanox.com%7C3f265f35ab734eeccb5a08d54ce2fb98%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636499460131485309=dDxT%2FzvezgY%2ByExVNiLDsPq4eh21gXZnr7WnUllrIDc%3D=0>
If I will try to deploy with puppet-tripleo before that commit everything is 
passing and working.

Any Idea how to fix this? Maybe we should revert 
https://github.com/openstack/puppet-tripleo/commit/bc3feec75f8dc1bac6691ce8cd05a37c27aa5e42<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenstack%2Fpuppet-tripleo%2Fcommit%2Fbc3feec75f8dc1bac6691ce8cd05a37c27aa5e42=02%7C01%7Cmoshele%40mellanox.com%7C3f265f35ab734eeccb5a08d54ce2fb98%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636499460131485309=dDxT%2FzvezgY%2ByExVNiLDsPq4eh21gXZnr7WnUllrIDc%3D=0>
 ?

Deployment works fine with this patch.

[1] -
Dec 26 10:32:56 localhost systemd: Starting HAProxy Load Balancer...
Dec 26 10:32:57 localhost haproxy-systemd-wrapper: [WARNING] 359/103257 (20629) 
: parsing [/etc/haproxy/haproxy.cfg:141] : 'option httplog' not usable with 
proxy 'nova_metadata' (needs 'mode http'). Falling back to 'option tcplog'.
Dec 26 10:32:57 localhost haproxy[20629]: Proxy cinder started.
Dec 26 10:32:57 localhost haproxy-systemd-wrapper: [WARNING] 359/103257 (20629) 
: Setting tune.ssl.default-dh-param to 1024 by default, if your workload 
permits it you should set it to at least 2048. Please set a value >= 1024 to 
make this warning disappear.
Dec 26 10:32:57 localhost haproxy-systemd-wrapper: [ALERT] 359/103257 (20629) : 
Starting proxy opendaylight_ws: cannot bind socket 
[172.16.2.11:8185<https://emea01.safelinks.prot

[openstack-dev] [tripleo] odl deployment failed due to opendaylight websocket config in haproxy

[Moshe Levi]

Hi all,

When I try to deploy tripleo with opendaylight oxygen release (we did a private 
build for master) it failed with haproxy failing
that it can't bind the opendaylight_ws: cannot bind socket see [1]. This is 
failing all the deployment as the haproxy is down.

The opendaylight_ws was introduced in this commit 
https://github.com/openstack/puppet-tripleo/commit/bc3feec75f8dc1bac6691ce8cd05a37c27aa5e42
If I will try to deploy with puppet-tripleo before that commit everything is 
passing and working.

Any Idea how to fix this? Maybe we should revert 
https://github.com/openstack/puppet-tripleo/commit/bc3feec75f8dc1bac6691ce8cd05a37c27aa5e42
 ?

[1] -
Dec 26 10:32:56 localhost systemd: Starting HAProxy Load Balancer...
Dec 26 10:32:57 localhost haproxy-systemd-wrapper: [WARNING] 359/103257 (20629) 
: parsing [/etc/haproxy/haproxy.cfg:141] : 'option httplog' not usable with 
proxy 'nova_metadata' (needs 'mode http'). Falling back to 'option tcplog'.
Dec 26 10:32:57 localhost haproxy[20629]: Proxy cinder started.
Dec 26 10:32:57 localhost haproxy-systemd-wrapper: [WARNING] 359/103257 (20629) 
: Setting tune.ssl.default-dh-param to 1024 by default, if your workload 
permits it you should set it to at least 2048. Please set a value >= 1024 to 
make this warning disappear.
Dec 26 10:32:57 localhost haproxy-systemd-wrapper: [ALERT] 359/103257 (20629) : 
Starting proxy opendaylight_ws: cannot bind socket [172.16.2.11:8185]
Dec 26 10:32:57 localhost haproxy-systemd-wrapper: [ALERT] 359/103257 (20629) : 
Starting proxy opendaylight_ws: cannot bind socket [192.168.24.7:8185]
Dec 26 10:32:57 localhost haproxy[20629]: Proxy glance_api started.


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-dev] [tripleo] tripleo-heat-templates CI is not unit test

[Moshe Levi]

Hi all,

While working on improving the environment_generator.py we found out that the 
unit test are broken see fix in [1]
This is happened because no CI job in tripleo-heat-templates runes tox -epy27.
Can you please add this job to tripleo-heat-templates?



[1] - https://review.openstack.org/#/c/530081/
__
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] [tripleo] Blueprints moved out to Rocky

[Moshe Levi]

I believe so,
Just regarding the use of sample-env-generator tool is not supporting 
parameters for roles:
Such as  :

  # Kernel arguments for ComputeSriov node
  ComputeSriovParameters:
KernelArgs: "intel_iommu=on iommu=pt"
OvsHwOffload: True

So can we merged the patches as is and fix the sample-env-generator late?

> -Original Message-
> From: Alex Schultz [mailto:aschu...@redhat.com]
> Sent: Tuesday, December 12, 2017 12:20 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky
> 
> On Mon, Dec 11, 2017 at 1:20 PM, Brad P. Crochet 
> wrote:
> >
> >
> > On Fri, Dec 8, 2017 at 6:35 PM Alex Schultz  wrote:
> >>
> >> Hey folks,
> >>
> >> So I went through the list of blueprints and moved some that were
> >> either not updated or appeared to have a bunch of patches not in a
> >> mergable state.
> >>
> >> Please take some time to review the list of blueprints currently
> >> associated with Rocky[0] to see if your efforts have been moved. If
> >> you believe you're close to implementing the feature in the next week
> >> or two, let me know and we can move it back into Queens. If you think
> >> it will take an extended period of time (more than 2 weeks) to land
> >> but we need it in Queens, please submit an FFE.
> >>
> >
> > I think these are in a close enough state to warrant inclusion in Queens:
> >
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Fget-networks-
> action=0
> >
> 2%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8ccc08d540e56
> 51a%7Ca
> >
> 652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636486276360618857
> ta=EKi
> > 0yRd07V01KvoZoiQY%2FMIZU9OPZHez6%2F06PL7e7EU%3D=0
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Ftripleo-common-list-
> availa
> > ble-roles-
> action=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee862294
> >
> 7ea8ccc08d540e5651a%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7
> C63648
> >
> 6276360618857=rNn1Ujf2XKCslsW7idN1qJwn0DWpN7I8A4gvYWiELbI
> %3D
> > erved=0
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Ftripleo-common-select-
> role
> > s-
> workflow=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947
> ea8cc
> >
> c08d540e5651a%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6364
> 8627636
> >
> 0618857=jpH6L7d1c0w6WDZxPoeDeHBzb0T2FIgEhHiT3PElEMg%3D
> served=
> > 0
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Fupdate-networks-
> action
> >
> a=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8ccc08d540
> e5651a%
> >
> 7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636486276360618857&
> sdata=
> > AlBpvtX3kdMedrO%2BehaRaTUhl%2BUclJdesiqsu7HvvEA%3D=0
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Fvalidate-roles-
> networks
> >
> ta=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8ccc08d540
> e5651a
> >
> %7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63648627636061885
> 7
> >
> =uDK%2F4Wo9S0D9qySb%2BORYVE1HDtrJ0J6Ec8qWU8hUwkw%3D
> d=0
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Fupdate-roles-
> action=0
> >
> 2%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8ccc08d540e56
> 51a%7Ca
> >
> 652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636486276360618857
> ta=Oos
> > SA5xeI4L4Ue6XbPh1Wd83tUU1SehQG%2BaSxRFXNW8%3D=0
> >
> 
> Ok I reviewed them and they do appear to have patches posted and are
> getting reviews.  I'll pull them back in to Queens and set the milestone to
> queens-3. Please make sure to update us on the status during this week and
> next week's IRC meetings. I would like to make sure these land ASAP. Do you
> think they should be in a state to land by the end of next week say 12/21?
> 
> Thanks,
> -Alex
> 
> > There is a good chance of these being completed in the coming week.
> >
> > Thanks,
> >
> > Brad
> >>
> >>
> > --
> > Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer
> > (c) 704.236.9385
> >
> >
> >
> __
> 
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7Caf36fee8622947ea8cc
> c08d540e5651a%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6364
> 86276360618857=vzMYyfhGhBEbJjEWeBCjQwAdsOdk7ZokGM7RI63Re
> NQ%3D=0
> >
> 
> 

Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky

[Moshe Levi]

> -Original Message-
> From: Alex Schultz [mailto:aschu...@redhat.com]
> Sent: Monday, December 11, 2017 8:31 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky
> 
> On Fri, Dec 8, 2017 at 6:11 PM, Moshe Levi <mosh...@mellanox.com> wrote:
> > Hi Alex,
> >
> > I don't see the tripleo ovs hardware offload feature. The spec was merge
> into queens [1], but for some reason the blueprint is not in approve state 
> [2].
> >
> 
> Just as a reminder it's everyone's responsibility to make sure their 
> blueprints
> are properly up to date. I've mentioned this in the weekly meeting a
> few[0][1] times in the last month. I've added the patches from this email into
> the blueprint for tracking
Sorry I didn’t know 
> 
> > I has only 3 patches left:
> > 1.
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> >
> iew.openstack.org%2F%23%2Fc%2F507401%2F=02%7C01%7Cmoshele
> %40mella
> >
> nox.com%7Cab9e4e0441974f8465c108d540c5812b%7Ca652971c7d2e4d9ba6a
> 4d1492
> >
> 56f461b%7C0%7C0%7C636486139387929919=BWaNEcgEAp59IE%2FdX
> 6cBoDueb
> > s%2FlJBKh7P%2BepnQP38g%3D=0 has 2 +2 2.
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> >
> iew.openstack.org%2F%23%2Fc%2F507100%2F=02%7C01%7Cmoshele
> %40mella
> >
> nox.com%7Cab9e4e0441974f8465c108d540c5812b%7Ca652971c7d2e4d9ba6a
> 4d1492
> >
> 56f461b%7C0%7C0%7C636486139387929919=iiVBnWBoVnGnhMC%2B
> SIYWjd1uS
> > DVNovnHR0Tr8oxetY0%3D=0 has 1 +2 3.
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> >
> iew.openstack.org%2F%23%2Fc%2F518715%2F=02%7C01%7Cmoshele
> %40mella
> >
> nox.com%7Cab9e4e0441974f8465c108d540c5812b%7Ca652971c7d2e4d9ba6a
> 4d1492
> >
> 56f461b%7C0%7C0%7C636486139387929919=LwfNUwfdrhqWGwWyG
> bO8LdrhJyk
> > e4ydqVe7s6wgth%2Bo%3D=0
> >
> > I would appreciated if we can land all the patches to  queens release.
> 
> We should be able to land these and they appear to be in decent shape.
> Please reach out on irc if you aren't getting additional reviews on these.  It
> would be really beneficial to land these in the new week or so if possible.
Ok I will

Thanks Alex
> 
> Thanks,
> -Alex
> 
> [0]
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Feav
> esdrop.openstack.org%2Fmeetings%2Ftripleo%2F2017%2Ftripleo.2017-11-
> 28-14.00.log.html%23l-
> 106=02%7C01%7Cmoshele%40mellanox.com%7Cab9e4e0441974f8465c
> 108d540c5812b%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6364
> 86139387929919=XzUZGUp8qffSXL4yCYYxWjdHjkByPBvIeOjveFiFthg%
> 3D=0
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Feav
> esdrop.openstack.org%2Fmeetings%2Ftripleo%2F2017%2Ftripleo.2017-11-
> 14-14.01.log.html%23l-
> 170=02%7C01%7Cmoshele%40mellanox.com%7Cab9e4e0441974f8465c
> 108d540c5812b%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6364
> 86139387929919=vacSmcfZZxexRUxCzOhIv7qqLo38JrN%2BjRc77bDiT
> W4%3D=0
> 
> >
> > [1] -
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> >
> iew.openstack.org%2F%23%2Fc%2F502313%2F=02%7C01%7Cmoshele
> %40mella
> >
> nox.com%7Cab9e4e0441974f8465c108d540c5812b%7Ca652971c7d2e4d9ba6a
> 4d1492
> >
> 56f461b%7C0%7C0%7C636486139387929919=6khPnm%2B0u%2B2M6D
> ojHrFNC7x
> > HUgLuNI3hOWEFniF8Bxg%3D=0
> > [2] -
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> > eprints.launchpad.net%2Ftripleo%2F%2Bspec%2Ftripleo-ovs-hw-
> offload
> >
> a=02%7C01%7Cmoshele%40mellanox.com%7Cab9e4e0441974f8465c108d540
> c5812b%
> >
> 7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636486139387929919&
> sdata=
> > QUycuuC%2Ft2PSgc%2FIv2KeYlhdGLeE16z4ECFNI2CPBSw%3D=0
> >
> >> -Original Message-
> >> From: Alex Schultz [mailto:aschu...@redhat.com]
> >> Sent: Saturday, December 9, 2017 1:34 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> <openstack-dev@lists.openstack.org>
> >> Subject: [openstack-dev] [tripleo] Blueprints moved out to Rocky
> >>
> >> Hey folks,
> >>
> >> So I went through the list of blueprints and moved some that were
> >> either not updated or appeared to have a bunch of patches not in a
> mergable state.
> >>
> >> Please take some time to review the list of blueprints currently
> >> associated with Rocky[0] to see if your efforts have been m

Re: [openstack-dev] [tripleo] Blueprints moved out to Rocky

[Moshe Levi]

Hi Alex, 

I don't see the tripleo ovs hardware offload feature. The spec was merge into 
queens [1], but for some reason the blueprint is not in approve state [2].

I has only 3 patches left: 
1.  https://review.openstack.org/#/c/507401/ has 2 +2
2.  https://review.openstack.org/#/c/507100/ has 1 +2 
3.  https://review.openstack.org/#/c/518715/

I would appreciated if we can land all the patches to  queens release. 

[1] - https://review.openstack.org/#/c/502313/
[2] - https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-hw-offload 

> -Original Message-
> From: Alex Schultz [mailto:aschu...@redhat.com]
> Sent: Saturday, December 9, 2017 1:34 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [tripleo] Blueprints moved out to Rocky
> 
> Hey folks,
> 
> So I went through the list of blueprints and moved some that were either not
> updated or appeared to have a bunch of patches not in a mergable state.
> 
> Please take some time to review the list of blueprints currently associated
> with Rocky[0] to see if your efforts have been moved. If you believe you're
> close to implementing the feature in the next week or two, let me know and
> we can move it back into Queens. If you think it will take an extended period
> of time (more than 2 weeks) to land but we need it in Queens, please submit
> an FFE.
> 
> If you have an blueprint that is currently not in implemented in Queens[1],
> please make sure to update the blueprint status if possible.  For the ones I
> left in due to the patches being in a decent state, please make sure those get
> merged in the next few weeks or we will need to push them out to Rocky.
> 
> Thanks,
> -Alex
> 
> 
> [0]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> eprints.launchpad.net%2Ftripleo%2Frocky=02%7C01%7Cmoshele%40
> mellanox.com%7C0abe7d8deef74a13d29508d53e945633%7Ca652971c7d2e4d
> 9ba6a4d149256f461b%7C0%7C0%7C636483729194465277=xDwvHSmx
> niqu6HN5FaQB2DTc6N8mRS879Ku1y4FDLss%3D=0
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblu
> eprints.launchpad.net%2Ftripleo%2Fqueens=02%7C01%7Cmoshele%4
> 0mellanox.com%7C0abe7d8deef74a13d29508d53e945633%7Ca652971c7d2e4
> d9ba6a4d149256f461b%7C0%7C0%7C636483729194465277=v6v1yDjt1f
> dc3FAILGsS2voCiMUmaLQGPwwxNtTzcso%3D=0
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C0abe7d8deef74a13d2
> 9508d53e945633%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636
> 483729194465277=N%2B78nm8bMlSWsASO6uIX2mJlO1%2BX9VfTM2
> A3qUu6GUk%3D=0
__
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] [tripleo] overcloud keystone error "Could not determine a suitable URL for the plugin"

[Moshe Levi]

How do I tell quickstart to generate certs and enable tls?

From: Juan Antonio Osorio [mailto:jaosor...@gmail.com]
Sent: Wednesday, December 6, 2017 5:24 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tripleo] overcloud keystone error "Could not 
determine a suitable URL for the plugin"



On 6 Dec 2017 16:58, "Moshe Levi" 
<mosh...@mellanox.com<mailto:mosh...@mellanox.com>> wrote:
I have the access to 10.0.0.0 network
I remove the
-e /home/stack/enable-tls.yaml -e 
~/heat-templates/environments/tls-endpoints-public-ip.yaml -e 
/home/stack/inject-trust-anchor.yaml
Form the ./overcloud-deploy.sh and now it working
The issue you posted wasn't a TLS issue, but it might be that it was being 
hidden by nova. You could truly to access keystone directly and that will be 
more revealing.

My /home/stack/enable-tls.yaml and /home/stack/inject-trust-anchor.yaml  were 
taken from

wget 
https://raw.githubusercontent.com/openstack-infra/tripleo-ci/master/test-environments/enable-tls.yaml<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fopenstack-infra%2Ftripleo-ci%2Fmaster%2Ftest-environments%2Fenable-tls.yaml=02%7C01%7Cmoshele%40mellanox.com%7Cadfadec5a9aa40e0d56508d53cbd6053%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481706419069326=MBqec8H5KjiEIPJDT%2F1UxxBntYERIfT6EykQNKCIaIA%3D=0>

wget 
https://raw.githubusercontent.com/openstack-infra/tripleo-ci/master/test-environments/inject-trust-anchor.yaml<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fopenstack-infra%2Ftripleo-ci%2Fmaster%2Ftest-environments%2Finject-trust-anchor.yaml=02%7C01%7Cmoshele%40mellanox.com%7Cadfadec5a9aa40e0d56508d53cbd6053%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481706419069326=SBRviDdKz1OGlrfqyDHVGPWvyKwz4eLxB%2BuxfCKIEj0%3D=0>
This will only work if you use the exact same fixed IP as we use in CI. So i 
don't recommend using that. Rather generate your own certs or tell quickstart 
to do it for you by using the appropriate flag.

So maybe the is an issue with tripleo or just these config files

From: Juan Antonio Osorio 
[mailto:jaosor...@gmail.com<mailto:jaosor...@gmail.com>]
Sent: Wednesday, December 6, 2017 12:36 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [tripleo] overcloud keystone error "Could not 
determine a suitable URL for the plugin"

From the node you're running the nova command, do you have access to the 
10.0.0.0 network (external)?

In virtual environments, quickstart will leave an overcloud-prep-network.sh 
script that will create a vlan interface that gives the undercloud access to 
that network. So, if it's a virtual environment and you're running that command 
from the undercloud (which from the log you sent it seems that's the case) you 
need to run that. Note that you need to run that every time you update your 
undercloud.

BR


On 6 Dec 2017 09:06, "Moshe Levi" 
<mosh...@mellanox.com<mailto:mosh...@mellanox.com>> wrote:
Hi all,

We deploy tripleo master using quickstart.
We this delorean repo:
name=delorean
baseurl=https://trunk.rdoproject.org/centos7-master/ac/82/ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrunk.rdoproject.org%2Fcentos7-master%2Fac%2F82%2Fac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7%2F=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481534161188454=R6s6CvAGGAB97GYgCsCsT%2BxU0PQ1fZ89xAuUQFM5tL8%3D=0>

The undercloud and overcloud deployment were successfully, but we I try to run 
command on the overcloud
I am getting the  keystone error "Could not determine a suitable URL for the 
plugin"
See nova-list with debug info [1]
Do you know how to resolve this? Help in troubleshooting this issue will be 
appreciated.


[1]  
http://paste.openstack.org/show/628240/<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpaste.openstack.org%2Fshow%2F628240%2F=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481534161188454=o4nTXxk826W8ys1W1DvZUelSLS5uTT9McwazErh3wOY%3D=0>





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2FOpenStack-dev-request%40lists.openstack.org%3Fsubject%3Aunsubscribe=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481534161188

Re: [openstack-dev] [tripleo] overcloud keystone error "Could not determine a suitable URL for the plugin"

[Moshe Levi]

I have the access to 10.0.0.0 network
I remove the
-e /home/stack/enable-tls.yaml -e 
~/heat-templates/environments/tls-endpoints-public-ip.yaml -e 
/home/stack/inject-trust-anchor.yaml
Form the ./overcloud-deploy.sh and now it working

My /home/stack/enable-tls.yaml and /home/stack/inject-trust-anchor.yaml  were 
taken from

wget 
https://raw.githubusercontent.com/openstack-infra/tripleo-ci/master/test-environments/enable-tls.yaml

wget 
https://raw.githubusercontent.com/openstack-infra/tripleo-ci/master/test-environments/inject-trust-anchor.yaml

So maybe the is an issue with tripleo or just these config files

From: Juan Antonio Osorio [mailto:jaosor...@gmail.com]
Sent: Wednesday, December 6, 2017 12:36 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tripleo] overcloud keystone error "Could not 
determine a suitable URL for the plugin"

From the node you're running the nova command, do you have access to the 
10.0.0.0 network (external)?

In virtual environments, quickstart will leave an overcloud-prep-network.sh 
script that will create a vlan interface that gives the undercloud access to 
that network. So, if it's a virtual environment and you're running that command 
from the undercloud (which from the log you sent it seems that's the case) you 
need to run that. Note that you need to run that every time you update your 
undercloud.

BR


On 6 Dec 2017 09:06, "Moshe Levi" 
<mosh...@mellanox.com<mailto:mosh...@mellanox.com>> wrote:
Hi all,

We deploy tripleo master using quickstart.
We this delorean repo:
name=delorean
baseurl=https://trunk.rdoproject.org/centos7-master/ac/82/ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrunk.rdoproject.org%2Fcentos7-master%2Fac%2F82%2Fac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7%2F=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481534161188454=R6s6CvAGGAB97GYgCsCsT%2BxU0PQ1fZ89xAuUQFM5tL8%3D=0>

The undercloud and overcloud deployment were successfully, but we I try to run 
command on the overcloud
I am getting the  keystone error "Could not determine a suitable URL for the 
plugin"
See nova-list with debug info [1]
Do you know how to resolve this? Help in troubleshooting this issue will be 
appreciated.


[1]  
http://paste.openstack.org/show/628240/<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpaste.openstack.org%2Fshow%2F628240%2F=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481534161188454=o4nTXxk826W8ys1W1DvZUelSLS5uTT9McwazErh3wOY%3D=0>





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2FOpenStack-dev-request%40lists.openstack.org%3Fsubject%3Aunsubscribe=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481534161188454=Zv8CbJlDuv3ZEiLbp%2BHX%2FQEqTDd%2Fndh4wd700hNdW8I%3D=0>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev=02%7C01%7Cmoshele%40mellanox.com%7C4ae1221315a84cee96a708d53c9544bd%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636481534161188454=T7Tc%2FtBAv1zl4X3TbTJIqQQ5ZW2PtSrvxVACYChEa40%3D=0>
__
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] [tripleo] overcloud keystone error "Could not determine a suitable URL for the plugin"

[Moshe Levi]

Hi all,

We deploy tripleo master using quickstart.
We this delorean repo:
name=delorean
baseurl=https://trunk.rdoproject.org/centos7-master/ac/82/ac82ea9271a4ae3860528eaf8a813da7209e62a6_28eeb6c7/

The undercloud and overcloud deployment were successfully, but we I try to run 
command on the overcloud
I am getting the  keystone error "Could not determine a suitable URL for the 
plugin"
See nova-list with debug info [1]
Do you know how to resolve this? Help in troubleshooting this issue will be 
appreciated.


[1]  http://paste.openstack.org/show/628240/




__
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] Infiniband & Melanox OFED 4.2 eIPoIB support

[Moshe Levi]

This more question to mellanox then to neutron community. 
I suggest that you will send me private mail regarding this issue and we can 
take it with the relevant people in Mellanox.
My email is mosh...@mellanox.com.  

> -Original Message-
> From: Massimo Benini [mailto:ben...@cscs.ch]
> Sent: Tuesday, November 14, 2017 11:39 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Neutron] Infiniband & Melanox OFED 4.2 eIPoIB
> support
> 
> Dear Neutron developers,
> 
> we are building up an OpenStack (Pike) cluster based on CentOS 7.4 and
> Mellanox Ofed 4.2.
> As far as we understand Neutron rely on eIPoIB in order to manage
> Infiniband networks but unfortunately Mellanox dropped this feature for the
> new OFED versions.
> Here below the Mellanox support answer about that:
> 
> "Please note that as of Mellanox OFED 4.0 eIPoIB is no longer supported in
> Mellanox OFED.If you wish to use it we recommend using the 3.4.X Drivers
> which still supported this feature."
> 
> Obviously we can not use the 3.X version of OFED because is not supported
> by RHEL 7.4 and also because we don't want to stick with an old software
> version.
> Do you have any plan to overcome this issue?
> 
> Thank you, regards
> 
> Massimo Benini
> 
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C6de1b0a14e4540045a
> 4108d52b434d35%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636
> 462490423586383=oEdi3vFeR4CEBom7rZNHajd%2BmujXhuHrT49yTx7
> Q5Bk%3D=0
__
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] [tripleO] building overcloud image with opendaylight

[Moshe Levi]

Hi all,

We are now working on to support the OVS hardware offload with opendaylight 
deployment.
First setup we want to deploy triple with just opendaylight mechanism driver.
I have some question regarding the deployment:

1 . As I understand from the documentation the we need to build overcloud with 
odl  is that right?
2. where do I get the latest odl rpm for centos?

Thanks in advance,

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

Re: [openstack-dev] [os-vif] [nova] Changes to os-vif cores

[Moshe Levi]

> -Original Message-
> From: Sahid Orentino Ferdjaoui [mailto:sferd...@redhat.com]
> Sent: Wednesday, October 25, 2017 11:22 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [os-vif] [nova] Changes to os-vif cores
> 
> On Tue, Oct 24, 2017 at 03:32:15PM +0100, Stephen Finucane wrote:
> > Hey,
> >
> > I'm not actually sure what the protocol is for adding/removing cores
> > to a library project without a PTL, so I'm just going to put this out
> > there: I'd like to propose the following changes to the os-vif core team.
> >
> > - Add 'nova-core'
> >
> >   os-vif makes extensive use of objects and we've had a few hiccups around
> >   versionings and the likes recently [1][2]. I'd the expertise of some of 
> > the
> >   other nova cores here as we roll this out to projects other than nova, 
> > and I
> >   trust those not interested/knowledgeable in this area to stay away
> > :)
> >
> > - Remove Russell Bryant, Maxime Leroy
> >
> >   These folks haven't been active on os-vif  [3][4] for a long time and I 
> > think
> >   they can be safely removed.
> 
> Indeed, they are not active. Seems to be reasonable.
+1
> 
> > To the existing core team members, please respond with a yay/nay and
> > we'll wait a week before doing anything.
> >
> > Cheers,
> > Stephen
> >
> > [1]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> >
> iew.openstack.org%2F%23%2Fc%2F508498%2F=02%7C01%7Cmoshele
> %40mella
> >
> nox.com%7Cf9470c2a06914266f7b508d51b819b76%7Ca652971c7d2e4d9ba6a
> 4d1492
> >
> 56f461b%7C0%7C0%7C636445165832350206=PU5gKHSscjFPUaFb5%2B
> g4QyWdv
> > VPWZQE6IuVTERcg1Zg%3D=0 [2]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> >
> iew.openstack.org%2F%23%2Fc%2F509107%2F=02%7C01%7Cmoshele
> %40mella
> >
> nox.com%7Cf9470c2a06914266f7b508d51b819b76%7Ca652971c7d2e4d9ba6a
> 4d1492
> >
> 56f461b%7C0%7C0%7C636445165832350206=CrXbAUP%2Fut5hov%2F
> YpfVVevu
> > pDzyJpqaoYjXDzSJnbDE%3D=0
> > [3]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> >
> iew.openstack.org%2F%23%2Fq%2Freviewedby%3A%2522Russell%2BBryant
> %2B%25
> >
> 253Crbryant%25=02%7C01%7Cmoshele%40mellanox.com%7Cf9470c2a
> 0691426
> >
> 6f7b508d51b819b76%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C
> 6364451
> >
> 65832350206=l7iWjHiCxiouHJdWxbvwI9Gi%2Bne8o14TlcfBWHttT8Y%3
> D
> > erved=0 2540redhat.com%253E%22+project:openstack/os-vif
> > [4]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> >
> iew.openstack.org%2F%23%2Fq%2Freviewedby%3A%2522Maxime%2BLeroy
> %2B%2525
> >
> 3Cmaxime.ler=02%7C01%7Cmoshele%40mellanox.com%7Cf9470c2a06
> 914266f
> >
> 7b508d51b819b76%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63
> 6445165
> >
> 832350206=8ywHQPppzRO2CAl6e1jzSOLx5G4gvHxRkGzl6qEgbyY%3D
> 
> > d=0 oy%25406wind.com%253E%22+project:openstack/os-vif
> >
> >
> __
> 
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> > s.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02
> >
> %7C01%7Cmoshele%40mellanox.com%7Cf9470c2a06914266f7b508d51b819b
> 76%7Ca6
> >
> 52971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636445165832350206
> a=2NIN
> > pJxKv%2BIq0iPCCm7UDPyFNaI9X47d%2B2MmpEQSlPI%3D=0
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7Cf9470c2a06914266f7b
> 508d51b819b76%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6364
> 45165832350206=2NINpJxKv%2BIq0iPCCm7UDPyFNaI9X47d%2B2Mm
> pEQSlPI%3D=0
__
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] [TripleO] Configure SR-IOV VFs in tripleo

[Moshe Levi]

> -Original Message-
> From: Saravanan KR [mailto:skram...@redhat.com]
> Sent: Tuesday, October 3, 2017 1:36 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO] Configure SR-IOV VFs in tripleo
> 
> On Tue, Sep 26, 2017 at 3:37 PM, Moshe Levi <mosh...@mellanox.com>
> wrote:
> > Hi  all,
> >
> >
> >
> > While working on tripleo-ovs-hw-offload work, I encounter the
> > following issue with SR-IVO.
> >
> >
> >
> > I added -e ~/heat-templates/environments/neutron-sriov.yaml -e
> > ~/heat-templates/environments/host-config-and-reboot.yaml to the
> > overcloud-deploy.sh.
> >
> > The computes nodes are configure with the intel_iommu=on kernel option
> > and the computes are reboot as expected,
> >
> > than the tripleo::host::sriov will create /etc/sysconfig/allocate_vfs
> > to configure the SR-IOV VF. It seem it requires additional reboot for
> > the SR-IOV VFs to be created. Is that expected behavior? Am I doing
> > something wrong?
> 
> The file allocate_vfs is required for the subsequent reboots, but during the
> deployment, the vfs are created by puppet-tripleo [1]. No additional reboot
> required for creating VFs.
Yes, I am not sure what went wrong in my first attempt, but know it is working 
as expected.
 
> 
> Regards,
> Saravanan KR
> 
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> hub.com%2Fopenstack%2Fpuppet-
> tripleo%2Fblob%2Fmaster%2Fmanifests%2Fhost%2Fsriov.pp%23L19=0
> 2%7C01%7Cmoshele%40mellanox.com%7C92c6146ab3e5460df36808d50a4aa
> 2db%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63642623803127
> 6659=zSCKOPHBHyiZXmSs4CLVMxWsZ3KCkp3JGhYZuPZRpY8%3D
> erved=0
> 
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > [1]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Fopenstack%2Fpuppet-
> tripleo%2Fblob%2F80e646ff779a0f8e201daec0
> >
> c927809224ed5fdb%2Fmanifests%2Fhost%2Fsriov.pp=02%7C01%7Cmo
> shele%
> >
> 40mellanox.com%7C92c6146ab3e5460df36808d50a4aa2db%7Ca652971c7d2e
> 4d9ba6
> >
> a4d149256f461b%7C0%7C0%7C636426238031276659=OBk9S2mnCNoG
> eygYwviv
> > DCDOo4vtG2vAIpHG7yRmpC4%3D=0
> >
> >
> >
> __
> 
> >  OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> > s.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02
> >
> %7C01%7Cmoshele%40mellanox.com%7C92c6146ab3e5460df36808d50a4aa2
> db%7Ca6
> >
> 52971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636426238031276659
> a=x%2F
> > 0%2F2nDx79tfpFCHyDRFdekO0gCStBbuvviUzVZ9An0%3D=0
> >
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C92c6146ab3e5460df3
> 6808d50a4aa2db%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636
> 426238031276659=x%2F0%2F2nDx79tfpFCHyDRFdekO0gCStBbuvviUz
> VZ9An0%3D=0
__
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] [TripleO][DIB] how create triplo overcloud image with latest kernel?

[Moshe Levi]

Thanks you all for the tips.
We were able to create image using blogpost that Yolanda mentioned.

From: Yolanda Robla Mota [mailto:yrobl...@redhat.com]
Sent: Wednesday, September 27, 2017 6:40 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Moshe Levi <mosh...@mellanox.com>; Hasan Qunoo <has...@mellanox.com>; 
Waleed Musa <wale...@mellanox.com>
Subject: Re: [openstack-dev] [TripleO][DIB] how create triplo overcloud image 
with latest kernel?

If you need a guideline about how to build TripleO images with DIB, i have that 
blogpost: 
http://teknoarticles.blogspot.com.es/2017/07/build-and-use-security-hardened-images.html<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fteknoarticles.blogspot.com.es%2F2017%2F07%2Fbuild-and-use-security-hardened-images.html=02%7C01%7Cmoshele%40mellanox.com%7C6f913bbb62a14993fdaf08d505be10a0%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636421236235553988=eZqPKn0Q%2BP8FJ%2Fe8v7CJXCT4ACNDyiNC980%2BFvbgKss%3D=0>
This if for security hardened images, but your replace 
"overcloud-hardened-images" by "overcloud-images", it will build the default 
one. You can specify the base image you want to use, as well as enable any repo 
you have, that may take the latest kernel.
Hope it helps!

On Wed, Sep 27, 2017 at 5:21 PM, Brad P. Crochet 
<b...@redhat.com<mailto:b...@redhat.com>> wrote:

On Tue, Sep 26, 2017 at 2:58 PM Ben Nemec 
<openst...@nemebean.com<mailto:openst...@nemebean.com>> wrote:


On 09/26/2017 05:43 AM, Moshe Levi wrote:
> Hi all,
>
> As part of the OVS Hardware Offload [1] [2],  we need to create new
> Centos/Redhat 7 image  with latest kernel/ovs/iproute.
>
> We tried to use virsh-customize to install the packages and we were able
> to update iproute and ovs, but for the kernel there is no space.
>
> We also tried with virsh-customize to uninstall the old kenrel but we no
> luck.
>
> Is other ways to replace kernel  package in existing image?

Do you have to use an existing image?  The easiest way to do this would
be to create a DIB element that installs what you want and just include
that in the image build in the first place.  I don't think that would be
too difficult to do now that we're keeping the image definitions in
simple YAML files.

If it is just packages, a DIB element wouldn't even be necessary. You could 
define a new yaml that just adds the packages that you want, and add that to 
the CLI when you build the images.

>
> [1] - 
> https://review.openstack.org/#/c/504911/<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.openstack.org%2F%23%2Fc%2F504911%2F=02%7C01%7Cmoshele%40mellanox.com%7C6f913bbb62a14993fdaf08d505be10a0%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636421236235553988=X8eJ6XL2v6%2BUepvqpcmlRVSWKobPQV6kjawZShL%2BCD4%3D=0>
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.openstack.org%2F%23%2Fc%2F504911%2F=02%7C01%7Cmoshele%40mellanox.com%7Cc801dab0778b428e226508d504c97ecf%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636420185839119329=6oEmh0LJacV3WPGGp3wW%2BhL3nPDxRh%2BzNPY67X09Blc%3D=0>
>
>
> [2] - 
> https://review.openstack.org/#/c/502313/<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.openstack.org%2F%23%2Fc%2F502313%2F=02%7C01%7Cmoshele%40mellanox.com%7C6f913bbb62a14993fdaf08d505be10a0%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636421236235553988=SEF6cyDF8IBlroFbbO8BPMYNOJe7n35azGVKfmYUIaM%3D=0>
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.openstack.org%2F%23%2Fc%2F502313%2F=02%7C01%7Cmoshele%40mellanox.com%7Cc801dab0778b428e226508d504c97ecf%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636420185839119329=EsydZ9EsUjkYcF92Gys569SJEvQ%2B%2Fu6uV8WAQJ0YMfc%3D=0>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2FOpenStack-dev-request%40lists.openstack.org%3Fsubject%3Aunsubscribe=02%7C01%7Cmoshele%40mellanox.com%7C6f913bbb62a14993fdaf08d505be10a0%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636421236235553988=MEMmNdpo5geSrCeMa6LxPP%2BYc8qxM%2Bh1SQ3nOWF2T3Y%3D=0>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev=02%7C01%7Cmoshele%40mellanox.com%7C6f913bbb62a14993fdaf08d505be10a0%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636421236235553988=x5kGvCTcWxS2VdwjhbHo54Euu2Ahjhm2FpVBonlZi%2FM%3D=0>
>

[openstack-dev] [TripleO][DIB] how create triplo overcloud image with latest kernel?

[Moshe Levi]

Hi all,

As part of the OVS Hardware Offload [1] [2],  we need to create new 
Centos/Redhat 7 image  with latest kernel/ovs/iproute.
We tried to use virsh-customize to install the packages and we were able to 
update iproute and ovs, but for the kernel there is no space.
We also tried with virsh-customize to uninstall the old kenrel but we no luck.
Is other ways to replace kernel  package in existing image?



[1] - 
https://review.openstack.org/#/c/504911/
[2] - 
https://review.openstack.org/#/c/502313/


__
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] [TripleO] OVS Hardware Offload

[Moshe Levi]

Hi all,

We are planning to add TripleO  support for OVS Hardware Offload, which was 
pushed to pike release [1] [2] [3].
Here is documentation commit which explain on how to use the feature [4].
We already wrote a spec for TripleO [5] and some POC code [6] [7] [8] and we 
would appreciate if we can get reviews.
Patches [6] [7] [8] are adding the support to the ovs mechanism driver, but  we 
also plan to add patches to support ODL with OVS Hardware Offload

[1] -https://review.openstack.org/#/c/275616/
[2] - https://review.openstack.org/#/c/452530/
[3] -https://review.openstack.org/#/c/398265/
[4] - https://review.openstack.org/#/c/504911/
[5] - https://review.openstack.org/#/c/502313/
[6] - https://review.openstack.org/#/c/502440/
[7] - https://review.openstack.org/#/c/507100/
[8] - https://review.openstack.org/#/c/507401/


Thanks,
Moshe Levi.
__
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] [TripleO] Configure SR-IOV VFs in tripleo

[Moshe Levi]

Hi  all,

While working on tripleo-ovs-hw-offload 
work, I encounter the following issue with SR-IVO.

I added -e ~/heat-templates/environments/neutron-sriov.yaml -e 
~/heat-templates/environments/host-config-and-reboot.yaml to the 
overcloud-deploy.sh.
The computes nodes are configure with the intel_iommu=on kernel option and the 
computes are reboot as expected,
than the tripleo::host::sriov will create /etc/sysconfig/allocate_vfs to 
configure the SR-IOV VF. It seem it requires additional reboot for the SR-IOV 
VFs to be created. Is that expected behavior? Am I doing something wrong?




[1] 
https://github.com/openstack/puppet-tripleo/blob/80e646ff779a0f8e201daec0c927809224ed5fdb/manifests/host/sriov.pp
__
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] [networking-ovn] Support for direct vnic_type

[Moshe Levi]

> -Original Message-
> From: pranab boruah [mailto:pranabjyotibor...@gmail.com]
> Sent: Friday, September 22, 2017 5:06 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Cc: Moshe Levi <mosh...@mellanox.com>
> Subject: [openstack-dev] [networking-ovn] Support for direct vnic_type
> 
> Thanks Moshe for the quick reply.
> 
> I can definitely use some guidance for contributing on this( a newbie here).
> Few questions:
> 1. Do you think this support could be added in queens release cycle? I think
> blueprints submission for queens is closed right?
I think it still open
> 2. For adding this support, some changes to the OVN components might be
> required too or just changes in the networking-ovn driver would be enough?
I am not sure I have not look on OVN at all. I would suggest to start with the 
networking-ovn to see if it working  
> 3. What tool do you guys use to deploy a muti-node cluster to start
> development? We used PackStack to deploy a 3-node Pike cluster with OVN,
> and it gave us enough nightmares of a lifetime.J
We use devstack. 
> 
> -Pranab
__
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] [os-vif] [passthrough] [VifHostDevice]

[Moshe Levi]

The ODL part is still not ready. We need to do code changes in odl to make it 
work see [1] [2]

[1] https://git.opendaylight.org/gerrit/#/c/62481/ 
[2] https://git.opendaylight.org/gerrit/#/c/60259/ 

We try to make the design as generic as possible so if you have a SR-IOV NIC 
that support switchdev 
And allow to offload rules using linux tc it should work.  

> -Original Message-
> From: pranab boruah [mailto:pranabjyotibor...@gmail.com]
> Sent: Friday, September 22, 2017 4:50 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [os-vif] [passthrough] [VifHostDevice]
> 
> Thanks Sean for such a descriptive answer. It definitely helped.
> 
> >the hardware offload support for melonox nics is only supported with
> >the openvswitch or odl >ml2 dirvers
> [Pranab] Okay. We have the option of using ODL as the mechanism driver
> too. I am building the cluster with ODL as the mechanism driver right now and
> would experiment with it.
> Do you think there is a design limitation in VIFHostDevice model that limits 
> us
> in using either only Mellanox or Netronome NICs? AFAIK, say I have a SRIOV
> NIC that supports OVS offload and Switchdev and we use openvswitch/odl as
> the mechanism driver, things should work as expected for this NIC too right?
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C5d64f1a6da0142ffb40
> 908d501c0c634%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63641
> 6849830686294=eU2fTih8PqnDEpmNugmDMmOB2I40znLkEpbEmfYS3
> 3Y%3D=0
__
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] [networking-ovn] Support for direct vnic_type

[Moshe Levi]

Hi, 

From  Mellanox perspective supporting direct port in OVN is in the plan. 
One of the reason that we did not contribute this change to OVN was because of 
that OVN support geneve tunnel and not vxlan.
(Mellanox card don't support hw-offloading of  geneve).
 If you want to contribute please go head I would happy to review the code 
changes. 

> -Original Message-
> From: pranab boruah [mailto:pranabjyotibor...@gmail.com]
> Sent: Friday, September 22, 2017 4:17 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [networking-ovn] Support for direct vnic_type
> 
> Hi,
> I request you to go through this thread :
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fpipermail%2Fopenstack-dev%2F2017-
> September%2F122447.html=02%7C01%7Cmoshele%40mellanox.com%
> 7C58f94f72a2b0453b525708d501bc6fc5%7Ca652971c7d2e4d9ba6a4d149256f4
> 61b%7C0%7C0%7C636416831208380962=QoirMj6E5QrBPwwxt9MR21F
> WjoW%2B1ScEacio4us8eIs%3D=0
> 
> As Sean pointed out that Direct vnic_type is not yet supported in OVN, while
> it is supported in ODL and OVS.
> I wanted to know if there is any plan to add this support in OVN too?
> Or is there is a limitation in OVN architectural design that limits the 
> support of
> Direct vinc_type?
> 
> Would be happy to contribute if required.
> 
> Thanks,
> Pranab
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.
> openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C58f94f72a2b0453b525
> 708d501bc6fc5%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C63641
> 6831208380962=BImVSbVcqyDh49OLzKcRWC6Kh0A%2Bgoe9uhWslRu
> uVdE%3D=0
__
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] [os-vif] [vif_plug_ovs] Queries on VIF_Type VIFHostDevice

[Moshe Levi]

-Original Message-
From: Mooney, Sean K [mailto:sean.k.moo...@intel.com] 
Sent: Wednesday, August 9, 2017 6:36 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type 
VIFHostDevice



> -Original Message-
> From: Moshe Levi [mailto:mosh...@mellanox.com]
> Sent: Wednesday, August 9, 2017 3:25 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on 
> VIF_Type VIFHostDevice
> 
> Hi,
> 
> 1) you should use neutron port with vnic_type direct
> 2) yes,  just use neutron port with vnic_type  direct and confighure 
> the nova compute with pci passthogth whitelist
> 3) you can configure firewall_driver = openvswitch to work with 
> Conntrack.
> 
> So in your case if have SR-IOV nic which doesn't support  hardware 
> offload (but has VF representors port)  you will just fallback to the 
> ovs kernel datapath.

[Mooney, Sean K] that is not what will happen with intel nics and I would be 
doubtful Based on the code I have seen in nova and neutron that a fallback will 
happen with mellanox.
If the neutron port has vnic_type direct it will Always result in a sriov vf 
being allocated for that port. 
There is no check in nova to ensure ovs support vf configuration and there is 
no check in neutron ml2 driver Either. This is why I wanted the feature based 
scheduling to prevent this from happening as that would prevent Nova from 
allocating the vf which would cause scheduling to fail.

[Moshe Levi] This is not what I meant. I was talking on the implementation of 
the ovs 2.8.0 hardware offload. 
I was referring  for NIC with SR-IOV that support representor ports switchdev 
mode (maybe I miss understood the question).  If it just SR-IOV NIC then you 
are correct.  
 

When nova generates the Libvirt xml for that interface it will configure that 
port to use sriov direct pass-through.
If ovs does not support managing that nic via the representor netdev or the nic 
does not support the tc flower protocol then the port add will not fail as we 
are just adding the representor netdev as a normal port But it will not be able 
to preform any control plane actions on it. there is no way for a Libvirt 
hostdevice to gracefully fall back to the kernel dataplane without modifying 
Xml. After all we are not even adding the vf to ovs we are adding a representor 
port to ovs so the dataplane is entirely bypassing ovs for unsupported nics.


As long as you have the host has vf available and the ovs ml2 driver is listed 
before the sriov nic Agent ml2 driver you will get into this broken state.

> The ovs 2.8.0 code try to offload each datapath rule to NIC hardware 
> if it failed it fails back to the ovs kernel datapath.
> So if have NIC that can offload classification  on vlan  and action 
> output. Only datapath flows that constructed for this classification 
> and action  will be offload to hardware.
> 
> -Original Meyssage-
> From: pranab boruah [mailto:pranabjyotibor...@gmail.com]
> Sent: Wednesday, August 9, 2017 4:36 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type 
> VIFHostDevice
> 
> Hi,
> I am experimenting with the os-vif library and stumbled upon this new 
> VIF type called VIFHostDevice. I have few general queries. TIA.
> 
> 1. How do I create ports with VIF_type as VIFHostDevice? Looking for 
> the CLI command options.
> 
> 
> 2. Say, I have OVS running completely on x86 host(no datapath or flow 
> offload to
>  NIC) as the networking mechanism and a SRIOV capable NIC(for 
> existence of VF representors that will be added to the OVS bridge). 
> Can I still launch instances with VIF_type as VIFHostDevice?
> 
> 
> 3. I want to use Security Groups using OVS+Conntrack as the mechanism.
> Can I apply SG rules on the ports of type VIFHostDevice using the 
> above mechanism?
> 
> PS: I am still trying to understand this. Hence, I might get my 
> premises wrong in the above questions. Will appreciate a detailed 
> explanation.
> 
> Regards,
> Pranab
> 
> __
> _
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> s
> .openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C0af8192c256c42f1252308d4df
> 2 
> b96b4%7Ca652971c7d2e4d9

Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type VIFHostDevice

[Moshe Levi]

Hi, 

1) you should use neutron port with vnic_type direct
2) yes,  just use neutron port with vnic_type  direct and confighure the nova 
compute with pci passthogth whitelist 
3) you can configure firewall_driver = openvswitch to work with Conntrack.

So in your case if have SR-IOV nic which doesn't support  hardware offload (but 
has VF representors port)  you will just fallback to the ovs kernel datapath.  
The ovs 2.8.0 code try to offload each datapath rule to NIC hardware if it 
failed it fails back to the ovs kernel datapath.
So if have NIC that can offload classification  on vlan  and action output. 
Only datapath flows that constructed for this classification and action  will 
be offload to hardware.

-Original Meyssage-
From: pranab boruah [mailto:pranabjyotibor...@gmail.com] 
Sent: Wednesday, August 9, 2017 4:36 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type 
VIFHostDevice

Hi,
I am experimenting with the os-vif library and stumbled upon this new VIF type 
called VIFHostDevice. I have few general queries. TIA.

1. How do I create ports with VIF_type as VIFHostDevice? Looking for the CLI 
command options.


2. Say, I have OVS running completely on x86 host(no datapath or flow offload to
 NIC) as the networking mechanism and a SRIOV capable NIC(for existence of VF 
representors that will be added to the OVS bridge). Can I still launch 
instances with VIF_type as VIFHostDevice?


3. I want to use Security Groups using OVS+Conntrack as the mechanism.
Can I apply SG rules on the ports of type VIFHostDevice using the above 
mechanism?

PS: I am still trying to understand this. Hence, I might get my premises wrong 
in the above questions. Will appreciate a detailed explanation.

Regards,
Pranab

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev=02%7C01%7Cmoshele%40mellanox.com%7C0af8192c256c42f1252308d4df2b96b4%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636378825693889082=iNi%2FLHV5LkTKs8sSpS4BgHU6lwaoywo6O%2BNcF3hqtms%3D=0
__
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] hardware offload support for openvswitch feature exception

[Moshe Levi]

Thanks Matt,
I have create blueprint [1] 
and update the patch [2] with reno 

[1]  - https://blueprints.launchpad.net/nova/+spec/sriov-ovs-offload
 [2] https://review.openstack.org/#/c/398265/ 
-Original Message-
From: Matt Riedemann [mailto:mriede...@gmail.com] 
Sent: Thursday, July 27, 2017 4:56 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] hardware offload support for openvswitch 
feature exception

On 7/26/2017 10:42 PM, Moshe Levi wrote:
> Hi all,
> 
> In the last few week I was working on hardware offload support for 
> openvswitch.
> 
> The idea is to leverage SR-IOV technology with OVS control plane management.
> 
> Just last month the ovs community merged all the required patches to 
> enable this feature [1] should be in OVS-2.8.0.
> 
> I was working on the required patches to enable this in OpenStack.
> 
> On the neutron side the RFE approved [2] and the neutron patch is 
> already merged [3]
> 
> On the OS-VIF side the patch is merged [4]
> 
> On the Third party CI side we have a Mellanox CI which is currently 
> commenting on os-vif [5] ( we will extend it to nova and neutron as 
> well)
> 
> The missing piece is the nova patch [6]
> 
> I just notice that this week is feature freeze in OpenStack and I 
> would like to request an exception for this feature.
> 
> I will appreciate if nova-core reviewers will review it.
> 
> ( Jay , Sean and Jan already review it several times and I think it is 
> close to be merged)
> 
> [1] -
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> hub.com%2Fopenvswitch%2Fovs%2Fcommit%2Fbf090264e68d160d0ae70ebc93d59bc
> 09d34cc8b=02%7C01%7Cmoshele%40mellanox.com%7C34367f31900d4b4f32ed
> 08d4d4f74ae3%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636367605958
> 238772=m9YqwQa%2BQ5f83wDdlgvxurAr4Hv8Uz7Sxew8M9zQqh0%3D
> =0
> 
> 
> [2] - 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbug
> s.launchpad.net%2Fneutron%2F%2Bbug%2F1627987=02%7C01%7Cmoshele%40
> mellanox.com%7C34367f31900d4b4f32ed08d4d4f74ae3%7Ca652971c7d2e4d9ba6a4
> d149256f461b%7C0%7C0%7C636367605958238772=CJEYZcjl9W1FSO%2FznqnN
> KbAWyZrRuiAOs0RrBeyiUo0%3D=0
> 
> [3] - 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> iew.openstack.org%2F%23%2Fc%2F275616%2F=02%7C01%7Cmoshele%40mella
> nox.com%7C34367f31900d4b4f32ed08d4d4f74ae3%7Ca652971c7d2e4d9ba6a4d1492
> 56f461b%7C0%7C0%7C636367605958238772=JEnx0Xz3xcgyhMP7JJPDA2l5%2F
> pGCVVzzxSuA%2FjKHkLA%3D=0
> 
> [4] - 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> iew.openstack.org%2F%23%2Fc%2F460278%2F=02%7C01%7Cmoshele%40mella
> nox.com%7C34367f31900d4b4f32ed08d4d4f74ae3%7Ca652971c7d2e4d9ba6a4d1492
> 56f461b%7C0%7C0%7C636367605958238772=mASkZcJSSdWk0gZrNJf%2BFSlif
> L88xO6NkYPyeuPCHZg%3D=0
> 
> [5] -
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2F52.1
> 69.200.208%2F25%2F485125%2F6%2Fcheck-os-vif%2FOVS_HW_offload%2Faaf2792
> %2F=02%7C01%7Cmoshele%40mellanox.com%7C34367f31900d4b4f32ed08d4d4
> f74ae3%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636367605958238772
> =zo1dZCVhq1pTMUvda0XnrYBVr2iC2XVeliWbN2Rb0yg%3D=0
> 
> [6] - 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frev
> iew.openstack.org%2F%23%2Fc%2F398265%2F=02%7C01%7Cmoshele%40mella
> nox.com%7C34367f31900d4b4f32ed08d4d4f74ae3%7Ca652971c7d2e4d9ba6a4d1492
> 56f461b%7C0%7C0%7C636367605958238772=9cTQAVBzqUFPTZEI267SoZr%2B0
> %2BSj4OmNnIi7%2FV7dYgw%3D=0
> 
> 
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> s.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev=02
> %7C01%7Cmoshele%40mellanox.com%7C34367f31900d4b4f32ed08d4d4f74ae3%7Ca6
> 52971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636367605958238772=JqCI
> iYYablV%2FflGV0I65oNJeWl7HHSFlYtk%2FvhaZ72g%3D=0
> 

Given everything else done here and the change in nova is (1) a single change 
and (2) self-contained and (3) relatively uncomplicated, I'm OK with this. 
Please create a blueprint in nova so we can track it as a feature since that's 
what it is.

-- 

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev=02%7C01%7Cmoshele%40mellanox.com%7C34367f31900d4b4f32ed08d

[openstack-dev] [nova] hardware offload support for openvswitch feature exception

[Moshe Levi]

Hi all,

In the last few week I was working on hardware offload support for openvswitch.
The idea is to leverage SR-IOV technology with OVS control plane management.
Just last month the ovs community merged all the required patches to enable 
this feature [1] should be in OVS-2.8.0.
I was working on the required patches to enable this in OpenStack.
On the neutron side the RFE approved [2] and the neutron patch is already 
merged [3]
On the OS-VIF side the patch is merged [4]
On the Third party CI side we have a Mellanox CI which is currently commenting 
on os-vif [5] ( we will extend it to nova and neutron as well)

The missing piece is the nova patch [6]
I just notice that this week is feature freeze in OpenStack and I would like to 
request an exception for this feature.
I will appreciate if nova-core reviewers will review it.
( Jay , Sean and Jan already review it several times and I think it is close to 
be merged)


[1] - 
https://github.com/openvswitch/ovs/commit/bf090264e68d160d0ae70ebc93d59bc09d34cc8b
[2] - https://bugs.launchpad.net/neutron/+bug/1627987
[3] - https://review.openstack.org/#/c/275616/
[4] - https://review.openstack.org/#/c/460278/
[5] - http://52.169.200.208/25/485125/6/check-os-vif/OVS_HW_offload/aaf2792/
[6] - https://review.openstack.org/#/c/398265/

__
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][vlan trunking] Guest networking configuration for vlan trunk

[Moshe Levi]

Hi Robert,
The closes thing that I know about is tagging of SR-IOV physical function’s 
VLAN tag to guests see [1]
Maybe you can leverage the same mechanism to config vlan trunking in guest.

[1] - 
https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/sriov-pf-passthrough-neutron-port-vlan.html


From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Monday, May 22, 2017 8:49 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova][vlan trunking] Guest networking configuration 
for vlan trunk

Hi,

I’m trying to find out if there is support in nova (in terms of metadata and 
cfgdrive) to configure vlan trunking in the guest. In the ‘CLI usage example’ 
provided in this wiki https://wiki.openstack.org/wiki/Neutron/TrunkPort, it 
indicates:

# The typical cloud image will auto-configure the first NIC (eg. eth0) only and 
not the vlan interfaces (eg. eth0.VLAN-ID).
ssh VM0-ADDRESS sudo ip link add link eth0 name eth0.101 type vlan id 101

I’d like to understand why the support of configuring vlan interfaces in the 
guest is not added. And should it be added?

Thanks,
Robert
__
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][networking-l2gw] Unable to create release tag

[Moshe Levi]

Hi,
I had similar problem with networking-mlnx (I think)  and I resolve  by 
creating Annotated Tags
Did you create the tag like this “git tag -am "Adding 10.0.0 Ocata tag" -s 
10.0.0 gerrit/stable/ocata”?


From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Tuesday, March 14, 2017 7:40 AM
To: OpenStack List 
Subject: [openstack-dev] [neutron][networking-l2gw] Unable to create release tag

Hi,
I was asked to create a release tag for stable/ocata. This fails with:

gkotton@ubuntu:~/networking-l2gw$ git push gerrit tag 10.0.0
Enter passphrase for key '/home/gkotton/.ssh/id_rsa':
Counting objects: 1, done.
Writing objects: 100% (1/1), 533 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
remote: Processing changes: refs: 1, done
To ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git
 ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
error: failed to push some refs to 
'ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git'

Any idea?
Thanks
Gary
__
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] [neutron][l2gatewaty] how to create l2-gateway-create when 2 switches has the same name

[Moshe Levi]

Hi,

I am using the latest networking-l2gateway. 
I have the following physical switches defined in neutron physical_switches
+--+---+-+--+-+
| uuid | name  | tunnel_ip   | ovsdb_identifier 
| switch_fault_status |
+--+---+-+--+-+
| 6932481e-8316-40f7-834a-6a6deeb72534 | vtep0 | 99.99.99.99 | ovsdb2   
| NULL|
| ceb7cadb-28a8-476b-b959-2db253633854 | vtep0 | 1.1.1.1 | ovsdb1   
| NULL|
+--+---+-+--+-+

I want to create L2 gateway on ceb7cadb-28a8-476b-b959-2db253633854

According to the l2-gateway api [1] it seem that in the --device name can be 
name or identifiers, so I tried with the ovsdb_identifier, but when I run the 
l2-gateway-connection-create it complain that the ovsdb1 is not found see [2]. 
I also tried with uuid and got the same result. 
How should I create l2 gateway when I have same names in the physical switches 
tables?


[1] - 
https://github.com/openstack/networking-l2gw/blob/master/specs/kilo/l2-gateway-api.rst
 
[2] - 
(neutron) l2-gateway-create --device name=ovsdb1,interface_names=eth7|8;eth8|8 
SW1
Created a new l2_gateway:
+---+-+
| Field | Value 

  |
+---+-+
| devices   | {"interfaces": [{"segmentation_id": ["8"], "name": "eth7"}, 
{"segmentation_id": ["8"], "name": "eth8"}], "id": 
"105d6abf-6257-4818-8451-fa6e0d6c7334", "device_name": "ovsdb1"} |
| id| 2ea12e77-3409-40b2-8535-6cf320fca4b2  

  |
| name  | SW1   

  |
| tenant_id | 0fa5309dd18a4861a5833e55d8a7f98c  

  |
+---+-+
(neutron) l2-gateway-connection-create SW1 private
L2 Gateway Device ovsdb1 could not be found.
Neutron server returns request_ids: ['req-f26351fb-fcf5-4d77-b2fe-8b58ac9057dc']


Thanks,
Moshe Levi



__
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] [ironic-pyhon-agent][DIB] IPA failed to start on Ubuntu because of modprobe path

[Moshe Levi]

Hi,
This commit 
https://github.com/openstack/diskimage-builder/commit/2854f4063bd2a6dcdb6fa5fab93aa56857e47b59
 
Added ExecStartPre=/usr/sbin/modprobe vfat to the ironic-python-agent systemd 
script 
The problem is that modprobe location in Ubuntu / sbin/modprobe (the 
/usr/sbin/modprobe vfat works for redhat)
I have opened this bug in Launchpad 
https://bugs.launchpad.net/diskimage-builder/+bug/1658297  
This break IPA element when building with Ubunut OS.
Is there conditional in systemd scripts like 
If os == Redhat then
ExecStartPre=/usr/sbin/modprobe vfat
Elseif os == Ubuntu  then
ExecStartPre=/sbin/modprobe vfat

What is the best way to fix this? 

Thanks,
Moshe Levi



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

[Moshe Levi]

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/

Thanks, 
Moshe Levi



__
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] [acceleration]Team Biweekly Meeting 2016.11.10 minutes

[Moshe Levi]

Hi Howard,
I won’t be able to make it from tomorrow meeting. Sorry.

From: Harm Sluiman [mailto:harm.slui...@gmail.com]
Sent: Tuesday, November 22, 2016 3:16 PM
To: Zhipeng Huang <zhipengh...@gmail.com>
Cc: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; rodolfo.alonso.hernan...@intel.com; 
Michele Paolino <m.paol...@virtualopensystems.com>; Scott Kelso 
<ske...@lenovo.com>; Roman Dobosz <roman.dob...@intel.com>; Jim Golden 
<jim.gol...@nist.gov>; Miroslav Halas <mha...@lenovo.com>; Moshe Levi 
<mosh...@mellanox.com>; pradeep.jagade...@huawei.com; michael.ro...@nokia.com; 
martial.mic...@nist.gov; jian-feng.d...@intel.com
Subject: Re: [acceleration]Team Biweekly Meeting 2016.11.10 minutes

Hi Howard. Can you send out the IRC in advance if you have it for Wednesday 
meeting?

On Thu, Nov 10, 2016 at 10:55 AM, Zhipeng Huang 
<zhipengh...@gmail.com<mailto:zhipengh...@gmail.com>> wrote:
Hi Team,

Thanks for attending today's meeting and again sorry for not be able to host it 
on yesterday.

Since we don't have a meetbot now associated with a fix channel, I recorded the 
irc chat in a doc file and you could find it in the attachment.

Key Takeaways:
1. Nomad project will be renamed to Cyborg (what a cool name) based upon our 
final tally on the 
etherpad<https://etherpad.openstack.org/p/nomad-ocata-design-session>
2. Moshe introduced Nacsa project proposal, and an initial design doc has been 
shared among the team. We will make the doc public after a few rounds of review 
and discussion
3. Reminder for the team to take a look at the Scientific Working Group 
etherpad<https://etherpad.openstack.org/p/scientific-wg-barcelona-agenda> for 
use cases

Our next meeting will be on Nov 23th, 10:00am on irc

--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com<mailto:huangzhip...@huawei.com>
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu<mailto:zhipe...@uci.edu>
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado



--
宋慢
Harm Sluiman



__
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] [neutron][nova][SR-IOV] SR-IOV meetings are canceled between 10/9-10/21

[Moshe Levi]

Hi, 

The 2 SR-IOV meeting between 10/9-10/21 are canceled.
We have holidays, so I won't be able to chair the meeting. 

Thanks,
Moshe Levi


__
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][neutron[SR-IOV] SR-IOV meeting is cancel today

[Moshe Levi]

Hi all,

Sorry for the late mail, but I have to cancel the meeting today.

Thanks,
Moshe Levi



__
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][SR-IOV] PCI/SR-IOV meeting today is canceled 08/16/16

[Moshe Levi]

Sorry for the late mail, but I won't be able to chair the meeting today

__
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] Neutron Port MAC Address Uniqueness

[Moshe Levi]

Hi Anil,


I tested it with Mellanox NIC and it working

16: enp6s0d1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode 
DEFAULT group default qlen 1000 

link/ether 00:02:c9:e9:c2:12 brd ff:ff:ff:ff:ff:ff  


vf 0 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto  


vf 1 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto  


vf 2 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto  


vf 3 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto  


vf 4 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto  


vf 5 MAC fa:16:3e:0d:8c:a2, vlan 192, spoof checking on, link-state enable  


vf 6 MAC fa:16:3e:0d:8c:a2, vlan 190, spoof checking on, link-state enable  


vf 7 MAC 00:00:00:00:00:00, vlan 4095, spoof checking off, link-state auto  
 

I guess the problem is with the SR-IOV NIC/ driver you are using maybe you 
should contact them 


-Original Message-
From: Moshe Levi 
Sent: Wednesday, August 10, 2016 5:59 PM
To: 'Miguel Angel Ajo Pelayo' <majop...@redhat.com>; OpenStack Development 
Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>
Cc: Armando M. <arma...@gmail.com>
Subject: RE: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

Miguel, 

I talked to our driver architect and according to him this is vendor 
implementation (according to him this  should work with  Mellanox NIC) I need 
to verify that this indeed working. 
I will update after I will prepare SR-IOV setup and try it myself.


-Original Message-
From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
Sent: Wednesday, August 10, 2016 12:04 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Armando M. <arma...@gmail.com>; Moshe Levi <mosh...@mellanox.com>
Subject: Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

@moshe, any insight on this?

I guess that'd depend on the nic internal switch implementation and how the 
switch ARP tables are handled there (per network, or global per switch).

If that's the case for some sr-iov vendors (or all), would it make sense to 
have a global switch to create globally unique mac addresses (for the same 
neutron deployment, of course).

On Wed, Aug 10, 2016 at 7:38 AM, huangdenghui <hdh_1...@163.com> wrote:
> hi Armando
> I think this feature causes problem in sriov scenario, since sriov 
> NIC don't support the vf has the same mac,even the port belongs to the 
> different network.
>
>
> 发自网易邮箱手机版
>
>
> On 2016-08-10 04:55 , Armando M. Wrote:
>
>
>
> On 9 August 2016 at 13:53, Anil Rao <anil@gigamon.com> wrote:
>>
>> Is the MAC address of a Neutron port on a tenant virtual network 
>> globally unique or unique just within that particular tenant network?
>
>
> The latter:
>
> https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.
> py#L139
>
>>
>>
>>
>> Thanks,
>>
>> Anil
>>
>>
>> _
>> _ 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] [neutron] Neutron Port MAC Address Uniqueness

[Moshe Levi]

Miguel, 

I talked to our driver architect and according to him this is vendor 
implementation (according to him this  should work with  Mellanox NIC)
I need to verify that this indeed working. 
I will update after I will prepare SR-IOV setup and try it myself.


-Original Message-
From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com] 
Sent: Wednesday, August 10, 2016 12:04 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Cc: Armando M. <arma...@gmail.com>; Moshe Levi <mosh...@mellanox.com>
Subject: Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

@moshe, any insight on this?

I guess that'd depend on the nic internal switch implementation and how the 
switch ARP tables are handled there (per network, or global per switch).

If that's the case for some sr-iov vendors (or all), would it make sense to 
have a global switch to create globally unique mac addresses (for the same 
neutron deployment, of course).

On Wed, Aug 10, 2016 at 7:38 AM, huangdenghui <hdh_1...@163.com> wrote:
> hi Armando
> I think this feature causes problem in sriov scenario, since sriov 
> NIC don't support the vf has the same mac,even the port belongs to the 
> different network.
>
>
> 发自网易邮箱手机版
>
>
> On 2016-08-10 04:55 , Armando M. Wrote:
>
>
>
> On 9 August 2016 at 13:53, Anil Rao <anil@gigamon.com> wrote:
>>
>> Is the MAC address of a Neutron port on a tenant virtual network 
>> globally unique or unique just within that particular tenant network?
>
>
> The latter:
>
> https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.
> py#L139
>
>>
>>
>>
>> Thanks,
>>
>> Anil
>>
>>
>> _
>> _ 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] [neutron][nova][SR-IOV] deprecation of supported_pci_vendor_devs

[Moshe Levi]

This is the deprecation patch [2] 

[2] - https://review.openstack.org/#/c/352812/

-Original Message-
From: Moshe Levi [mailto:mosh...@mellanox.com] 
Sent: Monday, August 08, 2016 3:43 PM
To: OpenStack Development Mailing List (not for usage questions) 
(openstack-dev@lists.openstack.org) <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] [neutron][nova][SR-IOV] deprecation of supported_pci_vendor_devs

[Moshe Levi]

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-dev] [neutron] weird behavior of neutron create port with extra dhcp option

[Moshe Levi]

Hi,
I encounter a weird behavior with neutron create port command.
I am using neutron master.

When I run this neutron create-port command 
stack@r-dcs88:/opt/devstack$ neutron port-create 
--device-id=984b4a6d-a66d-4db7-8acc-1113cd1097ef --device-owner=baremetal:none 
--mac-address 7c:fe:90:29:22:4e --extra-dhcp-opt 
'opt_value'='ff:00:00:00:00:00:02:00:00:02:c9:00:7c:fe:90:03:00:29:22:4e','opt_name'='client-id'
 --admin_state_up=True private
port is created as expected see [1]

when I create a port with the following command:
stack@r-dcs88:/opt/devstack$ neutron port-create 
--device-id=984b4a6d-a66d-4db7-8acc-1113cd1097ef --device-owner=baremetal:none 
--mac-address 7c:fe:90:29:22:4e --extra-dhcp-opt 
'opt_value'='ff:00:00:00:00:00:02:00:00:02:c9:00:7c:fe:90:03:00:29:22:4e','opt_name'='client-id'
 --vnic_type=baremetal --admin_state_up=True private
port is created but in neutron client  show the extra_dhcp_opts attribute 
without the options. The only difference in the command is that I added 
--vnic_type=baremetal to it.
I looked in the neutron database and I can see the extra_dhcp_opts in the table.

I debugged the neutron server and the problem is with 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin.py#L1217
 that calling the _extend_port_dict_extra_dhcp_opt and clearing the 
extra_dhcp_opts from the result variable. If I comment this 
line(_apply_dict_extend_functions)  I will get the correct result.
Commenting it don't seem to me as the correct fix and I have a hard time 
understating the code.
It seems that the dhcp opt extend the result in 2 places  here [3] and here [4].

Does anyone know what is the proper way to fix this issue? Help would be much 
appreciated 


[1] - http://paste.openstack.org/show/544013/
[2] - http://paste.openstack.org/show/544014/ 
[3] - 
https://github.com/openstack/neutron/blob/master/neutron/db/extradhcpopt_db.py#L37-L53
[4] - 
https://github.com/openstack/neutron/blob/1fd1b505ca0a4dcaa7184df02dbd53ba63355083/neutron/db/extradhcpopt_db.py#L116-L121



__
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] how to create initial db migration script to sub-project

[Moshe Levi]

Hi Henry,

Thank for the reply. 

I tried to do the following with your commit [2]:
1. I create models.py in networking_mlnx/db.
2. mysql -e "drop database neutron; create database neutron;"
3. neutron-db-manage --subproject=neutron  upgrade heads
4. neutron-db-manage --subproject=networking-mlnx  revision -m "test" --expend

Now I don't see the errors as before, but the migration script that was 
generated 
Looks like [3] and doesn't contain the new table.

Am I doing it wrong?  

[3] - 
from alembic import op
import sqlalchemy as sa


# revision identifiers, used by Alembic.
revision = 'cbb661581082'
down_revision = '65b6db113427b9_initial_contract'


def upgrade():
pass

-Original Message-
From: Henry Gessau [mailto:hen...@gessau.net] 
Sent: Sunday, July 24, 2016 9:21 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] how to create initial db migration 
script to sub-project

Hi Moshe,

It has been a while since a neutron sub-project initialized new alembic 
migrations, so the devref is out of date, sorry. Let me help you get this 
sorted out and then I can update the devref with the latest info.

First you need to create the initial migration for each branch (expand and 
contract). This is done by submitting a patch -- the contents of which used to 
be crafted by copying a similar patch from another sub-project. The patches to 
copy from are now out of date, so I have created a patch [2] for you and we can 
use this as the new "template patch for initial alembic migrations."

Some more comments inline ...

Moshe Levi <mosh...@mellanox.com> wrote:
> Hi,
> 
> I am trying to create initial db for the networking-mlnx project. 
> I am following this neutron alembic documentation [1].
> I added a entrypoint to networking-mlnx setup.cfg 
> neutron.db.alembic_migrations =
> networking-mlnx = networking_mlnx.db.migration:alembic_migrations
> I added model.py file to networking-mlnx/networking_mlnx/db
> And I run python setup.py develop to regenerate the entrypoint
> 
> I am running the following commands:
> 1. mysql -e "drop database neutron; create database neutron;"
> 2. neutron-db-manage --subproject=neutron  upgrade heads

So far so good.

> 3. neutron-db-manage --subproject=networking-mlnx  revision -m "test" 
> --autogenerate

Because we now require split (expand and contract) branches, you must now 
specify --expand or --contract *instead of* --autogenerate. I will update the 
devref about this.

> I am getting the following errors:
> INFO  [alembic.runtime.migration] Context impl MySQLImpl. 
>   
> INFO  [alembic.runtime.migration] Will assume non-transactional DDL.  
>   
> INFO  [alembic.autogenerate.compare] Detected removed table 
> u'alembic_version'  
> INFO  [alembic.autogenerate.compare] Detected removed index 
> 'idx_autoinc_vr_id' on 'ha_router_vrid_allocations' 
>   Generating 
> /.autodirect/mtrswgwork/moshele/openstack/networking-mlnx/networking_mlnx/db/migration/alembic_migrations/versions/120e7e350bb1_test.py
>  ... done
>   OK  
>   
>  
> Traceback (most recent call last):
>   
>  
>   File "/usr/bin/neutron-db-manage", line 10, in  
>   
>  
> sys.exit(main())  
>   
>  
>   File 
> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>  line 689, in main
> return_val |= bool(CONF.command.func(config, CONF.command.name))  
>   
>  
>   File 
> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>  line 275, in do_revision 
> update_head_files(config) 
>   
>  
>   File 
> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>  line 398, in update_head_files   
&

[openstack-dev] [neutron] how to create initial db migration script to sub-project

[Moshe Levi]

Hi,

I am trying to create initial db for the networking-mlnx project. 
I am following this neutron alembic documentation [1].
I added a entrypoint to networking-mlnx setup.cfg
neutron.db.alembic_migrations =
networking-mlnx = networking_mlnx.db.migration:alembic_migrations
I added model.py file to networking-mlnx/networking_mlnx/db
And I run python setup.py develop to regenerate the entrypoint 

I am running the following commands:
1. mysql -e "drop database neutron; create database neutron;"
2. neutron-db-manage --subproject=neutron  upgrade heads
3. neutron-db-manage --subproject=networking-mlnx  revision -m "test" 
--autogenerate

I am getting the following errors:
INFO  [alembic.runtime.migration] Context impl MySQLImpl.   

INFO  [alembic.runtime.migration] Will assume non-transactional DDL.

INFO  [alembic.autogenerate.compare] Detected removed table u'alembic_version'  

INFO  [alembic.autogenerate.compare] Detected removed index 'idx_autoinc_vr_id' 
on 'ha_router_vrid_allocations' 
  Generating 
/.autodirect/mtrswgwork/moshele/openstack/networking-mlnx/networking_mlnx/db/migration/alembic_migrations/versions/120e7e350bb1_test.py
 ... done
  OK
 
Traceback (most recent call last):  
 
  File "/usr/bin/neutron-db-manage", line 10, in
 
sys.exit(main())
 
  File 
"/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
 line 689, in main
return_val |= bool(CONF.command.func(config, CONF.command.name))
 
  File 
"/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
 line 275, in do_revision 
update_head_files(config)   
 
  File 
"/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
 line 398, in update_head_files   
f.write(head_map[CONTRACT_BRANCH] + '\n')   
 
KeyError: 'contract'


And the migration script just dropping unrelated tables 

[moshele@r-dcs84 networking-mlnx]$ cat 
/.autodirect/mtrswgwork/moshele/openstack/networking-mlnx/networking_mlnx/db/migration/alembic_migrations/versions/120e7e350bb1_test.py
# revision identifiers, used by Alembic.
revision = '120e7e350bb1'
down_revision = None

from alembic import op
import sqlalchemy as sa
from sqlalchemy.dialects import mysql

def upgrade():
### commands auto generated by Alembic - please adjust! ###
op.drop_table('alembic_version')
op.drop_index('idx_autoinc_vr_id', table_name='ha_router_vrid_allocations')
### end Alembic commands ###



It seem that the neutron alembic migration documentation [1] is out of date ( I 
don't see the --core_plugin flag in the neutron-db-manage man, but I do see the 
--subproject flag)

Does anyone know how to make it works? 


[1] - http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html


__
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][tempest][SR-IOV] SR-IOV CI for Mutli-Node with migration test

[Moshe Levi]

Hi all,

We are in advance stage of resolving migration with SR-IOV and to improve the 
coverage in that part.

We have proposed the following patches to fix SR-IOV migration and its race 
conditions:
[1] - Allocate PCI devices on migration: https://review.openstack.org/#/c/328983
[2] - Update binding:profile for SR-IOV ports - 
https://review.openstack.org/#/c/242573/
[3] - Update available resources before confirm stage - 
https://review.openstack.org/#/c/327356/
[4] - Fix revert on migration with SR-IOV - 
https://review.openstack.org/#/c/326174
[5] - Fixes for race conditions in revert migration with SR-IOV - 
https://review.openstack.org/#/c/339765/

We added a job for Mellanox CI for SR-IOV multi node. The Job is called 
Nova-ML2-Sriov-Multinode

To allow the multi node  Job with direct port (or any port type) we need [6] to 
be merged in tempest

[6] -  Fixed manager.py to support multinode test on vnic_port - 
https://review.openstack.org/#/c/335447/

Also we added basic migration test in tempest [7]  that passed in the SR-IOV 
multimode see log  [8]
[7] - Add connectivity check test for 
migration - 
https://review.openstack.org/#/c/339230/
[8] - http://13.69.151.247/MN_migrate/

Of course we plan to add more test like migration-revert and etc.

It would be wonderful if we can get some reviews from the nova/tempest 
community to land  all this patches in this cycle.

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-dev] [nova][SR-IOV] PCI/SR-IOV meeting today is canceled 06/28/16

[Moshe Levi]

Sorry for the late mail, but I won't be able to chair the meeting today 

__
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] [tempest][SR-IOV] tempest breaks Mellanox CI

[Moshe Levi]

Hi all,



A recent change  [1]  in tempest broke all Mellanox CIs.

This is the second time it happened.

After the first time it happened we decided that  Mellanox CI  will comment on 
tempest.

On this time I saw that Mellanox CI was commenting on that  patch with a 
failure but was still got approved - [2] Enabling Mellanox CI as commenting on  
tempest requires  us physical resources  such as servers/NICS because it tests 
SR-IOV.

So I am wandering  what can be done in the future to prevent this from happen 
again.



Anyway we proposed the following fix to tempest [3]





[1] - https://review.openstack.org/#/c/320495/

[2] - 
http://13.69.151.247/95/320495/20/check-sriov-tempest/Tempest-Sriov/825304c/testr_results.html.gz

[3] - https://review.openstack.org/#/c/330331/



__
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][SR-IOV/PCI] SR-IOV/PCI CI for mutli node

[Moshe Levi]

Hi, 

As part of the  Performance VMs CI and technical debt session we had in  Ausin 
summit,  we decide to focus on fixing pci resize and migration bugs.
Currently the pci resize patch [1]  and migration patch [2] are up for review.

The resize patch is tested with Intel PCI CI 
http://52.27.155.124/pci/307124/21/testr_experimental_result.html.gz - which is 
great.
We also would like to test the pci passthrough and SR-IOV  migration patches  
as well. For that we need SR-IOV/PCI CI for mutli node. 
For some reason I remember that Intel CI engineers volunteer to do that in 
Austin. If that is the case please join the SR-IOV meeting so we can track 
progress [3]
If not we are looking for someone to setup and maintain mutli node  PCI and 
SR-IOV CI for migration testing.

Another feature that is related to pci CI is the direct passthrough. Does 
anyone work on CI for this feature?  Does this feature even works?

[1] - https://review.openstack.org/#/c/307124/
[2] - https://review.openstack.org/#/c/242573/ 
[3] - http://eavesdrop.openstack.org/#SR-IOV/PCI_Passthrough_Meeting 


__
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] [ironic][neutron] bonding?

[Moshe Levi]

Hi Jim,

Neutron is supporting resource tagging [1] which is support currently  network 
resource_type
With a simple change is neutron you can also allow resource tagging for port 
resource_type [2]

This will allow you to tags ports and indicate that they are in the same group
maybe that can work better the ironic port group concept.


[1] - 
https://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/tag-instances.html
[2] - 
https://github.com/openstack/neutron/blob/master/neutron/extensions/tag.py#L38-L41


From: Armando M. [mailto:arma...@gmail.com]
Sent: Tuesday, May 24, 2016 10:19 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [ironic][neutron] bonding?



On 24 May 2016 at 04:51, Jim Rollenhagen 
> wrote:
Hi,

There's rumors floating around about Neutron having a bonding model in
the near future. Are there any solid plans for that?

Who spreads these rumors :)?

To the best of my knowledge I have not seen any RFE proposed recently along 
these lines.


For context, as part of the multitenant networking work, ironic has a
portgroup concept proposed, where operators can configure bonding for
NICs in a baremetal machine. There are ML2 drivers that support this
model and will configure a bond.

Some folks have concerns about landing this code if Neutron is going to
support bonding as a first-class citizen. So before we delay any
further, I'd like to find out if there's any truth to this, and what the
timeline for that might look like.

Thanks!

// jim

__
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] race condition with resize

[Moshe Levi]

Hi all,



While I was working on fixing the resize for pci passthrough [1] I have notice 
the following issue in resize.



If you are using small image and you resize-confirm it very fast the old 
resources are not getting freed.



After debug this issue I found out the root cause of it.



A Good run of resize is as detailed below:



When doing resize the _update_usage_from_migration in the resource trucker 
called twice.

1.   The first call we return  the instance type of the new flavor and will 
enter this case

 
https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L718

2.   Then it will put in the tracked_migrations the migration and the new 
instance_type


https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L763

3.   The second call we return the old  instance_type and will enter this 
case

 
https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L725

4.   Then in the tracked_migrations it will overwrite  the old value with 
migration and the old instance type

5.   
https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L763

6.   When doing resize-confirm the drop_move_claim called with the old 
instance type

https://github.com/openstack/nova/blob/9a05d38f48ef0f630c5e49e332075b273cee38b9/nova/compute/manager.py#L3369

7.   The drop_move_claim will compare the instance_type[id] from the 
tracked_migrations to the instance_type.id (which is the old one)

8.   And because they are equals it will  remove the old resource usage


https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L315-L328



But with small image like CirrOS   and doing the revert-confirm fast the second 
call of _update_usage_from_migration will not get executing.

The result is that when we enter the drop_move_claim it compares it with the 
new instance_type and this  expression is false 
https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L314

This mean that this code block is not executed  
https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L315-L326
 and therefore old resources are not getting freed.



Any thought on the matter?





[1] - https://review.openstack.org/#/c/307124/
__
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] [neutron][nova][SR-IOV] SR-IOV meeting May 3 2016 - update

[Moshe Levi]

Hi,



I just wanted to give a short update regarding SR-IOV/PCI Passthrough /NFV 
meeting.



* We decide to change the meeting frequency to every week, until 
PCI/SR-IOV/NUMA will be more stable  see [1]

* Improving SR-IOV/PCI Passthrough /NFV testing

o   With the help of wznoinsk we are working to move Mellanox CI to containers 
(owner lennyb)

o   How Muti node CI for IOV/PCI Passthrough /NFV (needs an owner)

o   CI for  PF passthrough (needs an owner)

* Documentation

o   Improve PCI Passthrough SR-IOV Documentation -  (owners lbeliveau, moshele)

o   Improve NUMA and cpu pinning Documentation - (owner sfinucan)

* I updated the etherpad [2] with the agenda for next week (May 10 
2016) and added the following sections:

o   Patches ready for core reviews

o   Patches for sub-team review - please try to review them for our next meeting

o   Patches that needs owner - feel free to  add your irc name to the patches 
you think you can continue



[1] - https://review.openstack.org/#/c/312107/

[2] - https://etherpad.openstack.org/p/sriov_meeting_agenda



Thanks,

 Moshe Levi.




__
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][neutron] restarting SR-IOV/PCI Passthrough meeting

[Moshe Levi]

Small correction, the biweekly meetings will start from May 3rd. 

-Original Message-
From: Moshe Levi [mailto:mosh...@mellanox.com] 
Sent: Friday, April 29, 2016 8:13 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova][neutron] restarting SR-IOV/PCI Passthrough 
meeting

Hi all,

I would like to restart the SR-IOV/PCI Pass-through.
The main focus is to improve CI coverage and fixing bugs in nova side.
I updated the agenda etherpad  [1] with stuff to cover on the next meeting Mar 
3rd 2016. The meeting will be biweekly.
I like that the Mellanox/Intel and other vendors CI representative will join 
the meeting, so that we can make progress in that area.
Please review the etherpad  and add stuff that you want to talk about (remember 
the current focus is on CI and bug fixes) I updated the  sriov meeting chair 
see [2]

Thanks,
Moshe Levi.
[1] - https://etherpad.openstack.org/p/sriov_meeting_agenda
[2] - https://review.openstack.org/#/c/311472/1


__
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][neutron] restarting SR-IOV/PCI Passthrough meeting

[Moshe Levi]

Hi all,

I would like to restart the SR-IOV/PCI Pass-through.
The main focus is to improve CI coverage and fixing bugs in nova side.
I updated the agenda etherpad  [1] with stuff to cover on the next meeting Mar 
3rd 2016. The meeting will be biweekly.
I like that the Mellanox/Intel and other vendors CI representative will join 
the meeting, so that we can make progress in that area.
Please review the etherpad  and add stuff that you want to talk about (remember 
the current focus is on CI and bug fixes)
I updated the  sriov meeting chair see [2]

Thanks,
Moshe Levi.
[1] - https://etherpad.openstack.org/p/sriov_meeting_agenda
[2] - https://review.openstack.org/#/c/311472/1


__
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] scheduling bandwidth resources / NIC_BW_KB resource class

[Moshe Levi]

From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
Sent: Friday, April 08, 2016 4:17 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / 
NIC_BW_KB resource class


Hi!,

   In the context of [1] (generic resource pools / scheduling in nova) and [2] 
(minimum bandwidth guarantees -egress- in neutron), I had a talk a few weeks 
ago with Jay Pipes,

   The idea was leveraging the generic resource pools and scheduling mechanisms 
defined in [1] to find the right hosts and track the total available bandwidth 
per host (and per host "physical network"), something in neutron (still to be 
defined where) would notify the new API about the total amount of "NIC_BW_KB" 
available on every host/physnet.
I believe that NIC bandwidth can be taken from Libvirt see [4] and the only 
piece that is missing is to tell nova the mapping of physnet to network 
interface name. (In case of SR-IOV this is already known)
I see bandwidth (speed)  as one of many capabilities of NIC, therefore I think 
we should take all of them in the same way in this case libvirt.  I was think 
of adding a new NIC as new resource to nova.

[4] - 
  net_enp129s0_e4_1d_2d_2d_8c_41
  /sys/devices/pci:80/:80:01.0/:81:00.0/net/enp129s0
  pci__81_00_0
  
enp129s0
e4:1d:2d:2d:8c:41












  


   That part is quite clear to me,

   From [1] I'm not sure which blueprint introduces the ability to schedule 
based on the resource allocation/availability itself, 
("resource-providers-scheduler" seems more like an optimization to the 
schedule/DB interaction, right?)
My understating is that the resource provider blueprint is just a rough filter 
of compute nodes before passing them to the scheduler filters. The existing 
filters here [6] will do the  accurate filtering of resources.
see [5]

[5] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2016-04-04.log.html#t2016-04-04T16:24:10
[6] - http://docs.openstack.org/developer/nova/filter_scheduler.html

And, that brings me to another point: at the moment of filtering hosts, 
nova  I guess, will have the neutron port information, it has to somehow 
identify if the port is tied to a minimum bandwidth QoS policy.

That would require identifying that the port has a "qos_policy_id" attached 
to it, and then, asking neutron for the specific QoS policy  [3], then look out 
for a minimum bandwidth rule (still to be defined), and extract the required 
bandwidth from it.
I am not sure if that is the correct  way to do it, but you can create NIC 
bandwidth filter (or NIC capabilities filter)  and in it you can implement the 
way to retrieve Qos policy information by using neutron client.

   That moves, again some of the responsibility to examine and understand 
external resources to nova.

Could it make sense to make that part pluggable via stevedore?, so we would 
provide something that takes the "resource id" (for a port in this case) and 
returns the requirements translated to resource classes (NIC_BW_KB in this 
case).


Best regards,
Miguel Ángel Ajo


[1] http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html
[2] https://bugs.launchpad.net/neutron/+bug/1560963
[3] http://developer.openstack.org/api-ref-networking-v2-ext.html#showPolicy
__
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] The same SRIOV / NFV CI failures missed a regression, why?

[Moshe Levi]

> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Friday, March 25, 2016 10:20 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova] The same SRIOV / NFV CI failures missed a
> regression, why?
> 
> On 03/24/2016 09:35 AM, Matt Riedemann wrote:
> > We have another mitaka-rc-potential bug [1] due to a regression when
> > detaching SR-IOV interfaces in the libvirt driver.
> >
> > There were two NFV CIs that ran on the original change [2].
> >
> > Both failed with the same devstack setup error [3][4].
> >
> > So it sucks that we have a regression, it sucks that no one watched
> > for those CI results before approving the change, and it really sucks
> > in this case since it was specifically reported from mellanox for
> > sriov which failed in [4]. But it happens.
> >
> > What I'd like to know is, have the CI problems been fixed? There is a
> > change up to fix the regression [5] and this time the Mellanox CI
> > check is passing [6]. The Intel NFV CI hasn't reported, but with the
> > mellanox one also testing the suspend scenario, it's probably good enough.
> 
>  From the commit message of the original patch that introduced the
> regression:
> 
> "This fix was tested on a real environment containing the above type of VMs.
> test_driver.test_detach_sriov_ports was slightly modified so that the VIF from
> which data is sent to _detach_pci_devices will contain the correct SRIOV 
> values
> (pci_slot, vlan and hw_veb VIF type)"
> 
> I'm not sure if the above statement could ever have been true considering the
> AttributeError that occurred in the bug...
> 
> In any case, I think that it's pretty clear that the CI systems for NFV and 
> PCI
> have been less than reliable at functionally testing the PCI and NFV-specific
> functionality in Nova.
> 
> This isn't trying to put down the people that work on those systems -- I know
> first hand that it can be difficult to build and maintain CI systems that 
> report in
> to upstream, and I appreciate the effort that goes into this.
> 
> But, going forward, I think we need to do something as a concerned
> community.
> 
> How about this for a proposal?
> 
> 1) We establish a joint lab environment that contains heterogeneous hardware
> to which all interested hardware vendors must provide hardware.
> 
> 2) The OpenStack Foundation and the hardware vendors each foot some
> portion of the bill to hire 2 or more systems administrators to maintain this 
> lab
> environment.
> 
> 3) The upstream Infrastructure team works with the hired system
> administrators to create a single CI system that can spawn functional test 
> jobs
> on the lab hardware and report results back to upstream Gerrit
> 
> Given the will to do this, I think the benefits of more trusted testing 
> results for
> the PCI and SR-IOV/NFV areas would more than make up for the cost.
+1 I like this proposal. We can help by providing Mellanox hardware and share 
our CI knowledge. 

> 
> Best,
> -jay
> 
> 
> __
> 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] The same SRIOV / NFV CI failures missed a regression, why?

[Moshe Levi]

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Thursday, March 24, 2016 3:35 PM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: [openstack-dev] [nova] The same SRIOV / NFV CI failures missed a
> regression, why?
> 
> We have another mitaka-rc-potential bug [1] due to a regression when
> detaching SR-IOV interfaces in the libvirt driver.
> 
> There were two NFV CIs that ran on the original change [2].
> 
> Both failed with the same devstack setup error [3][4].
> 
> So it sucks that we have a regression, it sucks that no one watched for those 
> CI
> results before approving the change, and it really sucks in this case since 
> it was
> specifically reported from mellanox for sriov which failed in [4]. But it 
> happens.
> 
> What I'd like to know is, have the CI problems been fixed? There is a change 
> up
> to fix the regression [5] and this time the Mellanox CI check is passing [6]. 
> The
> Intel NFV CI hasn't reported, but with the mellanox one also testing the 
> suspend
> scenario, it's probably good enough.
Patch-Set 6  of patch [2] passed in Mellanox CI  see 
http://144.76.193.39/ci-artifacts/262341/6/Nova-ML2-Sriov/testr_results.html.gz 
I am not sure why patch-set 7 failed. At first I thought it was because of that 
in  PS 6 we install oslo.utils==3.4.0 and in PS7 oslo.utils==3.5.0
but I could not find a difference that can be related to  this:
2016-02-16 05:05:42.164 7182 ERROR nova   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 30, in 
import_class
2016-02-16 05:05:42.164 7182 ERROR nova __import__(mod_str)
2016-02-16 05:05:42.164 7182 ERROR nova ValueError: Empty module name

Putting that a side,  the Mellanox CI in nova is currently running and passing 
so the SR-IOV for Ethernet is not broken.
The fix in [5] is for our SR-IOV InfiniBand solution. At the moment we only 
test it in neutron (SR-IOV InfiniBand solution) and 
the reason for that is that we don't have many physical server to run the CI  
for nova and neutron. 

> 
> [1] https://bugs.launchpad.net/nova/+bug/1560860
> [2] https://review.openstack.org/#/c/262341/
> [3]
> http://intel-openstack-ci-logs.ovh/compute-
> ci/refs/changes/41/262341/7/compute-nfv-
> flavors/20160215_232057/screen/n-sch.log.gz
> [4]
> http://144.76.193.39/ci-artifacts/262341/7/Nova-ML2-Sriov/logs/n-sch.log.gz
> [5] https://review.openstack.org/#/c/296305/
> [6]
> http://144.76.193.39/ci-artifacts/296305/1/Nova-ML2-
> Sriov/testr_results.html.gz
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> 
> __
> 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] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Moshe Levi]

+1 ☺

From: Ivan Berezovskiy [mailto:iberezovs...@mirantis.com]
Sent: Wednesday, February 24, 2016 4:47 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn 
for Fuel Library Core

+1 for Matthew!

2016-02-24 17:34 GMT+03:00 Fedor Zhadaev 
>:
+1

On Wed, Feb 24, 2016 at 5:30 PM Julia Aranovich 
> wrote:
+1

On Wed, Feb 24, 2016 at 4:57 PM Denis Egorenko 
> wrote:
I'm not a fuel core member, but i also would like to vote +1 for Matthew. He's 
doing great job!

2016-02-24 16:02 GMT+03:00 Aleksandr Didenko 
>:
+1

On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin 
> wrote:
Fellow Fuelers

I would like to kindly ask you to consider voting for Matthew Mosesohn as a 
Fuel Library Core
reviewer.

Matthew has been working with Fuel since its inception, worked on countless 
amount of features, such as :

Master Node Upgrades and Backup
Improvements to Fuel Infra
Mitaka, Kilo and Juno Support
Detachable Services Plugins
RHOS Support in Fuel
UCA Support
Refactoring of Haproxy and Firewall pieces

He has also been known as our Fuel Master node and Docker guru and has been 
continuously working on bugfixing where he scores as a bug squashing monster 
with more than 150 bugfixes to all the parts of Fuel Library (#1 throughout FL 
history).

As you can see, there is not a piece of Fuel Library that he has not yet gained 
experience with.

And this can easily be fetched with simple statistics of Matt's contribution. 
He is the topmost contributor to all Fuel projects among all Fuel Library folks 
and is the 3rd contributor of Fuel Library.
He also reviews a lot and has a fair amount of -1's (he is not as cruel as me, 
though :-))

Having that said, I would like to open the vote to promote Matt to OpenStack 
Fuel Library core reviewers.

--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com
www.mirantis.ru
vkuk...@mirantis.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



--
Best Regards,
Egorenko Denis,
Senior Deployment Engineer
Mirantis
__
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
--
Kind Regards,
Fedor Zhadaev

skype: zhadaevfm
IRC: fzhadaev

__
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



--
Thanks, Ivan Berezovskiy
MOS Puppet Team Lead
at Mirantis

slack: iberezovskiy
skype: bouhforever
phone: + 7-960-343-42-46

__
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][neutron][os-vif] os-vif core review team membership

[Moshe Levi]

> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: Tuesday, January 12, 2016 5:24 PM
> To: Daniel P. Berrange <berra...@redhat.com>; openstack-
> d...@lists.openstack.org
> Cc: Jay Pipes <jaypi...@gmail.com>; Sean Mooney
> <sean.k.moo...@intel.com>; Moshe Levi <mosh...@mellanox.com>; Sahid
> Orentino Ferdjaoui <sahid.ferdja...@redhat.com>; Maxime Leroy
> <maxime.le...@6wind.com>
> Subject: Re: [nova][neutron][os-vif] os-vif core review team membership
> 
> On 01/12/2016 10:15 AM, Daniel P. Berrange wrote:
> > So far myself & Jay Pipes have been working on the initial os-vif
> > prototype and setting up infrastructure for the project. Obviously we
> > need more then just 2 people on a core team, and after looking at
> > those who've expressed interest in os-vif, we came up with a
> > cross-section of contributors across the Nova, Neutron and NFV spaces
> > to be the initial core team:
> >
> >   Jay Pipes
> >   Daniel Berrange
> >   Sean Mooney
> >   Moshe Levi
> >   Russell Bryant
> >   Sahid Ferdjaoui
> >   Maxime Leroy
> >
> > So unless anyone wishes to decline the offer, once infra actually add
> > me to the os-vif-core team I'll be making these people os-vif core, so
> > we can move forward with the work on the library...
> 
> Thanks, I'm happy to help.
Same here. 
> 
> --
> Russell Bryant
__
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] [QoS] meeting rebooted

[Moshe Levi]

Just to add more details about the when and where  :) 
We will have a weekly meeting on Wednesday at 1400 UTC in #openstack-meeting-3
http://eavesdrop.openstack.org/#Neutron_QoS_Meeting 

Thanks,
Moshe Levi. 

> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Friday, November 20, 2015 12:08 PM
> To: Miguel Angel Ajo <mangel...@redhat.com>
> Cc: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>; victor.r.how...@gmail.com;
> irenab@gmail.com; Moshe Levi <mosh...@mellanox.com>; Vikram
> Choudhary <viks...@gmail.com>; Gal Sagie <gal.sa...@gmail.com>; Haim
> Daniel <hdan...@redhat.com>
> Subject: Re: [neutron] [QoS] meeting rebooted
> 
> Miguel Angel Ajo <mangel...@redhat.com> wrote:
> 
> >
> >Hi everybody,
> >
> >  We're restarting the QoS meeting for next week,
> >
> >  Here are the details, and a preliminary agenda,
> >
> >   https://etherpad.openstack.org/p/qos-mitaka
> >
> >
> >   Let's keep QoS moving!,
> >
> > Best,
> > Miguel Ángel.
> 
> I think you better give idea when/where it is restarted. :)
> 
> Ihar

__
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

[Moshe Levi]

Maybe we can you use the pci- passthrough meeting slot 
http://eavesdrop.openstack.org/#PCI_Passthrough_Meeting 
It been a long time since we had a meeting. 


> -Original Message-
> From: Nikola Đipanov [mailto:ndipa...@redhat.com]
> Sent: Tuesday, November 03, 2015 6:53 AM
> To: OpenStack Development Mailing List  d...@lists.openstack.org>
> Subject: [openstack-dev] [Nova] SR-IOV subteam
> 
> 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] [neutron][sriov] SRIOV-VM could not work well with normal VM

[Moshe Levi]

> -Original Message-
> From: yujie [mailto:judy_yu...@126.com]
> Sent: Tuesday, October 20, 2015 5:34 AM
> To: Moshe Levi <mosh...@mellanox.com>
> Cc: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron][sriov] SRIOV-VM could not work well
> with normal VM
> 
> Hi Moshe Levi,
> Sorry for replying to this message after so long time. The testing
> environment was unavailable before.
> I use Intel cards, but could only tested base kilo and vlan. Could it 
> work?
I am not failure with Intel cards, but as far as I know it should work with 
flat network not sure it will work with vlan 
> 
> 在 2015/9/22 13:24, Moshe Levi 写道:
> > Hi Yujie,
> >
> > There is a patch https://review.openstack.org/#/c/198736/ which I
> > wrote to add the mac of the normal instance to the SR-IOV embedded
> switch so that the packet will go to the PF instead of going to the wire.
> > This is done by using bridge tool with the command "bridge fdb add 
> dev "
> >
> > I was able to test it on Mellanox ConnectX3  card with both  vlan and flat
> network and it worked fine.
> > I wasn't able to test it on any of the Intel cards, but I was told the it 
> > only
> working on flat network, in vlan network the Intel card is dropping the tagged
> packets and they are not go up to the VF.
> >
> > What NIC are you using? Can you try using "bridge fdb add  dev
> > " where  is the mac of the normal vm and  is
> the PF and see if  that resolve the issue.
> > Also can you check it with  flat and vlan networks.
> >
> >
> > -Original Message-
> > From: yujie [mailto:judy_yu...@126.com]
> > Sent: Tuesday, September 22, 2015 6:28 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] [neutron][sriov] SRIOV-VM could not work well
> > with normal VM
> >
> > Hi all,
> > I am using neutron kilo without dvr to create sriov instance VM-A,it works
> well and could connect to its gateway fine.
> > But when I let the normal instance VM-B which in the same compute-node
> with VM-A ping its gateway, it failed. I capture the packet on the network-
> node, find the gateway already reply the ARP-reply message to VM-B. But
> compute-node which VM-B lives could not send the package to VM-B.
> > If delete VM-A and set : echo 0 >
> > /sys/class/enp5s0f0/device/sriov_numvfs, the problem solved.
> >
> > Is it a same question with the bug: SR-IOV port doesn't reach OVS port on
> same compute node ?
> > https://bugs.launchpad.net/neutron/+bug/1492228
> > Any suggestions will be grateful.
> >
> > Thanks,
> > Yujie
> >
> >
> >
> __
> 
> >  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] [neutron] New cycle started. What are you up to, folks?

[Moshe Levi]

> -Original Message-
> From: Sean M. Collins [mailto:s...@coreitpro.com]
> Sent: Thursday, October 01, 2015 6:42 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [neutron] New cycle started. What are you up
> to, folks?
> 
> On Thu, Oct 01, 2015 at 11:05:29AM EDT, Kyle Mestery wrote:
> > On Thu, Oct 1, 2015 at 9:57 AM, Sean M. Collins 
> wrote:
> >
> > > On Thu, Oct 01, 2015 at 10:02:24AM EDT, Ihar Hrachyshka wrote:
> > > > - more changes with less infra tinkering! neutron devs should not
> > > > need
> > > to go to infra projects so often to make an impact;
> > > > -- make our little neat DevStack plugin used for qos and sr-iov
> > > > only a
> > > huge pile of bash code that is currently stored in DevStack and is
> > > proudly called neutron-legacy now; and make the latter obsolete and
> > > eventually removed from DevStack;
> > >
> > > We may need to discuss this. I am currently doing a refactor of the
> > > Neutron DevStack integration in
> > >
> > > https://review.openstack.org/168438
> > >
> > > If I understand your message correctly, I disagree that we should be
> > > moving all the DevStack support for Neutron out of DevStack and
> > > making it a plugin. All that does is move the mess from one corner
> > > of the room, to another corner.
> > >
> > >
> > I would actually be in favor of cleaning up the mess AND moving it
> > into neutron. If it's in Neutron, we control our own destiny with
> > regards to landing patches which affect DevStack and ultimately our
> > gate jobs. To me, that's a huge win-win. Thus, cleanup first, then move to
> Neutron.
> 
> Frankly we have a bad track record in DevStack, if we are to make an
> argument about controlling our own destiny. Neutron-lib is in a sad state of
> affairs because we haven't had the discipline to keep things simple.
> 
> In fact, I think the whole genesis of the Neutron plugin for DevStack is a 
> great
> example of how controlling our own destiny has started to grow the mess.
> Yes, we needed it to gate the QoS code. But now things are starting to get
> added.
> 
> https://github.com/openstack/neutron/commit/bd07b74045d93c46483aa26
> 1b8686072d9b448e8
> 
I think the decision  should be based on where is the core code located. 
So if SR-IOV, OVS ,Linux Bridge, Qos are still in the neutron core the neutron 
devstack plugin 
should know how to install them. If we will decide to move them to different 
repos the
their devstack part should be moved as well.


> The trend is now that people are going to throw things into the Neutron
> DevStack plugin to get their doo-dad up and running, because making a new
> repo is harder than creating a patch (which maybe shows are repo creation
> process needs streamlining). I was originally for making Neutron DevStack
> plugins that exist in their own repos, instead of putting them in the Neutron
> tree. At least that makes things small, manageable, and straight forward. Yes,
> it makes for more plugin lines in your DevStack configuration, but at least 
> you
> know what each one does, instead of being an agglomeration.
> 
> If we are not careful, the Neutron DevStack plugin will grow into the big mess
> that neutron-legacy is.
> 
> Finally, Look at how many configuration knobs we have, and how there is a
> tendency to introduce new ones, instead of using local.conf to inject
> configuration into Neutron and the associated components. This ends up
> making it very complicated for someone to actually run Neutron in their
> DevStack, and I think a lot of people would give up and just run Nova-
> Network, which I will note is *still the default*.
> 
> We need to keep our ties strong with other projects, and improve them in
> some cases. I think culturally, if we start trying to move things into our 
> corner
> of the sandbox because working with other groups is hard, we send bad
> signals to others. This will eventually come back to bite us.
> 
> /rant
> 
> --
> Sean M. Collins
> 
> __
> 
> 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] [neutron][sriov] SRIOV-VM could not work well with normal VM

[Moshe Levi]

Hi Yujie,

There is a patch https://review.openstack.org/#/c/198736/ which I wrote to add 
the mac of the normal instance to 
the SR-IOV embedded switch so that the packet will go to the PF instead of 
going to the wire. 
This is done by using bridge tool with the command "bridge fdb add  dev 
"

I was able to test it on Mellanox ConnectX3  card with both  vlan and flat 
network and it worked fine. 
I wasn't able to test it on any of the Intel cards, but I was told the it only 
working on flat network, in vlan network the Intel card is dropping the tagged 
packets and they are not go up to the VF. 

What NIC are you using? Can you try using "bridge fdb add  dev 
" where  is the mac of the normal vm and  is the PF
and see if  that resolve the issue.  
Also can you check it with  flat and vlan networks.


-Original Message-
From: yujie [mailto:judy_yu...@126.com] 
Sent: Tuesday, September 22, 2015 6:28 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][sriov] SRIOV-VM could not work well with 
normal VM

Hi all,
I am using neutron kilo without dvr to create sriov instance VM-A,it works well 
and could connect to its gateway fine.
But when I let the normal instance VM-B which in the same compute-node with 
VM-A ping its gateway, it failed. I capture the packet on the network-node, 
find the gateway already reply the ARP-reply message to VM-B. But compute-node 
which VM-B lives could not send the package to VM-B.
If delete VM-A and set : echo 0 >
/sys/class/enp5s0f0/device/sriov_numvfs, the problem solved.

Is it a same question with the bug: SR-IOV port doesn't reach OVS port on same 
compute node ?
https://bugs.launchpad.net/neutron/+bug/1492228
Any suggestions will be grateful.

Thanks,
Yujie


__
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] [neutron][SR-IOV] deprecate agent_required option for SR-IOV mechanism driver

[Moshe Levi]

Hi all,

When SR-IOV introduce in Juno the SR-IOV Agent supported only link state change.
Some Intel cards don't support setting link state, so to
resolve it the  SR-IOV mechanism driver supports agent and agent less mode.
From Liberty the SR-IOV agent brings more functionality like
qos and port security so we want to make the agent mandatory.

I have already talked to pczesno from Intel and got his approval in the pci 
meeting [1]

For this to happen commit [2] and [3] need to be approved.



If anyone objects to this change now is the time to speak.





[1] - 
http://eavesdrop.openstack.org/meetings/pci_passthrough/2015/pci_passthrough.2015-06-23-13.09.log.txt

[2] - sriov: update port state even if ip link fails - 
https://review.openstack.org/#/c/195060/

[3] - SR-IOV: deprecate agent_required option - 
https://review.openstack.org/#/c/214324/



Thanks,

Moshe Levi
__
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][SR-IOV]How to assign VF to a VM?

[Moshe Levi]

Vxlan is not supported in SR-IOV and flat network should work from Kilo see 
commit[1]

Like I said you need to check your physical_device_mappings is correct can you 
post your
Did you put your agent config in /etc/neutron/conf.d/neutron-sriov-nic-agent?
So on the compute node you should do the following:
Create - /etc/neutron/conf.d/neutron-sriov-nic-agent/ml2_sriov.conf
And put the content
[securitygroup]
firewall_driver = neutron.agent.firewall.NoopFirewallDriver
[sriov_nic]
physical_device_mappings = physnet1:eth1
This will make only the agent to use firewall_driver = 
neutron.agent.firewall.NoopFirewallDriver
Also make sure physical_device_mappings is configure correctly

Please Note that the physnet1 in physical_device_mappings should be also 
appears in the nova.conf
pci_passthrough_whitelist = 
{address:*:0a:00.*,physical_network:physnet1}

[1] - https://review.openstack.org/#/c/142699/


From: 于洁 [mailto:16189...@qq.com]
Sent: Saturday, August 22, 2015 5:47 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: [openstack-dev] 回复： [Neutron][SR-IOV]How to assign VF to a VM?

Thanks Moshe,
Referring to https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking, 
it has the note:
Note:SR-IOV agent only work with NoopFirewallDriver when Security Groups are 
enabled, but you can still use other firewall_driver for other Agents by 
updating their conf with the requested firewall driver.
So I think linux.iptables_firewall.OVSHybridIptabl maybe not the issue.

[root@compute ~]# ps -ef|grep neutron-sriov
root 28672 26639  0 22:45 pts/000:00:00 grep --color=auto neutron-sriov
neutron  30891 1  0 05:21 ?00:01:41 /usr/bin/python2 
/usr/bin/neutron-sriov-nic-agent --config-file 
/usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf 
--config-dir /etc/neutron/conf.d/neutron-sriov-nic-agent --config-file 
/etc/neutron/plugins/ml2/ml2_conf_sriov.ini --log-file 
/var/log/neutron/sriov-nic-agent.log

I will have a try of vlan and vxlan.

Thank you,
Yu


-- 原始邮件 --
发件人: Moshe Levi;mosh...@mellanox.commailto:mosh...@mellanox.com;
发送时间: 2015年8月21日(星期五) 下午5:15
收件人: OpenStack Development Mailing List (not for usage 
questions)openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org;
 
openstack-operatorsopenstack-operat...@lists.openstack.orgmailto:openstack-operat...@lists.openstack.org;
主题: 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

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

[Moshe Levi]

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.org; 
openstack-dev 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 | 85aa4ef08044470dab1608395e5cac26  
   |
+---+--+

The logs of /var/log/neutron/server.log and /var/log/nova/nova-conductor.log 
are in attachment.

Any suggestions will be grateful.
Thanks.

Yu

__
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] sr-iov kilo getting libvirtd error while spawning a vm

[Moshe Levi]

Hi,
The driver name should be kvm and not qemu.
interface type=hostdev managed=yes
  mac address=fa:16:3e:eb:38:da/
  driver name=qemu/
  source
address type=pci domain=0x bus=0x81 slot=0x02 
function=0x7/
  /source
  vlan
tag id=1009/
  /vlan
/interface

I think you need to set the virt_type to kvm as describe below in the nova.conf
[libvirt]
virt_type = kvm



From: Kamsali, RaghavendraChari (Artesyn) 
[mailto:raghavendrachari.kams...@artesyn.com]
Sent: Monday, August 17, 2015 6:50 PM
To: openst...@lists.openstack.org
Cc: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: [openstack-dev] sr-iov kilo getting libvirtd error while spawning a vm

Hi,
Trying to bring up vm on sr-iov enabled openstack getting this error on compute 
node as shown below



from (pid=9551) _get_guest_xml /opt/stack/nova/nova/virt/libvirt/driver.py:4195
2015-08-17 21:15:40.957 DEBUG nova.virt.libvirt.vif 
[req-8d3ac9c1-d33d-4bd4-b4ab-5eda2e1c400f demo demo] vif_type=hw_veb 
instance=Instance(access_ip_v4=None,access_ip_v6=None,architecture=None,auto_disk_config=False,availability_zone=None,cell_name=None,cleaned=False,config_drive='',created_at=2015-08-17T15:45:32Z,default_ephemeral_device=None,default_swap_device='/dev/vdb',deleted=False,deleted_at=None,disable_terminate=False,display_description='vm1',display_name='vm1',ephemeral_gb=0,ephemeral_key_uuid=None,fault=?,flavor=Flavor(8),host='Compute1',hostname='vm1',id=18,image_ref='ef29abd3-f52c-4591-b608-c3ed948fb49b',info_cache=InstanceInfoCache,instance_type_id=8,kernel_id='',key_data=None,key_name=None,launch_index=0,launched_at=None,launched_on='Compute1',locked=False,locked_by=None,memory_mb=2048,metadata={},new_flavor=None,node='Compute1',numa_topology=None,old_flavor=None,os_type=None,pci_devices=PciDeviceList,pci_requests=InstancePCIRequests,power_state=0,progress=0,project_id='c3aa578e594f44f7a79cb075ac7688ab',ramdisk_id='',reservation_id='r-0u6rbpou',root_device_name='/dev/vda',root_gb=10,scheduled_at=None,security_groups=SecurityGroupList,shutdown_terminate=False,system_metadata={image_base_image_ref='ef29abd3-f52c-4591-b608-c3ed948fb49b',image_container_format='bare',image_disk_format='qcow2',image_min_disk='10',image_min_ram='0',network_allocated='True'},tags=?,task_state='spawning',terminated_at=None,updated_at=2015-08-17T15:45:34Z,user_data=None,user_id='9dd44e8f987548b2a304b3f12b812381',uuid=480128a7-7640-4ddb-9bd1-bdc0018e7f6e,vcpu_model=VirtCPUModel,vcpus=2,vm_mode=None,vm_state='building')
 vif=VIF({'profile': {u'pci_slot': u':81:02.7', u'physical_network': 
u'default', u'pci_vendor_info': u'8086:154c'}, 'ovs_interfaceid': None, 
'preserve_on_delete': True, 'network': Network({'bridge': None, 'subnets': 
[Subnet({'ips': [FixedIP({'meta': {}, 'version': 4, 'type': 'fixed', 
'floating_ips': [], 'address': u'192.168.1.11'})], 'version': 4, 'meta': 
{'dhcp_server': u'192.168.1.2'}, 'dns': [], 'routes': [], 'cidr': 
u'192.168.1.0/24', 'gateway': IP({'meta': {}, 'version': 4, 'type': 'gateway', 
'address': u'192.168.1.1'})})], 'meta': {'injected': False, 'tenant_id': 
u'c3aa578e594f44f7a79cb075ac7688ab', 'physical_network': u'default'}, 'id': 
u'e82ec190-e36d-4157-ae9c-e4e4948735e2', 'label': u'mgmt-net'}), 'devname': 
u'tap3b0a1ae4-4e', 'vnic_type': u'direct', 'qbh_params': None, 'meta': {}, 
'details': {u'port_filter': False, u'vlan': u'1009'}, 'address': 
u'fa:16:3e:eb:38:da', 'active': True, 'type': u'hw_veb', 'id': 
u'3b0a1ae4-4eb5-4911-a9a7-109217188067', 'qbg_params': None}) from (pid=9551) 
plug /opt/stack/nova/nova/virt/libvirt/vif.py:597
2015-08-17 21:15:40.961 ERROR nova.virt.libvirt.driver 
[req-8d3ac9c1-d33d-4bd4-b4ab-5eda2e1c400f demo demo] Error defining a domain 
with XML: domain type=qemu
  uuid480128a7-7640-4ddb-9bd1-bdc0018e7f6e/uuid
  nameinstance-0012/name
  memory2097152/memory
  vcpu2/vcpu
  metadata
nova:instance xmlns:nova=http://openstack.org/xmlns/libvirt/nova/1.0;
  nova:package version=2015.1.2/
  nova:namevm1/nova:name
  nova:creationTime2015-08-17 15:45:40/nova:creationTime
  nova:flavor name=m1.new
nova:memory2048/nova:memory
nova:disk10/nova:disk
nova:swap200/nova:swap
nova:ephemeral0/nova:ephemeral
nova:vcpus2/nova:vcpus
  /nova:flavor
  nova:owner
nova:user uuid=9dd44e8f987548b2a304b3f12b812381demo/nova:user
nova:project 
uuid=c3aa578e594f44f7a79cb075ac7688abdemo/nova:project
  /nova:owner
  nova:root type=image uuid=ef29abd3-f52c-4591-b608-c3ed948fb49b/
/nova:instance
  /metadata
  sysinfo type=smbios
system
  entry name=manufacturerOpenStack Foundation/entry
  entry name=productOpenStack Nova/entry
  entry name=version2015.1.2/entry
  entry name=serial94e62060-1011-4750-ac16-88c58d7b40af/entry
  entry name=uuid480128a7-7640-4ddb-9bd1-bdc0018e7f6e/entry
/system
  /sysinfo
  os
typehvm/type

[openstack-dev] [nova][FFE] Feature Freeze Exception Request for 'Adding support for InfiniBand SR-IOV vif type'

[Moshe Levi]

Hi,
I would like to request a FFE for the following BP 
https://blueprints.launchpad.net/nova/+spec/vif-driver-ib-passthrough
The BP has one patch https://review.openstack.org/#/c/187052/ which had +2 but 
lost in the rebase.
The neutron code it already merged https://review.openstack.org/#/c/187054/ and 
not merging this will break the mlnx
mechanism driver in the neutron core.
The code is self-contained and very minimal.

Thanks,
Moshe Levi.






__
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] Mellanox CI Issues

[Moshe Levi]

Hi Dan,

I just want to update you that the report success after short 
less-than-a-minute run is Zuul problem  see [1].
This is happened because we apply filter rules to run only on PCI code to 
reduce load on our CI System.

Unfortunately  we missed this issue  in our monitoring because all the job in 
the Jenkins were looking good and 
just Zuul reports also when no Jenkins job was scheduled.

I talked also with John Garbutt and it seem that the recommendation is to 
filter only doc and test folders, 
but still I would like to filter some other folders like
1. nova/nova/virt/hyperv
2. nova/nova/virt/ironic
3. nova/nova/virt/vmwareapi
4. nova/nova/virt/xenapi

Is there any Nova CI guidelines  for file filtering?

Again I would like to apologize for the inconvenient.

[1] https://review.openstack.org/#/c/188383/

Thank,
Moshe Levi.

-Original Message-
From: Lenny Verkhovsky 
Sent: Monday, June 01, 2015 11:21 PM
To: Dan Smith; OpenStack Development Mailing List (not for usage questions)
Cc: Moshe Levi
Subject: RE: [nova] Mellanox CI Issues

Hi Dan,
I disabled Mellanox Nova CI from commenting and will check this issue first 
thing tomorrow morning.
Thanks and my deepest apologies.

Lenny Verkhovsky


-Original Message-
From: Dan Smith [mailto:d...@danplanet.com] 
Sent: Monday, June 01, 2015 7:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Moshe Levi; Lenny Verkhovsky
Subject: [nova] Mellanox CI Issues

Hi,

Mellanox CI has been broken for a while now. Test runs are reported as 
successful after an impossibly short less-than-a-minute run. Could the owners 
of this please take a look and address the problem? At least disabling 
commenting while working on the issue would be helpful.

Also, on success, the bot doesn't post the log files, which is (a) inconsistent 
with other test bots and (b) not very helpful for validating that success is 
real. This is especially relevant right now, given that we know the success 
reports are erroneous at the moment.

This is the second time (in recent memory) that Mellanox CI has gone off the 
rails for a decent amount of time without being noticed by the owners. If this 
continues, I'll be in favor of removing commenting privileges for this account 
and will be hesitant to throw in my support for re-enabling it. Running CI 
against gerrit comes with serious responsibility for monitoring!

Thanks!

--Dan

__
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] Progressing/tracking work on libvirt / vif drivers

[Moshe Levi]

Hi Neil,

First of all thank for organizing this.

Both  Infiniband SR-IOV VIF type and Removal of mlnx_direct VIF type are ready 
for core review.



-Original Message-
From: Neil Jerram [mailto:neil.jer...@metaswitch.com] 
Sent: Monday, June 01, 2015 8:38 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif 
drivers

On 01/06/15 17:45, Neil Jerram wrote:

 Many thanks, John  Dan.  I'll start by drafting a summary of the work 
 that I'm aware of in this area, at 
 https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work.

OK, my first draft of this is now there at [1].  Please could folk with 
VIF-related work pending check that I haven't missed or misrepresented them?  
Especially, please could owners of the 'Infiniband SR-IOV' and 'mlnx_direct 
removal' changes confirm that those are really ready for core review?  It would 
be bad to ask for core review that wasn't in fact wanted.

Thanks,
Neil


[1] https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work

__
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] PCI pass-through SRIOV

[Moshe Levi]

This is a different  error

2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance: 
101776a0-cd2e-47b9-bdc4-1097782201c6] if ret == -1: raise libvirtError 
('virDomainCreateWithFlags() failed', dom=self)
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance: 
101776a0-cd2e-47b9-bdc4-1097782201c6] libvirtError: internal error: process 
exited while connecting to monitor: 2015-05-26T04:34:07.980897Z qemu-kvm: 
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: vfio: failed to 
open /dev/vfio/vfio: Operation not permitted
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance: 
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.980951Z qemu-kvm: 
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: vfio: failed to 
setup container for group 49
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance: 
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.980970Z qemu-kvm: 
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: vfio: failed to 
get group 49
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance: 
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.980995Z qemu-kvm: 
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: Device 
initialization failed.
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance: 
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.981019Z qemu-kvm: 
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: Device 'vfio-pci' 
could not be initialized

You are using intel card therefore I think you should contact them and ask if 
this card is supported.


From: Kamsali, RaghavendraChari (Artesyn) 
[mailto:raghavendrachari.kams...@artesyn.com]
Sent: Tuesday, May 26, 2015 4:49 PM
To: Kamsali, RaghavendraChari (Artesyn); Moshe Levi; OpenStack Development 
Mailing List (not for usage questions); openst...@lists.openstack.org
Subject: RE: [openstack-dev] PCI pass-through SRIOV

Please find the attachment for the logs when changed in ml2_conf_sriov.ini

From: Kamsali, RaghavendraChari (Artesyn) 
[mailto:raghavendrachari.kams...@artesyn.com]
Sent: Tuesday, May 26, 2015 1:36 PM
To: Moshe Levi; OpenStack Development Mailing List (not for usage questions); 
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: Re: [Openstack] [openstack-dev] PCI pass-through SRIOV

Hi,

Yes I changed it on what you mentioned in ml2_conf_sriov.ini ,but same issue 
occurs.


Thanks and Regards,
Raghavendrachari kamsali,
Embedded Computing and Power,
Hyderabad, AndhraPradesh , India



From: Moshe Levi [mailto:mosh...@mellanox.com]
Sent: Tuesday, May 26, 2015 12:58 PM
To: Kamsali, RaghavendraChari [ENGINEERING/IN]; OpenStack Development Mailing 
List (not for usage questions); 
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: RE: [openstack-dev] PCI pass-through SRIOV

Hi Kamsali,
This is the error:
Refusing to bind due to unsupported vnic_type: direct

Please add the following to you ml2_conf.ini
supported_pci_vendor_devs = 8086:154c

Thanks,
Moshe Levi


From: Kamsali, RaghavendraChari (Artesyn) 
[mailto:raghavendrachari.kams...@artesyn.com]
Sent: Monday, May 25, 2015 2:31 PM
To: Moshe Levi; OpenStack Development Mailing List (not for usage questions); 
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: RE: [openstack-dev] PCI pass-through SRIOV

FYI,

Neutron-server logs,
Ml2 config file on compute and controller
Nova.conf file



From: Moshe Levi [mailto:mosh...@mellanox.com]
Sent: Saturday, May 23, 2015 7:53 PM
To: OpenStack Development Mailing List (not for usage questions); 
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: Re: [Openstack] [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

Re: [openstack-dev] PCI pass-through SRIOV

[Moshe Levi]

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] [nova][neutron][SR-IOV]

[Moshe Levi]

Hi all,

I prepared etherpad with all SR-IOV Features [1]  that were submitted to 
Neutron/Nova for Liberty.
Please feel free to add new features or existing features that I missed.

The etherpad also includes issues to discuss  section.
Please feel free  add your feedback/issues under it.

I will  arrange BoF session. Time and day are TBD.

[1] https://etherpad.openstack.org/p/liberty-sriov

Regards,
Moshe Levi




__
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]Anyone looking at support for VLAN-aware VMs in Liberty?

[Moshe Levi]

Hi Erik,

Mellanox is also interested in it but for  ML2 plugin with and sriov-nic-switch 
mechanism driver.
I planning to do agent support for the sriov-nic-switch (when the driver will 
support it), but if you need help in other places I can also pitch in.


-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: Friday, May 08, 2015 8:23 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware 
VMs in Liberty?

On 05/08/2015 09:29 AM, Erik Moe wrote:
 Hi,

 I have not been able to work with upstreaming of this for some time now.
 But now it looks like I may make another attempt. Who else is 
 interested in this, as a user or to help contributing? If we get some 
 traction we can have an IRC meeting sometime next week.

Hi Erik,

Mirantis has interest in this functionality, and depending on the amount of 
work involved, we could pitch in...

Please cc me or add me to relevant reviews and I'll make sure the right folks 
are paying attention.

All the best,
-jay

 *From:*Scott Drennan [mailto:sco...@nuagenetworks.net]
 *Sent:* den 4 maj 2015 18:42
 *To:* openstack-dev@lists.openstack.org
 *Subject:* [openstack-dev] [neutron]Anyone looking at support for 
 VLAN-aware VMs in Liberty?

 VLAN-transparent or VLAN-trunking networks have landed in Kilo, but I 
 don't see any work on VLAN-aware VMs for Liberty.  There is a 
 blueprint[1] and specs[2] which was deferred from Kilo - is this 
 something anyone is looking at as a Liberty candidate?  I looked but 
 didn't find any recent work - is there somewhere else work on this is 
 happening?  No-one has listed it on the liberty summit topics[3] 
 etherpad, which could mean it's uncontroversial, but given history on 
 this, I think that's unlikely.

 cheers,

 Scott

 [1]: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms

 [2]: https://review.openstack.org/#/c/94612

 [3]: https://etherpad.openstack.org/p/liberty-neutron-summit-topics



 __
  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

[openstack-dev] [nova][neutron] bring NIC attributes to OPSK

[Moshe Levi]

Hi,
After talking to several customers, we noticed that there is a solid 
requirement that choosing a compute node would take into account other 
attributes as NIC's attributes and capabilities ( speed, RDAM enable,  
supported link modes and etc... ).
I was searching around old BP, and  was thinking on several options to 
implement it:

1.   Nova compute would recognize and report its Nic's capabilities, and 
Nova's filter or scheduler will take them into consideration.

(There is  a nova  blueprint for link state  awareness 
https://review.openstack.org/#/c/87978/3/specs/juno/nic-state-aware-scheduling.rst,
 but here the idea is just NIC's capabilities without the link state.)

2.   New Neutron physical topology service(service plugin)  that will 
retrieve this information and store it in Neutron either by  L2 Agents or SDN 
driver, and a Nova filter that will query Neutron [1].

[1] 
https://review.openstack.org/#/c/91275/19/specs/juno/physical-network-topology.rst

Please share your thoughts and feel free to comment.

Best Regard,
Moshe Levi

__
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][pci-passthrough] Error: An object of type PciDevicePoolList is required here

[Moshe Levi]

Jay,

Thanks for the response.
Here is the bug https://bugs.launchpad.net/nova/+bug/1435483

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: Monday, March 23, 2015 5:46 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][pci-passthrough] Error: An object of type 
PciDevicePoolList is required here

On Sun, Mar 22, 2015 at 04:58:00PM +, Moshe Levi wrote:
 Hi,
 
 In the latest master nova code I am keep getting this error  An object of 
 type PciDevicePoolList is required here
 
 My nova.conf contains  pci_passthrough_whitelist.
 
 When I tried to launch vm after devstack installation the vm was successfully 
 booted.
 When I restart the compute node and then try to launch vm I get a 
 failure due to  error An object of type PciDevicePoolList is required 
 here. (It doesn't matter if it vm with normal or vm with direct port 
 )
 
 In the debugger  I can see the in that one of resources sent to the 
 scheduler is pci_device_pools which is a list for example 
 ('pci_device_pools': [{'count': 7, 'vendor_id': u'15b3', 'product_id': 
 u'1004', 'tags': {u'numa_node': None, u'physical_network': u'physnet1'}}]) 
 When this resource saved into the database I get  the above error.
 Please note I can reproduce this issue only after I restart the compute node.
 Removing the pci_device_pools key from the resources (remove it from 
 self.compute_node in the resource_tracker) fix this issue, but I am not sure 
 that it is the correct way to go.
 
 Is anyone see  this issue?
 Should the pci_device_pools be sent to the scheduler?

It's actually not being sent to the scheduler (even though, confusingly, the 
call is to nova.scheduler.client.report.update_resource_stats()).
It's actually just going to the conductor, and then the database.

Looks like, indeed, there was a bug introduced recently. Have you filed a bug 
yet? If not, please do and we'll get to work on it.

Best,
-jay

__
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][pci-passthrough] Error: An object of type PciDevicePoolList is required here

[Moshe Levi]

Hi,

In the latest master nova code I am keep getting this error  An object of type 
PciDevicePoolList is required here

My nova.conf contains  pci_passthrough_whitelist.

When I tried to launch vm after devstack installation the vm was successfully 
booted.
When I restart the compute node and then try to launch vm I get a failure due 
to  error An object of type PciDevicePoolList is required here. (It doesn't 
matter if it vm with normal or vm with direct port )

In the debugger  I can see the in that one of resources sent to the scheduler 
is pci_device_pools which is a list for example ('pci_device_pools': 
[{'count': 7, 'vendor_id': u'15b3', 'product_id': u'1004', 'tags': 
{u'numa_node': None, u'physical_network': u'physnet1'}}])
When this resource saved into the database I get  the above error.
Please note I can reproduce this issue only after I restart the compute node.
Removing the pci_device_pools key from the resources (remove it from 
self.compute_node in the resource_tracker) fix this issue, but I am not sure 
that it is the correct way to go.

Is anyone see  this issue?
Should the pci_device_pools be sent to the scheduler?

__
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] request spec freeze exception for Add spec for VIF Driver for SR-IOV InfiniBand

[Moshe Levi]

Hi,

I'd like to request an exception for Add spec for VIF Driver for SR-IOV 
InfiniBand.
https://review.openstack.org/#/c/131729/

This is  very localized change, that does not affect any other types and 
justify by InfiniBand use cases.
Work in progress code https://review.openstack.org/#/c/145779/



Thanks,
Moshe Levi.
__
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][sriov] SRIOV related specs pending for approval

[Moshe Levi]

Also this one:
Nova: Add spec for VIF Driver for SR-IOV 
InfiniBandhttps://review.openstack.org/131729
https://review.openstack.org/#/c/131729/


From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Wednesday, January 07, 2015 5:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][sriov] SRIOV related specs pending for 
approval

Hi Joe and others,

One of the topics for tomorrow's NOVA IRC is about k-2 spec exception process. 
I'd like to bring up the following specs up again for consideration:

During the Kilo summit, the folks in the pci passthrough and SR-IOV groups 
discussed what we'd like to achieve in this cycle, and the result was 
documented in this Etherpad:
https://etherpad.openstack.org/p/kilo_sriov_pci_passthrough

To get the work going, we've submitted a few design specs:

Nova: Live migration with macvtap SR-IOV
https://blueprints.launchpad.net/nova/+spec/sriov-live-migration

Nova: sriov interface attach/detach
https://blueprints.launchpad.net/nova/+spec/sriov-interface-attach-detach

 Nova: Api specify vnic_type
https://blueprints.launchpad.net/neutron/+spec/api-specify-vnic-type

Nova: SRIOV scheduling with stateless offloads
https://blueprints.launchpad.net/nova/+spec/sriov-sched-with-stateless-offloads


Thanks for your kindly consideration.

-Robert

On 12/22/14, 1:20 PM, Joe Gordon 
joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote:



On Fri, Dec 19, 2014 at 6:53 AM, Robert Li (baoli) 
ba...@cisco.commailto:ba...@cisco.com wrote:
Hi Joe,

See this thread on the SR-IOV CI from Irena and Sandhya:

http://lists.openstack.org/pipermail/openstack-dev/2014-November/050658.html

http://lists.openstack.org/pipermail/openstack-dev/2014-November/050755.html

I believe that Intel is building a CI system to test SR-IOV as well.

Thanks for the clarification.


Thanks,
Robert


On 12/18/14, 9:13 PM, Joe Gordon 
joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote:



On Thu, Dec 18, 2014 at 2:18 PM, Robert Li (baoli) 
ba...@cisco.commailto:ba...@cisco.com wrote:
Hi,

During the Kilo summit, the folks in the pci passthrough and SR-IOV groups 
discussed what we'd like to achieve in this cycle, and the result was 
documented in this Etherpad:
https://etherpad.openstack.org/p/kilo_sriov_pci_passthrough

To get the work going, we've submitted a few design specs:

Nova: Live migration with macvtap SR-IOV
https://blueprints.launchpad.net/nova/+spec/sriov-live-migration

Nova: sriov interface attach/detach
https://blueprints.launchpad.net/nova/+spec/sriov-interface-attach-detach

 Nova: Api specify vnic_type
https://blueprints.launchpad.net/neutron/+spec/api-specify-vnic-type

Neutron-Network settings support for vnic-type
https://blueprints.launchpad.net/neutron/+spec/network-settings-support-vnic-type

Nova: SRIOV scheduling with stateless offloads
https://blueprints.launchpad.net/nova/+spec/sriov-sched-with-stateless-offloads

Now that the specs deadline is approaching, I'd like to bring them up in here 
for exception considerations. A lot of works have been put into them. And we'd 
like to see them get through for Kilo.

We haven't started the spec exception process yet.


Regarding CI for PCI passthrough and SR-IOV, see the attached thread.

Can you share this via a link to something on 
http://lists.openstack.org/pipermail/openstack-dev/


thanks,
Robert


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev