Open Stack

Hi Praveen,

What you're asking for is actually best explained via an API document,
because some fields become required depending on the value of other fields,
and in some cases if the user doesn't specify the value of a field the
system will fill it in with a reasonable default value. So in the diagram
I've attached, some of this won't be obvious. But in any case, hopefully
this is more illustrative.

Stephen




On Mon, May 19, 2014 at 4:55 PM, Praveen Yalagandula <
ypraveen at avinetworks.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/c524d43d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: api-object-diagram-juno-summit-02.png
Type: image/png
Size: 193733 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140519/c524d43d/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: api-object-diagram-juno-summit-02.dot
Type: application/msword
Size: 13671 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140519/c524d43d/attachment-0001.dot>