yahoo-eng-team team mailing list archive

[Tony Dunbar <adunbar@xxxxxxxxxx>]

@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