[Yahoo-eng-team] [Bug 1721439] [NEW] trust remaining_uses decrement by 2

2017-10-04 Thread Craig Cerny 
Public bug reported:

After setting the remaining_uses to a positive value e.g. 100, the
remaining_uses are being decremented twice upon each use of the trust.


#crate trust while logged in with admin 
openstack trust create --project demo --role admin admin demo

#Set remaining uses on trust
mysql -e 'update keystone.trust set remaining_uses=100'

#With env's set to to the demo user:
stack@ubuntu-xenial:~$ openstack --os-trust-id 9338333bc185421d987a5e3c1a6b8659 
 trust show 9338333bc185421d987a5e3c1a6b8659  
++--+
| Field  | Value|
++--+
| deleted_at | None |
| expires_at | None |
| id | 9338333bc185421d987a5e3c1a6b8659 |
| impersonation  | False|
| project_id | c9082a59cc66437dbab59422adc86fd0 |
| redelegation_count | 0|
| remaining_uses | 98   |
| roles  | admin|
| trustee_user_id| d569f0d606bf47e0b1dbf336aa4ece7e |
| trustor_user_id| c73ac9ac2e7b48ac872f2acb723892f8 |
++--+
stack@ubuntu-xenial:~$ openstack --os-trust-id 9338333bc185421d987a5e3c1a6b8659 
 trust show 9338333bc185421d987a5e3c1a6b8659  -c remaining_uses
++---+
| Field  | Value |
++---+
| remaining_uses | 96|
++---+
stack@ubuntu-xenial:~$ openstack --os-trust-id 9338333bc185421d987a5e3c1a6b8659 
 trust show 9338333bc185421d987a5e3c1a6b8659  -c remaining_uses
++---+
| Field  | Value |
++---+
| remaining_uses | 94|
++---+

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  trust remaining_uses decrement by 2

Status in OpenStack Identity (keystone):
  New

Bug description:
  After setting the remaining_uses to a positive value e.g. 100, the
  remaining_uses are being decremented twice upon each use of the trust.

  
  #crate trust while logged in with admin 
  openstack trust create --project demo --role admin admin demo

  #Set remaining uses on trust
  mysql -e 'update keystone.trust set remaining_uses=100'

  #With env's set to to the demo user:
  stack@ubuntu-xenial:~$ openstack --os-trust-id 
9338333bc185421d987a5e3c1a6b8659  trust show 9338333bc185421d987a5e3c1a6b8659  
  ++--+
  | Field  | Value|
  ++--+
  | deleted_at | None |
  | expires_at | None |
  | id | 9338333bc185421d987a5e3c1a6b8659 |
  | impersonation  | False|
  | project_id | c9082a59cc66437dbab59422adc86fd0 |
  | redelegation_count | 0|
  | remaining_uses | 98   |
  | roles  | admin|
  | trustee_user_id| d569f0d606bf47e0b1dbf336aa4ece7e |
  | trustor_user_id| c73ac9ac2e7b48ac872f2acb723892f8 |
  ++--+
  stack@ubuntu-xenial:~$ openstack --os-trust-id 
9338333bc185421d987a5e3c1a6b8659  trust show 9338333bc185421d987a5e3c1a6b8659  
-c remaining_uses
  ++---+
  | Field  | Value |
  ++---+
  | remaining_uses | 96|
  ++---+
  stack@ubuntu-xenial:~$ openstack --os-trust-id 
9338333bc185421d987a5e3c1a6b8659  trust show 9338333bc185421d987a5e3c1a6b8659  
-c remaining_uses
  ++---+
  | Field  | Value |
  ++---+
  | remaining_uses | 94|
  ++---+

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1721439/+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 1721426] [NEW] Install and configure in keystone

2017-10-04 Thread Dylan Wilson 
Public bug reported:


This bug tracker is for errors with the documentation, use the following
as a template and remove or add fields as you see fit. Convert [ ] into
[x] to check boxes:

- [X] This doc is inaccurate in this way: Right arrow skips over "Create a 
domain, projects, users, and roles" section entirely.
- [ ] This is a doc addition request.
- [ ] I have a fix to the document that I can paste below including example: 
input and output. 

If you have a troubleshooting or support issue, use the following
resources:

 - Ask OpenStack: http://ask.openstack.org
 - The mailing list: http://lists.openstack.org
 - IRC: 'openstack' channel on Freenode

---
Release: 12.0.0.0rc3.dev2 on 2017-08-26 22:01
SHA: 5a9aeefff06678d790d167b6dac752677f02edf9
Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-ubuntu.rst
URL: 
https://docs.openstack.org/keystone/pike/install/keystone-install-ubuntu.html

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: doc

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

Title:
  Install and configure in keystone

Status in OpenStack Identity (keystone):
  New

Bug description:

  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [X] This doc is inaccurate in this way: Right arrow skips over "Create a 
domain, projects, users, and roles" section entirely.
  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 12.0.0.0rc3.dev2 on 2017-08-26 22:01
  SHA: 5a9aeefff06678d790d167b6dac752677f02edf9
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-ubuntu.rst
  URL: 
https://docs.openstack.org/keystone/pike/install/keystone-install-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1721426/+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 1721423] [NEW] [Performance] Bad performance on instances list panel

2017-10-04 Thread Feilong Wang 
Public bug reported:

I just found there is no cache for microversion check which may cause
almost 40 unnecessary API calls.

