date:20161101

[Yahoo-eng-team] [Bug 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

2016-11-01 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/392125
Committed: 
https://git.openstack.org/cgit/openstack/zun/commit/?id=afe2b6fa12a631eb7912e93806e5f1ac0f4efc0b
Submitter: Jenkins
Branch:master

commit afe2b6fa12a631eb7912e93806e5f1ac0f4efc0b
Author: xxj 
Date:   Tue Nov 1 20:21:23 2016 +0800

Replace assertEqual(None, *) with assertIsNone

Replace assertEqual(None, *) with assertIsNone in tests to have
more clear messages in case of failure.

Closes-Bug:#1280522
Change-Id: Ib7a24bf7443d9c49e42119c649a32a1e8bd20ba1


** Changed in: zun
   Status: In Progress => Fix Released

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

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in anvil:
  New
Status in bifrost:
  Fix Released
Status in Blazar:
  In Progress
Status in Cinder:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in dox:
  New
Status in DragonFlow:
  New
Status in Freezer:
  New
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in Heat Translator:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in kolla-mesos:
  Fix Released
Status in Manila:
  Fix Released
Status in networking-brocade:
  New
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  Fix Released
Status in ooi:
  Fix Released
Status in os-brick:
  Fix Released
Status in os-client-config:
  Fix Released
Status in oslo.messaging:
  Fix Released
Status in python-barbicanclient:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-cueclient:
  Fix Released
Status in python-designateclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in python-swiftclient:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Quark: Money Reinvented:
  New
Status in Sahara:
  Fix Released
Status in OpenStack Search (Searchlight):
  Fix Released
Status in Solum:
  Fix Released
Status in Stackalytics:
  Fix Released
Status in OpenStack Object Storage (swift):
  Invalid
Status in taskflow:
  Fix Released
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in tuskar:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released
Status in Zun:
  Fix Released
Status in designate package in Ubuntu:
  Fix Released
Status in python-tuskarclient package in Ubuntu:
  Fix Committed

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1480941] Re: Hyper-V: Driver does not check if live migration is possible to destination node

2016-11-01 Thread Launchpad Bug Tracker

[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

** Changed in: nova
   Status: Incomplete => Expired

-- 
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/1480941

Title:
  Hyper-V: Driver does not check if live migration is possible to
  destination node

Status in OpenStack Compute (nova):
  Expired

Bug description:
  Hyper-V Driver does not check whether it can live migrate instances to
  the given destination [1], meaning that all destinations are valid for
  the operation, including nodes which are not in the same Active
  Directory. Attempting to live migrate to another host in another AD
  will cause the operation to fail. [2]

  
  [1] 
https://github.com/openstack/nova/blob/master/nova/virt/hyperv/livemigrationops.py#L119

  [2] http://paste.openstack.org/show/406766/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1480941/+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 1624784] Re: Fix missing i18n support for help text

2016-11-01 Thread liwei

** Also affects: python-glanceclient
   Importance: Undecided
   Status: New

** Changed in: python-glanceclient
 Assignee: (unassigned) => liwei (wei-li)

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

Title:
  Fix missing i18n support for help text

Status in Glance:
  In Progress
Status in python-glanceclient:
  New

Bug description:
  There are some missing translations for help text in glance.We should
  use i18n to wrap help text with _(),so the text will get translated.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1624784/+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 1621615] Re: network not configured when ipv6 netbooted into cloud-init

2016-11-01 Thread LaMont Jones

My currently-pending MPs address the issue and work in conjunction with
the new fixes for Bug#1621507:

https://code.launchpad.net/~lamont/cloud-init/+git/bug-1621615-device6/+merge/309718
https://code.launchpad.net/~lamont/cloud-initramfs-tools/bug-1621615-device6/+merge/309719

These need to land in zesty, and get SRUed to xenial and yakkety.

** Changed in: maas
   Status: Fix Released => In Progress

** Changed in: cloud-init
   Status: Fix Committed => Confirmed

** Changed in: cloud-init (Ubuntu)
   Status: Fix Released => Confirmed

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Released => Confirmed

** Changed in: cloud-initramfs-tools (Ubuntu)
   Status: Fix Released => Confirmed

** Changed in: cloud-initramfs-tools (Ubuntu Xenial)
   Status: Fix Released => Confirmed

