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

Stephen Balukoff sbalukoff at bluebox.net
Tue Feb 25 18:10:33 UTC 2014


Hi Eugene!

Responses inline:

On Tue, Feb 25, 2014 at 3:33 AM, Eugene Nikanorov
<enikanorov at mirantis.com>wrote:
>
> I'm really not sure what Mark McClain on some other folks see as
> implementation details. To me the 'instance' concept is as logical as
> others (vips/pool/etc). But anyway, it looks like majority of those who
> discuss, sees it as redundant concept.
>

Maybe we should have a discussion around what qualifies as a 'logical
concept' or 'logical construct,' and why the 'loadbalancer' concept you've
been championing either does or does not qualify, so we're all (closer to
being) on the same page before we discuss model changes?



> 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.


Thanks,
Stephen



-- 
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/381ea31a/attachment.html>


More information about the OpenStack-dev mailing list