Re: [openstack-dev] [neutron][nova][stable][sr-iov] Status of physical_device_mappings
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 <jaypi...@gmail.com> 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/mailm
[openstack-dev] [neutron][sriov] Status of physical_device_mappings
Hey OpenStackers,
(sorry, forgot a tag:( )
I’ve recently found out, that changing of use neutron sriov-agent in Mitaka
from optional to required[1] makes a kind of regression.
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.
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.
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.
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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] [sr-iov] Status of physical_device_mappings
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.
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.
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.
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.
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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][nova] Many same "region_name" configuration really meaingful for Multi-region customers?
Hi, From my previous 3K+ nodes 6+ regions OpenStack operations experience in Yandex, I found useless to have Cinder and Neutron services in cross-region manner. BTW, nova-neutron cross-region interactions are still legitimate use case: you may utilize one neutron for many nova regions. -- With best regards, Vladimir Eremin, Fuel Deployment Engineer, Mirantis, Inc. > On Mar 4, 2016, at 7:43 AM, Dolph Mathews <dolph.math...@gmail.com> wrote: > > Unless someone on the operations side wants to speak up and defend > cross-region nova-cinder or nova-neutron interactions as being a legitimate > use case, I'd be in favor of a single region identifier. > > However, both of these configuration blocks should ultimately be used to > configure keystoneauth, so I would be in favor of whatever solution > simplifies configuration for keystoneauth. > > On Tue, Mar 1, 2016 at 10:01 PM, Kai Qiang Wu <wk...@cn.ibm.com > <mailto:wk...@cn.ibm.com>> wrote: > Hi All, > > > Right now, we found that nova.conf have many places for region_name > configuration. Check below: > > nova.conf > > *** > [cinder] > os_region_name = *** > > [neutron] > region_name= *** > > > > *** > > > From some mult-region environments observation, those two regions would > always config same value. > Question 1: Does nova support config different regions in nova.conf ? Like > below > > [cinder] > > os_region_name = RegionOne > > [neutron] > region_name= RegionTwo > > > From Keystone point, I suspect those regions can access from each other. > > > Question 2: If all need to config with same value, why we not use single > region_name in nova.conf ? (instead of create many region_name in same file ) > > Is it just for code maintenance or else consideration ? > > > > Could nova and keystone community members help this question ? > > > Thanks > > > Best Wishes, > > Kai Qiang Wu (吴开强 Kennan） > IBM China System and Technology Lab, Beijing > > E-mail: wk...@cn.ibm.com <mailto:wk...@cn.ibm.com> > Tel: 86-10-82451647 > Address: Building 28(Ring Building), ZhongGuanCun Software Park, > No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 > > Follow your heart. You are miracle! > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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 signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [FFE] FF exception request for DPDK
Hi, All patches for DPDK feature [1] are on review, new patches are not expected: * https://review.openstack.org/286611 Support for DPDK enablement on node interfaces * https://review.openstack.org/284283 Add DPDK support for node interfaces For DPDK bonding [2]: * https://review.openstack.org/287410 Added dpdkovs provider for bond For network verifications [3]: * https://review.openstack.org/287806 Network verification for DPDK enabled interfaces [1]: https://blueprints.launchpad.net/fuel/+spec/support-dpdk [2]: https://blueprints.launchpad.net/fuel/+spec/support-dpdk-bond [3]: https://blueprints.launchpad.net/fuel/+spec/network-verification-dpdk -- With best regards, Vladimir Eremin, Fuel Deployment Engineer, Mirantis, Inc. > On Mar 1, 2016, at 7:27 PM, Aleksandr Didenko <adide...@mirantis.com> wrote: > > Hi, > > I'd like to to request a feature freeze exception for "Support for DPDK for > improved networking performance" feature [0]. > > Part of this feature is already merged [1]. We have the following patches in > work / on review: > > https://review.openstack.org/281827 > https://review.openstack.org/283044 > https://review.openstack.org/286595 > https://review.openstack.org/284285 > https://review.openstack.org/284283 > https://review.openstack.org/286611 > > And we need to write new patches for the following parts of this feature: > https://blueprints.launchpad.net/fuel/+spec/network-verification-dpdk > https://blueprints.launchpad.net/fuel/+spec/support-dpdk-bond > > We need 3 weeks after FF to finish this feature. > Risk of not delivering it after 3 weeks is low. > > Regards, > Alex > > [0] https://blueprints.launchpad.net/fuel/+spec/support-dpdk > [1] > https://review.openstack.org/#/q/status:merged+branch:master+topic:bp/support-dpdk > __ > 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] [puppet] adding ovs dpdk agent into neutron
Hi MichalX, Sean, Building from sources is possible, but it will be more stable, if you will use packaging system from the OS. Also, it will be really good if your module make changes to OpenStack configuration files using puppet-nova and puppet-neutron, and it could be split for compute/agent and scheduler changes. I will really glad to see modular, reusable solution that could be integrated with our implementation in fuel-library[1]. [1]: https://review.openstack.org/#/q/topic:bp/support-dpdk+project:openstack/fuel-library,n,z -- With best regards, Vladimir Eremin, Fuel Deployment Engineer, Mirantis, Inc. > On Mar 2, 2016, at 10:48 PM, Ptacek, MichalX <michalx.pta...@intel.com> wrote: > > Thanks Emilien, > It's becoming more clear to me what has to be done. > Did I get it correctly that using bash code inside puppet module is "nish > nish" and will NOT be accepted by the community ? > (even if we move the logic into own module like openstack/ovs-dpdk) > Additionally building from the src or using own packages from such builds is > also not possible in such modules even despite its performance or other > functional benefits ? > > best regards, > Michal > > -Original Message- > From: Emilien Macchi [mailto:emil...@redhat.com] > Sent: Wednesday, March 02, 2016 6:51 PM > To: Ptacek, MichalX <michalx.pta...@intel.com>; 'OpenStack Development > Mailing List (not for usage questions)' <openstack-dev@lists.openstack.org>; > m...@mattfischer.com > Cc: Mooney, Sean K <sean.k.moo...@intel.com>; Czesnowicz, Przemyslaw > <przemyslaw.czesnow...@intel.com> > Subject: Re: [openstack-dev] [puppet] adding ovs dpdk agent into neutron > > > > On 03/02/2016 03:07 AM, Ptacek, MichalX wrote: >> Hi all, >> >> >> >> we have puppet module for ovs deployments with dpdk support >> >> https://github.com/openstack/networking-ovs-dpdk/tree/master/puppet > > IMHO that's a bad idea to use networking-ovs-dpdk for the puppet module. > You should initiate the work to create openstack/puppet-dpdk (not sure about > the name) or try to patch openstack/puppet-vswitch. > > How puppet-vswitch would be different from puppet-dpdk? > > I've looked at the code and you run bash scripts from Puppet. > Really ? :-) > >> and we would like to adapt it in a way that it can be used within >> upstream neutron module >> >> e.g. to introduce class like this >> >> neutron::agents::ml2::ovsdpdk >> >> >> >> Current code works as follows: >> >> - Openstack with installed vanilla ovs is a kind of precondition >> >> - Ovsdpdk puppet module installation is triggered afterwards >> and it replace vanilla ovs by ovsdpdk >> >> (in order to have some flexibility and mostly due to performance >> reasons we are building ovs from src code) >> >> https://github.com/openstack/networking-ovs-dpdk/blob/master/puppet/ov >> sdpdk/files/build_ovs_dpdk.erb >> >> - As a part of deployments we have several shell scripts, which >> are taking care of build and configuration stuff >> >> >> >> I assume that some parts of our code can be easily rewritten to start >> using standard providers other parts might be rewritten to ruby … >> >> We would like to introduce neutron::agents::ml2::ovsdpdk as adequate >> solution with existing neutron::agents::ml2::ovs and not just patching it. >> > > What Puppet OpenStack group will let neutron::agents::ml2::ovsdpdk doing: > > * configure what you like in /etc/neutron/* > * install what you want that is part of OpenStack/Neutron* (upstream). > > What Puppet OpenStack group WILL NOT let neutron::agents::ml2::ovsdpdk > doing: > > * install third party software (packages from some custom repositories, not > upstream). > * build RPM/DEB from bash scripts > * build anything from bash scripts > * configure anything outside /etc/neutron/* > >> >> Actually I have following questions: >> >> Q1) Will it be acceptable if we move build logic before deployment and >> resulting rpm/deb will be installed instead of ovs package during >> deployment ? > > You should engage efforts to have upstream packaging in Ubuntu/Debian and Red > Hat systems (RDO). > >> Q2) Do we need to rewrite bash logic into ruby code ? > > Drop bash scripts, and use upstream packages, like we do everywhere else. > >> Q3) Do we need to raise separate blueprint, which has to be approved >> before starting adaptations ? > > Feel free to submit a blueprint so our group can be invo
Re: [openstack-dev] Configuring ISC dhclient on guest to acquire ipv6 default gateway
Hi Andrei, You’re seeing default route as a link-local address of router just because the routing things is working this way in IPv6 in general, not in OpenStack. gateway_ip is actually set on router interface, and could be reachable, and actually valid choice for routing, but there is no way (and it makes no sense) to automatically configure router’s GUA as a default gateway address. -- With best regards, Vladimir Eremin, Fuel Deployment Engineer, Mirantis, Inc. > On Dec 28, 2015, at 6:35 PM, Andrei Radulescu-Banu > <andrei.radulescu-b...@exfo.com> wrote: > > Thanks for your help, Vladimir. You are right, now that I look more closely, > in dhcpv6-stateful mode the default gateway is acquired through router > advertisement (instead of dhcp6 options). And the default gateway I get is > the link-local address instead of the configured gateway_ip of 1:2:3:4::1. > > This was confusing, to say the least - and not well explained anywhere - but > it is working. I've tested all three modes of configuration > (ipv6_address_mode and ipv6_ra_mode both simultaneously set to > dhcpv6-stateful, dhcpv6-stateless or slaac). In all cases I am acquiring a > default gateway - and it is the link local address of the default gateway. I > can tell it works because the default gateway is pingable through the > interface, and the low 3 bytes of the default gateway ip6 address matches the > low 3 bytes of the gateway MAC address. (The MAC address is viewable when > reviewing the router interfaces through the Horizon UI, for example - the > actual link local ip6 addresses of the default gateway are not displayed). > > Best, > Andrei > > > -- > > Message: 2 > Date: Fri, 25 Dec 2015 19:07:31 +0300 > From: Vladimir Eremin <vere...@mirantis.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] Configuring ISC dhclient on guest to > acquire ipv6 default gateway > Message-ID: <5864af60-644c-438e-9d82-80c4fced1...@mirantis.com> > Content-Type: text/plain; charset=utf-8 > > Hi Andrei, > > Default gateways for IPv6 is always configured with Router Advertisements > (RA), no matter what addressing mode is used. Please ensure that: > > - you have a virtual router connected to your IPv6 subnet, this would provide > RA (and actual router) in your network > - accept_ra is enabled in your guest OS: sysctl -a | grep accept_ra > > -- > 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
Re: [openstack-dev] Configuring ISC dhclient on guest to acquire ipv6 default gateway
Hi Andrei,
Default gateways for IPv6 is always configured with Router Advertisements (RA),
no matter what addressing mode is used. Please ensure that:
- you have a virtual router connected to your IPv6 subnet, this would provide
RA (and actual router) in your network
- accept_ra is enabled in your guest OS: sysctl -a | grep accept_ra
--
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.
> On Dec 23, 2015, at 12:50 AM, Andrei Radulescu-Banu
> <andrei.radulescu-b...@exfo.com> wrote:
>
> Hi all,
>
> I’ve been trying for a few days to understand how this should work. My guest
> OS is Linux based, using ISC dhclient. In devstack I have configured an ipv6
> net and subnet:
>
> [stack@localhost images]$ neutron net-show private6
> +---+--+
> | Field | Value|
> +---+--+
> | admin_state_up| True |
> | availability_zone_hints | |
> | availability_zones| nova |
> | id| 55170162-305e-4d04-a159-2a141f0cd685 |
> | mtu | 0|
> | name | private6 |
> | port_security_enabled | True |
> | provider:network_type | vxlan|
> | provider:physical_network | |
> | provider:segmentation_id | 1063 |
> | router:external | False|
> | shared| False|
> | status| ACTIVE |
> | subnets | 4ea435ac-0ede-4dbc-9096-d97c256cc4d5 |
> | tenant_id | 9ede0af4cbe94caf8222b1dcfaac0754 |
> +---+--+
>
> [stack@localhost images]$ neutron subnet-show private-subnet6
> +---+--+
> | Field | Value|
> +---+--+
> | allocation_pools | {"start": "1:2:3:4::100", "end": "1:2:3:4::200"} |
> | cidr | 1:2:3:4::/64 |
> | dns_nameservers | 1:2:3:4::2 |
> | enable_dhcp | True |
> | gateway_ip| 1:2:3:4::1 |
> | host_routes | |
> | id| 4ea435ac-0ede-4dbc-9096-d97c256cc4d5 |
> | ip_version| 6|
> | ipv6_address_mode | dhcpv6-stateful |
> | ipv6_ra_mode | dhcpv6-stateful |
> | name | private-subnet6 |
> | network_id| 55170162-305e-4d04-a159-2a141f0cd685 |
> | subnetpool_id | |
> | tenant_id | 9ede0af4cbe94caf8222b1dcfaac0754 |
> +---+--+
>
> When running dhclient on the interface, however, I am only able to acquire
> the interface address, but not the interface default gateway. I suppose the
> default gateway should be obtained through dhcp6 rather than neighbor
> discovery, because I set both ipv6_address_mode and ipv6_ra_mode to
> dhcpv6-stateful.
>
> Any ideas?
>
> Thanks,
> Andrei
> __
> 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] [IPv6] [radvd] Advertise tenant prefixes from router to outside
Hi Carl, As far as I understand Address Scopes, end user’s algorithm will be next: 1. Administrator creates an address scope and associate an IPv6 subnet pool with it. 2. Administrator creates Public shared network’s subnet from this subnet pool. 3. Tenant user creates tenant network from this subnet pool and connect it to Public shared network with router 4. OpenStack advertises prefix to the external interface of the router. -- With best regards, Vladimir Eremin, Fuel Deployment Engineer, Mirantis, Inc. > On Dec 17, 2015, at 8:21 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: > > On Thu, Dec 17, 2015 at 4:09 PM, Vladimir Eremin <vere...@mirantis.com> wrote: >> Hi Carl, >> >> I’ll fil RFE for sure, thank you for the link to the process ) >> >> So actually, we should announce all SUBNETS we’ve attached to router. >> Otherwise is will not work, because external network router will have no >> idea, where the traffic should be routed back. It is an actual viability >> discriminator: subnets, that doesn’t attached are counting as unviable to >> the external network context. > > The subnets attached to the router which are not controlled by a > subnet pool come straight from the user and there is no validation of > the addresses used, no overlap prevention, nor any other kind of > control. We can't leave it up to tenants to advertise whatever > subnets they want to to the external network. The advertisements must > be limited to subnets allocated to the tenant by the operator of the > cloud with some mechanism for preventing overlap of addresses between > subnets. > > A subnet that has an address scope was allocated from a pool defined > under that scope. We know where the address came from and that it > will not overlap any other subnet in the same scope. > > For subnets that don't meet this criteria, their traffic should not > even be routed out to the external network in the first place let > alone get a route back to the router. The address pools blueprint > covers this too. > >> BTW, could you please point me to the spec for address scopes. > > Sure: https://blueprints.launchpad.net/neutron/+spec/address-scopes > > Carl > > __ > 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] [IPv6] [radvd] Advertise tenant prefixes from router to outside
Hi
For now, when end user is creating IPv6-enabled tenant network and attaching it
to the virtual router, there is only way to set up external infrastructure to
put traffic back to the router is using DHCPv6 PD[1], unfortunately, it’s not
working at all[2]. Other methods like implementing BGP is still in development.
BTW, in IPv6 Router Advertisements we have an option called Route Information
Option, RA-RIO[3] to advertise more specific routes from gateway. We could
easily append a section like next one to advertise tenant prefix
2001:db8:1::/64 to public network. And if provider network router outside
OpenStack will be configured to accept these.
interface qg- {
AdvDefaultLifetime 0;
route 2001:db8:1::/64 {
};
};
Cisco accepts it by default AFAIK, linux needs a sysctl
net.ipv6.conf.*.accept_ra_rt_info_max_plen set to 64.
Moreover, enabling receiving RA-RIO prefixes in router namespaces allows
routers communicate by themselves.
I’ve done PoC patch for it https://gist.github.com/yottatsa/8282e670da16934960b3
[1]:
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/ipv6-prefix-delegation.html
[2]: https://bugs.launchpad.net/neutron/+bug/1505316
[3]: https://tools.ietf.org/html/rfc4191
--
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
Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside
Hi Carl,
I’ll fil RFE for sure, thank you for the link to the process )
So actually, we should announce all SUBNETS we’ve attached to router. Otherwise
is will not work, because external network router will have no idea, where the
traffic should be routed back. It is an actual viability discriminator:
subnets, that doesn’t attached are counting as unviable to the external network
context.
BTW, could you please point me to the spec for address scopes.
--
With best regards,
Vladimir Eremin,
Fuel Deployment Engineer,
Mirantis, Inc.
> On Dec 17, 2015, at 1:13 PM, Carl Baldwin <c...@ecbaldwin.net> wrote:
>
> On Thu, Dec 17, 2015 at 1:30 PM, Vladimir Eremin <vere...@mirantis.com> wrote:
>> Hi
>>
>> For now, when end user is creating IPv6-enabled tenant network and attaching
>> it to the virtual router, there is only way to set up external
>> infrastructure to put traffic back to the router is using DHCPv6 PD[1],
>> unfortunately, it’s not working at all[2]. Other methods like implementing
>> BGP is still in development.
>>
>> BTW, in IPv6 Router Advertisements we have an option called Route
>> Information Option, RA-RIO[3] to advertise more specific routes from
>> gateway. We could easily append a section like next one to advertise tenant
>> prefix 2001:db8:1::/64 to public network. And if provider network router
>> outside OpenStack will be configured to accept these.
>>
>> interface qg- {
>>AdvDefaultLifetime 0;
>>route 2001:db8:1::/64 {
>>};
>> };
>>
>> Cisco accepts it by default AFAIK, linux needs a sysctl
>> net.ipv6.conf.*.accept_ra_rt_info_max_plen set to 64.
>>
>> Moreover, enabling receiving RA-RIO prefixes in router namespaces allows
>> routers communicate by themselves.
>>
>> I’ve done PoC patch for it
>> https://gist.github.com/yottatsa/8282e670da16934960b3
>
> This is an interesting idea. I've wondered if we could do something
> like this before but I didn't know all the details around RA-RIO. The
> problem is that, in general, we have no idea if the subnets behind the
> routers are viable in the external network context. So, we can't just
> blindly have routers advertising whatever.
>
> In Mitaka, we're merging a new feature called "address scopes". We
> could limit advertising to only subnets that come from the address
> scope matching that of the external network. If we do this then we'll
> know that the subnet came from a pool of addresses that are valid in
> the external network context and that the addresses are unique.
>
> This could be relatively easy to implement on top of the current
> address scopes work. I think this is worth exploring with an RFE.
> Would you mind filing an RFE according to the Neutron process [1]?
>
> Carl
>
> [1]
> http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [fuel] Advanced PXE provisioning notes
Forgot about tags, sorry. -- With best regards, Vladimir Eremin, Fuel Deployment Engineer, Mirantis, Inc. > On Nov 13, 2015, at 5:13 PM, Vladimir Eremin <vere...@mirantis.com> wrote: > > Hi folks, > > As you know, to speed up provisioning stage we could use HTTP for downloading > kernel and initramfs. There are 3 options to do this: lpxelinux, iPXE (which > is successor/fork of gPXE) and GRUB 2, which we were assessed during my work > in Yandex and I’d like to share some experience. > > In this note I leave UEFI/iPXE embedding for IPv6 out of scope. Yandex has > chosen with iPXE embedding mostly because it’s well-known already and there > was less problem to embed iPXE to custom-build hardware than mess with UEFI. > > lpxelinux is a HTTP/FTP enabled variant of usual pxelinux (since syslinux > 5.10), so it’s required no chainloading (so no mess with DHCP-server) and no > boot config re-design. To provide HTTP URI instead of TFTP, two variants may > be used: > > * replace entries in boot config like LINUX from relative path like > boot/mykernel to absolute URL like http://boot-server/boot/mykernel > * provide pxelinux.pathprefix DHCP option [1] contains URL prefix like > http://boot-server/ > > This is most convenient variant to speed up pxelinux setup. Unfortunately, > lpxelinux hasn't built for Ubuntu Trusty, so it should be rebuilt from Debian > Sid. > > > iPXE is advanced boot loader with many features like IPv6, HTTP and scripting > language. Actually, it allows to pass hardware-related information to > provisioning server. > > Boot script should be compiled into iPXE, or you will need to set up your > DHCP-server [2] to serve different options for different loaders. This option > will require to re-write provisioning logic. > It also support UEFI, so it could be used for IPv6 provisioning. > > I recommend this variant for advanced IPv6 + HTTP provisioning. > > > GRUB2 is most advanced option. Unfortunately, it’s still has a bug with IPv6 > [3], so there is no point to overcomplicate the setup. > > > Note that UNDI API is provided correctly by most of modern NIC’s. However, > some cards like Mellanox ConnectX and weird Intels is not working correctly. > To fix it, iPXE could be built with vendor-specific driver [4]. There is no > workaround for lpxelinux. > > [1] http://www.syslinux.org/wiki/index.php/PXELINUX#DHCP_options > [2] http://ipxe.org/howto/chainloading > [3] https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229458 > [4] http://ipxe.org/appnote/hardware_drivers > > -- > 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
Re: [openstack-dev] [fuel] Advanced PXE provisioning notes
Hi Sean, Yes, iPXE could be one-to-rule-them-all replacement, because of HTTP, IPv6 and UEFI support. lpxelinux is good, but for one-line enhancements. -- With best regards, Vladimir Eremin, Fuel Deployment Engineer, Mirantis, Inc. > On Nov 13, 2015, at 6:17 PM, Sean Collins <scoll...@mirantis.com> wrote: > > Excellent info, thanks. > > Do you think long term iPXE is the way to go? IPv6 support would be a big > motivation - but it sounds like it would take some work to accomplish. > > On Fri, Nov 13, 2015 at 10:02 AM, Vladimir Eremin <vere...@mirantis.com > <mailto:vere...@mirantis.com>> wrote: > Forgot about tags, sorry. > > -- > With best regards, > Vladimir Eremin, > Fuel Deployment Engineer, > Mirantis, Inc. > > > > > On Nov 13, 2015, at 5:13 PM, Vladimir Eremin <vere...@mirantis.com > > <mailto:vere...@mirantis.com>> wrote: > > > > Hi folks, > > > > As you know, to speed up provisioning stage we could use HTTP for > > downloading kernel and initramfs. There are 3 options to do this: > > lpxelinux, iPXE (which is successor/fork of gPXE) and GRUB 2, which we were > > assessed during my work in Yandex and I’d like to share some experience. > > > > In this note I leave UEFI/iPXE embedding for IPv6 out of scope. Yandex has > > chosen with iPXE embedding mostly because it’s well-known already and there > > was less problem to embed iPXE to custom-build hardware than mess with UEFI. > > > > lpxelinux is a HTTP/FTP enabled variant of usual pxelinux (since syslinux > > 5.10), so it’s required no chainloading (so no mess with DHCP-server) and > > no boot config re-design. To provide HTTP URI instead of TFTP, two variants > > may be used: > > > > * replace entries in boot config like LINUX from relative path like > > boot/mykernel to absolute URL like http://boot-server/boot/mykernel > > <http://boot-server/boot/mykernel> > > * provide pxelinux.pathprefix DHCP option [1] contains URL prefix like > > http://boot-server/ <http://boot-server/> > > > > This is most convenient variant to speed up pxelinux setup. Unfortunately, > > lpxelinux hasn't built for Ubuntu Trusty, so it should be rebuilt from > > Debian Sid. > > > > > > iPXE is advanced boot loader with many features like IPv6, HTTP and > > scripting language. Actually, it allows to pass hardware-related > > information to provisioning server. > > > > Boot script should be compiled into iPXE, or you will need to set up your > > DHCP-server [2] to serve different options for different loaders. This > > option will require to re-write provisioning logic. > > It also support UEFI, so it could be used for IPv6 provisioning. > > > > I recommend this variant for advanced IPv6 + HTTP provisioning. > > > > > > GRUB2 is most advanced option. Unfortunately, it’s still has a bug with > > IPv6 [3], so there is no point to overcomplicate the setup. > > > > > > Note that UNDI API is provided correctly by most of modern NIC’s. However, > > some cards like Mellanox ConnectX and weird Intels is not working > > correctly. To fix it, iPXE could be built with vendor-specific driver [4]. > > There is no workaround for lpxelinux. > > > > [1] http://www.syslinux.org/wiki/index.php/PXELINUX#DHCP_options > > <http://www.syslinux.org/wiki/index.php/PXELINUX#DHCP_options> > > [2] http://ipxe.org/howto/chainloading <http://ipxe.org/howto/chainloading> > > [3] https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229458 > > <https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229458> > > [4] http://ipxe.org/appnote/hardware_drivers > > <http://ipxe.org/appnote/hardware_drivers> > > > > -- > > 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-dev] Advanced PXE provisioning notes
Hi folks, As you know, to speed up provisioning stage we could use HTTP for downloading kernel and initramfs. There are 3 options to do this: lpxelinux, iPXE (which is successor/fork of gPXE) and GRUB 2, which we were assessed during my work in Yandex and I’d like to share some experience. In this note I leave UEFI/iPXE embedding for IPv6 out of scope. Yandex has chosen with iPXE embedding mostly because it’s well-known already and there was less problem to embed iPXE to custom-build hardware than mess with UEFI. lpxelinux is a HTTP/FTP enabled variant of usual pxelinux (since syslinux 5.10), so it’s required no chainloading (so no mess with DHCP-server) and no boot config re-design. To provide HTTP URI instead of TFTP, two variants may be used: * replace entries in boot config like LINUX from relative path like boot/mykernel to absolute URL like http://boot-server/boot/mykernel * provide pxelinux.pathprefix DHCP option [1] contains URL prefix like http://boot-server/ This is most convenient variant to speed up pxelinux setup. Unfortunately, lpxelinux hasn't built for Ubuntu Trusty, so it should be rebuilt from Debian Sid. iPXE is advanced boot loader with many features like IPv6, HTTP and scripting language. Actually, it allows to pass hardware-related information to provisioning server. Boot script should be compiled into iPXE, or you will need to set up your DHCP-server [2] to serve different options for different loaders. This option will require to re-write provisioning logic. It also support UEFI, so it could be used for IPv6 provisioning. I recommend this variant for advanced IPv6 + HTTP provisioning. GRUB2 is most advanced option. Unfortunately, it’s still has a bug with IPv6 [3], so there is no point to overcomplicate the setup. Note that UNDI API is provided correctly by most of modern NIC’s. However, some cards like Mellanox ConnectX and weird Intels is not working correctly. To fix it, iPXE could be built with vendor-specific driver [4]. There is no workaround for lpxelinux. [1] http://www.syslinux.org/wiki/index.php/PXELINUX#DHCP_options [2] http://ipxe.org/howto/chainloading [3] https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229458 [4] http://ipxe.org/appnote/hardware_drivers -- 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