There are two actions for instances table need to check the microversion in 
allowed() function, see
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/instances/tables.py#L870

but unfortunately, there is no cache for this check, see
https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/nova.py#L60

And function get_microversion(request, feature) is also used by other
functions. Based on my test, after adding cache for this function, about
3+ seconds are saved.

** Affects: horizon
 Importance: Undecided
 Assignee: Feilong Wang (flwang)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => Feilong Wang (flwang)

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

Title:
  [Performance] Bad performance on instances list panel

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  I just found there is no cache for microversion check which may cause
  almost 40 unnecessary API calls.

  There are two actions for instances table need to check the microversion in 
allowed() function, see
  
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/instances/tables.py#L870

  but unfortunately, there is no cache for this check, see
  
https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/nova.py#L60

  And function get_microversion(request, feature) is also used by other
  functions. Based on my test, after adding cache for this function,
  about 3+ seconds are saved.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1721423/+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 1715163] Re: StaleDataError in _reconfigure_ha_resources while running tempest tests

2017-10-04 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/507856
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=7910c3a1c090ed7a46a32b371ecf73157ddba88f
Submitter: Jenkins
Branch:master

commit 7910c3a1c090ed7a46a32b371ecf73157ddba88f
Author: venkata anil 
Date:   Wed Sep 27 13:27:48 2017 +

Refactor DVR HA migarations DB operations

when a router is migrated from/to HA, router interface device_owner
in DB is updated in the AFTER_UPDATE event handler. Because of this
we see StaleDataError Trace as described in the bug report.
Instead, we follow DVR approach and update it in PRECOMMIT_UPDATE
handler, which only does DB changes. Here we update device_owner only
between legacy and HA router modes as migration involving DVR is
already handled in DVR code.

Also update distributed flag after all DB operations. Otherwise existing
code may affect router unbinding during retry as distributed flag
already updated before retry.

Testing is covered with scenario tempest test i.e
DVR HA migrations tests from gate job
"legacy-tempest-dsvm-neutron-dvr-multinode-scenario".

Closes-Bug: 1715163
Change-Id: I6e5783c44c77ec07371921e900ed45efd031ebdb


** 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/1715163

Title:
  StaleDataError in _reconfigure_ha_resources while running tempest
  tests

Status in neutron:
  Fix Released

Bug description:
  When running tempest-NetworkMigrationFromHA tempest test for 
gate-tempest-dsvm-neutron-dvr-multinode-scenario-ubuntu-xenial-nv on CI, the 
following Trace is seen resulting in test failure.
  (note: Link to q-svc log file [1])

  Sep 05 10:00:10.799230 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager [None 
req-f381e785-9e70-478c-ac95-f95e0d5d01a5 
tempest-NetworkMigrationFromHA-629661935 
tempest-NetworkMigrationFromHA-629661935] Error during notification for 
neutron.services.l3_router.l3_router_plugin.L3RouterPlugin._reconfigure_ha_resources--9223372036852786466
 router, after_update: StaleDataError: UPDATE statement on table 
'standardattributes' expected to update 1 row(s); 0 were matched.
  Sep 05 10:00:10.799496 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager Traceback (most 
recent call last):
  Sep 05 10:00:10.799687 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager   File 
"/usr/local/lib/python2.7/dist-packages/neutron_lib/callbacks/manager.py", line 
171, in _notify_loop
  Sep 05 10:00:10.799859 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager 
callback(resource, event, trigger, **kwargs)
  Sep 05 10:00:10.89 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager   File 
"/opt/stack/new/neutron/neutron/db/l3_hamode_db.py", line 486, in 
_reconfigure_ha_resources
  Sep 05 10:00:10.800150 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager 
self.schedule_router(context, router_id)
  Sep 05 10:00:10.800284 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager   File 
"/opt/stack/new/neutron/neutron/db/l3_agentschedulers_db.py", line 469, in 
schedule_router
  Sep 05 10:00:10.800422 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager self, context, 
router, candidates=candidates)
  Sep 05 10:00:10.800561 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager   File 
"/opt/stack/new/neutron/neutron/scheduler/l3_agent_scheduler.py", line 54, in 
schedule
  Sep 05 10:00:10.800703 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager plugin, context, 
router_id, candidates=candidates)
  Sep 05 10:00:10.800842 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager   File 
"/opt/stack/new/neutron/neutron/scheduler/l3_agent_scheduler.py", line 233, in 
_schedule_router
  Sep 05 10:00:10.801071 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager if not 
plugin.router_supports_scheduling(context, router_id):
  Sep 05 10:00:10.801242 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager   File 
"/opt/stack/new/neutron/neutron/services/l3_router/l3_router_plugin.py", line 
128, in router_supports_scheduling
  Sep 05 10:00:10.801413 ubuntu-xenial-2-node-rax-iad-10771875 
