On 10/12/13 13:34, Clint Byrum wrote:
Excerpts from Steven Hardy's message of 2013-12-10 03:00:26 -0800:
On Tue, Dec 10, 2013 at 11:45:11AM +0200, Pavlo Shchelokovskyy wrote:
- wouldn't it be better to keep all these changes in one bug and fix all
misuses per file basis (with one file per
On 10/12/13 15:10, Randall Burt wrote:
On Dec 10, 2013, at 1:27 PM, Zane Bitter zbit...@redhat.com
wrote:
On 10/12/13 12:46, Richard Lee wrote:
Hey all,
We're working on a blueprint
https://blueprints.launchpad.net/heat/+spec/preview-stack that adds
the ability to preview what a given
On 09/12/13 06:31, Steven Hardy wrote:
Hi all,
So I've been getting concerned about $subject recently, and based on some
recent discussions so have some other heat-core folks, so I wanted to start
a discussion where we can agree and communicate our expectations related to
nomination for
On 09/12/13 14:03, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2013-12-09 09:52:25 -0800:
On 09/12/13 06:31, Steven Hardy wrote:
Hi all,
So I've been getting concerned about $subject recently, and based on some
recent discussions so have some other heat-core folks, so I wanted
On 27/11/13 23:37, Fox, Kevin M wrote:
Hmm... Yeah. when you tell heat client the url to a template file, you could
set a flag telling the heat client it is in a git repo. It could then
automatically look for repo information and set a stack metadata item pointing
back to it.
Or just store
On 26/11/13 22:24, Tim Schnell wrote:
Use Case #1
I see valid value in being able to group templates based on a type or
+1, me too.
keyword. This would allow any client, Horizon or a Template Catalog
service, to better organize and handle display options for an end-user.
I believe these
On 27/11/13 16:27, Steven Hardy wrote:
I've raised this BP:
https://blueprints.launchpad.net/heat/+spec/v2api
And started a WIP wiki page where we can all work on refining what changes
need to be made:
https://wiki.openstack.org/wiki/Heat/Blueprints/V2API
The current (v1) API design is
On 27/11/13 18:16, Jay Pipes wrote:
On 11/27/2013 12:02 PM, Zane Bitter wrote:
Your proposal on the wiki page retains this URL but removes the tenant
ID:
GET /v2/stacks/{stack_name}
This now no longer uniquely identifies a stack, and is therefore not
ReST.
It would be along with a Vary
On 27/11/13 18:12, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2013-11-27 08:09:33 -0800:
In the longer term, there seems to be a lot of demand for some sort of
template catalog service, like Glance for templates. (I disagree with
Clint that it should actually _be_ Glance the
On 27/11/13 18:16, Tim Schnell wrote:
On 11/27/13 10:09 AM, Zane Bitter zbit...@redhat.com wrote:
On 26/11/13 22:24, Tim Schnell wrote:
Use Case #1
I see valid value in being able to group templates based on a type or
+1, me too.
keyword. This would allow any client, Horizon
On 27/11/13 19:57, Jay Pipes wrote:
Actually, even simpler than that...
parameters:
db:
- db_name:
description: blah
help: blah
- db_username:
description: blah
help: blah
After all, can't we assume that if the parameter value is a list, then
it is a group
On 26/11/13 03:26, Keith Bray wrote:
On 11/25/13 5:46 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Tim Schnell's message of 2013-11-25 14:51:39 -0800:
Hi Steve,
As one of the UI developers driving the requirements behind these new
blueprints I wanted to take a moment to assure you
Top-posting *and* replying to myself today :D
I realised that I could have implemented this in less time than I've
spent arguing about it already, so I did:
https://review.openstack.org/#/c/58357/
https://review.openstack.org/#/c/58358/
cheers,
Zane.
On 19/11/13 23:27, Zane Bitter wrote
On 20/11/13 23:49, Christopher Armstrong wrote:
On Wed, Nov 20, 2013 at 2:07 PM, Zane Bitter zbit...@redhat.com
mailto:zbit...@redhat.com wrote:
On 20/11/13 16:07, Christopher Armstrong wrote:
On Tue, Nov 19, 2013 at 4:27 PM, Zane Bitter zbit...@redhat.com
mailto:zbit
On 21/11/13 18:44, Christopher Armstrong wrote:
2) It relies on a plugin being present for any type of thing you
might want to notify.
I don't understand this point. What do you mean by a plugin? I was
assuming OS::Neutron::PoolMember (not LoadBalancerMember -- I went and
looked up
On 20/11/13 16:07, Christopher Armstrong wrote:
On Tue, Nov 19, 2013 at 4:27 PM, Zane Bitter zbit...@redhat.com
mailto:zbit...@redhat.com wrote:
On 19/11/13 19:14, Christopher Armstrong wrote:
[snip]
There are a number of advantages to including the whole template,
rather
On 20/11/13 20:09, Mike Spreitzer wrote:
Zane Bitter zbit...@redhat.com wrote on 11/15/2013 05:59:06 PM:
On 15/11/13 22:17, Keith Bray wrote:
The way I view 2 vs. 4 is that 2 is more complicated and you don't gain
any benefit of availability. If, in 2, your global heat endpoint
is down
On 18/11/13 23:45, Anderson Mesquita wrote:
Hello fellows,
As suggested on our meeting last Wednesday (2013-11-13)
http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-11-13-20.00.log.html#l-149,
we're trying to get the build_info discussion going.
The idea is that Heat should provide
On 19/11/13 19:03, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2013-11-15 12:41:53 -0800:
Good news, everyone! I have created the missing whiteboard diagram that
we all needed at the design summit:
On 19/11/13 19:14, Christopher Armstrong wrote:
On Mon, Nov 18, 2013 at 5:57 AM, Zane Bitter zbit...@redhat.com
mailto:zbit...@redhat.com wrote:
On 16/11/13 11:15, Angus Salkeld wrote:
On 15/11/13 08:46 -0600, Christopher Armstrong wrote:
On Fri, Nov 15, 2013 at 3:57
On 17/11/13 21:57, Steve Baker wrote:
On 11/15/2013 05:19 AM, Christopher Armstrong wrote:
http://docs.heatautoscale.apiary.io/
I've thrown together a rough sketch of the proposed API for
autoscaling. It's written in API-Blueprint format (which is a simple
subset of Markdown) and provides
On 16/11/13 11:11, Angus Salkeld wrote:
On 15/11/13 16:32 +0100, Zane Bitter wrote:
On 14/11/13 19:53, Christopher Armstrong wrote:
I'm a little unclear as to what point you're making here. Right now, the
launch configuration is specified in the scaling group by the
resources property
On 16/11/13 11:15, Angus Salkeld wrote:
On 15/11/13 08:46 -0600, Christopher Armstrong wrote:
On Fri, Nov 15, 2013 at 3:57 AM, Zane Bitter zbit...@redhat.com wrote:
On 15/11/13 02:48, Christopher Armstrong wrote:
On Thu, Nov 14, 2013 at 5:40 PM, Angus Salkeld asalk...@redhat.com
On 18/11/13 12:15, Mitsuru Kanabuchi wrote:
On Fri, 15 Nov 2013 12:46:44 +0100
Zane Bitter zbit...@redhat.com wrote:
Yes, but you don't know the UUID until you know it, and by then it's too
late (the resource has been created). So the idempotency token has to be
something passed
On 15/11/13 21:06, Mike Spreitzer wrote:
Zane Bitter zbit...@redhat.com wrote on 11/14/2013 12:56:22 PM:
...
My 2c: the way I designed the Heat API was such that extant stacks can
be addressed uniquely by name. Humans are pretty good with names, not so
much with 128 bit numbers
On 16/11/13 00:07, Georgy Okrokvertskhov wrote:
Hi,
With slight modifications of (2) one can benefit of availability:
1. There should not be a master node. Each heat engine should be able to
act as a master if someone asks it to deploy a template. Current master
engine will be responsible to
On 15/11/13 02:48, Christopher Armstrong wrote:
On Thu, Nov 14, 2013 at 5:40 PM, Angus Salkeld asalk...@redhat.com
mailto:asalk...@redhat.com wrote:
On 14/11/13 10:19 -0600, Christopher Armstrong wrote:
http://docs.heatautoscale.__apiary.io/
On 14/11/13 19:58, Christopher Armstrong wrote:
On Thu, Nov 14, 2013 at 10:44 AM, Zane Bitter zbit...@redhat.com
mailto:zbit...@redhat.com wrote:
On 14/11/13 18:51, Randall Burt wrote:
Perhaps, but I also miss important information as a legitimate
caller
On 15/11/13 11:58, Steven Hardy wrote:
On Fri, Nov 15, 2013 at 11:16:19AM +0100, Zane Bitter wrote:
On 14/11/13 19:58, Christopher Armstrong wrote:
On 14/11/13 18:51, Randall Burt wrote:
Perhaps, but I also miss important information as a legitimate
caller
On 14/11/13 19:53, Christopher Armstrong wrote:
Thanks for the comments, Zane.
On Thu, Nov 14, 2013 at 9:56 AM, Zane Bitter zbit...@redhat.com
mailto:zbit...@redhat.com wrote:
A few comments...
#1 thing is that the launch configuration needs to be somehow
represented. In general
Good news, everyone! I have created the missing whiteboard diagram that
we all needed at the design summit:
https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_Missing_Diagram
I've documented 5 possibilities. (1) is the current implementation,
which we agree we
On 15/11/13 18:24, Bartosz Górski wrote:
Hi Thomas,
Each of the two engines will be able to create resources in both regions.
We do not need to add anything in the heat client.
Right now when you want to create a new stack (using heat client or
directly API) you need to provide:
- stack name
-
to
deploy to any available openstack cloud. That is a HUGE benefit of 4.
Good point, I've added that to the Pro/Con in the wiki.
-Keith
On 11/15/13 2:58 PM, Zane Bitter zbit...@redhat.com wrote:
On 15/11/13 18:24, Bartosz Górski wrote:
Hi Thomas,
Each of the two engines will be able
On 14/11/13 11:29, Renat Akhmerov wrote:
As for EventScheduler proposal, I think it actually fits Mistral model
very well. What described in EvenScheduler is basically the ability to
configure webhooks to be called periodically or at a certain time. First
of all, from the very beginning the
On 14/11/13 12:26, Renat Akhmerov wrote:
On 14 Nov 2013, at 18:03, Zane Bitter zbit...@redhat.com
mailto:zbit...@redhat.com wrote:
What might be a downside is that sharing a back-end may not be
technically convenient - one thing we have been reminded of in Heat is
that a service with timed
On 14/11/13 17:19, Christopher Armstrong wrote:
http://docs.heatautoscale.apiary.io/
I've thrown together a rough sketch of the proposed API for autoscaling.
It's written in API-Blueprint format (which is a simple subset of
Markdown) and provides schemas for inputs and outputs using
On 14/11/13 18:51, Randall Burt wrote:
On Nov 14, 2013, at 11:30 AM, Christopher Armstrong
chris.armstr...@rackspace.com mailto:chris.armstr...@rackspace.com
wrote:
On Thu, Nov 14, 2013 at 11:16 AM, Randall Burt
randall.b...@rackspace.com mailto:randall.b...@rackspace.com wrote:
On 13/11/13 18:29, Thomas Spatzier wrote:
It also doesn't support a list, but I think we can and should fix that
in HOT.
Doesn't DependsOn already support lists? I quickly checked the code and it
seems it does:
https://github.com/openstack/heat/blob/master/heat/engine/resource.py#L288
Oh,
On 02/11/13 05:30, Clint Byrum wrote:
Excerpts from Christopher Armstrong's message of 2013-11-01 11:34:56 -0700:
Vijendar and I are trying to figure out if we need to set the resource_id
of a resource to None when it's being deleted.
This is done in a few resources, but not everywhere. To me
On 12/11/13 14:59, Alex Heneveld wrote:
One minor suggestion is to consider using a special character (eg $)
rather than reserved keywords. As I understand it the keywords are only
interpreted when they exactly match the value of a key in a map, so it
is already unlikely to be problematic.
On 30/10/13 20:35, Lakshminaraya Renganarayana wrote:
I'd like to see some more detail about how
inputs/outputs would be exposed in the configuration management systems
- or, more specifically, how the user can extend this to arbitrary
configuration management systems.
The way
On 28/10/13 04:23, Lakshminaraya Renganarayana wrote:
Sorry, Re-posting this with [Heat] in the subject line, because many of
us have filters based on [Heat] in the subject line.
Hello,
A few us at IBM studied Steve Baker's proposal on HOT Software
Configuration. Overall the proposed
On 28/10/13 14:53, Steven Hardy wrote:
On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana wrote:
A few us at IBM studied Steve Baker's proposal on HOT Software
Configuration. Overall the proposed constructs and syntax are great -- we
really like the clean syntax and concise
On 28/10/13 15:07, Mike Spreitzer wrote:
Zane Bitter zbit...@redhat.com wrote on 10/28/2013 06:47:50 AM:
On 27/10/13 16:37, Edgar Magana wrote:
Heat Developers,
I am one of the core developers for Neutron who is lately working
on the
concept of Network Topologies. I want to discuss
On 22/10/13 09:15, Thomas Spatzier wrote:
BTW, the convention of properties being input and attributes being output,
i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I used
to use both words as synonyms.
On 22/10/13 16:35, Thomas Spatzier wrote:
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 15:27
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
On 22/10/13 09:15
for these sorts of
discussions.)
On 2013-10-22 15:11:25 +0200 (+0200), Zane Bitter wrote:
[...]
Can't we just write Copyright OpenStack Contributors? (Where
'contributors' means individuals or organisations who have signed
the CLA.)
[...]
Actually, technically not. There are other avenues through
On 18/10/13 03:06, Sam Alba wrote:
Hi all,
I've been recently working on a Docker plugin for Heat that makes it
possible to use Docker containers as resources.
I've just opened the repository:
https://github.com/dotcloud/openstack-heat-docker
Cool, nice work. Thanks for sharing! :)
I agree
On 18/10/13 20:24, John Davidge -X (jodavidg - AAP3 INC at Cisco) wrote:
It looks like this discussion involves many of the issues faced when
developing the Curvature Donabe frameworks, which were presented at the
Portland Summit - slides and video here:
On 16/10/13 21:02, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2013-10-16 06:16:33 -0700:
I'd love to be able to put this control in the user's hands by just
using provider templates - i.e. you designate PuppetServer.yaml as the
provider for an OS::Nova::Server in your template
On 16/10/13 06:56, Mike Spreitzer wrote:
What is the difference between what today's heat engine does and a
workflow? I am interested to hear what you experts think, I hope it
will be clarifying. I presume the answers will touch on things like
error handling, state tracking, and updates.
On 16/10/13 00:48, Steve Baker wrote:
I've just written some proposals to address Heat's HOT software
configuration needs, and I'd like to use this thread to get some feedback:
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
On 16/10/13 15:58, Mike Spreitzer wrote:
Zane Bitter zbit...@redhat.com wrote on 10/16/2013 08:25:38 AM:
To answer your question, the key thing that Heat does is take in two
declarative models and generate a workflow to transform one into the
other. (The general case of this is a stack
On 15/10/13 02:18, Sam Alba wrote:
Hello,
I am working on a Heat plugin that makes a new resource available in a
template. It's working great and I will opensource it this week if I
can get the packaging right...
Awesome! :)
Right now, I am linking my module.py file in /usr/lib/heat to get
I would like to propose my candidacy for the OpenStack Technical Committee.
I have been involved with OpenStack since we started the Heat project in
early 2012. I'm still a member of the Heat Core team and - according to
the semi-official statistics from Bitergia
On 27/09/13 17:58, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2013-09-27 06:58:40 -0700:
On 27/09/13 08:58, Mike Spreitzer wrote:
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.
On 30/09/13 17:33, Clint Byrum wrote:
You are painting cloud providers as uncaring slum lords. Of course there
will be slum lords in any ecosystem, but there will also be high quality
service providers and private cloud operators with high expectations that
can use this type of feature as
On 26/09/13 16:49, Sean Dague wrote:
As many folks know, gerrit takes comments of either the form
recheck bug #X
or
recheck no bug
To kick off the check queue jobs again to handle flakey tests.
The problem is that we're getting a lot more no bug than bugs at this
point. If a failure
On 25/09/13 07:03, Mike Spreitzer wrote:
Zane wrote:
To take the first example, wouldn't your holistic scheduler
effectively have
to reserve a compute instance and some directly attached block
storage prior
to actually creating them? Have you considered Climate rather than
Heat as
an
On 27/09/13 08:58, Mike Spreitzer wrote:
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
On 24/09/13 05:31, Mike Spreitzer wrote:
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
On 18/09/13 19:34, Mike Spreitzer wrote:
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
On 15/09/13 09:19, Mike Spreitzer wrote:
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 generally taken to calling
holistic scheduling, discussed in two
On 13/09/13 05:41, Monty Taylor wrote:
On 09/12/2013 04:33 PM, Steve Baker wrote:
On 09/13/2013 08:28 AM, Mike Asthalter wrote:
Hello,
Can someone please explain the plans for our 2 wadls moving forward:
* wadl in original heat
repo:
On 01/09/13 23:11, Alex Rudenko wrote:
Hello everyone,
I would like to ask a question. But, first of all, I would like to say
that I'm new to OpenStack so the question might be irrelevant. From what
I've understood, the idea is to back up an entire stack including VMs,
volumes, networks etc.
Context: https://review.openstack.org/#/c/43571/
On 30/08/13 16:23, Chan, Winson C wrote:
Regarding the last set of comments on the UpdatePolicy, I want to bring your
attention to a few items. I already submitted a new patch set and didn't want
to reply on the old patch set so that's why I
On 27/08/13 23:13, Robert Collins wrote:
I think there is some confusion about implementation vs intent here
:). Or at least I hope so. I wouldn't expect Nova's mission statement
to talk about 'modelling virtual machines' : modelling is internal
jargon, not a mission!
So, I don't really agree
On 22/08/13 17:57, Steven Hardy wrote:
Hi,
I'd like to propose that we add Liang Chen to the heat-core team[1]
Liang has been doing some great work recently, consistently providing good
review feedback[2][3], and also sending us some nice patches[4][5], implementing
several features and fixes
On 15/08/13 19:14, Chan, Winson C wrote:
I updated the implementation section of
https://wiki.openstack.org/wiki/Heat/Blueprints/as-update-policy on instance
naming to support UpdatePolicy where in the case of the LaunchConfiguration
change, all the instances need to be replaced and to
On 08/08/13 06:59, Chan, Winson C wrote:
Proposal for the implementation is documented at
https://wiki.openstack.org/wiki/Heat/Blueprints/as-update-policy. Please
review and provide feedback.
Looks pretty good to me. I think there's a simpler way to trigger
updates to the instances based
On 30/07/13 21:34, Jason Dunsmore wrote:
Hello Heat devs,
I've started doing some testing to find multi-engine bugs, and I
discovered that it's possible to create two stacks with the same name
when only a single heat-engine is running.
Here are the results of my tests:
On 31/07/13 18:37, Bartosz Górski wrote:
Right now I have a problem with the way how the template is passed to
the nested stack.
From what I see the only way right now is providing url to it and it is
really annoying.
Is there any other way to do that?
Yes, that is the only way right now and
On 29/07/13 02:04, Angus Salkeld wrote:
On 26/07/13 09:43 -0700, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2013-07-26 06:37:09 -0700:
On 25/07/13 19:07, Bartosz Górski wrote:
We want to start from something simple. At the beginning we are
assuming
no dependencies between
On 29/07/13 17:16, Bartosz Górski wrote:
I want to be sure that we are on the same page. By master template you
mean a template that has only nested stacks as resources? Or also other
types of resources (like single server) which will be created in the
region where heat engine is located to
On 25/07/13 19:07, Bartosz Górski wrote:
We want to start from something simple. At the beginning we are assuming
no dependencies between resources from different region. Our first use
case (the one on the wikipage) uses this assumptions. So this is why it
can be easily split on two separate
On 25/07/13 17:08, Bartosz Górski wrote:
First of all sorry for the late reply. I needed some time to understand
you vision and check a few things.
On 07/24/2013 08:40 AM, Clint Byrum wrote:
Excerpts from Adrian Otto's message of 2013-07-23 21:22:14 -0700:
Clint,
On Jul 23, 2013, at 10:03
On 18/07/13 08:14, Thomas Spatzier wrote:
Steve Baker sba...@redhat.com wrote on 18.07.2013 00:00:40:
On 07/18/2013 08:53 AM, Gabriel Hurley wrote:
I spent a bunch of time working with and understanding Heat in H2,
and I find myself with one overarching question which I wonder if
anyone's
On 21/06/13 07:49, Angus Salkeld wrote:
On 20/06/13 22:19 -0400, cbjc...@linux.vnet.ibm.com wrote:
So anyway, let's get back to the topic this thread was discussing
about - passing meta data into provider stacks.
It seems that we have all reached an agreement that deletepolicy and
On 19/06/13 01:32, Adrian Otto wrote:
Yes. I think having a POST method in the API makes perfect sense. Assuming we
reach agreement on that, the next question that comes up is:
How to do you modify resources that have been created with a POST?
You mention HTTP PUT as an answer to that.
701 - 779 of 779 matches
Mail list logo
