[Yahoo-eng-team] [Bug 1837655] [NEW] glance can't be used with MySQL 8.0.17 or newer because 'member' became keyword

2019-07-23 Thread Nikita Gerasimov
Public bug reported:

Since MySQL 8.0.17 'member' is reserved keyword so it can't be column name in 
'image_members' table.
https://dev.mysql.com/doc/refman/8.0/en/keywords.html

# rpm -qf /usr/bin/glance-manage
openstack-glance-17.0.0-2.el7.noarch
$ glance-manage --config-file /etc/glance/glance-api.conf db_sync
INFO  [alembic.runtime.migration] Context impl MySQLImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
INFO  [alembic.runtime.migration] Running upgrade  -> liberty, liberty initial
CRITI [glance] Unhandled error
Traceback (most recent call last):
  File "/bin/glance-manage", line 10, in 
sys.exit(main())
  File "/usr/lib/python2.7/site-packages/glance/cmd/manage.py", line 563, in 
main
return CONF.command.action_fn()
  File "/usr/lib/python2.7/site-packages/glance/cmd/manage.py", line 395, in 
sync
self.command_object.sync(CONF.command.version)
  File "/usr/lib/python2.7/site-packages/glance/cmd/manage.py", line 165, in 
sync
self.expand(online_migration=False)
  File "/usr/lib/python2.7/site-packages/glance/cmd/manage.py", line 222, in 
expand
self._sync(version=expand_head)
  File "/usr/lib/python2.7/site-packages/glance/cmd/manage.py", line 180, in 
_sync
alembic_command.upgrade(a_config, version)
  File "/usr/lib/python2.7/site-packages/alembic/command.py", line 254, in 
upgrade
script.run_env()
  File "/usr/lib/python2.7/site-packages/alembic/script/base.py", line 425, in 
run_env
util.load_python_file(self.dir, 'env.py')
  File "/usr/lib/python2.7/site-packages/alembic/util/pyfiles.py", line 81, in 
load_python_file
module = load_module_py(module_id, path)
  File "/usr/lib/python2.7/site-packages/alembic/util/compat.py", line 141, in 
load_module_py
mod = imp.load_source(module_id, path, fp)
  File 
"/usr/lib/python2.7/site-packages/glance/db/sqlalchemy/alembic_migrations/env.py",
 line 88, in 
run_migrations_online()
  File 
"/usr/lib/python2.7/site-packages/glance/db/sqlalchemy/alembic_migrations/env.py",
 line 83, in run_migrations_online
context.run_migrations()
  File "", line 8, in run_migrations
  File "/usr/lib/python2.7/site-packages/alembic/runtime/environment.py", line 
836, in run_migrations
self.get_context().run_migrations(**kw)
  File "/usr/lib/python2.7/site-packages/alembic/runtime/migration.py", line 
330, in run_migrations
step.migration_fn(**kw)
  File 
"/usr/lib/python2.7/site-packages/glance/db/sqlalchemy/alembic_migrations/versions/liberty_initial.py",
 line 37, in upgrade
add_images_tables.upgrade()
  File 
"/usr/lib/python2.7/site-packages/glance/db/sqlalchemy/alembic_migrations/add_images_tables.py",
 line 200, in upgrade
_add_image_members_table()
  File 
"/usr/lib/python2.7/site-packages/glance/db/sqlalchemy/alembic_migrations/add_images_tables.py",
 line 155, in _add_image_members_table
extend_existing=True)
  File "", line 8, in create_table
  File "", line 3, in create_table
  File "/usr/lib/python2.7/site-packages/alembic/operations/ops.py", line 1120, 
in create_table
return operations.invoke(op)
  File "/usr/lib/python2.7/site-packages/alembic/operations/base.py", line 319, 
in invoke
return fn(self, operation)
  File "/usr/lib/python2.7/site-packages/alembic/operations/toimpl.py", line 
101, in create_table
operations.impl.create_table(table)
  File "/usr/lib/python2.7/site-packages/alembic/ddl/impl.py", line 194, in 
create_table
self._exec(schema.CreateTable(table))
  File "/usr/lib/python2.7/site-packages/alembic/ddl/impl.py", line 118, in 
