From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Thursday, February 27, 2014 11:12 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion
The point is to be able to share IP address, it really means that two VIPs(as we understand them in current model) need to reside within same backend (technically they need to share neutron port). Aren't we leaking some implementation detail here? I see IP address sharing as user intent, not an implementation detail. Same backend could be not only the only obstacle here. The backend is not exposed anyhow by the API, by the way. When you create root object with flavor - you really can't control to which driver it will be scheduled. So even if there is driver that is somehow (how?) will allow same IP on different backends, user just will not be able to create 2 vips that share IP address. Eugene, is your point that the logical model addresses the capability for IP sharing but that it can't be scheduled correctly? I'm not against introducing a wrapper entity that correlates the different config objects that logically make up one LB config, but I don't think it is needed from the logical object model pov IMO. Yes, it might make the implementation of the object model for some drivers easier, and I'm OK with having it, if it helps. But strictly speaking it is not needed, because a driver doesn't have to choose a backend when the pool is created or when a vip is created, if it doesn't have enough info yet. That is just not so simple. If you create vip and the pool - this or that way it is ready configuration that needs to be deployed, so driver chooses the backend. Then you need to add objects to this configuration, by say, adding a vip with the same IP on different port. I don't understand the issue described here. Currently there is no way you can specify this through the API. You can specify same IP address and another tcp port, but that call will just fail. Correct, as I have described, the current implementation allocates a neutron-port on the first VIP hence the second VIP will fail. This is an implementation detail, we can discuss how to address. In the logical model I have removed the reference to the neutron port and noted this for further discussion. E.g. we'll have subtle limitation in the API instead of consistency. It can wait until a vip/pool are created and attached to each other, then it would have a clearer idea of the backends eligible to host that whole LB configuration. Another driver though, might be able to perform the configuration on its "backend" straight-away on each API call, and still be able to comply with the object model. API will not let user to control drivers, that's one of the reasons why it's not possible from design standpoint. I do not see how this relates to controlling drivers. It is the driver implementation, the user should not need to control it. Youcef, can we chat over IRC? I think we could clarify lot more than over ML. Thanks, Eugene. Youcef On Thu, Feb 27, 2014 at 5:20 AM, Youcef Laribi <youcef.lar...@citrix.com<mailto:youcef.lar...@citrix.com>> wrote: Hi Eugene, 1) In order to allow real multiple 'vips' per pool feature, we need the listener concept. It's not just a different tcp port, but also a protocol, so session persistence and all ssl-related parameters should move to listener. Why do we need a new 'listener' concept? Since as Sam pointed out, we are removing the reference to a pool from the VIP in the current model, isn't this enough by itself to allow the model to support multiple VIPs per pool now? lb-pool-create .... -->$POOL-1 lb-vip-create .....$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1... --> $VIP-1 lb-vip-create .....$VIP_ADDRESS,$TCP_PORT, default_pool=$POOL-1... --> $VIP-2 Youcef From: Eugene Nikanorov [mailto:enikano...@mirantis.com<mailto:enikano...@mirantis.com>] Sent: Wednesday, February 26, 2014 1:26 PM To: Samuel Bercovici Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion Hi Sam, I've looked over the document, couple of notes: 1) In order to allow real multiple 'vips' per pool feature, we need the listener concept. It's not just a different tcp port, but also a protocol, so session persistence and all ssl-related parameters should move to listener. 2) ProviderResourceAssociation - remains on the instance object (our instance object is VIP) as a relation attribute. Though it is removed from public API, so it could not be specified on creation. Remember provider is needed for REST call dispatching. The value of provider attribute (e.g. ProviderResourceAssociation) is result of scheduling. 3) As we discussed before, pool->vip relation will be removed, but pool reuse by different vips (e.g. different backends) will be forbidden for implementation simplicity, because this is definitely not a priority right now. I think it's a fair limitation that can be removed later. On workflows: WFs #2 and #3 are problematic. First off, sharing the same IP is not possible for other vip for the following reason: vip is created (with new model) with flavor (or provider) and scheduled to a provider (and then to a particular backend), doing so for 2 vips makes address reuse impossible if we want to maintain logical API, or otherwise we would need to expose implementation details that will allow us to connect two vips to the same backend. On the open discussion questions: I think most of them are resolved by following existing API expectations about status fields, etc. Main thing that allows to go with existing API expectations is the notion of 'root object'. Root object is the object which status and admin_state show real operability of the configuration. While from implementation perspective it is a mounting point between logical config and the backend. The real challenge of model #3 is ability to share pools between different VIPs, e.g. between different flavors/providers/backends. User may be unaware of it, but it requires really complex logic to handle statistics, healthchecks, etc. I think while me may leave this ability at object model and API level, we will limit it, as I said previously. Thanks, Eugene. On Wed, Feb 26, 2014 at 9:06 PM, Samuel Bercovici <samu...@radware.com<mailto:samu...@radware.com>> wrote: Hi, I have added to the wiki page: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#1.1_Turning_existing_model_to_logical_model that points to a document that includes the current model + L7 + SSL. Please review. Regards, -Sam. From: Samuel Bercovici Sent: Monday, February 24, 2014 7:36 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Samuel Bercovici Subject: RE: [openstack-dev] [Neutron][LBaaS] Object Model discussion Hi, I also agree that the model should be pure logical. I think that the existing model is almost correct but the pool should be made pure logical. This means that the vip <---->pool relationships needs also to become any to any. Eugene, has rightfully pointed that the current "state" management will not handle such relationship well. To me this means that the "state" management is broken and not the model. I will propose an update to the state management in the next few days. Regards, -Sam. From: Mark McClain [mailto:mmccl...@yahoo-inc.com] Sent: Monday, February 24, 2014 6:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion On Feb 21, 2014, at 1:29 PM, Jay Pipes <jaypi...@gmail.com<mailto:jaypi...@gmail.com>> wrote: I disagree on this point. I believe that the more implementation details bleed into the API, the harder the API is to evolve and improve, and the less flexible the API becomes. I'd personally love to see the next version of the LBaaS API be a complete breakaway from any implementation specifics and refocus itself to be a control plane API that is written from the perspective of the *user* of a load balancing service, not the perspective of developers of load balancer products. I agree with Jay. We the API needs to be user centric and free of implementation details. One of my concerns I've voiced in some of the IRC discussions is that too many implementation details are exposed to the user. mark _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
