[OpenDaylight TSC] [OpenDaylight Board] Openstack thinking of projects

Mathieu Lemay mlemay at inocybe.com
Wed Jan 7 22:54:32 UTC 2015

Hi Neela, Luis and Colin,

I've been actively against simultaneous release for a while (see the
attached slides I presented at the last design summit).

On that OpenStack assessment I completely agree and we are facing the same
issues in OpenDaylight as of today. As for tagging I started the notion of
a project explorer a while back. It was completely rewritten over the
holidays and we are still actively working on this. There are however
additional issues that come to mind.

The idea of an 'installable' set of features for different use cases is
definitely important but then again what is the granularity.

To quote the link Neela sent:
"Skilled operators aren't deploying "the integrated release": they are
picking and choosing between components they feel are useful. New users,
however, are presented with a complex and scary "integrated release" as the
thing they have to deploy and manage: this inhibits adoption, and this
inhibits the adoption of a slice of OpenStack that could serve their need."

I find the exact same attitude in my recent deployments and have had to
customize integrated builds for use case specific users I was involved with.

Moreover, I would like to add that there is no relationship between a
project and its architectural components/add-ons. As such a project
maturity doesn't equate to a component maturity unless we have a 1:1
mapping.  I was very strongly pushing for a taxonomy for these components
along with potentially different repositories based on the quality /
stability or any other criteria. It would be important for users to know
what repositories they want to enable (stable, experimental or otherwise)

Anyhow, this will have to be investigated and resolved offline within the
community. I however wanted to thank everyone for bringing this up.


On Wed, Jan 7, 2015 at 3:51 PM, Colin Dixon <colin at colindixon.com> wrote:

> I think Luis is right on a bunch of fronts.
> First, I think there are at least 3 axes of maturity/importance:
> 1.) code maturity
> 2.) how close to  the root of the dependency tree it is
> 3.) process wiseness
> I'm not sure that we need to have bins for each of those three axes, but
> understanding that they exist and loosely where projects fall would be
> good. It's worth noting that they can also vary substantially for logical
> subprojects. In those cases, it's probably worth identifying and tracking
> those logical supprojects as independent entities.
> Aside from that I think we need to ask what we want from a simultaneous
> release and whether there are other ways we can get it. Right now I think
> the simultaneous release does 3 key things for us:
> 1.) Helps projects coordinate with each other.
> 2.) Provides a vehicle for users to download and consume ODL.
> 3.) Provides compatible "version bands" across projects so that you can
> run all of them together.
> I think we could manage 1 without a simultaneous release.
> As far as 2 goes, we could do some work to allow for a more "app store"
> like model where it's easy for users to download and install features for
> ODL which would allow for much more minimal release vehicles that had much
> smaller simultaneous releases. This is what Dave Lenrow was arguing for
> during Lithium planning, but I think we need to develop better tooling to
> make it possible.
> It's 3 that gives me the most pause. How do we make sure that users and
> downstream consumers can bundle together a set of versions of each project
> so that they all work. That is to avoid SFC working with version 1 and 3 of
> the MD-SAL while SNMP4SDN only works with version 2 and so you can't run
> both SFC and SNMP4SDN in the same controller.
> --Colin
> On Tue, Jan 6, 2015 at 7:54 PM, Luis Gomez <ecelgp at gmail.com> wrote:
>> Hi Neela and all,
>> I personally think we start to see some of the issues in OpenStack here
>> as well:
>> - Simultaneous Release is considered the only way for a project today
>> - Release deliverable starts to be complex and scary for users (many
>> features of different kinds)
>> - The existing model does not scale for cross-functional tasks like
>> integration, test, documentation and release mgmt
>> To address this we can definitely start looking at:
>> 1) Classifying (tagging) projects in terms of core and maturity. This
>> will help community and users to better understand the OpenDaylight and its
>> components. We already have some classification criteria based on release
>> offset but this only shows core/dependencies but no maturity for instance.
>> 2) Designing the right release processes and deliverables for the
>> different project groups. For example, a core project may have stronger
>> release requirements than a non-core project, or new projects can start in
>> “probe" mode (e.g. in ODL forge) and then later be incorporated in formal
>> ODL once they probe some maturity.
>> 3) Move cross-functional tasks responsibilities to the projects, I am
>> glad we already planned for this in Lithium. During this release projects
>> have a lot more integration, test and documentation deliverables than any
>> other release in the past.
>> I think we should start discussing these and other related items right
>> away and looking at some implementation by next release Beryllium. I am
>> happy Dave Lenrow and Mathieu Lemay already brought the subject in the mail
>> lists and set a TWS call for it. I will be glad to collaborate on this as
>> well.
>> BR/Luis
>> On Dec 18, 2014, at 9:13 AM, Neela Jacques <njacques at opendaylight.org>
>> wrote:
>> TSC, Board,
>> I would like to suggest each of us takes a read through this short post
>> describing some changes that OpenStack is looking to make regarding project
>> structure: http://ttx.re/the-way-forward.html (note this is the summary,
>> the full text is here:
>> http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html)
>>  It is the result of 5 years of experiences and months of thinking in the
>> OpenStack community regarding how to set up projects, simultaneous releases
>> etc. I am not suggesting we take the exact same approach, but I think this
>> is great input for us to use as we continue to think through the right
>> model for OpenDaylight as we continue to experience significant growth in
>> sub-projects etc. The idea of tagging is intriguing to me, we will watch it
>> closely to see how it works in practice.
>> Neela
>> Nicolas (Neela) Jacques | Executive Director | OpenDaylight Project |
>> njacques at opendaylight.org | 650-704-7029
>>  _______________________________________________
>> Board mailing list
>> Board at lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/board
>> _______________________________________________
>> TSC mailing list
>> TSC at lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/tsc
> _______________________________________________
> Board mailing list
> Board at lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/board


*Mathieu Lemay*
*President & CEO*
Inocybe Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/tsc/attachments/20150107/1cebf8d5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ODL Design Summit - Release Plans for Lithium - ML Slides.pdf
Type: application/pdf
Size: 575224 bytes
Desc: not available
URL: <http://lists.opendaylight.org/pipermail/tsc/attachments/20150107/1cebf8d5/attachment-0001.pdf>

More information about the TSC mailing list