Re: [openstack-dev] Paste unmaintained

On Thu, Aug 2, 2018 at 4:27 PM, Doug Hellmann wrote: > Excerpts from Stephen Finucane's message of 2018-08-02 15:11:25 +0100: >> tl;dr: It seems Paste [1] may be entering unmaintained territory and we >> may need to do something about it. >> >> I was cleaning up some warning messages that nova

Re: [openstack-dev] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

On Sat, May 5, 2018 at 1:53 AM, Eric K wrote: > Thanks a lot Witold and Thomas! > > So it doesn't seem that someone is currently using a keystone token to > authenticate web hook? Is is simply because most of the use cases had > involved services which do not use

Re: [openstack-dev] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

On Thu, May 3, 2018 at 9:49 PM, Eric K wrote: > Question to the projects which send or consume webhook notifications > (telemetry, monasca, senlin, vitrage, etc.), what are your > supported/preferred authentication mechanisms? Bearer token (e.g. > Keystone)? Signing? > >

Re: [openstack-dev] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

On Mon, Apr 23, 2018 at 8:09 PM, Dan Sneddon wrote: > We could add the ControlPlaneDefaultRoute and ControlPlaneSubnetCidr to > network_data.yaml, but this would involve some duplication of configuration > data, since those are currently defined in undercloud.conf. A more

Re: [openstack-dev] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

On Mon, Apr 23, 2018 at 7:16 PM, Harald Jensås <hjen...@redhat.com> wrote: > On Fri, 2018-04-20 at 14:44 +0200, Thomas Herve wrote: >> To make it clear, what you want to prevent is the need to add more >> keys in network_data.yaml? >> >> As those had to be

Re: [openstack-dev] [Heat][TripleO] - Getting attributes of openstack resources not created by the stack for TripleO NetworkConfig.

On Thu, Apr 19, 2018 at 2:59 PM, Harald Jensås wrote: > Hi, Hi, thanks for sending this. Responses inline. > When configuring TripleO deployments with nodes on routed ctlplane > networks we need to pass some per-network properties to the > NetworkConfig resource[1] in THT.

Re: [openstack-dev] [Zaqar] Nominating yangzhenyu for Zaqar core

On Mon, Feb 26, 2018 at 2:38 AM, Fei Long Wang wrote: > Hi team, > > I would like to propose adding Zhenyu Yang(yangzhenyu) for the Zaqar core > team. He has been an awesome contributor since joining the Zaqar team. And > now he is the most active non-core contributor

Re: [openstack-dev] [all] cyclomatic complexity check in flake8 & Python 3

On Tue, Dec 12, 2017 at 2:08 PM, Thierry Carrez wrote: > Zane Bitter wrote: >> We have around 60 repos using the 'mccabe' package to do cyclomatic >> complexity checks in flake8 in their gate jobs.[1] Based on advice >> received at the time[2], the version of mccabe that we

Re: [openstack-dev] [Zaqar] Nominating gecong for Zaqar core

On Tue, Oct 10, 2017 at 11:15 PM, feilong wrote: > Hi team, > > I would like to propose adding Cong Ge(gecong) for the Zaqar core team. > He has been an awesome contributor since joining the Zaqar team. And now > he is currently the most active non-core reviewer on Zaqar

Re: [openstack-dev] [Heat] revised structure of the heat-templates repository. Suggestions

On Fri, May 19, 2017 at 5:00 PM, Lance Haig wrote: > Hi, Hi Lance, Thanks for starting this. Comments inline. > As we know the heat-templates repository has become out of date in some > respects and also has been difficult to be maintained from a community > perspective.

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

On Wed, Apr 12, 2017 at 9:00 PM, Dan Sneddon wrote: > I'm implementing predictable control plane IPs for spine/leaf, and I'm > running into a problem implementing this in the TripleO Heat templates. > > I have a review in progress [1] that works, but fails on upgrade, so I'm

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

On Thu, Mar 23, 2017 at 9:39 AM, 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

