Thank you Matt.
We'll think how we can help here.
Best regards,
Alex Levine
On 5/10/16 7:40 PM, Matt Riedemann wrote:
On 5/10/2016 11:24 AM, Alexandre Levine wrote:
Hi Matt,
Sorry I couldn't reply earlier - was away.
I'm worrying about ScaleIO ephemeral storage backend
(https://blueprints.launchpad.net/nova/+spec/scaleio-ephemeral-storage-backend)
which is not in this list but various clients are very interested in
having it working along with or instead of Ceph. Especially I'm worrying
in view of the global libvirt storage pools refactoring which looks like
a quite global effort to me judging by a number of preliminary reviews.
It seems to me that we wouldn't be able to squeeze ScaleIO additions
after this refactoring.
What can be done about it?
We could've contribute our initial changes to current code (which would
potentially allow easy backporting to previous versions as a benefit
afterwards) and promise to update our parts along with the refactoring
reviews or something like this.
Best regards,
Alex Levine
On 5/6/16 3:34 AM, Matt Riedemann wrote:
There are still a few design summit sessions from the summit that I'll
recap but I wanted to get the priorities session recap out as early as
possible. We held that session in the last slot on Thursday. The full
etherpad is here [1].
The first part of the session was mostly going over schedule
milestones.
We already started Newton with a freeze on spec approvals for new
things since we already have a sizable backlog [2]. Now that we're
past the summit we can approve specs for new things again.
The full Newton release schedule for Nova is in this wiki [3].
These are the major dates from here on out:
* June 2: newton-1, non-priority spec approval freeze
* June 30: non-priority feature freeze
* July 15: newton-2
* July 19-21: Nova Midcycle
* Aug 4: priority spec approval freeze
* Sept 2: newton-3, final python-novaclient release, FeatureFreeze,
Soft StringFreeze
* Sept 16: RC1 and Hard StringFreeze
* Oct 7, 2016: Newton Release
The important thing for most people right now is we have exactly four
weeks until the non-priority spec approval freeze. We then have about
one month after that to land all non-priority blueprints.
Keep in mind that we've already got 52 approved blueprints and most of
those were re-approved from Mitaka, so have been approved for several
weeks already.
The non-priority blueprint cycle is intentionally restricted in Newton
because of all of the backlog work we've had spilling over into this
release. We really need to focus on getting as much of that done as
possible before taking on more new work.
For the rest of the priorities session we talked about what our actual
review priorities are for Newton. The list with details and owners is
already available here [4].
In no particular order, these are the review priorities:
* Cells v2
* Scheduler
* API Improvements
* os-vif integration
* libvirt storage pools (for live migration)
* Get Me a Network
* Glance v2 Integration
We *should* be able to knock out glance v2, get-me-a-network and
os-vif relatively soon (I'm thinking sometime in June).
Not listed in [4] but something we talked about was volume
multi-attach with Cinder. We said this was going to be a 'stretch
goal' contingent on making decent progress on that item by
non-priority feature freeze *and* we get the above three smaller
priority items completed.
Another thing we talked about but isn't going to be a priority is
NFV-related work. We talked about cleaning up technical debt and
additional testing for NFV but had no one in the session signed up to
own that work or with concrete proposals on how to make improvements
in that area. Since we can't assign review priorities to something
that nebulous it was left out. Having said that, Moshe Levi has
volunteered to restart and lead the SR-IOV/PCI bi-weekly meeting [5]
(thanks again, Moshe!). So if you (or your employer, or your vendor)
are interested in working on NFV in Nova please attend that meeting
and get involved in helping out that subteam.
[1] https://etherpad.openstack.org/p/newton-nova-summit-priorities
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090370.html
[3] https://wiki.openstack.org/wiki/Nova/Newton_Release_Schedule
[4]
https://specs.openstack.org/openstack/nova-specs/priorities/newton-priorities.html
[5]
http://lists.openstack.org/pipermail/openstack-dev/2016-April/093541.html
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Alexandre,
A closed-source vendor-specific ephemeral backend for a single virt
driver in Nova isn't a review priority for the release. The review
priorities we have for Newton are really broad multi-release efforts
that we need to focus on.
This doesn't mean we aren't approving other specs/blueprints. We
already have 53 approved blueprints for Newton and only 6 of those are
implemented, plus a healthy backlog of other open specs to review. We
always over-commit on approved blueprints and then things slip for
whatever reason and have to be deferred to another release. This
shouldn't be a surprise to anyone that's been around for awhile.
The ScaleIO image backend for libvirt is going to be dependent on the
refactor series in that code that Matthew Booth is working on [1]. We
need to cleanup that code for future work, like libvirt storage pool
support and for adding new image backends, like ScaleIO. To move that
along faster, you can help review the spec and code changes and/or
help out the subteam working on it to fill gaps in testing - we
identified some gaps in test coverage in the live migration meeting
this morning [2] so we need people helping out with those in parallel
to the refactor.
[1] https://review.openstack.org/#/c/302117/
[2]
http://eavesdrop.openstack.org/meetings/nova_live_migration/2016/nova_live_migration.2016-05-10-14.00.log.html
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
