Open Stack

Hi folks,

>From lbaas design session I have an impression that we need to have a kind
of merge of existing API and new proposed API.
E.g. the blueprint implementation should not be brand new API and DB
backend.
So I'd say from implementation perspective we may want to minimize amount
of changes for the patch that will bring existing model to a new design.
Such things as relationships M:N instead of 1:N are usually complicate
things a lot, so I'd probably consider to implement them in following
patches.
Changing 1:N to 1:1 (pools - healthmons) falls into another category: we
need to deprecate this rather than remove at once.
Same applies for status/status_description: we need to deprecate those.

Thanks,
Eugene.



On Wed, May 28, 2014 at 7:36 AM, Doug Wiegley <dougw at a10networks.com> wrote:

>  Hi Stephen,
>
>  > Doug:  What do you think of the idea of having both IPv4 and IPv6
> attributes on a 'load balancer' object? One doesn't need to have a single
> appliance serving both types of addresses for the listener, but there's
> certainly a chance (albeit small) to hit an async scenario if they're not.
>
>  I made the same suggestion in the bp review , so I have no issue with
> it.  :-)
>
>  I can think of at least one backend that pairs ip:port in their listener
> object, so the driver for that can implement the v4/v6 model natively with
> no issue (but not a true N:N).  For the ones that don’t, at least the race
> condition outlined earlier is limited to two objects, which is ok if the
> use case is common enough to warrant it.  I’d still prefer that issue be
> handled as far up the chain as possible, but I’d be ok.
>
>  Doug
>
>
>   From: Stephen Balukoff <sbalukoff at bluebox.net>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Tuesday, May 27, 2014 at 8:42 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in
> object model refactor blueprint
>
>   Hi y'all!
>
>
> On Tue, May 27, 2014 at 12:32 PM, Brandon Logan <
> brandon.logan at rackspace.com> wrote:
>
>> Referencing this blueprint:
>>
>> https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst
>>
>> Anyone who has suggestions to possible issues or can answer some of
>> these questions please respond.
>>
>>
>> 1. LoadBalancer to Listener relationship M:N vs 1:N
>> The main reason we went with the M:N was so IPv6 could use the same
>> listener as IPv4.  However this can be accomplished by the user just
>> creating a second listener and pool with the same configuration.  This
>> will end up being a bad user experience when the listener and pool
>> configuration starts getting complex (adding in TLS, health monitors,
>> SNI, etc). A good reason to not do the M:N is because the logic on might
>> get complex when dealing with status.  I'd like to get people's opinions
>> on this on whether we should do M:N or just 1:N.  Another option, is to
>> just implement 1:N right now and later implement the M:N in another
>> blueprint if it is decided that the user experience suffers greatly.
>>
>> My opinion: I like the idea of leaving it to another blueprint to
>> implement.  However, we would need to watch out for any major
>> architecture changes in the time itis not implemented that could make
>> this more difficult than what it needs to be.
>>
>
>  Is there such a thing as a 'possibly planned but not implemented design'
> to serve as a placeholder when considering other in-parallel blueprints and
> designs which could potentially conflict with the ability to implement an
> anticipated design like this?  (I'm guessing "no." I really wish we had a
> better design tracking tool than blueprint.)
>
>  Anyway, I don't have a problem with implementing 1:N right now. But, I
> do want to point out: The one and only common case I've seen where listener
> re-use actually makes a lot of sense (IPv4 and IPv6 for same listener)
> could be alleviated by adding separate ipv4 and ipv6 attributes to the
> loadbalancer object. I believe this was shot down when people were still
> calling it a VIP for philosophical reasons. Are people more open to this
> idea now that we're calling the object a 'load balancer'?  ;)
>
> Does anyone have any other use cases where listener re-use makes sense?
>
>
>>
>> 2. Pool to Health Monitor relationship 1:N vs 1:1
>> Currently, I believe this is 1:N however it was suggested to deprecate
>> this in favor of 1:1 by Susanne and Kyle agreed.  Are there any
>> objections to channging to 1:1?
>>
>> My opinion: I'm for 1:1 as long as there aren't any major reasons why
>> there needs to be 1:N.
>>
>>
>  Yep, totally on-board with 1:1 for pool and health monitor.
>
>
>> 3. Does the Pool object need a status field now that it is a pure
>> logical object?
>>
>> My opinion: I don't think it needs the status field.  I think the
>> LoadBalancer object may be the only thing that needs a status, other
>> than the pool members for health monitoring.  I might be corrected on
>> this though.
>>
>
>  So, I think it does make sense when using L7 rules. And it's
> specifically like this:
>
>  A pool is 'UP' if at least one non-backup member is 'UP' and 'DOWN'
> otherwise. This can be an important monitoring point if, for example,
> operations wants to be informed if the 'api pool' is down while the 'web
> frontend' pool is still up, in some meaningful way (ie. other than having
> to sort through a potential barrage of member down notifications to see
> wether any members of a given pool are still up.) Also, given that member
> status might be more than just 'UP' and 'DOWN' (eg. "PROVISIONING" or
> "DRAINING" might also be valid status types for certain kinds of
> back-ends.) It's harder for an operator to know whether a given pool is
> 'UP' or 'DOWN' without some kind of indication.
>
>  Also note that the larger the pool, the less meaningful individual
> members' statuses are: If you've got 1000 servers in a pool, it's probably
> OK if 3-4 of them are 'down' at any given time.
>
>  Having said this, if someone asks for the status of a pool, I'd be OK if
> the response was simply an array of statuses of each member in the pool,
> plus one 'summary' status (ie. as described above) and it's left to the
> user to do with that data whatever makes sense for their application. This
> would allow one to see, for example, that a pool with no members is by
> definition 'DOWN'.
>
>  Are we going to allow a pool to be set administratively down? (ex. for
> maintenance on one pool of servers powering a listener, while other pools
> remain online and available.) In this case, having a response that says the
> pool is 'ADMIN_DOWN' probably also makes sense.
>
> Doug:  What do you think of the idea of having both IPv4 and IPv6
> attributes on a 'load balancer' object? One doesn't need to have a single
> appliance serving both types of addresses for the listener, but there's
> certainly a chance (albeit small) to hit an async scenario if they're not.
>
>  Vijay:  I think the plan here was to come up with an use an entirely
> different DB schema than the legacy Neutron LBaaS, and then retro-fit
> backward compatibility with the old user API once the new LBaaS service is
> functional. I don't think anyone here is suggesting we try to make the old
> schema work for the new API.
>
>  Stephen
>
>  --
> 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/20140528/1e2d68bd/attachment.html>