_exec
return conn.execute(construct, *multiparams, **params)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
948, in execute
return meth(self, multiparams, params)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/sql/ddl.py", line 68, in 
_execute_on_connection
return connection._execute_ddl(self, multiparams, params)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
1009, in _execute_ddl
compiled
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
1200, in _execute_context
context)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
1409, in _handle_dbapi_exception
util.raise_from_cause(newraise, exc_info)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/util/compat.py", line 
203, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
1193, in _execute_context
context)
  File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py", line 
507, in do_execute
cursor.execute(statement, parameters)
  File "/usr/lib/python2.7/site-packages/pymysql/cursors.py", line 170, in 
execute
result = self._query(query)
  File "/usr/lib/python2.7/site-packages/pymysql/cursors.py", line 328, in 
_query
conn.query(q)
  File 

[Yahoo-eng-team] [Bug 1762736] [NEW] Iptables firewall driver adds forward rules for trusted ports only in the ingress direction

2018-04-10 Thread Nikita Gerasimov
Public bug reported:

Iptables firewall driver adds forward rules for trusted ports only in the 
ingress direction.
But for normal working of ports like "network:router_ha_interface" egress 
direction also required.

Version: queens
openstack-neutron-linuxbridge-12.0.1-1.el7.noarch

https://review.openstack.org/525607

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1762736

Title:
  Iptables firewall driver adds forward rules for trusted ports only in
  the ingress direction

Status in neutron:
  New

Bug description:
  Iptables firewall driver adds forward rules for trusted ports only in the 
ingress direction.
  But for normal working of ports like "network:router_ha_interface" egress 
direction also required.

  Version: queens
  openstack-neutron-linuxbridge-12.0.1-1.el7.noarch

  https://review.openstack.org/525607

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1762736/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1720205] [NEW] neutron does not create the necessary iptables rules for l3 and dhcp agents when linuxbridge used

2017-09-28 Thread Nikita Gerasimov
Public bug reported:

Version: pike
openstack-neutron-11.0.0-3.el7

Config: according to 
https://docs.openstack.org/neutron/pike/install/install-rdo.html
ml2 linuxbridge vxlan

neutron creates rules in neutron-linuxbri-FORWARD chain only for compute
ports but router and dhcp ports have no mention at all. So router and
dhcp traffic remains within host bridge.

Expected:
neutron creates rules like -A neutron-linuxbri-FORWARD -m physdev --physdev-out 
tapb48c914e-20 --physdev-is-bridged for all agents ports in bridge.


# iptables-save 
# Generated by iptables-save v1.4.21 on Thu Sep 28 18:16:57 2017
*nat
:PREROUTING ACCEPT [23760:1495817]
:INPUT ACCEPT [22739:1402147]
:OUTPUT ACCEPT [1778:116606]
:POSTROUTING ACCEPT [2260:170214]
COMMIT
# Completed on Thu Sep 28 18:16:57 2017
# Generated by iptables-save v1.4.21 on Thu Sep 28 18:16:57 2017
*mangle
:PREROUTING ACCEPT [922003:1129881715]
:INPUT ACCEPT [906034:1128976690]
:FORWARD ACCEPT [20488:1851370]
:OUTPUT ACCEPT [774093:3908358570]
:POSTROUTING ACCEPT [793969:3910141934]
COMMIT
# Completed on Thu Sep 28 18:16:57 2017
# Generated by iptables-save v1.4.21 on Thu Sep 28 18:16:57 2017
*raw
:PREROUTING ACCEPT [922261:1129974352]
:OUTPUT ACCEPT [774348:3908396136]
:neutron-linuxbri-OUTPUT - [0:0]
:neutron-linuxbri-PREROUTING - [0:0]
-A PREROUTING -j neutron-linuxbri-PREROUTING
-A OUTPUT -j neutron-linuxbri-OUTPUT
COMMIT
# Completed on Thu Sep 28 18:16:57 2017
# Generated by iptables-save v1.4.21 on Thu Sep 28 18:16:57 2017
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [27196:421070402]
:neutron-filter-top - [0:0]
:neutron-linuxbri-FORWARD - [0:0]
:neutron-linuxbri-INPUT - [0:0]
:neutron-linuxbri-OUTPUT - [0:0]
:neutron-linuxbri-local - [0:0]
:neutron-linuxbri-sg-chain - [0:0]
:neutron-linuxbri-sg-fallback - [0:0]
-A INPUT -j neutron-linuxbri-INPUT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j neutron-filter-top
-A FORWARD -j neutron-linuxbri-FORWARD
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -j neutron-filter-top
-A OUTPUT -j neutron-linuxbri-OUTPUT
-A neutron-filter-top -j neutron-linuxbri-local
-A neutron-linuxbri-FORWARD -m physdev --physdev-out tapb48c914e-20 
--physdev-is-bridged -m comment --comment "Accept all packets when port 
security is disabled." -j ACCEPT
-A neutron-linuxbri-FORWARD -m physdev --physdev-in tapb48c914e-20 
--physdev-is-bridged -m comment --comment "Accept all packets when port 
security is disabled." -j ACCEPT
-A neutron-linuxbri-INPUT -m physdev --physdev-in tapb48c914e-20 
--physdev-is-bridged -m comment --comment "Accept all packets when port 
security is disabled." -j ACCEPT
-A neutron-linuxbri-sg-chain -j ACCEPT
-A neutron-linuxbri-sg-fallback -m comment --comment "Default drop rule for 
unmatched traffic." -j DROP
COMMIT
# Completed on Thu Sep 28 18:16:57 2017

