Open Stack

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> 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://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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150409/dcf06b47/attachment.html>