Open Stack

On 3/20/2018 5:57 PM, melanie witt wrote:
>      * For rebuild, we're going to defer the instance.save() until 
> conductor has passed scheduling and before it casts to compute in order 
> to address the issue of rolling back instance values if something fails 
> during rebuild scheduling

I got to thinking about why the API does the instance.save() before 
casting to conductor, and realized that if we changed that, the POST 
response for rebuild will be different, because the handler code looks 
up the updated instance from the DB to form the response body. So if we 
move the save() to conductor, the response body will change and that's a 
behavior change, unless there is another way to handle this without 
duplicating a bunch of logic.

>    *  XenAPI: support non file system based SR types - e.g. LVM, ISCSI
>      * Currently xenapi is only file system-based, cannot yet support 
> LVM, ISCSI that are supported by XenServer
>      * We agreed that a specless blueprint is fine for this: 
> https://blueprints.launchpad.net/nova/+spec/xenapi-image-handler-option-improvement 
> 

This blueprint isn't approved yet. Is someone going to bring it up in 
the nova meeting, or are we just going to approve since it there was 
agreement to do so at the PTG?

>    * Block device mapping creation races during attach volume
>      * We agreed to create a nova-manage command to do BDM clean up and 
> then add a unique constraint in S
>      * mriedem will restore the device name spec and someone else can 
> pick it up

The spec is now restored:

https://review.openstack.org/#/c/452546/

But I don't know who was going to take it over (dansmith?).

>    * Validate policy when creating a server group
>      * We can create a server group that have no policies (empty 
> policies) currently. We can create a server with it, but all related 
> scheduler filters return True, so it is useless
>      * Spec: https://review.openstack.org/#/c/546484
>      * We agreed this should be a simple thing to do, spec review is 
> underway. We also said we should consider lumping in some other trivial 
> API cleanup into the same microversion - we have a lot of TODOs for 
> similar stuff like this in the API

I think https://review.openstack.org/#/c/546925/ will supersede ^ so we 
should probably hold off on Takashi's spec until we know for sure what 
we're doing about the hard-affinity policy limit stuff.

-- 

Thanks,

Matt