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 th
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
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:
https://wiki
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
col
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
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 wrote:
> So, I don't intend to argue the technical minutia of each design point
Cool, thanks for the explanation and clarification :)
Sent from my really tiny device...
On Sep 12, 2013, at 12:41 AM, "Steven Hardy" 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.
>>
>> Maybe
On Thu, Sep 12, 2013 at 01:07:03AM +, Keith Bray wrote:
> 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
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 au
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 (o
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 t
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
exampl
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 ins
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 inst
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 appro
Excerpts from Joshua Harlow's message of 2013-09-11 01:00:37 -0700:
> +1
>
> The assertions are not just applicable to autoscaling but to software in
> general. I hope we can make autoscaling "just enough" simple to work.
>
> The circular heat<=>trove example is one of those that does worry me a
On 11/09/13 05:51, Adrian Otto wrote:
I have a different point of view. First I will offer some assertions:
It's not clear to me what you actually have an issue with? (Top-posting
is not helping in this respect.)
A-1) We need to keep it simple.
A-1.1) Systems that are hard to compre
On Wed, Sep 11, 2013 at 03:51:02AM +, Adrian Otto wrote:
> 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 b
+1
The assertions are not just applicable to autoscaling but to software in
general. I hope we can make autoscaling "just enough" simple to work.
The circular heat<=>trove example is one of those that does worry me a little.
It feels like something is not structured right if that it is needed (
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
I think Zane's response pretty much covers it, but here's some comments
since you requested my response:
On Thu, Aug 15, 2013 at 05:50:19PM -0500, Christopher Armstrong wrote:
> *Introduction and Requirements*
>
> So there's kind of a perfect storm happening around autoscaling in Heat
> right now
On Fri, Aug 16, 2013 at 1:35 PM, Clint Byrum 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 Heat
> >
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 Heat
> > right now. It's making it really hard to figure out how I shoul
On 16/08/13 00:50, Christopher Armstrong wrote:
*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
differe
On Thu, Aug 15, 2013 at 6:39 PM, Randall Burt wrote:
>
> On Aug 15, 2013, at 6:20 PM, Angus Salkeld 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 service needs on an InstanceGroup, na
On Aug 15, 2013, at 6:20 PM, Angus Salkeld wrote:
> On 15/08/13 17:50 -0500, Christopher Armstrong wrote:
>> *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
On 15/08/13 17:50 -0500, Christopher Armstrong wrote:
*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 d
*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
28 matches
Mail list logo
