Open Stack

On 29/05/14 00:48, Eugene Nikanorov wrote:
> 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.

pardon my ignorance, I don't know what STF is. I missed the summit
discussions ('provider attribute' on resources must have come up there).
My take on the 'specific vendor' issue is that there isn't one, given
the current proposal. From the discussion there I think there is a use
case for a user saying 'i want a firewall from foo_vendor' and as you
said it's just a specialised use-case of the flavor framework.

Furthermore, right now the 'capabilities' for Flavors are very loosely
defined (just key:value tags on Flavor resource). Why can't we just also
define a 'vendor:foo' capability and use it for that purpose. I imagine
I'm oversimplifying somewhere but would that not address the concerns?

marios

> 
> 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.
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>