On 15.12.2015 19:12, Emilien Macchi wrote:
On 12/15/2015 12:23 PM, Jiří Stránský wrote:
On 15.12.2015 17:46, Emilien Macchi wrote:
For information, Puppet OpenStack CI is consistent for unit & functional
tests, we use a single (versionned) Puppetfile:
https://github.com/openstack/pu
On 15.12.2015 17:46, Emilien Macchi wrote:
For information, Puppet OpenStack CI is consistent for unit & functional
tests, we use a single (versionned) Puppetfile:
https://github.com/openstack/puppet-openstack-integration/blob/master/Puppetfile
TripleO folks might want to have a look at this to
My personal preference is to say:
1. Any templates which are included in the default environment (e.g
overcloud-resource-registry-puppet.yaml), must expose their parameters
via overcloud-without-mergepy.yaml
2. Any templates which are included in the default environment, but via a
"noop"
On 26.11.2015 14:12, Jiří Stránský wrote:
My personal preference is to say:
1. Any templates which are included in the default environment (e.g
overcloud-resource-registry-puppet.yaml), must expose their parameters
via overcloud-without-mergepy.yaml
2. Any templates which are included
On 8.9.2015 10:40, Steven Hardy wrote:
Hi all,
So, lately we're seeing an increasing number of patches adding integration
for various third-party plugins, such as different neutron and cinder
backends.
This is great to see, but it also poses the question of how we organize the
user-visible
On 8.9.2015 13:47, Jiří Stránský wrote:
Apart from "cinder" and "neutron-ml2" directories, we could also have a
"combined" (or sth similar) directory for env files which combine
multiple other env files. The use case which i see is for extra
pre-deployment config
Hi all,
after an epic battle with bugs this week, we have a passing CI job for HA.
Looking at the jobs which ran during last night, the success rate is
decent (14 all-green runs vs. just 1 run where HA job was the sole CI
failure).
I'm a bit reluctant still to say let's make it voting right
Hi Dan,
On 7.5.2015 04:32, Dan Prince wrote:
Looking over some of the Puppet pacemaker stuff today. I appreciate all
the hard work going into this effort but I'm not quite happy about all
of the conditionals we are adding to our puppet overcloud_controller.pp
manifest. Specifically it seems
On 5.5.2015 13:57, James Slagle wrote:
Hi, I'd like to propose adding Giulio Fidente and Steve Hardy to TripleO Core.
Giulio has been an active member of our community for a while. He
worked on the HA implementation in the elements and recently has been
making a lot of valuable contributions
On 9.9.2014 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.
+1
As I'm sure many have noticed, he has been above our stats requirements
for several months now. More
On 9.7.2014 17:52, Clint Byrum wrote:
So, I propose that we add jonpaul-sullivan and lxsli to the TripleO core
reviewer team.
+1
Jirka
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
On 30.5.2014 11:06, Tomas Sedovic wrote:
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
On 30.4.2014 09:02, Steve Kowalik wrote:
Hi,
I'm looking at moving init-keystone from tripleo-incubator to
os-cloud-config, and I've drafted a spec at
https://etherpad.openstack.org/p/tripleo-init-keystone-os-cloud-config .
Feedback welcome.
Cheers,
Hi Steve,
that looks
On 3.4.2014 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
with
On 27.3.2014 18:21, Dougal Matthews wrote:
On 27/03/14 15:56, Jaromir Coufal wrote:
Hi OpenStackers,
User interface which is managing the OpenStack Infrastructure is
currently named Tuskar-UI because of historical reasons. Tuskar itself
is a small service, which is giving logic into generating
(Removing [Heat] from the subject.)
So here are the steps i think are necessary to get the PKI setup done
and safely passed through Jenkins. If anyone thinks something is
redundant or missing, please shout:
1. Patch to os-cloud-config:
* Generation of keys and certs for cases user doesn't
On 16.3.2014 21:20, Steve Baker wrote:
On 15/03/14 02:33, Jiří Stránský wrote:
On 12.3.2014 17:03, Jiří Stránský wrote:
Thanks for all the replies everyone :)
I'm leaning towards going the way Robert suggested on the review [1] -
upload pre-created signing cert, signing key and CA cert
On 12.3.2014 17:03, Jiří Stránský wrote:
Thanks for all the replies everyone :)
I'm leaning towards going the way Robert suggested on the review [1] -
upload pre-created signing cert, signing key and CA cert to controller
nodes using Heat. This seems like a much cleaner approach
On 14.3.2014 14:42, Steven Dake wrote:
On 03/14/2014 06:33 AM, Jiří Stránský wrote:
On 12.3.2014 17:03, Jiří Stránský wrote:
Thanks for all the replies everyone :)
I'm leaning towards going the way Robert suggested on the review [1] -
upload pre-created signing cert, signing key and CA cert
-10 17:10 GMT+04:00 Jiří Stránský ji...@redhat.com:
On 7.3.2014 14:50, Imre Farkas wrote:
On 03/07/2014 10:30 AM, Jiří Stránský wrote:
Hi,
there's one step in cloud initialization that is performed over SSH --
calling keystone-manage pki_setup. Here's the relevant code in
keystone-init [1
On 7.3.2014 14:50, Imre Farkas wrote:
On 03/07/2014 10:30 AM, Jiří Stránský wrote:
Hi,
there's one step in cloud initialization that is performed over SSH --
calling keystone-manage pki_setup. Here's the relevant code in
keystone-init [1], here's a review for moving the functionality to
os
Hi,
there's one step in cloud initialization that is performed over SSH --
calling keystone-manage pki_setup. Here's the relevant code in
keystone-init [1], here's a review for moving the functionality to
os-cloud-config [2].
The consequence of this is that Tuskar will need passwordless ssh
On 26.2.2014 20:43, Jay Dobies wrote:
I'd say it's still an open question whether we'll want to give better UX
than that ^^ and at what cost (this is very much tied to the benefits
and drawbacks of various solutions we discussed in December [1]). All in
all it's not as bad as i expected it to be
On 27.2.2014 10:16, Dougal Matthews wrote:
On 26/02/14 13:34, Jiří Stránský wrote:
get Tuskar UI a bit closer back to the fact
that Undercloud is OpenStack too, and keep the name Flavors instead of
changing it to Node Profiles. I wonder if that would be unwelcome to
the Tuskar UI UX, though
On 26.2.2014 21:34, Dean Troyer wrote:
On Wed, Feb 26, 2014 at 1:43 PM, Jay Dobies jason.dob...@redhat.com wrote:
I like the notion of OpenStackClient. I'll talk ideals for a second. If we
had a standard framework and each project provided a command abstraction
that plugged in, we could pick
Hello,
i went through the CLI way of deploying overcloud, so if you're
interested what's the workflow, here it is:
https://gist.github.com/jistr/9228638
I'd say it's still an open question whether we'll want to give better UX
than that ^^ and at what cost (this is very much tied to the
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 passwords, whether we encrypt
them or not.
Yeah,
On 01/30/2014 11:26 AM, Tomas Sedovic wrote:
1.1 Treat similar hardware configuration as equal
The way I understand it is this: we use a scheduler filter that wouldn't
do a strict match on the hardware in Ironic. E.g. if our baremetal
flavour said 16GB ram and 1TB disk, it would also match a
On 15.1.2014 14:07, James Slagle wrote:
I'll start by laying out how I see editing or updating nodes working
in TripleO without Tuskar:
To do my initial deployment:
1. I build a set of images for my deployment for different roles. The
images are different based on their role, and only contain
On 13.1.2014 11:43, Jaromir Coufal wrote:
On 2014/10/01 21:17, Jay Dobies wrote:
Another question:
- A Role (sounds like we're moving away from that so I'll call it
Resource Category) can have multiple Node Profiles defined (assuming I'm
interpretting the + and the tabs in the Create a Role
On 21.12.2013 06:10, Jay Pipes wrote:
On 12/20/2013 11:34 AM, Clint Byrum wrote:
Excerpts from Radomir Dopieralski's message of 2013-12-20 01:13:20 -0800:
On 20/12/13 00:17, Jay Pipes wrote:
On 12/19/2013 04:55 AM, Radomir Dopieralski wrote:
On 14/12/13 16:51, Jay Pipes wrote:
[snip]
On 12.12.2013 17:10, Mark McLoughlin wrote:
On Wed, 2013-12-11 at 13:33 +0100, Jiří Stránský wrote:
Hi all,
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With the planned architecture
On 12.12.2013 11:49, Radomir Dopieralski wrote:
On 11/12/13 13:33, Jiří Stránský wrote:
[snip]
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With the planned architecture changes (making
On 12.12.2013 14:26, Jiří Stránský wrote:
On 12.12.2013 11:49, Radomir Dopieralski wrote:
On 11/12/13 13:33, Jiří Stránský wrote:
[snip]
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI
Hi all,
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With the planned architecture changes (making tuskar-api thinner
and getting rid of proxying to other services), there's not an obvious
A few clarifications added, next time i'll need to triple-read after
myself :)
On 11.12.2013 13:33, Jiří Stránský wrote:
Hi all,
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI
proxying from tuskar API to
other APIs is looked down upon. Jiri and I had been talking yesterday
and he mentioned it to me when I started to ask these same sorts of
questions.
On 12/11/2013 07:33 AM, Jiří Stránský wrote:
Hi all,
TL;DR: I believe that As an infrastructure administrator, Anna wants
On 4.12.2013 08:12, Robert Collins wrote:
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
with -core responsibilities.
In this
Hi all,
just a few thoughts (subjective opinions) regarding the whole debate:
* I think that having a manually picking images for machines approach
would make TripleO more usable in the beginning. I think it will take a
good deal of time to get our smart solution working with the admin
On 30.10.2013 10:06, Robert Collins wrote:
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
with -core responsibilities.
In this months
On 31.10.2013 06:09, Roman Podoliaka wrote:
Hi all,
0.MAJOR.MINOR versioning totally makes sense to me until we get to 1.0.0.
Just a couple of examples of releases we are doing this week:
1) tripleo-image-elements is bumped from 0.0.8 to 0.1.0 (we introduced a
kind of incompatible change by
Clint and Monty,
thank you for such good responses. I am new in TripleO team indeed and I
was mostly concerned by the line in the sand. Your responses shed some
more light on the issue for me and i hope we'll be heading the right way :)
Thanks
Jiri
On 19.9.2013 10:08, 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.
Tuskar's ultimate goal is to have to a full OpenStack management
solution: letting the cloud
101 - 143 of 143 matches
Mail list logo
