On 09/19/2013 04:35 AM, Mike Spreitzer wrote:
I'd like to try to summarize this discussion, if nothing else than to
see whether I have correctly understood it. There is a lot of
consensus, but I haven't heard from Adrian Otto since he wrote some
objections. I'll focus on trying to describe
I'd like to try to summarize this discussion, if nothing else than to see
whether I have correctly understood it. There is a lot of consensus, but
I haven't heard from Adrian Otto since he wrote some objections. I'll
focus on trying to describe the consensus; Adrian's concerns are already
Hi Michael! Thanks for this summary. There were some minor
inaccuracies, but I appreciate you at least trying when I should have
summarized it earlier. I'll give some feedback inline.
First, though, I have recently worked a lot on the wiki page for the
blueprint. It's available here:
radix, thanks. How exactly does the cooldown work?
Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Thu, Sep 12, 2013 at 04:15:39AM +, Joshua Harlow wrote:
Ah, thx keith, that seems to make a little more sense with that context.
Maybe that different instance will be doing other stuff also?
Is that the general heat 'topology' that should/is recommended for trove?
For say
Cool, thanks for the explanation and clarification :)
Sent from my really tiny device...
On Sep 12, 2013, at 12:41 AM, Steven Hardy sha...@redhat.com wrote:
On Thu, Sep 12, 2013 at 04:15:39AM +, Joshua Harlow wrote:
Ah, thx keith, that seems to make a little more sense with that context.
I apologize that this mail will appear at the incorrect position in
the thread, but I somehow got unsubscribed from openstack-dev due to
bounces and didn't receive the original email.
On 9/11/13 03:15 UTC, Adrian Otto adrian.o...@rackspace.com wrote:
So, I don't intend to argue the technical
Steve, I think I see where I introduced some confusion... Below, when
you draw:
User - Trove - (Heat - Nova)
I come at it from a view that the version of Nova that Trove talks to (via
Heat or not) is not necessarily a publicly available Nova endpoint (I.e.
Not in the catalog), although it
Excerpts from Steven Hardy's message of 2013-09-11 05:59:02 -0700:
On Wed, Sep 11, 2013 at 03:51:02AM +, Adrian Otto wrote:
It would be better if we could explain Autoscale like this:
Heat - Autoscale - Nova, etc.
-or-
User - Autoscale - Nova, etc.
This approach allows use
Sure,
I was thinking that since heat would do autoscaling persay, then heat would say
ask trove to make more databases (autoscale policy here) then this would cause
trove to actually callback into heat to make more instances.
Just feels a little weird, idk.
Why didn't heat just make those
Excerpts from Joshua Harlow's message of 2013-09-11 09:11:06 -0700:
Sure,
I was thinking that since heat would do autoscaling persay, then heat would
say ask trove to make more databases (autoscale policy here) then this would
cause trove to actually callback into heat to make more
I just have this idea that if u imagine a factory. Heat is the 'robot' in
an assembly line that ensures the 'assembly line' is done correctly. At
different stages heat makes sure the 'person/thing' putting a part on does
it correctly and heat verifies that the part is in the right place (for
There is context missing here. heat==trove interaction is through the
trove API. trove==heat interaction is a _different_ instance of Heat,
internal to trove's infrastructure setup, potentially provisioning
instances. Public Heat wouldn't be creating instances and then telling
trove to make
Ah, thx keith, that seems to make a little more sense with that context.
Maybe that different instance will be doing other stuff also?
Is that the general heat 'topology' that should/is recommended for trove?
For say autoscaling trove, will trove emit a set of metrics via ceilometer
that heat
I have a different point of view. First I will offer some assertions:
A-1) We need to keep it simple.
A-1.1) Systems that are hard to comprehend are hard to debug, and
that's bad.
A-1.2) Complex systems tend to be much more brittle than simple ones.
A-2) Scale-up operations need
On Fri, Aug 16, 2013 at 1:35 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Zane Bitter's message of 2013-08-16 09:36:23 -0700:
On 16/08/13 00:50, Christopher Armstrong wrote:
*Introduction and Requirements*
So there's kind of a perfect storm happening around autoscaling in
On Thu, Aug 15, 2013 at 6:39 PM, Randall Burt randall.b...@rackspace.comwrote:
On Aug 15, 2013, at 6:20 PM, Angus Salkeld asalk...@redhat.com wrote:
On 15/08/13 17:50 -0500, Christopher Armstrong wrote:
2. There should be a new custom-built API for doing exactly what the
autoscaling
*Introduction and Requirements*
So there's kind of a perfect storm happening around autoscaling in Heat
right now. It's making it really hard to figure out how I should compose
this email. There are a lot of different requirements, a lot of different
cool ideas, and a lot of projects that want to
18 matches
Mail list logo
