[openstack-dev] [tacker] PTL candidacy from yong sheng gong

[Yongsheng Gong]

This is my self-nomination to continue running as Tacker PTL for the
Rocky cycle.

Lots happened in Takcer Queens cycle. More documents, More features are coming
in. VNFFG is enhanced, Kubernetes vim and container VNF are introduced.
Private Zabbix based application monitoring is done too. Openstack client Tacker
commands are also being developed.


In Rocky cycle, I plan to

- Continue to stablize tacker and make it of production quality.
- Go on with tacker document.
- Enhance container based VNF
- Make a way to connect VM based VNF and container Based VNF
- Introduce more types of VIM, such as public vim, SDN controller vim


Thanks for your consideration.

Yong sheng gong










__
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] [requirements][release] FFE for constraints update for python-tackerclient bug-fix release

[Yongsheng Gong]

Hi,

The tacker client has na initial queens release which does not have right reno 
notes. Recently I have added some reno patches.
And also the team wants a feature  to land in the queens release.

I have requested the newer release at https://review.openstack.org/#/c/541638/ 


The new feature is at https://review.openstack.org/#/c/541631/ 


Please see how we can get it released?

Thanks


Yong sheng gong
Tacker

__
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] Route cannot be deleted

[Yongsheng Gong]

try to check if there are floatingips on the VMs on that subnet
962b8364-a2b4-46cc-95be-28cbab62b8c2


On Tue, Aug 5, 2014 at 3:24 PM, Sayali Lunkad sayali.92...@gmail.com
wrote:

 Hi,

 The issue was resolved by following the commands below.

 neutron port-update port-id --device_owner clear
 neutron port-delete port-id
 neutron router-delete router-id

 Thanks,
 Sayali.




 On Sat, Aug 2, 2014 at 3:49 PM, Sayali Lunkad sayali.92...@gmail.com
 wrote:

 Hi Zzelle,

 Thanks for the prompt response.
 As you mentioned I cleared all the routes using

 *neutron router-update 2f16d846-b6aa-43a3-adbe-7f91a1389b7f --routes
 action=clear *
 So to see the router status I run this:













 * neutron router-show 2f16d846-b6aa-43a3-adbe-7f91a1389b7f
 +---+--+|
 Field | Value
 |+---+--+ |
 admin_state_up| True ||
 external_gateway_info |  ||
 id| 2f16d846-b6aa-43a3-adbe-7f91a1389b7f ||
 name  | router0  | |
 routes|  ||
 status| ACTIVE   ||
 tenant_id | 315561c9a19e4794ac4f4364c842254f
 |+---+--+ *
 After that I try to unbind the subnet using the command below but the
 same problem persists.


 *neutron router-interface-delete* 2f16d846-b6aa-43a3-adbe-7f91a1389b7f
 962b8364-a2b4-46cc-95be-28cbab62b8c2
 409-{u'NeutronError': {u'message': u'Router interface for subnet
 962b8364-a2b4-46cc-95be-28cbab62b8c2 on router
 2f16d846-b6aa-43a3-adbe-7f91a1389b7f cannot be deleted, as it is required
 by one or more routes.', u'type': u'RouterInterfaceInUseByRoute',
 u'detail': u''}}

 I am confused at this point as all the routes have been cleared but still
 it is throwing an error saying the router is required by multiple routes.

 Thanks,
 Sayali.


 On Sat, Aug 2, 2014 at 3:25 PM, ZZelle zze...@gmail.com wrote:

 First command is of course:
 *   neutron router-show **2f16d846-b6aa-43a3-adbe-*
 *7f91a1389b7f *
 not
 *   neutron router-update **2f16d846-b6aa-43a3-adbe-**7f91a1389b7f*


 On Sat, Aug 2, 2014 at 11:54 AM, ZZelle zze...@gmail.com wrote:

 Hi,

 According to the first error message, the subnet you try to unbind is
 used in router routes, you can see current router routes using:

*neutron router-update **2f16d846-b6aa-43a3-adbe-**7f91a1389b7f*

 you need to update them before unbind:

 *   neutron router-update **2f16d846-b6aa-43a3-adbe-*
 *7f91a1389b7f --routes type=dict list=true destination=...,nexthop=...
 [destination=...,nexthop=...[...]] *
 or clear router routes:



 *   neutron router-update 2f16d846-b6aa-43a3-adbe-7f91a1389b7f --routes
 action=clear *
 And finally retry to unbind the subnet.



 Cédric,
 ZZelle@IRC


 On Sat, Aug 2, 2014 at 9:56 AM, Sayali Lunkad sayali.92...@gmail.com
 wrote:

 Hi,

 I am facing trouble deleting a router from my openstack deployment.

 I have tried the following commands on the *controller node* and
 pasted the output.

 *neutron router-interface-delete*
 2f16d846-b6aa-43a3-adbe-7f91a1389b7f  962b8364-a2b4-46cc-95be-28cbab62b8c2
 409-{u'NeutronError': {u'message': u'Router interface for subnet
 962b8364-a2b4-46cc-95be-28cbab62b8c2 on router
 2f16d846-b6aa-43a3-adbe-7f91a1389b7f cannot be deleted, as it is required
 by one or more routes.', u'type': u'RouterInterfaceInUseByRoute',
 u'detail': u''}}

  *neutron port-delete*  ec1aac66-481d-488e-860b-53b88d950ac7
 409-{u'NeutronError': {u'message': u'Port
 ec1aac66-481d-488e-860b-53b88d950ac7 has owner network:router_interface 
 and
 therefore cannot be deleted directly via the port API.', u'type':
 u'L3PortInUse', u'detail': u''}}

  *neutron router-delete* 2f16d846-b6aa-43a3-adbe-7f91a1389b7f
 409-{u'NeutronError': {u'message': u'Router
 2f16d846-b6aa-43a3-adbe-7f91a1389b7f still has active ports', u'type':
 u'RouterInUse', u'detail': u''}}

 *neutron l3-agent-router-remove* 7a977e23-767f-418e-8429-651c4232548c
 2f16d846-b6aa-43a3-adbe-7f91a1389b7f
 This removes the router from the l3 agent and attaches it to another
 one as seen below.

  *neutron l3-agent-list-hosting-router*
 2f16d846-b6aa-43a3-adbe-7f91a1389b7f

 +--+--++---+
 | id   | host |
 admin_state_up | alive |

 +--+--++---+
 | 96e1371a-be03-42ed-8141-3b0027d3a82f | alln01-1-csx-net-004 |
 True   | :-)   |

 +--+--++---+


 I have also run the commands below on the *network node* which worked
 fine.

 *ip netns delete* 

[openstack-dev] is tenant-id in network API?

[Yongsheng Gong]

Hi,
Today, I found the ​{tenant_id} is written in neutron API URLs at
http://developer.openstack.org/api-ref-networking-v2.html.

But when I tried to access it accordingly, it failed.

I don't think we have tenant_id in network API URL.


any Idea?

regards,
yong sheng gong
UnitedStack Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron]One security issue about floating ip

[Yongsheng Gong]

I have reported it on neutron project
https://bugs.launchpad.net/neutron/+bug/1334926


On Fri, Jun 27, 2014 at 5:07 AM, Vishvananda Ishaya vishvana...@gmail.com
wrote:

 I missed that going in, but it appears that clean_conntrack is not done on
 disassociate, just during migration. It sounds like we should remove the
 explicit call in migrate, and just always call it from remove_floating_ip.

 Vish

 On Jun 26, 2014, at 1:48 PM, Brian Haley brian.ha...@hp.com wrote:

  Signed PGP part
  I believe nova-network does this by using 'conntrack -D -r $fixed_ip'
 when the
  floating IP goes away (search for clean_conntrack), Neutron doesn't when
 it
  removes the floating IP.  Seems like it's possible to close most of that
 gap
  in the l3-agent - when it removes the IP from it's qg- interface it can
 do a
  similar operation.
 
  -Brian
 
  On 06/26/2014 03:36 PM, Vishvananda Ishaya wrote:
   I believe this will affect nova-network as well. We probably should use
   something like the linux cutter utility to kill any ongoing connections
   after we remove the nat rule.
  
   Vish
  
   On Jun 25, 2014, at 8:18 PM, Xurong Yang ido...@gmail.com wrote:
  
   Hi folks,
  
   After we create an SSH connection to a VM via its floating ip, even
   though we have removed the floating ip association, we can still
 access
   the VM via that connection. Namely, SSH is not disconnected when the
   floating ip is not valid. Any good solution about this security issue?
  
   Thanks Xurong Yang ___
   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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] DVR SNAT shortcut

[Yongsheng Gong]

Hi,
for each compute node to have SNAT to Internet, I think we have the
drawbacks:
1. SNAT is done in router, so each router will have to consume one public
IP on each compute node, which is money.
2. for each compute node to go out to Internet, the compute node will have
one more NIC, which connect to physical switch, which is money too

So personally, I like the design:
 floating IPs and 1:N SNAT still use current network nodes, which will have
HA solution enabled and we can have many l3 agents to host routers. but
normal east/west traffic across compute nodes can use DVR.

yong sheng gong


On Wed, Jun 25, 2014 at 4:30 PM, Zang MingJie zealot0...@gmail.com wrote:

 Hi:

 In current DVR design, SNAT is north/south direction, but packets have
 to go west/east through the network node. If every compute node is
 assigned a public ip, is it technically able to improve SNAT packets
 w/o going through the network node ?

 SNAT versus floating ips, can save tons of public ips, in trade of
 introducing a single failure point, and limiting the bandwidth of the
 network node. If the SNAT performance problem can be solved, I'll
 encourage people to use SNAT over floating ips. unless the VM is
 serving a public service

 --
 Zang MingJie

 ___
 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

Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

[Yongsheng Gong]

I think maybe we can device a kind of framework so that we can plugin
different BGP speakers.


On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi yamam...@valinux.co.jp
wrote:

 hi,

  ExaBgp was our first choice because we thought that run something in
  library mode would be much more easy to deal with (especially the
  exceptions and corner cases) and the code would be much cleaner. But
 seems
  that Ryu BGP also can fit in this requirement. And having the help from a
  Ryu developer like you turns it into a promising candidate!
 
  I'll start working now in a proof of concept to run the agent with these
  implementations and see if we need more requirements to compare between
 the
  speakers.

 we (ryu team) love to hear any suggestions and/or requests.
 we are currently working on our bgp api refinement and documentation.
 hopefully they will be available early next week.

 for both of bgp blueprints, it would be possible, and might be desirable,
 to create reference implementations in python using ryu or exabgp.
 (i prefer ryu. :-)

 YAMAMOTO Takashi

 ___
 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

Re: [openstack-dev] [neutron] Service VMs

[Yongsheng Gong]

+1 for its own project for service VM.


