On 13/11/14 09:58, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2014-11-13 05:54:03 -0800:
On 13/11/14 03:29, Murugan, Visnusaran wrote:
Hi all,
Convergence-POC distributes stack operations by sending resource actions
over RPC for any heat-engine to execute. Entire stack
On 12/11/14 06:33, Alexis Lee wrote:
I would much prefer to resurrect the previous proposal for adding
conditionals and then see what is still missing than to just dive
straight in to embedding a whole other language in HOT.
Do you mean
On 12/11/14 06:48, Angus Salkeld wrote:
(it's nice that there would be a consistent user experience
between these projects -mistral/heat/murano).
It's actually potentially horrible, because you introduce potential
quoting issues when you embed mistral workbooks in Heat templates or
pass Heat
The developer mailing list is not for usage questions. Please ask this
on ask.openstack.org - I'm sure a lot of people will be interested in
the answer and we want it searchable for them in future. Feel free to
ping me with a link when you've posted it.
cheers,
Zane.
On 12/11/14 06:00,
On 12/11/14 10:10, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800:
On 11/11/14 13:34, Ryan Brown wrote:
I am strongly against allowing arbitrary Javascript functions for
complexity reasons. It's already difficult enough to get meaningful
errors when you
On 10/11/14 12:09, Eoghan Glynn wrote:
2.*weaken the continuity guarantee* - by un-staggering the terms,
so that all seats are contested at each election.
This is probably not feasible.
Interesting, why do you think it wouldn't be feasible?
I was under the impression that
On 10/11/14 12:34, Alexis Lee wrote:
Zane Bitter said on Fri, Nov 07, 2014 at 12:35:09AM +0100:
Crazy thought: why not just implement conditionals? We had a
proto-spec for them started at one point...
I didn't know that was on the table :)
How about we support YAQL expressions? https
On 11/11/14 13:34, Ryan Brown wrote:
I am strongly against allowing arbitrary Javascript functions for
complexity reasons. It's already difficult enough to get meaningful
errors when you up your YAML syntax.
Agreed, and FWIW literally everyone that Clint has pitched the JS idea
to
On 01/11/14 16:31, Eoghan Glynn wrote:
+1 to this, with a term limit.
Notable that the Debian TC has been discussing term limits for
months now, and since DebConf they seem to have gotten much closer
to a concrete proposal[1] in the last week or so. Could be worth
watching for ideas on how
On 06/11/14 20:44, Steven Hardy wrote:
On Wed, Nov 05, 2014 at 02:46:43PM +, Lee, Alexis wrote:
I'm considering adding a function which takes a list and returns the first
non-null, non-empty value in that list.
So you could do EG:
some_thing:
config:
On 30/10/14 06:22, Eoghan Glynn wrote:
IIRC, there is no method for removing foundation members. So there
are likely a number of people listed who have moved on to other
activities and are no longer involved with OpenStack. I'd actually
be quite interested to see the turnout numbers with
Hi folks,
I've been looking at the convergence stuff, and become a bit concerned
that we're more or less flying blind (or at least I have been) in trying
to figure out the design, and also that some of the first implementation
efforts seem to be around the stuff that is _most_ expensive to
On 21/10/14 14:05, Subrahmanyam Ongole wrote:
Hi
We are in fact using OS::Neutron::PoolMember resource. I guess
ResourceGroup is the only iterative construct in Heat. Is the use case
supported today? I think this is more than a simple usage question, hence
posting it here. Thank you.
Regards
Greetings OpenStackers,
I would like to announce my candidacy for the OpenStack Technical Committee.
I have worked closely with the TC since around the time that Heat was
incubated, two years ago. I have been a regular participant in TC
meetings throughout the Juno cycle as the Heat PTL, so I
On 06/10/14 06:07, Thierry Carrez wrote:
Jay Pipes wrote:
On 10/03/2014 09:18 PM, Zane Bitter wrote:
The prospect of a much larger tent with many more projects in
OpenStack-proper shines a spotlight on the scalability of the Docs team,
and in particular how they decide which projects
I'd like to propose that we add Pavlo Shchelokovskyy to the heat-core team.
Pavlo has been a consistently active member of the Heat community - he's
a regular participant in IRC and at meetings, has been making plenty of
good commits[1] and maintains a very respectable review rate[2] with
Amidst all the discussion about layers and tents there has been this
lurking issue about Docs and their need to prioritise work that we
haven't really done a deep dive on yet. I'd like to start that
discussion by summarising my understanding of the situation, and
hopefully Anne and others can
Hi Steve,
Could you post this question on ask.openstack.org? The -dev mailing list
is not for usage questions; ask.openstack is a much better place to
ensure that others with the same question will benefit from the answer.
FWIW I'd be really surprised if the version of cloud-init in CoreOS is
Dredging up this thread because I was reminded of it today by a question
on ask.openstack.org.
On 18/07/14 09:19, Ayenson, Michael D. wrote:
Hello All,
My name is Mika Ayenson and I have to privilege to intern at Johns Hopkins - Applied
Physics Lab. I'm really excited to release the latest
On 26/09/14 00:01, Angus Lees wrote:
On Thu, 25 Sep 2014 04:01:38 PM Fox, Kevin M wrote:
Doesn't nova with a docker driver and heat autoscaling handle case 2 and 3
for control jobs? Has anyone tried yet?
For reference, the cases were:
- Something to deploy the code (docker / distro packages
At the time of the Icehouse release, we realised that the just-merged
stack abandon/adopt features were still in a very flaky state. A bunch
of bugs were opened and in the release notes we called this out as a
'preview' feature, not fully supported.
Fast-forward 6 months and we still have a
On 25/09/14 15:12, Vishvananda Ishaya wrote:
On Sep 24, 2014, at 10:55 AM, Zane Bitter zbit...@redhat.com wrote:
On 18/09/14 14:53, Monty Taylor wrote:
Hey all,
I've recently been thinking a lot about Sean's Layers stuff. So I wrote
a blog post which Jim Blair and Devananda were kind enough
On 22/09/14 11:04, Anant Patil wrote:
Hi,
In convergence, we discuss about having concurrent updates to a stack. I
wanted to know if it is safe to assume that the an update will be a
super set of it's previous updates. Understanding this is critical to
arrive at implementation of concurrent
On 23/09/14 17:59, Joe Gordon wrote:
Zaqar is aiming for low latency per message, SQS doesn't appear to be.
I've seen no evidence that Zaqar is actually aiming for that. There are
waaay lower-latency ways to implement messaging if you don't care about
durability (you wouldn't do
On 23/09/14 19:29, Devananda van der Veen wrote:
On Mon, Sep 22, 2014 at 5:47 PM, Zane Bitter zbit...@redhat.com wrote:
On 22/09/14 17:06, Joe Gordon wrote:
If 50,000 messages per second doesn't count as small-to-moderate then
Zaqar
does not fulfill a major SQS use case.
It's not a drop
On 24/09/14 08:47, Tomas Sedovic wrote:
On 24/09/14 13:50, Dimitri Mazmanov wrote:
TL;DR Is there any reason why stack-update doesn¹t reuse the existing
parameters when I extend my stack definition with a resource that uses
them?
Hey Dimitri,
There is an open bug for this feature:
On 18/09/14 14:53, Monty Taylor wrote:
Hey all,
I've recently been thinking a lot about Sean's Layers stuff. So I wrote
a blog post which Jim Blair and Devananda were kind enough to help me edit.
http://inaugust.com/post/108
Thanks Monty, I think there are some very interesting ideas in
On 19/09/14 22:37, Monty Taylor wrote:
I think we can do what you're saying and generalize a little bit. What
if we declared programs, as needed, when we think there is a need to
pick a winner. (I think we can all agree that early winner picking is
an unintended but very real side effect of the
On 23/09/14 08:58, Flavio Percoco wrote:
I believe the guarantee is still useful and it currently does not
represent an issue for the service nor the user. 2 things could happen
to FIFO in the future:
1. It's made optional and we allow users to opt-in in a per flavor
basis. (I personally don't
On 22/09/14 22:04, Joe Gordon wrote:
To me this is less about valid or invalid choices. The Zaqar team is
comparing Zaqar to SQS, but after digging into the two of them, zaqar
barely looks like SQS. Zaqar doesn't guarantee what IMHO is the most
important parts of SQS: the message will be
On 23/09/14 09:44, Anant Patil wrote:
On 23-Sep-14 09:42, Clint Byrum wrote:
Excerpts from Angus Salkeld's message of 2014-09-22 20:15:43 -0700:
On Tue, Sep 23, 2014 at 1:09 AM, Anant Patil anant.pa...@hp.com wrote:
Hi,
One of the steps in the direction of convergence is to enable Heat
On 22/09/14 10:40, Geoff O'Callaghan wrote:
So
On 22/09/2014 10:01 PM, Zane Bitter zbit...@redhat.com wrote:
On 20/09/14 04:17, Geoff O'Callaghan wrote:
Hi all,
I'm just trying to understand the messaging strategy in openstack.It
seems we have at least 2 messaging layers.
Oslo.messaging
On 22/09/14 10:11, Gordon Sim wrote:
On 09/19/2014 09:13 PM, Zane Bitter wrote:
SQS offers very, very limited guarantees, and it's clear that the reason
for that is to make it massively, massively scalable in the way that
e.g. S3 is scalable while also remaining comparably durable (S3
On 18/09/14 10:55, Flavio Percoco wrote:
On 09/18/2014 04:24 PM, Clint Byrum wrote:
Great job highlighting what our friends over at Amazon are doing.
It's clear from these snippets, and a few other pieces of documentation
for SQS I've read, that the Amazon team approached SQS from a _massive_
On 19/09/14 14:34, Clint Byrum wrote:
Excerpts from Flavio Percoco's message of 2014-09-19 02:37:08 -0700:
On 09/18/2014 11:51 AM, Angus Salkeld wrote:
On 18/09/2014 7:11 PM, Flavio Percoco fla...@redhat.com
mailto:fla...@redhat.com wrote:
Greetings,
If I recall correctly, Heat was
On 09/09/14 05:52, Steven Hardy wrote:
Hi Sahdev,
On Tue, Sep 02, 2014 at 11:52:30AM -0400, Sahdev P Zala wrote:
Hello guys,
As you know, the heat-translator project was started early this year with
an aim to create a tool to translate non-Heat templates to HOT. It is a
On 19/09/14 01:10, Mike Spreitzer wrote:
Angus Salkeld asalk...@mirantis.com wrote on 09/18/2014 09:33:56 PM:
Hi
I am trying to add some docs to openstack-manuals hot_guide about
using provider templates : https://review.openstack.org/#/c/121741/
Mike has suggested we use a different
On 16/09/14 02:49, Qiming Teng wrote:
Nice. What would be even nicer is a change to python-heatclient so that
heat resource-list has an option to output in dotfile format.
+1.
It would also be interesting to check if the dependency analysis is
capable of exploding a resource-group. Say I
On 16/09/14 13:56, Devananda van der Veen wrote:
On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy sha...@redhat.com wrote:
For example, today, I've been looking at the steps required for driving
autodiscovery:
https://etherpad.openstack.org/p/Ironic-PoCDiscovery-Juno
Driving this process looks a
On 16/09/14 13:54, Devananda van der Veen wrote:
On Sep 15, 2014 8:20 AM, James Slaglejames.sla...@gmail.com wrote:
On Mon, Sep 15, 2014 at 7:44 AM, Steven Hardysha...@redhat.com wrote:
The initial assumption is that there is some discovery step (either
automatic or static generation of
On 16/09/14 15:24, Devananda van der Veen wrote:
On Tue, Sep 16, 2014 at 11:44 AM, Zane Bitter zbit...@redhat.com wrote:
On 16/09/14 13:56, Devananda van der Veen wrote:
On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy sha...@redhat.com wrote:
For example, today, I've been looking at the steps
From time to time we have people drift away from core reviewing
activity on Heat for the long term due to changing employers, changing
roles or just changing priorities.
It's time for a bit of a clean-up, so I have removed Liang Chen and
Steve Dake from the heat-core group. We thank them for
On 14/09/14 11:09, Clint Byrum wrote:
Excerpts from Gauvain Pocentek's message of 2014-09-04 22:29:05 -0700:
Hi,
A bit of background: I'm working on the publication of the HOT
resources reference on docs.openstack.org. This book is mostly
autogenerated from the heat source code, using the
On 15/09/14 12:00, Steven Hardy wrote:
For example, today, I've been looking at the steps required for driving
autodiscovery:
https://etherpad.openstack.org/p/Ironic-PoCDiscovery-Juno
Driving this process looks a lot like application orchestration:
1. Take some input (IPMI credentials and MAC
On 15/09/14 13:28, Clint Byrum wrote:
Excerpts from Flavio Percoco's message of 2014-09-15 00:57:05 -0700:
On 09/12/2014 07:13 PM, Clint Byrum wrote:
Excerpts from Thierry Carrez's message of 2014-09-12 02:16:42 -0700:
Clint Byrum wrote:
Excerpts from Flavio Percoco's message of 2014-09-11
On 15/09/14 16:55, Anne Gentle wrote:
On Mon, Sep 15, 2014 at 11:31 AM, Zane Bitter zbit...@redhat.com wrote:
On 14/09/14 11:09, Clint Byrum wrote:
Excerpts from Gauvain Pocentek's message of 2014-09-04 22:29:05 -0700:
Hi,
A bit of background: I'm working on the publication of the HOT
On 11/09/14 19:05, Jay Pipes wrote:
On 09/11/2014 04:09 PM, Zane Bitter wrote:
Swift is the current exception here, but one could argue, and people
have[2], that Swift is also the only project that actually conforms to
our stated design tenets for OpenStack. I'd struggle to tell the Zaqar
folks
On 12/09/14 04:50, Flavio Percoco wrote:
On 09/12/2014 12:14 AM, Zane Bitter wrote:
However, Zaqar also supports the Pub-Sub model of messaging. I believe,
but would like Flavio to confirm, that this is what is meant when the
Zaqar team say that Zaqar is about messaging in general and not just
On 12/09/14 07:37, Thierry Carrez wrote:
Hi everyone,
I visited the Paris Design Summit space on Monday and confirmed that it
should be possible to split it in a way that would allow to have
per-program contributors meetups on the Friday. The schedule would go
as follows:
Tuesday:
On 04/09/14 08:14, Sean Dague wrote:
I've been one of the consistent voices concerned about a hard
requirement on adding NoSQL into the mix. So I'll explain that thinking
a bit more.
I feel like when the TC makes an integration decision previously this
has been about evaluating the project
On 09/09/14 15:03, Monty Taylor wrote:
On 09/04/2014 01:30 AM, Clint Byrum wrote:
Excerpts from Flavio Percoco's message of 2014-09-04 00:08:47 -0700:
Greetings,
Last Tuesday the TC held the first graduation review for Zaqar. During
the meeting some concerns arose. I've listed those concerns
On 09/09/14 19:56, Clint Byrum wrote:
Excerpts from Samuel Merritt's message of 2014-09-09 16:12:09 -0700:
On 9/9/14, 12:03 PM, Monty Taylor wrote:
On 09/04/2014 01:30 AM, Clint Byrum wrote:
Excerpts from Flavio Percoco's message of 2014-09-04 00:08:47 -0700:
Greetings,
Last Tuesday the TC
On 04/09/14 10:45, Jay Pipes wrote:
On 08/29/2014 05:15 PM, Zane Bitter wrote:
On 29/08/14 14:27, Jay Pipes wrote:
On 08/26/2014 10:14 AM, Zane Bitter wrote:
Steve Baker has started the process of moving Heat tests out of the
Tempest repository and into the Heat repository, and we're looking
On 01/09/14 19:18, Steve Baker wrote:
On 02/09/14 05:58, Lars Kellogg-Stedman wrote:
Hello all,
I recently submitted this change:
https://review.openstack.org/#/c/118190/
This causes the Docker plugin to *remove* containers on delete,
rather than simply *stopping* them. When creating
On 07/09/14 23:43, Morgan Fainberg wrote:
## avoiding collaboration between bad actors
The two core requirement means that it takes three people (proposer +
2 core) to collaborate on landing something inappropriate (whether its
half baked, a misfeature, whatever). Thats only 50% harder than 2
On 29/08/14 14:27, Jay Pipes wrote:
On 08/26/2014 10:14 AM, Zane Bitter wrote:
Steve Baker has started the process of moving Heat tests out of the
Tempest repository and into the Heat repository, and we're looking for
some guidance on how they should be packaged in a consistent way.
Apparently
On 28/08/14 13:31, Drago Rosson wrote:
You are in luck, because I have just now open-sourced Barricade! Check it
out [4].
[4]https://github.com/rackerlabs/barricade
Please add a license (preferably ASL 2.0). Open Source doesn't mean
the source is on GitHub, it means that the code is licensed
On 27/08/14 09:55, Thierry Carrez wrote:
Daniel P. Berrange wrote:
On Wed, Aug 27, 2014 at 02:51:55PM +0200, Thierry Carrez wrote:
[...]
I think this proposal makes the best use of our setup: discuss clear
cross-project issues, address key specific topics which need
face-to-face time and
On 26/08/14 18:59, Clint Byrum wrote:
Excerpts from Steve Baker's message of 2014-08-26 14:25:46 -0700:
On 27/08/14 03:18, David Kranz wrote:
On 08/26/2014 10:14 AM, Zane Bitter wrote:
Steve Baker has started the process of moving Heat tests out of the
Tempest repository and into the Heat
On 27/08/14 11:04, Steven Hardy wrote:
On Wed, Aug 27, 2014 at 07:54:41PM +0530, Jyoti Ranjan wrote:
I am little bit skeptical about using Swift for this use case because of
its eventual consistency issue. I am not sure Swift cluster is good to be
used for this kind of problem.
APIs that particular accounts should be
locked down.
cheers,
Zane.
On 8/25/14, 9:49 AM, Zane Bitter zbit...@redhat.com wrote:
In particular, even if a service like Zaqar or Heat implements their own
authorisation (e.g. the user creating a Zaqar queue supplies lists of
the accounts
Steve Baker has started the process of moving Heat tests out of the
Tempest repository and into the Heat repository, and we're looking for
some guidance on how they should be packaged in a consistent way.
Apparently there are a few projects already packaging functional tests
in the package
On 24/08/14 23:17, Adam Young wrote:
On 08/23/2014 02:01 AM, Clint Byrum wrote:
I don't know how Zaqar does its magic, but I'd love to see simple signed
URLs rather than users/passwords. This would work for Heat as well. That
way we only have to pass in a single predictably formatted string.
On 25/08/14 05:21, Thierry Carrez wrote:
Zane Bitter wrote:
[...]
Here are a few of the conclusions:
* Everyone wishes the Design Summit worked like this.
The meetup seemed a lot more productive than the design summit ever is.
It's really nice to be in a room small enough that you can talk
On 22/08/14 21:02, Anne Gentle wrote:
I'm with Rocky on the anti-czar-as-a-word camp. We all like clever names to
shed the corporate stigma but this word ain't it. Liaison or lead?
+1. The only time you hear the word 'czar' in regular life (outside of
references to pre-revolutionary Russia)
On 25/08/14 06:48, Thierry Carrez wrote:
Zane Bitter wrote:
Over the past couple of release cycles, the TC has put together a fairly
comprehensive checklist for projects entering into incubation with a
view to being included in the integrated release. However, I'm not aware
of anything
On 21/08/14 04:30, Thierry Carrez wrote:
Georgy Okrokvertskhov wrote:
During last Atlanta summit there were couple discussions about
Application Catalog and Application space projects in OpenStack. These
cross-project discussions occurred as a result of Murano incubation
request [1] during
On 22/08/14 08:33, Thierry Carrez wrote:
Hi everyone,
We all know being a project PTL is an extremely busy job. That's because
in our structure the PTL is responsible for almost everything in a project:
- Release management contact
- Work prioritization
- Keeping bugs under control
-
On 22/08/14 12:45, Dolph Mathews wrote:
I'm all for getting a final decision, but a 'final' decision that has been
imposed from outside rather than internalised by the participants is...
rarely final.
The expectation of a PTL isn't to stomp around and make final decisions,
it's to step in when
We held the inaugural Heat mid-cycle meetup in Raleigh, North Carolina
this week. There were a dozen folks in attendance, and I think everyone
agreed that it was a very successful event. Notes from the meetup are on
the Etherpad here:
https://etherpad.openstack.org/p/heat-juno-midcycle-meetup
Here's an interesting fact about Zaqar (the project formerly known as
Marconi) that I hadn't thought about before this week: it's probably the
first OpenStack project where a major part of the API primarily faces
software running in the cloud rather than facing the user.
That is to say,
Over the past couple of release cycles, the TC has put together a fairly
comprehensive checklist for projects entering into incubation with a
view to being included in the integrated release. However, I'm not aware
of anything equivalent for projects that are becoming official (i.e.
moving to
On 21/08/14 12:21, Daniel P. Berrange wrote:
On Thu, Aug 21, 2014 at 05:05:04PM +0100, Matthew Booth wrote:
I would prefer that you didn't merge this.
i.e. The project is better off without it.
A bit off topic, but I've never liked this message that gets added
as it think it sounds overly
On 20/08/14 15:37, Jay Pipes wrote:
For example, everyone agrees that Ceilometer has
room for improvement, but any implication that the Ceilometer is not
interested in or driving towards those improvements (because of NIH or
whatever) is, as has been pointed out, grossly unfair to the Ceilometer
On 19/08/14 10:37, Jay Pipes wrote:
By graduating an incubated project into the integrated release, the
Technical Committee is blessing the project as the OpenStack way to do
some thing. If there are projects that are developed *in the OpenStack
ecosystem* that are actively being developed to
On 11/08/14 05:24, Thierry Carrez wrote:
So the idea that being (and remaining) in the integrated release should
also be judged on technical merit is a slightly different effort. It's
always been a factor in our choices, but like Devananda says, it's more
difficult than just checking a number of
On 14/08/14 03:21, Malawade, Abhijeet wrote:
Hi all,
I am trying to use heat to create docker containers. I have configured
heat-docker plugin.
I am also able to create stack using heat successfully.
To start container on different host we need to provide 'docker_endpoint' in
template. For
On 11/08/14 10:46, Clint Byrum wrote:
Right now we're stuck with an update that just doesn't work. It isn't
just about update-failure-recovery, which is coming along nicely, but
it is also about the lack of signals to control rebuild, poor support
for addressing machines as groups, and
On 11/08/14 14:49, Clint Byrum wrote:
Excerpts from Steven Hardy's message of 2014-08-11 11:40:07 -0700:
On Mon, Aug 11, 2014 at 11:20:50AM -0700, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2014-08-11 08:16:56 -0700:
On 11/08/14 10:46, Clint Byrum wrote:
Right now we're stuck
On 11/08/14 15:24, Dan Prince wrote:
Hmmm. We blocked a good bit of changes to get these HOT templates in so
I hate to see us revert them. Also, It isn't clear to me how much work
it would be to fully support the non-HOT to HOT templates upgrade path.
How much work is this? And is that something
On 11/08/14 16:21, Matthew Treinish wrote:
I'm sorry, but the fact that the
docs in the rally tree has a section for user testimonials [4] I feel speaks a
lot about the intent of the project.
What... does that even mean?
They seem like just the type of guys that would help Keystone with
On 08/08/14 11:07, Tomas Sedovic wrote:
On 08/08/14 00:53, Zane Bitter wrote:
On 07/08/14 13:22, Tomas Sedovic wrote:
Hi all,
I have a ResourceGroup which wraps a custom resource defined in another
template:
servers:
type: OS::Heat::ResourceGroup
properties
On 07/08/14 13:22, Tomas Sedovic wrote:
Hi all,
I have a ResourceGroup which wraps a custom resource defined in another
template:
servers:
type: OS::Heat::ResourceGroup
properties:
count: 10
resource_def:
type: my_custom_server
On 06/08/14 10:37, Anant Patil wrote:
Hi,
I see that the stack delete method is too long to comprehend easily
without going to-and-fro few times. I think we should refactor it and
move out the UpdateReplace related logic for backup stack to another
method. We can also move the user credentials
On 04/08/14 19:18, Yuriy Taraday wrote:
Hello, git-review users!
I'd like to gather feedback on a feature I want to implement that might
turn out useful for you.
I like using Git for development. It allows me to keep track of current
development process, it remembers everything I ever did with
On 06/08/14 18:12, Yuriy Taraday wrote:
2. since hacking takes tremendous amount of time (you're doing a Cool
Feature (tm), nothing less) you need to update some code from master, so
you're just merging master in to your branch (i.e. using Git as you'd
use it normally);
This is not how I'd
This is your reminder that two weeks from now we'll be in the middle of
the Heat mid-cycle meetup in Raleigh, NC. (The meetup runs from August
18-20.)
If you plan to attend, make sure you are signed up on this list by the
end of this week:
On 30/07/14 02:21, Anant Patil wrote:
On 28-Jul-14 22:37, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2014-07-28 07:25:24 -0700:
On 26/07/14 00:04, Anant Patil wrote:
When the stack is updated, a diff of updated template and current
template can be stored to optimize database.
On 26/07/14 00:04, Anant Patil wrote:
Hi,
When we do a stack update, I see that there are 2 copies of raw_template
stored in database for each update. For n updates there are 2n + 1
entries of raw_template in database. Is this expected or is it a bug?
When I dug more into it, I see that the
On 18/07/14 06:02, Dimitri Mazmanov wrote:
On 18/07/14 11:20, Steven Hardy sha...@redhat.com wrote:
On Fri, Jul 18, 2014 at 09:02:33AM +, Dimitri Mazmanov wrote:
Hi,
I¹m working on the following use-case:
I have a stack template containing a custom resource - my_res - that
upon
On 25/07/14 13:50, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2014-07-24 12:09:39 -0700:
On 17/07/14 07:51, Ryan Brown wrote:
On 07/17/2014 03:33 AM, Steven Hardy wrote:
On Thu, Jul 17, 2014 at 12:31:05AM -0400, Zane Bitter wrote:
On 16/07/14 23:48, Manickam, Kanagaraj wrote
On 17/07/14 07:51, Ryan Brown wrote:
On 07/17/2014 03:33 AM, Steven Hardy wrote:
On Thu, Jul 17, 2014 at 12:31:05AM -0400, Zane Bitter wrote:
On 16/07/14 23:48, Manickam, Kanagaraj wrote:
SNIP
*Resource*
Status action should be enum of predefined status
+1
Rsrc_metadata - make full name
On 16/07/14 23:48, Manickam, Kanagaraj wrote:
I have gone thru the Heat Database and found the drawbacks in the
existing model as listed below. Could you review and add anything
missing here. Thanks.
Heat Database model is having following drawbacks:
1.Duplicate information
2.Incomplete
On 14/07/14 12:21, Tomas Sedovic wrote:
On 12/07/14 06:41, Zane Bitter wrote:
On 11/07/14 09:37, Tomas Sedovic wrote:
[snip]
3. List of IP addresses of all controllers:
https://github.com/openstack/tripleo-heat-templates/blob/a7f2a2c928e9c78a18defb68feb40da8c7eb95d6/overcloud-source.yaml
The Technical Committee has been conducting an analysis of existing
projects to ensure they comply with the same criteria to which newly
incubated/graduated projects are being held. Heat is one of the last
projects to undergo this analysis, so it will be happening soon -
possibly as soon as
On 11/07/14 09:37, Tomas Sedovic wrote:
Hi all,
This is a follow-up to Clint Byrum's suggestion to add the `Map`
intrinsic function[0], Zane Bitter's response[1] and Randall Burt's
addendum[2].
Sorry for bringing it up again, but I'd love to reach consensus on this.
The summary of the previous
On 10/07/14 05:34, Steven Hardy wrote:
The other approach is to set up a new container, owned by the user, every
time. In that case, a provider selecting this implementation would need to make it
clear to customers if they would be billed for a WaitCondition resource. I'd prefer
to avoid
On 09/07/14 22:38, Mike Spreitzer wrote:
Zane Bitter zbit...@redhat.com wrote on 07/01/2014 06:54:58 PM:
On 01/07/14 16:23, Mike Spreitzer wrote:
An AWS autoscaling group can span multiple availability zones in one
region. What is the thinking about how to get analogous functionality
Hello Heatists,
I've updated the etherpad with some information about accommodation for
the mid-cycle meetup:
https://etherpad.openstack.org/p/heat-juno-midcycle-meetup
For those signed up, now would be a good time to book if you haven't
already. If you plan to attend but haven't signed up
On 08/07/14 17:13, Angus Salkeld wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/07/14 09:14, Zane Bitter wrote:
I see that the new client plugins are loaded using stevedore, which is
great and IMO absolutely the right tool for that job. Thanks to Angus
Steve B for implementing
501 - 600 of 779 matches
Mail list logo
