Open Stack

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 <sbalukoff at 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.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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140519/7b104146/attachment.html>