Open Stack

On Wed, Jul 19, 2017 at 5:38 PM, McLellan, Steven 
<steve.mclellan at hpe.com> wrote:
> Thanks Balazs for noticing and replying to my message!
> 
> The Status field is quite important to us since it's the indicator of 
> VM state that Horizon displays most prominently and the most simple 
> description of whether a VM is currently usable or not without having 
> to parse the various _state fields. If we can't get this change added 
> in Pike I'll probably implement a simplified version of the mapping 
> in [2], but it would be really good to get it into the notifications 
> in Pike if possible. I understand though that this late in the cycle 
> it may not be possible.

I can create a patch to add the status to the instance notifications 
but I don't know if nova cores accept it for this late in Pike.
@Cores: Do you?

Cheers,
gibi

> 
> 
> Thanks,
> 
> Steve
> 
> On 7/19/17, 10:27 AM, "Balazs Gibizer" <balazs.gibizer at ericsson.com> 
> wrote:
> 
>     Hi,
> 
>     Steve asked the following question on IRC [1]
> 
>     < sjmc7> hi gibi. sorry, meant to bring this up in the 
> notifications
>     meeting but i had to step away for a bit. we were having a 
> discussion
>     last week about the field that the API returns as 'status' - do 
> the
>     notifications have an equivalent?
> 
>     I will try to answer it here so others can chime in.
> 
>     Internally in nova an instance has vm_state, task_state and
>     power_state. On the REST API the instance has status which is
>     calculated from vm_state and task_state. See the code doing the
>     conversion here [2]. The instance notifications contain both the
>     vm_state, task_state and power_state of the instance but do not 
> contain
>     the calculated status value [3]. The instance.update notification 
> has
>     extra state fields to signal possible state transitions [4].
> 
>     Technically we can add the calculated status field to the 
> notifications
>     but it is not there at the moment. So if searchlight needs that 
> info
>     right now then it needs to be calculated on searchlight side 
> based on
>     the vm_state and the task_state from the notification.
> 
>     Adding this field can be a continuation of the bp
>     additional-notification-fields-for-searchlight [5] in Queens.
> 
> 
>     Cheers,
>     gibi
> 
>     [1]
>     
> http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-07-18.log.html#t2017-07-18T17:39:36
>     [2]
>     
> https://github.com/openstack/nova/blob/a4a9733f4a9ead01356f0f76c1bb1f04f905fa4e/nova/api/openstack/common.py#L113
>     [3]
>     
> https://github.com/openstack/nova/blob/2e4417d57cb6f74664c5746b43db9a96797f33e9/nova/notifications/objects/instance.py#L52-L54
>     [4]
>     
> https://github.com/openstack/nova/blob/2e4417d57cb6f74664c5746b43db9a96797f33e9/nova/notifications/objects/instance.py#L352
>     [5]
>     
> https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight
> 
> 
>     
> __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev