Open Stack

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 
>>>
>>>
>>
>>
>> __________________________________________________________________________ 
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> OpenStack-dev-request at 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
>