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

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

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 interested in, so I

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 http://this.id} I have no idea what this is supposed to mean, sorry. Is it possible? The get_resource

[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

Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat

On 30/01/15 02:19, Thomas Spatzier wrote: From: Zane Bitter zbit...@redhat.com To: openstack Development Mailing List openstack-dev@lists.openstack.org Date: 29/01/2015 17:47 Subject: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat I got a question today about creating

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

On 26/01/15 19:04, Angus Salkeld wrote: On Sat, Jan 24, 2015 at 7:00 AM, Zane Bitter zbit...@redhat.com mailto:zbit...@redhat.com wrote: I'm also prepared to propose specs for all of these _if_ people think that would be helpful. I see three options here: - Propose 18 fairly

Re: [openstack-dev] [heat] operators vs users for choosing convergence engine

On 02/02/15 19:52, Steve Baker wrote: A spec has been raised to add a config option to allow operators to choose whether to use the new convergence engine for stack operations. For some context you should read the spec first [1] Rather than doing this, I would like to propose the following: I

Re: [openstack-dev] [Heat] Add extraroutes support to neutron routers

On 05/02/15 12:23, James Denton wrote: Hello all, Regarding https://blueprints.launchpad.net/heat/+spec/router-properties-object Does anyone know if there are plans to implement this functionality in an upcoming release? Unlikely - unfortunately the Neutron API for extra routes makes it

Re: [openstack-dev] [heat] operators vs users for choosing convergence engine

On 03/02/15 14:12, Clint Byrum wrote: The visible change in making things parallel was minimal. In talking about convergence, it's become clear that users can and should expect something radically different when they issue stack updates. I'd love to say that it can be done to just bind

[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

Re: [openstack-dev] [Mistral] Changing expression delimiters in Mistral DSL

On 16/02/15 16:06, Dmitri Zimine wrote: 2) Use functions, like Heat HOT or TOSCA: HOT templates and TOSCA doesn’t seem to have a concept of typed variables to borrow from (please correct me if I missed it). But they have functions: function: { function_name: {foo: [parameter1, parameter 2],

Re: [openstack-dev] [Heat] core team changes

On 27/01/15 20:36, Angus Salkeld wrote: Hi all After having a look at the stats: http://stackalytics.com/report/contribution/heat-group/90 http://stackalytics.com/?module=heat-groupmetric=person-day I'd like to propose the following changes to the Heat core team: Add: Qiming Teng Huang

[openstack-dev] [Heat][Keystone] Native keystone resources in Heat

I got a question today about creating keystone users/roles/tenants in Heat templates. We currently support creating users via the AWS::IAM::User resource, but we don't have a native equivalent. IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only

Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat

On 29/01/15 12:03, Steven Hardy wrote: On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote: IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backend (i.e. LDAP). If this means that it's now possible to configure a cloud so that one need

Re: [openstack-dev] [heat] multicloud support for ec2

On 25/01/15 00:03, Hongbin Lu wrote: Hi Heat team, I am looking for a solution to bridge between OpenStack and EC2. According to documents, it seems that Heat has multicloud support but the remote cloud(s) must be OpenStack. It actually doesn't, although it is planned. (We have multi-region

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:

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 just

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:

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

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

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

Re: [openstack-dev] [heat][congress] Stack lifecycle plugpoint as an enabler for cloud provider's services

On 19/03/15 06:17, VACHNIS, AVI (AVI) wrote: Hi, I'm looking at this interesting blueprint https://blueprints.launchpad.net/heat/+spec/stack-lifecycle-plugpoint and I hope you can easily clarify some things to me. I see the following statements related to this BP: * [in problem description

Re: [openstack-dev] [Heat] vnic_type in OS::Neutron::Port

On 20/03/15 14:33, Rob Pothier (rpothier) wrote: Hi All, It was brought to my attention that the recent changes with the vnic_type possibly should not include the colon in the property value. In the earlier versions of the review the colon was not in the property, and was appended later.

Re: [openstack-dev] [TripleO][Tuskar] Common library for shared code

On 16/03/15 16:38, Ben Nemec wrote: On 03/13/2015 05:53 AM, Jan Provaznik wrote: On 03/10/2015 05:53 PM, James Slagle wrote: On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník jprov...@redhat.com wrote: Hi, it would make sense to have a library for the code shared by Tuskar UI and CLI (I mean

Re: [openstack-dev] [Magnum][Heat] Expression of Bay Status

On 09/03/15 23:47, Angus Salkeld wrote: On Tue, Mar 10, 2015 at 8:53 AM, Adrian Otto adrian.o...@rackspace.com mailto:adrian.o...@rackspace.com wrote: Magnum Team, In the following review, we have the start of a discussion about how to tackle bay status:

Re: [openstack-dev] [heat] Unknown resource OS::Heat::ScaledResource

On 10/03/15 12:26, Manickam, Kanagaraj wrote: Hi, I observed in one of the patch mentioned below, OS::Heat::ScaledResource is reported as unknown, could anyone help here to resolve the issue. Thanks.

Re: [openstack-dev] Avoiding regression in project governance

On 10/03/15 12:29, Russell Bryant wrote: I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved*any* tags other than the one

Re: [openstack-dev] [heat] heat delete woes in Juno

On 26/03/15 15:30, Georgy Okrokvertskhov wrote: I attached an example of the template which is hanging right now in my Juno environment. I believe it hangs because of floating ip stuff and the way how it is attached to a VM. It is autogenerated, so please don't be disturbed by strange resource

Re: [openstack-dev] [heat] Network name as a Server properties

On 30/03/15 03:51, BORTMAN, Limor (Limor) wrote: Hi, I noticed the we can't use network name under OS::Neutron::Port (only network_id) as a valid neutron property, and I was wondering why? IIRC it was something weird about how python-neutronclient worked at the time. I expected it to be

Re: [openstack-dev] [Openstack-operators] Resources owned by a project/tenant are not cleaned up after that project is deleted from keystone

On 25/02/15 19:15, Dolph Mathews wrote: On Wed, Feb 25, 2015 at 5:42 PM, Zane Bitter zbit...@redhat.com mailto:zbit...@redhat.com wrote: On 25/02/15 15:37, Joe Gordon wrote: On Sat, Feb 21, 2015 at 5:03 AM, Tim Bell tim.b...@cern.ch mailto:tim.b...@cern.ch

Re: [openstack-dev] [Openstack-operators] Resources owned by a project/tenant are not cleaned up after that project is deleted from keystone

On 25/02/15 15:37, Joe Gordon wrote: On Sat, Feb 21, 2015 at 5:03 AM, Tim Bell tim.b...@cern.ch mailto:tim.b...@cern.ch wrote: A few inline comments and a general point How do we handle scenarios like volumes when we have a per-component janitor rather than a single co-ordinator

Re: [openstack-dev] [heat] heat delete woes in Juno

On 26/03/15 15:56, Matt Fischer wrote: We don't have heat stack-abandon enabled. It's marked as a preview feature, have you had any issues? It's fairly safe for this use case. If it's important for you that you don't lose track of your resources and you want to adopt them again later, it's a

Re: [openstack-dev] [Heat] Decoupling Heat integration tests from Heat tree

On 26/03/15 10:38, Pavlo Shchelokovskyy wrote: Hi all, following IRC discussion here is a summary of what I propose can be done in this regard, in the order of increased decoupling: 1) make a separate requirements.txt for integration tests and modify the tox job to use it. The code of these

Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat

On 30/01/15 05:20, Steven Hardy wrote: On Thu, Jan 29, 2015 at 12:31:17PM -0500, Zane Bitter wrote: On 29/01/15 12:03, Steven Hardy wrote: On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote: IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only

[openstack-dev] [TripleO][Heat] Overcloud software updates and ResourceGroups

A few of us have been looking for a way to perform software updates to servers in a TripleO Heat/Puppet-based overcloud that avoids an impedance mismatch with Heat concepts and how Heat runs its workflow. As many talented TripleO-ers who have gone before can probably testify, that's

Re: [openstack-dev] [all] Question for the TC candidates

On 23/04/15 12:14, Chris Dent wrote: This might be a bit presumptuous, but why not give it a try... Not at all, we should *strongly* encourage people to ask questions of the candidates. In fact, I think we should encourage everyone to contribute to the discussion, not just the candidates.

Re: [openstack-dev] [all] Question for the TC candidates

On 24/04/15 09:00, Ed Leafe wrote: I'm not sure what you see as the difference between the end users and the operators of OpenStack, because in my mind they are one and the same. I don't consider the people using, say, public cloud services to be OpenStack end users, because ultimately they

Re: [openstack-dev] Please stop reviewing code while asking questions

On 24/04/15 07:21, Amrith Kumar wrote: Julien, We had a similar discussion within Trove several months ago and agreed to a convention that if you have a question, that should not warrant a -1 unless, as you indicate there's a strong reason to believe that the code is wrong and the question

[openstack-dev] TC Candidacy

Hello Stackists, I'd like to announce my candidacy for the OpenStack Technical Committee. I'm running because I don't think that the diversity of perspectives amongst TC members reflects the diversity of our community. We're fortunate to have a few people whose brilliance often transcends the

Re: [openstack-dev] [all] Question for the TC candidates

On 24/04/15 09:52, Ed Leafe wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/24/2015 08:30 AM, Zane Bitter wrote: I'm not sure what you see as the difference between the end users and the operators of OpenStack, because in my mind they are one and the same. I don't consider

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On 24/04/15 20:00, Joe Gordon wrote: On Fri, Apr 24, 2015 at 4:35 PM, Fox, Kevin M kevin@pnnl.gov mailto:kevin@pnnl.gov wrote: Notification might be a good way to integrate with nova. Individual tenants might want to do things as vm's come up/down, etc. Right now, you need

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On 24/04/15 19:02, Joe Gordon wrote: On Mon, Apr 20, 2015 at 5:54 AM, Flavio Percoco fla...@redhat.com mailto:fla...@redhat.com wrote: Greetings, I'd like my first action as Zaqar's PTL to be based on reflections and transparency with regards to what our past has been, to what

Re: [openstack-dev] [heat] Stack/Resource updated_at conventions

On 28/04/15 03:56, Steven Hardy wrote: On Mon, Apr 27, 2015 at 06:41:52PM -0400, Zane Bitter wrote: On 27/04/15 13:38, Steven Hardy wrote: On Mon, Apr 27, 2015 at 04:46:20PM +0100, Steven Hardy wrote: AFAICT there's two options: 1. Update the stack.Stack so we store now at every transition

Re: [openstack-dev] [heat] Stack/Resource updated_at conventions

On 27/04/15 13:38, Steven Hardy wrote: On Mon, Apr 27, 2015 at 04:46:20PM +0100, Steven Hardy wrote: AFAICT there's two options: 1. Update the stack.Stack so we store now at every transition (e.g in state_set) 2. Stop trying to explicitly control updated_at, and just allow the oslo

Re: [openstack-dev] [heat][ceilometer] autoscaling

On 06/05/15 08:25, ICHIBA Sara wrote: hey there, Please I wanna know if their is anyway I can have cpu, ram and network meters for each VM returned by ceilometer to heat for autoscaling tasks? In advance, thank you for your response, Sara The openstack-dev list is for discussing future

Re: [openstack-dev] [all] TC Communications planning

On 06/05/15 09:13, Anne Gentle wrote: Hi all, In the interest of communicating sooner rather than later, I wanted to write a new thread to say that Flavio Percoco and I are going to work on a TC communications plan as co-chairs of a TC communications working group. I think we can find a happy

Re: [openstack-dev] [Murano] [Mistral] SSH workflow action

Hello! This looks like a perfect soapbox from which to talk about my favourite issue ;) You're right about the ssh idea, for the reasons discussed related to networking and a few more that weren't (e.g. users shouldn't have to and generally don't want to give their private SSH keys to cloud

Re: [openstack-dev] [Murano] [Mistral] SSH workflow action

is restricted to be authenticated to specific API URL like GET /v1/queues/queue-id/ Thanks Gosha On Tue, May 12, 2015 at 8:58 AM, Fox, Kevin M kevin@pnnl.gov mailto:kevin@pnnl.gov wrote: +1 From: Zane Bitter [zbit...@redhat.com

Re: [openstack-dev] [Murano] [Mistral] SSH workflow action

. Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis mailto:sla...@mirantis.com On Tue, May 12, 2015 at 10:52 AM, Renat Akhmerov rakhme...@mirantis.com mailto:rakhme...@mirantis.com wrote: Zane, Fully agree with you vision here. On 12 May 2015, at 07:15, Zane Bitter

Re: [openstack-dev] [Murano] [Mistral] [Zaqar] [Keystone] SSH workflow action

all of the many groups who need it so that they can prioritise the work appropriately :) cheers, Zane. Thanks Gosha On Tue, May 12, 2015 at 8:58 AM, Fox, Kevin M kevin@pnnl.gov mailto:kevin@pnnl.gov wrote: +1 From: Zane Bitter

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

On 14/05/15 10:39, Geoff Arnold wrote: +1 There seems to be a significant disconnect between Heat, Horizon and Keystone on the subject of multi-region configurations, and the documentation isn’t helpful. At the very least, it would be useful if discussions at the summit could result in a decent

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

offers support for dealing with multiple regions within a single cloud. It also offers an option to switch between multiple different clouds using an option unfortunately called AVAILABLE_REGIONS, which is a total misnomer. - ZB Geoff On May 14, 2015, at 7:56 AM, Zane Bitter zbit...@redhat.com

Re: [openstack-dev] [Murano] [Mistral] [Zaqar] [Keystone] SSH workflow action

On 14/05/15 23:38, Adam Young wrote: So the mechanisms are there. In the short term we'd need some cross-project co-operation to define a system through which we can do this across projects (i.e. Murano or any other service can create a user and have Zaqar authorise it for listening on a

Re: [openstack-dev] [Murano] [Mistral] [Zaqar] [Keystone] SSH workflow action

On 15/05/15 11:57, Adam Young wrote: It's kind of unfortunate IMHO that the default policy.json files tend to give all users access to non-admin APIs, rather than requiring a specific role (like Member). Working on that. Come to my policy session! This one, I assume:

Re: [openstack-dev] [trove][zaqar] Trove and Zaqar integration. Summit working session

On 11/05/15 05:49, Flavio Percoco wrote: On 08/05/15 00:45 -0700, Nikhil Manchanda wrote: 3) The trove-guest-agent is in vm. it is connected by taskmanager by rabbitmq. We designed it. But is there some prectise to do this? how to make the vm be connected in vm-network and

Re: [openstack-dev] [nova-docker][ceilometer][heat] Autoscaling docker in openstack

On 17/04/15 10:11, VACHNIS, AVI (AVI) wrote: Hi, @Ashish, if the limitation you've mentioned for #1 still exists, I join your question how heat auto-scale-group may work w/o ceilometer being able to collect docker metrics? Yeah, you're correct. Approach #2 has exactly the same problem as

Re: [openstack-dev] [heat] is cloudwatch really deprecated?

On 17/04/15 13:54, Matt Fischer wrote: On Fri, Apr 17, 2015 at 11:03 AM, Zane Bitter zbit...@redhat.com mailto:zbit...@redhat.com wrote: On 17/04/15 12:46, Matt Fischer wrote: The wiki for Using Cloudwatch states: This feature will be deprecated or removed during

Re: [openstack-dev] [Heat] moving sqlite migration scripts to tests

On 16/04/15 04:05, Anant Patil wrote: Hi, Sometime back we had a discussion on IRC regarding sqlite migration scripts. Since sqlite is mostly used for testing, we were thinking about moving the sqlite migration related code to tests folder and keep the migrate_repo sane (with only production

Re: [openstack-dev] [heat] is cloudwatch really deprecated?

On 17/04/15 12:46, Matt Fischer wrote: The wiki for Using Cloudwatch states: This feature will be deprecated or removed during the Havana cycle as we move to using Ceilometer as a metric/alarm service instead. [1] However it seems that cloudwatch is still being developed. It doesn't seem

Re: [openstack-dev] [TripleO][Heat] Overcloud software updates and ResourceGroups

On 03/04/15 01:29, Giulio Fidente wrote: hi there, thanks for sharing this, I have a On 04/03/2015 12:31 AM, Zane Bitter wrote: A few of us have been looking for a way to perform software updates to servers in a TripleO Heat/Puppet-based overcloud [...] Here's a trivial example of what

Re: [openstack-dev] [TripleO][Heat] Overcloud software updates and ResourceGroups

On 02/04/15 20:31, Fox, Kevin M wrote: I'm not sure how to feel about this... Its clever... That's... unfortunate ;) Ideally this would sound like something that is a natural fit for Heat's data model. The reason it's not is that config management tools like Puppet are less sophisticated

Re: [openstack-dev] [TripleO][Heat] Overcloud software updates and ResourceGroups

On 07/04/15 05:13, Steven Hardy wrote: On Thu, Apr 02, 2015 at 06:31:39PM -0400, Zane Bitter wrote: A few of us have been looking for a way to perform software updates to servers in a TripleO Heat/Puppet-based overcloud that avoids an impedance mismatch with Heat concepts and how Heat runs its

Re: [openstack-dev] [heat] autoscaling and load balancers

On 07/04/15 22:02, Miguel Grinberg wrote: Hi, The OS::Heat::AutoScalingGroup resource is somewhat limited at this time, because when a scaling even occurs it does not notify dependent resources, such as a load balancer, that the pool of instances has changed. As Thomas mentioned, the

Re: [openstack-dev] [heat] autoscaling and load balancers

On 08/04/15 18:03, Miguel Grinberg wrote: Here is where we disagree. In my opinion this is broken functionality. It's not broken functionality, it's functionality that never existed. Spontaneous stack updates are just not part of the CloudFormation model, and they've never been a part of

Re: [openstack-dev] [heat] autoscaling and load balancers

On 08/04/15 21:51, Miguel Grinberg wrote: Hi Angus, Regarding this: As Zane suggested, you should think of autoscaling as been in a different service. It's not that I can't see your point of view. I can imagine an autoscaling service. I agree with you guys that if we had that, then none of

Re: [openstack-dev] [all] how to send messages (and events) to our users

On 06/04/15 22:55, Angus Salkeld wrote: Hi all For quite some time we (Heat team) have wanted to be able to send messages to our users (by user I do not mean the Operator, but the User that is interacting with the client). What do I mean by user messages, and how do they differ from our

[openstack-dev] Standard way to indicate a partial blueprint implementation?

Ever since we established[1] a format for including metadata about bugs in Git commit messages that included a 'Partial-Bug' tag, people have been looking for a way to do the equivalent for partial blueprint implementations. A non-exhaustive search of a small number of projects reveals at

Re: [openstack-dev] [all] grenade with external plugins for the big tent - how to use

On 11/06/15 09:38, Kyle Mestery wrote: On Thu, Jun 11, 2015 at 6:11 AM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: Yesterday we landed the infrastructure for Grenade external plugins - https://review.openstack.org/#/c/185050/ The first user of this is the Heat project,

Re: [openstack-dev] [puppet] [fuel] more collaboration request

This thread kind of deteriorated a bit (though it looks like it's hopefully recovering), so I'd just like to add some observations. What we have here is a classic case of a long-running fork, with all that that entails. In this case the fork is a public one, but that actually makes very

[openstack-dev] [GBP][Heat] Group-based Policy plug-in for Heat

Every day I get an email about broken dependencies for the group-based policy Heat plugin in Fedora (openstack-heat-gbp), because the version of Heat it depends on is capped. Two points: 1) Would whoever maintains that package (Bob?) please fix it :) 2) Why was this plugin not submitted to

Re: [openstack-dev] [TripleO] [Puppet] Package updates strategy

On 28/05/15 03:35, Jan Provaznik wrote: On 05/28/2015 01:10 AM, Steve Baker wrote: On 28/05/15 10:54, Richard Raseley wrote: Zane Bitter wrote: Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO

Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead

On 27/05/15 12:42, Clint Byrum wrote: == Crazy idea section == One thing I never had a chance to discuss with any of the Zaqar devs that I would find interesting is an email-only backend for Zaqar. Basically make Zaqar an HTTP-to-email gateway. There are quite a few hyper-scale options for

[openstack-dev] [TripleO] Package updates strategy

Steve is working on a patch to allow package-based updates of overcloud nodes[1] using the distro's package manager (yum in the case of RDO, but conceivable apt in others). Note we're talking exclusively about minor updates, not version-to-version upgrades here. Dan mentioned at the summit

Re: [openstack-dev] [heat] Question about retrieving resource_list from ResourceGroup

On 26/06/15 15:14, Hongbin Lu wrote: Hi team, I would like to start my question by using a sample template: heat_template_version: 2014-10-16 parameters: count: type: number default: 5 removal_list: type: comma_delimited_list default: [] resources:

Re: [openstack-dev] meeting with the zaqar team at summit; my notes

multi-tenant capable and authenticated (if it's so safe why not use the same RabbitMQ as all the other services?), but it would be less of an 'immediate uninstall' case. cheers, Zane. Thanks, Kevin * * *From:* Zane Bitter

Re: [openstack-dev] meeting with the zaqar team at summit; my notes

On 22/05/15 11:48, Amrith Kumar wrote: I’m posting this to the mailing list to summarize my notes from a meeting at 5pm yesterday at Summit relative to Zaqar and lightweight multi-tenant messaging and how it may be applicable to a number of projects. I’ll begin by saying these are not ‘minutes’

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] 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] [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] [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

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] [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] [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] [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] [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] [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] [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] 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] [tc] [all] thinking additional tags

On 08/07/15 18:12, Steve Baker wrote: On 09/07/15 04:39, Zane Bitter wrote: On 08/07/15 09:03, Sean Dague wrote: Personally, I'm running out of steam on tags for this cycle, but Zane brought up a good point in the TC meeting yesterday, which was that it would be nice to have tags for criteria

<    1   2   3   4   5   6   7   8   >