Field 'updated_at' always 'None' when show aggregate

Bug #1663456 reported by Eric Xie
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
In Progress
Low
Brin Zhang

Bug Description

Description
===========
When i got detailed info of one host aggregate with CLI `openstack aggregate show`,
the field 'updated_at' always was 'None'.

Steps to reproduce
==================
* Create one host aggregate with CLI `openstack aggregate create t-sh`
* Set some properties for the aggregate with CLI `openstack aggregate set --zone tztz --property foo=bar agg-sh`
* Get detailed info of the aggregate with CLI `openstack aggregate show agg-sh`

Expected result
===============
| updated_at | 2017-02-10T03:27:25.535045 |

Actual result
=============
| updated_at | None |

Environment
===========
1. nova version
[root@controller nova]# git log
commit 50d402821be7476eb58ccd791c50d8ed801e85eb
Author: Matt Riedemann <email address hidden>
Date: Wed Feb 8 10:23:14 2017 -0500

    Consider startup scenario in _get_compute_nodes_in_db

2. Which hypervisor did you use?
devstack + libvirt + kvm

Logs
==============
Enable --debug in openstack command.
* Set some properties for the aggregate with '--debug'.
RESP BODY: {"aggregate": {"name": "agg-sh", "availability_zone": "tztz", "deleted": false, "created_at": "2017-02-10T03:26:21.000000", "updated_at": "2017-02-10T03:27:25.535045", "hosts": [], "deleted_at": null, "id": 4, "metadata": {"foo": "bar", "availability_zone": "tztz"}}}

Note: field 'updated_at' has valid value.

* Get detailed info with '--debug'
RESP BODY: {"aggregates": [{"name": "agg-1", "availability_zone": "tz1", "deleted": false, "created_at": "2017-02-10T02:09:47.000000", "updated_at": null, "hosts": ["controller"], "deleted_at": null, "id": 1, "metadata": {"color": "green", "foo": "bar", "availability_zone": "tz1"}}, {"name": "agg-a", "availability_zone": "tz2", "deleted": false, "created_at": "2017-02-10T02:39:15.000000", "updated_at": null, "hosts": [], "deleted_at": null, "id": 2, "metadata": {"foo": "tar", "availability_zone": "tz2"}}, {"name": "t-sh", "availability_zone": "tz3", "deleted": false, "created_at": "2017-02-10T02:39:24.000000", "updated_at": null, "hosts": [], "deleted_at": null, "id": 3, "metadata": {"color": "blue", "hello": "world", "availability_zone": "tz3"}}, {"name": "agg-sh", "availability_zone": "tztz", "deleted": false, "created_at": "2017-02-10T03:26:21.000000", "updated_at": null, "hosts": [], "deleted_at": null, "id": 4, "metadata": {"foo": "bar", "availability_zone": "tztz"}}]}

Note: field 'updated_at' is null.

Eric Xie (eric-xie)
Changed in nova:
status: New → In Progress
assignee: nobody → Eric Xie (eric-xie)
tags: added: host-aggregate
Revision history for this message
Sean Dague (sdague) wrote :

There are no currently open reviews on this bug, changing
the status back to the previous state and unassigning. If
there are active reviews related to this bug, please include
links in comments.

Changed in nova:
status: In Progress → New
assignee: Eric Xie (eric-xie) → nobody
Sean Dague (sdague)
Changed in nova:
status: New → Incomplete
status: Incomplete → Confirmed
importance: Undecided → Medium
tags: added: api
Eric Xie (eric-xie)
Changed in nova:
assignee: nobody → Eric Xie (eric-xie)
Revision history for this message
Theodoros Tsioutsias (ttsiouts) wrote :

Hello,

I checked the issue but I'm not sure if this is a bug.
Indeed, when you use the CLI `openstack aggregate set --zone tztz --property foo=bar agg-sh` the updated_at field remains at 'None'.
The thing is that with this CLI, the metadata of the aggregate get updated and not the aggregate itself. Specifically the table nova_api.aggregate_metadata is getting updated.
On the other hand, if for example, you change the name of the aggregate, using the CLI `aggregate set --name agg-sh-new agg-sh`, the updated_at field gets a correct value since the table nova_api.aggregates is updated.

Best Regards,
Thodoris

Revision history for this message
Omar Muhtaseb (omarm) wrote :

Are there any activities regarding this bug? I would like to assign it to myself

Revision history for this message
Eric Xie (eric-xie) wrote :

@Omar, you can assign it to yourself.

Changed in nova:
assignee: Eric Xie (eric-xie) → nobody
nalini (nvarshney)
Changed in nova:
assignee: nobody → nalini (nvarshney)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

Fix proposed to branch: master
Review: https://review.openstack.org/537334

Changed in nova:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on nova (master)

Change abandoned by nalini (<email address hidden>) on branch: master
Review: https://review.openstack.org/537334

Changed in nova:
assignee: nalini (nvarshney) → Vishakha Agarwal (vishakha.agarwal)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

Fix proposed to branch: master
Review: https://review.openstack.org/580271

Matt Riedemann (mriedem)
Changed in nova:
importance: Medium → Wishlist
status: In Progress → Opinion
assignee: Vishakha Agarwal (vishakha.agarwal) → nobody
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on nova (master)

Change abandoned by Matt Riedemann (<email address hidden>) on branch: master
Review: https://review.opendev.org/580271
Reason: This is old and in merge conflict. I've marked the bug as wishlist/opinion and if someone wants to pursue this I'd suggest bringing it up on the mailing list. As noted earlier, we've had similar discussions about things like updating the parent instance action when one of it's child events is updated/created. Looks like we moved forward with updating the action record's updated_at when the event was finished (updated):

I75a827b759b59773c08ffc6b1e3e54d6189b5853

So we do have precedence for doing this.

Revision history for this message
Matt Riedemann (mriedem) wrote :

This could probably be considered the same as bug 1719561.

Changed in nova:
status: Opinion → Confirmed
importance: Wishlist → Low
Brin Zhang (zhangbailin)
Changed in nova:
assignee: nobody → Brin Zhang (zhangbailin)
Changed in nova:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

Fix proposed to branch: master
Review: https://review.opendev.org/702070

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on nova (master)

Change abandoned by Brin Zhang (<email address hidden>) on branch: master
Review: https://review.opendev.org/702070
Reason: This fix is redundant, in latest version, and base on https://review.opendev.org/#/c/580271/, the aggregare metadata's update_at can be populated automatically.

root@ubuntu-OpenStack:/opt/stack/nova# nova --debug aggregate-set-metadata test_agg0 host1='aaaa'

Version X-OpenStack-Nova-API-Version: 2.81 x-compute-request-id: req-c25e19d5-3862-4bb5-bb96-41fb1d30f389 x-openstack-request-id: req-c25e19d5-3862-4bb5-bb96-41fb1d30f389
DEBUG (session:580) RESP BODY: {"aggregate": {"id": 4, "uuid": "688b4bf1-6927-45bd-9c6c-6ad1108788ea", "name": "test_agg0", "hosts": [], "metadata": {"host1": "aaaa"}, "created_at": "2020-01-14T06:20:18.000000", "updated_at": "2020-01-14T06:21:34.729395", "deleted_at": null, "deleted": false, "availability_zone": null}}
DEBUG (session:943) POST call to compute for http://192.168.190.23/compute/v2.1/os-aggregates/4/action used request id req-c25e19d5-3862-4bb5-bb96-41fb1d30f389
Metadata has been successfully updated for aggregate 4.
+----+-----------+-------------------+-------+--------------+--------------------------------------+
| Id | Name | Availability Zone | Hosts | Metadata | UUID |
+----+-----------+-------------------+-------+--------------+--------------------------------------+
| 4 | test_agg0 | - | | 'host1=aaaa' | 688b4bf1-6927-45bd-9c6c-6ad1108788ea |
+----+-----------+-------------------+-------+--------------+--------------------------------------+

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.