Re: [openstack-dev] [Heat] Rework auto-scaling support in Heat

On 28/11/14 02:33, Qiming Teng wrote: Dear all, Auto-Scaling is an important feature supported by Heat and needed by many users we talked to. There are two flavors of AutoScalingGroup resources in Heat today: the AWS-based one and the Heat native one. As more requests coming in, the team has p

Re: [openstack-dev] [Heat] Rework auto-scaling support in Heat

On 01/12/14 18:34, Angus Salkeld wrote: I'd suggest a combination between A and B. We may not be as far apart as I thought. 1) Separate some of the autoscaling logic into libraries in Heat 2) Get the separated REST service in place and working (using the above heat library) 3) Add an environm

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

On 01/12/14 02:02, Anant Patil wrote: On GitHub:https://github.com/anantpatil/heat-convergence-poc I'm trying to review this code at the moment, and finding some stuff I don't understand: https://github.com/anantpatil/heat-convergence-poc/blob/master/heat/engine/stack.py#L911-L916 This appe

Re: [openstack-dev] [Mistral] Query on creating multiple resources

On 08/12/14 09:41, Sushma Korati wrote: Can we create multiple resources using a single task, like multiple keypairs or security-groups or networks etc? Define them in a Heat template and create the Heat stack as a single task. - ZB ___ OpenStack-de

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

On 08/12/14 07:00, Murugan, Visnusaran wrote: Hi Zane & Michael, Please have a look @ https://etherpad.openstack.org/p/execution-stream-and-aggregator-based-convergence Updated with a combined approach which does not require persisting graph and backup stack removal. Well, we still have to

Re: [openstack-dev] [Mistral] Query on creating multiple resources

On 09/12/14 03:48, Renat Akhmerov wrote: Hey, I think it’s a question of what the final goal is. For just creating security groups as a resource I think Georgy and Zane are right, just use Heat. If the goal is to try Mistral or have this simple workflow as part of more complex then it’s total

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

You really need to get a real email client with quoting support ;) On 10/12/14 06:42, Murugan, Visnusaran wrote: Well, we still have to persist the dependencies of each version of a resource _somehow_, because otherwise we can't know how to clean them up in the correct order. But what I think

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

On 11/12/14 01:14, Anant Patil wrote: On 04-Dec-14 10:49, Zane Bitter wrote: On 01/12/14 02:02, Anant Patil wrote: On GitHub:https://github.com/anantpatil/heat-convergence-poc I'm trying to review this code at the moment, and finding some stuff I don't understand: https://

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

On 11/12/14 08:26, Murugan, Visnusaran wrote: [Murugan, Visnusaran] In case of rollback where we have to cleanup earlier version of resources, we could get the order from old template. We'd prefer not to have a graph table. In theory you could get it by keeping old templates around. But that me

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

On 12/12/14 05:29, Murugan, Visnusaran wrote: -Original Message- From: Zane Bitter [mailto:zbit...@redhat.com] Sent: Friday, December 12, 2014 6:37 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Heat] Convergence proof-of-concept showdown On 11/12/14 08:26

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

On 15/12/14 09:32, Anant Patil wrote: On 12-Dec-14 06:29, Zane Bitter wrote: On 11/12/14 01:14, Anant Patil wrote: On 04-Dec-14 10:49, Zane Bitter wrote: On 01/12/14 02:02, Anant Patil wrote: On GitHub:https://github.com/anantpatil/heat-convergence-poc I'm trying to review this code a

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

post operation if Rollback==True) 3. DELETE will be just another update with an empty to_be_realized_graph. Yes, that goes without saying. In my implementation Stack._create_or_update() handles all three operations. It would be great if we can freeze a stable approach by mid-week as Christmas

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

On 15/12/14 10:15, Anant Patil wrote: On 13-Dec-14 05:42, Zane Bitter wrote: On 12/12/14 05:29, Murugan, Visnusaran wrote: -Original Message- From: Zane Bitter [mailto:zbit...@redhat.com] Sent: Friday, December 12, 2014 6:37 AM To: openstack-dev@lists.openstack.org Subject: Re

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

