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.sa...@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....@pnnl.gov<mailto: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<mailto:rbry...@redhat.com>]
Sent: Friday, March 18, 2016 4:59 AM
To: OpenStack Development Mailing List (not for usage questions); 
gal.sa...@gmail.com<mailto: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

Reply via email to