Re: [openstack-dev] [neutron][nova][stable][sr-iov] Status of physical_device_mappings

2016-03-30 Thread Ihar Hrachyshka 
Seems like the explanation below indeed suggests that’s a regression for  
Mitaka. We’ll track the bug for a backport. I don’t think that we can block  
the initial Mitaka release for that though. So let’s work on the master fix  
right now, and target the fix for Mitaka for one of the first minor updates  
for the branch.


Ihar

Vladimir Eremin  wrote:


Hi jay,

There was no ability to setup this configuration WITH Neutron SR-IOV ML2  
agent in Liberty. That what you pointed out and you’re totally correct.


But in Liberty, you’re not required to use Neutron SR-IOV ML2 agent to  
get this functionality works. And if you configure only nova-compute and  
neutron-server (WITHOUT Neutron SR-IOV ML2 agent), you could achieve  
desired configuration.


Basically:
* Liberty: you can use agent and you will be limited in physnets, or you  
can use it without agent.

* Mitaka: you should use agent and you will be limited in physnets.

So, regression is introduced by making Neutron SR-IOV ML2 agent required.  
And this easy-fix removes the problem.


--
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.




On Mar 23, 2016, at 11:01 PM, Jay Pipes  wrote:

+tags for stable and nova

Hi Vladimir, comments inline. :)

On 03/21/2016 05:16 AM, Vladimir Eremin wrote:

Hey OpenStackers,

I’ve recently found out, that changing of use neutron sriov-agent in  
Mitaka from optional to required[1] makes a kind of regression.


While I understand that it is important for you to be able to associate  
more than one NIC to a physical network, I see no evidence that there  
was a *regression* in Mitaka. I don't see any ability to specify more  
than one NIC for a physical network in the Liberty Neutron SR-IOV ML2  
agent:


https://github.com/openstack/neutron/blob/stable/liberty/neutron/common/utils.py#L223-L225

Before Mitaka, there was possible to use any number of NICs with one  
Neutron physnet just by specifying pci_passthrough_whitelist in nova:


[default]
pci_passthrough_whitelist = { "devname": "eth3", "physical_network": "physnet2”},{ "devname": 
"eth4", "physical_network": "physnet2”},

which means, that eth3 and eth4 will be used for physnet2 in some manner.


Yes, *in Nova*, however from what I can tell, this functionality never  
existed in the parse_mappings() function in neutron.common.utils module.



In Mitaka, there also required to setup neutron sriov-agent as well:

[sriov_nic]
physical_device_mappings = physnet2:eth3

The problem actually is to unable to specify this mapping as  
"physnet2:eth3,physnet2:eth4” due to implementation details, so it is  
clearly a regression.


A regression means that a change broke some previously-working  
functionality. This is not a regression, since there apparently was  
never such functionality in Neutron.


I’ve filed bug[2] for it and proposed a patch[3]. Originally  
physical_device_mappings is converted to dict, where physnet name goes  
to key, and interface name to value:



parse_mappings('physnet2:eth3’)

   {‘physnet2’: 'eth3’}

parse_mappings('physnet2:eth3,physnet2:eth4’)

   ValueError: Key physnet2 in mapping: 'physnet2:eth4' not unique

I’ve changed it a bit, so interface name is stored in list, so now this  
case is working:



parse_mappings_multi('physnet2:eth3,physnet2:eth4’)

   {‘physnet2’: [‘eth3’, 'eth4’]}

I’d like to see this fix[3] in master and Mitaka branch.


I understand you really want this functionality in Mitaka. And I will  
leave it up to the stable team to determine whether this code should be  
backported to stable/mitaka. However, I will point out that this is a  
new feature, not a bug fix for a regression. There is no regression  
because the ability for Neutron to use more than one NIC with a physnet  
was never supported as far as I can tell.


Best,
-jay

Moshe Levi also proposed to refactor this part of code to remove  
physical_device_mappings and reuse data that nova provides somehow.  
I’ll file the RFE as soon as I figure out how it should work.


[1]:  
http://docs.openstack.org/liberty/networking-guide/adv_config_sriov.html

[2]: https://bugs.launchpad.net/neutron/+bug/1558626
[3]: https://review.openstack.org/294188

--
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.





__
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

Re: [openstack-dev] [neutron][nova][stable][sr-iov] Status of physical_device_mappings

2016-03-29 Thread Vladimir Eremin 
Hi jay,

There was no ability to setup this configuration WITH Neutron SR-IOV ML2 agent 
in Liberty. That what you pointed out and you’re totally correct.

But in Liberty, you’re not required to use Neutron SR-IOV ML2 agent to get this 
functionality works. And if you configure only nova-compute and neutron-server 
(WITHOUT Neutron SR-IOV ML2 agent), you could achieve desired configuration.

Basically:
* Liberty: you can use agent and you will be limited in physnets, or you can 
use it without agent.
* Mitaka: you should use agent and you will be limited in physnets.

So, regression is introduced by making Neutron SR-IOV ML2 agent required. And 
this easy-fix removes the problem.

-- 
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.



> On Mar 23, 2016, at 11:01 PM, Jay Pipes  wrote:
> 
> +tags for stable and nova
> 
> Hi Vladimir, comments inline. :)
> 
> On 03/21/2016 05:16 AM, Vladimir Eremin wrote:
>> Hey OpenStackers,
>> 
>> I’ve recently found out, that changing of use neutron sriov-agent in Mitaka 
>> from optional to required[1] makes a kind of regression.
> 
> While I understand that it is important for you to be able to associate more 
> than one NIC to a physical network, I see no evidence that there was a 
> *regression* in Mitaka. I don't see any ability to specify more than one NIC 
> for a physical network in the Liberty Neutron SR-IOV ML2 agent:
> 
> https://github.com/openstack/neutron/blob/stable/liberty/neutron/common/utils.py#L223-L225
> 
>> Before Mitaka, there was possible to use any number of NICs with one Neutron 
>> physnet just by specifying pci_passthrough_whitelist in nova:
>> 
>> [default]
>> pci_passthrough_whitelist = { "devname": "eth3", "physical_network": 
>> "physnet2”},{ "devname": "eth4", "physical_network": "physnet2”},
>> 
>> which means, that eth3 and eth4 will be used for physnet2 in some manner.
> 
> Yes, *in Nova*, however from what I can tell, this functionality never 
> existed in the parse_mappings() function in neutron.common.utils module.
> 
>> In Mitaka, there also required to setup neutron sriov-agent as well:
>> 
>> [sriov_nic]
>> physical_device_mappings = physnet2:eth3
>> 
>> The problem actually is to unable to specify this mapping as 
>> "physnet2:eth3,physnet2:eth4” due to implementation details, so it is 
>> clearly a regression.
> 
> A regression means that a change broke some previously-working functionality. 
> This is not a regression, since there apparently was never such functionality 
> in Neutron.
> 
>> I’ve filed bug[2] for it and proposed a patch[3]. Originally 
>> physical_device_mappings is converted to dict, where physnet name goes to 
>> key, and interface name to value:
>> 
>> >>> parse_mappings('physnet2:eth3’)
>> {‘physnet2’: 'eth3’}
>> >>> parse_mappings('physnet2:eth3,physnet2:eth4’)
>> ValueError: Key physnet2 in mapping: 'physnet2:eth4' not unique
>> 
>> I’ve changed it a bit, so interface name is stored in list, so now this case 
>> is working:
>> 
>> >>> parse_mappings_multi('physnet2:eth3,physnet2:eth4’)
>> {‘physnet2’: [‘eth3’, 'eth4’]}
>> 
>> I’d like to see this fix[3] in master and Mitaka branch.
> 
> I understand you really want this functionality in Mitaka. And I will leave 
> it up to the stable team to determine whether this code should be backported 
> to stable/mitaka. However, I will point out that this is a new feature, not a 
> bug fix for a regression. There is no regression because the ability for 
> Neutron to use more than one NIC with a physnet was never supported as far as 
> I can tell.
> 
> Best,
> -jay
> 
>> Moshe Levi also proposed to refactor this part of code to remove 
>> physical_device_mappings and reuse data that nova provides somehow. I’ll 
>> file the RFE as soon as I figure out how it should work.
>> 
>> [1]: http://docs.openstack.org/liberty/networking-guide/adv_config_sriov.html
>> [2]: https://bugs.launchpad.net/neutron/+bug/1558626
>> [3]: https://review.openstack.org/294188
>> 
>> --
>> With best regards,
>> Vladimir Eremin,
>> Fuel Deployment Engineer,
>> Mirantis, Inc.
>> 
>> 
>> 
>> 
>> 
>> __
>> 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

Re: [openstack-dev] [neutron][nova][stable][sr-iov] Status of physical_device_mappings

2016-03-24 Thread Mooney, Sean K 


> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Wednesday, March 23, 2016 8:01 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron][nova][stable][sr-iov] Status of
> physical_device_mappings
> 
> +tags for stable and nova
> 
> Hi Vladimir, comments inline. :)
> 
> On 03/21/2016 05:16 AM, Vladimir Eremin wrote:
> > Hey OpenStackers,
> >
> > I've recently found out, that changing of use neutron sriov-agent in
> Mitaka from optional to required[1] makes a kind of regression.
> 
> While I understand that it is important for you to be able to associate
> more than one NIC to a physical network, I see no evidence that there
> was a *regression* in Mitaka. I don't see any ability to specify more
> than one NIC for a physical network in the Liberty Neutron SR-IOV ML2
> agent:
> 
> https://github.com/openstack/neutron/blob/stable/liberty/neutron/common/
> utils.py#L223-L225
> 
> > Before Mitaka, there was possible to use any number of NICs with one
> Neutron physnet just by specifying pci_passthrough_whitelist in nova:
> >
> >  [default]
> >  pci_passthrough_whitelist = { "devname": "eth3",
> > "physical_network": "physnet2"},{ "devname": "eth4",
> > "physical_network": "physnet2"},
> >
> > which means, that eth3 and eth4 will be used for physnet2 in some
> manner.
> 
> Yes, *in Nova*, however from what I can tell, this functionality never
> existed in the parse_mappings() function in neutron.common.utils module.
> 
> > In Mitaka, there also required to setup neutron sriov-agent as well:
> >
> >  [sriov_nic]
> >  physical_device_mappings = physnet2:eth3
> >
> > The problem actually is to unable to specify this mapping as
> "physnet2:eth3,physnet2:eth4" due to implementation details, so it is
> clearly a regression.
> 
> A regression means that a change broke some previously-working
> functionality. This is not a regression, since there apparently was
> never such functionality in Neutron.
This may have worked in the past if yo did not use the neutron sriovnic agent.
In liberty it was optional and not used with intel nics but in mitaka it is now 
required.
I do not have a liberty system to hand to test but perhaps that is how it 
worked(assuming it did work) 
In liberty but not in mitaka?
> 
> > I've filed bug[2] for it and proposed a patch[3]. Originally
> physical_device_mappings is converted to dict, where physnet name goes
> to key, and interface name to value:
> >
> >  >>> parse_mappings('physnet2:eth3')
> >  {'physnet2': 'eth3'}
> >  >>> parse_mappings('physnet2:eth3,physnet2:eth4')
> >  ValueError: Key physnet2 in mapping: 'physnet2:eth4' not unique
> >
> > I've changed it a bit, so interface name is stored in list, so now
> this case is working:
> >
> >  >>> parse_mappings_multi('physnet2:eth3,physnet2:eth4')
> >  {'physnet2': ['eth3', 'eth4']}
> >
> > I'd like to see this fix[3] in master and Mitaka branch.
> 
> I understand you really want this functionality in Mitaka. And I will
> leave it up to the stable team to determine whether this code should be
> backported to stable/mitaka. However, I will point out that this is a
> new feature, not a bug fix for a regression. There is no regression
> because the ability for Neutron to use more than one NIC with a physnet
> was never supported as far as I can tell.
> 
> Best,
> -jay
> 
> > Moshe Levi also proposed to refactor this part of code to remove
> physical_device_mappings and reuse data that nova provides somehow. I'll
> file the RFE as soon as I figure out how it should work.
> >
> > [1]:
> > http://docs.openstack.org/liberty/networking-guide/adv_config_sriov.ht
> > ml
> > [2]: https://bugs.launchpad.net/neutron/+bug/1558626
> > [3]: https://review.openstack.org/294188
> >
> > --
> > With best regards,
> > Vladimir Eremin,
> > Fuel Deployment Engineer,
> > Mirantis, Inc.
> >
> >
> >
> >
> >
> > __
> >  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][stable][sr-iov] Status of physical_device_mappings

2016-03-23 Thread Jay Pipes 

+tags for stable and nova

Hi Vladimir, comments inline. :)

On 03/21/2016 05:16 AM, Vladimir Eremin wrote:

Hey OpenStackers,

I’ve recently found out, that changing of use neutron sriov-agent in Mitaka 
from optional to required[1] makes a kind of regression.


While I understand that it is important for you to be able to associate 
more than one NIC to a physical network, I see no evidence that there 
was a *regression* in Mitaka. I don't see any ability to specify more 
than one NIC for a physical network in the Liberty Neutron SR-IOV ML2 agent:


https://github.com/openstack/neutron/blob/stable/liberty/neutron/common/utils.py#L223-L225


Before Mitaka, there was possible to use any number of NICs with one Neutron 
physnet just by specifying pci_passthrough_whitelist in nova:

 [default]
 pci_passthrough_whitelist = { "devname": "eth3", "physical_network": "physnet2”},{ "devname": 
"eth4", "physical_network": "physnet2”},

which means, that eth3 and eth4 will be used for physnet2 in some manner.


Yes, *in Nova*, however from what I can tell, this functionality never 
existed in the parse_mappings() function in neutron.common.utils module.



In Mitaka, there also required to setup neutron sriov-agent as well:

 [sriov_nic]
 physical_device_mappings = physnet2:eth3

The problem actually is to unable to specify this mapping as 
"physnet2:eth3,physnet2:eth4” due to implementation details, so it is clearly a 
regression.


A regression means that a change broke some previously-working 
functionality. This is not a regression, since there apparently was 
never such functionality in Neutron.



I’ve filed bug[2] for it and proposed a patch[3]. Originally 
physical_device_mappings is converted to dict, where physnet name goes to key, 
and interface name to value:

 >>> parse_mappings('physnet2:eth3’)
 {‘physnet2’: 'eth3’}
 >>> parse_mappings('physnet2:eth3,physnet2:eth4’)
 ValueError: Key physnet2 in mapping: 'physnet2:eth4' not unique

I’ve changed it a bit, so interface name is stored in list, so now this case is 
working:

 >>> parse_mappings_multi('physnet2:eth3,physnet2:eth4’)
 {‘physnet2’: [‘eth3’, 'eth4’]}

I’d like to see this fix[3] in master and Mitaka branch.


I understand you really want this functionality in Mitaka. And I will 
leave it up to the stable team to determine whether this code should be 
backported to stable/mitaka. However, I will point out that this is a 
new feature, not a bug fix for a regression. There is no regression 
because the ability for Neutron to use more than one NIC with a physnet 
was never supported as far as I can tell.


Best,
-jay


Moshe Levi also proposed to refactor this part of code to remove 
physical_device_mappings and reuse data that nova provides somehow. I’ll file 
the RFE as soon as I figure out how it should work.

[1]: http://docs.openstack.org/liberty/networking-guide/adv_config_sriov.html
[2]: https://bugs.launchpad.net/neutron/+bug/1558626
[3]: https://review.openstack.org/294188

--
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.





__
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