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

Thu May 29 14:49:55 UTC 2014

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "Livnat Peer" <lpeer at redhat.com>, board at ovirt.org, devel at ovirt.org
> Sent: Thursday, May 29, 2014 5:32:20 PM
> Subject: Re: [ovirt-devel] 3.5 Time-frame: pushing feature freeze
> 
> 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
> 
> ==================================
> 
> 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
> 
> 

Dan this is why we have the sync meeting, and this is where we discuss these issues
as you know. There's no point of opening this now as the question is how much time
we need to postpone and not if we wish to postpone.

The suggestion is for June 15 and it seems to be acceptable to everyone attended
the meeting yesterday. This mail was to give a headsup for those who did not
attend the meeting and give a chance for folks to ask for additional time if
needed.

Based on yesterday's feedback. we updated the release page to the following schedule:
http://www.ovirt.org/OVirt_3.5_release-management
If check the history you'll see that the GA date is the same.

Doron