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 opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss