Tag: blueprints

Its been one week of specifications for Nova in Kilo. What are we seeing proposed so far? Here’s a summary…

API

• Add instance administrative lock status to the instance detail results: review 127139.
• Add more detailed network information to the metadata server: review 85673.
• Add separated policy rule for each v2.1 api: review 127863.
• Add user limits to the limits API (as well as project limits): review 127094.
• Allow all printable characters in resource names: review 126696.
• Implement instance tagging: review 127281.
• Implement tags for volumes and snapshots with the EC2 API: review 126553 (spec approved).
• Implement the v2.1 API: review 126452 (spec approved).
• Microversion support: review 127127.
• Move policy validation to just the API layer: review 127160.
• Support X509 keypairs: review 105034.

Administrative

• Enable the nova metadata cache to be a shared resource to improve the hit rate: review 126705.

Containers Service

• Initial specification: review 114044.

Hypervisor: FreeBSD

• Implement support for FreeBSD networking in nova-network: review 127827.

Hypervisor: Hyper-V

• Allow volumes to be stored on SMB shares instead of just iSCSI: review 102190.

Hypervisor: VMWare

• 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.

Hypervisor: libvirt

• 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.

Instance features

• Allow direct access to LVM volumes if supported by Cinder: review 127318.

Interal

• Move flavor data out of the system_metdata table in the SQL database: review 126620.

Internationalization

• Enable lazy translations of strings: review 126717.

Scheduler

• 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.

Scheduling

• Add instance count on the hypervisor as a weight: review 127871.

Security

• 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
remember why.

Trivial blueprints
==================

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.

Other proposals
===============

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
from there.

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.