On Tue, Apr 22, 2014 at 9:41 AM, Kyle Mestery mest...@noironetworks.comwrote:

 On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann
 doug.hellm...@dreamhost.com wrote:
  On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery mest...@noironetworks.com
 wrote:
  For the upcoming Summit there are 3 sessions filed around Service
  VMs in Neutron. After discussing this with a few different people,
  I'd like to propose the idea that the Service VM work be moved out
  of Neutron and into it's own project on stackforge. There are a few
  reasons for this:
 
  How long do you anticipate the project needing to live on stackforge
  before it can move to a place where we can introduce symmetric gating
  with the projects that use it?
 
 The patches for this (look at the BP here [1]) have been in review for
 a while now as WIP. I think it's reasonable to expect that moving this
 to stackforge would let the authors and others interested collaborate
 faster. I expect this would take a cycle on stackforge before we could
 talk about other projects using this. But honestly, that's a better
 question for Isaku and Bob.

  Who is going to drive the development work?
 
 For that, I'm thinking Isaku and Bob (copied above) would be the ones
 driving it. But anyone else who is interested should feel free to jump
 in as well.

 Thanks,
 Kyle

 [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms

  Doug
 
 
  1. There is nothing Neutron specific about service VMs.
  2. Service VMs can perform services for other OpenStack projects.
  3. The code is quite large and may be better served being inside it's
  own project.
 
  Moving the work out of Neutron and into it's own project would allow
  for separate velocity for this project, and for code to be shared for
  the Service VM work for things other than Neutron services.
 
  I'm starting this email thread now to get people's feedback on this
  and see what comments other have. I've specifically copied Isaku and
  Bob, who both filed summit sessions on this and have done a lot of
  work in this area to date.
 
  Thanks,
  Kyle
 
  ___
  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

Re: [openstack-dev] Neutron error using devstack

[Yongsheng Gong]

you need to give the neutron command the login certificate (user name,
password, tenant etc) to work.

for example:
export OS_USERNAME=admin
export OS_PASSWORD=password
export OS_TENANT_NAME=admin
export OS_AUTH_URL=http://localhost:5000/v2.0



On Sun, Mar 2, 2014 at 2:05 AM, abhishek jain ashujain9...@gmail.comwrote:

 Hi all

 I have installed devstack successfully from the following link...


 http://www.linux.com/learn/tutorials/721712-intro-to-openstack-part-two-how-to-install-and-configure-openstack-on-a-server

 However I'm not able to run the neutron services.The error which generally
 comes after running neutron command is as follows.

 neutron subnet-create vxlan-net 10.100.1.0/24 --name vxlan-net

 You must provide a username via either --os-username or env[OS_USERNAME]

 ashu@ashu $ ps -ef | grep neutron
 ashu31039 30660  0 18:09 pts/25   00:00:00 grep --color=auto neutron

 Please help regarding this

 ___
 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

Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified

[Yongsheng Gong]

It is not easy to enhance it. If we check the tenant_id on creation, if
should we  also to do some job when keystone delete tenant?


On Mon, Feb 17, 2014 at 6:41 AM, Dolph Mathews dolph.math...@gmail.comwrote:

 keystoneclient.middlware.auth_token passes a project ID (and name, for
 convenience) to the underlying application through the WSGI environment,
 and already ensures that this value can not be manipulated by the end user.

 Project ID's (redundantly) passed through other means, such as URLs, are
 up to the service to independently verify against keystone (or
 equivalently, against the WSGI environment), but can be directly
 manipulated by the end user if no checks are in place.

 Without auth_token in place to manage multitenant authorization, I'd still
 expect services to blindly trust the values provided in the environment
 (useful for both debugging the service and alternative deployment
 architectures).

 On Sun, Feb 16, 2014 at 8:52 AM, Dong Liu willowd...@gmail.com wrote:

 Hi stackers:

 I found that when creating network subnet and other resources, the
 attribute tenant_id
 can be set by admin tenant. But we did not verify that if the tanent_id
 is real in keystone.

 I know that we could use neutron without keystone, but do you think
 tenant_id should
 be verified when we using neutron with keystone.

 thanks
 ___
 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] vhost-{pid} takes up cpu

[Yongsheng Gong]

Hi deal stackers,

I am running a devstack with two nodes:
one is controller (no nova-compute running) and other is compute.

I am using neutron ml2 plugin and ovs agent with GRE tunnel.

I started a VM and tried to run iperf testing:
1. start iperf as server role in the VM, which has a floating ip
192.168.10.10:
iperf -s

2 start iperf as client role on the controler node to test the VM via
floating ip:
iperf -c 192.168.10.10 -t 120

at the same time, run top on compute node, I found the vhost-{pid} was
taking too much cpu resource ( more than 75%):

Tasks: 230 total,   2 running, 228 sleeping,   0 stopped,   0 zombie
%Cpu0  : 23.7 us,  9.1 sy,  0.0 ni, 66.9 id,  0.0 wa,  0.0 hi,  0.3 si,
 0.0 st
%Cpu1  : 10.2 us,  2.7 sy,  0.0 ni, 86.3 id,  0.0 wa,  0.0 hi,  0.7 si,
 0.0 st
%Cpu2  :  0.0 us, 19.8 sy,  0.0 ni,  5.2 id,  0.0 wa,  2.2 hi, 72.8 si,
 0.0 st
%Cpu3  : 12.6 us,  4.2 sy,  0.0 ni, 83.2 id,  0.0 wa,  0.0 hi,  0.0 si,
 0.0 st
KiB Mem:  12264832 total,  1846428 used, 10418404 free,43692 buffers
KiB Swap:0 total,0 used,0 free,   581572 cached

  PID USER  PR  NI  VIRT  RES  SHR S  %CPU %MEMTIME+  COMMAND

 4073 root  20   0 000 R  79.8  0.0   3:26.97 vhost-4070


gongysh@gongysh-p6535cn:~$ ps -ef | grep 4070
119   4070 1 31 19:24 ?00:04:13 qemu-system-x86_64 -machine
accel=kvm:tcg -name instance-0002 -S -M pc-i440fx-1.4 -m 2048 -smp
1,sockets=1,cores=1,threads=1 -uuid 5cbfb914-d16c-4b51-a057-50f2da827830
-smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack
Nova,version=2014.1,serial=94b43180-e901-1015-b061-90cecbca80a3,uuid=5cbfb914-d16c-4b51-a057-50f2da827830
-no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0002.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc
base=utc,driftfix=slew -no-hpet -no-shutdown -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
file=/opt/stack/data/nova/instances/5cbfb914-d16c-4b51-a057-50f2da827830/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive
file=/opt/stack/data/nova/instances/5cbfb914-d16c-4b51-a057-50f2da827830/disk.config,if=none,id=drive-ide0-1-1,readonly=on,format=raw,cache=none
-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev
tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:ce:da:ae,bus=pci.0,addr=0x3
-chardev
file,id=charserial0,path=/opt/stack/data/nova/instances/5cbfb914-d16c-4b51-a057-50f2da827830/console.log
-device isa-serial,chardev=charserial0,id=serial0 -chardev
pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -vnc
0.0.0.0:0 -k en-us -vga cirrus -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5


This is a big performance problem, imagine almost all the cpu resources
will be consumed by the vhost-{pid}s if we have many VMs and all are
running with full speed network traffic.


any ideas?

regards,
yong sheng gong
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] multiple external networks not working

[Yongsheng Gong]

in order that the router is scheduled to a l3 agent with a given external
network,  we should create the router and set its gateway interface on that
external network just after the router creation.