neutron-server[30374]: ERROR neutron_lib.callbacks.manager return 
self.l3_driver_controller.uses_scheduler(context,

[Yahoo-eng-team] [Bug 1719730] Re: Reschedule after the late affinity check fails with "'NoneType' object is not iterable"

2017-10-04 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/507938
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=9d6632a67d91fb3c5145c14ac38011e919d6d8c0
Submitter: Jenkins
Branch:master

commit 9d6632a67d91fb3c5145c14ac38011e919d6d8c0
Author: melanie witt 
Date:   Wed Sep 27 17:27:56 2017 +

Set group_members when converting to legacy request spec

In Pike we converted the affinity filter code to use the RequestSpec
object instead of legacy dicts. The filter used to populate server
group info in the filter_properties and the conversion removed that.
However, in the conductor, we are still converting RequestSpec back
and forth between object and primitive, and there is a mismatch
between the keys being set/get in filter_properties. So during a
reschedule with a server group, we hit an exception
"'NoneType' object is not iterable" in the RequestSpec.from_primitives
method and the reschedule fails.

This adds 'group_members' to the _to_legacy_group_info method to set
the key.

Closes-Bug: #1719730

Change-Id: Icb418f2be575bb2ba82756fdeb67b24a28950746


** Changed in: nova
   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/1719730

Title:
  Reschedule after the late affinity check fails with "'NoneType' object
  is not iterable"

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) pike series:
  Confirmed

Bug description:
  Ran into this while hacking on something locally and running the
  server groups functional tests:

  
  ==
  Failed 1 tests - output below:
  ==

  
nova.tests.functional.test_server_group.ServerGroupTestV215.test_rebuild_with_anti_affinity
  
---

  Captured pythonlogging:
  ~~~
  19:45:29,525 ERROR [nova.scheduler.utils] Error from last host: host2 (node 
host2): ['Traceback (most recent call last):\n', '  File 
"nova/compute/manager.py", line 1831, in _do_build_and_run_instance\n
filter_properties)\n', '  File "nova/compute/manager.py", line 2061, in 
_build_and_run_instance\ninstance_uuid=instance.uuid, 
reason=six.text_type(e))\n', 'RescheduledException: Build of instance 
c249e39f-0d38-40ce-860d-6c72cdeba436 was re-scheduled: Build of instance 
c249e39f-0d38-40ce-860d-6c72cdeba436 was re-scheduled: Anti-affinity instance 
group policy was violated.\n']
  19:45:29,526 WARNING [nova.scheduler.utils] Failed to 
compute_task_build_instances: 'NoneType' object is not iterable
  19:45:29,527 WARNING [nova.scheduler.utils] Setting instance to ERROR state.

  
  Two instances are being booted simultaneously and both land on the same host, 
so the second one will fail the late affinity check and raise a 
RescheduledException to be rescheduled to another host. But conductor fails to 
do that because the 'group_members' key doesn't exist in filter_properties and 
an attempt to make a list out of it fails [1].

  In the past, code [2] was added 'group_members' to filter_properties
  to handle affinity and a more recent change removed most of it but
  missed 'group_members' [3]. So nothing is ever setting
  filter_properties['group_members'] but RequestSpec.from_primitives()
  expects it to be there and blows up trying to make a list from None.

  
  [1] 
https://github.com/openstack/nova/blob/ad6d339/nova/objects/request_spec.py#L205
 
  [2] https://review.openstack.org/#/c/148277
  [3] https://review.openstack.org/#/c/469037

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1719730/+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 1721411] [NEW] cc_ntp schema validation tests don't work in the absence of a package manager

2017-10-04 Thread Garrett Holmstrom 
Public bug reported:

When the cc_ntp module goes to render an ntp configuration file it
chooses whether to write ntp.conf or a systemd-timesyncd config file
based on whether or not it can find a package manager.  The unit tests
that begin with "test_ntp_handler_schema_validation", however, function
correctly only if ntp.conf is the file that gets written out, causing
the test suite to fail with FileNotFoundErrors in environments like
Fedora's package-building chroots, which lack package managers:

==
ERROR: Ntp schema validation allows for an empty ntp: configuration.
--
Traceback (most recent call last):
  File 
"/builddir/build/BUILD/cloud-init-17.1/tests/unittests/test_handler/test_handler_ntp.py",
 line 305, in test_ntp_handler_schema_validation_allows_empty_ntp_config
with open(ntp_conf) as stream:
FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/ci-TestNtp.28kd8373/ntp.conf'

** Affects: cloud-init
 Importance: Undecided
 Status: New

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

Title:
  cc_ntp schema validation tests don't work in the absence of a package
  manager

Status in cloud-init:
  New

Bug description:
  When the cc_ntp module goes to render an ntp configuration file it
  chooses whether to write ntp.conf or a systemd-timesyncd config file
  based on whether or not it can find a package manager.  The unit tests
  that begin with "test_ntp_handler_schema_validation", however,
  function correctly only if ntp.conf is the file that gets written out,
  causing the test suite to fail with FileNotFoundErrors in environments
  like Fedora's package-building chroots, which lack package managers:

  ==
  ERROR: Ntp schema validation allows for an empty ntp: configuration.
  --
  Traceback (most recent call last):
File 
"/builddir/build/BUILD/cloud-init-17.1/tests/unittests/test_handler/test_handler_ntp.py",
 line 305, in test_ntp_handler_schema_validation_allows_empty_ntp_config
  with open(ntp_conf) as stream:
  FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/ci-TestNtp.28kd8373/ntp.conf'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1721411/+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 1721402] [NEW] stable/ocata requirements mismatch (pika and iso8601)

2017-10-04 Thread Stuart Rench 
Public bug reported:

When installing keystone from the GitHub 
(https://github.com/openstack/keystone/tree/stable/ocata),
there are 2 packages that cause issues with proper functionality.

The first is pika.  When starting the service it says that pika must be
>0.9.0 but <0.11.0, however, the requirements.txt file allows for 0.11.0
to be installed.

The second is iso8601.  The service will stand up just fine, but when 
attempting to log in, the service will fail to authenticate due to the 
inability for oslo_utils timeparser to be able to parse a time in the following 
format:
2010-01-01T12:00:00UTC+01:00

Further investigation shows that version 0.1.12 broke this change
(https://bitbucket.org/micktwomey/pyiso8601/).  Downgrading iso8601 to
0.1.11 resolves the issue.

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  stable/ocata requirements mismatch (pika and iso8601)

Status in OpenStack Identity (keystone):
  New

Bug description:
  When installing keystone from the GitHub 
(https://github.com/openstack/keystone/tree/stable/ocata),
  there are 2 packages that cause issues with proper functionality.

  The first is pika.  When starting the service it says that pika must
  be >0.9.0 but <0.11.0, however, the requirements.txt file allows for
  0.11.0 to be installed.

  The second is iso8601.  The service will stand up just fine, but when 
attempting to log in, the service will fail to authenticate due to the 
inability for oslo_utils timeparser to be able to parse a time in the following 
format:
  2010-01-01T12:00:00UTC+01:00

  Further investigation shows that version 0.1.12 broke this change
  (https://bitbucket.org/micktwomey/pyiso8601/).  Downgrading iso8601 to
  0.1.11 resolves the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1721402/+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 1676298] Re: Need to remove usage of novaclient.v2.security_group_rules

2017-10-04 Thread Ying Zuo 
This has been addressed with
https://blueprints.launchpad.net/horizon/+spec/drop-nova-network in
Horizon.

** Changed in: horizon
   Status: Confirmed => Fix Released

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

Title:
  Need to remove usage of novaclient.v2.security_group_rules

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in python-openstackclient:
  Confirmed

Bug description:
  python-novaclient has removed the deprecated security_group_rules APIs
  in https://review.openstack.org/447707 . These are still being used by
  openstackclient (see [1]), so it will fail when a new novaclient
  version is released.

  [1] https://github.com/openstack/python-
  
openstackclient/blob/f63a9f402dc3761a1f7e358d92b7e1aa33098c7a/openstackclient/network/v2/security_group_rule.py#L19-L22

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1676298/+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 1713927] Re: gate-grenade-dsvm-neutron-dvr-multinode-ubuntu-xenial fails constantly

2017-10-04 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/500143
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=7bff99ac4a5ef0d4b2cc6f77f5679bb8e01f86d7
Submitter: Jenkins
Branch:master

commit 7bff99ac4a5ef0d4b2cc6f77f5679bb8e01f86d7
Author: Brian Haley 
Date:   Fri Sep 1 13:52:51 2017 -0400

DVR: Always initialize floating IP host

With a recent change to the neutron server code, the server was
processing floating IPs that were not bound to the respective
agent during fullsync operation.

Change to always initialize floating IP host info so callers
can determine if info should be sent to an agent or not.

Also changed the logic that decides when the server should
send a floating IP to an agent to be easier to understand.

Closes-bug: #1713927
Change-Id: Ic916225e0a11c3fb8cd94437ca063e0d3295a569


** 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/1713927

Title:
  gate-grenade-dsvm-neutron-dvr-multinode-ubuntu-xenial fails constantly

Status in neutron:
  Fix Released

Bug description:
  The job is at almost 100% failure rate.
  
http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=11

  It went up from 24% to 100% at about Aug 26 6pm UTC.

  Logs: http://logs.openstack.org/32/498932/1/check/gate-grenade-dsvm-
  neutron-dvr-multinode-ubuntu-xenial/6ba16a7/logs/grenade.sh.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1713927/+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 1359774] Re: No way to specify initial services region during login

2017-10-04 Thread Ying Zuo 
*** This bug is a duplicate of bug 1703390 ***
https://bugs.launchpad.net/bugs/1703390

** This bug has been marked a duplicate of bug 1703390
   Allow setting default region to log into

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

Title:
  No way to specify initial services region during login

Status in django-openstack-auth:
  Invalid
Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  If keystone is set up with multiple service regions, the initial
  service region is selected for you.  This is done by searching the
  service catalog for the first non-identity service and then selecting
  the region for the first endpoint.  This is an inconvenience when the
  user knows exactly which service region they want to use first.

To manage notifications about this bug go to:
https://bugs.launchpad.net/django-openstack-auth/+bug/1359774/+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 1721369] [NEW] Volume Retype of attached volume with active VM does not work

2017-10-04 Thread Trinh Lee 
Public bug reported:

Steps to reproduce:

1. Boot a Nova VM instance and make sure it is ACTIVE and running fine.
2. Create a new Cinder volume.
3. Attach the above Cinder volume to the above active (running) VM.
3. Try to migrate this ATTACHED volume between different storages of the same 
type (cinder retype with --migration-policy on-demand )
4. The retyped volume gets stuck at "Retyping" state forever.

Expected result:
The attached volume should be retyped to another storage.

Notes: no specific errors observed from the cinder-volumes.log or 
cinder-api.log.
The attached volume is simply stuck at "Retyping" state. A new (temporary) 
volume was created but stuck at "Migrating" state forever as well.

This issue was observed on the latest Liberty branch. But I believe the
same issue might happen with Ocata as well.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: cinder libvirt nova volume

** Tags added: cinder libvirt nova volume

** Description changed:

  Steps to reproduce:
  
  1. Boot a Nova VM instance and make sure it is ACTIVE and running fine.
  2. Create a new Cinder volume.
  3. Attach the above Cinder volume to the above active (running) VM.
  3. Try to migrate this ATTACHED volume between different storages of the same 
type (cinder retype with --migration-policy on-demand )
  4. The retyped volume gets stuck at "Retyping" state forever.
  
  Expected result:
  The attached volume should be retyped to another storage.
  
- Notes: no specific errors observed from the cinder-volumes.log or 
cinder-api.log. 
+ Notes: no specific errors observed from the cinder-volumes.log or 
cinder-api.log.
  The attached volume is simply stuck at "Retyping" state. A new (temporary) 
volume was created but stuck at "Migrating" state forever as well.
+ 
+ This issue was observed on the latest Liberty branch. But I believe the
+ same issue might happen with Ocata as well.

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

Title:
  Volume Retype of attached volume with active VM does not work

Status in OpenStack Compute (nova):
  New

Bug description:
  Steps to reproduce:

  1. Boot a Nova VM instance and make sure it is ACTIVE and running fine.
  2. Create a new Cinder volume.
  3. Attach the above Cinder volume to the above active (running) VM.
  3. Try to migrate this ATTACHED volume between different storages of the same 
type (cinder retype with --migration-policy on-demand )
  4. The retyped volume gets stuck at "Retyping" state forever.

  Expected result:
  The attached volume should be retyped to another storage.

  Notes: no specific errors observed from the cinder-volumes.log or 
cinder-api.log.
  The attached volume is simply stuck at "Retyping" state. A new (temporary) 
volume was created but stuck at "Migrating" state forever as well.

  This issue was observed on the latest Liberty branch. But I believe
  the same issue might happen with Ocata as well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1721369/+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 1695861] Re: Invalid availability zone name with ':' is accepted

2017-10-04 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/490722
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=38b25397e805dcf7a995666049713304fe4f1af1
Submitter: Jenkins
Branch:master

commit 38b25397e805dcf7a995666049713304fe4f1af1
Author: Tetsuro Nakamura 
Date:   Fri Aug 4 11:29:00 2017 +0900

fix nova accepting invalid availability zone name with ':'

Nova has a legacy hack to allow admins to specify hosts via an
availability zone using az:host:node. That means ':' cannot be
included in the name of an availability zone itself.

However, the aggregate API accepts requests which have
availability zone names including ':'.

This patch checks the availabilty zone name when aggregate is
created or updated and raises an error if it contains ':'.

Change-Id: I9b0d8e8d4b3ab2cb3d578c22fa259e0e7c0d325b
Closes-Bug: #1695861


** Changed in: nova
   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/1695861

Title:
  Invalid availability zone name with ':' is accepted

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
  Confirmed
Status in OpenStack Compute (nova) pike series:
  Confirmed

Bug description:
  According to the parse_availability_zone() of the API class [1], Nova
  has a legacy hack to allow admins to specify hosts via an availability
  zone using az:host:node. That means ':' cannot be included in the name
  of an availability zone itself. However, the create aggregate API
  accepts requests which have availability zone names including ':'.
  That causes a following bad scenario:

  1. An admin creates a host aggregate with availability_zone = bad:name:example
  2. An admin tries to create a server with availability_zone = bad:name:example
  3. The nova-api parse the request and split the availability_zone value with 
':'
  4. Then it recognizes az=bad, host=name, node=example
  5. Nova returns 'No valid host found' because there is no availability zone 
whose name is 'bad'.

  To solve this problem following fixes are needed:

  Option A:
  * Do not allow admins to create a host aggregate whose availability_zone name 
including ':'.
  * Document this specification.

  Option B:
  * Deprecate the legacy admin hack which uses  az:host:node and allow ':' for 
az name.

  [1]
  
https://review.openstack.org/gitweb?p=openstack/nova.git;a=blob;f=nova/compute/api.py;h=46ed8e91fcc16f3755fd6a5e2e4a6d54f990cb8b;hb=HEAD#l561

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1695861/+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 997763] Re: floating ips are not disassociated from instances on deletion

2017-10-04 Thread Graham Hayes 
** No longer affects: designate

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

Title:
  floating ips are not disassociated from instances on deletion

Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) essex series:
  Fix Released
Status in nova package in Ubuntu:
  Fix Released
Status in nova source package in Precise:
  Fix Released

Bug description:
  The following scenario does not work:

  nova add-floating-ip  

  nova delete 

  nova "floating-ip-list" renders error like this:
  "The server has either erred or is incapable of performing the requested 
operation"

  This is because there's still mapping between the fixed ip of the deleted 
instance and floating ip left.
  Right now one must explicitly type:
  nova remove-floating-ip  
  nova delete 

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/997763/+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 1721301] [NEW] Database Rights for Glance

2017-10-04 Thread John Studarus 
Public bug reported:


This bug tracker is for errors with the documentation, use the following
as a template and remove or add fields as you see fit. Convert [ ] into
[x] to check boxes:

- [ ] This doc is inaccurate in this way: __
- [ ] This is a doc addition request.
- [X] I have a fix to the document that I can paste below including example: 
input and output. 

If you have a troubleshooting or support issue, use the following
resources:

 - Ask OpenStack: http://ask.openstack.org
 - The mailing list: http://lists.openstack.org
 - IRC: 'openstack' channel on Freenode

---
Release: 15.0.1.dev1 on 'Mon Aug 7 01:28:54 2017, commit 9091d26'
SHA: 9091d262afb120fd077bae003d52463f833a4fde
Source: 
https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/install-ubuntu.rst
URL: https://docs.openstack.org/glance/pike/install/install-ubuntu.html

The current documents need to be updated to include create and assigning 
database rights.
This would apply to all the OS version pages.

create database glance;
GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%'  IDENTIFIED BY 'GLANCE_DBPASS';
GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost'  IDENTIFIED BY 
'GLANCE_DBPASS';
flush privileges;

** Affects: glance
 Importance: Undecided
 Status: New

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

Title:
  Database Rights for Glance

Status in Glance:
  New

Bug description:

  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [ ] This doc is inaccurate in this way: __
  - [ ] This is a doc addition request.
  - [X] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 15.0.1.dev1 on 'Mon Aug 7 01:28:54 2017, commit 9091d26'
  SHA: 9091d262afb120fd077bae003d52463f833a4fde
  Source: 
https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/install-ubuntu.rst
  URL: https://docs.openstack.org/glance/pike/install/install-ubuntu.html

  The current documents need to be updated to include create and assigning 
database rights.
  This would apply to all the OS version pages.

  create database glance;
  GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%'  IDENTIFIED BY 
'GLANCE_DBPASS';
  GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost'  IDENTIFIED BY 
'GLANCE_DBPASS';
  flush privileges;

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1721301/+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 1721305] [NEW] fips between two provider nets can never work

2017-10-04 Thread Doug Wiegley 
Public bug reported:

If you create two provider networks, mark one as shared, and the other
as external and shared, neutron will happily let you associate a
floating ip from the first to the second.

But, provider nets have gateways outside of neutron's control, so the
NAT on the neutron node can never happen.

But, neutron still tries to fire up an ip on the gateway ip, so it
sometimes works, based on who wins the arp race.

The workaround is to disable the gateway on the networks and put in a
static route for 0.0.0.0/gw instead.

But, umm, yuck.

** 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/1721305

Title:
  fips between two provider nets can never work

Status in neutron:
  New

Bug description:
  If you create two provider networks, mark one as shared, and the other
  as external and shared, neutron will happily let you associate a
  floating ip from the first to the second.

  But, provider nets have gateways outside of neutron's control, so the
  NAT on the neutron node can never happen.

  But, neutron still tries to fire up an ip on the gateway ip, so it
  sometimes works, based on who wins the arp race.

  The workaround is to disable the gateway on the networks and put in a
  static route for 0.0.0.0/gw instead.

  But, umm, yuck.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1721305/+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 1721256] [NEW] native OpenFlow does not support resubmit to previous tables

2017-10-04 Thread David Shaughnessy 
Public bug reported:

When moving traffic between the OpenFlow tables it can be necessary to move 
traffic back to an earlier table to be reprocessed.
This action is supported when using the ofctl implementation however when the 
of_interface is set to native the follow error is thrown:
RuntimeError: ofctl request 
version=0x4,msg_type=0xe,msg_len=0x40,xid=0x4bd1c40f,OFPFlowMod(buffer_id=4294967295,command=0,cookie=13554728807927189788,cookie_mask=0,flags=0,hard_timeout=0,idle_timeout=0,instructions=[OFPInstructionGotoTable(len=8,table_id=50,type=1)],match=OFPMatch(oxm_fields={}),out_group=0,out_port=0,priority=5,table_id=60)
 error OpenFlow errors [OFPErrorMsg(code=2,data=bytearray(),type=3)]

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: ovs

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

Title:
  native OpenFlow does not support resubmit to previous tables

Status in neutron:
  New

Bug description:
  When moving traffic between the OpenFlow tables it can be necessary to move 
traffic back to an earlier table to be reprocessed.
  This action is supported when using the ofctl implementation however when the 
of_interface is set to native the follow error is thrown:
  RuntimeError: ofctl request 
version=0x4,msg_type=0xe,msg_len=0x40,xid=0x4bd1c40f,OFPFlowMod(buffer_id=4294967295,command=0,cookie=13554728807927189788,cookie_mask=0,flags=0,hard_timeout=0,idle_timeout=0,instructions=[OFPInstructionGotoTable(len=8,table_id=50,type=1)],match=OFPMatch(oxm_fields={}),out_group=0,out_port=0,priority=5,table_id=60)
 error OpenFlow errors [OFPErrorMsg(code=2,data=bytearray(),type=3)]

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1721256/+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 1285000] Re: instance data resides on destination node when vm is deleted during live-migration

2017-10-04 Thread Matt Riedemann 
** Changed in: nova
   Status: In Progress => Fix Released

** Changed in: nova/ocata
   Status: In Progress => Fix Released

** Changed in: nova/pike
   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/1285000

Title:
  instance data resides on destination node when vm is deleted during
  live-migration

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) newton series:
  Won't Fix
Status in OpenStack Compute (nova) ocata series:
  Fix Released
Status in OpenStack Compute (nova) pike series:
  Fix Released

Bug description:
  If the VM is deleted during live-migration process, there is possibility that 
the instance data residing on the destination compute node is not deleted.
  Please refer to http://paste.openstack.org/show/69730/ reproduce the issue.

  IMO, One of the possible solution is to restrict the user from
  deleting the VM when live-migration is in progress.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1285000/+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 1702454] Re: Transforming the RequestSpec object into legacy dicts doesn't support the requested_destination field

