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 OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev