<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div class="gmail_quote"><div dir="ltr">On Fri, Sep 7, 2018 at 9:21 PM Matt Riedemann <<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/6/2018 1:49 PM, Rico Lin wrote:<br>
> * Cross-community integrations (K8s, CloudFoundry, Ceph, OPNFV)<br>
<br>
Are there some specific initiatives or deliverables you have in mind <br>
here, or just general open communication channels? It's very hard to <br>
gauge any kind of progress/success on the latter.<br></blockquote><div><br></div><div>I'm refering on clear communication channels and go from Use cases to real development tasks (As I try to explain in the last section of my candidacy).</div><div>And here's some specific initiatives or deliverables sample I got in mind.</div><div>* From StarlingX, some great improvement for Edge cases are delivered to projects. And there're also communications cross StarlingX and TCs on how to make it integrated with rest OpenStack projects (currently StarlingX still using it's own forks of OpenStack projects). And there're other projects that other organizations contribute to OpenStack or form another communities that depend on OpenStack.</div><div>* We recently create a new repo `openstack-service-broker` [1]. Use Service Broker (A project from CloudFoundry) expose external resources to applications running in a PaaS. Which is exactly a integration cross CloudFoundry and OpenStack (protentially with K8s too) base on specific scenario.</div><div>* K8s as one of the most popular case here, I believe we already can see some nice integration cross OpenStack and K8s. Include Manila, Keystone support in K8s, Magnum become one of official deployment tool in K8s community. Also I'm currently working on Integrate Heat AutoScaling to K8s cluster autoscaler as well [2].</div><div>* OPNFV integrated with OpenStack as it's cluster provider.</div><div><br></div><div>So the goal here IMO is `how can we properly set up cross communication and improve scenarios with use cases or help these scenarios to become deliverable for user?`.</div><div>SIGs are one of the format that I believe can help to accelerate this goal. As I mentioned in [3] and in goal `Strong the structure of SIGs`. We should consider to allow SIGs to become that platform from use cases and scenario to a trackable development tasks. I know there's nothing block a SIG to do so, but there's also no guideline, structure format, or other resources to make the path easier for SIG.</div><div><br></div><div>Hope these explains wht the goal is in my mind.</div><div><br></div><div>[1] <a href="https://github.com/openstack/openstack-service-broker">https://github.com/openstack/openstack-service-broker</a></div><div>[2] <a href="https://github.com/kubernetes/autoscaler/pull/1226">https://github.com/kubernetes/autoscaler/pull/1226</a></div><div>[3] <a href="http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000453.html">http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000453.html</a></div><div><br></div></div><div dir="ltr" class="gmail-m_-3814627374734035157gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font size="2" face="tahoma, sans-serif" color="#999999"></font></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>