2017-10-04 Thread Matt Riedemann 
** Also affects: nova/pike
   Importance: Undecided
   Status: New

** Also affects: nova/newton
   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/1702454

Title:
  Transforming the RequestSpec object into legacy dicts doesn't support
  the requested_destination field

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) newton series:
  New
Status in OpenStack Compute (nova) ocata series:
  New
Status in OpenStack Compute (nova) pike series:
  New

Bug description:
  We added a new field in the RequestSpec object called
  'requested_destination' and we began using it for evacuations by
  https://review.openstack.org/#/c/315572/ (Newton)

  That object was tranformed into legacy dictionaries (called
  "filter_properties" and "request_spec") before being rehydrated for
  the rebuild_instance() method in the conductor service. That said,
  when transforming, we were forgetting about the
  'requested_destination' field in the object so that when we were
  calling the scheduler, we were never using that field.

  That bug was fixed implicitly by
  https://review.openstack.org/#/c/469037/ which is now merged in
  master, but the issue is still there in stable branches, and if you
  need to use the legacy methods, you'll not have it.

  As a consequence, the feature to pass a destination for evacuation is
  not working in Newton and Ocata. Fortunately, given we didn't
  transformed the object into dicts before calling the scheduler for
  live-migrations, it does work for that action.

  A proper resolution would be to make sure that we pass the
  requested_destination field into 'filter_properties' so that when
  transforming again into an object, we set again the field.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1702454/+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 1712210] Re: Live migration does not restrict to the original cell

2017-10-04 Thread Matt Riedemann 
https://review.openstack.org/#/c/496729/ is merged, but the commit
targeted a different bug, which is why it didn't close this out. It was
fixed in the 16.0.0 Pike GA.

** Changed in: nova/pike
 Assignee: (unassigned) => Matt Riedemann (mriedem)

** Changed in: nova/pike
   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/1712210

Title:
  Live migration does not restrict to the original cell

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) pike series:
  Fix Released

Bug description:
  Migration operations between multiple cells is not supported in Pike,
  but the LiveMigrateTask in conductor does not restrict the
  RequestSpec.requested_destination.cell to the original cell that the
  instance is in when calling the scheduler's select_destination method.

  
https://github.com/openstack/nova/blob/16.0.0.0rc1/nova/conductor/tasks/live_migrate.py#L153

  And when forcing a host during live migration, it completely bypasses
  the scheduler altogether:

  
https://github.com/openstack/nova/blob/16.0.0.0rc1/nova/conductor/tasks/live_migrate.py#L91

  We could fix the former by adding the cell mapping to the
  requested_destination like for a cold migration:

  
https://github.com/openstack/nova/blob/16.0.0.0rc1/nova/conductor/tasks/migrate.py#L51-L65

  As for the latter (forced host, bypass the scheduler), we could just
  leave it and let it fail - you'd likely get some kind of unhelpful RPC
  error since the computes can't talk to each other. Or we could get the
  cell mapping for the source node and destination node and verify they
  are the same and fail in a clear way if they are not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1712210/+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 1721179] Re: A cell cannot be deleted once a host is added to the cell

2017-10-04 Thread Matt Riedemann 
** Changed in: nova
   Importance: Undecided => Medium

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

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

** Changed in: nova/ocata
   Status: New => Confirmed

** Changed in: nova/pike
   Status: New => Confirmed

** Changed in: nova/pike
   Importance: Undecided => Medium

** Changed in: nova/ocata
   Importance: Undecided => Medium

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

Title:
  A cell cannot be deleted once a host is added to the cell

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) ocata series:
  Confirmed
Status in OpenStack Compute (nova) pike series:
  Confirmed

Bug description:
  Description
  ===

  In cell v2 environment, once a host is added to a cell,
  the cell cannot be deleted even though the cell does not have any hosts.

  Steps to reproduce
  ==

  In cell v2 environment, a cell to delete has only one compute host.

  1. Delete the nova-compute service

  > nova service-delete db8e01f5-021d-4c87-a4eb-f3e5089e6105

  The records are soft deleted in the 'services' table and the 'compute_nodes' 
table of the cell database. 
  But the record in 'host_mappings' table of api database is not deleted.

  2. Delete the cell

  > nova-manage cell_v2 delete_cell --cell_uuid 
0fcd92ba-b257-4fbc-94d5-9ac6a77ccf81
  There are existing hosts mapped to cell with uuid 
0fcd92ba-b257-4fbc-94d5-9ac6a77ccf81.

  The command fails with the message above.
  It is caused because the host record remains in the 'host_mappings' table of 
api database.

  But there is no ways to delete the host record in the 'host_mappings'
  table.

  Expected result
  ===

  The cell can be deleted if the cell does not have any hosts.
  Or we should have the way to delete the host from the cell.

  Actual result
  =

  The cell cannot be deleted even though the cell does not have any hosts.
  (We don't have the way to delete the host from the cell.)

  Environment
  ===

  OS: Ubuntu 16.04.2 LTS
  nova master(commit 8ca24bf1ff80f39b14726aca22b5cf52603ea5a0)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1721179/+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 1721243] [NEW] cc_resizefs for zfs/zpool

2017-10-04 Thread do3meli 
Public bug reported:

