Open Stack

Ian, Neil, thanks for your input!

> There may be a set of races you need to deal with, too - what happens
if
> > Nova starts a VM attached to a Neutron network binding that has yet
to
> > be set up?  Neutron doesn't (well, technically, shouldn't be
expected
> > to) do things instantaneously on a call, even binding, or you get
into
> > the realm of distributed system failure case analysis.
> 
> Good point.  Andreas, how do you think the timing of the Nova and 
> Neutron parts will work?

Well, that's a good point where I based my design on wrong assumptions.
I had a clear picture of separation in my mind, letting neutron serve
all the base network (bridge or libvirt network) while nova will use
this as base for plugging. But that's obviously not true - also for
linuxbridge agent there is some plug code ensuring that the bridge is
there. 
--> So plug is definitively required to work around potential timing
issues!

Another idea I just verified is, letting nova create the libvirt
network, but without any interface definitions for it. Neutron then
would add the corresponding interface asyncronously. Unfortunately this
does not work too, as an instance can not be spawned on a libvirt
network without any interface defined...

So for my case this might be a showstopper. My original problem which I
tried to solve with the network approach is, that nova does not need to
know about the physical eth interface name used as source for a macvtap
but rather just use the generic network name. So for it would be the
same problem like with directly defining macvtap as interface type


> Do you happen to know how data gets routed _to_ a VM, in the 
> type='network' case?

Neil, sorry no. Haven't played around with that, yet. But from reading
the libvirt man, it looks good. It's saying "Guest network traffic will
be forwarded to the physical network via the host's IP routing stack" -
so I would assume this is L3. Maybe you should give it a quick try to
figure out... 

-- 
Andreas 
(irc: scheuran)


On Wed, 2015-06-10 at 21:20 +0100, Neil Jerram wrote:
> Hi Ian,
> 
> Thanks for your reply!
> 
> On 10/06/15 21:07, Ian Wells wrote:
> > I don't see a problem with this, though I think you do want plug/unplug
> > calls to be passed on to Neutron so that has the opportunity to set up
> > the binding from its side (usage >0) and tear it down when you're done
> > with it (usage <1).
> >
> > There may be a set of races you need to deal with, too - what happens if
> > Nova starts a VM attached to a Neutron network binding that has yet to
> > be set up?  Neutron doesn't (well, technically, shouldn't be expected
> > to) do things instantaneously on a call, even binding, or you get into
> > the realm of distributed system failure case analysis.
> 
> Good point.  Andreas, how do you think the timing of the Nova and 
> Neutron parts will work?
> 
> > Neil, are you trying to route to the host - where this will work,
> > because a libvirt network is L2 - or to the VM - where this won't, for
> > the same reason?
> 
> Consider data that's arriving at a local VM, and has come from a VM on 
> another compute host.
> 
>    VM ----- Host A ------------- Host B ----- VM
> 10.0.0.1                                  10.0.0.2
> 
> In Host B's routing table there is a rule like this:
> 
> 10.0.0.2/32 dev tap12345-CD
> 
> where tap12345-CD is the TAP interface towards the VM.  Does that answer 
> your question, and would that be possible with a libvirt network?
> 
> Thanks,
> 	Neil
> 
> 
> > --
> > Ian.
> >
> >
> > On 10 June 2015 at 12:16, Neil Jerram <Neil.Jerram at metaswitch.com
> > <mailto:Neil.Jerram at metaswitch.com>> wrote:
> >
> >     On 10/06/15 15:47, Andreas Scheuring wrote:
> >
> >         Hi Daniel, Neil and others,
> >
> >         I was thinking about introducing libvirt-network as a new vif
> >         type to
> >         nova. It can be used when Neutron prepares a libvirt network for
> >         attaching guests.
> >
> >         Would you see any general concerns with such an approach?
> >         Anything that
> >         I need to consider with libvirt networks in addition? Maybe I should
> >         mention one thing due to the discussion this morning: No plug/unplug
> >         behavior would required.
> >
> >         Any feedback is welcome!
> >
> >
> >         I added a blueprint and wrote a spec with more details [1]. This
> >         blueprint would make the macvtap-vif blueprint [2] dispensable.
> >
> >         The neutron code exploiting this libvirt network vif type will
> >         land on
> >         stackforge. It will manage macvtap backed libvirt networks --> offer
> >         guest attachments via macvtap. [3]
> >
> >
> >
> >         [1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif
> >         [2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif
> >         [3] https://launchpad.net/networking-macvtap
> >         (I'm still waiting for the repo to be approved, so for now I
> >         only have a
> >         launchpad project to ref to).
> >
> >
> >     Thanks, Andreas, this looks interesting.  I wonder if
> >
> >     <network>
> >        <name>xyz</name>
> >        <forward mode="route"\>
> >        ...
> >     </network>
> >
> >     <domain>
> >        ...
> >        <interface type='network'>
> >          <source network='xyx'/>
> >        </interface>
> >        ...
> >     </domain>
> >
> >     would provide the connectivity that my Calico project wants to set
> >     up [1] - i.e. where all data to and from VMs is routed on the
> >     compute host - instead of
> >
> >     <domain>
> >        ...
> >        <interface type='ethernet'>
> >          ...
> >        </interface>
> >        ...
> >     </domain>
> >
> >     Do you happen to know how data gets routed _to_ a VM, in the
> >     type='network' case?
> >
> >     Regards,
> >              Neil
> >
> >
> >     [1] http://docs.projectcalico.org/en/latest/home.html
> >
> >
> >     __________________________________________________________________________
> >     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
> >
> >
> >
> >
> > __________________________________________________________________________
> > 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
> >
> 
> __________________________________________________________________________
> 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
>