[openstack-dev] [Neutron][LBaaS] Object Model discussion

Ed Hall edhall at yahoo-inc.com
Tue Feb 25 20:15:45 UTC 2014


On Feb 25, 2014, at 10:10 AM, Stephen Balukoff <sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>> wrote:
 On Feb 25, 2014 at 3:39 AM, enikanorov at mirantis.com<mailto:enikanorov at mirantis.com> wrote:
Agree, however actual hardware is beyond logical LBaaS API but could be a part of admin LBaaS API.

Aah yes--  In my opinion, users should almost never be exposed to anything that represents a specific piece of hardware, but cloud administrators must be. The logical constructs the user is exposed to can "come close" to what an actual piece of hardware is, but again, we should be abstract enough that a cloud admin can swap out one piece of hardware for another without affecting the user's workflow, application configuration, (hopefully) availability, etc.

I recall you said previously that the concept of having an 'admin API' had been discussed earlier, but I forget the resolution behind this (if there was one). Maybe we should revisit this discussion?

I tend to think that if we acknowledge the need for an admin API, as well as some of the core features it's going to need, and contrast this with the user API (which I think is mostly what Jay and Mark McClain are rightly concerned about), it'll start to become obvious which features belong where, and what kind of data model will emerge which supports both APIs.

[I’m new to this discussion; my role at my employer has been shifted from an internal to a community focus and I’m madly
attempting to come up to speed. I’m a software developer with an operations focus; I’ve worked with OpenStack since Diablo
as Yahoo’s team lead for network integration.]

Two levels (user and admin) would be the minimum. But our experience over time is that even administrators occasionally
need to be saved from themselves. This suggests that, rather than two or more separate APIs, a single API with multiple
roles is needed. Certain operations and attributes would only be accessible to someone acting in an appropriate role.

This might seem over-elaborate at first glance, but there are other dividends: a single API is more likely to be consistent,
and maintained consistently as it evolves. By taking a role-wise view the hierarchy of concerns is clarified. If you focus on
the data model first you are more likely to produce an arrangement that mirrors the hardware but presents difficulties in
representing and implementing user and operator intent.

Just some general insights/opinions — take for what they’re worth.

                 -Ed

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140225/34ef4355/attachment.html>


More information about the OpenStack-dev mailing list