Hi Russell, Thanks for starting this thread, i have been wanting to do so myself.
First, to me Kuryr is much more then just providing a "libnetwork driver" or a "CNI driver" in the networking part. Kuryr goal (to me at least) is to simplify orchestration, management and performance and avoid vendor lock-in by providing these drivers but also being able to expose and enhance additional policy level features that OpenStack has but are lacking in COEs, We are also looking at easier deployment and packaging and providing additional value with features that make things more efficient and address issues operators/users are facing (like attaching to existing Neutron networks). We see our selfs operating both on OpenStack projects, helping with features needed for this integration but also in any other project (like Kubernetes / Docker) if this will make more sense and show better value. The plan is to continue this with storage, we will have to examine things and decide where is the best place to locate them the pros and cons. I personally don't want to run and start implementing things at other communities and under other governance model unless they make much more sense and show better value for the overall solution. So my initial reaction is that we can show a lot of value in the storage part as part of OpenStack Kuryr and hence the mission statement change. There are many features that i believe we can work in that are currently lacking and we will need to examine them one by one and keep doing the design and spec process open with the community so everyone can review and judge the value. The last thing i am going to do is drive to re-implement things that are already there and in good enough shape, none of us have the need or time to do that :) In the storage area i see the plugins (and not just for Kubernetes), i see the persistent and re-using of storage parts as being interesting to start with. Another area that i included as storage is mostly disaster recovery and backup, i think we can bring a lot of value to containers deployments by leveraging projects like Smaug and Freezer which offer application backups and recovery. I really prefer we do this thinking process together as a community and i already talked with some people that showed interest in some of these features. My intention was to first get the TC approval to explore this area and make sure it doesnt conflict and only then start working on defining the details again with the broad community, openly just like we do everything else. On Fri, Mar 18, 2016 at 10:12 PM, Fox, Kevin M <kevin....@pnnl.gov> wrote: > I'd assume a volume plugin for cinder support and/or a volume plugin for > manila support? > > Either would be useful. > > Thanks, > Kevin > ------------------------------ > *From:* Russell Bryant [rbry...@redhat.com] > *Sent:* Friday, March 18, 2016 4:59 AM > *To:* OpenStack Development Mailing List (not for usage questions); > gal.sa...@gmail.com > *Subject:* [openstack-dev] [Kuryr] Clarification of expanded mission > statement > > The Kuryr project proposed an update to its mission statement and I agreed > to start a ML thread seeking clarification on the update. > > https://review.openstack.org/#/c/289993 > > The change expands the current networking focus to also include storage > integration. > > I was interested to learn more about what work you expect to be doing. On > the networking side, it's clear to me: a libnetwork plugin, and now perhaps > a CNI plugin. What specific code do you expect to deliver as a part of > your expanded scope? Will that code be in Kuryr, or be in upstream > projects? > > If you don't know yet, that's fine. I was just curious what you had in > mind. We don't really have OpenStack projects that are organizing around > contributing to other upstreams, but I think this case is fine. > > -- > Russell Bryant > -- Best Regards , The G.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev