<div dir="ltr">I agree with Kevin. Like in Juno, we as a subteam will be shooting for option 1 (again) for Kilo - ideally we can land in Kilo, and we will work closely with the community to try to accomplish that. In the meantime, we need to have a repo to iterate our implementations, build package (Juno based) to early adopters, and be as transparent as if the code is on gerrit. With option 2 never picking up momentum when Bob suggested it on the ML, option 3 being more like an idea discussed by several cores during the mid-cycle meetup, and option 4 is currently on holding pattern without any detail but tons of concern raised on ML --- option 5 (stackforge) seems like the best available option at this point.<div><br></div><div>Thanks,</div><div>- Stephen</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 11, 2014 at 10:02 AM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks. This is good writeup.<div><br></div><div><span class=""><div>><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">Of course this all assumes there is consensus that we should proceed with GBP, that we should continue by iterating the currently proposed design and code, and that GBP should eventually become part of Neutron. These assumptions may still be the real issues</span><span style="font-size:13.333333015441895px;font-family:arial,sans-serif"> :-( </span><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">.</span></div><div><span style="font-size:13.333333015441895px;font-family:arial,sans-serif"><br></span></div></span><div><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">Unfortunately I think this is the real root cause. Most of the people that worked on GBP definitely want to see it merged into Neutron and is in general agreement there. However, some of the other cores disagreed and now GBP is sitting in limbo. IIUC, this thread was started to just get GBP to some location where it can be developed on and tested that isn't a big string of rejected gerrit patches. </span></div></div><span class=""><div><span style="font-size:13.333333015441895px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13.333333015441895px;font-family:arial,sans-serif">></span><span style="font-family:arial,sans-serif;font-size:13.333333015441895px">Does the above make some sense? What have I missed?</span><span style="font-family:arial,sans-serif;font-size:13.333333015441895px"> </span></div><div><span style="font-size:13.333333015441895px;font-family:arial,sans-serif"><br></span></div></span><div><font face="arial, sans-serif">Option 1 is great, but I don't see how the same thing that happened in Juno would be avoided.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Option 2 is also good, but that idea didn't seem to catch on. If this option is on the table, this seems like the best way to go.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Option 3 sounded like it brought up a lot of tooling (gerrit) issues with regard to how the merging workflow would work. </font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Option 4 is unknown until the incubator details are hashed out.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Option 5 is stackforge. I see this as a better place just to do what is already being done right now. You're right that patches would occur without core reviewers, but that's essentially what's happening now since nothing is getting merged. </font></div><div><font face="arial, sans-serif"><br></font></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 11, 2014 at 7:57 AM, Robert Kukura <span dir="ltr"><<a href="mailto:kukura@noironetworks.com" target="_blank">kukura@noironetworks.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span>
    <br>
    <div>On 9/10/14, 6:54 PM, Kevin Benton
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Being in the incubator won't help with this if it's
        a different repo as well.</div>
    </blockquote></span>
    Agreed. <br>
    <br>
    Given the requirement for GBP to intercept API requests, the
    potential couplings between policy drivers, ML2 mechanism drivers,
    and even service plugins (L3 router), and the fact Neutron doesn't
    have a stable [service] plugin API, along with the goal to
    eventually merge GBP into Neutron, I'd rank the options as follows
    in descending order:<br>
    <br>
    1) Merge the GBP patches to the neutron repo early in Kilo and
    iterate, just like we had planned for Juno<span><span> ;-) </span></span>.<br>
    <br>
    2) Like 1, but with the code initially in a "preview" subtree to
    clarify its level of stability and support, and to facilitate
    packaging it as an optional component.<br>
    <br>
    3) Like 1, but merge to a feature branch in the neutron repo and
    iterate there.<br>
    <br>
    4) Develop in an official neutron-incubator repo, with neutron core
    reviews of each GBP patch.<br>
    <br>
    5) Develop in StackForge, without neutron core reviews.<br>
    <br>
    <br>
    Here's how I see these options in terms of the various
    considerations that have come up during this discussion:<br>
    <br>
    * Options 1, 2 and 3 most easily support whatever coupling is needed
    with the rest of Neutron. Options 4 and 5 would sometimes require
    synchronized changes across repos since dependencies aren't in terms
    of stable interfaces. <br>
    <br>
    * Options 1, 2 and 3 provide a clear path to eventually graduate GBP
    into a fully supported Neutron feature, without loss of git history.
    Option 4 would have some hope of eventually merging into the neutron
    repo due to the code having already had core reviews. With option 5,
    reviewing and merging a complete GBP implementation from StackForge
    into the neutron repo would be a huge effort, with significant risk
    that reviewers would want design changes not practical to make at
    that stage.<br>
    <br>
    * Options 1 and 2 take full advantage of existing review, CI,
    packaging and release processes and mechanisms. All the other
    options require extra work to put these in place.<br>
    <br>
    * Options 1 and 2 can easily make GBP consumable by early adopters
    through normal channels such as devstack and OpenStack
    distributions. The other options all require the operator or the
    packager to pull GBP code from a different source than the base
    Neutron code.<br>
    <br>
    * Option 1 relies on the historical understanding that new Neutron
    extension APIs are not initially considered stable, and incompatible
    changes can occur in future releases. Options 2, 3 and 4 make this
    explicit. Option 5 really has nothing to do with Neutron.<br>
    <br>
    * Option 5 allows rapid iteration by the GBP team, without waiting
    for core review. This is essential during experimentation and
    prototyping, but at least some participants consider the GBP
    implementation to be well beyond that phase.<br>
    <br>
    * Options 3, 4, and 5 potentially decouple the GBP release schedule
    from the Neutron release schedule. With options 1 or 2, GBP
    snapshots would be included in all normal Neutron releases. With any
    of the options, the GBP team, vendors, or distributions would be
    able to back-port arbitrary snapshots of GBP to a branch off the
    stable/juno branch (in the neutron repo itself or in a clone) to
    allow early adopters to use GBP with Juno-based OpenStack
    distributions.<br>
    <br>
    <br>
    Does the above make some sense? What have I missed? <br>
    <br>
    Of course this all assumes there is consensus that we should proceed
    with GBP, that we should continue by iterating the currently
    proposed design and code, and that GBP should eventually become part
    of Neutron. These assumptions may still be the real issues<span><span> :-( </span></span>. If we can't
    agree on whether GBP is in an experimentation/rapid-prototyping
    phase vs. an almost-ready-to-beta-test phase, I don't see how can we
    get consensus on the next steps for its development.<br>
    <br>
    -Bob<div><div><br>
    <blockquote type="cite">
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Wed, Sep 10, 2014 at 7:22 AM, Robert
          Kukura <span dir="ltr"><<a href="mailto:kukura@noironetworks.com" target="_blank">kukura@noironetworks.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
              On 9/9/14, 7:51 PM, Jay Pipes wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                On 09/09/2014 06:57 PM, Kevin Benton wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  Hi Jay,<br>
                  <br>
                  The main component that won't work without direct
                  integration is<br>
                  enforcing policy on calls directly to Neutron and
                  calls between the<br>
                  plugins inside of Neutron. However, that's only one
                  component of GBP.<br>
                  All of the declarative abstractions, rendering of
                  policy, etc can be<br>
                  experimented with here in the stackforge project until
                  the incubator is<br>
                  figured out.<br>
                </blockquote>
                <br>
                OK, thanks for the explanation Kevin, that helps!<br>
              </blockquote>
            </span>
            I'll add that there is likely to be a close coupling between
            ML2 mechanism drivers and corresponding GBP policy drivers
            for some of the back-end integrations. These will likely
            share local state such as connections to controllers, and
            may interact with each other as part of processing core and
            GBP API requests. Development, review, and packaging of
            these would be facilitated by having them on the same branch
            in the same repo, but its probably not absolutely necessary.<br>
            <br>
            -Bob
            <div>
              <div><br>
                <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <br>
                  Best,<br>
                  -jay<br>
                  <br>
                  <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    On Tue, Sep 9, 2014 at 12:01 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a><br>
                    <mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>>
                    wrote:<br>
                    <br>
                        On 09/04/2014 12:07 AM, Sumit Naiksatam wrote:<br>
                    <br>
                            Hi,<br>
                    <br>
                            There's been a lot of lively discussion on
                    GBP a few weeks back<br>
                            and we<br>
                            wanted to drive forward the discussion on
                    this a bit more. As you<br>
                            might imagine, we're excited to move this
                    forward so more people can<br>
                            try it out.  Here are the options:<br>
                    <br>
                            * Neutron feature branch: This presumably
                    allows the GBP feature<br>
                            to be<br>
                            developed independently, and will perhaps
                    help in faster iterations.<br>
                            There does seem to be a significant
                    packaging issue [1] with this<br>
                            approach that hasn’t been completely
                    addressed.<br>
                    <br>
                            * Neutron-incubator: This allows a path to
                    graduate into<br>
                            Neutron, and<br>
                            will be managed by the Neutron core team.
                    That said, the proposal is<br>
                            under discussion and there are still some
                    open questions [2].<br>
                    <br>
                            * Stackforge: This allows the GBP team to
                    make rapid and iterative<br>
                            progress, while still leveraging the
                    OpenStack infra. It also<br>
                            provides<br>
                            option of immediately exposing the existing
                    implementation to early<br>
                            adopters.<br>
                    <br>
                            Each of the above options does not preclude
                    moving to the other<br>
                            at a later time.<br>
                    <br>
                            Which option do people think is more
                    preferable?<br>
                    <br>
                            (We could also discuss this in the weekly
                    GBP IRC meeting on<br>
                            Thursday:<br>
                    <a href="https://wiki.openstack.org/__wiki/Meetings/Neutron_Group___Policy" target="_blank">https://wiki.openstack.org/__wiki/Meetings/Neutron_Group___Policy</a>
                    <<a href="https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy" target="_blank">https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy</a>>)<br>
                    <br>
                            Thanks!<br>
                    <br>
                            [1]<br>
                    <a href="http://lists.openstack.org/__pipermail/openstack-dev/2014-__August/044283.html" target="_blank">http://lists.openstack.org/__pipermail/openstack-dev/2014-__August/044283.html</a><br>
                    <<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html</a>><br>
                            [2]<br>
                    <a href="http://lists.openstack.org/__pipermail/openstack-dev/2014-__August/043577.html" target="_blank">http://lists.openstack.org/__pipermail/openstack-dev/2014-__August/043577.html</a><br>
                    <<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html</a>><br>
                    <br>
                    <br>
                        Hi all,<br>
                    <br>
                        IIRC, Kevin was saying to me in IRC that GBP
                    really needs to live<br>
                        in-tree due to it needing access to various
                    internal plugin points<br>
                        and to be able to call across different plugin
                    layers/drivers inside<br>
                        of Neutron.<br>
                    <br>
                        If this is the case, how would the stackforge
                    GBP project work if it<br>
                        wasn't a fork of Neutron in its entirety?<br>
                    <br>
                        Just curious,<br>
                        -jay<br>
                    <br>
                    <br>
                        _________________________________________________<br>
                        OpenStack-dev mailing list<br>
                        <a href="mailto:OpenStack-dev@lists.openstack.__org" target="_blank">OpenStack-dev@lists.openstack.__org</a><br>
                        <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>><br>
                    <a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev</a>
                    <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
                    <br>
                    <br>
                    <br>
                    <br>
                    -- <br>
                    Kevin Benton<br>
                    <br>
                    <br>
                    _______________________________________________<br>
                    OpenStack-dev mailing list<br>
                    <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
                    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                    <br>
                  </blockquote>
                  <br>
                  _______________________________________________<br>
                  OpenStack-dev mailing list<br>
                  <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
                  <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                </blockquote>
                <br>
                <br>
                _______________________________________________<br>
                OpenStack-dev mailing list<br>
                <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
                <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div>Kevin Benton</div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>