# brctl show
bridge name bridge id   STP enabled interfaces
brq76f218a0-55  8000.1a1da1c5730b   no  tap5015bfe4-c5
tapa6d0f381-b7
tapb48c914e-20
vxlan-1006
brq8856ee40-24  8000.921ccb87ce25   no  tap8d487e05-d8
vxlan-1043

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1720205

Title:
  neutron does not create the necessary iptables rules for l3 and dhcp
  agents when linuxbridge used

Status in neutron:
  New

Bug description:
  Version: pike
  openstack-neutron-11.0.0-3.el7

  Config: according to 
https://docs.openstack.org/neutron/pike/install/install-rdo.html
  ml2 linuxbridge vxlan

  neutron creates rules in neutron-linuxbri-FORWARD chain only for
  compute ports but router and dhcp ports have no mention at all. So
  router and dhcp traffic remains within host bridge.

  Expected:
  neutron creates rules like -A neutron-linuxbri-FORWARD -m physdev 
--physdev-out tapb48c914e-20 --physdev-is-bridged for all agents ports in 
bridge.

  
  # iptables-save 
  # Generated by iptables-save v1.4.21 on Thu Sep 28 18:16:57 2017
  *nat
  :PREROUTING ACCEPT [23760:1495817]
  :INPUT ACCEPT [22739:1402147]
  :OUTPUT ACCEPT [1778:116606]
  :POSTROUTING ACCEPT [2260:170214]
  COMMIT
  # Completed on Thu Sep 28 18:16:57 2017
  # Generated by iptables-save v1.4.21 on Thu Sep 28 18:16:57 2017
  *mangle
  :PREROUTING ACCEPT [922003:1129881715]
  :INPUT ACCEPT [906034:1128976690]
  :FORWARD ACCEPT [20488:1851370]
  :OUTPUT ACCEPT [774093:3908358570]
  :POSTROUTING ACCEPT 

[Yahoo-eng-team] [Bug 1717927] [NEW] neutron does not create the necessary forward rules for HA network

2017-09-18 Thread Nikita Gerasimov
Public bug reported:

neutron version - 10.0.3
ml2 linuxbridge
tenant network type - VXLAN
firewall driver - iptables

When HA router used neutron automatically create HA network per project
but miss appropriate forward rules configuration so router instances in
network namespaces can't reach each other by HA address and go to active
state simultaneously.

As workaround you cat read l3_ha_net_cidr option and tune iptables
config on router nodes.

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1717927

Title:
  neutron does not create the necessary forward rules for HA network

Status in neutron:
  New

Bug description:
  neutron version - 10.0.3
  ml2 linuxbridge
  tenant network type - VXLAN
  firewall driver - iptables

  When HA router used neutron automatically create HA network per
  project but miss appropriate forward rules configuration so router
  instances in network namespaces can't reach each other by HA address
  and go to active state simultaneously.

  As workaround you cat read l3_ha_net_cidr option and tune iptables
  config on router nodes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1717927/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1655662] [NEW] libvirt xen hvm guests can't hot plug (attach detach) default block devices

2017-01-11 Thread Nikita Gerasimov
Public bug reported:

