[ovirt-devel] 3.5 Time-frame: pushing feature freeze

Sandro Bonazzola sbonazzo at redhat.com
Thu May 29 14:52:10 UTC 2014


Il 29/05/2014 16:32, Dan Kenigsberg ha scritto:
> On Thu, May 29, 2014 at 09:10:59AM -0400, Doron Fediuck wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Livnat Peer" <lpeer at redhat.com>
>>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>> Cc: board at ovirt.org, devel at ovirt.org
>>> Sent: Thursday, May 29, 2014 4:05:45 PM
>>> Subject: Re: 3.5 Time-frame: pushing feature freeze
>>>
>>> On 05/29/2014 03:44 PM, Doron Fediuck wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>, board at ovirt.org,
>>>>> devel at ovirt.org
>>>>> Sent: Thursday, May 29, 2014 3:21:26 PM
>>>>> Subject: Re: 3.5 Time-frame: pushing feature freeze
>>>>>
>>>>> On 05/28/2014 06:01 PM, Doron Fediuck wrote:
>>>>>> Hi,
>>>>>> The current date for feature freeze is May 30.
>>>>>> Based on today's weekly sync[1], it seems that most teams require
>>>>>> additional 2 weeks to conclude current work.
>>>>>>
>>>>>> Therefore I suggest to set an updated FF milestone for June 15.
>>>>>>
>>>>>> If you need more time or think we should not change the current
>>>>>> date please respond.
>>>>>>
>>>>>
>>>>> I think we should prioritize schedule over capacity.
>>>>> Features which do not make it to FF can wait for the next release.
>>>>>
>>>>> I think that we should be more careful in the planning phase because it
>>>>> seems to be a recurring phenomena where people commit for features they
>>>>> know won't make it to FF - still these features get approved for the
>>>>> release.
>>>>>
>>>>> I suggest to adopt a spec review phase, which would become part of the
>>>>> planning phase, Here is the process (which is similar to some of the
>>>>> openstack projects' process):
>>>>>
>>>>> 1. For each feature the owner would have to submit a spec file which
>>>>> includes a description and details of the feature (like what feature
>>>>> pages should include today - and mostly do not!).
>>>>>
>>>>> An example would be -
>>>>> https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z
>>>>>
>>>>> 2. The specs are getting reviews and hopefully approved after they meet
>>>>> some standards and make sense to add to oVirt.
>>>>>
>>>>> 3. Once a spec is approved it can be a candidate to include in the
>>>>> release ( at this point the owner should have a good estimation on how
>>>>> long it is going to take him to implement the proposed spec)
>>>>>
>>>>> 4. The release manager of the version should approve the spec for the
>>>>> version according to the well known deadlines.
>>>>>
>>>>>
>>>>> Livnat
>>>>>
>>>>>> Thanks,
>>>>>> Doron
>>>>>>
>>>>>> [1] http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-28-14.01.txt
>>>>
>>>> Livnat,
>>>> it seems that most other teams need the extra time based on yesterday's
>>>> weekly sync, which included a network representative as well.
>>>> So regardless of networking  the rest of the version is not ready to
>>>> freeze hence this is needed.
>>>>
>>>
>>> This is not about a specific team status, this is more about our general
>>> approach to deadlines which should be less flexible.
>>>
>>
>> And I agreed we will not be flexible for next version, but currently
>> most teams are not ready yet. This is the feedback we got in the sync
>> meeting and it cannot be ignored.
> 
> I don't think anybody suggests to ignore the feedback. As always, the
> question is: is the release time-based, or feature based?
> 
> It is not clear to me which are the features that block the release.
> They should be named and prioritized. Otherwise, we'd slip dates
> forever.
> 
> The number of non-green features in the spreadsheet
> http://bit.ly/17qBn6F does not match the numbers cited during the sync
> meeting, so I am confused.
> 
> On Vdsm side I find 5 features with code in advanced stages. jsonrpc and import
> data domain should probably block the release. I am not sure about the rest.
> 
> infra   1079821 [RFE] Prevent host fencing while kdumping       Code will be in by end of May
> infra   1081049 [RFE] replace XML-RPC communication (engine-vdsm) with json-rpc based on bidirectional transport     End of May
> infra   1083645 [RFE][scale]: Replace the use of oop with ioprocess     Code will be in by Mid June
> virt    1082479 disable spice file transfer & copy and paste    packaging on F19&F20 issues
> storage 1083307 import existing data domain     coding

Please add them to the 3.5 tracker bug (http://bugzilla.redhat.com/1073943)


> 
> ==================================
> 
> Can we agree on a definite list of feature that must block 3.5?
> 
> gluster 1040795 Gluster Volume Capacity monitoring      In Progress
> gluster 1083583 Gluster Profile In Progress
> 
> infra   1063095 [RFE][AAA] engine should have a generic LDAP provider   Most code already in. Finalization and fixes by mid June
> infra   1090517 [RFE][AAA] Support anonymous bind for authn/authz       Most code already in. Finalization and fixes by mid June
> infra   1090515 [RFE][AAA] Support for "hardened" AD environments with oVirt    Most code already in. Finalization and fixes by mid June
> infra   1083993 [RFE] using foreman provider to provision bare-metal hosts      Code will be in by end of May
> 
> infra-cli       855724   [RFE] ovirt-engine-restapi : Statistic values representation issues    In Progress
> infra-sdk       1069204 [RFE] Don't require live engine to generate SDK code    In Progress
> integration     1080402 Allow setup of iSCSI based storage for hosted engine    In Validation
> integration-dwh 1080997 DWH running on separate host    In Progress
> integration-reports     1080998 reports running on separate host        In Progress
> integration     1080992 websocket proxy running on separate host        In Validation
> 
> storage 1083310 live merge (delete snapshot)    coding
> storage 1058160 VM Async Tasks via HSM  coding
> storage 1055640 Get rid of storage pool metadata on master storage domain       code review (90% complete)
> storage 1086178 SANlock fencing design
> 
> virt    1083059 "Instance types (new template handling) - adding flavours"       few things needs to be finished(perms,defaults,REST)
> virt    virtio-rng support      on review
> virt    -       finish remaining PPC support (block/allow specific features)    on review
> 
> node    875088   ovirt-node-registration - a generic node registration  ETA end of May (in review)
> node    1038616 ovirt node support for hosted engine nodes      ETA end of May (in review)
> node    1053435 oVirt virtual appliance In progress
> 
> sla     1036731 hosted engine on iscsi  In progress- should be ready by Mid June
> sla     1084930 CPU SLA for capping     In progress- should be ready by Mid June
> sla     1085049 I/O SLA for capping (blkio)     In progress- should be ready by Mid June
> sla     1093051 Integrating with Opta Planner to demonstrate a balanced cluster In progress- should be ready by Mid June
> sla     1069303 NUMA support in oVirt   In Progress- missing UI and REST.
> sla     1062435 Implement REST API for oVirt scheduler  In progress- should be ready by 1st week of June
> sla     1093038 Resource considerations for Migration in RHEV - memory  Won't make it.
> sla     1093102 Reducing HA down-time   In progress- should be ready by Mid June
> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com



More information about the Devel mailing list