** Also affects: cloud-init (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Also affects: cloud-initramfs-tools (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: maas
Milestone: 2.1.0 => 2.1.1

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

Title:
  network not configured when ipv6 netbooted into cloud-init

Status in cloud-init:
  Confirmed
Status in MAAS:
  In Progress
Status in cloud-init package in Ubuntu:
  Confirmed
Status in cloud-initramfs-tools package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-initramfs-tools source package in Xenial:
  Confirmed
Status in cloud-init source package in Yakkety:
  New
Status in cloud-initramfs-tools source package in Yakkety:
  New

Bug description:
  https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507 talks of
  how IPv6 netboot with iscsi root disk doesn't work, blocking IPv6-only
  MAAS.

  After I hand-walked busybox through getting an IPv6 address,
  everything worked just fine until cloud-init couldn't fetch the
  instance data, because it insisted on bringing up the interface in
  IPv4, and there is no IPv4 DHCP on that vlan.

  Please work with initramfs and friends on getting IPv6 netboot to
  actually configure the interface.  This may be as simple as teaching
  it about "inet6 dhcp" interfaces, and bolting the pieces together.
  Note that "use radvd" is not really an option for our use case.

  Related bugs:
   * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 
addresses
   * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6) 

  [Impact]

  It is not possible to enlist, commmission, or deploy with MAAS in an
  IPv6-only environment. Anyone wanting to netboot with a network root
  filesystem in an IPv6-only environment is affected.

  This upload addresses this by accepting, using, and forwarding any
  IPV6* variables from the initramfs boot.  (See
  https://launchpad.net/bugs/1621507)

  [Test Case]

  See Bug 1229458. Configure radvd, dhcpd, and tftpd for your IPv6-only
  netbooting world. Pass the boot process an IPv6 address to fetch
  instance-data from, and see it fail to configure the network.

  [Regression Potential]

  1) If the booting host is in a dual-boot environment, and the
  instance-dat URL uses a hostname that has both A and  RRsets, the
  booting host may try to talk IPv6 to get instance data.  If the
  instance-data providing host is only allowing that to happen over
  IPv4, it will fail. (It also represents a configuraiton issue on the
  providing host...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1621615/+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 1434103] Re: SQL schema downgrades are no longer supported

2016-11-01 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/382676
Committed: 
https://git.openstack.org/cgit/openstack/trove/commit/?id=6593986b34030b533bc66d112aaa6f873d519b52
Submitter: Jenkins
Branch:master

commit 6593986b34030b533bc66d112aaa6f873d519b52
Author: Trevor McCasland 
Date:   Wed Oct 5 17:20:45 2016 -0500

Remove downgrade

Removed downgrade from all existing migrations.
Modified a test that verifies that no migrations have a downgrade.
Modified test _walk_versions to only do upgrades.
Removed exceptions from pylint.config

Related cross-project spec: https://review.openstack.org/152337
Closes-Bug: #1434103

Change-Id: I9a7c87ae3f4e2eff3a4a6df881d086d52062dbba


** Changed in: trove
   Status: In Progress => Fix Released

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

Title:
  SQL schema downgrades are no longer supported

Status in Ceilometer:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in Magnum:
  Fix Released
Status in neutron:
  Fix Released
Status in octavia:
  Fix Released
Status in Sahara:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released

Bug description:
  Approved cross-project spec: https://review.openstack.org/152337

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1434103/+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 1638399] [NEW] EC2 networking driver for Neutron

2016-11-01 Thread Sachin

Public bug reported:

OpenStack project is so far focused on private cloud management. This
proposal together with a set of others for glance, cinder and nova aim
to extend OpenStack for side-by-side management of Public cloud.

Enterprises are increasingly looking at hybrid and multi-cloud strategy
as next phase of their datacenter environments. Public cloud offers
flexible on-demand resource while private cloud gives the ability to run
workloads securely. There is lack of standard when it comes to cloud
management. These specs propose OpenStack API as the solution.
Regardless of infrastructure — public or private and technology — KVM,
VMware or Hyper-V cloud workloads can be deployed and managed with
standard OpenStack API.

This driver will provide a mechanism to implement neutron networking on top of 
AWS. As was demoed in the Openstack Barcelona Summit in 2016, following 
constructs map nicely and work.
-- Creation of tenant networks and all operations
-- Creation of subnet
-- Creation of router to connect external (public) network to tenant network
-- Floating IPs.

The draft code is available here: https://github.com/platform9
/openstack-omni/tree/master/neutron

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: rfe

** Tags added: rfe

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

Title:
  EC2 networking driver for Neutron

Status in neutron:
  New

Bug description:
  OpenStack project is so far focused on private cloud management. This
  proposal together with a set of others for glance, cinder and nova aim
  to extend OpenStack for side-by-side management of Public cloud.

  Enterprises are increasingly looking at hybrid and multi-cloud
  strategy as next phase of their datacenter environments. Public cloud
  offers flexible on-demand resource while private cloud gives the
  ability to run workloads securely. There is lack of standard when it
  comes to cloud management. These specs propose OpenStack API as the
  solution. Regardless of infrastructure — public or private and
  technology — KVM, VMware or Hyper-V cloud workloads can be deployed
  and managed with standard OpenStack API.

  This driver will provide a mechanism to implement neutron networking on top 
of AWS. As was demoed in the Openstack Barcelona Summit in 2016, following 
constructs map nicely and work.
  -- Creation of tenant networks and all operations
  -- Creation of subnet
  -- Creation of router to connect external (public) network to tenant network
  -- Floating IPs.

  The draft code is available here: https://github.com/platform9
  /openstack-omni/tree/master/neutron

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1638399/+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 1638381] [NEW] Live Migration failure: 'unicode' object has no attribute '_o'

2016-11-01 Thread Einar Næss Jensen

Public bug reported:

nova live-migration a7ff526d-0cab-4da7-92c2-49d8e89d1d27
dev02-compute-01 --block-migrate


