[Yahoo-eng-team] [Bug 1622538] [NEW] Wrong "can_host" field of compute node resource providers
Public bug reported: The "can_host" field of compute node records should be 1. However, according to the latest placement implementation, it is 0. mysql> select * from resource_providers; +-+-++--+-++--+ | created_at | updated_at | id | uuid | name| generation | can_host | +-+-++--+-++--+ | 2016-09-12 08:54:19 | 2016-09-12 09:33:41 | 1 | 508f3973-8e1a-4241-afec-ee3e21be0611 | host1 | 80 |0 | +-+-++--+---++--+ 1 row in set (0.00 sec) ** Affects: nova Importance: Undecided Assignee: Yingxin (cyx1231st) Status: New ** Tags: placement ** Changed in: nova Assignee: (unassigned) => Yingxin (cyx1231st) ** Tags added: placement ** Description changed: The "can_host" field of compute node records should be 1. However, - according to the latest placement code, it is 0. - + according to the latest placement implementation, it is 0. mysql> select * from resource_providers; +-+-++--+-++--+ | created_at | updated_at | id | uuid | name| generation | can_host | +-+-++--+-++--+ | 2016-09-12 08:54:19 | 2016-09-12 09:33:41 | 1 | 508f3973-8e1a-4241-afec-ee3e21be0611 | host1 | 80 |0 | +-+-++--+---++--+ 1 row in set (0.00 sec) -- 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/1622538 Title: Wrong "can_host" field of compute node resource providers Status in OpenStack Compute (nova): New Bug description: The "can_host" field of compute node records should be 1. However, according to the latest placement implementation, it is 0. mysql> select * from resource_providers; +-+-++--+-++--+ | created_at | updated_at | id | uuid | name| generation | can_host | +-+-++--+-++--+ | 2016-09-12 08:54:19 | 2016-09-12 09:33:41 | 1 | 508f3973-8e1a-4241-afec-ee3e21be0611 | host1 | 80 |0 | +-+-++--+---++--+ 1 row in set (0.00 sec) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1622538/+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 1599400] [NEW] nova boot has unexpected API error
Public bug reported: Description: = Nova allow users to set free-form flavor extra-specs "hw:cpu_policy", "hw:cpu_thread_policy". But when boot an instance with that flavor, nova will raise ValueError and result in HTTP 500. Reproduce: = # 1. create flavor 11 with an illegal extra_spec "hw:cpu_thread_policy=shared" $ nova flavor-create test 11 128 1 3 $ nova flavor-key 11 set hw:cpu_policy=dedicated $ nova flavor-key 11 set hw:cpu_thread_policy=shared # 2. boot an instance from that malformed flavor 11 $ nova boot --image --flavor 11 test ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-a26ad5f3-7982-4361-8817-0ab111ac9ab1) ** Affects: nova Importance: Undecided Status: New ** Description changed: Description: = Nova allow users to set free-form flavor extra-specs "hw:cpu_policy", "hw:cpu_thread_policy". But when boot an instance with that flavor, nova will raise ValueError and result in HTTP 500. - Reproduce: = # 1. create flavor 11 with an illegal extra_spec "hw:cpu_thread_policy=shared" $ nova flavor-create test 11 128 1 3 $ nova flavor-key 11 set hw:cpu_policy=dedicated - $nova flavor-key 11 set hw:cpu_thread_policy=shared + $ nova flavor-key 11 set hw:cpu_thread_policy=shared # 2. boot an instance from that malformed flavor 11 - $nova boot --image --flavor 11 test + $ nova boot --image --flavor 11 test ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-a26ad5f3-7982-4361-8817-0ab111ac9ab1) ** Summary changed: - nova boot unexpected API error + nova boot has unexpected API error -- 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/1599400 Title: nova boot has unexpected API error Status in OpenStack Compute (nova): New Bug description: Description: = Nova allow users to set free-form flavor extra-specs "hw:cpu_policy", "hw:cpu_thread_policy". But when boot an instance with that flavor, nova will raise ValueError and result in HTTP 500. Reproduce: = # 1. create flavor 11 with an illegal extra_spec "hw:cpu_thread_policy=shared" $ nova flavor-create test 11 128 1 3 $ nova flavor-key 11 set hw:cpu_policy=dedicated $ nova flavor-key 11 set hw:cpu_thread_policy=shared # 2. boot an instance from that malformed flavor 11 $ nova boot --image --flavor 11 test ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-a26ad5f3-7982-4361-8817-0ab111ac9ab1) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1599400/+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 1523506] Re: hosts within two availability zones
** Changed in: nova Status: Incomplete => Invalid -- 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/1523506 Title: hosts within two availability zones Status in OpenStack Compute (nova): Invalid Bug description: There have been a lot of bug fixes related to this topic, but it still exists somehow. Some previous fix-released bugs for example: https://bugs.launchpad.net/nova/+bug/1200479 https://bugs.launchpad.net/nova/+bug/1196893 https://bugs.launchpad.net/nova/+bug/1277230 The mailing list has already decided not to allow hosts in different AZs (http://lists.openstack.org/pipermail/openstack- dev/2014-April/031803.html), but it can still be reproduced by following 3 steps: start repro 1) create two host aggregates "foo", "bar" to the default AZ: $ nova aggregate-create foo ++--+---+---+--+ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+---+--+ | 58 | foo | - | | | ++--+---+---+--+ $ nova aggregate-create bar ++--+---+---+--+ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+---+--+ | 59 | bar | - | | | ++--+---+---+--+ 2) assign a host "node2" to both aggregates $ nova aggregate-add-host foo node2 ++--+---+-+--+ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+-+--+ | 58 | foo | - | 'node2' | | ++--+---+-+--+ $ nova aggregate-add-host bar node2 ++--+---+-+--+ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+-+--+ | 59 | bar | - | 'node2' | | ++--+---+-+--+ 3) change "foo" to a named AZ called "az" $ nova aggregate-update foo foo az Aggregate 58 has been successfully updated. ++--+---+-++ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+-++ | 58 | foo | az| 'node2' | 'availability_zone=az' | ++--+---+-++ end repro The third step should NOT happen because it causes "node2" belong to both default AZ and "az" AZ, logically: $ nova aggregate-details foo ++--+---+-++ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+-++ | 58 | foo | az| 'node2' | 'availability_zone=az' | ++--+---+-++ $ nova aggregate-details bar ++--+---+-+--+ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+-+--+ | 59 | bar | - | 'node2' | | ++--+---+-+--+ Interesting thing is, "node2" is actually only belong to the availibility zone "az" if we list all the AZs. Thanks to the previous bug fixings: $ nova availability-zone-list +---++ | Name | Status | +---++ | internal | available | | |- node1 || | | |- nova-conductor | enabled :-) 2015-12-07T13:45:59.00 | | | |- nova-consoleauth | enabled :-) 2015-12-07T13:45:59.00 | | | |- nova-scheduler | enabled :-) 2015-12-07T13:46:02.00 | | | |- nova-cert| enabled :-) 2015-12-07T13:46:01.00 | | az| available | | |- node2 || | | |- nova-compute | enabled :-) 2015-12-07T13:46:04.00 | +---++ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1523506/+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 1550098] [NEW] Disk resource consumption is inconsistent between scheduler and resource tracker
Public bug reported: The way scheduler consumes disk resources in host state is inconsistent with RT's way in compute service. The scheduler consumes "free_disk_mb" in its host state. https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L266 It comes from the min value of "free_disk_gb" and "disk_available_least" in ComputeNode object. https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L189-L201 But compute node changes "local_gb_used" instead in consuming resources from a request. https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L709-L710 There is a inconsistent gap(confirmed) of compute node state between scheduler and resource tracker, but somehow the compute node will be updated by virt driver to the consistent status after maybe 10 seconds. ** Affects: nova Importance: Undecided Assignee: Yingxin (cyx1231st) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Yingxin (cyx1231st) ** Changed in: nova Status: New => In Progress -- 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/1550098 Title: Disk resource consumption is inconsistent between scheduler and resource tracker Status in OpenStack Compute (nova): In Progress Bug description: The way scheduler consumes disk resources in host state is inconsistent with RT's way in compute service. The scheduler consumes "free_disk_mb" in its host state. https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L266 It comes from the min value of "free_disk_gb" and "disk_available_least" in ComputeNode object. https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L189-L201 But compute node changes "local_gb_used" instead in consuming resources from a request. https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L709-L710 There is a inconsistent gap(confirmed) of compute node state between scheduler and resource tracker, but somehow the compute node will be updated by virt driver to the consistent status after maybe 10 seconds. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1550098/+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 1523506] [NEW] hosts within two availability zones
Public bug reported: There have been a lot of bug fixes related to this topic, but it still exists somehow. Some previous fix-released bugs for example: https://bugs.launchpad.net/nova/+bug/1200479 https://bugs.launchpad.net/nova/+bug/1196893 https://bugs.launchpad.net/nova/+bug/1277230 The mailing list has already decided not to allow hosts in different AZs (http://lists.openstack.org/pipermail/openstack- dev/2014-April/031803.html), but it can still be reproduced by following 3 steps: start repro 1) create two host aggregates "foo", "bar" to the default AZ: $ nova aggregate-create foo ++--+---+---+--+ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+---+--+ | 58 | foo | - | | | ++--+---+---+--+ $ nova aggregate-create bar ++--+---+---+--+ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+---+--+ | 59 | bar | - | | | ++--+---+---+--+ 2) assign a host "node2" to both aggregates $ nova aggregate-add-host foo node2 ++--+---+-+--+ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+-+--+ | 58 | foo | - | 'node2' | | ++--+---+-+--+ $ nova aggregate-add-host bar node2 ++--+---+-+--+ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+-+--+ | 59 | bar | - | 'node2' | | ++--+---+-+--+ 3) change "foo" to a named AZ called "az" $ nova aggregate-update foo foo az Aggregate 58 has been successfully updated. ++--+---+-++ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+-++ | 58 | foo | az| 'node2' | 'availability_zone=az' | ++--+---+-++ end repro The third step should NOT happen because it causes "node2" belong to both default AZ and "az" AZ, logically: $ nova aggregate-details foo ++--+---+-++ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+-++ | 58 | foo | az| 'node2' | 'availability_zone=az' | ++--+---+-++ $ nova aggregate-details bar ++--+---+-+--+ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+-+--+ | 59 | bar | - | 'node2' | | ++--+---+-+--+ Interesting thing is, "node2" is actually only belong to the availibility zone "az" if we list all the AZs. Thanks to the previous bug fixings: $ nova availability-zone-list +---++ | Name | Status | +---++ | internal | available | | |- node1 || | | |- nova-conductor | enabled :-) 2015-12-07T13:45:59.00 | | | |- nova-consoleauth | enabled :-) 2015-12-07T13:45:59.00 | | | |- nova-scheduler | enabled :-) 2015-12-07T13:46:02.00 | | | |- nova-cert| enabled :-) 2015-12-07T13:46:01.00 | | az| available | | |- node2 || | | |- nova-compute | enabled :-) 2015-12-07T13:46:04.00 | +---++ ** Affects: nova Importance: Undecided Assignee: Yingxin (cyx1231st) Status: New ** Tags: scheduler ** Changed in: nova Assignee: (unassigned) => Yingxin (cyx1231st) ** Tags added: scheduler -- 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/1523506 Title: hosts within two availability zones Status in OpenStack Compute (nova): New Bug description: There have been a lot of bug fixes related to this topic, but it still exists somehow. Some previous fix-released bugs for example: https://bugs.launchpad
[Yahoo-eng-team] [Bug 1523459] [NEW] Instance can be booted into the "internal" availability zone
Public bug reported: Currently, only the nova-compute service has its own availability zone. Services such as nova-scheduler, nova-network, and nova-conductor appear in the AZ named "internal". (ref: http://docs.openstack.org/openstack-ops/content/scaling.html) For example: $ nova availability-zone-list +---++ | Name | Status | +---++ | internal | available | | |- node1 || | | |- nova-conductor | enabled :-) 2015-12-07T11:38:09.00 | | | |- nova-consoleauth | enabled :-) 2015-12-07T11:38:05.00 | | | |- nova-scheduler | enabled :-) 2015-12-07T11:38:12.00 | | | |- nova-cert| enabled :-) 2015-12-07T11:38:07.00 | | nova | available | | |- node2 || | | |- nova-compute | enabled :-) 2015-12-07T11:38:12.00 | | |- node3 || | | |- nova-compute | enabled :-) 2015-12-07T11:38:12.00 | +---++ However, we can schedule an instance to the "internal" AZ using following command: $ nova boot --flavor 42 --image --availability-zone "internal" test Succeed with no error message! But this "test" instance will be in ERROR status because there is no compute node in the "internal" AZ. $ nova list +--+--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+--+ | eca73033-15cf-402a-b39a-a91e497e3e07 | test | ERROR | - | NOSTATE | | +--+--+++-+--+ ** Affects: nova Importance: Undecided Assignee: Yingxin (cyx1231st) Status: New ** Tags: scheduler ** Changed in: nova Assignee: (unassigned) => Yingxin (cyx1231st) ** Tags added: scheduler ** Description changed: - Currently, only the nova-compute service has its own availability zone. Services such as nova-scheduler, nova-network, and nova-conductor appear in the AZ named "internal". (http://docs.openstack.org/openstack-ops/content/scaling.html) For example: + Currently, only the nova-compute service has its own availability zone. Services such as nova-scheduler, nova-network, and nova-conductor appear in the AZ named "internal". (ref: http://docs.openstack.org/openstack-ops/content/scaling.html) For example: $ nova availability-zone-list +---++ | Name | Status | +---++ | internal | available | | |- node1 || | | |- nova-conductor | enabled :-) 2015-12-07T08:15:49.00 | | | |- nova-consoleauth | enabled :-) 2015-12-07T08:15:50.00 | | | |- nova-scheduler | enabled :-) 2015-12-07T08:15:50.00 | | | |- nova-cert| enabled :-) 2015-12-07T08:15:51.00 | | | available | | |- node2 || | | |- nova-compute | enabled :-) 2015-12-07T08:15:49.00 | | nova | available | | |- node3 || | | |- nova-compute | enabled :-) 2015-12-07T08:15:50.00 | +---++ - However, we can schedule an instance to the "internal" AZ using following command: $ nova boot --flavor 42 --image --availability-zone "internal" test Succeed with no error message! - But this "test" instance will be in ERROR status because there is no compute node in the "internal" AZ. $ nova list +--+--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+--+ | eca73033-15cf-402a-b39a-a91e497e3e07 | test | ERROR | - | NOSTATE | | +--+--+++-+--+ ** Description changed: Currently, only the nova-compute service has its o
[Yahoo-eng-team] [Bug 1523450] [NEW] Empty-named AZ is accepted using aggregate-set-metadata
Public bug reported: An empty-named AZ can be set using the following command if there exists an aggregate 'foo': $nova aggregate-set-metadata foo availability_zone= ++--+---+-+--+ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+-+--+ | 55 | foo | | 'node2' | 'availability_zone=' | ++--+---+-+--+ This empty-named AZ is meaningless and confusing, because it ISN'T the default AZ. For example if we list AZ there will be an empty entry: $nova availability-zone-list +---++ | Name | Status | +---++ | internal | available | | |- node1 || | | |- nova-conductor | enabled :-) 2015-12-07T08:15:49.00 | | | |- nova-consoleauth | enabled :-) 2015-12-07T08:15:50.00 | | | |- nova-scheduler | enabled :-) 2015-12-07T08:15:50.00 | | | |- nova-cert| enabled :-) 2015-12-07T08:15:51.00 | | | available | | |- node2 || | | |- nova-compute | enabled :-) 2015-12-07T08:15:49.00 | | nova | available | | |- node3 || | | |- nova-compute | enabled :-) 2015-12-07T08:15:50.00 | +---++ However, nova scheduler CANNOT distinguish between this empty-named AZ and the default AZ, for example: $nova boot --flavor 42 --image --availability-zone "" test The scheduler will treat "" as default AZ, the 'test' instance will be booted in either "" or the default "nova" AZ. ** Affects: nova Importance: Undecided Assignee: Yingxin (cyx1231st) Status: New ** Tags: scheduler ** Changed in: nova Assignee: (unassigned) => Yingxin (cyx1231st) ** Description changed: An empty-named AZ can be set using the following command if there exists an aggregate 'foo': $nova aggregate-set-metadata foo availability_zone= ++--+---+-+--+ | Id | Name | Availability Zone | Hosts | Metadata | ++--+---+-+--+ | 55 | foo | | 'node2' | 'availability_zone=' | ++--+---+-+--+ - This empty-named AZ is meaningless and confusing, because it ISN'T the default AZ. For example if we list AZ there will be an empty entry: $nova availability-zone-list +---++ | Name | Status | +---++ | internal | available | | |- node1 || | | |- nova-conductor | enabled :-) 2015-12-07T08:15:49.00 | | | |- nova-consoleauth | enabled :-) 2015-12-07T08:15:50.00 | | | |- nova-scheduler | enabled :-) 2015-12-07T08:15:50.00 | | | |- nova-cert| enabled :-) 2015-12-07T08:15:51.00 | | | available | | |- node2 || | | |- nova-compute | enabled :-) 2015-12-07T08:15:49.00 | | nova | available | | |- node3 || | | |- nova-compute | enabled :-) 2015-12-07T08:15:50.00 | +---++ - However, nova scheduler CANNOT distinguish between this empty-named AZ and the default AZ, for example: - $nova boot --flavor 42 --image cirros-0.3.4-x86_64-uec --availability-zone "" test - The scheduler will treat "" as default AZ, the test instance will be booted in either "" or the default "nova" AZ. + $nova boot --flavor 42 --image --availability-zone "" test + The scheduler will treat "" as default AZ, the 'test' instance will be booted in either "" or the default "nova" AZ. ** Tags added: scheduler -- 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/1523450 Title: Empty-named AZ is accepted using a
[Yahoo-eng-team] [Bug 1493680] [NEW] HostState.metrics is no longer a dict
Public bug reported: The commit ae7dab9975bcbe3bb40cb9723b0deaed985b904c changes 'HostState.metrics' from a simple dictionary to 'objects.MonitorMetricList'. But it doesn't change the related behavior in 'weights.MetricsWeigher'. MetricWeigher still treat 'host_state.metrics' as a dictionary of 'host_manager.MetricItem'. It causes MetricWeigher failure during weighing. ** 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/1493680 Title: HostState.metrics is no longer a dict Status in OpenStack Compute (nova): New Bug description: The commit ae7dab9975bcbe3bb40cb9723b0deaed985b904c changes 'HostState.metrics' from a simple dictionary to 'objects.MonitorMetricList'. But it doesn't change the related behavior in 'weights.MetricsWeigher'. MetricWeigher still treat 'host_state.metrics' as a dictionary of 'host_manager.MetricItem'. It causes MetricWeigher failure during weighing. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1493680/+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