[Openstack] network question on openstack installation
Uwe Sauter
uwe.sauter.de at gmail.com
Mon Jun 29 23:48:39 UTC 2015
You should use the same IP addresses that are configured for the tunnel. It is expected that this scan takes some time as it iterates over all available network protocols.
It is a bit concerning that GRE is listed as filtered. But now we are moving into uncertain/unknown terrain. Perhaps somebody else can jump in now?
Am 30. Juni 2015 01:35:14 MESZ, schrieb "Yngvi Páll Þorfinnsson" <yngvith at siminn.is>:
>root at network2:/# nmap -sO compute5
>
>Starting Nmap 6.40 ( http://nmap.org ) at 2015-06-29 23:29 GMT
>Nmap scan report for compute5 (172.22.14.17)
>Host is up (0.00014s latency).
>rDNS record for 172.22.14.17: compute5.siminn.is
>Not shown: 245 closed protocols
>PROTOCOL STATE SERVICE
>1 open icmp
>2 open|filtered igmp
>6 open tcp
>17 open udp
>47 open|filtered gre
>96 open scc-sp
>103 open|filtered pim
>136 open|filtered udplite
>166 open unknown
>182 open unknown
>255 open|filtered unknown
>MAC Address: 0C:C4:7A:1E:77:7E (Unknown)
>
>Nmap done: 1 IP address (1 host up) scanned in 310.51 seconds
>
>
>-----Original Message-----
>From: Yngvi Páll Þorfinnsson
>Sent: 29. júní 2015 23:35
>To: 'Uwe Sauter'; 'YANG LI'
>Cc: 'openstack at lists.openstack.org'
>Subject: RE: [Openstack] network question on openstack installation
>
>It's taking up to 5 minutes to finish
>
>root at compute5:/# nmap -sO 172.22.14.14
>
>Starting Nmap 6.40 ( http://nmap.org ) at 2015-06-29 23:28 GMT
>Warning: 172.22.14.14 giving up on port because retransmission cap hit
>(10).
>Nmap scan report for network2.siminn.is (172.22.14.14) Host is up
>(0.000091s latency).
>Not shown: 246 closed protocols
>PROTOCOL STATE SERVICE
>1 open icmp
>2 open|filtered igmp
>6 open tcp
>7 open|filtered cbt
>17 open udp
>36 open xtp
>47 open|filtered gre
>103 open|filtered pim
>136 open|filtered udplite
>255 open|filtered unknown
>MAC Address: 0C:C4:7A:1E:77:3D (Unknown)
>
>Nmap done: 1 IP address (1 host up) scanned in 307.19 seconds
>
>
>
>-----Original Message-----
>From: Yngvi Páll Þorfinnsson
>Sent: 29. júní 2015 23:28
>To: 'Uwe Sauter'; YANG LI
>Cc: openstack at lists.openstack.org
>Subject: RE: [Openstack] network question on openstack installation
>
>Well this one finished finally
>
>Should I use the tunnel or mgmt IP ?
>
>root at compute5:/# nmap -sO 172.22.15.14
>
>Starting Nmap 6.40 ( http://nmap.org ) at 2015-06-29 23:21 GMT
>Warning: 172.22.15.14 giving up on port because retransmission cap hit
>(10).
>Nmap scan report for 172.22.15.14
>Host is up (0.00017s latency).
>Not shown: 247 closed protocols
>PROTOCOL STATE SERVICE
>1 open icmp
>2 open|filtered igmp
>6 open tcp
>17 open udp
>47 open|filtered gre
>54 open narp
>103 open|filtered pim
>136 open|filtered udplite
>144 open unknown
>MAC Address: 0C:C4:7A:1E:77:3D (Unknown)
>
>Nmap done: 1 IP address (1 host up) scanned in 297.15 seconds
>root at compute5:/#
>
>
>
>-----Original Message-----
>From: Uwe Sauter [mailto:uwe.sauter.de at gmail.com]
>Sent: 29. júní 2015 23:18
>To: Yngvi Páll Þorfinnsson; YANG LI
>Cc: openstack at lists.openstack.org
>Subject: RE: [Openstack] network question on openstack installation
>
>Hm, I'm running out of ideas. Can you run those two commands to verify
>that GRE traffic can pass the firewalls:
>
>Network node: nmap -sO <IP of compute node>
>
>Compute node: nmap -sO <IP of network node>
>
>In both cases, that's a big o, not a zero.
>
>Am 30. Juni 2015 01:07:04 MESZ, schrieb "Yngvi Páll Þorfinnsson"
><yngvith at siminn.is>:
>>OK, so I ran the command you sent me , and now it looks it‘s allowed,
>>
>>Controller:
>>
>>root at controller2:/# iptables -L -nv --line-numbers Chain INPUT (policy
>
>>ACCEPT 6437 packets, 2609K bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 54411 17M nova-api-INPUT all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>2 0 0 ACCEPT 47 -- * * 172.22.15.0/24
>
>> 172.22.15.0/24
>>
>>Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 0 0 nova-filter-top all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>2 0 0 nova-api-FORWARD all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>
>>Chain OUTPUT (policy ACCEPT 6228 packets, 2573K bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 51439 16M nova-filter-top all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>2 51439 16M nova-api-OUTPUT all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>
>>Chain nova-api-FORWARD (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>Chain nova-api-INPUT (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 0 0 ACCEPT tcp -- * * 0.0.0.0/0
>
>> 172.22.14.22 tcp dpt:8775
>>
>>Chain nova-api-OUTPUT (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>Chain nova-api-local (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>Chain nova-filter-top (2 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 51439 16M nova-api-local all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>root at controller2:/#
>>
>>
>>Network:
>>
>>root at network2:/# iptables -L -nv --line-numbers Chain INPUT (policy
>>ACCEPT 8 packets, 512 bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 2215 700K neutron-openvswi-INPUT all -- * *
>>0.0.0.0/0 0.0.0.0/0
>>2 0 0 ACCEPT 47 -- * * 172.22.15.0/24
>
>> 172.22.15.0/24
>>
>>Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 0 0 neutron-filter-top all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>2 0 0 neutron-openvswi-FORWARD all -- * *
>>0.0.0.0/0 0.0.0.0/0
>>
>>Chain OUTPUT (policy ACCEPT 5 packets, 664 bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 1827 332K neutron-filter-top all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>2 1827 332K neutron-openvswi-OUTPUT all -- * *
>>0.0.0.0/0 0.0.0.0/0
>>
>>Chain neutron-filter-top (2 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 1827 332K neutron-openvswi-local all -- * *
>>0.0.0.0/0 0.0.0.0/0
>>
>>Chain neutron-openvswi-FORWARD (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>Chain neutron-openvswi-INPUT (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>Chain neutron-openvswi-OUTPUT (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>Chain neutron-openvswi-local (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>Chain neutron-openvswi-sg-chain (0 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>Chain neutron-openvswi-sg-fallback (0 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 0 0 DROP all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>root at network2:/#
>>
>>compute:
>>
>>root at compute5:/# iptables -L -nv --line-numbers Chain INPUT (policy
>>ACCEPT 24 packets, 7092 bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0
>
>> 0.0.0.0/0 udp dpt:53
>>2 0 0 ACCEPT 47 -- * * 172.22.15.0/24
>
>> 172.22.15.0/24
>>3 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0
>
>> 0.0.0.0/0 tcp dpt:53
>>4 0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0
>
>> 0.0.0.0/0 udp dpt:67
>>5 0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0
>
>> 0.0.0.0/0 tcp dpt:67
>>
>>Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 0 0 ACCEPT all -- * virbr0 0.0.0.0/0
>
>> 192.168.122.0/24 ctstate RELATED,ESTABLISHED
>>2 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24
>
>> 0.0.0.0/0
>>3 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0
>
>> 0.0.0.0/0
>>4 0 0 REJECT all -- * virbr0 0.0.0.0/0
>
>> 0.0.0.0/0 reject-with icmp-port-unreachable
>>5 0 0 REJECT all -- virbr0 * 0.0.0.0/0
>
>> 0.0.0.0/0 reject-with icmp-port-unreachable
>>
>>Chain OUTPUT (policy ACCEPT 14 packets, 2340 bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 0 0 ACCEPT udp -- * virbr0 0.0.0.0/0
>
>> 0.0.0.0/0 udp dpt:68
>>
>>
>>I tried once more to create an instance, but if failed as well
>>
>>Best regards
>>Yngvi
>>
>>From: Uwe Sauter [mailto:uwe.sauter.de at gmail.com]
>>Sent: 29. júní 2015 23:01
>>To: Yngvi Páll Þorfinnsson; YANG LI
>>Cc: openstack at lists.openstack.org
>>Subject: RE: [Openstack] network question on openstack installation
>>
>>I'm not sure if there is something wrong but on both hosts I don't see
>
>>any rule that accepts GRE traffic. You need to allow GRE traffic on
>>your internal network so that tunneling can actually work. Without
>that
>>it's like having your network configured but not plugged in...
>>Am 30. Juni 2015 00:50:28 MESZ, schrieb "Yngvi Páll Þorfinnsson"
>><yngvith at siminn.is<mailto:yngvith at siminn.is>>:
>>Network node:
>>
>>
>>root at network2:/# iptables -L -nv --line-numbers Chain INPUT (policy
>>ACCEPT 1286 packets, 351K bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 1171 338K neutron-openvswi-INPUT all -- * *
>>0.0.0.0/0 0.0.0.0/0
>>
>>
>>Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 0 0 neutron-filter-top all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>2 0 0 neutron-openvswi-FORWARD all -- * *
>>0.0.0.0/0 0.0.0.0/0
>>
>>
>>Chain OUTPUT (policy ACCEPT 1124 packets, 180K bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 988 164K neutron-filter-top all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>2 988 164K neutron-openvswi-OUTPUT all -- * *
>>0.0.0.0/0 0.0.0.0/0
>>
>>
>>Chain neutron-filter-top (2 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 988 164K neutron-openvswi-local all -- * *
>>0.0.0.0/0 0.0.0.0/0
>>
>>
>>Chain neutron-openvswi-FORWARD (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>
>>Chain neutron-openvswi-INPUT (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>
>>Chain neutron-openvswi-OUTPUT (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>
>>Chain neutron-openvswi-local (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>
>>Chain neutron-openvswi-sg-chain (0 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>
>>Chain neutron-openvswi-sg-fallback (0 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 0 0 DROP all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>root at network2:/#
>>
>>
>>Controller node
>>
>>
>>root at controller2:/# iptables -L -nv --line-numbers Chain INPUT (policy
>
>>ACCEPT 25498 packets, 7540K bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 25498 7540K nova-api-INPUT all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>
>>
>>Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 0 0 nova-filter-top all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>2 0 0 nova-api-FORWARD all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>
>>
>>Chain OUTPUT (policy ACCEPT 24216 packets, 7244K bytes)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 24216 7244K nova-filter-top all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>2 24216 7244K nova-api-OUTPUT all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>
>>
>>Chain nova-api-FORWARD (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>
>>Chain nova-api-INPUT (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 0 0 ACCEPT tcp -- * * 0.0.0.0/0
>
>> 172.22.14.22 tcp dpt:8775
>>
>>
>>Chain nova-api-OUTPUT (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>
>>Chain nova-api-local (1 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>
>>
>>Chain nova-filter-top (2 references)
>>num pkts bytes target prot opt in out source
>
>> destination
>>1 24216 7244K nova-api-local all -- * * 0.0.0.0/0
>
>> 0.0.0.0/0
>>root at controller2:/#
>>
>>
>>
>>
>>
>>
>>From: Uwe Sauter [mailto:uwe.sauter.de at gmail.com]
>>Sent: 29. júní 2015 22:46
>>To: Yngvi Páll Þorfinnsson; YANG LI
>>Cc:
>openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
>>Subject: RE: [Openstack] network question on openstack installation
>>
>>
>>One more thing. Please provide
>>
>>iptables -L -nv --line-numbers
>>
>>for network and compute nodes.
>>Am 30. Juni 2015 00:25:45 MESZ, schrieb "Yngvi Páll Þorfinnsson"
>><yngvith at siminn.is<mailto:yngvith at siminn.is>>:
>>In fact, I don‘t think I‘ll need more than one „external network“ so,
>>am I on the wrong path here, i.e. when I‘m configuing the external
>>network as a VLAN ?
>>
>>
>>Best regards
>>Yngvi
>>
>>
>>From: Yngvi Páll Þorfinnsson
>>Sent: 29. júní 2015 21:57
>>To: Uwe Sauter; YANG LI
>>Cc:
>openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
>>Subject: Re: [Openstack] network question on openstack installation
>>
>>
>>OK, I only found one fresh error
>>Compute node; nova-compute.log ( as usually when I create instance)
>>
>>
>>grep ERR nova-compute.log
>>2015-06-29 21:11:11.801 4166 ERROR nova.compute.manager [-] [instance:
>>af901a2b-2462-4c19-b1f1-237371fd8177] Instance failed to spawn
>>
>>
>>I‘ve attached the neutron agent-show and neutron (sub)net-list in the
>
>>attached file.
>>
>>
>>Best regards
>>Yngvi
>>
>>
>>
>>
>>From: Uwe Sauter [mailto:uwe.sauter.de at gmail.com]
>>Sent: 29. júní 2015 21:34
>>To: Yngvi Páll Þorfinnsson; YANG LI
>>Cc:
>openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
>>Subject: RE: [Openstack] network question on openstack installation
>>
>>
>>Can you check for ERRORs in:
>>Network node: neutron server log, neutron openvswitch agent log,
>>openvswitch log Nova controller node: nova api log, nova scheduler log
>
>>Compute node: nova compute log, neutron openvswitch agent log,
>>openvswitch log
>>
>>Also please list again neutron agent-show for the different agents and
>
>>neutron net-show and neutron subnet-show for your (sub)networks.
>>Am 29. Juni 2015 23:24:48 MESZ, schrieb "Yngvi Páll Þorfinnsson"
>><yngvith at siminn.is<mailto:yngvith at siminn.is>>:
>>Thanks a lot for your effort Uwe ;-)
>>It‘s relly helpful !
>>
>>
>>Now , I keep creating instances, and have the same error.
>>I still get a strange comment in the
>>Neutron server.log file when I try to create an instance:
>>
>>
>>2015-06-29 21:11:11.576 1960 DEBUG
>>neutron.plugins.ml2.drivers.mech_openvswitch
>>[req-1e603e4b-61e6-4896-8f81-208daba8569b None] Checking segment:
>>{'segmentation_id': 1102L, 'physical_network': u'external', 'id':
>>u'11fab5ad-c457-4175-9e5a-f505fc0e072d', 'network_type': u'vlan'} for
>>mappings: {u'external': u'br-ex'} with tunnel_types: [u'gre']
>>check_segment_for_agent
>>/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/mech_openv
>>switch.py:52
>>
>>
>>But still this segment is not listed for ‚neutron net-list‘ nor
>>‚neutron-subnet-list‘ !
>>
>>
>>
>>
>>root at controller2:/# source admin-openrc.sh root at controller2:/#
>>root at controller2:/# neutron net-list
>>+--------------------------------------+-------------+-----------------------------------------------------+
>>| id | name | subnets
>
>> |
>>+--------------------------------------+-------------+-----------------------------------------------------+
>>| b43da44a-42d5-4b1f-91c2-d06a923deb29 | ext_net1101 |
>>c40fa8e3-cd8e-4566-ade6-5f3eabed121c 157.157.8.0/24 |
>>| 3446e54b-346f-45e5-89a2-1ec4eef251ab | demo-net |
>>2c79bb00-0ace-4319-8151-81210ee3dfb2 172.22.18.0/24 |
>>+--------------------------------------+-------------+-----------------------------------------------------+
>>root at controller2:/#
>>root at controller2:/# neutron subnet-list
>>+--------------------------------------+--------------------+----------------+---------------------------------------------------+
>>| id | name | cidr
>
>> | allocation_pools |
>>+--------------------------------------+--------------------+----------------+---------------------------------------------------+
>>| c40fa8e3-cd8e-4566-ade6-5f3eabed121c | ext_net1101-subnet |
>>157.157.8.0/24 | {"start": "157.157.8.51", "end": "157.157.8.250"} |
>>| 2c79bb00-0ace-4319-8151-81210ee3dfb2 | demo-subnet |
>>172.22.18.0/24 | {"start": "172.22.18.2", "end": "172.22.18.254"} |
>>+--------------------------------------+--------------------+----------------+---------------------------------------------------+
>>
>>
>>
>>
>>And the output of listing it is empty:
>>
>>
>>root at controller2:/# neutron net-show
>>11fab5ad-c457-4175-9e5a-f505fc0e072d
>>Unable to find network with name
>'11fab5ad-c457-4175-9e5a-f505fc0e072d'
>>root at controller2:/#
>>root at controller2:/# source demo-openrc.sh root at controller2:/# neutron
>>net-show 11fab5ad-c457-4175-9e5a-f505fc0e072d
>>Unable to find network with name
>'11fab5ad-c457-4175-9e5a-f505fc0e072d'
>>
>>
>>This is after I have dropped the neutron, and resynced....
>>
>>
>>Best regards
>>Yngvi
>>
>>
>>From: Uwe Sauter [mailto:uwe.sauter.de at gmail.com]
>>Sent: 29. júní 2015 21:16
>>To: Yngvi Páll Þorfinnsson; YANG LI
>>Cc:
>openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
>>Subject: RE: [Openstack] network question on openstack installation
>>
>>
>>Yes. Just keep in mind that if you extend your configuration with a
>new
>>config file, then you must change your init script / unit file to
>>reference that file. And it would probably be a good idea to re-sync
>>the DB with that additional file as an option. Or you keep your plugin
>
>>configuration in a single file and be happy with the current layout.
>>Am 29. Juni 2015 22:47:22 MESZ, schrieb "Yngvi Páll Þorfinnsson"
>><yngvith at siminn.is<mailto:yngvith at siminn.is>>:
>>
>>Hi Uwe
>>
>>I just ran this some minutes ago, i.e. did the "population of db"
>>again,
>>According to the manual.
>>Should'nt this be enough ?
>>
>>
>>root at controller2:/# su -s /bin/sh -c "neutron-db-manage --config-file
>>/etc/neutron/neutron.conf \
>>
>>--config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade juno"
>>neutron
>>
>>INFO [alembic.migration] Context impl MySQLImpl.
>>INFO [alembic.migration] Will assume non-transactional DDL.
>>INFO [alembic.migration] Running upgrade None -> havana,
>>havana_initial INFO [alembic.migration] Running upgrade havana ->
>>e197124d4b9, add unique constraint to members INFO
>[alembic.migration]
>>Running upgrade e197124d4b9 -> 1fcfc149aca4, Add a unique constraint
>on
>>(agent_type, host) columns to prevent a race condition when an agent
>>
>>entry is 'upserted'.
>>INFO [alembic.migration] Running upgrade 1fcfc149aca4 ->
>50e86cb2637a,
>>nsx_mappings INFO [alembic.migration] Running upgrade 50e86cb2637a ->
>
>>1421183d533f, NSX DHCP/metadata support INFO [alembic.migration]
>>Running upgrade 1421183d533f -> 3d3cb89d84ee, nsx_switch_mappings INFO
>
>>[alembic.migration] Running upgrade 3d3cb89d84ee -> 4ca36cfc898c,
>>nsx_router_mappings INFO [alembic.migration] Running upgrade
>>4ca36cfc898c -> 27cc183af192, ml2_vnic_type INFO [alembic.migration]
>>Running upgrade 27cc183af192 -> 50d5ba354c23,
>>ml2 binding:vif_details
>>INFO [alembic.migration] Running upgrade 50d5ba354c23 ->
>157a5d299379,
>>ml2 binding:profile
>>INFO [alembic.migration] Running upgrade 157a5d299379 ->
>3d2585038b95,
>>VMware NSX rebranding INFO [alembic.migration] Running upgrade
>>3d2585038b95 -> abc88c33f74f, lb stats INFO
>>
>>[alembic.migration]
>>
>>Running upgrade abc88c33f74f -> 1b2580001654,
>>
>>nsx_sec_group_mapping
>>INFO [alembic.migration] Running upgrade 1b2580001654 -> e766b19a3bb,
>
>>nuage_initial INFO [alembic.migration] Running upgrade e766b19a3bb ->
>
>>2eeaf963a447, floatingip_status INFO [alembic.migration] Running
>>upgrade 2eeaf963a447 -> 492a106273f8, Brocade ML2 Mech. Driver INFO
>>[alembic.migration] Running upgrade 492a106273f8 -> 24c7ea5160d7,
>Cisco
>>CSR VPNaaS INFO [alembic.migration] Running upgrade 24c7ea5160d7 ->
>>81c553f3776c, bsn_consistencyhashes INFO [alembic.migration] Running
>>upgrade 81c553f3776c -> 117643811bca,
>>nec: delete old ofc mapping tables
>>INFO [alembic.migration] Running upgrade 117643811bca ->
>19180cf98af6,
>>nsx_gw_devices INFO [alembic.migration] Running upgrade 19180cf98af6
>>-> 33dd0a9fa487, embrane_lbaas_driver INFO [alembic.migration]
>Running
>>upgrade 33dd0a9fa487 -> 2447ad0e9585, Add IPv6 Subnet properties INFO
>>[alembic.migration] Running upgrade 2447ad0e9585
>>
>>-> 538732fa21e1, NEC Rename quantum_id to neutron_id
>>INFO [alembic.migration] Running upgrade 538732fa21e1 ->
>5ac1c354a051,
>>n1kv segment allocs for cisco n1kv plugin INFO [alembic.migration]
>>Running upgrade 5ac1c354a051 -> icehouse, icehouse INFO
>>[alembic.migration] Running upgrade icehouse -> 54f7549a0e5f,
>>set_not_null_peer_address INFO [alembic.migration] Running upgrade
>>54f7549a0e5f -> 1e5dd1d09b22, set_not_null_fields_lb_stats INFO
>>[alembic.migration] Running upgrade 1e5dd1d09b22 -> b65aa907aec,
>>set_length_of_protocol_field INFO [alembic.migration] Running upgrade
>
>>b65aa907aec -> 33c3db036fe4, set_length_of_description_field_metering
>>INFO [alembic.migration] Running upgrade 33c3db036fe4 ->
>4eca4a84f08a,
>>Remove ML2 Cisco Credentials DB INFO [alembic.migration] Running
>>upgrade 4eca4a84f08a -> d06e871c0d5,
>>set_admin_state_up_not_null_ml2
>>INFO
>>
>>[alembic.migration] Running upgrade d06e871c0d5 ->
>>
>>6be312499f9, set_not_null_vlan_id_cisco INFO [alembic.migration]
>>Running upgrade 6be312499f9 -> 1b837a7125a9, Cisco APIC Mechanism
>>Driver INFO [alembic.migration]
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
More information about the Openstack
mailing list