gives this in nova log:
2016-11-01 21:48:49.242 14425 ERROR nova.virt.libvirt.driver 
[req-750740d4-c988-4d91-b690-78fca9ac20b4 08e955c2ffdb49b1abeb5b5c4f8fad03 
805b50c70a744113b7d87dd248111275 - - -] [instance: 
a7ff526d-0cab-4da7-92c2-49d8e89d1d27] Live Migration failure: 'unicode' object 
has no attribute '_o'
2016-11-01 21:48:49.288 14425 ERROR nova.virt.libvirt.driver 
[req-750740d4-c988-4d91-b690-78fca9ac20b4 08e955c2ffdb49b1abeb5b5c4f8fad03 
805b50c70a744113b7d87dd248111275 - - -] [instance: 
a7ff526d-0cab-4da7-92c2-49d8e89d1d27] Migration operation has aborted


and instance is not live-migrated.

regular migrating works:


root@dev02-controller-01:~# nova migrate a7ff526d-0cab-4da7-92c2-49d8e89d1d27 
root@dev02-controller-01:~# nova list --all
WARNING: Option "--all_tenants" is deprecated; use "--all-tenants"; this option 
will be removed in novaclient 3.3.0.
+--+--+--+-+--+-++
| ID   | Name | Tenant ID   
 | Status  | Task State   | Power State | Networks  
 |
+--+--+--+-+--+-++
| a7ff526d-0cab-4da7-92c2-49d8e89d1d27 | Centos7-provider-01  | 
975ce89aac384a44be29269198817d00 | RESIZE  | resize_migrating | Running | 
provider=10.100.16.53  |
| edbf68ea-fa00-4493-813e-214fa87599b1 | centos7-selfserved   | 
975ce89aac384a44be29269198817d00 | ACTIVE  | -| Running | 
selfservice=172.16.1.5 |
| d303140e-447f-4ec6-9226-fa041a777f3c | democirr | 
975ce89aac384a44be29269198817d00 | SHUTOFF | -| Shutdown| 
provider=10.100.16.57  |
| 93aeb4c8-46b9-44f2-b32f-152305e3e747 | frontend | 
8e37b03ab46f4cc8bfc21f1659f2613b | SHUTOFF | -| Shutdown| 
provider=10.100.16.55  |
| 24104cff-d89d-4ecf-a53a-786e68a5d1e4 | fsdfs| 
975ce89aac384a44be29269198817d00 | ACTIVE  | -| Running | 
provider=10.100.16.63  |
| 9538b44e-2c92-40cc-a37e-032af7dd3cf7 | provider1| 
975ce89aac384a44be29269198817d00 | SHUTOFF | -| Shutdown| 
provider=10.100.16.52  |
| 2744b560-7105-4cb8-ada0-0dfefa92fdf4 | selfservice-instance | 
975ce89aac384a44be29269198817d00 | ACTIVE  | -| Running | 
selfservice=172.16.1.3 |
+--+--+--+-+--+-++
root@dev02-controller-01:~# nova list --all
WARNING: Option "--all_tenants" is deprecated; use "--all-tenants"; this option 
will be removed in novaclient 3.3.0.
+--+--+--+---++-++
| ID   | Name | Tenant ID   
 | Status| Task State | Power State | Networks  
 |
+--+--+--+---++-++
| a7ff526d-0cab-4da7-92c2-49d8e89d1d27 | Centos7-provider-01  | 
975ce89aac384a44be29269198817d00 | VERIFY_RESIZE | -  | Running | 
provider=10.100.16.53  |
| edbf68ea-fa00-4493-813e-214fa87599b1 | centos7-selfserved   | 
975ce89aac384a44be29269198817d00 | ACTIVE| -  | Running | 
selfservice=172.16.1.5 |
| d303140e-447f-4ec6-9226-fa041a777f3c | democirr | 
975ce89aac384a44be29269198817d00 | SHUTOFF   | -  | Shutdown| 
provider=10.100.16.57  |
| 93aeb4c8-46b9-44f2-b32f-152305e3e747 | frontend | 
8e37b03ab46f4cc8bfc21f1659f2613b | SHUTOFF   | -  | Shutdown| 
provider=10.100.16.55  |
| 24104cff-d89d-4ecf-a53a-786e68a5d1e4 | fsdfs| 
975ce89aac384a44be29269198817d00 | ACTIVE| -  | Running | 
provider=10.100.16.63  |
| 9538b44e-2c92-40cc-a37e-032af7dd3cf7 | provider1| 
975ce89aac384a44be29269198817d00 | SHUTOFF   | -  | Shutdown| 
provider=10.100.16.52  |
| 2744b560-7105-4cb8-ada0-0dfefa92fdf4 | selfservice-instance | 
975ce89aac384a44be29269198817d00 | ACTIVE| -  | Running | 
selfservice=172.16.1.3 |
+--+--+--+---++-++
root@dev02-controller-01:~# nova resize-confirm 
a7ff526d-0cab-4da7-92c2-49d8e89d1d27


root@dev02-controller-01:~# nova --debug

[Yahoo-eng-team] [Bug 1585100] Re: lbaas-poolmember: subnet is optional according to docs, but actually required

2016-11-01 Thread Anne Gentle

** No longer affects: openstack-api-site

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

Title:
  lbaas-poolmember: subnet is optional according to docs, but actually
  required

Status in neutron:
  Opinion

Bug description:
  I have devstack master with neutron lbaas with octavia.
  And I tried to create poolmember with this Heat template:
  heat_template_version: 2013-05-23

  resources:
port:
  type: OS::Neutron::LBaaS::PoolMember
  properties:
pool: 7abe4251-c643-414a-8776-7346b9c09e71
address: 5.5.5.5
protocol_port: 

  And then I got an error:
  2016-05-24 11:20:26.239 INFO heat.engine.resource 
[req-3734d004-fe1d-4e55-8978-15c9251d5f30 None demo] CREATE: PoolMember "port" 
Stack "test_pool" [0ae40413-9d58-4840-8915-67dbc43f9035]
  2016-05-24 11:20:26.239 TRACE heat.engine.resource Traceback (most recent 
call last):
  2016-05-24 11:20:26.239 TRACE heat.engine.resource   File 
"/opt/stack/heat/heat/engine/resource.py", line 715, in _action_recorder
  2016-05-24 11:20:26.239 TRACE heat.engine.resource yield
  2016-05-24 11:20:26.239 TRACE heat.engine.resource   File 
"/opt/stack/heat/heat/engine/resource.py", line 795, in _do_action
  2016-05-24 11:20:26.239 TRACE heat.engine.resource yield 
self.action_handler_task(action, args=handler_args)
  2016-05-24 11:20:26.239 TRACE heat.engine.resource   File 
"/opt/stack/heat/heat/engine/scheduler.py", line 329, in wrapper
  2016-05-24 11:20:26.239 TRACE heat.engine.resource step = next(subtask)
  2016-05-24 11:20:26.239 TRACE heat.engine.resource   File 
"/opt/stack/heat/heat/engine/resource.py", line 763, in action_handler_task
  2016-05-24 11:20:26.239 TRACE heat.engine.resource done = 
check(handler_data)
  2016-05-24 11:20:26.239 TRACE heat.engine.resource   File 
"/opt/stack/heat/heat/engine/resources/openstack/neutron/lbaas/pool_member.py", 
line 168, in check_create_complete
  2016-05-24 11:20:26.239 TRACE heat.engine.resource self.pool_id, 
{'member': properties})['member']
  2016-05-24 11:20:26.239 TRACE heat.engine.resource   File 
"/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 
1110, in create_lbaas_member
  2016-05-24 11:20:26.239 TRACE heat.engine.resource return 
self.post(self.lbaas_members_path % lbaas_pool, body=body)
  2016-05-24 11:20:26.239 TRACE heat.engine.resource   File 
"/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 
347, in post
  2016-05-24 11:20:26.239 TRACE heat.engine.resource headers=headers, 
params=params)
  2016-05-24 11:20:26.239 TRACE heat.engine.resource   File 
"/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 
282, in do_request
  2016-05-24 11:20:26.239 TRACE heat.engine.resource 
self._handle_fault_response(status_code, replybody, resp)
  2016-05-24 11:20:26.239 TRACE heat.engine.resource   File 
"/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 
257, in _handle_fault_response
  2016-05-24 11:20:26.239 TRACE heat.engine.resource 
exception_handler_v20(status_code, error_body)
  2016-05-24 11:20:26.239 TRACE heat.engine.resource   File 
"/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py", line 84, 
in exception_handler_v20
  2016-05-24 11:20:26.239 TRACE heat.engine.resource 
request_ids=request_ids)
  2016-05-24 11:20:26.239 TRACE heat.engine.resource BadRequest: Failed to 
parse request. Required attribute 'subnet_id' not specified
  2016-05-24 11:20:26.239 TRACE heat.engine.resource Neutron server returns 
request_ids: ['req-307da359-cccb-4b57-a9cb-0a29186e62cb']

  I also tried to create poolmember with cli, and got a message that
  subnet is required to create poolmember.

  But according to docs http://developer.openstack.org/api-ref-
  networking-v2-ext.html#createMemberv2 subnet is optional.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1585100/+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 1552056] Re: "router-interface-delete port=xxx" deletes the whole port instead of just removing the interface

2016-11-01 Thread Anne Gentle

** Changed in: openstack-api-site
   Status: Fix Committed => Fix Released

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

Title:
  "router-interface-delete port=xxx" deletes the whole port instead of
  just removing the interface

Status in neutron:
  Won't Fix
Status in openstack-api-site:
  Fix Released

Bug description:
  The help message of "neutron router-interface-delete" says

  "Remove an internal network interface from a router."

  =
  Expected behavior
  =
  neutron router-interface-add subnet=subnetx
  --> creates a port, and adds this port as interface to the router

  neutron router-interface-delete subnet=subnetx
  --> removes that interface from the router and deletes the corresponding port

  
  neutron router-interface-add port=portx
  --> adds an already existing port as interface to the router

  neutron router-interface-delete port=portx
  --> removes that interface from the router. Does NOT delete that 
corresponding port

  =
  Actual result
  =

  "neutron router-interface-delete subnet=subnetx" works as expected.

  BUT

  "neutron router-interface-delete port=portx" does not only remove the
  interface from the router, it also deletes the whole port!

  
  =
  Proposed solution
  =

  Either
  #1 Extend the API description to refelct this behavior

  
  Or
  #2 Change the behavior in the special case to NOT delete the port, but only 
remove the interface from the router

  
  ==
  Steps to reproduce
  ==

  # neutron router-interface-delete -h
  usage: neutron router-interface-delete [-h] [--request-format {json}]
 ROUTER INTERFACE

  Remove an internal network interface from a router.

  positional arguments:
ROUTERID or name of the router.
INTERFACE The format is "SUBNET|subnet=SUBNET|port=PORT". Either
  a subnet or port must be specified. Both ID and name
  are accepted as SUBNET or PORT. Note that "subnet="
  can be omitted when specifying a subnet.


  [root@tecs218 ~(keystone_admin)]# neutron router-create test
  Created a new router:
  +---+--+
  | Field | Value|
  +---+--+
  | admin_state_up| True |
  | external_gateway_info |  |
  | id| 4039bd93-b183-4250-af0f-e9739ac1a19a |
  | name  | test |
  | status| ACTIVE   |
  | tenant_id | 0d76aad1dda94f83a2a0a55c04547434 |
  +---+--+
  [root@tecs218 ~(keystone_admin)]# neutron router-interface-add test  
port=90e0abe1-852b-4cfe-afd9-2bd31a42c279
  Added interface 90e0abe1-852b-4cfe-afd9-2bd31a42c279 to router test.
  [root@tecs218 ~(keystone_admin)]# neutron router-interface-add test  
port=90e0abe1-852b-4cfe-afd9-2bd31a42c27^C
  [root@tecs218 ~(keystone_admin)]# neutron port-show 
90e0abe1-852b-4cfe-afd9-2bd31a42c279
  
+-+---+
  | Field   | Value 
|
  
+-+---+
  | admin_state_up  | True  
|
  | bandwidth   | 0 
|
  | binding:host_id |   
|
  | binding:profile | {}
|
  | binding:vif_details | {}
|
  | binding:vif_type| unbound   
|
  | binding:vnic_type   | normal
|
  | bond| 0 
|
  | cbs | 0 
|
  | device_id   | 4039bd93-b183-4250-af0f-e9739ac1a19a  
|
  | device_owner| network:router_interface

[Yahoo-eng-team] [Bug 1638368] Re: new keystone db migrations require either SUPER or log_bin_trust_function_creators=1

2016-11-01 Thread Matt Fischer

** Also affects: keystone
   Importance: Undecided
   Status: New

** Description changed:

+ Upgrade Process Docs:
+ http://docs.openstack.org/developer/keystone/upgrading.html#upgrading-
+ without-downtime
+ 
  The new keystone upgrade features (keystone-manage db_sync --expand)
  require either that the keystone user has SUPER or that
  
  set global log_bin_trust_function_creators=1; is run.
  
  I'm not sure which is the better option but logging this anyway.
  
  Without that you get this error:
  
  root@dev01-keystone-001:/var/log/mysql# keystone-manage db_sync --expand
  2016-11-01 19:56:17.803 1 INFO migrate.versioning.api [-] 97 -> 98...
  2016-11-01 19:56:17.821 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:17.821 1 INFO migrate.versioning.api [-] 98 -> 99...
  2016-11-01 19:56:17.839 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:17.839 1 INFO migrate.versioning.api [-] 99 -> 100...
  2016-11-01 19:56:17.855 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:17.856 1 INFO migrate.versioning.api [-] 100 -> 101...
  2016-11-01 19:56:17.897 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:17.897 1 INFO migrate.versioning.api [-] 101 -> 102...
  2016-11-01 19:56:17.961 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:17.961 1 INFO migrate.versioning.api [-] 102 -> 103...
  2016-11-01 19:56:18.108 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:18.109 1 INFO migrate.versioning.api [-] 103 -> 104...
  2016-11-01 19:56:18.132 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:18.132 1 INFO migrate.versioning.api [-] 104 -> 105...
  2016-11-01 19:56:18.454 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:18.455 1 INFO migrate.versioning.api [-] 105 -> 106...
  2016-11-01 19:56:18.680 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:18.680 1 INFO migrate.versioning.api [-] 106 -> 107...
  2016-11-01 19:56:18.968 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:18.968 1 INFO migrate.versioning.api [-] 107 -> 108...
  2016-11-01 19:56:19.324 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:19.325 1 INFO migrate.versioning.api [-] 108 -> 109...
  2016-11-01 19:56:19.477 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:19.534 1 INFO migrate.versioning.api [-] 0 -> 1...
  2016-11-01 19:56:19.550 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:19.550 1 INFO migrate.versioning.api [-] 1 -> 2...
  2016-11-01 19:56:19.569 1 INFO migrate.versioning.api [-] done
  2016-11-01 19:56:19.569 1 INFO migrate.versioning.api [-] 2 -> 3...
  2016-11-01 19:56:19.881 1 CRITICAL keystone [-] OperationalError: 
(_mysql_exceptions.OperationalError) (1419, 'You do not have the SUPER 
privilege and binary logging is enabled (you *might* want to use the less safe 
log_bin_trust_function_creators variable)') [SQL: "\nCREATE TRIGGER 
credential_insert_read_only BEFORE INSERT ON credential\nFOR EACH ROW\nBEGIN\n  
SIGNAL SQLSTATE '45000'\nSET MESSAGE_TEXT = 'Credential migration in 
progress. Cannot perform writes to credential table.';\nEND;\n"]
  2016-11-01 19:56:19.881 1 ERROR keystone Traceback (most recent call last):
  2016-11-01 19:56:19.881 1 ERROR keystone   File "/usr/bin/keystone-manage", 
line 10, in 
  2016-11-01 19:56:19.881 1 ERROR keystone sys.exit(main())
  2016-11-01 19:56:19.881 1 ERROR keystone   File 
"/venv/local/lib/python2.7/site-packages/keystone/cmd/manage.py", line 44, in 
main
  2016-11-01 19:56:19.881 1 ERROR keystone cli.main(argv=sys.argv, 
config_files=config_files)
  2016-11-01 19:56:19.881 1 ERROR keystone   File 
"/venv/local/lib/python2.7/site-packages/keystone/cmd/cli.py", line 1254, in 
main
  2016-11-01 19:56:19.881 1 ERROR keystone CONF.command.cmd_class.main()
  2016-11-01 19:56:19.881 1 ERROR keystone   File 
"/venv/local/lib/python2.7/site-packages/keystone/cmd/cli.py", line 438, in main
  2016-11-01 19:56:19.881 1 ERROR keystone migration_helpers.expand_schema()
  2016-11-01 19:56:19.881 1 ERROR keystone   File 
"/venv/local/lib/python2.7/site-packages/keystone/common/sql/migration_helpers.py",
 line 233, in expand_schema
  2016-11-01 19:56:19.881 1 ERROR keystone 
_sync_repo(repo_name='expand_repo')
  2016-11-01 19:56:19.881 1 ERROR keystone   File 
"/venv/local/lib/python2.7/site-packages/keystone/common/sql/migration_helpers.py",
 line 144, in _sync_repo
  2016-11-01 19:56:19.881 1 ERROR keystone init_version=init_version, 
sanity_check=False)
  2016-11-01 19:56:19.881 1 ERROR keystone   File 
"/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/migration.py", line 
78, in db_sync
  2016-11-01 19:56:19.881 1 ERROR keystone migration = 
versioning_api.upgrade(engine, repository, version)
  2016-11-01 19:56:19.881 1 ERROR keystone   File 
