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

Stephen Balukoff sbalukoff at bluebox.net
Tue Feb 25 20:28:51 UTC 2014


Hi Ed,

That sounds good to me, actually:  As long as 'cloud admin' API functions
are represented as well as 'simple user workflows', then I'm all for a
unified API that simply exposes more depending on permissions.

Stephen


On Tue, Feb 25, 2014 at 12:15 PM, Ed Hall <edhall at yahoo-inc.com> wrote:

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


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140225/4214bf71/attachment.html>


More information about the OpenStack-dev mailing list