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

Doron Fediuck dfediuck at redhat.com
Thu May 29 15:00:09 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:58:01 PM
> Subject: Re: [ovirt-devel] 3.5 Time-frame: pushing feature freeze
> 
> On Thu, May 29, 2014 at 10:49:55AM -0400, Doron Fediuck wrote:
> > 
> > 
> > ----- 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.
> 
> Ok. We postpone. But do we shed any feature? What should we focus on?
> I'm not into blaming the late features and their owner - I just want to
> know what are the real blockers.
> 
> 

We have a plan for 3.5, and anything in the plan which makes it to June 15
can be included. You have a valid point on blocking features and I'll
open another thread asking folks to add it to the 3.5 tracker-
http://bugzilla.redhat.com/1073943



More information about the Devel mailing list