Open Stack

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