Open Stack

Hi Alex:

We still hope to land this patch series during this cycle. If you're
referring to the -2 on the patch you mentioned [1], it was just a
procedural -2 until we stopped using the old methods in the driver and
cutover completely to the new methods. I'll ping Dan Smith on IRC
later today, and see if he's ready to revisit his -2.

The cutover to the new methods is in this patch [2], and then there is
a big delete of all the old methods and tests in this patch [3].
Yesterday, the entire patch series was green as far as CI was
concerned, including the experimental job Matt Riedemann kindly added
for LVM (thanks!!!). There are now a few merge conflicts, but it's
still otherwise ready for review.

Feodor has been an excellent reviewer, and it would be great to
continue to get his feedback on this patch series. We hope to be able
to reciprocate when the ScaleIO patches are up for review since we'll
be familiar with that area of the code. The entire patch series can be
found here [4] if anyone else is interested in jumping in on reviews
too.

Thanks folks!

--diana

[1] https://review.openstack.org/#/c/317689/
[2] https://review.openstack.org/#/c/282580/
[3] https://review.openstack.org/#/c/322974/
[4] https://review.openstack.org/#/q/openstack/nova+topic:libvirt-instance-storage

On Wed, Jun 8, 2016 at 1:05 PM, Alexandre Levine
<alexandrelevine at gmail.com> wrote:
> Hi Matt,
>
> According to the state of this review:
> https://review.openstack.org/#/c/317689/ the works aren't going to be done
> in this cycle.
>
> Do you think it'd be possible for our driver to cut in now?
>
> Feodor participated in reviewing and helped as much as possible with current
> efforts and if needed we can spare even more resources to help with the
> refactoring in the next cycle.
>
> 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
>>
>> 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