What is the rationale for this new feature? Since there is already an
autoscaling group implemented by Heat, what is the added benefit here? And
why is it being done as another heat-native thing rather than as an
independent service (e.g., as outlined in
Clint Byrum cl...@fewbar.com wrote on 10/17/2013 09:16:12 PM:
Excerpts from Mike Spreitzer's message of 2013-10-17 17:19:58 -0700:
What is the rationale for this new feature? Since there is already an
autoscaling group implemented by Heat, what is the added benefit here?
And
why is it
Steven Hardy sha...@redhat.com wrote on 10/16/2013 04:11:40 AM:
...
IMO we should be abstracting the software configuration complexity
behind a
Heat resource interface, not pushing it up to a pre-processor (which
implies some horribly complex interfaces at the heat template level)
I am not
Zane Bitter zbit...@redhat.com wrote on 10/16/2013 10:30:44 AM:
On 16/10/13 15:58, Mike Spreitzer wrote:
...
Thanks for a great short sharp answer. In that light, I see a
concern.
Once a workflow has been generated, the system has lost the ability
to
adapt to changes in either model
Mike Wilson geekinu...@gmail.com wrote on 10/16/2013 07:13:17 PM:
I need to understand better what holistic scheduling means, ...
By holistic I simply mean making a joint decision all at once about a
bunch of related resources of a variety of types. For example, making a
joint decision about
Steve Baker sba...@redhat.com wrote on 10/15/2013 06:48:53 PM:
From: Steve Baker sba...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 10/15/2013 06:51 PM
Subject: [openstack-dev] [Heat] HOT Software configuration proposal
I've just written some proposals to address Heat's HOT
The threading in the archive includes this discussion under the HOT
Software orchestration proposal for workflows heading, and the overall
ordering in the archive looks very mixed up to me. I am going to reply
here, hoping that the new subject line will be subject to less strange
ordering in
simply
merged inline into the InstanceGroupPolicy[Use] class.
Regards,
Mike
From: Yathiraj Udupi (yudupi) yud...@cisco.com
To: Mike Spreitzer/Watson/IBM@IBMUS,
Cc: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date: 10/14/2013 01:38 PM
Subject:Re
That came through beautifully formatted to me, but it looks much worse in
the archive. I'm going to use crude email tech here, so that I know it
won't lose anything in handling.
Yathiraj Udupi (yudupi) yud...@cisco.com wrote on 10/14/2013 01:17:47
PM:
I read your email where you expressed
Yes, Rethinking Scheduler Design
http://summit.openstack.org/cfp/details/34 is not the same as the
performance issue that Boris raised. I think the former would be a
natural consequence of moving to an optimization-based joint
decision-making framework, because such a thing necessarily takes
Yathiraj Udupi (yudupi) yud...@cisco.com wrote on 10/14/2013 11:43:34
PM:
...
For the policy model, you can expect rows in the DB each
representing different policy instances something like-
{id: , uuid: SOME-UUID-1, name: anti-colocation-1, type:
anti-colocation, properties:
Regarding Alex's question of which component does holistic infrastructure
scheduling, I hesitate to simply answer heat. Heat is about
orchestration, and infrastructure scheduling is another matter. I have
attempted to draw pictures to sort this out, see
@lists.openstack.org,
Cc: Mike Spreitzer/Watson/IBM@IBMUS
Date: 10/11/2013 08:19 AM
Subject:Re: [openstack-dev] [scheduler] APIs for Smart Resource
Placement - Updated Instance Group Model and API extension model - WIP
Draft
Long-story short, sounds like we do have the same concerns here
I favor separation of concerns. I think (4), at least, has got nothing to
do with infrastructure orchestration, the primary concern of today's heat
engine. I advocate (4), but as separate functionality.
Regards,
Mike
Alex Rudenko alexei.rude...@gmail.com wrote on 10/09/2013 12:59:22 PM:
Yes, there is more than the northbound API to discuss. Gary started us
there in the Scheduler chat on Oct 1, when he broke the issues down like
this:
11:12:22 AM garyk: 1. a user facing API
11:12:41 AM garyk: 2. understanding which resources need to be tracked
11:12:48 AM garyk: 3. backend
Debojyoti Dutta ddu...@gmail.com wrote on 10/09/2013 02:48:26 AM:
Mike, I agree we could have a cleaner API but I am not sure how
cleanly it will integrate with current nova which IMO should be test
we should pass (assuming we do cross services later)
I think the cleaner APIs integrate with
Yes, that helps. Please, guys, do not interpret my questions as
hostility, I really am just trying to understand. I think there is some
overlap between your concerns and mine, and I hope we can work together.
Sticking to the physical reservations for the moment, let me ask for a
little more
Sylvain: please do not interpret my questions as hostility. I am only
trying to understand your proposal, but I am still confused. Can you
please walk through a scenario involving Climate reservations on virtual
resources? I mean from start to finish, outlining which party makes which
Thanks for the clue about where the request/response bodies are
documented. Is there any convenient way to view built documentation for
Havana right now?
You speak repeatedly of the desire for clean interfaces, and nobody
could disagree with such words. I characterize my desire that way too.
which party makes which decision, based on what.
Thanks,
Mike
From: Sylvain Bauza sylvain.ba...@bull.net
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org,
Cc: Mike Spreitzer/Watson/IBM@IBMUS
Date: 10/07/2013 05:07 AM
Subject:Re: [openstack-dev
Thanks. I have a few questions. First, I am a bit stymied by the style
of API documentation used in that document and many others: it shows the
first line of an HTTP request but says nothing about all the other
details. I am sure some of those requests must have interesting bodies,
but I am
In addition to the other questions below, I was wondering if you could
explain why you included all those integer IDs; aren't the UUIDs
sufficient?
Thanks,
Mike
From: Mike Spreitzer/Watson/IBM@IBMUS
To: Yathiraj Udupi (yudupi) yud...@cisco.com,
Cc: OpenStack Development Mailing
Thanks, Dina. Yes, we do not understand each other; can I ask some more
questions?
You outlined a two-step reservation process (We assume the following
reservation process for the OpenStack services...), and right after that
talked about changing your mind to use Heat instead of individual
FYI, I have refined my pictures at
https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o0R9U
and
https://docs.google.com/drawings/d/1TCfNwzH_NBnx3bNz-GQQ1bRVgBpJdstpu0lH_TONw6g
to hopefully make it clearer that I agree with the sentiment that holistic
infrastructure
Maybe the answer is hiding in plain sight: host aggregates. This is a
concept we already have, and it allows identification of arbitrary
groupings for arbitrary purposes.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Clint Byrum cl...@fewbar.com wrote on 10/01/2013 02:38:53 AM:
From: Clint Byrum cl...@fewbar.com
To: openstack-dev openstack-dev@lists.openstack.org,
Date: 10/01/2013 02:40 AM
Subject: Re: [openstack-dev] [scheduler] [heat] Policy specifics
(for holistic infrastructure scheduling)
Mike,
OK, let's take the holistic infrastructure scheduling out of Heat. It
really belongs at a lower level anyway. Think of it as something you slap
on top of Nova, Cinder, Neutron, etc. and everything that is going to use
them goes first through the holistic scheduler, to give it a chance to
Alex Glikson glik...@il.ibm.com wrote on 09/29/2013 03:30:35 PM:
Mike Spreitzer mspre...@us.ibm.com wrote on 29/09/2013 08:02:00 PM:
Another reason to prefer host is that we have other resources to
locate besides compute.
Good point. Another approach (not necessarily contradicting
Robert Collins robe...@robertcollins.net wrote on 09/29/2013 02:21:28
AM:
Host not hypervisor I think; consider nova baremetal, where hypervisor
== machine that runs tftpd and makes IPMI calls, and host == place
where the user workload will execute.
In nova baremetal, is there still a
Monty Taylor mord...@inaugust.com wrote on 09/29/2013 01:38:26 PM:
On 09/29/2013 01:02 PM, Mike Spreitzer wrote:
Robert Collins robe...@robertcollins.net wrote on 09/29/2013
02:21:28 AM:
Host not hypervisor I think; consider nova baremetal, where
hypervisor
== machine that runs tftpd
I have begun drafting a blueprint about more detailed host/hypervisor
location information, to support the sort of policy-informed placement
decision-making that Debo, Yathi, and I have been talking about. The
blueprint is at
I have begun to draft some specifics about the sorts of policies that
might be added to infrastructure to inform a smart unified placement
engine. These are cast as an extension to Heat templates. See
https://wiki.openstack.org/wiki/Heat/PolicyExtension . Comments
solicited.
Regards,
Stephen Gran stephen.g...@theguardian.com wrote on 09/27/2013 04:26:37
AM:
Maybe I'm missing something obvious, but I'm not convinced all that
logic belongs in Heat. I would expect nova and related components to
expose grouping information (availability zones in nova, networks in
Zane Bitter zbit...@redhat.com wrote on 09/27/2013 08:24:49 AM:
Your diagrams clearly show scheduling happening in a separate stage to
(infrastructure) orchestration, which is to say that at the point where
resources are scheduled, their actual creation is in the *future*.
I am not a
Sorry, I was a bit too hasty in writing the last part of my last message;
I forgot to qualify software orchestration to indicate I am speaking
only of its preparatory phase. I should have written:
Zane Bitter zbit...@redhat.com wrote on 09/27/2013 08:24:49 AM:
...
If I understood your
Stephen Gran stephen.g...@theguardian.com wrote on 09/27/2013 10:46:09
AM:
If the admins of the openstack install wanted users to be able to select
placement by rack, surely the availability zones would be rack1 - rack5
? In this case, the user would write:
Resources : {
MyASG
Clint Byrum cl...@fewbar.com wrote on 09/27/2013 11:58:16 AM:
From: Clint Byrum cl...@fewbar.com
To: openstack-dev openstack-dev@lists.openstack.org,
Date: 09/27/2013 12:01 PM
Subject: Re: [openstack-dev] [scheduler] [heat] Policy specifics
...
Mike,
These are not the kinds of
Zane also raised an important point about value. Any scheduler is serving
one master most directly, the cloud provider. Any sane cloud provider has
some interest in serving the interests of the cloud users, as well as
having some concerns of its own. The way my group has resolved this is in
I agree that such a thing is useful for scheduling. I see a bit of a
tension here: for software engineering reasons we want some independence,
but we also want to avoid wasteful duplication.
I think we are collectively backing into the problem of metamodeling for
datacenters, and establishing
Clint wrote:
There is a third stealth-objective that CFN has caused to linger in
Heat. That is packaging cloud applications. By allowing the 100%
concrete CFN template to stand alone, users can ship the template.
IMO this marrying of software assembly, config, and orchestration is a
Debo, Yathi: I have read
https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit?pli=1
and most of the referenced materials, and I have a couple of big-picture
questions. That document talks about making Nova call out to something
that makes the sort of smart
Climate is about reserving resources. Are those physical resources or
virtual ones? Where was I supposed to read the answer to basic questions
like that?
If climate is about reserving virtual resources, how is that different
from scheduling them?
Thanks,
Let me elaborate a little on my thoughts about software orchestration, and
respond to the recent mails from Zane and Debo. I have expanded my
picture at
https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o0R9U
and added a companion picture at
I was not trying to raise issues of geographic dispersion and other higher
level structures, I think the issues I am trying to raise are relevant
even without them. This is not to deny the importance, or relevance, of
higher levels of structure. But I would like to first respond to the
Someone earlier asked for greater clarity about infrastructure
orchestration, so here is my view. I see two main issues: (1) deciding
the order in which to do things, and (2) doing them in an acceptable
order. That's an oversimplified wording because, in general, some
parallelism is
From: Tim Bell tim.b...@cern.ch
...
Is this something that will be added into OpenStack or made
available as open source through something like stackforge ?
I and some others think that the OpenStack architecture should have a
place for holistic infrastructure scheduling. I also think this
I have written a new outline of my thoughts, you can find it at
https://docs.google.com/document/d/1RV_kN2Io4dotxZREGEks9DM0Ih_trFZ-PipVDdzxq_E
It is intended to stand up better to independent study. However, it is
still just an outline. I am still learning about stuff going on in
OpenStack,
What's the threat model here?
Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
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
From: Tim Bell tim.b...@cern.ch
...
Discussing with various people in the community, there seems to be
interest in a way to
- Identify when a hypervisor is being drained or is down
and inventory its VMs
- Find the best practise way of restarting that VM for
Manuel, and others:
I am sorry, in the rush at the end of the scheduler meeting a critical
fact flew from my mind: the material I distributed beforehand was intended
as something I could reference during discussion in the meeting, I did not
expect it to fully stand on its own. Indeed, you have
When we get into things like affinity concerns or managing network
bandwidth, we see the need for cross-stack relationships. You may want to
place parts of a new stack near parts of an existing one, for example. I
see that in CFN you can make cross-references between different parts of a
My question is about stacks that are not nested. Suppose, for example,
that I create a stack that implements a shared service. Later I create a
separate stack that uses that shared service. When creating that client
stack, I would like to have a way of talking about its relationships with
Gary
From: Mike Spreitzer mspre...@us.ibm.com
Reply-To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date: Tuesday, September 17, 2013 8:00 AM
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] [scheduler] Bringing
Is it possible to change the email address I use in git and gerrit? I
think I started off with an inferior choice. I have now taught LaunchPad
and Gerrit that I have two email addresses. The OpenStack Foundation
appears a bit confused, but I'm hoping that's not critical.
I am stuck at the
Thanks Anne. Since I have already signed the ICLA, my real question is
about what has to be true on an on-going basis for me to do developer
stuff like reviewing and submitting patches.
Thanks,
Mike___
OpenStack-dev mailing list
I am working through the instructions at
https://wiki.openstack.org/wiki/GerritWorkflow - and things are going OK,
including installing ~/.ssh/id_rsa.pub at
https://review.openstack.org/#/settings/ssh-keys, without any linebreaks
in the middle nor at the end - except it fails at the point
From: Anne Gentle annegen...@justwriteclick.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org,
Date: 09/17/2013 05:51 PM
Subject: Re: [openstack-dev] Change email address, or, why I can't
use github and will I be able to submit patches?
...
Github was
data processing is surely a superset of big data. Either, by itself,
is way too vague. But the wording that many people favor, which I will
quote again, uses the vague term in a qualified way that makes it
appropriately specific, IMHO. Here is the wording again:
``To provide a simple,
From: Jaromir Coufal jcou...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 09/16/2013 11:51 AM
Subject: Re: [openstack-dev] [Tuskar] Tuskar Names Clarification
Unification
Hi,
after few days of gathering information, it looks that no more new
ideas appear there, so let's
I have written a brief document, with pictures. See
https://docs.google.com/document/d/1hQQGHId-z1A5LOipnBXFhsU3VAMQdSe-UXvL4VPY4ps
Regards,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
I've read up on recent goings-on in the scheduler subgroup, and have some
thoughts to contribute.
But first I must admit that I am still a newbie to OpenStack, and still am
missing some important clues. One thing that mystifies me is this: I see
essentially the same thing, which I have
As I mentioned the last time this was brought up, I already have a meeting
series that conflicts with the scheduler group chats and will be hard to
move; that is why I have been trying to participate asynchronously. But
since Gary asked again, I am seeing what I can do about that other meeting
From: Gary Kotton gkot...@vmware.com
...
Can you please join us at the up and coming scheduler meeting. That
will give you a chance to bring up the idea's and discuss them with
a larger audience.
I will do so on Sep 17. Later meetings still TBD.
Regards,
Alex, my understanding is that the motivation for rack-awareness in Hadoop
is optimizing availability rather than networking. The good news, for
those of us who favor a holistic scheduler, is that it can take both sorts
of things into account when/where desired.
Yes, the case of a public
We are currently explicitly considering location and space. For example,
a template can require that a volume be in a disk that is directly
attached to the machine hosting the VM to which the volume is attached.
Spinning rust bandwidth is much trickier because it is not something you
can
Gary Kotton gkot...@vmware.com wrote on 09/12/2013 05:40:59 AM:
From: Gary Kotton gkot...@vmware.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org,
Date: 09/12/2013 05:46 AM
Subject: Re: [openstack-dev] [heat] Comments/questions on the
From: Nirmal Ranganathan rnir...@gmail.com
...
Not host capacity, just a opaque reference to distinguish a host is
enough. Hadoop can use that information to appropriately place block
replicas. For example if the replication count is 3, and if a host/
rack topology is provided to Hadoop, it
To provide a simple, reliable and repeatable mechanism by which to
deploy Hadoop and related Big Data projects, including management,
monitoring and processing mechanisms driving further adoption of
OpenStack.
That sounds like it is at about the right level of specificity.
A quick dictionary lookup of data processing yields the following. I
wonder if you mean something more specific.
data processing |ˈˌdædə ˈprɑsɛsɪŋ|
noun
a series of operations on data, esp. by a computer, to retrieve,
transform, or classify information.
From: Matthew Farrellee
First, I'm a newbie here, wondering: is this the right place for
comments/questions on blueprints? Supposing it is...
I am referring to
https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension
In my own research group we have experience with a few systems that do
something
Jon Maron jma...@hortonworks.com wrote on 09/10/2013 08:50:23 PM:
From: Jon Maron jma...@hortonworks.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org,
Cc: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date: 09/10/2013 08:55 PM
Subject:
Robert Collins robe...@robertcollins.net wrote on 09/06/2013 05:31:14
PM:
From: Robert Collins robe...@robertcollins.net
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org,
Date: 09/06/2013 05:36 PM
Subject: Re: [openstack-dev] [tripleo] Scaling of TripleO
...
My
Joshua, I do not think such a strict and coarse scheduling is a practical
way to manage developers, who have highly individualized talents,
backgrounds, and interests.
Regards,
Mike
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
For the case of an item that has no significant doc of its own but is
related to an extensive blueprint, how about linking to that extensive
blueprint?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
201 - 276 of 276 matches
Mail list logo
