On Thu, Sep 27, 2018 at 11:14 AM Zane Bitter <zbit...@redhat.com> wrote:
> > and we will gradually fade out the existing 'AutoScalingGroup'
> > and related resource types in Heat.
> That's almost impossible to do without breaking existing users.

One approach would be to switch the underlying Heat AutoScalingGroup
implementation to use Senlin and then deprecate the AutoScalingGroup
resource type in favor of the Senlin resource type over several
cycles.  Not saying that this is the definitive solution, but it is
worth discussing as an option since this follows a path other projects
have taken (e.g. nova-volume extraction into cinder).

A prerequisite to this approach would probably require Heat to create
the so-called common library to house the autoscaling code.  Then
Senlin would need to achieve feature parity against this autoscaling
library before the switch could happen.

> Clearly there are _some_ parts that could in principle be shared. (I
> added some comments to the etherpad to clarify what I think Rico was
> referring to.)
> It seems to me that there's value in discussing it together rather than
> just working completely independently, even if the outcome of that
> discussion is that

+1.  The outcome of any discussion will be beneficial not only to the
teams but also the operators and users.


Duc (dtruong)

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to