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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
