<div dir="ltr"><div><div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:13px">Hi,</span><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
I'm Masakazu Shinohara of Cyberagent corporation in Japan.</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">I am a representative of our new cloud network project.</div>
<div style="font-family:arial,sans-serif;font-size:13px">We have a lot of services such as on line games blogs or all kind of web services.<br></div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
Now we have been testing Openstack and Cisco ACI.</div><div style="font-family:arial,sans-serif;font-size:13px">It is a really important thing that they can work correctly.</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">We have been observing, learning and following very closely the work going on for Group Based Policy. Our production deployment relies on using it in Juno. We strongly want to see it complete as proposed in Neutron.<br>
</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px"><div dir="ltr"><div>Best regards</div><div><br></div><div>--------------------------------------------------------------</div>
<div>Masakazu Shinohara</div><div>CyberAgent,Inc</div><div>Ameba division Ameba Infra. Unit</div><div>Architect group</div><div>Zip code 150-0045</div><div>Shibuya First Place Bldg, 8-16 Shinsen-cho </div><div>Shibuya-ku Tokyo</div>
<div>Mobile <a href="tel:%2B81%2080-6863-2356" value="+818068632356" target="_blank">+81 80-6863-2356</a></div><div>Extension 62478</div><div><a href="mailto:shinohara_masakazu@cyberagent.co.jp" target="_blank">shinohara_masakazu@cyberagent.co.jp</a></div>
</div></div><span style="font-family:arial,sans-serif;font-size:13px">------------------------------</span><span style="font-family:arial,sans-serif;font-size:13px">------------------------------</span><span style="font-family:arial,sans-serif;font-size:13px">--</span>-</div>
<div><br></div><div><br></div><div><br style="font-family:arial,sans-serif;font-size:13px"><blockquote class="gmail_quote" style="font-family:arial,sans-serif;font-size:13px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
From: Mark McClain <<a href="mailto:mmcclain@yahoo-inc.com" target="_blank">mmcclain@yahoo-inc.com</a> <mailto:<a href="mailto:mmcclain@yahoo-inc.com" target="_blank">mmcclain@yahoo-inc.com</a><u></u>>><br>Reply-To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<u></u>openstack.org</a><br><mailto:<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<u></u>openstack.org</a>>><br>
Date: Monday, August 4, 2014 at 4:27 PM<br>To: "OpenStack Development Mailing List (not for usage questions)"<br><<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<u></u>openstack.org</a><br>
<mailto:<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.<u></u>openstack.org</a>>><br>Subject: [openstack-dev] [Neutron] Group Based Policy and the way forward<br><br>All-<br>
<br>tl;dr<br><br>* Group Based Policy API is the kind of experimentation we be should<br>attempting.<br>* Experiments should be able to fail fast.<br>* The master branch does not fail fast.<br>* StackForge is the proper home to conduct this experiment.<br>
<br><br>Why this email?<br>---------------<br>Our community has been discussing and working on Group Based Policy<br>(GBP) for many months.  I think the discussion has reached a point where<br>we need to openly discuss a few issues before moving forward.  I<br>
recognize that this discussion could create frustration for those who<br>have invested significant time and energy, but the reality is we need<br>ensure we are making decisions that benefit all members of our community<br>
(users, operators, developers and vendors).<br><br>Experimentation<br>----------------<br>I like that as a community we are exploring alternate APIs.  The process<br>of exploring via real user experimentation can produce valuable results.<br>
  A good experiment should be designed to fail fast to enable further<br>trials via rapid iteration.<br><br>Merging large changes into the master branch is the exact opposite of<br>failing fast.<br><br>The master branch deliberately favors small iterative changes over time.<br>
  Releasing a new version of the proposed API every six months limits<br>our ability to learn and make adjustments.<br><br>In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental<br>APIs.  The results have been very mixed as operators either shy away<br>
from testing/offering the API or embrace the API with the expectation<br>that the community will provide full API support and migration.  In both<br>cases, the experiment fails because we either could not get the data we<br>
need or are unable to make significant changes without accepting a<br>non-trivial amount of technical debt via migrations or draft API support.<br><br>Next Steps<br>----------<br>Previously, the GPB subteam used a Github account to host the<br>
development, but the workflows and tooling do not align with OpenStack's<br>development model. I’d like to see us create a group based policy<br>project in StackForge.  StackForge will host the code and enable us to<br>
follow the same open review and QA processes we use in the main project<br>while we are developing and testing the API. The infrastructure there<br>will benefit us as we will have a separate review velocity and can<br>frequently publish libraries to PyPI.  From a technical perspective, the<br>
13 new entities in GPB [1] do not require any changes to internal<br>Neutron data structures.  The docs[2] also suggest that an external<br>plugin or service would work to make it easier to speed development.<br><br>End State<br>
---------<br>APIs require time to fully bake and right now it is too early to know<br>the final outcome.  Using StackForge will allow the team to retain all<br>of its options including: merging the code into Neutron, adopting the<br>
repository as sub-project of the Network Program, leaving the project in<br>StackForge project or learning that users want something completely<br>different.  I would expect that we'll revisit the status of the repo<br>
during the L or M cycles since the Kilo development cycle does not leave<br>enough time to experiment and iterate.<br><br><br>mark<br><br>[1]<br><a href="http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst#n370" target="_blank">http://git.openstack.org/cgit/<u></u>openstack/neutron-specs/tree/<u></u>specs/juno/group-based-policy-<u></u>abstraction.rst#n370</a><br>
[2]<br><a href="https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078" target="_blank">https://docs.google.com/<u></u>presentation/d/<u></u>1Nn1HjghAvk2RTPwvltSrnCUJkidWK<u></u>WY2ckU7OYAVNpo/edit#slide=id.<u></u>g12c5a79d7_4078</a><br>
<br>[3]</blockquote></div></div></div>
</div>