Re: [openstack-dev] [tripleo] Proposing Florian Fuchs for tripleo-validations core

On 04/06/2017 11:53 AM, Martin André wrote: Hellooo, I'd like to propose we extend Florian Fuchs +2 powers to the tripleo-validations project. Florian is already core on tripleo-ui (well, tripleo technically so this means there is no changes to make to gerrit groups). Florian took over many of

Re: [openstack-dev] [validations][ui][tripleo] resetting state of validations

On 01/18/2017 10:14 PM, Dan Trainor wrote: Hi - Is there a way to reset the state of all the validations that have previously ran, back to the original state they were prior to running? Using the UI, for example, some validations (by design) run as soon as you log in. Others run after

Re: [openstack-dev] [TripleO] Newton release this week

On 11/06/2016 05:24 PM, James Slagle wrote: TripleO plans to do an updated Newton release this upcoming week to pick up the critical fixes that have been backported to stable/newton since the original Newton release. My plan as of now is to request the release on Wednesday November 9th. I'll

[openstack-dev] [tripleo] How To Review tripleo-validations

pad[4] with the `validations` tag. If you have any questions or suggestions, don't hesitate to reply here or talk to me (shadower) on IRC. Cheers, Tomas Sedovic [1]: https://bugs.launchpad.net/tripleo/+bug/1620617 [2]: http://docs.ansible.com/ansible/playbooks_variables.html [3

[openstack-dev] [TripleO] Status of the validations and priority patches

in tripleo-validations is a fair game (most patches are individual validations): https://review.openstack.org/#/q/project:openstack/tripleo-validations+status:open Cheers, Tomas Sedovic __ OpenStack Development Mailing

Re: [openstack-dev] [E] [TripleO] scripts to do post deployment analysis of an overcloud

On 08/08/2016 11:05 AM, Hugh Brock wrote: On Wed, Aug 3, 2016 at 4:49 PM, Joe Talerico wrote: On Wed, Jul 27, 2016 at 2:04 AM, Hugh Brock wrote: On Jul 26, 2016 8:08 PM, "Gordon, Kent" wrote: -Original

Re: [openstack-dev] [TripleO] Consolidating TripleO validations with Browbeat validations

On 06/20/2016 06:37 PM, Joe Talerico wrote: Hello - It would seem there is a little bit of overlap with TripleO validations ( clapper validations ) and Browbeat *Checks*. I would like to see these two come together, and I wanted to get some feedback on this. For reference here are the Browbeat

Re: [openstack-dev] [TripleO] Consolidating TripleO validations with Browbeat validations

On 06/20/2016 08:58 PM, Assaf Muller wrote: On Mon, Jun 20, 2016 at 12:43 PM, Joe Talerico wrote: On Mon, Jun 20, 2016 at 12:41 PM, Ihar Hrachyshka wrote: On 20 Jun 2016, at 18:37, Joe Talerico wrote: Hello - It would seem

Re: [openstack-dev] [tripleo] composable roles team

On 05/02/2016 07:47 PM, Brent Eagles wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/01/2016 08:01 PM, Emilien Macchi wrote: If a feature can't land without disruption, then why not using a special branch to be merged once the feature is complete ? The problem is that during

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

On 12/23/2015 01:01 PM, Steven Hardy wrote: On Tue, Dec 22, 2015 at 03:36:02PM +, Dougal Matthews wrote: Hi all, This topic came up in the 2015-12-15 meeting[1], and again briefly today. After working with the code that came out of the deployment library spec[2] I had

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

, validation and (optionally) plan. That could be done in Swift or filesystem/git as well, but we'd have to write code to handle indexing and querying and at that point using a DB seems easier. Tomas Sedovic Thanks, Dougal [1]: http://eavesdrop.openstack.org/meetings/tripleo/2015/tripleo.2015-12-15

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

On 01/14/2015 01:47 AM, Ton Ngo wrote: Hi Tomas, I think your patch is a great start so we can prototype quickly; I am trying it out right now. We can break up the implementation into several parts that can be updated more or less independently based on the feedback. Ton, snip Hey

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

On 01/12/2015 07:05 PM, Steven Hardy wrote: On Mon, Jan 12, 2015 at 04:29:15PM +0100, Tomas Sedovic wrote: Hey folks, I did a quick proof of concept for a part of the Stack Breakpoint spec[1] and I put the does this resource have a breakpoint flag into the metadata of the resource: https

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

On 01/13/2015 01:15 AM, Ton Ngo wrote: I was also thinking of using the environment to hold the breakpoint, similarly to parameters. The CLI and API would process it just like parameters. As for the state of a stack hitting the breakpoint, leveraging the FAILED state seems to be

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

On 01/12/2015 10:36 PM, Zane Bitter wrote: 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

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

Hey folks, I did a quick proof of concept for a part of the Stack Breakpoint spec[1] and I put the does this resource have a breakpoint flag into the metadata of the resource: https://review.openstack.org/#/c/146123/ I'm not sure where this info really belongs, though. It does sound like

Re: [openstack-dev] [tripleo] Managing no-mergepy template duplication

On 12/03/2014 11:11 AM, Steven Hardy wrote: Hi all, Lately I've been spending more time looking at tripleo and doing some reviews. I'm particularly interested in helping the no-mergepy and subsequent puppet-software-config implementations mature (as well as improving overcloud updates via

[openstack-dev] [TripleO] Strategy for testing and merging the merge.py-free templates

Hi everyone, As outlined in the Remove merge.py[1] spec, Peter Belanyi and I have built the templates for controller, nova compute, swift and cinder nodes that can be deploying directly to Heat (i.e. no merge.py pass is necessary). The patches: https://review.openstack.org/#/c/123100/

Re: [openstack-dev] [TripleO] Strategy for testing and merging the merge.py-free templates

On 10/14/2014 12:43 PM, Steven Hardy wrote: On Tue, Oct 14, 2014 at 10:55:30AM +0200, Tomas Sedovic wrote: Hi everyone, As outlined in the Remove merge.py[1] spec, Peter Belanyi and I have built the templates for controller, nova compute, swift and cinder nodes that can be deploying directly

Re: [openstack-dev] [Heat] stack-update with existing parameters

On 24/09/14 13:50, Dimitri Mazmanov wrote: TL;DR Is there any reason why stack-update doesn¹t reuse the existing parameters when I extend my stack definition with a resource that uses them? Hey Dimitri, There is an open bug for this feature: https://bugs.launchpad.net/heat/+bug/1224828 and

Re: [openstack-dev] [TripleO] Propose adding StevenK to core reviewers

On 09/09/14 20:32, Gregory Haynes wrote: Hello everyone! I have been working on a meta-review of StevenK's reviews and I would like to propose him as a new member of our core team. As I'm sure many have noticed, he has been above our stats requirements for several months now. More

[openstack-dev] [tripleo] Meeting time update

As you all (hopefully) know, our meetings alternate between Tuesdays 19:00 UTC and Wednesdays 7:00 UTC. Because of the whining^W weekly-expressed preferences[1] of the Europe-based folks, the latter meetings are going to be moved by +1 hour. So the new meeting times are: * Tuesdays at 19:00 UTC

Re: [openstack-dev] [TripleO] Change of meeting time

On 20/08/14 05:15, Derek Higgins wrote: On 24/05/14 01:21, James Polley wrote: Following a lengthy discussion under the subject Alternating meeting tmie for more TZ friendliness, the TripleO meeting now alternates between Tuesday 1900UTC (the former time) and Wednesday 0700UTC, for better

Re: [openstack-dev] [Heat] Passing a list of ResourceGroup's attributes back to its members

On 12/08/14 01:06, Steve Baker wrote: On 09/08/14 11:15, Zane Bitter wrote: On 08/08/14 11:07, Tomas Sedovic wrote: On 08/08/14 00:53, Zane Bitter wrote: On 07/08/14 13:22, Tomas Sedovic wrote: Hi all, I have a ResourceGroup which wraps a custom resource defined in another template

[openstack-dev] [Heat] Passing a list of ResourceGroup's attributes back to its members

Hi all, I have a ResourceGroup which wraps a custom resource defined in another template: servers: type: OS::Heat::ResourceGroup properties: count: 10 resource_def: type: my_custom_server properties: prop_1: ... prop_2:

Re: [openstack-dev] [TripleO] Strategy for merging Heat HOT port

On 04/08/14 00:50, Steve Baker wrote: On 01/08/14 12:19, Steve Baker wrote: The changes to port tripleo-heat-templates to HOT have been rebased to the current state and are ready to review. They are the next steps in blueprint tripleo-juno-remove-mergepy. However there is coordination needed

Re: [openstack-dev] [TripleO] Strategy for merging Heat HOT port

On 01/08/14 02:19, Steve Baker wrote: The changes to port tripleo-heat-templates to HOT have been rebased to the current state and are ready to review. They are the next steps in blueprint tripleo-juno-remove-mergepy. However there is coordination needed to merge since every existing

Re: [openstack-dev] [Heat] [TripleO] Extended get_attr support for ResourceGroup

On 15/07/14 20:01, Zane Bitter wrote: On 14/07/14 12:21, Tomas Sedovic wrote: On 12/07/14 06:41, Zane Bitter wrote: On 11/07/14 09:37, Tomas Sedovic wrote: [snip] Alternatively, we could extend the ResourceGroup's get_attr behaviour: {get_attr: [controller_group, resource.0

Re: [openstack-dev] [Heat] [TripleO] Extended get_attr support for ResourceGroup

On 12/07/14 06:41, Zane Bitter wrote: On 11/07/14 09:37, Tomas Sedovic wrote: Hi all, This is a follow-up to Clint Byrum's suggestion to add the `Map` intrinsic function[0], Zane Bitter's response[1] and Randall Burt's addendum[2]. Sorry for bringing it up again, but I'd love to reach

[openstack-dev] [Heat] [TripleO] Extended get_attr support for ResourceGroup

Hi all, This is a follow-up to Clint Byrum's suggestion to add the `Map` intrinsic function[0], Zane Bitter's response[1] and Randall Burt's addendum[2]. Sorry for bringing it up again, but I'd love to reach consensus on this. The summary of the previous conversation: 1. TripleO is using some

Re: [openstack-dev] [TripleO] Proposal to add Jon Paul Sullivan and Alexis Lee to core review team

On 09/07/14 17:52, Clint Byrum wrote: Hello! I've been looking at the statistics, and doing a bit of review of the reviewers, and I think we have an opportunity to expand the core reviewer team in TripleO. We absolutely need the help, and I think these two individuals are well positioned to

Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects

On 16/06/14 18:51, Clint Byrum wrote: Excerpts from Tomas Sedovic's message of 2014-06-16 09:19:40 -0700: All, After having proposed some changes[1][2] to tripleo-heat-templates[3], reviewers suggested adding a deprecation period for the merge.py script. While TripleO is an official

[openstack-dev] [TripleO] Backwards compatibility policy for our projects

All, After having proposed some changes[1][2] to tripleo-heat-templates[3], reviewers suggested adding a deprecation period for the merge.py script. While TripleO is an official OpenStack program, none of the projects under its umbrella (including tripleo-heat-templates) have gone through

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

On 10/06/14 10:25, Clint Byrum wrote: Excerpts from Jaromir Coufal's message of 2014-06-08 16:44:58 -0700: Hi, it looks that there is no more activity on the survey for mid-cycle dates so I went forward to evaluate it. I created a table view into the etherpad [0] and results are following:

Re: [openstack-dev] [tripleO] Should #tuskar business be conducted in the #tripleo channel?

On 30/05/14 02:08, James Slagle wrote: On Thu, May 29, 2014 at 12:25 PM, Anita Kuno ante...@anteaya.info wrote: As I was reviewing this patch today: https://review.openstack.org/#/c/96160/ It occurred to me that the tuskar project is part of the tripleo program:

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

On 28/05/14 10:05, Julien Danjou wrote: On Tue, May 27 2014, Gauvain Pocentek wrote: So my feeling is that we should work on the tools to convert RST (or whatever format, but RST seems to be the norm for openstack projects) to docbook, and generate our online documentation from there. There

Re: [openstack-dev] [TripleO] reviewer update march [additional cores]

On 08/04/14 01:50, Robert Collins wrote: tl;dr: 3 more core members to propose: bnemec greghaynes jdon -1, there's a typo in jdob's nick ;-) In all seriousness, I support all of them being added to core. On 4 April 2014 08:55, Chris Jones c...@tenshu.net wrote: Hi +1 for your

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

