[openstack-dev] [heat-api] Proposed heat watch/monitoring architectural changes
eglynn at redhat.com
Mon Sep 24 14:29:07 UTC 2012
> > Eoghan Glynn wrote:
> > This proposed separation is much better than deeply embedding
> > the CloudWatch API implementation within Heat.
> > However, since metrics collection & alarming have much wider
> > applicability than their use within orchestration, would it
> > make sense to go one step further and hive off the CW/CWA-
> > related logic into a completely separate infrastructure that
> > could be independently deployed and be developed in parallel
> > with the Heat project?
> > Cheers,
> > Eoghan
> Yes, looking at the new architecture diagram I thought the same
> My current focus is on creating a better cloudwatch implementation
> for heat, but also decoupling things such that it can either be
> contributed to another project (e.g ceilometer has been previously
> discussed), or used independently.
> I guess the question is how much effort is involved in creating a new
> project (perhaps a heat sub-project like heat-jeos?) in terms of our
> existing infrastructure and packaging etc.
Yes, there's definitely a trade-off there. One advantage of a complete
greenfield would be that it may attract those in the community with
a specific interest in monitoring, but who may not also be interested
in orchestration. While a carefully structured sub-project could be
hived off at a later date, it may continue to be perceived as being
closely associated with the mother project.
(On the other hand, a close association with an existing active project
with a solid track-record is not necessarily a bad thing).
> We can discuss this within the team and decide if it makes sense to
> do the split now or later when the implementation is more complete,
> but I agree it is probably something we want to work towards.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev