#opendaylight-meeting: tws

Meeting started by colindixon at 18:02:56 UTC (full logs).

Meeting summary

  1. agenda bashing (colindixon, 18:03:01)
    1. https://wiki.opendaylight.org/index.php?title=Tech_Work_Stream:Main&oldid=40524#Upcoming_Meeting_Agendas the agenda for today (colindixon, 18:04:31)
    2. today we'll cover boron planning (colindixon, 18:06:02)
    3. two topics: (i) fast-phased approach for shorter releases and (ii) advisory group input on boron (colindixon, 18:06:25)

  2. advisory group input for Boron (colindixon, 18:07:09)
    1. https://lists.opendaylight.org/pipermail/tsc/2016-January/004565.html (colindixon, 18:07:36)
    2. colindixon notes that there are (in his mind) 3 bins of asks: (1) is new features at the ~project-level, (2) another is ODL-wide issues, (3) is sort of meta-issues around network architectures etc. (colindixon, 18:15:27)
    3. examples of (1) are things like BGP add-path and/or aggregated logs/alrsm (colindixon, 18:15:54)
    4. examples of (2) are things like [easier] upgrades between releases (colindixon, 18:17:50)
    5. (3) is stuff like better defining the role of ODL as VNF manager vs. controller vs. NFV orchestrator (colindixon, 18:22:02)

  3. easier upgrades (colindixon, 18:22:11)
    1. easier upgrades were something that was the top prioirty coming out of the advisory group (colindixon, 18:22:52)
    2. specifically, not for third-party apps, but for the components released as part of a major ODL releases it should be easier for users to upgrade than what they're currently doing which is starting from scratch every new release (colindixon, 18:26:48)
    3. edwarnicke says that he thinks upgrades are complicated and it's going to take us a few tries to get it right, thus having a shorter release cycle is likely to give us more tries to get it right in the same period of time (colindixon, 18:28:07)
    4. https://docs.google.com/presentation/d/1IKI8DV3oqb1snJLCaK6lLvvCXCnpEolQ6Xp_Qlk6E8M/edit (edwarnicke, 18:29:09)
    5. colindixon and rovarga agree with this within caveats of how fast you can actually go, how much you can actually do in a given time window, etc. (colindixon, 18:29:55)
    6. skitt and vishnoianil comment that if it's true that most users are only upgrading every year (or every other release) that releasing faster might not help (colindixon, 18:31:10)
    7. they say this is true both because faster releases won't help them, but also because debugging upgrades requires input from users who would also need to test upgrades faster, which they might or might not (colindixon, 18:32:26)
    8. uri worries faster releases will potentially signal instability (colindixon, 18:35:20)
    9. edwarnicke presents his fast-phased approch with the diagram about the different branches (see slide 2 of the linked google doc above) (colindixon, 18:35:53)
    10. colindixon says other than the raw overhead (which skitt and rovarga pointed out), there is the issue of how many differnet branches a project will have to simultaneously maintain (colindixon, 18:36:56)
    11. edwarnicke says it's all trade-offs, colindixon agrees (colindixon, 18:37:07)
    12. edwarnicke points out the primary advantage of this approach is that everyone is building against (likely stable) release artifacts so that people aren't running into SNAPSHOT-integrated transient breakages, but also don't have to wait for 6 months for new released artifacts (colindixon, 18:38:40)
    13. skitt says in the end you'll see a piepline that is 6 months long, but emits a release every 2 months (colindixon, 18:39:00)
    14. edwarnicke, vishnoianil, skitt, etc. talk about the merits of faster releases, edwarnicke says that he finds that testing and other things are easier when you do less long releases more often (colindixon, 18:43:43)
    15. edwarnicke says there's only so much trouble developers can get in in 2 months (colindixon, 18:44:06)
    16. vishnoianil says this would need to support projects that wouldn't have any changes in a 2 month period, that should be faciliated (colindixon, 18:44:38)

  4. planning how fast-phased would work (colindixon, 18:47:31)
    1. colindixon says one good part of this is that it starts offf with kernel having a 2 month release, protocols have a 4 month release, and apps have a 6 month release, which is a reasonable way to get our feet wet without risking everything (colindixon, 18:49:43)
    2. colindixon ask kernel project devs how crazy this looks to them (colindixon, 18:49:54)
    3. edwarnicke points out that one advantage would be that we could maybe eliminate milestones other than cutting RCs some distance before release, e.g., we no longer need API freeze since that's really for downstream projects (colindixon, 18:51:17)
    4. rovarga says that he doesn't see the milestones as mosty for downstream projects, they're also for internal project discipline (colindixon, 18:52:32)
    5. rovarga also says that this needs to be fleshed out a lot more before we can commit to it (colindixon, 18:52:49)
    6. zxiiro asks how many branches everyone will need, edwarnicke, he, and colindixon agree there will be three branches per project (between stable and integration branches), that's in addition to branches for older supported releases (colindixon, 18:54:35)
    7. rovarga says we'd need to see this diagram for two full cycles (~12 months) before we'd understand what's going on (colindixon, 18:56:49)
    8. skitt, rovarga and others argue that we should abandon text-named versions, e.g., -Lithium or -Lithium-SR1, etc. (colindixon, 18:57:27)
    9. skitt aks if we would consider shipping every 2 months for ourselves, but only some of those are targeted for "customers" (colindixon, 18:59:19)
    10. colindixon says he had thought about that too, which is that we might make only some releases public, e.g., 2 per year (colindixon, 18:59:52)
    11. LuisGomez had brought this idea up earlier, which is how many versions do we support in the past, are we supporting releases for a year or for N releases, if it's just 2 releases does this mean we only support things for 2 months? (colindixon, 19:01:29)
    12. abhijitkumbhare asks how OpenStack does this, vishnoianil and colindixon say they have shorter project dependency chains and their APIs are more stable/ossified so they have fewer issues with integration (colindixon, 19:02:13)
    13. abhijitkumbhare also asks how we fail out if this if it turns out to have been a bad idea (colindixon, 19:02:31)
    14. vishnoianil points out deprecation and removal will be faster if we keep it the same which could be worse for users since they'd have to worry about changes every 4 months instead of every 6-12 in the past (colindixon, 19:03:23)
    15. edwarnicke says that we can lead by example by showing how to use integration branches (colindixon, 19:04:25)
    16. colindixon says that's part of it, wall-clock times being shortened down by a factor of 3 still matters (colindixon, 19:04:51)

  5. next steps (colindixon, 19:06:26)
    1. colindixon will start a thread on the mailing list (colindixon, 19:06:38)
    2. we could delay boron start to get it right and start it this way (colindixon, 19:06:49)
    3. we could try to do a shadow version of this alongside a more "normal" boron release (colindixon, 19:07:15)
    4. edwarnicke proposes other ideas which is that we could have just kernel projects try to opt in for boron and what that mgiht mean (colindixon, 19:09:23)


Meeting ended at 19:09:26 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. colindixon (52)
  2. odl_meetbot (4)
  3. rovarga (2)
  4. abhijitkumbhare (2)
  5. edwarnicke (1)


Generated by MeetBot 0.1.4.