On 06/04/14 23:27, Steve Baker wrote: On 05/04/14 04:47, Tomas Sedovic wrote: Hi All, snip The maintenance burden of merge.py can be gradually reduced if features in it can be deleted when they are no longer needed. At some point in this process merge.py will need to accept HOT templates

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

Hi All, I was wondering if the time has come to document what exactly are we doing with tripleo-heat-templates and merge.py[1], figure out what needs to happen to move away and raise the necessary blueprints on Heat and TripleO side. (merge.py is a script we use to build the final TripleO Heat

Re: [openstack-dev] [TripleO] reviewer update march

On 03/04/14 13:02, Robert Collins wrote: Getting back in the swing of things... Hi, like most OpenStack projects we need to keep the core team up to date: folk who are not regularly reviewing will lose context over time, and new folk who have been reviewing regularly should be trusted

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

On 20/02/14 16:24, Imre Farkas wrote: On 02/20/2014 03:57 PM, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

On 20/02/14 10:12, Radomir Dopieralski wrote: On 19/02/14 18:29, Dougal Matthews wrote: The question for me, is what passwords will we have and when do we need them? Are any of the passwords required long term. We will need whatever the Heat template needs to generate all the configuration

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

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

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

On 20/02/14 14:10, Jiří Stránský wrote: On 20.2.2014 12:18, Radomir Dopieralski wrote: On 20/02/14 12:02, Radomir Dopieralski wrote: Anybody who gets access to Tuskar-API gets the passwords, whether we encrypt them or not. Anybody who doesn't have access to Tuskar-API doesn't get the

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me. How are you going to redeploy without them? What do you mean by redeploy? 1

Re: [openstack-dev] [TripleO][Tuskar] Dealing with passwords in Tuskar-API

On 20/02/14 16:02, Radomir Dopieralski wrote: On 20/02/14 15:57, Tomas Sedovic wrote: On 20/02/14 15:41, Radomir Dopieralski wrote: On 20/02/14 15:00, Tomas Sedovic wrote: Are we even sure we need to store the passwords in the first place? All this encryption talk seems very premature to me

Re: [openstack-dev] [TripleO] [Tuskar] [UX] Infrastructure Management UI - Icehouse scoped wireframes

On 05/02/14 03:58, Jaromir Coufal wrote: Hi to everybody, based on the feedback from last week [0] I incorporated changes in the wireframes so that we keep them up to date with latest decisions: http://people.redhat.com/~jcoufal/openstack/tripleo/2014-02-05_tripleo-ui-icehouse.pdf Changes: *

Re: [openstack-dev] [TripleO] [Tuskar] [UX] Infrastructure Management UI - Icehouse scoped wireframes

snip 1. Are we doing node tags (page 4) for the first iteration? Where are they going to live? Yes, it's very easy to do, already part of Ironic. Cool! 2. There are multiple node profiles per role on pages 11, 12, 17. Is that just an oversight or do you intend on keeping those in? I

Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

My apologies for firing this off and then hiding under the FOSDEM rock. In light of the points raised by Devananda and Robert, I no longer think fiddling with the scheduler is the way to go. Note this was never intended to break/confuse all TripleO users -- I considered it a cleaner

[openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial: 1. Build the UI and everything underneath to work with homogenous hardware

Re: [openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous hardware support

On 30/01/14 15:53, Matt Wagner wrote: On 1/30/14, 5:26 AM, Tomas Sedovic wrote: Hi all, I've seen some confusion regarding the homogenous hardware support as the first step for the tripleo UI. I think it's time to make sure we're all on the same page. Here's what I think is not controversial

Re: [openstack-dev] os-*-config in tripleo repositories

On 09/01/14 14:13, Derek Higgins wrote: It looks like we have some duplication and inconsistencies on the 3 os-*-config elements in the tripleo repositories os-apply-config (duplication) : We have two elements that install this diskimage-builder/elements/config-applier/

Re: [openstack-dev] [TRIPLEO] tripleo-core update october

Just an fyi, tomas-8c8 on the reviewers list is yours truly. That's the name I got assigned when I registered to Gerrit and apparently, it can't be changed. Thanks for the heads-up, will be doing more reviews. T. On 07/10/13 21:03, Robert Collins wrote: Hi, like most OpenStack projects we

Re: [openstack-dev] [TripleO] Tuskar and releases

On 02/10/13 07:46, Sergey Lukjanov wrote: In Savanna we're supplying plugin for OpenStack Dashboard - https://github.com/stackforge/savanna-dashboard It doesn't contains any copy-paste and dependencies for Django/Horizon and currently compatible with Grizzly and Havana OpenStack Dashboard, it

Re: [openstack-dev] [TripleO] Generalising racks :- modelling a datacentre

On 09/25/2013 05:15 AM, Robert Collins wrote: One of the major things Tuskar does is model a datacenter - which is very useful for error correlation, capacity planning and scheduling. Long term I'd like this to be held somewhere where it is accessible for schedulers and ceilometer etc. E.g.

[openstack-dev] [Tuskar] The last IRC meeting

I planned to cancel today's meeting, but I was reminded that we ought to finish the naming votes from the last week and it would be good to talk a bit more about the Tuskar coming under TripleO. The time: Tuesday, 24th September, 2013 at 19:00 UTC The agenda: * Discuss merger with TripleO

[openstack-dev] [Tuskar] [TripleO] The vision and looking ahead

Hi everyone, Some of us Tuskar developers have had the chance to meet the TripleO developers face to face and discuss the visions and goals of our projects. Tuskar's ultimate goal is to have to a full OpenStack management solution: letting the cloud operators try OpenStack, install it, keep

Re: [openstack-dev] [Tuskar] [TripleO] The vision and looking ahead

On 09/19/2013 04:00 PM, Adam Young wrote: On 09/19/2013 05:19 AM, Imre Farkas wrote: On 09/19/2013 10:08 AM, Tomas Sedovic wrote: Hi everyone, Some of us Tuskar developers have had the chance to meet the TripleO developers face to face and discuss the visions and goals of our projects

Re: [openstack-dev] [Tuskar] Tuskar Names Clarification Unification

On 09/17/2013 04:17 AM, Jaromir Coufal wrote: On 2013/16/09 15:11, Tomas Sedovic wrote: On 09/16/2013 05:50 PM, Jaromir Coufal wrote: Hi, after few days of gathering information, it looks that no more new ideas appear there, so let's take the last round of voting for names which you prefer

Re: [openstack-dev] [Tuskar] Tuskar Names Clarification Unification

On 09/17/2013 04:53 AM, Mike Spreitzer wrote: From: Jaromir Coufal jcou...@redhat.com To: openstack-dev@lists.openstack.org, Date: 09/16/2013 11:51 AM Subject: Re: [openstack-dev] [Tuskar] Tuskar Names Clarification Unification Hi, after few days of gathering information, it

Re: [openstack-dev] [Tuskar] Tuskar Names Clarification Unification

On 09/16/2013 05:50 PM, Jaromir Coufal wrote: Hi, after few days of gathering information, it looks that no more new ideas appear there, so let's take the last round of voting for names which you prefer. It's important for us to get on the same page.

Re: [openstack-dev] [Tuskar] Meeting agenda for Tue 10th September at 19:00 UTC

The meeting happened. You can read the notes: http://eavesdrop.openstack.org/meetings/tuskar/2013/tuskar.2013-09-10-19.00.html or the full IRC log if you're so inclined: http://eavesdrop.openstack.org/meetings/tuskar/2013/tuskar.2013-09-10-19.00.log.html On 09/09/2013 05:34 PM, Tomas Sedovic

[openstack-dev] [Tuskar] Meeting agenda for Tue 10th September at 19:00 UTC

The Tuskar team holds a meeting in #openstack-meeting-alt, see https://wiki.openstack.org/wiki/Meetings/Tuskar The next meeting is on Tuesday 10th September at 19:00 UTC. Current topics for discussion: * Documentation * Simplify development setup * Tests * Releases Milestones * Open

[openstack-dev] [Tuskar] Weekly IRC meetings

://wiki.openstack.org/wiki/Meetings#Tuskar_meeting I'll send out the agenda for the first meeting later (at most 24 hours before the meeting starts). Three cheers for timezones! -- Tomas Sedovic Tuskar PTL ___ OpenStack-dev mailing list OpenStack-dev

Re: [openstack-dev] Tuskar PTL candidacy

elected after every release from a pool of self-nominees. https://wiki.openstack.org/wiki/PTLguide -Original Message- From: Tomas Sedovic [mailto:tsedo...@redhat.com] Sent: Thursday, August 22, 2013 8:55 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] Tuskar PTL candidacy

[openstack-dev] Announcing Tuskar project and PTL nominations

-nomination period will end on Monday, 26th August 2013, 23:59 UTC. -- Tomas Sedovic ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Announcing Tuskar project and PTL nominations

On 08/21/2013 02:32 PM, Tomas Sedovic wrote: Hi everyone, We would like to announce Tuskar, an OpenStack management service. Our goal is to provide an API and UI to install and manage OpenStack at larger scale: where you deal with racks, different hardware classes for different purposes

[openstack-dev] [Horizon[ Update on the realtime-communication blueprint

All, Presenting a new version of the proof of concept for the realtime-communication Horizon blueprint[0]. Here's the code: https://review.openstack.org/#/q/status:open+project:openstack/horizon+branch:master+topic:bp/realtime-communication,n,z Following the previous discussion, this