Open Stack

Hi, Marios,

STF stands for 'service type framework'. It's the current way to dispatch
calls to different drivers based on 'provider' attribute of the LBaaS
service instance. Firewall and VPN implementations were not upstreamed as
we want to move to Flavor Framework.

I think the flavor framework does allow the operator to expose vendor names
if the operator chooses to.

Thanks,
Gary


On Thu, May 29, 2014 at 5:38 AM, marios at redhat.com <mandreou at redhat.com>wrote:

> 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
> >
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140529/2b419158/attachment.html>