On Feb 25, 2014, at 10:10 AM, Stephen Balukoff
<sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>> wrote:
On Feb 25, 2014 at 3:39 AM,
enikano...@mirantis.com<mailto:enikano...@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
