docs/release-process/release-goals.rst

   1 **********************
   2 Fluorine Release Goals
   3 **********************
   4
   5 Purpose
   6 =======
   7
   8 This document outlines OpenDaylight's project-level goals for Fluorine. It is
   9 meant for consumption by fellow LFN projects, the LFN TAC and the LFN Board.
  10
  11 Goals
  12 =====
  13
  14 Infrastructure Efficiency
  15 -------------------------
  16
  17 OpenDaylight has major infrastructure requirements that can't be mitigated due
  18 to the large number of tests the community has developed over time. The
  19 Integration/Test and RelEng/Builder projects have always strove to use
  20 resources efficiently, to make OpenDaylight's increasingly large test suite
  21 fit in the same resource allocation. However, OpenDaylight's recent move to LFN
  22 and the Managed Release model may have unlocked new opportunities to achieve
  23 equally good or better test coverage at a lower cost.
  24
  25 A few ideas are outlined below, although it's expected others will emerge.
  26
  27 Regular Cost Feedback
  28 +++++++++++++++++++++
  29
  30 Getting feedback about the impact of efficiency efforts is critical.
  31 OpenDaylight has requested that LFN start sending out infrastructure spending
  32 reports. These will allow the community to make data-driven decisions about
  33 which changes have substantial impacts and which aren't a good work-vs-reward
  34 trade-off.
  35
  36 Reports should be provided as frequently as possible and should include all
  37 available data, like per-flavor usage, to help target efforts.
  38
  39 Other LFN projects may find it helpful to request similar reports.
  40
  41 OpenStack Deployments via OPNFV Images
  42 ++++++++++++++++++++++++++++++++++++++
  43
  44 OpenDaylight currently spends significant infrastructure and developer
  45 resources maintaining our own Devstack-based OpenStack deployment logic. OPNFV
  46 installer projects already produce VM images with master branch versions of
  47 OpenStack and OpenDaylight installed via production tooling. OpenDaylight would
  48 like to move to doing our OpenStack testing using these images, updating the
  49 version of OpenDaylight to the build under test. Using a pre-baked OpenStack
  50 deployment vs deploying it ourselves in every job would result in substantial
  51 cost savings, and not having to maintain Devstack deployment logic would make
  52 our jobs much more stable and save developer time.
  53
  54 This change wasn't possible in our previous Rackspace-hosted infrastructure,
  55 but we hope it will be enabled by our recent move to Vexxhost or by running
  56 jobs that require OpenStack on LFN-managed hardware.
  57
  58 Audit for Unwatched CSIT
  59 ++++++++++++++++++++++++
  60
  61 As part of OpenDaylight's move to the Managed Release model, the Test team will
  62 have greater freedom to step in and directly manage project's tests. This may
  63 enable the Test team to disable tests that are not actively watched and make
  64 other jobs run less frequently.
  65
  66 Cross-Project CI/CD
  67 -------------------
  68
  69 OpenDaylight pioneered Cross-Project CI/CD (XCI) in LFN with OPNFV shortly
  70 after that project's creation. Since then, both projects and others that have
  71 followed have realized major benefits from continuously integrating recent
  72 pre-release versions. OpenDaylight would like to continue and expand this work
  73 in Fluorine.
  74
  75 OpenDaylight as Infra
  76 ---------------------
  77
  78 OpenDaylight's cloud infrastructure runs on OpenStack. We would like to start
  79 using a released version of OpenDaylight NetVirt as the Neutron backend in
  80 this infrastructure. This "eating our own dogfood" exercise would make for a
  81 good production-level test and good marketing.
  82
  83 This change wasn't possible in our previous Rackspace-hosted infrastructure,
  84 but we hope it will be enabled by our recent move to Vexxhost or by running
  85 jobs that require OpenStack on LFN-managed hardware.
  86
  87 Expand Contribution Base
  88 ------------------------
  89
  90 OpenDaylight would like to continue bringing new contributors to the community.
  91
  92 For Fluorine, OpenDaylight would like to focus on getting downstream consumers
  93 involved in upstream development. In an ideal Open Source world, the users of
  94 an Open Source projects would contribute back to the projects they consume.
  95 OpenDaylight would like to facilitate this by building special relationships
  96 between key downstream consumers and the upstream developer community. These
  97 downstreams could be companies, universities or Open Source projects. We hope
  98 for contributions in the form of code, documentation and bug reports.
  99
 100 OpenDaylight would like to work with the LFN MAC and TAC to identify a small
 101 set of downstream users to pilot the program with. The users would provide
 102 developers with dedicated cycles and a commitment to stick around for the
 103 long-term. In exchange, the OpenDaylight developer community would prioritize
 104 training these developers, answering their questions and generally facilitate
 105 their bootstrapping into the upstream community.
 106
 107 Support Kernel Projects
 108 -----------------------
 109
 110 Companies allocating contributors to OpenDaylight tend to distribute resources
 111 to projects that are directly related to the usecases they are interested in,
 112 but neglect to give sufficient resources to the kernel projects that support
 113 them. OpenDaylight's kernel developers are doing a heroic job of keeping the
 114 platform healthy, but for the long-term health of the project special attention
 115 needs to be paid to sufficiently staffing these key projects.
 116
 117 OpenDaylight requests that LFN member companies that consume OpenDaylight
 118 consider contributing developer resources to kernel projects. The new
 119 developers should be allocated for the long-term, to avoid costing cycles
 120 for training that aren't repaid by contributions.
 121
 122 Improve First-Impression Documentation
 123 --------------------------------------
 124
 125 OpenDaylight has a tremendous amount of documentation, but much of it is
 126 written by experienced developers for experienced developers. As with most
 127 Open Source projects, the experienced developers typically don't look at
 128 documentation targeted at inexperienced potential contributors. This type of
 129 general documentation is also typically not maintained by individual projects,
 130 who are focused on making sure their project-specific docs are in good shape.
 131
 132 To facilitate expanding OpenDaylight's user and contributor base, we would like
 133 to focus on improving this "first impression" documentation for Fluorine. Since
 134 it's not realistic to hope for a major improvement from the existing
 135 contributor base, OpenDaylight requests the LFN Board create a LF staff
 136 position focused on auditing and working with LFN project communities to
 137 improve this general, "first impression" documentation. This resource would be
 138 shared across all LFN projects.
 139
 140 Improve Release Model
 141 ---------------------
 142
 143 The OpenDaylight community has developed a new release model for Fluorine. The
 144 Managed Release Model will facilitate timely releases, provide a more stable
 145 development environment for the most active OpenDaylight projects, reduce
 146 process overhead for all projects, give more autonomy to Unmanged Projects and
 147 allow the Release and Test teams to give more support to Managed Projects.
 148
 149 See the `Managed Release Process`_ for additional details.
 150
 151 Resync Release Cadence
 152 ----------------------
 153
 154 OpenDaylight's release dates need to synchronize with a number of related Open
 155 Source projects. The OpenDaylight TSC will work with those projects, perhaps
 156 making use of the LFN TAC, to understand the best time for our releases. The
 157 TSC will adjust OpenDaylight's release schedule accordingly and ensure it's
 158 met. We anticipate that the new Managed Release Process will make it easier for
 159 OpenDaylight to consistently meet release date targets going forward.
 160
 161 In-Person Developer Design Forum Per-Release
 162 --------------------------------------------
 163
 164 OpenDaylight would like to continue having a face-to-face Developer Design
 165 Forum to plan each release. The community has expressed many times that these
 166 events are extremely valuable, that they need to continue happening and that
 167 they can't be replaced by remote DDFs.
 168
 169 OpenDaylight requests that the LFN Board allocate resources for at least one,
 170 ideally two, days of DDF for each OpenDaylight six-month release cycle. It has
 171 worked well to host these events in conjunction with other large, relevant
 172 events like ONS.
 173
 174 .. _Managed Release Process: https://git.opendaylight.org/gerrit/68382/