On Thu, Feb 13, 2014 at 3:26 PM, Nick Ma skywalker.n...@gmail.com wrote:

 I have a multiple external networks environment:

 | 6fd43d02-221a-44fe-8088-dc5915512c14  |   Ext-Net-2   |
 1a530334-9dd7-45f3-aa6a-2bb1a5dad562 192.168.1.0/24 |
 | a2946b29-6be5-4285-9eb9-99625ec2a283 |Ext-Net  |
 dfbc7f6c-c3dd-4c56-a142-48964e2e474c 192.168.2.0/24 |

 Each of the external network is served by a single L3-agent. I also
 declare gateway_external_network_id in each l3_agent.ini, and set
 external_network_bridge.

 Then, I set up tenants, routers and gateways as follows:

 TenantA -- TenantA-Router -- Ext-Net -- Internet
 TenantB -- TenantB-Router -- Ext-Net-2 -- Internet

 I find that both qrouter-xxx is associated with only one L3-agent, not
 as expected.

 I debugged l3-agent-router-scheduler component to see how it works. I
 found that:

 Before the router is scheduled, I print agent objects out:

 neutron.db.agents_db.Agent[object at 2ba9150] {...
 configurations=u'{router_id: , gateway_external_network_id:
 6fd43d02-221a-44fe-8088-dc5915512c14, ...

 The gateway_external_network_id is actual there.

 And I print router object out:

 Router: {'status': u'ACTIVE', 'external_gateway_info': None, 'name':
 u'TenantA-R1', 'gw_port_id': None, 'admin_state_up': True, 'tenant_id':
 u'b181fd2406784da5895a966da4b74126', 'routes': [], 'id':
 u'14ff540e-13c6-4aec-8064-a74320f62a0d'}

 The external_gateway_info is None.

 Finally, I run neutron router-show:

 7ab3f8f4-89c8-4735-a5c2-4c0a09103bf1 | TenantA-R1 | {network_id:
 6fd43d02-221a-44fe-8088-dc5915512c14, enable_snat: true}

 The external_gateway_info is there.

 So, I guess that:

 The router scheduler works before I associate with external gateway to
 that router.

 in neutron/db/l3_agentschedulers_db.py:
 def get_l3_agent_candidates(self, sync_router, l3_agents)
 gateway_external_network_id = agent_conf.get(
 'gateway_external_network_id', None)
 ex_net_id = (sync_router['external_gateway_info'] or {}).get(
 'network_id')

 It compares the two variables to see if they are equal, the l3-agent is
 candidate.

 Forget to tell that it happens for HAVANA stable release. I haven't
 tested master branch yet.

 1. A bug or by design?
 2. How to run multiple external networks?

 --

 Nick Ma
 skywalker.n...@gmail.com


 ___
 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

Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

[Yongsheng Gong]

+1


On Tue, Feb 11, 2014 at 7:28 AM, Mark McClain mmccl...@yahoo-inc.comwrote:

 All-

 I'd like to nominate Oleg Bondarev to become a Neutron core reviewer.
  Oleg has been valuable contributor to Neutron by actively reviewing,
 working on bugs, and contributing code.

 Neutron cores please reply back with +1/0/-1 votes.

 mark
 ___
 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

Re: [openstack-dev] [Neutron] Developer documentation - linking to slideshares?

[Yongsheng Gong]

My slides are also available to be used.


On Thu, Feb 6, 2014 at 2:27 AM, Collins, Sean 
sean_colli...@cable.comcast.com wrote:

 On Tue, Feb 04, 2014 at 07:52:22AM -0600, Anne Gentle wrote:
  Currently the docs contributor sign the same CLA as code contributors.
 I'd
  encourage you to use the docs to really explain not just link to slide
  decks. There's a better chance of maintenance over time.

 Agreed - I plan on writing up docs, but when I find something really
 good on a slide I'd like to be able to have a reference to it in the
 footnotes - I suppose a works cited section, so I'm not plagiarizing.

  I had been using a wiki page for a collection of videos at
  https://wiki.openstack.org/wiki/Demo_Videos. But it ages with time.

 Awesome - I'll make sure to add that link to some kind of
 further reading section.

 --
 Sean M. Collins
 ___
 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

Re: [openstack-dev] [Neutron] About ports backing floating IPs

[Yongsheng Gong]

for all ports:
user can change the device_id and device owner easily, it will cause mess
in particularly for system ports, such as router interface and gateway
ports, dhcp ports etc.

dhcp port:
there is not point of updating its security groups, and I don't know the
effect when we update its Ip addresses from API too.

this applies to other system ports.



On Wed, Jan 15, 2014 at 7:50 AM, Salvatore Orlando sorla...@nicira.comwrote:

 TL;DR;
 I have been looking back at the API and found out that it's a bit weird
 how floating IPs are mapped to ports. This might or might not be an issue,
 and several things can be done about it.
 The rest of this post is a boring description of the problem and a
 possibly even more boring list of potential solutions.

 Floating IPs are backed by ports on the external network where they are
 implemented; while there are good reason for doing so, this has some
 seemingly weird side effects, which are usually not visible to tenants as
 only admins are allowed (by default) to view the ports backing the floating
 IPs.

 Assigning an external port to a floating IP is an easy way for ensuring
 the IP address used for the floating IP is then not reused for other
 allocation purposes on the external network; indeed admin users might start
 VMs on external networks as well. Conceptually, it is also an example of
 port-level insertion for a network service (DNAT/SNAT).

 However these are the tricky aspects:
 - IP Address changes: The API allows IP address updates for a floating IP
 port. However as it might be expected, the IP of the floating IP entities
 does not change, as well as the actual floating IP implemented in the
 backend (l3 agent or whatever the plugin uses).
 - operational status: It is always down at least for plugins based on
 OVS/LB agents. This is because there is no actual VIF backing a floating
 IP, so there is nothing to wire.
 - admin status: updating it just has no effect at all
 - Security groups and  allowed address pairs: The API allows for updating
 them, but it is not clear whether something actually happens in the
 backend, and I'm even not entirely sure this makes sense at all.

 Why these things happen, whether it's intended behaviour, and whether it's
 the right behaviour it's debatable.

 From my perspective, this leads to inconsistent state, as:
 - the address reported in the floating IP entity might differ from the one
 on the port backing the floating IP
 - operational status is wrongly represented as down
 - expectations concerning operations on the port are not met (eg: admin
 status update)
 And I reckon state inconsistencies should always be avoided.

 Considering the situation described above, there are few possible options.

 1- don't do anything, since the port backing the floating IP is hidden
 from the tenant.
 This might be ok provided that a compelling reason for ignoring entities
 not visible to tenants is provided.
 However it has to be noted that Neutron authZ logic, which is based on
 openstack.common would allow deployers to change that (*)

 2- remove the need for a floating IP to be backed from a port
 While this might seem simple, this has non-trivial implications as IPAM
 logic would need to become aware of floating IPs, and should  be discussed
 further.

 3- leverage policy-based APIs, and transform floating IPs in a remote
 access policy
 In this way the floating IP will become a policy to apply to a port; it
 will be easier to solve conflicts with security policies and it will be
 possible to just use IPs (or addressing policies) configured on the port.
 However, this will be hardly backward compatible, and its feasibility
 depends on the outcome of the more general discussions on policy-based APIs
 for neutron.

 4- Document the current behaviour
 This is something which is probably worth doing anyway until a solution is
 agreed upon

 Summarising, since all the 'technical' options sounds not feasible for the
 upcoming Icehouse release, it seems worth at least documenting the current
 behaviour, and start a discussion on whether we should do something about
 this and, if yes, what.

 Regards and apologies for the long post,
 Salvatore

 (*) As an interesting corollary, the flexibility of making authZ policies
 super-configurable causes the API to be non-portable. However, this is a
 subject for a different discussion.

 ___
 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

Re: [openstack-dev] [Neutron] Alembic migrations

[Yongsheng Gong]

but mark mcclain https://review.openstack.org/#/dashboard/2592 seems not
to agree it. so it is blocked for a long time.


On Sun, Dec 22, 2013 at 10:38 PM, Roman Podoliaka
rpodoly...@mirantis.comwrote:

 Hi Gary,

 It's a known bug (the migration script creating 'agents' table is
 mistakenly not applied when running schema migrations with ML2 core
 plugin selected). There is a patch on review
 https://review.openstack.org/#/c/61677 fixing this error.

 Thanks,
 Roman

 On Sun, Dec 22, 2013 at 4:02 PM, Gary Kotton gkot...@vmware.com wrote:
  Hi,
  Anyone else encounter the following exception:
 
  + /usr/local/bin/neutron-db-manage --config-file
 /etc/neutron/neutron.conf
  --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head
  No handlers could be found for logger neutron.common.legacy
  INFO  [alembic.migration] Context impl MySQLImpl.
  INFO  [alembic.migration] Will assume non-transactional DDL.
  INFO  [alembic.migration] Running upgrade None - folsom, folsom initial
  database
  INFO  [alembic.migration] Running upgrade folsom - 2c4af419145b,
 l3_support
  INFO  [alembic.migration] Running upgrade 2c4af419145b - 5a875d0e5c, ryu
  INFO  [alembic.migration] Running upgrade 5a875d0e5c - 48b6f43f7471, DB
  support for service types
  INFO  [alembic.migration] Running upgrade 48b6f43f7471 - 3cb5d900c5de,
  security_groups
  INFO  [alembic.migration] Running upgrade 3cb5d900c5de - 1d76643bcec4,
  nvp_netbinding
  INFO  [alembic.migration] Running upgrade 1d76643bcec4 - 2a6d0b51f4bb,
  cisco plugin cleanup
  INFO  [alembic.migration] Running upgrade 2a6d0b51f4bb - 1b693c095aa3,
  Quota ext support added in Grizzly
  INFO  [alembic.migration] Running upgrade 1b693c095aa3 - 1149d7de0cfa,
  inital port security
  INFO  [alembic.migration] Running upgrade 1149d7de0cfa - 49332180ca96,
 ryu
  plugin update
  INFO  [alembic.migration] Running upgrade 49332180ca96 - 38335592a0dc,
  nvp_portmap
  INFO  [alembic.migration] Running upgrade 38335592a0dc - 54c2c487e913,
 'DB
  support for load balancing service
  INFO  [alembic.migration] Running upgrade 54c2c487e913 - 45680af419f9,
  nvp_qos
  INFO  [alembic.migration] Running upgrade 45680af419f9 - 1c33fa3cd1a1,
  Support routing table configuration on Router
  INFO  [alembic.migration] Running upgrade 1c33fa3cd1a1 - 363468ac592c,
  nvp_network_gw
  INFO  [alembic.migration] Running upgrade 363468ac592c - 511471cc46b,
 Add
  agent management extension model support
  INFO  [alembic.migration] Running upgrade 511471cc46b - 3b54bf9e29f7,
 NEC
  plugin sharednet
  INFO  [alembic.migration] Running upgrade 3b54bf9e29f7 - 4692d074d587,
  agent scheduler
  INFO  [alembic.migration] Running upgrade 4692d074d587 - 1341ed32cc1e,
  nvp_net_binding
  INFO  [alembic.migration] Running upgrade 1341ed32cc1e - grizzly,
 grizzly
  INFO  [alembic.migration] Running upgrade grizzly - f489cf14a79c, DB
  support for load balancing service (havana)
  INFO  [alembic.migration] Running upgrade f489cf14a79c - 176a85fc7d79,
 Add
  portbindings db
  INFO  [alembic.migration] Running upgrade 176a85fc7d79 - 32b517556ec9,
  remove TunnelIP model
  INFO  [alembic.migration] Running upgrade 32b517556ec9 - 128e042a2b68,
  ext_gw_mode
  INFO  [alembic.migration] Running upgrade 128e042a2b68 - 5ac71e65402c,
  ml2_initial
  INFO  [alembic.migration] Running upgrade 5ac71e65402c - 3cbf70257c28,
  nvp_mac_learning
  INFO  [alembic.migration] Running upgrade 3cbf70257c28 - 5918cbddab04,
 add
  tables for router rules support
  INFO  [alembic.migration] Running upgrade 5918cbddab04 - 3cabb850f4a5,
  Table to track port to host associations
  INFO  [alembic.migration] Running upgrade 3cabb850f4a5 - b7a8863760e,
  Remove cisco_vlan_bindings table
  INFO  [alembic.migration] Running upgrade b7a8863760e - 13de305df56e,
  nec_add_pf_name
  INFO  [alembic.migration] Running upgrade 13de305df56e - 20ae61555e95,
 DB
  Migration for ML2 GRE Type Driver
  INFO  [alembic.migration] Running upgrade 20ae61555e95 - 477a4488d3f4,
 DB
  Migration for ML2 VXLAN Type Driver
  INFO  [alembic.migration] Running upgrade 477a4488d3f4 - 2032abe8edac,
  LBaaS add status description
  INFO  [alembic.migration] Running upgrade 2032abe8edac - 52c5e4a18807,
  LBaaS Pool scheduler
  INFO  [alembic.migration] Running upgrade 52c5e4a18807 - 557edfc53098,
 New
  service types framework (service providers)
  INFO  [alembic.migration] Running upgrade 557edfc53098 - e6b16a30d97,
 Add
  cisco_provider_networks table
  INFO  [alembic.migration] Running upgrade e6b16a30d97 - 39cf3f799352,
 FWaaS
  Havana-2 model
  INFO  [alembic.migration] Running upgrade 39cf3f799352 - 52ff27f7567a,
  Support for VPNaaS
  INFO  [alembic.migration] Running upgrade 52ff27f7567a - 11c6e18605c8,
 Pool
  Monitor status field
  INFO  [alembic.migration] Running upgrade 11c6e18605c8 - 35c7c198ddea,
  remove status from HealthMonitor
  INFO  [alembic.migration] Running upgrade 35c7c198ddea - 263772d65691,
  Cisco plugin db cleanup part II
  INFO  

Re: [openstack-dev] [neutron] Third party Neutron plugin testing meeting

[Yongsheng Gong]

It is 1am beijing time, so I am afraid I will not join.