Re: [openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

On Wed, Mar 22, 2017 at 3:24 PM, Alex Schultz wrote: > On Wed, Mar 22, 2017 at 7:58 AM, Paul Belanger wrote: [snip] >> Please correct me if I am wrong, because I still have my container training >> wheels on. I understand the need for etcd, and

Re: [openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

On Tue, Mar 21, 2017 at 10:26 PM, Davanum Srinivas wrote: > Jay, > > the /v3alpha HTTP API (grpc-gateway) supports watch > https://coreos.com/etcd/docs/latest/dev-guide/apispec/swagger/rpc.swagger.json Ah, that's a great find, thanks. That means that we don't have to use

Re: [openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

On Wed, Mar 15, 2017 at 12:05 AM, Joshua Harlow wrote: > * How does reloading work (does it)? No. There is nothing that we can do in oslo that will make services magically reload configuration. It's also unclear to me if that's something to do. In a containerized

Re: [openstack-dev] [mistral] Mistral Custom Actions API Design

On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady wrote: > > One of the pain points for me as an action developer is the OpenStack > actions[1]. Since they all use the same method name to retrieve the > underlying client, you cannot simply inherit from more than one so you are >

Re: [openstack-dev] [requirements] pycrypto is dead, long live pycryptodome... or cryptography...

On Wed, Mar 8, 2017 at 8:03 PM, Matthew Thode wrote: > So, pycrypto upstream is dead and has been for a while, we should look > at moving off of it for both bugfix and security reasons. > > Currently it's used by the following. > > barbican, cinder, trove, glance, heat,

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

On Tue, Feb 28, 2017 at 7:54 AM, Sergey Kraynev wrote: > Zane, > as I understand, all related code was removed. Probably we may to remove our > Hidden resource too. We can't remove our hidden resources, because it breaks stacks that reference them (to the point that you

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

On Fri, Feb 17, 2017 at 5:48 PM, Ian Cordasco <sigmaviru...@gmail.com> wrote: > -Original Message- > From: Thomas Herve <the...@redhat.com> [snip] >> Respecting the guidelines is totally fair, but review stats won't tell >> you much, at least in my case:

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

least the >> current PTL (Rico Lin) and the previous PTL (Rabi Mishra), and possibly >> others (Thomas Herve, Sergey Kraynev), haven't been added to the group. >> That's slowing down getting backports merged, amongst other things. >> >> I'd like to request that we upd

Re: [openstack-dev] [tc][glance][glare][all] glance/glare/artifacts/images at the PTG

On Mon, Feb 13, 2017 at 8:39 PM, Clint Byrum wrote: [snip] > Any attempt at versioning that is not git, will frustrate any git user. > This cat's already out of the bag, but I'd suggest adding git repositories > as a blob container type and finding a way to allow git to

Re: [openstack-dev] Attempting to proxy websockets through Apache or HAProxy for Zaqar

On Tue, Jan 17, 2017 at 6:23 PM, Dan Trainor wrote: > Hi - > > In an attempt to work on [0], I've been playing around with proxying all the > service API endpoints that the UI needs to communicate with, through either > haproxy or Apache to avoid a bug[1] around how

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

On Wed, Jan 11, 2017 at 3:34 PM, Emilien Macchi <emil...@redhat.com> wrote: > On Wed, Jan 11, 2017 at 2:50 AM, Thomas Herve <the...@redhat.com> wrote: >> I think this is going where I thought it would: let's not do anything. >> The image resource is

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

On Tue, Jan 10, 2017 at 10:41 PM, Clint Byrum wrote: > Excerpts from Zane Bitter's message of 2017-01-10 15:28:04 -0500: >> location is a required property: >> >> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Glance::Image >> >> The resource type

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

On Tue, Jan 10, 2017 at 9:28 PM, Zane Bitter wrote: > On 10/01/17 14:17, Tim Bell wrote: >> >> >>> On 10 Jan 2017, at 17:41, Zane Bitter >> > wrote: >>> >>> On 10/01/17 05:25, Flavio Percoco wrote: > I'd

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

On Fri, Jan 6, 2017 at 6:12 PM, Zane Bitter wrote: > 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

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

On Fri, Dec 16, 2016 at 2:57 PM, Steven Hardy <sha...@redhat.com> wrote: > On Fri, Dec 16, 2016 at 02:03:10PM +0100, Thomas Herve wrote: >> On Fri, Dec 16, 2016 at 1:17 PM, Giulio Fidente <gfide...@redhat.com> wrote: >> > I was wondering if it would make sense to ha

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

On Fri, Dec 16, 2016 at 1:17 PM, Giulio Fidente wrote: > hi, > > we're trying to address in TripleO a couple of use cases for which we'd like > to trigger a Mistral workflow from a Heat template. > > One example where this would be useful is the creation of the Swift rings, >

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

On Wed, Nov 23, 2016 at 11:58 PM, Zane Bitter wrote: > 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

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

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. Before we do that, I wonder if we should

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

On Tue, Oct 25, 2016 at 12:12 AM, Zane Bitter <zbit...@redhat.com> wrote: > 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

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

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 leveraged that in Heat [1], so that you can

Re: [openstack-dev] [heat]Delete trust with exception when deleting a stack?

On Fri, Oct 14, 2016 at 4:39 PM, zhu4236926 wrote: > Hi guys, >1. I set the conifg deferred_auth_method with value trusts, so a trust > record will be created in keystone when creating a stack, and heat save the > trust result to db. >2. Delete the stack, if all

Re: [openstack-dev] [heat] resigning from heat-cores

On Mon, Sep 12, 2016 at 2:35 PM, Pavlo Shchelokovskyy wrote: > Hi Heaters, > > with great regret I announce my resignation from the heat-core team. > > About a year ago I was reassigned to another project, and despite my best > efforts I came to conclusion that

[openstack-dev] [Heat] Convergence status

Hi all, We're approaching release time, and there are still some concerns whether or not we can make convergence the default. In particular we have a somewhat longstanding issue with canceling creation [1]. The good news is that this is almost fixed [2], and update cancel is almost there too [3].

Re: [openstack-dev] what permission is required to create a Keystone trust

On Thu, Sep 1, 2016 at 5:54 AM, Matt Jia wrote: > Hi, > > I am experimenting the Keystone Trusts feature with a script which creates a > trust between two users. > > import keystoneclient.v3 as keystoneclient > #import swiftclient.client as swiftclient > > > auth_url_v3 =

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

On Tue, Aug 30, 2016 at 6:02 PM, Steven Hardy wrote: > On Tue, Aug 30, 2016 at 04:10:47PM +0200, Jiří Stránský wrote: >> >> On 30.8.2016 10:17, Steven Hardy wrote: >> >> >> >> > Yeah, that gets us closer, but we do need to handle more than one value >> > (list entry) per key,

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

On Mon, Aug 29, 2016 at 3:16 PM, Steven Hardy <sha...@redhat.com> wrote: > On Mon, Aug 29, 2016 at 07:07:09AM +0200, Thomas Herve wrote: >> dict($.groupBy($.keys().toList()[0], $.values().toList()[0][0])) >> >> ought to work, I believe? > > So, as it tu

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

On Sun, Aug 28, 2016 at 11:58 PM, Steven Hardy wrote: > Hi all, > > I have a need to merge a list of maps of lists: > > heat_template_version: 2016-10-14 > > outputs: > debug: > value: > yaql: > # dict(vms=>dict($.vms.select([$.name, $]))) >

Re: [openstack-dev] [TripleO] a new Undercloud install driven by Heat

On Thu, Aug 4, 2016 at 11:48 PM, Dan Prince wrote: > Last week I started some prototype work on what could be a new way to > install the Undercloud. The driving force behind this was some of the > recent "composable services" work we've done in TripleO so initially I > called

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

On Mon, Jul 18, 2016 at 7:13 PM, Michael Still <mi...@stillhq.com> wrote: > On 16 Jul 2016 1:27 PM, "Thomas Herve" <the...@redhat.com> wrote: >> >> On Fri, Jul 15, 2016 at 8:36 PM, Fox, Kevin M <kevin@pnnl.gov> wrote: >> > The lack of Instan

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

On Fri, Jul 15, 2016 at 8:36 PM, Fox, Kevin M wrote: > Some specific things: > > Magnum trying to not use Barbican as it adds an addition dependency. See the > discussion on the devel mailing list for details. > > Horizon discussions at the summit around wanting to use Zaqar

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

On Mon, Jul 4, 2016 at 2:06 PM, 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

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

On Thu, May 26, 2016 at 11:48 AM, Jiri Tomasek <jtoma...@redhat.com> wrote: > On 05/25/2016 08:08 PM, Thomas Herve wrote: >> Sorry for not responding earlier, but I have some inputs. In Heat we >> publish events on Zaqar queue, and we defined this format: >> >>

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

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 workflows and act upon them > without having to do various polling hacks. > > Since

Re: [openstack-dev] [heat] enabled convergence background

On Fri, May 20, 2016 at 5:46 AM, xiangxinyong wrote: > Hi Team, > > I noticed that heat enabled convergence. I hope that's not the case :). We haven't made the switch yet. We continue to do testing, and we're still finding issues so we won't make it until we have a good

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

On Wed, May 18, 2016 at 8:49 PM, Zane Bitter 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 "crazy" to merely "unrealistic".[4] In the

[openstack-dev] [Heat] Summit recap

Hi all, Here are some of my thoughts on the Austin summit sessions. Don't hesitate to ask questions or fix my misunderstanding. I'll try to keep it short, please also refer to the etherpads for more details (sometimes :)): https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Heat

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

On Wed, Apr 20, 2016 at 12:14 PM, Ethan Lynn wrote: > Could we move Functional Tests to Thursday? I have a hands-on workshop at > wed 4:30-6:00 pm. Sorry, I don't have anything to switch it with. -- Thomas

[openstack-dev] [Heat] No IRC meeting next week

Hi all, As expected, no meeting during the summit next week. It will resume normally the week after, though I won't be around to run it. Thanks, -- Thomas __ OpenStack Development Mailing List (not for usage questions)

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

On Wed, Apr 20, 2016 at 3:26 AM, Zane Bitter wrote: > Umm, I thought that was the idea. > > I need to be at both of those Heat ones anyway, so this doesn't really help > me. I'd rather have the DLM session in this slot instead. (The only sessions > I can really skip are the

[openstack-dev] [Heat] Design summit planning

Hi all, We've been allocated 12 sessions for Austin. I started an etherpad where you can put topics that you'd like to talk about: https://etherpad.openstack.org/p/newton-heat-sessions. Please fill it up, we'll discuss what we have at the meeting tomorrow. Maybe we'll wait until next week to

Re: [openstack-dev] [Heat] Meeting time

On Wed, Mar 30, 2016 at 10:26 AM, Thomas Herve <the...@redhat.com> wrote: > On Wed, Mar 30, 2016 at 10:13 AM, Thomas Herve <the...@redhat.com> wrote: >> Hi all, >> >> I'd like to be able to attend at least one of the IRC meeting, and it >> doesn't really w

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

On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter 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 complex >> deployment like TripleO.

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

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] [Heat] Re-evaluate conditions specification

On Thu, Mar 31, 2016 at 11:39 AM, Qiming Teng <teng...@linux.vnet.ibm.com> wrote: > On Thu, Mar 31, 2016 at 10:40:33AM +0200, Thomas Herve wrote: >> Hi all, >> >> As the patches for conditions support are incoming, I've found >> something in the code (and the spec)

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

On Thu, Mar 31, 2016 at 10:40 AM, Thomas Herve <the...@redhat.com> wrote: > Hi all, > > As the patches for conditions support are incoming, I've found > something in the code (and the spec) I'm not really happy with. We're > creating a new top-level section in the templa

[openstack-dev] [Heat] Re-evaluate conditions specification

Hi all, As the patches for conditions support are incoming, I've found something in the code (and the spec) I'm not really happy with. We're creating a new top-level section in the template called "conditions" which holds names that can be reused for conditionally creating resource. While it's

Re: [openstack-dev] [Heat] Meeting time

On Wed, Mar 30, 2016 at 10:13 AM, Thomas Herve <the...@redhat.com> wrote: > Hi all, > > I'd like to be able to attend at least one of the IRC meeting, and it > doesn't really work right now. So if you'd like to come to meetings, > please fill the following doodle: >

[openstack-dev] [Heat] Meeting time

Hi all, I'd like to be able to attend at least one of the IRC meeting, and it doesn't really work right now. So if you'd like to come to meetings, please fill the following doodle: http://doodle.com/poll/4m6aicfnwuug86rs Note that I'll try to make the best choice depending on my selfish

[openstack-dev] [Heat] PTL Candidacy

Hi everyone, I'm happy to announce my candidacy for PTL of Heat for the Newton cycle. The project and the community are in a good place in my opinion currently, both diverse and active. As much as possible I'd like to continue encourage and improve that. Heat is being used more and more by

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

On Wed, Mar 16, 2016 at 11:57 AM, 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

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

On Thu, Mar 10, 2016 at 2:55 PM, Sean Dague <s...@dague.net> wrote: > On 03/10/2016 08:40 AM, Thomas Herve wrote: >> On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent <cdent...@anticdent.org> wrote: >>> +many. It would be great if we just got rid of the runnable web >&g

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent wrote: > On Thu, 10 Mar 2016, Sean Dague wrote: > >> These are HTTP services. They really shoudn't be claiming new ports, >> they should be running on a real webserver on 80 or 443. >> >> There is some legacy there with the

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

On Wed, Feb 17, 2016 at 7:54 PM, 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

Re: [openstack-dev] [magnum][heat] Bug 1544227

On Thu, Feb 11, 2016 at 5:23 PM, Hongbin Lu wrote: > Rabi, > > As you observed, I have uploaded two testing patches [1][2] that depends on > your fix patch [3] and the reverted patch [4] respectively. An observation is > that the test "gate-functional-dsvm-magnum-mesos"

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

On Mon, Dec 7, 2015 at 1:39 PM, 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]

Re: [openstack-dev] [Heat] get_reality implementation: default values, specified in config files

On Thu, Dec 3, 2015 at 1:00 PM, Peter Razumovsky wrote: > > Hello! > > During get_reality implementation next problem raised: if I don't specify > optional not update allowed property (like availabiliy_zone in > OS::Cinder::Volume), default value will be set for this

Re: [openstack-dev] [Heat] Enabling and Reading notifications

On Tue, Nov 3, 2015 at 11:22 PM, Pratik Mallya wrote: > Hello, > > I was looking for guidance as to how to enable notifications in heat and > if there is already a tool that can read those events? Looking through the > code, it gives somewhat conflicting information

[openstack-dev] [Heat][Rant] About blank rechecks

Hi all, You've seen me complain about people doing blank rechecks in Gerrit on IRC, and it seems it had little to no effect. So here I am trying to spread the word here. I'll try to stay calm. I'm seeing way too many rechecks on heat patches. It's not epidemic, but it's still enough to make me

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

+1! -- Thomas On Tue, Oct 20, 2015 at 3:38 PM, Sergey Kraynev wrote: > I'd like to propose new candidates for heat core-team: > Rabi Mishra > Peter Razumovsky > > According statistic both candidate made a big effort in Heat as > reviewers and as contributors [1][2]. >

Re: [openstack-dev] [Fuel] py.test vs testrepository

On Wed, Oct 7, 2015 at 12:59 PM, Roman Prykhodchenko wrote: > What I can extract now from this thread is that Fuel should switch to > testr because of the following reasons: > > - Diversity of tools is a bad idea on a project scale > - testrepository and related components are

Re: [openstack-dev] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

We can get stacks by stack list call, but it does not provide info about stack parameters. If we need stack parameters, we have to use stack.get. Yeah that part is right. I believe we consider stack parameters somewhat private to the user, which may be the reason they are not easily

Re: [openstack-dev] [openstack][magnum][heat]problems for synchronizing stack parameters from heat

Hi all, Magnum creates a stack when a bay is created and update the stack parameters when the bay is updated. Magnum has a periodic task to synchronize stack status from heat. And now we want to synchronize stack parameters from heat, too. But heat don't allow admin user to show stack

Re: [openstack-dev] [heat] status of instance_user/admin_user in heat

Looks like this change is what I need, but was the code supposed to not set it to ec2-user when instance_user is unset? I've always had it unset and it's always set it to ec2-user, certainly for Ubuntu images anyway, I've not tested others. It's a common misconception. Unset is different

Re: [openstack-dev] [heat] status of instance_user/admin_user in heat

Heat devs, What is the status of the instance_user config option and the corollary OS::Nova::Server::admin_user field? Our users find it very confusing when Heat creates a VM with a user called ec2-user. While I've told them to explicitly set admin_user, the documentation claims its

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

Hi, Response inline. 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. That's technically not true. If you use a neutron

Re: [openstack-dev] Barbican : Unable to reterieve asymmetric order request for rsa algorithm type

Hi All , Could any one please let me know if Barbican would support asymmetric order retrieval and the request . Please find the curl command and response for creating the order and retrieving the order root@barbican:~# curl -X POST -H 'content-type:application/json' -H 'X-Project-Id:

Re: [openstack-dev] [nova][libvirt] Block migrations and Cinder volumes

Interesting bug. I think I agree with you that there isn't a good solution currently for instances that have a mix of shared and not-shared storage. I'm curious what Daniel meant by saying that marking the disk shareable is not as reliable as we would want. I think this is the bug I

Re: [openstack-dev] [nova] if by archived you mean, wipes out your tables completely, then sure, it works fine

[snip] If we assume that all of our tables are filled up with zeroes for those deleted columns, because that’s the default, this **wipes the whole table clean**. How do the tests pass? Well the tests are in test_db_api-ArchiveTestCase, and actually, they don’t. But they don’t fail every

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

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 Tianhua Remove: Bartosz Górski

Re: [openstack-dev] [Nova] Automatic evacuate

This still doesn't do away with the requirement to reliably detect node failure, and to fence misbehaving nodes. Detecting that a node has failed, and fencing it if unsure, is a prerequisite for any recovery action. So you need Corosync/Pacemaker anyway. Obviously, yes. My post

Re: [openstack-dev] [Heat] Nominating Pavlo Shchelokovskyy for heat-core

I'd like to propose that we add Pavlo Shchelokovskyy to the heat-core team. Pavlo has been a consistently active member of the Heat community - he's a regular participant in IRC and at meetings, has been making plenty of good commits[1] and maintains a very respectable review rate[2] with

Re: [openstack-dev] [Heat] Introducing Re-Heat

Hello All, My name is Mika Ayenson and I have to privilege to intern at Johns Hopkins - Applied Physics Lab. I’m really excited to release the latest proof of concept “Re-Heat” Re-Heat is a JHUAPL developed tool for OpenStack users to help them quickly rebuild their OpenStack

Re: [openstack-dev] [heat] health maintenance in autoscaling groups

The check url is already a part of Neutron LBaaS IIRC. Yep. LBaaS is a work in progress, right? You mean more than OpenStack in general? :) The LBaaS API in Neutron has been working fine since Havana. It's certainly has shortcomings and it seems there is a big refactoring in plan, though.

