@Markus: Thanks for the information. I don't know much about Nova, have mostly worked in Horizon thus far.
Thinking about this some more, it might be safest to make a change in Horizon versus changing Nova and inadvertently causing a regression issue. I can add "soft-delete" to the list we use in Horizon to look up instance states and translate with very little risk; then we would support both "soft_deleted" and "soft-delete". Then if in the future Nova changes to "soft_deleted", Horizon will still work properly. @Markus, @Doug Fish: Is there an easy way to move this defect from Nova to Horizon so I can make the change there? ** Project changed: nova => horizon -- 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/1506177 Title: vm_state 'soft-delete' should be 'soft_deleted' Status in OpenStack Dashboard (Horizon): In Progress Bug description: In https://github.com/openstack/nova/blob/4cf6ef68199183697a0209751575f88fe5b2a733/nova/compute/vm_states.py#L40 the vm_state SOFT_DELETED is mapped to the value 'soft-delete. All the other vm_states are mapped to values that match their state in lower case, so to be consistent SOFT_DELETED should map to 'soft_deleted'. I searched through the Nova code and did not find any references to soft-delete, so a change should not cause any breakage. In Horizon's instance table here: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/instances/tables.py#L1001 the value expected is 'soft_deleted', so changing the value in nova to be consistent should help. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1506177/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
