Open Stack

Hi,

one other part of your future work, if the BP is accepted, is to
deploy a third party testing environment. Since your work doesn't rely
on opensource solution (VMWare), it won't be tested by the openstack
CI. you will have to deploy an infra to test and vote on each patch
submitted to neutron that might break your driver.

see : http://ci.openstack.org/third_party.html

regards

On Wed, May 7, 2014 at 8:39 AM, Jussi Sorjonen
<Jussi.Sorjonen at cybercom.com> wrote:
> Hi,
>
> Just to give this some context, the original idea for the driver came from
> the fact that there was no readily available method for using VLAN-backed
> port groups in dvSwitches with neutron. We tried using nova-network with
> regular vSwitches and VlanManager to evaluate the VMware driver in
> nova-compute but it was decided that neutron is a an absolute requirement
> for production use.
>
> The current code of the driver is tested with nova-compute controlling a
> vSphere 5.1 cluster. Multiple instances were successfully created,
> attached to the correct port group and network connectivity was achieved.
>
> We are not using VXLANs at the moment and are not actively looking into
> deploying them, so implementing a VXLAN support in the driver is not
> currently in our interest. Considering that VXLANs are configured as port
> groups in dvSwitches on the VMware side there isn¹t much difference in
> that part. However, configuring the VXLANs in the vShield app is something
> I think is out of the scope of this driver.
>
> We¹re interested in going through the blueprint process. Due to a rather
> tight schedule on our end we had to get a limited-functionality version of
> the driver ready before we had time to look into the process of submitting
> a blueprint and the required specs. The current version of the driver
> implements the only required feature in our environment - attaching
> virtual machines on the VMware side to correct dvSwitch port groups.
> Adding features like creating the port groups based on networks defined in
> neutron etc. are in consideration.
>
> I hope this answers some of the questions and I¹m happy to provide more
> details, if needed.
>
> Regards
>
> --
> Jussi Sorjonen, Systems Specialist, Data Center
> +358 (0)50 594 7848, jussi.sorjonen at cybercom.com
> Cybercom Finland Oy, Urho Kekkosen katu 3 B, 00100 Helsinki, FINLAND
> www.cybercom.fi | www.cybercom.com
>
>
>
>
> On 06/05/14 11:17, "Mathieu Rohon" <mathieu.rohon at gmail.com> wrote:
>
>>Hi IIkka,
>>
>>this is a very interesting MD for ML2. Have you ever tried to use your
>>ML2 driver with VMWare drivers on the nova side, so that you could
>>manage your VM with nova, and its network with neutron.
>>Do you think it would be difficult to extend your driver to support
>>vxlan encapsulation?
>>
>>Neutron has a new process to validate BP. Please follow those
>>instructions to submit your spec for review :
>>https://wiki.openstack.org/wiki/Blueprints#Neutron
>>
>>regards
>>
>>On Mon, May 5, 2014 at 2:22 PM, Ilkka Tengvall
>><ilkka.tengvall at cybercom.com> wrote:
>>> Hi,
>>>
>>> I would like to start a discussion about a ML2 driver for VMware
>>>distributed
>>> virtual switch (dvSwitch) for Neutron. There is a new blueprint made by
>>>Sami
>>> Mäkinen (sjm) in
>>>
>>>https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mech-vmware-dv
>>>switch.
>>>
>>> The driver is described and code is publicly available and hosted in
>>>github:
>>>
>>>https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mech-vmware-dv
>>>switch
>>>
>>> We would like to get the driver through contribution process, what ever
>>>that
>>> exactly means :)
>>>
>>> The original problem this driver solves for is is the following:
>>>
>>> We've been running VMware virtualization platform in our data center
>>>before
>>> OpenStack, and we will keep doing it due existing services. We also have
>>> been running OpenStack for a while also. Now we wanted to get the most
>>>out
>>> of both by combining the customers networks on the both plafroms by
>>>using
>>> provider networks. The problem is that the networks need two separate
>>> managers, neutron and vmware. There was no OpenStack tools to attach the
>>> guests on VMware side to OpenStack provider networks during instance
>>> creation.
>>>
>>> Now we are putting our VMware under control of OpenStack. We want to
>>>have
>>> one master to control the networks, Neutron. We implemented the new ML2
>>> driver to do just that. It is capable of joining the machines created in
>>> vSphere to the same provider networks the OpenStack uses, using dvSwitch
>>> port groups.
>>>
>>>
>>> I just wanted to open the discussion, for the technical details please
>>> contact our experts on the CC list:
>>>
>>> Sami J. Mäkinen
>>> Jussi Sorjonen (freenode: mieleton)
>>>
>>>
>>> BR,
>>>
>>> Ilkka Tengvall
>>>  Advisory Consultant, Cloud Architecture
>>>  email:  ilkka.tengvall at cybercom.com
>>>  mobile: +358408443462
>>>  freenode: ikke-t
>>>  web:    http://cybercom.com - http://cybercom.fi
>>>
>>> _______________________________________________
>>> 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