Re: Akraino Charter
|
Srini
Hi Frank,
On this:
“ - Is Akraino look to build the images/containers? Or limit the scope to installers, starting with Airship? If so, which sister project(s) going to build binary images suitable for Airship? Could you maybe elaborate why you feel it matters whether building images is part of the project or not?
“ I see some projects applying patches (patches that are created in upstream) to their current release instead of taking latest release. This requires capability of building binaries & packages.
Even otherwise, there are some upstream projects don’t create binary images or images in a way that is required.
For example, Openstack-kolla and Openstack-helm projects can be considered as sister projects to Airship as Kolla project creates container images for each openstack service and pushes them to dockerhub. Openstak-helm project is the home for helm charts which help in deploying them. I guess Airship installer requires them in containers and helm charts.
Some projects such as libvirtd, ovs, ovs-dpdk, collectd, kubelet, OVN north/south controllers and many more, that are required to be part of the Edge stack, also need to be containerized and have helm charts. Where do we do them? As Akraino or as a sister project?
My thinking is that to make Akraino complete integration project, it would need to have capabilities to build the images.
Thoughts?
What about
From: main@... [mailto:main@...]
On Behalf Of fzdarsky@...
Sent: Friday, September 7, 2018 4:20 AM To: main@... Subject: Re: [akraino] Akraino Charter
On Fri, Sep 7, 2018 at 12:02 AM Srini <srinivasa.r.addepalli@...> wrote:
The current code is only the seed code that AT&T generously donated to kick-start the project. Obviously there are pieces missing and maybe pieces we may not need / want to do differently later. I wouldn't extrapolate from the seed code to the project's mission/focus that the community needs to agree on.
Then, notice the code is integration code. It pulls in pieces from Airship and other upstreams (which themselves are development projects).
Ok, if you're not talking about patches for backporting but to fix/add functionality this would be forking and I hope we'll establish a clear upstream-first policy to prevent forking. Apart from that it would not be good citizenship to not upstream / not give upstream the chance to address gaps first, we'd accumulate technical debt that we don't want. I often hear the argument that these patches are "temporary" to enable us to move fast and that there's the intention to eventually upstream... which from experience hardly ever happens later.
It's a different, of course, if we're talking about plugins like in your Barometer example.
Could you maybe elaborate why you feel it matters whether building images is part of the project or not?
In my view, we should eventually build images to make internal testing and test-driving by users easier. But I'd like to avoid the trap of putting too much emphasis on the images; how they are built, how to harden them, how to tune/optimize them, etc. Just mentioning this, as it's a topic that typically comes up sooner or later (like recently in ONAP). And it's important to understand that users will likely throw away our images and rebuild & re-test anyway.
I'd expect that we'll identify gaps as a result of the integration. If it's a gap in an upstream project, we should absolutely strive to address those gaps there and never carry patches against an upstream project. If it's a functional gap not addressed by our current upstreams, we should try to find projects that do something similar and see whether we can extend those. Developing ourselves should be last resort and then as an independent (sub-)project that will need to prove its value to the larger community over time. Plus it should be possible to swap it out for other solutions if they develop elsewhere.
Whatever code we produce ourselves should of course strive towards production quality. But it's not our task to create patches to fix upstream projects or even do backports to an upstream's stable branch! That's the job of the upstream projects themselves.
And because everyone, both upstreams and us, has finite engineering resources, they have to trade off how much time they spend on backports to older, stable branches vs how much time they invest into new features. Plus how many HW/SW configurations they are able to fully test.
Now consider an edge stack that consists of dozens of components. It's already difficult to find combinations of versions of components that play well together, let alone the complexity of doing backports across all of them.
Next, consider how users would consume Akraino: Would they just download our/upstream images and run them in production? Of course not! They'd have to get commercial support from vendors (unless they have many engineers to burn to go DIY), but vendors will in most cases not support the exact combination as integrated/tested in Akraino, so the effort we put in there has a relatively low ROI...
TBH, this all makes the goal of "production quality" for the whole Akraino stack rather aspirational than realistic...
-- Frank Zdarsky | NFV&SDN Technology Strategy, Office of the CTO | Red Hat
|
|
|