Re: [openstack-dev] [heat][yaql] Heat map replacement options

On 19/07/16 11:04, Steven Hardy wrote: On Fri, Jul 15, 2016 at 10:25:39AM +0100, Steven Hardy wrote: Hi all, I'm trying to figure out the cleanest way to do a replacement of values in a mapping (json parameter) in a heat template, e.g: ServiceNetMap: type: json default:

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

On 14/07/16 16:30, Fox, Kevin M wrote: I'm going to go ahead and ask the difficult question now as the answer is relevant to the attached proposal... Should we reconsider whether the big tent is the right approach going forward? There have been some major downsides I think to the Big Tent

Re: [openstack-dev] [Heat][Senlin] Deprecation roadmap for Heat's Autoscaling resources?

On 04/07/16 08:06, Johannes Grassler wrote: Hello, I just noticed the note at the top of : | The content on this page is obsolete. The autoscaling solution is offloaded from Heat to Senlin since Mitaka. That isn't a page about how

Re: [openstack-dev] RHEL free for developer use

On 22/06/16 03:33, Jeremy Stanley wrote: On 2016-06-21 14:48:58 +0200 (+0200), Zane Bitter wrote: That isn't my understanding, but it's hard to give a definitive answer without knowing what kinds of non-free software you're referring to (since I know there have been fierce disagreements even

Re: [openstack-dev] [all] Proposal: Architecture Working Group

On 20/06/16 19:27, Clint Byrum wrote: Excerpts from Doug Wiegley's message of 2016-06-20 10:40:56 -0600: So, it sounds like you’ve just described the job of the TC. It may sound like that, but the TC have repeatedly (and perhaps wisely) disclaimed that as part of their job. So any attempt to

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

On 20/06/16 18:50, Jeremy Stanley wrote: On 2016-06-20 18:43:44 +0200 (+0200), Zane Bitter wrote: The binaries are free-as-in-beer - IIUC you can't redistribute them. The source code, of course, remains free-as-in-speech as it has always been. (It's easy to forget the distinction when you work

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

On 16/06/16 23:04, Jeremy Stanley wrote: On 2016-06-16 16:04:28 -0400 (-0400), Steve Gordon wrote: [...] This is definitely a point worth clarifying in the general case, but tangentially for the specific case of the RHEL operating system please note that RHEL is available to developers for

Re: [openstack-dev] [magnum][heat] spawn a group of nodes on different availability zones

][heat] spawn a group of nodes on different availability zones On Wed, Mar 02, 2016 at 05:40:20PM -0500, Zane Bitter wrote: On 02/03/16 05:50, Mathieu Velten wrote: Hi all, I am looking at a way to spawn nodes in different specified availability zones when deploying a cluster with Magnum

Re: [openstack-dev] [heat][TripleO] Adding interfaces to environment files?

On 07/06/16 15:57, Jay Dobies wrote: 1. Now that we support passing un-merged environment files to heat, it'd be good to support an optional description key for environments, I've never understood why the environment file doesn't have a description field itself. Templates have descriptions,

[openstack-dev] [TripleO][Kolla][Heat][Higgins][Magnum][Kuryr] Gap analysis: Heat as a k8s orchestrator

I spent a bit of time exploring the idea of using Heat as an external orchestration layer on top of Kubernetes - specifically in the case of TripleO controller nodes but I think it could be more generally useful too - but eventually came to the conclusion it doesn't work yet, and probably

Re: [openstack-dev] [tripleo] Zaqar messages standardization

On 26/05/16 09:42, Dmitry Tantsur wrote: On 05/25/2016 08:08 PM, Thomas Herve wrote: On Fri, May 20, 2016 at 5:52 PM, Jiri Tomasek wrote: Hey all, I've been recently working on getting the TripleO UI integrated with Zaqar, so it can receive a messages from Mistral

Re: [openstack-dev] [Mistral][Zaqar][Ceilometer][Searchlight] Triggering Mistral workflows from Zaqar messages

of features across projects, but in even know what is being planned in other projects. Perhaps we need some sort of "Autonomous Applications working group"? cheers, Zane. Regards! --- Lingxian Kong On Fri, May 20, 2016 at 9:49 AM, Zane Bitter <zbit...@redh

Re: [openstack-dev] [Mistral][Zaqar] Triggering Mistral workflows from Zaqar messages

On 19/05/16 04:20, Thomas Herve wrote: On Wed, May 18, 2016 at 8:49 PM, Zane Bitter <zbit...@redhat.com> wrote: I've been lobbying the Mistral developers for $SUBJECT since, basically, forever.[1][2][3] I like to think after a couple of years I succeeded in changing their view on it from

Re: [openstack-dev] [Heat] Versioned objects upgrade patterns

On 17/05/16 20:27, Crag Wolfe wrote: Now getting very Heat-specific. W.r.t. to https://review.openstack.org/#/c/303692/ , the goal is to de-duplicate raw_template.files (this is a dict of template filename to contents), both in the DB and in RAM. The approach this patch is taking is that, when

[openstack-dev] [Mistral][Zaqar] Triggering Mistral workflows from Zaqar messages

I've been lobbying the Mistral developers for $SUBJECT since, basically, forever.[1][2][3] I like to think after a couple of years I succeeded in changing their view on it from "crazy" to merely "unrealistic".[4] In the last few months I've had a couple of realisations though: 1) The 'pull'

Re: [openstack-dev] [Heat] Versioned objects upgrade patterns

On 17/05/16 15:40, Crag Wolfe wrote: Another thing I am wondering about: if my particular object is not exposed by RPC, is it worth making it a full blown o.vo or not? I.e, I can do the 3 steps over 3 releases just in the object's .py file -- what additional value do I get from o.vo? It's more

Re: [openstack-dev] [oslo][mistral] Saga of process than ack and where can we go from here...

Another data point: at this summit session we discussed delivering to users notifications about events in the cloud: https://etherpad.openstack.org/p/newton-alternatives-to-polling It's pretty critical that this have at-least-once delivery semantics, because in future people will be using

Re: [openstack-dev] [Heat] Summit recap

On 09/05/16 09:44, Julien Danjou wrote: On Mon, May 09 2016, Thomas Herve wrote: […] Using DLM We managed to not talk about ZooKeeper too much :). We want to remove the database locks that we have and use tooz instead. The key is to provide a nice upgrade path, so starting

Re: [openstack-dev] [heat]Provides different stack quota to tenant

On 09/05/16 12:36, Sylvernass Arthas wrote: Excerpts from Sylvernass Arthas's message of 2016-05-08 05:33:13 -0700: Hi, guys Now, all tenant share the public config "max_stacks_per_tenant" which decides maximum number of stacks any one tenant may have active at one time, the default

Re: [openstack-dev] [heat]informal meetup during summit

ow if you're coming, just for easy pre-booking purpose:) On Apr 22, 2016 12:13 AM, "Zane Bitter" <zbit...@redhat.com <mailto:zbit...@redhat.com>> wrote: On 20/04/16 13:00, Rico Lin wrote: Hi team Let plan for more informal meetup(relax) time! Let all hea

Re: [openstack-dev] [Heat][Horizon] Liberty horizon and get_file workaround?

On 22/04/16 01:06, Jason Pascucci wrote: Hi, I wanted to add my yaml as new resources (via /etc/heat/environment.d/default.yaml, but we use some external files in the OS::Nova::Server personality section. I think you're describing this bug: https://bugs.launchpad.net/heat/+bug/1454401

Re: [openstack-dev] [heat]informal meetup during summit

On 20/04/16 13:00, Rico Lin wrote: Hi team Let plan for more informal meetup(relax) time! Let all heaters and any other projects can have fun and chance for technical discussions together. After discuss in meeting, we will have a pre-meetup-meetup on Friday morning to have a cup of cafe or some

Re: [openstack-dev] [tripleo][heat] Summit session clashes

On 19/04/16 18:04, Steve Baker wrote: On 19/04/16 20:29, Steven Hardy wrote: On Tue, Apr 19, 2016 at 04:24:46PM +1200, Steve Baker wrote: All of the TripleO design summit sessions are on Thursday afternoon in slots which clash with Heat sessions. Heat is a core component of TripleO

Re: [openstack-dev] [heat] convergence cancel messages

On 17/04/16 00:44, Anant Patil wrote: I think it is a good idea, but I see that a resource can be marked unhealthy only after it is done. Currently, yes. The idea would be to change that so that if it finds the resource IN_PROGRESS then it kills the thread and makes

Re: [openstack-dev] [heat] convergence cancel messages

On 15/04/16 10:58, Anant Patil wrote: On 14-Apr-16 23:09, Zane Bitter wrote: On 11/04/16 04:51, Anant Patil wrote: After lot of ping-pong in my head, I have taken a different approach to implement stack-update-cancel when convergence is on. Polling for traversal update in each heat engine

Re: [openstack-dev] [heat] upgrade options for custom heat resource plug-ins

On 11/04/16 14:06, Praveen Yalagandula wrote: Hi, We are developing a custom heat resource plug-in and wondering about how to handle plug-in upgrades. As our product's object model changes with new releases, we will need to release updated resource plug-in code too. So, in the first instance,

Re: [openstack-dev] [heat] convergence cancel messages

On 11/04/16 04:51, Anant Patil wrote: On 14-Mar-16 14:40, Anant Patil wrote: On 24-Feb-16 22:48, Clint Byrum wrote: Excerpts from Anant Patil's message of 2016-02-23 23:08:31 -0800: Hi, I would like the discuss various approaches towards fixing bug https://launchpad.net/bugs/1533176 When

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

On 03/04/16 21:38, Dan Prince wrote: On Mon, 2016-03-21 at 16:14 -0400, Zane Bitter wrote: As of the Liberty release, Magnum now supports provisioning Mesos clusters, so TripleO wouldn't have to maintain the installer for that either. (The choice of Mesos is somewhat unfortunate in our case

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On 01/04/16 12:31, Steven Hardy wrote: On Fri, Apr 01, 2016 at 04:15:30PM +0200, Thomas Herve wrote: On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter <zbit...@redhat.com> wrote: On 31/03/16 18:10, Zane Bitter wrote: I'm in favour of some sort of variable-based implementation for a few r

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On 05/04/16 06:43, Steven Hardy wrote: On Fri, Apr 01, 2016 at 04:39:02PM +, Fox, Kevin M wrote: Why is imperative programming always brought up when discussing conditionals in the templates? We are not wanting anything imperative. The heat engine still picks the final ordering

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On 01/04/16 10:15, Thomas Herve wrote: On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter <zbit...@redhat.com> wrote: On 31/03/16 18:10, Zane Bitter wrote: I'm in favour of some sort of variable-based implementation for a few reasons. One is that (5) seems to come up fairly regularly in a c

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On 31/03/16 18:10, Zane Bitter wrote: I'm in favour of some sort of variable-based implementation for a few reasons. One is that (5) seems to come up fairly regularly in a complex deployment like TripleO. Another is that Fn::If feels awkward compared to get_variable. I actually have to revise

Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On 31/03/16 10:10, Thomas Herve wrote: On Thu, Mar 31, 2016 at 2:25 PM, Huangtianhua wrote: The conditions function has been requested for a long time, and there have been several previous discussions, which all ended up in debating the implementation, and no result.

Re: [openstack-dev] [Neutron][LBaaS][heat] Removing LBaaS v1 - are weready?

On 23/03/16 17:44, Fox, Kevin M wrote: Can someone verify the code in the review is complete enough to do a full migration? Any steps missing or not documented? Is heat going to want to support v1 resources longer then neutron does? Its kind of nice to be able to run a newer dashboard/heat

Re: [openstack-dev] [heat] Issue with validation and preview due to get_attr==None

On 27/03/16 22:58, Anant Patil wrote: On 24-Mar-16 20:26, Sergey Kraynev wrote: Zane, I like you idea. As example we may discuss some steps for it during summit session (if it need). Also I have another question, which probably came in your heads a lot of times: A few times, but I usually

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

On 24/03/16 04:29, Steven Hardy wrote: On Thu, Mar 24, 2016 at 01:39:01AM -0400, Rabi Mishra wrote: On Wed, Mar 23, 2016 at 05:25:57PM +0300, Sergey Kraynev wrote: Hello, It looks similar on issue, which was discussed here [1] I suppose, that the root cause is incorrect using

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

On 24/03/16 01:39, Rabi Mishra wrote: On Wed, Mar 23, 2016 at 05:25:57PM +0300, Sergey Kraynev wrote: Hello, It looks similar on issue, which was discussed here [1] I suppose, that the root cause is incorrect using get_attr for your case. Probably you got "list" instead of

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

On 23/03/16 13:35, Steven Hardy wrote: On Wed, Mar 23, 2016 at 05:25:57PM +0300, Sergey Kraynev wrote: Hello, It looks similar on issue, which was discussed here [1] I suppose, that the root cause is incorrect using get_attr for your case. Probably you got "list" instead of

Re: [openstack-dev] [heat] Issue with validation and preview due to get_attr==None

On 23/03/16 13:14, Steven Hardy wrote: Hi all, I'm looking for some help and additional input on this bug: https://bugs.launchpad.net/heat/+bug/1559807 Hmm, I was wondering how this ever worked, but it appears you're making particularly aggressive use of the list_join and map_merge

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

On 23/03/16 07:54, Ryan Hallisey wrote: *Snip* Indeed, this has literally none of the benefits of the ideal Heat deployment enumerated above save one: it may be entirely the wrong tool in every way for the job it's being asked to do, but at least it is still well-integrated with the rest of

[openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

tl;dr Containers represent a massive, and also mandatory, opportunity for TripleO. Lets start thinking about ways that we can take maximum advantage to achieve the goals of the project. Now that you have the tl;dr I'm going to start from the beginning, so settle in and grab yourself a cup of

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

Late to the party, but this comparison seems misleading to me... On 26/01/16 04:46, Steven Hardy wrote: It's one more thing, which is already maintained and has an active community, vs yet-another-bespoke-special-to-tripleo-thing. IMHO we have *way* too many tripleo specific things already.

Re: [openstack-dev] [Heat] Nomination Oleksii Chuprykov to Heat core reviewer

On 16/03/16 06:57, Sergey Kraynev wrote: Hi Heaters, The Mitaka release is close to finish, so it's good time for reviewing results of work. One of this results is analyze contribution results for the last release cycle. According to the data [1] we have one good candidate for nomination to

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

the server has booted, and anything exposed as an attribute of a resource MUST be available by the time the resource becomes CREATE_COMPLETE otherwise Heat's whole data flow model is broken. Regards, Gary -Original Message- From: Zane Bitter [mailto:zbit...@redhat.com] Sent: Thursday

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

On 09/03/16 05:42, Sergey Kraynev wrote: Hi Gary, First of all you don't need to use "depends_on", because using "get_attr" already create implicit dependency from rg_a. About getting Null instead of real Ip address: It sounds like a bug, but IMO, it's expected behavior, because I suppose it

Re: [openstack-dev] [Heat] Dealing with nonexistent resources during resource-list / stack-delete

On 08/03/16 08:03, Johannes Grassler wrote: Hello, On 03/07/2016 04:48 PM, Zane Bitter wrote: On 04/03/16 04:35, Johannes Grassler wrote: [Uncaught client exceptions in resource plugins' add_dependencies() methods] Yes, you're right and this sucks. That's not the only problem we've had

Re: [openstack-dev] [Heat] Dealing with nonexistent resources during resource-list / stack-delete

On 08/03/16 10:40, Johannes Grassler wrote: Hello, On 03/07/2016 04:48 PM, Zane Bitter wrote: On 04/03/16 04:35, Johannes Grassler wrote: [Uncaught client exceptions in resource plugins' add_dependencies() methods] In the meantime, we need to find and squash every instance of this problem

Re: [openstack-dev] [Heat] Dealing with nonexistent resources during resource-list / stack-delete

On 04/03/16 04:35, Johannes Grassler wrote: Hello, I am currently looking into https://bugs.launchpad.net/heat/+bug/1442121 and not quite sure how to tackle it, since the problematic code is used for lots of things[0]: the root cause of the problem are API clients in resource plugins that do

Re: [openstack-dev] [magnum][heat] spawn a group of nodes on different availability zones

On 02/03/16 05:50, Mathieu Velten wrote: Hi all, I am looking at a way to spawn nodes in different specified availability zones when deploying a cluster with Magnum. Currently Magnum directly uses predefined Heat templates with Heat parameters to handle configuration. I tried to reach my goal

Re: [openstack-dev] [heat]How to manage the life cycle of resources in a stack?

On 24/02/16 11:27, zhu4236926 wrote: Hi guys, I get some resources by creating a stack, e.g. ,the resources may be 2 volumes, volume A and volume B. If the volume A and volume B are useless, we can delete them by deleting the stack , we also can delete them by cinder.If they are deleted

Re: [openstack-dev] [heat] intrinsic function bugfixes and hot versioning

On 17/02/16 13:54, Steven Hardy wrote: Hi all, So, Zane and I have discussed $subject and it was suggested I take this to the list to reach consensus. Recently, I've run into a couple of small but inconvenient limitations in our intrinsic function implementations, specifically for str_replace

Re: [openstack-dev] [heat] Changing the default Server/SoftwareDeployment transports?

On 22/01/16 04:36, Steven Hardy wrote: Hi all, Wanted to start some discussion re $subject, context is: https://bugs.launchpad.net/heat/+bug/1507568 Here, we're hitting issues because by default OS::Nova::Server uses the POLL_SERVER_CFN transport. This made sense back when the

Re: [openstack-dev] [all][tc] Stabilization cycles: Elaborating on the idea to move it forward

On 20/01/16 12:53, Flavio Percoco wrote: Greetings, At the Tokyo summit, we discussed OpenStack's development themes in a cross-project session. In this session a group of folks started discussing what topics the overall community could focus on as a shared effort. One of the things that was

Re: [openstack-dev] [heat]Delete the stack while the status of stack is CREATE_IN_PROGRESS?

On 19/01/16 11:33, zhu4236926 wrote: Hi guys, I find a interesting problem in Juno version. First, I create a new stack, it contains three resources, e.g. (In my test, there are six resources) heat_template_version: 2014-10-16 resources: volume1: type: OS::Cinder::Volume

Re: [openstack-dev] [heat] Client checking of server version

On 06/01/16 08:53, Jay Dobies wrote: I ran into an issue in a review about moving environment resolution from client to server [1]. It revolves around clients being able to access older versions of servers (that's a pretty simplistic description; see [2] for the spec). Before the holiday, Steve

Re: [openstack-dev] [heat] Client checking of server version

On 05/01/16 16:37, Steven Hardy wrote: On Mon, Jan 04, 2016 at 03:53:07PM -0500, Jay Dobies wrote: I ran into an issue in a review about moving environment resolution from client to server [1]. It revolves around clients being able to access older versions of servers (that's a pretty simplistic

Re: [openstack-dev] [heat] Client checking of server version

On 04/01/16 15:53, Jay Dobies wrote: I ran into an issue in a review about moving environment resolution from client to server [1]. It revolves around clients being able to access older versions of servers (that's a pretty simplistic description; see [2] for the spec). Before the holiday, Steve

Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

On 22/12/15 11:56, Clint Byrum wrote: Excerpts from Dougal Matthews's message of 2015-12-22 07:36:02 -0800: Hi all, This topic came up in the 2015-12-15 meeting[1], and again briefly today. After working with the code that came out of the deployment library spec[2] I had some concerns with how

Re: [openstack-dev] [heat] Rico Lin for heat-core

On 07/12/15 07:39, Sergey Kraynev wrote: Hi all. I'd like to nominate Rico Lin for heat-core. He did awesome job with providing useful and valuable reviews. Also his contribution is really high [1] . [1] http://stackalytics.com/report/contribution/heat-group/60 Heat core-team, please vote

Re: [openstack-dev] [heat][tripleo] User Initiated Rollback

On 03/12/15 09:41, Steven Hardy wrote: On Thu, Dec 03, 2015 at 08:11:41AM -0500, Dan Prince wrote: On Wed, 2015-12-02 at 16:02 +, Steven Hardy wrote: So, chatting with Giulio today about https://bugs.launchpad.net/heat/ +bug/1521944 has be thinking about $subject. The root case of that

Re: [openstack-dev] [heat][tripleo] User Initiated Rollback

On 02/12/15 11:02, Steven Hardy wrote: So, chatting with Giulio today about https://bugs.launchpad.net/heat/+bug/1521944 has be thinking about $subject. The root case of that issue is essentially a corner case of a stack-update, combined with some coupling within the Neutron API which prevents

Re: [openstack-dev] [release] preparing your mitaka-1 milestone tag

On 27/11/15 09:32, Doug Hellmann wrote: Next week (Dec 1-3) is the Mitaka 1 milestone deadline. Release liaisons for all managed projects using the cycle-with-milestones release model will need to propose tags for their repositories by Thursday. Tag requests submitted after Dec 3 will be

Re: [openstack-dev] [tripleo][ironic][heat] Adding back the tripleo check job

On 01/12/15 06:22, Steven Hardy wrote: > +1 > > I don't think it hurts to turn it on, but tbh I'm uncomfortable with the > mental overhead of a non-voting job that I have to manually treat as a > voting job. If it's stable enough to make it a voting job, I'd prefer we >

Re: [openstack-dev] [tripleo][ironic][heat] Adding back the tripleo check job

On 30/11/15 12:51, Ruby Loo wrote: On 30 November 2015 at 10:19, Derek Higgins > wrote: Hi All, A few months tripleo switch from its devtest based CI to one that was based on instack. Before doing this we anticipated

Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

On 17/11/15 13:38, Alan Pevec wrote: 2015-11-12 21:37 GMT+01:00 Zane Bitter <zbit...@redhat.com>: https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:stable/juno,n,z It would be nice to treat the remaining 'High' priority one as a blocker. The rest aren't a b

Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

On 10/11/15 10:11, Alan Pevec wrote: Hi, while we continue discussion about the future of stable branches in general and stable/juno in particular, I'd like to execute the current plan which was[1] 2014.2.4 (eol) early November, 2015. release manager: apevec Iff there's enough folks

Re: [openstack-dev] [keystone] [Mistral] [Heat] Autoprovisioning, per-user projects, and Federation

On 11/11/15 13:11, Clint Byrum wrote: Excerpts from Zane Bitter's message of 2015-11-11 09:43:43 -0800: 1. Keystone (or some Rabbit->Zaqar proxy service reading notifications from Keystone) sends "new federated user" notification out via Zaqar. 2. Mistral picks up the message and checks policy

Re: [openstack-dev] [keystone] [Mistral] [Heat] Autoprovisioning, per-user projects, and Federation

On 10/11/15 11:32, Adam Young wrote: On 11/10/2015 10:28 AM, Renat Akhmerov wrote: On 09 Nov 2015, at 20:43, Adam Young wrote: On 11/06/2015 06:28 PM, Tim Hinrichs wrote: Congress allows users to write a policy that executes an action under certain conditions. The

Re: [openstack-dev] [keystone] [Mistral] Autoprovisioning, per-user projects, and Federation

On 09/11/15 11:55, Adam Young wrote: On 11/09/2015 10:57 AM, Tim Hinrichs wrote: Congress happens to have the capability to run a script/API call under arbitrary conditions on the state of other OpenStack projects, which sounded like what you wanted. Or did I misread your original question?

Re: [openstack-dev] [TripleO] [Ironic] Let's stop hijacking other projects' OSC namespaces

On 09/11/15 07:44, Dmitry Tantsur wrote: As we already have "openstack undercloud" and "openstack overcloud" prefixes for TripleO, I suggest we move these commands under "openstack overcloud nodes" namespace. So we end up with: overcloud nodes import overcloud nodes configure ready state

Re: [openstack-dev] [kolla][tripleo] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

On 04/11/15 16:26, Michal Rostecki wrote: On 11/03/2015 10:27 PM, Zane Bitter wrote: I think we all agree that using something _like_ Kubernetes would be extremely interesting for controller services, where you have a bunch of heterogeneous services with scheduling constraints (HA), that may

Re: [openstack-dev] [kolla][tripleo] Mesos orchestration as discussed at mid cycle (action required from core reviewers)

On 02/11/15 18:33, Steven Dake (stdake) wrote: Blame the core team :) I suspect you will end up retrying a lot of patterns we tried and failed with Kubernetes. Kubernetes eventually was found to be non-viable by the delivery of this 2 week project: https://github.com/sdake/compute-upgrade

Re: [openstack-dev] [heat] Shared code between server and client

On 28/10/15 00:09, Jay Dobies wrote: On 23/10/15 05:35, Robert Collins wrote: My 2c - if its a stable API in the client, and can be kept stable, there's no problem. +1 Ok, forgive me for sounding dumb here (and changing the topic of the thread somewhat), but what do we consider a stable

Re: [openstack-dev] [heat] Shared code between server and client

On 23/10/15 05:35, Robert Collins wrote: My 2c - if its a stable API in the client, and can be kept stable, there's no problem. +1 -Rob On 23 October 2015 at 08:49, Jay Dobies wrote: I'm working on moving the functionality for merging environments from the client

Re: [openstack-dev] Scheduler proposal

On 07/10/15 13:36, Ed Leafe wrote: Several months ago I proposed an experiment [0] to see if switching the data model for the Nova scheduler to use Cassandra as the backend would be a significant improvement as opposed to the current design using multiple copies of the same data (compute_node

[openstack-dev] [TripleO] Blueprints for upgrades

I've started an etherpad collecting a list of potential blueprints for achieving major version upgrades of in TripleO, with an initial target of upgrading Kilo to Liberty using a stable/liberty undercloud. There's still a bunch of unanswered questions (especially around compute nodes), and

Re: [openstack-dev] [heat] Traditional question about Heat IRC meeting time.

rom my iPhone On Oct 1, 2015, at 10:36 PM, Zane Bitter <zbit...@redhat.com> wrote: On 29/09/15 05:56, Sergey Kraynev wrote: Hi Heaters! Previously we had constant "tradition" to change meeting time for involving more people from different time zones. However last release cycle sh

Re: [openstack-dev] [heat] Traditional question about Heat IRC meeting time.

On 29/09/15 05:56, Sergey Kraynev wrote: Hi Heaters! Previously we had constant "tradition" to change meeting time for involving more people from different time zones. However last release cycle show, that two different meetings with 07:00 and 20:00 UTC are comfortable for most of our

Re: [openstack-dev] [all] -1 due to line length violation in commit messages

On 29/09/15 12:05, Ihar Hrachyshka wrote: On 25 Sep 2015, at 16:44, Ihar Hrachyshka wrote: Hi all, releases are approaching, so it’s the right time to start some bike shedding on the mailing list. Recently I got pointed out several times [1][2] that I violate our commit

Re: [openstack-dev] [all] -1 due to line length violation in commit messages

On 28/09/15 05:47, Gorka Eguileor wrote: On 26/09, Morgan Fainberg wrote: As a core (and former PTL) I just ignored commit message -1s unless there is something majorly wrong (no bug id where one is needed, etc). I appreciate well formatted commits, but can we let this one go? This

[openstack-dev] [Heat] Scattered thoughts on the PTL election

The Heat project pioneered the concept of rotating the PTL for every development cycle, and so far all of the early (before 2013) developers who are still involved have served as PTL. I think this has been a *tremendous* success for the project, and a testament to the sheer depth of leadership

Re: [openstack-dev] [heat] Backup resources and properties in the delete-path

On 10/09/15 12:53, Steven Hardy wrote: Hi all, So, I've been battling with $subject for the last few days ref [1][2]. The problem I have is that out TestResource references several properties in the delete (check_delete_complete) path[4], which it turns out doesn't work very well if those

Re: [openstack-dev] [Heat] Multi Node Stack - keystone federation

On 09/09/15 04:10, SHTILMAN, Tomer (Tomer) wrote: On 07/09/15 05:27, SHTILMAN, Tomer (Tomer) wrote: Hi Currently in heat we have the ability to deploy a remote stack on a different region using OS::Heat::Stack and region_name in the context My question is regarding multi node , separate

Re: [openstack-dev] [tripleo] Upgrade plans for RDO Manager - Brainstorming

On 24/08/15 15:12, Emilien Macchi wrote: Hi, So I've been working on OpenStack deployments for 4 years now and so far RDO Manager is the second installer -after SpinalStack [1]- I'm working on. SpinalStack already had interested features [2] that allowed us to upgrade our customer platforms

Re: [openstack-dev] [Heat] Multi Node Stack - keystone federation

On 09/09/15 04:10, SHTILMAN, Tomer (Tomer) wrote: We are currently building in our lab multi cloud setup with keystone federation and I will check if my understating is correct, I am planning for propose a BP for this once will be clear There was further interest in this at the IRC meeting

Re: [openstack-dev] [Heat] Multi Node Stack - keystone federation

On 07/09/15 05:27, SHTILMAN, Tomer (Tomer) wrote: Hi Currently in heat we have the ability to deploy a remote stack on a different region using OS::Heat::Stack and region_name in the context My question is regarding multi node , separate keystones, with keystone federation. Is there an option

Re: [openstack-dev] [Heat] convergence rally test results (so far)

On 03/09/15 02:56, Angus Salkeld wrote: On Thu, Sep 3, 2015 at 3:53 AM Zane Bitter <zbit...@redhat.com <mailto:zbit...@redhat.com>> wrote: On 02/09/15 04:55, Steven Hardy wrote: > On Wed, Sep 02, 2015 at 04:33:36PM +1200, Robert Collins wrote: >> On 2 Se

Re: [openstack-dev] [trove] [heat] Multi region support

On 01/09/15 19:47, Angus Salkeld wrote: On Wed, Sep 2, 2015 at 8:30 AM Lowery, Mathew > wrote: Thank you Zane for the clarifications! I misunderstood #2 and that led to the other misunderstandings. Further questions: * Are nested

Re: [openstack-dev] [Heat] convergence rally test results (so far)

On 02/09/15 04:55, Steven Hardy wrote: On Wed, Sep 02, 2015 at 04:33:36PM +1200, Robert Collins wrote: On 2 September 2015 at 11:53, Angus Salkeld wrote: 1. limit the number of resource actions in parallel (maybe base on the number of cores) I'm having trouble

Re: [openstack-dev] [trove] [heat] Multi region support

On 01/09/15 11:41, Lowery, Mathew wrote: This is a Trove question but including Heat as they seem to have solved this problem. Summary: Today, it seems that Trove is not capable of creating a cluster spanning multiple regions. Is that the case and, if so, are there any plans to work on that?

Re: [openstack-dev] [TripleO] Encapsulating logic and state in the client

On 18/08/15 02:33, Clint Byrum wrote: Excerpts from Zane Bitter's message of 2015-08-17 09:25:36 -0700: It occurs to me that there has never been a detailed exposition of the purpose of the tripleo-common library here, and that this might be a good time to rectify that. Basically, there are

Re: [openstack-dev] [tripleo] Upgrades, Releases Branches

On 17/08/15 15:29, James Slagle wrote: I'd like propose we take a somewhat modified release branch approach, which combines many of the advantages of the stable-branch model, but allows for a somewhat more liberal approach to backports, where most things are considered valid backports provided

[openstack-dev] [TripleO] Encapsulating logic and state in the client

It occurs to me that there has never been a detailed exposition of the purpose of the tripleo-common library here, and that this might be a good time to rectify that. Basically, there are two things that it sucks to have in the client: First, logic - that is, any code that is not related to

Re: [openstack-dev] [Heat] RPC API versioning

On 06/08/15 08:20, Grasza, Grzegorz wrote: -Original Message- From: Zane Bitter [mailto:zbit...@redhat.com] Sent: Thursday, 6 August, 2015 2:57 To: OpenStack Development Mailing List Subject: [openstack-dev] [Heat] RPC API versioning We've been talking about this since before summit

Re: [openstack-dev] [app-catalog][heat] Heat template contributors repo

On 06/08/15 13:53, Christopher Aedo wrote: Today during the app-catalog IRC meeting we talked about hosting Heat templates for contributors. Right now someone who wants to create their own templates can easily self-host them on github, but until they get people pointed at it, nobody will know

Re: [openstack-dev] [Heat] RPC API versioning

On 06/08/15 10:08, Dan Smith wrote: This is, I believe, sufficient to solve our entire problem. Specifically, we have no need for an indirection API that rebroadcasts messages that are too new (since that can't happen with pinning) and no need for Versioned Objects in the RPC layer. (Versioned

[openstack-dev] [Heat] RPC API versioning

We've been talking about this since before summit without much consensus. I think a large part of the problem is that very few people have deep knowledge of both Heat and Versioned Objects. However, I think we are at a point where we should be able to settle on an approach at least for the

Re: [openstack-dev] Proposing Kanagaraj Manickam and Ethan Lynn for heat-core

You forgot the [heat] tag ;) On 31/07/15 00:35, Steve Baker wrote: I believe the heat project would benefit from Kanagaraj Manickam and Ethan Lynn having the ability to approve heat changes. +1 for both and, at the risk of counting votes prematurely, welcome! - ZB Their reviews are

Re: [openstack-dev] [fuel][puppet] The state of collaboration: 5 weeks

On 21/07/15 04:21, Dmitry Borodaenko wrote: I -2 for this reason: this patch already had a +2 so it was closed to be merged by someone else, while the patch was *breaking backward compatiblity* in puppet-horizon, because Vasyl was changing the default cache driver to force users to use Memcached

Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

On 14/07/15 14:34, Pavlo Shchelokovskyy wrote: Hi Heaters, currently we already expose to the user only resources for services deployed in the cloud [1], and soon we will do the same based on whether actual user roles allow creating specific resources [2]. Here I would like to get your opinion

<    1   2   3   4   5   6   7   8   >