Re: [openstack-dev] [Heat] Passing a list of ResourceGroup's attributes back to its members

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

Re: [openstack-dev] [TripleO][heat] a small experiment with Ansible in TripleO

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 unacceptab

Re: [openstack-dev] Which program for Rally

On 08/08/14 10:41, Anne Gentle wrote: - Would have to ensure Rally is what we want "first" as getting to be PTL since you are first to propose seems to be the model. I know that at one time it was popular in the trade/gutter press to cast aspersions on new projects by saying that someone getti

Re: [openstack-dev] [TripleO][heat] a small experiment with Ansible in TripleO

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 w

Re: [openstack-dev] [TripleO][Heat] reverting the HOT migration? // dealing with lockstep changes

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

Re: [openstack-dev] Which program for Rally

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 perf

Re: [openstack-dev] [heat] heat docker multi host scheduling support

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 th

Re: [openstack-dev] [all] The future of the integrated release

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

Re: [openstack-dev] [all] The future of the integrated release

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

Re: [openstack-dev] Criteria for giving a -1 in a review

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

Re: [openstack-dev] [all] The future of the integrated release

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

Re: [openstack-dev] [Glance][Heat] Murano split dsicussion

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 Iceho

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

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 - Communicat

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 22/08/14 11:19, Thierry Carrez wrote: Zane Bitter wrote: On 22/08/14 08:33, Thierry Carrez wrote: We also still need someone to have the final say in case of deadlocked issues. -1 we really don't. I know we disagree on that :) No problem, you and I work in different programs so w

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

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

[openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

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

[openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

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, nobody

[openstack-dev] [tc] Procedure for adding official projects

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 t

Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

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. Ex

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

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

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

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)

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

On 25/08/14 06:30, Thierry Carrez wrote: Zane Bitter wrote: 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 expec

Re: [openstack-dev] [tc] Procedure for adding official projects

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 any

[openstack-dev] [qa][all][Heat] Packaging of functional tests

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 .tes

Re: [openstack-dev] [all] Design Summit reloaded

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 broade

Re: [openstack-dev] [qa][all][Heat] Packaging of functional tests

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

Re: [openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report

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. Pleas

Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

municate to other project APIs that particular accounts should be locked down. cheers, Zane. On 8/25/14, 9:49 AM, "Zane Bitter" 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 acc

Re: [openstack-dev] [UX] [Horizon] [Heat] Merlin project (formerly known as cross-project UI library for Heat/Mistral/Murano/Solum) plans for PoC and more

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 licen

Re: [openstack-dev] [nova] Is the BP approval process broken?

On 28/08/14 17:02, Jay Pipes wrote: I understand your frustration about the silence, but the silence from core team members may actually be a loud statement about where their priorities are. I don't know enough about the Nova review situation to say if the process is broken or not. But I can s

Re: [openstack-dev] [qa][all][Heat] Packaging of functional tests

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. Appar

Re: [openstack-dev] [Heat] Should docker plugin remove containers on delete?

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 name

Re: [openstack-dev] doubling our core review bandwidth

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

Re: [openstack-dev] [qa][all][Heat] Packaging of functional tests

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 lo

Re: [openstack-dev] [Zaqar] Comments on the concerns arose during the TC meeting

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 appl

Re: [openstack-dev] [Zaqar] Comments on the concerns arose during the TC meeting

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 b

Re: [openstack-dev] [Zaqar] Comments on the concerns arose during the TC meeting

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 h

Re: [openstack-dev] [Zaqar] Comments on the concerns arose during the TC meeting

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

Re: [openstack-dev] [Zaqar] Comments on the concerns arose during the TC meeting

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 genera

Re: [openstack-dev] [all] Design Summit planning

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: cross-proje

[openstack-dev] [Heat] Core team tidy-up

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 t

Re: [openstack-dev] [Heat] Defining what is a SupportStatus version

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 sphin

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

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

Re: [openstack-dev] [Zaqar] Zaqar graduation (round 2) [was: Comments on the concerns arose during the TC meeting]

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 04

Re: [openstack-dev] [Heat] Defining what is a SupportStatus version

On 15/09/14 16:55, Anne Gentle wrote: On Mon, Sep 15, 2014 at 11:31 AM, Zane Bitter 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 resources

Re: [openstack-dev] Heat dependency visualisation

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 have

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

On 16/09/14 13:56, Devananda van der Veen wrote: On Mon, Sep 15, 2014 at 9:00 AM, 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 applicat

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

On 16/09/14 13:54, Devananda van der Veen wrote: On Sep 15, 2014 8:20 AM, "James Slagle" wrote: > >On Mon, Sep 15, 2014 at 7:44 AM, Steven Hardy wrote: > > > >The initial assumption is that there is some discovery step (either > >automatic or static generation of a manifest of nodes), that ca

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

On 16/09/14 15:24, Devananda van der Veen wrote: On Tue, Sep 16, 2014 at 11:44 AM, Zane Bitter wrote: On 16/09/14 13:56, Devananda van der Veen wrote: On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy wrote: For example, today, I've been looking at the steps required for driving autodisc

Re: [openstack-dev] [Heat] Continue discussing multi-region orchestration

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: https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_M

Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API

On 19/11/13 19:14, Christopher Armstrong wrote: On Mon, Nov 18, 2013 at 5:57 AM, Zane Bitter 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 AM, Zane

Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API

On 20/11/13 16:07, Christopher Armstrong wrote: On Tue, Nov 19, 2013 at 4:27 PM, Zane Bitter 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 than a re

Re: [openstack-dev] [Heat] Continue discussing multi-region orchestration

On 20/11/13 20:09, Mike Spreitzer wrote: Zane Bitter 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 endpoi

Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API

On 20/11/13 23:49, Christopher Armstrong wrote: On Wed, Nov 20, 2013 at 2:07 PM, Zane Bitter 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 mailto:zbit...@redhat.com> <mailto:zbit..

Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API

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 the

Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API

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

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

On 26/11/13 03:26, Keith Bray wrote: On 11/25/13 5:46 PM, "Clint Byrum" 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 and the rest o

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

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 are

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

On 26/11/13 23:44, Tim Schnell wrote: A template-validate call would need to return all the group and ordering >information, but otherwise heat can ignore this extra data. I agree with all of your modifications, although bringing up the template-validate call reminded me that the implementation

Re: [openstack-dev] [heat] Is it time for a v2 Heat API?

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 based

Re: [openstack-dev] [heat] Is it time for a v2 Heat API?

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

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

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 proje

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

On 27/11/13 18:16, Tim Schnell wrote: On 11/27/13 10:09 AM, "Zane Bitter" 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 or a Templa

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

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 of

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

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 t

Re: [openstack-dev] [heat] Core criteria, review stats vs reality

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 heat-cor

Re: [openstack-dev] [heat] Core criteria, review stats vs reality

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 to

Re: [openstack-dev] [heat] Stack preview

On 10/12/13 12:46, Richard Lee wrote: Hey all, We're working on a blueprint that adds the ability to preview what a given template+parameters would create in terms of resources. We think this would provide significant value for bluepri

Re: [openstack-dev] [Heat] workflow for fixes involving numerous changes

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 patch

Re: [openstack-dev] [heat] Stack preview

On 10/12/13 15:10, Randall Burt wrote: On Dec 10, 2013, at 1:27 PM, Zane Bitter 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 template

Re: [openstack-dev] [heat] Stack preview

On 11/12/13 11:59, Randall Burt wrote: On Dec 10, 2013, at 3:46 PM, Zane Bitter wrote: On 10/12/13 15:10, Randall Burt wrote: On Dec 10, 2013, at 1:27 PM, Zane Bitter wrote: On 10/12/13 12:46, Richard Lee wrote: Hey all, We're working on a blueprint <https://blueprints.launc

Re: [openstack-dev] [Openstack][Heat] Creating an Openstack project using Heat

On 16/12/13 15:57, Sayaji Patil wrote: Hi, I have installed Openstack with heat using packstack. One thing I noticed is that the "Orchestration Heat" option is only available inside a project view. Is this by design ? My use case it to create a project with images, networks,routers and fire

[openstack-dev] [Heat] Neutron resources and hidden dependencies

At the design summit we had a discussion[1] about redesigning Neutron resources to avoid the need for hidden dependencies (that is to say, dependencies which cannot be inferred from the template). Since then we've got close to fixing one of those issues[2] (thanks Bartosz!), but the patch is c

Re: [openstack-dev] [Heat] hybrid cloud & bursting question

On 18/12/13 04:26, 이준원 wrote: Hi, stackers, I know only little about Heat, and I can't wholly follow recent discussions around multi-region support in this mailing list. Please help me understand the roadmap or plan about hybrid cloud and "bursting" in particular. I'd like to ask the following

Re: [openstack-dev] [Heat] Neutron resources and hidden dependencies

On 18/12/13 05:21, Thomas Herve wrote: At the design summit we had a discussion[1] about redesigning Neutron resources to avoid the need for hidden dependencies (that is to say, dependencies which cannot be inferred from the template). Since then we've got close to fixing one of those issues[2

Re: [openstack-dev] [Heat] Reducing pep8 ignores

On 22/01/14 06:23, Pavlo Shchelokovskyy wrote: Hi all, we have an approved blueprint that concerns reducing number of ignored PEP8 and openstack/hacking style checks for heat (https://blueprints.launchpad.net/heat/+spec/reduce-flake8-ignored-rules). I've been already warned that enabling some of

Re: [openstack-dev] [Heat] Reducing pep8 ignores

On 22/01/14 23:19, ZhiQiang Fan wrote: you can split H306 to several patches since it contains so much files. optional: It would be really nice if you can fix the unused import problem (if exist) in the same time, this seems can be checked via IDE That check is already enabled. On Wed, Jan

[openstack-dev] Reviewing reviewers

I don't know about other projects, but we in the Heat project are constantly on the lookout for people who can be converted into core reviewers. Inevitably part of that process is evaluating whether someone has developed the depth of knowledge of the code that would allow them to catch a reason

[openstack-dev] [Heat] How to model resources in Heat

I've noticed a few code reviews for new Heat resource types - particularly Neutron resource types - where folks are struggling to find the appropriate way to model the underlying API in Heat. This is a really hard problem, and is often non-obvious even to Heat experts, so here are a few tips th

Re: [openstack-dev] [Heat] How to model resources in Heat

On 29/01/14 19:40, Jay Pipes wrote: On Wed, 2014-01-29 at 18:55 -0500, Zane Bitter wrote: I've noticed a few code reviews for new Heat resource types - particularly Neutron resource types - where folks are struggling to find the appropriate way to model the underlying API in Heat. This

Re: [openstack-dev] [Heat] About LaunchConfiguration and Autoscaling

On 30/01/14 06:01, Thomas Herve wrote: Hi all, While talking to Zane yesterday, he raised an interesting question about whether or not we want to keep a LaunchConfiguration object for the native autoscaling resources. The LaunchConfiguration object basically holds properties to be able to fir

Re: [openstack-dev] [Heat] How to model resources in Heat

On 30/01/14 16:54, Clint Byrum wrote: I'm pretty sure it is useful to model images in Heat. Consider this scenario: resources: build_done_handle: type: AWS::CloudFormation::WaitConditionHandle build_done: type: AWS::CloudFormation::WaitCondition properties: handle:

Re: [openstack-dev] [Heat] About LaunchConfiguration and Autoscaling

On 30/01/14 12:20, Randall Burt wrote: On Jan 30, 2014, at 12:09 PM, Clint Byrum wrote: >I would hope we would solve that at a deeper level, rather than making >resources for the things we think will need re-use. I think nested stacks >allow this level of re-use already anyway. Software conf

Re: [openstack-dev] [Heat] [TripleO] Rolling updates spec re-written. RFC

On 03/02/14 17:09, Clint Byrum wrote: Excerpts from Thomas Herve's message of 2014-02-03 12:46:05 -0800: So, I wrote the original rolling updates spec about a year ago, and the time has come to get serious about implementation. I went through it and basically rewrote the entire thing to reflect

Re: [openstack-dev] [Heat] [TripleO] Rolling updates spec re-written. RFC

On 04/02/14 20:34, Robert Collins wrote: On 5 February 2014 13:14, Zane Bitter wrote: That's not a great example, because one DB server depends on the other, forcing them into updating serially anyway. I have to say that even in general, this whole idea about applying update policies t

Re: [openstack-dev] [Heat] [TripleO] Rolling updates spec re-written. RFC

On 05/02/14 11:39, Clint Byrum wrote: Excerpts from Zane Bitter's message of 2014-02-04 16:14:09 -0800: On 03/02/14 17:09, Clint Byrum wrote: UpdatePolicy in cfn is a single string, and causes very generic rolling Huh? http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribu

Re: [openstack-dev] Asynchrounous programming: replace eventlet with asyncio

On 06/02/14 13:22, Joshua Harlow wrote: Has there been any investigation into heat. Heat has already used parts of the coroutine approach (for better or worse). An example: https://github.com/openstack/heat/blob/master/heat/engine/scheduler.py#L230 """ Decorator for a task that needs to d

Re: [openstack-dev] Asynchrounous programming: replace eventlet with asyncio

On 04/02/14 13:53, Kevin Conway wrote: On 2/4/14 12:07 PM, "victor stinner" wrote: >The purpose of replacing eventlet with asyncio is to get a well defined >control flow, no more surprising task switching at random points. I disagree with this. Eventlet and gevent yield the execution context

Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core

On 09/02/14 17:38, Steve Baker wrote: I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.

Re: [openstack-dev] [heat] Can heat automatically create a flavor as part of stack creation?

On 09/02/14 03:09, Robert Collins wrote: In principle yes. You need: - to write a module to orchestrate the nova flavor API. https://wiki.openstack.org/wiki/Heat/Plugins - to configure your policy rules in the cloud in question to let the heat engine user create flavors Not quite. Heat

Re: [openstack-dev] [Heat][docs] Need more sample HOT templates for users

On 14/02/14 03:21, Qiming Teng wrote: On Fri, Feb 14, 2014 at 08:24:09AM +0100, Thomas Spatzier wrote: Thanks, Thomas. The first link actually provides a nice inventory of all Resources and their properties, attributes, etc. I didn't look into this because I was thinking of the word 'developer

Re: [openstack-dev] [Heat] Thoughts on adding a '--progress' option?

On 28/02/14 02:28, Qiming Teng wrote: The creation a stack is usually a time costly process, considering that there are cases where software packages need to be installed and configured. There are also cases where a stack consists of more than one VM instance and the dependency between instance

Re: [openstack-dev] Climate Incubation Application

On 03/03/14 12:32, Joe Gordon wrote: >- if you're reserving resources far before you'll need them, it'll be >cheaper Why? How does this save a provider money? If an operator has zero information about the level of future demand, they will have to spend a *lot* of money on excess capacity or r

Re: [openstack-dev] Incubation Request: Murano

On 25/02/14 05:08, Thierry Carrez wrote: The second challenge is that we only started to explore the space of workload lifecycle management, with what looks like slightly overlapping solutions (Heat, Murano, Solum, and the openstack-compatible PaaS options out there), and it might be difficult, o

Re: [openstack-dev] Incubation Request: Murano

On 04/03/14 00:04, Georgy Okrokvertskhov wrote: First of all let me highlight that Murano DSL was much inspired by TOSCA. We carefully read this standard before our movement to Murano DSL. TOSCA standard has a lot f of very well designed concepts and ideas which we reused in Murano. There is one

Re: [openstack-dev] [Heat] Order of machines to be terminated during scale down

On 26/11/14 09:13, Maish Saidel-Keesing wrote: Thanks Pavlo. Is there any reason why FIFO was chosen? I believe that this was the original termination policy on AWS, and that was the reason we chose it. It was used on AWS because if you deleted an instance that was just created you would be

Re: [openstack-dev] [nova] Proposal new hacking rules

On 26/11/14 09:33, Louis Taylor wrote: On Wed, Nov 26, 2014 at 08:54:35AM -0500, Jay Pipes wrote: It's not about an equality condition. It's about the message that is produced by testtools.TestCase.assertEqual(), and the helpfulness of that message when the order of the arguments is reversed.

Re: [openstack-dev] [heat] [CustomResource] LifeCycle methods flow

On 26/11/14 05:20, Pradip Mukhopadhyay wrote: Hello, Any pointer (document and/or code pointer) related to how the different overridden methods are getting called when a custom resource is getting deployed in the heat stack? Basically just tried to annotate the h-eng log on a simple, very-fi

[openstack-dev] [Heat] Convergence proof-of-concept showdown

A bunch of us have spent the last few weeks working independently on proof of concept designs for the convergence architecture. I think those efforts have now reached a sufficient level of maturity that we should start working together on synthesising them into a plan that everyone can forge ah

Re: [openstack-dev] [Heat] Using Job Queues for timeout ops

On 13/11/14 13:59, Clint Byrum wrote: I'm not sure we have the same understanding of AMQP, so hopefully we can clarify here. This stackoverflow answer echoes my understanding: http://stackoverflow.com/questions/17841843/rabbitmq-does-one-consumer-block-the-other-consumers-of-the-same-queue Not

  1   2   3   4   5   6   7   8   9   >