Re: [openstack-dev] [Ironic] - Integration with neutron using external attachment point
Hi Igor, Thanks for the pointers. Have you had a chance to look at the details of our blueprint? Are there any workflows supported by yours that we forgot? We would be happy to have you help on the reference implementation for this. Thanks, Kevin Benton On Tue, May 20, 2014 at 3:13 AM, Igor Cardoso igordc...@gmail.com wrote: Hello Kevin. There is a similar Neutron blueprint [1], originally meant for Havana but now aiming for Juno. I would be happy to join efforts with you regarding our blueprints. See also: [2]. [1] https://blueprints.launchpad.net/neutron/+spec/ml2-external-port [2] https://blueprints.launchpad.net/neutron/+spec/campus-network On 19 May 2014 23:52, Kevin Benton blak...@gmail.com wrote: Hello, I am working on an extension for neutron to allow external attachment point information to be stored and used by backend plugins/drivers to place switch ports into neutron networks[1]. One of the primary use cases is to integrate ironic with neutron. The basic workflow is that ironic will create the external attachment points when servers are initially installed. This step could either be automated (extract switch-ID and port number of LLDP message) or it could be manually performed by an admin who notes the ports a server is plugged into. Then when an instance is chosen for assignment and the neutron port needs to be created, the creation request would reference the corresponding attachment ID and neutron would configure the physical switch port to place the port on the appropriate neutron network. If this workflow won't work for Ironic, please respond to this email or leave comments on the blueprint review. 1. https://review.openstack.org/#/c/87825/ Thanks -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Igor Duarte Cardoso. http://igordcard.blogspot.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] about policy.json in unit test
Thanks for your explanation. I think the implement in nova maybe is a good reference. I have filed it to a blueprint. https://blueprints.launchpad.net/cinder/+spec/united-policy-in-cinder Ricky. From: Christopher Yeoh [mailto:cbky...@gmail.com] Sent: Monday, May 19, 2014 3:44 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Cinder] about policy.json in unit test On Mon, May 19, 2014 at 1:14 AM, Mike Perez thin...@gmail.commailto:thin...@gmail.com wrote: On 02:04 Tue 29 Apr , Bohai (ricky) wrote: Hi stackers, I found there are two policy.json files in cinder project. One is for source code(cinder/etc/policy.json), another is for the unit test(cinder/cinder/tests/policy.json). Maybe it's better to united them and make the unit test to use the policy.json file in the source code: 1. policy.json in the source code is really what we want to test but not the one in unit test. 2. It's more convenient for the developers, because of only need to modify one policy.json file. Current it's easy to miss one of them. Any advices? Seems like the right direction. Don't know why they were separate to begin with. Nova has the same issue so its probably just historical. I'm not familiar with the cinder policy files, but for Nova the default policy settings are different for the real policy file versus the one used for the unittests and the unittests rely on this. So there's likely there will need to be some cleanup required to use just one policy file and may complicate the unittests a bit more. But overall sounds like a good idea just to have one policy file. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Chalenges with highly available service VMs
arosen@arosen-MacBookPro:~/devstack$ neutron port-show
f5117013-ac04-45af-a5d6-e9110213ad6f
+---+--+
| Field | Value
|
+---+--+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:vnic_type | normal
|
| device_id | 99012a6c-a5ed-41c0-92c9-14d40af0c2df
|
| device_owner | compute:None
|
| extra_dhcp_opts |
|
| fixed_ips | {subnet_id:
505eb39c-32dc-4fe7-a497-f801a0677c54, ip_address: 10.0.0.22} |
| id| f5117013-ac04-45af-a5d6-e9110213ad6f
|
| mac_address | fa:16:3e:77:4d:2d
|
| name |
|
| network_id| 1b069199-bfa4-4efc-aebd-4a663d447964
|
| security_groups | 0d5477cf-f63a-417e-be32-a12557fa4098
|
| status| ACTIVE
|
| tenant_id | c71ebe8d1f6e47bab7d44046ec2f6b39
|
+---+--+
arosen@arosen-MacBookPro:~/devstack$ neutron port-update
f5117013-ac04-45af-a5d6-e9110213ad6f --allowed-address-pairs list=true
type=dict ip_address=10.0.0.0/24
Updated port: f5117013-ac04-45af-a5d6-e9110213ad6f
arosen@arosen-MacBookPro:~/devstack$ neutron port-show
f5117013-ac04-45af-a5d6-e9110213ad6f
+---+--+
| Field | Value
|
+---+--+
| admin_state_up| True
|
| allowed_address_pairs | {ip_address: 10.0.0.0/24, mac_address:
fa:16:3e:77:4d:2d}|
| binding:vnic_type | normal
|
| device_id | 99012a6c-a5ed-41c0-92c9-14d40af0c2df
|
| device_owner | compute:None
|
| extra_dhcp_opts |
|
| fixed_ips | {subnet_id:
505eb39c-32dc-4fe7-a497-f801a0677c54, ip_address: 10.0.0.22} |
| id| f5117013-ac04-45af-a5d6-e9110213ad6f
|
| mac_address | fa:16:3e:77:4d:2d
|
| name |
|
| network_id| 1b069199-bfa4-4efc-aebd-4a663d447964
|
| security_groups | 0d5477cf-f63a-417e-be32-a12557fa4098
|
| status| ACTIVE
|
| tenant_id | c71ebe8d1f6e47bab7d44046ec2f6b39
|
+---+--+
On Tue, May 20, 2014 at 7:52 PM, Aaron Rosen aaronoro...@gmail.com wrote:
Hi Praveen,
I think there is some confusion here. This function doesn't check if there
is any overlap that occurs within the cidr block. It only checks that the
fixed_ips+mac don't overlap with an allowed address pair. In your example
if the host has an ip_address of 10.10.1.1 and you want to allow any ip in
10.10.1.0/24 to pass through the port you can just add a rule for
10.10.1.0/24 directly without having to break it up.
Aaron
On Tue, May 20, 2014 at 11:20 AM, Praveen Yalagandula
yprav...@avinetworks.com wrote:
Hi Aaron,
The main motivation is simplicity. Consider the case where we want to
allow ip cidr 10.10.1.0/24 to be allowed on a port which has a fixed IP
of 10.10.1.1. Now if we do not want to allow overlapping, then one needs to
add 8 cidrs to get around this - (10.10.1.128/25, 10.10.1.64/26,
10.10.1.32/27, 10.10.1.0/32); which makes it cumbersome.
In any case, allowed-address-pairs is ADDING on to what is allowed
because of the fixed IPs. So, there is no possibility of conflict. The
check will probably make sense if we are maintaining denied addresses
instead of allowed addresses.
Cheers,
Praveen
On Tue, May 20, 2014 at 9:34 AM, Aaron Rosen aaronoro...@gmail.comwrote:
Hi Praveen,
I think we should fix the update_method instead to properly check for
this. I don't see any advantage to allow the fixed_ips/mac to be in the
allowed_address_pairs since they are explicitly allowed. What's your
motivation for
Re: [openstack-dev] Chalenges with highly available service VMs
Hi Praveen, I think there is some confusion here. This function doesn't check if there is any overlap that occurs within the cidr block. It only checks that the fixed_ips+mac don't overlap with an allowed address pair. In your example if the host has an ip_address of 10.10.1.1 and you want to allow any ip in 10.10.1.0/24 to pass through the port you can just add a rule for 10.10.1.0/24 directly without having to break it up. Aaron On Tue, May 20, 2014 at 11:20 AM, Praveen Yalagandula yprav...@avinetworks.com wrote: Hi Aaron, The main motivation is simplicity. Consider the case where we want to allow ip cidr 10.10.1.0/24 to be allowed on a port which has a fixed IP of 10.10.1.1. Now if we do not want to allow overlapping, then one needs to add 8 cidrs to get around this - (10.10.1.128/25, 10.10.1.64/26, 10.10.1.32/27, 10.10.1.0/32); which makes it cumbersome. In any case, allowed-address-pairs is ADDING on to what is allowed because of the fixed IPs. So, there is no possibility of conflict. The check will probably make sense if we are maintaining denied addresses instead of allowed addresses. Cheers, Praveen On Tue, May 20, 2014 at 9:34 AM, Aaron Rosen aaronoro...@gmail.comwrote: Hi Praveen, I think we should fix the update_method instead to properly check for this. I don't see any advantage to allow the fixed_ips/mac to be in the allowed_address_pairs since they are explicitly allowed. What's your motivation for changing this? Aaron On Mon, May 19, 2014 at 4:05 PM, Praveen Yalagandula yprav...@avinetworks.com wrote: Hi Aaron, Thanks for the prompt response. If the overlap does not have any negative effect, can we please just remove this check? It creates confusion as there are certain code paths where we do not perform this check. For example, the current code does NOT perform this check when we are updating the list of allowed-address-pairs -- I can successfully assign an existing fixed IP address to the allowed-address-pairs. The check is being performed on only one code path - when assigning fixed IPs. If it sounds right to you, I can submit my patch removing this check. Thanks, Praveen On Mon, May 19, 2014 at 12:32 PM, Aaron Rosen aaronoro...@gmail.comwrote: Hi, Sure, if you look at this method: def _check_fixed_ips_and_address_pairs_no_overlap(self, context, port): address_pairs = self.get_allowed_address_pairs(context, port['id']) for fixed_ip in port['fixed_ips']: for address_pair in address_pairs: if (fixed_ip['ip_address'] == address_pair['ip_address'] and port['mac_address'] == address_pair['mac_address']): raise addr_pair.AddressPairMatchesPortFixedIPAndMac() it checks that the allowed_address_pairs don't overlap with fixed_ips and mac_address on the port. The only reason we do this additional check is that having the same fixed_ip and mac_address pair as an allowed_address_pair would have no effect since the fixed_ip/mac on the port inherently allows that traffic through. Best, Aaron On Mon, May 19, 2014 at 12:22 PM, Praveen Yalagandula yprav...@avinetworks.com wrote: Hi Aaron, In OVS and ML2 plugins, on port-update, there is a check to make sure that allowed-address-pairs and fixed-ips don't overlap. Can you please explain why that is needed? - icehouse final: neutron/plugins/ml2/plugin.py 677 elif changed_fixed_ips: 678 self._check_fixed_ips_and_address_pairs_no_overlap( 679 context, updated_port) --- Thanks, Praveen On Wed, Jul 17, 2013 at 3:45 PM, Aaron Rosen aro...@nicira.comwrote: Hi Ian, For shared networks if the network is set to port_security_enabled=True then the tenant will not be able to remove port_security_enabled from their port if they are not the owner of the network. I believe this is the correct behavior we want. In addition, only admin's are able to create shared networks by default. I've created the following blueprint https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairsand doc: https://docs.google.com/document/d/1hyB3dIkRF623JlUsvtQFo9fCKLsy0gN8Jf6SWnqbWWA/edit?usp=sharingwhich will provide us a way to do this. It would be awesome if you could check it out and let me know what you think. Thanks, Aaron On Tue, Jul 16, 2013 at 10:34 AM, Ian Wells ijw.ubu...@cack.org.ukwrote: On 10 July 2013 21:14, Vishvananda Ishaya vishvana...@gmail.com wrote: It used to be essential back when we had nova-network and all tenants ended up on one network. It became less useful when tenants could create their own networks and could use them as they saw fit. It's still got its uses - for instance, it's nice that the metadata server can be sure that a request is really coming from where it claims - but I would very much like it to be possible to,
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
Hi Chris, Iam also interested in attending NFV IRC meetings. Regards, Balaji.P -Original Message- From: Chris Wright [mailto:chr...@sous-sol.org] Sent: Wednesday, May 21, 2014 4:18 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit * Stephen Wong (s3w...@midokura.com) wrote: I am part of the ServiceVM team and I will attend the NFV IRC meetings. Great, thank you Stephen. cheers, -chris ___ OpenStack-dev mailing list 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
