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.net>wrote: > 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.com>wrote: > >> 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 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 >> >> > > > -- > 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