"/venv/local/lib/python2.7/site-packages/migrate/versioning/api.py", line 186, 
in upgrade
  2016-11-01 19:56:19.881 1 ERROR keystone return _migrate(url, repository, 
version,

[Yahoo-eng-team] [Bug 1638273] Re: find_child_pids crashes under non-english locals

2016-11-01 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/392137
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=3c1bf8697b9be4a406e978af8a3329389f992514
Submitter: Jenkins
Branch:master

commit 3c1bf8697b9be4a406e978af8a3329389f992514
Author: John Schwarz 
Date:   Tue Nov 1 14:28:32 2016 +0200

Don't depend on translated strings for error check

Currently, execute() may raise an exception that contains a *translated*
string that starts with 'Exit code: %(returncode)d...' if the returncode
of a process was not 0. find_child_pids() will then check if the
raised exception contains 'Exit code: 1' (to check if the returncode is
1), but in non-English locales this will fail as the 2 strings are not
encoded the same.

This patch adds a new ProcessExecutionError (which inherits from
RuntimeError, so as to not change all the code that currently depends on
execute() returning RuntimeError) which now accepts a returncode. This
can be changed explicitly without depending on the error message.

Later patches can move ProcessExecutionError to neutron-lib, if this is
needed - this patch intends to write the smallest piece of code that can
be backported.

Closes-Bug: #1638273
Change-Id: I85d3bec13e852918eb13e73c1367c70e1f4d34b1


** Changed in: neutron
   Status: In Progress => Fix Released

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

Title:
  find_child_pids crashes under non-english locals

Status in neutron:
  Fix Released

Bug description:
  Traceback available at [1].

  The function execute() returns _("Exit code: %(returncode)d; ...")
  [2]. Under non-English locales (we checked for Japanese, but surely
  this will also occur in others, the check 'Exit code: 1' in str(e)
  [3] will fail since 'Exit code: 1' is not encoded the same.

  This ultimately prevents stuff like booting a new VM.

  [1]: http://pastebin.com/x66aqctN
  [2]: 
https://github.com/openstack/neutron/blob/15d65607a47810f7d155d43902d358cb9f953a7a/neutron/agent/linux/utils.py#L127
  [3]: 
https://github.com/openstack/neutron/blob/15d65607a47810f7d155d43902d358cb9f953a7a/neutron/agent/linux/utils.py#L176

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1638273/+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 1638344] [NEW] Horizon checks a neutron policy.json action that does not exists - "remove_router" doesn't exists in the neutron policy.json

2016-11-01 Thread Rick Bartra

Public bug reported:

Horizon checks the "remove_router" neutron action which doesn't exists in the 
neutron policy.json. 
Neutron also doesn't check the "remove_router" action in the policy.json when 
performing the "neutron firewall-update  --no-routers" CLI command.

Horizon policy check:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/firewalls/tables.py#L251

Neutron policy file in Horizon:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/conf/neutron_policy.json

Neutron policy file in Neutron:
https://github.com/openstack/neutron/blob/master/etc/policy.json

** Affects: horizon
 Importance: Undecided
 Status: New

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

Title:
  Horizon checks a neutron policy.json action that does not exists -
  "remove_router" doesn't exists in the neutron policy.json

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Horizon checks the "remove_router" neutron action which doesn't exists in the 
neutron policy.json. 
  Neutron also doesn't check the "remove_router" action in the policy.json when 
performing the "neutron firewall-update  --no-routers" CLI command.

  Horizon policy check:
  
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/firewalls/tables.py#L251

  Neutron policy file in Horizon:
  
https://github.com/openstack/horizon/blob/master/openstack_dashboard/conf/neutron_policy.json

  Neutron policy file in Neutron:
  https://github.com/openstack/neutron/blob/master/etc/policy.json

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1638344/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR

2016-11-01 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/386348
Committed: 
https://git.openstack.org/cgit/openstack/ec2-api/commit/?id=897e498ce8312d4b8373a176e548edba95929bcb
Submitter: Jenkins
Branch:master

commit 897e498ce8312d4b8373a176e548edba95929bcb
Author: Iswarya_Vakati 
Date:   Fri Oct 14 10:30:09 2016 +0530

Drop MANIFEST.in - it's not needed by pbr

Ec2-api already uses PBR:-
setuptools.setup(
setup_requires=['pbr>=1.8'],
pbr=True)

This patch removes `MANIFEST.in` file as pbr generates a
sensible manifest from git files and some standard files
and it removes the need for an explicit `MANIFEST.in` file.

Change-Id: I3eafb35c6a8ecd89cb5719e63954aabae7899830
Closes-Bug:#1608980


** Changed in: ec2-api
   Status: In Progress => Fix Released

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

Title:
  Remove MANIFEST.in as it is not explicitly needed by PBR

Status in craton:
  Fix Released
Status in DragonFlow:
  Fix Released
Status in ec2-api:
  Fix Released
Status in gce-api:
  Fix Released
Status in Karbor:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in Kosmos:
  Fix Released
Status in Magnum:
  Fix Released
Status in masakari:
  Fix Released
Status in neutron:
  Fix Released
Status in Neutron LBaaS Dashboard:
  Confirmed
Status in octavia:
  Fix Released
Status in python-searchlightclient:
  In Progress
Status in OpenStack Search (Searchlight):
  In Progress
Status in Solum:
  Fix Released
Status in Swift Authentication:
  In Progress
Status in OpenStack Object Storage (swift):
  In Progress
Status in Tricircle:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in watcher:
  Fix Released
Status in Zun:
  Fix Released

Bug description:
  PBR do not explicitly require MANIFEST.in, so it can be removed.

  
  Snippet from: http://docs.openstack.org/infra/manual/developers.html

  Manifest

  Just like AUTHORS and ChangeLog, why keep a list of files you wish to
  include when you can find many of these in git. MANIFEST.in generation
  ensures almost all files stored in git, with the exception of
  .gitignore, .gitreview and .pyc files, are automatically included in
  your distribution. In addition, the generated AUTHORS and ChangeLog
  files are also included. In many cases, this removes the need for an
  explicit ‘MANIFEST.in’ file

To manage notifications about this bug go to:
https://bugs.launchpad.net/craton/+bug/1608980/+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 1636185] Re: Associate Floating IP with server - Improve description

2016-11-01 Thread Anne Gentle

Source files for this document are in the openstack/nova/api-ref repo
location.

** Also affects: nova
   Importance: Undecided
   Status: New

** No longer affects: openstack-api-site

-- 
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/1636185

Title:
  Associate Floating IP with server - Improve description

Status in OpenStack Compute (nova):
  New

Bug description:
  According to the docs on this link

  http://developer.openstack.org/api-ref/compute/?expanded=add-
  associate-floating-ip-addfloatingip-action-detail#add-associate-
  floating-ip-addfloatingip-action

  the "addFloatingIp" parameter in the request is a string. However,
  after some attempts we figured out the documentation is not correct.
  Turns out this parameter is an object, not a String as described. A
  working example to the request would look something like this:

  body = {
  'addFloatingIp': {
  'address': '172.24.4.5',
  'fixed_address': '10.0.0.10'
  }
  }

  Please fix this parameter on the docs, and also add a working example.
  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1636185/+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 1636180] Re: Error in docs for creating new Floating IP

2016-11-01 Thread Anne Gentle

Source files are in openstack/neutron-lib/api-ref I believe, so moving
but to track with neutron.

** Also affects: neutron
   Importance: Undecided
   Status: New

** No longer affects: openstack-api-site

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

Title:
  Error in docs for creating new Floating IP

Status in neutron:
  New

Bug description:
  According to the docs on this link:

  http://developer.openstack.org/api-
  ref/networking/v2/index.html?expanded=create-floating-ip-detail
  #floating-ips-floatingips

  we should pass an object such as this for creating a new floating IP:

  {
  "floatingip": {
  "floating_network_id": "376da547-b977-4cfe-9cba-275c80debf57"
  }
  }

  But using this object throw us an error. Instead we need to use a much
  simpler object, without the "floatingip" key. It would result in
  something like this:

  body = {"floating_network_id": public_network.id}

  Please fix the API docs to spare anybody else's time.
  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1636180/+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 1638339] [NEW] mitaka docs build breaks on vine.five

2016-11-01 Thread Eric Fried

Public bug reported:

In attempting to track down build failures in an out-of-tree project, I
submitted a change set to try out the nova gate in mitaka.  It failed
the docs build on the vine.five switch in kombu.

The change set is here:
https://review.openstack.org/#/c/392200/

The failure log is here:
http://logs.openstack.org/00/392200/1/check/gate-nova-docs-ubuntu-trusty/55fb272/console.html#_2016-11-01_15_22_32_787002

