I agree. But, as far as I know [2], there should be a some kind of ML2 integration layer for each plugin, and it should be in Neutron code base (see [1] for example). There is no vDS ML2 driver in Neutron at all and FF will become soon. So, it seems we cannot manage to adjust a blueprint spec [3], make it approved, refactor a code of the driver and provide a 3rd party CI for that in such a short period before FF.
[1] thin Mellanox ML2 driver https://review.openstack.org/#/c/148614/ [2] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html [3] https://blueprints.launchpad.net/neutron/+spec/ml2-dvs-mech-driver On Sat, Jan 24, 2015 at 12:45 AM, Kevin Benton <blak...@gmail.com> wrote: > It's worth noting that all Neutron ML2 drivers are required to move to > their own repos starting in Kilo so installing an extra python package to > use a driver will become part of the standard Neutron installation > workflow. So I would suggest creating a stackforge project for the vDS > driver and packaging it up. > > On Fri, Jan 23, 2015 at 11:39 AM, Andrey Danin <ada...@mirantis.com> > wrote: > >> Hi, all, >> >> As you may know, Fuel 6.0 has an ability to deploy either a KVM-oriented >> environment or a VMware vCenter-oriented environment. We wants to go >> further and mix them together. A user should be able to run both >> hypervisors in one OpenStack environment. We want to get it in Fuel 6.1. >> Here is how we gonna do this. >> >> * When vCenter is used as a hypervisor the only way to use volumes with >> it is to use Cinder VMDK backend. And vise versa, KVM cannot operate with >> the volumes provided by Cinder VMDK backend. All that means that we should >> have two separe infrastructures (a hypervisor + a volume service) for each >> HV presented in environment. To do that we decided to place corresponding >> nova-compute and cinder-volume instances into different Availability Zones. >> Also we want to disable 'cross_az_attach' option in nova.conf to restrict a >> user to mount a volume to an instance which doesn't support this volume >> type. >> >> * A cinder-volume service is just a proxy between vCenter Datastore and >> Glance when used with VMDK. It means that the service itself doesn't need a >> local hard drive but sometimes can significantly consume network. That's >> why it's not a good idea to always put it to a Controller node. So, we want >> to add a new role called 'cinder-vmdk'. A user will be able to put this >> role to whatever node he wants: a separate node or combine with other >> roles. HA will be achieved by placing the role on two or more nodes. >> Cinder-volume services on each node will be configured identicaly, >> including 'host' stanza. We have the same approach now for Cinder+Ceph. >> >> * Nova-compute services for vCenter are kept running on Controller nodes. >> They are managed by Corosync. >> >> * There are two options for network backend exist. A good old >> Nova-network and a modern Neutron with ML2 DVS driver enabled. The problem >> with Nova-network is that we have to run it in 'singlehost' mode. It means, >> that the only nova-network service will be running for the whole >> environment. It makes the service a single point of failure, prevents a >> user to use Security Groups, and increases a network consuming for the node >> where the service is running. The problem with Neutron is that there is no >> ML2 DVS driver in an upstream Neutron for Juno and even Kilo. The is an >> unmerged patch [1] with almost no chances to get in Kilo. Good news are >> that we managed to run a PoC lab with this driver and both HVs enabled. So, >> we can build the driver as a package but it'll be a little ugly. That's why >> we picked the Nova-network approach as a basis. In Cluster creation wizard >> will be something to choose if you want to use vCenter in a cluster or not. >> Depending on it the nova-network service will be run in the 'singlenode' or >> 'multinode' mode. May be, if we have enough resources we'll implement a >> Neutron + vDS support also. >> >> * We are going to move all VMWare-specific settings to a separate UI tab. >> On the Settings tab we will keep a Glance backend switch (Swift, Ceph, >> VMware) and a libvirt_type switch (KVM, qemu). At the cluster creation >> wizard there will be a checkbox called 'add a VMware vCenter support into >> your cloud'. When it's enabled a user can choose nova-network only. >> >> * OSTF test suit will be extended to support separate sets of tests for >> each HV. >> >> [1] Neutron ML2 vDS driver https://review.openstack.org/#/c/111227/ >> >> Links to blueprints: >> https://blueprints.launchpad.net/fuel/+spec/vmware-ui-settings >> https://blueprints.launchpad.net/fuel/+spec/cinder-vmdk-role >> https://blueprints.launchpad.net/fuel/+spec/vmware-dual-hypervisor >> >> >> I would appreciate to see your thoughts about all that. >> >> >> >> -- >> Andrey Danin >> ada...@mirantis.com >> skype: gcon.monolake >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Kevin Benton > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Andrey Danin ada...@mirantis.com skype: gcon.monolake
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
