Its been one week of specifications for Nova in Kilo. What are we seeing proposed so far? Here’s a summary…
- Enable the nova metadata cache to be a shared resource to improve the hit rate: review 126705.
- Implement support for FreeBSD networking in nova-network: review 127827.
- Allow volumes to be stored on SMB shares instead of just iSCSI: review 102190.
- Add ephemeral disk support to the VMware driver: review 126527 (spec approved).
- Add support for the HTML5 console: review 127283.
- Allow Nova to access a VMWare image store over NFS: review 126866.
- Enable administrators and tenants to take advantage of backend storage policies: review 126547 (spec approved).
- Support the OVA image format: review 127054.
- Add a new linuxbridge VIF type, macvtap: review 117465.
- Add support for SMBFS as a image storage backend: review 103203.
- Convert to using built in libvirt disk copy mechanisms for cold migrations on non-shared storage: review 126979.
- Support libvirt storage pools: review 126978.
- Support quiesce filesystems during snapshot: review 126966.
- Allow direct access to LVM volumes if supported by Cinder: review 127318.
- Move flavor data out of the system_metdata table in the SQL database: review 126620.
- Add an IOPS weigher: review 127123 (spec approved).
- Allow limiting the flavors that can be scheduled on certain host aggregates: review 122530.
- Create an object model to represent a request to boot an instance: review 127610.
- Decouple services and compute nodes in the SQL database: review 126895.
- Implement resource objects in the resource tracker: review 127609.
- Move select_destinations() to using a request object: review 127612.
- Provide a reference implementation for console proxies that uses TLS: review 126958.
- Strongly validate the tenant and user for quota consuming requests with keystone: review 92507.
From my email last week on the topic:
I am pleased to announce that the specs process for nova in kilo is
now open. There are some tweaks to the previous process, so please
read this entire email before uploading your spec!
Blueprints approved in Juno
For specs approved in Juno, there is a fast track approval process for
Kilo. The steps to get your spec re-approved are:
- Copy your spec from the specs/juno/approved directory to the
specs/kilo/approved directory. Note that if we declared your spec to
be a "partial" implementation in Juno, it might be in the implemented
directory. This was rare however.
- Update the spec to match the new template
- Commit, with the "Previously-approved: juno" commit message tag
- Upload using git review as normal
Reviewers will still do a full review of the spec, we are not offering
a rubber stamp of previously approved specs. However, we are requiring
only one +2 to merge these previously approved specs, so the process
should be a lot faster.
A note for core reviewers here -- please include a short note on why
you're doing a single +2 approval on the spec so future generations
We are not requiring specs for trivial blueprints in Kilo. Instead,
create a blueprint in Launchpad
at https://blueprints.launchpad.net/nova/+addspec and target the
specification to Kilo. New, targeted, unapproved specs will be
reviewed in weekly nova meetings. If it is agreed they are indeed
trivial in the meeting, they will be approved.
For other proposals, the process is the same as Juno... Propose a spec
review against the specs/kilo/approved directory and we'll review it
After a week I’m seeing something interesting. In Juno the specs process was new, and we saw a pause in the development cycle while people actually wrote down their designs before sending the code. This time around people know what to expect, and there are left over specs from Juno lying around. We’re therefore seeing specs approved much faster than in Kilo. This should reduce the effect of the “pipeline flush” that we saw in Juno.
So far we have five approved specs after only a week.
As we get closer to releasing the RC1 of Nova for Juno, I’ve started collecting a list of all the blueprints we implemented in Juno. This was mostly done because it helps me write the release notes, but I am posting it here because I am sure that others will find it handy too.
Ongoing behind the scenes work
- Support sub-classing objects. launchpad specification
- Stop using the scheduler run_instance method. Previously the scheduler would select a host, and then boot the instance. Instead, let the scheduler select hosts, but then return those so the caller boots the instance. This will make it easier to move the scheduler to being a generic service instead of being internal to nova. launchpad specification
- Refactor the nova scheduler into being a library. This will make splitting the scheduler out into its own service later easier. launchpad specification
- Move nova to using the v2 cinder API. launchpad specification
- Move prep_resize to conductor in preparation for splitting out the scheduler. launchpad specification
- Use JSON schema to strongly validate v3 API request bodies. Please note this work will later be released as v2.1 of the Nova API. launchpad specification
- Provide a standard format for the output of the VM diagnostics call. This work will be exposed by a later version of the v2.1 API. launchpad specification
- Move to the OpenStack standard name for the request id header, in a backward compatible manner. launchpad specification
- Implement the v2.1 API on the V3 API code base. This work is not yet complete. launchpad specification
- Refactor the internal nova API to make the nova-network and neutron implementations more consistent. launchpad specification
- Extensible Resource Tracking. The set of resources tracked by nova is hard coded, this change makes that extensible, which will allow plug-ins to track new types of resources for scheduling. launchpad specification
- Allow a host to be evacuated, but with the scheduler selecting destination hosts for the instances moved. launchpad specification
- Add support for host aggregates to scheduler filters. launchpad: disk; instances; and IO ops specification
- i18n Enablement for Nova, turn on the lazy translation support from Oslo i18n and updating Nova to adhere to the restrictions this adds to translatable strings. launchpad specification
- Offload periodic task sql query load to a slave sql server if one is configured. launchpad specification
- Only update the status of a host in the sql database when the status changes, instead of every 60 seconds. launchpad specification
- Include status information in API listings of hypervisor hosts. launchpad specification
- Allow API callers to specify more than one status to filter by when listing services. launchpad specification
- Add quota values to constrain the number and size of server groups a users can create. launchpad specification
Hypervisor driver specific
- Move the vmware driver to using the oslo vmware helper library. launchpad specification
- Add support for network interface hot plugging to vmware. launchpad specification
- Refactor the vmware driver’s spawn functionality to be more maintainable. This work was internal, but is mentioned here because it significantly improves the supportability of the VMWare driver. launchpad specification