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
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 differen
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 use
on bugs are stored in the tripleo launchpad[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.an
thing 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 Ma
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 Message-
From: Gonéri Le Bouder [mailto:gon...@lebouder.net]
Sent: Tuesday
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 c
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 there is a little bit of overlap with TripleO
validations ( clappe
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 o
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 so
them per stage, 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/201
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,
Hey ever
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 suffic
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 resour
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 metad
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
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 heat).
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 deployin
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/
http
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
an
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 i
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
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
>>
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,
>>>>>
>>&
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:
>>
>> servers:
>>type: OS::Heat::ResourceGrou
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:
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 coordinat
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
> t
On 15/07/14 20:43, Tomas Sedovic wrote:
> 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]
>>>
>>>>
>
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
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
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 fu
On 10/07/14 15:05, Alexis Lee wrote:
> Tomas Sedovic said on Thu, Jul 10, 2014 at 02:26:06PM +0200:
>> On 09/07/14 17:52, Clint Byrum wrote:
>> +1 for both. However, some of the reviews show what I think is a
>> worrying trend in TripleO core. Specifically, nitpicking and te
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 position
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 offi
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
incubat
On 12/06/14 16:02, Macdonald-Wallace, Matthew wrote:
> FWIW, I’ve tried to make a useful dashboard for this using Sean Dague’s
> gerrit-dash-creator [0].
>
>
>
> Short URL is http://bit.ly/1l4DLFS long url is:
>
>
>
> https://review.openstack.org/#/dashboard/?foreach=%28project%3Aopenstack%
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 ar
On 30/05/14 02:08, James Slagle wrote:
> On Thu, May 29, 2014 at 12:25 PM, Anita Kuno 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:
>> http://git.openstack.org/cgit/openst
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
>> t
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 wrote:
>> Hi
>>
>> +1 for your proposed
On 06/04/14 23:27, Steve Baker wrote:
> On 05/04/14 04:47, Tomas Sedovic wrote:
>> Hi All,
>>
>>
> 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 me
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 te
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 trus
On 25/03/14 21:17, Robert Collins wrote:
> TripleO has just seen an influx of new contributors. \o/. Flip side -
> we're now slipping on reviews /o\.
>
> In the meeting today we had basically two answers: more cores, and
> more work by cores.
>
> We're slipping by 2 reviews a day, which given 16
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? A
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? A
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?
On 20/02/14 14:47, Radomir Dopieralski wrote:
> On 20/02/14 14:10, Jiří Stránský wrote:
>> On 20.2.2014 12:18, Radomir Dopieralski wrote:
>
>>> Thinking about it some more, all the uses of the passwords come as a
>>> result of an action initiated by the user either by tuskar-ui, or by
>>> the tusk
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 t
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 a
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
> configu
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 though
the
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:
*
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 equivalen
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
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 in
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/
tripleo-i
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
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, i
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. netw
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 in
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
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 i
On 09/17/2013 04:53 AM, Mike Spreitzer wrote:
> From: Jaromir Coufal
> 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 looks that n
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
p
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.
https://etherpad.openstack.org/tuskar-naming
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 Se
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 discussi
https://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
Ope
On 08/22/2013 06:23 PM, Clint Byrum wrote:
Excerpts from Martyn Taylor's message of 2013-08-22 04:23:55 -0700:
Hi Sylvain,
We are currently working on design docs. We'll be adding some
architecture diagrams and description to our documentation soon.
To answer your question re: provisioning an
They're 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] Tuska
push Tuskar towards clear
documentation and friendliness to newcomers.
--
Tomas Sedovic
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
.@lists.launchpad.net with subject "Tuskar PTL
candidacy".
The self-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
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 iteratio
76 matches
Mail list logo