the resizefs module is not able to handle zfs/zpool resizing for the
root filesystem. if tried so we get the error message: "Could not
determine filesystem type of /".

version: cloud_init-17.1-py2.7.egg

** Affects: cloud-init
 Importance: Undecided
 Status: New

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

Title:
  cc_resizefs for zfs/zpool

Status in cloud-init:
  New

Bug description:
  the resizefs module is not able to handle zfs/zpool resizing for the
  root filesystem. if tried so we get the error message: "Could not
  determine filesystem type of /".

  version: cloud_init-17.1-py2.7.egg

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1721243/+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 1668223] Re: subnet create is not working with --use-default-subnet-pool

2017-10-04 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/503000
Committed: 
https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=c315d5802d0aa5fa597db7cee7aa82c24c2ae4c2
Submitter: Jenkins
Branch:master

commit c315d5802d0aa5fa597db7cee7aa82c24c2ae4c2
Author: Jens Harbott 
Date:   Tue Sep 12 13:27:01 2017 +

Add the default-subnetpools extension to api-ref

Add a section about it in the subnet documentation and show the
``use_default_subnetpool`` is an optional parameter for the subnet create
and bulk-create requests.

Change-Id: I145bc3c86d6e0a4a062879dee8075199473d9904
Closes-Bug: 1668223


** 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/1668223

Title:
  subnet create is not working with --use-default-subnet-pool

Status in neutron:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released

Bug description:
  Seems like the option is not passed properly to the API:

  $ openstack --debug subnet create --ip-version 6 --use-default-subnet-pool 
--ipv6-address-mode slaac --ipv6-ra-mode slaac --network mynet mysubnet
  ...
  REQ: curl -g -i -X POST http://10.42.1.126:9696/v2.0/subnets -H "User-Agent: 
openstacksdk/0.9.13 keystoneauth1/2.18.0 python-requests/2.12.5 CPython/2.7.12" 
-H "Content-Type: application/json" -H "X-Auth-Token: 
{SHA1}c61b74f7c026e385b8953576101f854d86cb0d48" -d '{"subnet": {"network_id": 
"1f20da97-ddd4-40f8-b8d3-6321de8671a0", "ipv6_ra_mode": "slaac", "ip_version": 
6, "name": "mysubnet", "ipv6_address_mode": "slaac"}}'
  http://10.42.1.126:9696 "POST /v2.0/subnets HTTP/1.1" 400 146
  RESP: [400] Content-Type: application/json Content-Length: 146 
X-Openstack-Request-Id: req-299d7f52-d5ce-4873-979d-f63626f380ab Date: Mon, 27 
Feb 2017 10:30:31 GMT Connection: keep-alive 
  RESP BODY: {"NeutronError": {"message": "Bad subnets request: a subnetpool 
must be specified in the absence of a cidr.", "type": "BadRequest", "detail": 
""}}
  ...
  HttpException: HttpException: Bad Request, Bad subnets request: a subnetpool 
must be specified in the absence of a cidr.

  END return value: 1
  $

  Running the same command using the neutron CLI is working fine:

  $ neutron --debug subnet-create --name subnet6 --ip_version 6 
--use-default-subnetpool --ipv6-address-mode slaac --ipv6-ra-mode slaac mynet
  ...
  DEBUG: keystoneauth.session REQ: curl -g -i -X POST 
http://10.42.1.126:9696/v2.0/subnets.json -H "User-Agent: python-neutronclient" 
-H "Content-Type: application/json" -H "Accept: application/json" -H 
"X-Auth-Token: {SHA1}dd78a0939a35913dad4181aaf5f68e0c9277d74e" -d '{"sub
  net": {"use_default_subnetpool": true, "network_id": 
"1f20da97-ddd4-40f8-b8d3-6321de8671a0", "ipv6_ra_mode": "slaac", "ip_version": 
6, "ipv6_address_mode": "slaac", "name": "subnet6"}}'
  DEBUG: keystoneauth.session RESP: [201] Content-Type: application/json 
Content-Length: 735 X-Openstack-Request-Id: 
req-13f0bc2a-e4e5-43dc-b048-e63acef8f131 Date: Mon, 27 Feb 2017 10:46:32 GMT 
Connection: keep-alive 
  RESP BODY: {"subnet": {"service_types": [], "description": "", "enable_dhcp": 
true, "tags": [], "network_id": "1f20da97-ddd4-40f8-b8d3-6321de8671a0", 
"tenant_id": "6de6f29dcf904ab8a12e8ca558f532e9", "created_at": 
"2017-02-27T10:46:31Z", "dns_nameservers": [], "updated_at":
   "2017-02-27T10:46:31Z", "gateway_ip": "2001:db8:1234::1", "ipv6_ra_mode": 
"slaac", "allocation_pools": [{"start": "2001:db8:1234::2", "end": 
"2001:db8:1234:0::::"}], "host_routes": [], "revision_number": 
2, "ip_version": 6, "ipv6_address_mode": "slaac", "c
  idr": "2001:db8:1234::/64", "project_id": "6de6f29dcf904ab8a12e8ca558f532e9", 
"id": "ebb07be0-3f8d-4219-afbd-f81ca352954d", "subnetpool_id": 
"4c1661ba-b24c-4fda-8815-3f1fd29281af", "name": "subnet6"}}
  ...

  So somehow this attribute is missing from the OSC's request:

  "use_default_subnetpool": true

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