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 <edh...@yahoo-inc.com> wrote: > > On Feb 25, 2014, at 10:10 AM, Stephen Balukoff <sbaluk...@bluebox.net> > wrote: > > On Feb 25, 2014 at 3:39 AM, 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 > > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
