<div dir="ltr">Hi Russell,<div><br></div><div>Thanks for starting this thread, i have been wanting to do so myself.</div><div><br></div><div>First, to me Kuryr is much more then just providing a "libnetwork driver" or a "CNI driver"</div><div>in the networking part.</div><div><br></div><div>Kuryr goal (to me at least) is to simplify orchestration, management and performance</div><div>and avoid vendor lock-in by providing these drivers but also being able to expose and enhance additional</div><div>policy level features that OpenStack has but are lacking in COEs, We are also looking at easier</div><div>deployment and packaging and providing additional value with features that make things more efficient and address issues</div><div>operators/users are facing (like attaching to existing Neutron networks).</div><div><br></div><div>We see our selfs operating both on OpenStack projects, helping with features needed for this integration but</div><div>also in any other project (like Kubernetes / Docker) if this will make more sense and show better value.</div><div><br></div><div>The plan is to continue this with storage, we will have to examine things and decide where is the best</div><div>place to locate them the pros and cons.</div><div>I personally don't want to run and start implementing things at other communities and under other</div><div>governance model unless they make much more sense and show better value for the overall solution.</div><div>So my initial reaction is that we can show a lot of value in the storage part as part of OpenStack Kuryr and hence</div><div>the mission statement change.</div><div><br></div><div>There are many features that i believe we can work in that are currently lacking and we will</div><div>need to examine them one by one and keep doing the design and spec process open with the community</div><div>so everyone can review and judge the value.</div><div>The last thing i am going to do is drive to re-implement things that are already there and in good enough shape,</div><div>none of us have the need or time to do that :)</div><div><br></div><div>In the storage area i see the plugins (and not just for Kubernetes), i see the persistent and re-using of storage</div><div>parts as being interesting to start with.</div><div>Another area that i included as storage is mostly disaster recovery and backup, i think we can bring a lot of value</div><div>to containers deployments by leveraging projects like Smaug and Freezer which offer application backups</div><div>and recovery.</div><div>I really prefer we do this thinking process together as a community and i already talked with some people that showed</div><div>interest in some of these features.</div><div><br></div><div>My intention was to first get the TC approval to explore this area and make sure it doesnt conflict and</div><div>only then start working on defining the details again with the broad community, openly just like we do</div><div>everything else.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 10:12 PM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">I'd assume a volume plugin for cinder support and/or a volume plugin for manila support?<br>
<br>
Either would be useful.<br>
<br>
Thanks,<br>
Kevin<br>
<div style="font-family:Times New Roman;color:#000000;font-size:16px">
<hr>
<div style="direction:ltr"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Russell Bryant [<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>]<br>
<b>Sent:</b> Friday, March 18, 2016 4:59 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions); <a href="mailto:gal.sagie@gmail.com" target="_blank">gal.sagie@gmail.com</a><br>
<b>Subject:</b> [openstack-dev] [Kuryr] Clarification of expanded mission statement<br>
</font><br>
</div><div><div class="h5">
<div></div>
<div>
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The Kuryr project proposed an update to its mission statement and I agreed to start a ML thread seeking clarification on the update.</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif"><a href="https://review.openstack.org/#/c/289993" target="_blank">https://review.openstack.org/#/c/289993</a></font><br>
</div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif">The change expands the current networking focus to also include storage integration.</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif">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?</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica, sans-serif">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.</font></div>
<div><br>
</div>
-- <br>
<div>
<div dir="ltr">
<div><font face="arial black, sans-serif">Russell Bryant</font></div>
</div>
</div>
</div>
</div>
</div></div></div>
</div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Best Regards ,<br><br>The G. </div>
</div>