On Wed, Dec 11, 2013 at 10:10 AM, Akihiro Motoki amot...@gmail.com wrote:

 Thanks Kyle for coordinating the meeting.

 The time is midnight to me, but it fits everyone except me. I'll try the
 time but not sure. Anyway I will follow the log.

 2013年12月11日水曜日 Shiv Haris sha...@brocade.com:

 +1



 Will join via IRC or voice call







 *From:* Gary Duan [mailto:gd...@varmour.com]
 *Sent:* Tuesday, December 10, 2013 10:59 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [neutron] Third party Neutron plugin
 testingmeeting



 I will be joining IRC too.



 Thanks,

 Gary



 On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana emag...@plumgrid.com
 wrote:

 Also joining!
 Looking forward to hearing your ideas folks!

 Edgar


 On 12/10/13 10:16 AM, Nachi Ueno na...@ntti3.com wrote:

 +1 ! I'll join.
 I'm also working on investigating how to use openstack gating system.
 (This document is still draft version)
 
 https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
 efQalL5Q0/edit#slide=id.p
 
 2013/12/10 Ivar Lazzaro i...@embrane.com:
  +1 for 1700UTC Thursday on IRC
 
  -Original Message-
  From: Kyle Mestery [mailto:mest...@siliconloons.com]
  Sent: Tuesday, December 10, 2013 9:21 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
 testing meeting
 
  On Dec 10, 2013, at 10:45 AM, Veiga, Anthony
 anthony_ve...@cable.comcast.com wrote:
  -Original Message-
  From: Kyle Mestery mest...@siliconloons.com
  Reply-To: OpenStack Development Mailing List (not for usage
 questions)
  openstack-dev@lists.openstack.org
  Date: Tuesday, December 10, 2013 10:48
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
  Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
  meeting
 
  Last week I took an action item to organize a meeting for everyone
  who is doing third-party testing in Neutron for plugins, whether this
  is vendor or Open Source based. The idea is to share ideas around
  setups and any issues people hit. I'd like to set this meeting up for
  this week, Thursday at 1700UTC. I would also like to propose we make
  this a dial in meeting using the Infrastructure Conferencing bridges
  [1]. If this time works, I'll set something up and reply to this
  thread with the dial in information.
 
  +1 for the meeting time.  Any particular reason for voice over IRC?
 
  We kind of decided that doing this over voice initially would be
 expedient, but I am fine with moving to IRC. If I don't hear objections,
 lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
 
 
 
  Also, I've started a etherpad page [2] with information. It would be
  good for people to add information to this etherpad as well. I've
  coupled this pad with information around multi-node gate testing for
  Neutron as well, as I suspect most of the third-party testing will
  require multiple nodes as well.
 
  I'll start filling out our setup.  I have some questions around
  Third-Party Testing in particular, and look forward to this
 discussion.
 
  Awesome, thanks Anthony!
 
 
  Thanks!
  Kyle
 
  [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing


 ___
 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

Re: [openstack-dev] [neutron] Third party Neutron plugin testing meeting

[Yongsheng Gong]

UTC 22:00+, which is 6:am beijing time，but if there are guys from Israel
alike, I can get up one hour earlier, just like what I do for neutron
meeting.


On Wed, Dec 11, 2013 at 11:08 AM, Kyle Mestery mest...@siliconloons.comwrote:

 I suspect we'll need another meeting next week, I propose we have it
 at a time friendly to those in Asian timezones. Yong and Akihiro, can
 you guys propose a timeslot which works for you guys and I'll see
 about setting the followup meeting up.

 Thanks,
 Kyle

 On Dec 10, 2013, at 8:14 PM, Yongsheng Gong gong...@unitedstack.com
 wrote:

  It is 1am beijing time, so I am afraid I will not join.
 
 
  On Wed, Dec 11, 2013 at 10:10 AM, Akihiro Motoki amot...@gmail.com
 wrote:
  Thanks Kyle for coordinating the meeting.
 
  The time is midnight to me, but it fits everyone except me. I'll try the
 time but not sure. Anyway I will follow the log.
 
  2013年12月11日水曜日 Shiv Haris sha...@brocade.com:
 
  +1
 
 
 
  Will join via IRC or voice call
 
 
 
 
 
 
 
  From: Gary Duan [mailto:gd...@varmour.com]
  Sent: Tuesday, December 10, 2013 10:59 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
 testingmeeting
 
 
 
  I will be joining IRC too.
 
 
 
  Thanks,
 
  Gary
 
 
 
  On Tue, Dec 10, 2013 at 10:33 AM, Edgar Magana emag...@plumgrid.com
 wrote:
 
  Also joining!
  Looking forward to hearing your ideas folks!
 
  Edgar
 
 
  On 12/10/13 10:16 AM, Nachi Ueno na...@ntti3.com wrote:
 
  +1 ! I'll join.
  I'm also working on investigating how to use openstack gating system.
  (This document is still draft version)
  
 https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
  efQalL5Q0/edit#slide=id.p
  
  2013/12/10 Ivar Lazzaro i...@embrane.com:
   +1 for 1700UTC Thursday on IRC
  
   -Original Message-
   From: Kyle Mestery [mailto:mest...@siliconloons.com]
   Sent: Tuesday, December 10, 2013 9:21 AM
   To: OpenStack Development Mailing List (not for usage questions)
   Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
  testing meeting
  
   On Dec 10, 2013, at 10:45 AM, Veiga, Anthony
  anthony_ve...@cable.comcast.com wrote:
   -Original Message-
   From: Kyle Mestery mest...@siliconloons.com
   Reply-To: OpenStack Development Mailing List (not for usage
  questions)
   openstack-dev@lists.openstack.org
   Date: Tuesday, December 10, 2013 10:48
   To: OpenStack Development Mailing List (not for usage questions)
   openstack-dev@lists.openstack.org
   Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
   meeting
  
   Last week I took an action item to organize a meeting for everyone
   who is doing third-party testing in Neutron for plugins, whether
 this
   is vendor or Open Source based. The idea is to share ideas around
   setups and any issues people hit. I'd like to set this meeting up
 for
   this week, Thursday at 1700UTC. I would also like to propose we make
   this a dial in meeting using the Infrastructure Conferencing bridges
   [1]. If this time works, I'll set something up and reply to this
   thread with the dial in information.
  
   +1 for the meeting time.  Any particular reason for voice over IRC?
  
   We kind of decided that doing this over voice initially would be
  expedient, but I am fine with moving to IRC. If I don't hear
 objections,
  lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
  
  
  
   Also, I've started a etherpad page [2] with information. It would be
   good for people to add information to this etherpad as well. I've
   coupled this pad with information around multi-node gate testing for
   Neutron as well, as I suspect most of the third-party testing will
   require multiple nodes as well.
  
   I'll start filling out our setup.  I have some questions around
   Third-Party Testing in particular, and look forward to this
 discussion.
  
   Awesome, thanks Anthony!
  
  
   Thanks!
   Kyle
  
   [1]
 
 
  ___
  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

Re: [openstack-dev] {opestack][Neutron - FWaaS] CLI Firewall-Policy-Update Bug

[Yongsheng Gong]

try to use:
 neutron firewall-policy-update dd2c7d33-2c36-4200-b1f8-daaa1ab202d5
--firewall-rules list=true rule1


On Wed, Dec 11, 2013 at 1:37 PM, trinath.soman...@freescale.com 
trinath.soman...@freescale.com wrote:

  Hi –



 I found this issue with FWaaS CLI commands.



 When I issue the command,



 $ neutron firewall-policy-update dd2c7d33-2c36-4200-b1f8-daaa1ab202d5
 --firewall-rules rule1



 404-{u'NeutronError': {u'message': u'Firewall Rule r could not be found.',
 u'type': u'FirewallRuleNotFound', u'detail': u''}}



 With respect to the code, I see that the split is not happening based on
 the white space character rather, the string is being split or parsed.



 Is there a bug assigned to this and is that resolved ?



 Kindly help me in this regard.



 --

 Trinath Somanchi - B39208

 trinath.soman...@freescale.com | extn: 4048



 ___
 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

Re: [openstack-dev] Neutron Distributed Virtual Router

[Yongsheng Gong]

If distributed router is good enough, why do we still need non-distributed
router?


On Tue, Dec 10, 2013 at 9:04 AM, Ian Wells ijw.ubu...@cack.org.uk wrote:

 I would imagine that, from the Neutron perspective, you get a single
 router whether or not it's distributed.  I think that if a router is
 distributed - regardless of whether it's tenant-tenant or tenant-outside -
 it certainly *could* have some sort of SLA flag, but I don't think a simple
 'distributed' flag is either here or there; it's not telling the tenant
 anything meaningful.


 On 10 December 2013 00:48, Mike Wilson geekinu...@gmail.com wrote:

 I guess the question that immediately comes to mind is, is there anyone
 that doesn't want a distributed router? I guess there could be someone out
 there that hates the idea of traffic flowing in a balanced fashion, but
 can't they just run a single router then? Does there really need to be some
 flag to disable/enable this behavior? Maybe I am oversimplifying things...
 you tell me.

 -Mike Wilson


 On Mon, Dec 9, 2013 at 3:01 PM, Vasudevan, Swaminathan (PNB Roseville) 
 swaminathan.vasude...@hp.com wrote:

  Hi Folks,

 We are in the process of defining the API for the Neutron Distributed
 Virtual Router, and we have a question.



 Just wanted to get the feedback from the community before we implement
 and post for review.



 We are planning to use the “distributed” flag for the routers that are
 supposed to be routing traffic locally (both East West and North South).

 This “distributed” flag is already there in the “neutronclient” API, but
 currently only utilized by the “Nicira Plugin”.

 We would like to go ahead and use the same “distributed” flag and add an
 extension to the router table to accommodate the “distributed flag”.



 Please let us know your feedback.



 Thanks.



 Swaminathan Vasudevan

 Systems Software Engineer (TC)





 HP Networking

 Hewlett-Packard

 8000 Foothills Blvd

 M/S 5541

 Roseville, CA - 95747

 tel: 916.785.0937

 fax: 916.785.1815

 email: swaminathan.vasude...@hp.com





 ___
 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

Re: [openstack-dev] [neutron] only one subnet_id is allowed behind a router for vpnservice object

[Yongsheng Gong]

ok, My pleasure to help,
I created a bp for it:
https://blueprints.launchpad.net/neutron/+spec/vpn-multiple-subnet


On Fri, Dec 6, 2013 at 2:11 PM, Nachi Ueno na...@ntti3.com wrote:

 Hi Yong

 Yes, to support multiple subnet is on the roadmap.
 I'll definitely welcome your help :P

 2013/12/5 Yongsheng Gong gong...@unitedstack.com:
  I think we should allow more than subnet_id in one vpnservice object.
  but the model below limits only one subnet_id is used.
 
 https://github.com/openstack/neutron/blob/master/neutron/extensions/vpnaas.py
  RESOURCE_ATTRIBUTE_MAP = {
 
  'vpnservices': {
  'id': {'allow_post': False, 'allow_put': False,
 'validate': {'type:uuid': None},
 'is_visible': True,
 'primary_key': True},
  'tenant_id': {'allow_post': True, 'allow_put': False,
'validate': {'type:string': None},
'required_by_policy': True,
'is_visible': True},
  'name': {'allow_post': True, 'allow_put': True,
   'validate': {'type:string': None},
   'is_visible': True, 'default': ''},
  'description': {'allow_post': True, 'allow_put': True,
  'validate': {'type:string': None},
  'is_visible': True, 'default': ''},
  'subnet_id': {'allow_post': True, 'allow_put': False,
'validate': {'type:uuid': None},
'is_visible': True},
  'router_id': {'allow_post': True, 'allow_put': False,
'validate': {'type:uuid': None},
'is_visible': True},
  'admin_state_up': {'allow_post': True, 'allow_put': True,
 'default': True,
 'convert_to': attr.convert_to_boolean,
 'is_visible': True},
  'status': {'allow_post': False, 'allow_put': False,
 'is_visible': True}
  },
 
  with such limit, I don't think there is a way to allow other subnets
 behind
  the router be vpn exposed!
 
  thoughts?
 
  Thanks
  Yong Sheng Gong
 
  ___
  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

Re: [openstack-dev] [Neutron] DHCP Agent Reliability

[Yongsheng Gong]

another way is to have a large agent_down_time, by default it is 9 secs.


On Wed, Dec 4, 2013 at 7:55 AM, Carl Baldwin c...@ecbaldwin.net wrote:

 Stephen, all,

 I agree that there may be some opportunity to split things out a bit.
 However, I'm not sure what the best way will be.  I recall that Mark
 mentioned breaking out the processes that handle API requests and RPC
 from each other at the summit.  Anyway, it is something that has been
 discussed.

 I actually wanted to point out that the neutron server now has the
 ability to run a configurable number of sub-processes to handle a
 heavier load.  Introduced with this commit:

 https://review.openstack.org/#/c/37131/

 Set api_workers to something  1 and restart the server.

 The server can also be run on more than one physical host in
 combination with multiple child processes.

 Carl

 On Tue, Dec 3, 2013 at 9:47 AM, Stephen Gran
 stephen.g...@theguardian.com wrote:
  On 03/12/13 16:08, Maru Newby wrote:
 
  I've been investigating a bug that is preventing VM's from receiving IP
  addresses when a Neutron service is under high load:
 
  https://bugs.launchpad.net/neutron/+bug/1192381
 
  High load causes the DHCP agent's status updates to be delayed, causing
  the Neutron service to assume that the agent is down.  This results in
 the
  Neutron service not sending notifications of port addition to the DHCP
  agent.  At present, the notifications are simply dropped.  A simple fix
 is
  to send notifications regardless of agent status.  Does anybody have any
  objections to this stop-gap approach?  I'm not clear on the
 implications of
  sending notifications to agents that are down, but I'm hoping for a
 simple
  fix that can be backported to both havana and grizzly (yes, this bug has
  been with us that long).
 
  Fixing this problem for real, though, will likely be more involved.  The
  proposal to replace the current wsgi framework with Pecan may increase
 the
  Neutron service's scalability, but should we continue to use a 'fire and
  forget' approach to notification?  Being able to track the success or
  failure of a given action outside of the logs would seem pretty
 important,
  and allow for more effective coordination with Nova than is currently
  possible.
 
 
  It strikes me that we ask an awful lot of a single neutron-server
 instance -
  it has to take state updates from all the agents, it has to do
 scheduling,
  it has to respond to API requests, and it has to communicate about actual
  changes with the agents.
 
  Maybe breaking some of these out the way nova has a scheduler and a
  conductor and so on might be a good model (I know there are things people
  are unhappy about with nova-scheduler, but imagine how much worse it
 would
  be if it was built into the API).
 
  Doing all of those tasks, and doing it largely single threaded, is just
  asking for overload.
 
  Cheers,
  --
  Stephen Gran
  Senior Systems Integrator - theguardian.com
  Please consider the environment before printing this email.
  --
  Visit theguardian.com
  On your mobile, download the Guardian iPhone app theguardian.com/iphoneand
  our iPad edition theguardian.com/iPad   Save up to 33% by subscribing
 to the
  Guardian and Observer - choose the papers you want and get full digital
  access.
  Visit subscribe.theguardian.com
 
  This e-mail and all attachments are confidential and may also
  be privileged. If you are not the named recipient, please notify
  the sender and delete the e-mail and all attachments immediately.
  Do not disclose the contents to another person. You may not use
  the information for any purpose, or store, or copy, it in any way.
 
  Guardian News  Media Limited is not liable for any computer
  viruses or other material transmitted with or as part of this
  e-mail. You should employ virus checking software.
 
  Guardian News  Media Limited
 
  A member of Guardian Media Group plc
  Registered Office
  PO Box 68164
  Kings Place
  90 York Way
  London
  N1P 2AP
 
  Registered in England Number 908396
 
 
 --
 
 
 
  ___
  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

Re: [openstack-dev] [Neutron] Rename 'tenant' to 'project' as per Keystone?

[Yongsheng Gong]

who can tell me the whole story about keystone(or openstack) changes
between project-tenant-project?


On Wed, Dec 4, 2013 at 9:58 AM, Adam Young ayo...@redhat.com wrote:

 On 11/26/2013 12:07 PM, Maru Newby wrote:

 Keystone is almost finished replacing the term 'tenant' with 'project'
 (see recent thread https://www.mail-archive.com/
 openstack-dev@lists.openstack.org/msg09709.html)  and we might want to
 think about how and when Neutron makes a similar transition.  It's an
 unlikely priority in the near term given the focus on stability, but I
 wanted to broach the topic for discussion in case people think it might be
 worth attempting later in the cycle.  I've filed a preliminary blueprint in
 any case: https://blueprints.launchpad.net/neutron/+spec/rename-
 tenant-to-project


 Maru


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

 yes please!


 ___
 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] whey cannot we update vpn service and IPsecSiteConnection when they are in pending_create state

[Yongsheng Gong]

currently, when vpn service and IPsecSiteConnection are created, their
state is PENDING_CREATE,  which disallows updating at:
def assert_update_allowed(self, obj):
status = getattr(obj, 'status', None)
_id = getattr(obj, 'id', None)
if utils.in_pending_status(status):
raise vpnaas.VPNStateInvalidToUpdate(id=_id, state=status)

so why cannot we update these objects just after we created them?

I think  for IPsecSiteConnection, we should be able to update some
description fields such as name, and for vpnservice objects, we should be
able to do updating if we have no IPsecSiteConnection for it.

Regards,
Yong Sheng Gong
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Reg : Security groups implementation using openflows in quantum ovs plugin

[Yongsheng Gong]

Is the open flow rule stateful?


On Tue, Nov 19, 2013 at 6:26 AM, 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

 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

Re: [openstack-dev] [Neutron] Plugin and Driver Inclusion Requirements

[Yongsheng Gong]

For third party testing, I am afraid these tests will make the patch merge
process much longer since each patch, which even has nothing to do with the
specific plugins, will triggers the unwanted third party testing jobs.


On Fri, Nov 15, 2013 at 4:20 AM, Mark McClain mark.mccl...@dreamhost.comwrote:

 tl;dr
 -
 The Neutron team has experienced tremendous growth in vendor plugins and
 drivers over the last few cycles.  As a result of the growth, the Neutron
 team is implementing new requirements for plugin and driver code for
 Icehouse cycle to ensure continued code quality and stability.

 - Each third party plugin/driver shall designate a point of contact for
 the coordinated release cycle.
 - To be designated as compatible, a third-party plugin and/or driver code
 must implement external third party integration testing.
 - Policy is in effect immediately for new plugin/drivers.
 - Existing plugin/drivers have until Icehouse-2 to become compliant.

 Introduction
 ---
 Ensuring release quality through proper testing is an important tenant of
 the OpenStack community and Neutron team wants to do our part. We are
 introducing changes below provide more visibility into the quality and
 stability of vendor plugin and driver code.  The policies described here
 are in effect immediately.

 Rationale
 
 Code proposals for third party plugins have always presented a review
 challenge for the Neutron core team.  In the early days, code was often
 proposed by core project contributors and our review process only validated
 whether the requirements were met for community coding style and unit
 testing.  As Neutron has added new resources via extensions, it has become
 more difficult for Neutron reviewers to ensure the proposed code is
 functional.  Many of the plugins and/or drivers require proprietary
 hardware and/or software to conduct such testing.

 In addition to testing changes, the Neutron team is revising the
 requirements for the point of contact for third party code.  The changes
 bring the written expectations for contacts in line with current practice.

 Point of Contact Requirements
 -
 Each third party plugin and/or driver shall designate a point of contact
 for each coordinated release cycle.  The contact will serve as a liaison
 between the Neutron core team and the vendor or community supporting the
 plugin or driver.  The contact shall:
 - Attend weekly Neutron team IRC meetings
 - Be an active reviewer and contributor
 - Be an active participant on openstack-dev mailing list
 - Assist the core team with triaging bugs specific to the plugin and/or
 driver
 - Ensure OpenStack development deadlines are properly communicated back to
 their company and/or community

 NOTE: The this information can be maintained here:
 https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers

 Testing Requirements
 -
 To be designated as compatible, a third-party plugin and/or driver code
 must implement external third party testing.  The testing should be Tempest
 executed against a Devstack build with the proposed code changes.  The
 environment managed by the vendor should be configured to incorporate the
 plugin and/or driver solution.  The OpenStack Infrastructure team has
 provided details on how to integrate 3rd party testing at:

 http://ci.openstack.org/third_party.html

 and Tempest can be found at:

 https://github.com/openstack/tempest

 The Neutron team expects that the third party testing will provide a +/-1
 verify vote for all changes to a plugin or driver’s code.  In addition, the
 Neutron team expects that the third party test will also vote on all code
 submissions by the jenkins user.  The jenkins user regularly submits
 requirements changes and the Neutron team hopes to catch any possible
 regressions as early as possible.

 Existing Plugin and Drivers
 -
 Plugins and drivers currently in the Neutron project repository will be
 given a grace period until the Icehouse-2 milestone to implement external
 third party testing.  At that time, the Neutron team will release a list of
 the compatible plugins and drivers (i.e. those that meet the testing
 requirements).  Plugins and drivers that do not have external testing will
 be deprecated at the Icehouse release and will be candidates for removal
 when the J-release cycle opens.



 ___
 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

Re: [openstack-dev] [Glance] Summit Session Summaries

[Yongsheng Gong]

great, thanks


On Sat, Nov 16, 2013 at 5:10 AM, Mark Washenberger 
mark.washenber...@markwash.net wrote:

 Hi folks,

 My summary notes from the OpenStack Design Summit Glance sessions follow.
 Enjoy, and please help correct any misunderstandings.



 Image State Consistency:
 

 https://etherpad.openstack.org/p/icehouse-summit-image-state-consistency

 In this session, we focused on the problem of snapshots that fail
 after the image is created but before the image data is uploaded
 result in a pending image that will never become active, and the
 only operation nova can do is to delete the image. Thus there is
 not a very good way to communicate the failure to users without
 just leaving a useless image record around.

 A solution was proposed to allow Nova to directly set the status
 of the image, say to killed or some other state.

 A problem with the proposed solution is that we generally have
 kept the status field internally controlled by glance, which
 means there are some modeling and authorization concerns.
 However, it is actually something Nova could do today through
 the hacky mechanism of initiating a PUT with data, but then
 terminating the connection without sending a complete body. So
 the authorization aspects are not really a fundamental concern.

 It was suggested that the solution to this problem
 is to make Nova responsible for reporting these failures rather
 than Glance. In the short term, we could do the following
  - have nova delete the image when snapshot fails (already merged)
  - merge nova patch to report the failure as part of instance
error reporting

 In the longer term, it was seen as desirable for nova to treat
 snapshots as asynchronous tasks and reflect those tasks in the
 api, including the failure/success of those tasks.

 Another long term option that was viewed mostly favorably was
 to add another asynchronous task to glance for vanilla uploads
 so that nova snapshots can avoid creating the image until it
 is fully active.

 Fei Long Wang is going to follow up on what approach makes the
 most sense for Nova and report back for our next steps.



 What to do about v1?
 

 https://etherpad.openstack.org/p/icehouse-summit-images-v1-api

 In this discussion, we hammered out the details for how to drop
 the v1 api and in what timetable.

 Leaning heavily on cinder's experience dropping v1, we came
 up with the following schedule.

 Icehouse:
 - Announce plan to deprecate the V1 API and registry in J and remove
 it in K
 - Announce feature freeze for v1 API immediately
 - Make sure everything in OpenStack is using v2 (cinder, nova, ?)
 - Ensure v2 is being fully covered in tempest tests
 - Ensure there are no gaps in the migration strategy from v1 to v2
 - after the fact, it seems to me we need to produce a migration
 guide as a way to evaluate the presence of such gaps
 - Make v2 the default in glanceclient
 - Turn v2 on by default in glance API

 J:
 - Mark v1 as deprecated
 - Turn v1 off by default in config

 K:
 - Delete v1 api and v1 registry


 A few gotchas were identified, in particular, a concern was raised
 about breaking stable branch testing when we switch the default in
 glanceclient to v2--since latest glanceclient will be used to test
 glance  in say Folsom or Grizzly where the v2 api didn't really
 work at all.

 In addition, it was suggested that we should be very aggressive
 in using deprecation warnings for config options to communicate
 this change as loudly as possible.




 Image Sharing
 -

 https://etherpad.openstack.org/p/icehouse-summit-enhance-v2-image-sharing

 This session focused on the gaps between the current image sharing
 functionality and what is needed to establish an image marketplace.

 One issue was the lack of verification of project ids when sharing an
 image.

 A few other issues were identified:
 - there is no way to share an image with a large number of projects in a
 single api operation
 - membership lists are not currently paged
 - there is no way to share an image with everyone, you must know each
 other project id

 We identified a potential issue with bulk operations and
 verification--namely there is no way to do bulk verification of project ids
 in keystone that we know of, so probably keystone work would be needed to
 have both of these features in place without implying super slow api calls.

 In addition, we spent some time toying with the idea of image catalogs. If
 publishers put images in catalogs, rather than having shared images show up
 directly in other users' image lists, things would be a lot safer and we
 could relax some of our restrictions. However, there are some issues with
 this approach as well,
 - How do you find the catalog of a trusted image publisher?
 - Are we just pushing the issue of sensible world-listings to another
 resource?
 - This would be a big change.



 Enhancing Image 

Re: [openstack-dev] [neutron] [ml2] What is the router plugin for ml2

[Yongsheng Gong]

the router extension is now a service plugin for core ML2
plugin: service_plugins =
neutron.services.l3_router.l3_router_plugin.L3RouterPlugin


On Thu, Oct 31, 2013 at 11:46 AM, Xu Zhongxing xu_zhong_x...@163.comwrote:

 I noticed that the ml2 plugin does not support router extension itself. In
 README, it says It utilizes the service plugin interface to implement the
 L3 router abstraction.

 I wonder what is the current solution for router in ml2? Is there a plugin
 that already exists?




 ___
 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

Re: [openstack-dev] [Neutron][LBaaS] LBaaS plans for Icehouse

[Yongsheng Gong]

HI,
the following time is ok for me:
UTC+8: 6:00-23:00
UTC: 22:00-15:00

If it is scheduled during these time slot, I will join.

Thanks
Yong Sheng Gong


On Wed, Oct 23, 2013 at 4:50 PM, Eugene Nikanorov
enikano...@mirantis.comwrote:

 Hi Neutron folks!

 We're going to have an IRC meeting where we will discuss development plans
 for LBaaS in Icehouse.

 Currently I'm proposing to meet on Thursday, 24 at 8:00 PDT on freenode
 #neutron-lbaas channel.

 Agenda for the meeting:
 1. New features for lbaas in Icehouse
 Pretty much everything vendors expect to be impl in Icehouse should be
 briefly covered.
 2. Feature ordering/dependencies
 3. Dev resources evaluation

 If the time is not convenient for you, please suggest another time. (It's
 better to have it this week)

 Thanks,
 Eugene.

 ___
 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

Re: [openstack-dev] [Neutron] Tenant's info from plugin/services

[Yongsheng Gong]

I think this should be done in keystone. maybe you need a CLI command:
keystone tenant-get


On Thu, Oct 17, 2013 at 6:55 AM, Ivar Lazzaro i...@embrane.com wrote:

  Hello Everyone,

 ** **

 I was wondering if there’s a “standard” way within Neutron to retrieve
 tenants’ specific information (e.g. “name”) from a plugin/service.

 The call “context” already provides the tenant’s UUID, but that may be
 useful to have some extra info in certain cases.

 ** **

 Thanks,

 Ivar.

 ___
 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

Re: [openstack-dev] Tricky questions - 1/2 Quantum Network Object

[Yongsheng Gong]

On Mon, Oct 14, 2013 at 2:55 PM, Marco Fornaro marco.forn...@huawei.comwrote:

  Hi Gong,

 ** **

 Thanks so much for your answers

 ** **

 Just one more question: you wrote “You can create networks with just one
 subnet, but the vlan id will run out soon if vlan is used.”

 Sorry but: how can the Vlan ID “run out soon”?...is it really possible to
 finish them?

 **

for example, one network is using one vlan ID if vlan is used for linux
bridge plugin. If we create networks with just one subnet, we will need
more vlan ids than networks with more than subnets.



**

 Best Regards

 ** **

 Marco

 ** **

 ** **

 *From:* Yongsheng Gong [mailto:gong...@unitedstack.com]
 *Sent:* den 11 oktober 2013 10:56
 *To:* OpenStack Development Mailing List
 *Subject:* Re: [openstack-dev] Tricky questions - 1/2 Quantum Network
 Object

 ** **

 ** **

 ** **

 On Fri, Oct 11, 2013 at 4:41 PM, Marco Fornaro marco.forn...@huawei.com
 wrote:

 Hi All,

  

 (I already posted this on openstack mail list, but perhaps it’s more a
 developer stuff J)

 Some Tricky questions I ask help for (email 1 of 2):

  

  

 *Quantum Network object*

 In the “openstack networking guide”-”Using Openstack compute with
 Openstack”-” Advanced VM creation” (
 http://docs.openstack.org/grizzly/openstack-network/admin/content/advanceed_vm_creation.html)
 there are example boot a VM on one or more NETWORKs (meaning the quantum
 Network object):  

 nova boot --image img --flavor flavor \

 *--nic net-id=net1-id --nic net-id=net2-id* vm-name

  

 BUT if you look at the description of the network object in the API
 abstraction it looks like a collection of subnets (meaning the quantum
 object), so basically a collection of IP Addresses like 192.168.100.0/24**
 **

  

 *SO (first question): what happens in the network where I boot the VM has
 more than a subnet?...I suppose the VM should have a nic for EACH subnet of
 the network!*

 You will just get a nic for each network, not for each subnet of the
 network.   to choose the subnet, use --nic
 net-id=net-uuid,v4-fixed-ip=ip-addr

   

 *THEN (second question): why do I need a network object? Shouldn’t it be
 more practical to have just the subnet object?..why do I need to create a
 Network if it’s just a collection of subnets?*

  under the hood, the traffic among networks are isolated by tunnel id,
 vlan id or something else. You can create networks with just one subnet,
 but the vlan id will run out soon if vlan is used.

 ** **

 we can have many networks, and the subnets within network can have overlap
 IPs.

 ** **

   

 Thanks in advance for any help

  

 Best Regards

  

 Marco

  

  

  


 ___
 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

Re: [openstack-dev] Tricky questions - 1/2 Quantum Network Object

[Yongsheng Gong]

On Fri, Oct 11, 2013 at 4:41 PM, Marco Fornaro marco.forn...@huawei.comwrote:

  Hi All,

 ** **

 (I already posted this on openstack mail list, but perhaps it’s more a
 developer stuff J)

 Some Tricky questions I ask help for (email 1 of 2):

 ** **

 ** **

 *Quantum Network object*

 In the “openstack networking guide”-”Using Openstack compute with
 Openstack”-” Advanced VM creation” (
 http://docs.openstack.org/grizzly/openstack-network/admin/content/advanceed_vm_creation.html)
 there are example boot a VM on one or more NETWORKs (meaning the quantum
 Network object):  

 nova boot --image img --flavor flavor \

 *--nic net-id=net1-id --nic net-id=net2-id* vm-name

 ** **

 BUT if you look at the description of the network object in the API
 abstraction it looks like a collection of subnets (meaning the quantum
 object), so basically a collection of IP Addresses like 192.168.100.0/24**
 **

 ** **

 *SO (first question): what happens in the network where I boot the VM has
 more than a subnet?...I suppose the VM should have a nic for EACH subnet of
 the network!*

You will just get a nic for each network, not for each subnet of the
network.   to choose the subnet, use --nic
net-id=net-uuid,v4-fixed-ip=ip-addr

 **

 ** **

 *THEN (second question): why do I need a network object? Shouldn’t it be
 more practical to have just the subnet object?..why do I need to create a
 Network if it’s just a collection of subnets?*

under the hood, the traffic among networks are isolated by tunnel id, vlan
id or something else. You can create networks with just one subnet, but the
vlan id will run out soon if vlan is used.
we can have many networks, and the subnets within network can have overlap
IPs.

**

 ** **

 Thanks in advance for any help

 ** **

 Best Regards

 ** **

 Marco

 ** **

 ** **

 ** **

 ___
 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

Re: [openstack-dev] Tricky questions - 2/2 NOVA COMPUTE: are Booted VMs independent by other openstack/quantum services?

[Yongsheng Gong]

On Fri, Oct 11, 2013 at 4:41 PM, Marco Fornaro marco.forn...@huawei.comwrote:

  Hi All,

 ** **

 (I already posted this on openstack mail list, but perhaps it’s more a
 developer stuff J)

 Some Tricky questions I ask help for (email 2 of 2):

 ** **

 (please refer to a scenario with Openstack+Quantum, so we can have complex
 networks)

 ** **

 *Nova Compute*

 *Are booted VMs independent by other nova/quantum services?*

 *I mean: *when a VM is already booted does it need in any case to dialog
 with other nova/quantum services (apart from nova compute) like quantum,
 the quantum plugin agent, the keystone etc etc???

 For example and in other words: when a VM is running might I turn off the
 quantum server (or even physically disconnect the dedicated server itself?
 )?

 ** **

 Because…it this is NOT possible this means that the various servers (for
 example the quantum) are involved during the whole lifecycle of a
 VM…..could this be a bottleneck?, something to take in count for high
 availability and performance?

 ** **

 **

It depends how your vm gets the IP. If it is using dhcp, you need to keep
the dnsmasq alive. Other quantum services can be down when the VM is
running normally.

 **

 Thanks in advance for any help

 ** **

 Best Regards

 ** **

 Marco

 ** **

 ** **

 ** **

 ** **

 ** **

 ** **

 ** **

 ** **

 ___
 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

Re: [openstack-dev] VM instances Can not connect to external

[Yongsheng Gong]

have u enable the port interface of br-ex? For example ifconfig eth1 up


On Fri, Sep 27, 2013 at 7:26 PM, Jeff Cai jeff_...@symantec.com wrote:

 I did all that the doc tells me to do, which includes

 setting up a bridge in the network node.

 ** **

 Just like
 http://docs.openstack.org/grizzly/basic-install/apt/content/basic-install_network.html#basic-install_network-services
 

 ** **

 I did the Procedure 2.2-4 and 2.2-5.

 ** **

 Jeff

 ** **

 *From:* Ashok Kumaran [mailto:ashokkumara...@gmail.com]
 *Sent:* Friday, September 27, 2013 6:33 PM
 *To:* OpenStack Development Mailing List
 *Subject:* Re: [openstack-dev] VM instances Can not connect to external***
 *

 ** **

 You have IP forwarding enabled?

 ** **

 Did you create br-ex bridge and associated the external as a port to it?**
 **

 ** **

 On Fri, Sep 27, 2013 at 3:33 PM, Jeff Cai jeff_...@symantec.com wrote:**
 **

 Hi,

  

 I set up openstack environment on Ubuntu 12.0.4 with 3 nodes according to
 the starter guide on docs.openstack.org. Everything works well except
 that the VM instances cannot connect to outside. Among VM instances they
 can connect to each other.

  

 Attached the network diagram:

  

 

  

 In VM, it can ping the demo-router address 10.5.5.1 (internal) and
 10.200.29.33 (external). But it cannot ping out the other external
 addresses.

  

 Both the public and demo-net network work normally:

  

 Project   Network Name  Subnets Associated
 Shared Status   Admin State

 adminpublic   public-subnet 10.200.29.0/24
 No  Active  Up

 demodemo-net  demo-net-subnet 10.5.5.0/24
 No  Active  Up

  

 But the port where the demo router is DOWN

  

  

 (bd10e227)   10.200.29.33
 network:router_gateway  DOWN   UP

  

  

 The port info:

  
 Port
 --

 Name

 None

 ID

 bd10e227-8f83-4804-9f68-a0e643e451e5

 Network ID

 d415febb-b387-40e0-9416-32c1b19d5b46http://10.200.29.31/horizon/project/networks/d415febb-b387-40e0-9416-32c1b19d5b46/detail
 

 Project ID

 -

 Fixed IP

 *IP address:* 10.200.29.33, *Subnet ID*6781dfdc-508b-46c3-89ce-5624f95448d0
 

 Mac Address

 fa:16:3e:e2:b2:b3

 Status

 DOWN

 Admin State

 UP

 Attached Device

 *Device Owner*: network:router_gateway

 *Device ID*: 5d43330d-c0ee-4bd5-a76f-b15daad1df2e

  

  

 Could anyone please give me some clues to solve this problem?

  

 Best Regards

 * *

 *Jeff Cai*

 ** **


 ___
 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


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

Re: [openstack-dev] [LBaaS][Horizon] Subnet for VIP?

[Yongsheng Gong]

VIP can be on a different subnet than the members are on. But we need to
set up a router so that the haproxy can work.


On Tue, Sep 24, 2013 at 11:40 PM, f...@vmware.com wrote:

 I didn't know current lbaas plugin has such limitation. Although I think
 the UI should not incur such limitation as the lbaas API definition does
 allow this, I'm fine with it.

 Thanks,
 -Kaiwei

 --
 *From: *Eugene Nikanorov enikano...@mirantis.com
 *To: *OpenStack Development Mailing List 
 openstack-dev@lists.openstack.org
 *Sent: *Tuesday, September 24, 2013 2:00:33 AM
 *Subject: *Re: [openstack-dev] [LBaaS][Horizon] Subnet for VIP?


 Hi Fank,

 That looks like Horizon limitation that is bound to current reference
 implementation of lbaas service where VIP should be on a subnet where
 pool's memebers are.
 So it's not a bug. Expect this to change in Icehouse.

 Thanks,
 Eugene.



 On Tue, Sep 24, 2013 at 9:19 AM, f...@vmware.com wrote:

 Hi,

 When adding a VIP for this pool, we suppose to specify the subnet which
 the VIP will be on. However, the Horizon UI forces us to provide an IP
 address for the VIP from the subnet which we used to create the pool. That
 subnet for pool is supposed to be the subnet for pool's members, not the
 subnet for the VIP.

 This looks like a UI bug?

 Thanks,
 -Kaiwei

 ___
 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] unable to run tox due to the '--pre' argument

[Yongsheng Gong]

Hi,
I tried to run tests after I changed some codes in python neutron client,
But I failed.
Could someone please help me out?

$ tox -e py27
GLOB sdist-make: /mnt/data/opt/stack/python-neutronclient/setup.py
py27 create: /mnt/data/opt/stack/python-neutronclient/.tox/py27
py27 installdeps:
-r/mnt/data/opt/stack/python-neutronclient/requirements.txt,
-r/mnt/data/opt/stack/python-neutronclient/test-requirements.txt
ERROR: invocation failed, logfile:
/mnt/data/opt/stack/python-neutronclient/.tox/py27/log/py27-1.log
ERROR: actionid=py27
msg=getenv
cmdargs=[local('/mnt/data/opt/stack/python-neutronclient/.tox/py27/bin/pip'),
'install', '--pre',
'-r/mnt/data/opt/stack/python-neutronclient/requirements.txt',
'-r/mnt/data/opt/stack/python-neutronclient/test-requirements.txt']
...
Usage:
  pip install [options] requirement specifier ...
  pip install [options] -r requirements file ...
  pip install [options] [-e] vcs project url ...
  pip install [options] [-e] local project path ...
  pip install [options] archive url/path ...

no such option: --pre

ERROR: could not install deps
[-r/mnt/data/opt/stack/python-neutronclient/requirements.txt,
-r/mnt/data/opt/stack/python-neutronclient/test-requirements.txt]


$ tox --version
1.6.1 imported from /usr/local/lib/python2.7/dist-packages/tox/__init__.pyc
$ pip --version
pip 1.4.1 from /usr/local/lib/python2.7/dist-packages/pip-1.4.1-py2.7.egg
(python 2.7)

$ cat /etc/issue
Ubuntu 13.04 \n \l

Regards,
Yong Sheng Gong
UnitedStack Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] unable to run tox due to the '--pre' argument

[Yongsheng Gong]

Thanks for the reply.

It is weird the pip will be changed into 1.3.1 after I run tox -e py27.
Here is the process I run:

gongysh@gongysh-ThinkPad-T530:/opt/stack/python-neutronclient$
.tox/py27/bin/pip --version
pip 1.3.1 from
/mnt/data/opt/stack/python-neutronclient/.tox/py27/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg
(python 2.7)

I upgrade the pip into 1.4.1:

gongysh@gongysh-ThinkPad-T530:/opt/stack/python-neutronclient$
.tox/py27/bin/pip install -U pip
gongysh@gongysh-ThinkPad-T530:/opt/stack/python-neutronclient$
.tox/py27/bin/pip  --version
pip 1.4.1 from
/mnt/data/opt/stack/python-neutronclient/.tox/py27/lib/python2.7/site-packages
(python 2.7)
gongysh@gongysh-ThinkPad-T530:/opt/stack/python-neutronclient/.tox/py27/lib/python2.7/site-packages$
ls
easy-install.pth  pip  pip-1.4.1-py2.7.egg-info
 setuptools-0.6c11-py2.7.egg  setuptools.pth

Then I run tox -e py27 and it failed:

gongysh@gongysh-ThinkPad-T530:/mnt/data/opt/stack/python-neutronclient$ tox
-e py27
GLOB sdist-make: /mnt/data/opt/stack/python-neutronclient/setup.py
py27 create: /mnt/data/opt/stack/python-neutronclient/.tox/py27
py27 installdeps:
-r/mnt/data/opt/stack/python-neutronclient/requirements.txt,
-r/mnt/data/opt/stack/python-neutronclient/test-requirements.txt
ERROR: invocation failed, logfile:
/mnt/data/opt/stack/python-neutronclient/.tox/py27/log/py27-1.log
ERROR: actionid=py27
msg=getenv
cmdargs=[local('/mnt/data/opt/stack/python-neutronclient/.tox/py27/bin/pip'),
'install', '--pre',
'-r/mnt/data/opt/stack/python-neutronclient/requirements.txt',
'-r/mnt/data/opt/stack/python-neutronclient/test-requirements.txt']

I check the pip version in .tox:
gongysh@gongysh-ThinkPad-T530:/mnt/data/opt/stack/python-neutronclient$
 .tox/py27/bin/pip --version
pip 1.3.1 from
/mnt/data/opt/stack/python-neutronclient/.tox/py27/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg
(python 2.7)


It is changed back!!!

Regards,
Yong Sheng Gong


On Thu, Sep 19, 2013 at 9:02 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2013-09-19 08:12:47 +0800 (+0800), Yongsheng Gong wrote:
 [...]
  $ tox -e py27
 [...]
  no such option: --pre
 [...]
  $ tox --version
  1.6.1 imported from /usr/local/lib/python2.7/dist-packages/tox/
  __init__.pyc
  $ pip --version
  pip 1.4.1 from /usr/local/lib/python2.7/dist-packages/
  pip-1.4.1-py2.7.egg (python 2.7)
 [...]

 You may have an existing .tox/py27 virtualenv with an earlier
 version of pip already installed and tox is reusing it. Running
 '.tox/py27/bin/pip --version' should tell you. If you pass the -r
 switch to tox when running like 'tox -e py27 -r' it should clear any
 existing virtualenv and create a fresh one, or you can upgrade the
 pip inside it with '.tox/py27/bin/pip install -U pip' if you want.
 --
 Jeremy Stanley

 ___
 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

Re: [openstack-dev] [Neutron] - Evacuate a agent node

[Yongsheng Gong]

set the agent's admin status to False will empty up the agent's resources.
but it will not move the owned resources.


On Thu, Sep 12, 2013 at 3:36 PM, Endre Karlson endre.karl...@gmail.comwrote:

 Is it possible to get a evacuation command for a node running agents ?
 Say moving all the agents owned resources from network node a  b?

 ___
 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

Re: [openstack-dev] [Neutron] - Evacuate a agent node

[Yongsheng Gong]

To implement the 'evacuation' is also possible.


On Thu, Sep 12, 2013 at 3:43 PM, Yongsheng Gong gong...@unitedstack.comwrote:

 set the agent's admin status to False will empty up the agent's resources.
 but it will not move the owned resources.


 On Thu, Sep 12, 2013 at 3:36 PM, Endre Karlson endre.karl...@gmail.comwrote:

 Is it possible to get a evacuation command for a node running agents ?
 Say moving all the agents owned resources from network node a  b?

 ___
 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

Re: [openstack-dev] reg. Multihost dhcp feature in Havana ?

[Yongsheng Gong]

no, we don't get agreement on the implementation.
You can get some ideas from comments of
https://review.openstack.org/#/c/37919/

Yong Sheng Gong
Unitedstack Inc.


On Thu, Sep 12, 2013 at 4:57 PM, Gopi Krishna B gopi97...@gmail.com wrote:




 On Tue, Sep 10, 2013 at 1:46 PM, Gopi Krishna B gopi97...@gmail.comwrote:

 Hi
 Was looking at the below link and checking if the feature to support
 Multihost networking is part of Havana.

 https://blueprints.launchpad.net/neutron/+spec/quantum-multihost

 I couldnot find out the feature in the Havana blue print. Could you let
 me know details reg. the feature ?

 https://blueprints.launchpad.net/neutron/havana/+specs?show=all

 --
 Regards
 Gopi Krishna


 Hi
 Does anyone have info related to this feature being part of Havana.

 Thanks



 ___
 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

Re: [openstack-dev] About multihost patch review

[Yongsheng Gong]

On Thu, Aug 29, 2013 at 1:28 AM, Vishvananda Ishaya
vishvana...@gmail.comwrote:


 On Aug 26, 2013, at 6:14 PM, Maru Newby ma...@redhat.com wrote:

 
  On Aug 26, 2013, at 4:06 PM, Edgar Magana emag...@plumgrid.com wrote:
 
  Hi Developers,
 
  Let me explain my point of view on this topic and please share your
 thoughts in order to merge this new feature ASAP.
 
  My understanding is that multi-host is nova-network HA  and we are
 implementing this bp
 https://blueprints.launchpad.net/neutron/+spec/quantum-multihost for the
 same reason.
  So, If in neutron configuration admin enables multi-host:
  etc/dhcp_agent.ini
 
  # Support multi host networks
  # enable_multihost = False
 
  Why do tenants needs to be aware of this? They should just create
 networks in the way they normally do and not by adding the multihost
 extension.
 
  I was pretty confused until I looked at the nova-network HA doc [1].
  The proposed design would seem to emulate nova-network's multi-host HA
 option, where it was necessary to both run nova-network on every compute
 node and create a network explicitly as multi-host.  I'm not sure why
 nova-network was implemented in this way, since it would appear that
 multi-host is basically all-or-nothing.  Once nova-network services are
 running on every compute node, what does it mean to create a network that
 is not multi-host?

 Just to add a little background to the nova-network multi-host: The fact
 that the multi_host flag is stored per-network as opposed to a
 configuration was an implementation detail. While in theory this would
 support configurations where some networks are multi_host and other ones
 are not, I am not aware of any deployments where both are used together.

 That said, If there is potential value in offering both, it seems like it
 should be under the control of the deployer not the user. In other words
 the deployer should be able to set the default network type and enforce
 whether setting the type is exposed to the user at all.

yes, the default is not multihost, admin (by policy) can set up multihost
network


 Also, one final point. In my mind, multi-host is strictly better than
 single host, if I were to redesign nova-network today, I would get rid of
 the single host mode completely.

 problem is: the current design of neutron is single host already (If I get
your point). To do multihost automatically, it needs much effort .

 Vish

 
  So, to Edgar's question - is there a reason other than 'be like
 nova-network' for requiring neutron multi-host to be configured per-network?
 
 
  m.
 
  1:
 http://docs.openstack.org/trunk/openstack-compute/admin/content/existing-ha-networking-options.html
 
 
  I could be totally wrong and crazy, so please provide some feedback.
 
  Thanks,
 
  Edgar
 
 
  From: Yongsheng Gong gong...@unitedstack.com
  Date: Monday, August 26, 2013 2:58 PM
  To: Kyle Mestery (kmestery) kmest...@cisco.com, Aaron Rosen 
 aro...@nicira.com, Armando Migliaccio amigliac...@vmware.com, Akihiro
 MOTOKI amot...@gmail.com, Edgar Magana emag...@plumgrid.com, Maru
 Newby ma...@redhat.com, Nachi Ueno na...@nttmcl.com, Salvatore
 Orlando sorla...@nicira.com, Sumit Naiksatam 
 sumit.naiksa...@bigswitch.com, Mark McClain mark.mccl...@dreamhost.com,
 Gary Kotton gkot...@vmware.com, Robert Kukura rkuk...@redhat.com
  Cc: OpenStack List openstack-dev@lists.openstack.org
  Subject: Re: About multihost patch review
 
  Hi,
  Edgar Magana has commented to say:
  'This is the part that for me is confusing and I will need some
 clarification from the community. Do we expect to have the multi-host
 feature as an extension or something that will natural work as long as the
 deployment include more than one Network Node. In my opinion, Neutron
 deployments with more than one Network Node by default should call DHCP
 agents in all those nodes without the need to use an extension. If the
 community has decided to do this by extensions, then I am fine' at
 
 https://review.openstack.org/#/c/37919/11/neutron/extensions/multihostnetwork.py
 
  I have commented back, what is your opinion about it?
 
  Regards,
  Yong Sheng Gong
 
 
  On Fri, Aug 16, 2013 at 9:28 PM, Kyle Mestery (kmestery) 
 kmest...@cisco.com wrote:
  Hi Yong:
 
  I'll review this and try it out today.
 
  Thanks,
  Kyle
 
  On Aug 15, 2013, at 10:01 PM, Yongsheng Gong gong...@unitedstack.com
 wrote:
 
  The multihost patch is there for a long long time, can someone help
 to review?
  https://review.openstack.org/#/c/37919/
 
 
 
 
  ___
  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

Re: [openstack-dev] [neutron] Why does nova.network.neutronv2.get_client(context, admin=True) drop auth_token?

[Yongsheng Gong]

For admin, we must use admin token.  In general, the token from API context
is not of role admin.

I think the BP can help
https://blueprints.launchpad.net/keystone/+spec/reuse-token


On Thu, Aug 29, 2013 at 8:12 AM, Roman Verchikov rverchi...@mirantis.comwrote:

 Hi stackers!

 Sorry for the stupid question, but why does
 nova.network.neutronv2.get_client() [1] drop auth_token for admin? Is it
 really necessary to make another check for username/password when trying to
 get a list of ports or floating IPs?..

 When keystone is configured with LDAP backed this leads to a bunch of LDAP
 requests which tend to be quite slow. Plus those LDAP requests could have
 been simply skipped when keystone is configured with token cache enabled.

 Thanks,
 Roman

 [1]
 https://github.com/openstack/nova/blob/master/nova/network/neutronv2/__init__.py#L68
 ___
 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

Re: [openstack-dev] About multihost patch review

[Yongsheng Gong]

First 'be like nova-network' is a merit for some deployments.
second, To allow admin to decide which network will be multihosted at
runtime will enable the neutron to continue using the current network node
(dhcp agent) mode at the same time.

If we force the network multihosted when the configuration enable_multihost
is true, and then administrator wants to transfer to normal neutron way,
he/she must modify the configuration item and then restart.



On Tue, Aug 27, 2013 at 9:14 AM, Maru Newby ma...@redhat.com wrote:


 On Aug 26, 2013, at 4:06 PM, Edgar Magana emag...@plumgrid.com wrote:

  Hi Developers,
 
  Let me explain my point of view on this topic and please share your
 thoughts in order to merge this new feature ASAP.
 
  My understanding is that multi-host is nova-network HA  and we are
 implementing this bp
 https://blueprints.launchpad.net/neutron/+spec/quantum-multihost for the
 same reason.
  So, If in neutron configuration admin enables multi-host:
  etc/dhcp_agent.ini
 
  # Support multi host networks
  # enable_multihost = False
 
  Why do tenants needs to be aware of this? They should just create
 networks in the way they normally do and not by adding the multihost
 extension.

 I was pretty confused until I looked at the nova-network HA doc [1].  The
 proposed design would seem to emulate nova-network's multi-host HA option,
 where it was necessary to both run nova-network on every compute node and
 create a network explicitly as multi-host.  I'm not sure why nova-network
 was implemented in this way, since it would appear that multi-host is
 basically all-or-nothing.  Once nova-network services are running on every
 compute node, what does it mean to create a network that is not multi-host?

 So, to Edgar's question - is there a reason other than 'be like
 nova-network' for requiring neutron multi-host to be configured per-network?


 m.

 1:
 http://docs.openstack.org/trunk/openstack-compute/admin/content/existing-ha-networking-options.html


  I could be totally wrong and crazy, so please provide some feedback.
 
  Thanks,
 
  Edgar
 
 
  From: Yongsheng Gong gong...@unitedstack.com
  Date: Monday, August 26, 2013 2:58 PM
  To: Kyle Mestery (kmestery) kmest...@cisco.com, Aaron Rosen 
 aro...@nicira.com, Armando Migliaccio amigliac...@vmware.com, Akihiro
 MOTOKI amot...@gmail.com, Edgar Magana emag...@plumgrid.com, Maru
 Newby ma...@redhat.com, Nachi Ueno na...@nttmcl.com, Salvatore
 Orlando sorla...@nicira.com, Sumit Naiksatam 
 sumit.naiksa...@bigswitch.com, Mark McClain mark.mccl...@dreamhost.com,
 Gary Kotton gkot...@vmware.com, Robert Kukura rkuk...@redhat.com
  Cc: OpenStack List openstack-dev@lists.openstack.org
  Subject: Re: About multihost patch review
 
  Hi,
  Edgar Magana has commented to say:
  'This is the part that for me is confusing and I will need some
 clarification from the community. Do we expect to have the multi-host
 feature as an extension or something that will natural work as long as the
 deployment include more than one Network Node. In my opinion, Neutron
 deployments with more than one Network Node by default should call DHCP
 agents in all those nodes without the need to use an extension. If the
 community has decided to do this by extensions, then I am fine' at
 
 https://review.openstack.org/#/c/37919/11/neutron/extensions/multihostnetwork.py
 
  I have commented back, what is your opinion about it?
 
  Regards,
  Yong Sheng Gong
 
 
  On Fri, Aug 16, 2013 at 9:28 PM, Kyle Mestery (kmestery) 
 kmest...@cisco.com wrote:
  Hi Yong:
 
  I'll review this and try it out today.
 
  Thanks,
  Kyle
 
  On Aug 15, 2013, at 10:01 PM, Yongsheng Gong gong...@unitedstack.com
 wrote:
 
   The multihost patch is there for a long long time, can someone help
 to review?
   https://review.openstack.org/#/c/37919/
 
 


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

Re: [openstack-dev] About multihost patch review

[Yongsheng Gong]

Hi,
Edgar Magana has commented to say:
'This is the part that for me is confusing and I will need some
clarification from the community. Do we expect to have the multi-host
feature as an extension or something that will natural work as long as the
deployment include more than one Network Node. In my opinion, Neutron
deployments with more than one Network Node by default should call DHCP
agents in all those nodes without the need to use an extension. If the
community has decided to do this by extensions, then I am fine' at
https://review.openstack.org/#/c/37919/11/neutron/extensions/multihostnetwork.py

I have commented back, what is your opinion about it?

Regards,
Yong Sheng Gong


On Fri, Aug 16, 2013 at 9:28 PM, Kyle Mestery (kmestery) kmest...@cisco.com
 wrote:

 Hi Yong:

 I'll review this and try it out today.

 Thanks,
 Kyle

 On Aug 15, 2013, at 10:01 PM, Yongsheng Gong gong...@unitedstack.com
 wrote:

  The multihost patch is there for a long long time, can someone help to
 review?
  https://review.openstack.org/#/c/37919/


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

[openstack-dev] [keystone] Two BPs for managing the tokens

[Yongsheng Gong]

Hi,
Talked with Henry Nash and Jamie Lennox on IRC, I have created two BPs to
manage the keystone tokens:
1.
https://blueprints.launchpad.net/keystone/+spec/periodically-flush-expired-token
which is used to delete expired token
2.  https://blueprints.launchpad.net/keystone/+spec/reuse-token
which will re-use valid token

These two BPs will help us to reduce the token records in token table
enormously.

I have put some ideas on the BP description.

Any comments are welcome.


Regards,
Yong Sheng Gong
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Two BPs for managing the tokens

[Yongsheng Gong]

Hi adam,
Can u explain more about 'In conjunction with the caching layer, it might
be the right approach:  flush the old tokens upon revocation list
regeneration.'?

when is the list_revoked_tokens called?

thanks


On Sat, Aug 24, 2013 at 1:51 AM, Adam Young ayo...@redhat.com wrote:

  On 08/23/2013 12:43 PM, Joe Gordon wrote:


 On Aug 23, 2013 12:24 PM, Dolph Mathews dolph.math...@gmail.com wrote:
 
 
  On Fri, Aug 23, 2013 at 10:51 AM, Miller, Mark M (EB SW Cloud - RD -
 Corvallis) mark.m.mil...@hp.com wrote:
 
  Hello,
 
 
 
  I would think you would want to reuse the same token but update the
 expiration time as if it were the first time the token had been generated.
 
 
  That wouldn't work for PKI tokens, as the resulting signature would have
 to change.
 
 
 
 
  Mark
 
 
 
  From: Yongsheng Gong [mailto:gong...@unitedstack.com]
  Sent: Friday, August 23, 2013 12:40 AM
  To: OpenStack Development Mailing List
  Subject: [openstack-dev] [keystone] Two BPs for managing the tokens
 
 
 
  Hi,
 
  Talked with Henry Nash and Jamie Lennox on IRC, I have created two BPs
 to manage the keystone tokens:
 
  1.
 https://blueprints.launchpad.net/keystone/+spec/periodically-flush-expired-token


 Not sure that this is worth writing or maintaining.  The system services
 for Cron are much more robust, and we don;t have to maintain them.

 I do have this review for your consideration, though:

 https://review.openstack.org/#/c/43510/

 In conjunction with the caching layer, it might be the right approach:
 flush the old tokens upon revocation list regeneration.



  
  which is used to delete expired token
 
  2.  https://blueprints.launchpad.net/keystone/+spec/reuse-token
 
  which will re-use valid token
 
 
 
  These two BPs will help us to reduce the token records in token table
 enormously.
 
 
 
  I have put some ideas on the BP description.
 
 
 
  Any comments are welcome.
 

 What about Adam Young's vision for keystone, which I like,
 http://adam.younglogic.com/2013/07/a-vision-for-keystone/
 These two blueprints don't appear to be in line with it.

 Also, instead of making keystone reuse tokens why not make the token reuse
 in the clients better (keyring based).  Last I checked it was disabled and
 broken in nova (there was a patch to fix it, but keep it disabled)

 
 
 
 
  Regards,
 
  Yong Sheng Gong
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  --
 
  -Dolph
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


 ___
 OpenStack-dev mailing 
 listOpenStack-dev@lists.openstack.orghttp://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] oauth and keystone

[Yongsheng Gong]

Hi,

I have seen the code about oauth in the keystone but I cannot find the
document about how to setup keystone and other openstack services to enable
oauth.

Can anyone tell me how to setup an env like this?

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