On 17/12/14 13:05, Gurjar, Unmesh wrote: I'm storing a tuple of its name and database ID. The data structure is resource.GraphKey. I was originally using the name for something, but I suspect I could probably drop it now and just store the database ID, but I haven't tried it yet. (Having the name

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

On 15/12/14 07:47, Murugan, Visnusaran wrote: We have similar questions regarding other areas in your implementation, which we believe if we understand the outline of your implementation. It is difficult to get a hold on your approach just by looking at code. Docs strings / Etherpad will help.

Re: [openstack-dev] Fw: [Heat] Multiple_Routers_Topoloy

The -dev mailing list is not for usage questions. Please post your question to ask.openstack.org and include the text of the error message you when trying to add a RouterInterface. cheers, Zane. On 22/12/14 04:18, Rao Shweta wrote: Hi All I am working on openstack Heat and i wanted to make

Re: [openstack-dev] [heat] Application level HA via Heat

On 22/12/14 13:21, Steven Hardy wrote: Hi all, So, lately I've been having various discussions around $subject, and I know it's something several folks in our community are interested in, so I wanted to get some ideas I've been pondering out there for discussion. I'll start with a proposal of h

Re: [openstack-dev] [heat] Application level HA via Heat

On 24/12/14 05:17, Steven Hardy wrote: On Mon, Dec 22, 2014 at 03:42:37PM -0500, Zane Bitter wrote: On 22/12/14 13:21, Steven Hardy wrote: Hi all, So, lately I've been having various discussions around $subject, and I know it's something several folks in our community are intereste

Re: [openstack-dev] [Heat] Precursor to Phase 1 Convergence

On 09/01/15 01:07, Angus Salkeld wrote: I am not in favor of the --continue as an API. I'd suggest responding to resource timeouts and if there is no response from the task, then re-start (continue) the task. Yeah, I am not in favour of a new API either. In fact, I believe we already have this

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

On 08/01/15 05:39, Anant Patil wrote: 1. The stack was failing when there were single disjoint resources or just one resource in template. The graph did not include this resource due to a minor bug in dependency_names(). I have added a test case and fix here: https://github.com/anantpatil/heat-co

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

On 12/01/15 10:49, Ryan Brown wrote: On 01/12/2015 10:29 AM, Tomas Sedovic wrote: Hey folks, I did a quick proof of concept for a part of the Stack Breakpoint spec[1] and I put the "does this resource have a breakpoint" flag into the metadata of the resource: https://review.openstack.org/#/c/1

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

On 12/01/15 13:05, Steven Hardy wrote: >I also had a chat with Steve Hardy and he suggested adding a STOPPED state >to the stack (this isn't in the spec). While not strictly necessary to >implement the spec, this would help people figure out that the stack has >reached a breakpoint instead of jus

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

On 13/01/15 11:58, Tomas Sedovic wrote: I also had a chat with Steve Hardy and he suggested adding a STOPPED state to the stack (this isn't in the spec). While not strictly necessary to implement the spec, this would help people figure out that the stack has reached a breakpoint instead of just w

Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

On 13/01/15 10:01, Jeremy Stanley wrote: On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote: Why doesn't rally just remove itself from projects.txt, then there would be no restrictions on what it adds. I second this recommendation. If Rally wants to depend on things which are not part of O

[openstack-dev] [Heat] Final steps toward a Convergence design

Hi folks, I'd like to come to agreement on the last major questions of the convergence design. I well aware that I am the current bottleneck as I have been struggling to find enough time to make progress on it, but I think we are now actually very close. I believe the last remaining issue to

[openstack-dev] [Heat] Convergence Phase 1 implementation plan

I've mentioned this in passing a few times, but I want to lay it out here in a bit more detail for comment. Basically we're implementing convergence at a time when we still have a lot of 'unit' tests that are really integration tests, and we don't want to have to rewrite them to anticipate this

Re: [openstack-dev] [heat][hot]

On 25/01/15 10:41, Dmitry wrote: Hello, I need to receive instance id as part of the instance installation script. Something like: params: $current_id: {get_param: $this.id } I have no idea what this is supposed to mean, sorry. Is it possible? The get_resource fun

Re: [openstack-dev] [Heat][Summit] Input wanted - real world heat spec

On 23/04/14 20:45, Robert Collins wrote: Hi, we've got this summit session planned - http://summit.openstack.org/cfp/details/428 which is really about https://etherpad.openstack.org/p/heat-workflow-vs-convergence We'd love feedback and questions - this is a significant amount of work, but work I

Re: [openstack-dev] [Heat] Juno Design Summit sessions

A preliminary schedule is available now at: http://junodesignsummit.sched.org/type/heat If anybody has feedback or notices any obvious conflicts (you might have to wait until Monday for all of the tracks to be scheduled), please let me know. cheers, Zane. On 17/04/14 18:14, Zane Bitter

Re: [openstack-dev] [Heat] looking to add support for server groups to heat...any comments?

On 25/04/14 12:23, Chris Friesen wrote: I'm looking to add support for server groups to heat. I've got working code, but I thought I'd post the overall design here in case people had objections. Basically, what I propose is to add a "class NovaServerGroup" resource. Currently it would only s

Re: [openstack-dev] [Trove][Heat] Use cases required for Trove

On 25/04/14 08:30, Denis Makogon wrote: Hello Trove/Heat community. I'd like to start thread related to required use cases (from Trove perspective). To support (completely) Heat in Trove, it neeeds to support required operations like: 1. Resize operations: - resize a volume (to bi

Re: [openstack-dev] [Heat] looking to add support for server groups to heat...any comments?

On 25/04/14 13:50, Chris Friesen wrote: On 04/25/2014 11:01 AM, Mike Spreitzer wrote: Zane Bitter wrote on 04/25/2014 12:36:00 PM: > On 25/04/14 12:23, Chris Friesen wrote: More important is Zane's following question. > > The "Server" class would be e

Re: [openstack-dev] [Heat] looking to add support for server groups to heat...any comments?

On 25/04/14 16:07, Chris Friesen wrote: On 04/25/2014 12:00 PM, Zane Bitter wrote: On 25/04/14 13:50, Chris Friesen wrote: In the nova boot command we pass the group uuid like this: --hint group=e4cf5dea-4831-49a1-867d-e263f2579dd0 If we were to make use of the scheduler hints, how would

[openstack-dev] [Heat] No meeting this week

Since this is the designated "off" week, I'm going to cancel this week's IRC meeting. By happy coincidence, that will give us until after Summit to decide on a new alternate meeting time :) The next meeting will be on the 7th of May, at the regular time (2000 UTC). cheers, Zane. _

Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)

On 05/05/14 13:40, Solly Ross wrote: One thing that I was discussing with @jaypipes and @dansmith over on IRC was the possibility of breaking flavors down into separate components -- i.e have a disk flavor, a CPU flavor, and a RAM flavor. This way, you still get the control of the size of your bu

[openstack-dev] [Mistral][Heat] Feedback on the Mistral DSL

Hi Mistral folks, Congrats on getting the 0.0.2 release out. I had a look at Renat's screencast and the examples, and I wanted to share some feedback based on my experience with Heat. Y'all will have to judge for yourselves to what extent this experience is applicable to Mistral. (Assume that

Re: [openstack-dev] [heat] How to cross-reference resources within OS::Heat::ResourceGroup

On 06/05/14 16:07, Janczuk, Tomasz wrote: Could this be accomplished with 3 resource groups instead of one? The first would create the ports, the second floating IPs, and the last the VMs? In that case, would there be a way to construct a reference to a particular instance of, say, a port, when c

Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)

On 20/05/14 12:17, Jay Pipes wrote: Hi Zane, sorry for the delayed response. Comments inline. On 05/06/2014 09:09 PM, Zane Bitter wrote: On 05/05/14 13:40, Solly Ross wrote: One thing that I was discussing with @jaypipes and @dansmith over on IRC was the possibility of breaking flavors down

[openstack-dev] [Heat] Meeting times for Juno

I know people are very interested in an update on this, so here's the plan such as it is. I'd like to reassure everyone that we will definitely be keeping our original meeting time of Wednesdays at 2000 UTC, every second week (including this week). I want to try out a new time for the altern

Re: [openstack-dev] [Openstack-docs] [Heat][Documentation] Heat template documentation

On 23/05/14 06:38, Andreas Jaeger wrote: On 05/23/2014 12:13 PM, Steven Hardy wrote: [...] I'll hold my hand up as one developer who tried to contribute but ran away screaming due to all the XML-java-ness of the current process. I don't think markup complexity is a major barrier to contribution

Re: [openstack-dev] Designate Incubation Request

On 28/05/14 14:52, Sean Dague wrote: I would agree this doesn't make sense in Neutron. I do wonder if it makes sense in the Network program. I'm getting suspicious of the programs for projects model if every new project incubating in seems to need a new program. Which isn't really a reflection o

Re: [openstack-dev] Designate Incubation Request

On 29/05/14 05:26, Thierry Carrez wrote: Sean Dague wrote: I honestly just think we might want to also use it as a time to rethink our program concept. Because all our programs that include projects that are part of the integrated release are 1 big source tree, and maybe a couple of little trees

Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup

On 29/05/14 13:33, Mike Spreitzer wrote: Devananda van der Veen wrote on 05/29/2014 01:26:12 PM: > Hi Jaromir, > > I agree that the midcycle meetup with TripleO and Ironic was very > beneficial last cycle, but this cycle, Ironic is co-locating its > sprint with Nova. Our focus needs to be

Re: [openstack-dev] [Glance] [Heat] Glance Metadata Catalog for Capabilities and Tags

On 29/05/14 18:42, Tripp, Travis S wrote: Hello everyone! At the summit in Atlanta we demonstrated the “Graffiti” project concepts. We received very positive feedback from members of multiple dev projects as well as numerous operators. We were specifically asked multiple times about getting th

Re: [openstack-dev] [Heat] Short term scaling strategies for large Heat stacks

On 29/05/14 19:52, Clint Byrum wrote: Multiple Stacks === We could break the stack up between controllers, and compute nodes. The controller will be less likely to fail because it will probably be 3 nodes for a reasonably sized cloud. The compute nodes would then live in their own st

[openstack-dev] [Heat] Blueprint process (heat-specs repo)

Last week we agreed[1] to follow that other project in setting up a specs repo.[2] (Many thanks to Ying, Monty and Clint for getting this up and running.) I'm still figuring out myself how this is going to work, but the basic idea seems to be this: - All new blueprints should be submitted as

Re: [openstack-dev] [heat] Resource action API

On 04/06/14 03:01, yang zhang wrote: Hi all, Now heat only supports suspending/resuming a whole stack, all the resources of the stack will be suspended/resumed, but sometime we just want to suspend or resume only a part of resources Any reason you wouldn't put that subset of resources into

Re: [openstack-dev] [Heat]Heat template parameters encryption

On 04/06/14 15:58, Vijendar Komalla wrote: Hi Devs, I have submitted an WIP review (https://review.openstack.org/#/c/97900/) for Heat parameters encryption blueprint https://blueprints.launchpad.net/heat/+spec/encrypt-hidden-parameters This quick and dirty implementation encrypts all the paramete

Re: [openstack-dev] [heat] Resource action API

On 05/06/14 03:32, yang zhang wrote: Thanks so much for your commits. > Date: Wed, 4 Jun 2014 14:39:30 -0400 > From: zbit...@redhat.com > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [heat] Resource action API > > On 04/06/14 03:01, yang zhang wrote: > > Hi all,

Re: [openstack-dev] [Marconi] Adopt Spec

On 05/06/14 12:03, Kurt Griffiths wrote: I just learned that some projects are thinking about having the specs process be the channel for submitting new feature ideas, rather than registering blueprints. I must admit, that would be kind of nice because it would provide some much-needed structure

[openstack-dev] [Heat] Reminder: meeting at alternate time this week

A lot of people forgot last time, so this is your reminder that this week the Heat IRC meeting will be held at the alternate time: Wednesday at 1200 UTC in #openstack-meeting or in your local time zone: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140611T12 cheers, Zane. __

[openstack-dev] [Heat][TripleO] Heat mid-cycle meetup

There has been a lot of interest in holding a Heat meetup during the Juno cycle. We have the opportunity to piggy-back on the TripleO meetup - and I expect at least some Heat developers to attend that - but we also know that some key people from both Heat and TripleO will be unable to attend (T

Re: [openstack-dev] [Trove] Heat integration

On 16/06/14 13:56, Nikhil Manchanda wrote: Denis Makogon writes: Because Trove should not do what it does now (cloud service orchestration is not the part of the OS Database Program). Trove should delegate all tasks to Cloud Orchestration Service (Heat). Agreed that Trove should delegate pro

Re: [openstack-dev] testr help

Thanks Clark for this great write-up. However, I think the solution to the problem in question is richer commands and better output formatting, not discarding information. On 07/03/14 16:30, Clark Boylan wrote: But running tests in parallel introduces some fun problems. Like where do you send

Re: [openstack-dev] Taskflow remote worker model ftw!

Cool, nice work Josh & team! On 10/03/14 17:23, Joshua Harlow wrote: This means that the engine no longer has to run tasks locally or in threads (or greenthreads) but can run tasks on remote machines (anything that can be connected to a MQ via kombu; TBD when this becomes oslo.messaging). Does

Re: [openstack-dev] testr help

On 10/03/14 16:04, Clark Boylan wrote: On Mon, Mar 10, 2014 at 11:31 AM, Zane Bitter wrote: Thanks Clark for this great write-up. However, I think the solution to the problem in question is richer commands and better output formatting, not discarding information. On 07/03/14 16:30, Clark

Re: [openstack-dev] [heat]Policy on upgades required config changes

On 11/03/14 01:05, Keith Bray wrote: We do run close to Heat master here at Rackspace, and we'd be happy to set up a non-voting job to notify when a review would break Heat on our cloud if that would be beneficial. Some of the breaks we have seen have been things that simply weren't caught in co

Re: [openstack-dev] testr help

On 10/03/14 20:29, Robert Collins wrote: Which bits look raw? It should only show text/* attachments, non-text should be named but not dumped. I was thinking of the: pythonlogging:'': {{{ part. - ZB ___ OpenStack-dev mailing list OpenStack-dev@lis

Re: [openstack-dev] [Heat] Stack breakpoint

On 17/03/14 17:03, Ton Ngo wrote: (reposting as new thread) I would like to revisit with more details an idea that was mentioned in the last design summit and hopefully get some feedback. The scenario is troubleshooting a failed template. Currently we can stop on the point of failure by disabl

Re: [openstack-dev] [Heat] Stack breakpoint

On 17/03/14 21:18, Mike Spreitzer wrote: Zane Bitter wrote on 03/17/2014 07:03:25 PM: > On 17/03/14 17:03, Ton Ngo wrote: > > - How to handle resources with timer, e.g. wait condition: pause/resume > > timer value > > Handle it by only allowing pauses before and

Re: [openstack-dev] [Murano][Heat] MuranoPL questions?

(I added a couple of tags to the subject; hope this doesn't screw up anyone's threading.) On 09/03/14 16:26, Joshua Harlow wrote: I'd be very interested in knowing the resource controls u plan to add. Memory, CPU... I'm still trying to figure out where something like https://github.com/istalke

Re: [openstack-dev] MuranoPL questions?

On 18/03/14 08:01, Ruslan Kamaldinov wrote: Joshua, Clint, The only platform I'm aware about which fully supports true isolation and which has been used in production for this purpose is Java VM. I know people who developed systems for online programming competitions and really smart kids tried

Re: [openstack-dev] [Nova][Heat] How to reliably detect VM failures?

On 18/03/14 12:42, Steven Dake wrote: On 03/18/2014 07:54 AM, Qiming Teng wrote: Hi, Folks, I have been trying to implement a HACluster resource type in Heat. I haven't created a BluePrint for this because I am not sure everything will work as expected. The basic idea is to extend the OS

Re: [openstack-dev] [Murano][Heat] MuranoPL questions?

On 19/03/14 05:00, Stan Lagun wrote: Steven, Agree with your opinion on HOT expansion. I see that inclusion of imperative workflows and ALM would require major Heat redesign and probably would be impossible without loosing compatibility with previous HOT syntax. It would blur Heat mission, confu

Re: [openstack-dev] [Nova][Heat] How to reliably detect VM failures?

On 19/03/14 02:07, Chris Friesen wrote: On 03/18/2014 11:18 AM, Zane Bitter wrote: On 18/03/14 12:42, Steven Dake wrote: You should be able to use the HARestarter resource and functionality to do healthchecking of a vm. HARestarter is actually pretty problematic, both in a "causes

Re: [openstack-dev] [Murano][Heat] MuranoPL questions?

On 19/03/14 17:13, Stan Lagun wrote: On Wed, Mar 19, 2014 at 9:18 PM, Zane Bitter mailto:zbit...@redhat.com>> wrote: On 19/03/14 05:00, Stan Lagun wrote: Steven, Agree with your opinion on HOT expansion. I see that inclusion of imperative workflows and ALM

Re: [openstack-dev] [Murano][Heat] MuranoPL questions?

I completely agree with Georgy, but you raised some questions about Heat that I want to answer in the interests of spreading knowledge about how Heat works. A heavily-snipped response follows... On 21/03/14 05:11, Stan Lagun wrote: 3. Despite HOT being more secure on the surface it is not nece

Re: [openstack-dev] [Murano][Heat] MuranoPL questions?

On 21/03/14 18:58, Stan Lagun wrote: Zane, I appreciate your explanations on Heat/HOT. This really makes sense. I didn't mean to say that MuranoPL is better for Heat. Actually HOT is good for Heat's mission. I completely acknowledge it. I've tried to avoid comparison between languages and I'm so

Re: [openstack-dev] [all] sample config files should be ignored in git...

On 26/03/14 14:10, Clint Byrum wrote: This is an issue that affects all of our git repos. If you are using oslo.config, you will likely also be using the sample config generator. However, for some reason we are all checking this generated file in. This makes no sense, as we humans are not editti

[openstack-dev] [Heat] PTL Candidacy

Greetings, fellow Heatists. My name is not Steve and I would like to announce my candidacy for the position of Orchestration PTL. Most of you, I hope, already know me. I've been working on Heat full-time essentially since the project started, and I've been a member of the core team since befor

Re: [openstack-dev] [heat] metadata for a HOT

On 02/04/14 16:45, Mike Spreitzer wrote: I would like to suggest that a metadata section be allowed at the top level of a HOT. Note that while resources in a stack can have metadata, there is no way to put metadata on a stack itself. What do you think? I think that if you're going to propose

[openstack-dev] [Oslo][Nova][Heat] Sample config generator issue

We have an issue in Heat where the sample config generator from Oslo is currently broken (see bug #1288586). Unfortunately it turns out that there is no fix to the generator script itself that can do the Right Thing for both Heat and Nova. A brief recap on how the sample config generator works

Re: [openstack-dev] [Heat] Some thoughts on the mapping section

On 03/04/14 03:21, Thomas Herve wrote: Speaking of offering options for selection, there is another proposal on >adding conditional creation of resources [3], whose use case to enable >or disable a resource creation (among others). My perception is that >these are all relevant enhancements to th

Re: [openstack-dev] [Oslo][Nova][Heat] Sample config generator issue

On 03/04/14 08:48, Doug Hellmann wrote: On Wed, Apr 2, 2014 at 9:55 PM, Zane Bitter wrote: We have an issue in Heat where the sample config generator from Oslo is currently broken (see bug #1288586). Unfortunately it turns out that there is no fix to the generator script itself that can do the

Re: [openstack-dev] [Heat] [TripleO] Better handling of lists in Heat - a proposal to add a map function

On 19/02/14 02:48, Clint Byrum wrote: Since picking up Heat and trying to think about how to express clusters of things, I've been troubled by how poorly the CFN language supports using lists. There has always been the Fn::Select function for dereferencing arrays and maps, and recently we added a

Re: [openstack-dev] [TripleO] [Heat] TripleO Heat Templates and merge.py

On 04/04/14 13:58, Clint Byrum wrote: >We could keep roughly the same structure: a separate template for each >OpenStack service (compute, block storage, object storage, ironic, nova >baremetal). We would then use Heat environments to treat each of these >templates as a custom resource (e.g. OS::

Re: [openstack-dev] [Murano][Heat] MuranoPL questions?

I was just going to let this thread die, because it's clear that we're just approaching this from different philosophical viewpoints, and I think that we need _both_ viewpoints expressed in the community. Trying to change each other's mind would be as pointless as it is futile ;) That said, it

Re: [openstack-dev] [heat] Managing changes to the Hot Specification (hot_spec.rst)

On 06/04/14 14:23, Steven Dake wrote: Hi folks, There are two problems we should address regarding the growth and change to the HOT specification. First our +2/+A process for normal changes doesn't totally make sense for hot_spec.rst. We generally have some informal bar for controversial chang

[openstack-dev] [Neutron][Heat] The Neutron API and orchestration

The Neutron API is a constant cause of pain for us as Heat developers, but afaik we've never attempted to bring up the issues we have found in a cross-project forum. I've recently been doing some more investigation and I want to document the exact ways in which the current Neutron API breaks or

Re: [openstack-dev] [Neutron][Heat] The Neutron API and orchestration

at we can claim is Not Our Fault. I would still prefer to see some sort of interface that results in the dependencies mentioned above occurring naturally in the template - the alternative is to heavily document how to do this yourself using get_attr to get, e.g. the IP address of a Serve

Re: [openstack-dev] [Neutron][Heat] The Neutron API and orchestration

On 07/04/14 21:58, Nachi Ueno wrote: Hi Zane Thank you for your very valuable post. We should convert your suggest to multiple bps. 2014-04-07 17:28 GMT-07:00 Zane Bitter : The Neutron API is a constant cause of pain for us as Heat developers, but afaik we've never attempted to bring u

Re: [openstack-dev] [Neutron][Heat] The Neutron API and orchestration

On 09/04/14 19:20, Kevin Benton wrote: >is definitely broken as far as I can tell, because you have to give up dynamic allocation of IP addresses to use it What do you mean you have to give up dynamic allocation of IP addresses? A user is never required to enter an IP address for a port if they

Re: [openstack-dev] [heat] Custom Resource

On 14/04/14 07:01, Steven Hardy wrote: Hi Rabi, On Mon, Apr 14, 2014 at 06:44:44AM -0400, Rabi Mishra wrote: Hi All, Recently, I've come across some requirements for external integrations/resources that can be managed like stack resources (create,update,delete) from the stack. 1. Adding/Rem

Re: [openstack-dev] [heat] Custom Resource

On 14/04/14 13:40, Steven Hardy wrote: It's not clear to me why you'd even expect that $third_party_system knows how to receive SNS notifications, so you might instead want to fire up a VM with some client on it which knows how to talk to the service directly and act as a proxy, with lifecycle ev

Re: [openstack-dev] [heat] computed package names?

On 15/04/14 14:31, Mike Spreitzer wrote: It appears that in Fedora 19 and 20 the Wordpress examples need to install different packages than in every other release (see my debugging in https://review.openstack.org/#/c/87065/). I just got a complaint from Heat validation that I can't do this:

Re: [openstack-dev] [heat] computed package names?

On 15/04/14 15:57, Mike Spreitzer wrote: Zane Bitter wrote on 04/15/2014 03:29:03 PM: > On 15/04/14 14:31, Mike Spreitzer wrote: > > It appears that in Fedora 19 and 20 the Wordpress examples need to > > install different packages than in every other release (see my debuggin

Re: [openstack-dev] [heat] Re: deliver the vm-level HA to improve the business continuity with openstack

On 15/04/14 06:16, Qiming Teng wrote: 3) Can/should we do the VM HA orchestration in Heat? My perception is that it can be done in Heat, based on my limited understandig of how Heat works. It may imply some requirements to other projects (e.g. nova, cinder, neutron ...) as well, though Heat sh

Re: [openstack-dev] [heat] computed package names?

On 15/04/14 17:59, Mike Spreitzer wrote: Clint Byrum wrote on 04/15/2014 05:17:21 PM: > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700: > > > FWIW, in the short term I'm not aware of any issue with installing > > mariadb in Fedora 17/18, provided that mysql is not installed

Re: [openstack-dev] [heat][mistral] Mistral agenda item for Heat community meeting on Apr 17

On 16/04/14 10:29, Renat Akhmerov wrote: Can we include action item “Heat/Mistral collaboration” into the agenda of tomorrow’s Heat community meeting? I’d like to take a few minutes and discuss this a little bit. If you think it’s not a suitable time/way to discuss it please let me know your p

Re: [openstack-dev] [heat] computed package names?

On 16/04/14 05:53, Thomas Spatzier wrote: IMO, it would be desirable to not have things like yum or apt appear in the template explicitly. For many packages it seems like at least the top level package names (not including distro specific versioning strings) are equal across distros so when speci

[openstack-dev] [Heat] Juno Design Summit sessions

A few reminders about design summit sessions for Heat... * The deadline for proposals is the 20th of April, i.e. the end of this week. Get your proposals in now. * The Design Summit isn't the place to introduce feature proposals. The place to introduce proposals is the mailing list and there'

Re: [openstack-dev] [heat][mistral] Mistral agenda item for Heat community meeting on Apr 17

On 17/04/14 00:34, Renat Akhmerov wrote: Ooh, I confused the day of meeting :(. My apologies, I’m in a completely different timezone (for me it’s in the middle of night) so I strongly believed it was on a different day. I’ll be there next time. Yeah, it's really unfortunate that it falls righ

[openstack-dev] Proposing Thomas Spatzier for heat-core

I'd like to propose that we add Thomas Spatzier to the heat-core team. Thomas has been involved in and consistently contributing to the Heat community for around a year, since the time of the Havana design summit. His code reviews are of extremely high quality IMO, and he has been reviewing at

Re: [openstack-dev] [Heat] Proposing Thomas Spatzier for heat-core

Resending with [Heat] in the subject line. My bad. On 22/04/14 14:21, Zane Bitter wrote: I'd like to propose that we add Thomas Spatzier to the heat-core team. Thomas has been involved in and consistently contributing to the Heat community for around a year, since the time of the Havana d

Re: [openstack-dev] [Heat] Proposing Thomas Spatzier for heat-core

On 23/04/14 04:14, Thomas Spatzier wrote: Hi all, I just realized during a review that I see a couple of more options, so this poll seems to be thru already ;-) Yep, I updated the list yesterday :) Thank you all for your support! I'm glad to be part of this great team! Congrats, and keep u

[openstack-dev] [Heat] Meeting time redux

At the beginning of this year we introduced alternating times for the Heat weekly IRC meeting, in the hope that our contributors in Asia would be able to join us. The consensus is that this hasn't worked out as well as we had hoped - even the new time falls at 8am in Beijing, so folks are regul

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

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_ s

Re: [openstack-dev] [Heat][Zaqar] Integration plan moving forward

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" mailto:fla...@redhat.com>> wrote: Greetings, If I recall correctly, Heat was planning to adopt Zaqa

Re: [openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator

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 StackFo

Re: [openstack-dev] [Heat] naming of provider template for docs

On 19/09/14 01:10, Mike Spreitzer wrote: Angus Salkeld 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 term, he thinks "provider

<    1   2   3   4   5   6   7   8   9   >