Thanks for your review @demobox, - should domain objects have private or protected constructors and fields? I wrote the domain objects in order to be coherent with the rest of the code. Others domain objects were written in the same way: e.g. Pool has private fileds and constructors as Subnet and HealthMonitorStatus has protected fiields and constructors as AllocationPool. However I agree to use private visibility for all domain objects. - should we have version numbers in method names and constants (LBaaSv1)? Next version of OpenStack (Juno) will improve LBaaS API and object model (https://blueprints.launchpad.net/neutron/+spec/lbaas-api-and-objmodel-improvement). The new LBaaS will expose a new API (v2) but will also be compatible with the legacy API (v1). This means that a cloud-platform built with OpenStack may have (or not) LBaaS extension, may expose LBaaS API v1 (if Havana or IceHouse is used), or may expose LBaaS API v1 and LBaaS API v2 (if Juno is used). My point of view is that jclouds must support both versions to be able to address all cloud-platforms built with OpenStack (Havana, IceHouse, Juno, etc.). I have tried to define "generic" API and domain objects that would be compatible with LBaaS v1 and LBaaS v2. However, even if LBaaS improvements do not change all, it is not so simple: e.g. VIP is replaced by LoadBalancer and Listener; attribute subnet_id moves from Pool to Member, I think that "generic" domain objects would be confused for developpers that use jclouds: e.g. as a developper, do I have to use the Pool.subnetId or the Member.subnetId? Do I have to use VIP or LoadBalancer? Finally, I decided to explicitly seperate LBaaS v1 and LBaaS v2. I think it is more simple for everyone (contributors an users jclouds) to use either LBaaSv1 API or LBaaSv2 API. This implies having NeutronAPI.getLBaaSv1Api and NeutronAPI.getLBaaSv2Api. And I think that it is the role of the jclouds LoadBlancer abstraction to use either LBaaS v1 or v2 depending on the API exposed by the cloud-platform. However, if you have better idea to create a generic API independant of the version, let's discuss about it. - does the "associate health monitor" call require a domain/parameter object too? Yes, LBaaS v1 association method takes a health_monitor as parameter (even if only the id must be specified), not a String. I thought that AssociateBuilder was the more elegant way to map the "associate health monitor" call. However, if you have a better idea, let me know.
--- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-openstack/pull/146#issuecomment-56264339
