Open Stack

On Thu, Sep 27, 2018 at 11:45 PM Zane Bitter <zbitter at redhat.com> wrote:

> On 26/09/18 10:27 PM, Qiming Teng wrote:<snip>
>
 <snip>

> Heat still has a *lot* of users running very important stuff on Heat
> scaling group code which, as you know, is burdened by a lot of technical
> debt.
>
> Though I agree that a common library that can be used by both projects
would be really good, I still don't understand what user issues (though the
resource implementations are not the best, they actually work) we're trying
to address here.

As far as duplicated effort is concerned (that's the only justification I
could get from the etherpad), possibly senlin duplicated some stuff
expecting to replace heat implementation in time. Also, we've not made any
feature additions to heat group resources since long time (expecting senlin
to do it instead) and I've not seen any major bugs reported by users. May
be we're talking about duplicated effort in the "future", now that we have
changed plans for heat ASG?;)

>> What will be great if we can build common library cross projects, and use
> >> that common library in both projects, make sure we have all improvement
> >> implemented in that library, finally to use Senlin from that from that
> >> library call in Heat autoscaling group. And in long-term, we gonna let
> all
>
> <snip>

>
> +1 - to expand on Rico's example, we have at least 3 completely separate
> implementations of batching, each supporting different actions:
>
> Heat AutoscalingGroup: updates only
> Heat ResourceGroup: create or update
> Senlin Batch Policy: updates only
>
> and users are asking for batch delete as well.
>

I've seen this request a few times. But, what I wonder is "why a user would
want to do a delete in a controlled batched manner"? The only
justifications provided is that "they want to throttle requests to other
services, as those services are not able to handle large concurrent
requests sent by heat properly". Are we not looking at the wrong place to
fix those issues?

IMHO, a good list of user issues on the mentioned etherpad would really
help justify the effort needed.

This is clearly an area
> where technical debt from duplicate implementations is making it hard to
> deliver value to users.
>
> cheers,
> Zane.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Regards,
Rabi Mishra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180928/225d4581/attachment.html>