Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
On Mon, May 19, 2014 at 9:28 PM, Brandon Logan brandon.lo...@rackspace.com wrote: In the API meeting at the summit, Mark McClain mentioned that the existing API should be supported, but deprecated so as not to interrupt those using the existing API. To me, that sounds like the object model can change but there needs to be some kind of adapter/translation layer that modifies any existing current API calls to the new object model. So currently there is this blueprint spec that Eugene submitted: https://review.openstack.org/#/c/89903/3/specs/juno/lbaas-api-and-objmodel-improvement.rst That is implementing the object model with VIP as root object. I suppose this needs to be changed to have the changed we agreed on at the summit. Also, this blueprint should also cover the layer in which to the existing API calls get mapped to this object model. My question is to anyone who knows for certain: should this blueprint just be changed to reflect the new object model agreed on at the summit or should a new blueprint spec be created? If it should just be changed should it wait until Eugene gets back from vacation since he's the one who created this blueprint spec? If you think it makes sense to change this existing document, I would say we should update Eugene's spec mentioned above to reflect what was agreed upon at the summit. I know Eugene is on vacation this week, so in this case it may be ok for you to push a new revision of his specification while he's out, updating it to reflect the object model changes. This way we can make some quick progress on this front. We won't approve this until he gets back and has a chance to review it. Let me know if you need help in pulling this spec down and pushing a new version. Thanks, Kyle After that, then the API change blueprint spec should be created that adds the /loadbalancers resource and other changes. If anyone else can add anything please do. If I said anything wrong please correct me, and if anyone can answer my question above please do. Thanks, Brandon Logan On Mon, 2014-05-19 at 17:06 -0400, Susanne Balle wrote: Great summit!! fantastic to meeting you all in person. We now have agreement on the Object model. How do we turn that into blueprints and also how do we start making progress on the rest of the items we agree upon at the summit? Susanne On Fri, May 16, 2014 at 2:07 AM, Brandon Logan brandon.lo...@rackspace.com wrote: Yeah that’s a good point. Thanks! From: Eugene Nikanorov enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 10:38 PM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Brandon, It's allowed right now just per API. It's up to a backend to decide the status of a node in case some monitors find it dead. Thanks, Eugene. On Fri, May 16, 2014 at 4:41 AM, Brandon Logan brandon.lo...@rackspace.com wrote: I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 9:55 AM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential point since you brought healthmon and pool. There will be an additional entity called ‘PoolMonitorAssociation’ which results in a many to many relationship between pool and monitors. Right? Now, the model is indicating
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Hi folks, Agree with Kyle, you may go ahead and update the spec on review to reflect the design discussed at the summit. Thanks, Eugene. On Tue, May 20, 2014 at 6:07 PM, Kyle Mestery mest...@noironetworks.comwrote: On Mon, May 19, 2014 at 9:28 PM, Brandon Logan brandon.lo...@rackspace.com wrote: In the API meeting at the summit, Mark McClain mentioned that the existing API should be supported, but deprecated so as not to interrupt those using the existing API. To me, that sounds like the object model can change but there needs to be some kind of adapter/translation layer that modifies any existing current API calls to the new object model. So currently there is this blueprint spec that Eugene submitted: https://review.openstack.org/#/c/89903/3/specs/juno/lbaas-api-and-objmodel-improvement.rst That is implementing the object model with VIP as root object. I suppose this needs to be changed to have the changed we agreed on at the summit. Also, this blueprint should also cover the layer in which to the existing API calls get mapped to this object model. My question is to anyone who knows for certain: should this blueprint just be changed to reflect the new object model agreed on at the summit or should a new blueprint spec be created? If it should just be changed should it wait until Eugene gets back from vacation since he's the one who created this blueprint spec? If you think it makes sense to change this existing document, I would say we should update Eugene's spec mentioned above to reflect what was agreed upon at the summit. I know Eugene is on vacation this week, so in this case it may be ok for you to push a new revision of his specification while he's out, updating it to reflect the object model changes. This way we can make some quick progress on this front. We won't approve this until he gets back and has a chance to review it. Let me know if you need help in pulling this spec down and pushing a new version. Thanks, Kyle After that, then the API change blueprint spec should be created that adds the /loadbalancers resource and other changes. If anyone else can add anything please do. If I said anything wrong please correct me, and if anyone can answer my question above please do. Thanks, Brandon Logan On Mon, 2014-05-19 at 17:06 -0400, Susanne Balle wrote: Great summit!! fantastic to meeting you all in person. We now have agreement on the Object model. How do we turn that into blueprints and also how do we start making progress on the rest of the items we agree upon at the summit? Susanne On Fri, May 16, 2014 at 2:07 AM, Brandon Logan brandon.lo...@rackspace.com wrote: Yeah that’s a good point. Thanks! From: Eugene Nikanorov enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 10:38 PM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Brandon, It's allowed right now just per API. It's up to a backend to decide the status of a node in case some monitors find it dead. Thanks, Eugene. On Fri, May 16, 2014 at 4:41 AM, Brandon Logan brandon.lo...@rackspace.com wrote: I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 9:55 AM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential point since you brought
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Thanks Kyle and Eugene. I can do this if no one else wants to. If someone really wants to do this then let me know and I’ll gladly give it up. Just let me know soon. I just want to get this done ASAP. Thanks, Brandon From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, May 20, 2014 at 9:35 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Hi folks, Agree with Kyle, you may go ahead and update the spec on review to reflect the design discussed at the summit. Thanks, Eugene. On Tue, May 20, 2014 at 6:07 PM, Kyle Mestery mest...@noironetworks.commailto:mest...@noironetworks.com wrote: On Mon, May 19, 2014 at 9:28 PM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: In the API meeting at the summit, Mark McClain mentioned that the existing API should be supported, but deprecated so as not to interrupt those using the existing API. To me, that sounds like the object model can change but there needs to be some kind of adapter/translation layer that modifies any existing current API calls to the new object model. So currently there is this blueprint spec that Eugene submitted: https://review.openstack.org/#/c/89903/3/specs/juno/lbaas-api-and-objmodel-improvement.rst That is implementing the object model with VIP as root object. I suppose this needs to be changed to have the changed we agreed on at the summit. Also, this blueprint should also cover the layer in which to the existing API calls get mapped to this object model. My question is to anyone who knows for certain: should this blueprint just be changed to reflect the new object model agreed on at the summit or should a new blueprint spec be created? If it should just be changed should it wait until Eugene gets back from vacation since he's the one who created this blueprint spec? If you think it makes sense to change this existing document, I would say we should update Eugene's spec mentioned above to reflect what was agreed upon at the summit. I know Eugene is on vacation this week, so in this case it may be ok for you to push a new revision of his specification while he's out, updating it to reflect the object model changes. This way we can make some quick progress on this front. We won't approve this until he gets back and has a chance to review it. Let me know if you need help in pulling this spec down and pushing a new version. Thanks, Kyle After that, then the API change blueprint spec should be created that adds the /loadbalancers resource and other changes. If anyone else can add anything please do. If I said anything wrong please correct me, and if anyone can answer my question above please do. Thanks, Brandon Logan On Mon, 2014-05-19 at 17:06 -0400, Susanne Balle wrote: Great summit!! fantastic to meeting you all in person. We now have agreement on the Object model. How do we turn that into blueprints and also how do we start making progress on the rest of the items we agree upon at the summit? Susanne On Fri, May 16, 2014 at 2:07 AM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: Yeah that’s a good point. Thanks! From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 10:38 PM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Brandon, It's allowed right now just per API. It's up to a backend to decide the status of a node in case some monitors find it dead. Thanks, Eugene. On Fri, May 16, 2014 at 4:41 AM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Great summit!! fantastic to meeting you all in person. We now have agreement on the Object model. How do we turn that into blueprints and also how do we start making progress on the rest of the items we agree upon at the summit? Susanne On Fri, May 16, 2014 at 2:07 AM, Brandon Logan brandon.lo...@rackspace.comwrote: Yeah that’s a good point. Thanks! From: Eugene Nikanorov enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 10:38 PM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Brandon, It's allowed right now just per API. It's up to a backend to decide the status of a node in case some monitors find it dead. Thanks, Eugene. On Fri, May 16, 2014 at 4:41 AM, Brandon Logan brandon.lo...@rackspace.com wrote: I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 9:55 AM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential point since you brought healthmon and pool. There will be an additional entity called ‘PoolMonitorAssociation’ which results in a many to many relationship between pool and monitors. Right? Now, the model is indicating a pool can have only one monitor. So a minor correction is required to indicate the many to many relationship via PoolMonitorAssociation. Thanks, Vijay V. *From:* Eugene Nikanorov [mailto:enikano...@mirantis.com] *Sent:* Thursday, May 15, 2014 7:36 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Hi Vijay, When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id listener_id, which creates this object. And also, there would be an API that will be used to list the listeners of a LoadBalancer. Right? Right, that's the same as health monitors and pools work right now: there are separate REST action to associate healthmon to a pool Thanks, Eugene. ___ OpenStack-dev mailing list 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 ___ OpenStack-dev mailing list 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
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Thanks Susanne, and was great meeting many of you. Actually I was trying to find an updated version of the object model that was presented at the summit but couldn’t find it. Is there a link online? Youcef From: Susanne Balle [mailto:sleipnir...@gmail.com] Sent: Monday, May 19, 2014 2:07 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Great summit!! fantastic to meeting you all in person. We now have agreement on the Object model. How do we turn that into blueprints and also how do we start making progress on the rest of the items we agree upon at the summit? Susanne On Fri, May 16, 2014 at 2:07 AM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: Yeah that’s a good point. Thanks! From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 10:38 PM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Brandon, It's allowed right now just per API. It's up to a backend to decide the status of a node in case some monitors find it dead. Thanks, Eugene. On Fri, May 16, 2014 at 4:41 AM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 9:55 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential point since you brought healthmon and pool. There will be an additional entity called ‘PoolMonitorAssociation’ which results in a many to many relationship between pool and monitors. Right? Now, the model is indicating a pool can have only one monitor. So a minor correction is required to indicate the many to many relationship via PoolMonitorAssociation. Thanks, Vijay V. From: Eugene Nikanorov [mailto:enikano...@mirantis.commailto:enikano...@mirantis.com] Sent: Thursday, May 15, 2014 7:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Hi Vijay, When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id listener_id, which creates this object. And also, there would be an API that will be used to list the listeners of a LoadBalancer. Right? Right, that's the same as health monitors and pools work right now: there are separate REST action to associate healthmon to a pool Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Another question for the group: Would it be helpful to go ahead and update the API google doc we've also been using in discussing API / object model changes? (Also, I'd eventually like to see this become part of the standard documentation, so pointers on how to get started making that happen would be appreciated!) Thanks, Stephen On Mon, May 19, 2014 at 4:45 PM, Stephen Balukoff sbaluk...@bluebox.netwrote: Hi folks, Ok, I've attached a newly-updated object diagram (and its source) which is hopefully both a little bit clearer than the monstrosity I created for the summit, and also incorporates a couple agreed-upon changes at the summit. Notes about this: - The grayed-out object (LBtoListener and VIPGroupToAntiGroup) are simply there to show the database objects that will be used to express the n:m relationship between VIPs and Listeners, and VIPGroups and VIPAntiGroups. The user API will have no direct access to these join objects. - I've update the TLSCertificate object to reflect that we intend to use barbican to manage TLS certificates. - I've also split out a 'TLS CA Chain' object from the TLS Certificate object since it has much different usage than the TLS Certificate object and after talking with y'all (especially Samuel) I think this is probably clearer. Note that it might be possible to manage the CA chains in barbican as well if they eventually add full certificate management... however I'm not showing this here, as a CA chain is public data, so there's no reason we couldn't safely store this in the Neutron database. (And we probably don't need full certificate management for CA chains.) - There may be a few missing fields (for example, I think status needs to be two fields?) In any case, I think I've captured all the most consequential ones. Also: - We talked briefly about the differences between Samuel's proposed L7 Policies / Rules proposal and my proposal in the Friday LBaaS meeting, however we deferred full discussion of this to the mailing list. What it boils down to is essentially whether people think there will be a need to re-use L7Policies. (L7Policies in both our proposals are a group of L7Rules that get logically ANDed together). Perhaps we should start this discussion in another thread? - We're also not 100% in agreement over how TLS SNI Policies should work. I'm unclear on Samuel's model here, and I think this is something else we deferred to discussion on the mailing list. Oh and! Please keep in mind that I think both Eugene and Samuel were going to be on vacation this week. :) Thanks, Stephen On Mon, May 19, 2014 at 2:22 PM, Youcef Laribi youcef.lar...@citrix.comwrote: Thanks Susanne, and was great meeting many of you. Actually I was trying to find an updated version of the object model that was presented at the summit but couldn’t find it. Is there a link online? Youcef *From:* Susanne Balle [mailto:sleipnir...@gmail.com] *Sent:* Monday, May 19, 2014 2:07 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Great summit!! fantastic to meeting you all in person. We now have agreement on the Object model. How do we turn that into blueprints and also how do we start making progress on the rest of the items we agree upon at the summit? Susanne On Fri, May 16, 2014 at 2:07 AM, Brandon Logan brandon.lo...@rackspace.com wrote: Yeah that’s a good point. Thanks! *From: *Eugene Nikanorov enikano...@mirantis.com *Reply-To: *openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org *Date: *Thursday, May 15, 2014 at 10:38 PM *To: *openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org *Subject: *Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Brandon, It's allowed right now just per API. It's up to a backend to decide the status of a node in case some monitors find it dead. Thanks, Eugene. On Fri, May 16, 2014 at 4:41 AM, Brandon Logan brandon.lo...@rackspace.com wrote: I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan *From: *Eugene Nikanorov enikano...@mirantis.com *Reply-To: *openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org *Date: *Thursday, May 15, 2014 at 9:55 AM *To: *openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org *Subject: *Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Hi Stephen, If it is possible, can you please annotate the fields to distinguish the required ones from the optional ones? Thanks, Praveen On Mon, May 19, 2014 at 4:45 PM, Stephen Balukoff sbaluk...@bluebox.netwrote: Hi folks, Ok, I've attached a newly-updated object diagram (and its source) which is hopefully both a little bit clearer than the monstrosity I created for the summit, and also incorporates a couple agreed-upon changes at the summit. Notes about this: - The grayed-out object (LBtoListener and VIPGroupToAntiGroup) are simply there to show the database objects that will be used to express the n:m relationship between VIPs and Listeners, and VIPGroups and VIPAntiGroups. The user API will have no direct access to these join objects. - I've update the TLSCertificate object to reflect that we intend to use barbican to manage TLS certificates. - I've also split out a 'TLS CA Chain' object from the TLS Certificate object since it has much different usage than the TLS Certificate object and after talking with y'all (especially Samuel) I think this is probably clearer. Note that it might be possible to manage the CA chains in barbican as well if they eventually add full certificate management... however I'm not showing this here, as a CA chain is public data, so there's no reason we couldn't safely store this in the Neutron database. (And we probably don't need full certificate management for CA chains.) - There may be a few missing fields (for example, I think status needs to be two fields?) In any case, I think I've captured all the most consequential ones. Also: - We talked briefly about the differences between Samuel's proposed L7 Policies / Rules proposal and my proposal in the Friday LBaaS meeting, however we deferred full discussion of this to the mailing list. What it boils down to is essentially whether people think there will be a need to re-use L7Policies. (L7Policies in both our proposals are a group of L7Rules that get logically ANDed together). Perhaps we should start this discussion in another thread? - We're also not 100% in agreement over how TLS SNI Policies should work. I'm unclear on Samuel's model here, and I think this is something else we deferred to discussion on the mailing list. Oh and! Please keep in mind that I think both Eugene and Samuel were going to be on vacation this week. :) Thanks, Stephen On Mon, May 19, 2014 at 2:22 PM, Youcef Laribi youcef.lar...@citrix.comwrote: Thanks Susanne, and was great meeting many of you. Actually I was trying to find an updated version of the object model that was presented at the summit but couldn’t find it. Is there a link online? Youcef *From:* Susanne Balle [mailto:sleipnir...@gmail.com] *Sent:* Monday, May 19, 2014 2:07 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Great summit!! fantastic to meeting you all in person. We now have agreement on the Object model. How do we turn that into blueprints and also how do we start making progress on the rest of the items we agree upon at the summit? Susanne On Fri, May 16, 2014 at 2:07 AM, Brandon Logan brandon.lo...@rackspace.com wrote: Yeah that’s a good point. Thanks! *From: *Eugene Nikanorov enikano...@mirantis.com *Reply-To: *openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org *Date: *Thursday, May 15, 2014 at 10:38 PM *To: *openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org *Subject: *Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Brandon, It's allowed right now just per API. It's up to a backend to decide the status of a node in case some monitors find it dead. Thanks, Eugene. On Fri, May 16, 2014 at 4:41 AM, Brandon Logan brandon.lo...@rackspace.com wrote: I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan *From: *Eugene Nikanorov enikano...@mirantis.com *Reply-To: *openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org *Date: *Thursday, May 15, 2014 at 9:55 AM *To: *openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org *Subject: *Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
In the API meeting at the summit, Mark McClain mentioned that the existing API should be supported, but deprecated so as not to interrupt those using the existing API. To me, that sounds like the object model can change but there needs to be some kind of adapter/translation layer that modifies any existing current API calls to the new object model. So currently there is this blueprint spec that Eugene submitted: https://review.openstack.org/#/c/89903/3/specs/juno/lbaas-api-and-objmodel-improvement.rst That is implementing the object model with VIP as root object. I suppose this needs to be changed to have the changed we agreed on at the summit. Also, this blueprint should also cover the layer in which to the existing API calls get mapped to this object model. My question is to anyone who knows for certain: should this blueprint just be changed to reflect the new object model agreed on at the summit or should a new blueprint spec be created? If it should just be changed should it wait until Eugene gets back from vacation since he's the one who created this blueprint spec? After that, then the API change blueprint spec should be created that adds the /loadbalancers resource and other changes. If anyone else can add anything please do. If I said anything wrong please correct me, and if anyone can answer my question above please do. Thanks, Brandon Logan On Mon, 2014-05-19 at 17:06 -0400, Susanne Balle wrote: Great summit!! fantastic to meeting you all in person. We now have agreement on the Object model. How do we turn that into blueprints and also how do we start making progress on the rest of the items we agree upon at the summit? Susanne On Fri, May 16, 2014 at 2:07 AM, Brandon Logan brandon.lo...@rackspace.com wrote: Yeah that’s a good point. Thanks! From: Eugene Nikanorov enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 10:38 PM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Brandon, It's allowed right now just per API. It's up to a backend to decide the status of a node in case some monitors find it dead. Thanks, Eugene. On Fri, May 16, 2014 at 4:41 AM, Brandon Logan brandon.lo...@rackspace.com wrote: I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 9:55 AM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential point since you brought healthmon and pool. There will be an additional entity called ‘PoolMonitorAssociation’ which results in a many to many relationship between pool and monitors. Right? Now, the model is indicating a pool can have only one monitor. So a minor
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Yeah that’s a good point. Thanks! From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 10:38 PM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Brandon, It's allowed right now just per API. It's up to a backend to decide the status of a node in case some monitors find it dead. Thanks, Eugene. On Fri, May 16, 2014 at 4:41 AM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 9:55 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential point since you brought healthmon and pool. There will be an additional entity called ‘PoolMonitorAssociation’ which results in a many to many relationship between pool and monitors. Right? Now, the model is indicating a pool can have only one monitor. So a minor correction is required to indicate the many to many relationship via PoolMonitorAssociation. Thanks, Vijay V. From: Eugene Nikanorov [mailto:enikano...@mirantis.commailto:enikano...@mirantis.com] Sent: Thursday, May 15, 2014 7:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Hi Vijay, When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id listener_id, which creates this object. And also, there would be an API that will be used to list the listeners of a LoadBalancer. Right? Right, that's the same as health monitors and pools work right now: there are separate REST action to associate healthmon to a pool Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Hi Craig, Implementation-specific options are not exposed through the API, or otherwise it would be inconsistent, given that we are moving to a flavor-based approach of specifying service requirements where implementation is completely hidden from the user. Thanks, Eugene. On Thu, May 15, 2014 at 3:24 AM, IWAMOTO Toshihiro iwam...@valinux.co.jpwrote: At Wed, 14 May 2014 10:18:29 -0700, Stephen Balukoff wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] Hi Craig, I'm attaching the latest object model diagram as discussed with the RAX team last night, Samuel and Eugene. Note that we don't necessarily have HP's blessing on this model yet, nor do we have Neutron core developer buy in. But in any case, here it is. Sorry for jumping into a meta-argument, but what the LBaaS community needs to do first is to figure out how to make the neutron community agree on a LBaaS proposal. On the other hand, the neutron community (or the core?) needs to make it clear that what criteria or process is required to approve some LBaaS idea (obj. model, API, whatsoever). I'm sorry to say (again) that not much people have energy to follow and check out small differences in those large pictures of LBaaS object models. -- IWAMOTO Toshihiro ___ OpenStack-dev mailing list 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
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Hi Stephen: * The LBtoListener object is grayed out because it will need to exist in the database (to allow Listeners to be re-used, solving the IPv4 + IPv6 common use case), but should not be directly addressable via the user API. (This is also the reason it's got no tenant_id.) When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id listener_id, which creates this object. And also, there would be an API that will be used to list the listeners of a LoadBalancer. Right? * The vip group and vip anti group stuff is meant to solve the vip colocation / apolocation problem. These are optional objects that don't need to be created unless a user has colocation / apolocation needs. (I'd be happy to run anyone through the logic on how these work, as it's probably not immediately intuitive.) Yes please, could you explain on the ML! Thanks, Vijay V. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Wednesday, May 14, 2014 11:02 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Aah-- and here's a small error correction. :) Please also note: * We're not yet in consensus on the L7 or SSL related objects, but the Loadbalancer, Listener, Pool, and Member should probably not change at this point (unless there are major objections voiced in the very near term). * I've tried to use color coordination to indicate different logical parts that can probably be implemented in different blueprints / by different engineering teams. * The LBtoListener object is grayed out because it will need to exist in the database (to allow Listeners to be re-used, solving the IPv4 + IPv6 common use case), but should not be directly addressable via the user API. (This is also the reason it's got no tenant_id.) * The vip group and vip anti group stuff is meant to solve the vip colocation / apolocation problem. These are optional objects that don't need to be created unless a user has colocation / apolocation needs. (I'd be happy to run anyone through the logic on how these work, as it's probably not immediately intuitive.) Stephen On Wed, May 14, 2014 at 10:22 AM, Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote: Also, apologies for the crappy formatting. I like gv files as they're easily tracked in a text-based revision control system (like git) that depends on useful diffs to do code reviews. But sometimes the layout it chooses is a little dumb. Stephen On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote: Hi Craig, I'm attaching the latest object model diagram as discussed with the RAX team last night, Samuel and Eugene. Note that we don't necessarily have HP's blessing on this model yet, nor do we have Neutron core developer buy in. But in any case, here it is. Also, I think the #openstack-lbaas channel is a great idea! Stephen On Wed, May 14, 2014 at 9:05 AM, Craig Tracey cr...@craigtracey.commailto:cr...@craigtracey.com wrote: Hi all, From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else? On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts? Best, Craig ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807tel:%28800%29613-4305%20x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807tel:%28800%29613-4305%20x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Hi Vijay, When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id listener_id, which creates this object. And also, there would be an API that will be used to list the listeners of a LoadBalancer. Right? Right, that's the same as health monitors and pools work right now: there are separate REST action to associate healthmon to a pool Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
It is pity to see enoumous LBaaS efforts have been largely spinning (in a sense of spinlocks) for a while. At Thu, 15 May 2014 14:31:54 +0400, Eugene Nikanorov wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] Hi Craig, Implementation-specific options are not exposed through the API, or otherwise it would be inconsistent, given that we are moving to a flavor-based approach of specifying service requirements where implementation is completely hidden from the user. There was a lot of arguments against your flavor proposal at the design summit session and at the meeting at the pod area. So, it is not clear if moving to a flavor-based happens in a reasonalbe timeframe. OTOH, the flavor framework is not much more than a bitmap matching of feature vectors. I think something is not going right as we spent good 30mins on this topic at the pod area. We'll be able to continue the same technical level argument at home as we did for the last couple of months. My suggestion is to try to discuss differently here at the summit. -- IWAMOTO Toshihiro ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Hi Iwamoto, I think you may want to talk to Mark MacClain on why we want to move to flavors instead of letting user to chose implementation. Basically the arguments against flavors (flexible mapping) are based on some lack of understanding of cloud operator requirements. Ability to chose provider was the first simplistic step in allowing multivendor support, but it appeared to be not much convenient for cloud operators. And obviously implementation details (especially vendor-specific) should be hidden behind API, that's the goal of all OS services to abstract tenant from that. Thanks, Eugene. On Thu, May 15, 2014 at 6:45 PM, IWAMOTO Toshihiro iwam...@valinux.co.jpwrote: It is pity to see enoumous LBaaS efforts have been largely spinning (in a sense of spinlocks) for a while. At Thu, 15 May 2014 14:31:54 +0400, Eugene Nikanorov wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] Hi Craig, Implementation-specific options are not exposed through the API, or otherwise it would be inconsistent, given that we are moving to a flavor-based approach of specifying service requirements where implementation is completely hidden from the user. There was a lot of arguments against your flavor proposal at the design summit session and at the meeting at the pod area. So, it is not clear if moving to a flavor-based happens in a reasonalbe timeframe. OTOH, the flavor framework is not much more than a bitmap matching of feature vectors. I think something is not going right as we spent good 30mins on this topic at the pod area. We'll be able to continue the same technical level argument at home as we did for the last couple of months. My suggestion is to try to discuss differently here at the summit. -- IWAMOTO Toshihiro ___ OpenStack-dev mailing list 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
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential point since you brought healthmon and pool. There will be an additional entity called ‘PoolMonitorAssociation’ which results in a many to many relationship between pool and monitors. Right? Now, the model is indicating a pool can have only one monitor. So a minor correction is required to indicate the many to many relationship via PoolMonitorAssociation. Thanks, Vijay V. *From:* Eugene Nikanorov [mailto:enikano...@mirantis.com] *Sent:* Thursday, May 15, 2014 7:36 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Hi Vijay, When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id listener_id, which creates this object. And also, there would be an API that will be used to list the listeners of a LoadBalancer. Right? Right, that's the same as health monitors and pools work right now: there are separate REST action to associate healthmon to a pool Thanks, Eugene. ___ OpenStack-dev mailing list 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
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 9:55 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential point since you brought healthmon and pool. There will be an additional entity called ‘PoolMonitorAssociation’ which results in a many to many relationship between pool and monitors. Right? Now, the model is indicating a pool can have only one monitor. So a minor correction is required to indicate the many to many relationship via PoolMonitorAssociation. Thanks, Vijay V. From: Eugene Nikanorov [mailto:enikano...@mirantis.commailto:enikano...@mirantis.com] Sent: Thursday, May 15, 2014 7:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Hi Vijay, When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id listener_id, which creates this object. And also, there would be an API that will be used to list the listeners of a LoadBalancer. Right? Right, that's the same as health monitors and pools work right now: there are separate REST action to associate healthmon to a pool Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Hi, I agree with Logan I am wondering if you can share a use case with multiple health monitors. German From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Thursday, May 15, 2014 5:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There's also ambiguity in the case where one health monitor fails and another doesn't. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 9:55 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential point since you brought healthmon and pool. There will be an additional entity called 'PoolMonitorAssociation' which results in a many to many relationship between pool and monitors. Right? Now, the model is indicating a pool can have only one monitor. So a minor correction is required to indicate the many to many relationship via PoolMonitorAssociation. Thanks, Vijay V. From: Eugene Nikanorov [mailto:enikano...@mirantis.commailto:enikano...@mirantis.com] Sent: Thursday, May 15, 2014 7:36 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Hi Vijay, When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id listener_id, which creates this object. And also, there would be an API that will be used to list the listeners of a LoadBalancer. Right? Right, that's the same as health monitors and pools work right now: there are separate REST action to associate healthmon to a pool Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Brandon, It's allowed right now just per API. It's up to a backend to decide the status of a node in case some monitors find it dead. Thanks, Eugene. On Fri, May 16, 2014 at 4:41 AM, Brandon Logan brandon.lo...@rackspace.comwrote: I have concerns about multiple health monitors on the same pool. Is this always going to be the same type of health monitor? There’s also ambiguity in the case where one health monitor fails and another doesn’t. Is it an AND or OR that determines whether the member is down or not? Thanks, Brandon Logan From: Eugene Nikanorov enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 9:55 AM To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Vijay, Pools-monitors are still many to many, if it's not so on the picture - we'll fix that. I brought this up as an example of how we dealt with m:n via API. Thanks, Eugene. On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Thanks for the clarification. Eugene. A tangential point since you brought healthmon and pool. There will be an additional entity called ‘PoolMonitorAssociation’ which results in a many to many relationship between pool and monitors. Right? Now, the model is indicating a pool can have only one monitor. So a minor correction is required to indicate the many to many relationship via PoolMonitorAssociation. Thanks, Vijay V. *From:* Eugene Nikanorov [mailto:enikano...@mirantis.com] *Sent:* Thursday, May 15, 2014 7:36 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model? Hi Vijay, When you say API is not available, it means this should not be considered like a resource/entity. Correct? But then, there would be API like a bind API, that accepts loadbalancer_id listener_id, which creates this object. And also, there would be an API that will be used to list the listeners of a LoadBalancer. Right? Right, that's the same as health monitors and pools work right now: there are separate REST action to associate healthmon to a pool Thanks, Eugene. ___ OpenStack-dev mailing list 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Also, apologies for the crappy formatting. I like gv files as they're easily tracked in a text-based revision control system (like git) that depends on useful diffs to do code reviews. But sometimes the layout it chooses is a little dumb. Stephen On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff sbaluk...@bluebox.netwrote: Hi Craig, I'm attaching the latest object model diagram as discussed with the RAX team last night, Samuel and Eugene. Note that we don't necessarily have HP's blessing on this model yet, nor do we have Neutron core developer buy in. But in any case, here it is. Also, I think the #openstack-lbaas channel is a great idea! Stephen On Wed, May 14, 2014 at 9:05 AM, Craig Tracey cr...@craigtracey.comwrote: Hi all, From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else? On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts? Best, Craig ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Have you found that #openstack-neutron is too busy for LBaaS discussions? The downside to moving LBaaS discussions to a separate channel from the general neutron channel is that many neutron developers are left out of the discussion. -- Kevin Benton On Wed, May 14, 2014 at 9:05 AM, Craig Tracey cr...@craigtracey.com wrote: Hi all, From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else? On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts? Best, Craig ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Thanks Stephen, One nit and one question - For each of the tables with status fields we will want to have status_description fields as well. This is already a part of the V2 models. - How does this model handle things like implementation-specific options and/or things like additional headers? I'm thinking of some of those very common cases with http/https...X-Forwarded-For, httpclose, etc. Best, Craig On Wed, May 14, 2014 at 1:32 PM, Stephen Balukoff sbaluk...@bluebox.netwrote: Aah-- and here's a small error correction. :) Please also note: * We're not yet in consensus on the L7 or SSL related objects, but the Loadbalancer, Listener, Pool, and Member should probably not change at this point (unless there are major objections voiced in the very near term). * I've tried to use color coordination to indicate different logical parts that can probably be implemented in different blueprints / by different engineering teams. * The LBtoListener object is grayed out because it will need to exist in the database (to allow Listeners to be re-used, solving the IPv4 + IPv6 common use case), but should not be directly addressable via the user API. (This is also the reason it's got no tenant_id.) * The vip group and vip anti group stuff is meant to solve the vip colocation / apolocation problem. These are optional objects that don't need to be created unless a user has colocation / apolocation needs. (I'd be happy to run anyone through the logic on how these work, as it's probably not immediately intuitive.) Stephen On Wed, May 14, 2014 at 10:22 AM, Stephen Balukoff sbaluk...@bluebox.netwrote: Also, apologies for the crappy formatting. I like gv files as they're easily tracked in a text-based revision control system (like git) that depends on useful diffs to do code reviews. But sometimes the layout it chooses is a little dumb. Stephen On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: Hi Craig, I'm attaching the latest object model diagram as discussed with the RAX team last night, Samuel and Eugene. Note that we don't necessarily have HP's blessing on this model yet, nor do we have Neutron core developer buy in. But in any case, here it is. Also, I think the #openstack-lbaas channel is a great idea! Stephen On Wed, May 14, 2014 at 9:05 AM, Craig Tracey cr...@craigtracey.comwrote: Hi all, From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else? On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts? Best, Craig ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list 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
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Hi Craig, I was attempting to avoid haproxy-specific terminology here, but some of those attributes are on the listener (ie. keepalive = 0 would be equivalent to httpclose). Other options (like adding headers) are expressed through the layer-7 functionality. So, we have yet to update the API to correspond with this object diagram, but if you recall the API I linked on the list a couple weeks ago ( https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit?usp=sharing) look in the section on L7 policies and L7 rules. (Note also that we don't yet have group consensus on the specifics of implementing the L7 stuff-- but adding headers would definitely fall in that category, eh.) Stephen On Wed, May 14, 2014 at 3:04 PM, Craig Tracey cr...@craigtracey.com wrote: Thanks Stephen, One nit and one question - For each of the tables with status fields we will want to have status_description fields as well. This is already a part of the V2 models. - How does this model handle things like implementation-specific options and/or things like additional headers? I'm thinking of some of those very common cases with http/https...X-Forwarded-For, httpclose, etc. Best, Craig On Wed, May 14, 2014 at 1:32 PM, Stephen Balukoff sbaluk...@bluebox.netwrote: Aah-- and here's a small error correction. :) Please also note: * We're not yet in consensus on the L7 or SSL related objects, but the Loadbalancer, Listener, Pool, and Member should probably not change at this point (unless there are major objections voiced in the very near term). * I've tried to use color coordination to indicate different logical parts that can probably be implemented in different blueprints / by different engineering teams. * The LBtoListener object is grayed out because it will need to exist in the database (to allow Listeners to be re-used, solving the IPv4 + IPv6 common use case), but should not be directly addressable via the user API. (This is also the reason it's got no tenant_id.) * The vip group and vip anti group stuff is meant to solve the vip colocation / apolocation problem. These are optional objects that don't need to be created unless a user has colocation / apolocation needs. (I'd be happy to run anyone through the logic on how these work, as it's probably not immediately intuitive.) Stephen On Wed, May 14, 2014 at 10:22 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: Also, apologies for the crappy formatting. I like gv files as they're easily tracked in a text-based revision control system (like git) that depends on useful diffs to do code reviews. But sometimes the layout it chooses is a little dumb. Stephen On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: Hi Craig, I'm attaching the latest object model diagram as discussed with the RAX team last night, Samuel and Eugene. Note that we don't necessarily have HP's blessing on this model yet, nor do we have Neutron core developer buy in. But in any case, here it is. Also, I think the #openstack-lbaas channel is a great idea! Stephen On Wed, May 14, 2014 at 9:05 AM, Craig Tracey cr...@craigtracey.comwrote: Hi all, From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else? On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts? Best, Craig ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list 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 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
At Wed, 14 May 2014 10:18:29 -0700, Stephen Balukoff wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] Hi Craig, I'm attaching the latest object model diagram as discussed with the RAX team last night, Samuel and Eugene. Note that we don't necessarily have HP's blessing on this model yet, nor do we have Neutron core developer buy in. But in any case, here it is. Sorry for jumping into a meta-argument, but what the LBaaS community needs to do first is to figure out how to make the neutron community agree on a LBaaS proposal. On the other hand, the neutron community (or the core?) needs to make it clear that what criteria or process is required to approve some LBaaS idea (obj. model, API, whatsoever). I'm sorry to say (again) that not much people have energy to follow and check out small differences in those large pictures of LBaaS object models. -- IWAMOTO Toshihiro ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
