nstack-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
mailto
> >>
> >> Susanne
> >>
> >>
> >> On Fri, May 16, 2014 at 2:07 AM, Brandon Logan
> >> wrote:
> >> Yeah that’s a good point. Thanks!
> >>
> >>
> >> From: Eugene Nikanorov
> >&g
point. Thanks!
>>
>>
>> From: Eugene Nikanorov
>> Reply-To: "openstack-dev@lists.openstack.org"
>>
>>
>> Date: Thursday, May 15, 2014 at 10:38 PM
>>
>> To: "openstack-dev@lists.openstack.org"
gt; To: "openstack-dev@lists.openstack.org"
>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object
> Model?
>
>
>
> Brandon,
>
>
> It's allowed r
d 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 Li
2:22 PM, Youcef Laribi
> 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?
>>
>>
>>
&
: 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
t; 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
10:38 PM
To:
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>"
mailto: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 dec
Nikanorov
> 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" >
>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
&g
5, 2014 at 9:55 AM
To:
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>"
mailto: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
ts.openstack.org<mailto:openstack-dev@lists.openstack.org>"
mailto: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 br
no...@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 avai
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
)
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
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 ]
> [1.1 ]
> Hi Craig,
>
> Implementation-specific options are not exposed through the API, or
> otherwise it would be i
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 wi
[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
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 Wed, 14 May 2014 10:18:29 -0700,
Stephen Balukoff wrote:
>
> [1 ]
> [1.1 ]
> 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 Neutr
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 c
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?
>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
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 Balukof
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
25 matches
Mail list logo
