While I would be interested to know how many people actually do use
COPY_ONCE, I think if I was in charge of a production deployment I would
use COPY_ONCE.
On 01/12/16 02:27, Jeffrey Zhang wrote:
Kolla has a config_strategy option during deployment. it supports
COPY_ONCE and
COPY_ALWAYS. whic
Right now I try to attack the bug list whenever I get time, admittedly
it's not a regular activity though. I actually wasn't aware kolla and
kolla-ansible had separate bug trackers, so far I've just been following
the kolla one so this is good to know.
One issue I have is the fact that a large
This actually seems really useful, thanks Christian.
On 15/12/16 11:35, Christian Berendt wrote:
Hello everybody.
Based on the dashboard which is used for the Nova project I have created one
for Kolla. The dashboard gets updated hourly.
http://kolla.betacloud.io/bugs-dashboard.html
Christian
Hi Kris,
Thanks for the feedback, I think everyone involved in kolla-ansible
should take the time to read through it, as it definitely highlights
some areas that we need to improve.
There's a lot of questions here, so I haven't gone into too much detail
on any specific one; my hope is that I
Ah, I think you may be misreading what Sean is saying there. What he
means is kolla-ansible provides the bare minimum config templates to
make the service work. To template every possible config option would be
too much of a maintenance burden on the project.
Of course, users will want to cust
Hi Kolla,
Does anyone know the current status of docs refactor? I believe there
was someone looking into it (apologies can't remember their name).
If not, I'd like to propose a vote for some immediate changes that can
improve things.
Regards,
-Paul
_
vercomplicating it, might be worth
reaching out to people from Ansible for more info.
On 25/01/17 00:01, Mooney, Sean K wrote:
-Original Message-
From: Paul Bourke [mailto:paul.bou...@oracle.com]
Sent: Tuesday, January 24, 2017 11:49 AM
To: OpenStack Development Mailing List (not for
Hi Hiroki,
To my knowledge it's not possible to change the target repository for an
open patch. What we've done so far is to abandon the in progress one,
cherry-pick to the correct repository and start a new review (adding the
original author as a co-author of course).
Hope that helps,
-Paul
itted against the kolla repository.
Please have a look if you have time.
Thanks,
-Paul
On 24/01/17 12:06, Paul Bourke wrote:
Hi Kolla,
Does anyone know the current status of docs refactor? I believe there
was someone looking into it (apologies can't remember their name).
If not, I'd
Hi Christian,
Thanks for the summary, useful for those of us not at the PTG.
I'm a little confused on the final outcome, it sounds like most of what
you've written is currently the case.
Besides a more user friendly deploy guide appearing under
https://docs.openstack.org/project-deploy-guide
Hi all,
At the weekly meeting a week or two ago, we mentioned removing some old
/ unused images from Kolla in the interest of keeping the gate run times
down, as well as general code hygiene.
The images I've determined that are either no longer relevant, or were
simply never made use of in k
;mailto:aschu...@redhat.com>> wrote:
On Tue, Jun 26, 2018 at 8:05 AM, Paul Bourke mailto:paul.bou...@oracle.com>> wrote:
> Hi all,
>
> At the weekly meeting a week or two ago, we mentioned removing
some old /
> unused images from Kolla in the inter
Hi James,
Sorry to hear about the lack of participation. I for one am guilty of
not taking part, there just seems to be never enough time in the day to
cram in all the moving parts that a project like OpenStack requires.
That being said, this effort is definitely one of the most important to
+1. Will always have good memories of when Steve was getting the project
off the ground. Thanks Steve for doing a great job of building the
community around Kolla, and for all your help in general!
Best of luck,
-Paul
On 08/08/18 12:23, Eduardo Gonzalez wrote:
Steve,
Is sad to see you leavin
+1
On 25/09/18 16:47, Eduardo Gonzalez wrote:
Hi,
I would like to propose Chason Chan to the kolla-ansible core team.
Chason is been working on addition of Vitrage roles, rework VpnaaS
service, maintaining
documentation as well as fixing many bugs.
Voting will be open for 14 days (until 9th
c) Split the repository shortly after tagging 3.0.0 – creating a
kolla-ansible deliverable for Ocata.
On 15/09/16 07:12, Steven Dake (stdake) wrote:
Core Reviewers:
The facts:
We have roughly 250 bugs in rc2. Of those, I suspect over half can just
be closed out as dupes, fixed, wontf
+1
On 19/09/16 18:40, Jeffrey Zhang wrote:
Kolla core reviewer team,
Kolla supports multiple Linux distros now, including
* Ubuntu
* CentOS
* RHEL
* Fedora
* Debian
* OracleLinux
But only Ubuntu, CentOS, and OracleLinux are widely used and we have
robust gate to ensure the quality.
For fedor
-1 for deprecating Debian.
As I mentioned in https://review.openstack.org/#/c/369183/, Debian
support was added incrementally by Benedikt Trefzer as recently as June.
So it's reasonable to believe there is at least one active user of Debian.
I would like to try get some input from him on whet
If it's the case Benedict or noone else is interested in continuing
Debian, I can reverse my vote. Though it seems I'll be outvoted anyway ;)
On 20/09/16 10:21, Swapnil Kulkarni wrote:
On Tue, Sep 20, 2016 at 2:38 PM, Paul Bourke wrote:
-1 for deprecating Debian.
As I mentione
Tagging kolla
On 29/09/16 16:22, Michał Jastrzębski wrote:
Agree with Christian, this is our internal wiring. As long as we
provide automated upgrade procedure which will seamlessly migrate from
heka to alternative we want, we should be good without deprecation per
se.
Cheers,
Michal
On 29 Sep
Kolleagues,
How do people feel above removing the requirement of having TrivialFix
in commit messages where a bug/bp is not required?
I'm seeing a lot of valid and important commits being held up because of
this, in my opinion, unnecessary requirement. It also causes friction
for new contrib
Hi Jeremy,
> All I ask is that if the Kolla team wants to differentiate itself
> from the review requirements of most OpenStack projects, please make
We have no desire to do this, that's not what is being discussed here.
On the contrary we're looking to reduce the barrier to entry for
committe
Hi Joshua,
Thanks for sharing your workflow, interesting to see.
To answer your question, there is a 1:1 relationship between Kolla and
OpenStack releases. As Kevin outlined, you may get lucky, currently in
Oracle we deploy OpenStack Mitaka with Kolla Newton and for the most
part it works fin
Reminder Kolla, today is the deadline for feedback on this! Personally I
think it could use a few tweaks so please don't forget to take a look.
Link: http://tinyurl.com/OSmascot
On 21/10/16 21:58, Steven Dake (stdake) wrote:
Forgot kolla tag in subject.
From: Steven Dake mailto:std...@cisco.c
favor of removing the requirement for TrivialFix.
As per our standard policy, the voting window is open for 7 days
beginning November 3^rd , and finishing (in 7 days) on November 11^th .
Regards
-steve
*From: *Paul Bourke
*Reply-To: *"OpenStack Development Mailing List (not
Thanks for the reminder Andreas, patchset here:
https://review.openstack.org/397672
On 15/11/16 10:29, Andreas Jaeger wrote:
On 2016-11-15 11:10, Paul Bourke wrote:
Given the window for this vote is now closed and I saw no minus ones
I'll assume this has passed. TrivialFix is now opt
Seems good so far, thanks Michal / Steve. Cores don't forget to add
openstack/kolla-ansible to your watched projects in Gerrit :)
I assume we just -2 any Ansible related patches currently open against
the openstack/kolla project with instructions on how to resubmit.
Also has it been discussed
+1
On 17/11/16 07:18, Martin André wrote:
On Wed, Nov 16, 2016 at 7:23 PM, Michał Jastrzębski wrote:
Hello,
In light of recent events (kolla-kubernetes becoming thriving project,
kolla-ansible being split) I feel we need to change of core reviewer
election process.
Currently Kolla was single
Hi Darragh / git-upstream community,
I've been looking at a way to easily view a log of what commits made
since the last upstream import when managing a branch with git-upstream.
Right now this can be hard to do - something like 'git log
upstream/master..HEAD' shows a lot of duplicate commits
Seen as both repos stem from the same codebase, we should be able to
just cherry-pick changes as usual. If a fix comprises of a change to
both kolla and kolla-ansible, it will just mean two cherry-picks. Will
need to wait till the relevant pieces are removed from both repos to
confirm this but
If I'm understanding the requirement correctly, we want to know which
version of an OpenStack component is installed in an image? If so why
not just run something like:
# docker run kolla/oraclelinux-source-keystone:3.0.0 pip show keystone
Name: keystone
Version: 10.0.0.0rc2.dev290
[...]
Or eq
Propose all docs stay under the kolla namespace
(http://docs.openstack.org/developer/kolla).
Steve mentioned that we should try to keep all components (e.g. mailing
list tags) under the same umbrella which I agree with.
On 21/11/16 08:05, Jeffrey Zhang wrote:
After the split, we have two pro
There is some concerns internally around Ansible fact gathering, and how
it relates to adding / removing individual nodes in Kolla. As I've spent
a fair bit of time in this area I decided to send some info around both
for anyone confused about this in the future and also to tease out any
ways w
101 - 133 of 133 matches
Mail list logo
