So I've been assuming that the Octavia object model would be an exact
copy of the neutron lbaas one with additional information for Octavia.
However, after thinking about it I'm not sure this is the right way to
go because the object model in neutron lbaas may change in the future,
and Octavia can't just change it's object model when neutron
lbaas/openstack lbaas changes it's object model.  So if there are any
lessons learned we would like to apply to Octavia's object model now is
the time.

Entity name changes are also on the table if people don't really like
some of the names.  Even adding new entities or removing entities if
there are good reasons isn't out of the question.

Anyway here are a few of my suggestions.  Please add on to this if you
want.  Also, just flat out tell me I'm wrong on some of htese
suggestions if you feel as such.

A few improvements I'd suggest (using the current entity names):
-A real root object that is the only top level object (loadbalancer).
--This would be 1:M relationship with Listeners, but Listeners would
only be children of loadbalancers.
--Pools, Members, and Health Monitors would follow the same workflow.
--Basically no shareable entities.

-Provisioning status only on the root object (loadbalancer).
--PENDING_CREATE, PENDING_UPDATE, PENDING_DELETE, ACTIVE (No need for a
DEFEERRED status! YAY!)
--Also maybe a DELETED status.

-Operating status on other entities
--ACTIVE or ONLINE, DEGRADED, INACTIVE or OFFLINE
--Pools and Members
--Listeners have been mentioned but I'd like to hear more details on
that.

-Adding status_description field in, or something similar.  Would only
eixst on loadbalancer entity if loadbalancer is the only top level
object.

Thanks,
Brandon
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to