[openstack-dev] [manila] Manila pythonclient compatibility with Juno release

[Nilesh P Bhosale]

Hi All,

We want to run python-manilaclient along with clients for other OpenStack 
services coming from OpenStack Juno release.
But, since https://github.com/openstack/python-manilaclient has only the 
master branch and no branch for Juno, if I try to deploy it on the same 
node, it breaks others due to the conflict in dependencies (specified in 
requirements.txt).
So, can someone help get me the Git revision/tag which can be used as a 
Juno release tag?
I tried to see the Git logs, but not sure which one to pick inline with 
the Juno release schedule, code freeze/release date?.

Need help in this regard.

Thanks,
Nilesh Bhosale__
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

[openstack-dev] [Mistral] Roll back capabilities & execution data context variables in YAML

[Rahul Rege]

Mistral team,

Couple of questions..

1) Roll back support : I came across few blueprints that talk about the
roll-back support but not sure if they are delivered yet, I wanted to check
if something is there out of the box that I should be aware of. Ofcourse,
roll-back being very specific, I'd expect a user defined action being
called for rolling back, just wondering if there is any construct after
(on-error : ) to be used in YAML

2) Execution context predefined ids - Here is what I found that talks about
task and execution ids that I can access (execution context
),
it would be great if you could point me to the list of all possible
variables like $.execution_id that are accessible inside the YAML.



Thanks and Regards
Rahul Rege
__
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

Re: [openstack-dev] [nova] will the real v2.1/v3 API status please stand up?

[Ken'ichi Ohmichi]

2015-02-09 9:26 GMT+09:00 Christopher Yeoh :
>>
>> I wasn't at the mid-cycle meetup for Kilo but even for Juno I'll admit I
>> was a bit lost. It's not my fault, I'm more good looks than brains. :)
>>
>> When I look at approved specs for Kilo, three pop out:
>>
>> 1. https://blueprints.launchpad.net/nova/+spec/v2-on-v3-api
>>
>> 2. https://blueprints.launchpad.net/nova/+spec/api-microversions
>>
>> 3. https://blueprints.launchpad.net/nova/+spec/v3-api-policy
>>
>
> So we need the first to blueprints for v2.1 microversions. We don't need
> v3-api-policy merged to release
>  v2.1 microversions though I believe it is a separate important bit of work
> to reduce tech debt and make
> life easier for operators.

I think the first one(bp/v2-on-v3-api) only is necessary for dropping
'experimental' label from v2.1 API, because raw v2.1 API(meaning
v2.1 without microversions) has already implemented some merits
(strong validation, clean code, easy deployment, etc) for developers
and operators.

>> The only one of those that has a dependency in launchpad is the last one
>> and it's dependency is on:
>>
>> https://blueprints.launchpad.net/nova/+spec/nova-v3-api
>>
>> Which looks like it was replaced by the v2-on-v3-api blueprint.
>>
>> If I look at the open changes for each, there are a lot:
>>
>> 1.
>> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/v2-on-v3-api,n,z
>>
>> 2.
>> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/api-microversions,n,z
>>
>> 3.
>> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/v3-api-policy,n,z
>>
>> Do those all need to merge before the v2.1 API is no longer experimental?

As I said at the above, the first branch is necessary for dropping
experimental from v2.1 API. In addition, the first branch contains
some cleanup patches also. The important patches are just four:

* Provide full v2 compatibility
  https://review.openstack.org/#/c/138599/
  https://review.openstack.org/#/c/153466/
  https://review.openstack.org/#/c/153137

* Drop experimental from v2
  https://review.openstack.org/149948

So we have already done most works for v2.1 API.

Thanks
Ken Ohmichi

__
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

Re: [openstack-dev] [Manila]Questions about using not handle share-servers drivers with "Flat network"

[Li, Chen]

Hi Ben,

Sorry for the burden.
It took more effort than I expected.
Finally, I think I understand what you guys have told me again and again.

Thanks very much for putting up with me and my questions.

-chen

From: Ben Swartzlander [mailto:b...@swartzlander.org]
Sent: Thursday, February 05, 2015 8:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Manila]Questions about using not handle 
share-servers drivers with "Flat network"


On 02/04/2015 07:01 PM, Li, Chen wrote:
Hi,

Thanks very much for the reply.
Really sorry for the late response.

In your case if you have a driver that doesn't handle share servers, then the 
network is complete out of scope for Manila. Drivers that don't manage share 
servers have neither flat not segment networking in Manila, they have NO 
networking.

ð  So, you mean there is no way I can work as I want, right ?

But, is it possible to enable that ?

I think you missed the point when I say networking is out of scope for 
non-share-server-handling drivers. All that that means is that Manila will not 
be involved with the management of the network resources for the backend or the 
network paths between the clients and the server. The reason for this is to 
allow administrators to configure the network however they like. Arbitrarily 
complicated network designs are possible when you use a driver with 
driver_manages_share_servers=False because you're free to do what you want and 
Manila doesn't care.

I think people sometimes forget that Manila doesn't want to be involved with 
network management. We only touch the network where it's unavoidable, such as 
when we have to create new virtual machines that need to be reachable over the 
network from existing VMs. There already exist many other great tools inside 
and outside of OpenStack for doing network management and we want to avoid 
duplicating or overlapping with their functionality as much as possible.


If you noticed, we're trying to enable HDFS in manila:  
https://blueprints.launchpad.net/manila/+spec/hdfs-driver
That's the main reason I want to emphasize on my driver do not handle share 
server.

Big data users want to have a unify storage when they're working in cloud.
Because instances are not reliable resource in cloud. Put data together with 
instances while making sure data's reliability would be complicated.

The biggest difference between HDFS and all currently backends manila support 
is:
HDFS has different control path and data path.
For a HDFS cluster, it has one name node and multi data nodes.
Client would talk to "name node" first, get data location and then talk to data 
nodes to get data.
   The "Export location" represent "name node" information only.


ð  We can't put any "share-server" in the middle of user instances and HDFS 
cluster.

But, it do possible to let the HDFS work in the cloud with restrictions


ð  It can only support one  share-network at one time.

This actually restrict the ability of the manila backend, no multi-tenancy at 
all.

We want to use HDFS like this:
Connect users' "share-network" and "HDFS-cluster-network" by router.
Similar to currently generic driver's behavior when 
"connect_share_server_to_tenant_network = False" while no "share-server" exist.
Access control is achieved based on its own user.

We can add some access control based on keystone users and keystone tenants to 
avoid bad users to connect to HDFS cluster at very beginning if that's possible.

Thanks.
-chen

From: Ben Swartzlander [mailto:b...@swartzlander.org]
Sent: Wednesday, January 28, 2015 12:35 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Manila]Questions about using not handle 
share-servers drivers with "Flat network"

On 01/27/2015 06:39 PM, Li, Chen wrote:
Hi list,

I have some questions.
Hope can get help from you guys.

Manila has two driver modes.
For handle share server drivers, the share-network is easy to understand.
For not handle share-servers drivers, manila request admin to do everything 
before manila-share service start, and when the service is running, it only 
serves requests do not contain "share-network".

I kept confusing about which/why users would create shares without 
"share-network". Although when working with this kind of driver, the 
manila-share service can only support one specific network restricted by the 
backend. But "users" do not know backends, they should always want to create 
shares with "share-network", because users always want to connect shares to 
their instances that lives in the cloud with "share-network".
Then I have been told that these shares created without "share-network" are 
assumed to be used on a "public network".
The "public network" do make a clear explanation about why "share-network" not 
matter anymore.

But, when I build my cloud with Manila, what I want to do is let backends to 
serve my "Flat network".

I want to have 2 backends in Manila, both

Re: [openstack-dev] [nova] will the real v2.1/v3 API status please stand up?

[Christopher Yeoh]

Hi,

On Sat, Feb 7, 2015 at 8:35 AM, Matt Riedemann 
wrote:

> I'm not going to hide it, I don't know what's going on with the v2.1 API
> status, i.e. what is the criteria to that thing dropping it's
> 'experimental' label?
>
>
So I caught up with Matt on IRC, repeating some references and discussion
here for everyone else


> I wasn't at the mid-cycle meetup for Kilo but even for Juno I'll admit I
> was a bit lost. It's not my fault, I'm more good looks than brains. :)
>
> When I look at approved specs for Kilo, three pop out:
>
> 1. https://blueprints.launchpad.net/nova/+spec/v2-on-v3-api
>
> 2. https://blueprints.launchpad.net/nova/+spec/api-microversions
>
> 3. https://blueprints.launchpad.net/nova/+spec/v3-api-policy
>
>
So we need the first to blueprints for v2.1 microversions. We don't need
v3-api-policy merged to release
 v2.1 microversions though I believe it is a separate important bit of work
to reduce tech debt and make
life easier for operators.




> The only one of those that has a dependency in launchpad is the last one
> and it's dependency is on:
>
> https://blueprints.launchpad.net/nova/+spec/nova-v3-api
>
> Which looks like it was replaced by the v2-on-v3-api blueprint.
>
> If I look at the open changes for each, there are a lot:
>
> 1. https://review.openstack.org/#/q/status:open+project:
> openstack/nova+branch:master+topic:bp/v2-on-v3-api,n,z
>
> 2. https://review.openstack.org/#/q/status:open+project:
> openstack/nova+branch:master+topic:bp/api-microversions,n,z
>
> 3. https://review.openstack.org/#/q/status:open+project:
> openstack/nova+branch:master+topic:bp/v3-api-policy,n,z
>
> Do those all need to merge before the v2.1 API is no longer experimental?
>
>
We have an etherpad here which tracks our release criteria for v2.1 and
microversions:

https://etherpad.openstack.org/p/v2_1_ReleaseCriteria

As mentioned above it doesn't include api-policy

To make life easier for us I'd also like to request that if you review a
changeset that modifies the v2 api that you ensure it also if required is
applied to v2.1(v3 code). If it doesn't apply to v3 then ensure a
v2-only tag is in the commit message. That will help us verify v2 does not
diverge from v2.1 just before
release. After that I think v2 code will be essentially frozen except for
bug fixes and any api changes will
only be made through microversions.

Regards,

Chris

Is the, for lack of a better term, 'completion criteria', being tracked in
> an etherpad or wiki page somewhere?  I see stuff in the priorities etherpad
> https://etherpad.openstack.org/p/kilo-nova-priorities-tracking but it's
> not clear to me at a high level what makes v2.1 no longer experimental.
>
> Can someone provide that in less than 500 words?
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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
>
__
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

[openstack-dev] [keystone] SPF exception: Recursive deletion and project disabling

[Rodrigo Duarte]

Hi,

We are proposing this spec: https://review.openstack.org/#/c/148730/ . In
there we detail how will work recursive deletion and disabling for projects
(and domains). This change was dependent on the Reseller spec that was
approved before the deadline and adds some good improvements for the recent
merged Hierarchical Multitenancy feature, these changes would ease a lot
the way operators handle deployments using projects/domains hierarchies,
the implementation changes are not big and we believe it could easily land
in Kilo if the spec was approved.

What do you think? Makes sense for this spec to be a Spec Proposal Freeze
exception?

-- 
Rodrigo Duarte Sousa
Senior Software Engineer at Advanced OpenStack Brazil
Distributed Systems Laboratory
MSc in Computer Science
Federal University of Campina Grande
Campina Grande, PB - Brazil
http://rodrigods.com 
__
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

Re: [openstack-dev] [heat] Resource CREATE failed with TypeError

[Steve Baker]

On 06/02/15 23:07, Qiming Teng wrote:

Hi,

Just checked your template.  It seems your SoftwareDeployment resource
is not referencing the SoftwareConfig resource properly.  A
SoftwareDeployment 'binds' a SoftwareConfig to a Server.  Without that
'binding', the template won't work as expected.

I'll follow up on this checking if Heat should validate that the
'config' property of a SoftwareDeployment is set.

Regards,
   Qiming
The discussion is ongoing in https://review.openstack.org/#/c/144865/ as 
to whether the config property should be made mandatory, and whatever 
the outcome is will become the fix for 
https://bugs.launchpad.net/heat/+bug/1407387




On Wed, Feb 04, 2015 at 07:23:10AM +, Zhou, Zhenzan wrote:

Hi, Experts

I am writing a template to start a multi node devstack cloud inside overcloud. 
Heat Engine got exception after started the first controller VM. I am using the 
latest Heat code.
Here is the stack trace:

Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
2015-02-04 15:10:21.733 138441 ERROR oslo_messaging.rpc.dispatcher 
[req-f8fbb6d4-924d-4c0c-8b60-16ed30358765 ] Exception during message handling: 
object of type 'NoneType' has no len()
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher Traceback 
(most recent call last):
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 2015-02-04 
15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/venvs/heat/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
 line 142, in _dispatch_and_reply
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher 
executor_callback))
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 2015-02-04 
15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/venvs/heat/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
 line 186, in _dispatch
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher 
executor_callback)
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 2015-02-04 
15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/venvs/heat/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
 line 130, in _do_dispatch
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher result = 
func(ctxt, **new_args)
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 2015-02-04 
15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/venvs/heat/local/lib/python2.7/site-packages/osprofiler/profiler.py",
 line 105, in wrapper
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher return 
f(*args, **kwargs)
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 2015-02-04 
15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/venvs/heat/local/lib/python2.7/site-packages/heat/engine/service.py",
 line 74, in wrapped
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher return 
func(self, ctx, *args, **kwargs)
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 2015-02-04 
15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/venvs/heat/local/lib/python2.7/site-packages/heat/engine/service.py",
 line 1386, in show_software_config
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher sc = 
db_api.software_config_get(cnxt, config_id)
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 2015-02-04 
15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/venvs/heat/local/lib/python2.7/site-packages/heat/db/api.py", line 
258, in software_config_get
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher return 
IMPL.software_config_get(context, config_id)
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 2015-02-04 
15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher   File 
"/opt/stack/venvs/heat/local/lib/python2.7/site-packages/heat/db/sqlalchemy/api.py",
 line 717, in software_config_get
Feb  4 15:10:21 minicloud-allinone-controller0-i7bnc6baumzl heat-engine: 
2015-02-04 15:10:21.733 138441 TRACE oslo_messaging.rpc.dispatcher result = 
model_query(context, models.SoftwareConfig).get(config_id)
Feb  4 15:10:21 minicloud-allinone-

Re: [openstack-dev] [nova] FFE request for passing capabilities in the flavor to ironic

[Nisha Agarwal]

Hi wanyen and Nova team,

I support wanyen for this FFE. The code changes are very small and harmless
to Nova. They just provide a way to ironic to comsume inputs given at
flavor.

Regards
Nisha

On Sat, Feb 7, 2015 at 12:33 AM, Hsu, Wan-Yen  wrote:

>  Hi,
>
>
>
>I would like to ask for a feature freeze exception for passing
> capabilities in the flavor to Ironic:
>
>
>
>
> https://blueprints.launchpad.net/nova/+spec/pass-flavor-capabilities-to-ironic-virt-driver
>
> Addressed by: https://review.openstack.org/136104
> Pass on the capabilities in the flavor to the ironic
>
>Addressed by: https://review.openstack.org/141012
>Pass on the capabilities to instance_info
>
> several Ironic Kilo features including secure boot, trusted boot, and
> local boot support with partition image are depending on this feature.  It
> also has impact on Ironic vendor driver’s hardware property introspection
> feature.
>
>
>
>  Code changes to support this spec in Nova ironic virt driver is very
> small-
>
> only 31 lines of code (including comments) in
> nova/virt/ironic/patcher.py,  and 22 lines of code in test_patcher.py.
>
>
>
>Please consider approving this FFE.  Thanks!
>
>
>
> Regards,
>
> wanyen
>
>
>
> __
> 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
>
>


-- 
The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.
__
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

Re: [openstack-dev] [nova][neutron] Passthrough of PF's from SR-IOV capable devices.

[Irena Berezovsky]

On Thu, Feb 5, 2015 at 9:01 PM, Steve Gordon  wrote:

> - Original Message -
> > From: "Przemyslaw Czesnowicz" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> >
> > Hi
> >
> > > 1) If the device is a "normal" PCI device, but is a network card, am I
> > > still able to
> > > take advantage of the advanced syntax added circa Juno to define the
> > > relationship between that card and a given physical network so that the
> > > scheduler can place accordingly (and does this still use the ML2 mech
> > > drvier for
> > > SR-IOV even though it's a "normal" device.
> >
> > Actually libvirt won't allow using "normal" PCI devices for network
> > interfaces into VM.
> > Following error is thrown by libvirt 1.2.9.1:
> > libvirtError: unsupported configuration: Interface type hostdev is
> currently
> > supported on SR-IOV Virtual Functions only
> >
> > I don't know why libvirt prohibits that. But we should prohibit that on
> > Openstack side as well.
>
> This is true for hostdev"> style configuration, "normal" PCI devices are
> still valid in Libvirt for passthrough using  though. The former
> having been specifically created for handling passthrough of VFs, the
> latter being the more generic passthrough functionality and what was used
> with the original PCI passthrough functionality introduced circa Havana.
>
> I guess what I'm really asking in this particular question is what is the
> intersection of these two implementations - if any, as on face value it
> seems that to passthrough a physical PCI device I must use the older syntax
> and thus can't have the scheduler be aware of its external network
> connectivity.
>
Support for "normal" PCI device passthrough for networking in SR-IOV like
way will require new VIF Driver support for hostdev style device guest XML
being created and some call invocation to set MAC address and VLAN tag.

>
> > > 2) There is no functional reason from a Libvirt/Qemu perspective that I
> > > couldn't
> > > pass through a PF to a guest, and some users have expressed surprise
> to me
> > > when they have run into this check in the Nova driver. I assume in the
> > > initial
> > > implementation this was prevented to avoid a whole heap of fun
> additional
> > > logic
> > > that is required if this is allowed (e.g. check that no VFs from the PF
> > > being
> > > requested are already in use, remove all the associated VFs from the
> pool
> > > when
> > > assigning the PF, who gets allowed to use PFs versus VFs etc.). Am I
> > > correct here
> > > or is there another reason that this would be undesirable to allow in
> > > future -
> > > assuming such checks can also be designed - that I am missing?
> > >
> > I think that is correct. But even if the additional logic was
> implemented  it
> > wouldn't work because of how libvirt behaves currently.
>
> Again though, in the code we have a distinction between a physical device
> (as I was asking about in Q1) and a physical function (as I am asking about
> in Q2) and similarly whether libvirt allows or not depends on how you
> configure in the guest XML. Though I wouldn't be surprised on the PF case
> if it is in fact not allowed in Libvirt (even with ) it is again
> important to consider this distinctly separate from passing through the
> physical device case which we DO allow currently in the code I'm asking
> about.
>
I think what you suggest is not difficult to support, but current (since
Juno) PCI device passthrough  for networking is all about SR-IOV PCI device
passthrough. As I mentioned, to support  "normal" PCI device will require
libvirt VIF Driver adjustment. I think its possible to make this work with
existing neutron ML2 SRIOV Mechanism Driver.

>
> -Steve
>
> __
> 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
>
__
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