Re: [openstack-dev] [Ceilometer] [Heat] Ceilometer aware people, please advise us on processing notifications..

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/06/14 09:28, Clint Byrum wrote: Hello! I would like to turn your attention to this specification draft that I've written: https://review.openstack.org/#/c/100012/1/specs/convergence-continuous-observer.rst Angus has suggested

[openstack-dev] Import errors in tests are not reported in python 2.7

Hi all, I don't know if it's a know issue or not, but I noticed on one of my patch (https://review.openstack.org/#/c/99648/) that the 2.7 gate was passing whereas the 2.6 is failing because of import errors. It seems to be a problem related to the difference in the discover module, so

Re: [openstack-dev] Import errors in tests are not reported in python 2.7

On 06/12/2014 10:32 AM, Thomas Herve wrote: Hi all, I don't know if it's a know issue or not, but I noticed on one of my patch (https://review.openstack.org/#/c/99648/) that the 2.7 gate was passing whereas the 2.6 is failing because of import errors. It seems to be a problem related

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

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

[openstack-dev] [Heat] Stack snapshots

Hi all, I started working on the stack snapshot blueprint [1] and wrote a first series of patches [2] to get a feeling of what's possible. I have a couple of related design questions though: * Is a stack snapshot independent of the stack? That's the way I chose for my patches, you start with

Re: [openstack-dev] more oslo liaisons needed

I see that several projects have their Oslo liaisons lined up (https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons). It would be great if we had at least one volunteer from each project before the summit, so we can get a head start on the coordination work. Hi Doug, I'd be happy to handle

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

Hi folks, There are two problems we should address regarding the growth and change to the HOT specification. First our +2/+A process for normal changes doesn't totally make sense for hot_spec.rst. We generally have some informal bar for controversial changes (of which changes to

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

Hi, Hi Qiming Regarding the discussion about the adding of a native 'mappings' section to HOT [1], which has been abandoned, I have some different thoughts for the team to consider. Maybe having that section added is not a bad idea. I do think we need a 'mappings' kind of

[openstack-dev] [Heat] PTL Candidacy

Hello all, I'd like announce my candidacy for Heat PTL. It's been a pleasure to be part of such a great team for about a year now, and that's the main driver for me to want to represent all of you. I trust that as a team we'll continue do a good job delivering nice software, and I hope I

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

What I can say is that I'm not convinced. The only use-case for a DSL would be if you have to upload user-written code, but what you mentioned is a Web interface, where the user doesn't use the DSL, and the cloud provider is the developer. There is no reason in this case to have a secure

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

Hi Thomas, I think we went to the second loop of the discussion about generic language concepts. Murano does not use a new language for the sole purpose of having parameters, constraints and polymorphism. These are generic concepts which are common for different languages, so keeping

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

Hi Stan, Comments inline. Zane, I appreciate your explanations on Heat/HOT. This really makes sense. I didn't mean to say that MuranoPL is better for Heat. Actually HOT is good for Heat's mission. I completely acknowledge it. I've tried to avoid comparison between languages and I'm sorry

Re: [openstack-dev] [heat][neutron] OS::Heat::AutoScalingGroup and OS::Neutron::PoolMember?

Has anybody exercised the case of OS::Heat::AutoScalingGroup scaling a nested stack that includes a OS::Neutron::PoolMember? Should I expect this to work? Hi Mike, Yes I tested it and it works. I'm trying to build an example for heat-templates putting it all together. I'm mostly struggling

Re: [openstack-dev] [Heat] lazy translation is breaking Heat

This change was recently merged: https://review.openstack.org/#/c/69133/ Unfortunately it didn't enable lazy translations for the unit tests, so it didn't catch the many places in Heat that won't work when lazy translations are enabled. Notably there are a lot of cases where the code adds

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

+1! -- Thomas - Mail original - On Mon, Feb 10, 2014 at 11:38:40AM +1300, Steve Baker wrote: I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has

  1   2   >