Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 18/05/17 09:23, Monty Taylor wrote: But think of the following use cases: As a user, I want to make an API key that I'm going to use for general automation just like I use my Password auth plugin based user account today. I want it to be able to do everything I can do today - but I value

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 18/05/17 07:53, Sean Dague wrote: My worry about policy also is that I'm not sure how safe it is for a project owned API key to inherit permissions from the user who created it. I can't think of a better way to it though but I'm still slightly uncomfortable with it since a user with more

Re: [openstack-dev] [Heat] Heat template example repository

On 16/05/17 10:32, Lance Haig wrote: What if instead of a directory per release, we just had a 'deprecated' directory where we move stuff that is going away (e.g. anything relying on OS::Glance::Image), and then deleted them when it disappeared from any supported release (e.g. LBaaSv1 must be

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 16/05/17 01:06, Colleen Murphy wrote: Additionally, I think OAuth - either extending the existing OAuth1.0 plugin or implementing OAuth2.0 - should probably be on the table. I believe that OAuth is not a good fit for long-lived things like an application needing to communicate with its own

Re: [openstack-dev] [all][keystone][product] api keys/application specific passwords

On 15/05/17 20:07, Adrian Turjak wrote: On 16/05/17 01:09, Lance Bragstad wrote: On Sun, May 14, 2017 at 11:59 AM, Monty Taylor > wrote: On 05/11/2017 02:32 PM, Lance Bragstad wrote: Hey all, One of the Baremetal/VM

Re: [openstack-dev] [Heat] Heat template example repository

On 15/05/17 12:10, Steven Hardy wrote: On Mon, May 15, 2017 at 04:46:28PM +0200, Lance Haig wrote: Hi Steve, I am happy to assist in any way to be honest. It was great to meet you in Boston, and thanks very much for volunteering to help out. BTW one issue I'm aware of is that the

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] [heat] [telemetry] - RFC cross project request id tracking

On 15/05/17 10:35, Doug Hellmann wrote: Excerpts from Sean Dague's message of 2017-05-15 10:01:20 -0400: On 05/15/2017 09:35 AM, Doug Hellmann wrote: Excerpts from Sean Dague's message of 2017-05-14 07:04:03 -0400: One of the things that came up in a logging Forum session is how much effort

Re: [openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

On 04/05/17 10:14, Thierry Carrez wrote: Chris Dent wrote: On Wed, 3 May 2017, Drew Fisher wrote: "Most large customers move slowly and thus are running older versions, which are EOL upstream sometimes before they even deploy them." Can someone with more of the history give more detail on

Re: [openstack-dev] [stable][heat] Nominate huangtianhua for heat-stable-maint

bump On 30/03/17 16:45, Zane Bitter wrote: We are feeling the pinch on stable-branch reviewers in Heat, so now that I understand the process a bit better, let's try this again. I'd like to nominate Huang Tianhua to join the heat-stable-maint team. Tianhua is a heat-core member and one of our

Re: [openstack-dev] [TripleO][Heat] Conditionally passing properties in Heat

On 20/04/17 03:37, Steven Hardy wrote: On Wed, Apr 19, 2017 at 02:51:28PM -0700, Dan Sneddon wrote: Unfortunately, I tried the recommendation that Thomas Herve made about using conditionals, but that failed. It appears that you can't use a get_attr inside of a conditional statement, I get an

Re: [openstack-dev] [tc][elections]questions about one platform vision

On 18/04/17 10:39, Flavio Percoco wrote: On 16/04/17 09:03 +0100, Neil Jerram wrote: FWIW, I think the Lego analogy is not actually helpful for another reason: it has vastly too many ways of combining, and (hence) no sense at all of consistency / interoperability between the different things

Re: [openstack-dev] [heat][sahara][magnum][tripleo] Scaling nested stack validation

On 28/11/16 14:20, Zane Bitter wrote: On 23/11/16 17:58, Zane Bitter wrote: I also investigated another issue, which is that since the fix for https://bugs.launchpad.net/heat/+bug/1388140 landed (in Kilo) I believe we are validating nested stacks multiple times (specifically, m times, where m

[openstack-dev] [stable][heat] Nominate huangtianhua for heat-stable-maint

We are feeling the pinch on stable-branch reviewers in Heat, so now that I understand the process a bit better, let's try this again. I'd like to nominate Huang Tianhua to join the heat-stable-maint team. Tianhua is a heat-core member and one of our most prolific stable branch reviewers:

[openstack-dev] [all][tc] OpenStack is for applications

Hello OpenStackists, One of the great strengths of our community is the way our panoply of teams can make independent progress towards our goals with a breadth that no one person or group could hope to keep track of, let alone control. However, for this to work then from time to time we need

Re: [openstack-dev] Project Navigator Updates - Feedback Request

On 24/03/17 12:57, Lauren Sell wrote: Hi everyone, We’ve been talking for some time about updating the project navigator, and we have a draft ready to share for community feedback before we launch and publicize it. One of the big goals coming out of the joint TC/UC/Board meeting a few weeks

Re: [openstack-dev] [tripleo][ui] [heat] i18n proposal for heat templates 'description' help strings

On 23/03/17 04:39, Peng Wu wrote: Hi, For TripleO UI project, some users requested to translate the web UI. But some web UI string are from heat template files in tripleo-heat- templates project. In order to get translated templates displayed in tripleo-ui, we propose a blueprint as

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 13/03/17 17:20, Davanum Srinivas wrote: Zane, Sorry for the top post, Can you please submit a TC resolution? I can help with it as well. Let's test the waters. OK, here is a start: https://review.openstack.org/#/c/447031/ - ZB Thanks, Dims On Mon, Mar 13, 2017 at 5:10 PM, Zane Bitter

Re: [openstack-dev] [tripleo][heat] Heat memory usage in the TripleO gate: Ocata edition

On 16/03/17 09:36, Joe Talerico wrote: On Wed, Mar 15, 2017 at 5:53 PM, Zane Bitter <zbit...@redhat.com> wrote: On 15/03/17 15:52, Joe Talerico wrote: Can we start looking at CPU usage as well? Not sure if your data has this as well... Usage by Heat specifically? Or just in general?

Re: [openstack-dev] [tripleo][heat] Heat memory usage in the TripleO gate: Ocata edition

On 15/03/17 15:52, Joe Talerico wrote: Can we start looking at CPU usage as well? Not sure if your data has this as well... Usage by Heat specifically? Or just in general? We're limited by what is logged in the gate, so CPU usage by Heat is definitely a non-starter. Picking a random gate

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 15/03/17 14:41, Jay Pipes wrote: On 03/15/2017 01:21 PM, Fox, Kevin M wrote: Other OpenStack subsystems (such as Heat) handle this with Trusts. A service account is made in a different, usually SQL backed Keystone Domain and a trust is created associating the service account with the User.

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 15/03/17 08:45, Sean Dague wrote: On 03/13/2017 05:10 PM, Zane Bitter wrote: I'm not sure I agree. One can very simply inject needed credentials into a running VM and have it interact with the cloud APIs. Demo please! Most Keystone backends are read-only, you can't even create a new user

[openstack-dev] [tripleo][heat] Heat memory usage in the TripleO gate: Ocata edition

Following up on the previous thread: http://lists.openstack.org/pipermail/openstack-dev/2017-January/109748.html Here is the latest data, which includes the Ocata release: https://fedorapeople.org/~zaneb/tripleo-memory/20170314/heat_memused.png As you can see, there has been one jump in

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 13/03/17 18:16, Jay Pipes wrote: Who, specifically, are these gatekeepers of which you speak? In this case, the Nova & Keystone core teams. - ZB __ OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 10/03/17 21:34, Clint Byrum wrote: (BTW I proposed a workaround for Magnum/Kuryr at the PTG by using a pre-signed Zaqar URL with a subscription triggering a Mistral workflow, and I've started working on a POC.) What triggers the boot to kick over the bucket full of golf balls though? It's

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 12/03/17 11:30, Clint Byrum wrote: Excerpts from Fox, Kevin M's message of 2017-03-11 21:31:40 +: No, they are treated as second class citizens. Take Trova again as an example. The underlying OpenStack infrastructure does not provide a good security solution for Trove's use case. As

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 10/03/17 14:30, Jay Pipes wrote: On 03/10/2017 01:37 PM, Zane Bitter wrote: On 09/03/17 23:57, Renat Akhmerov wrote: And this whole discussion is taking me to the question: is there really any officially accepted strategy for OpenStack for 1, 3, 5 years? Is there any ultimate community goal

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 10/03/17 17:43, Clint Byrum wrote: Excerpts from Fox, Kevin M's message of 2017-03-10 20:47:55 +: Just because the market hasn't immediately shifted from IaaS to containers doesn't mean it won't happen eventually, and that google's wrong in their push for containers over IaaS. It took a

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 10/03/17 12:27, Monty Taylor wrote: On 03/10/2017 10:59 AM, Clint Byrum wrote: I'm curious what you (Josh) or Zane would change too. Containers/apps/kubes/etc. have to run on computers with storage and networks. OpenStack provides a pretty rich set of features for giving users computers with

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 10/03/17 11:59, Clint Byrum wrote: What a community like ours is good at doing is gathering all the exciting industry leading bleeding edge chaos into a boring commodity platform. What Zane is saying (and I agree with) is let's make sure we see the whole cloud forest and not just focus on

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 09/03/17 23:57, Renat Akhmerov wrote: And this whole discussion is taking me to the question: is there really any officially accepted strategy for OpenStack for 1, 3, 5 years? Is there any ultimate community goal we’re moving to regardless of underlying technologies (containers,

Re: [openstack-dev] [tc][appcat] The future of the App Catalog

On 08/03/17 11:23, David Moreau Simard wrote: The App Catalog, to me, sounds sort of like a weird message that OpenStack somehow requires applications to be packaged/installed/deployed differently. If anything, perhaps we should spend more effort on advertising that OpenStack provides bare metal

Re: [openstack-dev] [TripleO][Heat] Selectively disabling deployment resources

On 08/03/17 10:05, James Slagle wrote: On Tue, Mar 7, 2017 at 7:24 PM, Zane Bitter <zbit...@redhat.com> wrote: On 07/03/17 14:34, James Slagle wrote: I've been working on this spec for TripleO: https://review.openstack.org/#/c/431745/ which allows users to selectively disable Heat depl

Re: [openstack-dev] [TripleO][Heat] Selectively disabling deployment resources

On 07/03/17 14:34, James Slagle wrote: I've been working on this spec for TripleO: https://review.openstack.org/#/c/431745/ which allows users to selectively disable Heat deployment resources for a given server (or server in the case of a *DeloymentGroup resource). I'm not completely clear on

Re: [openstack-dev] [telemetry][heat] Removal of Aodh combination alarms

On 24/02/17 06:15, Julien Danjou wrote: Hey, We're about to remove the code for the deprecated combination alarm. https://review.openstack.org/#/c/429405/ I checked and as far as I can tell that should not break Heat gate, but I'd prefer to be sure. So, Heat developers if you have some code

Re: [openstack-dev] [stable][heat] Heat stable-maint additions

On 18/02/17 03:24, Thierry Carrez wrote: Thomas Herve wrote: [...] At any rate, it's a matter of trust, a subject that comes from time to time, and it's fairly divisive. In this case though, I find it ironic that I can approve whatever garbage I want on master, it can make its way into a

[openstack-dev] [stable][heat] Heat stable-maint additions

merged, amongst other things. I'd like to request that we update the membership to be the same as https://review.openstack.org/#/admin/groups/152,members Rabi Mishra Rico Lin Sergey Kraynev Steve Baker Steven Hardy Thomas Herve Zane Bitter I also wonder if the stable-maint team would consider

[openstack-dev] [Heat] Breaking change to 3rd-party Template plugin API

This email is directed at anyone who maintains a 3rd-party Template plugin for Heat. (Do such people exist?) Good news: you know how it's never been clear what parts of the Stack and Resource interfaces you could rely on to be stable? I'm proposing to fix that in Pike. Bad news: you know

Re: [openstack-dev] [Heat][TripleO] How to run mistral workflows via templates

Better late than never... On 16/12/16 08:57, Steven Hardy wrote: I know we've previously tried to steer execute/run type actions to signal driven interfaces (and I myself have opposed these kinds of resources in the past, to be honest). However, I can't currently see a better way to handle

Re: [openstack-dev] [heat][tripleo] Heat memory usage in the TripleO gate during Ocata

On 11/01/17 09:21, Zane Bitter wrote: From that run, total memory usage by Heat was 2.32GiB. That's a little lower than the peak that occurred near the end of Newton development for the legacy path, but still more than double the current legacy path usage (0.90GiB on the job that ran

Re: [openstack-dev] 答复: [heat] glance v2 support?

On 11/01/17 10:01, Thomas Herve wrote: On Wed, Jan 11, 2017 at 3:34 PM, Emilien Macchi wrote: On Wed, Jan 11, 2017 at 2:50 AM, Thomas Herve wrote: I think this is going where I thought it would: let's not do anything. The image resource is there for v1

Re: [openstack-dev] [heat][tripleo] Heat memory usage in the TripleO gate during Ocata

On 06/01/17 16:58, Emilien Macchi wrote: It's worth reiterating that TripleO still disables convergence in the undercloud, so these are all tests of the legacy code path. It would be great if we could set up a non-voting job on t-h-t with convergence enabled and start tracking memory use over

Re: [openstack-dev] 答复: [heat] glance v2 support?

On 10/01/17 14:17, Tim Bell wrote: On 10 Jan 2017, at 17:41, Zane Bitter <zbit...@redhat.com <mailto:zbit...@redhat.com>> wrote: On 10/01/17 05:25, Flavio Percoco wrote: I'd recommend Heat to not use locations as that will require deployers to either enable them for ever

Re: [openstack-dev] 答复: [heat] glance v2 support?

On 10/01/17 05:25, Flavio Percoco wrote: I'd recommend Heat to not use locations as that will require deployers to either enable them for everyone or have a dedicate glance-api node for Heat. If not use location, do we have other options for user? What should user to do before create a

Re: [openstack-dev] [heat][tripleo] Heat memory usage in the TripleO gate during Ocata

On 06/01/17 16:35, Thomas Herve wrote: Thanks a lot for the analysis. It's great that things haven't gotten off track. I tracked down most of the step changes to identifiable patches: 2016-10-07: 2.44GiB -> 1.64GiB - https://review.openstack.org/382068/ merged, making ResourceInfo classes

Re: [openstack-dev] [heat][tripleo] Heat memory usage in the TripleO gate during Ocata

On 06/01/17 16:40, Hugh Brock wrote: Why would TripleO not move to convergence at the earliest possible point? We'll need some data to decide when the earliest possible point is :) Last time Steve (Hardy) tested it I believe convergence was looking far worse than legacy in memory usage, at a

Re: [openstack-dev] [heat][tripleo] Heat memory usage in the TripleO gate during Ocata

On 06/01/17 16:58, Emilien Macchi wrote: On Fri, Jan 6, 2017 at 4:35 PM, Thomas Herve <the...@redhat.com> wrote: On Fri, Jan 6, 2017 at 6:12 PM, Zane Bitter <zbit...@redhat.com> wrote: It's worth reiterating that TripleO still disables convergence in the undercloud, so these a

[openstack-dev] [heat][tripleo] Heat memory usage in the TripleO gate during Ocata

tl;dr everything looks great, and memory usage has dropped by about 64% since the initial Newton release of Heat. I re-ran my analysis of Heat memory usage in the tripleo-heat-templates gate. (This is based on the gate-tripleo-ci-centos-7-ovb-nonha job.) Here's a pretty picture:

Re: [openstack-dev] [heat] Rolling upgrades vs. duplication of prop data

On 05/01/17 11:41, Crag Wolfe wrote: Hi, I have a patch[1] to support the de-duplication of resource properties data between events and resources. In the ideal rolling-upgrade world, we would be writing data to the old and new db locations, only reading from the old in the first release (let's

Re: [openstack-dev] [heat] A question on the endpoint of Heat

On 20/12/16 02:29, zengchen wrote: Hi, Heat stackers: May I ask a question about the endpoint of Heat. I see the endpoints of Heat registered to Keystone look like this. 'http://10.229.45.150:8004/v1/$(project_id)s' . My question is that why use '$' instead of '%' as the replacement symbol.

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

On 14/12/16 18:18, Michał Jastrzębski wrote: I agree that meeting notes are crucial to this type of meeting.I just say that gerrit PoC/demo is valid form of 'notes' if meeting was about some implementional detail, which I assume is the case for this type of meetings. Do we agree that as hoc

Re: [openstack-dev] [tripleo] Requesting files from the overcloud from the undercloud

On 12/12/16 09:09, Steven Hardy wrote: On Wed, Nov 30, 2016 at 01:54:34PM -0700, Alex Schultz wrote: Hey folks, So I'm in the process of evaluating options for implementing the capture-environment-status-and-logs[0] blueprint. At the moment my current plan is to implement a mistral workflow

Re: [openstack-dev] [heat] On allowing null as a parameter default

On 08/12/16 08:40, Steven Hardy wrote: On Mon, Dec 05, 2016 at 04:27:50PM -0500, Zane Bitter wrote: Any parameter in a Heat template that has a default other than None is considered optional, so the user is not required to pass a value. Otherwise, however, the parameter is required and creating

[openstack-dev] [heat] On allowing null as a parameter default

Any parameter in a Heat template that has a default other than None is considered optional, so the user is not required to pass a value. Otherwise, however, the parameter is required and creating the stack will fail pretty immediately if the user does not pass a value. I've noticed that this

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

On 29/11/16 10:28, Doug Hellmann wrote: Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600: On 11/29/2016 08:03 AM, Doug Hellmann wrote: I'll rank my preferred solutions, because I don't actually like any of them. Just curious...what would you "actually like"? Chris My

Re: [openstack-dev] [heat][sahara][magnum][tripleo] Scaling nested stack validation

On 23/11/16 17:58, Zane Bitter wrote: I also investigated another issue, which is that since the fix for https://bugs.launchpad.net/heat/+bug/1388140 landed (in Kilo) I believe we are validating nested stacks multiple times (specifically, m times, where m is the stack's depth in the tree

Re: [openstack-dev] [heat][zaqar][telemetry] Subscribing to events

On 28/10/16 08:32, Julien Danjou wrote: > 2. Content Format > The info/data forwarded by Aodh is alarm, not the original event. At here, > I assume most of the users would like to see the original event, not the alarm. That sounds easy. :) Not that easy:

[openstack-dev] [heat][sahara][magnum][tripleo] Scaling nested stack validation

We discussed $SUBJECT at the summit as one of the main performance problems that people are running into when trying to create very large autoscaling groups, as projects like Sahara, Magnum, TripleO, OpenShift are wont to do. Of course, as we all know, validation happens synchronously, so it's

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

On 18/11/16 16:56, Clint Byrum wrote: Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500: So, say that I want to create my servers in Heat so that I can use Heat software deployments for orchestration. How would I go about e.g. making sure that the servers are always connected to

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

On 18/11/16 16:47, Clint Byrum wrote: Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500: On 15/11/16 09:56, Monty Taylor wrote: Hey everybody! At this past OpenStack Summit the results of the Interop Challenge were shown on stage. It was pretty awesome - 17 different people

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

On 17/11/16 19:01, Monty Taylor wrote: On 11/17/2016 05:24 PM, Zane Bitter wrote: On 15/11/16 09:56, Monty Taylor wrote: Hey everybody! At this past OpenStack Summit the results of the Interop Challenge were shown on stage. It was pretty awesome - 17 different people from 17 different clouds

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

On 15/11/16 09:56, Monty Taylor wrote: Hey everybody! At this past OpenStack Summit the results of the Interop Challenge were shown on stage. It was pretty awesome - 17 different people from 17 different clouds ran the same workload. And it worked! However, one of the reasons it worked is

Re: [openstack-dev] [heat][tripleo] New repository for software-config elements

On 15/11/16 04:26, Thomas Herve wrote: Hi all, Historically elements to create images using software config were developed in the heat-templates repository, which turned out to mean that this had to be packaged, etc. Today we were asked if tags could be added to help maintaining the packages.

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

On 13/11/16 11:44, Jeremy Stanley wrote: On 2016-11-12 17:44:42 -0800 (-0800), Clint Byrum wrote: https://www.apache.org/licenses/GPL-compatibility.html "This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then

Re: [openstack-dev] [tc][kolla] Ansible module with GPLv3

On 04/11/16 12:51, Jeremy Stanley wrote: On 2016-11-04 11:42:25 -0500 (-0500), Michał Jastrzębski wrote: [...] Kolla is licensed as Apache v2 all across the board today. To implement one of highly requested features we would need to develop so-called strategy plugin for ansible, and I can't see

Re: [openstack-dev] [FaaS] Function as a service in OpenStack

On 01/11/16 22:20, Lingxian Kong wrote: Hi, all, Recently when I was talking with some customers of our OpenStack based public cloud, some of them are expecting to see a service similar to AWS Lambda in OpenStack ecosystem (so such service could be invoked by Heat, Mistral, Swift, etc.). This

Re: [openstack-dev] [tripleo] Ocata specs

On 01/11/16 15:13, James Slagle wrote: On Tue, Nov 1, 2016 at 7:21 PM, Emilien Macchi wrote: Hi, TripleO (like some other projects in OpenStack) have not always done good job in merging specs on time during a cycle. I would like to make progress on this topic and for that,

Re: [openstack-dev] [heat][zaqar][telemetry] Subscribing to events

On 22/10/16 10:38, Thomas Herve wrote: Hi all, One of my long time goal since I started contributing to OpenStack is to try to remove polling where I can. With Zaqar WebSocket support, we now have a transport available for users to connect to, and where we can push notifications. We already

Re: [openstack-dev] [heat] Rolling Upgrades

On 21/10/16 08:37, Michał Dulko wrote: > Finally, a note about Oslo versioned objects: they don't really help > us. They work great for nova where there is just nova-conductor > reading and writing to the DB, but we have multiple heat-engines doing > that that need to be restarted in a rolling

Re: [openstack-dev] [heat] Rolling Upgrades

On 20/10/16 20:02, Crag Wolfe wrote: AFAIK, only sqlalchemy+mariadb is being used in production I believe there are people using Postgres in production, or at least there were at one point. - ZB __ OpenStack

Re: [openstack-dev] [heat] Design Summit Schedule

On 14/10/16 09:31, Rabi Mishra wrote: Hi All, As agreed in the last team meeting, I've pushed the final design summit schedule[1][2] for heat. Please have a look and let me know, if we need to change anything (I assume, we can still make some changes in the last week before summit). Note: I've

Re: [openstack-dev] [heat] [magnum] Subjects to discuss during the summit

On 10/10/16 11:11, Spyros Trigazis wrote: 4. Finally, a thought under investigation is replacing the nodes one by one using a different image. e.g. Upgrade from fedora 24 to 25 with new versions of packages all in a new qcow2 image. How could we update the stack for this? This should

Re: [openstack-dev] [heat] [magnum] Subjects to discuss during the summit

On 11/10/16 02:24, Rabi Mishra wrote: 1.2 For large stacks, 1000 nodes, the final call to heat to fetch the IPs for all nodes takes 3 to 4 minutes. In heat, the stack has status CREATE_COMPLETE but magnum's state is updated

Re: [openstack-dev] [all][elections] Results of the TC Election

On 09/10/16 19:58, Tony Breeds wrote: On Mon, Oct 10, 2016 at 10:49:12AM +1100, Tony Breeds wrote: Please join me in congratulating the 6 newly elected members of the TC. Doug Hellmann (dhellmann) Emilien Macchi (emilienm) Jeremy Stanley (fungi) Monty Taylor (mordred) Sean Dague (sdague) Steve

Re: [openstack-dev] [TripleO][CI] Need more undercloud resources

On 25/08/16 09:49, James Slagle wrote: On Thu, Aug 25, 2016 at 5:40 AM, Derek Higgins wrote: On 25 August 2016 at 02:56, Paul Belanger wrote: On Wed, Aug 24, 2016 at 02:11:32PM -0400, James Slagle wrote: The latest recurring problem that is failing

Re: [openstack-dev] [neutron][lbaas][heat][octavia] Heat engine doesn't detect lbaas listener failures

On 27/09/16 15:11, Jiahao Liang wrote: Hello all, I am trying to use heat to launch lb resources with Octavia as backend. The template I used is from https://github.com/openstack/heat-templates/blob/master/hot/lbaasv2/lb_group.yaml. Following are a few observations: 1. Even though Listener

Re: [openstack-dev] [all][elections][TC] TC Candidacy

On 27/09/16 06:19, John Davidge wrote: Having Stackforge as a separate Github organization and set of >repositories was a maintenance nightmare due to the awkwardness of >renaming projects when they "moved into OpenStack". There's no reason that this would need a separate github structure, just

Re: [openstack-dev] [oslo.db] [release] opportunistic tests breaking randomly

On 21/09/16 11:41, Joshua Harlow wrote: tl;dr this appears to have been around forever (at least since we switched to using a pure-Python MySQL client) and is almost certainly completely unrelated to any particular release of oslo.db. Update: Mike was kind enough to run this one to ground and

Re: [openstack-dev] [heat] [horizon] why is heat service-list limited to 'admin project?

On 21/09/16 03:30, Akihiro Motoki wrote: Hi, The default policy.json provided by heat limits 'service-list' API to 'admin' project like below. Is there any reason 'admin' role user in non-'admin' project cannot see service-list? https://bugs.launchpad.net/keystone/+bug/968696

Re: [openstack-dev] [oslo.db] [release] opportunistic tests breaking randomly

On 14/09/16 11:44, Mike Bayer wrote: On 09/14/2016 11:08 AM, Mike Bayer wrote: On 09/14/2016 09:15 AM, Sean Dague wrote: I noticed the following issues happening quite often now in the opportunistic db tests for nova -

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

On 30/08/16 12:18, Jiří Stránský wrote: Hmm yea that's strange, because YAQL has a test case for reduce() with 5 items: https://github.com/openstack/yaql/blob/f71a0305089997cbfa5ff00f660920711b04f39e/yaql/tests/test_queries.py#L337-L339 If YAQL people are reading this, I suggest you should

Re: [openstack-dev] [heat][yaql] Deep merge map of lists?

On 30/08/16 12:02, Steven Hardy wrote: debug_tripleo2: value: yaql: expression: $.data.l.reduce($1.mergeWith($2)) data: l: - "gnocchi_metricd_node_names": ["overcloud-controller-0", "overcloud-controller-1",

Re: [openstack-dev] [all][massively distributed][architecture] Coordination between actions/WGs

On 24/08/16 20:37, Jay Pipes wrote: On 08/24/2016 04:26 AM, Peter Willis wrote: Colleagues, I'd like to confirm that scalability and multi-site operations are key to BT's NFV use cases e.g. vCPE, vCDN, vEPC, vIMS, MEC, IoT, where we will have compute highly distributed around the network (from

Re: [openstack-dev] [heat][tripleo][horizon][tripleo-ui] Parameter groups, tags and deprecation

On 25/08/16 14:02, Steven Hardy wrote: Hi all, So I'm following up on a discussion that started here: https://review.openstack.org/#/c/356240 Basically I recently suggested[1] that relaxing the restriction where a parameter can only exist in exactly one parameter_group would be a way to help

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

On 19/08/16 09:55, Anant Patil wrote: What I'm suggesting is very close to that: (1) stack-cancel-update will start another update using the previous template/environment. We'll start rolling back; in-progress resources will be allowed to complete normally. (2)

[openstack-dev] [Heat] Review priorities for feature freeze

Following on from the IRC meeting this morning, I started an etherpad with the top-priority reviews for the core team to be looking at in the lead-up to feature freeze: https://etherpad.openstack.org/p/heat-newton-reviews If you have other high-priority patches please add them to the list.

Re: [openstack-dev] [Heat][Horizon] Any guidelines for naming heat resource type names?

On 16/08/16 17:43, Praveen Yalagandula wrote: Hi all, We have developed some heat resources for our custom API server. We followed the instructions in the development guide at http://docs.openstack.org/developer/heat/pluginguide.html and got everything working. However, the Horizon "Resource

Re: [openstack-dev] [tripleo] Fernet Key rotation

On 09/08/16 21:21, Adam Young wrote: On 08/09/2016 06:00 PM, Zane Bitter wrote: In either case a good mechanism might be to use a Heat Software Deployment via the Heat API directly (i.e. not as part of a stack) to push changes to the servers. (I say 'push' but it's more a case of making

Re: [openstack-dev] [tripleo] Fernet Key rotation

On 09/08/16 18:28, Fox, Kevin M wrote: It needs to work in a distributed way... What happens if the one node you have cron running on doesn't work for a while. Keystone breaks? IIUC it wouldn't break, but your keys wouldn't get rotated so you'd end up using the same key until such time as

Re: [openstack-dev] [tripleo] Fernet Key rotation

On 09/08/16 17:11, Adam Young wrote: The Fernet token format uses a symmetric key to sign tokens. In order to check the signature, these keys need to be synchronized across all of the Keystone servers. I don't want to pass around nake symmetric keys. The right way to do this is to put them

Re: [openstack-dev] [magnum][heat] 2 million requests / sec, 100s of nodes

On 07/08/16 19:52, Clint Byrum wrote: Excerpts from Steve Baker's message of 2016-08-08 10:11:29 +1200: On 05/08/16 21:48, Ricardo Rocha wrote: Hi. Quick update is 1000 nodes and 7 million reqs/sec :) - and the number of requests should be higher but we had some internal issues. We have a

Re: [openstack-dev] [magnum][heat] 2 million requests / sec, 100s of nodes

On 08/08/16 17:09, Ricardo Rocha wrote: * trying the convergence_engine: as far as i could see this is already there, just not enabled by default. We can give it a try and let you know how it goes if there's no obvious drawback. Would it just work with the current schema? We're running heat

Re: [openstack-dev] [magnum][heat] 2 million requests / sec, 100s of nodes

On 05/08/16 12:01, Hongbin Lu wrote: Add [heat] to the title to get more feedback. Best regards, Hongbin *From:*Ricardo Rocha [mailto:rocha.po...@gmail.com] *Sent:* August-05-16 5:48 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev]

Re: [openstack-dev] [tc] persistently single-vendor projects

On 04/08/16 23:00, joehuang wrote: I think all the problem is caused by the definition "official OpenStack project" for one big-tent project. I understand that each OpenStack vendor wants some differentiation in their solution, while also would like to collaborate with common core projects.

Re: [openstack-dev] [sahara][heat][infra] breakage of Sahara gate and images from openstack.org

On 29/07/16 13:12, Luigi Toscano wrote: Hi all, the Sahara jobs on the gate run the scenario tests (from sahara-tests) using the fake plugin, so no real Hadoop/Spark/BigData operations are performed, but other the other expected operations are executed on the image. In order to do this we used

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

n 07/28/2016 12:33 PM, Steven Dake (stdake) wrote: Doug, Zane's analysis is correct. I agree with Zane's assessment that TC clarification can solve this situation. Regards -steve On 7/28/16, 9:15 AM, "Zane Bitter" <zbit...@redhat.com> wrote: On 28/07/16 08:48, Vladimir Kozhukalov wrot

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

On 28/07/16 14:20, Jay Pipes wrote: How would guidance from the TC about what it means for a repo to be "part of the OpenStack tent" add clarity for repos that are not trying to be part of the OpenStack tent? If it were clear what it means for a repo to be "part of the OpenStack tent" then it

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

e: Doug, Zane's analysis is correct. I agree with Zane's assessment that TC clarification can solve this situation. Regards -steve On 7/28/16, 9:15 AM, "Zane Bitter" <zbit...@redhat.com> wrote: On 28/07/16 08:48, Vladimir Kozhukalov wrote: Fuel-ccp repositories are public, e

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

On 28/07/16 08:48, Vladimir Kozhukalov wrote: Fuel-ccp repositories are public, everyone is welcome to participate. I don’t see where we violate “4 opens”. These repos are now experimental. At the moment the team is working on building CI pipeline and developing functional tests that are to be

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

On 20/07/16 18:41, Clint Byrum wrote: Excerpts from Fox, Kevin M's message of 2016-07-20 20:12:48 +: And maybe this raises an interesting defininition mismatch in the conversation. There is archetectural stuff like, do we support 7 different web frameworks, or do we standardize on

Re: [openstack-dev] Mascot/logo for your project

On 19/07/16 12:26, gordon chung wrote: On 19/07/16 03:50 AM, Julien Danjou wrote: Heidi, could you confirm that it is a mascot per team or per project? Honestly, I don't think it'll suit us to have only one mascot/logo. It's gonna be hard to use a logo marked "Telemetry" as a branding for

<    1   2   3   4   5   6   7   8   >