Open Stack

On Nov 28, 2012, at 3:13 PM, Dan Wendlandt <dan at nicira.com> wrote:

> 
> 
> On Wed, Nov 28, 2012 at 12:10 PM, Kyle Mestery (kmestery) <kmestery at cisco.com> wrote:
> Dan and Kiran:
> 
> I think this could actually be done in a plugin. For instance, the Cisco plugin actually interacts with physical infrastructure to configure NX-OS devices (e.g. setting up trunk ports, adding and removing VLANs to ports, etc.). What Kiran is talking about could ideally be handled in a plugin dependent manner I suspect. I don't believe there's anything in Quantum tying Quantum networks solely to overlay networks, the plugin itself can orchestrate things however it likes.
> 
> Kyle,
> 
> I agree that each Quantum plugin will define what a "base setup" is, and then provisions logical networks on top.  Items like adding/removing VLANs are clearly in the scope of what several plugins already do to provision logical networks on top of physical infrastructure, so I did not interpret that to be what Kiran was talking about.  Perhaps it would be good for Kiran to clarify what he's thinking about with a more detailed example.  In general, what setup is required by the physical infrastructure is going to be highly plugin dependent, meaning that perhaps there would be extensions to assist with physical setup on a per-plugin basis, but it seems harder to create a generica "operator api" to setup the network in a way that is sufficient for all (or even most) plugins. 
> 
> dan

Cool, I think we were both thinking the same thing then, I agree with what you were say above. Hearing more from Kiran would be good to get a better idea of his requirements here. Requiring his own plugin may be overkill, but adding extensions on a per-plugin basis is a much better way to go forward.

Thanks,
Kyle

>  
> 
> Thanks,
> Kyle
> 
> On Nov 28, 2012, at 1:10 PM, Dan Wendlandt <dan at nicira.com> wrote:
> 
> > Adding openstack-dev
> >
> > Hi Kiran,
> >
> > This is an interesting topic, and one that is brought up from time to time.
> >
> > In general, core OpenStack projects do not focus on the provisioning/turn-up of the physical devices themselves, focusing instead of the provisioning/turn-up of virtual devices on top of already deployed physical infrastructure.  For example, nova does not image the compute server, configure hypervisor IP addresses, or install KVM/XenServer/Hyper-V/EX.  Rather, Nova assumes that these components have been installed and creates virtual machines on top of them.  Similarly, I would expect that Quantum would not tackle the basic configuration of your physical networking gear (defining physical subnets, setting up management connectivity, enabling SNMP for monitoring, etc.), but rather assumes a base network config is in place and overlays the logical network connectivity on top of it.
> >
> > That said, I think automating the setup of the physical infrastructure is a very interesting + valuable exercise in and of itself, and there are many places where integration with Quantum would be very valuable to both projects.  It may be that if this effort takes off, it would make sense to host this as a sort of eco-system project, if it turns out that this is what we do for other similar efforts around compute + storage.
> >
> > Dan
> >
> >
> > On Wed, Nov 28, 2012 at 1:05 AM, Kiran Lonikar <klonikar at yahoo-inc.com> wrote:
> > Hi All,
> >
> > We need to reach out to openstack quantum folks for discussing our quantum
> > extension proposal. I am not sure if reaching out to Dan would be
> > sufficient. I would appreciate if any of you could include the quantum
> > stakeholders.
> >
> > Our proposal:
> > We are developing a management system for our network architecture. This
> > is being developed as a set of APIs to pre-configure our network, turnup
> > network devices, enable/disable ports on the devices etc. This system
> > would be used by our operations people to setup the network. The core
> > quantum APIs would be used by the end users of the network or openstack
> > compute.
> >
> > We are in the process of putting together a blueprint, but want to start
> > discussions to gauge the level of interest for such extensions to the core
> > APIs.
> >
> > -Kiran
> >
> >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Dan Wendlandt
> > Nicira, Inc: www.nicira.com
> > twitter: danwendlandt
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt 
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev