Open Stack

Gal,

Thanks for clarifying the initiative. I added “[Magnum]” to the title so that Magnum team members can cast their inputs to this thread (if any).

Best regards,
Hongbin

From: Gal Sagie [mailto:gal.sagie at gmail.com]
Sent: March-19-16 6:04 AM
To: Fox, Kevin M
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Kuryr] Clarification of expanded mission statement

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.Fox at pnnl.gov<mailto:Kevin.Fox at 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 [rbryant at redhat.com<mailto:rbryant at redhat.com>]
Sent: Friday, March 18, 2016 4:59 AM
To: OpenStack Development Mailing List (not for usage questions); gal.sagie at gmail.com<mailto:gal.sagie at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160327/3622ef58/attachment.html>