Open Stack

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> 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]
> *Sent:* Friday, March 18, 2016 4:59 AM
> *To:* OpenStack Development Mailing List (not for usage questions);
> 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/20160319/668a984a/attachment.html>