[openstack-dev] [Neutron][Flavors] Flavor framework implementation questions

Eugene Nikanorov enikanorov at mirantis.com
Wed May 28 21:48:31 UTC 2014


Hi,

I have two questions that previously were briefly discussed. Both of them
still cause discussions within advanced services community, so I'd like to
make final clarification in this email thread.

1. Usage of "Service Type Framework"
I think right now there is a consensus that letting user to choose a vendor
is not what neutron should do. To be more specific, having public
'provider' attribute on a resource may create certain problems
for operators because it binds resource and implementation too tightly that
it can't be maintained without changing user configuration.
The question that was discussed is if it's ok to remove this public
attribute and still use the rest of framework?
I think the answer is yes: the binding between resource and implementing
driver is ok if it's read-only and visible only to admin. This still serves
as hint for dispatching requests to driver and also may help operator to
troubleshoot issues.
I'd like to hear other opinions on this because there are patches for vpn
and fwaas that use STF with the difference described above.

2. Choosing implementation and backend
This topic was briefly touched at design session dedicated to flavors.

Current proposal that was discussed on advanced services meetings was to
employ 2-step scheduling as described in the following sample code:
https://review.openstack.org/#/c/83055/7/neutron/tests/unit/test_flavors.pyline
38-56

In my opinion the proposed way has the following benefits:
- it delegates actual backend choosing to a driver.
This way different vendors may not be required to agree on how to bind
resource to a backend or any kind of other common implementation stuff that
usually leads to lots of discussions.
- allows different configurable vendor-specific algorithms to be used when
binding resource to a backend
- some drivers don't have notion of a backend because external entities
manage backends for them

Another proposal is to have single-step scheduling where each driver
exposes the list of backends
and then scheduling just chooses the backend based on capabilities in the
flavor.

I'd like to better understand the benefits of the second approach (this is
all implementation so from user standpoint it doesn't make difference)

So please add your opinions on those questions.

My suggestion is also to have a short 30 min meeting sometime this or next
week to finalize those questions. There are several patches and blueprints
that depend on them.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140529/bdaad042/attachment.html>


More information about the OpenStack-dev mailing list