Open Stack

On 4/9/2015 10:34 PM, Kevin Benton wrote:
> IIRC there was some work to make the plugging call out to a script so
> all of the calls to various vswitches don't need to be in Nova. I would
> prefer this to removing all plugging logic from Nova.
>
> The main reason I would be hesitant to leave plugging completely out of
> Nova is that it requires an agent on the compute node, which isn't the
> case right now (e.g. plugins based on openflow, ovsdb, or something
> similar with a remote controller handling the setup of forwarding logic).
>
> On Apr 9, 2015 5:27 PM, "Matt Riedemann" <mriedem at linux.vnet.ibm.com
> <mailto:mriedem at linux.vnet.ibm.com>> wrote:
>
>
>
>     On 4/9/2015 8:56 AM, Neil Jerram wrote:
>
>         On 08/04/15 22:07, Michael Still wrote:
>
>             priorities and specs
>             ===============
>
>             I think the current spec process is starting to work well
>             for us, and
>             that priorities was a success. We should continue with
>             specs, but with
>             an attempt to analyse why so many approved specs don’t land
>             [...]
>
>
>             nova-net
>             =======
>
>             OMG, this is still a thing. We need to actually work out
>             what we’re
>             doing here, and then do it. [...]
>
>
>             conclusion
>             ========
>
>             I make no claim that my list is exhaustive. What else do you
>             think we
>             should be tackling in Liberty?
>
>
>         Something kind of related to two of the strands above, from the
>         point of
>         view of someone who had an approved networking-related Nova spec
>         that
>         failed to land for Kilo...
>
>         Basically, should Nova try harder to get out of the networking
>         business?
>            Currently the situation is that OpenStack networking
>         experimentation
>         is mostly in Neutron (as I assume it should be) but also often
>         requires
>         changes to the VIF type code in Nova.  Should we try to close
>         off that
>         situation, I would guess through some structural solution that
>         puts all
>         the required code changes firmly into Neutron's domain?
>
>
>     Yes, this isn't just Neutron, it's also storage backends with
>     Cinder, see nova.virt.libvirt.volume.
>
>     At one point in this release I tried to wrap my head around why we
>     have all of this VIF plugging gorp inside nova and requires a nova
>     change to enable neutron plugins.  This all happened before I was
>     working on the project, but my takeaway was this was how nova got
>     neutron up and running at the time with the way nova was architected
>     for nova-network, but is like fitting a square peg in a round hole,
>     i.e. the virt driver has to do something locally so the neutron
>     agent picks up that change and tells the neutron server and
>     meanwhile nova is waiting on the vif plugging callback event from
>     neutron so it can continue with the server build request (and that's
>     only the libvirt driver).  I'm not really sure why nova can't simply
>     call a neutron API to do the plug and then wait for a response that
>     it's done, but leave all of the messy neutron plugin-specific
>     binding stuff in neutron and abstract it away from nova.  Same goes
>     for cinder and connecting/disconnecting volumes.
>
>     But I'm naive, so just my 2 cents here.
>
>
>         I don't want to prejudge what the solution might be.  My point
>         here is
>         to suggest discussing and deciding whether this could be a
>         worthwhile
>         priority.  If it sounds of interest, I could add something to the
>         etherpad for Nova design session ideas.
>
>         (I appreciate that the nova-net question is way bigger and more
>         practically important overall than my specific point about the
>         VIF type
>         code.  However it is possible that the VIF type code contributes
>         to a
>         continuing lack of clarity about where networking function lies in
>         OpenStack.)
>
>         Regards,
>               Neil
>
>         ______________________________________________________________________________
>         OpenStack Development Mailing List (not for usage questions)
>         Unsubscribe:
>         OpenStack-dev-request at lists.__openstack.org?subject:__unsubscribe <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>         http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>     --
>
>     Thanks,
>
>     Matt Riedemann
>
>
>     ______________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.__openstack.org?subject:__unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

But the neutron L2 agent is already on the compute node, right?  Or are 
there plans to remove that?

-- 

Thanks,

Matt Riedemann