Currently default disk bus for libvirt+Xen HVM guests is "ide", which
not allow hot reconfiguration. So images without special metadata
property specifying bus can't be attached or detached.

https://github.com/openstack/nova/blob/ad1c7ac2b102112280a25927d731edb168f80998/nova/virt/libvirt/blockinfo.py#L250

At the same time QEMU/KVM guests have "virtio" as default disk bus for
disk which is QEMU analog of "xen" bus for XEN.

Fix looks trivial and require only delete XEN HVM specific part to
return "xen" as default part in all cases. User will be able to use
other buses by metadata and only when it's really required.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: libvirt xen

** Tags added: libvirt xen

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1655662

Title:
  libvirt xen hvm guests can't  hot plug (attach detach) default block
  devices

Status in OpenStack Compute (nova):
  New

Bug description:
  Currently default disk bus for libvirt+Xen HVM guests is "ide", which
  not allow hot reconfiguration. So images without special metadata
  property specifying bus can't be attached or detached.

  
https://github.com/openstack/nova/blob/ad1c7ac2b102112280a25927d731edb168f80998/nova/virt/libvirt/blockinfo.py#L250

  At the same time QEMU/KVM guests have "virtio" as default disk bus for
  disk which is QEMU analog of "xen" bus for XEN.

  Fix looks trivial and require only delete XEN HVM specific part to
  return "xen" as default part in all cases. User will be able to use
  other buses by metadata and only when it's really required.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1655662/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1441083] Re: pkg_resources.DistributionNotFound: The 'argparse' distribution was not found and is required by oslo.config, python-keystoneclient, pysaml2

2015-04-07 Thread Nikita Gerasimov
** Also affects: python-openstackclient
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1441083

Title:
  pkg_resources.DistributionNotFound: The 'argparse' distribution was
  not found and is required by oslo.config, python-keystoneclient,
  pysaml2

Status in OpenStack Identity (Keystone):
  New
Status in OpenStack Command Line Client:
  New

Bug description:
  Hi,

  When trying to install a fresh DevStack, I got issues with pip 6.1. First 
issue:
  https://bugs.launchpad.net/tempest/+bug/1440984

  I worked around the first issue, but then I got this issue:

  2015-04-07 10:08:34.084 | + /usr/bin/keystone-manage db_sync
  2015-04-07 10:08:34.239 | Traceback (most recent call last):
  2015-04-07 10:08:34.239 |   File /usr/bin/keystone-manage, line 4, in 
module
  2015-04-07 10:08:34.239 | 
__import__('pkg_resources').require('keystone==2015.1.dev143')
  2015-04-07 10:08:34.239 |   File 
/usr/lib/python2.7/site-packages/pkg_resources/__init__.py, line 3057, in 
module
  2015-04-07 10:08:34.239 | working_set = WorkingSet._build_master()
  2015-04-07 10:08:34.240 |   File 
/usr/lib/python2.7/site-packages/pkg_resources/__init__.py, line 639, in 
_build_master
  2015-04-07 10:08:34.240 | ws.require(__requires__)
  2015-04-07 10:08:34.240 |   File 
/usr/lib/python2.7/site-packages/pkg_resources/__init__.py, line 940, in 
require
  2015-04-07 10:08:34.240 | needed = 
self.resolve(parse_requirements(requirements))
  2015-04-07 10:08:34.240 |   File 
/usr/lib/python2.7/site-packages/pkg_resources/__init__.py, line 827, in 
resolve
  2015-04-07 10:08:34.240 | raise DistributionNotFound(req, requirers)
  2015-04-07 10:08:34.241 | pkg_resources.DistributionNotFound: The 'argparse' 
distribution was not found and is required by oslo.config, 
python-keystoneclient, pysaml2

  The problem is that newly released pip 6.1 doesn't want to install
  argparse because argparse is part of the Python standard library:

  fedora@myhost$ pip install argparse
  Skipping requirement: argparse because argparse is a stdlib package
  You must give at least one requirement to install (see pip help install)

  Workaround: downgrade pip to 6.0.8 and install argparse using pip (pip
  install argparse).

  A better fix is maybe to make argparse optional in keystone
  requirements? It's now possible to add environment markers to
  dependencies. Example:

  futures; python_version  '2.7'

  See https://github.com/pypa/pip/pull/1472

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1441083/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp