Open Stack

On 08/23/2012 02:24 AM, Monty Taylor wrote:
>
>
> On 08/22/2012 06:35 PM, Vishvananda Ishaya wrote:
>>
>> On Aug 22, 2012, at 5:10 PM, Monty Taylor <mordred at inaugust.com> wrote:
>>>
>>> If this lands, then I can apt-get/yum install folsom openstack, then I
>>> can apt-get/yum install the non-landed additional driver that itself is
>>> written against openstack in a fairly seamless manner. That means that
>>> the driver code can live, not as a patch to folsom nova, but as a legit
>>> add-on project. Then - when grizzly comes out and the driver code
>>> _lands_ the config references that would have been deployed to use the
>>> driver via the entrypoint name will not have to change in the config
>>> files, because they'll be using entrypoint names and not python library
>>> path indications.
>>
>> If it doesn't land, it seems like you could still do the above, you would
>> just have to specify the full path into your module in the config option
>> (i.e. compute_driver = some_module.driver.Driver)
>>
>> I understand that entry-points is much nicer, but is there some additional
>> feature besides cleanliness that we are enabling?
>
> Mainly cleanliness. The one difference is that the config wouldn't need
> to change if/when the driver lands upstream - but that's probably not death.

When I was cleaning up the virt drivers, so they are class loading now, 
entry points came up in that discussion, but it was generally agreed 
that was a bigger conceptual change, and should wait until the Grizzly 
design summit.

I think adding more different ways to load drivers at the 11th hour 
isn't a great idea. Virt drivers only need a config file stanza today, 
they don't need to be in the nova tree, so I don't see how this change 
saves substantial operational time.

Loading by entry point explicitly assumes support for out of tree 
drivers (today we have implicity support, because you can, but you 
realize that interface may not be stable, and definitely isn't 
versioned). Which gives some implicit assumptions on the driver API not 
changing in incompatible ways. I don't think those are things we are 
ready to guaruntee.

My vote would be to not have this go in, but have this as part of the 
Grizzly design summit discussion, as this seems part of a much larger 
discussion of in vs. out of tree drivers. And stability of these driver 
points.

	-Sean

-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com