(Does the docs build not honor the upper constraints set in the generic
[testenv]?)

** Affects: nova
 Importance: Undecided
 Status: New

-- 
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/1638339

Title:
  mitaka docs build breaks on vine.five

Status in OpenStack Compute (nova):
  New

Bug description:
  In attempting to track down build failures in an out-of-tree project,
  I submitted a change set to try out the nova gate in mitaka.  It
  failed the docs build on the vine.five switch in kombu.

  The change set is here:
  https://review.openstack.org/#/c/392200/

  The failure log is here:
  
http://logs.openstack.org/00/392200/1/check/gate-nova-docs-ubuntu-trusty/55fb272/console.html#_2016-11-01_15_22_32_787002

  (Does the docs build not honor the upper constraints set in the
  generic [testenv]?)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1638339/+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 1611171] Re: re-runs self via sudo

2016-11-01 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/371930
Committed: 
https://git.openstack.org/cgit/openstack/ec2-api/commit/?id=f8dbd1cc45a1ceeedebf80607ef72eaaaba174a9
Submitter: Jenkins
Branch:master

commit f8dbd1cc45a1ceeedebf80607ef72eaaaba174a9
Author: Iswarya_Vakati 
Date:   Sat Sep 17 18:28:28 2016 +0530

Don't attempt to escalate ec2-api-manage privileges

Remove code which allowed ec2-api-manage to attempt to escalate
privileges so that configuration files can be read by users who
normally wouldn't have access, but do have sudo access.

Change-Id: I1ab7052fc117f064054e3127517da77598b6d27b
Closes-Bug:#1611171


** Changed in: ec2-api
   Status: In Progress => Fix Released

-- 
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/1611171

Title:
  re-runs self via sudo

Status in Cinder:
  Fix Released
Status in Designate:
  In Progress
Status in ec2-api:
  Fix Released
Status in gce-api:
  Fix Released
Status in Manila:
  In Progress
Status in masakari:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) newton series:
  Fix Committed
Status in OpenStack Security Advisory:
  Won't Fix
Status in Rally:
  Fix Released

Bug description:
  Hello, I'm looking through Designate source code to determine if is
  appropriate to include in Ubuntu Main. This isn't a full security
  audit.

  This looks like trouble:

  ./designate/cmd/manage.py

  def main():
  CONF.register_cli_opt(category_opt)

  try:
  utils.read_config('designate', sys.argv)
  logging.setup(CONF, 'designate')
  except cfg.ConfigFilesNotFoundError:
  cfgfile = CONF.config_file[-1] if CONF.config_file else None
  if cfgfile and not os.access(cfgfile, os.R_OK):
  st = os.stat(cfgfile)
  print(_("Could not read %s. Re-running with sudo") % cfgfile)
  try:
  os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + 
sys.argv)
  except Exception:
  print(_('sudo failed, continuing as if nothing happened'))

  print(_('Please re-run designate-manage as root.'))
  sys.exit(2)

  
  This is an interesting decision -- if the configuration file is _not_ 
readable by the user in question, give the executing user complete privileges 
of the user that owns the unreadable file.

  I'm not a fan of hiding privilege escalation / modifications in
  programs -- if a user had recently used sudo and thus had the
  authentication token already stored for their terminal, this 'hidden'
  use of sudo may be unexpected and unwelcome, especially since it
  appears that argv from the first call leaks through to the sudo call.

  Is this intentional OpenStack style? Or unexpected for you guys too?

  (Feel free to make this public at your convenience.)

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+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 1625209] Re: ipv6 options are being checked for ipv4 subnet

2016-11-01 Thread Neil Jerram

If I understand correctly, this is not an independent bug. Rather, it
only arises when changes are made in networking-calico to address
another bug (1541490). And the only proposed change for _this_ bug is
now also in networking-calico.

Therefore it doesn't make sense for this bug to have an independent
existence from 1541490, or for any changes for this bug to be separated
from proposed changes from 1541490. I will close this bug for
networking-calico, and ask that you simply combine all of the
networking-calico changes that you think are needed for 1541490.

** Changed in: networking-calico
Status: In Progress => Invalid

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

Title:
ipv6 options are being checked for ipv4 subnet

Status in networking-calico:
Invalid
Status in neutron:
Invalid

Bug description:
When DHCP agent tries to set fixed_ips parameter for DHCP port (see
https://bugs.launchpad.net/networking-calico/+bug/1541490) Neutron checks
ipv6_address_mode and ipv6_ra_mode options of subnet that corresponds to the
given fixed IP even for IPv4 subnet. And this fails as IPv4 subnet does not
have such options (see traceback http://paste.openstack.org/show/580996/). And,
of course, you cannot set such flags for IPv4 subnet.
I'd expect that such check is performed for IPv6 subnets only.

Probably, this situation is possible not only while using non-native
DHCP agent.

Neutron version: Newton (7f6b5b5d8953159740f74b0a4a5280527f6baa69).
Environment: Calico (https://github.com/openstack/networking-calico) over
Neutron.
Point of failure:
https://github.com/openstack/neutron/blob/7f6b5b5d8953159740f74b0a4a5280527f6baa69/neutron/agent/linux/dhcp.py#L1342
Traceback: http://paste.openstack.org/show/580996/
Failure rate: always.

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-calico/+bug/1625209/+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

51 matches

Mail list logo