On the Polestar call today I floated the idea, which was well received (there
were four of us on the call), that going forward we expand the audience for the
strategy discussions that the Polestar group was supposed to be driving, by
moving the detailed strategy discussions (at least) to the weekly technical
community call that Bin is leading. That way, Polestar can focus on helping set
the agenda for future discussions, but doesn't have to get into the weeds on
strategy aspects, and we can benefit from the wider community input on them.
With the ~50% of free time in the tech community calls (when new projects etc
are not being discussed), there should be plenty of time for a general strategy
discussion on key topics for OPNFV, over at least two calls per month.
Examples of what I would like to have discussion on in the tech community calls
are:
1) The "resiliency at scale" pain point that the EUAG has listed. On an earlier
Polestar call I proposed to break that down at the first step into resiliency
of:
- the NFVI, for
- discrete deployments that are very large (1000+ nodes) and very small
(<10 nodes)
- globally-managed clusters of deployment sites that number very many
(10000+) or very few (minimum 2)
- applications/VNFs
- composed of very many discrete VDUs
- composed of very few VDUs
These distinct aspects of this problem likely are driven by distinct goals and
technologies, which we can take on as discussion topics. For example, IMO
resiliency of the NFVI and support for small site deployments will both depend
upon a more cloud-native and optimized approach to deploying OpenStack and
other NFVI services, including containerizing the services and carefully
selecting which services are installed on the local site, vs other sites with a
broader view/role for managing multiple local sites with services such as
telemetry, fault management, orchestration, scaling, and VNF lifecycle
management in general. We should be identifying and focusing support on
projects that are driving these principles.
2) Shift of OPNFV focus from 6-month releases to a more devops model that
builds/deploys/tests OPNFV platforms on the master branch of OpenStack, and as
needed stable branches of SDNCs (if we can't build on the master branch). This
will have a variety of advantages for the project:
- Feature projects will no longer lose ~2/3 of the release cycle, as they can
start new feature development *immediately* at the start of the cycle, and
continue until much later in the cycle before a stable release branch is cut.
- This is enabled because the installer projects no longer will require 2
months (best case) to rebase on the new stable release of OpenStack. In
examples such as Danube, it was even worse due to the holidays and other
situations e.g. lab moves.
- This will also help us put more emphasis on build stability and testing, as
even though some build/feature failures may be expected as master changes
impact builds and tests, we will better emphasize detecting and resolving
issues faster, and will surely have enough successful builds per week to use as
a basis for testing.
- Without this agility-enabling approach, OPNFV may risk over time becoming
just a place where installer distros are packaged with other components into
reference platforms, but feature development is de-emphasized as there is
simply not enough stable platform time for it in the release cycle.
Thanks,
Bryan Sullivan | AT&T
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
