Open Stack

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.Laribi at 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:sleipnir012 at 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.logan at rackspace.com> wrote:
>
> Yeah that’s a good point.  Thanks!
>
>
>
> *From: *Eugene Nikanorov <enikanorov at mirantis.com>
> *Reply-To: *"openstack-dev at lists.openstack.org" <
> openstack-dev at lists.openstack.org>
>
> *Date: *Thursday, May 15, 2014 at 10:38 PM
>
>
> *To: *"openstack-dev at lists.openstack.org" <
> openstack-dev at 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.logan at 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 <enikanorov at mirantis.com>
> *Reply-To: *"openstack-dev at lists.openstack.org" <
> openstack-dev at lists.openstack.org>
> *Date: *Thursday, May 15, 2014 at 9:55 AM
> *To: *"openstack-dev at lists.openstack.org" <
> openstack-dev at 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.Venkatachalam at 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:enikanorov at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140519/3be6bc2d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: api-object-diagram-juno-summit.png
Type: image/png
Size: 178700 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140519/3be6bc2d/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: api-object-diagram-juno-summit.dot
Type: application/msword
Size: 12585 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140519/3be6bc2d/attachment-0001.dot>