[openstack-dev] cinder authentication with authtoken
Hi, I need a way to access cinder apis using auth-token. I used below API to get the cinder client and tried getting the availability zones. cinder_client = cc.Client(1, auth_token=self.ctxt.auth_token, project_id=self.ctxt.tenant, auth_url=self.ctxt.auth_url) cinder_client.availability_zones.list() But authentication fails with the exception: "cinderclient.exceptions.BadRequest: Expecting to find username or userId in passwordCredentials - the server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400)" It works fine when I use username and api_key instead of auth_token cinder_client = cc.Client(1, username="admin", api_key="X", project_id="admin", auth_url="http://X.X.X.X:5000/v2.0;) cinder_client.availability_zones.list() Please help me with a means of using cinder apis with auth_token. Thanks, Kanthi __ 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] Reg vxlans configuration in Neutron
Hi,
I am trying to use vxlans in Havana. I have two nodes, one acting as
controller+network node and other as compute node.
VM's launched have not got the dhcp ip.
I have compiled openvswitch from openvswitch-2.0.0 tar ball and installed
both userspace and kmod rpms.
modinfo openvswitch
filename:
/lib/modules/3.9.5-301.fc19.x86_64/kernel/extra/openvswitch/openvswitch.ko
version:2.0.0
license:GPL
description:Open vSwitch switching datapath
srcversion: 4728289FE3C06CF45730614
depends:libcrc32c,gre
vermagic: 3.9.5-301.fc19.x86_64 SMP mod_unload
My kernel version is 3.9.5-301.fc19.x86_64.
I am using ml2 plugin and here is the configuration w.r.t vxlans
ml2_conf.ini
type_drivers = vxlan
vni_ranges = 100:1000
vxlan_group = 239.10.10.1
enable_tunneling = True
local_ip = 21.21.21.11-- This is the ip of the interface which
is used as data network
tunnel_types = vxlan
ovs_neutron_plugin.ini
tunnel_id_ranges = 200:1000
Similar configuration exists on compute node as well.
Below is ovs dump on controller.
[root@cirros SOURCES]# ovs-vsctl show
2cf1fe42-1f7d-48ab-a8e6-fbe033513da2
Bridge br-tun
Port br-tun
Interface br-tun
type: internal
Port vxlan-21.21.21.11
Interface vxlan-21.21.21.11
type: vxlan
options: {in_key=flow, local_ip=21.21.21.10,
out_key=flow, remote_ip=21.21.21.11}
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Bridge br-int
Port br-int
Interface br-int
type: internal
Port tap06b8d215-3a
tag: 1
Interface tap06b8d215-3a
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
ovs_version: 2.0.0
on compute:
accd3b1f-58b7-46cf-80f9-a4e007b0c47c
Bridge br-tun
Port vxlan-21.21.21.10
Interface vxlan-21.21.21.10
type: vxlan
options: {in_key=flow, local_ip=21.21.21.11,
out_key=flow, remote_ip=21.21.21.10}
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Bridge br-int
Port br-int
Interface br-int
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port qvo11538984-b7
tag: 4095
Interface qvo11538984-b7
ovs_version: 2.0.0
I see some error/warning logs in openvswitch logs
2014-01-09T11:21:56.733Z|9|bridge|INFO|bridge br-tun: added interface
br-tun on port 65534
2014-01-09T11:21:56.733Z|00010|bridge|INFO|bridge br-tun: using datapath ID
ee4470d36449
2014-01-09T11:21:56.733Z|00011|connmgr|INFO|br-tun: added service
controller punix:/var/run/openvswitch/br-tun.mgmt
2014-01-09T11:21:56.811Z|00012|bridge|WARN|could not open network device
patch-tun (No such device)
2014-01-09T11:21:56.897Z|00013|netdev_vport|ERR|patch-tun: patch type
requires valid 'peer' argument
2014-01-09T11:21:56.897Z|00014|bridge|WARN|could not configure network
device patch-tun (Invalid argument)
2014-01-09T11:21:56.982Z|00015|bridge|INFO|bridge br-int: added interface
patch-tun on port 1
2014-01-09T11:21:57.133Z|00016|bridge|WARN|could not open network device
patch-int (No such device)
2014-01-09T11:21:57.217Z|00017|netdev_vport|ERR|patch-int: patch type
requires valid 'peer' argument
2014-01-09T11:21:57.217Z|00018|bridge|WARN|could not configure network
device patch-int (Invalid argument)
2014-01-09T11:21:57.284Z|00019|bridge|INFO|bridge br-tun: added interface
patch-int on port 1
2014-01-09T11:21:58.179Z|00020|memory|INFO|peak resident set size grew 268%
in last 10.0 seconds, from 9336 kB to 34332 kB
2014-01-09T11:21:58.179Z|00021|memory|INFO|ports:4 rules:16
2014-01-09T11:21:58.340Z|00022|bridge|WARN|could not open network device
vxlan-21.21.21.11 (No such device)
2014-01-09T11:21:58.404Z|00023|netdev_vport|ERR|vxlan-21.21.21.11: vxlan
type requires valid 'remote_ip' argument
2014-01-09T11:21:58.404Z|00024|bridge|WARN|could not configure network
device vxlan-21.21.21.11 (Invalid argument)
2014-01-09T11:21:58.488Z|00025|bridge|INFO|bridge br-tun: added interface
vxlan-21.21.21.11 on port 4
I also don't see patch-tun, patch-int or vxlan-21.21.21.10 in ifconfig.
Could you please help me resolve the issue
Regards,
Kanthi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-security] Neutron security groups for L2 networks in Havana
Hi Aaron, I missed the latest mail of this thread in my mailbox, so pasting the content of your response below. *The issue is that the nova-api says that by default every instance needs tobe in a default security group that blocks all ingress traffic from outsideand allows all ingress from instances that belong to the same securitygroup. If an instance does not have an ip address we are unable to enforcethe instance-instance communication of members that are part of the samesecurity group (or at least the iptables implementation in place doesn't).There is an extension in neutron that implements port_security that allowsone to disable this so that one can do L2 networking as you want to. Thoughunfortunately, this does not work correctly at this time with nova ascurrently it's calling into neutron to create the security group and attachit to the instance anways. See: https://bugs.launchpad.net/nova/+bug/1175464 https://bugs.launchpad.net/nova/+bug/1175464 .I'm hoping to resolve this issue in the next few weeks.* *There is an extension in neutron that implements port_security that allows* *one to disable this so that one can do L2 networking as you want to. Though* *unfortunately, this does not work correctly at this time with nova as* *currently it's calling into neutron to create the security group and attach* *it to the instance anways. See: https://bugs.launchpad.net/nova/+bug/1175464 https://bugs.launchpad.net/nova/+bug/1175464 .* *I'm hoping to resolve this issue in the next few weeks.* Thanks a lot for the information. As per my understanding of the bug description and the code diff, the fix would prevent nova from adding 'default' security group if neutron is not specifying any security group, only for the case where there are plugins that implement port_security_api and have port_security_enabled=False I have two concerns here: 1. If we don't have any such plugins, then port_security is assumed to be enabled and again default security group would be added by nova, which mandates subnet and L2 networks does not work as expected. 2. If neutron provides security group(non default) via its own api or by means of security plugins, L2 networks still fail due to the same subnet issue. You may ask why security group is needed for L2 networks as the security rules are actually converted to iptables. The reason is that the vNIC may have ipaddress at later point of time and we can add security rules based on this ip then. I am just wondering why should the subnet be mandatory for the vNIC during the instance boot time. Regards, Kanthi On Fri, Nov 8, 2013 at 11:45 AM, Kanthi P pavuluri.kan...@gmail.com wrote: Hi Aaron, Thanks for the reply ! Yes security groups are mapped to L3/L4 headers, these security rules are being converted to iptables. If we remove the subnet check, we will be able to launch instances without ipaddress, they just have the mac address. Users can configure their own ipaddress after they are booted. If we use neutron security groups, it provides a default group (on port basis) which blocks all ingress and allows all egress traffic. Later users can configure security groups based on the ip address what they provided to the vnics. I mean to say, ports will have subnet but just that this subnet is not known to openstack during the instance boot time. On Fri, Nov 8, 2013 at 9:42 AM, Aaron Rosen aro...@nicira.com wrote: On Thu, Nov 7, 2013 at 12:23 PM, Kanthi P pavuluri.kan...@gmail.comwrote: Hi, I am trying to boot a VM which has a network without subnet in Havana, but it throws an exception saying that subnet is mandatory if quantum security groups are enabled. Here are the commands I used. neutron net-create testNet neutron net-show testNet +---+--+ | Field | Value| +---+--+ | admin_state_up| True | | id| 47208beb-2801-4729-bc7b-6532717232fc | | name | testNet | | provider:network_type | local| | provider:physical_network | | | provider:segmentation_id | | | router:external | False| | shared| False| | status| ACTIVE | | subnets | | | tenant_id | b5b591dcda2645cd9d15a4fe3eb1b50d | +---+--+ nova boot --flavor 2 --image 30c1984c-8a4f-4e3f-8c9a-7de0b321caa2 --nic net-id=47208beb-2801-4729-bc7b-6532717232fc testServer1 Here is the piece of code which
Re: [openstack-dev] Reg : Security groups implementation using openflows in quantum ovs plugin
Hi All, Thanks for the response! Amir,Mike: Is your implementation being done according to ML2 plugin Regards, Kanthi On Tue, Nov 19, 2013 at 1:43 AM, Mike Wilson geekinu...@gmail.com wrote: Hi Kanthi, Just to reiterate what Kyle said, we do have an internal implementation using flows that looks very similar to security groups. Jun Park was the guy that wrote this and is looking to get it upstreamed. I think he'll be back in the office late next week. I'll point him to this thread when he's back. -Mike On Mon, Nov 18, 2013 at 3:39 PM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Nov 18, 2013, at 4:26 PM, Kanthi P pavuluri.kan...@gmail.com wrote: Hi All, We are planning to implement quantum security groups using openflows for ovs plugin instead of iptables which is the case now. Doing so we can avoid the extra linux bridge which is connected between the vnet device and the ovs bridge, which is given as a work around since ovs bridge is not compatible with iptables. We are planning to create a blueprint and work on it. Could you please share your views on this Hi Kanthi: Overall, this idea is interesting and removing those extra bridges would certainly be nice. Some people at Bluehost gave a talk at the Summit [1] in which they explained they have done something similar, you may want to reach out to them since they have code for this internally already. The OVS plugin is in feature freeze during Icehouse, and will be deprecated in favor of ML2 [2] at the end of Icehouse. I would advise you to retarget your work at ML2 when running with the OVS agent instead. The Neutron team will not accept new features into the OVS plugin anymore. Thanks, Kyle [1] http://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/towards-truly-open-and-commoditized-software-defined-networks-in-openstack [2] https://wiki.openstack.org/wiki/Neutron/ML2 Thanks, Kanthi ___ 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 ___ 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
[openstack-dev] Reg : Security groups implementation using openflows in quantum ovs plugin
Hi All, We are planning to implement quantum security groups using openflows for ovs plugin instead of iptables which is the case now. Doing so we can avoid the extra linux bridge which is connected between the vnet device and the ovs bridge, which is given as a work around since ovs bridge is not compatible with iptables. We are planning to create a blueprint and work on it. Could you please share your views on this Thanks, Kanthi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
